PAM un break-glass konti ISO 27001 vajadzībām 2026. gadā
Svētdienas rītā plkst. 02:14 incidentu vadītājs saņem ziņu, no kuras baidās katrs informācijas drošības vadītājs: “Ražošanas vides autentifikācija nedarbojas. Administratīvā konsole nav sasniedzama. Datubāzes pārslēgšanās uz rezerves vidi ir iestrēgusi.”
Dežurējošais mākoņvides inženieris redz problēmu, bet nevar to novērst. Viņa parastā priviliģētā loma ir atkarīga no tā paša identitātes nodrošinātāja, kura darbība šobrīd ir degradēta. Operāciju vadītājs pieprasa ārkārtas administratora autentifikācijas datus. Atbilstības vadītājs jautā, vai break-glass konts jebkad ir testēts. Datu aizsardzības speciālists (DPO) jautā, vai piekļuve ražošanas datubāzei var atklāt personas datus. Informācijas drošības vadītājs uzdod jautājumu, kas nosaka, vai šis gadījums kļūs par kontrolētu atjaunošanu vai audita murgu:
“Vai mēs varam pierādīt, kurš izmantoja ārkārtas piekļuvi, kāpēc, ko šī persona darīja un ka konts pēc tam tika atiestatīts?”
Cita organizācija ar to pašu problēmu var saskarties klusākā telpā. FinTech informācijas drošības vadītājs sēž pretī ārējiem auditoriem pēc nepareizas mākoņdatubāzes konfigurācijas. Incidents tika ātri novērsts, taču pamatcēlonis nebija nomierinošs. Trešās puses izstrādātājam bija pastāvīgas administratīvās privilēģijas. Kad primārais administrators nebija pieejams, izstrādātājs izmantoja break-glass kontu, kura pamatā bija koplietota parole, kas glabājās “drošā” piezīmē, pieejamā DevOps komandai.
Auditoru uzmanības centrā nebija tikai nepareizā konfigurācija. Viņi jautāja, vai piekļuve bija ierobežota laikā, vai pastāvēja individuāla pārskatatbildība, vai komandas tika žurnalētas, vai personas dati tika aizsargāti saskaņā ar GDPR 32. pantu, vai DORA IKT riska pienākumi tika izpildīti un vai NIS2 kiberdrošības higiēnas prasības bija pierādāmas.
Tā ir reālā spiediena zona priviliģētās piekļuves pārvaldībai un break-glass kontiem 2026. gadā. PAM vairs nav šaurs identitāšu drošības projekts. Tā ir vieta, kur satiekas izspiedējprogrammatūra, mākoņvides kompromitēšana, piegādātāju risks, datu aizsardzība, darbības noturība un audita pierādījumi.
Priviliģētā piekļuve ir vieta, kur uzbrucēji mēģina uzvarēt. Break-glass piekļuve ir vieta, kur aizstāvji mēģina atjaunoties. Abas paļaujas uz vienu un to pašu bīstamo spēju: paaugstinātu piekļuvi, kas var apiet kontroles pasākumus, mainīt konfigurācijas, lasīt sensitīvus datus, rotēt atslēgas, atspējot žurnālfiksēšanu, atjaunot rezerves kopijas, izvietot kodu vai iznīcināt pierādījumus.
Clarysec praktiskā nostāja ir vienkārša: ārkārtas piekļuve ir nepieciešama, bet nepārvaldīta ārkārtas piekļuve ir nepārvaldīts risks. Pareizā atbilde nav “nekādu break-glass kontu”. Pareizā atbilde ir pārvaldīts priviliģētās piekļuves pārvaldības modelis ar uzskaiti, apstiprināšanu, laika ierobežojumiem, drošu autentifikāciju, sesiju žurnālfiksēšanu, pārskatīšanu pēc izmantošanas, autentifikācijas datu atiestatīšanu un audita pierādījumiem.
Kāpēc priviliģētā piekļuve ir valdes līmeņa atbilstības jautājums
Zemāka brieduma vidēs priviliģētā piekļuve bieži tiek uzskatīta par IT administrēšanas uzdevumu. Kādam ir nepieciešamas administratora tiesības, tiek atvērts pieteikums, tiek piešķirta loma, un darbība turpinās. Šis modelis neiztur mūsdienu izspiedējprogrammatūras, mākoņvidē balstītas infrastruktūras, NIS2 pārskatatbildības, DORA darbības noturības vai GDPR pārkāpumu izvērtēšanas prasības.
NIS2 Direktīva kiberdrošības pārvaldību paceļ valdes līmenī. 20. pants prasa būtisko un svarīgo subjektu vadības struktūrām apstiprināt kiberdrošības risku pārvaldības pasākumus, pārraudzīt ieviešanu un apgūt kiberdrošības apmācību. 21. pants prasa atbilstošus un samērīgus tehniskos, operatīvos un organizatoriskos pasākumus, tostarp riska analīzi, incidentu apstrādi, darbības nepārtrauktību, piegādes ķēdes drošību, kontroles efektivitāti, kiberdrošības higiēnu, personāla drošību, piekļuves kontroli, aktīvu pārvaldību un MFA vai nepārtrauktu autentifikāciju, ja tas ir piemēroti.
SaaS pakalpojumu sniedzējiem, pārvaldīto pakalpojumu sniedzējiem, pārvaldītajiem drošības pakalpojumu sniedzējiem, mākoņpakalpojumiem, datu centriem un citām digitālās infrastruktūras organizācijām NIS2 piemērojamība ir atkarīga no nozares, lieluma, lomas, pārrobežu ietekmes un iedibinājuma ES. Operacionālā atziņa ir tieša: piekļuves kontrole vairs nav paslēpta tehniskā pielikumā. Tā ir daļa no kiberdrošības higiēnas pamatlīmeņa, kas vadībai jāapstiprina, jāuzrauga un jālabo.
Finanšu struktūrām Digital Operational Resilience Act maina terminoloģiju, bet ne pamatā esošo risku. DORA piemēro no 2025. gada 17. janvāra, un tā izveido vienotu ietvaru IKT risku pārvaldībai, būtisku ar IKT saistītu incidentu ziņošanai, digitālās darbības noturības testēšanai un IKT trešo pušu riska pārvaldībai. 5. pants prasa IKT riska pārvaldības un kontroles kārtību, kurā vadības struktūra definē, apstiprina, pārrauga un uzņemas atbildību par IKT riska kārtību. 6. pants prasa dokumentētu IKT risku pārvaldības ietvaru ar politikām, procedūrām, protokoliem un rīkiem IKT aktīvu aizsardzībai. 17. pants prasa ar IKT saistītu incidentu pārvaldības procesu, kas atklāj, reģistrē, klasificē, eskalē incidentus un atjauno drošu darbību.
GDPR pievieno privātuma un pārskatatbildības skatījumu. 5(1)(f). pants prasa personas datus apstrādāt, nodrošinot integritāti un konfidencialitāti. 5(2). pants prasa pārskatatbildību. 25. pants prasa datu aizsardzību pēc projektēšanas un pēc noklusējuma. 32. pants prasa atbilstošus tehniskos un organizatoriskos pasākumus apstrādes drošībai. Ja priviliģēts lietotājs bez pārskatīšanas var eksportēt klientu ierakstus, piekļūt īpašu kategoriju datiem, atspējot audita žurnālus vai mainīt glabāšanas iestatījumus, organizācija nav tikai pieļāvusi IAM kļūdu. Tā var nespēt pierādīt atbilstošu drošību.
ISO/IEC 27001:2022 ir pārvaldības sistēmas pamats, kas ļauj šos pienākumus pārvaldīt vienā integrētā programmā. 4.2. punkts prasa organizācijai izprast ieinteresētās puses un to prasības, tostarp tiesiskos, regulatīvos un līgumiskos pienākumus. 5.1. punkts prasa vadību un apņemšanos. 6.1.2. punkts prasa informācijas drošības risku izvērtēšanu. 6.1.3. punkts prasa riska apstrādi. 8. punkts prasa darbības plānošanu un kontroli.
Priviliģētās piekļuves gadījumā tas pārbīda sarunu no “kuru PAM rīku mums pirkt?” uz “kurus riskus mēs apstrādājam, kuri kontroles pasākumi ir izvēlēti, kam tie pieder, kā tie tiek ekspluatēti un kuri pierādījumi apliecina, ka tie darbojas?”
PAM nav viens kontroles pasākums, bet pierādījumu ķēde
PAM rīks var glabāt paroles seifā, starpniekot sesijas, ierakstīt taustiņspiedienus, rotēt autentifikācijas datus un piemērot just-in-time piekļuvi. Šīs spējas ir svarīgas. Taču, ja organizācija nav definējusi priviliģētās lomas, apstiprinājusi ārkārtas piekļuvi, sasaistījusi piekļuvi ar aktīviem, pārskatījusi tiesības, aizsargājusi žurnālus un apmācījusi administratorus, rīks kļūst par daļēju kontroles pasākumu ar vāju audita pamatojumu.
Noderīgākais veids, kā pārvaldīt priviliģētu piekļuvi, ir domāt par kontroles rezultātiem, nevis rīku nosaukumiem.
Zenith Controls: The Cross-Compliance Guide Zenith Controls aplūko ISO/IEC 27002:2022 kontroles pasākumu 8.2, priviliģētas piekļuves tiesības, kā PAM smaguma centru. Tas klasificē šo kontroles pasākumu kā preventīvu, kas atbalsta konfidencialitāti, integritāti un pieejamību, ir saskaņots ar kiberdrošības konceptu Protect, darbības spēju identitātes un piekļuves pārvaldība un drošības domēnu Protection.
Kontroles pasākums 8.2 ir spēcīgs, jo tas sasaistās ar apkārtējiem kontroles pasākumiem, kas padara priviliģēto piekļuvi auditējamu:
| ISO/IEC 27002:2022 kontroles pasākums | Kāpēc tas ir svarīgi PAM un break-glass kontiem |
|---|---|
| 5.16 Identitātes pārvaldība | Katram priviliģētam lietotājam jābūt pārbaudītai, unikālai identitātei, pirms paaugstinātu piekļuvi var kontrolēt. |
| 5.18 Piekļuves tiesības | Piekļuves piešķiršanā, pārskatīšanā, mainīšanā un atsaukšanā jāiekļauj priviliģētās un ārkārtas tiesības. |
| 8.3 Informācijas piekļuves ierobežošana | Priviliģēti konti nedrīkst kļūt par nekontrolētiem apvedceļiem uz sensitīviem datiem. |
| 8.5 Droša autentifikācija | Administratora un ārkārtas kontiem nepieciešama stiprāka autentifikācija, piemēram, MFA vai līdzvērtīgs apliecinājuma līmenis. |
| 6.7 Attālinātais darbs | Attālinātai priviliģētai administrēšanai nepieciešami droši kanāli, uzraudzība un ierobežoti nosacījumi. |
| 8.15 Žurnālfiksēšana | Priviliģētās darbības jāreģistrē, jāaizsargā un jāpārskata. |
| 8.16 Uzraudzības darbības | Žurnāliem jānodrošina ievade atklāšanai, anomāliju analīzei un reaģēšanai. |
| 8.18 Priviliģēto utilītprogrammu izmantošana | Administratīvie rīki, kas spēj apiet kontroles pasākumus, jāuzskaita, jāierobežo un jāžurnalē. |
Tāpēc auditors reti apstājas pie jautājuma: “Vai jums ir PAM sistēma?” Spēcīgāki audita jautājumi ir: vai jums ir priviliģēto kontu uzskaite? Vai priviliģētās lomas ir apstiprinātas? Vai tiesības ir ierobežotas laikā? Vai ārkārtas autentifikācijas dati ir aizsargāti? Vai varat pierādīt, kurš tos izmantoja? Vai komandas tiek žurnalētas? Vai ir iekļauti piegādātāju administratori? Vai piekļuves tiesības tiek pārskatītas? Vai autentifikācijas dati tika atiestatīti? Vai izņēmumiem tika pieņemts risks?
Zenith Controls piekļuves tiesību kartējums to formulē tieši: piekļuves tiesību pārvaldība operacionalizē piekļuves kontroles principus, piemēram, minimāli nepieciešamās tiesības, principu “nepieciešams zināt” un autorizāciju, savukārt priviliģētiem kontiem nepieciešama īpaša pārbaude un savlaicīga atsaukšana, kad tie vairs nav nepieciešami.
Politikas prasības uzticamai break-glass piekļuvei
Break-glass konts nav koplietota administratora parole aizzīmogotā aploksnē. 2026. gadā šāds modelis ir pārāk vājš mākoņpakalpojumiem, fintech, SaaS, veselības aprūpei, pārvaldītajiem pakalpojumiem un regulētām digitālajām operācijām.
Aizstāvamam break-glass modelim nepieciešami septiņi minimālie politikas noteikumi:
- Kontam jābūt dokumentētam.
- Kontam jābūt apstiprinātam.
- Izmantošanai jābūt unikāli attiecināmai uz konkrētu personu, ja tas ir tehniski iespējams.
- Izmantošana jāierobežo tikai ar patiesām ārkārtas situācijām.
- Izmantošana jāžurnalē un jāpārskata.
- Autentifikācijas dati vai autentifikācijas faktori pēc izmantošanas jāatiestata vai jārotē.
- Konts jātestē un jāiekļauj audita tvērumā.
Clarysec politiku bibliotēka pārvērš šos principus izmantojamā pārvaldības valodā.
Lietotāju kontu un privilēģiju pārvaldības politika-sme Lietotāju kontu un privilēģiju pārvaldības politika - SME nosaka:
“Ārkārtas piekļuvei (piemēram, “break glass” administratora kontiem) jābūt skaidri dokumentētai, aizsargātai un izmantotai tikai tad, kad tas ir absolūti nepieciešams.”
No sadaļas “Risku apstrāde un izņēmumi”, politikas 7.3.1. punkts.
Tā pati SME politika turpina:
“Šādi konti jāžurnalē, jāpārskata pēc izmantošanas un jāatiestata pēc katra ārkārtas notikuma.”
No sadaļas “Risku apstrāde un izņēmumi”, politikas 7.3.2. punkts.
Ikdienas privilēģiju paaugstināšanai SME politika prasa arī:
“Paaugstinātām vai administratīvām privilēģijām nepieciešams papildu apstiprinājums no ģenerāldirektora vai IT vadītāja, un tām jābūt dokumentētām, ierobežotām laikā un pakļautām periodiskai pārskatīšanai.”
No sadaļas “Politikas ieviešanas prasības”, politikas 6.2.2. punkts.
Lielākām organizācijām uzņēmuma politiku kopums iet dziļāk. Lietotāju kontu un privilēģiju pārvaldības politika Lietotāju kontu un privilēģiju pārvaldības politika prasa:
“Priviliģētās sesijas pilnībā jāžurnalē, tostarp izpildītās komandas un veiktās darbības. Žurnāli periodiski jāpārskata norīkotiem pārskatītājiem.”
No sadaļas “Politikas ieviešanas prasības”, politikas 6.4.2. punkts.
Tā pati politika prasa pagaidu vai ārkārtas priviliģētās piekļuves kontiem ievērot dokumentētu break-glass procedūru 6.2.5. punktā, savukārt 7.4. punkts izklāsta šīs procedūras prasības.
Piekļuves kontroles politika Piekļuves kontroles politika pastiprina audita pierādījumu glabāšanas prasības:
“Apstiprināšanas lēmumi jāžurnalē un jāsaglabā audita vajadzībām vismaz 2 gadus.”
No sadaļas “Pārvaldības prasības”, politikas 5.3.2. punkts.
Žurnālfiksēšanas un uzraudzības politika-sme Žurnālfiksēšanas un uzraudzības politika - SME nosaka autentifikācijas žurnālfiksēšanas prasības:
“Autentifikācijas žurnāli: veiksmīgi un neveiksmīgi pieteikšanās mēģinājumi, sesijas ilgums, MFA izmantošana”
No sadaļas “Pārvaldības prasības”, politikas 5.4.2. punkts.
Kopā šie punkti pārvērš ārkārtas piekļuvi no varonīga pagaidu risinājuma par kontrolētu notikumu. Konts ir izņēmuma gadījums, bet pārvaldība nav izņēmums.
Zenith Blueprint pieeja PAM ieviešanai
Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint aplūko priviliģēto piekļuvi kā praktisku ieviešanas jautājumu, nevis teorētisku kontroles paziņojumu. Controls in Action fāzē, 19. solī, Technological Controls I, tas nosaka:
“Jebkurā informācijas sistēmā priviliģētā piekļuve ir vara, un līdz ar šo varu rodas risks.”
No Controls in Action fāzes, 19. solis: Technological Controls I.
- solis prasa organizācijām identificēt priviliģētos kontus lokālajās, mākoņvides, SaaS, izstrādes un infrastruktūras vidēs. Tas ietver domēna administratorus, root lietotājus, mākoņnomnieka administratorus, datubāzu superlietotājus un CI/CD konveijeru kontrolierus. Tas arī uzsver priviliģētās piekļuves minimizēšanu, izmantojot lomās balstītu piekļuves kontroli, just-in-time privilēģiju paaugstināšanu un apstiprināšanas darbplūsmas.
Tas ir svarīgi, jo daudzi nopietni incidenti nesākas ar formālu break-glass kontu. Tie sākas ar pastāvīgu privilēģiju. Mākoņvides inženieris saglabā īpašnieka tiesības “katram gadījumam”. Datubāzes administrators saglabā piekļuvi ražošanas videi pēc pāriešanas uz citu komandu. CI/CD servisa kontam ir plašas atļaujas vairākās vidēs. Pārvaldīto pakalpojumu sniedzēja konts ir atbrīvots no MFA, jo “viņiem vajag ātru piekļuvi”.
Zenith Blueprint 20. solis to pašu loģiku paplašina uz priviliģētajām utilītprogrammām. Tas uzdod organizācijām izveidot vai atjaunināt priviliģēto utilītprogrammu uzskaiti, ierobežot izpildi līdz autorizētiem administratoriem, pārbaudīt, ka izmantošana tiek žurnalēta un rada brīdinājumus, un apsvērt skriptu žurnālfiksēšanu, piemēram, PowerShell žurnālfiksēšanu, izmantojot grupas politiku. Tas ir kritiski, jo priviliģēts konts bieži ir tikai ieejas punkts. Kaitējums rodas, kad uzbrucējs palaiž rīkus, kas atspējo kontroles pasākumus, izgūst autentifikācijas datus vai veic laterālu pārvietošanos.
- solis formalizē piekļuves kontroles dzīves ciklu. Tas prasa strukturētu piekļuves piešķiršanu un deprovisionēšanu, ideālā gadījumā integrētu ar personāla funkciju un atbalstītu ar piekļuves pieprasījumu darbplūsmām, kā arī dokumentētu ceturkšņa piekļuves tiesību pārskatīšanu. 16. solis sasaista dzīves ciklu ar darba attiecību izbeigšanu, prasot darbinieka darba attiecību izbeigšanas kontrolsarakstu, ko personāla funkcija un IT izmanto kopīgi, tostarp konta atspējošanu, aktīvu atdošanu un NDA atgādinājumus.
Zenith Blueprint padara PAM par savienotu darbības modeli: identitāte, personāla funkcija, priviliģētās utilītprogrammas, žurnālfiksēšana, reaģēšana uz incidentiem, piekļuves tiesību pārskatīšana un audita pierādījumi savstarpēji pastiprina viens otru.
Praktisks break-glass pārvaldības modelis 2026. gadam
Labi izstrādātam break-glass procesam jādarbojas atteices laikā. Ja tas ir atkarīgs no tā paša identitātes nodrošinātāja, pieteikumu sistēmas un tērzēšanas pakalpojuma, kas nav pieejami darbības pārtraukuma laikā, tas ir tikai formalitāte.
Vienlaikus ārkārtas piekļuve nedrīkst kļūt par ērtības apvedkanālu. Clarysec parasti veido break-glass pārvaldību ap četriem slāņiem: prevencija, aktivizēšana, novērošana un atjaunošana.
| Slānis | Kontroles mērķis | Praktiskie pierādījumi |
|---|---|---|
| Prevencija | Samazināt ārkārtas piekļuves nepieciešamību, izmantojot minimāli nepieciešamās tiesības, JIT piekļuvi, redundanci un testētas atjaunošanas procedūras. | PAM uzskaite, RBAC modelis, piekļuves tiesību pārskatīšanas ieraksti, noturības testi, risku apstrādes plāns. |
| Aktivizēšana | Nodrošināt, ka ārkārtas piekļuve tiek izmantota tikai apstiprinātās ārkārtas situācijās un ir ierobežota laikā. | Break-glass procedūra, apstiprinājuma pieteikums, incidenta paziņojums, nominēts apstiprinātājs, aktivizēšanas laikspiedols. |
| Novērošana | Fiksēt, kas notika priviliģētās darbības laikā. | Sesijas ierakstīšana, komandu žurnāli, autentifikācijas žurnāli, MFA pierādījumi, SIEM brīdinājumi, pulksteņu sinhronizācijas pierādījumi. |
| Atjaunošana | Novērst atlikušo risku pēc ārkārtas izmantošanas. | Autentifikācijas datu rotācija, konta atiestatīšana, pārskatīšana pēc izmantošanas, incidenta laika skala, gūtās atziņas, riska reģistra atjauninājums. |
Mākoņvidēs iekļaujiet nomnieka līmeņa administratorus, mākoņvides root kontus, ārkārtas identitātes nodrošinātāja administratorus, priviliģētus servisa kontus, datubāzu galvenos lietotājus, Kubernetes cluster-admin lomas, CI/CD izvietošanas atslēgas, noslēpumu seifu administratorus un trešo pušu atbalsta kontus.
Hibrīdvidēs iekļaujiet domēna administratorus, rezerves kopiju administratorus, hipervizora administratorus, ugunsmūra administratorus, EDR konsoles administratorus un priviliģēto utilītprogrammu lietotājus.
Privātuma ziņā jutīgās vidēs iekļaujiet administratorus, kuri var piekļūt datubāzēm ar personas datiem, žurnāliem ar identifikatoriem, personāla funkcijas ierakstiem, biometriskās identitātes pārbaudes datiem, krāpšanas uzraudzības sistēmām vai klientu atbalsta rīkiem.
Mērķa stāvokli ir viegli aprakstīt un grūti viltot: katrs ārkārtas piekļuves ceļš ir zināms, apstiprināts, aizsargāts, novērojams, atgriezenisks un pārskatīts.
60 minūšu break-glass pierādījumu vingrinājums
Informācijas drošības vadītājs vai atbilstības vadītājs šonedēļ var veikt noderīgu break-glass vingrinājumu, nepērkot jaunu rīku. Mērķis nav tikai apstiprināt, ka konts darbojas. Mērķis ir pierādīt, ka kontroles pasākums rada pierādījumus.
Scenārijs
Pieņemiet, ka primārais identitātes nodrošinātājs darbojas degradētā režīmā. Parastā just-in-time privilēģiju paaugstināšana nav pieejama. Ražošanas datubāzes klasterim nepieciešamas ārkārtas konfigurācijas izmaiņas, lai atjaunotu pakalpojumu. Jāaktivizē break-glass mākoņvides administratora konts.
1. solis: apstipriniet, ka konts ir priviliģēto kontu uzskaitē
Izmantojiet Zenith Blueprint, Controls in Action fāzi, 19. soli, lai validētu, ka konts parādās priviliģēto kontu uzskaitē. Reģistrējiet konta nosaukumu un vidi, biznesa īpašnieku, tehnisko īpašnieku, sasniedzamās sistēmas, personas datu ietekmi, autentifikācijas metodi, seifa atrašanās vietu, rotācijas metodi un pēdējā testa datumu.
Ja konta nav, uzskatiet to par kontroles trūkumu un pievienojiet riska reģistram.
2. solis: pārbaudiet saskaņotību ar politiku
Kartējiet notikumu pret Lietotāju kontu un privilēģiju pārvaldības politikas prasībām par dokumentētām break-glass procedūrām un priviliģēto sesiju žurnālfiksēšanu. Ja esat SME, izmantojiet Lietotāju kontu un privilēģiju pārvaldības politika-sme 7.3.1. un 7.3.2. punktu kā minimālo pamatlīmeni: dokumentēts, aizsargāts, nepieciešams, žurnalēts, pārskatīts un atiestatīts.
Kartējiet apstiprinājumu glabāšanu pret Piekļuves kontroles politika 5.3.2. punktu, kas prasa apstiprināšanas lēmumus žurnalēt un glabāt vismaz 2 gadus.
3. solis: atveriet ārkārtas piekļuves ierakstu
Pirms aktivizēšanas vai aktivizēšanas brīdī izveidojiet pieteikumu vai incidenta ierakstu. Iekļaujiet:
- Ārkārtas iemesls
- Ietekmētais pakalpojums
- Pieprasītais konts
- Pieprasītājs
- Apstiprinātājs
- Sākuma laiks
- Paredzamais beigu laiks
- Ietekme uz klientiem vai regulējumu
- GDPR personas datu ietekme
- NIS2 vai DORA ziņošanas uzraudzības karodziņš
Negaidiet līdz beigām, lai rekonstruētu stāstu. Audita vērtība ir vislielākā, ja ieraksts sākas pirms piekļuves izmantošanas.
4. solis: aktivizējiet un novērojiet
Aktivizējiet break-glass kontu. Apstipriniet, ka tiek izmantota MFA vai kompensējoša autentifikācija, sesija tiek ierakstīta, komandas vai administratīvās darbības tiek žurnalētas, žurnāli tiek pārsūtīti uz centralizētu žurnālfiksēšanu, laika sinhronizācija atbalsta laika skalas rekonstrukciju un par ārkārtas konta izmantošanu tiek ģenerēts brīdinājums.
Tas atbilst Zenith Controls 8.15 Žurnālfiksēšanai, kas apraksta žurnālfiksēšanu kā uzraudzības pamata datu slāni un norāda, ka priviliģēti lietotāji un priviliģēto utilītprogrammu izpilde jāžurnalē visaptveroši.
5. solis: aizveriet, atiestatiet un pārskatiet
Pēc ārkārtas uzdevuma atspējojiet kontu vai atgrieziet to aizzīmogotā statusā, rotējiet autentifikācijas datus vai atiestatiet autentifikācijas faktoru, pārskatiet sesijas žurnālus, dokumentējiet komandas un konfigurācijas izmaiņas, apstipriniet, ka nav notikusi nevajadzīga datu piekļuve, atjauniniet incidenta ierakstu, reģistrējiet gūtās atziņas un izlemiet, vai ir sasniegti NIS2, DORA vai GDPR paziņošanas sliekšņi.
Ja tika piekļūts personas datiem, iesaistiet DPO. Ja notikums izraisīja pakalpojumu darbības traucējumus vai varētu radīt būtisku ietekmi, iesaistiet NIS2 vai DORA ziņošanas īpašnieku. Ja break-glass konts nedarbojās, dokumentējiet to kā darbības noturības konstatējumu, nevis tikai IAM problēmu.
Starpatbilstības kartējums PAM un break-glass kontroles pasākumiem
Spēcīgākais pārvaldības modelis nedublē kontroles pasākumus katram regulējumam. Tas veido vienu pierādījumu ķēdi, kas atbalsta vairākus pienākumus.
| Ietvars | PAM un break-glass nozīme | Pierādījumi, ko sagaida auditori un regulatori |
|---|---|---|
| ISO/IEC 27001:2022 | Risku izvērtēšana, riska apstrāde, Piemērojamības deklarācija, darbības kontrole un A pielikuma kontroles pasākumi piekļuves tiesībām, priviliģētai piekļuvei, žurnālfiksēšanai, uzraudzībai, incidentu pārvaldībai un nepārtrauktībai. | ISMS darbības joma, riska reģistrs, SoA, politikas, piekļuves tiesību pārskatīšana, PAM konfigurācija, žurnāli, incidentu ieraksti, korektīvās darbības. |
| NIS2 | 21. pants prasa atbilstošus tehniskos, operatīvos un organizatoriskos pasākumus, tostarp piekļuves kontroli, aktīvu pārvaldību, MFA vai nepārtrauktu autentifikāciju, incidentu apstrādi un kiberdrošības higiēnu. 20. pants skaidri nosaka vadības pārraudzību. | Valdes apstiprinājums, kiberdrošības higiēnas pamatlīmenis, priviliģētās piekļuves politika, piekļuves tiesību pārskatīšanas pierādījumi, incidentu ziņošanas rokasgrāmatas, piegādātāju administratoru kontroles pasākumi. |
| DORA | 5. un 6. pants prasa pārvaldītu IKT risku pārvaldību. 17. pants prasa incidentu atklāšanu, reģistrēšanu, klasificēšanu, eskalāciju un drošu atjaunošanu. 28. līdz 30. pants prasa IKT trešo pušu riska pārvaldību un līgumu kontroles pasākumus. | IKT risku ietvars, vadības ziņošana, PAM kritiskām funkcijām, trešo pušu administratoru piekļuves kontroles pasākumi, incidentu žurnāli, pamatcēloņa analīze, noturības testi. |
| GDPR | 5(1)(f)., 5(2)., 25. un 32. pants prasa integritāti, konfidencialitāti, pārskatatbildību, datu aizsardzību pēc projektēšanas un atbilstošus drošības pasākumus. | Piekļuves minimizēšana, administratora lomu pārskatīšana, piekļuves personas datiem žurnāli, DPIA atsauces, ja piemērojams, pārkāpuma izvērtēšanas pierādījumi. |
| NIST CSF 2.0 | GOVERN rezultāti sasaista tiesiskos pienākumus, riska apetīti, lomas, politikas un pārraudzību. PROTECT, DETECT, RESPOND un RECOVER rezultāti atbalsta piekļuves kontroli, žurnālus, uzraudzību, reaģēšanu uz incidentiem un atjaunošanu. | Pašreizējie un mērķa profili, trūkumu plāns, pārvaldības ieraksti, žurnālu uzraudzība, incidentu reaģēšanas vingrinājumi, atjaunošanas dokumentācija. |
| COBIT 2019 | Pārvaldības un vadības skatījums koncentrējas uz vērtību, risku, resursiem, procesu īpašumtiesībām, kontroles mērķiem un apliecinājumu par priviliģēto piekļuvi. | Procesu īpašumtiesības, RACI, kontroles veiktspējas rādītāji, vadības ziņošana, apliecinājuma konstatējumi, trūkumu novēršanas izsekošana. |
NIST CSF 2.0 ir īpaši noderīgs, pārvēršot PAM pašreizējā profilā un mērķa profilā. Tā profila metode sākas ar darbības jomu, pēc tam apkopo politikas, riska prioritātes, reģistrus, prasības, prakses un darba lomas, pirms izveido prioritizētu rīcības plānu. Priviliģētai piekļuvei tas nozīmē profila tvēruma noteikšanu ap identitāšu drošību, mākoņvides administrēšanu, izspiedējprogrammatūras noturību, kritiskām finanšu sistēmām vai piegādātāju piekļuvi.
Finanšu struktūrām, uz kurām attiecas DORA, DORA darbojas kā nozarei specifiskais ES kiberdrošības noturības režīms līdzvērtīgiem NIS2 riska un incidentu pienākumiem. Tas nepadara NIS2 nebūtisku. Tas nozīmē, ka finanšu struktūrai jāizmanto DORA kā vadošais režīms IKT riska un incidentu prasībām, vienlaikus saglabājot koordināciju ar nacionālajām kiberdrošības stratēģijām, kompetentajām iestādēm un CSIRT, ja piemērojams.
Kā auditori testē priviliģētās piekļuves pierādījumus
Auditori nevērtē PAM tikai, lasot politiku. Viņi salīdzina politiku, konfigurāciju, žurnālus, pieteikumus, intervijas un novēroto praksi.
Zenith Controls audita metodoloģija priviliģētās piekļuves tiesībām atsaucas uz ISO/IEC 19011:2018 audita praksēm. Auditori pārskata politikas, kas definē paaugstinātās tiesības, piekļuves piešķiršanas, uzraudzības un atsaukšanas procedūras. Viņi pārbauda lietotāju kontu uzskaites, privilēģiju piešķiršanas ierakstus un žurnālus. Viņi apstiprina pierādījumus ar intervijām, PAM rīkiem, direktoriju pakalpojumiem un žurnālu paraugiem.
| Auditora profils | Tipiski PAM jautājumi | Vāji pierādījumi, kas izraisa konstatējumus |
|---|---|---|
| ISO pārvaldības sistēmas auditors | Vai priviliģētā piekļuve ir iekļauta risku izvērtēšanā, apstrādē, SoA, politikā, darbības kontrolē un iekšējā auditā? | Politika pastāv, bet nav riska īpašnieka apstiprinājuma, nav piekļuves tiesību pārskatīšanas ierakstu, nav korektīvo darbību izsekošanas. |
| Tehniskais ISO/IEC 27002:2022 kontroles pasākumu vērtētājs | Vai priviliģētie konti ir unikāli identificēti, apstiprināti, ierobežoti laikā, stingri autentificēti, žurnalēti un pārskatīti? | Koplietoti administratoru konti, neaktīvas administratoru tiesības, nav sesijas žurnālu, nav pārskatīšanas pierādījumu. |
| NIS2 iestāde | Vai organizācija var pierādīt piekļuves kontroli, aktīvu pārvaldību, kiberdrošības higiēnu, MFA, ja piemērojams, un gatavību incidentiem? | Ārkārtas piekļuve nav testēta, piegādātāju administratoru piekļuve nav pārvaldīta, vāji incidentu pierādījumi. |
| DORA IKT riska auditors | Vai finanšu struktūra var uzrādīt vadības pārraudzību, kritisko funkciju kartējumu, incidentu klasifikāciju, trešo pušu administratoru pārvaldību un noturības testēšanu? | Trešo pušu administratori ārpus PAM, nav pamatcēloņa pierādījumu, nav sasaistes ar kritiskām vai svarīgām funkcijām. |
| GDPR auditors vai DPO pārskatītājs | Vai organizācija var pierādīt, ka priviliģētā piekļuve personas datiem ir minimizēta, pamatota, žurnalēta un ņemta vērā pārkāpuma izvērtēšanā? | Administratoriem ir plaša piekļuve personas datiem, žurnāli ir nepilnīgi, pārkāpuma izvērtējumā trūkst piekļuves pierādījumu. |
| ISACA vai COBIT orientēts auditors | Kam pieder process, kā tas tiek mērīts, kā izņēmumi tiek apstiprināti un kā vadība zina, ka tas darbojas? | Nav RACI, nav metriku, nepārvaldīti izņēmumi, vāja vadības ziņošana. |
Attiecībā uz piekļuves tiesībām Zenith Controls norāda, ka auditori izlases veidā pārbauda lietotāju piekļuves pieprasījumus, pārbauda dokumentētus apstiprinājumus un apstiprina, ka IT piešķīra tikai apstiprinātu piekļuvi. Viņi arī salīdzina lietotāju lomas ar faktiskajām tiesībām, pārbaudot, vai tiek piemērotas minimāli nepieciešamās tiesības. Attiecībā uz žurnālfiksēšanu auditori pārbauda žurnālfiksēšanas tvērumu, notikumu tipus, glabāšanas periodus, aizsardzības pasākumus un faktiskos žurnāla ierakstus. Viņi vērtē, vai tiek fiksēti un pārskatīti neveiksmīgi pieteikšanās mēģinājumi, piekļuve sensitīviem datiem un konfigurācijas izmaiņas.
Laba break-glass pierādījumu pakotne ietver:
- Apstiprinātu ārkārtas piekļuves pieprasījumu
- Incidenta vai darbības pārtraukuma kontekstu
- Piekļuvi aktivizējušā lietotāja identitāti
- Apstiprinātāja identitāti
- Sākuma un beigu laiku
- MFA vai autentifikācijas pierādījumus
- Sesijas ierakstu vai komandu žurnālu
- Sistēmas žurnālus un SIEM brīdinājumu
- Veiktās izmaiņas
- Autentifikācijas datu atiestatīšanas apstiprinājumu
- Pārskatīšanu pēc izmantošanas
- Datu piekļuves izvērtēšanu
- Regulatīvās paziņošanas izvērtēšanu
- Korektīvās darbības, ja kaut kas neizdevās
Ja jūsu vingrinājums nevar sagatavot šo pakotni, kontroles pasākums nav gatavs auditam.
Slēptā kļūme: trešo pušu priviliģētā piekļuve
Daudzas organizācijas darbinieku administratorus pārvalda labāk nekā piegādātāju administratorus. Mākoņpakalpojumu, SaaS, fintech un pārvaldīto pakalpojumu vidēs tam jābūt otrādi.
NIS2 21. pants ietver piegādes ķēdes drošību un attiecības ar tiešajiem piegādātājiem un pakalpojumu sniedzējiem. DORA 28. līdz 30. pants finanšu struktūrām iet tālāk, prasot IKT trešo pušu riska stratēģiju, IKT pakalpojumu līgumu reģistrus, sākotnējo izpēti, koncentrācijas riska izvērtēšanu, audita tiesības, izbeigšanas tiesības, izstāšanās stratēģijas un līgumiskos drošības pasākumus.
Piegādātāju priviliģētajai piekļuvei jābūt PAM tvērumā, ja piegādātājs var administrēt ražošanas vidi, atbalstīt kritiskas vai svarīgas funkcijas, piekļūt personas datiem, mainīt drošības konfigurācijas, pārvaldīt rezerves kopijas, izvietot kodu vai ekspluatēt uzraudzības rīkus.
Clarysec parasti sagaida, ka piegādātāju priviliģētās piekļuves kontroles pasākumi ietver:
- Nominētus piegādātāja lietotājus, nevis koplietotus piegādātāja kontus
- Līgumiskās drošības prasības priviliģētai piekļuvei
- MFA un drošu attālinātu piekļuvi
- Laikierobežotus piekļuves logus
- Klienta apstiprinājumu ārkārtas piekļuvei
- Sesiju žurnālfiksēšanu vai līdzvērtīgas audita pēdas
- Tūlītēju atsaukšanu, kad mainās personāls
- Sadarbības pienākumus incidentu gadījumā
- Pierādījumu glabāšanu, kas saskaņota ar klienta audita vajadzībām
- Izstāšanās plānu piegādātāja piekļuves noņemšanai
NIST CSF 2.0 piegādes ķēdes rezultāti šeit ir cieši saskaņoti. Tie prasa piegādātāju lomas un pienākumus, piegādātāju prioritizāciju pēc kritiskuma, prasības līgumos, sākotnējo izpēti, pastāvīgu uzraudzību, piegādātāju iesaisti incidentu plānošanā un pēclīguma riska plānus.
Ja pārvaldīto pakalpojumu sniedzēja konts ir atbrīvots no jūsu iekšējās PAM darbplūsmas, tā nav ērtība. Tas ir augsta riska izņēmums, kam jāatrodas riska reģistrā, piegādātāju reģistrā un piekļuves tiesību pārskatīšanā.
Biežākie PAM un break-glass konstatējumi 2026. gadā
Clarysec iesaistēs konstatējumi reti ir pārsteidzoši. Tie parasti ir labu nodomu, operatīva spiediena un nepilnīgu pierādījumu kombinācijas.
Biežākie konstatējumi ir:
- Break-glass konti pastāv, bet nav iekļauti priviliģēto kontu uzskaitē.
- Ārkārtas konti ir izslēgti no parastās piekļuves tiesību pārskatīšanas.
- Organizācija nevar pierādīt, kurš izmantoja ārkārtas kontu.
- Konts pēc izmantošanas netika atiestatīts.
- Priviliģētās sesijas tiek žurnalētas, bet komandas netiek žurnalētas.
- Žurnāli pastāv lokāli, bet nav aizsargāti pret priviliģētiem lietotājiem.
- Mākoņvides root konti netiek testēti.
- MFA atjaunošanas procesi nav dokumentēti.
- Tiek ignorēta priviliģētā piekļuve CI/CD konveijeriem un servisa kontiem.
- Trešo pušu atbalsta piekļuve apiet iekšējo apstiprināšanu.
- Piekļuves apstiprinājums pastāv tērzēšanas ziņās, bet netiek saglabāts kā audita pierādījums.
- Darba attiecību izbeigšana noņem e-pastu un VPN, bet ne SaaS administratora tiesības.
- DPO netiek iesaistīts, ja priviliģētā piekļuve var atklāt personas datus.
- Incidentu rokasgrāmatās nav iekļauti NIS2, DORA vai GDPR paziņošanas lēmumpunkti.
Katru konstatējumu var apstrādāt, izmantojot ISO/IEC 27001:2022 riska apstrādi. Identificējiet risku, piešķiriet īpašnieku, izvēlieties kontroles pasākumus, atjauniniet Piemērojamības deklarāciju, ieviesiet apstrādes plānu un saglabājiet dokumentētus pierādījumus. Tā ir informācijas drošības pārvaldības sistēmas izmantošanas priekšrocība salīdzinājumā ar izkaisītu drošības uzdevumu kopumu.
Kā izskatās laba prakse
Nobriedušam PAM un break-glass darbības modelim ir piecas atkārtotas rutīnas.
Pirmkārt, katru mēnesi vai nepārtraukti uzskaitiet priviliģēto piekļuvi. Iekļaujiet cilvēku administratorus, servisa kontus, ārkārtas kontus, mākoņvides lomas, CI/CD identitātes, datubāzes lietotājus, priviliģētās utilītprogrammas un trešo pušu administratorus.
Otrkārt, piemērojiet minimāli nepieciešamās tiesības, izmantojot lomas, just-in-time privilēģiju paaugstināšanu un apstiprinājumus. Pastāvīgām privilēģijām jābūt retām, pamatotām un pārskatītām biežāk nekā standarta lietotāju piekļuvei.
Treškārt, uzraugiet priviliģēto uzvedību. Žurnalējiet autentifikāciju, sesijas ilgumu, MFA izmantošanu, komandas, konfigurācijas izmaiņas, datu eksportus, neveiksmīgus mēģinājumus, privilēģiju eskalāciju un priviliģēto utilītprogrammu izpildi.
Ceturtkārt, testējiet break-glass kontus pirms ārkārtas situācijas. Break-glass konts, kas nekad nav testēts, ir pieņēmums, nevis kontroles pasākums.
Piektkārt, ziņojiet vadībai. NIS2 un DORA gan kiberdrošības, gan IKT risku paceļ līdz vadības struktūras atbildībai. Valdei nav vajadzīgs katrs komandu žurnāls, bet tai ir vajadzīgas metrikas: priviliģēto kontu skaits, kavētas pārskatīšanas, ārkārtas aktivizācijas, piegādātāju administratoru konti, neveiksmīgi testi, kritiski izņēmumi un trūkumu novēršanas statuss.
Šeit Clarysec rīkkopa kļūst praktiska. Politiku bibliotēka dod pārvaldības valodu. Zenith Blueprint dod ieviešanas secību. Zenith Controls dod starpatbilstības kartējumu, kontroles pasākumu attiecības, atbalstošos standartus un audita metodoloģiju.
Nākamie soļi: pārvērtiet ārkārtas piekļuvi auditam gatavā noturībā
Ja jūsu organizācija pēdējo 90 dienu laikā nav testējusi break-glass piekļuvi, sāciet ar to. Nesāciet ar rīka izvēles darbsemināru. Sāciet ar pierādījumiem.
- Izveidojiet vai atjauniniet priviliģēto kontu uzskaiti.
- Identificējiet katru break-glass kontu un ārkārtas administrēšanas ceļu.
- Kartējiet katru kontu pret biznesa īpašnieku, sistēmas īpašnieku un datu ietekmi.
- Apstipriniet politikas pārklājumu, izmantojot Clarysec Lietotāju kontu un privilēģiju pārvaldības politika Lietotāju kontu un privilēģiju pārvaldības politika vai Lietotāju kontu un privilēģiju pārvaldības politika-sme Lietotāju kontu un privilēģiju pārvaldības politika - SME.
- Izmantojiet Zenith Blueprint Zenith Blueprint Controls in Action fāzes 19., 20., 22. un 16. soli, lai sasaistītu priviliģēto piekļuvi, priviliģētās utilītprogrammas, dzīves cikla pārskatīšanu un darba attiecību izbeigšanu.
- Izmantojiet Zenith Controls Zenith Controls, lai kartētu ISO/IEC 27002:2022 kontroles pasākumus 8.2, 5.18 un 8.15 pret NIS2, DORA, GDPR un NIST pierādījumu prasībām.
- Veiciet break-glass pierādījumu vingrinājumu un reģistrējiet rezultātus.
- Pievienojiet trūkumus risku apstrādes plānam un izsekojiet trūkumu novēršanu līdz slēgšanai.
Priviliģētā piekļuve ir vara. Break-glass piekļuve ir ārkārtas vara. 2026. gadā organizācijas, kas tīri atjaunosies pēc izspiedējprogrammatūras, mākoņvides darbības pārtraukumiem un identitātes atteicēm, būs tās, kas var pierādīt, ka ārkārtas piekļuve bija kontrolēta pirms krīzes, tās laikā un pēc tās.
Clarysec var palīdzēt jums izveidot šo pierādījumu — no politikas līdz kontroles pasākumu kartējumam un auditam gataviem pierādījumiem. Sāciet ar Zenith Blueprint, apvienojiet to ar Lietotāju kontu un privilēģiju pārvaldības politiku un Piekļuves kontroles politiku, pēc tam izmantojiet Zenith Controls, lai parādītu, kā jūsu PAM programma atbalsta ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 un COBIT 2019.
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council