Mākoņpakalpojumu kopīgās atbildības matrica ISO, NIS2 un DORA vajadzībām

Fintech uzņēmuma operāciju vadītājs pirmdien plkst. 07.15 zvana informācijas drošības vadītājam (CISO).

Eiropas bankas klients prasa pierādījumus, ka uzņēmuma SaaS platforma spēj izpildīt DORA IKT trešo pušu riska prasības. Pārdošanas komanda jau ir nosūtījusi ierasto piegādātāja drošības paketi: ISO sertifikātu, penetrācijas testa vadības kopsavilkumu, kiberrisku apdrošināšanas sertifikātu, privātuma paziņojumu un mākoņpakalpojumu sniedzēja apliecinājuma ziņojumu.

Banka atgriežas ar precīzāku jautājumu:

“Parādiet, kam pieder katrs kontroles pasākums jūsu mākoņvidē: jums, jūsu mākoņpakalpojumu sniedzējam, jūsu pārvaldītās datubāzes nodrošinātājam, jūsu identitātes nodrošinātājam, jūsu žurnalēšanas piegādātājam un jebkuriem apakšapstrādātājiem. Pēc tam parādiet pierādījumus.”

Vēlāk tajā pašā rītā informācijas drošības vadītājs piedalās valdes sanāksmē. Izpilddirektors uzdos to pašu jautājumu biznesa valodā: “Vai esam pārliecināti, ka šī platforma ir droša, un kurš ir atbildīgs, ja kaut kas noiet greizi?”

Tieši šajā brīdī daudzas mākoņpakalpojumu atbilstības programmas apstājas.

Organizācijai var būt spēcīgs mākoņpakalpojumu sniedzējs, labi rīki, pamatotas politikas un risku reģistrs. Taču, kad jāapliecina atbildības robežas, pierādījumi ir izkliedēti. Iepirkuma funkcijai ir līgumi. Juridiskajam dienestam ir datu apstrādes līgums. Inženierijai ir arhitektūras shēmas. Drošības komandai ir žurnāli un mākoņvides konfigurācijas. Privātuma funkcijai ir apakšapstrādātāju saraksts. Atbilstības funkcijai ir piemērojamības deklarācija. Nevienam nav viena kontrolēta artefakta, kas kontroles pasākumu līmenī nosaka, ko dara pakalpojumu sniedzējs, kas jākonfigurē klientam, kurš apakšapstrādātājs ir iesaistīts, kura klauzula padara pienākumu izpildāmu un kādus pierādījumus auditoram būtu jāgaida.

Šis artefakts ir mākoņpakalpojumu kopīgās atbildības matrica.

Tā nav vispārīga lielā mākoņpakalpojumu sniedzēja prezentācijas lapa, kurā teikts, ka pakalpojumu sniedzējs aizsargā mākoni, bet klients aizsargā to, kas atrodas mākonī. Reāla mākoņpakalpojumu kopīgās atbildības matrica ISO/IEC 27001:2022, NIS2, DORA un GDPR vajadzībām ir pārvaldības ieraksts. Tā iztur klienta sākotnējo izpēti, ISO auditu, DORA pārskatīšanu, GDPR pārskatatbildības pārbaudi un incidenta izmeklēšanu.

Kāpēc mākoņpakalpojumu kopīgā atbildība kļūst par audita problēmu

Kopīgās atbildības modelis parasti tiek skaidrots kā tehniska robeža. IaaS modelī pakalpojumu sniedzējs pārvalda fiziskos objektus, aparatūru, virtualizāciju un pamatinfrastruktūru. Klients pārvalda identitātes, datus, darbslodzes, tīkla noteikumus, šifrēšanas izvēles un konfigurācijas. SaaS modelī pakalpojumu sniedzējs uzņemas lielāku operacionālo atbildību, taču klients joprojām ir atbildīgs par lietotāju piekļuvi, datu pārvaldību, tiesisko pamatu, konfigurāciju, uzraudzības prasībām un incidentu eskalāciju.

Šis skaidrojums ir noderīgs, bet nepilnīgs.

Auditori, regulatori un uzņēmumu klienti jautā vairāk nekā “kurš darbina kontroles pasākumu?”. Viņi vēlas zināt:

• Kurš ir pārskatatbildīgs par risku?
• Kura līguma klauzula padara šo pārskatatbildību izpildāmu?
• Kura politika pieprasa šo kontroles pasākumu?
• Kurš mākoņpakalpojums, SaaS platforma vai apakšapstrādātājs ietilpst darbības jomā?
• Kuri pierādījumi apliecina, ka kontroles pasākums darbojās pārskatīšanas periodā?
• Kuru ietvara prasību šie pierādījumi izpilda?
• Kas notiek, ja pakalpojumu sniedzējs maina pakalpojumu, atrašanās vietu, apakšuzņēmēju vai kontroles pasākumu statusu?

ISO/IEC 27001:2022 ISO/IEC 27001:2022 padara to par pārvaldības sistēmas jautājumu. Punkti 4.1 līdz 4.4 prasa organizācijai izprast iekšējos un ārējos jautājumus, ieinteresētās puses, tiesiskos un līgumiskos pienākumus, ISMS darbības jomu, saskarnes un atkarības. Punkti 6.1.1 līdz 6.1.3 prasa risku izvērtēšanu, risku apstrādi, riska īpašnieka apstiprinājumu, atlikušā riska pieņemšanu un piemērojamības deklarāciju. Punkts 8.1 prasa darbības plānošanu un kontroli, tostarp ārēji nodrošinātu procesu, produktu un pakalpojumu kontroli, ja tie ir nozīmīgi ISMS.

Praktiski tas nozīmē: ja mākoņpakalpojumu sniedzējs, SaaS piegādātājs vai apakšapstrādātājs atbalsta darbības jomā iekļautu biznesa procesu, tas nevar atrasties ārpus ISMS. Tam jābūt redzamam darbības jomā, riskos, apstrādē, līgumiskajos kontroles pasākumos un pierādījumos.

NIS2 paaugstina prasību līmeni. Article 21 pieprasa būtiskām un svarīgām vienībām ieviest atbilstošus un samērīgus tehniskos, operacionālos un organizatoriskos pasākumus, tostarp riska analīzi, incidentu apstrādi, nepārtrauktību, piegādes ķēdes drošību, drošu iegādi, drošu izstrādi, ievainojamību apstrādi, efektivitātes izvērtēšanu, kiberdrošības higiēnu, kriptogrāfiju, personāla drošību, piekļuves kontroli, aktīvu pārvaldību un daudzfaktoru autentifikāciju vai nepārtrauktu autentifikāciju, ja tas ir piemēroti. Article 20 nosaka vadības struktūru pārvaldības atbildību.

DORA finanšu iestādēm ir vēl konkrētāka. Tā ir piemērojama no 2025. gada 17. janvāra un pieprasa finanšu iestādēm pārvaldīt IKT risku, ziņošanu par būtiskiem ar IKT saistītiem incidentiem, digitālās operacionālās noturības testēšanu un IKT trešo pušu risku. Articles 28 līdz 30 pieprasa IKT trešo pušu riska pārvaldību, sākotnēju koncentrācijas riska izvērtēšanu, līgumiskus drošības pasākumus, audita un piekļuves tiesības, apakšuzņēmēju pārredzamību, izbeigšanas tiesības un izstāšanās stratēģijas.

GDPR pievieno pārskatatbildības pārbaudi. Article 5 pieprasa personas datus apstrādāt, nodrošinot integritāti un konfidencialitāti, un Article 5(2) pieprasa, lai pārzinis spētu pierādīt atbilstību. Article 28 regulē apstrādātāju līgumus un apakšapstrādātājus. Article 32 pieprasa apstrādes drošību. Articles 33 un 34 pieprasa paziņošanu par personas datu aizsardzības pārkāpumu, ja tas ir piemērojams.

Mākoņpakalpojumu kopīgās atbildības matrica kļūst par tiltu starp šiem pienākumiem.

Clarysec definīcija: pārvaldības artefakts, nevis shēma

Clarysec projektos mākoņpakalpojumu kopīgās atbildības matrica ir kontrolēts ISMS ieraksts, kas sasaista mākoņpakalpojumus, piegādātājus, apakšapstrādātājus, kontroles pasākumus, politikas, līgumiskos pienākumus, pierādījumus un audita gaidas.

Spēcīgākais skaidrojums ir sniegts Zenith Blueprint Zenith Blueprint Controls in Action posma 23. solī:

“Mākoņpakalpojumu sniedzēji aizsargā infrastruktūru, bet jūs joprojām esat pārskatatbildīgi par saviem datiem, savām konfigurācijām, savām piekļuves politikām un savu gatavību reaģēšanai uz incidentiem.”

Tajā pašā solī skaidrots, ka mākoņpakalpojumu izmantošana jāuzskata par ISMS daļu, tostarp jāklasificē mākoņpakalpojumi, jāizprot apstrādātie vai glabātie dati, jāveic pakalpojumu sniedzēja izvērtēšana, jānosaka līguma klauzulas un jāpārvalda pakalpojuma izmaiņas. Tas pārvērš kopīgo atbildību no koncepta par izsekojamu kontroles struktūru.

Zenith Controls Zenith Controls uzskata ISO/IEC 27001:2022 A pielikuma kontroles pasākumus un ISO/IEC 27002:2022 vadlīniju 5.20, 5.21 un 5.23 par centrālajiem atskaites punktiem:

• 5.20, informācijas drošības ietveršana piegādātāju līgumos.
• 5.21, informācijas drošības pārvaldība IKT piegādes ķēdē.
• 5.23, informācijas drošība mākoņpakalpojumu izmantošanā.

Tie nav izolēti kontrolsaraksta punkti. Tie veido matricas mugurkaulu.

Atbalsta standarti var pastiprināt matricu. ISO/IEC 27017 palīdz ar mākoņpakalpojumiem specifiskām drošības praksēm. ISO/IEC 27018 un ISO/IEC 27701 atbalsta PII un privātuma pārvaldību. ISO/IEC 27005 atbalsta risku izvērtēšanu. ISO 22301 atbalsta nepārtrauktību un noturību. ISO/IEC 27035 atbalsta incidentu pārvaldību. ISO/IEC 20000-1 var palīdzēt gadījumos, kad mākoņpakalpojumi ir daļa no pārvaldīta pakalpojuma piegādes.

Minimāli dzīvotspējīga kopīgās atbildības matrica

Nobriedusi matrica nesākas ar 200 rindām. Tā sākas ar svarīgākajiem mākoņpakalpojumiem.

SaaS, fintech vai regulētam SME Clarysec parasti sāk ar:

1. Klientiem pieejamu ražošanas mākoņvidi.
2. Identitātes nodrošinātāju.
3. Pārvaldītu datubāzes vai glabāšanas pakalpojumu.
4. Žurnalēšanas, uzraudzības un SIEM platformu.
5. Maksājumu, KYC, analītikas vai klientu atbalsta SaaS.
6. Rezerves kopiju un avārijas atjaunošanas pakalpojumu.
7. Pārvaldīto pakalpojumu sniedzēju vai pārvaldītās drošības pakalpojumu sniedzēju.
8. Apakšapstrādātājus, kas piekļūst klientu datiem, glabā tos vai apstrādā tos.

Pirmajā matricā jāiekļauj šādas kolonnas.

Praktiska žurnalēšanas rinda varētu izskatīties šādi.

Šī rinda nav tikai dokumentācija. Tā drošības komandai norāda, kas jākonfigurē, iepirkuma funkcijai — kāda līguma valoda jāpārbauda, privātuma funkcijai — kāda datu plūsma jāreģistrē, un auditoriem — kādi pierādījumi jāpieprasa.

Politikas pamats: kā padarīt matricu par izpildāmu prasību

Mākoņpakalpojumu kopīgās atbildības matrica bez politikas pamata ir tikai izklājlapa. Clarysec politikas padara to izpildāmu.

SME vajadzībām Mākoņpakalpojumu izmantošanas politika - SME Mākoņpakalpojumu izmantošanas politika - SME, sadaļas “Pārvaldības prasības” 5.3. punktā pieprasa:

“IT pakalpojumu sniedzējam vai GM jāuztur Mākoņpakalpojumu reģistrs. Tajā jāreģistrē:”

Tā pati SME politika 5.2.3. punktā sasaista mākoņpakalpojumu pārvaldību ar privātumu un atrašanās vietas risku:

“Datu rezidence un privātuma prakse atbilst piemērojamām tiesiskajām prasībām (piemēram, GDPR)”

Uzņēmuma vidēm Mākoņpakalpojumu izmantošanas politika Mākoņpakalpojumu izmantošanas politika, sadaļas “Pārvaldības prasības” 5.1. punktā nosaka:

“Organizācijai jāuztur centralizēts Mākoņpakalpojumu reģistrs, kura īpašnieks ir Galvenais informācijas drošības vadītājs un kurā ir:”

Pēc tam 5.4. punkts padara mākoņpakalpojumu atbildības līgumiski izpildāmas:

“Visos CSP (Cloud Service Provider) līgumos jāiekļauj izpildāmi noteikumi par:”

Piegādātāju pārvaldība paplašina matricu ārpus tiešā pakalpojumu sniedzēja. Trešo pušu un piegādātāju drošības politika - SME Trešo pušu un piegādātāju drošības politika - SME, sadaļas “Pārvaldības prasības” 5.3.5. punktā pieprasa:

“Ierobežojumi turpmākai apakšuzņēmēju piesaistei bez apstiprinājuma”

Tā pati SME piegādātāju politika, sadaļas “Politikas ieviešanas prasības” 6.3.1. punktā pievieno periodisku pārskatīšanu:

“Kritiskie vai augsta riska piegādātāji jāpārskata vismaz reizi gadā. Pārskatīšanā jāpārbauda:”

Uzņēmuma līmenī Trešo pušu un piegādātāju drošības politika Trešo pušu un piegādātāju drošības politika, sadaļas “Pārvaldības prasības” 5.3. punktā nosaka:

“Līgumos ar piegādātājiem jāiekļauj:”

Personas datiem Datu aizsardzības un privātuma politika Datu aizsardzības un privātuma politika, sadaļas “Ievērošana un atbilstība” 8.5.1. punktā pieprasa:

“Līgumos ar apstrādātājiem jāiekļauj:”

Atkarību pārredzamībai Piegādātāju atkarības risku pārvaldības politika Piegādātāju atkarības risku pārvaldības politika, 6.5.4. punktā pieprasa:

“Piegādātāja attiecību izmantošana, lai iegūtu atjauninājumus par apakšuzņēmējiem vai piegādes ķēdes atkarībām vienu līmeni tālāk, ja tās varētu mūs ietekmēt (piemēram, ja kritisks programmatūras piegādātājs būtiski paļaujas uz trešās puses bibliotēku, tas jāreģistrē).”

Žurnāliem Žurnalēšanas un uzraudzības politika - SME Žurnalēšanas un uzraudzības politika - SME, sadaļas “Pārvaldības prasības” 5.5.1.3. punktā sniedz konkrētu līgumisku prasību:

“Līgumos jāpieprasa pakalpojumu sniedzējiem glabāt žurnālus vismaz 12 mēnešus un nodrošināt piekļuvi pēc pieprasījuma”

Kopā šīs politikas padara matricu par obligātu pārvaldības ierakstu, kas atbalsta piegādātāju apstiprināšanu, mākoņpakalpojumu sākotnējo piesaisti, privātuma pārskatatbildību, ikgadējo pārskatīšanu un audita pierādījumus.

Matricas kartēšana ISO/IEC 27001:2022, NIS2, DORA un GDPR ietvaros

Klasiska kļūda ir četru atsevišķu atbilstības darbgrāmatu veidošana. Viens kontroles pasākums var izpildīt vairākus pienākumus, ja atbildība un pierādījumi ir izsekojami.

ISO/IEC 27001:2022 nodrošina ISMS dzinēju: kontekstu, ieinteresētās puses, darbības jomu, vadību, risku apstrādi, mērķus, darbības kontroli, veiktspējas izvērtēšanu un uzlabošanu. A pielikums nodrošina praktisko kontroles pasākumu struktūru.

NIS2 Article 21 dabiski kartējas uz to pašu matricu, izmantojot piegādes ķēdes drošību, incidentu apstrādi, nepārtrauktību, piekļuves kontroli, aktīvu pārvaldību un drošu iegādi. Article 20 padara matricu nozīmīgu valdei, jo vadības struktūrām jāapstiprina un jāpārrauga kiberdrošības risku pārvaldības pasākumi.

DORA pārvērš matricu par IKT trešo pušu riska rīku. Articles 5, 6 un 8 pieprasa pārvaldību, dokumentētu IKT risku pārvaldību un aktīvu, funkciju un atkarību identificēšanu. Articles 17 līdz 19 pieprasa incidentu atklāšanu, klasificēšanu, eskalāciju, komunikāciju un ziņošanu. Articles 28 līdz 30 pieprasa trešo pušu risku pārvaldību, koncentrācijas riska analīzi, līguma klauzulas, apakšuzņēmēju kontroles pasākumus, audita tiesības, izbeigšanas tiesības un izstāšanās stratēģijas.

GDPR pievieno personas datu perspektīvu. Katrai mākoņpakalpojuma rindai jāidentificē, vai tiek apstrādāti personas dati, vai pakalpojumu sniedzējs ir apstrādātājs vai apakšapstrādātājs, vai datu atrašanās vietai ir nozīme un kādi līguma vai DPA pierādījumi pastāv.

NIST CSF 2.0 palīdz komunicēt to pašu matricu rezultātu valodā. GOVERN funkcija aptver organizācijas kontekstu, tiesiskās un regulatīvās prasības, atkarības, risku pārvaldību, lomas, politikas un pārraudzību. GV.SC rezultāti ir īpaši noderīgi piegādātāju kiberriskam, tostarp piegādātāju lomām, kritiskumam, līgumiskajām prasībām, sākotnējai izpētei, uzraudzībai, incidentu koordinācijai un izbeigšanas plānošanai.

COBIT 2019 pievieno apliecinājuma un pārvaldības perspektīvu. Tas jautā, vai pārskatatbildība, pārvaldības prakses, īpašumtiesības, uzraudzība un problēmu novēršana ir atkārtojamas un pamatotas ar pierādījumiem.

Matricas veidošana no reģistra līdz pierādījumiem

Iedomājieties SaaS uzņēmumu, kas izmanto hipermēroga IaaS platformu, pārvaldītu datubāzi, trešās puses identitātes nodrošinātāju, klientu atbalsta SaaS platformu un ārēju SIEM. Ieviešanas plūsma ir vienkārša.

1. solis: sāciet ar Mākoņpakalpojumu reģistru

Izmantojiet Mākoņpakalpojumu izmantošanas politiku vai Mākoņpakalpojumu izmantošanas politiku - SME kā sākšanas nosacījumu. Reģistrējiet katru mākoņpakalpojumu, īpašnieku, nolūku, datu kategorijas, atrašanās vietu, biznesa funkciju, piegādātāja līmeni, līguma īpašnieku un pārskatīšanas datumu.

Ja pakalpojums glabā klientu ierakstus, autentifikācijas žurnālus vai atbalsta pieteikumus, atzīmējiet to kā privātumam nozīmīgu. Ja tas atbalsta ražošanas pieejamību, atzīmējiet to kā operacionāli kritisku. Ja tas atbalsta finanšu klienta kritisku vai svarīgu funkciju, atzīmējiet to kā DORA nozīmīgu.

2. solis: pievienojiet kopīgās atbildības domēnus

Katram pakalpojumam definējiet atbildības galvenajos domēnos.

3. solis: sasaistiet kontroles pasākumus ar risku un piemērojamības deklarāciju

Zenith Blueprint, Risk Management posma 13. solī, skaidro izsekojamības prasību:

“Savstarpēji sasaistiet regulējumus: ja noteikti kontroles pasākumi ir ieviesti tieši, lai nodrošinātu atbilstību GDPR, NIS2 vai DORA, to var norādīt vai nu Riska reģistrā (kā daļu no riska ietekmes pamatojuma), vai SoA piezīmēs.”

Piemēram, risks “nesankcionēta piekļuve klientu ražošanas datiem mākoņvides nepareizas konfigurācijas dēļ” var kartēties uz piekļuves kontroli, mākoņpakalpojumu izmantošanu, žurnalēšanu, kriptogrāfiju, ievainojamību pārvaldību un piegādātāju līgumiem. SoA var atsaukties uz ISO/IEC 27001:2022 A pielikuma 5.15, 5.16, 5.20, 5.23, 8.8, 8.15, 8.16 un 8.24 ar piezīmēm par GDPR Article 32, NIS2 Article 21 un DORA IKT risku pārvaldību, ja piemērojams.

4. solis: pievienojiet pierādījumus pirms audita sezonas

Pierādījumi jāiestrādā matricā jau projektēšanas laikā, nevis jāvāc panikā.

Pierādījumu saraksts pārvērš atbildību pierādījumos. Tas arī palīdz komerciālajām komandām ātrāk atbildēt uz uzņēmumu klientu sākotnējās izpētes jautājumiem, jo tās var parādīt ne tikai sertifikācijas, bet arī kontroles pasākumu īpašumtiesības un darbības pierādījumus.

Apakšapstrādātāji: aklā zona lielākajā daļā matricu

Apakšapstrādātāji ir vieta, kur kopīgā atbildība kļūst par reālu piegādes ķēdes risku.

SaaS sniedzējs var būt jūsu apstrādātājs saskaņā ar GDPR. Šis sniedzējs var paļauties uz mākoņmitināšanas pakalpojumu sniedzēju, CDN, analītikas pakalpojumu, atbalsta platformu, e-pasta piegādes pakalpojumu, pārvaldītu datubāzi, novērojamības nodrošinātāju un maksājumu apstrādātāju. Daži var piekļūt personas datiem. Daži var atbalstīt kritisku pakalpojuma piegādi, tieši neskatot datus. Daži var atrasties ārpus ES. Daži var būt aizstājami. Citi var radīt koncentrācijas risku.

DORA Article 29 pieprasa koncentrācijas riska izvērtēšanu kritiskiem vai svarīgiem IKT pakalpojumiem, tostarp aizstājamību, vairākas vienošanās ar tiem pašiem vai saistītiem pakalpojumu sniedzējiem, apakšuzņēmēju ķēdes, trešo valstu apakšuzņēmējus, maksātnespējas tiesības, datu atjaunošanas ierobežojumus un Savienības datu aizsardzības prasību izpildāmību. DORA Article 30 pieprasa līgumiskus noteikumus par apakšuzņēmēju piesaistes nosacījumiem, atrašanās vietām, datu apstrādi un glabāšanu, piekļuvi un atjaunošanu, incidentu palīdzību, sadarbību ar iestādēm, audita tiesībām, izbeigšanu un izstāšanos.

NIS2 Article 21 līdzīgi pieprasa piegādes ķēdes drošību tiešajiem piegādātājiem un pakalpojumu sniedzējiem, kā arī piegādātājam specifisku ievainojamību, piegādātāju kiberdrošības prakšu un drošas izstrādes procedūru ņemšanu vērā.

Tāpēc Clarysec uzskata apakšapstrādātāju kartēšanu par obligātu piegādātāju pārvaldības paplašinājumu, nevis tikai privātuma sarakstu. Apakšapstrādātāju reģistram jāparāda, kurš piegādātājs izmanto apakšapstrādātāju, no kura pakalpojuma tas ir atkarīgs, vai tiek apstrādāti personas dati, vai tas atbalsta kritisku funkciju, apstrādes reģions, ja tas ir nozīmīgi, tālāk nododamie līgumiskie pienākumi, apstiprinājuma vai iebildumu tiesības, pieejamie apliecinājumi, uzraudzības metode un izstāšanās iespēja.

Zenith Blueprint, Controls in Action posma 23. solī, nosaka:

“Katram kritiskam piegādātājam identificējiet, vai tas izmanto apakšuzņēmējus (apakšapstrādātājus), kuri var piekļūt jūsu datiem vai sistēmām. Dokumentējiet, kā jūsu informācijas drošības prasības tiek tālāk nodotas šīm pusēm — vai nu ar jūsu piegādātāja līguma noteikumiem, vai ar jūsu tiešajām klauzulām.”

Tas ir pierādījumu līmenis, ko auditori sagaida, jautājot, vai mākoņpakalpojumu atbildības tiek kontrolētas tālāk piegādes ķēdē.

Kā auditori testē to pašu matricu

Spēcīga mākoņpakalpojumu kopīgās atbildības matrica iztur vairākus audita stilus, jo tā ir veidota ap īpašumtiesībām, izpildāmību un pierādījumiem.

Matrica nav gala mērķis. Tā ir karte, ko auditori izmanto, lai testētu, vai pārvaldības sistēma ir reāla.

ISO auditors var izvēlēties augstas ietekmes mākoņpiekļuves risku un izsekot to no risku reģistra līdz SoA, pēc tam līdz piekļuves tiesību pārskatīšanai, MFA pierādījumiem un uzraudzības brīdinājumiem. DORA izvērtētājs var izvēlēties kritisku IKT pakalpojumu sniedzēju un pieprasīt izstāšanās testu, apakšuzņēmēju analīzi un līgumiskās audita tiesības. GDPR pārbaudītājs var koncentrēties uz dzēšanu, datu rezidenci, paziņošanu par pārkāpumu un apakšapstrādātāju pārredzamību.

Biežākie kļūmju modeļi

Visbiežākās kopīgās atbildības kļūmes nav eksotiskas.

Pirmkārt, organizācijas paļaujas uz pakalpojumu sniedzēju apliecinājuma ziņojumiem, nekartējot tos ar klienta atbildībām. Mākoņpakalpojumu sniedzējs var pierādīt fizisko drošību, infrastruktūras noturību un platformas kontroles pasākumus, bet ne to, vai jūsu glabātuves spainis bija privāts, IAM lomas atbilda minimāli nepieciešamajām tiesībām vai žurnāli bija iespējoti.

Otrkārt, līgumos ir vispārīga drošības valoda, bet nav incidentu termiņu, žurnālu piekļuves tiesību, audita tiesību, apakšuzņēmēju ierobežojumu, datu atgriešanas noteikumu vai izstāšanās atbalsta. Zenith Blueprint, Controls in Action posma 23. solī, izceļ tipiskas piegādātāju līgumu jomas, piemēram, konfidencialitāti, piekļuves kontroli, tehniskos un organizatoriskos pasākumus, incidentu termiņus, audita tiesības, apakšuzņēmēju kontroles pasākumus un līguma beigu noteikumus.

Treškārt, apakšapstrādātāji ir uzskaitīti privātuma vajadzībām, bet nav sasaistīti ar drošību, nepārtrauktību vai koncentrācijas risku. Tālāks novērojamības vai atbalsta pakalpojumu sniedzējs var nekad neparādīties risku reģistrā, lai gan tā nepieejamība vai pārkāpums var ietekmēt klientu pakalpojumu piegādi.

Ceturtkārt, SoA norāda, ka kontroles pasākums ir piemērojams, bet neviens nevar uzrādīt darbības pierādījumus. Mākoņvides žurnalēšana var būt atzīmēta kā ieviesta, bet organizācija nevar pierādīt glabāšanas iestatījumus, piekļuves tiesību pārskatīšanu, brīdinājumu apstrādi vai pakalpojumu sniedzēja žurnālu piekļuves saistības.

Piektkārt, reaģēšanas uz incidentiem plāni neatspoguļo pakalpojumu sniedzēja atkarību. Ja pakalpojumu sniedzējs paziņo par platformas incidentu, kurš izvērtē ietekmi uz klientiem? Kurš nosaka, vai nepieciešama NIS2, DORA vai GDPR paziņošana? Kurš sazinās ar ietekmētajiem klientiem? Ko darīt, ja pamatcēlonis ir pie apakšapstrādātāja?

Vadības pārskatatbildība: kāpēc valdei tas ir svarīgi

NIS2 Article 20 pieprasa vadības struktūrām apstiprināt kiberdrošības risku pārvaldības pasākumus, pārraudzīt ieviešanu un saņemt apmācību. DORA Article 5 pieprasa vadības struktūrai noteikt, apstiprināt, pārraudzīt un uzņemties atbildību par IKT risku pārvaldības kārtību, tostarp IKT trešo pušu politikām, nepārtrauktības un atjaunošanas plāniem, audita plāniem, apmācībām un ziņošanas kanāliem.

Tas maina matricas mērķi. Tā vairs nav tikai drošības darba lapa. Tā kļūst par pierādījumu, ka vadība zina:

• Kuri mākoņpakalpojumi atbalsta kritiskas operācijas.
• Kuras trešās puses un apakšapstrādātāji ir būtiski.
• Kuri pienākumi piemērojami saskaņā ar klientu līgumiem, GDPR, NIS2 un DORA.
• Kuras atbildības saglabā organizācija.
• Kuras pakalpojumu sniedzēju saistības ir līgumiski izpildāmas.
• Kuri trūkumi prasa finansējumu, trūkumu novēršanu vai riska pieņemšanu.

SME gadījumā būtiska ir samērīguma pieeja. Mazākai vienībai nav vajadzīga smagnēja birokrātija, taču tai joprojām ir vajadzīga dokumentācija, uzraudzība, noturīgas sistēmas, IKT riska avotu detektēšana, būtisku trešo pušu atkarību identificēšana, nepārtrauktības pasākumi, testēšana, gūtās mācības un periodiska pārskatīšana, ja tā ietilpst darbības jomā.

Matrica ir viens no efektīvākajiem samērīgajiem rīkiem, jo tā konsolidē pienākumus, nevis tos pavairo.

30 dienu sprints, lai padarītu jūsu mākoņpakalpojumu modeli gatavu auditam

Ja nevarat atbildēt, kam pieder katrs mākoņvides kontroles pasākums, kuri pierādījumi to apliecina un kurš apakšapstrādātājs to var ietekmēt, jūsu kopīgās atbildības modelis joprojām ir shēma, nevis pārvaldības artefakts.

Praktisks 30 dienu sprints izskatās šādi:

1. Izveidojiet vai atjauniniet Mākoņpakalpojumu reģistru, izmantojot Mākoņpakalpojumu izmantošanas politiku vai Mākoņpakalpojumu izmantošanas politiku - SME.
2. Identificējiet kritiskos pakalpojumus, personas datu apstrādi, klientiem pieejamas sistēmas un DORA vai NIS2 nozīmīgumu.
3. Izveidojiet pirmo matricu ap ISO/IEC 27001:2022 A pielikuma kontroles pasākumiem 5.20, 5.21 un 5.23, izmantojot Zenith Controls.
4. Sasaistiet katru rindu ar risku reģistru un piemērojamības deklarāciju, izmantojot Zenith Blueprint 13. soli.
5. Validējiet piegādātāju un apstrādātāju klauzulas, izmantojot Trešo pušu un piegādātāju drošības politiku, Trešo pušu un piegādātāju drošības politiku - SME un Datu aizsardzības un privātuma politiku.
6. Pievienojiet žurnālu glabāšanu, incidentu eskalāciju, apakšapstrādātāju apstiprināšanu, audita tiesības un izstāšanās pierādījumus.
7. Pārskatiet kritiskos piegādātājus reizi gadā un pēc būtiskām izmaiņām, incidentiem, jauniem apakšapstrādātājiem vai audita konstatējumiem.

Mērķis ir vienkāršs. Kad klients, auditors, regulators vai valde jautā “kam pieder šis kontroles pasākums?”, jūs nemeklējat pa līgumiem, pieteikumiem un mapēm. Jūs atverat matricu, parādāt īpašnieku, parādāt klauzulu, parādāt pierādījumus un parādāt audita pēdu tālāk piegādes ķēdē.

Clarysec var palīdzēt pārvērst mākoņpakalpojumu sniedzēju apliecinājuma paketes integrētā kopīgās atbildības matricā ISO/IEC 27001:2022 auditiem, NIS2 gatavībai, DORA IKT trešo pušu riskam, GDPR pārskatatbildībai un uzņēmumu klientu sākotnējai izpētei.

Sāciet ar reģistru. Izveidojiet matricu. Pievienojiet pierādījumus. Pēc tam izmantojiet to kā valdei gatavu pierādījumu, ka mākoņpakalpojumu risks nav nodots ārpakalpojumā — tas tiek pārvaldīts.