Debesijos audito įrodymai ISO 27001, NIS2 ir DORA kontekste

Marija, sparčiai augančios finansinės analitikos įmonės CISO, turėjo šešias savaites iki trijų sutampančių terminų. Jos ISO 27001:2022 priežiūros auditas jau buvo suplanuotas. NIS2, priskyrusi įmonę svarbiam subjektui, pakėlė vadovybės atskaitomybę į naują lygmenį. DORA turėjo patikrinti, ar jos fintech operacijos gali pagrįsti skaitmeninį operacinį atsparumą. Tuo pačiu metu stambus verslo klientas stabdė sutartį, kol jos komanda nepraeis išsamios saugumo patikinimo peržiūros.

Įmonė nebuvo nesaugi. Ji vykdė produkcinius darbo krūvius AWS ir Azure, naudojo Microsoft 365 ir kelias kritines SaaS platformas, taikė MFA, kūrė atsargines duomenų kopijas, vykdė pažeidžiamumų skenavimą ir rinko debesijos žurnalus. Problema buvo įrodymai.

Įrodymai buvo išsibarstę po Slack ekrano kopijas, kūrėjų wiki puslapius, debesijos konsolių eksportus, pirkimų aplankus, teisines sutartis ir platformų savininkų žodinius patikinimus. Kai auditorius paklausdavo: „Parodykite, kaip kontroliuojate savo debesijos aplinką“, nuorodos į debesijos paslaugų teikėjo atitikties puslapį nepakakdavo. Teikėjo sertifikatai įrodė teikėjo kontrolės priemones. Jie neįrodė Marijos atsakomybės dalies bendros atsakomybės modelyje.

Būtent čia žlunga daugelis debesijos saugumo audito įrodymų programų. Ne todėl, kad nėra kontrolės priemonių, o todėl, kad organizacija negali struktūruotai ir atsekamai įrodyti, kurios atsakomybės priklauso teikėjui, kurios – klientui, kaip sukonfigūruotos SaaS ir IaaS kontrolės priemonės, kaip įgyvendinami tiekėjų įsipareigojimai ir kaip įrodymai saugomi auditoriams, priežiūros institucijoms ir klientams.

Debesijos atitiktis nebėra techninis priedas. SaaS teikėjui pagal NIS2, finansų sektoriaus subjektui pagal DORA arba bet kuriai ISO 27001:2022 organizacijai, naudojančiai IaaS, PaaS ir SaaS, debesijos valdysena yra ISVS taikymo srities, rizikos valdymo plano, tiekėjų gyvavimo ciklo, incidentų valdymo proceso, privatumo atskaitomybės ir vadovybės peržiūros dalis.

Praktinis tikslas paprastas: sukurti vieną priežiūros institucijoms tinkamą debesijos įrodymų architektūrą, kuri atsakytų į ISO 27001:2022, NIS2, DORA, GDPR, klientų patikinimo ir vidaus audito klausimus, nereikalaujant kiekvienai sistemai iš naujo rengti įrodymų.

Debesija visada patenka į taikymo sritį, net kai infrastruktūra perduota išorės teikėjui

Pirmoji audito klaida – manyti, kad išorės teikėjui perduota infrastruktūra yra už ISVS ribų. Taip nėra. Išorinių paslaugų naudojimas pakeičia kontrolės ribas, bet nepanaikina atskaitomybės.

ISO/IEC 27001:2022 reikalauja, kad organizacija apibrėžtų savo kontekstą, suinteresuotąsias šalis, ISVS taikymo sritį, sąsajas, priklausomybes ir procesus. Debesijai pirmenybę teikiančiame versle tapatybės teikėjas, debesijos prieglobos paskyra, CRM, el. pašto platforma, duomenų saugykla, CI/CD konvejeris, užklausų valdymo priemonė ir atsarginių kopijų paslauga dažnai yra pagrindinė verslo infrastruktūra.

Clarysec Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint šį aspektą pabrėžia ISVS pagrindų ir vadovybės įsipareigojimo etape, 2 žingsnyje „Suinteresuotųjų šalių poreikiai ir ISVS taikymo sritis“:

„Jei savo IT infrastruktūrą perduodate debesijos paslaugų teikėjui, tai jos nepašalina iš taikymo srities; priešingai, į taikymo sritį įtraukiate šio santykio valdymą ir debesijos turtą, nes jūsų duomenų saugumas debesijoje yra jūsų atsakomybė.“

Tai yra audito atraminis teiginys. Jūsų taikymo sritis neturi teigti: „AWS neįtraukiama, nes ją valdo Amazon.“ Ji turi nurodyti, kad informacinis turtas ir procesai, susiję su AWS talpinamomis paslaugomis, patenka į taikymo sritį, įskaitant debesijos saugumo kontrolės priemonių, tapatybės, žurnalavimo, šifravimo, atsarginių kopijų, tiekėjų patikinimo ir reagavimo į incidentus valdymą.

ISO 27001:2022 kontekste tai pagrindžia 4.1–4.4 punktų reikalavimus dėl konteksto, suinteresuotųjų šalių, taikymo srities ir ISVS procesų. NIS2 kontekste tai pagrindžia Article 21 lūkesčius dėl rizikos analizės, incidentų valdymo, veiklos tęstinumo, tiekimo grandinės saugumo, saugaus įsigijimo ir priežiūros, prieigos kontrolės, turto valdymo, kriptografijos, kontrolės priemonių veiksmingumo ir MFA, kai taikoma. DORA kontekste tai pagrindžia principą, kad finansų sektoriaus subjektai išlieka atsakingi už IRT riziką net tada, kai IRT paslaugos perduodamos išorės teikėjams.

Klausimas nėra, ar jūsų debesijos paslaugų teikėjas yra saugus. Klausimas yra, ar valdote savo naudojimąsi teikėju, teisingai konfigūruojate savo atsakomybės dalį, stebite paslaugą, valdote tiekėjų įsipareigojimus ir saugote įrodymus.

Bendra atsakomybė turi tapti bendrais įrodymais

Debesijos paslaugų teikėjai paaiškina bendrą atsakomybę. Auditoriai tikrina, ar ją įgyvendinote praktikoje.

IaaS aplinkoje teikėjas paprastai saugo fizines patalpas, pagrindinę infrastruktūrą ir hipervizorių. Klientas kontroliuoja tapatybę, darbo krūvių konfigūraciją, operacinės sistemos stiprinimą, taikomųjų programų saugumą, duomenų klasifikavimą, šifravimo nustatymus, tinklo taisykles, žurnalavimą, atsargines kopijas, pataisų diegimą ir reagavimą į incidentus.

SaaS aplinkoje teikėjas kontroliuoja daugumą platformos operacijų, tačiau klientas vis tiek kontroliuoja nuomininko konfigūraciją, naudotojus, administratoriaus vaidmenis, integracijas, duomenų bendrinimą, saugojimo terminus, žurnalavimo parinktis ir eskalavimo procedūras.

Clarysec Zenith Controls: The Cross-Compliance Guide Zenith Controls ISO/IEC 27002:2022 kontrolės priemonę 5.23 „Informacijos saugumas naudojant debesijos paslaugas“ traktuoja kaip centrinę debesijos valdysenos kontrolės priemonę, turinčią prevencinį tikslą konfidencialumo, vientisumo ir prieinamumo požiūriu. Ji susieja debesijos paslaugas su tiekėjų santykiais, saugiu informacijos perdavimu, turto apskaita, duomenų nutekėjimo prevencija, galinių įrenginių ir tinklo saugumu bei saugaus kūrimo praktikomis.

Svarbi Zenith Controls interpretacija teigia:

„Debesijos paslaugų teikėjai (CSP) veikia kaip kritiniai tiekėjai, todėl jiems taikomos visos tiekėjų atrankos, sutarčių sudarymo ir rizikos valdymo kontrolės priemonės pagal 5.19. Tačiau 5.23 žengia toliau, nes nagrinėja debesijai būdingas rizikas, tokias kaip kelių nuomininkų architektūra, duomenų vietos skaidrumas ir bendros atsakomybės modeliai.“

Šis skirtumas yra kritinis. Vien tiekėjų sertifikatai nepatenkina Annex A.5.23. Reikia kliento pusės įrodymų, patvirtinančių, kad debesijos paslaugai taikoma valdysena, ji sukonfigūruota, stebima ir peržiūrima.

Tai yra skirtumas tarp debesijos kontrolės priemonių turėjimo ir auditui tinkamų debesijos kontrolės priemonių turėjimo.

Pradėkite nuo auditoriui tinkamo Debesijos paslaugų registro

Greičiausias būdas pagerinti pasirengimą debesijos auditui – sukurti išsamų Debesijos paslaugų registrą. Tai neturi būti pirkimų sąrašas ar finansų eksportas. Jis turi susieti debesijos paslaugas su duomenimis, savininkais, regionais, prieiga, sutartimis, kritiškumu, reglamentavimo aktualumu ir įrodymais.

Clarysec MVĮ Debesijos paslaugų naudojimo politika-sme Debesijos paslaugų naudojimo politika-sme 5.3 punkte pateikia glaustą ir auditui tinkamą bazinį reikalavimą:

„Debesijos paslaugų registrą turi tvarkyti IT paslaugų teikėjas arba GM. Jame turi būti registruojama: 5.3.1 Kiekvienos patvirtintos debesijos paslaugos pavadinimas ir paskirtis 5.3.2 Atsakingas asmuo arba komanda (Taikomosios programos savininkas) 5.3.3 Saugomų arba tvarkomų duomenų tipai 5.3.4 Šalis arba regionas, kuriame saugomi duomenys 5.3.5 Naudotojų prieigos leidimai ir administratoriaus paskyros 5.3.6 Sutarties duomenys, atnaujinimo datos ir pagalbos kontaktai“

Įmonių aplinkoms Clarysec Debesijos paslaugų naudojimo politika Debesijos paslaugų naudojimo politika nustato platesnį įpareigojimą:

„Ši politika nustato privalomus organizacijos reikalavimus saugiam, reikalavimus atitinkančiam ir atsakingam debesijos paslaugų naudojimui pagal Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS) ir Software-as-a-Service (SaaS) teikimo modelius.“

Debesijos paslaugų naudojimo politika reikalauja centralizuoto registro, už kurį atsakingas CISO, ir patvirtintų bazinių konfigūracijų debesijos aplinkoms. Šis registras tampa kelių įpareigojimų įrodymų pagrindu vienu metu.

ISO 27001:2022 kontekste jis padeda pagrįsti turto apskaitą, debesijos naudojimo valdyseną, tiekėjų santykius, prieigos kontrolę, teisinius ir sutartinius reikalavimus, rizikos valdymą ir dokumentuotą informaciją. NIS2 kontekste jis padeda pagrįsti tiekimo grandinės saugumą, turto valdymą, rizikos analizę, incidentų valdymą ir tęstinumą. DORA kontekste jis padeda pagrįsti IRT turto ir priklausomybių atvaizdavimą, IRT trečiųjų šalių registrus, kritinių arba svarbių funkcijų atvaizdavimą ir koncentracijos rizikos analizę. GDPR kontekste jis nustato, ar tvarkomi asmens duomenys, kur jie yra, kuris teikėjas veikia kaip duomenų tvarkytojas ir kokios perdavimo arba duomenų tvarkymo sąlygos taikomos.

Jei registras nenustato duomenų kategorijų ir regionų, privatumo ir atsparumo įrodymai bus neišsamūs. Jei jis nenustato taikomųjų programų savininkų, prieigos peržiūros liks be savininko. Jei jis nenustato sutarčių ir atnaujinimo datų, tiekėjų saugumo nuostatų nebus galima patikrinti.

Paverskite ISO 27001:2022 debesijos įrodymų ašimi

ISO 27001:2022 yra tinkamiausia debesijos įrodymų ašis, nes ji susieja verslo kontekstą, riziką, kontrolės priemones, operacinius įrodymus, stebėseną ir tobulinimą.

Pagrindiniai su debesija susiję ISO 27001:2022 reikalavimai apima:

• 4.1–4.4 punktus dėl konteksto, suinteresuotųjų šalių, ISVS taikymo srities, sąsajų, priklausomybių ir procesų.
• 5.1–5.3 punktus dėl vadovybės įsipareigojimo, politikos, vaidmenų, atsakomybių ir atskaitomybės.
• 6.1.1–6.1.3 punktus dėl rizikos vertinimo, rizikos valdymo, Annex A palyginimo, Taikytinumo pareiškimo ir liekamosios rizikos priėmimo.
• 7.5 punktą dėl kontroliuojamos dokumentuotos informacijos.
• 8.1–8.3 punktus dėl operacinio planavimo, rizikos vertinimo vykdymo ir rizikos valdymo vykdymo.
• 9.1–9.3 punktus dėl stebėsenos, matavimo, vidaus audito ir vadovybės peržiūros.
• 10 punktą dėl neatitikties, korekcinių veiksmų ir nuolatinio tobulinimo.

Annex A kontrolės priemonės, turinčios didžiausią svorį debesijos įrodymams, apima A.5.19 Informacijos saugumą tiekėjų santykiuose, A.5.20 Informacijos saugumo įtraukimą į tiekėjų susitarimus, A.5.21 Informacijos saugumo valdymą IRT tiekimo grandinėje, A.5.22 Tiekėjų paslaugų stebėseną, peržiūrą ir pakeitimų valdymą, A.5.23 Informacijos saugumą naudojant debesijos paslaugas, A.5.24–A.5.27 incidentų valdymą, A.5.29 Informacijos saugumą trikdžių metu, A.5.30 IRT parengtį veiklos tęstinumui, A.5.31 Teisinius, įstatyminius, reglamentavimo ir sutartinius reikalavimus, A.5.34 Privatumą ir PII apsaugą, A.5.36 Informacijos saugumo politikų, taisyklių ir standartų laikymąsi, A.8.8 Techninių pažeidžiamumų valdymą, A.8.9 Konfigūracijų valdymą, A.8.13 Informacijos atsargines kopijas, A.8.15 Žurnalų valdymą, A.8.16 Stebėsenos veiklas, A.8.24 Kriptografijos naudojimą, A.8.25 Saugaus kūrimo gyvavimo ciklą, A.8.29 Saugumo testavimą kūrimo ir priėmimo metu ir A.8.32 Pakeitimų valdymą.

Zenith Blueprint kontrolės priemonių taikymo etape, 23 žingsnyje, debesijos paslaugos paaiškinamos auditoriams suprantama kalba:

„Perėjimas prie debesijos paslaugų iš esmės keičia pasitikėjimo modelį. Jūs nebevaldote serverio, tinklo perimetro ar hipervizoriaus. Dažnai net nežinote, kur fiziškai yra duomenys. Tai, ką valdote ir ką ši kontrolė įtvirtina, yra šio santykio valdysena, matomumas, ką naudojate, ir saugumo lūkesčiai, kuriuos keliate savo teikėjams.“

Tvirtas A.5.23 Taikytinumo pareiškimo įrašas neturi apsiriboti teiginiu „Taikoma, debesijos teikėjas sertifikuotas“. Jis turi paaiškinti, kodėl kontrolės priemonė taikoma, kokias rizikas ji valdo, kaip ji įgyvendinta ir kur saugomi įrodymai.

Į SoA arba kontrolės priemonių sekiklį įtraukite įrodymų vietos stulpelį. Auditoriams neturi reikėti ieškoti įrodymų el. pašte, užklausų sistemose ir bendruose diskuose.

Naudokite vieną įrodymų modelį ISO 27001:2022, NIS2 ir DORA

NIS2 ir DORA abi reikalauja dokumentuoto, rizika grindžiamo, vadovybės valdomo kibernetinio saugumo. Sutapimas didelis, tačiau priežiūros spaudimas skiriasi.

NIS2 taikoma daugeliui esminių ir svarbių subjektų ES, įskaitant skaitmeninės infrastruktūros teikėjus, valdomų paslaugų teikėjus, valdomų saugumo paslaugų teikėjus, bankininkystę, finansų rinkų infrastruktūras ir skaitmeninius teikėjus. Article 21 reikalauja tinkamų ir proporcingų techninių, operacinių ir organizacinių priemonių, įskaitant rizikos analizę, incidentų valdymą, veiklos tęstinumą, tiekimo grandinės saugumą, saugų įsigijimą ir priežiūrą, pažeidžiamumų valdymą, kontrolės priemonių veiksmingumo vertinimą, kibernetinę higieną, mokymus, kriptografiją, prieigos kontrolę, turto valdymą ir MFA arba saugias komunikacijas, kai tinkama.

Debesijos saugumo audito įrodymų požiūriu NIS2 klausia, ar debesijos ir tiekėjų rizikos valdomos kaip paslaugos teikimo rizikos dalis. Ji taip pat nustato struktūruotą reikšmingų incidentų pranešimą, įskaitant ankstyvąjį įspėjimą per 24 valandas, pranešimą apie incidentą per 72 valandas ir galutinę ataskaitą per vieną mėnesį.

DORA nuo 2025 m. sausio 17 d. taikoma daugeliui ES finansų sektoriaus subjektų ir nustato vienodus reikalavimus IRT rizikos valdymui, pranešimui apie reikšmingus IRT incidentus, skaitmeninio operacinio atsparumo testavimui, informacijos dalijimuisi ir IRT trečiųjų šalių rizikai. Finansų sektoriaus subjektams, kurie taip pat priskirti pagal NIS2, DORA laikoma sektoriui skirtu Sąjungos teisės aktu dėl persidengiančių operacinių įpareigojimų.

Debesijos atžvilgiu DORA yra tiesioginė. Finansų sektoriaus subjektai išlieka atsakingi už IRT riziką, kai paslaugos perduodamos išorės teikėjams. Jiems reikia IRT trečiųjų šalių strategijų, sutarčių registrų, ikisutartinių vertinimų, deramo patikrinimo, audito ir prieigos teisių, nutraukimo trigerių, koncentracijos rizikos analizės, subtiekimo kontrolės priemonių ir išbandytų pasitraukimo strategijų.

Zenith Controls susieja ISO/IEC 27002:2022 kontrolės priemonę 5.23 su ES NIS2 Article 21 ir DORA Articles 28 to 31. Ji taip pat nurodo palaikančius standartus, tokius kaip ISO/IEC 27017 dėl debesijos saugumo vaidmenų ir stebėsenos, ISO/IEC 27018 dėl PII apsaugos viešojoje debesijoje, ISO/IEC 27701 dėl privatumo valdymo debesijos duomenų tvarkytojo santykiuose, ISO/IEC 27036-4 dėl debesijos paslaugų stebėsenos ir tiekėjų susitarimų, ir ISO/IEC 27005 dėl debesijos rizikos vertinimo.

Praktinė išvada paprasta. Nekurkite atskirų įrodymų paketų ISO 27001:2022, NIS2, DORA ir GDPR. Kurkite vieną debesijos įrodymų architektūrą su konkrečioms sistemoms skirtais susiejimais.

Tiekėjų sutartys yra kontrolės įrodymai, o ne teisiniai archyvai

Debesijos audito įrodymai dažnai nutrūksta sutarčių sluoksnyje. Saugumo funkcija turi tiekėjo klausimyną. Teisės funkcija turi MSA. Pirkimai turi atnaujinimo datą. DPO turi DPA. Niekas neturi vieningo vaizdo, ar susitarime yra saugumo nuostatos, kurių reikalauja ISO 27001:2022, NIS2, DORA ir GDPR.

Clarysec MVĮ Trečiųjų šalių ir tiekėjų saugumo politika-sme Trečiųjų šalių ir tiekėjų saugumo politika-sme 5.3 punkte nustato:

„Sutartyse turi būti privalomos nuostatos, apimančios: 5.3.1 Konfidencialumą ir neatskleidimą 5.3.2 Informacijos saugumo įsipareigojimus 5.3.3 Pranešimų apie duomenų saugumo pažeidimus terminus (pvz., per 24–72 valandas) 5.3.4 Audito teises arba atitikties įrodymų prieinamumą 5.3.5 Tolesnio subtiekimo apribojimus be patvirtinimo 5.3.6 Nutraukimo sąlygas, įskaitant saugų duomenų grąžinimą arba sunaikinimą“

Audito nuoseklumui šias nuostatas perkelkite į sutarčių peržiūros matricą. ISO 27001:2022 Annex A.5.20 tikisi, kad saugumo reikalavimai bus suderinti su tiekėjais. GDPR Article 28 reikalauja duomenų tvarkytojo sąlygų, apimančių konfidencialumą, saugumo priemones, pagalbą, subtvarkytojus, duomenų ištrynimą arba grąžinimą ir pagalbą audito metu. DORA Article 30 reikalauja išsamių sutartinių nuostatų IRT trečiųjų šalių teikėjams, įskaitant paslaugų aprašymus, duomenų vietą, saugumą, pagalbą incidentų metu, bendradarbiavimą su institucijomis, audito teises, prieigos teises, nutraukimo ir perėjimo tvarką. NIS2 tiekimo grandinės saugumui taip pat reikia įgyvendinamo tiekėjų bendradarbiavimo.

Zenith Controls susieja ISO/IEC 27002:2022 kontrolės priemonę 5.20 su tiekėjų susitarimais ir pažymi sąsajas su 5.19 tiekėjų santykiais, 5.14 informacijos perdavimu, 5.22 tiekėjų stebėsena, 5.11 turto grąžinimu ir 5.36 atitiktimi.

Esmė yra praktinis įgyvendinimas. Jei debesijos sutartis suteikia prieigą prie SOC 2 ataskaitų, auditoriai gali paklausti, ar ataskaitą gavote, peržiūrėjote išimtis, sekėte taisomuosius veiksmus ir pakartotinai įvertinote riziką. Jei sutartis žada pranešti apie pažeidimą, jie gali paklausti, ar jūsų incidentų reagavimo veiksmų plane yra tiekėjo kontaktinis kelias ir reglamentavimo sprendimų taškai. Jei subtiekėjų pakeitimams reikia patvirtinimo arba pranešimo, jie gali paklausti, ar subtvarkytojų pranešimai peržiūrimi prieš priėmimą.

Sutartis be peržiūros įrodymų yra archyvas. Sutartis, susieta su tiekėjo rizika, stebėsenos įrašais ir incidentų darbo eigomis, yra kontrolės priemonė.

SaaS žurnalavimas ir konfigūracija yra dažnos audito aklosios zonos

Debesijos išvados dažnai kyla iš SaaS, o ne IaaS. Infrastruktūros komandos paprastai turi inžinerinius savininkus, žurnalavimo konvejerius, bazines kontrolės priemones ir pakeitimų įrašus. SaaS platformos išskaidytos tarp pardavimų, HR, finansų, klientų sėkmės, rinkodaros ir operacijų. Kiekviena gali tvarkyti jautrius arba reguliuojamus duomenis.

Clarysec Žurnalų valdymo ir stebėsenos politika-sme Žurnalų tvarkymo ir stebėsenos politika-sme tai tiesiogiai aptaria 5.5 punkte:

„5.5 Debesijos paslaugos ir trečiųjų šalių žurnalavimas 5.5.1 Platformoms, kuriose žurnalavimas nėra tiesiogiai kontroliuojamas IT (pvz., SaaS el. paštas), taikomi šie reikalavimai: 5.5.1.1 Žurnalavimas turi būti įjungtas ir sukonfigūruotas, kai tokia galimybė yra 5.5.1.2 Įspėjimai turi būti nukreipiami IT pagalbos teikėjui 5.5.1.3 Sutartyse turi būti reikalaujama, kad teikėjai saugotų žurnalus bent 12 mėnesių ir pateiktų prieigą pagal prašymą“

Įmonėms Debesijos paslaugų naudojimo politika papildomai nustato:

„Debesijos paslaugos turi būti integruotos į organizacijos SIEM nuolatinei stebėsenai.“

Šis reikalavimas perkelia SaaS iš „verslo įrankio“ į „stebimą informacinę sistemą“. Įrodymai turi apimti žurnalavimo nustatymų eksportus, SIEM jungties įrodymus, įspėjimų taisykles, triavimo užklausas, saugojimo nustatymus ir administracinės prieigos peržiūras.

Kritinėms SaaS paslaugoms parenkite įrodymus dėl administratoriaus paskyrų sukūrimo, įtartinų prisijungimų, masinių atsisiuntimų, viešo bendrinimo, MFA išjungimo, API žetonų sukūrimo, išorinių svečių veiklos ir privilegijų pakėlimo. IaaS atveju parenkite CloudTrail arba lygiavertį valdymo plokštumos žurnalavimą, saugyklos prieigos žurnalus, IAM pakeitimus, srautų žurnalus, kai tinkama, CSPM išvadas, pažeidžiamumų skenavimą, pataisų įrodymus, šifravimo nustatymus, atsarginių kopijų būseną, tinklo saugumo grupių peržiūras ir pakeitimų užklausas.

Zenith Controls audito metodika, skirta kontrolei 5.23, pažymi, kad ISO/IEC 27007 stiliaus auditas gali tikrinti AWS S3 talpyklų leidimus, šifravimą, IAM politikas ir CloudTrail žurnalavimą. COBIT orientuotas auditorius gali peržiūrėti įspėjimų konfigūracijas, DLP kontrolės priemones, Microsoft 365 Secure Score naudojimą ir pakeitimų valdymo žurnalus. NIST SP 800-53A perspektyva gali tikrinti paskyrų valdymą ir stebėseną, įskaitant tai, ar debesijos darbo krūviams pataisos diegiamos, jie skenuojami ir stebimi tokiu pačiu griežtumu kaip vidaus sistemos.

Skirtingi auditoriai kalba skirtingomis tarmėmis. Jūsų įrodymai turi būti tie patys.

Sukurkite priežiūros institucijoms tinkamą įrodymų paketą vienai SaaS ir vienai IaaS paslaugai

Praktinė darbo eiga prasideda nuo vienos kritinės SaaS platformos ir vienos kritinės IaaS aplinkos. Pavyzdžiui, Microsoft 365 bendradarbiavimui ir AWS produkcinei prieglobai.

1 žingsnis: atnaujinkite Debesijos paslaugų registrą

Microsoft 365 atveju registruokite paskirtį, savininką, duomenų tipus, regioną, administratoriaus paskyras, sutartį, DPA, pagalbos kontaktą, atnaujinimo datą ir kritiškumą. AWS atveju registruokite produkcinę paskyrą, regionus, duomenų kategorijas, darbo krūvius, paskyros savininką, root paskyros būseną, pagalbos planą, sutarties sąlygas ir susietas verslo paslaugas.

Naudokite Debesijos paslaugų naudojimo politika-sme laukus kaip minimalų duomenų rinkinį. Pridėkite kritiškumą, reglamentavimo aktualumą ir įrodymų vietą.

2 žingsnis: dokumentuokite bendrą atsakomybę

Microsoft 365 atveju kliento atsakomybės apima naudotojų gyvavimo ciklą, MFA, sąlyginę prieigą, svečių bendrinimą, saugojimo žymas, DLP, kai naudojama, žurnalavimą ir incidentų eskalavimą. AWS atveju kliento atsakomybės apima IAM, tinklo taisykles, darbo krūvių stiprinimą, šifravimo konfigūraciją, atsargines kopijas, žurnalavimą, pataisų diegimą ir taikomųjų programų saugumą.

Pridėkite teikėjo bendros atsakomybės dokumentaciją, tada susiekite kiekvieną kliento atsakomybę su kontrolės savininku ir įrodymų šaltiniu.

3 žingsnis: užfiksuokite konfigūracijos įrodymus

Microsoft 365 atveju eksportuokite arba užfiksuokite ekrano kopijomis MFA ir sąlyginės prieigos politikas, administratoriaus vaidmenis, išorinio bendrinimo nustatymus, audito žurnalavimą, saugojimo konfigūraciją ir saugumo balo veiksmus. AWS atveju eksportuokite IAM slaptažodžių politiką, privilegijuoto MFA būseną, CloudTrail konfigūraciją, S3 viešos prieigos blokavimą, šifravimo būseną, saugumo grupių peržiūrą, atsarginių kopijų užduotis ir pažeidžiamumų skenavimo būseną.

Debesijos paslaugų naudojimo politika reikalauja, kad debesijos aplinkos atitiktų dokumentuotą bazinę konfigūraciją, patvirtintą Debesijos saugumo architekto. Jūsų įrodymų pakete turi būti ir bazinė konfigūracija, ir atitikties jai įrodymas.

4 žingsnis: susiekite tiekėjo ir privatumo įrodymus

Pridėkite sutartį, DPA, subtvarkytojų sąrašą, pranešimo apie pažeidimus sąlygas, audito patikinimo ataskaitas ir duomenų vietos įrodymus. Jei tvarkomi asmens duomenys, registruokite, ar teikėjas veikia kaip duomenų tvarkytojas, kaip tvarkomas ištrynimas, kaip veikia pagalba dėl duomenų subjektų prašymų ir kokios perdavimo apsaugos priemonės taikomos.

DORA atveju nustatykite, ar debesijos paslauga palaiko kritinę arba svarbią funkciją. Jei taip, susiekite įrodymus su IRT trečiųjų šalių registru, deramo patikrinimo byla, audito teisėmis, pasitraukimo planu ir koncentracijos rizikos peržiūra.

5 žingsnis: susiekite žurnalavimą su reagavimu į incidentus

Parodykite, kad žurnalai įjungti, nukreipiami, peržiūrimi ir naudojami. Pridėkite SIEM valdymo skydus, įspėjimų taisykles ir bent vieną uždarytą įspėjimo užklausą. Tada susiekite darbo eigą su NIS2 ir DORA pranešimo sprendimų taškais.

NIS2 atveju incidentų procesas turi palaikyti 24 valandų ankstyvąjį įspėjimą, 72 valandų pranešimą apie incidentą ir vieno mėnesio galutinę ataskaitą dėl reikšmingų incidentų. DORA atveju IRT incidentų procesas turėtų klasifikuoti incidentus pagal paveiktus klientus, operacijas, trukmę, prastovą, geografinį paplitimą, poveikį duomenims, paslaugos kritiškumą ir ekonominį poveikį.

6 žingsnis: drausmingai saugokite įrodymus

Clarysec Audito ir atitikties stebėsenos politika-sme Audito ir atitikties stebėsenos politika-sme 6.2 punkte apibrėžia praktinę įrodymų drausmę:

„6.2 Įrodymų rinkimas ir dokumentavimas 6.2.1 Visi įrodymai turi būti saugomi centralizuotame audito aplanke. 6.2.2 Failų pavadinimai turi aiškiai nurodyti audito temą ir datą. 6.2.3 Metaduomenys (pvz., kas surinko, kada ir iš kurios sistemos) turi būti dokumentuoti. 6.2.4 Įrodymai turi būti saugomi bent dvejus metus arba ilgiau, kai to reikalauja sertifikavimo ar klientų susitarimai.“

Įmonių Audito ir atitikties stebėsenos politika Audito ir atitikties stebėsenos politika nustato tikslą:

„Sukurti dokumentuotus įrodymus ir audito pėdsaką, pagrindžiančius reglamentavimo institucijų paklausimus, teisinius procesus arba klientų patikinimo prašymus.“

Ekrano kopija pavadinimu „screenshot1.png“ yra silpnas įrodymas. Failas „AWS-Prod-CloudTrail-Enabled-2026-05-10-CollectedBy-JSmith.png“ yra stipresnis, nes apibūdina sistemą, kontrolės priemonę, datą ir rinkėją. Metaduomenys svarbūs, nes auditoriams reikia pasitikėti, kada įrodymai buvo surinkti, kas juos surinko ir iš kurios sistemos.

Kaip auditoriai tikrina tą pačią debesijos kontrolės priemonę

Stipriausi debesijos įrodymų paketai kuriami kelioms audito perspektyvoms. ISO 27001:2022 auditoriai tikrina, ar kontrolės priemonė yra ISVS, rizikos vertinime, rizikos valdyme ir SoA. NIST orientuoti vertintojai tikrina techninį įgyvendinimą. COBIT 2019 auditoriai tikrina valdyseną, tiekėjų veiksmingumą ir procesų integraciją. Privatumo auditoriai daugiausia dėmesio skiria duomenų tvarkytojo įsipareigojimams, duomenų buvimo vietai, pasirengimui pažeidimams ir duomenų subjektų teisėms. DORA priežiūros peržiūros orientuojasi į IRT trečiųjų šalių riziką ir atsparumą.

Zenith Controls apima šiuos audito metodikos skirtumus debesijos paslaugoms, tiekėjų susitarimams ir tiekėjų stebėsenai. Dėl 5.22 „Tiekėjų paslaugų stebėsena, peržiūra ir pakeitimų valdymas“ nurodoma, kad auditoriai gali tikrinti ketvirtinių tiekėjų peržiūrų protokolus, KPI ataskaitas, SOC ataskaitų vertinimus, pakeitimų žurnalus, rizikos vertinimus, tiekėjų incidentus ir problemų sekimą. Dėl 5.20 „Informacijos saugumo įtraukimas į tiekėjų susitarimus“ pabrėžiama sutarčių atranka pagal konfidencialumą, saugumo įsipareigojimus, pranešimą apie pažeidimus, audito teises, subtiekėjų patvirtinimą ir nutraukimo sąlygas.

Kryžminės atitikties kontrolės priemonės, nešančios debesijos audito krūvį

Priežiūros institucijoms tinkamas debesijos įrodymų modelis grindžiamas nedideliu skaičiumi didelės vertės kontrolės priemonių. Šios kontrolės priemonės neša didelę atitikties naštos dalį pagal ISO 27001:2022, NIS2, DORA, GDPR, NIST ir COBIT 2019.

NIST SP 800-53 Rev.5 suteikia techninio gylio per paskyrų valdymą, išorinių sistemų paslaugas, nuolatinę stebėseną, sistemų stebėseną ir ribų apsaugą. COBIT 2019 suteikia valdysenos gylio per tiekėjų santykių valdymą, tiekėjų riziką, duomenų mainus, tinklo saugumą ir pasirengimą pakeitimams.

Palaikantys ISO standartai patikslina įrodymų modelį. ISO/IEC 27017 pateikia debesijai skirtas gaires dėl bendrų vaidmenų, virtualių mašinų konfigūracijos ir klientų veiklos stebėsenos. ISO/IEC 27018 orientuojasi į PII apsaugą viešojoje debesijoje. ISO/IEC 27701 išplečia privatumo įpareigojimus į duomenų tvarkytojo ir valdytojo operacijas. ISO/IEC 27036-4 palaiko debesijos tiekėjų susitarimus ir stebėseną. ISO/IEC 27005 taikomas debesijos rizikos vertinimui.

Vadovybės peržiūra turi matyti debesijos riziką, ne tik debesijos veikimo laiką

Vienas dažniausiai nepastebimų audito artefaktų yra vadovybės peržiūra. ISO 27001:2022 tikisi, kad vadovybės peržiūroje bus nagrinėjami pokyčiai, suinteresuotųjų šalių poreikiai, veiklos tendencijos, audito rezultatai, rizikos valdymo būsena ir tobulinimo galimybės. NIS2 reikalauja, kad valdymo organai patvirtintų kibernetinio saugumo rizikos valdymo priemones ir prižiūrėtų jų įgyvendinimą. DORA reikalauja, kad valdymo organas apibrėžtų, patvirtintų, prižiūrėtų IRT rizikos valdymą ir išliktų už jį atskaitingas.

Ketvirtinis debesijos saugumo ir tiekėjų valdymo skydas turi rodyti:

• Patvirtintų debesijos paslaugų skaičių.
• Kritines debesijos paslaugas ir jų savininkus.
• Paslaugas, tvarkančias asmens duomenis.
• Paslaugas, palaikančias kritines arba svarbias funkcijas.
• Atviras didelės rizikos debesijos neteisingas konfigūracijas.
• MFA ir privilegijuotos prieigos peržiūros būseną.
• Kritinių SaaS ir IaaS platformų žurnalavimo aprėptį.
• Gautas ir peržiūrėtas tiekėjų patikinimo ataskaitas.
• Sutarčių išimtis ir priimtas rizikas.
• Debesijos incidentus, beveik įvykusius incidentus ir įgytą patirtį.
• Atsarginių kopijų ir atkūrimo testų rezultatus.
• Koncentracijos rizikos ir pasitraukimo plano būseną.

Šis valdymo skydas tampa įrodymu ISO 27001:2022 vadovybės įsipareigojimui ir veiklos vertinimui, NIS2 valdysenai ir DORA vadovybės atskaitomybei.

Zenith Blueprint rizikos valdymo etape, 14 žingsnyje, rekomenduoja įgyvendinant rizikos valdymo priemones ir politikas atlikti kryžminį sulyginimą su reglamentavimo reikalavimais. Jame teigiama, kad pagrindinių reglamentavimo reikalavimų susiejimas su ISVS kontrolės priemonėmis yra naudinga vidinė praktika ir „taip pat daro įspūdį auditoriams / vertintojams, nes parodo, kad saugumo nevaldote vakuume, o suprantate teisinį kontekstą“.

Tokios brandos tikisi priežiūros institucijos ir įmonių klientai.

Dažnos debesijos audito išvados ir kaip jų išvengti

Pasirengimo debesijos auditui darbuose pasikartojančios išvados yra nuspėjamos:

1. Debesijos paslaugų registras yra, bet jame trūksta SaaS įrankių.
2. Duomenų vieta neregistruojama arba nukopijuojama iš rinkodaros puslapių, o ne iš sutartinių įrodymų.
3. MFA taikomas darbuotojams, bet ne visoms administratoriaus arba „break-glass“ paskyroms.
4. Debesijos žurnalai įjungti, bet nėra peržiūrimi, saugomi arba susieti su reagavimu į incidentus.
5. Tiekėjų SOC ataskaitos archyvuojamos, bet nevertinamos.
6. Sutartinės nuostatos yra naujiems tiekėjams, bet ne senosioms kritinėms paslaugoms.
7. Subtvarkytojų pranešimai gaunami el. paštu, bet nevertinami pagal riziką.
8. Atsarginių kopijų užduotys vykdomos sėkmingai, bet atkūrimo testai neįrodyti.
9. Inžinieriai supranta bendrą atsakomybę, bet ji nėra dokumentuota auditoriams.
10. SoA pažymi debesijos kontrolės priemones kaip taikomas, bet nesusieja jų su rizikos įrašais, įrodymais ar savininkais.

Tai yra atsekamumo problemos. Sprendimas – susieti politiką, riziką, kontrolės priemonę, savininką, įrodymus ir peržiūrą.

Kai atėjo audito diena, Marija nebesirėmė išsibarsčiusiomis ekrano kopijomis. Ji atidarė centralizuotą valdymo skydą, kuriame buvo Debesijos paslaugų registras, rizikos vertinimai, SoA įrašai, bazinės konfigūracijos įrodymai, tiekėjų peržiūros bylos, žurnalavimo įrodymai ir DORA koncentracijos rizikos peržiūra. Kai auditorius paklausė, kaip valdoma debesijos rizika, ji parodė ISVS. Kai auditorius paklausė, kaip paslaugos saugiai sukonfigūruotos, ji parodė bazinę konfigūraciją ir CSPM įrodymus. Kai auditorius paklausė apie IRT trečiųjų šalių riziką, ji parodė sutarčių peržiūrą, tiekėjų stebėseną ir pasitraukimo planavimą.

Rezultatas nebuvo tobula aplinka. Nė viena debesijos aplinka nėra tobula. Skirtumas buvo tas, kad rizikos sprendimai buvo dokumentuoti, įrodymai buvo pagrįsti, o atskaitomybė – matoma.

Sukurkite debesijos įrodymų paketą prieš auditoriui jo paprašant

Jei jūsų organizacija remiasi SaaS, IaaS arba PaaS, kitas auditas nepriims atsakymo „tuo pasirūpina teikėjas“ kaip pakankamo. Turite įrodyti bendrą atsakomybę, kliento pusės konfigūraciją, tiekėjų nuostatas, žurnalavimą, pasirengimą incidentams, atsparumą ir vadovybės priežiūrą.

Šią savaitę pradėkite nuo trijų praktinių veiksmų:

1. Sukurkite arba atnaujinkite Debesijos paslaugų registrą naudodami Clarysec Debesijos paslaugų naudojimo politika Debesijos paslaugų naudojimo politika arba Debesijos paslaugų naudojimo politika-sme Debesijos paslaugų naudojimo politika-sme.
2. Susiekite penkias svarbiausias debesijos paslaugas su ISO 27001:2022 Annex A kontrolės priemonėmis, NIS2 Article 21, DORA IRT trečiųjų šalių įpareigojimais, kai taikoma, ir GDPR duomenų tvarkytojo reikalavimais.
3. Sukurkite centralizuotą įrodymų aplanką, taikydami saugojimo terminų ir metaduomenų drausmę iš Audito ir atitikties stebėsenos politika Audito ir atitikties stebėsenos politika arba Audito ir atitikties stebėsenos politika-sme Audito ir atitikties stebėsenos politika-sme.

Tada naudokite Zenith Blueprint Zenith Blueprint, kad įtrauktumėte šį darbą į 30 žingsnių ISVS audito veiksmų planą, ir Zenith Controls Zenith Controls, kad patvirtintumėte kryžminės atitikties susiejimus, palaikančius ISO standartus ir audito metodikos lūkesčius.

Clarysec gali padėti išsibarsčiusias debesijos ekrano kopijas, tiekėjų bylas ir SaaS nustatymus paversti priežiūros institucijoms tinkamu įrodymų paketu, kuris atlaiko ISO 27001:2022 sertifikavimo auditą, NIS2 priežiūros klausimus, DORA IRT trečiųjų šalių peržiūras ir įmonių klientų patikinimo reikalavimus.