PAM og break-glass-konti for ISO 27001 i 2026

Kl. 02:14 en søndag morgen modtager hændelseslederen den besked, enhver CISO frygter: “Produktionsautentifikation fejler. Administrationskonsollen kan ikke nås. Database-failover sidder fast.”

Den vagthavende cloudingeniør kan se problemet, men kan ikke rette det. Den normale privilegerede rolle afhænger af den samme identitetsudbyder, som nu er forringet. Driftslederen beder om nødlegitimationsoplysningerne til administratoren. Den complianceansvarlige spørger, om break-glass-kontoen nogensinde er blevet testet. DPO’en spørger, om adgang til produktionsdatabasen kan eksponere personoplysninger. CISO’en stiller det spørgsmål, der afgør, om dette bliver en kontrolleret genopretning eller et revisionsmæssigt mareridt:

“Kan vi dokumentere, hvem der brugte nødadgangen, hvorfor, hvad de gjorde, og at kontoen efterfølgende blev nulstillet?”

En anden organisation kan stå med samme problem i et mere stille lokale. En fintech-CISO sidder over for eksterne revisorer efter en fejlkonfiguration i en clouddatabase. Hændelsen blev rettet hurtigt, men rodårsagen var ikke betryggende. En tredjepartsudvikler havde stående administrative rettigheder. Da den primære administrator ikke var tilgængelig, brugte udvikleren en break-glass-konto baseret på en delt adgangskode, der var gemt i en “sikker” note med adgang for DevOps-teamet.

Revisorerne fokuserede ikke kun på fejlkonfigurationen. De spurgte, om adgangen var tidsbegrænset, om der fandtes individuel ansvarlighed, om kommandoer blev logget, om personoplysninger var beskyttet efter GDPR Article 32, om DORA-forpligtelser vedrørende IKT-risiko var opfyldt, og om NIS2-forventninger til cyberhygiejne kunne dokumenteres.

Det er det praktiske prespunkt for styring af privilegeret adgang og break-glass-konti i 2026. PAM er ikke længere et nicheprojekt inden for identitetssikkerhed. Det er dér, ransomware, cloudkompromittering, leverandørrisiko, databeskyttelse, operationel robusthed og revisionsbevismateriale mødes.

Privilegeret adgang er dér, angribere forsøger at vinde. Break-glass-adgang er dér, forsvarere forsøger at komme sig. Begge bygger på den samme farlige kapacitet: forhøjet adgang, der kan omgå kontroller, ændre konfigurationer, læse følsomme data, rotere nøgler, deaktivere logning, gendanne sikkerhedskopier, udrulle kode eller ødelægge bevismateriale.

Clarysecs praktiske position er enkel: Nødadgang er nødvendig, men ustyret nødadgang er ustyret risiko. Det rigtige svar er ikke “ingen break-glass-konti”. Det rigtige svar er en styret model for privilegeret adgang med fortegnelse, godkendelse, tidsbegrænsning, stærk autentifikation, sessionslogning, gennemgang efter brug, nulstilling af legitimationsoplysninger og revisionsbevismateriale.

Hvorfor privilegeret adgang er et complianceanliggende på bestyrelsesniveau

I miljøer med lavere modenhed behandles privilegeret adgang ofte som en IT-administrationsopgave. Nogen har brug for administratorrettigheder, en sag oprettes, en rolle tildeles, og forretningen fortsætter. Den model holder ikke over for moderne ransomware, cloudbaseret infrastruktur, NIS2-ansvarlighed, DORA-operationel robusthed eller GDPR-kontrol ved brud.

NIS2 Directive placerer cybersikkerhedsstyring i bestyrelseslokalet. Article 20 kræver, at ledelsesorganer i væsentlige og vigtige enheder godkender risikostyringsforanstaltninger for cybersikkerhed, fører tilsyn med implementeringen og gennemfører cybersikkerhedstræning. Article 21 kræver passende og forholdsmæssige tekniske, driftsmæssige og organisatoriske foranstaltninger, herunder risikoanalyse, håndtering af hændelser, forretningskontinuitet, sikkerhed i forsyningskæden, kontroleffektivitet, cyberhygiejne, HR-sikkerhed, adgangsstyring, politikker for aktivstyring og MFA eller løbende autentifikation, hvor det er relevant.

For SaaS-udbydere, managed service providers, managed security providers, cloudtjenester, datacentre og andre organisationer inden for digital infrastruktur afhænger NIS2-anvendelighed af sektor, størrelse, rolle, grænseoverskridende påvirkning og etablering i EU. Den driftsmæssige læring er direkte: Adgangsstyring er ikke længere begravet i et teknisk bilag. Den er en del af den baseline for cyberhygiejne, som ledelsen skal godkende, overvåge og korrigere.

For finansielle enheder ændrer Digital Operational Resilience Act sproget, men ikke den underliggende risiko. DORA finder anvendelse fra 17. januar 2025 og etablerer et ensartet rammeværk for styring af IKT-risiko, rapportering af større IKT-relaterede hændelser, test af digital operationel robusthed og styring af IKT-tredjepartsrisiko. Article 5 kræver styrings- og kontrolordninger for IKT-risiko, hvor ledelsesorganet definerer, godkender, fører tilsyn med og har ansvar for IKT-risikoordninger. Article 6 kræver et dokumenteret IKT-risikostyringsrammeværk med politikker, procedurer, protokoller og værktøjer til beskyttelse af IKT-aktiver. Article 17 kræver en proces for IKT-relateret hændelsesstyring, som detekterer, registrerer, klassificerer, eskalerer og genetablerer sikker drift.

GDPR tilføjer privatlivs- og ansvarlighedsperspektivet. Article 5(1)(f) kræver, at personoplysninger behandles med integritet og fortrolighed. Article 5(2) kræver ansvarlighed. Article 25 kræver databeskyttelse gennem design og standardindstillinger. Article 32 kræver passende tekniske og organisatoriske foranstaltninger for behandlingssikkerhed. Hvis en privilegeret bruger kan eksportere kunderegistre, tilgå særlige kategorier af oplysninger, deaktivere revisionslogs eller ændre opbevaringsindstillinger uden gennemgang, har organisationen ikke blot begået en IAM-fejl. Den kan være ude af stand til at dokumentere passende sikkerhed.

ISO/IEC 27001:2022 er rygraden i ledelsessystemet, som gør det muligt at håndtere disse forpligtelser gennem ét integreret program. Clause 4.2 kræver, at organisationen forstår interessenter og deres krav, herunder retlige, regulatoriske og kontraktlige forpligtelser. Clause 5.1 kræver lederskab og forpligtelse. Clause 6.1.2 kræver informationssikkerhedsrisikovurdering. Clause 6.1.3 kræver risikobehandling. Clause 8 kræver operationel planlægning og styring.

For privilegeret adgang flytter dette samtalen fra “hvilket PAM-værktøj skal vi købe?” til “hvilke risici behandler vi, hvilke kontroller er valgt, hvem ejer dem, hvordan driftes de, og hvilket bevismateriale dokumenterer, at de virker?”

PAM er ikke én kontrol, men en kæde af bevismateriale

Et PAM-værktøj kan opbevare adgangskoder i vault, formidle sessioner, registrere tastetryk, rotere legitimationsoplysninger og håndhæve Just-in-Time-adgang. De kapaciteter er vigtige. Men hvis organisationen ikke har defineret privilegerede roller, godkendt nødadgang, kortlagt adgang til aktiver, gennemgået rettigheder, beskyttet logfiler og uddannet administratorer, bliver værktøjet en delvis kontrol med svag revisionsmæssig forsvarlighed.

Den mest anvendelige måde at styre privilegeret adgang på er at tænke i kontrolresultater, ikke i værktøjsnavne.

Zenith Controls: The Cross-Compliance Guide Zenith Controls behandler ISO/IEC 27002:2022-kontrol 8.2, Privilegerede adgangsrettigheder, som tyngdepunktet for PAM. Den klassificerer denne kontrol som forebyggende, understøttende for fortrolighed, integritet og tilgængelighed, tilpasset cybersikkerhedskonceptet Protect, den operationelle kapacitet identitets- og adgangsstyring (IAM) og sikkerhedsdomænet Protection.

Kontrol 8.2 er stærk, fordi den hænger sammen med de omkringliggende kontroller, der gør privilegeret adgang reviderbar:

Derfor stopper en revisor sjældent ved spørgsmålet: “Har I et PAM-system?” De stærkere revisionsspørgsmål er: Har I en fortegnelse over privilegerede konti? Er privilegerede roller godkendt? Er rettigheder tidsbegrænsede? Er nødlegitimationsoplysninger sikret? Kan I dokumentere, hvem der brugte dem? Bliver kommandoer logget? Er leverandøradministratorer omfattet? Gennemgås adgangsrettigheder? Blev legitimationsoplysninger nulstillet? Blev undtagelser risikoaccepteret?

Zenith Controls-kortlægningen for adgangsrettigheder gør pointen direkte: Styring af adgangsrettigheder operationaliserer adgangsstyringsprincipper som mindst privilegieprincip, need-to-know-princippet og godkendelse, mens privilegerede konti kræver særlig kontrol og hurtig tilbagekaldelse, når de ikke længere er nødvendige.

Politikkrav til troværdig break-glass-adgang

En break-glass-konto er ikke en delt administratoradgangskode i en forseglet kuvert. I 2026 er den model for svag til cloud, fintech, SaaS, sundhedssektoren, managed services og reguleret digital drift.

En forsvarlig break-glass-model kræver syv minimumsregler i politikken:

1. Kontoen skal dokumenteres.
2. Kontoen skal godkendes.
3. Brug skal kunne henføres entydigt, hvor det er teknisk muligt.
4. Brug skal begrænses til reelle nødsituationer.
5. Brug skal logges og gennemgås.
6. Legitimationsoplysninger eller autentifikationsfaktorer skal nulstilles eller roteres efter brug.
7. Kontoen skal testes og indgå i revisionsomfanget.

Clarysecs politikbibliotek omsætter disse principper til anvendeligt styringssprog.

Politik for styring af brugerkonti og privilegier - SME Politik for styring af brugerkonti og privilegier - SME angiver:

“Nødadgang (f.eks. “break glass”-administratorkonti) skal være klart dokumenteret, sikret og må kun bruges, når det er absolut nødvendigt.”

Fra afsnittet “Risikobehandling og undtagelser,” politikklausul 7.3.1.

Den samme SME-politik fortsætter:

“Sådanne konti skal logges, gennemgås efter brug og nulstilles efter hver nødhændelse.”

Fra afsnittet “Risikobehandling og undtagelser,” politikklausul 7.3.2.

For daglig privilegieforøgelse kræver SME-politikken også:

“Forhøjede eller administrative rettigheder kræver yderligere godkendelse fra direktøren eller IT-ansvarlig og skal dokumenteres, være tidsbegrænsede og underlægges periodisk gennemgang.”

Fra afsnittet “Krav til implementering af politikken,” politikklausul 6.2.2.

For større organisationer går virksomhedsudgaven af politikken dybere. Politik for styring af brugerkonti og privilegier Politik for styring af brugerkonti og privilegier kræver, at:

“Privilegerede sessioner skal logges fuldt ud, herunder udstedte kommandoer og udførte handlinger. Logfiler skal gennemgås periodisk af udpegede gennemgangsansvarlige.”

Fra afsnittet “Krav til implementering af politikken,” politikklausul 6.4.2.

Den samme politik kræver, at midlertidige eller nødrelaterede privilegerede adgangskonti følger en dokumenteret break-glass-procedure i klausul 6.2.5, mens klausul 7.4 beskriver kravene til denne procedure.

Politik for adgangskontrol Politik for adgangskontrol styrker revisionsopbevaring:

“Godkendelsesbeslutninger skal logges og opbevares til revisionsformål i mindst 2 år.”

Fra afsnittet “Styringskrav,” politikklausul 5.3.2.

Lognings- og overvågningspolitik - SME Lognings- og overvågningspolitik - SME identificerer forventninger til autentifikationslogning:

“Autentifikationslogfiler: vellykkede og mislykkede loginforsøg, sessionsvarighed, MFA-brug”

Fra afsnittet “Styringskrav,” politikklausul 5.4.2.

Tilsammen gør disse klausuler nødadgang fra en heroisk nødvej til en kontrolleret hændelse. Kontoen er undtagelsen, men styringen er det ikke.

Zenith Blueprint-tilgangen til implementering af PAM

Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint behandler privilegeret adgang som et praktisk implementeringsproblem, ikke som en teoretisk kontrolerklæring. I fasen Controls in Action, Step 19, Technological Controls I, står der:

“I ethvert informationssystem er privilegeret adgang magt , og med den magt følger risiko.”

Fra fasen Controls in Action, Step 19: Technological Controls I.

Step 19 kræver, at organisationer identificerer privilegerede konti på tværs af on-premises-, cloud-, SaaS-, udviklings- og infrastrukturmiljøer. Det omfatter domæneadministratorer, root-brugere, cloud tenant-administratorer, database-superbrugere og CI/CD-pipeline-controllere. Det fremhæver også minimering af privilegeret adgang gennem rollebaseret adgangskontrol (RBAC), just-in-time privilegieforøgelse og godkendelsesarbejdsgange.

Det er vigtigt, fordi mange alvorlige hændelser ikke begynder med den formelle break-glass-konto. De begynder med stående privilegier. En cloudingeniør beholder ejerrettigheder “for en sikkerheds skyld”. En databaseadministrator beholder produktionsadgang efter skift til et andet team. En CI/CD-servicekonto har brede tilladelser på tværs af miljøer. En managed service provider-konto er undtaget fra MFA, fordi “de har brug for hurtig adgang”.

Step 20 i Zenith Blueprint udvider samme ræsonnement til privilegerede hjælpeprogrammer. Den instruerer organisationer i at oprette eller opdatere en fortegnelse over privilegerede hjælpeprogrammer, begrænse udførelse til autoriserede administratorer, verificere, at brug logges og udløser alarmer, samt overveje scriptlogning, f.eks. PowerShell-logning via gruppepolitik. Dette er kritisk, fordi en privilegeret konto ofte kun er indgangspunktet. Skaden opstår, når angriberen kører værktøjer, der deaktiverer kontroller, dumper legitimationsoplysninger eller bevæger sig lateralt.

Step 22 formaliserer livscyklussen for adgangsstyring. Den kræver struktureret tildeling af adgang og deprovisionering, ideelt integreret med HR og understøttet af arbejdsgange for adgangsanmodninger, med kvartalsvise dokumenterede gennemgange af adgangsrettigheder. Step 16 kobler livscyklussen til fratrædelsesprocessen ved at kræve en fratrædelsestjekliste for medarbejdere, som HR og IT anvender i fællesskab, herunder deaktivering af konti, tilbagelevering af aktiver og påmindelser om fortrolighedsaftale.

Zenith Blueprint gør PAM til en sammenhængende driftsmodel: identitet, HR, privilegerede hjælpeprogrammer, logning, hændelseshåndtering, gennemgang af adgangsrettigheder og revisionsbevismateriale forstærker hinanden.

En praktisk styringsmodel for break-glass i 2026

En veldesignet break-glass-proces skal fungere under fejl. Hvis den afhænger af den samme identitetsudbyder, sagsstyringsplatform og chattjeneste, som er utilgængelige under nedbruddet, er den kun teater.

Samtidig må nødadgang ikke blive en bekvemmelig omgåelseskanal. Clarysec designer typisk break-glass-styring omkring fire lag: forebyggelse, aktivering, observation og genopretning.

For cloudmiljøer skal tenant-administratorer, cloud-rootkonti, nødadministratorer hos identitetsudbyderen, privilegerede servicekonti, database-masterbrugere, Kubernetes cluster-admin-roller, CI/CD-udrulningsnøgler, administratorer af secrets vaults og tredjeparts supportkonti omfattes.

For hybridmiljøer skal domæneadministratorer, backupadministratorer, hypervisoradministratorer, firewalladministratorer, administratorer af EDR-konsoller og brugere af privilegerede hjælpeprogrammer omfattes.

For privatlivsfølsomme miljøer skal administratorer omfattes, hvis de kan tilgå databaser med personoplysninger, logfiler med identifikatorer, HR-registre, biometriske identitetsverifikationsdata, systemer til svigovervågning eller kundesupportværktøjer.

Måltilstanden er enkel at beskrive og vanskelig at forfalske: Hver nødadgangsvej er kendt, godkendt, sikret, observerbar, reversibel og gennemgået.

En 60-minutters break-glass-øvelse med bevismateriale

En CISO eller complianceansvarlig kan gennemføre en nyttig break-glass-øvelse i denne uge uden at købe et nyt værktøj. Formålet er ikke kun at bekræfte, at kontoen virker. Formålet er at dokumentere, at kontrollen producerer bevismateriale.

Scenarie

Antag, at den primære identitetsudbyder er forringet. Normal just-in-time privilegieforøgelse er utilgængelig. En produktionsdatabaseklynge kræver nødændringer i konfigurationen for at genetablere tjenesten. Break-glass-cloudadministratorkontoen skal aktiveres.

Step 1: Bekræft, at kontoen indgår i fortegnelsen over privilegerede konti

Brug Zenith Blueprint, Controls in Action-fasen, Step 19, til at validere, at kontoen fremgår af fortegnelsen over privilegerede konti. Registrér kontonavn og miljø, virksomhedsejer, teknisk ejer, systemer der kan nås, påvirkning af personoplysninger, autentifikationsmetode, vault-placering, rotationsmetode og dato for seneste test.

Hvis kontoen mangler, skal det behandles som en kontrolmangel og tilføjes til risikoregisteret.

Step 2: Kontrollér overensstemmelse med politikker

Kortlæg hændelsen til kravene i Politik for styring af brugerkonti og privilegier for dokumenterede break-glass-procedurer og logning af privilegerede sessioner. Hvis I er en SMV, skal Politik for styring af brugerkonti og privilegier - SME klausul 7.3.1 og 7.3.2 anvendes som minimumsbaseline: dokumenteret, sikret, nødvendig, logget, gennemgået og nulstillet.

Kortlæg opbevaring af godkendelser til Politik for adgangskontrol klausul 5.3.2, som kræver, at godkendelsesbeslutninger logges og opbevares i mindst 2 år.

Step 3: Opret en nødadgangsregistrering

Opret en sag eller hændelsesregistrering før eller ved aktivering. Medtag:

• Årsag til nødadgang
• Berørt tjeneste
• Anmodet konto
• Anmoder
• Godkender
• Starttidspunkt
• Forventet sluttidspunkt
• Kunde- eller regulatorisk påvirkning
• GDPR-påvirkning af personoplysninger
• NIS2- eller DORA-observationsflag for rapportering

Vent ikke til afslutningen med at rekonstruere forløbet. Revisionsværdien er stærkest, når registreringen begynder, før adgangen bruges.

Step 4: Aktivér og observér

Aktivér break-glass-kontoen. Bekræft, at MFA eller kompenserende autentifikation anvendes, at sessionen registreres, at kommandoer eller administrative handlinger logges, at logfiler videresendes til centraliseret logning, at synkronisering af systemtid understøtter rekonstruktion af tidslinjen, og at der genereres en alarm for brug af nødkontoen.

Dette stemmer overens med Zenith Controls for 8.15 Logning, som beskriver logning som det grundlæggende datalag for overvågning og bemærker, at privilegerede brugere og udførelse af privilegerede hjælpeprogrammer skal logges omfattende.

Step 5: Luk, nulstil og gennemgå

Efter nødopgaven skal kontoen deaktiveres eller føres tilbage til forseglet status, legitimationsoplysninger roteres eller autentifikationsfaktoren nulstilles, sessionslogfiler gennemgås, kommandoer og konfigurationsændringer dokumenteres, det bekræftes, at der ikke er sket unødvendig dataadgang, hændelsesregistreringen opdateres, læringspunkter registreres, og det afgøres, om tærskler for NIS2-, DORA- eller GDPR-underretning er udløst.

Hvis personoplysninger blev tilgået, skal DPO’en involveres. Hvis hændelsen medførte driftsafbrydelse eller kunne medføre væsentlig påvirkning, skal den NIS2- eller DORA-rapporteringsansvarlige involveres. Hvis break-glass-kontoen fejlede, skal det dokumenteres som en konstatering vedrørende operationel robusthed, ikke blot som et IAM-forhold.

Tværgående compliance-kortlægning for PAM- og break-glass-kontroller

Den stærkeste styringsmodel duplikerer ikke kontroller for hver regulering. Den opbygger én beviskæde, der understøtter flere forpligtelser.

NIST CSF 2.0 er særligt nyttig, når PAM omsættes til en Current Profile og Target Profile. Profilmetoden begynder med omfang, indsamler derefter politikker, risikoprioriteter, registre, krav, praksisser og arbejdsroller, før der udarbejdes en prioriteret handlingsplan. For privilegeret adgang betyder det at afgrænse profilen omkring identitetssikkerhed, cloudadministration, ransomware-robusthed, kritiske finansielle systemer eller leverandøradgang.

For finansielle enheder omfattet af DORA fungerer DORA som EU’s sektorspecifikke cyberrobusthedsregime for tilsvarende NIS2-risiko- og hændelsesforpligtelser. Det gør ikke NIS2 irrelevant. Det betyder, at den finansielle enhed bør anvende DORA som det styrende regime for IKT-risiko- og hændelseskrav, samtidig med at der koordineres med nationale cybersikkerhedsstrategier, kompetente myndigheder og CSIRT’er, hvor det er relevant.

Hvordan revisorer tester bevismateriale for privilegeret adgang

Revisorer vurderer ikke PAM alene ved at læse politikker. De triangulerer politik, konfiguration, logfiler, sager, interviews og observeret praksis.

Zenith Controls-revisionsmetodikken for privilegerede adgangsrettigheder henviser til ISO/IEC 19011:2018-revisionspraksis. Revisorer gennemgår politikker, der definerer forhøjede rettigheder, tildeling af adgang, overvågning og procedurer for tilbagekaldelse. De undersøger fortegnelser over brugerkonti, registreringer af privilegietildelinger og logfiler. De bekræfter bevismateriale gennem interviews, PAM-værktøjer, katalogtjenester og logeksempler.

For adgangsrettigheder bemærker Zenith Controls, at revisorer udtager stikprøver af brugeradgangsanmodninger, verificerer dokumenterede godkendelser og bekræfter, at IT kun har tildelt godkendt adgang. De sammenligner også brugerroller med faktiske rettigheder og kontrollerer, om mindst mulige rettigheder håndhæves. For logning inspicerer revisorer logningsomfang, hændelsestyper, opbevaringsperioder, beskyttelsesforanstaltninger og faktiske logposter. De vurderer, om mislykkede login, adgang til følsomme data og konfigurationsændringer registreres og gennemgås.

En god break-glass-bevispakke omfatter:

• Godkendt nødadgangsanmodning
• Hændelses- eller nedbrudskontekst
• Identitet på brugeren, der aktiverer adgang
• Godkenders identitet
• Start- og sluttidspunkt
• MFA- eller autentifikationsbevismateriale
• Sessionsregistrering eller kommandolog
• Systemlogfiler og SIEM-alarm
• Foretagne ændringer
• Bekræftelse på nulstilling af legitimationsoplysninger
• Gennemgang efter brug
• Vurdering af dataadgang
• Vurdering af regulatorisk underretning
• Korrigerende handlinger, hvis noget fejlede

Hvis jeres øvelse ikke kan producere denne pakke, er kontrollen ikke revisionsklar.

Den skjulte svigt: privilegeret tredjepartsadgang

Mange organisationer styrer medarbejderadministratorer bedre end leverandøradministratorer. For cloud-, SaaS-, fintech- og managed service-miljøer er det omvendt af, hvad der er nødvendigt.

NIS2 Article 21 omfatter sikkerhed i forsyningskæden og relationer med direkte leverandører og tjenesteudbydere. DORA Articles 28 til 30 går videre for finansielle enheder og kræver strategi for IKT-tredjepartsrisiko, registre over IKT-servicekontrakter, rettidig omhu, vurdering af koncentrationsrisiko, revisionsrettigheder, opsigelsesrettigheder, exitstrategier og kontraktlige sikkerhedsforanstaltninger.

Privilegeret leverandøradgang skal være omfattet af PAM, hvis leverandøren kan administrere produktion, understøtte kritiske eller vigtige funktioner, tilgå personoplysninger, ændre sikkerhedskonfigurationer, administrere sikkerhedskopier, udrulle kode eller betjene overvågningsværktøjer.

Clarysec forventer typisk, at kontroller for privilegeret leverandøradgang omfatter:

• Navngivne leverandørbrugere, ikke delte leverandørkonti
• Kontraktlige sikkerhedskrav til privilegeret adgang
• MFA og sikker fjernadgang
• Tidsbegrænsede adgangsvinduer
• Kundegodkendelse af nødadgang
• Sessionslogning eller tilsvarende revisionsspor
• Øjeblikkelig tilbagekaldelse, når personale ændres
• Forpligtelser til samarbejde ved hændelser
• Opbevaring af bevismateriale tilpasset kundens revisionsbehov
• Exitplan for fjernelse af leverandøradgang

NIST CSF 2.0-resultater for forsyningskæden passer stærkt hertil. De kræver leverandørers roller og ansvar, prioritering af leverandører efter kritikalitet, krav i kontrakter, rettidig omhu, løbende overvågning, leverandørinddragelse i hændelsesplanlægning og risikoplaner efter kontraktophør.

Hvis en managed service provider-konto er undtaget fra jeres interne PAM-arbejdsgang, er det ikke en bekvemmelighed. Det er en højrisikoundtagelse, der hører hjemme i risikoregisteret, leverandørregisteret og adgangsgennemgangen.

Almindelige PAM- og break-glass-konstateringer i 2026

På tværs af Clarysec-engagementer er konstateringerne sjældent overraskende. De er som regel kombinationer af gode intentioner, driftspres og ufuldstændigt bevismateriale.

De mest almindelige konstateringer er:

• Break-glass-konti findes, men er ikke opført i fortegnelsen over privilegerede konti.
• Nødkonti er undtaget fra normale gennemgange af adgangsrettigheder.
• Organisationen kan ikke dokumentere, hvem der brugte en nødkonto.
• Kontoen blev ikke nulstillet efter brug.
• Privilegerede sessioner logges, men kommandoer gør ikke.
• Logfiler findes lokalt, men er ikke beskyttet mod privilegerede brugere.
• Cloud-rootkonti testes ikke.
• MFA-genopretningsprocesser er udokumenterede.
• Privilegeret adgang for CI/CD-pipelines og servicekonti ignoreres.
• Tredjeparts supportadgang omgår intern godkendelse.
• Adgangsgodkendelse findes i chatbeskeder, men opbevares ikke som revisionsbevismateriale.
• Fratrædelsesprocessen fjerner e-mail og VPN, men ikke SaaS-administratorrettigheder.
• DPO’en involveres ikke, når privilegeret adgang kan eksponere personoplysninger.
• Hændelsesplaybooks omfatter ikke beslutningspunkter for NIS2-, DORA- eller GDPR-underretning.

Hver konstatering kan håndteres gennem ISO/IEC 27001:2022-risikobehandling. Identificér risikoen, tildel en ejer, vælg kontroller, opdatér anvendelseserklæringen, implementér behandlingsplanen og opbevar dokumenteret bevismateriale. Det er styrken ved at bruge et ISMS i stedet for et spredt sæt sikkerhedsopgaver.

Sådan ser god praksis ud

En moden PAM- og break-glass-driftsmodel har fem tilbagevendende rutiner.

For det første skal privilegeret adgang registreres månedligt eller kontinuerligt. Medtag menneskelige administratorer, servicekonti, nødkonti, cloudroller, CI/CD-identiteter, databasebrugere, privilegerede hjælpeprogrammer og tredjepartsadministratorer.

For det andet skal mindst privilegieprincip håndhæves gennem roller, just-in-time privilegieforøgelse og godkendelser. Stående privilegier bør være sjældne, begrundede og gennemgås hyppigere end standardbrugeradgang.

For det tredje skal privilegeret adfærd overvåges. Log autentifikation, sessionsvarighed, MFA-brug, kommandoer, konfigurationsændringer, dataeksporter, mislykkede forsøg, eskalering af rettigheder og udførelse af privilegerede hjælpeprogrammer.

For det fjerde skal break-glass-konti testes før nødsituationen. En break-glass-konto, der aldrig er testet, er en antagelse, ikke en kontrol.

For det femte skal der rapporteres til ledelsen. NIS2 og DORA løfter begge cybersikkerhed og IKT-risiko til ledelsesorganets ansvar. Bestyrelsen har ikke brug for hver kommandolog, men den har brug for målinger: antal privilegerede konti, forsinkede gennemgange, nødaktiveringer, leverandøradministratorkonti, fejlede tests, kritiske undtagelser og afhjælpningsstatus.

Det er her, Clarysecs værktøjssæt bliver praktisk. Politikbiblioteket leverer styringssproget. Zenith Blueprint leverer implementeringsrækkefølgen. Zenith Controls leverer tværgående compliance-kortlægning, kontrolrelationer, understøttende standarder og revisionsmetodik.

Næste skridt: gør nødadgang til revisionsklar robusthed

Hvis jeres organisation ikke har testet break-glass-adgang inden for de seneste 90 dage, skal I starte dér. Begynd ikke med en workshop om valg af værktøj. Begynd med bevismateriale.

1. Opbyg eller opdatér fortegnelsen over privilegerede konti.
2. Identificér hver break-glass-konto og hver nødadministratorvej.
3. Kortlæg hver konto til virksomhedsejer, systemejer og datapåvirkning.
4. Bekræft politikdækning med Clarysecs Politik for styring af brugerkonti og privilegier Politik for styring af brugerkonti og privilegier eller Politik for styring af brugerkonti og privilegier - SME Politik for styring af brugerkonti og privilegier - SME.
5. Brug Zenith Blueprint Zenith Blueprint Controls in Action-fasen, Steps 19, 20, 22 og 16, til at forbinde privilegeret adgang, privilegerede hjælpeprogrammer, livscyklusgennemgange og fratrædelsesproces.
6. Brug Zenith Controls Zenith Controls til at kortlægge ISO/IEC 27002:2022-kontrollerne 8.2, 5.18 og 8.15 til forventninger om bevismateriale under NIS2, DORA, GDPR og NIST.
7. Gennemfør en break-glass-øvelse med bevismateriale, og registrér resultaterne.
8. Tilføj mangler til risikobehandlingsplanen, og følg afhjælpning frem til lukning.

Privilegeret adgang er magt. Break-glass-adgang er nødmagt. I 2026 vil de organisationer, der kommer rent igennem ransomware, cloudnedbrud og identitetsfejl, være dem, der kan dokumentere, at nødadgangen var kontrolleret før, under og efter krisen.

Clarysec kan hjælpe jer med at opbygge den dokumentation, fra politik til kontrolkortlægning og revisionsklart bevismateriale. Start med Zenith Blueprint, kombiner den med Politik for styring af brugerkonti og privilegier og Politik for adgangskontrol, og brug derefter Zenith Controls til at vise, hvordan jeres PAM-program understøtter ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 og COBIT 2019.