Debesijos bendros atsakomybės matrica ISO, NIS2 ir DORA kontekste
Finansinių technologijų įmonės operacijų vadovas pirmadienį 07:15 paskambina CISO.
Europos banko klientas prašo įrodymų, kad įmonės SaaS platforma gali atitikti DORA IRT trečiųjų šalių rizikos reikalavimus. Pardavimų komanda jau išsiuntė įprastą tiekėjo saugumo paketą: ISO sertifikatą, įsiskverbimo testavimo vadovybei skirtą santrauką, kibernetinio draudimo pažymą, privatumo pranešimą ir debesijos paslaugų teikėjo patikinimo ataskaitą.
Bankas grįžta su tikslesniu klausimu:
„Parodykite, kam priklauso kiekviena kontrolės priemonė jūsų debesijos aplinkoje: jums, jūsų debesijos paslaugų teikėjui, jūsų valdomos duomenų bazės teikėjui, jūsų tapatybės teikėjui, jūsų žurnalų valdymo tiekėjui ir visiems subtvarkytojams. Tada parodykite įrodymus.“
Vėliau tą rytą CISO dalyvauja valdybos posėdyje. Generalinis direktorius užduos tą patį klausimą verslo kalba: „Ar esame tikri, kad ši platforma saugi, ir kas atsakingas, jei kas nors nepavyks?“
Būtent čia daugelis debesijos atitikties programų sustoja.
Organizacija gali turėti stiprų debesijos paslaugų teikėją, gerus įrankius, pagrįstas politikas ir rizikų registrą. Tačiau paprašius pagrįsti atsakomybių ribas, įrodymai būna išskaidyti. Pirkimų funkcija turi sutartis. Teisės funkcija turi DPA. Inžinerija turi architektūros schemas. Saugumo komanda turi žurnalus ir debesijos konfigūracijas. Privatumo funkcija turi subtvarkytojų sąrašą. Atitikties komanda turi Taikytinumo pareiškimą. Niekas neturi vieno kontroliuojamo artefakto, kuriame pagal kiekvieną kontrolės priemonę būtų nurodyta, ką daro paslaugų teikėjas, ką turi sukonfigūruoti klientas, kuris subtvarkytojas dalyvauja, kuri sutarties nuostata padaro įsipareigojimą vykdytiną ir kokių įrodymų turėtų tikėtis auditorius.
Tas artefaktas yra debesijos bendros atsakomybės matrica.
Tai ne bendro pobūdžio didžiojo debesijos paslaugų teikėjo skaidrė, kurioje sakoma, kad paslaugų teikėjas apsaugo debesiją, o klientas apsaugo tai, kas yra debesijoje. Tikra debesijos bendros atsakomybės matrica, skirta ISO/IEC 27001:2022, NIS2, DORA ir GDPR, yra valdysenos įrašas. Ji atlaiko kliento deramą patikrinimą, ISO auditą, DORA peržiūrą, GDPR atskaitomybės patikrinimą ir incidento tyrimą.
Kodėl debesijos bendra atsakomybė tampa audito problema
Bendros atsakomybės modelis paprastai aiškinamas kaip techninė riba. IaaS atveju paslaugų teikėjas valdo fizines patalpas, aparatinę įrangą, virtualizaciją ir bazinę infrastruktūrą. Klientas valdo tapatybes, duomenis, darbo krūvius, tinklo taisykles, šifravimo pasirinkimus ir konfigūracijas. SaaS atveju paslaugų teikėjas prisiima daugiau operacinės atsakomybės, tačiau klientui vis tiek priklauso naudotojų prieiga, duomenų valdysena, teisinis pagrindas, konfigūracija, stebėsenos lūkesčiai ir incidentų eskalavimas.
Toks paaiškinimas naudingas, bet nepakankamas.
Auditoriai, reguliuotojai ir įmonių klientai klausia ne tik „kas vykdo kontrolės priemonę?“ Jie nori žinoti:
- Kas yra atskaitingas už riziką?
- Kuri sutarties nuostata padaro šią atskaitomybę vykdytiną?
- Kuri politika reikalauja šios kontrolės priemonės?
- Kuri debesijos paslauga, SaaS platforma ar subtvarkytojas patenka į taikymo sritį?
- Kurie įrodymai patvirtina, kad kontrolės priemonė veikė per peržiūros laikotarpį?
- Kurios sistemos reikalavimą šie įrodymai tenkina?
- Kas nutinka, jei paslaugų teikėjas pakeičia paslaugą, vietą, subrangovą ar kontrolės priemonių būklę?
ISO/IEC 27001:2022 ISO/IEC 27001:2022 tai paverčia valdymo sistemos klausimu. 4.1–4.4 punktai reikalauja, kad organizacija suprastų vidinius ir išorinius klausimus, suinteresuotąsias šalis, teisinius ir sutartinius įsipareigojimus, ISVS taikymo sritį, sąsajas ir priklausomybes. 6.1.1–6.1.3 punktai reikalauja rizikos vertinimo, rizikos tvarkymo, rizikos savininko patvirtinimo, liekamosios rizikos priėmimo ir Taikytinumo pareiškimo. 8.1 punktas reikalauja operacinio planavimo ir kontrolės, įskaitant išorės teikiamų procesų, produktų ir paslaugų, aktualių ISVS, kontrolę.
Paprastai tariant, jei debesijos paslaugų teikėjas, SaaS tiekėjas ar subtvarkytojas palaiko į taikymo sritį patenkantį verslo procesą, jis negali likti už ISVS ribų. Jis turi būti matomas taikymo srityje, rizikose, rizikos tvarkyme, sutartinėje kontrolėje ir įrodymuose.
NIS2 kelia kartelę. Article 21 reikalauja, kad esminiai ir svarbūs subjektai įgyvendintų tinkamas ir proporcingas technines, operacines ir organizacines priemones, įskaitant rizikos analizę, incidentų valdymą, veiklos tęstinumą, tiekimo grandinės saugumą, saugų įsigijimą, saugų kūrimą, pažeidžiamumų tvarkymą, veiksmingumo vertinimą, kibernetinę higieną, kriptografiją, personalo saugumą, prieigos kontrolę, turto valdymą ir kelių veiksnių autentifikavimą arba tęstinį autentifikavimą, kai tai tinkama. Article 20 nustato valdymo organų valdysenos atsakomybę.
DORA finansų subjektams yra dar aiškesnis. Jis taikomas nuo 2025 m. sausio 17 d. ir reikalauja, kad finansų subjektai valdytų IRT riziką, pranešimus apie reikšmingus su IRT susijusius incidentus, skaitmeninio operacinio atsparumo testavimą ir IRT trečiųjų šalių riziką. Articles 28 to 30 reikalauja IRT trečiųjų šalių rizikos valdymo, preliminaraus koncentracijos rizikos vertinimo, sutartinių apsaugos priemonių, audito ir prieigos teisių, subrangos matomumo, nutraukimo teisių ir pasitraukimo strategijų.
GDPR prideda atskaitomybės testą. Article 5 reikalauja, kad asmens duomenys būtų tvarkomi užtikrinant vientisumą ir konfidencialumą, o Article 5(2) reikalauja, kad duomenų valdytojas galėtų įrodyti atitiktį. Article 28 reglamentuoja duomenų tvarkytojų sutartis ir subtvarkytojus. Article 32 reikalauja tvarkymo saugumo. Articles 33 and 34 reikalauja pranešti apie asmens duomenų saugumo pažeidimą, kai tai taikoma.
Debesijos bendros atsakomybės matrica tampa jungtimi tarp šių įpareigojimų.
Clarysec apibrėžimas: valdysenos artefaktas, o ne schema
Clarysec projektuose debesijos bendros atsakomybės matrica yra kontroliuojamas ISVS įrašas, susiejantis debesijos paslaugas, tiekėjus, subtvarkytojus, kontrolės priemones, politikas, sutartinius įsipareigojimus, įrodymus ir audito lūkesčius.
Aiškiausias paaiškinimas pateikiamas Zenith Blueprint Zenith Blueprint etape „Controls in Action“, Step 23:
„Debesijos paslaugų teikėjai apsaugo infrastruktūrą, tačiau jūs vis tiek esate atskaitingi už savo duomenis, konfigūracijas, prieigos politikas ir pasirengimą reaguoti į incidentus.“
Tas pats žingsnis paaiškina, kad debesijos naudojimas turi būti traktuojamas kaip ISVS dalis, įskaitant debesijos paslaugų klasifikavimą, tvarkomų ar saugomų duomenų supratimą, paslaugų teikėjo vertinimą, sutartines nuostatas ir paslaugų pakeitimų valdymą. Taip bendra atsakomybė iš koncepcijos paverčiama atsekama kontrolės struktūra.
Zenith Controls Zenith Controls ISO/IEC 27001:2022 A priedo kontrolės priemones ir ISO/IEC 27002:2022 gaires 5.20, 5.21 ir 5.23 laiko pagrindiniais atramos taškais:
- 5.20, informacijos saugumo aptarimas tiekėjų susitarimuose.
- 5.21, informacijos saugumo valdymas IRT tiekimo grandinėje.
- 5.23, informacijos saugumas naudojant debesijos paslaugas.
Tai nėra atskiri kontrolinio sąrašo punktai. Jie sudaro matricos pagrindą.
| Matricos klausimas | ISO/IEC 27001:2022 A priedo atramos taškas | Praktinė reikšmė |
|---|---|---|
| Kam tiekėjas turi įsipareigoti sutartyje? | 5.20 | Saugumas, konfidencialumas, audito teisės, pranešimas apie incidentus, subranga ir nutraukimas turi būti vykdytini. |
| Kaip kontroliuojame paslaugų teikėjo paslaugų teikėją? | 5.21 | IRT tiekimo grandinės ir žemesnių grandžių priklausomybių rizika turi būti identifikuojama, vertinama, stebima ir perduodama toliau. |
| Kaip valdome debesijos paslaugos pasirinkimą, naudojimą ir pasitraukimą? | 5.23 | Debesijos atsakomybės, konfigūracijos, įrodymai, žurnalai, duomenų vieta ir pasitraukimas turi būti valdomi per visą gyvavimo ciklą. |
Pagalbiniai standartai gali sustiprinti matricą. ISO/IEC 27017 padeda taikyti debesijai būdingas saugumo praktikas. ISO/IEC 27018 ir ISO/IEC 27701 palaiko PII ir privatumo valdyseną. ISO/IEC 27005 palaiko rizikos vertinimą. ISO 22301 palaiko veiklos tęstinumą ir atsparumą. ISO/IEC 27035 palaiko incidentų valdymą. ISO/IEC 20000-1 gali padėti, kai debesijos paslaugos yra valdomos paslaugų teikimo dalis.
Mažiausia gyvybinga bendros atsakomybės matrica
Brandžios matricos nereikia pradėti nuo 200 eilučių. Ji pradedama nuo svarbiausių debesijos paslaugų.
SaaS, finansinių technologijų ar reguliuojamai MVĮ Clarysec paprastai pradeda nuo:
- Klientams skirtos produkcinės debesijos aplinkos.
- Tapatybės teikėjo.
- Valdomos duomenų bazės arba saugyklos paslaugos.
- Žurnalų valdymo, stebėsenos ir SIEM platformos.
- Mokėjimų, KYC, analitikos arba klientų aptarnavimo SaaS.
- Atsarginių kopijų ir atkūrimo po katastrofos paslaugos.
- Valdomų paslaugų teikėjo arba valdomo saugumo paslaugų teikėjo.
- Subtvarkytojų, kurie pasiekia, saugo ar tvarko klientų duomenis.
Pirmojoje matricoje turi būti šie stulpeliai.
| Stulpelis | Kodėl tai svarbu |
|---|---|
| Paslauga arba kontrolės sritis | Identifikuoja tikslią debesijos paslaugą, SaaS produktą ar į taikymo sritį patenkantį subprocesą. |
| Duomenys ir verslo funkcija | Susieja paslaugą su asmens duomenimis, kritinėmis paslaugomis, finansinėmis funkcijomis ar esminėmis operacijomis. |
| Atsakomybės savininkas | Apibrėžia paslaugų teikėją, klientą, bendrą atsakomybę, subtvarkytoją arba vidinės kontrolės savininką. |
| Kliento įsipareigojimas | Parodo, ką jūsų organizacija turi sukonfigūruoti, patvirtinti, stebėti ar pagrįsti įrodymais. |
| Paslaugų teikėjo įsipareigojimas | Parodo, ką debesijos arba SaaS paslaugų teikėjas turi pateikti pagal sutartį, patikinimą ar platformos galimybes. |
| Priklausomybė nuo subtvarkytojo | Atseka žemesnių grandžių teikėjus, kurie gali paveikti saugumą, privatumą, tęstinumą ar duomenų buvimo vietą. |
| ISO/IEC 27001:2022 A priedo kontrolės priemonė | Susieja eilutę su Taikytinumo pareiškimu ir kontrolės priemonės pagrindimu. |
| NIS2, DORA, GDPR, NIST CSF arba COBIT 2019 susiejimas | Parodo kelių atitikties sričių aktualumą nedubliuojant kontrolės priemonių. |
| Įrodymai | Apibrėžia auditui tinkamus įrodymus. |
| Peržiūros dažnumas | Apibrėžia stebėsenos periodiškumą, ypač kritiniams arba didelės rizikos tiekėjams. |
Praktinė žurnalų valdymo eilutė galėtų atrodyti taip.
| Paslauga arba kontrolės sritis | Atsakomybės savininkas | Kliento įsipareigojimas | Paslaugų teikėjo įsipareigojimas | Priklausomybė nuo subtvarkytojo | Kontrolės priemonės ir sistemos | Įrodymai |
|---|---|---|---|---|---|---|
| Produkcinės debesijos audito žurnalai | Bendra atsakomybė | Įjungti audito žurnalus, apibrėžti saugojimo terminą, riboti prieigą, peržiūrėti įspėjimus ir testuoti paiešką | Suteikti žurnalų funkcionalumą, platformos įvykius, saugojimo parinktis ir prieinamumo įsipareigojimus | Žurnalų valdymo arba SIEM tiekėjas, jei žurnalai eksportuojami | ISO/IEC 27001:2022 A priedas 5.20, 5.23, 8.15, 8.16; NIS2 Article 21; DORA Articles 6, 8, 10, 17; NIST CSF 2.0 Detect ir Govern rezultatai | Žurnalų valdymo standartas, debesijos konfigūracijos eksportas, žurnalų pavyzdžiai, SIEM įspėjimai, prieigos peržiūra, paslaugų teikėjo sutarties nuostata, saugojimo įrodymai |
Ši eilutė nėra vien dokumentacija. Ji nurodo saugumo komandai, ką konfigūruoti, pirkimų funkcijai – kokią sutartinę formuluotę tikrinti, privatumo funkcijai – kokį duomenų srautą registruoti, o auditoriams – kokių įrodymų prašyti.
Politikos pagrindas: kaip matricą paversti vykdytinu reikalavimu
Debesijos bendros atsakomybės matrica be politikos pagrindo yra tik skaičiuoklė. Clarysec politikos padaro ją vykdytiną.
MVĮ atveju Debesijos paslaugų naudojimo politika – MVĮ Debesijos paslaugų naudojimo politika – MVĮ, skyrius „Valdysenos reikalavimai“, 5.3 nuostata reikalauja:
„IT paslaugų teikėjas arba generalinis vadovas turi tvarkyti Debesijos paslaugų registrą. Jame turi būti registruojama:“
Ta pati MVĮ politika, 5.2.3 nuostata, susieja debesijos valdyseną su privatumo ir vietos rizika:
„Duomenų buvimo vieta ir privatumo praktikos atitinka taikomus teisinius reikalavimus (pvz., GDPR)“
Įmonių aplinkose Debesijos paslaugų naudojimo politika Debesijos paslaugų naudojimo politika, skyrius „Valdysenos reikalavimai“, 5.1 nuostata nurodo:
„Organizacija turi palaikyti centralizuotą Debesijos paslaugų registrą, už kurį atsakingas CISO, ir kuriame pateikiama:“
5.4 nuostata debesijos atsakomybes paverčia sutartyje vykdytinomis:
„Visose CSP (Cloud Service Provider) sutartyse turi būti vykdytinos nuostatos dėl:“
Tiekėjų valdysena išplečia matricą už tiesioginio paslaugų teikėjo ribų. Trečiųjų šalių ir tiekėjų saugumo politika – MVĮ Trečiųjų šalių ir tiekėjų saugumo politika – MVĮ, skyrius „Valdysenos reikalavimai“, 5.3.5 nuostata reikalauja:
„Apribojimai dėl tolesnės subrangos be patvirtinimo“
Ta pati MVĮ tiekėjų politika, skyrius „Politikos įgyvendinimo reikalavimai“, 6.3.1 nuostata prideda periodinę peržiūrą:
„Kritiniai arba didelės rizikos tiekėjai turi būti peržiūrimi bent kartą per metus. Peržiūra turi patikrinti:“
Įmonių lygiu Trečiųjų šalių ir tiekėjų saugumo politika Trečiųjų šalių ir tiekėjų saugumo politika, skyrius „Valdysenos reikalavimai“, 5.3 nuostata nurodo:
„Sutartyse su tiekėjais turi būti įtraukta:“
Asmens duomenims Duomenų apsaugos ir privatumo politika Duomenų apsaugos ir privatumo politika, skyrius „Įgyvendinimas ir atitiktis“, 8.5.1 nuostata reikalauja:
„Sutartyse su duomenų tvarkytojais turi būti įtraukta:“
Priklausomybių matomumui Tiekėjų priklausomybės rizikos valdymo politika Tiekėjų priklausomybės rizikos valdymo politika, 6.5.4 nuostata reikalauja:
„Pasitelkti santykius su tiekėju, siekiant gauti atnaujinimus apie subrangovus arba tiekimo grandinės priklausomybes vienu lygiu žemiau, kai jos galėtų mus paveikti (pavyzdžiui, jei kritinis programinės įrangos tiekėjas labai priklauso nuo trečiosios šalies bibliotekos, tai turi būti užregistruota).“
Žurnalams Žurnalų valdymo ir stebėsenos politika – MVĮ Žurnalų valdymo ir stebėsenos politika – MVĮ, skyrius „Valdysenos reikalavimai“, 5.5.1.3 nuostata pateikia konkretų sutartinį reikalavimą:
„Sutartyse turi būti reikalaujama, kad paslaugų teikėjai saugotų žurnalus bent 12 mėnesių ir suteiktų prieigą paprašius“
Kartu šios politikos paverčia matricą privalomu valdysenos įrašu, kuris palaiko tiekėjų tvirtinimą, debesijos įtraukimą, privatumo atskaitomybę, metinę peržiūrą ir audito įrodymus.
Matricos susiejimas su ISO/IEC 27001:2022, NIS2, DORA ir GDPR
Klasikinė klaida – kurti keturias atskiras atitikties darbaknyges. Viena kontrolės priemonė gali tenkinti kelis įpareigojimus, jei atsakomybė ir įrodymai yra atsekami.
| Kontrolės sritis | ISO/IEC 27001:2022 A priedas | Paslaugų teikėjo įrodymai | Kliento įrodymai | Susiejimas su kitomis sistemomis |
|---|---|---|---|---|
| Tiekėjų susitarimai | 5.20 | Sutartis, saugumo priedas, DPA, patikinimo ataskaita, įsipareigojimas pranešti apie incidentus | Tiekėjo rizikos vertinimas, sutarties peržiūros kontrolinis sąrašas, patvirtinimo įrašas | NIS2 Article 21; DORA Article 30; GDPR Article 28; NIST CSF 2.0 GV.SC |
| IRT tiekimo grandinė | 5.21 | Subtvarkytojų sąrašas, subrangos sąlygos, žemesnių grandžių teikėjų patikinimas, pranešimai apie pakeitimus | Priklausomybių registras, koncentracijos peržiūra, metinė tiekėjo peržiūra | NIS2 Article 21; DORA Articles 28 and 29; COBIT 2019 tiekėjų valdysenos tikslai |
| Debesijos paslaugų naudojimas | 5.23 | Paslaugos dokumentacija, duomenų vietos parinktys, eksportavimo įrankiai, ištrynimo palaikymas | Debesijos registras, konfigūravimo standartai, pasitraukimo planas, paslaugos peržiūra | DORA Articles 6, 8, 28 and 30; GDPR Articles 5, 28 and 32 |
| Tapatybė ir prieiga | 5.15, 5.16, 5.18 | IAM galimybės, MFA parinktys, administratoriaus kontrolės priemonės, platformos audito įvykiai | MFA taikymas, mažiausių privilegijų principas, prieigos peržiūros, priėmimo, pareigų keitimo ir išėjimo įrašai | NIS2 Article 21(2)(i); DORA Article 9; GDPR Article 32 |
| Žurnalų valdymas ir stebėsena | 8.15, 8.16 | Platformos žurnalai, audito API, saugojimo parinktys, paslaugos pranešimai | SIEM duomenų įvedimo įrodymai, įspėjimų peržiūros, žurnalų saugojimo nustatymai, prieigos apribojimai | NIS2 Article 21; DORA Articles 10 and 17; GDPR Article 32 |
| Incidentų valdymas | 5.24, 5.25, 5.26, 5.27 | Paslaugų teikėjo pranešimai apie incidentus, pagalbos užklausos, pagrindinės priežasties ataskaitos | Incidentų veiksmų planas, triažo įrodymai, reguliuotojo vertinimas, įgyta patirtis | NIS2 Article 23; DORA Articles 17, 18 and 19; GDPR Articles 33 and 34 |
| Tęstinumas ir pasitraukimas | 5.29, 5.30, 5.23 | Prieinamumo įsipareigojimai, eksportavimo įrankiai, sunaikinimo sertifikatas, atkūrimo palaikymas | Atsarginių kopijų testai, atkūrimo pratybos, pasitraukimo testas, prieigos teisių atšaukimas | DORA Articles 11, 24, 28 and 30; NIS2 Article 21; GDPR Article 28 |
ISO/IEC 27001:2022 suteikia ISVS variklį: kontekstą, suinteresuotąsias šalis, taikymo sritį, lyderystę, rizikos tvarkymą, tikslus, operacinę kontrolę, veiklos vertinimą ir tobulinimą. A priedas suteikia praktinę kontrolės priemonių struktūrą.
NIS2 Article 21 natūraliai susiejamas su ta pačia matrica per tiekimo grandinės saugumą, incidentų valdymą, tęstinumą, prieigos kontrolę, turto valdymą ir saugų įsigijimą. Article 20 daro matricą aktualią valdybai, nes valdymo organai turi patvirtinti ir prižiūrėti kibernetinio saugumo rizikos valdymo priemones.
DORA paverčia matricą IRT trečiųjų šalių rizikos įrankiu. Articles 5, 6 and 8 reikalauja valdysenos, dokumentuoto IRT rizikos valdymo ir turto, funkcijų bei priklausomybių identifikavimo. Articles 17 to 19 reikalauja incidentų aptikimo, klasifikavimo, eskalavimo, komunikacijos ir pranešimo. Articles 28 to 30 reikalauja trečiųjų šalių rizikos valdymo, koncentracijos rizikos analizės, sutartinių nuostatų, subrangos kontrolės priemonių, audito teisių, nutraukimo teisių ir pasitraukimo strategijų.
GDPR prideda asmens duomenų perspektyvą. Kiekviena debesijos paslaugos eilutė turi nurodyti, ar tvarkomi asmens duomenys, ar paslaugų teikėjas yra duomenų tvarkytojas arba subtvarkytojas, ar svarbi duomenų vieta ir kokie sutarties arba DPA įrodymai yra.
NIST CSF 2.0 padeda tą pačią matricą komunikuoti rezultatų kalba. GOVERN funkcija apima organizacinį kontekstą, teisinius ir reglamentavimo reikalavimus, priklausomybes, rizikos valdymą, vaidmenis, politikas ir priežiūrą. GV.SC rezultatai ypač naudingi tiekėjų kibernetinei rizikai, įskaitant tiekėjų vaidmenis, kritiškumą, sutartinius reikalavimus, deramą rūpestingumą, stebėseną, incidentų koordinavimą ir nutraukimo planavimą.
COBIT 2019 prideda patikinimo ir valdysenos perspektyvą. Jis klausia, ar atskaitomybė, valdymo praktikos, savininkystė, stebėsena ir problemų šalinimas yra pakartojami ir pagrįsti įrodymais.
Matricos kūrimas nuo registro iki įrodymų
Įsivaizduokite SaaS įmonę, naudojančią didžiojo debesijos paslaugų teikėjo IaaS platformą, valdomą duomenų bazę, trečiosios šalies tapatybės teikėją, klientų aptarnavimo SaaS platformą ir išorinį SIEM. Įgyvendinimo eiga yra tiesioginė.
1 žingsnis: pradėkite nuo Debesijos paslaugų registro
Naudokite Debesijos paslaugų naudojimo politiką arba Debesijos paslaugų naudojimo politiką – MVĮ kaip paleidiklį. Užregistruokite kiekvieną debesijos paslaugą, savininką, tikslą, duomenų kategorijas, vietą, verslo funkciją, tiekėjo lygį, sutarties savininką ir peržiūros datą.
Jei paslauga saugo klientų įrašus, autentifikavimo žurnalus ar pagalbos užklausas, pažymėkite ją kaip aktualią privatumui. Jei ji palaiko produkcinės aplinkos prieinamumą, pažymėkite ją kaip operaciškai kritinę. Jei ji palaiko finansų kliento kritinę arba svarbią funkciją, pažymėkite ją kaip aktualią DORA.
2 žingsnis: pridėkite bendros atsakomybės sritis
Kiekvienai paslaugai apibrėžkite atsakomybes pagrindinėse srityse.
| Sritis | Tipinė paslaugų teikėjo atsakomybė | Tipinė kliento atsakomybė | Tipinis klausimas dėl subtvarkytojo |
|---|---|---|---|
| Fizinis ir infrastruktūros saugumas | Patalpos, aparatinė įranga, aplinkos kontrolės priemonės, platformos atsparumas | Peržiūrėti patikinimo ataskaitas ir sutartinius įsipareigojimus | Ar paslaugų teikėjas remiasi duomenų centru, CDN arba prieglobos subtvarkytoju? |
| Tapatybė ir prieiga | Platformos IAM galimybės, administratoriaus saugumo funkcijos, federacijos palaikymas | MFA, vaidmenų projektavimas, mažiausių privilegijų principas, priėmimo, pareigų keitimo ir išėjimo peržiūros | Ar tapatybės tarpininkas arba pagalbos tiekėjas pasiekia paskyras? |
| Duomenų apsauga | Šifravimo parinktys, duomenų vietos parinktys, atsarginių kopijų funkcijos | Klasifikavimas, šifravimo konfigūracija, saugojimas, teisinis pagrindas | Ar kuris nors subtvarkytojas saugo arba pasiekia asmens duomenis? |
| Žurnalų valdymas ir stebėsena | Įvykių generavimas, audito API, platformos telemetrija | Įjungti žurnalus, eksportuoti į SIEM, peržiūrėti įspėjimus, saugoti įrodymus | Ar SIEM arba MDR teikėjas tvarko žurnalus, kuriuose yra asmens duomenų? |
| Reagavimas į incidentus | Paslaugų teikėjo aptikimas, platformos pranešimai apie incidentus, pagalbos eskalavimas | Vidinis triažas, pranešimai reguliuotojams ir klientams, įrodymų išsaugojimas | Ar žemesnės grandies incidentai gali atidėti pranešimą arba pagrindinės priežasties analizę? |
| Tęstinumas ir pasitraukimas | Platformos prieinamumo įsipareigojimai, eksportavimo įrankiai, ištrynimo palaikymas | Atkūrimo tikslai, atsarginių kopijų testavimas, pasitraukimo planas, duomenų grąžinimas arba sunaikinimas | Ar yra atkūrimo apribojimų dėl subrangos paslaugų ar vietų? |
3 žingsnis: susiekite kontrolės priemones su rizika ir Taikytinumo pareiškimu
Zenith Blueprint, Rizikos valdymo fazė, Step 13, paaiškina atsekamumo reikalavimą:
„Kryžmiškai susiekite reglamentus: jei tam tikros kontrolės priemonės įgyvendinamos konkrečiai tam, kad būtų laikomasi GDPR, NIS2 ar DORA, tai galite pažymėti Rizikų registre (kaip rizikos poveikio pagrindimo dalį) arba SoA pastabose.“
Pavyzdžiui, rizika „neteisėta prieiga prie klientų produkcinių duomenų dėl debesijos konfigūracijos klaidos“ gali būti susieta su prieigos kontrole, debesijos naudojimu, žurnalų valdymu, kriptografija, pažeidžiamumų valdymu ir tiekėjų susitarimais. SoA gali nurodyti ISO/IEC 27001:2022 A priedo 5.15, 5.16, 5.20, 5.23, 8.8, 8.15, 8.16 ir 8.24 kontrolės priemones, kartu su pastabomis dėl GDPR Article 32, NIS2 Article 21 ir DORA IRT rizikos valdymo, kai taikoma.
4 žingsnis: pridėkite įrodymus dar prieš audito sezoną
Įrodymai turi būti suplanuoti matricoje, o ne renkami panikoje.
| Matricos eilutė | Saugotini įrodymai |
|---|---|
| Debesijos paslaugų teikėjo deramas rūpestingumas | Tiekėjo vertinimas, saugumo klausimynas, patikinimo ataskaita, sertifikatai, rizikos lygis, patvirtinimo įrašas |
| Sutartiniai saugumo įsipareigojimai | MSA, DPA, saugumo priedas, audito teisės, subrangos nuostata, pranešimo apie incidentus nuostata, duomenų vietos sąlygos |
| Kliento konfigūracijos atsakomybė | Debesijos konfigūracijos eksportas, IAM politika, MFA ataskaita, šifravimo nustatymai, tinklo taisyklės, pakeitimų užklausos |
| Žurnalų valdymas ir stebėsena | Žurnalų saugojimo nustatymai, audito žurnalų pavyzdžiai, SIEM duomenų įvedimo įrodymas, įspėjimų peržiūros įrašai, eskalavimo užklausos |
| Subtvarkytojų atsekamumas | Paslaugų teikėjo subtvarkytojų sąrašas, patvirtinimo įrašas, duomenų srautų žemėlapis, metinės peržiūros pastabos, pranešimai apie pakeitimus |
| Pasitraukimas ir atkūrimas | Atsarginių kopijų testavimo rezultatai, duomenų eksporto testas, sunaikinimo sertifikatas, pasitraukimo planas, atkūrimo pratybų ataskaita |
Įrodymų sąrašas atsakomybę paverčia audito įrodymais. Jis taip pat padeda komercinėms komandoms greičiau atsakyti į įmonių deramą patikrinimą, nes jos gali parodyti ne tik sertifikatus, bet ir kontrolės priemonių savininkystę bei veikimo įrodymus.
Subtvarkytojai: akloji daugumos matricų zona
Subtvarkytojai yra vieta, kur bendra atsakomybė tampa realia tiekimo grandinės rizika.
SaaS paslaugų teikėjas pagal GDPR gali būti jūsų duomenų tvarkytojas. Tas teikėjas gali remtis debesijos prieglobos teikėju, CDN, analitikos paslauga, pagalbos platforma, el. pašto siuntimo paslauga, valdoma duomenų baze, stebimumo teikėju ir mokėjimų tvarkytoju. Kai kurie gali pasiekti asmens duomenis. Kai kurie gali palaikyti kritinį paslaugos teikimą tiesiogiai nematydami duomenų. Kai kurie gali būti už ES ribų. Kai kuriuos galima pakeisti. Kiti gali sukurti koncentracijos riziką.
DORA Article 29 reikalauja koncentracijos rizikos vertinimo kritinėms arba svarbioms IRT paslaugoms, įskaitant pakeičiamumą, kelis susitarimus su tais pačiais arba susijusiais paslaugų teikėjais, subrangos grandines, trečiosiose šalyse veikiančius subrangovus, nemokumo teisę, duomenų atkūrimo apribojimus ir Sąjungos duomenų apsaugos vykdytinumą. DORA Article 30 reikalauja sutartinių nuostatų dėl subrangos sąlygų, vietų, duomenų tvarkymo ir saugojimo, prieigos ir atkūrimo, pagalbos incidentų atveju, bendradarbiavimo su institucijomis, audito teisių, nutraukimo ir pasitraukimo.
NIS2 Article 21 panašiai reikalauja tiekimo grandinės saugumo tiesioginiams tiekėjams ir paslaugų teikėjams, taip pat atsižvelgti į tiekėjui būdingus pažeidžiamumus, tiekėjo kibernetinio saugumo praktikas ir saugaus kūrimo procedūras.
Todėl Clarysec subtvarkytojų susiejimą traktuoja kaip privalomą tiekėjų valdysenos plėtinį, o ne tik privatumo sąrašą. Subtvarkytojų registras turi parodyti, kuris tiekėjas naudoja subtvarkytoją, nuo kurios paslaugos jis priklauso, ar tvarkomi asmens duomenys, ar jis palaiko kritinę funkciją, tvarkymo regioną, kai aktualu, toliau perduodamas prievoles, patvirtinimo arba prieštaravimo teises, prieinamą patikinimą, stebėsenos metodą ir pasitraukimo galimybę.
Zenith Blueprint, etapas „Controls in Action“, Step 23, nurodo:
„Kiekvienam kritiniam tiekėjui nustatykite, ar jis naudoja subrangovus (subtvarkytojus), kurie gali pasiekti jūsų duomenis arba sistemas. Dokumentuokite, kaip jūsų informacijos saugumo reikalavimai perduodami šioms šalims – per jūsų tiekėjo sutarties sąlygas arba per jūsų pačių tiesiogines nuostatas.“
Tai yra įrodymų lygis, kurio auditoriai tikisi klausdami, ar debesijos atsakomybės kontroliuojamos žemyn tiekimo grandinėje.
Kaip auditoriai testuoja tą pačią matricą
Stipri debesijos bendros atsakomybės matrica atlaiko kelis audito stilius, nes ji kuriama apie savininkystę, vykdytinumą ir įrodymus.
| Audito perspektyva | Ką auditorius testuos | Kokių įrodymų tikėsis |
|---|---|---|
| ISO/IEC 27001:2022 auditorius | ISVS taikymo sritis, suinteresuotosios šalys, rizikos vertinimas, SoA taikytinumas, tiekėjų kontrolės priemonės, debesijos naudojimas, operaciniai įrodymai ir nuolatinis tobulinimas | ISVS taikymo sritis, rizikų registras, SoA, tiekėjų registras, debesijos registras, sutartys, peržiūros įrašai, vidaus audito išvados, korekciniai veiksmai |
| NIS2 pasirengimo vertintojas | Vadovybės patvirtinimas, Article 21 kontrolės priemonių aprėptis, tiekimo grandinės saugumas, incidentų valdymas, tęstinumas, prieiga, turto valdymas ir veiksmingumo vertinimas | Valdybos ataskaitos, politikų patvirtinimai, tiekėjų rizikos peržiūros, incidentų veiksmų planai, tęstinumo testai, MFA įrodymai, pažeidžiamumų ir žurnalų įrašai |
| DORA vertintojas | IRT valdysena, IRT rizikos sistema, turto ir priklausomybių apskaita, kritiniai IRT trečiųjų šalių susitarimai, sutartinės nuostatos, koncentracijos rizika, testavimas ir pasitraukimo strategija | IRT rizikos sistema, IRT paslaugų registras, kritiškumo vertinimas, sutartys, audito teisės, incidentų įrašai, atsparumo testai, pasitraukimo testai, subrangos analizė |
| GDPR peržiūrėtojas | Duomenų valdytojo ir duomenų tvarkytojo vaidmenys, duomenų tvarkymo tikslai, vientisumas ir konfidencialumas, pasirengimas pažeidimui, duomenų tvarkytojų sutartys ir subtvarkytojų skaidrumas | Tvarkymo veiklos įrašai, DPA, subtvarkytojų sąrašas, duomenų srautų žemėlapis, saugumo priemonės, pažeidimo procedūra, saugojimo ir ištrynimo įrodymai |
| NIST CSF vertintojas | GOVERN rezultatai, tiekėjų kibernetinė rizika, turto apskaita, prieigos kontrolė, duomenų saugumas, stebėsena, reagavimas ir atkūrimas | Esami ir tiksliniai profiliai, tiekėjų rizikos procesas, turto apskaita, prieigos ataskaitos, stebėsenos įrašai, incidentų pratybos, atkūrimo įrodymai |
| COBIT 2019 arba ISACA auditorius | Valdysenos atskaitomybė, valdymo praktikos, kontrolės priemonių savininkystė, veiklos stebėsena, problemų valdymas ir patikinimo atsekamumas | RACI, valdysenos posėdžių protokolai, politikų išimtys, KPI, tiekėjų rezultatų kortelės, problemų žurnalai, vadovybės peržiūros rezultatai |
Matrica nėra galutinis tikslas. Tai žemėlapis, kurį auditoriai naudoja testuodami, ar valdysenos sistema yra reali.
ISO auditorius gali pasirinkti didelio poveikio debesijos prieigos riziką ir atsekti ją nuo rizikų registro iki SoA, tada iki prieigos peržiūrų, MFA įrodymų ir stebėsenos įspėjimų. DORA vertintojas gali pasirinkti kritinį IRT teikėją ir paprašyti pasitraukimo testo, subrangos analizės ir sutartinių audito teisių. GDPR peržiūrėtojas gali sutelkti dėmesį į ištrynimą, duomenų buvimo vietą, pranešimą apie pažeidimą ir subtvarkytojų skaidrumą.
Dažniausi nesėkmių modeliai
Dažniausios bendros atsakomybės nesėkmės nėra išskirtinės.
Pirma, organizacijos remiasi paslaugų teikėjų patikinimo ataskaitomis, nesusiedamos jų su kliento atsakomybėmis. Debesijos paslaugų teikėjas gali įrodyti fizinį saugumą, infrastruktūros atsparumą ir platformos kontrolės priemones, bet ne tai, ar jūsų saugyklos konteineris buvo privatus, ar IAM vaidmenys atitiko mažiausių privilegijų principą, ar žurnalai buvo įjungti.
Antra, sutartyse būna bendro pobūdžio saugumo formuluotės, bet nėra incidentų terminų, žurnalų prieigos teisių, audito teisių, subrangos apribojimų, duomenų grąžinimo nuostatų ar pasitraukimo palaikymo. Zenith Blueprint, etapas „Controls in Action“, Step 23, išskiria tipines tiekėjų susitarimų sritis, tokias kaip konfidencialumas, prieigos kontrolė, techninės ir organizacinės priemonės, incidentų terminai, teisė atlikti auditą, subrangovų kontrolės priemonės ir sutarties pabaigos nuostatos.
Trečia, subtvarkytojai nurodomi privatumo tikslais, bet nesusiejami su saugumu, tęstinumu ar koncentracijos rizika. Žemesnės grandies stebimumo arba pagalbos teikėjas gali niekada nepatekti į rizikų registrą, nors jo paslaugos sutrikimas ar pažeidimas galėtų paveikti klientams teikiamą paslaugą.
Ketvirta, SoA nurodo, kad kontrolės priemonė taikoma, tačiau niekas negali pateikti veikimo įrodymų. Debesijos žurnalų valdymas gali būti pažymėtas kaip įgyvendintas, bet organizacija negali įrodyti saugojimo nustatymų, prieigos peržiūrų, įspėjimų tvarkymo ar paslaugų teikėjo žurnalų prieigos įsipareigojimų.
Penkta, reagavimo į incidentus planai neatspindi priklausomybės nuo paslaugų teikėjo. Jei paslaugų teikėjas praneša apie platformos incidentą, kas vertina poveikį klientams? Kas nustato, ar reikia pranešti pagal NIS2, DORA ar GDPR? Kas susisiekia su paveiktais klientais? O jei pagrindinė priežastis yra pas subtvarkytoją?
Vadovybės atskaitomybė: kodėl valdybai tai turi rūpėti
NIS2 Article 20 reikalauja, kad valdymo organai patvirtintų kibernetinio saugumo rizikos valdymo priemones, prižiūrėtų jų įgyvendinimą ir gautų mokymus. DORA Article 5 reikalauja, kad valdymo organas apibrėžtų, patvirtintų, prižiūrėtų ir būtų atsakingas už IRT rizikos valdymo priemones, įskaitant IRT trečiųjų šalių politikas, tęstinumo ir atkūrimo planus, audito planus, mokymus ir pranešimo kanalus.
Tai keičia matricos paskirtį. Ji nebėra tik saugumo darbo lapas. Ji tampa įrodymu, kad vadovybė žino:
- Kurios debesijos paslaugos palaiko kritines operacijas.
- Kurios trečiosios šalys ir subtvarkytojai yra reikšmingi.
- Kurie įsipareigojimai taikomi pagal klientų sutartis, GDPR, NIS2 ir DORA.
- Kurios atsakomybės lieka organizacijai.
- Kurie paslaugų teikėjo įsipareigojimai yra sutartyje vykdytini.
- Kurioms spragoms reikia finansavimo, taisomųjų veiksmų arba rizikos priėmimo.
MVĮ svarbus proporcingumas. Mažesniam subjektui nereikia sunkiasvorės biurokratijos, tačiau jam vis tiek reikia dokumentacijos, stebėsenos, atsparių sistemų, IRT rizikos šaltinių aptikimo, pagrindinių trečiųjų šalių priklausomybių identifikavimo, tęstinumo priemonių, testavimo, įgytos patirties ir periodinės peržiūros, kai tai patenka į taikymo sritį.
Matrica yra vienas efektyviausių proporcingų įrankių, nes ji konsoliduoja įpareigojimus, o ne juos daugina.
30 dienų sprintas, kad jūsų debesijos modelis būtų tinkamas auditui
Jei negalite atsakyti, kam priklauso kiekviena debesijos kontrolės priemonė, kokie įrodymai ją patvirtina ir kuris subtvarkytojas galėtų ją paveikti, jūsų bendros atsakomybės modelis vis dar yra schema, o ne valdysenos artefaktas.
Praktinis 30 dienų sprintas atrodo taip:
- Sukurkite arba atnaujinkite Debesijos paslaugų registrą naudodami Debesijos paslaugų naudojimo politiką arba Debesijos paslaugų naudojimo politiką – MVĮ.
- Identifikuokite kritines paslaugas, asmens duomenų tvarkymą, klientams skirtas sistemas ir aktualumą DORA arba NIS2.
- Sukurkite pirmąją matricą pagal ISO/IEC 27001:2022 A priedo kontrolės priemones 5.20, 5.21 ir 5.23, naudodami Zenith Controls.
- Susiekite kiekvieną eilutę su rizikų registru ir Taikytinumo pareiškimu, naudodami Zenith Blueprint Step 13.
- Patikrinkite tiekėjų ir duomenų tvarkytojų nuostatas naudodami Trečiųjų šalių ir tiekėjų saugumo politiką, Trečiųjų šalių ir tiekėjų saugumo politiką – MVĮ ir Duomenų apsaugos ir privatumo politiką.
- Pridėkite žurnalų saugojimą, incidentų eskalavimą, subtvarkytojų patvirtinimą, audito teises ir pasitraukimo įrodymus.
- Peržiūrėkite kritinius tiekėjus kasmet ir po reikšmingų pakeitimų, incidentų, naujų subtvarkytojų ar audito išvadų.
Tikslas paprastas. Kai klientas, auditorius, reguliuotojas ar valdyba klausia „kam priklauso ši kontrolės priemonė?“, jūs neieškote sutarčių, užklausų ir aplankų. Atidarote matricą, parodote savininką, parodote nuostatą, parodote įrodymus ir parodote pėdsaką žemyn tiekimo grandinėje.
Clarysec gali padėti paversti debesijos paslaugų teikėjų patikinimo paketus į integruotą bendros atsakomybės matricą ISO/IEC 27001:2022 auditams, NIS2 pasirengimui, DORA IRT trečiųjų šalių rizikai, GDPR atskaitomybei ir įmonių klientų deramiems patikrinimams.
Pradėkite nuo registro. Sukurkite matricą. Pridėkite įrodymus. Tada naudokite ją kaip valdybai tinkamą įrodymą, kad debesijos rizika nėra perduota išorėn – ji valdoma.
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
