Piekļuves pārvaldība personu identificējošai informācijai ISO 27701:2025 un GDPR kontekstā

Ārējā auditora jautājums palika gaisā — šķietami vienkāršs.

“Vai varat parādīt piekļuves tiesību pārskatīšanas reģistru par jūsu atbalsta komandas piekļuvi PII ražošanas vidē pēdējā ceturksnī?”

Anjai, Medtelligence CISO, tas bija patiesības brīdis. Medtelligence ir strauji augošs veselības tehnoloģiju SaaS pakalpojumu sniedzējs, kas slimnīcu vārdā darbojas kā PII apstrādātājs un mākoņplatformā apstrādā sensitīvus pacientu datus. Uzņēmumam bija spēcīga autentifikācija, definētas lomas un nobriedusi inženierijas komanda. Taču auditors nejautāja, vai pastāv pieteikšanās lapa. Viņš prasīja pierādījumus, ka piekļuve personas datiem laika gaitā tiek pārvaldīta.

Viņš vēlējās redzēt, kas var piekļūt PII ražošanas vidē, kāpēc šāda piekļuve ir piešķirta, kad tā apstiprināta, vai tā joprojām ir nepieciešama, vai atbalsta darbības tiek žurnalētas un vai nevajadzīgās piekļuves tiesības ir noņemtas.

Anja atvēra IAM konsoli. Tur bija atbalsta inženieri, datubāzu administratori, integrācijas pakalpojumu konts, pārvaldīto pakalpojumu sniedzējs, divas ārkārtas piekļuves lomas un bijušais līgumdarbinieks, kas joprojām atradās grupā, jo darba attiecību izbeigšanas procesa pieteikums bija slēgts pirms attiecīgo tiesību noņemšanas. HR datos bija redzams, ka persona uzņēmumu pametusi pirms sešām nedēļām. Piekļuves tiesību pārskatīšanas izklājlapā bija norāde “gaida izpildi”. SIEM saturēja žurnālus, taču neviens nebija sasaistījis, kuri notikumi pierāda piekļuvi PII.

Tieši šajā brīdī privātuma pārvaldība kļūst reāla.

Saskaņā ar GDPR personas dati jāapstrādā, nodrošinot integritāti un konfidencialitāti, un ar atbilstošiem tehniskiem un organizatoriskiem pasākumiem jāaizsargā pret neatļautu vai nelikumīgu apstrādi, nejaušu nozaudēšanu, iznīcināšanu vai bojājumu. GDPR arī skaidri nostiprina pārskatatbildību: pārzinim jāspēj pierādīt atbilstību. ISO/IEC 27701:2025 šo pārskatatbildību pārvērš privātuma informācijas pārvaldības sistēmā jeb PIMS, kur piekļuve PII vairs nav tehniska pēcdoma. Tā kļūst par pārvaldītu dzīves ciklu, kas aptver lomas, apstrādātājus, mākoņplatformas, darbiniekus, priviliģētos administratorus, žurnālus, pārskatīšanu, līgumus un pierādījumus.

Daudzām organizācijām problēma nav piekļuves kontroles trūkums. Problēma ir nespēja konsekventi pierādīt PII piekļuves pārvaldību ISO/IEC 27701:2025, GDPR, ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIS2, DORA, NIST CSF 2.0 un COBIT 2019 ietvaros.

PII piekļuves pārvaldība nav tikai IAM

Tradicionāla IAM programma uzdod jautājumu: “Vai pareizie lietotāji var piekļūt pareizajām sistēmām?”

Nobriedusi ISO/IEC 27701:2025 PIMS uzdod stingrākus jautājumus:

• Kuras sistēmas apstrādā PII?
• Kurām lomām nepieciešama piekļuve konkrētām PII kategorijām?
• Vai organizācija darbojas kā PII pārzinis, apstrādātājs, kopīgs pārzinis vai apakšapstrādātājs?
• Vai piekļuve ir ierobežota atbilstoši nolūkam, dokumentētai biznesa vajadzībai un minimāli nepieciešamajām tiesībām?
• Vai priviliģētas darbības tiek žurnalētas un pārskatītas?
• Vai organizācija var pierādīt, ka apstrādātāja un apakšapstrādātāja piekļuve tiek kontrolēta līgumiski?
• Vai pierādījumos ir iekļauti mākoņpakalpojumu atbalsta piekļuves ceļi, nomnieku izolācija, eksporta darbības un administratīvās darbības?
• Vai piekļuves lēmumi tiek pārskatīti pēc ievadīšanas darbā, lomas maiņas, incidenta, darba attiecību izbeigšanas un būtiskām sistēmas izmaiņām?

Tāpēc PII drošības un piekļuves kontroles pārvaldība ir dabisks tilts starp ISO/IEC 27701:2025 un GDPR. GDPR nodrošina tiesisko pārskatatbildības ietvaru. ISO/IEC 27701:2025 operacionalizē privātuma pārvaldību pārziņiem un apstrādātājiem. ISO/IEC 27001:2022 nodrošina IDPS risku pārvaldības mehānismu. ISO/IEC 27002:2022 nodrošina kontroles pasākumu arhitektūru, tostarp privātumu un PII aizsardzību, piekļuves kontroli, piekļuves tiesības, žurnalēšanu, mākoņpakalpojumus, piegādātāju attiecības, klasifikāciju, dzēšanu, maskēšanu un kriptogrāfiju.

Clarysec Zenith Blueprint: An Auditor’s 30-Step Roadmap šo tēmu ievieto Controls in Action fāzē. 23. solī, kas aptver organizatoriskos kontroles pasākumus no 5.19 līdz 5.37, ISO/IEC 27002:2022 kontroles pasākums 5.34 Privacy and Protection of PII tiek raksturots kā uzticēšanās jautājums, nevis tikai datu jautājums:

personu identificējoša informācija nav tikai vēl viens datu tips — tā ir ļoti sensitīvs uzticēšanās atspoguļojums. Vārdi, adreses, identifikatori, veselības ieraksti, finanšu informācija — šie dati stāsta par reāliem cilvēkiem.

Tajā pašā fragmentā ir dots praktiskais pamats: privātuma aizsardzība sākas ar datu pārzināšanu. Organizācijai jāzina, kādus PII tā vāc, kur tie atrodas, kāpēc tie tiek apstrādāti un kas tiem var piekļūt.

Atbilstības spiediens PII piekļuves kontroles pamatā

PII piekļuves pārvaldība vairs nav viena ietvara jautājums. Tādas organizācijas kā Medtelligence darbojas privātuma regulējuma, kiberdrošības tiesību aktu, darbības noturības, klientu apliecinājuma un drošības sertifikācijas krustpunktā.

GDPR Article 5 prasa personas datus apstrādāt saskaņā ar likumīguma, godprātības, pārredzamības, nolūka ierobežojuma, datu minimizēšanas, precizitātes, glabāšanas ierobežojuma, integritātes un konfidencialitātes principiem. Article 5(2) ievieš pārskatatbildību: pārzinis ir atbildīgs par atbilstību un tam jāspēj to pierādīt. Article 32 savukārt prasa piemērot atbilstošus tehniskus un organizatoriskus pasākumus apstrādes drošībai.

NIS2 Article 21 prasa būtiskām un svarīgām vienībām īstenot atbilstošus un samērīgus tehniskus, operatīvus un organizatoriskus kiberdrošības risku pārvaldības pasākumus. Minimālās jomas ietver riska analīzi, drošības politikas, incidentu apstrādi, darbības nepārtrauktību, piegādes ķēdes drošību, drošu iegādi un izstrādi, efektivitātes izvērtēšanu, kiberdrošības higiēnu un apmācības, kriptogrāfiju, HR drošību, piekļuves kontroli, aktīvu pārvaldību un, ja nepieciešams, daudzfaktoru autentifikāciju vai nepārtrauktu autentifikāciju un drošu saziņu. Article 20 arī nosaka vadības struktūru atbildību apstiprināt un pārraudzīt kiberdrošības risku pārvaldības pasākumus.

DORA no 2025. gada 17. janvāra attiecas uz plašu finanšu vienību loku un ievieš nozarei specifisku darbības noturības režīmu. Tas aptver IKT risku pārvaldību, būtisku ar IKT saistītu incidentu ziņošanu, digitālās darbības noturības testēšanu, informācijas apmaiņu, IKT trešo pušu risku un līgumiskās vienošanās ar IKT trešo pušu pakalpojumu sniedzējiem. Finanšu vienībām un IKT pakalpojumu sniedzējiem, kas tās atbalsta, piekļuves kontrole nav tikai privātuma jautājums. Tā ir daļa no darbības noturības.

ISO/IEC 27001:2022 sasaista šos pienākumus ar uz risku balstītu pārvaldības sistēmu. Clauses 6.1.1 līdz 6.1.3 prasa organizācijām risināt riskus un iespējas, definēt informācijas drošības riska novērtēšanas procesu, identificēt konfidencialitātes, integritātes un pieejamības riskus, izvērtēt riskus, izvēlēties riska apstrādes iespējas, noteikt kontroles pasākumus, salīdzināt izvēlētos kontroles pasākumus ar Annex A, dokumentēt Piemērojamības paziņojumu, saņemt riska īpašnieka apstiprinājumu un pieņemt atlikušos riskus. Clauses 8.2 un 8.3 prasa veikt risku izvērtēšanu plānotos intervālos vai pēc būtiskām izmaiņām un īstenot Risku apstrādes plānu ar dokumentētiem rezultātiem.

PII pārvaldības kontekstā tas nozīmē, ka piekļuves kontrole nav izolēts IAM iestatījums. Tas ir riska apstrādes lēmums. Loma, kas var eksportēt algu uzskaites ierakstus, pacientu datus, maksājumu informāciju, identitātes dokumentus, atrašanās vietas datus vai klientu atbalsta sarakstes, jāpamato Risku reģistrā, jāatspoguļo Piemērojamības paziņojumā, jāievieš IAM, jāžurnalē ražošanas vidē, periodiski jāpārskata un jānoņem, kad tā vairs nav nepieciešama.

Clarysec kontroles modelis: no privātuma solījuma līdz pierādījumiem

Clarysec PII piekļuves pārvaldību uztver kā pierādījumu ķēdi. Ķēde sākas ar datu uzskaiti un lomu definēšanu, turpinās ar piekļuves apstiprināšanu un ieviešanu un noslēdzas ar uzraudzību, pārskatīšanu, piekļuves atsaukšanu un auditam gataviem ierakstiem.

Zenith Controls: The Cross-Compliance Guide šī tēma galvenokārt ir saistīta ar trim ISO/IEC 27002:2022 kontroles pasākumiem:

Auditori reti pieņem “mēs izmantojam IAM” kā pierādījumu. Viņi sagaida redzēt, kā IAM lēmumi sasaistās ar privātuma pienākumiem, sistēmas īpašumtiesībām, datu klasifikāciju, biznesa vajadzību, riska apstrādi, piekļuves tiesību pārskatīšanas biežumu, žurnalēšanas tvērumu un piegādātāju līgumiem.

Clarysec PII Security and Access Control Policy nosaka pamatlīmeni PIMS valodā:

[Both] Sistēmas īpašniekam / Lietojumprogrammas īpašniekam JĀIEROBEŽO piekļuve PII līdz apstiprinātām lomām un pilnvarotiem lietotājiem, kas pirms piekļuves aktivizēšanas ir reģistrēti vai izsekojami REG02 vai REG12.

No sadaļas “4.2 Piekļuves kontroles pamatlīmenis”, politikas punkts 4.2.1.

Atzīme “[Both]” nozīmē, ka kontroles pasākums ir piemērojams neatkarīgi no tā, vai organizācija darbojas kā PII pārzinis vai PII apstrādātājs. Šī atšķirība ir būtiska. Pārziņi bieži nespēj definēt uz nolūku balstītus piekļuves noteikumus. Apstrādātāji bieži nespēj pierādīt, ka piekļuve ir ierobežota ar klienta norādījumiem, apstiprinātiem atbalsta piekļuves ceļiem un līgumiski pilnvarotu personālu.

Tā pati politika paaugstina prasību līmeni sensitīviem vai augstas ietekmes PII:

[Both] Sistēmas īpašniekam / Lietojumprogrammas īpašniekam vismaz reizi ceturksnī JĀPĀRSKATA lietotāju piekļuve sistēmām, kurās tiek apstrādāti augstas ietekmes vai sensitīvi PII, un pārskatīšanas rezultāts JĀREĢISTRĒ REG12.

No sadaļas “4.2 Piekļuves kontroles pamatlīmenis”, politikas punkts 4.2.3.

Tieši šeit PIMS kļūst auditējama. Piekļuves tiesību pārskatīšana nav tikai vadītāja e-pasts. Tas ir ieraksts REG12, sasaistīts ar sistēmu, datu kategoriju, lomu, īpašnieku, pārskatīšanas rezultātu un korektīvo pasākumu.

Politikas pamats: minimāli nepieciešamās tiesības, biznesa vajadzība un noklusējuma liegums

Efektīva pārvaldība sākas ar ieviešamiem noteikumiem. Pirms Anja varēja auditoram parādīt piekļuves tiesību pārskatīšanas reģistru, viņai bija jāparāda, ka piekļuves tiesību pārskatīšanas prasība ir formāli noteikta.

Clarysec SME Access Control Policy - SME nosaka principu:

Šī politika piemēro minimālo privilēģiju principu un prasa, lai piekļuve būtu ierobežota līdz darba pienākumu izpildei minimāli nepieciešamajam apjomam.

No sadaļas “Mērķis”, politikas punkts 1.3.

SME Data Protection and Privacy Policy - SME sasaista piekļuvi ar biznesa vajadzību:

Lietotāju piekļuve personas datiem jāierobežo līdz lomām ar dokumentētu biznesa vajadzību.

No sadaļas “Pārvaldības prasības”, politikas punkts 5.3.2.

Lielākām organizācijām uzņēmuma līmeņa Data Protection and Privacy Policy kontroles prasību formulē kā sistēmas prasību:

Visām sistēmām pēc noklusējuma jāievieš piekļuve saskaņā ar minimālo privilēģiju principu.

No sadaļas “Politikas ieviešanas prasības”, politikas punkts 6.3.1.

Šī atšķirība ir svarīga. Mazākam uzņēmumam var būt nepieciešams vienkāršots, bet skaidrs biznesa vajadzības ieraksts. Uzņēmuma līmeņa organizācijai nepieciešama sistēmas līmeņa ieviešana, periodiska pārskatīšana, pienākumu nodalīšana, priviliģētās piekļuves pārvaldība un pierādījumi, kas saglabāti iekšējam auditam, klientu apliecinājumiem, regulatoru pieprasījumiem un pārkāpumu izmeklēšanai.

PII piekļuves dzīves cikls: apstiprināšana, izmantošana, pārskatīšana, atsaukšana

Biežākā PII piekļuves kļūme nav sākotnējā apstiprināšana. Tā ir piekļuves saglabāšanās.

Zenith Blueprint Controls in Action fāzes 22. solī ISO/IEC 27002:2022 kontroles pasākums 5.18 Access Rights tiek skaidrots šādi:

Kontrole 5.18 nodrošina, ka piekļuves tiesības tiek ne tikai atbilstoši piešķirtas, bet arī kontrolētā un izsekojamā veidā pārskatītas, pielāgotas un atsauktas.

Pēc tam tiek aprakstīti pazīstami scenāriji: jauns darbinieks saņem piekļuvi, maina lomu un saglabā vecās tiesības; bijušais administrators aiziet, bet marķieris paliek aktīvs; līgumdarbinieka konta termiņš dokumentos beidzas, bet IAM tas paliek aktīvs. Tieši šīs vājās vietas kļūst par GDPR drošības incidentiem, ja tajās iesaistīti PII.

Clarysec SME User Account and Privilege Management Policy - SME nosaka pamatperiodiskumu:

Visu lietotāju kontu un privilēģiju pārskatīšana jāveic ik pēc sešiem mēnešiem.

No sadaļas “Politikas ieviešanas prasības”, politikas punkts 6.4.1.

Uzņēmuma vidēm User Account and Privilege Management Policy nosaka stingrāku darbības ritmu:

IT drošības funkcijai sadarbībā ar struktūrvienību vadītājiem jāveic visu lietotāju kontu un saistīto privilēģiju ceturkšņa pārskatīšana.

No sadaļas “Politikas ieviešanas prasības”, politikas punkts 6.5.1.

Praktiskam PII piekļuves dzīves ciklam jāietver:

1. Sistēmas un PII kategoriju klasificēšana.
2. Apstiprināto lomu un dokumentētās biznesa vajadzības definēšana.
3. Lomu sasaiste ar apstrādes nolūkiem.
4. Piekļuves apstiprināšana pirms aktivizēšanas.
5. Minimāli nepieciešamo tiesību, pienākumu nodalīšanas un spēcīgas autentifikācijas ieviešana.
6. Autentifikācijas, piekļuves, eksporta, konfigurācijas un priviliģēto darbību žurnalēšana.
7. Piekļuves pārskatīšana atbilstoši uz risku balstītam pārskatīšanas periodiskumam.
8. Piekļuves noņemšana lomas maiņas, darba attiecību izbeigšanas, projekta noslēguma, līguma termiņa beigām vai klienta norādījuma gadījumā.
9. Pierādījumu saglabāšana PIMS reģistrā un auditācijas pēdā.

Tā nav birokrātija. Tas ir veids, kā organizācija pierāda, ka PII piekļuve tiek kontrolēta pēc projektēšanas, pēc noklusējuma un ar pierādījumiem.

Praktisks piemērs: ceturkšņa PII piekļuves tiesību pārskatīšana

Anjas audits izdevās brīdī, kad viņa sarunu pārcēla no politikas paziņojumiem uz pierādījumiem.

Vispirms viņa atsaucās uz PII Security and Access Control Policy punktu 4.2.3, kas prasīja vismaz reizi ceturksnī pārskatīt piekļuvi augstas ietekmes vai sensitīviem PII un pārskatīšanas rezultātu reģistrēt REG12.

Pēc tam viņa auditoram izskaidroja iepriekšējo ceturksni:

• IT izveidoja visu lietotāju, grupu, priviliģēto lomu, pakalpojumu kontu, piegādātāju kontu, ārkārtas piekļuves lomu un atbalsta piekļuves tiesību sarakstu ražošanas datubāzei, kurā atrodas pacientu dati.
• Saraksts tika nosūtīts lietojumprogrammas īpašniekam — klientu panākumu nodaļas vadītājam, kurš pārvaldīja atbalsta komandas operatīvo vajadzību.
• Lietojumprogrammas īpašnieks pārskatīja sarakstu rindu pa rindai, salīdzinot to ar aktuālo lomu, klientu atbalsta atbildību un apstrādes nolūku.
• Divi atbalsta speciālisti, kuri bija pārcelti uz citām komandām, tika atzīmēti piekļuves atsaukšanai.
• IT pakalpojumu pārvaldības sistēmā tika izveidots pieteikums, sasaistīts ar piekļuves tiesību pārskatīšanu, tam tika piešķirts SLA, un pēc piekļuves atsaukšanas tas tika slēgts.
• REG12 tika atjaunināts ar pārskatīšanas ierakstu, apstiprinātāju, izņēmumiem, korektīvā pasākuma pieteikumu, slēgšanas pierādījumiem un nākamās pārskatīšanas datumu.

Rezultāts bija slēgta pierādījumu ķēde. Anja ne tikai pateica, ka Medtelligence izmanto minimāli nepieciešamās tiesības. Viņa parādīja politikas prasību, atbildīgo īpašnieku, piekļuves sarakstu, pārskatīšanas lēmumu, korektīvo darbību un pabeigtu piekļuves atsaukšanu.

Tā ir atšķirība starp piekļuves kontroli un piekļuves pārvaldību.

Piegādātāju un apstrādātāju piekļuve: aklā zona PIMS auditos

Daudzi neatļautas piekļuves riski ienāk caur atbalstu, ārpakalpojumiem, integrācijas partneriem, pārvaldīto pakalpojumu sniedzējiem un apakšapstrādātājiem. Apstrādātājam var būt attālināta piekļuve klienta ražošanas datiem. Mākoņpakalpojumu sniedzējs var nodrošināt atbalsta piekļuves ceļus. Apakšapstrādātājs var uzturēt meklēšanas indeksu, kas satur klientu identifikatorus. Pārvaldīts drošības pakalpojumu sniedzējs var piekļūt žurnāliem, kuros ir personas dati.

Saskaņā ar GDPR pārziņiem jāizmanto apstrādātāji, kas sniedz pietiekamas garantijas. ISO/IEC 27701:2025 ietvarā apstrādātāju un apakšapstrādātāju pārvaldība jāoperacionalizē ar dokumentētiem norādījumiem, līgumos noteiktiem kontroles pasākumiem, apliecinājumiem un uzraudzību. ISO/IEC 27002:2022 to atbalsta ar piegādātāju attiecību kontroles pasākumiem, tostarp 5.19 Information security in supplier relationships, 5.20 Addressing information security within supplier agreements un 5.21 Managing information security in the ICT supply chain.

Zenith Blueprint Controls in Action fāzes 23. solī apkopo piegādātāju vienošanās pierādījumu jomas, tostarp:

✓ Piekļuves kontroles pienākumi, piemēram, kas var piekļūt jūsu datiem, kā tiek pārvaldīti autentifikācijas dati un kāda uzraudzība ir ieviesta;

Tas ietver arī konfidencialitātes pienākumus, tehniskos un organizatoriskos pasākumus, incidentu ziņošanas termiņus, audita tiesības, apakšuzņēmēju kontroles pasākumus un kontu deaktivizēšanu līguma beigās.

Clarysec Processor, Subprocessor and Third-Party Privacy Management Policy pārvērš to pārziņa puses PIMS pierādījumos:

[Controller] Privātuma vadītājam / PIMS vadītājam pirms apstiprināšanas JĀPĀRBAUDA, ka REG08 apstrādātāja līguma kontroles lauki aptver apstrādes tvērumu, ilgumu, nolūku, PII kategorijas, datu subjektu kategorijas, konfidencialitāti, drošību, apakšapstrādātāja autorizāciju, palīdzību, auditu vai apliecinājumu, atdošanu, dzēšanu un izbeigšanu.

No sadaļas “4.3 Līguma un dokumentēto norādījumu kontroles”, politikas punkts 4.3.2.

Piegādātāju piekļuve tiek tieši kontrolēta arī Clarysec SME un uzņēmuma līmeņa piegādātāju politikās. SME Third-Party and Supplier Security Policy - SME nosaka:

Piegādātājiem jāpiešķir piekļuve tikai minimālajām sistēmām un datiem, kas nepieciešami to funkcijas izpildei.

No sadaļas “Politikas ieviešanas prasības”, politikas punkts 6.2.1.

Uzņēmuma līmeņa Third party and supplier security policy papildus nosaka RBAC, pārskatīšanu un minimāli nepieciešamās tiesības:

Piegādātāju personālam jāpiemēro lomās balstīta piekļuves kontrole (RBAC), periodiska piekļuves tiesību pārskatīšana un minimāli nepieciešamo tiesību piemērošana.

No sadaļas “Politikas ieviešanas prasības”, politikas punkts 6.3.1.

Ja piegādātāja piekļuve var sasniegt PII, tai jābūt PIMS tvērumā. Tai jāparādās līgumu kontroles pasākumos, piekļuves apstiprinājumos, IAM grupās, žurnalēšanas tvērumā, pārskatīšanas ierakstos, darba attiecību izbeigšanas ierakstos, incidentu rokasgrāmatās un audita pierādījumos.

PII piekļuve mākoņvidē: kopīga atbildība nav kopīga pārskatatbildība

PII piekļuves pārvaldībā mākoņvidē organizācijas bieži pārvērtē pakalpojumu sniedzēja lomu un nenovērtē savas atbildības. Mākoņpakalpojumu sniedzējs var aizsargāt infrastruktūru, bet klients joprojām pārvalda identitātes, lomas, nomnieka konfigurāciju, atbalsta piekļuvi, žurnālus, šifrēšanas iestatījumus, eksporta tiesības un gatavību reaģēšanai uz incidentiem.

Zenith Blueprint Controls in Action fāzes 23. solī mākoņpakalpojumu vadlīnijās to formulē tieši:

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

Tas arī brīdina:

Mākoņvidē redzamība ir daļēja, ja tā nav mērķtiecīgi izprojektēta. Jākonfigurē žurnalēšana, jāpiemēro šifrēšana, jādefinē identitāšu lomas un jāuzrauga darbības, izmantojot iebūvētos rīkus vai trešo pušu integrācijas. Tas nav infrastruktūras uzdevums — tā ir IDPS prasība.

Clarysec Cloud Usage Policy pārvērš to uzņēmuma līmeņa piekļuves prasībā:

Visiem mākoņpakalpojumiem jāievieš uz identitāti balstīta piekļuves kontrole, kas saskaņota ar minimālo privilēģiju principu.

No sadaļas “Politikas ieviešanas prasības”, politikas punkts 6.2.1.

Organizācijām, kas mākoņvidēs darbojas kā apstrādātāji, Clarysec Cloud PII Processor Policy nosaka konkrētāku PIMS pārskatīšanas pienākumu:

[Processor] Informācijas drošības vadītājam vismaz reizi ceturksnī REG12 JĀPĀRSKATA priviliģēta mākoņpiekļuve, atbalsta piekļuve, klientu PII piekļuve un žurnalēšanas pārklājums.

No sadaļas “4.2 Mākoņa konfigurācija, nomnieku izolācija, piekļuve un žurnalēšana”, politikas punkts 4.2.4.

Šis punkts ir īpaši būtisks SaaS uzņēmumiem, mākoņvidē izvietotām platformām, pārvaldītiem datu pakalpojumiem un B2B apstrādātājiem.

PII piekļuves pārvaldība mākoņvidē nav pilnīga, ja mākoņvides žurnāli, IAM politikas, pakalpojumu konti, priviliģētās lomas, klientu atbalsta rīki, API atslēgas un datu eksporta funkcijas netiek pārskatītas kopā.

Žurnalēšana un uzraudzība: PII pārvaldības atmiņa

PIMS piekļuves kontroles programma bez žurnāliem ir solījums bez atmiņas.

PII Security and Access Control Policy prasa noteikt žurnalēšanas tvērumu pirms izmantošanas ražošanas vidē vai būtiskām izmaiņām:

[Both] Sistēmas īpašniekam / Lietojumprogrammas īpašniekam pirms izmantošanas ražošanas vidē vai būtiskām izmaiņām REG12 JĀDEFINĒ PII žurnalēšanas tvērums autentifikācijas notikumiem, piekļuves notikumiem, priviliģētām darbībām, PII eksporta darbībām un būtiskām konfigurācijas izmaiņām.

No sadaļas “4.6 Žurnalēšana un uzraudzība”, politikas punkts 4.6.1.

SME Logging and Monitoring Policy - SME skaidri nosaka piekļuves žurnālu saturu:

Piekļuves žurnāli: piekļuve datnēm (īpaši sensitīviem vai personas datiem), piekļuves tiesību izmaiņas, koplietotu resursu izmantošana.

No sadaļas “Pārvaldības prasības”, politikas punkts 5.4.3.

Uzņēmuma līmeņa Logging and Monitoring Policy koncentrējas uz izmantojamību auditā:

IDPS auditācijas pēdas reģistrā jāreģistrē žurnālu datu pieejamība auditiem, izmeklēšanām un regulatīvajām pārskatīšanām.

No sadaļas “Pārvaldības prasības”, politikas punkts 5.4.

Tas ir būtiski, jo privātuma pierādījumiem bieži jāatbild uz notikumos balstītiem jautājumiem:

• Kas piekļuva PII?
• Vai piekļuve bija autorizēta?
• Vai piekļuve bija sasaistīta ar atbalsta pieteikumu, juridisku pieprasījumu, operatīvu uzdevumu vai klienta norādījumu?
• Vai dati tika eksportēti, kopēti, mainīti vai dzēsti?
• Vai tika izmantota priviliģēta piekļuve?
• Vai piekļuves tiesības tika mainītas pirms vai pēc piekļuves?
• Vai darbība norādīja uz drošības incidentu vai personas datu aizsardzības pārkāpumu?

Žurnāli nav paredzēti tikai SOC. Tie ir PIMS pierādījumi, klientu apliecinājumu pierādījumi, apstrādātāju apliecinājumu pierādījumi un reaģēšanas uz incidentiem pierādījumi.

Savstarpējās atbilstības kartēšana: viens piekļuves modelis, daudzi skatpunkti

Vājā vieta PII piekļuves tiesību pārskatīšanā nekad nav tikai viens konstatējums. Tā var kļūt par GDPR pārskatatbildības problēmu, ISO/IEC 27701:2025 PIMS vājumu, ISO/IEC 27001:2022 neatbilstību, NIS2 pārvaldības kļūmi, DORA noturības jautājumu, NIST CSF 2.0 pārvaldības nepilnību vai COBIT 2019 procesa brieduma problēmu.

Detalizētāka kontroles pasākumu kartējuma tabula parāda, kā viens PII piekļuves pārvaldības process atbalsta vairākas prasības:

Zenith Controls vērtība ir tā, ka komandas var sasaistīt šos skatpunktus ar vieniem un tiem pašiem kontroles pierādījumiem, nevis uzturēt atsevišķas atbilstības salas.

Veiciet 45 minūšu PII piekļuves pierādījumu sprintu

Noderīgs veids, kā pārbaudīt gatavību, ir izvēlēties vienu augstas ietekmes sistēmu, piemēram, klientu atbalsta platformu, HR sistēmu, maksājumu portālu, pacientu portālu, datu ezeru vai SaaS ražošanas datubāzi, un veikt fokusētu pierādījumu sprintu.

1. solis: definējiet PII apstrādes kontekstu

Reģistrējiet REG12:

• Sistēmas nosaukumu un īpašnieku
• PII kategorijas
• Datu subjektu kategorijas
• Pārziņa vai apstrādātāja lomu
• Apstrādes nolūku
• Augstas ietekmes vai sensitīvu PII indikatoru
• Mākoņpakalpojumu, piegādātāju un apakšapstrādātāju atkarības

Ja sistēmā iesaistīts apstrādātājs, pārbaudiet REG08 līguma kontroles laukus, izmantojot Processor, Subprocessor and Third-Party Privacy Management Policy. Apstiprinājumam jāaptver apstrādes tvērums, ilgums, nolūks, PII kategorijas, datu subjektu kategorijas, konfidencialitāte, drošība, apakšapstrādātāja autorizācija, palīdzība, audits vai apliecinājums, atdošana, dzēšana un izbeigšana.

2. solis: iegūstiet piekļuves sarakstu

Eksportējiet visus lietotājus, grupas, priviliģētās lomas, pakalpojumu kontus, atbalsta lomas, ārkārtas piekļuves kontus, API atslēgas un piegādātāju kontus. Salīdziniet katru tiesību piešķīrumu ar apstiprinātajām lomām.

3. solis: apstipriniet minimāli nepieciešamās tiesības un nolūka atbilstību

Izmantojiet PII Security and Access Control Policy pamatlīniju: piekļuve pirms aktivizēšanas jāierobežo līdz apstiprinātām lomām un pilnvarotiem lietotājiem, kas reģistrēti vai izsekojami REG02 vai REG12. Ja lietotāju nevar izsekot līdz lomai, nolūkam un apstiprinājumam, konstatējums nav “trūkst dokumentācijas”. Konstatējums ir “PII piekļuve nav pierādāmi autorizēta”.

4. solis: pārbaudiet žurnalēšanas tvērumu

Apstipriniet, ka žurnāli fiksē autentifikāciju, piekļuves notikumus, priviliģētas darbības, PII eksporta darbības un būtiskas konfigurācijas izmaiņas. Pēc tam apstipriniet, kur žurnāli tiek glabāti, cik ilgi tie tiek glabāti, kas tiem var piekļūt un vai tie ir reģistrēti IDPS auditācijas pēdas reģistrā auditiem, izmeklēšanām un regulatīvajām pārskatīšanām.

5. solis: noslēdziet ciklu

Katram izņēmumam reģistrējiet riska īpašnieku, tūlītēju ierobežošanas darbību, pastāvīgu korektīvo pasākumu, mērķa datumu, nepieciešamos pierādījumus, atlikušā riska lēmumu un to, vai nepieciešama pārkāpuma izvērtēšana.

Šis viens vingrinājums parasti atklāj PII piekļuves pārvaldības faktisko briedumu. Spēcīgas organizācijas spēj atbildēt ātri. Vājas organizācijas atklāj, ka privātuma politika, IAM konfigurācija, apstrādātāju līgumi, mākoņvides žurnalēšana un audita pierādījumi nav savienoti.

Bieži audita konstatējumi PII piekļuves pārvaldībā

Lielākā daļa konstatējumu ir paredzami. Tie rodas tad, kad privātuma, drošības, juridiskā, IT un piegādātāju pārvaldības funkcija katra kontrolē daļu no kopējā procesa, bet neviens neuzņemas atbildību par pilnu PII piekļuves dzīves ciklu.

Bieži konstatējumi:

• PII sistēmas nav pilnībā iekļautas PIMS uzskaitē.
• Piekļuves lomas ir definētas tehniski, bet nav sasaistītas ar apstrādes nolūkiem.
• Sensitīvi PII ir pieejami caur plašām operatīvām grupām.
• Ceturkšņa pārskatīšana aptver darbiniekus, bet ne pakalpojumu kontus, API atslēgas vai piegādātāju lietotājus.
• Mākoņpakalpojumu atbalsta piekļuve ir iespējama, bet netiek pārskatīta kā PII piekļuve.
• Žurnāli pastāv, bet nepierāda PII piekļuvi, eksportu vai priviliģētu darbību.
• Apstrādātāju līgumos ir vispārīgas konfidencialitātes klauzulas, bet nav konkrētu piekļuves kontroles, audita, apakšapstrādātāja, atdošanas, dzēšanas vai izbeigšanas kontroles pasākumu.
• Bijušie darbinieki vai līgumdarbinieki saglabā piekļuvi caur koplietotām grupām vai nepārvaldītiem marķieriem.
• Datu noliktavas piekļuve ir plašāka nekā avota lietojumprogrammas piekļuve.
• Ārkārtas piekļuves konti pastāv bez pārskatīšanas pēc izmantošanas.
• Klientu atbalsta impersonācija netiek žurnalēta ar pieteikuma kontekstu.
• Piemērojamības paziņojumā ir iekļauti piekļuves kontroles pasākumi, bet pierādījumi neparāda PII specifisku ieviešanu.

Katrs no šiem konstatējumiem atkarībā no tvēruma var kļūt par GDPR pārskatatbildības problēmu, klientu apliecinājuma jautājumu, NIS2 vai DORA pārvaldības vājumu vai ISO/IEC 27001:2022 neatbilstību.

Kā izskatās laba prakse

Nobriedis darbības modelis nepaļaujas uz varonīgām ceturkšņa tīrīšanām. Tas iestrādā PII piekļuves pārvaldību ikdienas operācijās.

Pirmkārt, organizācijai ir datu pārzināšana. Tā zina, kur atrodas PII, kāpēc tie tiek apstrādāti, kura PIMS loma ir piemērojama un kuras sistēmas, piegādātāji, mākoņpakalpojumi, žurnāli, rezerves kopijas un eksporta darbības ietilpst tvērumā.

Otrkārt, piekļuve ir lomās balstīta un saskaņota ar nolūku. Piekļuves tiesības tiek definētas, pamatojoties uz apstiprinātām lomām, dokumentētu biznesa vajadzību, apstrādes nolūku un minimāli nepieciešamajām tiesībām.

Treškārt, kontroles pasākumi tiek tehniski ieviesti. IAM, RBAC, priviliģētās piekļuves pārvaldība, MFA, nosacītā piekļuve, nomnieku kontroles pasākumi, šifrēšana un vides nodalīšana ievieš politikas prasības.

Ceturtkārt, uzraudzība ir mērķtiecīga. Organizācija var rekonstruēt autentifikāciju, piekļuvi, eksportu, priviliģētas darbības, atbalsta piekļuvi un konfigurācijas izmaiņas, kas ietekmē PII.

Piektkārt, pārskatīšana ir uz risku balstīta un dokumentēta. Augstas ietekmes PII tiek pārskatīti vismaz reizi ceturksnī. Piegādātāju un mākoņpakalpojumu atbalsta piekļuve ir iekļauta. Izņēmumi tiek izsekoti līdz slēgšanai.

Sestkārt, pierādījumi ir atkārtoti izmantojami. Tie paši ieraksti atbalsta GDPR pārskatatbildību, ISO/IEC 27701:2025 PIMS darbību, ISO/IEC 27001:2022 riska apstrādi, NIS2 risku pārvaldības pasākumus, DORA IKT risku pārvaldību, NIST CSF 2.0 GOVERN rezultātus un COBIT 2019 vadības apliecinājumu.

Tā ir atšķirība starp piekļuves kontroli kā iestatījumu un piekļuves pārvaldību kā sistēmu.

Pārvērtiet PII piekļuvi auditam gatavos pierādījumos

Ja jūsu nākamais audits, klienta pārskatīšana vai regulatora pieprasījums sāktos rīt ar jautājumu “parādiet, kas var piekļūt PII”, vai jūsu komanda pierādījumus sagatavotu dažu minūšu laikā, vai arī sāktu salīdzināt izklājlapas?

Clarysec var palīdzēt novērst šo plaisu.

Sāciet ar PII Security and Access Control Policy, saskaņojiet apstrādātāju un mākoņvides pienākumus, izmantojot Processor, Subprocessor and Third-Party Privacy Management Policy un Cloud PII Processor Policy, pēc tam izmantojiet Zenith Blueprint: An Auditor’s 30-Step Roadmap, lai ieviestu kontroles pasākumus pareizā secībā. Visbeidzot izmantojiet Zenith Controls: The Cross-Compliance Guide, lai kartētu PII piekļuves pierādījumus ISO/IEC 27701:2025, GDPR, ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIS2, DORA, NIST CSF 2.0 un COBIT 2019 ietvaros.

Ātrākais praktiskais nākamais solis ir vienkāršs: izvēlieties vienu augstas ietekmes PII sistēmu, aizpildiet REG12, eksportējiet piekļuves sarakstu, pārbaudiet žurnalēšanas tvērumu un veiciet ceturkšņa pārskatīšanai līdzīgu pārbaudi. Vienas sesijas laikā jūs zināsiet, vai jūsu PII piekļuves pārvaldība ir gatava auditam — vai tikai gatava politikas līmenī.