ISO 27001-guide til revisionsbevis for adgangsstyring

Klokken er 09:10 på revisionsdagen. Maria, CISO i en hastigt voksende FinTech- og cloudplatform, har sin politik for adgangsstyring åben. Den it-ansvarlige eksporterer indstillinger for betinget adgang fra identitetsudbyderen. HR leder efter fratrædelsessagen for en finansanalytiker, der stoppede for seks uger siden. Den interne revisor kigger op og stiller det spørgsmål, alle vidste ville komme:
“Vis mig, hvordan adgang anmodes, godkendes, håndhæves, gennemgås og fjernes for en bruger med privilegeret adgang til personoplysninger.”
Den ene sætning kan afsløre, om et program for adgangsstyring er revisionsklart eller blot politikklar.
Marias team havde et modent ledelsessystem for informationssikkerhed (ISMS), en årlig ISO/IEC 27001:2022-recertificeringscyklus, multifaktorautentifikation på plads, rollebaseret adgangsstyring i kernesystemer og kvartalsvise regneark til gennemgang af adgangsrettigheder. Men denne revision var anderledes. Revisorens anmodningsliste omfattede forberedelse på nye regulatoriske krav. For Marias organisation betød det NIS2, DORA og GDPR, alle vurderet gennem samme operationelle linse: identitet, adgang, autentifikation, privilegier og bevismateriale.
Problemet for mange CISO’er er ikke, at adgangsstyring ikke findes. Problemet er, at bevismaterialet findes i fragmenter. Onboarding-godkendelser ligger i Jira eller ServiceNow. MFA-indstillinger ligger i Microsoft Entra ID, Okta eller en anden identitetsudbyder. AWS-, Azure- og Google Cloud-tilladelser ligger i separate konsoller. Privilegerede handlinger kan være logget i et PAM-værktøj — eller slet ikke. HR-status ligger i BambooHR, Workday eller regneark. Gennemgang af adgangsrettigheder kan være godkendt via e-mail.
Når en revisor kobler IAM, MFA, PAM, hændelser for tiltrædelser, omplaceringer og fratrædelser, personoplysninger, cloudadministration og regulatoriske forventninger sammen, falder fragmenteret bevismateriale hurtigt fra hinanden.
ISO/IEC 27001:2022-revisioner af adgangsstyring er ikke kun tekniske konfigurationsgennemgange. De er test af ledelsessystemet. De undersøger, om identitets- og adgangsrisici er forstået, behandlet, implementeret, overvåget og forbedret. Når NIS2, DORA og GDPR også er relevante, skal det samme bevismateriale vise risikobaseret adgangsgovernance, stærk autentifikation, sporbare godkendelser, rettidig tilbagekaldelse, begrænsning af privilegier, beskyttelse af personoplysninger og ledelsesmæssig ansvarlighed.
Det praktiske svar er ikke en større mappe. Det er én bevismodel for adgangsstyring, der starter med ISMS-omfang og risiko, går gennem politik- og kontroldesign, lander i IAM- og PAM-værktøjer og kan kortlægges klart til ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST og COBIT.
Hvorfor adgangsstyring er den centrale regulatoriske kontrol
Adgangsstyring er blevet et emne for bestyrelse og tilsynsmyndigheder, fordi kompromittering af identiteter nu er en almindelig vej til driftsforstyrrelser, brud på persondatasikkerheden, svig og eksponering i forsyningskæden.
Under NIS2 bringer Articles 2 og 3, læst sammen med Annex I og Annex II, mange mellemstore og større enheder i oplistede sektorer ind under anvendelsesområdet som væsentlige eller vigtige enheder. Det omfatter digital infrastruktur og udbydere af IKT-tjenestestyring såsom udbydere af cloud computing-tjenester, datacentertjenester, administrerede tjenester og administrerede sikkerhedstjenester. Medlemsstaterne skulle gennemføre NIS2 senest i oktober 2024 og anvende nationale foranstaltninger fra oktober 2024, med enhedslister forfaldne i april 2025. Article 20 gør ledelsesorganer ansvarlige for at godkende foranstaltninger til styring af cybersikkerhedsrisici og føre tilsyn med implementeringen. Article 21 kræver tekniske, operationelle og organisatoriske foranstaltninger, herunder politikker for adgangsstyring, styring af aktiver, cyberhygiejne, hændelseshåndtering, forretningskontinuitet, sikkerhed i forsyningskæden og MFA eller løbende autentifikation, hvor det er relevant.
DORA tilføjer et sektorspecifikt lag af operationel robusthed for finansielle enheder og relevante IKT-tredjepartsleverandører. Articles 1, 2 og 64 fastlægger DORA som et ensartet rammeværk med anvendelse fra 17. januar 2025. Articles 5 og 6 kræver governance og et dokumenteret rammeværk for styring af IKT-risiko. Article 9 omhandler beskyttelse og forebyggelse, herunder IKT-sikkerhedspolitikker, procedurer, protokoller og værktøjer. Articles 24 til 30 tilføjer test af digital operationel robusthed og styring af IKT-tredjepartsrisiko. For finansielle enheder bliver bevismateriale for adgangsstyring til bevismateriale for robusthed, ikke kun bevismateriale for it-administration.
GDPR tilføjer perspektivet om personoplysninger. Articles 2 og 3 definerer en bred anvendelse for behandling i EU og rækkevidde mod EU-markedet. Article 5 kræver integritet, fortrolighed og dokumenterbar ansvarlighed. Article 25 kræver databeskyttelse gennem design og standardindstillinger. Article 32 kræver passende tekniske og organisatoriske foranstaltninger. I praksis betyder det kontrolleret adgang, sikker autentifikation, logning, gennemgang og rettidig fjernelse for systemer, der behandler personoplysninger.
ISO/IEC 27001:2022 giver organisationer den ledelsessystemmotor, der kan samle disse forpligtelser. Clauses 4.1 til 4.3 kræver, at organisationen forstår kontekst, interessenter, juridiske og kontraktlige krav, grænseflader, afhængigheder og ISMS-omfang. Clauses 6.1.1 til 6.1.3 kræver risikovurdering for informationssikkerhed, risikobehandling, sammenligning med Annex A, en erklæring om anvendelighed og godkendelse af behandlingsplaner og restrisiko. Clause 8.1 kræver operationel styring, dokumenterede oplysninger, der viser, at processer er gennemført som planlagt, ændringsstyring og styring af eksternt leverede processer.
Revisionsspørgsmålet er derfor ikke “Har I MFA?” Det er “Kan I dokumentere, at adgangsrisiko for identiteter og systemer inden for omfanget styres, behandles, implementeres, overvåges og forbedres?”
Opbyg bevismaterialets rygrad fra ISMS-omfang til IAM-dokumentation
Clarysec starter revisionsforberedelse for adgangsstyring med at gøre bevismaterialet sporbart fra forretningskonteksten. ISO/IEC 27001:2022 forventer, at ISMS er integreret i organisationens processer og skaleret til organisationens behov. En SaaS-leverandør med 30 medarbejdere og en multinational bank har ikke den samme adgangsarkitektur, men begge har brug for en sammenhængende kæde af bevismateriale.
| Bevislag | Hvad det dokumenterer | Typiske kildesystemer | Værdi på tværs af efterlevelse |
|---|---|---|---|
| ISMS-omfang og krav fra interessenter | Hvilke systemer, data, reguleringer og tredjepartsafhængigheder der er omfattet | ISMS-omfang, compliance-register, datafortegnelse, leverandørregister | Understøtter ISO/IEC 27001:2022 Clauses 4.2 og 4.3, NIS2-afgrænsning, DORA-kortlægning af IKT-afhængigheder, GDPR-ansvarlighed |
| Adgangsrisikovurdering | Hvorfor IAM, MFA, PAM og gennemgange er nødvendige baseret på risiko | Risikoregister, trusselsscenarier, behandlingsplan | Understøtter ISO/IEC 27001:2022 Clause 6.1, ISO/IEC 27005:2022, DORA-rammeværk for IKT-risiko, NIS2-risikoforanstaltninger |
| Politikker og standarder | Hvad organisationen kræver | Politik for adgangsstyring, politik for privilegeret adgang, politik for onboarding og fratrædelse | Omsætter regulatoriske forventninger til håndhævelige interne regler |
| IAM- og PAM-konfiguration | Om kontroller er teknisk implementeret | IdP, HRIS, ITSM, PAM, cloud-IAM, SaaS-administrationskonsoller | Dokumenterer mindst privilegieprincip, MFA, RBAC, godkendelsesarbejdsgange og kontroller for privilegerede sessioner |
| Registreringer for gennemgang og overvågning | Om adgang fortsat er passende over tid | Kampagner for adgangsgennemgang, SIEM, PAM-logfiler, ledelsesattestationer | Dokumenterer løbende kontroludførelse, DORA-overvågning, NIS2-cyberhygiejne, GDPR-dataminimering |
| Offboarding- og undtagelsesregistreringer | Om adgang fjernes, og undtagelser styres | HR-fratrædelsesliste, deaktiveringslogfiler, undtagelsesregister | Dokumenterer rettidig tilbagekaldelse, accept af restrisiko og forebyggelse af brud |
ISO/IEC 27005:2022 er nyttig, fordi den anbefaler at samle juridiske, regulatoriske, kontraktlige, sektorspecifikke og interne krav i en fælles risikokontekst. Clauses 6.4 og 6.5 fremhæver risikokriterier, der tager højde for organisatoriske mål, lovgivning, leverandørrelationer og begrænsninger. Clauses 7.1 og 7.2 muliggør hændelsesbaserede og aktivbaserede scenarier. For adgangsstyring betyder det vurdering af strategiske scenarier såsom “privilegeret SaaS-administrator eksporterer EU-kundedata” sammen med aktivscenarier såsom “forældreløs AWS IAM-nøgle tilknyttet produktionslager.”
I Clarysecs Zenith Blueprint: En revisors 30-trins køreplan opbygges denne bevisrygrad i fasen Kontroller i praksis. Trin 19 fokuserer på teknologiske kontroller for endpoint og adgangsstyring, mens trin 22 formaliserer organisationens styring af adgangens livscyklus.
Zenith Blueprint instruerer teams i at verificere, at tildeling og fjernelse af adgang er struktureret, integreret med HR, hvor det er muligt, understøttet af arbejdsgange for adgangsanmodninger og gennemgået kvartalsvist. Den instruerer også organisationer i at dokumentere identitetstyper, håndhæve kontroller for individuelle, delte og serviceidentiteter, anvende stærke adgangskodepolitikker og MFA, eliminere inaktive konti og opretholde sikker opbevaring i en vault-løsning eller dokumentation for servicelegitimationsoplysninger.
Det er præcis sådan, revisorer tester adgangsstyring: én identitet, ét system, én godkendelse, ét privilegium, én gennemgang og én tilbagekaldelse ad gangen.
Hvad der skal indsamles som revisionsklart bevismateriale for adgangsstyring
Din bevispakke for adgangsstyring skal gøre det muligt for en revisor at udtage enhver bruger som stikprøve og følge livscyklussen: anmodning, godkendelse, tildeling, autentifikation, privilegieforøgelse, overvågning, gennemgang og tilbagekaldelse.
En stærk bevispakke omfatter:
- Politik for adgangsstyring og politik for brugerkonti
- Procedure for tiltrædelser, omplaceringer og fratrædelser
- Rollematrix eller adgangskontrolmatrix
- Liste over applikationer, platforme og datarepositories inden for omfanget
- MFA-konfiguration hos identitetsudbyderen
- Politikker for betinget adgang og undtagelsesliste
- Fortegnelse over privilegerede konti
- PAM-bevismateriale for arbejdsgange, herunder godkendelser og sessionslogfiler
- Output fra seneste kampagne for adgangsgennemgang
- Eksempler på ledelsesattestationer og afhjælpende foranstaltninger
- HR-fratrædelsesrapport afstemt mod deaktiveringslogfiler
- Fortegnelse over servicekonti, ejere, registreringer for rotation af adgangskoder og bevismateriale fra vault-løsning
- Procedure for break-glass-administratorkonti og testlog
- Bevismateriale for hændelser eller alarmer vedrørende mislykkede loginforsøg, eskalering af rettigheder eller inaktive konti
- Poster i erklæringen om anvendelighed for adgangsrelaterede Annex A-kontroller
Clarysec-politikker gør denne forventning eksplicit. I SMV-politikken Politik for adgangsstyring for SMV’er er kravet enkelt og revisionsfokuseret:
“Der skal opretholdes en sikker registrering for alle adgangstildelinger, ændringer og fjernelser.”
Fra afsnittet “Krav til implementering af politikken,” clause 6.1.1.
Den samme SMV-politik kobler også RBAC og MFA direkte til rolleansvar:
“Implementerer rollebaseret adgangsstyring (RBAC) og håndhæver stærk autentifikation (f.eks. multifaktorautentifikation (MFA)).”
Fra afsnittet “Roller og ansvar,” clause 4.2.3.
For større organisationer kræver enterprise-politikken Politik for onboarding og fratrædelse, at IAM-systemet logger kontooprettelse, rolle- og tilladelsestildelinger samt deaktiveringshændelser, understøtter rollebaserede adgangsskabeloner og integrerer med HR-systemer for udløsende hændelser ved tiltrædelser, omplaceringer og fratrædelser. Den klausul hjælper med at fortælle revisionshistorien ét sted: standardiseret onboarding, HR-udløst identitetslivscyklus og sporbare IAM-hændelser.
Kortlæg IAM, MFA, PAM og gennemgange til ISO/IEC 27001:2022-kontroller
Clarysecs Zenith Controls: Vejledning til efterlevelse på tværs af rammeværker behandler adgangsstyring som en sammenhængende kontrolfamilie, ikke et punkt på en tjekliste. For ISO/IEC 27001:2022 omfatter de mest relevante kontroller:
- kontrol 5.15, adgangsstyring
- kontrol 5.16, identitetsstyring
- kontrol 5.17, autentifikationsoplysninger
- kontrol 5.18, adgangsrettigheder
- kontrol 8.2, privilegerede adgangsrettigheder
- kontrol 8.3, begrænsning af adgang til information
- kontrol 8.5, sikker autentifikation
- kontrol 8.15, logning
- kontrol 8.16, overvågningsaktiviteter
For autentifikationsoplysninger kortlægger Zenith Controls kontrol 5.17 som en forebyggende kontrol, der understøtter fortrolighed, integritet og tilgængelighed, med den operationelle kapacitet identitets- og adgangsstyring. Den knytter direkte an til identitetsstyring, sikker autentifikation, roller og ansvar, acceptabel brug og efterlevelse af politikker. Sikkerhed for legitimationsoplysninger omfatter livscyklus for autentifikatorer, sikker udstedelse, opbevaring, nulstilling, tilbagekaldelse, MFA-tokens, private nøgler og servicelegitimationsoplysninger.
For adgangsrettigheder kortlægger Zenith Controls kontrol 5.18 til formel tildeling, gennemgang, ændring og tilbagekaldelse. Den knytter an til adgangsstyring, identitetsstyring, funktionsadskillelse, privilegerede adgangsrettigheder og overvågning af efterlevelse. Det er den kontrol, der omsætter mindst privilegieprincip til bevismateriale.
For privilegerede adgangsrettigheder kortlægger Zenith Controls kontrol 8.2 til den særlige risiko ved forhøjede konti, herunder domæneadministratorer, root-brugere, administratorer af cloud-tenants, databasesuperbrugere og CI/CD-controllere. Vejledningen kobler privilegeret adgang til identitetsstyring, adgangsrettigheder, begrænsning af informationsadgang, sikker autentifikation, fjernarbejde, logning og overvågning.
| Revisionsemne | ISO/IEC 27001:2022-bevismateriale for adgang | NIS2-kortlægning | DORA-kortlægning | GDPR-kortlægning |
|---|---|---|---|---|
| IAM-livscyklus | Arbejdsgang for tiltrædelser, omplaceringer og fratrædelser, adgangsanmodninger, godkendelser, rolleskabeloner, deaktiveringslogfiler | Article 21-risikostyringsforanstaltninger, politikker for adgangsstyring og styring af aktiver | Articles 5, 6 og 9 governance, IKT-risikorammeværk, logisk sikkerhed og adgangsstyring | Articles 5, 25 og 32 ansvarlighed, minimering og sikkerhed |
| MFA | IdP-politik, skærmbilleder af betinget adgang, MFA-tilmeldingsstatistik, godkendelser af undtagelser | Article 21(2)(j) MFA eller løbende autentifikation, hvor det er relevant | Sikker adgang til kritiske IKT-systemer og IKT-risikokontroller | Passende tekniske foranstaltninger mod uautoriseret adgang |
| PAM | Fortegnelse over privilegerede konti, godkendelser, JIT-privilegieforøgelse, sessionslogfiler, rotation i vault-løsning | Article 21(2)(i) risikobaseret adgangsstyring og styring af aktiver | Beskyttelse af IKT-systemer, operationel robusthed og overvågning | Begrænsning og revision af forhøjet adgang til personoplysninger |
| Gennemgang af adgangsrettigheder | Kvartalsvise eller halvårlige gennemgangsregistreringer, ledelsesattestationer, afhjælpningssager | Cyberhygiejne, politikker for adgangsstyring og styring af aktiver | Løbende overvågning, rollebaseret adgang og tilbagekaldelse | Databeskyttelse som standard og dokumenterbar ansvarlighed |
| Offboarding | HR-fratrædelsesliste, bevis for kontolåsning eller sletning, tilbagekaldelse af tokens | Rettidig fjernelse af unødvendig adgang | Styring af IKT-adgang gennem hele livscyklussen | Forebyggelse af uautoriseret adgang til personoplysninger |
En enkelt veldesignet rapport for gennemgang af adgangsrettigheder kan understøtte ISO/IEC 27001:2022, NIS2, DORA og GDPR, hvis den omfatter omfang, systemejer, gennemgangsansvarlig, kontoliste, rollebegrundelse, privilegieflag, beslutninger, fjernelser, undtagelser og afslutningsdato.
MFA-bevismateriale er mere end et skærmbillede
En almindelig revisionsfejl er at fremlægge et skærmbillede, hvor der står “MFA aktiveret.” Revisorer har brug for mere end det. De skal vide, hvor MFA gælder, hvem der er undtaget, hvordan undtagelser godkendes, om privilegerede konti er dækket, og om den tekniske konfiguration svarer til politikken.
Fra Zenith Blueprint, fasen Kontroller i praksis, trin 19, vil revisorer spørge, hvordan adgangskode- og MFA-politikker håndhæves, hvilke systemer der er beskyttet, hvem MFA gælder for, og om kritiske applikationer kan testes med en prøvekonto. Bevismateriale kan omfatte IdP-konfiguration, politikker for betinget adgang, MFA-tilmeldingsstatistik og procedurer for nulstilling af adgangskoder.
For enterprise-miljøer fastslår Clarysecs Politik for styring af brugerkonti og privilegier:
“Hvor det er teknisk muligt, er multifaktorautentifikation (MFA) obligatorisk for: 6.3.2.1 Administrative konti og konti på root-niveau 6.3.2.2 Fjernadgang (VPN, cloudplatforme) 6.3.2.3 Adgang til følsomme eller regulerede data”
Fra afsnittet “Krav til implementering af politikken,” clause 6.3.2.
Det skaber en direkte revisionsbro. Hvis MFA er obligatorisk for administratorkonti, fjernadgang og regulerede data, bør bevispakken omfatte lister over administrative konti og konti på root-niveau, konfiguration af fjernadgang, politikker for betinget adgang på cloudplatforme, lister over applikationer med følsomme data, MFA-tilmeldingsrapporter, godkendelser af undtagelser, kompenserende kontroller og nyere bevismateriale for gennemgang af alarmer om mislykkede loginforsøg eller forsøg på omgåelse af MFA.
For NIST SP 800-53 Rev. 5 stemmer dette overens med IA-2 Identification and Authentication, IA-5 Authenticator Management, AC-17 Remote Access og AU-2 Event Logging. For COBIT 2019 understøtter det DSS05.04 Manage user identity and logical access og relaterede praksisser for sikkerhedsovervågning.
Understøttende ISO-standarder udvider billedet. ISO/IEC 27018:2020 udvider autentifikationsforventninger for public cloud, der håndterer personoplysninger. ISO/IEC 24760-1:2019 understøtter binding af autentifikatorer og livscyklusstyring. ISO/IEC 29115:2013 introducerer sikringsniveauer for autentifikation, nyttigt når det skal besluttes, hvor hardwaretokens eller phishing-resistent MFA er nødvendige. ISO/IEC 27033-1:2015 understøtter stærk netværksautentifikation for fjernadgang eller adgang mellem netværk.
PAM-bevismateriale er den hurtigste vej til en væsentlig konstatering eller en ren revision
Privilegeret adgang er dér, hvor revisorer bliver skeptiske, fordi privilegerede konti kan tilsidesætte kontroller, udtrække data, skabe persistens og ændre logfiler. I Zenith Blueprint, trin 19, står der:
“I ethvert informationssystem er privilegeret adgang magt, og med den magt følger risiko.”
Vejledningen fokuserer på, hvem der har privilegeret adgang, hvad den giver mulighed for, hvordan den styres, og hvordan den overvåges over tid. Den anbefaler en ajourført fortegnelse, mindst privilegieprincip, RBAC, tidsbaseret eller just-in-time privilegieforøgelse, godkendelsesarbejdsgange, unikke navngivne konti, undgåelse af delte konti, logning af break-glass-administratorkonti, PAM-systemer, periodisk rotation af legitimationsoplysninger, vaulting, registrering af sessioner, midlertidig privilegieforøgelse, overvågning og regelmæssig gennemgang.
Clarysecs enterprise-Politik for adgangsstyring omsætter dette til et kontrolkrav:
“Administrativ adgang skal kontrolleres stramt gennem: 5.4.1.1 Særskilte privilegerede konti 5.4.1.2 Sessionsovervågning og -optagelse 5.4.1.3 Multifaktorautentifikation 5.4.1.4 Tidsbegrænset eller workflow-udløst privilegieforøgelse”
Fra afsnittet “Styringskrav,” clause 5.4.1.
Dette citat er næsten et revisions-testscript. Hvis politikken siger særskilte administratorkonti, skal den privilegerede kontoliste vises, og det skal dokumenteres, at hver konto knytter sig til en navngiven person. Hvis den siger sessionsovervågning, skal der vises registrerede sessioner eller PAM-logfiler. Hvis den siger MFA, skal håndhævelse dokumenteres for alle adgangsveje med privilegeret adgang. Hvis den siger tidsbegrænset privilegieforøgelse, skal udløbstidsstempler og godkendelsessager vises.
SMV-versionen er lige så direkte. Politik for styring af brugerkonti og privilegier for SMV’er fastslår:
“Forhøjede eller administrative privilegier kræver yderligere godkendelse fra direktøren eller den it-ansvarlige og skal dokumenteres, være tidsbegrænsede og underlægges periodisk gennemgang.”
Fra afsnittet “Krav til implementering af politikken,” clause 6.2.2.
For mindre organisationer er dette ofte forskellen mellem “vi stoler på vores administrator” og “vi kontrollerer privilegeret risiko.” Revisoren kræver ikke enterprise-værktøjer i enhver SMV, men kræver bevismateriale, der står mål med risikoen. En sag, en godkendelse, en midlertidig gruppetildeling, håndhævet MFA og en gennemgangsregistrering kan være tilstrækkeligt, når omfanget er begrænset, og risikoen er lavere.
Gennemgang af adgangsrettigheder dokumenterer, at mindst mulige rettigheder fungerer
Gennemgang af adgangsrettigheder viser, om tilladelser akkumuleres i det skjulte. De viser også, om ledere forstår den adgang, deres teams faktisk har.
Enterprise-politikken Politik for styring af brugerkonti og privilegier kræver:
“Kvartalsvise gennemgange af alle brugerkonti og tilknyttede privilegier skal gennemføres af informationssikkerhedsfunktionen i samarbejde med afdelingsledere.”
Fra afsnittet “Krav til implementering af politikken,” clause 6.5.1.
For SMV’er fastsætter Politik for styring af brugerkonti og privilegier for SMV’er en proportional kadence:
“En gennemgang af alle brugerkonti og privilegier skal udføres hver sjette måned.”
Fra afsnittet “Krav til implementering af politikken,” clause 6.4.1.
En troværdig adgangsgennemgang omfatter systemnavn, omfang, gennemgangsansvarliges navn, eksportdato, gennemgangsdato, identitetsejer, afdeling, leder, ansættelsesstatus, rolle eller rettighed, privilegieflag, datasensitivitetsflag, beslutning, afhjælpningssag, lukkedato, undtagelsesejer og udløbsdato for undtagelse.
For Zenith Controls er adgangsrettigheder 5.18 det sted, hvor dette bliver bevismateriale på tværs af efterlevelse. Vejledningen kortlægger adgangsrettigheder til GDPR Article 25, fordi adgang bør være begrænset gennem design og som standard. Den kortlægger til NIS2 Article 21(2)(i), fordi politikker for adgangsstyring og styring af aktiver kræver risikobaseret tildeling, rettidig fjernelse af unødvendig adgang og formel tilbagekaldelse. Den kortlægger til DORA, fordi finansielle IKT-systemer har brug for rollebaseret adgang, overvågning og tilbagekaldelsesprocesser.
NIST-orienterede revisorer tester ofte dette gennem AC-2 Account Management, AC-5 Separation of Duties og AC-6 Least Privilege. COBIT 2019-revisorer ser mod DSS05.04 Manage user identity and logical access og DSS06.03 Manage roles, responsibilities, access privileges and levels of authority. ISACA ITAF-revisorer fokuserer på, om bevismaterialet er tilstrækkeligt, pålideligt og fuldstændigt.
Offboarding og tilbagekaldelse af tokens er lette at udtage som stikprøve
Fratrådte medarbejdere er et af de letteste steder at dokumentere, om livscyklussen fungerer. Revisorer vælger ofte en nyligt fratrådt medarbejder og beder om HR-fratrædelsesregistreringen, sagen, loggen over kontodeaktivering, bevis for SaaS-deaktivering, fjernelse af VPN, tilbagekaldelse af MFA, fjernelse af API-token og tilbagelevering af aktiver.
I Politik for onboarding og fratrædelse for SMV’er fastslår Clarysec:
“Fratrådte konti skal låses eller slettes, og tilknyttede adgangstokens skal tilbagekaldes, herunder fjernadgang (VPN), MFA-apptilknytninger og API-tokens.”
Fra afsnittet “Krav til implementering af politikken,” clause 6.3.3.
Det er vigtigt, fordi moderne adgang ikke kun er et brugernavn og en adgangskode. Adgang kan fortsætte via refresh tokens, API-nøgler, SSH-nøgler, OAuth-tildelinger, servicekonti, lokale administratorrettigheder, mobile sessioner og tredjepartsportaler. En deaktiveret HR-registrering uden tilbagekaldelse af tokens er ufuldstændigt bevismateriale.
Zenith Blueprint, fasen Kontroller i praksis, trin 16, instruerer organisationer i at være klar med en dokumenteret fratrædelsestjekliste, bevismateriale fra en nyligt fratrådt medarbejder, en log over deaktivering af brugerkonti fra AD eller MDM, en underskrevet formular for tilbagelevering af aktiver og offboarding-dokumentation, der omfatter fortrolighedsforpligtelser.
Marias revisor bad om en fratrådt seniorudvikler, som havde privilegeret adgang til produktionsdatabaser. Hendes team fremlagde Politik for onboarding og fratrædelse for SMV’er, fratrædelsestjeklisten bygget ud fra Zenith Blueprint trin 16, den HR-udløste ITSM-sag, katalogets deaktiveringslog, tilbagekaldelsen af VPN-certifikatet, fjernelsen fra GitHub-organisationen, sletningen af AWS IAM-nøglen og den lukkede verifikationssag underskrevet af den it-ansvarlige. Bevismaterialet var fuldstændigt, rettidigt og direkte knyttet tilbage til politikken.
Kør en bevismaterialsprint med tre stikprøver, før revisoren gør det
En praktisk beredskabsøvelse er at vælge tre stikprøver før revisionen:
- En ny medarbejder, der er startet inden for de seneste 90 dage
- En privilegeret bruger med administratoradgang til cloud, database, produktion eller IAM
- En fratrådt eller rolleændret medarbejder fra de seneste 90 dage
| Stikprøve | Bevismateriale der skal indsamles | Beståelseskriterium | Almindelig konstatering |
|---|---|---|---|
| Ny medarbejder | HR-startregistrering, adgangsanmodning, godkendelse, rolletildeling, MFA-tilmelding, første login | Adgang er kun tildelt efter godkendelse og i overensstemmelse med rollen | Adgang tildelt før godkendelse eller for bred rolle |
| Privilegeret bruger | Forretningsmæssig begrundelse, særskilt administratorkonto, MFA-bevis, PAM-godkendelse, sessionslog, kvartalsvis gennemgang | Privilegiet er navngivet, begrundet, tidsbegrænset hvor muligt, overvåget og gennemgået | Delt administratorkonto, manglende MFA, intet sessionsbevis |
| Fratrådt eller omplaceret medarbejder | HR-hændelse, fratrædelses- eller rolleændringssag, deaktiveringslogfiler, fjernelse af VPN, tilbagekaldelse af MFA- eller API-token, lukning af gennemgang | Adgang fjernet hurtigt og fuldstændigt | SaaS-konto stadig aktiv, API-token ikke tilbagekaldt, gammelt gruppemedlemskab bevaret |
Kobl derefter hver stikprøve til ISMS-registreringerne: risikoscenarie, behandlingsbeslutning, kontrolvalg i erklæringen om anvendelighed, politikklausul, teknisk konfiguration, gennemgangsregistrering og korrigerende handling, hvis der findes et hul.
Det flytter revisionsforberedelse fra dokumentsamling til kontrolverifikation.
Forbered jer på forskellige revisionsperspektiver
Forskellige revisionsbaggrunde fører til forskellige spørgsmål, selv når bevismaterialet er det samme.
| Revisionsperspektiv | Primært fokus | Forventet bevismateriale |
|---|---|---|
| ISO/IEC 27001:2022-revisor | ISMS-proces, risikobehandling og kontroludførelse | Risikovurdering, SoA, godkendte politikker, adgangsanmodninger, gennemgangsregistreringer, deaktiveringslogfiler |
| ISO/IEC 19011:2018-revisionspraksis | Stikprøver, bekræftelse og konsistens | Adgangskodeindstillinger, lockout-tærskler, godkendelsestidsstempler, udførelsesregistreringer, interviews |
| ISO/IEC 27007:2020 ISMS-revisor | Gennemførelse af ISMS-revision og effektivitet | Rolledefinitioner sammenlignet med faktiske tilladelser, spor for godkendelse af privilegeret adgang, tilbagekaldelseslogfiler |
| NIST-fokuseret vurderingspart | Teknisk implementering og kontroltest | AC-2-, AC-5-, AC-6-, AC-17-, IA-2-, IA-5- og AU-2-bevismateriale fra IAM-, PAM- og SIEM-værktøjer |
| COBIT 2019- eller ISACA-revisor | Governance, ejerskab og bevismaterialets pålidelighed | DSS05.04- og DSS06.03-procesbevismateriale, metrikker, undtagelser, sporing af afhjælpning |
| DORA-gennemgangsansvarlig | IKT-risiko, robusthed og kritikalitet | Adgangslister for kritiske systemer, overvågning af privilegeret adgang, kontroller for tredjepartsadministratorer, links til robusthedstest |
| NIS2-gennemgangsansvarlig | Ledelsens ansvarlighed og risikoforanstaltninger | Bestyrelsestilsyn, Article 21-foranstaltninger for adgangsstyring, MFA-dækning, hændelsesberedskab |
| GDPR-gennemgangsansvarlig | Fortrolighed og ansvarlighed for personoplysninger | Begrænsninger i adgang til personoplysninger, bevismateriale for Article 25-databeskyttelse som standard, Article 32-sikkerhedsforanstaltninger |
Forberedelse af bevismateriale, der tilfredsstiller alle disse perspektiver, viser et modent efterlevelsesprogram og reducerer dobbeltarbejde.
Almindelige konstateringer og forebyggende handlinger
Konstateringer vedrørende adgangsstyring er forudsigelige. Det samme er de forebyggende handlinger.
| Konstatering | Hvorfor det er vigtigt | Forebyggelse |
|---|---|---|
| Gennemgang af adgangsrettigheder findes, men privilegerede konti er udeladt | Administratorrettigheder skaber risikoen med størst konsekvens | Medtag privilegieflag, PAM-registreringer og administratorgrupper i hver gennemgang |
| MFA er aktiveret for medarbejdere, men ikke for servicedesks, kontrahenter eller cloudadministratorer | Angribere går efter undtagelser | Oprethold rapport over MFA-dækning og undtagelsesregister med udløbsdatoer |
| Tiltrædelsesprocessen er dokumenteret, men omplaceringer styres ikke | Rolleglidning akkumuleres efter rolleændringer | Udløs adgangsgennemgang ved hver afdelings- eller rolleændring |
| Delte administratorkonti findes uden kompenserende kontroller | Ansvarligheden er svag | Erstat med navngivne administratorkonti, eller håndhæv vault-udtjekning og sessionslogning |
| Fratrådte medarbejdere er deaktiveret i kataloget, men aktive i SaaS-platforme | Adgang fortsætter uden for den centrale IdP | Oprethold applikationsfortegnelse og offboarding-tjekliste for hvert system |
| Adgangskoder til servicekonti er ukendte eller roteres aldrig | Ikke-menneskelige identiteter bliver skjulte bagdøre | Tildel ejere, opbevar hemmeligheder i vault-løsning, roter legitimationsoplysninger og gennemgå brugslogfiler |
| Politikken siger kvartalsvis gennemgang, men bevismaterialet viser årlig gennemgang | Politik og praksis afviger | Juster kadencen ud fra risiko, eller håndhæv det dokumenterede krav |
| Adgangsgodkendelser ligger i e-mail uden opbevaringsregel | Revisionssporet er skrøbeligt | Brug ITSM-arbejdsgange og opbevaring, der er afstemt med politikken |
Enterprise-politikken Politik for adgangsstyring tilføjer et opbevaringskrav, der forebygger en af de mest almindelige fejl i bevismateriale:
“Godkendelsesbeslutninger skal logges og opbevares til revisionsformål i mindst 2 år.”
Fra afsnittet “Styringskrav,” clause 5.3.2.
Hvis godkendelser forsvinder efter oprydning i e-mail, kan kontrollen have fungeret, men revisionen kan ikke basere sig på den. Opbevaring er en del af kontroldesignet.
Ledelsesmæssig ansvarlighed kræver adgangsmetrikker
NIS2 Article 20 og DORA Articles 5 og 6 gør adgangsstyring til et ledelsesanliggende, fordi identitetskompromittering kan blive til driftsforstyrrelser, regulatorisk rapportering, brud på persondatasikkerheden og skade for kunder. ISO/IEC 27001:2022 Clauses 5.1 til 5.3 kræver også, at øverste ledelse afstemmer ISMS med forretningsstrategien, stiller ressourcer til rådighed, kommunikerer vigtigheden, tildeler ansvar og fremmer løbende forbedring.
Nyttige metrikker for adgangsstyring omfatter:
- Procentdel af kritiske systemer dækket af SSO
- Procentdel af privilegerede konti med MFA
- Antal stående privilegerede konti sammenlignet med JIT-konti
- Fuldførelsesgrad for gennemgang af adgangsrettigheder
- Antal tilbagekaldte overdrevne tilladelser
- Efterlevelse af SLA for deaktivering af fratrådte medarbejdere
- Antal inaktive konti
- Dækning af ejere for servicekonti
- Dækning for PAM-sessionsoptagelse
- Antal og alder på MFA-undtagelser
Disse metrikker hjælper ledelsen med at godkende risikobehandling og dokumentere tilsyn. De gør også revisioner mere troværdige, fordi organisationen kan vise, at adgangsstyring overvåges som en levende risiko og ikke genopdages før hver revision.
Omsæt spredt bevismateriale til revisionssikkerhed
Hvis ISO/IEC 27001:2022-bevismateriale for adgangsstyring er spredt på tværs af HR, ITSM, IAM, PAM, cloudkonsoller og regneark, er næste skridt ikke endnu en omskrivning af politikken. Næste skridt er en bevisarkitektur.
Start med denne rækkefølge:
- Definér systemer, identiteter og data inden for omfanget.
- Kortlæg NIS2-, DORA-, GDPR- og kontraktlige krav ind i ISMS-konteksten.
- Brug risikoscenarier i ISO/IEC 27005:2022-stil til at prioritere IAM, MFA, PAM og gennemgang af adgangsrettigheder.
- Opdater erklæringen om anvendelighed og risikobehandlingsplanen.
- Afstem politikklausuler med faktiske IAM- og PAM-arbejdsgange.
- Kør bevismaterialsprinten med tre stikprøver.
- Luk huller, før revisoren finder dem.
- Vedligehold en genanvendelig bevispakke til certificering, kunde-due diligence og regulatoriske gennemgange.
Clarysec kan hjælpe jer med at implementere dette gennem Zenith Blueprint: En revisors 30-trins køreplan, kortlægge krav på tværs med Zenith Controls: Vejledning til efterlevelse på tværs af rammeværker og operationalisere krav med det rette Clarysec-politiksæt, herunder Politik for adgangsstyring, Politik for styring af brugerkonti og privilegier og Politik for onboarding og fratrædelse.
Revisionsberedskab for adgangsstyring handler ikke om at dokumentere, at I har købt et IAM-værktøj. Det handler om at dokumentere, at identitets-, autentifikations-, privilegie- og gennemgangsprocesser reducerer reel forretningsrisiko og opfylder de standarder og regler, der er relevante for organisationen.
Download Clarysec-værktøjskasserne, kør bevismaterialsprinten med tre stikprøver, og omsæt jeres bevismateriale for adgangsstyring fra et spredt rod til en klar, gentagelig og juridisk forsvarlig revisionsportefølje.
Frequently Asked Questions
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
