Prieigos prie AII valdysena pagal ISO 27701:2025 ir GDPR

Išorės auditoriaus klausimas liko tvyroti ore — apgaulingai paprastas.

„Ar galite parodyti savo techninės pagalbos komandos prieigos prie gamybinėje aplinkoje tvarkomos AII peržiūros žurnalą už praėjusį ketvirtį?“

Anjai, Medtelligence CISO, tai buvo tiesos akimirka. Medtelligence yra sparčiai augantis sveikatos technologijų SaaS paslaugų teikėjas, veikiantis kaip ligoninių AII tvarkytojas ir debesijos platformoje tvarkantis jautrius pacientų duomenis. Bendrovė turėjo stiprų autentifikavimą, apibrėžtus vaidmenis ir brandžią inžinerijos komandą. Tačiau auditorius neklausė, ar egzistuoja prisijungimo puslapis. Jis prašė įrodymų, kad prieiga prie asmens duomenų buvo valdoma visą laikotarpį.

Jis norėjo matyti, kas galėjo pasiekti gamybinėje aplinkoje tvarkomą AII, kodėl ta prieiga buvo suteikta, kada ji buvo patvirtinta, ar ji vis dar buvo reikalinga, ar techninės pagalbos veiksmai buvo žurnaluojami ir ar pertekliniai leidimai buvo pašalinti.

Anja atidarė IAM konsolę. Joje buvo techninės pagalbos inžinieriai, duomenų bazių administratoriai, integracijos paslaugų paskyra, valdomų paslaugų teikėjas, du avariniai „break-glass“ vaidmenys ir buvęs rangovas, vis dar esantis grupėje, nes darbo santykių nutraukimo užklausa buvo uždaryta anksčiau, nei buvo pašalintos jo prieigos teisės. HR duomenys rodė, kad asmuo išėjo prieš šešias savaites. Prieigos peržiūros skaičiuoklėje buvo įrašyta „laukiama“. SIEM turėjo žurnalus, tačiau niekas nebuvo susiejęs, kurie įvykiai įrodo prieigą prie AII.

Būtent čia privatumo valdysena tampa reali.

Pagal GDPR asmens duomenys turi būti tvarkomi užtikrinant vientisumą ir konfidencialumą, apsaugant juos nuo neautorizuoto ar neteisėto tvarkymo, atsitiktinio praradimo, sunaikinimo ar sugadinimo tinkamomis techninėmis ir organizacinėmis priemonėmis. GDPR taip pat aiškiai įtvirtina atskaitomybę: duomenų valdytojas turi gebėti įrodyti atitiktį. ISO/IEC 27701:2025 šią atskaitomybę paverčia privatumo informacijos valdymo sistema, arba PIMS, kurioje prieiga prie AII nebėra techninė detalė po fakto. Ji tampa valdoma gyvavimo ciklo dalimi, apimančia vaidmenis, duomenų tvarkytojus, debesijos platformas, darbuotojus, privilegijuotus administratorius, žurnalus, peržiūras, sutartis ir įrodymus.

Daugelio organizacijų spraga nėra tai, kad jos neturi prieigos kontrolės. Spraga yra ta, kad jos negali nuosekliai įrodyti prieigos prie AII valdysenos pagal ISO/IEC 27701:2025, GDPR, ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIS2, DORA, NIST CSF 2.0 ir COBIT 2019.

Prieigos prie AII valdysena nėra vien IAM

Tradicinė IAM programa klausia: „Ar tinkami naudotojai gali pasiekti tinkamas sistemas?“

Brandus ISO/IEC 27701:2025 PIMS kelia griežtesnius klausimus:

• Kurios sistemos tvarko AII?
• Kuriems vaidmenims reikalinga prieiga prie konkrečių AII kategorijų?
• Ar organizacija veikia kaip AII valdytojas, AII tvarkytojas, bendras duomenų valdytojas ar subtvarkytojas?
• Ar prieiga ribojama pagal tikslą, dokumentuotą verslo poreikį ir mažiausių privilegijų principą?
• Ar privilegijuoti veiksmai žurnaluojami ir peržiūrimi?
• Ar organizacija gali įrodyti, kad duomenų tvarkytojo ir subtvarkytojo prieiga valdoma sutartinėmis priemonėmis?
• Ar debesijos techninės pagalbos prieigos keliai, nuomininkų izoliavimas, eksportai ir administraciniai veiksmai įtraukti į įrodymus?
• Ar prieigos sprendimai peržiūrimi po priėmimo į darbą, vaidmens pakeitimo, incidento, darbo santykių nutraukimo ir esminio sistemos pakeitimo?

Todėl AII saugumo ir prieigos kontrolės valdysena yra natūrali jungtis tarp ISO/IEC 27701:2025 ir GDPR. GDPR suteikia teisinės atskaitomybės pagrindą. ISO/IEC 27701:2025 privatumo valdymą duomenų valdytojams ir duomenų tvarkytojams perkelia į veiklos lygmenį. ISO/IEC 27001:2022 suteikia ISVS rizikos valdymo mechanizmą. ISO/IEC 27002:2022 suteikia kontrolės priemonių architektūrą, įskaitant privatumą ir AII apsaugą, prieigos kontrolę, prieigos teises, žurnalavimą, debesijos paslaugas, santykius su tiekėjais, klasifikavimą, ištrynimą, maskavimą ir kriptografiją.

Clarysec Zenith Blueprint: auditoriaus 30 žingsnių veiksmų planas tai priskiria kontrolės priemonių įgyvendinimo etapui. 23 žingsnyje, apimančiame organizacines kontrolės priemones nuo 5.19 iki 5.37, ISO/IEC 27002:2022 kontrolės priemonė 5.34 „Privatumas ir AII apsauga“ apibūdinama kaip pasitikėjimo, o ne vien duomenų klausimas:

asmenį identifikuojanti informacija nėra tiesiog dar vienas duomenų tipas — tai itin jautri pasitikėjimo išraiška. Vardai, adresai, ID, sveikatos įrašai, finansiniai duomenys — šie duomenys pasakoja istoriją apie tikrus žmones.

Tas pats fragmentas pateikia praktinį pagrindą: privatumo apsauga prasideda nuo duomenų supratimo. Organizacija turi žinoti, kokią AII renka, kur ji yra, kodėl ji tvarkoma ir kas gali ją pasiekti.

Atitikties spaudimas prieigos prie AII kontrolės srityje

Prieigos prie AII valdysena nebėra vienos sistemos klausimas. Tokios organizacijos kaip Medtelligence veikia privatumo reguliavimo, kibernetinio saugumo teisės, veiklos atsparumo, klientų patikinimo ir saugumo sertifikavimo sankirtoje.

GDPR Article 5 reikalauja, kad asmens duomenys būtų tvarkomi laikantis teisėtumo, sąžiningumo, skaidrumo, tikslo apribojimo, duomenų kiekio mažinimo, tikslumo, saugojimo trukmės ribojimo, vientisumo ir konfidencialumo principų. Article 5(2) įtvirtina atskaitomybę: duomenų valdytojas yra atsakingas už atitiktį ir turi gebėti ją įrodyti. Article 32 reikalauja tinkamų techninių ir organizacinių priemonių tvarkymo saugumui užtikrinti.

NIS2 Article 21 reikalauja, kad esminiai ir svarbūs subjektai taikytų tinkamas ir proporcingas technines, operacines bei organizacines kibernetinio saugumo rizikos valdymo priemones. Minimalios sritys apima rizikos analizę, saugumo politikas, incidentų valdymą, veiklos tęstinumą, tiekimo grandinės saugumą, saugų įsigijimą ir kūrimą, veiksmingumo vertinimą, kibernetinę higieną ir mokymus, kriptografiją, žmogiškųjų išteklių saugumą, prieigos kontrolę, turto valdymą ir, kai tinkama, daugiaveiksnį arba tęstinį autentifikavimą bei saugią komunikaciją. Article 20 taip pat nustato valdymo organų atsakomybę patvirtinti kibernetinio saugumo rizikos valdymo priemones ir vykdyti jų priežiūrą.

DORA nuo 2025 m. sausio 17 d. taikoma plačiam finansų sektoriaus subjektų ratui ir sukuria sektoriui skirtą veiklos atsparumo režimą. Ji apima IRT rizikos valdymą, reikšmingų su IRT susijusių incidentų pranešimą, skaitmeninio veiklos atsparumo testavimą, keitimąsi informacija, trečiųjų šalių IRT riziką ir sutartinius susitarimus su trečiųjų šalių IRT paslaugų teikėjais. Finansų sektoriaus subjektams ir juos palaikantiems IRT paslaugų teikėjams prieigos kontrolė yra ne tik privatumo klausimas. Ji yra veiklos atsparumo dalis.

ISO/IEC 27001:2022 šiuos įpareigojimus susieja su rizika grindžiama valdymo sistema. 6.1.1–6.1.3 punktai reikalauja, kad organizacijos spręstų rizikas ir galimybes, apibrėžtų informacijos saugumo rizikos vertinimo procesą, identifikuotų rizikas konfidencialumui, vientisumui ir prieinamumui, įvertintų rizikas, pasirinktų tvarkymo galimybes, nustatytų kontrolės priemones, palygintų pasirinktas kontrolės priemones su Annex A, dokumentuotų Taikomumo pareiškimą, gautų rizikos savininko patvirtinimą ir priimtų liekamąsias rizikas. 8.2 ir 8.3 punktai reikalauja rizikos vertinimų planuotais intervalais arba po reikšmingų pokyčių ir rizikos tvarkymo plano įgyvendinimo su dokumentuotais rezultatais.

AII valdysenos kontekste tai reiškia, kad prieigos kontrolė nėra izoliuotas IAM nustatymas. Tai rizikos tvarkymo sprendimas. Vaidmuo, galintis eksportuoti darbo užmokesčio įrašus, pacientų duomenis, mokėjimo informaciją, tapatybės dokumentus, vietos duomenis ar klientų techninės pagalbos pokalbių išrašus, turi būti pagrįstas rizikų registre, atspindėtas Taikomumo pareiškime, įgyvendintas IAM, žurnaluojamas gamybinėje aplinkoje, periodiškai peržiūrimas ir pašalinamas, kai nebereikalingas.

Clarysec kontrolės modelis: nuo privatumo pažado iki įrodymų

Clarysec prieigos prie AII valdyseną vertina kaip įrodymų grandinę. Grandinė prasideda nuo duomenų apskaitos ir vaidmenų apibrėžimo, pereina per prieigos patvirtinimą ir įgyvendinimą, o baigiasi stebėsena, peržiūra, prieigos teisių atšaukimu ir auditui tinkamais įrašais.

Zenith Controls: kelių atitikties režimų vadove ši tema daugiausia siejama su trimis ISO/IEC 27002:2022 kontrolės priemonėmis:

Auditoriai retai priima teiginį „naudojame IAM“ kaip įrodymą. Jie tikisi matyti, kaip IAM sprendimai susieti su privatumo įpareigojimais, sistemos savininkyste, duomenų klasifikavimu, verslo poreikiu, rizikos tvarkymu, prieigos peržiūros periodiškumu, žurnalavimo taikymo sritimi ir tiekėjų sutartimis.

Clarysec AII saugumo ir prieigos kontrolės politika nustato bazinį reikalavimą PIMS kalba:

[Abiem atvejais] Sistemos savininkas / Taikomosios programos savininkas PRIVALO apriboti prieigą prie AII tik patvirtintiems vaidmenims ir autorizuotiems naudotojams, užregistruotiems arba atsekamiems REG02 arba REG12, prieš įjungiant prieigą.

Iš skyriaus „4.2 Prieigos kontrolės baziniai reikalavimai“, politikos punktas 4.2.1.

Žyma „[Abiem atvejais]“ reiškia, kad kontrolės priemonė taikoma nepriklausomai nuo to, ar organizacija veikia kaip AII valdytojas, ar kaip AII tvarkytojas. Šis skirtumas svarbus. Duomenų valdytojai dažnai neapibrėžia tikslais pagrįstų prieigos taisyklių. Duomenų tvarkytojai dažnai neįrodo, kad prieiga ribojama kliento nurodymais, patvirtintais techninės pagalbos keliais ir sutartimi autorizuotais darbuotojais.

Ta pati politika nustato aukštesnį reikalavimų lygį jautriai arba didelio poveikio AII:

[Abiem atvejais] Sistemos savininkas / Taikomosios programos savininkas PRIVALO bent kartą per ketvirtį peržiūrėti naudotojų prieigą prie sistemų, kuriose tvarkoma didelio poveikio arba jautri AII, ir peržiūros rezultatą įrašyti į REG12.

Iš skyriaus „4.2 Prieigos kontrolės baziniai reikalavimai“, politikos punktas 4.2.3.

Čia PIMS tampa audituojama. Prieigos peržiūra nėra vien vadovo el. laiškas. Tai REG12 įrašas, susietas su sistema, duomenų kategorija, vaidmeniu, savininku, peržiūros rezultatu ir taisomuoju veiksmu.

Politikos pagrindas: mažiausios privilegijos, verslo poreikis ir numatytasis draudimas

Veiksminga valdysena prasideda nuo įgyvendinamų taisyklių. Prieš Anjai parodant auditoriui prieigos peržiūros žurnalą, ji turėjo parodyti, kad prieigos peržiūrų reikalavimas yra formaliai nustatytas.

Clarysec MVĮ skirta Prieigos kontrolės politika - SME nustato principą:

Šia politika įgyvendinamas mažiausių privilegijų principas ir reikalaujama, kad prieiga būtų ribojama iki minimalaus lygio, būtino darbo funkcijoms atlikti.

Iš skyriaus „Tikslas“, politikos punktas 1.3.

MVĮ skirta Duomenų apsaugos ir privatumo politika - SME susieja prieigą su verslo poreikiu:

Naudotojų prieiga prie asmens duomenų turi būti ribojama vaidmenims, turintiems dokumentuotą verslo poreikį.

Iš skyriaus „Valdysenos reikalavimai“, politikos punktas 5.3.2.

Didesnėms organizacijoms įmonės lygmens Duomenų apsaugos ir privatumo politika kontrolės lūkestį išreiškia kaip sistemos reikalavimą:

Visos sistemos pagal numatytuosius nustatymus turi įgyvendinti prieigą pagal mažiausių privilegijų principą.

Iš skyriaus „Politikos įgyvendinimo reikalavimai“, politikos punktas 6.3.1.

Skirtumas svarbus. Mažesnei įmonei gali reikėti lengvo, bet aiškaus verslo poreikio įrašo. Įmonei reikia sistemos lygmens įgyvendinimo, periodinės peržiūros, pareigų atskyrimo, privilegijuotos prieigos valdysenos ir įrodymų, saugomų vidaus auditui, klientų patikinimui, reglamentavimo institucijų paklausimams ir pažeidimų tyrimui.

Prieigos prie AII gyvavimo ciklas: patvirtinimas, naudojimas, peržiūra, atšaukimas

Dažniausias prieigos prie AII nesuveikimas nėra pradinis patvirtinimas. Tai prieigos išlikimas.

Zenith Blueprint kontrolės priemonių įgyvendinimo etape, 22 žingsnyje, ISO/IEC 27002:2022 kontrolės priemonę 5.18 „Prieigos teisės“ aiškina taip:

Kontrolė 5.18 užtikrina, kad prieigos teisės būtų ne tik tinkamai suteikiamos, bet ir peržiūrimos, koreguojamos bei atšaukiamos kontroliuojamu ir atsekamu būdu.

Toliau aprašomi pažįstami scenarijai: naujas darbuotojas gauna prieigą, pakeičia vaidmenį ir išlaiko senus leidimus; buvęs administratorius išeina, tačiau prieigos raktas lieka aktyvus; rangovo paskyra popieriuje pasibaigia, bet IAM sistemoje lieka galioti. Būtent šios silpnybės tampa GDPR saugumo incidentais, kai susijusi AII.

Clarysec MVĮ skirta Naudotojų paskyrų ir privilegijų valdymo politika - SME nustato bazinį periodiškumą:

Visų naudotojų paskyrų ir privilegijų peržiūra turi būti atliekama kas šešis mėnesius.

Iš skyriaus „Politikos įgyvendinimo reikalavimai“, politikos punktas 6.4.1.

Įmonių aplinkoms Naudotojų paskyrų ir privilegijų valdymo politika sugriežtina veiklos ritmą:

IT saugumo komanda, bendradarbiaudama su padalinių vadovais, privalo kas ketvirtį atlikti visų naudotojų paskyrų ir susijusių privilegijų peržiūras.

Iš skyriaus „Politikos įgyvendinimo reikalavimai“, politikos punktas 6.5.1.

Praktinis prieigos prie AII gyvavimo ciklas turėtų apimti:

1. Sistemos ir AII kategorijų klasifikavimą.
2. Patvirtintų vaidmenų ir dokumentuoto verslo poreikio apibrėžimą.
3. Vaidmenų susiejimą su tvarkymo tikslais.
4. Prieigos patvirtinimą prieš jos įjungimą.
5. Mažiausių privilegijų principo, pareigų atskyrimo ir stipraus autentifikavimo įgyvendinimą.
6. Autentifikavimo, prieigos, eksporto, konfigūracijos ir privilegijuotų veiksmų žurnalavimą.
7. Prieigos peržiūrą pagal rizika grindžiamą periodiškumą.
8. Prieigos pašalinimą pakeitus vaidmenį, nutraukus darbo santykius, uždarius projektą, pasibaigus sutarčiai arba gavus kliento nurodymą.
9. Įrodymų išsaugojimą PIMS registre ir audito pėdsake.

Tai nėra biurokratija. Taip organizacija įrodo, kad prieiga prie AII valdoma pagal projektavimą, pagal numatytuosius nustatymus ir remiantis įrodymais.

Praktinis pavyzdys: ketvirtinė prieigos prie AII peržiūra

Anjos auditas pavyko tada, kai ji pokalbį perkėlė nuo politikos teiginių prie įrodymų.

Pirmiausia ji nurodė AII saugumo ir prieigos kontrolės politikos 4.2.3 punktą, kuriame reikalaujama kas ketvirtį peržiūrėti prieigą prie didelio poveikio arba jautrios AII ir peržiūros rezultatą įrašyti į REG12.

Tada ji auditoriui parodė praėjusio ketvirčio eigą:

• IT sugeneravo visų naudotojų, grupių, privilegijuotų vaidmenų, paslaugų paskyrų, tiekėjų paskyrų, „break-glass“ vaidmenų ir techninės pagalbos leidimų sąrašą gamybinei duomenų bazei, kurioje saugomi pacientų duomenys.
• Sąrašas buvo perduotas Taikomosios programos savininkui — klientų sėkmės vadovui, kuris buvo atsakingas už techninės pagalbos komandos operacinį poreikį.
• Taikomosios programos savininkas eilutė po eilutės peržiūrėjo sąrašą pagal esamą vaidmenį, klientų techninės pagalbos atsakomybę ir tvarkymo tikslą.
• Du techninės pagalbos specialistai, perėję į kitas komandas, buvo pažymėti prieigos atšaukimui.
• IT paslaugų valdymo sistemoje buvo sukurta užklausa, susieta su prieigos peržiūra, jai priskirtas SLA ir ji uždaryta po prieigos atšaukimo.
• REG12 buvo atnaujintas peržiūros įrašu, tvirtintoju, išimtimis, taisomųjų veiksmų užklausa, uždarymo įrodymais ir kitos peržiūros data.

Rezultatas buvo uždara įrodymų grandinė. Anja ne tik pasakė, kad Medtelligence taiko mažiausių privilegijų principą. Ji parodė politikos reikalavimą, atsakingą savininką, prieigos sąrašą, peržiūros sprendimą, korekcinį veiksmą ir užbaigtą prieigos atšaukimą.

Tai ir yra skirtumas tarp prieigos kontrolės ir prieigos valdysenos.

Tiekėjų ir duomenų tvarkytojų prieiga: akloji zona PIMS audituose

Daugelis neteisėtos prieigos rizikų atsiranda per techninę pagalbą, išorės paslaugas, integracijos partnerius, valdomų paslaugų teikėjus ir subtvarkytojus. Duomenų tvarkytojas gali turėti nuotolinę prieigą prie kliento gamybinių duomenų. Debesijos paslaugų teikėjas gali teikti techninės pagalbos prieigos kelius. Subtvarkytojas gali prižiūrėti paieškos indeksą, kuriame yra klientų identifikatorių. Valdomų saugumo paslaugų teikėjas gali pasiekti žurnalus, kuriuose yra asmens duomenų.

Pagal GDPR duomenų valdytojai turi naudoti duomenų tvarkytojus, suteikiančius pakankamas garantijas. Pagal ISO/IEC 27701:2025 duomenų tvarkytojų ir subtvarkytojų valdysena turi būti perkelta į veiklos lygmenį per dokumentuotus nurodymus, sutarčių kontrolės priemones, patikinimą ir stebėseną. ISO/IEC 27002:2022 tai palaiko per tiekėjų santykių kontrolės priemones, įskaitant 5.19 „Informacijos saugumas santykiuose su tiekėjais“, 5.20 „Informacijos saugumo aptarimas tiekėjų susitarimuose“ ir 5.21 „Informacijos saugumo valdymas IRT tiekimo grandinėje“.

Zenith Blueprint kontrolės priemonių įgyvendinimo etape, 23 žingsnyje, tiekėjų susitarimų įrodymų sritis apibendrina taip:

✓ Prieigos kontrolės atsakomybės, pavyzdžiui, kas gali pasiekti jūsų duomenis, kaip valdomi prisijungimo duomenys ir kokia stebėsena taikoma;

Į jas taip pat įeina konfidencialumo įsipareigojimai, techninės ir organizacinės priemonės, pranešimų apie incidentus terminai, teisės atlikti auditą, subtiekėjų kontrolės priemonės ir paskyrų deaktyvavimas pasibaigus sutarčiai.

Clarysec Duomenų tvarkytojų, subtvarkytojų ir trečiųjų šalių privatumo valdymo politika tai paverčia duomenų valdytojo pusės PIMS įrodymais:

[Duomenų valdytojas] Privatumo vadovas / PIMS vadovas PRIVALO prieš patvirtinimą patikrinti, ar duomenų tvarkytojo sutarčių kontrolės laukai REG08 apima tvarkymo taikymo sritį, trukmę, tikslą, AII kategorijas, duomenų subjektų kategorijas, konfidencialumą, saugumą, subtvarkytojų autorizavimą, pagalbą, auditą arba patikinimą, grąžinimą, ištrynimą ir nutraukimą.

Iš skyriaus „4.3 Sutarčių ir dokumentuotų nurodymų kontrolės priemonės“, politikos punktas 4.3.2.

Tiekėjų prieiga taip pat tiesiogiai valdoma Clarysec MVĮ ir įmonės tiekėjų politikose. MVĮ skirta Trečiųjų šalių ir tiekėjų saugumo politika - SME nustato:

Tiekėjams turi būti suteikiama prieiga tik prie minimalių sistemų ir duomenų, reikalingų jų funkcijai atlikti.

Iš skyriaus „Politikos įgyvendinimo reikalavimai“, politikos punktas 6.2.1.

Įmonės lygmens Trečiųjų šalių ir tiekėjų saugumo politika papildo RBAC, peržiūra ir mažiausių privilegijų principu:

Tiekėjų personalui turi būti taikoma vaidmenimis pagrįsta prieigos kontrolė (RBAC), periodinės prieigos peržiūros ir mažiausių privilegijų principo įgyvendinimas.

Iš skyriaus „Politikos įgyvendinimo reikalavimai“, politikos punktas 6.3.1.

Jei tiekėjo prieiga gali pasiekti AII, ji priklauso PIMS taikymo sričiai. Ji turi atsispindėti sutarčių kontrolės priemonėse, prieigos patvirtinimuose, IAM grupėse, žurnalavimo taikymo srityje, peržiūros įrašuose, darbo santykių arba paslaugų nutraukimo įrašuose, incidentų veiksmų planuose ir audito įrodymuose.

Prieiga prie AII debesijoje: bendra atsakomybė nėra bendra atskaitomybė

Prieigos prie AII valdysena debesijoje yra sritis, kurioje organizacijos dažnai pervertina paslaugų teikėją ir nepakankamai įvertina savo atsakomybes. Debesijos paslaugų teikėjas gali saugoti infrastruktūrą, tačiau klientas vis tiek valdo tapatybes, vaidmenis, nuomininko konfigūraciją, techninės pagalbos prieigą, žurnalus, šifravimo nustatymus, eksporto leidimus ir pasirengimą reaguoti į incidentus.

Zenith Blueprint kontrolės priemonių įgyvendinimo etape, 23 žingsnyje, debesijos paslaugų gairėse tai įvardija tiesiogiai:

Debesijos paslaugų teikėjai saugo infrastruktūrą, tačiau jūs vis tiek esate atskaitingi už savo duomenis, konfigūracijas, prieigos politikas ir pasirengimą reaguoti į incidentus.

Taip pat įspėjama:

Debesijoje matomumas yra dalinis, jei jis nėra sąmoningai suprojektuotas. Turite sukonfigūruoti žurnalavimą, įgyvendinti šifravimą, apibrėžti tapatybės vaidmenis ir stebėti veiklą naudodami vietines priemones arba trečiųjų šalių integracijas. Tai nėra infrastruktūros užduotis — tai ISVS reikalavimas.

Clarysec Debesijos paslaugų naudojimo politika tai paverčia įmonės prieigos reikalavimu:

Visose debesijos paslaugose turi būti taikoma tapatybe pagrįsta prieigos kontrolė, suderinta su mažiausių privilegijų principu.

Iš skyriaus „Politikos įgyvendinimo reikalavimai“, politikos punktas 6.2.1.

Organizacijoms, kurios debesijos aplinkose veikia kaip duomenų tvarkytojai, Clarysec Debesijos AII tvarkytojo politika nustato konkretesnį PIMS peržiūros įpareigojimą:

[Duomenų tvarkytojas] Informacijos saugumo vadovas PRIVALO bent kartą per ketvirtį REG12 peržiūrėti privilegijuotą debesijos prieigą, techninės pagalbos prieigą, klientų AII prieigą ir žurnalavimo aprėptį.

Iš skyriaus „4.2 Debesijos konfigūracija, nuomininkų izoliavimas, prieiga ir žurnalavimas“, politikos punktas 4.2.4.

Šis punktas ypač aktualus SaaS įmonėms, debesijoje veikiančioms platformoms, valdomoms duomenų paslaugoms ir B2B duomenų tvarkytojams.

Prieigos prie AII valdysena debesijoje nėra užbaigta, jei kartu neperžiūrimi debesijos žurnalai, IAM politikos, paslaugų paskyros, privilegijuoti vaidmenys, klientų techninės pagalbos įrankiai, API raktai ir duomenų eksporto funkcijos.

Žurnalų tvarkymas ir stebėsena: AII valdysenos atmintis

PIMS prieigos kontrolės programa be žurnalų yra pažadas be atminties.

AII saugumo ir prieigos kontrolės politika reikalauja apibrėžti žurnalavimo taikymo sritį prieš naudojimą gamybinėje aplinkoje arba esminį pakeitimą:

[Abiem atvejais] Sistemos savininkas / Taikomosios programos savininkas PRIVALO REG12 apibrėžti AII žurnalavimo taikymo sritį autentifikavimo įvykiams, prieigos įvykiams, privilegijuotiems veiksmams, AII eksporto veiklai ir esminiams konfigūracijos pakeitimams prieš naudojimą gamybinėje aplinkoje arba esminį pakeitimą.

Iš skyriaus „4.6 Žurnalų tvarkymas ir stebėsena“, politikos punktas 4.6.1.

MVĮ skirta Žurnalų tvarkymo ir stebėsenos politika - SME aiškiai įvardija prieigos žurnalų turinį:

Prieigos žurnalai: failų prieiga, ypač prie jautrių arba asmens duomenų, leidimų pakeitimai, bendrinamų išteklių naudojimas.

Iš skyriaus „Valdysenos reikalavimai“, politikos punktas 5.4.3.

Įmonės lygmens Žurnalų tvarkymo ir stebėsenos politika orientuota į audito panaudojamumą:

ISVS audito pėdsako registre turi būti registruojamas žurnalų duomenų prieinamumas auditams, tyrimams ir reglamentavimo institucijų peržiūroms.

Iš skyriaus „Valdysenos reikalavimai“, politikos punktas 5.4.

Tai kritiškai svarbu, nes privatumo įrodymai dažnai turi atsakyti į įvykiais pagrįstus klausimus:

• Kas pasiekė AII?
• Ar prieiga buvo autorizuota?
• Ar prieiga buvo susieta su techninės pagalbos užklausa, teisiniu prašymu, operacine užduotimi arba kliento nurodymu?
• Ar duomenys buvo eksportuoti, nukopijuoti, pakeisti arba ištrinti?
• Ar buvo naudota privilegijuota prieiga?
• Ar leidimai buvo pakeisti prieš prieigą ar po jos?
• Ar veikla rodė saugumo incidentą arba asmens duomenų saugumo pažeidimą?

Žurnalai skirti ne tik SOC. Jie yra PIMS įrodymai, klientų patikinimo įrodymai, duomenų tvarkytojų patikinimo įrodymai ir reagavimo į incidentus įrodymai.

Kelių atitikties režimų susiejimas: vienas prieigos modelis, daug požiūrio kampų

AII prieigos peržiūrų silpnybė niekada nėra tik viena išvada. Ji gali tapti GDPR atskaitomybės problema, ISO/IEC 27701:2025 PIMS silpnybe, ISO/IEC 27001:2022 neatitiktimi, NIS2 valdysenos nesėkme, DORA atsparumo klausimu, NIST CSF 2.0 valdysenos spraga arba COBIT 2019 procesų brandos problema.

Išsamesnė kontrolės priemonių susiejimo lentelė parodo, kaip vienas prieigos prie AII valdysenos procesas palaiko kelis reikalavimus:

Zenith Controls vertė yra ta, kad komandos gali susieti šiuos požiūrio kampus su tais pačiais kontrolės įrodymais, o ne palaikyti atskirus atitikties silosus.

Atlikite 45 minučių prieigos prie AII įrodymų sprintą

Naudingas būdas patikrinti pasirengimą — pasirinkti vieną didelio poveikio sistemą, pavyzdžiui, klientų techninės pagalbos platformą, HR sistemą, mokėjimų portalą, pacientų portalą, duomenų ežerą arba SaaS gamybinę duomenų bazę, ir atlikti tikslinį įrodymų sprintą.

1 žingsnis: apibrėžkite AII tvarkymo kontekstą

REG12 įrašykite:

• Sistemos pavadinimą ir savininką
• AII kategorijas
• Duomenų subjektų kategorijas
• Duomenų valdytojo arba duomenų tvarkytojo vaidmenį
• Tvarkymo tikslą
• Didelio poveikio arba jautrios AII indikatorių
• Debesijos, tiekėjų ir subtvarkytojų priklausomybes

Jei sistemoje dalyvauja duomenų tvarkytojas, patikrinkite REG08 sutarčių kontrolės laukus naudodami Duomenų tvarkytojų, subtvarkytojų ir trečiųjų šalių privatumo valdymo politiką. Patvirtinimas turi apimti tvarkymo taikymo sritį, trukmę, tikslą, AII kategorijas, duomenų subjektų kategorijas, konfidencialumą, saugumą, subtvarkytojų autorizavimą, pagalbą, auditą arba patikinimą, grąžinimą, ištrynimą ir nutraukimą.

2 žingsnis: ištraukite prieigos sąrašą

Eksportuokite visus naudotojus, grupes, privilegijuotus vaidmenis, paslaugų paskyras, techninės pagalbos vaidmenis, „break-glass“ paskyras, API raktus ir tiekėjų paskyras. Palyginkite kiekvieną prieigos teisę su patvirtintais vaidmenimis.

3 žingsnis: patvirtinkite mažiausias privilegijas ir suderinimą su tikslu

Naudokite AII saugumo ir prieigos kontrolės politikos bazinį reikalavimą: prieiga turi būti ribojama patvirtintiems vaidmenims ir autorizuotiems naudotojams, užregistruotiems arba atsekamiems REG02 arba REG12, prieš įjungiant prieigą. Jei naudotojo negalima atsekti iki vaidmens, tikslo ir patvirtinimo, išvada nėra „trūksta dokumentacijos“. Išvada yra „prieiga prie AII nėra įrodomai autorizuota“.

4 žingsnis: patikrinkite žurnalavimo taikymo sritį

Patvirtinkite, kad žurnalai fiksuoja autentifikavimą, prieigos įvykius, privilegijuotus veiksmus, AII eksporto veiklą ir esminius konfigūracijos pakeitimus. Tada patvirtinkite, kur žurnalai saugomi, kiek laiko jie saugomi, kas gali juos pasiekti ir ar jie įrašyti į ISVS audito pėdsako registrą auditams, tyrimams ir reglamentavimo institucijų peržiūroms.

5 žingsnis: uždarykite ciklą

Kiekvienai išimčiai įrašykite rizikos savininką, nedelsiamą suvaldymo veiksmą, nuolatinį trūkumų šalinimą, tikslinę datą, reikalingus įrodymus, liekamosios rizikos sprendimą ir ar reikalingas pažeidimo vertinimas.

Šis vienas pratimas paprastai atskleidžia tikrąją prieigos prie AII valdysenos brandą. Stiprios organizacijos gali atsakyti greitai. Silpnos organizacijos pamato, kad privatumo politika, IAM konfigūracija, duomenų tvarkytojų sutartys, debesijos žurnalavimas ir audito įrodymai yra atsieti.

Dažnos audito išvados prieigos prie AII valdysenoje

Dauguma išvadų yra nuspėjamos. Jos atsiranda tada, kai privatumas, saugumas, teisė, IT ir tiekėjai valdo po dalį istorijos, tačiau niekas nevaldo viso prieigos prie AII gyvavimo ciklo.

Dažnos išvados:

• AII sistemos nėra visiškai įtrauktos į PIMS apskaitą.
• Prieigos vaidmenys apibrėžti techniškai, bet nesusieti su tvarkymo tikslais.
• Jautri AII pasiekiama per plačias operacines grupes.
• Ketvirtinės peržiūros apima darbuotojus, bet ne paslaugų paskyras, API raktus ar tiekėjų naudotojus.
• Debesijos techninės pagalbos prieiga yra galima, bet neperžiūrima kaip prieiga prie AII.
• Žurnalai egzistuoja, bet neįrodo prieigos prie AII, eksporto ar privilegijuotos veiklos.
• Duomenų tvarkytojų sutartyse yra bendros konfidencialumo nuostatos, bet nėra konkrečių prieigos kontrolės, audito, subtvarkytojų, grąžinimo, ištrynimo ar nutraukimo kontrolės priemonių.
• Buvę darbuotojai ar rangovai išlaiko prieigą per bendras grupes arba nevaldomus prieigos raktus.
• Duomenų saugyklos prieiga yra platesnė nei pirminės taikomosios programos prieiga.
• „Break-glass“ paskyros egzistuoja be peržiūros po naudojimo.
• Klientų techninės pagalbos naudotojo imitavimas nežurnaluojamas su užklausos kontekstu.
• Taikomumo pareiškime įtrauktos prieigos kontrolės priemonės, tačiau įrodymai nerodo AII specifinio įgyvendinimo.

Kiekviena iš šių išvadų, priklausomai nuo taikymo srities, gali tapti GDPR atskaitomybės problema, klientų patikinimo klausimu, NIS2 arba DORA valdysenos silpnybe arba ISO/IEC 27001:2022 neatitiktimi.

Kaip atrodo geras modelis

Brandus veiklos modelis nesiremia herojišku ketvirtiniu tvarkymu. Jis įtraukia prieigos prie AII valdyseną į įprastas operacijas.

Pirma, organizacija supranta savo duomenis. Ji žino, kur yra AII, kodėl ji tvarkoma, kuris PIMS vaidmuo taikomas ir kurios sistemos, tiekėjai, debesijos paslaugos, žurnalai, atsarginės kopijos ir eksportai patenka į taikymo sritį.

Antra, prieiga yra vaidmenimis pagrįsta ir suderinta su tikslais. Leidimai apibrėžiami pagal patvirtintus vaidmenis, dokumentuotą verslo poreikį, tvarkymo tikslą ir mažiausių privilegijų principą.

Trečia, kontrolės priemonės įgyvendinamos techniškai. IAM, RBAC, privilegijuotos prieigos valdymas, MFA, sąlyginė prieiga, nuomininko kontrolės priemonės, šifravimas ir aplinkų atskyrimas įgyvendina politikos lūkesčius.

Ketvirta, stebėsena yra sąmoningai suprojektuota. Organizacija gali atkurti autentifikavimo, prieigos, eksporto, privilegijuotų veiksmų, techninės pagalbos prieigos ir konfigūracijos pakeitimus, darančius poveikį AII.

Penkta, peržiūros yra rizika grindžiamos ir dokumentuotos. Didelio poveikio AII peržiūrima bent kartą per ketvirtį. Įtraukiama tiekėjų ir debesijos techninės pagalbos prieiga. Išimtys sekamos iki uždarymo.

Šešta, įrodymai yra pakartotinai panaudojami. Tie patys įrašai palaiko GDPR atskaitomybę, ISO/IEC 27701:2025 PIMS veikimą, ISO/IEC 27001:2022 rizikos tvarkymą, NIS2 rizikos valdymo priemones, DORA IRT rizikos valdyseną, NIST CSF 2.0 GOVERN rezultatus ir COBIT 2019 valdymo patikinimą.

Tai skirtumas tarp prieigos kontrolės kaip nustatymo ir prieigos valdysenos kaip sistemos.

Paverskite prieigą prie AII auditui tinkamais įrodymais

Jei jūsų kitas auditas, kliento peržiūra ar reglamentavimo institucijos paklausimas rytoj prasidėtų klausimu „parodykite, kas gali pasiekti AII“, ar jūsų komanda pateiktų įrodymus per kelias minutes, ar pradėtų derinti skaičiuokles?

Clarysec gali padėti uždaryti šią spragą.

Pradėkite nuo AII saugumo ir prieigos kontrolės politikos, suderinkite duomenų tvarkytojų ir debesijos įpareigojimus per Duomenų tvarkytojų, subtvarkytojų ir trečiųjų šalių privatumo valdymo politiką ir Debesijos AII tvarkytojo politiką, tada naudokite Zenith Blueprint: auditoriaus 30 žingsnių veiksmų planą, kad kontrolės priemones įgyvendintumėte tinkama seka. Galiausiai naudokite Zenith Controls: kelių atitikties režimų vadovą, kad susietumėte prieigos prie AII įrodymus pagal ISO/IEC 27701:2025, GDPR, ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIS2, DORA, NIST CSF 2.0 ir COBIT 2019.

Greičiausias praktinis kitas žingsnis paprastas: pasirinkite vieną didelio poveikio AII sistemą, užpildykite REG12, eksportuokite prieigos sąrašą, patikrinkite žurnalavimo taikymo sritį ir atlikite ketvirtinio tipo peržiūrą. Per vieną sesiją žinosite, ar jūsų prieigos prie AII valdysena yra tinkama auditui, ar tik tinkama politikai.