PAM en break-glass-accounts voor ISO 27001 in 2026

Om 02:14 op een zondagochtend ontvangt de incident commander het bericht waar iedere CISO voor vreest: “Productie-authenticatie faalt. De beheerconsole is onbereikbaar. Databasefailover zit vast.”

De dienstdoende cloud engineer kan het probleem zien, maar niet oplossen. Zijn reguliere geprivilegieerde rol is afhankelijk van dezelfde identiteitsprovider die nu gedegradeerd is. De operationeel verantwoordelijke vraagt om de noodcredential voor de beheerder. De compliance manager vraagt of het break-glass-account ooit is getest. De DPO vraagt of toegang tot de productiedatabase persoonsgegevens kan blootstellen. De CISO stelt de vraag die bepaalt of dit beheerst herstel wordt of een auditnachtmerrie:

“Kunnen wij aantonen wie noodtoegang heeft gebruikt, waarom, wat die persoon heeft gedaan en dat het account daarna is gereset?”

Een andere organisatie kan hetzelfde probleem in een stillere ruimte ervaren. Een FinTech-CISO zit tegenover externe auditors na een verkeerde configuratie van een clouddatabase. Het incident werd snel opgelost, maar de oorzaakanalyse was niet geruststellend. Een externe ontwikkelaar had permanente beheerdersrechten. Toen de primaire beheerder niet beschikbaar was, gebruikte de ontwikkelaar een break-glass-account op basis van een gedeeld wachtwoord dat was opgeslagen in een “veilige” notitie die beschikbaar was voor het DevOps-team.

De auditors keken niet alleen naar de verkeerde configuratie. Zij vroegen of de toegang tijdgebonden was, of individuele verantwoordingsplicht bestond, of commando’s werden gelogd, of persoonsgegevens waren beschermd onder GDPR Article 32, of aan de ICT-risicoverplichtingen onder DORA was voldaan en of de cyberhygiëneverwachtingen van NIS2 aantoonbaar waren.

Dat is in 2026 het reële drukpunt van privileged access management en break-glass-accounts. PAM is geen nicheproject voor identiteitsbeveiliging meer. Het is het punt waar ransomware, cloudcompromittering, leveranciersrisico, gegevensbescherming, operationele weerbaarheid en auditbewijs samenkomen.

Geprivilegieerde toegang is waar aanvallers proberen te winnen. Break-glass-toegang is waar verdedigers proberen te herstellen. Beide steunen op dezelfde gevaarlijke mogelijkheid: verhoogde privileges waarmee beheersmaatregelen kunnen worden omzeild, configuraties kunnen worden gewijzigd, gevoelige gegevens kunnen worden gelezen, sleutels kunnen worden geroteerd, logging kan worden uitgeschakeld, back-ups kunnen worden hersteld, code kan worden uitgerold of bewijs kan worden vernietigd.

Het praktische standpunt van Clarysec is eenvoudig: noodtoegang is noodzakelijk, maar onbeheerde noodtoegang is onbeheerd risico. Het juiste antwoord is niet “geen break-glass-accounts”. Het juiste antwoord is een governancemodel voor privileged access management met inventarisatie, goedkeuring, tijdsbeperking, sterke authenticatie, sessielogging, beoordeling na gebruik, reset van credentials en auditbewijs.

Waarom geprivilegieerde toegang een compliancevraagstuk op bestuursniveau is

In omgevingen met een lagere volwassenheid wordt geprivilegieerde toegang vaak behandeld als een IT-beheertaak. Iemand heeft beheerdersrechten nodig, er wordt een ticket geopend, een rol wordt toegekend en de organisatie gaat door. Dat model houdt geen stand tegen moderne ransomware, cloud-native infrastructuur, NIS2-verantwoordingsplicht, operationele weerbaarheid onder DORA of toetsing bij datalekken onder GDPR.

De NIS2 Directive brengt cybersecuritygovernance naar de bestuurskamer. Article 20 vereist dat bestuursorganen van essentiële en belangrijke entiteiten cyberbeveiligingsrisicobeheersmaatregelen goedkeuren, toezicht houden op de implementatie en cyberbeveiligingstraining volgen. Article 21 vereist passende en evenredige technische, operationele en organisatorische maatregelen, waaronder risicoanalyse, incidentafhandeling, bedrijfscontinuïteit, beveiliging van de toeleveringsketen, doeltreffendheid van beheersmaatregelen, cyberhygiëne, HR-beveiliging, toegangscontrole, beleid voor assetmanagement en MFA of continue authenticatie waar passend.

Voor SaaS-aanbieders, managed service providers, managed security providers, clouddiensten, datacenters en andere organisaties voor digitale infrastructuur hangt de toepasselijkheid van NIS2 af van sector, omvang, rol, grensoverschrijdende impact en vestiging in de EU. De operationele les is direct: toegangscontrole is niet langer verborgen in een technische bijlage. Het is onderdeel van de baseline voor cyberhygiëne die het management moet goedkeuren, bewaken en corrigeren.

Voor financiële entiteiten verandert de Digital Operational Resilience Act de terminologie, maar niet het onderliggende risico. DORA is van toepassing vanaf 17 januari 2025 en stelt een uniform kader vast voor ICT-risicobeheer, rapportage van majeure ICT-gerelateerde incidenten, testen van digitale operationele weerbaarheid en ICT-risicobeheer van derde partijen. Article 5 vereist governance- en beheersregelingen voor ICT-risico, waarbij het bestuursorgaan ICT-risicoregelingen definieert, goedkeurt, overziet en daarvoor verantwoordelijk is. Article 6 vereist een gedocumenteerd ICT-risicobeheerkader met beleid, procedures, protocollen en tools om ICT-activa te beschermen. Article 17 vereist een proces voor ICT-gerelateerd incidentbeheer dat beveiligde operaties detecteert, registreert, classificeert, escaleert en herstelt.

GDPR voegt het privacy- en verantwoordingsperspectief toe. Article 5(1)(f) vereist dat persoonsgegevens met integriteit en vertrouwelijkheid worden verwerkt. Article 5(2) vereist verantwoordingsplicht. Article 25 vereist data protection by design en by default. Article 32 vereist passende technische en organisatorische maatregelen voor beveiliging van de verwerking. Als een geprivilegieerde gebruiker klantregistraties kan exporteren, toegang heeft tot bijzondere categorieën persoonsgegevens, auditlogs kan uitschakelen of bewaartermijnen kan wijzigen zonder beoordeling, heeft de organisatie niet slechts een IAM-fout gemaakt. Zij kan mogelijk geen passende beveiliging aantonen.

ISO/IEC 27001:2022 is de ruggengraat van het managementsysteem waarmee deze verplichtingen via één geïntegreerd programma kunnen worden behandeld. Clause 4.2 vereist dat de organisatie belanghebbenden en hun eisen begrijpt, waaronder wettelijke, regelgevende en contractuele eisen. Clause 5.1 vereist leiderschap en betrokkenheid. Clause 6.1.2 vereist informatiebeveiligingsrisicobeoordeling. Clause 6.1.3 vereist risicobehandeling. Clause 8 vereist operationele planning en beheersing.

Voor geprivilegieerde toegang verschuift dit het gesprek van “welke PAM-tool moeten we kopen?” naar “welke risico’s behandelen we, welke beheersmaatregelen zijn geselecteerd, wie is eigenaar, hoe worden ze uitgevoerd en welk bewijs toont aan dat ze werken?”

PAM is niet één beheersmaatregel, maar een keten van bewijs

Een PAM-tool kan wachtwoorden in een kluis beheren, sessies bemiddelen, toetsaanslagen opnemen, credentials roteren en just-in-time-toegang afdwingen. Die mogelijkheden zijn belangrijk. Maar als de organisatie geen geprivilegieerde rollen heeft gedefinieerd, noodtoegang niet heeft goedgekeurd, toegang niet aan bedrijfsmiddelen heeft gekoppeld, rechten niet heeft beoordeeld, logboeken niet heeft beschermd en beheerders niet heeft getraind, wordt de tool een gedeeltelijke beheersmaatregel met zwakke verdedigbaarheid in audits.

De meest bruikbare manier om geprivilegieerde toegang te besturen is denken in beoogde resultaten van beheersmaatregelen, niet in toolnamen.

De Zenith Controls: The Cross-Compliance Guide Zenith Controls behandelt ISO/IEC 27002:2022-beheersmaatregel 8.2, Privileged access rights, als het zwaartepunt voor PAM. Deze beheersmaatregel wordt geclassificeerd als preventief, ter ondersteuning van vertrouwelijkheid, integriteit en beschikbaarheid, afgestemd op het cybersecurityconcept Protect, de operationele capability identiteits- en toegangsbeheer en het beveiligingsdomein Protection.

Beheersmaatregel 8.2 is krachtig omdat deze aansluit op de omliggende beheersmaatregelen die geprivilegieerde toegang auditbaar maken:

Daarom stopt een auditor zelden bij de vraag: “Heeft u een PAM-systeem?” Sterkere auditvragen zijn: Heeft u een inventaris van geprivilegieerde accounts? Zijn geprivilegieerde rollen goedgekeurd? Zijn rechten tijdgebonden? Zijn noodcredentials beveiligd? Kunt u aantonen wie ze heeft gebruikt? Worden commando’s gelogd? Zijn leveranciersbeheerders opgenomen? Worden toegangsrechten beoordeeld? Zijn credentials gereset? Zijn uitzonderingen op basis van risico geaccepteerd?

De mapping van toegangsrechten in Zenith Controls maakt dit punt rechtstreeks: beheer van toegangsrechten operationaliseert toegangscontroleprincipes zoals het principe van minimale privileges, het need-to-know-principe en autorisatie, terwijl geprivilegieerde accounts bijzondere aandacht en snelle intrekking vereisen wanneer zij niet langer nodig zijn.

Beleidsvereisten voor betrouwbare break-glass-toegang

Een break-glass-account is geen gedeeld beheerderswachtwoord in een verzegelde envelop. In 2026 is dat model te zwak voor cloud, fintech, SaaS, gezondheidszorg, managed services en gereguleerde digitale operaties.

Een verdedigbaar break-glass-model heeft zeven minimale beleidsregels nodig:

1. Het account moet worden gedocumenteerd.
2. Het account moet worden goedgekeurd.
3. Gebruik moet waar technisch mogelijk uniek herleidbaar zijn.
4. Gebruik moet beperkt blijven tot echte noodsituaties.
5. Gebruik moet worden gelogd en beoordeeld.
6. Credentials of authenticatiefactoren moeten na gebruik worden gereset of geroteerd.
7. Het account moet worden getest en binnen de auditscope vallen.

De beleidsbibliotheek van Clarysec zet deze principes om in bruikbare governancetaal.

Het User Account and Privilege Management Policy-sme User Account and Privilege Management Policy - SME bepaalt:

“Noodtoegang (bijv. ‘break-glass’-beheerdersaccounts) moet duidelijk worden gedocumenteerd, beveiligd en uitsluitend worden gebruikt wanneer dit absoluut noodzakelijk is.”

Uit de sectie “Risicobehandeling en uitzonderingen”, beleidsclausule 7.3.1.

Hetzelfde SME-beleid vervolgt:

“Dergelijke accounts moeten worden gelogd, na gebruik worden beoordeeld en na elke noodsituatie worden gereset.”

Uit de sectie “Risicobehandeling en uitzonderingen”, beleidsclausule 7.3.2.

Voor dagelijkse privilegeverhoging vereist het SME-beleid ook:

“Verhoogde of administratieve privileges vereisen aanvullende goedkeuring door de algemeen directeur of IT-verantwoordelijke en moeten worden gedocumenteerd, tijdgebonden zijn en periodiek worden beoordeeld.”

Uit de sectie “Vereisten voor beleidsimplementatie”, beleidsclausule 6.2.2.

Voor grotere organisaties gaat de enterprise-beleidsset verder. Het User Account and Privilege Management Policy User Account and Privilege Management Policy vereist dat:

“Geprivilegieerde sessies volledig moeten worden gelogd, inclusief uitgevoerde commando’s en verrichte handelingen. Logboeken moeten periodiek worden beoordeeld door aangewezen beoordelaars.”

Uit de sectie “Vereisten voor beleidsimplementatie”, beleidsclausule 6.4.2.

Hetzelfde beleid vereist in clausule 6.2.5 dat tijdelijke of noodaccounts voor geprivilegieerde toegang een gedocumenteerde break-glass-procedure volgen, terwijl clausule 7.4 de vereisten voor die procedure uiteenzet.

Het Access Control Policy Access Control Policy versterkt auditbewaring:

“Goedkeuringsbesluiten moeten worden gelogd en voor auditdoeleinden minimaal 2 jaar worden bewaard.”

Uit de sectie “Governancevereisten”, beleidsclausule 5.3.2.

Het Logging and Monitoring Policy-sme Logging and Monitoring Policy - SME benoemt verwachtingen voor authenticatielogging:

“Authenticatielogboeken: geslaagde en mislukte aanmeldpogingen, sessieduur, MFA-gebruik”

Uit de sectie “Governancevereisten”, beleidsclausule 5.4.2.

Samen maken deze clausules van noodtoegang geen heroïsche workaround, maar een beheerst event. Het account is uitzonderlijk, maar de governance niet.

De Zenith Blueprint-aanpak voor implementatie van PAM

De Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint behandelt geprivilegieerde toegang als een praktisch implementatievraagstuk, niet als een theoretische controlestelling. In de fase Controls in Action, stap 19, Technological Controls I, staat:

“In elk informatiesysteem is geprivilegieerde toegang macht, en met die macht komt risico.”

Uit de fase Controls in Action, stap 19: Technological Controls I.

Stap 19 vereist dat organisaties geprivilegieerde accounts identificeren in on-premises-, cloud-, SaaS-, ontwikkel- en infrastructuuromgevingen. Dit omvat domeinbeheerders, root-gebruikers, cloudtenantbeheerders, database-superusers en beheerders van CI/CD-pijplijnen. Ook benadrukt deze stap het minimaliseren van geprivilegieerde toegang via rolgebaseerde toegangscontrole, just-in-time-privilegeverhoging en goedkeuringsworkflows.

Dat is relevant omdat veel ernstige incidenten niet beginnen met het formele break-glass-account. Zij beginnen met permanente privileges. Een cloud engineer behoudt eigenaarsrechten “voor het geval dat”. Een databasebeheerder behoudt productietoegang na een teamwissel. Een CI/CD-serviceaccount heeft brede machtigingen over meerdere omgevingen. Een managed service provider-account is vrijgesteld van MFA omdat “ze snel toegang nodig hebben”.

Stap 20 van de Zenith Blueprint past dezelfde redenering toe op geprivilegieerde utilities. Deze stap draagt organisaties op een inventaris van geprivilegieerde utilities aan te maken of bij te werken, uitvoering te beperken tot geautoriseerde beheerders, te verifiëren dat gebruik wordt gelogd en waarschuwingen genereert, en scriptlogging te overwegen, zoals PowerShell-logging via group policy. Dit is kritiek omdat een geprivilegieerd account vaak slechts het toegangspunt is. De schade ontstaat wanneer de aanvaller tools uitvoert die beheersmaatregelen uitschakelen, credentials dumpen of lateraal bewegen.

Stap 22 formaliseert de toegangscontrolelevenscyclus. Deze stap vraagt om gestructureerde toegangsverlening en deprovisioning, idealiter geïntegreerd met HR en ondersteund door workflows voor toegangsaanvragen, met gedocumenteerde kwartaalbeoordelingen van toegangsrechten. Stap 16 koppelt de levenscyclus aan offboarding door een uitdiensttredingschecklist voor medewerkers te vereisen die HR en IT gezamenlijk gebruiken, inclusief uitschakeling van accounts, teruggave van bedrijfsmiddelen en herinneringen aan geheimhoudingsovereenkomsten.

De Zenith Blueprint maakt van PAM een samenhangend operationeel model: identiteit, HR, geprivilegieerde utilities, logging, incidentrespons, toegangsrechtenbeoordelingen en auditbewijs versterken elkaar.

Een praktisch governancemodel voor break-glass in 2026

Een goed ontworpen break-glass-proces moet werken tijdens falen. Als het afhankelijk is van dezelfde identiteitsprovider, hetzelfde ticketsysteem en dezelfde chatdienst die tijdens de storing niet beschikbaar zijn, is het schijnbeheersing.

Tegelijkertijd mag noodtoegang geen omzeilingskanaal voor gemak worden. Clarysec ontwerpt break-glass-governance doorgaans rond vier lagen: preventie, activering, observatie en herstel.

Neem voor cloudomgevingen tenantbeheerders, cloud-rootaccounts, noodbeheerders van identiteitsproviders, geprivilegieerde serviceaccounts, database-mastergebruikers, Kubernetes-cluster-adminrollen, CI/CD-deploy keys, beheerders van secrets vaults en supportaccounts van derden op.

Neem voor hybride omgevingen domeinbeheerders, back-upbeheerders, hypervisorbeheerders, firewallbeheerders, EDR-consolebeheerders en gebruikers van geprivilegieerde utilities op.

Neem voor privacygevoelige omgevingen beheerders op die toegang kunnen krijgen tot databases met persoonsgegevens, logboeken met identificatoren, HR-registraties, biometrische identiteitsverificatiegegevens, systemen voor fraudemonitoring of klantondersteuningstools.

De doeltoestand is eenvoudig te beschrijven en moeilijk te vervalsen: ieder noodpad is bekend, goedgekeurd, beveiligd, waarneembaar, omkeerbaar en beoordeeld.

Een break-glass-bewijsoefening van 60 minuten

Een CISO of compliance manager kan deze week een nuttige break-glass-oefening uitvoeren zonder een nieuwe tool te kopen. Het doel is niet alleen bevestigen dat het account werkt. Het doel is aantonen dat de beheersmaatregel bewijs oplevert.

Scenario

Ga ervan uit dat de primaire identiteitsprovider gedegradeerd is. Reguliere just-in-time-privilegeverhoging is niet beschikbaar. Een productiedatabasecluster heeft noodwijzigingen in de configuratie nodig om de dienstverlening te herstellen. Het break-glass-cloudbeheerdersaccount moet worden geactiveerd.

Stap 1: Bevestig dat het account in de inventaris van geprivilegieerde accounts staat

Gebruik de Zenith Blueprint, fase Controls in Action, stap 19, om te valideren dat het account voorkomt in de inventaris van geprivilegieerde accounts. Registreer de accountnaam en omgeving, bedrijfseigenaar, technische eigenaar, bereikbare systemen, impact op persoonsgegevens, authenticatiemethode, kluislocatie, rotatiemethode en datum van de laatste test.

Als het account ontbreekt, behandel dit dan als een beheersingshiaat en voeg het toe aan het risicoregister.

Stap 2: Controleer beleidsafstemming

Map het event op de vereisten van het User Account and Privilege Management Policy voor gedocumenteerde break-glass-procedures en logging van geprivilegieerde sessies. Als u een mkb-organisatie bent, gebruik dan clausules 7.3.1 en 7.3.2 van het User Account and Privilege Management Policy-sme als minimale baseline: gedocumenteerd, beveiligd, noodzakelijk, gelogd, beoordeeld en gereset.

Map de bewaring van goedkeuringen op clausule 5.3.2 van het Access Control Policy, die vereist dat goedkeuringsbesluiten minimaal 2 jaar worden gelogd en bewaard.

Stap 3: Open een registratie voor noodtoegang

Maak vóór of op het moment van activering een ticket of incidentregistratie aan. Neem op:

• Reden voor de noodsituatie
• Getroffen dienst
• Aangevraagd account
• Aanvrager
• Goedkeurder
• Starttijd
• Verwachte eindtijd
• Klant- of regelgevingsimpact
• GDPR-impact op persoonsgegevens
• Waarschuwingsmarkering voor NIS2- of DORA-rapportage

Wacht niet tot het einde om het verhaal te reconstrueren. De auditwaarde is het sterkst wanneer de registratie begint voordat de toegang wordt gebruikt.

Stap 4: Activeer en observeer

Activeer het break-glass-account. Bevestig dat MFA of compenserende authenticatie wordt gebruikt, de sessie wordt opgenomen, commando’s of administratieve handelingen worden gelogd, logboeken worden doorgestuurd naar centrale logging, tijdsynchronisatie reconstructie van de tijdlijn ondersteunt en een waarschuwing wordt gegenereerd voor gebruik van het noodaccount.

Dit sluit aan bij Zenith Controls voor 8.15 Logging, waarin logging wordt beschreven als de fundamentele datalaag voor monitoring en waarin wordt opgemerkt dat geprivilegieerde gebruikers en uitvoering van geprivilegieerde utilities uitgebreid moeten worden gelogd.

Stap 5: Sluit af, reset en beoordeel

Schakel na de noodtaak het account uit of breng het terug naar de verzegelde status, roteer credentials of reset de authenticatiefactor, beoordeel sessielogboeken, documenteer commando’s en configuratiewijzigingen, bevestig dat geen onnodige gegevenstoegang heeft plaatsgevonden, werk de incidentregistratie bij, leg geleerde lessen vast en bepaal of meldingsdrempels onder NIS2, DORA of GDPR zijn geactiveerd.

Als persoonsgegevens zijn ingezien, betrek de DPO. Als het event dienstverlening heeft verstoord of materiële impact kan veroorzaken, betrek de rapportage-eigenaar voor NIS2 of DORA. Als het break-glass-account faalde, documenteer dit dan als een bevinding inzake operationele weerbaarheid, niet slechts als een IAM-kwestie.

Cross-compliance-mapping voor PAM- en break-glass-beheersmaatregelen

Het sterkste governancemodel dupliceert geen beheersmaatregelen voor elke regeling. Het bouwt één bewijsketen die meerdere verplichtingen ondersteunt.

NIST CSF 2.0 is bijzonder nuttig wanneer PAM wordt vertaald naar een Current Profile en Target Profile. De profielmethode begint met de reikwijdte, verzamelt vervolgens beleid, risicoprioriteiten, registers, vereisten, praktijken en werkrollen, en creëert daarna een geprioriteerd actieplan. Voor geprivilegieerde toegang betekent dit dat het profiel wordt afgebakend rond identiteitsbeveiliging, cloudbeheer, ransomwareweerbaarheid, kritieke financiële systemen of leverancierstoegang.

Voor financiële entiteiten die onder DORA vallen, fungeert DORA als het sectorspecifieke EU-regime voor cyberweerbaarheid voor gelijkwaardige NIS2-risico- en incidentverplichtingen. Dat maakt NIS2 niet irrelevant. Het betekent dat de financiële entiteit DORA moet gebruiken als leidend regime voor ICT-risico- en incidentvereisten, met behoud van coördinatie met nationale cyberbeveiligingsstrategieën, bevoegde autoriteiten en CSIRT’s waar van toepassing.

Hoe auditors bewijs voor geprivilegieerde toegang testen

Auditors beoordelen PAM niet alleen door beleid te lezen. Zij trianguleren beleid, configuratie, logboeken, tickets, interviews en waargenomen praktijk.

De auditmethodologie van Zenith Controls voor geprivilegieerde toegangsrechten verwijst naar auditpraktijken uit ISO/IEC 19011:2018. Auditors beoordelen beleid dat verhoogde rechten, toegangsverlening, monitoring en intrekkingsprocedures definieert. Zij onderzoeken inventarissen van gebruikersaccounts, registraties van privilegetoewijzingen en logboeken. Zij onderbouwen bewijs via interviews, PAM-tools, directoryservices en logvoorbeelden.

Voor toegangsrechten merkt Zenith Controls op dat auditors gebruikersaanvragen voor toegang steekproefsgewijs beoordelen, gedocumenteerde goedkeuringen verifiëren en bevestigen dat IT alleen goedgekeurde toegang heeft toegekend. Zij vergelijken ook gebruikersrollen met feitelijke rechten en controleren of het principe van minimale privileges wordt afgedwongen. Voor logging inspecteren auditors het loggingbereik, eventtypen, bewaartermijnen, beveiligingen en daadwerkelijke logboekitems. Zij beoordelen of mislukte aanmeldingen, toegang tot gevoelige gegevens en configuratiewijzigingen worden vastgelegd en beoordeeld.

Een goed break-glass-bewijspakket omvat:

• Goedgekeurde aanvraag voor noodtoegang
• Incident- of storingscontext
• Identiteit van de gebruiker die toegang activeert
• Identiteit van de goedkeurder
• Start- en eindtijd
• MFA- of authenticatiebewijs
• Sessieopname of commandologboek
• Systeemlogboeken en SIEM-waarschuwing
• Aangebrachte wijzigingen
• Bevestiging van reset van credentials
• Beoordeling na gebruik
• Beoordeling van gegevenstoegang
• Beoordeling van meldingsplicht aan toezichthouders
• Corrigerende maatregelen als iets faalde

Als uw oefening dit pakket niet kan opleveren, is de beheersmaatregel niet auditgereed.

De verborgen tekortkoming: geprivilegieerde toegang door derden

Veel organisaties besturen interne beheerders beter dan leveranciersbeheerders. Voor cloud-, SaaS-, fintech- en managed service-omgevingen is dat precies verkeerd om.

NIS2 Article 21 omvat beveiliging van de toeleveringsketen en relaties met directe leveranciers en dienstverleners. DORA Articles 28 tot en met 30 gaan verder voor financiële entiteiten en vereisen een ICT-risicostrategie voor derde partijen, registers van ICT-dienstverleningscontracten, due diligence, beoordeling van concentratierisico, auditrechten, beëindigingsrechten, exitstrategieën en contractuele beveiligingsmaatregelen.

Geprivilegieerde leverancierstoegang moet binnen de PAM-scope vallen als de leverancier productie kan beheren, kritieke of belangrijke functies kan ondersteunen, toegang heeft tot persoonsgegevens, beveiligingsconfiguraties kan wijzigen, back-ups kan beheren, code kan uitrollen of monitoringtools kan bedienen.

Clarysec verwacht doorgaans dat beheersmaatregelen voor geprivilegieerde leverancierstoegang het volgende omvatten:

• Leveranciersgebruikers op naam, geen gedeelde leveranciersaccounts
• Contractuele beveiligingsvereisten voor geprivilegieerde toegang
• MFA en beveiligde toegang op afstand
• Tijdgebonden toegangsvensters
• Goedkeuring door de klant voor noodtoegang
• Sessieopname of gelijkwaardige audittrails
• Onmiddellijke intrekking wanneer personeel wijzigt
• Verplichtingen voor samenwerking bij incidenten
• Bewaring van bewijs afgestemd op auditbehoeften van de klant
• Exitplan voor het verwijderen van leverancierstoegang

De uitkomsten voor de toeleveringsketen in NIST CSF 2.0 sluiten hier sterk op aan. Zij vragen om rollen en verantwoordelijkheden van leveranciers, prioritering van leveranciers op basis van kritikaliteit, eisen in contracten, due diligence, voortdurende monitoring, betrokkenheid van leveranciers bij incidentplanning en risicoplannen na contractafloop.

Als een managed service provider-account is vrijgesteld van uw interne PAM-workflow, is dat geen gemak. Het is een hoogrisico-uitzondering die thuishoort in het risicoregister, leveranciersregister en de toegangsrechtenbeoordeling.

Veelvoorkomende PAM- en break-glass-bevindingen in 2026

In Clarysec-opdrachten zijn de bevindingen zelden verrassend. Meestal gaat het om combinaties van goede bedoelingen, operationele druk en onvolledig bewijs.

De meest voorkomende bevindingen zijn:

• Break-glass-accounts bestaan, maar staan niet in de inventaris van geprivilegieerde accounts.
• Noodaccounts zijn uitgesloten van reguliere toegangsrechtenbeoordelingen.
• De organisatie kan niet aantonen wie een noodaccount heeft gebruikt.
• Het account is na gebruik niet gereset.
• Geprivilegieerde sessies worden gelogd, maar commando’s niet.
• Logboeken bestaan lokaal, maar zijn niet beschermd tegen geprivilegieerde gebruikers.
• Cloud-rootaccounts worden niet getest.
• MFA-herstelprocessen zijn niet gedocumenteerd.
• Geprivilegieerde toegang voor CI/CD-pijplijnen en serviceaccounts wordt genegeerd.
• Supporttoegang door derden omzeilt interne goedkeuring.
• Toegangsgoedkeuring bestaat in chatberichten, maar wordt niet bewaard als auditbewijs.
• Offboarding verwijdert e-mail en VPN, maar geen SaaS-beheerdersrechten.
• De DPO wordt niet betrokken wanneer geprivilegieerde toegang persoonsgegevens kan blootstellen.
• Incidentdraaiboeken bevatten geen beslispunten voor meldingen onder NIS2, DORA of GDPR.

Elke bevinding kan worden behandeld via ISO/IEC 27001:2022-risicobehandeling. Identificeer het risico, wijs een eigenaar toe, selecteer beheersmaatregelen, werk de Verklaring van Toepasselijkheid bij, implementeer het behandelplan en bewaar gedocumenteerd bewijs. Dat is de kracht van het gebruik van een ISMS in plaats van een losse verzameling beveiligingstaken.

Hoe goed eruitziet

Een volwassen operationeel model voor PAM en break-glass kent vijf terugkerende routines.

Ten eerste: inventariseer geprivilegieerde toegang maandelijks of continu. Neem menselijke beheerders, serviceaccounts, noodaccounts, cloudrollen, CI/CD-identiteiten, databasegebruikers, geprivilegieerde utilities en beheerders van derden op.

Ten tweede: dwing het principe van minimale privileges af via rollen, just-in-time-privilegeverhoging en goedkeuringen. Permanente privileges moeten zeldzaam, gerechtvaardigd en vaker beoordeeld zijn dan standaard gebruikerstoegang.

Ten derde: bewaak geprivilegieerd gedrag. Log authenticatie, sessieduur, MFA-gebruik, commando’s, configuratiewijzigingen, data-exporten, mislukte pogingen, privilege-escalaties en uitvoering van geprivilegieerde utilities.

Ten vierde: test break-glass-accounts vóór de noodsituatie. Een break-glass-account dat nooit is getest, is een aanname, geen beheersmaatregel.

Ten vijfde: rapporteer aan het management. NIS2 en DORA brengen zowel cybersecurity- als ICT-risico onder verantwoordelijkheid van het bestuursorgaan. Het bestuur heeft niet ieder commandologboek nodig, maar wel metrieken: aantal geprivilegieerde accounts, achterstallige beoordelingen, noodactiveringen, leveranciersaccounts met beheerdersrechten, mislukte tests, kritieke uitzonderingen en remediatiestatus.

Hier wordt de toolkit van Clarysec praktisch. De beleidsbibliotheek levert de governancetaal. De Zenith Blueprint levert de implementatievolgorde. Zenith Controls levert de cross-compliance-mapping, controlerelaties, ondersteunende normen en auditmethodologie.

Volgende stappen: maak van noodtoegang auditgereed weerstandsvermogen

Als uw organisatie break-glass-toegang in de afgelopen 90 dagen niet heeft getest, begin daar. Begin niet met een workshop voor toolselectie. Begin met bewijs.

1. Bouw of actualiseer uw inventaris van geprivilegieerde accounts.
2. Identificeer ieder break-glass-account en ieder noodpad voor beheerders.
3. Map elk account op bedrijfseigenaar, systeemeigenaar en gegevensimpact.
4. Bevestig beleidsdekking met Clarysec’s User Account and Privilege Management Policy User Account and Privilege Management Policy of User Account and Privilege Management Policy-sme User Account and Privilege Management Policy - SME.
5. Gebruik de Zenith Blueprint Zenith Blueprint, fase Controls in Action, stappen 19, 20, 22 en 16, om geprivilegieerde toegang, geprivilegieerde utilities, levenscyclusbeoordelingen en offboarding met elkaar te verbinden.
6. Gebruik Zenith Controls Zenith Controls om ISO/IEC 27002:2022-beheersmaatregelen 8.2, 5.18 en 8.15 te mappen op de bewijsverwachtingen van NIS2, DORA, GDPR en NIST.
7. Voer een break-glass-bewijsoefening uit en registreer de resultaten.
8. Voeg hiaten toe aan het risicobehandelingsplan en volg remediatie tot sluiting.

Geprivilegieerde toegang is macht. Break-glass-toegang is noodmacht. In 2026 zullen de organisaties die schoon herstellen van ransomware, cloudstoringen en identiteitsfalen, de organisaties zijn die kunnen aantonen dat noodtoegang vóór, tijdens en na de crisis beheerst was.

Clarysec kan u helpen dat bewijs op te bouwen, van beleid tot control mapping en auditgereed bewijs. Start met de Zenith Blueprint, combineer deze met het User Account and Privilege Management Policy en Access Control Policy, en gebruik vervolgens Zenith Controls om te laten zien hoe uw PAM-programma ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 en COBIT 2019 ondersteunt.