Matrica zajedničke odgovornosti u oblaku za ISO, NIS2, DORA
COO fintech društva zove CISO-a u ponedjeljak u 07:15.
Europski bankarski klijent traži dokaz da SaaS platforma društva može ispuniti zahtjeve DORA za IKT rizik trećih strana. Prodajni tim već je poslao uobičajeni paket sigurnosnih dokaza dobavljača: ISO certifikat, sažetak za upravu izvješća o penetracijskom testiranju, potvrdu o kibernetičkom osiguranju, obavijest o privatnosti i sigurnosno atestacijsko izvješće pružatelja usluga u oblaku.
Banka se vraća s preciznijim pitanjem:
“Pokažite nam tko je vlasnik svake kontrole u vašem okruženju u oblaku. Vi, vaš pružatelj usluga u oblaku, vaš pružatelj upravljane baze podataka, vaš pružatelj identiteta, vaš dobavljač za dnevničko bilježenje i svi podizvršitelji obrade. Zatim pokažite dokaze.”
Kasnije tog jutra CISO ima sastanak s upravnim odborom. CEO će postaviti isto pitanje poslovnim jezikom: “Jesmo li sigurni da je ova platforma sigurna i tko je odgovoran ako nešto pođe po zlu?”
Na tom mjestu mnogi programi usklađenosti u oblaku zastaju.
Organizacija može imati snažnog pružatelja usluga u oblaku, dobre alate, primjerene politike i registar rizika. No kada treba dokazati granice odgovornosti, dokazi su raspršeni. Nabava ima ugovore. Pravni odjel ima ugovor o obradi podataka. Inženjering ima arhitektonske dijagrame. Sigurnost ima dnevničke zapise i konfiguracije oblaka. Privatnost ima popis podizvršitelja obrade. Usklađenost ima Izjavu o primjenjivosti. Nitko nema jedan kontrolirani artefakt koji, kontrolu po kontrolu, pokazuje što radi pružatelj, što klijent mora konfigurirati, koji je podizvršitelj obrade uključen, koja odredba čini obvezu provedivom i koje dokaze revizor treba očekivati.
Taj je artefakt matrica zajedničke odgovornosti u oblaku.
Ne generički slajd hiperskalabilnog pružatelja koji kaže da pružatelj osigurava oblak, a klijent ono što je u oblaku. Stvarna matrica zajedničke odgovornosti u oblaku za ISO/IEC 27001:2022, NIS2, DORA i GDPR zapis je upravljanja. Ona izdržava klijentsku dubinsku analizu dobavljača, ISO reviziju, DORA pregled, provjeru odgovornosti prema GDPR-u i istragu incidenta.
Zašto zajednička odgovornost u oblaku postaje revizijsko pitanje
Model zajedničke odgovornosti obično se objašnjava kao tehnička granica. U IaaS-u pružatelj upravlja fizičkim lokacijama, hardverom, virtualizacijom i temeljnom infrastrukturom. Klijent upravlja identitetima, podacima, radnim opterećenjima, mrežnim pravilima, odabirom šifriranja i konfiguracijama. U SaaS-u pružatelj preuzima veću operativnu odgovornost, ali klijent i dalje zadržava odgovornost za korisnički pristup, upravljanje podacima, pravnu osnovu, konfiguraciju, očekivanja nadzora i eskalaciju incidenata.
To je objašnjenje korisno, ali nije dovoljno.
Revizori, regulatorna tijela i poslovni klijenti ne pitaju samo “tko provodi kontrolu?” Žele znati:
- Tko je odgovoran za rizik?
- Koja ugovorna odredba tu odgovornost čini provedivom?
- Koja politika zahtijeva kontrolu?
- Koja je usluga u oblaku, SaaS platforma ili podizvršitelj obrade u opsegu?
- Koji dokaz potvrđuje da je kontrola djelovala tijekom razdoblja pregleda?
- Koji zahtjev okvira taj dokaz zadovoljava?
- Što se događa ako pružatelj promijeni uslugu, lokaciju, podugovaratelja ili profil kontrola?
ISO/IEC 27001:2022 ISO/IEC 27001:2022 ovo postavlja kao pitanje sustava upravljanja. Točke 4.1 do 4.4 zahtijevaju da organizacija razumije unutarnja i vanjska pitanja, zainteresirane strane, pravne i ugovorne obveze, opseg ISMS-a, sučelja i ovisnosti. Točke 6.1.1 do 6.1.3 zahtijevaju procjenu rizika, obradu rizika, odobrenje vlasnika rizika, prihvaćanje preostalog rizika i Izjavu o primjenjivosti. Točka 8.1 zahtijeva operativno planiranje i kontrolu, uključujući kontrolu eksterno pruženih procesa, proizvoda i usluga relevantnih za ISMS.
Jednostavno rečeno, ako pružatelj usluga u oblaku, SaaS dobavljač ili podizvršitelj obrade podržava poslovni proces u opsegu, ne može biti izvan ISMS-a. Mora biti vidljiv u opsegu, riziku, obradi rizika, ugovornoj kontroli i dokazima.
NIS2 podiže razinu zahtjeva. Article 21 zahtijeva da ključni i važni subjekti provedu 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, siguran razvoj, postupanje s ranjivostima, procjenu učinkovitosti, kibernetičku higijenu, kriptografiju, sigurnost ljudskih resursa, kontrolu pristupa, upravljanje imovinom i višefaktorsku autentifikaciju ili kontinuiranu autentikaciju gdje je primjereno. Article 20 odgovornost za upravljanje stavlja na upravljačka tijela.
DORA je za financijske subjekte još izričitija. Primjenjuje se od 17. siječnja 2025. i zahtijeva da financijski subjekti upravljaju IKT rizikom, prijavljuju veće incidente povezane s IKT-om, testiraju digitalnu operativnu otpornost i upravljaju IKT rizikom trećih strana. Articles 28 to 30 zahtijevaju upravljanje IKT rizikom trećih strana, preliminarnu procjenu rizika koncentracije, ugovorne zaštitne mjere, prava na reviziju i pristup, vidljivost podugovaranja, prava raskida i izlazne strategije.
GDPR dodaje test odgovornosti. Article 5 zahtijeva da se osobni podaci obrađuju uz cjelovitost i povjerljivost, a Article 5(2) zahtijeva da voditelj obrade može dokazati usklađenost. Article 28 uređuje ugovore s izvršiteljima obrade i podizvršitelje obrade. Article 32 zahtijeva sigurnost obrade. Articles 33 and 34 zahtijevaju prijavu povrede osobnih podataka kada je primjenjivo.
Matrica zajedničke odgovornosti u oblaku postaje poveznica između tih obveza.
Clarysec definicija: artefakt upravljanja, a ne dijagram
U Clarysec angažmanima matrica zajedničke odgovornosti u oblaku kontrolirani je ISMS zapis koji povezuje usluge u oblaku, dobavljače, podizvršitelje obrade, kontrole, politike, ugovorne obveze, dokaze i revizijska očekivanja.
Najsnažnije objašnjenje nalazi se u Zenith Blueprint Zenith Blueprint, u fazi Controls in Action, korak 23:
“Pružatelji usluga u oblaku osiguravaju infrastrukturu, ali vi ste i dalje odgovorni za svoje podatke, svoje konfiguracije, svoje politike pristupa i svoju spremnost za odgovor na incidente.”
Isti korak objašnjava da se korištenje oblaka mora tretirati kao dio ISMS-a, uključujući klasifikaciju usluga u oblaku, razumijevanje podataka koji se obrađuju ili pohranjuju, procjenu pružatelja, ugovorne odredbe i upravljanje promjenama usluga. Time se zajednička odgovornost iz koncepta pretvara u sljedivu kontrolnu strukturu.
Zenith Controls Zenith Controls kontrole iz Priloga A ISO/IEC 27001:2022 i smjernice ISO/IEC 27002:2022 5.20, 5.21 i 5.23 tretira kao središnja uporišta:
- 5.20, Uređivanje informacijske sigurnosti u ugovorima s dobavljačima.
- 5.21, Upravljanje informacijskom sigurnošću u IKT opskrbnom lancu.
- 5.23, Informacijska sigurnost pri korištenju usluga u oblaku.
To nisu izolirane stavke kontrolnog popisa. One definiraju okosnicu matrice.
| Pitanje matrice | Uporište iz Priloga A ISO/IEC 27001:2022 | Praktično značenje |
|---|---|---|
| Na što se dobavljač mora ugovorno obvezati? | 5.20 | Sigurnost, povjerljivost, prava na reviziju, prijavljivanje incidenata, podugovaranje i prestanak ugovora moraju biti provedivi. |
| Kako kontroliramo pružateljeva pružatelja? | 5.21 | Rizik IKT opskrbnog lanca i nizvodnih ovisnosti mora se identificirati, procijeniti, pratiti i prenijeti niz ugovorni lanac. |
| Kako upravljamo odabirom, korištenjem i izlaskom iz usluga u oblaku? | 5.23 | Odgovornostima u oblaku, konfiguracijama, dokazima, dnevničkim bilježenjem, lokacijom podataka i izlazom mora se upravljati tijekom cijelog životnog ciklusa. |
Potporni standardi mogu ojačati matricu. ISO/IEC 27017 pomaže s praksama sigurnosti specifičnima za oblak. ISO/IEC 27018 i ISO/IEC 27701 podržavaju osobne podatke (PII) i upravljanje privatnošću. ISO/IEC 27005 podržava procjenu rizika. ISO 22301 podržava neprekidnost poslovanja i otpornost. ISO/IEC 27035 podržava upravljanje incidentima. ISO/IEC 20000-1 može pomoći kada su usluge u oblaku dio pružanja upravljanih usluga.
Minimalno održiva matrica zajedničke odgovornosti
Zrela matrica ne počinje s 200 redaka. Počinje s uslugama u oblaku koje su najvažnije.
Za SaaS, fintech ili regulirano malo ili srednje poduzeće Clarysec obično počinje s:
- Produkcijskim okruženjem u oblaku dostupnim klijentima.
- Pružateljem identiteta.
- Upravljanom bazom podataka ili uslugom pohrane.
- Platformom za dnevničko bilježenje, nadzor i SIEM.
- SaaS-om za plaćanja, KYC, analitiku ili korisničku podršku.
- Uslugom sigurnosnog kopiranja i oporavka od katastrofe.
- Pružateljem upravljanih usluga ili pružateljem upravljanih sigurnosnih usluga.
- Podizvršiteljima obrade koji pristupaju podacima klijenata, pohranjuju ih ili obrađuju.
Prva matrica treba uključivati sljedeće stupce.
| Stupac | Zašto je važan |
|---|---|
| Usluga ili kontrolno područje | Identificira točnu uslugu u oblaku, SaaS proizvod ili podproces u opsegu. |
| Podaci i poslovna funkcija | Povezuje uslugu s osobnim podacima, kritičnim uslugama, financijskim funkcijama ili ključnim operacijama. |
| Vlasnik odgovornosti | Definira pružatelja, klijenta, zajedničku odgovornost, podizvršitelja obrade ili internog vlasnika kontrole. |
| Obveza klijenta | Pokazuje što vaša organizacija mora konfigurirati, odobriti, nadzirati ili dokazati. |
| Obveza pružatelja | Pokazuje što pružatelj usluge u oblaku ili SaaS pružatelj mora isporučiti ugovorom, sigurnosnim dokazima ili funkcionalnostima platforme. |
| Ovisnost o podizvršitelju obrade | Prati nizvodne pružatelje koji mogu utjecati na sigurnost, privatnost, neprekidnost poslovanja ili rezidentnost podataka. |
| Kontrola iz Priloga A ISO/IEC 27001:2022 | Povezuje redak s Izjavom o primjenjivosti i obrazloženjem kontrole. |
| Mapiranje na NIS2, DORA, GDPR, NIST CSF ili COBIT 2019 | Pokazuje relevantnost za više okvira bez dupliciranja kontrola. |
| Dokazi | Definira dokaz spreman za reviziju. |
| Učestalost pregleda | Definira ritam nadzora, osobito za kritične ili visokorizične dobavljače. |
Praktičan redak za dnevničko bilježenje može izgledati ovako.
| Usluga ili kontrolno područje | Vlasnik odgovornosti | Obveza klijenta | Obveza pružatelja | Ovisnost o podizvršitelju obrade | Kontrole i okviri | Dokazi |
|---|---|---|---|---|---|---|
| Revizijsko bilježenje u produkcijskom oblaku | Zajednička | Omogućiti revizijske zapise, definirati zadržavanje, ograničiti pristup, pregledavati upozorenja i testirati dohvat | Osigurati mogućnost dnevničkog bilježenja, događaje platforme, opcije zadržavanja i obveze dostupnosti | Dobavljač za dnevničko bilježenje ili SIEM ako se dnevnički zapisi izvoze | ISO/IEC 27001:2022 Prilog A 5.20, 5.23, 8.15, 8.16; NIS2 Article 21; DORA Articles 6, 8, 10, 17; ishodi Detect i Govern iz NIST CSF 2.0 | Standard dnevničkog bilježenja i nadzora, izvoz konfiguracije oblaka, uzorci dnevničkih zapisa, SIEM upozorenja, pregled pristupa, ugovorna odredba pružatelja, dokazi o zadržavanju |
Taj redak nije samo dokumentacija. On sigurnosti kaže što treba konfigurirati, nabavi koji ugovorni tekst treba provjeriti, privatnosti koji tok podataka treba evidentirati, a revizorima koje dokaze treba zatražiti.
Temelj u politikama: pretvaranje matrice u provediv zahtjev
Matrica zajedničke odgovornosti u oblaku bez uporišta u politici samo je proračunska tablica. Clarysec politike čine je provedivom.
Za mala i srednja poduzeća, Politika korištenja usluga u oblaku za MSP-ove Politika korištenja usluga u oblaku za MSP-ove, odjeljak “Zahtjevi upravljanja”, točka 5.3 zahtijeva:
“Registar usluga u oblaku mora održavati pružatelj IT usluga ili glavni direktor. Mora evidentirati:”
Ista politika za MSP-ove, točka 5.2.3, povezuje upravljanje oblakom s privatnošću i rizikom lokacije:
“Rezidentnost podataka i prakse privatnosti usklađene su s primjenjivim pravnim zahtjevima (npr. GDPR)”
Za korporativna okruženja, Politika korištenja usluga u oblaku Politika korištenja usluga u oblaku, odjeljak “Zahtjevi upravljanja”, točka 5.1 navodi:
“Organizacija mora održavati centralizirani Registar usluga u oblaku, u vlasništvu CISO-a, koji sadrži:”
Točka 5.4 zatim čini odgovornosti u oblaku ugovorno provedivima:
“Svi ugovori s CSP-ovima (pružateljima usluga u oblaku) moraju uključivati provedive odredbe za:”
Upravljanje dobavljačima proširuje matricu izvan neposrednog pružatelja. Politika sigurnosti trećih strana i dobavljača za MSP-ove Politika sigurnosti trećih strana i dobavljača za MSP-ove, odjeljak “Zahtjevi upravljanja”, točka 5.3.5 zahtijeva:
“Ograničenja daljnjeg podugovaranja bez odobrenja”
Ista politika dobavljača za MSP-ove, odjeljak “Zahtjevi za provedbu politike”, točka 6.3.1 dodaje periodični pregled:
“Kritični ili visokorizični dobavljači moraju se pregledavati najmanje jednom godišnje. Pregled mora provjeriti:”
Na korporativnoj razini, Politika sigurnosti trećih strana i dobavljača Politika sigurnosti trećih strana i dobavljača, odjeljak “Zahtjevi upravljanja”, točka 5.3 navodi:
“Ugovori s dobavljačima moraju uključivati:”
Za osobne podatke, Politika zaštite podataka i privatnosti Politika zaštite podataka i privatnosti, odjeljak “Provedba i usklađenost”, točka 8.5.1 zahtijeva:
“Ugovori s izvršiteljima obrade moraju uključivati:”
Za vidljivost ovisnosti, Politika upravljanja rizikom ovisnosti o dobavljačima Politika upravljanja rizikom ovisnosti o dobavljačima, točka 6.5.4 zahtijeva:
“Korištenje odnosa s dobavljačem radi dobivanja ažuriranja o podugovarateljima ili ovisnostima opskrbnog lanca jednu razinu nizvodno gdje bi mogle utjecati na nas (primjerice, ako se kritični dobavljač softvera snažno oslanja na biblioteku treće strane, to se mora evidentirati).”
Za dnevničke zapise, Politika dnevničkog bilježenja i nadzora za MSP-ove Politika dnevničkog bilježenja i nadzora za MSP-ove, odjeljak “Zahtjevi upravljanja”, točka 5.5.1.3 daje konkretan ugovorni zahtjev:
“Ugovori moraju zahtijevati od pružatelja da zadržavaju dnevničke zapise najmanje 12 mjeseci i omoguće pristup na zahtjev”
Zajedno, ove politike čine matricu obveznim zapisom upravljanja koji podržava odobravanje dobavljača, uvođenje usluga u oblaku, odgovornost za privatnost, godišnji pregled i revizijske dokaze.
Mapiranje matrice kroz ISO/IEC 27001:2022, NIS2, DORA i GDPR
Klasična pogreška jest izrada četiri odvojene radne knjige za usklađenost. Jedna kontrola može zadovoljiti više obveza ako su odgovornost i dokazi sljedivi.
| Kontrolno područje | ISO/IEC 27001:2022 Prilog A | Dokazi pružatelja | Dokazi klijenta | Mapiranje na okvire |
|---|---|---|---|---|
| Ugovori s dobavljačima | 5.20 | Ugovor, sigurnosni prilog, ugovor o obradi podataka, sigurnosno atestacijsko izvješće, obveza obavješćivanja o incidentu | Procjena rizika dobavljača, kontrolni popis pregleda ugovora, zapis o odobrenju | NIS2 Article 21; DORA Article 30; GDPR Article 28; NIST CSF 2.0 GV.SC |
| IKT opskrbni lanac | 5.21 | Popis podizvršitelja obrade, uvjeti podugovaranja, nizvodni sigurnosni dokazi, obavijesti o promjenama | Registar ovisnosti, pregled koncentracije, godišnji pregled dobavljača | NIS2 Article 21; DORA Articles 28 and 29; ciljevi upravljanja dobavljačima iz COBIT 2019 |
| Korištenje usluga u oblaku | 5.23 | Dokumentacija usluge, opcije lokacije podataka, alati za izvoz, podrška za brisanje | Registar usluga u oblaku, standardi konfiguracije, izlazni plan, pregled usluge | DORA Articles 6, 8, 28 and 30; GDPR Articles 5, 28 and 32 |
| Identitet i pristup | 5.15, 5.16, 5.18 | IAM mogućnosti, MFA opcije, administratorske kontrole, revizijski događaji platforme | Provedba MFA, načelo najmanjih ovlasti, pregledi pristupa, zapisi o dolascima, promjenama uloga i odlascima zaposlenika | NIS2 Article 21(2)(i); DORA Article 9; GDPR Article 32 |
| Dnevničko bilježenje i nadzor | 8.15, 8.16 | Dnevnički zapisi platforme, revizijski API-ji, opcije zadržavanja, obavijesti o usluzi | Unos u SIEM, pregledi upozorenja, postavke zadržavanja dnevničkih zapisa, ograničenja pristupa | NIS2 Article 21; DORA Articles 10 and 17; GDPR Article 32 |
| Upravljanje incidentima | 5.24, 5.25, 5.26, 5.27 | Obavijesti pružatelja o incidentima, tiketi podrške, izvješća o analizi temeljnog uzroka | Operativne upute za incidente, dokazi trijaže, procjena obveze regulatornog izvješćivanja, naučene lekcije | NIS2 Article 23; DORA Articles 17, 18 and 19; GDPR Articles 33 and 34 |
| Neprekidnost poslovanja i izlaz | 5.29, 5.30, 5.23 | Obveze dostupnosti, alati za izvoz, potvrda o brisanju, podrška oporavku | Rezultati testova sigurnosnih kopija, vježbe oporavka, izlazni test, ukidanje prava pristupa | DORA Articles 11, 24, 28 and 30; NIS2 Article 21; GDPR Article 28 |
ISO/IEC 27001:2022 daje pokretački mehanizam ISMS-a: kontekst, zainteresirane strane, opseg, vodstvo, obradu rizika, ciljeve, operativnu kontrolu, vrednovanje učinkovitosti i poboljšanje. Prilog A daje praktičnu strukturu kontrola.
NIS2 Article 21 prirodno se mapira na istu matricu kroz sigurnost opskrbnog lanca, postupanje s incidentima, neprekidnost poslovanja, kontrolu pristupa, upravljanje imovinom i sigurnu nabavu. Article 20 čini matricu relevantnom za upravni odbor jer upravljačka tijela moraju odobriti i nadzirati mjere upravljanja rizicima kibernetičke sigurnosti.
DORA pretvara matricu u alat za IKT rizik trećih strana. Articles 5, 6 and 8 zahtijevaju upravljanje, dokumentirano upravljanje IKT rizicima te identifikaciju imovine, funkcija i ovisnosti. Articles 17 to 19 zahtijevaju otkrivanje incidenata, klasifikaciju, eskalaciju, komunikaciju i izvješćivanje. Articles 28 to 30 zahtijevaju upravljanje rizikom trećih strana, analizu rizika koncentracije, ugovorne odredbe, kontrole podugovaranja, prava na reviziju, prava raskida i izlazne strategije.
GDPR dodaje perspektivu osobnih podataka. Svaki redak usluge u oblaku treba identificirati obrađuju li se osobni podaci, je li pružatelj izvršitelj obrade ili podizvršitelj obrade, je li lokacija podataka relevantna i koji ugovor ili dokaz iz ugovora o obradi podataka postoji.
NIST CSF 2.0 pomaže pri komunikaciji iste matrice jezikom ishoda. Funkcija GOVERN obuhvaća organizacijski kontekst, pravne i regulatorne zahtjeve, ovisnosti, upravljanje rizicima, uloge, politike i nadzor. Ishodi GV.SC osobito su korisni za kibernetički rizik dobavljača, uključujući uloge dobavljača, kritičnost, ugovorne zahtjeve, dubinsku analizu dobavljača, praćenje, koordinaciju incidenata i planiranje prestanka angažmana.
COBIT 2019 dodaje perspektivu dokazivanja i upravljanja. Postavlja pitanje jesu li odgovornost, prakse upravljanja, vlasništvo, praćenje učinkovitosti i otklanjanje problema ponovljivi i potkrijepljeni dokazima.
Izgradnja matrice od registra do dokaza
Zamislite SaaS društvo koje koristi hiperskalabilnu IaaS platformu, upravljanu bazu podataka, pružatelja identiteta treće strane, SaaS platformu za korisničku podršku i vanjski SIEM. Tijek implementacije je jednostavan.
Korak 1: Počnite s Registrom usluga u oblaku
Koristite Politiku korištenja usluga u oblaku ili Politiku korištenja usluga u oblaku za MSP-ove kao okidač. Evidentirajte svaku uslugu u oblaku, vlasnika, svrhu, kategorije podataka, lokaciju, poslovnu funkciju, razinu dobavljača, vlasnika ugovora i datum pregleda.
Ako usluga pohranjuje evidencije klijenata, dnevničke zapise autentikacije ili tikete podrške, označite je kao relevantnu za privatnost. Ako podržava dostupnost produkcije, označite je kao operativno kritičnu. Ako podržava kritičnu ili važnu funkciju financijskog klijenta, označite je kao relevantnu za DORA.
Korak 2: Dodajte domene zajedničke odgovornosti
Za svaku uslugu definirajte odgovornosti kroz temeljne domene.
| Domena | Tipična odgovornost pružatelja | Tipična odgovornost klijenta | Tipično pitanje o podizvršitelju obrade |
|---|---|---|---|
| Fizička sigurnost i sigurnost infrastrukture | Objekti, hardver, kontrole okoline, otpornost platforme | Pregledati sigurnosna atestacijska izvješća i ugovorne obveze | Oslanja li se pružatelj na podatkovni centar, CDN ili podizvršitelja hostinga? |
| Identitet i pristup | IAM mogućnosti platforme, sigurnosne značajke za administratore, podrška za federaciju | MFA, dizajn uloga, načelo najmanjih ovlasti, pregledi za dolaske, promjene uloga i odlaske zaposlenika | Pristupa li posrednik identiteta ili dobavljač podrške računima? |
| Zaštita podataka | Opcije šifriranja, opcije lokacije podataka, značajke sigurnosnog kopiranja | Klasifikacija, konfiguracija šifriranja, zadržavanje, pravna osnova | Pohranjuje li ili pristupa li bilo koji podizvršitelj obrade osobnim podacima? |
| Dnevničko bilježenje i nadzor | Generiranje događaja, revizijski API-ji, telemetrija platforme | Omogućiti dnevničke zapise, izvoziti u SIEM, pregledavati upozorenja, zadržati dokaze | Obrađuje li pružatelj SIEM ili MDR usluge dnevničke zapise koji sadržavaju osobne podatke? |
| Odgovor na incidente | Otkrivanje od strane pružatelja, obavijesti o incidentima platforme, eskalacija podrške | Interna trijaža, obavijesti regulatoru i klijentima, očuvanje dokaza | Mogu li nizvodni incidenti odgoditi obavješćivanje ili analizu temeljnog uzroka? |
| Neprekidnost poslovanja i izlaz | Obveze dostupnosti platforme, alati za izvoz, podrška brisanju | Ciljevi oporavka, testiranje sigurnosnih kopija, izlazni plan, povrat ili uništenje podataka | Postoje li ograničenja oporavka zbog podugovorenih usluga ili lokacija? |
Korak 3: Povežite kontrole s rizikom i Izjavom o primjenjivosti
Zenith Blueprint, faza upravljanja rizicima, korak 13, objašnjava zahtjev sljedivosti:
“Unakrsno povežite propise: ako su određene kontrole implementirane posebno radi usklađivanja s GDPR, NIS2 ili DORA, to možete navesti u Registru rizika (kao dio obrazloženja utjecaja rizika) ili u napomenama SoA.”
Primjerice, rizik “neovlašteni pristup produkcijskim podacima klijenata zbog pogrešne konfiguracije oblaka” može se mapirati na kontrolu pristupa, korištenje oblaka, dnevničko bilježenje, kriptografiju, upravljanje ranjivostima i ugovore s dobavljačima. SoA može upućivati na ISO/IEC 27001:2022 Prilog A 5.15, 5.16, 5.20, 5.23, 8.8, 8.15, 8.16 i 8.24, s napomenama za GDPR Article 32, NIS2 Article 21 i upravljanje IKT rizicima prema DORA gdje je primjenjivo.
Korak 4: Priložite dokaze prije revizijske sezone
Dokaze treba ugraditi u matricu, a ne prikupljati u panici.
| Redak matrice | Dokazi koje treba zadržati |
|---|---|
| Dubinska analiza dobavljača usluga u oblaku | Procjena dobavljača, sigurnosni upitnik, sigurnosno atestacijsko izvješće, certifikacije, ocjena rizika, zapis o odobrenju |
| Ugovorne sigurnosne obveze | MSA, ugovor o obradi podataka, sigurnosni prilog, prava na reviziju, odredba o podugovaranju, odredba o obavješćivanju o incidentu, uvjeti lokacije podataka |
| Odgovornost klijenta za konfiguraciju | Izvoz konfiguracije oblaka, IAM politika, MFA izvješće, postavke šifriranja, mrežna pravila, tiketi promjena |
| Dnevničko bilježenje i nadzor | Postavke zadržavanja dnevničkih zapisa, uzorci revizijskih zapisa, dokaz unosa u SIEM, zapisi pregleda upozorenja, tiketi eskalacije |
| Sljedivost podizvršitelja obrade | Popis podizvršitelja obrade pružatelja, zapis o odobrenju, mapa toka podataka, bilješke godišnjeg pregleda, obavijest o promjenama |
| Izlaz i oporavak | Rezultati testova sigurnosnih kopija, test izvoza podataka, potvrda o brisanju, izlazni plan, izvješće o vježbi oporavka |
Popis dokaza pretvara odgovornost u dokaz. Također pomaže komercijalnim timovima da brže odgovore na dubinsku analizu poslovnih klijenata jer mogu pokazati ne samo certifikacije, nego i vlasništvo nad kontrolama i operativne dokaze.
Podizvršitelji obrade: slijepa točka u većini matrica
Podizvršitelji obrade mjesto su gdje zajednička odgovornost postaje stvarni rizik opskrbnog lanca.
SaaS pružatelj može biti vaš izvršitelj obrade prema GDPR-u. Taj se pružatelj može oslanjati na pružatelja hostinga u oblaku, CDN, analitičku uslugu, platformu podrške, uslugu dostave e-pošte, upravljanu bazu podataka, pružatelja opservabilnosti i izvršitelja plaćanja. Neki mogu pristupati osobnim podacima. Neki mogu podržavati kritično pružanje usluge bez izravnog uvida u podatke. Neki mogu biti izvan EU. Neki mogu biti zamjenjivi. Drugi mogu stvarati rizik koncentracije.
DORA Article 29 zahtijeva procjenu rizika koncentracije za kritične ili važne IKT usluge, uključujući mogućnost zamjene, više aranžmana s istim ili povezanim pružateljima, lance podugovaranja, podugovaratelje iz trećih zemalja, propise o nesolventnosti, ograničenja oporavka podataka i provedivost zaštite podataka Unije. DORA Article 30 zahtijeva ugovorne odredbe o uvjetima podugovaranja, lokacijama, obradi i pohrani podataka, pristupu i oporavku, pomoći pri incidentima, suradnji s tijelima, pravima na reviziju, raskidu i izlazu.
NIS2 Article 21 slično zahtijeva sigurnost opskrbnog lanca za izravne dobavljače i pružatelje usluga, uz razmatranje ranjivosti specifičnih za dobavljača, praksi kibernetičke sigurnosti dobavljača i postupaka sigurnog razvoja.
Zato Clarysec mapiranje podizvršitelja obrade tretira kao obvezno proširenje upravljanja dobavljačima, a ne samo kao popis za privatnost. Registar podizvršitelja obrade treba pokazati koji dobavljač koristi podizvršitelja obrade, koja usluga o njemu ovisi, obrađuju li se osobni podaci, podržava li kritičnu funkciju, regiju obrade gdje je relevantno, prenesene ugovorne obveze, prava odobrenja ili prigovora, dostupne sigurnosne dokaze, metodu nadzora i izlaznu opciju.
Zenith Blueprint, faza Controls in Action, korak 23 navodi:
“Za svakog kritičnog dobavljača utvrdite koristi li podugovaratelje (podizvršitelje obrade) koji mogu pristupiti vašim podacima ili sustavima. Dokumentirajte kako se vaši zahtjevi informacijske sigurnosti prenose na te strane, bilo kroz ugovorne uvjete vašeg dobavljača ili kroz vaše vlastite izravne odredbe.”
To je razina dokaza koju revizori očekuju kada pitaju jesu li odgovornosti u oblaku kontrolirane nizvodno.
Kako revizori testiraju istu matricu
Snažna matrica zajedničke odgovornosti u oblaku izdržava više stilova revizije jer je izgrađena oko vlasništva, provedivosti i dokaza.
| Revizijska perspektiva | Što će revizor testirati | Koje će dokaze očekivati |
|---|---|---|
| Revizor ISO/IEC 27001:2022 | Opseg ISMS-a, zainteresirane strane, procjena rizika, primjenjivost SoA, kontrole dobavljača, korištenje oblaka, operativni dokazi i kontinuirano poboljšanje | Opseg ISMS-a, registar rizika, SoA, registar dobavljača, registar usluga u oblaku, ugovori, zapisi pregleda, nalazi interne revizije, korektivne radnje |
| Pregledavatelj spremnosti za NIS2 | Odobrenje uprave, obuhvat kontrola iz Article 21, sigurnost opskrbnog lanca, postupanje s incidentima, neprekidnost poslovanja, pristup, upravljanje imovinom i procjena učinkovitosti | Izvješćivanje upravnom odboru, odobrenja politika, pregledi rizika dobavljača, operativne upute za incidente, testovi neprekidnosti poslovanja, MFA dokazi, zapisi o ranjivostima i dnevničkom bilježenju |
| Procjenitelj DORA | IKT upravljanje, okvir IKT rizika, popis imovine i ovisnosti, kritični IKT aranžmani s trećim stranama, ugovorne odredbe, rizik koncentracije, testiranje i izlazna strategija | Okvir IKT rizika, registar IKT usluga, procjena kritičnosti, ugovori, prava na reviziju, zapisi o incidentima, testovi otpornosti, izlazni testovi, analiza podugovaranja |
| Pregledavatelj GDPR | Uloge voditelja obrade i izvršitelja obrade, svrhe obrade podataka, cjelovitost i povjerljivost, spremnost za povredu, ugovori s izvršiteljima obrade i transparentnost podizvršitelja obrade | Evidencija aktivnosti obrade, ugovor o obradi podataka, popis podizvršitelja obrade, mapa toka podataka, sigurnosne mjere, postupak za povrede, dokazi o zadržavanju i brisanju |
| Procjenitelj NIST CSF | Ishodi GOVERN, kibernetički rizik dobavljača, popis imovine, kontrola pristupa, sigurnost podataka, nadzor, odgovor i oporavak | Trenutačni i ciljani profili, proces rizika dobavljača, popis imovine, izvješća o pristupu, zapisi nadzora, vježbe incidenata, dokazi oporavka |
| Revizor COBIT 2019 ili ISACA | Odgovornost u upravljanju, prakse upravljanja, vlasništvo nad kontrolama, praćenje učinkovitosti, upravljanje problemima i sljedivost dokazivanja | RACI, zapisnici upravljačkih sastanaka, iznimke od politike, KPI-jevi, ocjenjivačke kartice dobavljača, zapisi o problemima, izlazni rezultati preispitivanja uprave |
Matrica nije krajnji cilj. Ona je mapa kojom se revizori koriste kako bi testirali je li sustav upravljanja stvaran.
ISO revizor može odabrati visokoutjecajni rizik pristupa u oblaku i pratiti ga od registra rizika do SoA, zatim do pregleda pristupa, MFA dokaza i upozorenja nadzora. DORA procjenitelj može odabrati kritičnog IKT pružatelja i zatražiti izlazni test, analizu podugovaranja i ugovorna prava na reviziju. GDPR pregledavatelj može se usredotočiti na brisanje, rezidentnost podataka, prijavu povrede i transparentnost podizvršitelja obrade.
Uobičajeni obrasci neuspjeha
Najčešći neuspjesi zajedničke odgovornosti nisu egzotični.
Prvo, organizacije se oslanjaju na sigurnosna atestacijska izvješća pružatelja bez mapiranja na odgovornosti klijenta. Pružatelj usluga u oblaku može dokazati fizičku sigurnost, otpornost infrastrukture i kontrole platforme, ali ne i je li vaš spremnik za pohranu bio privatan, jesu li IAM uloge bile u skladu s načelom najmanjih ovlasti ili jesu li dnevnički zapisi bili omogućeni.
Drugo, ugovori sadržavaju generičan sigurnosni tekst, ali ne i rokove za incidente, prava pristupa dnevničkim zapisima, prava na reviziju, ograničenja podugovaranja, odredbe o povratu podataka ili izlaznu podršku. Zenith Blueprint, faza Controls in Action, korak 23 ističe tipična područja ugovora s dobavljačima kao što su povjerljivost, kontrola pristupa, tehničke i organizacijske mjere (TOM), rokovi za incidente, pravo na reviziju, kontrole podugovaratelja i odredbe pri isteku ugovora.
Treće, podizvršitelji obrade navedeni su za potrebe privatnosti, ali nisu povezani sa sigurnošću, neprekidnošću poslovanja ili rizikom koncentracije. Nizvodni pružatelj opservabilnosti ili podrške možda se nikada ne pojavi u registru rizika, iako bi njegova nedostupnost usluge ili povreda mogla utjecati na pružanje usluge klijentima.
Četvrto, SoA kaže da je kontrola primjenjiva, ali nitko ne može proizvesti operativne dokaze. Dnevničko bilježenje u oblaku može biti označeno kao implementirano, ali organizacija ne može dokazati postavke zadržavanja, preglede pristupa, postupanje s upozorenjima ili obveze pružatelja za pristup dnevničkim zapisima.
Peto, planovi odgovora na incidente ne odražavaju ovisnost o pružatelju. Ako pružatelj obavijesti o incidentu platforme, tko procjenjuje utjecaj na klijente? Tko određuje je li potrebna obavijest prema NIS2, DORA ili GDPR? Tko kontaktira pogođene klijente? Što ako je temeljni uzrok kod podizvršitelja obrade?
Odgovornost uprave: zašto bi upravni odbor trebao mariti
NIS2 Article 20 zahtijeva da upravljačka tijela odobre mjere upravljanja rizicima kibernetičke sigurnosti, nadziru implementaciju i prođu osposobljavanje. DORA Article 5 zahtijeva da upravljačko tijelo definira, odobri, nadzire i bude odgovorno za aranžmane upravljanja IKT rizicima, uključujući politike za IKT treće strane, planove neprekidnosti poslovanja i oporavka, planove revizije, osposobljavanje i kanale izvješćivanja.
To mijenja svrhu matrice. Ona više nije samo sigurnosni radni list. Postaje dokaz da uprava zna:
- Koje usluge u oblaku podržavaju kritične operacije.
- Koje su treće strane i podizvršitelji obrade materijalni.
- Koje se obveze primjenjuju prema ugovorima s klijentima, GDPR, NIS2 i DORA.
- Koje odgovornosti ostaju u organizaciji.
- Koje su obveze pružatelja ugovorno provedive.
- Koje praznine zahtijevaju financiranje, korektivne radnje ili prihvaćanje rizika.
Za mala i srednja poduzeća razmjernost je važna. Manji subjekt ne treba tešku birokraciju, ali i dalje treba dokumentaciju, nadzor, otporne sustave, otkrivanje izvora IKT rizika, identifikaciju ključnih ovisnosti o trećim stranama, mjere neprekidnosti poslovanja, testiranje, naučene lekcije i periodični pregled kada je u opsegu.
Matrica je jedan od najučinkovitijih razmjernih alata jer konsolidira obveze umjesto da ih umnožava.
Tridesetodnevni sprint za pripremu modela oblaka za reviziju
Ako ne možete odgovoriti tko je vlasnik svake kontrole u oblaku, koji dokaz je potvrđuje i koji podizvršitelj obrade može na nju utjecati, vaš model zajedničke odgovornosti i dalje je dijagram, a ne artefakt upravljanja.
Praktični tridesetodnevni sprint izgleda ovako:
- Izradite ili ažurirajte Registar usluga u oblaku koristeći Politiku korištenja usluga u oblaku ili Politiku korištenja usluga u oblaku za MSP-ove.
- Identificirajte kritične usluge, obradu osobnih podataka, sustave dostupne klijentima i relevantnost za DORA ili NIS2.
- Izradite prvu matricu oko kontrola iz Priloga A ISO/IEC 27001:2022 5.20, 5.21 i 5.23 koristeći Zenith Controls.
- Povežite svaki redak s registrom rizika i Izjavom o primjenjivosti koristeći korak 13 iz Zenith Blueprint.
- Provjerite odredbe za dobavljače i izvršitelje obrade koristeći Politiku sigurnosti trećih strana i dobavljača, Politiku sigurnosti trećih strana i dobavljača za MSP-ove i Politiku zaštite podataka i privatnosti.
- Dodajte zadržavanje dnevničkih zapisa, eskalaciju incidenata, odobrenje podizvršitelja obrade, prava na reviziju i izlazne dokaze.
- Pregledajte kritične dobavljače jednom godišnje te nakon značajnih promjena, incidenata, novih podizvršitelja obrade ili revizijskih nalaza.
Cilj je jednostavan. Kada klijent, revizor, regulatorno tijelo ili upravni odbor pita “tko je vlasnik ove kontrole?”, ne pretražujete ugovore, tikete i mape. Otvarate matricu, pokazujete vlasnika, pokazujete odredbu, pokazujete dokaz i pokazujete nizvodni trag.
Clarysec vam može pomoći da pakete sigurnosnih dokaza pružatelja usluga u oblaku pretvorite u integriranu matricu zajedničke odgovornosti za revizije ISO/IEC 27001:2022, spremnost za NIS2, IKT rizik trećih strana prema DORA, odgovornost prema GDPR-u i dubinsku analizu dobavljača za poslovne klijente.
Počnite s registrom. Izgradite matricu. Priložite dokaze. Zatim je koristite kao dokaz za upravni odbor da se rizik oblaka ne prepušta vanjskim stranama, nego se njime upravlja.
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
