PAM ir avarinės „break-glass“ paskyros ISO 27001 kontekste 2026 m.

Sekmadienio rytą 02:14 incidento vadovas gauna žinutę, kurios baiminasi kiekvienas vyriausiasis informacijos saugumo vadovas (CISO): „Produkcinės aplinkos autentifikavimas neveikia. Administravimo konsolė nepasiekiama. Duomenų bazės perjungimas į atsarginę aplinką įstrigo.“

Budintis debesijos inžinierius problemą mato, tačiau negali jos pašalinti. Jo įprastas privilegijuotasis vaidmuo priklauso nuo to paties tapatybės teikėjo, kurio paslauga dabar veikia ribotai. Operacijų vadovas prašo avarinių administratoriaus prisijungimo duomenų. Atitikties vadovas klausia, ar „break-glass“ paskyra kada nors buvo testuota. Duomenų apsaugos pareigūnas (DPO) klausia, ar prisijungimas prie produkcinės duomenų bazės gali atskleisti asmens duomenis. CISO užduoda klausimą, nuo kurio priklauso, ar tai bus kontroliuotas atkūrimas, ar audito košmaras:

„Ar galime įrodyti, kas naudojo avarinę prieigą, kodėl ją naudojo, ką atliko ir kad paskyra po to buvo nustatyta iš naujo?“

Kita organizacija gali susidurti su ta pačia problema tylesnėje aplinkoje. Finansinių technologijų įmonės CISO sėdi prieš išorės auditorius po neteisingos debesijos duomenų bazės konfigūracijos. Incidentas buvo greitai pašalintas, tačiau pagrindinė priežastis nekėlė pasitikėjimo. Trečiosios šalies kūrėjas turėjo nuolatines administratoriaus teises. Kai pagrindinis administratorius buvo nepasiekiamas, kūrėjas panaudojo „break-glass“ paskyrą, pagrįstą bendru slaptažodžiu, laikytu „saugioje“ pastaboje, prieinamoje DevOps komandai.

Auditoriai neapsiribojo vien neteisinga konfigūracija. Jie klausė, ar prieiga buvo terminuota, ar egzistavo individuali atskaitomybė, ar komandos buvo žurnalizuojamos, ar asmens duomenys buvo apsaugoti pagal GDPR Article 32, ar buvo įvykdyti DORA IRT rizikos įpareigojimai ir ar galima pagrįsti NIS2 kibernetinės higienos lūkesčių laikymąsi.

Tai yra realus 2026 m. privilegijuotos prieigos valdymo ir „break-glass“ paskyrų spaudimo taškas. PAM nebėra siauras tapatybės saugumo projektas. Tai vieta, kur susikerta ransomware, debesijos kompromitavimas, tiekėjų rizika, duomenų apsauga, veiklos atsparumas ir audito įrodymai.

Privilegijuota prieiga yra vieta, kurioje užpuolikai bando laimėti. „Break-glass“ prieiga yra vieta, kurioje gynėjai bando atkurti veiklą. Abi remiasi tuo pačiu pavojingu pajėgumu: padidintomis teisėmis, kuriomis galima apeiti kontrolės priemones, keisti konfigūracijas, skaityti jautrius duomenis, vykdyti raktų rotaciją, išjungti žurnalų registravimą, atkurti atsargines kopijas, diegti kodą arba sunaikinti įrodymus.

Praktinė Clarysec pozicija paprasta: avarinė prieiga yra būtina, tačiau nevaldoma avarinė prieiga yra nevaldoma rizika. Teisingas atsakymas nėra „jokių „break-glass“ paskyrų“. Teisingas atsakymas yra valdomas privilegijuotos prieigos valdymo modelis, apimantis inventorizavimą, patvirtinimą, laiko ribas, stiprų autentifikavimą, sesijų žurnalavimą, peržiūrą po naudojimo, prisijungimo duomenų nustatymą iš naujo ir audito įrodymus.

Kodėl privilegijuota prieiga yra valdybos lygmens atitikties klausimas

Žemesnės brandos aplinkose privilegijuota prieiga dažnai laikoma IT administravimo užduotimi. Kažkam reikia administratoriaus teisių, sukuriama užklausa, suteikiamas vaidmuo ir organizacija juda toliau. Toks modelis neatlaiko šiuolaikinių ransomware grėsmių, debesijai pritaikytos infrastruktūros, NIS2 atskaitomybės, DORA veiklos atsparumo ar GDPR pažeidimų vertinimo.

NIS2 direktyva kibernetinio saugumo valdyseną perkelia į valdybos darbotvarkę. Article 20 reikalauja, kad esminių ir svarbių subjektų valdymo organai patvirtintų kibernetinio saugumo rizikos valdymo priemones, prižiūrėtų jų įgyvendinimą ir dalyvautų kibernetinio saugumo mokymuose. Article 21 reikalauja tinkamų ir proporcingų techninių, operacinių ir organizacinių priemonių, įskaitant rizikos analizę, incidentų valdymą, veiklos tęstinumą, tiekimo grandinės saugumą, kontrolės priemonių veiksmingumą, kibernetinę higieną, personalo saugumą, prieigos kontrolę, turto valdymą ir, kai tinkama, MFA arba tęstinį autentifikavimą.

SaaS teikėjams, valdomų paslaugų teikėjams, valdomo saugumo paslaugų teikėjams, debesijos paslaugoms, duomenų centrams ir kitoms skaitmeninės infrastruktūros organizacijoms NIS2 taikymas priklauso nuo sektoriaus, dydžio, vaidmens, tarpvalstybinio poveikio ir įsisteigimo ES. Operacinė išvada tiesioginė: prieigos kontrolė nebėra paslėpta techniniame priede. Ji yra kibernetinės higienos bazinio lygio dalis, kurią vadovybė turi patvirtinti, stebėti ir taisyti.

Finansų subjektams Skaitmeninės veiklos atsparumo aktas keičia terminiją, bet ne esminę riziką. DORA taikomas nuo 2025 m. sausio 17 d. ir nustato vieningą IRT rizikos valdymo, reikšmingų su IRT susijusių incidentų pranešimo, skaitmeninės veiklos atsparumo testavimo ir IRT trečiųjų šalių rizikos valdymo sistemą. Article 5 reikalauja IRT rizikos valdysenos ir kontrolės tvarkos, pagal kurią valdymo organas apibrėžia, tvirtina, prižiūri IRT rizikos valdymo sistemą ir už ją atsako. Article 6 reikalauja dokumentuotos IRT rizikos valdymo sistemos su politikomis, procedūromis, protokolais ir priemonėmis IRT turtui apsaugoti. Article 17 reikalauja su IRT susijusių incidentų valdymo proceso, kuris aptinka, registruoja, klasifikuoja, eskaluoja incidentus ir atkuria saugią veiklą.

GDPR prideda privatumo ir atskaitomybės perspektyvą. Article 5(1)(f) reikalauja, kad asmens duomenys būtų tvarkomi užtikrinant vientisumą ir konfidencialumą. Article 5(2) reikalauja atskaitomybės. Article 25 reikalauja pritaikytosios ir standartizuotosios duomenų apsaugos. Article 32 reikalauja tinkamų techninių ir organizacinių priemonių tvarkymo saugumui užtikrinti. Jei privilegijuotas naudotojas gali eksportuoti klientų įrašus, pasiekti specialių kategorijų duomenis, išjungti audito žurnalus arba keisti saugojimo nustatymus be peržiūros, organizacija padarė ne vien IAM klaidą. Ji gali negebėti pagrįsti tinkamo saugumo.

ISO/IEC 27001:2022 yra valdymo sistemos pagrindas, leidžiantis šiuos įpareigojimus tvarkyti per vieną integruotą programą. Clause 4.2 reikalauja, kad organizacija suprastų suinteresuotąsias šalis ir jų reikalavimus, įskaitant teisinius, reguliacinius ir sutartinius įpareigojimus. Clause 5.1 reikalauja lyderystės ir įsipareigojimo. Clause 6.1.2 reikalauja informacijos saugos rizikos vertinimo. Clause 6.1.3 reikalauja rizikos valdymo priemonių parinkimo ir įgyvendinimo. Clause 8 reikalauja operacinio planavimo ir kontrolės.

Privilegijuotos prieigos atveju tai perkelia pokalbį nuo „kurį PAM įrankį turėtume įsigyti?“ prie „kokias rizikas valdome, kokios kontrolės priemonės parinktos, kas jas valdo, kaip jos vykdomos ir kokie įrodymai patvirtina, kad jos veikia?“

PAM nėra viena kontrolės priemonė, tai įrodymų grandinė

PAM įrankis gali saugoti slaptažodžius saugykloje, tarpininkauti sesijoms, įrašyti klavišų paspaudimus, keisti prisijungimo duomenis ir taikyti prieigą reikiamu laiku. Šios galimybės svarbios. Tačiau jei organizacija nėra apibrėžusi privilegijuotų vaidmenų, patvirtinusi avarinės prieigos, susiejusi prieigos su turtu, peržiūrėjusi teisių, apsaugojusi žurnalų ir apmokiusi administratorių, įrankis tampa daline kontrolės priemone su silpnu audito pagrindimu.

Naudingiausia privilegijuotą prieigą valdyti per kontrolės rezultatus, o ne per įrankių pavadinimus.

Zenith Controls: The Cross-Compliance Guide Zenith Controls ISO/IEC 27002:2022 kontrolę 8.2, Privilegijuotos prieigos teisės, laiko PAM traukos centru. Ši kontrolė klasifikuojama kaip prevencinė, palaikanti konfidencialumą, vientisumą ir prieinamumą, suderinta su kibernetinio saugumo sąvoka Protect, operaciniu pajėgumu Tapatybės ir prieigos valdymas ir saugumo sritimi Protection.

Kontrolė 8.2 yra reikšminga, nes ji susieja aplinkines kontrolės priemones, kurios privilegijuotą prieigą padaro audituojamą:

Todėl auditorius retai sustoja ties klausimu: „Ar turite PAM sistemą?“ Stipresni audito klausimai yra tokie: ar turite privilegijuotų paskyrų inventorių? Ar privilegijuoti vaidmenys patvirtinti? Ar teisės terminuotos? Ar avariniai prisijungimo duomenys apsaugoti? Ar galite įrodyti, kas juos naudojo? Ar komandos žurnalizuojamos? Ar įtraukti tiekėjų administratoriai? Ar prieigos teisės peržiūrimos? Ar prisijungimo duomenys nustatyti iš naujo? Ar išimtys priimtos kaip rizika?

Zenith Controls prieigos teisių susiejimas tai parodo tiesiogiai: prieigos teisių valdymas įgyvendina prieigos kontrolės principus, tokius kaip mažiausios teisės, būtinybė žinoti ir autorizavimas, o privilegijuotoms paskyroms reikia specialios priežiūros ir skubaus atšaukimo, kai jos nebereikalingos.

Politikos reikalavimai patikimai „break-glass“ prieigai

„Break-glass“ paskyra nėra bendras administratoriaus slaptažodis užklijuotame voke. 2026 m. toks modelis per silpnas debesijai, fintech, SaaS, sveikatos priežiūrai, valdomoms paslaugoms ir reguliuojamoms skaitmeninėms operacijoms.

Pagrįstam „break-glass“ modeliui reikia septynių minimalių politikos taisyklių:

1. Paskyra turi būti dokumentuota.
2. Paskyra turi būti patvirtinta.
3. Naudojimas, kai techniškai įmanoma, turi būti vienareikšmiškai priskiriamas konkrečiam asmeniui.
4. Naudojimas turi būti ribojamas tik tikromis avarinėmis situacijomis.
5. Naudojimas turi būti žurnalizuojamas ir peržiūrimas.
6. Prisijungimo duomenys arba autentifikavimo veiksniai po naudojimo turi būti nustatomi iš naujo arba keičiami.
7. Paskyra turi būti testuojama ir įtraukta į audito apimtį.

Clarysec politikų biblioteka šiuos principus paverčia praktiškai naudojama valdysenos kalba.

Naudotojų paskyrų ir privilegijų valdymo politika MVĮ Naudotojų paskyrų ir privilegijų valdymo politika - MVĮ nurodo:

„Avarinė prieiga (pvz., „break-glass“ administratoriaus paskyros) turi būti aiškiai dokumentuota, apsaugota ir naudojama tik tada, kai tai absoliučiai būtina.“

Iš skyriaus „Rizikos valdymas ir išimtys“, politikos nuostata 7.3.1.

Ta pati MVĮ politika tęsia:

„Tokios paskyros turi būti žurnalizuojamos, peržiūrimos po naudojimo ir nustatomos iš naujo po kiekvieno avarinio įvykio.“

Iš skyriaus „Rizikos valdymas ir išimtys“, politikos nuostata 7.3.2.

Kasdieniam privilegijų pakėlimui MVĮ politika taip pat reikalauja:

„Padidintoms arba administratoriaus privilegijoms reikalingas papildomas generalinio direktoriaus arba IT vadovo patvirtinimas; jos turi būti dokumentuotos, terminuotos ir periodiškai peržiūrimos.“

Iš skyriaus „Politikos įgyvendinimo reikalavimai“, politikos nuostata 6.2.2.

Didesnėms organizacijoms įmonės politikų rinkinys numato išsamesnius reikalavimus. Naudotojų paskyrų ir privilegijų valdymo politika Naudotojų paskyrų ir privilegijų valdymo politika reikalauja:

„Privilegijuotos sesijos turi būti visiškai žurnalizuojamos, įskaitant išduotas komandas ir atliktus veiksmus. Žurnalus turi periodiškai peržiūrėti paskirti peržiūrėtojai.“

Iš skyriaus „Politikos įgyvendinimo reikalavimai“, politikos nuostata 6.4.2.

Ta pati politika reikalauja, kad laikinos arba avarinės privilegijuotos prieigos paskyros pagal 6.2.5 nuostatą laikytųsi dokumentuotos „break-glass“ procedūros, o 7.4 nuostata apibrėžia šios procedūros reikalavimus.

Prieigos kontrolės politika Prieigos kontrolės politika sustiprina saugojimą audito tikslais:

„Patvirtinimo sprendimai turi būti žurnalizuojami ir saugomi audito tikslais ne trumpiau kaip 2 metus.“

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

Žurnalų registravimo ir stebėsenos politika MVĮ Žurnalų registravimo ir stebėsenos politika - MVĮ nustato autentifikavimo žurnalavimo lūkesčius:

„Autentifikavimo žurnalai: sėkmingi ir nesėkmingi prisijungimo bandymai, sesijos trukmė, MFA naudojimas“

Iš skyriaus „Valdysenos reikalavimai“, politikos nuostata 5.4.2.

Kartu šios nuostatos avarinę prieigą paverčia ne herojišku apėjimo sprendimu, o kontroliuojamu įvykiu. Paskyra yra išimtinė, tačiau valdysena – ne.

Zenith Blueprint požiūris į PAM įgyvendinimą

Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint privilegijuotą prieigą traktuoja kaip praktinę įgyvendinimo problemą, o ne teorinį kontrolės teiginį. Fazėje „Kontrolės priemonės praktikoje“, 19 žingsnyje „Technologinės kontrolės priemonės I“, nurodoma:

„Bet kurioje informacinėje sistemoje privilegijuota prieiga yra galia, o su šia galia ateina rizika.“

Iš fazės „Kontrolės priemonės praktikoje“, 19 žingsnis: Technologinės kontrolės priemonės I.

19 žingsnis reikalauja, kad organizacijos identifikuotų privilegijuotas paskyras vietinėse, debesijos, SaaS, kūrimo ir infrastruktūros aplinkose. Tai apima domeno administratorius, root naudotojus, debesijos nuomininko administratorius, duomenų bazių supernaudotojus ir CI/CD konvejerių valdiklius. Jame taip pat pabrėžiamas privilegijuotos prieigos mažinimas taikant vaidmenimis grindžiamą prieigos kontrolę, privilegijų pakėlimą reikiamu laiku ir patvirtinimo darbo eigas.

Tai svarbu, nes daug rimtų incidentų neprasideda nuo formalios „break-glass“ paskyros. Jie prasideda nuo nuolatinių privilegijų. Debesijos inžinierius pasilieka savininko teises „dėl viso pikto“. Duomenų bazės administratorius išlaiko produkcinės aplinkos prieigą po perėjimo į kitą komandą. CI/CD paslaugų paskyra turi plačius leidimus skirtingose aplinkose. Valdomų paslaugų teikėjo paskyra atleidžiama nuo MFA, nes „jiems reikia greitos prieigos“.

Zenith Blueprint 20 žingsnis tą patį principą išplečia privilegijuotoms pagalbinėms programoms. Jis nurodo organizacijoms sukurti arba atnaujinti privilegijuotų pagalbinių programų inventorių, apriboti vykdymą autorizuotiems administratoriams, patikrinti, ar naudojimas žurnalizuojamas ir generuoja įspėjimus, ir apsvarstyti scenarijų žurnalavimą, pavyzdžiui, PowerShell žurnalavimą taikant grupės politiką. Tai kritiška, nes privilegijuota paskyra dažnai yra tik pradinis taškas. Žala atsiranda tada, kai užpuolikas paleidžia įrankius, kurie išjungia kontrolės priemones, išgauna prisijungimo duomenis arba juda lateraliai.

22 žingsnis formalizuoja prieigos kontrolės gyvavimo ciklą. Jis reikalauja struktūruoto prieigos suteikimo ir prieigos panaikinimo, idealiu atveju integruoto su HR ir palaikomo prieigos užklausų darbo eigomis, su ketvirtinėmis dokumentuotomis prieigos peržiūromis. 16 žingsnis susieja gyvavimo ciklą su darbo santykių nutraukimo procesu, reikalaudamas darbuotojo atleidimo kontrolinio sąrašo, kurį kartu naudoja HR ir IT, įskaitant paskyrų išjungimą, turto grąžinimą ir NDA priminimus.

Zenith Blueprint PAM paverčia susietu veiklos modeliu: tapatybė, HR, privilegijuotos pagalbinės programos, žurnalų registravimas, reagavimas į incidentus, prieigos peržiūros ir audito įrodymai sustiprina vieni kitus.

Praktinis „break-glass“ valdysenos modelis 2026 m.

Gerai suprojektuotas „break-glass“ procesas turi veikti gedimo metu. Jei jis priklauso nuo to paties tapatybės teikėjo, užklausų platformos ir pokalbių paslaugos, kurios per sutrikimą nepasiekiamos, tai tik imitacija.

Kartu avarinė prieiga negali tapti patogumo apėjimo kanalu. Clarysec paprastai projektuoja „break-glass“ valdyseną pagal keturis sluoksnius: prevenciją, aktyvavimą, stebėjimą ir atkūrimą.

Debesijos aplinkose įtraukite nuomininko lygmens administratorius, debesijos root paskyras, avarinius tapatybės teikėjo administratorius, privilegijuotas paslaugų paskyras, duomenų bazių pagrindinius naudotojus, Kubernetes cluster-admin vaidmenis, CI/CD diegimo raktus, paslapčių saugyklų administratorius ir trečiųjų šalių palaikymo paskyras.

Hibridinėse aplinkose įtraukite domeno administratorius, atsarginių kopijų administratorius, hipervizorių administratorius, ugniasienių administratorius, EDR konsolių administratorius ir privilegijuotų pagalbinių programų naudotojus.

Privatumo požiūriu jautriose aplinkose įtraukite administratorius, kurie gali pasiekti duomenų bazes su asmens duomenimis, žurnalus su identifikatoriais, HR įrašus, biometrinės tapatybės tikrinimo duomenis, sukčiavimo stebėsenos sistemas arba klientų aptarnavimo priemones.

Tikslinę būseną paprasta apibūdinti ir sunku suklastoti: kiekvienas avarinis kelias yra žinomas, patvirtintas, apsaugotas, stebimas, grąžinamas į ankstesnę būseną ir peržiūrimas.

60 minučių „break-glass“ įrodymų pratybos

CISO arba atitikties vadovas šią savaitę gali atlikti naudingas „break-glass“ pratybas neįsigydamas naujo įrankio. Tikslas nėra vien patvirtinti, kad paskyra veikia. Tikslas yra įrodyti, kad kontrolės priemonė sukuria įrodymus.

Scenarijus

Tarkime, kad pagrindinis tapatybės teikėjas veikia ribotai. Įprastas privilegijų pakėlimas reikiamu laiku nepasiekiamas. Produkcinės duomenų bazės klasteriui reikia avarinių konfigūracijos pakeitimų paslaugai atkurti. Turi būti aktyvuota „break-glass“ debesijos administratoriaus paskyra.

1 žingsnis. Patvirtinkite, kad paskyra yra privilegijuotų paskyrų inventoriuje

Naudokite Zenith Blueprint, fazę „Kontrolės priemonės praktikoje“, 19 žingsnį, kad patikrintumėte, ar paskyra įtraukta į privilegijuotų paskyrų inventorių. Užregistruokite paskyros pavadinimą ir aplinką, verslo savininką, techninį savininką, pasiekiamas sistemas, poveikį asmens duomenims, autentifikavimo metodą, saugyklos vietą, rotacijos metodą ir paskutinio testo datą.

Jei paskyros nėra, vertinkite tai kaip kontrolės spragą ir įtraukite ją į rizikų registrą.

2 žingsnis. Patikrinkite suderinimą su politika

Susiekite įvykį su Naudotojų paskyrų ir privilegijų valdymo politikos reikalavimais dėl dokumentuotų „break-glass“ procedūrų ir privilegijuotų sesijų žurnalavimo. Jei esate MVĮ, naudokite Naudotojų paskyrų ir privilegijų valdymo politika MVĮ 7.3.1 ir 7.3.2 nuostatas kaip minimalų bazinį lygį: dokumentuota, apsaugota, būtina, žurnalizuojama, peržiūrima ir nustatoma iš naujo.

Patvirtinimų saugojimą susiekite su Prieigos kontrolės politikos 5.3.2 nuostata, kuri reikalauja, kad patvirtinimo sprendimai būtų žurnalizuojami ir saugomi bent 2 metus.

3 žingsnis. Sukurkite avarinės prieigos įrašą

Sukurkite užklausą arba incidento įrašą prieš aktyvavimą arba aktyvavimo metu. Įtraukite:

• Avarinės situacijos priežastį
• Paveiktą paslaugą
• Prašomą paskyrą
• Prašytoją
• Tvirtintoją
• Pradžios laiką
• Numatytą pabaigos laiką
• Poveikį klientams arba reguliacinei atitikčiai
• GDPR asmens duomenų poveikį
• NIS2 arba DORA pranešimo stebėjimo žymą

Nelaukite pabaigos, kad atkurtumėte istoriją. Audito vertė didžiausia, kai įrašas pradedamas prieš naudojant prieigą.

4 žingsnis. Aktyvuokite ir stebėkite

Aktyvuokite „break-glass“ paskyrą. Patvirtinkite, kad naudojama MFA arba kompensuojantis autentifikavimas, sesija įrašoma, komandos arba administraciniai veiksmai žurnalizuojami, žurnalai persiunčiami į centralizuotą žurnalų registravimo sistemą, laiko sinchronizavimas leidžia atkurti laiko juostą ir sugeneruojamas įspėjimas apie avarinės paskyros naudojimą.

Tai atitinka Zenith Controls dėl 8.15 Žurnalų registravimo, kuriame žurnalų registravimas apibūdinamas kaip bazinis duomenų sluoksnis stebėsenai ir pažymima, kad privilegijuoti naudotojai ir privilegijuotų pagalbinių programų vykdymas turi būti išsamiai žurnalizuojami.

5 žingsnis. Uždarykite, nustatykite iš naujo ir peržiūrėkite

Po avarinės užduoties išjunkite paskyrą arba grąžinkite ją į užantspauduotą būseną, pakeiskite prisijungimo duomenis arba nustatykite autentifikavimo veiksnį iš naujo, peržiūrėkite sesijos žurnalus, dokumentuokite komandas ir konfigūracijos pakeitimus, patvirtinkite, kad neįvyko nereikalinga prieiga prie duomenų, atnaujinkite incidento įrašą, užregistruokite išmoktas pamokas ir nuspręskite, ar pasiekti NIS2, DORA arba GDPR pranešimo slenksčiai.

Jei buvo pasiekti asmens duomenys, įtraukite DPO. Jei įvykis sukėlė paslaugos sutrikimą arba galėjo sukelti reikšmingą poveikį, įtraukite NIS2 arba DORA pranešimų savininką. Jei „break-glass“ paskyra nesuveikė, dokumentuokite tai kaip veiklos atsparumo išvadą, o ne vien IAM problemą.

PAM ir „break-glass“ kontrolės priemonių susiejimas su keliais atitikties reikalavimais

Stipriausias valdysenos modelis nedubliuoja kontrolės priemonių kiekvienam reglamentui. Jis sukuria vieną įrodymų grandinę, palaikančią kelis įpareigojimus.

NIST CSF 2.0 ypač naudingas verčiant PAM į esamą profilį ir tikslinį profilį. Jo profilio metodas prasideda nuo taikymo srities, tada surenka politikas, rizikos prioritetus, registrus, reikalavimus, praktikas ir darbo vaidmenis, o po to sukuria prioritetizuotą veiksmų planą. Privilegijuotai prieigai tai reiškia profilio taikymo sritį aplink tapatybės saugumą, debesijos administravimą, atsparumą ransomware, kritines finansų sistemas arba tiekėjų prieigą.

DORA taikomiems finansų subjektams DORA veikia kaip sektoriui skirtas ES kibernetinio atsparumo režimas lygiaverčiams NIS2 rizikos ir incidentų įpareigojimams. Tai nereiškia, kad NIS2 neaktuali. Tai reiškia, kad finansų subjektas turėtų naudoti DORA kaip pagrindinį režimą IRT rizikos ir incidentų reikalavimams, kartu palaikydamas koordinavimą su nacionalinėmis kibernetinio saugumo strategijomis, kompetentingomis institucijomis ir CSIRT, kai taikoma.

Kaip auditoriai testuoja privilegijuotos prieigos įrodymus

Auditoriai PAM vertina ne vien skaitydami politiką. Jie sulygina politiką, konfigūraciją, žurnalus, užklausas, interviu ir stebimą praktiką.

Zenith Controls audito metodika privilegijuotos prieigos teisėms remiasi ISO/IEC 19011:2018 audito praktikomis. Auditoriai peržiūri politikas, apibrėžiančias padidintas teises, suteikimo, stebėsenos ir atšaukimo procedūras. Jie tikrina naudotojų paskyrų inventorius, privilegijų priskyrimo įrašus ir žurnalus. Įrodymus jie patvirtina per interviu, PAM įrankius, katalogų paslaugas ir žurnalų pavyzdžius.

Dėl prieigos teisių Zenith Controls pažymi, kad auditoriai atrenka naudotojų prieigos užklausų pavyzdžius, tikrina dokumentuotus patvirtinimus ir patvirtina, kad IT suteikė tik patvirtintą prieigą. Jie taip pat lygina naudotojų vaidmenis su faktinėmis teisėmis, tikrindami, ar taikomas mažiausių privilegijų principas. Dėl žurnalų registravimo auditoriai tikrina žurnalų apimtį, įvykių tipus, saugojimo terminus, apsaugas ir faktinius žurnalų įrašus. Jie vertina, ar užfiksuojami ir peržiūrimi nesėkmingi prisijungimai, prieiga prie jautrių duomenų ir konfigūracijos pakeitimai.

Geras „break-glass“ įrodymų paketas apima:

• Patvirtintą avarinės prieigos prašymą
• Incidento arba paslaugos sutrikimo kontekstą
• Prieigą aktyvuojančio naudotojo tapatybę
• Tvirtintojo tapatybę
• Pradžios ir pabaigos laiką
• MFA arba autentifikavimo įrodymus
• Sesijos įrašą arba komandų žurnalą
• Sistemos žurnalus ir SIEM įspėjimą
• Atliktus pakeitimus
• Patvirtinimą, kad prisijungimo duomenys nustatyti iš naujo
• Peržiūrą po naudojimo
• Prieigos prie duomenų vertinimą
• Reguliacinio pranešimo vertinimą
• Korekcinius veiksmus, jei kas nors nesuveikė

Jei jūsų pratybos negali parengti šio paketo, kontrolės priemonė nėra tinkama auditui.

Paslėpta nesėkmė: trečiųjų šalių privilegijuota prieiga

Daugelis organizacijų darbuotojų administratorius valdo geriau nei tiekėjų administratorius. Debesijos, SaaS, fintech ir valdomų paslaugų aplinkose turėtų būti atvirkščiai.

NIS2 Article 21 apima tiekimo grandinės saugumą ir santykius su tiesioginiais tiekėjais bei paslaugų teikėjais. DORA Articles 28–30 finansų subjektams kelia dar griežtesnius reikalavimus: IRT trečiųjų šalių rizikos strategiją, IRT paslaugų sutarčių registrus, deramą patikrinimą, koncentracijos rizikos vertinimą, audito teises, nutraukimo teises, pasitraukimo strategijas ir sutartines saugumo priemones.

Privilegijuota tiekėjų prieiga turi būti PAM taikymo srityje, jei tiekėjas gali administruoti produkcinę aplinką, palaikyti kritines ar svarbias funkcijas, pasiekti asmens duomenis, keisti saugumo konfigūracijas, valdyti atsargines kopijas, diegti kodą arba eksploatuoti stebėsenos priemones.

Clarysec paprastai tikisi, kad tiekėjų privilegijuotos prieigos kontrolės priemonės apims:

• Vardinius tiekėjų naudotojus, o ne bendras tiekėjų paskyras
• Sutartinius saugumo reikalavimus privilegijuotai prieigai
• MFA ir saugią nuotolinę prieigą
• Terminuotus prieigos langus
• Kliento patvirtinimą avarinei prieigai
• Sesijų žurnalavimą arba lygiaverčius audito pėdsakus
• Nedelsiamą atšaukimą pasikeitus personalui
• Bendradarbiavimo incidentų metu įsipareigojimus
• Įrodymų saugojimą, suderintą su kliento audito poreikiais
• Pasitraukimo planą tiekėjo prieigai pašalinti

NIST CSF 2.0 tiekimo grandinės rezultatai čia stipriai dera. Jie reikalauja tiekėjų vaidmenų ir atsakomybių, tiekėjų prioritetizavimo pagal kritiškumą, reikalavimų sutartyse, deramo patikrinimo, nuolatinės stebėsenos, tiekėjų dalyvavimo incidentų planavime ir rizikos planų po sutarties pabaigos.

Jei valdomų paslaugų teikėjo paskyra atleidžiama nuo jūsų vidinės PAM darbo eigos, tai nėra patogumas. Tai didelės rizikos išimtis, kuri turi būti rizikų registre, tiekėjų registre ir prieigos peržiūroje.

Dažnos PAM ir „break-glass“ išvados 2026 m.

Clarysec projektuose išvados retai būna netikėtos. Paprastai tai yra gerų ketinimų, operacinio spaudimo ir neišsamių įrodymų deriniai.

Dažniausios išvados:

• „Break-glass“ paskyros egzistuoja, bet nėra įtrauktos į privilegijuotų paskyrų inventorių.
• Avarinės paskyros neįtraukiamos į įprastas prieigos peržiūras.
• Organizacija negali įrodyti, kas naudojo avarinę paskyrą.
• Paskyra po naudojimo nebuvo nustatyta iš naujo.
• Privilegijuotos sesijos žurnalizuojamos, bet komandos – ne.
• Žurnalai yra vietoje, bet nėra apsaugoti nuo privilegijuotų naudotojų.
• Debesijos root paskyros netestuojamos.
• MFA atkūrimo procesai nedokumentuoti.
• Ignoruojama privilegijuota prieiga CI/CD konvejeriams ir paslaugų paskyroms.
• Trečiųjų šalių palaikymo prieiga apeina vidinį patvirtinimą.
• Prieigos patvirtinimas yra pokalbių žinutėse, bet nesaugomas kaip audito įrodymas.
• Darbo santykių nutraukimo procesas pašalina el. paštą ir VPN, bet ne SaaS administratoriaus teises.
• DPO neįtraukiamas, kai privilegijuota prieiga gali atskleisti asmens duomenis.
• Incidentų veiksmų planuose nėra NIS2, DORA arba GDPR pranešimo sprendimo taškų.

Kiekvieną išvadą galima valdyti per ISO/IEC 27001:2022 rizikos valdymo priemones. Identifikuokite riziką, priskirkite savininką, parinkite kontrolės priemones, atnaujinkite Taikomumo pareiškimą, įgyvendinkite rizikos valdymo priemonių planą ir saugokite dokumentuotus įrodymus. Tai yra ISVS naudojimo galia, palyginti su išskaidytu saugumo užduočių rinkiniu.

Kaip atrodo geras modelis

Brandus PAM ir „break-glass“ veiklos modelis turi penkias pasikartojančias rutinas.

Pirma, kas mėnesį arba nuolat inventorizuokite privilegijuotą prieigą. Įtraukite žmogiškuosius administratorius, paslaugų paskyras, avarines paskyras, debesijos vaidmenis, CI/CD tapatybes, duomenų bazių naudotojus, privilegijuotas pagalbines programas ir trečiųjų šalių administratorius.

Antra, taikykite mažiausių privilegijų principą per vaidmenis, privilegijų pakėlimą reikiamu laiku ir patvirtinimus. Nuolatinės privilegijos turi būti retos, pagrįstos ir peržiūrimos dažniau nei standartinė naudotojų prieiga.

Trečia, stebėkite privilegijuotą elgseną. Žurnalizuokite autentifikavimą, sesijos trukmę, MFA naudojimą, komandas, konfigūracijos pakeitimus, duomenų eksportą, nesėkmingus bandymus, privilegijų pakėlimą ir privilegijuotų pagalbinių programų vykdymą.

Ketvirta, testuokite „break-glass“ paskyras prieš avarinę situaciją. „Break-glass“ paskyra, kuri niekada nebuvo testuota, yra prielaida, o ne kontrolės priemonė.

Penkta, teikite ataskaitas vadovybei. NIS2 ir DORA kibernetinį saugumą ir IRT riziką perkelia į valdymo organo atsakomybės lygmenį. Valdybai nereikia kiekvieno komandų žurnalo, bet jai reikia rodiklių: privilegijuotų paskyrų skaičiaus, vėluojančių peržiūrų, avarinės prieigos aktyvavimų, tiekėjų administratorių paskyrų, nepavykusių testų, kritinių išimčių ir trūkumų šalinimo būsenos.

Čia Clarysec įrankių rinkinys tampa praktiškas. Politikų biblioteka suteikia valdysenos kalbą. Zenith Blueprint pateikia įgyvendinimo seką. Zenith Controls suteikia susiejimą su keliais atitikties reikalavimais, kontrolės ryšius, palaikančius standartus ir audito metodiką.

Kiti žingsniai: paverskite avarinę prieigą auditui tinkamu atsparumu

Jei jūsų organizacija per pastarąsias 90 dienų netestavo „break-glass“ prieigos, pradėkite nuo to. Nepradėkite nuo įrankio pasirinkimo dirbtuvių. Pradėkite nuo įrodymų.

1. Sukurkite arba atnaujinkite privilegijuotų paskyrų inventorių.
2. Identifikuokite kiekvieną „break-glass“ paskyrą ir avarinio administravimo kelią.
3. Susiekite kiekvieną paskyrą su verslo savininku, sistemos savininku ir poveikiu duomenims.
4. Patvirtinkite politikos aprėptį naudodami Clarysec Naudotojų paskyrų ir privilegijų valdymo politiką Naudotojų paskyrų ir privilegijų valdymo politika arba Naudotojų paskyrų ir privilegijų valdymo politiką MVĮ Naudotojų paskyrų ir privilegijų valdymo politika - MVĮ.
5. Naudokite Zenith Blueprint Zenith Blueprint fazės „Kontrolės priemonės praktikoje“ 19, 20, 22 ir 16 žingsnius, kad susietumėte privilegijuotą prieigą, privilegijuotas pagalbines programas, gyvavimo ciklo peržiūras ir darbo santykių nutraukimo procesą.
6. Naudokite Zenith Controls Zenith Controls, kad susietumėte ISO/IEC 27002:2022 kontroles 8.2, 5.18 ir 8.15 su NIS2, DORA, GDPR ir NIST įrodymų lūkesčiais.
7. Atlikite „break-glass“ įrodymų pratybas ir užregistruokite rezultatus.
8. Įtraukite spragas į rizikos valdymo priemonių planą ir sekite trūkumų šalinimą iki uždarymo.

Privilegijuota prieiga yra galia. „Break-glass“ prieiga yra avarinė galia. 2026 m. organizacijos, kurios tvarkingai atsigaus po ransomware atakų, debesijos sutrikimų ir tapatybės gedimų, bus tos, kurios galės įrodyti, kad avarinė prieiga buvo kontroliuojama prieš krizę, jos metu ir po jos.

Clarysec gali padėti sukurti šį įrodymą – nuo politikos iki kontrolės susiejimo ir auditui tinkamų įrodymų. Pradėkite nuo Zenith Blueprint, derinkite jį su Naudotojų paskyrų ir privilegijų valdymo politika ir Prieigos kontrolės politika, tada naudokite Zenith Controls, kad parodytumėte, kaip jūsų PAM programa palaiko ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 ir COBIT 2019.