Aplikacije i cloud15. lipnja 2026. · 9 min čitanja

Sigurnost u oblaku: što tvrtka mora znati

Prelazak u oblak ne prenosi i odgovornost za sigurnost na pružatelja. Evo kako funkcionira podijeljena odgovornost, koji su najčešći rizici i kako ih smanjiti.
Cloud inženjer pregledava konzolu i nadzornu ploču cloud infrastrukture.

Prelazak u oblak donosi fleksibilnost i brzinu, ali rijetko mijenja jednu zabludu: da pružatelj clouda preuzima brigu o sigurnosti. Istina je drugačija. Pružatelj osigurava infrastrukturu na kojoj usluge rade, ali za način na koji ih konfigurirate, tko im pristupa i kako štitite podatke odgovarate vi. Velik dio incidenata u oblaku posljedica je upravo pogrešne konfiguracije i loše kontrole identiteta, a ne propusta u temeljnoj infrastrukturi pružatelja. Egzotične eksploatacije postoje, ali su rijetke. Otvorena pohrana, preširoke ovlasti i ključevi u kodu rade puno više štete.

Za reguliranu tvrtku u Hrvatskoj to nije samo tehničko pitanje. Osobni podaci u oblaku ostaju pod GDPR-om, financijske institucije pod DORA-om, a operatori ključnih i važnih subjekata pod Zakonom o kibernetičkoj sigurnosti, koji prenosi NIS2. Sve te obveze traže dokaz da kontrolirate cloud okruženje i njegove dobavljače. Procjena sigurnosti u oblaku daje taj dokaz: sustavno provjerava konfiguraciju, identitet, mrežu, podatke i nadzor te pokazuje gdje stvarni rizik leži i kako ga zatvoriti.

Ovo je dio našeg pregleda sigurnosti aplikacija. Procjenu i jačanje cloud okruženja pružamo kroz procjenu sigurnosti u oblaku.

Zašto proboji dolaze od konfiguracije, ne od eksploatacija

Slika napadača koji probija šifriranje pružatelja clouda lijepa je za film, ali ne opisuje stvarnost. Pružatelji poput AWS-a, Azurea i Google Clouda ulažu ogromna sredstva u sigurnost svoje infrastrukture i ona rijetko popušta. Slaba točka je gotovo uvijek na strani korisnika: nešto je postavljeno pogrešno, netko ima previše prava, ili nitko ne gleda zapise.

Tipičan scenarij ne traži genija. Spremnik za pohranu ostane javno dostupan jer je netko mijenjao postavke u žurbi. Pristupni ključ završi u javnom repozitoriju koda. Servisni račun dobije administratorske ovlasti jer je tako bilo lakše dovršiti integraciju. Napadač ne provaljuje zid, nego prolazi kroz vrata koja su ostala otključana. Zato procjena sigurnosti u oblaku gleda postavke i ovlasti prije nego egzotične ranjivosti.

U oblaku napadač rijetko ruši zid. Najčešće prolazi kroz vrata koja je netko ostavio otključana.

Model podijeljene odgovornosti

Ključ razumijevanja cloud sigurnosti je model podijeljene odgovornosti. Pružatelj odgovara za sigurnost samog oblaka: fizičke poslužitelje, mrežu podatkovnog centra i temeljnu infrastrukturu virtualizacije. Korisnik odgovara za sigurnost u oblaku: kako konfigurira usluge, tko im ima pristup i kako štiti podatke koje u njih stavlja.1

Granica se pomiče ovisno o vrsti usluge. Kod virtualnih poslužitelja (IaaS) na vama je gotovo sve iznad hipervizora, uključujući operativni sustav i zakrpe. Kod platformi (PaaS) pružatelj preuzima operativni sustav, ali konfiguracija aplikacije i pristup ostaju vaši. Kod gotovih usluga (SaaS) pružatelj nosi najviše, ali kontrola identiteta, dijeljenje podataka i postavke i dalje su vaša odgovornost. Odgovornost korisnika nikada ne nestane, samo se mijenja njezin opseg.

PodručjeIaaSPaaS / SaaS
Fizička infrastruktura i podatkovni centarPružateljPružatelj
Mreža i virtualizacijaPružateljPružatelj
Operativni sustav i zakrpeKorisnikPružatelj
Konfiguracija usluga i mrežeKorisnikKorisnik
Identitet, pristup i ovlastiKorisnikKorisnik
Podaci, klasifikacija i enkripcijaKorisnikKorisnik
Tko za što odgovara ovisno o modelu usluge.

Identitet i pristup kao glavni put proboja

Upravljanje identitetima i pristupom (IAM) najvažniji je sloj cloud sigurnosti. U oblaku je identitet novi perimetar: tko ima koji ključ i koje ovlasti određuje što napadač može učiniti ako dođe do tih podataka. Kompromitiran administratorski račun u oblaku znači puno više od kompromitiranog radnog računala, jer otvara cijelo okruženje.

Najčešći problemi su preširoke ovlasti i eskalacija. Korisnici i servisni računi često dobiju prava unaprijed, za svaki slučaj, pa naprave puno više nego što im posao traži. Napadač koji preuzme takav račun može stvoriti nove identitete, dodijeliti si dodatna prava i kretati se kroz okruženje. Zato procjena gleda stvarne ovlasti, ne samo deklarirane uloge, i traži putove eskalacije gdje skroman pristup vodi do potpune kontrole. Temelj obrane je načelo najmanjih ovlasti i obavezna dvofaktorska autentifikacija za sve, posebno za administratorske račune.

Pogrešna konfiguracija usluga, mreže i izloženosti

Pogrešna konfiguracija najčešći je uzrok stvarnih incidenata u oblaku.2 Ne radi se o jednoj postavci nego o mnoštvu malih previda koji se zbroje. Spremnik za pohranu otvoren prema internetu. Baza podataka dostupna s bilo koje adrese umjesto samo s aplikacijskih poslužitelja. Sigurnosna grupa koja propušta promet na portovima koji su trebali biti zatvoreni. Upravljačka sučelja izložena javno bez ograničenja.

Problem se pogoršava jer se cloud okruženje mijenja svaki dan. Timovi stvaraju nove resurse, mijenjaju postavke i brišu stare usluge, a svaka promjena može otvoriti rupu. Ručna provjera ne stigne pratiti takav tempo. Zato ozbiljna procjena kombinira pregled trenutnog stanja s preporukom za kontinuirani nadzor konfiguracije, koji upozorava čim neka postavka odstupi od sigurnog standarda. Ista logika vrijedi za sigurnost web aplikacija i sigurnost API-ja koje se vrte u oblaku.

Zaštita podataka i enkripcija

Podaci su razlog zbog kojeg sve ostalo radimo. U oblaku ih treba zaštititi i u mirovanju, kad leže u pohrani ili bazi, i u prijenosu, dok putuju mrežom. Enkripcija u mirovanju danas je standardna i često uključena bez dodatnog truda, ali ključno pitanje je tko upravlja ključevima. Za osjetljive podatke razmislite o vlastitim ključevima umjesto onih kojima u potpunosti upravlja pružatelj, kako biste zadržali kontrolu nad pristupom.

Enkripcija nije sve. Podatke treba prvo klasificirati, jer ne traže svi istu razinu zaštite. Treba znati gdje se nalaze osobni i osjetljivi podaci, tko im pristupa i kuda se kopiraju. Mnogi proboji nisu pitanje slabe enkripcije nego činjenice da je kopija baze završila u testnom okruženju bez ikakve zaštite. Procjena prati taj tok podataka i provjerava da osjetljive informacije ne cure kroz sporedne kanale.

Zapisivanje i nadzor

Bez zapisa ne znate što se dogodilo. Cloud platforme nude detaljno bilježenje svake radnje u okruženju, od prijave korisnika do promjene konfiguracije, ali to bilježenje treba uključiti, čuvati i pratiti. Čest propust je da su zapisi uključeni samo djelomično, da se brišu prebrzo ili da ih nitko ne gleda dok se incident ne dogodi.

Cilj nadzora je primijetiti sumnjivu radnju dok još traje, a ne tjednima kasnije. Neuobičajena prijava iz strane zemlje, naglo stvaranje novih identiteta ili masovno preuzimanje podataka znakovi su koje sustav nadzora može uhvatiti. Zato procjena provjerava jesu li ključni zapisi uključeni, zaštićeni od brisanja i povezani s nekim obликom analize. Za tvrtke koje to ne mogu pratiti same, smisleno je razmotriti nadzor i odgovor (MDR) kao stalnu uslugu.

AWS, Azure i GCP: razlike na visokoj razini

Tri velika pružatelja dijele iste principe, ali ih nazivaju i slažu različito. Razumijevanje tih razlika važno je jer se sigurni obrasci ne prenose mehanički s jedne platforme na drugu. Sama načela, najmanje ovlasti, enkripcija i nadzor, ostaju ista, ali alati i zadane postavke se razlikuju.

FunkcijaAWSAzureGoogle Cloud
Upravljanje identitetomIAMEntra ID i IAM ulogeCloud IAM
Organizacija resursaAccounts i OrganizationsSubscriptions i Management GroupsProjects i Folders
Bilježenje radnjiCloudTrailActivity Log i MonitorCloud Audit Logs
Nadzor stanja sigurnostiSecurity HubDefender for CloudSecurity Command Center
Iste funkcije, različiti nazivi i naglasci kod tri velika pružatelja.

Praktična posljedica je da tim koji dobro poznaje AWS ne smije pretpostaviti da su zadane postavke u Azureu ili GCP-u jednako sigurne. Multi-cloud okruženja dodatno otežavaju stvar, jer treba održavati dosljedan standard preko različitih sučelja. Procjena uzima u obzir konkretnu platformu i njezine osobitosti, ne generičku listu.

Kako teče procjena sigurnosti u oblaku

Procjena nije slučajan pregled nego strukturiran proces. Cilj je dobiti potpunu sliku okruženja, pronaći stvarne rizike i dati konkretne, prioritizirane preporuke.

  1. 01
    Opseg i pristup
    Dogovaramo koje račune, pretplate i projekte gledamo te dobivamo pristup samo za čitanje konfiguracije i zapisa.
  2. 02
    Inventar i pregled stanja
    Mapiramo resurse, identitete, mreže i pohranu te uspoređujemo konfiguraciju sa sigurnim standardima za danu platformu.
  3. 03
    Analiza identiteta i ovlasti
    Tražimo preširoke ovlasti, trajne ključeve i putove eskalacije kojima skroman pristup vodi do kontrole okruženja.
  4. 04
    Provjera izloženosti i podataka
    Tražimo javno izloženu pohranu i usluge, provjeravamo enkripciju te pratimo tok osjetljivih podataka.
  5. 05
    Zapisi i nadzor
    Provjeravamo jesu li ključni zapisi uključeni, zaštićeni i praćeni, te postoji li mogućnost otkrivanja sumnjivih radnji.
  6. 06
    Izvještaj i prioriteti
    Predajemo nalaze poredane po riziku, s konkretnim preporukama i planom popravka koji tim može slijediti.

Po našem iskustvu prvi nalazi obično se vrte oko istih tema: prevelike ovlasti, izložena pohrana i nepotpuni zapisi. Trajanje i opseg ovise o veličini okruženja, a stvarna procjena ovisi o opsegu.

Česte greške koje ponavljamo

Iste pogreške pojavljuju se kod tvrtki svih veličina. Prepoznavanje obrazaca pomaže da ih izbjegnete prije nego postanu incident.

  • Pretpostavka da pružatelj brine o svemu, pa korisnik zanemari svoj dio odgovornosti.
  • Administratorske ovlasti dodijeljene unaprijed, za svaki slučaj, koje nitko kasnije ne smanji.
  • Pristupni ključevi i lozinke ostavljeni u kodu, skriptama i konfiguracijskim datotekama.
  • Zadane postavke prihvaćene bez provjere, jer je bilo brže nego razmišljati o sigurnoj konfiguraciji.
  • Zapisi isključeni ili prekratko čuvani, pa nakon incidenta nedostaje trag o tome što se dogodilo.
  • Sigurnost shvaćena kao jednokratan posao, bez kontinuiranog nadzora promjena.

Usklađenost: NIS2, ISO 27001 i GDPR

Korištenje oblaka ne smanjuje regulatorne obveze, nego ih čini izričitijima. GDPR i dalje vrijedi za osobne podatke u oblaku, a tvrtka ostaje voditelj obrade odgovoran za njihovu zaštitu, bez obzira na to gdje fizički leže. Ugovor s pružateljem mora urediti obradu podataka i jasno postaviti granice odgovornosti.

Regulirani subjekti pod Zakonom o kibernetičkoj sigurnosti, koji prenosi NIS2, moraju upravljati rizicima i kod vanjskih pružatelja usluga, što oblak izravno uključuje. ISO/IEC 27001:2022 traži kontrole nad informacijskom sigurnošću koje obuhvaćaju i cloud usluge, a popratni standard ISO/IEC 27017 daje konkretne smjernice za sigurnost u oblaku.1 Procjena sigurnosti u oblaku daje dokaze koje ti okviri traže: pregled stanja, popis rizika i plan popravka.

Kako Raptoric pomaže

Procjenjujemo konfiguraciju, identitet, mrežu, podatke i nadzor u AWS, Azure i Google Cloud okruženjima te pomažemo zatvoriti najčešće rizike prije nego postanu incident. Radimo neovisno o pružatelju, pa nalaz odražava vaš stvarni rizik, a ne prodaju nekog proizvoda. Cijelu uslugu pružamo kroz procjenu sigurnosti u oblaku. Dogovorite uvodni razgovor.

Česta pitanja

Brine li pružatelj clouda o našoj sigurnosti?
Samo djelomično. Pružatelj štiti fizičku infrastrukturu, mrežu podatkovnog centra i virtualizaciju, ali za konfiguraciju usluga, kontrolu pristupa i zaštitu podataka odgovara korisnik. To je model podijeljene odgovornosti, a opseg vaše odgovornosti mijenja se ovisno o vrsti usluge. Nikada ne nestane.
Koji je najčešći uzrok proboja u oblaku?
Pogrešna konfiguracija i preširoke ovlasti, ne sofisticirani napadi. Tipično se radi o javno izloženoj pohrani, pristupnim ključevima ostavljenima u kodu ili servisnim računima s administratorskim pravima. Napadač najčešće prolazi kroz postavke koje su ostavljene otključane, a ne kroz propust u infrastrukturi pružatelja.
Vrijedi li GDPR za podatke u oblaku?
Da. Prebacivanje podataka u oblak ne mijenja obveze prema GDPR-u. Tvrtka ostaje voditelj obrade i odgovorna je za zaštitu osobnih podataka bez obzira na to gdje leže. Odnos s pružateljem treba urediti ugovorom o obradi podataka, koji jasno postavlja granice odgovornosti obje strane.
Razlikuje li se sigurnost na AWS-u, Azureu i GCP-u?
Načela su ista: najmanje ovlasti, enkripcija, nadzor. Razlikuju se nazivi alata, organizacija resursa i zadane postavke. Sigurni obrazac s jedne platforme ne prenosi se mehanički na drugu. Zato procjena uzima u obzir konkretnu platformu, a multi-cloud okruženja traže dosljedan standard preko različitih sučelja.
Je li procjena sigurnosti u oblaku jednokratan posao?
Pregled je jednokratan, ali sigurnost nije. Cloud okruženje mijenja se svaki dan jer timovi stvaraju i mijenjaju resurse, a svaka promjena može otvoriti rizik. Zato uz početnu procjenu preporučujemo kontinuirani nadzor konfiguracije, koji upozorava čim neka postavka odstupi od sigurnog standarda.
Što obuhvaća procjena sigurnosti u oblaku?
Pregled konfiguracije usluga i mreže, analizu identiteta i ovlasti, provjeru izloženosti i zaštite podataka te pregled zapisa i nadzora. Rezultat je popis rizika poredan po prioritetu, s konkretnim preporukama. Procjena daje i dokaze koje traže NIS2, ISO/IEC 27001 i GDPR za reguliranu tvrtku.

Izvori

  1. 1ISO/IEC. ISO/IEC 27017: Code of practice for information security controls for cloud services. International Organization for Standardization, 2015. Poveznica
  2. 2ENISA. ENISA Threat Landscape. European Union Agency for Cybersecurity, 2024. Poveznica
Povezana usluga
Procjena sigurnosti u oblaku
Želite li ovakvu provjeru na vlastitim sustavima?
Naš tim definirat će opseg posla s vama u 30-minutnom razgovoru.
Dogovorite razgovor