Revizijski dokazi za oblak za ISO 27001, NIS2 i DORA
Maria, direktorica informacijske sigurnosti (CISO) u brzorastućoj tvrtki za financijsku analitiku, imala je šest tjedana do preklapanja triju rokova. Njezina nadzorna revizija prema ISO 27001:2022 već je bila zakazana. NIS2 je tvrtku, kao važan subjekt, doveo na novu razinu odgovornosti uprave. DORA je trebala provjeriti može li njezino fintech poslovanje dokazati digitalnu operativnu otpornost. Istodobno je veliki korporativni klijent odgađao potpisivanje ugovora dok njezin tim ne prođe detaljan pregled sigurnosnih potvrda.
Tvrtka nije bila nesigurna. Pokretala je produkcijska radna opterećenja u AWS-u i Azureu, koristila Microsoft 365 i nekoliko kritičnih SaaS platformi, provodila MFA, izrađivala sigurnosne kopije podataka, provodila skeniranja ranjivosti i prikupljala dnevničke zapise iz oblaka. Problem su bili dokazi.
Dokazi su bili raspršeni po snimkama zaslona iz Slacka, wiki stranicama razvojnih inženjera, izvozima iz konzola u oblaku, mapama nabave, pravnim ugovorima i usmenim uvjeravanjima vlasnika platformi. Kada bi revizor pitao: „Pokažite mi kako kontrolirate svoje okruženje u oblaku”, poveznica na stranicu pružatelja usluga u oblaku o usklađenosti ne bi bila dovoljna. Certifikati pružatelja dokazivali su kontrole pružatelja. Nisu dokazivali Marijinu stranu modela podijeljene odgovornosti.
Tu mnogi programi revizijskih dokaza za sigurnost u oblaku zakazuju. Ne zato što kontrole ne postoje, nego zato što organizacija ne može strukturirano i sljedivo dokazati koje odgovornosti pripadaju pružatelju, koje korisniku, kako su konfigurirane kontrole za SaaS i IaaS, kako se provode obveze dobavljača i kako se dokazi zadržavaju za revizore, regulatorna tijela i klijente.
Usklađenost oblaka više nije tehnički dodatak. Za pružatelja SaaS-a obuhvaćenog NIS2, financijski subjekt obuhvaćen DORA-om ili bilo koju organizaciju certificiranu prema ISO 27001:2022 koja koristi IaaS, PaaS i SaaS, upravljanje oblakom dio je opsega ISMS-a, plana obrade rizika, životnog ciklusa dobavljača, procesa za incidente, odgovornosti za privatnost i preispitivanja uprave.
Praktični cilj je jednostavan: izgraditi jedinstvenu arhitekturu dokaza za oblak spremnu za regulatorna tijela, koja odgovara na pitanja iz ISO 27001:2022, NIS2, DORA, GDPR, programa dokazivanja sigurnosti prema zahtjevima klijenata i interne revizije bez ponovne izrade dokaza za svaki okvir.
Oblak je uvijek u opsegu, čak i kada je infrastruktura izdvojena
Prva revizijska zamka jest pretpostavka da je izdvojena infrastruktura izvan ISMS-a. Nije. Izdvajanje mijenja granicu kontrola, ali ne uklanja odgovornost.
ISO/IEC 27001:2022 zahtijeva da organizacija definira svoj kontekst, zainteresirane strane, opseg ISMS-a, sučelja, ovisnosti i procese. U poslovanju kojem je oblak primarni model, pružatelj identiteta, račun za hosting u oblaku, CRM, platforma e-pošte, podatkovno skladište, CI/CD cjevovod, alat za evidentiranje zahtjeva i usluge sigurnosnog kopiranja često su temeljna poslovna infrastruktura.
Clarysecov Zenith Blueprint: Revizorova mapa puta u 30 koraka Zenith Blueprint naglašava to u fazi ISMS Foundation & Leadership, korak 2, Potrebe dionika i opseg ISMS-a:
„Ako svoju IT infrastrukturu izdvojite pružatelju usluga u oblaku, to je ne isključuje iz opsega; naprotiv, u opseg uključujete upravljanje tim odnosom i imovinu u oblaku jer je sigurnost vaših podataka u oblaku vaša odgovornost.”
Ta je izjava revizijsko uporište. Vaš opseg ne bi trebao glasiti: „AWS je isključen jer njime upravlja Amazon.” Trebao bi navesti da su informacijska imovina i procesi povezani s uslugama hostiranima na AWS-u u opsegu, uključujući upravljanje sigurnosnim kontrolama u oblaku, identitetom, zapisivanjem događaja, šifriranjem, sigurnosnim kopiranjem, provjerama dobavljača i odgovorom na incidente.
Za ISO 27001:2022 to podupire točke 4.1 do 4.4 o kontekstu, zainteresiranim stranama, opsegu i procesima ISMS-a. Za NIS2 podupire očekivanja iz Article 21 za analizu rizika, postupanje s incidentima, neprekidnost poslovanja, sigurnost opskrbnog lanca, sigurnu nabavu i održavanje, kontrolu pristupa, upravljanje imovinom, kriptografiju, djelotvornost kontrola i MFA gdje je primjenjivo. Za DORA podupire načelo da financijski subjekti ostaju odgovorni za IKT rizik čak i kada su IKT usluge izdvojene.
Pitanje nije je li vaš pružatelj usluga u oblaku siguran. Pitanje je upravljate li vlastitim korištenjem pružatelja, konfigurirate li svoju stranu ispravno, nadzirete li uslugu, upravljate li obvezama dobavljača i zadržavate li dokaze.
Podijeljena odgovornost mora postati podijeljeni dokaz
Pružatelji usluga u oblaku objašnjavaju podijeljenu odgovornost. Revizori provjeravaju jeste li je proveli u praksi.
U IaaS-u pružatelj obično osigurava fizičke lokacije, temeljnu infrastrukturu i hipervizor. Korisnik kontrolira identitet, konfiguraciju radnih opterećenja, otvrdnjavanje operacijskog sustava, sigurnost aplikacija, klasifikaciju podataka, postavke šifriranja, mrežna pravila, zapisivanje događaja, sigurnosne kopije, zakrpavanje i odgovor na incidente.
U SaaS-u pružatelj kontrolira većinu operacija platforme, ali korisnik i dalje kontrolira konfiguraciju korisničkog okruženja, korisnike, administratorske uloge, integracije, dijeljenje podataka, zadržavanje, opcije zapisivanja događaja i postupke eskalacije.
Clarysecov Zenith Controls: Vodič za višestruku usklađenost Zenith Controls tretira kontrolu ISO/IEC 27002:2022 5.23, Informacijska sigurnost pri korištenju usluga u oblaku, kao središnju kontrolu upravljanja oblakom s preventivnom namjenom u području povjerljivosti, cjelovitosti i dostupnosti. Povezuje usluge u oblaku s odnosima s dobavljačima, sigurnim prijenosom informacija, popisom imovine, sprječavanjem curenja podataka, sigurnošću krajnjih uređaja i mreže te praksama sigurnog razvoja.
Ključno tumačenje u Zenith Controls navodi:
„Pružatelji usluga u oblaku (CSP) djeluju kao kritični dobavljači, pa se primjenjuju sve kontrole koje se odnose na odabir dobavljača, ugovaranje i upravljanje rizicima prema 5.19. Međutim, 5.23 ide dalje jer adresira rizike specifične za oblak, kao što su višekorisničko okruženje, transparentnost lokacije podataka i modeli podijeljene odgovornosti.”
Ta je razlika ključna. Sami certifikati dobavljača ne zadovoljavaju Prilog A.5.23. Potrebni su dokazi na strani korisnika koji pokazuju da se uslugom u oblaku upravlja, da je konfigurirana, praćena i pregledavana.
| Područje dokaza | Što revizor želi vidjeti | Tipični dokaz |
|---|---|---|
| Popis usluga u oblaku | Poznate su odobrene SaaS, PaaS i IaaS usluge | Registar usluga u oblaku, popis vlasnika, vrste podataka, regije, ugovori |
| Podijeljena odgovornost | Odgovornosti pružatelja i korisnika dokumentirane su | Matrica odgovornosti, dokumentacija pružatelja, interno mapiranje kontrola |
| Osnovna konfiguracija | Postavke pod kontrolom korisnika slijede odobrenu osnovnu konfiguraciju | CSPM izvješća, izvozi sigurnosne ocjene, provjere Terraform politika, snimke zaslona |
| Identitet i pristup | Administratorski i korisnički pristup kontrolira se i pregledava | MFA izvješća, SSO konfiguracija, pregled privilegiranih uloga, uzorci izlaznog procesa |
| Zapisivanje događaja i praćenje | Relevantni dnevnički zapisi iz oblaka omogućeni su, zadržani i pregledani | SIEM integracija, pravila upozorenja, postavke zadržavanja dnevničkih zapisa, evidencije incidenata |
| Obveze dobavljača | Ugovori sadržavaju provedive sigurnosne odredbe | DPA, SLA, prava na reviziju, prijava povrede podataka, uvjeti za podizvođače |
| Neprekidnost i izlaz | Kritične usluge mogu se oporaviti ili prenijeti | Testovi sigurnosnih kopija, izlazni plan, dokazi oporavka, pregled rizika koncentracije |
| Spremnost za incidente | Incidenti u oblaku mogu se otkriti, klasificirati i prijaviti | Operativne upute, dokazi eskalacije, tijek rada za obavješćivanje regulatora |
To je razlika između postojanja kontrola u oblaku i kontrola u oblaku spremnih za reviziju.
Počnite s registrom usluga u oblaku koji revizori mogu koristiti
Najbrži način za poboljšanje revizijske spremnosti oblaka jest izrada potpunog registra usluga u oblaku. To ne smije biti popis nabave ni izvoz iz financija. Mora povezati usluge u oblaku s podacima, vlasnicima, regijama, pristupom, ugovorima, kritičnošću, regulatornom relevantnošću i dokazima.
Clarysecova Politika korištenja usluga u oblaku za MSP Politika korištenja usluga u oblaku za MSP daje sažetu i revizijski prikladnu osnovu u točki 5.3:
„Registar usluga u oblaku mora održavati pružatelj IT usluga ili glavni direktor. Mora evidentirati: 5.3.1 naziv i svrhu svake odobrene usluge u oblaku 5.3.2 odgovornu osobu ili tim (vlasnik aplikacije) 5.3.3 vrste podataka koje se pohranjuju ili obrađuju 5.3.4 državu ili regiju u kojoj se podaci pohranjuju 5.3.5 korisnička prava pristupa i administratorske račune 5.3.6 detalje ugovora, datume obnove i kontakte za podršku”
Za korporativna okruženja Clarysecova Politika korištenja usluga u oblaku Politika korištenja usluga u oblaku uspostavlja širi mandat:
„Ova politika utvrđuje obvezne zahtjeve organizacije za sigurnu, usklađenu i odgovornu uporabu usluga računalstva u oblaku kroz modele isporuke infrastruktura kao usluga (IaaS), platforma kao usluga (PaaS) i softver kao usluga (SaaS).”
Politika korištenja usluga u oblaku zahtijeva centralizirani registar u vlasništvu direktora informacijske sigurnosti (CISO) i odobrene osnovne konfiguracije za okruženja u oblaku. Taj registar postaje temelj dokaza za više obveza odjednom.
Za ISO 27001:2022 podupire popis imovine, upravljanje korištenjem usluga u oblaku, odnose s dobavljačima, kontrolu pristupa, pravne i ugovorne zahtjeve, obradu rizika i dokumentirane informacije. Za NIS2 podupire sigurnost opskrbnog lanca, upravljanje imovinom, analizu rizika, postupanje s incidentima i neprekidnost. Za DORA podupire mapiranje IKT imovine i ovisnosti, registre IKT trećih strana, mapiranje kritičnih ili važnih funkcija i analizu rizika koncentracije. Za GDPR identificira obrađuju li se osobni podaci, gdje se nalaze, koji pružatelj djeluje kao izvršitelj obrade te koji se uvjeti prijenosa ili obrade podataka primjenjuju.
Ako registar ne identificira kategorije podataka i regije, dokazi za privatnost i otpornost bit će nepotpuni. Ako ne identificira vlasnike aplikacija, pregledi pristupa ostat će bez vlasnika. Ako ne identificira ugovore i datume obnove, sigurnosne odredbe za dobavljače ne mogu se testirati.
Pretvorite ISO 27001:2022 u okosnicu dokaza za oblak
ISO 27001:2022 najbolja je okosnica za dokaze u oblaku jer povezuje poslovni kontekst, rizik, kontrole, operativne dokaze, praćenje i poboljšanje.
Ključni zahtjevi ISO 27001:2022 relevantni za oblak uključuju:
- Točke 4.1 do 4.4 za kontekst, zainteresirane strane, opseg ISMS-a, sučelja, ovisnosti i procese.
- Točke 5.1 do 5.3 za vodstvo, politiku, uloge, odgovornosti i odgovornost.
- Točke 6.1.1 do 6.1.3 za procjenu rizika, obradu rizika, usporedbu s Prilogom A, Izjavu o primjenjivosti i prihvaćanje preostalog rizika.
- Točku 7.5 za kontrolirane dokumentirane informacije.
- Točke 8.1 do 8.3 za operativno planiranje, provedbu procjene rizika i provedbu obrade rizika.
- Točke 9.1 do 9.3 za praćenje, mjerenje, internu reviziju i preispitivanje uprave.
- Točku 10 za nesukladnosti, korektivne radnje i kontinuirano poboljšanje.
Kontrole iz Priloga A koje nose najveću težinu dokaza za oblak uključuju A.5.19 Informacijska sigurnost u odnosima s dobavljačima, A.5.20 Uređivanje informacijske sigurnosti u ugovorima s dobavljačima, A.5.21 Upravljanje informacijskom sigurnošću u IKT opskrbnom lancu, A.5.22 Praćenje, pregled i upravljanje promjenama usluga dobavljača, A.5.23 Informacijska sigurnost pri korištenju usluga u oblaku, A.5.24 do A.5.27 upravljanje incidentima, A.5.29 Informacijska sigurnost tijekom prekida, A.5.30 IKT spremnost za neprekidnost poslovanja, A.5.31 Pravni, zakonski, regulatorni i ugovorni zahtjevi, A.5.34 Privatnost i zaštita PII, A.5.36 Usklađenost s politikama, pravilima i standardima za informacijsku sigurnost, A.8.8 Upravljanje tehničkim ranjivostima, A.8.9 Upravljanje konfiguracijom, A.8.13 Sigurnosno kopiranje informacija, A.8.15 Zapisivanje događaja, A.8.16 Aktivnosti praćenja, A.8.24 Uporaba kriptografije, A.8.25 Sigurni životni ciklus razvoja softvera, A.8.29 Sigurnosno testiranje u razvoju i prihvatu te A.8.32 Upravljanje promjenama.
U Zenith Blueprint, faza Controls in Action, korak 23, objašnjava usluge u oblaku jezikom koji je blizak revizorima:
„Prijelaz na usluge u oblaku uvodi duboke promjene u model povjerenja. Više ne kontrolirate poslužitelj, mrežni perimetar ni hipervizor. Često čak ne znate gdje se podaci fizički nalaze. Ono što kontrolirate, i što ova kontrola provodi, jest upravljanje tim odnosom, vidljivost nad onim što koristite i sigurnosna očekivanja koja postavljate svojim pružateljima.”
Snažan zapis u Izjavi o primjenjivosti za A.5.23 ne bi trebao navoditi samo „Primjenjivo, pružatelj usluge u oblaku certificiran”. Trebao bi objasniti zašto se kontrola primjenjuje, koje rizike obrađuje, kako je implementirana i gdje su pohranjeni dokazi.
| Polje SoA | Primjer sadržaja za A.5.23 |
|---|---|
| Primjenjivost | Primjenjivo jer se poslovno kritične usluge izvode na SaaS i IaaS platformama |
| Obrazloženje | Usluge u oblaku obrađuju podatke klijenata, podatke zaposlenika i produkcijska radna opterećenja |
| Obrađeni rizici | Pogrešna konfiguracija, neovlašteni pristup, curenje podataka, otkaz pružatelja, promjena regije, praznine u zapisivanju događaja |
| Status implementacije | Registar usluga u oblaku održava se, osnovne konfiguracije odobrene su, MFA se provodi, dnevnički zapisi integrirani su, pregledi dobavljača provedeni su |
| Dokazi | Registar usluga u oblaku, konfiguracijska izvješća, pregled pristupa, SIEM nadzorne ploče, ugovor s dobavljačem, pregled SOC izvješća, test sigurnosne kopije |
| Regulatorno mapiranje | NIS2 Article 21, DORA Articles 28 to 30, GDPR Articles 28 and 32, ugovori s klijentima |
| Vlasnik | CISO za upravljanje, arhitekt sigurnosti u oblaku za osnovnu konfiguraciju, vlasnici aplikacija za kontrole na razini usluge |
Dodajte stupac lokacije dokaza u SoA ili alat za praćenje kontrola. Revizori ne bi trebali pretraživati e-poštu, sustave za evidentiranje zahtjeva i dijeljene diskove kako bi pronašli dokaze.
Koristite jedan model dokaza za ISO 27001:2022, NIS2 i DORA
NIS2 i DORA zahtijevaju dokumentiranu kibernetičku sigurnost temeljenu na riziku i vođenu upravom. Preklapanje je znatno, ali nadzorni pritisak razlikuje se.
NIS2 se primjenjuje na mnoge ključne i važne subjekte u EU, uključujući pružatelje digitalne infrastrukture, pružatelje upravljanih usluga, pružatelje upravljanih sigurnosnih usluga, bankarstvo, infrastrukture financijskog tržišta i digitalne pružatelje. Article 21 zahtijeva odgovarajuće i razmjerne tehničke, operativne i organizacijske mjere, uključujući analizu rizika, postupanje s incidentima, neprekidnost poslovanja, sigurnost opskrbnog lanca, sigurnu nabavu i održavanje, postupanje s ranjivostima, procjenu djelotvornosti kontrola, kibernetičku higijenu, osposobljavanje, kriptografiju, kontrolu pristupa, upravljanje imovinom i MFA ili sigurne komunikacije gdje je primjenjivo.
Za revizijske dokaze sigurnosti u oblaku NIS2 provjerava upravlja li se rizicima oblaka i dobavljača kao dijelom rizika pružanja usluge. Donosi i strukturirano prijavljivanje značajnih incidenata, uključujući rano upozorenje unutar 24 sata, obavijest o incidentu unutar 72 sata i završno izvješće u roku od jednog mjeseca.
DORA se primjenjuje od 17. siječnja 2025. na mnoge financijske subjekte u EU i uvodi jedinstvene zahtjeve za upravljanje IKT rizicima, prijavljivanje većih IKT incidenata, testiranje digitalne operativne otpornosti, razmjenu informacija i IKT rizik trećih strana. Za financijske subjekte koji su također identificirani prema NIS2, DORA se smatra sektorskim pravnim aktom Unije za preklapajuće operativne obveze.
Za oblak je DORA izravna. Financijski subjekti ostaju odgovorni za IKT rizik kada su usluge izdvojene. Potrebne su im strategije za IKT treće strane, registri ugovora, procjene prije sklapanja ugovora, dubinska analiza dobavljača, prava na reviziju i pristup, okidači raskida, analiza rizika koncentracije, kontrole podugovaranja i testirane izlazne strategije.
Zenith Controls mapira kontrolu ISO/IEC 27002:2022 5.23 na EU NIS2 Article 21 i DORA Articles 28 to 31. Upućuje i na prateće standarde kao što su ISO/IEC 27017 za sigurnosne uloge i praćenje u oblaku, ISO/IEC 27018 za zaštitu PII u javnom oblaku, ISO/IEC 27701 za upravljanje privatnošću u odnosima s izvršiteljima obrade u oblaku, ISO/IEC 27036-4 za praćenje usluga u oblaku i ugovore s dobavljačima te ISO/IEC 27005 za procjenu rizika u oblaku.
| Okvir | Relevantna točka ili članak | Kako dokazi za A.5.23 pomažu |
|---|---|---|
| ISO 27001:2022 | Točke 4, 6, 8, 9 i Prilog A.5.23 | Dokazuje da je korištenje oblaka obuhvaćeno opsegom, procijenjeno prema riziku, kontrolirano, praćeno, revidirano i poboljšavano |
| NIS2 | Article 21 | Pokazuje razmjerne mjere za sigurnost opskrbnog lanca, kontrolu pristupa, neprekidnost, postupanje s incidentima i upravljanje imovinom |
| DORA | Articles 28 to 31 | Podupire dubinsku analizu IKT trećih strana, ugovore, praćenje, rizik koncentracije, izlazne planove i nadzor |
| GDPR | Articles 28 and 32 | Podupire upravljanje izvršiteljima obrade, sigurnost obrade, spremnost za povredu i odgovornost za privatnost u oblaku |
Praktična je posljedica jednostavna. Nemojte graditi odvojene pakete dokaza za ISO 27001:2022, NIS2, DORA i GDPR. Izgradite jednu arhitekturu dokaza za oblak s mapiranjima po pojedinom okviru.
Ugovori s dobavljačima su dokaz kontrola, a ne pravni arhivi
Revizijski dokazi za oblak često pucaju na ugovornoj razini. Sigurnost ima upitnik za dobavljača. Pravni poslovi imaju MSA. Nabava ima datum obnove. Službenik za zaštitu podataka (DPO) ima DPA. Nitko nema jedinstven pogled na to sadržava li ugovor sigurnosne odredbe koje zahtijevaju ISO 27001:2022, NIS2, DORA i GDPR.
Clarysecova Politika sigurnosti trećih strana i dobavljača za MSP Politika sigurnosti trećih strana i dobavljača za MSP navodi u točki 5.3:
„Ugovori moraju uključivati obvezne odredbe koje obuhvaćaju: 5.3.1 povjerljivost i obvezu neotkrivanja 5.3.2 obveze informacijske sigurnosti 5.3.3 rokove za prijavu povrede podataka (npr. unutar 24–72 sata) 5.3.4 prava na reviziju ili dostupnost dokaza usklađenosti 5.3.5 ograničenja daljnjeg podugovaranja bez odobrenja 5.3.6 uvjete raskida, uključujući siguran povrat ili uništenje podataka”
Radi revizijske dosljednosti, pretvorite te odredbe u matricu pregleda ugovora. ISO 27001:2022 Prilog A.5.20 očekuje da sigurnosni zahtjevi budu dogovoreni s dobavljačima. GDPR Article 28 zahtijeva uvjete za izvršitelja obrade koji obuhvaćaju povjerljivost, sigurnosne mjere, pomoć, podizvršitelje obrade, brisanje ili povrat podataka i revizijsku podršku. DORA Article 30 zahtijeva detaljne ugovorne odredbe za pružatelje IKT usluga trećih strana, uključujući opise usluga, lokaciju podataka, sigurnost, pomoć pri incidentima, suradnju s nadležnim tijelima, prava na reviziju, prava pristupa, raskid i prijelazne aranžmane. Sigurnost opskrbnog lanca prema NIS2 također zahtijeva provedivu suradnju dobavljača.
Zenith Controls mapira kontrolu ISO/IEC 27002:2022 5.20 na ugovore s dobavljačima i bilježi veze s 5.19 odnosima s dobavljačima, 5.14 prijenosom informacija, 5.22 praćenjem dobavljača, 5.11 povratom imovine i 5.36 usklađenošću.
Ključ je operativna provedba. Ako ugovor za oblak daje pristup SOC 2 izvješćima, revizori mogu pitati jeste li izvješće pribavili, pregledali iznimke, pratili korektivne radnje i ponovno procijenili rizik. Ako ugovor obećava obavijest o povredi, mogu pitati uključuju li vaše operativne upute za incident kontaktni put prema dobavljaču i regulatorne točke odlučivanja. Ako promjene podizvođača zahtijevaju odobrenje ili obavijest, mogu pitati pregledavaju li se obavijesti o podizvršiteljima obrade prije prihvaćanja.
Ugovor bez dokaza pregleda jest arhiv. Ugovor povezan s rizikom dobavljača, evidencijom praćenja i tijekovima rada za incidente jest kontrola.
Zapisivanje događaja i konfiguracija SaaS-a česte su slijepe točke revizije
Nalazi u oblaku često dolaze iz SaaS-a, a ne iz IaaS-a. Infrastrukturni timovi obično imaju tehničke vlasnike, kanale za zapisivanje, osnovne kontrole i evidenciju promjena. SaaS platforme fragmentirane su kroz prodaju, HR, financije, korisnički uspjeh, marketing i operacije. Svaka može obrađivati osjetljive ili regulirane podatke.
Clarysecova Politika zapisivanja događaja i praćenja za MSP Politika zapisivanja događaja i praćenja za MSP izravno adresira to u točki 5.5:
„5.5 Usluge u oblaku i zapisivanje događaja trećih strana 5.5.1 Za platforme na kojima zapisivanje događaja nije pod izravnom IT kontrolom (npr. SaaS e-pošta), primjenjuju se sljedeći zahtjevi: 5.5.1.1 zapisivanje događaja mora biti omogućeno i konfigurirano gdje je dostupno 5.5.1.2 upozorenja se moraju usmjeriti pružatelju IT podrške 5.5.1.3 ugovori moraju zahtijevati od pružatelja da zadržavaju dnevničke zapise najmanje 12 mjeseci i omoguće pristup na zahtjev”
Za korporativna okruženja Politika korištenja usluga u oblaku dodaje:
„Usluge u oblaku moraju biti integrirane u SIEM organizacije radi kontinuiranog praćenja.”
Taj zahtjev premješta SaaS iz kategorije „poslovni alat” u kategoriju „praćeni informacijski sustav”. Dokazi trebaju uključivati izvoze postavki zapisivanja događaja, dokaz SIEM konektora, pravila upozorenja, zapise trijaže, postavke zadržavanja i preglede administratorskog pristupa.
Za kritični SaaS pripremite dokaze za otvaranje administratorskih računa, sumnjive prijave, masovna preuzimanja, javno dijeljenje, onemogućavanje MFA, izradu API tokena, aktivnost vanjskih gostiju i eskalaciju privilegija. Za IaaS pripremite CloudTrail ili ekvivalentno zapisivanje upravljačke ravnine, zapise pristupa pohrani, IAM promjene, zapise tokova gdje je primjenjivo, CSPM nalaze, skeniranja ranjivosti, dokaze zakrpavanja, postavke šifriranja, status sigurnosnih kopija, preglede mrežnih sigurnosnih grupa i evidenciju promjena.
Revizijska metodologija Zenith Controls za kontrolu 5.23 navodi da revizija u stilu ISO/IEC 27007 može pregledavati dopuštenja AWS S3 spremnika, šifriranje, IAM politike i CloudTrail zapisivanje. Revizor usmjeren na COBIT može pregledati konfiguracije upozorenja, DLP kontrole, korištenje Microsoft 365 Secure Score i evidenciju upravljanja promjenama. Perspektiva NIST SP 800-53A može testirati upravljanje računima i praćenje, uključujući provjeru jesu li radna opterećenja u oblaku zakrpana, skenirana i praćena jednakom strogošću kao interni sustavi.
Različiti revizori govore različitim dijalektima. Vaši dokazi trebaju biti isti.
Izgradite paket dokaza spreman za regulatorna tijela za jednu SaaS i jednu IaaS uslugu
Praktičan tijek rada počinje s jednom kritičnom SaaS platformom i jednim kritičnim IaaS okruženjem. Primjerice, Microsoft 365 za suradnju i AWS za produkcijski hosting.
Korak 1: Ažurirajte registar usluga u oblaku
Za Microsoft 365 evidentirajte svrhu, vlasnika, vrste podataka, regiju, administratorske račune, ugovor, DPA, kontakt za podršku, datum obnove i kritičnost. Za AWS evidentirajte produkcijski račun, regije, kategorije podataka, radna opterećenja, vlasnika računa, status root računa, plan podrške, ugovorne uvjete i povezane poslovne usluge.
Koristite polja iz Politike korištenja usluga u oblaku za MSP kao minimalni skup podataka. Dodajte kritičnost, regulatornu relevantnost i lokaciju dokaza.
Korak 2: Dokumentirajte podijeljenu odgovornost
Za Microsoft 365 odgovornosti korisnika uključuju životni ciklus korisnika, MFA, uvjetni pristup, dijeljenje s gostima, oznake zadržavanja, DLP gdje se koristi, zapisivanje događaja i eskalaciju incidenta. Za AWS odgovornosti korisnika uključuju IAM, mrežna pravila, otvrdnjavanje radnih opterećenja, konfiguraciju šifriranja, sigurnosno kopiranje, zapisivanje događaja, zakrpavanje i sigurnost aplikacija.
Priložite dokumentaciju pružatelja o podijeljenoj odgovornosti, zatim mapirajte svaku odgovornost korisnika na vlasnika kontrole i izvor dokaza.
Korak 3: Prikupite konfiguracijske dokaze
Za Microsoft 365 izvezite ili snimite zaslon MFA i politika uvjetnog pristupa, administratorskih uloga, postavki vanjskog dijeljenja, revizijskog zapisivanja, konfiguracije zadržavanja i radnji sigurnosne ocjene. Za AWS izvezite IAM politiku lozinki, status MFA za privilegirane korisnike, CloudTrail konfiguraciju, blokadu javnog pristupa za S3, status šifriranja, pregled sigurnosnih grupa, poslove sigurnosnog kopiranja i status skeniranja ranjivosti.
Politika korištenja usluga u oblaku zahtijeva da okruženja u oblaku budu usklađena s dokumentiranom osnovnom konfiguracijom koju je odobrio arhitekt sigurnosti u oblaku. Vaš paket dokaza treba uključivati i osnovnu konfiguraciju i dokaz usklađenosti s njom.
| Zahtjev politike | Poduzeta radnja | Generirani revizijski dokaz |
|---|---|---|
| MFA za pristup s povišenim ovlastima | MFA proveden na administratorskim računima i pristupu konzoli | Izvoz MFA politike, uzorak povlaštenog računa, pregled hitnog računa |
| Zapisivanje aktivnosti | Revizijski zapisi iz oblaka omogućeni su i usmjereni u SIEM | Snimka zaslona CloudTrail ili SaaS revizijskog dnevnika, dokaz SIEM unosa, postavka zadržavanja |
| Ograničenja pristupa | Primijenjene su uloge prema načelu najmanjih ovlasti i tromjesečni pregledi pristupa | Izvoz IAM uloga, pregled administratorskih uloga, odobrenje vlasnika podataka |
| Sigurna konfiguracija | Postavke u oblaku mjerene su prema odobrenoj osnovnoj konfiguraciji | CSPM izvješće, izvoz sigurnosne ocjene, registar iznimki |
| Sigurnosno kopiranje i oporavak | Testirano je vraćanje za kritična radna opterećenja ili podatke | Status posla sigurnosnog kopiranja, zapis testa vraćanja, naučene lekcije |
Korak 4: Povežite dokaze o dobavljaču i privatnosti
Priložite ugovor, DPA, popis podizvršitelja obrade, uvjete prijave povrede, izvješća o sigurnosnim potvrdama i dokaze o lokaciji podataka. Ako se obrađuju osobni podaci, evidentirajte djeluje li pružatelj kao izvršitelj obrade, kako se provodi brisanje, kako funkcionira podrška za zahtjeve ispitanika i koje se zaštitne mjere za prijenos primjenjuju.
Za DORA utvrdite podupire li usluga u oblaku kritičnu ili važnu funkciju. Ako da, povežite dokaze s registrom IKT trećih strana, datotekom dubinske analize dobavljača, pravima na reviziju, izlaznim planom i pregledom rizika koncentracije.
Korak 5: Povežite zapisivanje događaja s odgovorom na incidente
Pokažite da su dnevnički zapisi omogućeni, usmjereni, pregledavani i korišteni. Priložite SIEM nadzorne ploče, pravila upozorenja i najmanje jedan zatvoreni zapis upozorenja. Zatim mapirajte tijek rada na točke odlučivanja za prijavljivanje prema NIS2 i DORA.
Za NIS2 proces za incidente mora podržavati rano upozorenje u roku od 24 sata, obavijest o incidentu u roku od 72 sata i završno izvješće u roku od jednog mjeseca za značajne incidente. Za DORA proces za IKT incidente trebao bi klasificirati incidente prema pogođenim klijentima, transakcijama, trajanju, prekidu rada, geografskom opsegu, utjecaju na podatke, kritičnosti usluge i ekonomskom učinku.
Korak 6: Pohranite dokaze disciplinirano
Clarysecova Politika praćenja revizije i usklađenosti za MSP Politika praćenja revizije i usklađenosti za MSP, točka 6.2, definira praktičnu disciplinu dokaza:
„6.2 Prikupljanje i dokumentiranje dokaza 6.2.1 Svi dokazi moraju biti pohranjeni u centraliziranoj mapi za reviziju. 6.2.2 Nazivi datoteka moraju jasno upućivati na temu revizije i datum. 6.2.3 Metapodaci (npr. tko ih je prikupio, kada i iz kojeg sustava) moraju biti dokumentirani. 6.2.4 Dokazi se moraju zadržati najmanje dvije godine ili dulje ako to zahtijevaju certifikacija ili ugovori s klijentima.”
Korporativna Politika praćenja revizije i usklađenosti Politika praćenja revizije i usklađenosti navodi cilj:
„Generirati dokazive dokaze i revizijski trag kao potporu regulatornim upitima, pravnim postupcima ili zahtjevima klijenata za pružanje potvrda.”
Snimka zaslona nazvana „screenshot1.png” slab je dokaz. Datoteka nazvana „AWS-Prod-CloudTrail-Enabled-2026-05-10-CollectedBy-JSmith.png” snažnija je jer opisuje sustav, kontrolu, datum i osobu koja ju je prikupila. Metapodaci su važni jer revizori moraju moći vjerovati kada je dokaz prikupljen, tko ga je prikupio i iz kojeg sustava.
Kako revizori testiraju istu kontrolu u oblaku
Najjači paketi dokaza za oblak oblikovani su za više revizijskih perspektiva. Revizori ISO 27001:2022 provjeravaju je li kontrola u ISMS-u, procjeni rizika, obradi rizika i SoA. Procjenitelji usmjereni na NIST testiraju tehničku implementaciju. Revizori COBIT 2019 testiraju upravljanje, učinkovitost dobavljača i integraciju procesa. Revizori privatnosti usredotočuju se na obveze izvršitelja obrade, rezidentnost podataka, spremnost za povrede i prava ispitanika. Nadzorni pregledi prema DORA-i usredotočuju se na IKT rizik trećih strana i otpornost.
| Revizijska perspektiva | Vjerojatno revizijsko pitanje | Dokazi za pripremu |
|---|---|---|
| ISO 27001:2022 | Zašto je kontrola u oblaku primjenjiva i kako je implementirana u okviru ISMS-a? | Izjava o opsegu, registar rizika, SoA, politika za oblak, registar, osnovna konfiguracija, zapisi interne revizije |
| Revizija ISMS-a u stilu ISO/IEC 27007 | Mogu li se konfiguracija i dokumentacija provjeriti kroz intervjue i uzorke? | Snimke zaslona, izvozi, provjera samo za čitanje, intervjui s vlasnicima usluga u oblaku i SaaS usluga |
| NIST SP 800-53A | Kontroliraju li se računi u oblaku, praćenje i vanjske usluge kao interni sustavi? | IAM pregled, zapisi životnog ciklusa računa, SIEM dnevnički zapisi, skeniranja ranjivosti, zahtjevi za vanjske usluge |
| COBIT 2019 | Prate li se, mijenjaju i upravljaju uslugama dobavljača prema poslovnom riziku? | Zapisnici pregleda dobavljača, KPI-ji, KRI-ji, SLA izvješća, zapisi promjena, ponovne procjene rizika |
| ISACA ITAF | Jesu li dokazi dostatni, pouzdani i zadržani za potporu zaključcima? | Centralizirana mapa dokaza, metapodaci, izvozi iz izvora, tragovi prijava, odobrenja |
| Revizija privatnosti i GDPR | Jesu li obveze izvršitelja obrade i kontrole osobnih podataka operativne u oblaku? | DPA, SCC-ovi gdje je potrebno, dokaz rezidentnosti podataka, postupak brisanja, pristup evidenciji povreda, testovi vraćanja |
| Nadzorni pregled prema DORA-i | Može li financijski subjekt dokazati nadzor nad IKT trećim stranama i otpornost? | Registar IKT ugovora, mapiranje kritičnih funkcija, izlazna strategija, pregled rizika koncentracije, rezultati testiranja |
| Upit nadležnog tijela prema NIS2 | Može li subjekt pokazati razmjerne mjere kibernetičke sigurnosti i spremnost za prijavljivanje incidenata? | Mapiranje Article 21, operativne upute za incident, dokazi sigurnosti dobavljača, testovi neprekidnosti, odobrenje uprave |
Zenith Controls uključuje te razlike u revizijskoj metodologiji za usluge u oblaku, ugovore s dobavljačima i praćenje dobavljača. Za 5.22, Praćenje, pregled i upravljanje promjenama usluga dobavljača, ističe da revizori mogu pregledati zapisnike tromjesečnih pregleda dobavljača, KPI izvješća, procjene SOC izvješća, zapisnike promjena, procjene rizika, incidente dobavljača i praćenje otvorenih pitanja. Za 5.20, Uređivanje informacijske sigurnosti u ugovorima s dobavljačima, ističe uzorkovanje ugovora za povjerljivost, sigurnosne obveze, prijavu povrede, prava na reviziju, odobrenje podizvođača i uvjete raskida.
Kontrole višestruke usklađenosti koje nose teret revizije oblaka
Model dokaza za oblak spreman za regulatorna tijela gradi se oko manjeg broja kontrola visokog učinka. Te kontrole nose velik dio tereta usklađenosti kroz ISO 27001:2022, NIS2, DORA, GDPR, NIST i COBIT 2019.
| Tema kontrole | Sidro ISO 27001:2022 | Relevantnost za NIS2 | Relevantnost za DORA | Relevantnost za GDPR |
|---|---|---|---|---|
| Upravljanje oblakom | A.5.23 | Article 21 mjere za rizike oblaka i sustava | Okvir IKT rizika i ovisnosti o trećim stranama | Sigurnost obrade u oblaku i nadzor nad izvršiteljem obrade |
| Ugovori s dobavljačima | A.5.20 | Sigurnost opskrbnog lanca i suradnja | Article 30 ugovorne odredbe | Article 28 ugovor s izvršiteljem obrade |
| Praćenje dobavljača | A.5.22 | Kontinuirano upravljanje rizicima | Kontinuirano praćenje IKT trećih strana, KPI-ji i KRI-ji | Dubinska analiza dobavljača i sigurnosni pregled |
| Zapisivanje događaja i praćenje | A.8.15, A.8.16 | Otkrivanje incidenata i djelotvornost kontrola | Otkrivanje, klasifikacija i prijavljivanje IKT incidenata | Otkrivanje povreda i odgovornost |
| Kontrola pristupa i MFA | A.5.15, A.5.16, A.5.17, A.5.18 | Kontrola pristupa i MFA gdje je primjenjivo | Mjere zaštite i prevencije | Povjerljivost i cjelovitost osobnih podataka |
| Sigurnosno kopiranje i otpornost | A.8.13, A.5.29, A.5.30 | Neprekidnost poslovanja i krizno upravljanje | Neprekidnost, oporavak, sigurnosno kopiranje i vraćanje podataka | Dostupnost i otpornost obrade |
| Upravljanje incidentima | A.5.24, A.5.25, A.5.26, A.5.27 | Tijek rada za prijavljivanje u roku od 24 sata, 72 sata i završno izvješće | Početni, međufazni i završni životni ciklus izvješćivanja | Procjena i obavješćivanje o povredi osobnih podataka |
| Pravne obveze i obveze privatnosti | A.5.31, A.5.34 | Usklađenost s pravnim i regulatornim zahtjevima | Sektorski nadzorni zahtjevi | Zakonita obrada, odgovornost i ugovori prema Article 28 |
NIST SP 800-53 Rev.5 dodaje tehničku dubinu kroz upravljanje računima, usluge vanjskih sustava, kontinuirano praćenje, praćenje sustava i zaštitu granica sustava. COBIT 2019 dodaje upravljačku dubinu kroz upravljanje odnosima s dobavljačima, rizik dobavljača, razmjenu podataka, sigurnost mreže i spremnost za promjene.
Prateći ISO standardi izoštravaju model dokaza. ISO/IEC 27017 pruža smjernice specifične za oblak o podijeljenim ulogama, konfiguraciji virtualnih strojeva i praćenju aktivnosti korisnika. ISO/IEC 27018 usredotočuje se na zaštitu PII u javnom oblaku. ISO/IEC 27701 proširuje obveze privatnosti na operacije izvršitelja obrade i voditelja obrade. ISO/IEC 27036-4 podupire ugovore s dobavljačima usluga u oblaku i praćenje. ISO/IEC 27005 podupire procjenu rizika u oblaku.
Preispitivanje uprave mora vidjeti rizik oblaka, a ne samo dostupnost oblaka
Jedan od najčešće zanemarenih revizijskih artefakata jest preispitivanje uprave. ISO 27001:2022 očekuje da preispitivanje uprave uzme u obzir promjene, potrebe zainteresiranih strana, trendove učinkovitosti, rezultate revizije, status obrade rizika i prilike za poboljšanje. NIS2 zahtijeva da upravljačka tijela odobre mjere upravljanja rizicima kibernetičke sigurnosti i nadziru njihovu provedbu. DORA zahtijeva da upravljačko tijelo definira, odobri, nadzire i ostane odgovorno za upravljanje IKT rizicima.
Tromjesečna nadzorna ploča za sigurnost u oblaku i dobavljače trebala bi prikazivati:
- broj odobrenih usluga u oblaku;
- kritične usluge u oblaku i njihove vlasnike;
- usluge koje obrađuju osobne podatke;
- usluge koje podupiru kritične ili važne funkcije;
- otvorene pogrešne konfiguracije oblaka visokog rizika;
- status MFA i pregleda pristupa s povišenim ovlastima;
- pokrivenost zapisivanja događaja za kritične SaaS i IaaS platforme;
- primljena i pregledana izvješća o sigurnosnim potvrdama dobavljača;
- ugovorne iznimke i prihvaćene rizike;
- incidente u oblaku, zamalo nastale događaje i naučene lekcije;
- rezultate testova sigurnosnog kopiranja i oporavka;
- status rizika koncentracije i izlaznog plana.
Ta nadzorna ploča postaje dokaz za vodstvo i vrednovanje učinkovitosti prema ISO 27001:2022, upravljanje prema NIS2 i odgovornost uprave prema DORA-i.
Zenith Blueprint, u fazi Upravljanje rizicima, korak 14, preporučuje međusobno upućivanje na regulatorne zahtjeve pri implementaciji obrada rizika i politika. Navodi da je mapiranje ključnih regulatornih zahtjeva na ISMS kontrole korisna interna vježba i da „također ostavlja dobar dojam na revizore/procjenitelje jer pokazuje da sigurnošću ne upravljate u vakuumu, nego ste svjesni pravnog konteksta”.
To je razina zrelosti koju regulatorna tijela i korporativni klijenti očekuju.
Uobičajeni nalazi revizije oblaka i kako ih izbjeći
U radu na revizijskoj spremnosti oblaka ponavljajući nalazi su predvidljivi:
- Registar usluga u oblaku postoji, ali SaaS alati nedostaju.
- Lokacija podataka nije evidentirana ili je preuzeta s marketinških stranica umjesto iz ugovornih dokaza.
- MFA se provodi za zaposlenike, ali ne za sve administratorske ili hitne račune.
- Dnevnički zapisi iz oblaka omogućeni su, ali nisu pregledavani, zadržani ili povezani s odgovorom na incidente.
- SOC izvješća dobavljača arhivirana su, ali nisu procijenjena.
- Ugovorne odredbe postoje za nove dobavljače, ali ne i za naslijeđene kritične usluge.
- Obavijesti o podizvršiteljima obrade primaju se e-poštom, ali se ne procjenjuju prema riziku.
- Poslovi sigurnosnog kopiranja uspješno se izvršavaju, ali testovi oporavka nisu potkrijepljeni dokazima.
- Razvojni inženjeri razumiju podijeljenu odgovornost, ali ona nije dokumentirana za revizore.
- SoA označava kontrole u oblaku kao primjenjive, ali ih ne povezuje sa zapisima rizika, dokazima ili vlasnicima.
To su problemi sljedivosti. Rješenje je povezati politiku, rizik, kontrolu, vlasnika, dokaz i pregled.
Kada je Maria stigla do dana revizije, više se nije oslanjala na raspršene snimke zaslona. Otvorila je središnju nadzornu ploču koja je prikazivala registar usluga u oblaku, procjene rizika, SoA zapise, dokaze osnovne konfiguracije, datoteke pregleda dobavljača, dokaze zapisivanja događaja i DORA pregled rizika koncentracije. Kada je revizor pitao kako se upravlja rizicima oblaka, pokazala je ISMS. Kada je revizor pitao kako su usluge sigurno konfigurirane, pokazala je osnovnu konfiguraciju i CSPM dokaze. Kada je revizor pitao o IKT riziku trećih strana, pokazala je pregled ugovora, praćenje dobavljača i izlazno planiranje.
Rezultat nije bilo savršeno okruženje. Nijedno okruženje u oblaku nije savršeno. Razlika je bila u tome što su odluke o riziku bile dokumentirane, dokazi dokazivi, a odgovornost vidljiva.
Izgradite paket dokaza za oblak prije nego što ga revizor zatraži
Ako se vaša organizacija oslanja na SaaS, IaaS ili PaaS, vaša sljedeća revizija neće prihvatiti odgovor „time upravlja pružatelj” kao dovoljan. Morate dokazati podijeljenu odgovornost, konfiguraciju na strani korisnika, odredbe za dobavljače, zapisivanje događaja, spremnost za incidente, otpornost i nadzor uprave.
Započnite s tri praktične radnje ovog tjedna:
- Izradite ili ažurirajte svoj registar usluga u oblaku koristeći Clarysecovu Politiku korištenja usluga u oblaku Politika korištenja usluga u oblaku ili Politiku korištenja usluga u oblaku za MSP Politika korištenja usluga u oblaku za MSP.
- Mapirajte svojih pet najvažnijih usluga u oblaku na kontrole ISO 27001:2022 Prilog A, NIS2 Article 21, obveze IKT trećih strana prema DORA-i gdje je primjenjivo i zahtjeve za izvršitelje obrade prema GDPR-u.
- Izgradite centraliziranu mapu dokaza koristeći disciplinu zadržavanja i metapodataka iz Politike praćenja revizije i usklađenosti Politika praćenja revizije i usklađenosti ili Politike praćenja revizije i usklađenosti za MSP Politika praćenja revizije i usklađenosti za MSP.
Zatim koristite Zenith Blueprint Zenith Blueprint kako biste taj rad smjestili u mapu puta za reviziju ISMS-a u 30 koraka, a Zenith Controls Zenith Controls kako biste provjerili mapiranja višestruke usklađenosti, prateće ISO standarde i očekivanja revizijske metodologije.
Clarysec vam može pomoći pretvoriti raspršene snimke zaslona iz oblaka, datoteke dobavljača i SaaS postavke u paket dokaza spreman za regulatorna tijela koji može izdržati certifikacijske revizije ISO 27001:2022, nadzorna pitanja prema NIS2, DORA preglede IKT trećih strana i zahtjeve korporativnih klijenata za sigurnosnim potvrdama.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
