ISO 27001-vägledning för revisionsunderlag inom åtkomstkontroll
Klockan är 09:10 på revisionsdagen. Maria, CISO för en snabbväxande fintech- och molnplattform, har sin åtkomstkontrollpolicy öppen. IT-ansvarig exporterar inställningar för villkorsstyrd åtkomst från identitetsleverantören. HR letar efter avslutsärendet för en finansanalytiker som slutade för sex veckor sedan. Internrevisorn tittar upp och ställer frågan som alla visste skulle komma:
”Visa mig hur åtkomst begärs, godkänns, tillämpas, granskas och tas bort för en användare med privilegierad åtkomst till personuppgifter.”
Den enda meningen kan avslöja om ett åtkomstkontrollprogram är revisionsklart eller bara färdigt på policynivå.
Marias team hade ett moget ledningssystem för informationssäkerhet, en årlig ISO/IEC 27001:2022-omcertifieringscykel, flerfaktorsautentisering på plats, rollbaserade behörighetsmallar i centrala system och kalkylblad för kvartalsvisa åtkomstgranskningar. Men den här revisionen var annorlunda. Revisorns begärandelista omfattade beredskap för nya regulatoriska krav. För Marias organisation innebar det NIS2, DORA och GDPR, alla granskade genom samma operativa lins: identitet, åtkomst, autentisering, privilegier och underlag.
Problemet för många CISO:er är inte att åtkomstkontroll saknas. Problemet är att underlaget finns i fragment. Introduktionsgodkännanden ligger i Jira eller ServiceNow. MFA-inställningar finns i Microsoft Entra ID, Okta eller hos en annan identitetsleverantör. Behörigheter i AWS, Azure och Google Cloud ligger i separata konsoler. Privilegierade åtgärder kan vara loggade i ett PAM-verktyg, eller inte alls. HR-status finns i BambooHR, Workday eller kalkylblad. Åtkomstgranskningar kan vara godkända via e-post.
När en revisor kopplar samman IAM, MFA, PAM, händelser för nyanställningar, interna förflyttningar och avslut, personuppgifter, molnadministration och regulatoriska förväntningar faller fragmenterat underlag snabbt isär.
ISO/IEC 27001:2022-revisioner av åtkomstkontroll är inte bara tekniska konfigurationsgranskningar. De är tester av ledningssystemet. De granskar om identitets- och åtkomstrisker är förstådda, behandlade, införda, övervakade och förbättrade. När NIS2, DORA och GDPR också är relevanta måste samma underlag visa riskbaserad behörighetsstyrning, stark autentisering, spårbara godkännanden, snabb behörighetsindragning, begränsning av privilegier, skydd av personuppgifter och ledningens ansvarsskyldighet.
Det praktiska svaret är inte en större pärm. Det är en gemensam underlagsmodell för åtkomstkontroll som börjar med ISMS-omfattning och risk, går via policy- och kontrolldesign, landar i IAM- och PAM-verktyg och mappas tydligt mot ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST och COBIT.
Varför åtkomstkontroll är den regulatoriska knutpunkten
Åtkomstkontroll har blivit en fråga för styrelse och tillsynsmyndigheter eftersom komprometterade identiteter nu är en vanlig väg till driftstörningar, personuppgiftsincidenter, bedrägerier och exponering i leveranskedjan.
Enligt NIS2 omfattar Articles 2 and 3, lästa tillsammans med Annex I and Annex II, många medelstora och större entiteter inom angivna sektorer som väsentliga eller viktiga entiteter. Detta inkluderar digital infrastruktur och leverantörer av IKT-tjänstehantering, såsom leverantörer av molntjänster, datacentertjänster, hanterade tjänsteleverantörer och leverantörer av hanterade säkerhetstjänster. Medlemsstaterna skulle införliva NIS2 senast i oktober 2024 och tillämpa nationella åtgärder från oktober 2024, med listor över entiteter senast i april 2025. Article 20 gör ledningsorgan ansvariga för att godkänna åtgärder för hantering av cybersäkerhetsrisker och utöva tillsyn över genomförandet. Article 21 kräver tekniska, operativa och organisatoriska åtgärder, inklusive åtkomstkontrollpolicyer, tillgångshantering, cyberhygien, incidenthantering, kontinuitet i verksamheten, säkerhet i leveranskedjan samt MFA eller kontinuerlig autentisering där det är lämpligt.
DORA lägger till ett sektorsspecifikt lager för operativ resiliens för finansiella entiteter och relevanta IKT-tredjepartsleverantörer. Articles 1, 2 and 64 etablerar DORA som ett enhetligt ramverk som gäller från den 17 januari 2025. Articles 5 and 6 kräver styrning och ett dokumenterat ramverk för IKT-riskhantering. Article 9 behandlar skydd och förebyggande åtgärder, inklusive IKT-säkerhetspolicyer, rutiner, protokoll och verktyg. Articles 24 to 30 lägger till testning av digital operativ resiliens och hantering av IKT-tredjepartsrisk. För finansiella entiteter blir åtkomstkontrollunderlag resiliensunderlag, inte bara underlag för IT-administration.
GDPR tillför personuppgiftsperspektivet. Articles 2 and 3 definierar bred tillämplighet för behandling inom EU och räckvidd mot EU-marknaden. Article 5 kräver riktighet, konfidentialitet och påvisbar ansvarsskyldighet. Article 25 kräver dataskydd genom design och som standard. Article 32 kräver lämpliga tekniska och organisatoriska åtgärder. I praktiken innebär det kontrollerad åtkomst, säker autentisering, loggning, granskning och snabb borttagning för system som behandlar personuppgifter.
ISO/IEC 27001:2022 ger organisationer den ledningssystemsmotor som behövs för att förena dessa krav. Klausulerna 4.1 till 4.3 kräver att organisationen förstår kontext, intressenter, rättsliga och avtalsmässiga krav, gränssnitt, beroenden och ISMS-omfattning. Klausulerna 6.1.1 till 6.1.3 kräver informationssäkerhetsriskbedömning, riskbehandling, jämförelse mot bilaga A, en tillämplighetsförklaring och godkännande av riskbehandlingsplaner och kvarstående risk. Klausul 8.1 kräver operativ styrning, dokumenterad information som visar att processer har genomförts som planerat, styrning av ändringar och kontroll över processer som tillhandahålls externt.
Revisionsfrågan är därför inte ”Har ni MFA?” Den är ”Kan ni visa, för identiteter och system inom omfattningen, att åtkomstrisk styrs, behandlas, införs, övervakas och förbättras?”
Bygg underlagets ryggrad från ISMS-omfattning till IAM-bevisning
Clarysec inleder förberedelser inför revision av åtkomstkontroll genom att göra underlaget spårbart från verksamhetskontexten. ISO/IEC 27001:2022 förväntar sig att ISMS integreras i organisationens processer och skalas efter organisationens behov. En SaaS-leverantör med 30 personer och en multinationell bank har inte samma åtkomstarkitektur, men båda behöver en sammanhängande beviskedja.
| Underlagslager | Vad det visar | Typiska källsystem | Värde för flera regelverk |
|---|---|---|---|
| ISMS-omfattning och intressentkrav | Vilka system, data, regelverk och tredjepartsberoenden som ingår i omfattningen | ISMS-omfattning, register över regelefterlevnadskrav, dataregister, leverantörsregister | Stödjer ISO/IEC 27001:2022 Clauses 4.2 och 4.3, NIS2-omfattning, DORA-kartläggning av IKT-beroenden, GDPR-ansvarsskyldighet |
| Åtkomstriskbedömning | Varför IAM, MFA, PAM och granskningar behövs utifrån risk | Riskregister, hotscenarier, riskbehandlingsplan | Stödjer ISO/IEC 27001:2022 Clause 6.1, ISO/IEC 27005:2022, DORA:s IKT-riskramverk, NIS2-riskåtgärder |
| Policyer och standarder | Vad organisationen kräver | Åtkomstkontrollpolicy, privilegiepolicy, policy för introduktion och avslut | Omvandlar regulatoriska förväntningar till bindande interna regler |
| IAM- och PAM-konfiguration | Om kontroller är tekniskt införda | IdP, HRIS, ITSM, PAM, moln-IAM, SaaS-administrationskonsoler | Visar principen om minsta privilegium, MFA, RBAC, godkännandearbetsflöden och kontroller för privilegierade sessioner |
| Gransknings- och övervakningsposter | Om åtkomsten fortsatt är lämplig över tid | Åtkomstgranskningskampanjer, SIEM, PAM-loggar, chefers intyganden | Visar löpande kontrollfunktion, DORA-övervakning, NIS2-cyberhygien, GDPR-minimering |
| Poster för offboarding och undantag | Om åtkomst tas bort och undantag kontrolleras | HR-lista över avslut, avaktiveringsloggar, undantagsregister | Visar snabb återkallelse, acceptans av kvarstående risk och förebyggande av incidenter |
ISO/IEC 27005:2022 är användbar eftersom den rekommenderar att rättsliga, regulatoriska, avtalsmässiga, sektorsspecifika och interna krav konsolideras till en gemensam riskkontext. Klausulerna 6.4 och 6.5 betonar riskkriterier som beaktar organisatoriska mål, lagar, leverantörsrelationer och begränsningar. Klausulerna 7.1 och 7.2 möjliggör händelsebaserade och tillgångsbaserade scenarier. För åtkomstkontroll innebär det att bedöma strategiska scenarier som ”privilegierad SaaS-administratör exporterar EU-kunddata” tillsammans med tillgångsscenarier som ”herrelös AWS IAM-nyckel kopplad till produktionslagring”.
I Clarysecs Zenith Blueprint: En revisors 30-stegs färdplan byggs denna underlagsryggrad under fasen Kontroller i praktiken. Steg 19 fokuserar på tekniska kontroller för slutpunkts- och åtkomsthantering, medan steg 22 formaliserar organisationens åtkomstlivscykel.
Zenith Blueprint instruerar team att verifiera att provisionering och avprovisionering är strukturerade, integrerade med HR där det är möjligt, stöds av arbetsflöden för åtkomstbegäran och granskas kvartalsvis. Den instruerar också organisationer att dokumentera identitetstyper, tillämpa kontroller för individuella, delade identiteter och tjänsteidentiteter, använda starka lösenordspolicyer och MFA, eliminera inaktiva konton och upprätthålla säker valvlagring eller dokumentation för tjänsteautentiseringsuppgifter.
Det är precis så revisorer testar åtkomstkontroll: en identitet, ett system, ett godkännande, ett privilegium, en granskning och en återkallelse åt gången.
Vad som ska samlas in för revisionsklart åtkomstkontrollunderlag
Ert underlagspaket för åtkomstkontroll ska göra det möjligt för en revisor att välja vilken användare som helst och följa livscykeln: begäran, godkännande, tilldelning, autentisering, privilegiehöjning, övervakning, granskning och återkallelse.
Ett starkt underlagspaket omfattar:
- Åtkomstkontrollpolicy och policy för användarkonton
- Rutin för nyanställningar, interna förflyttningar och avslut
- Rollmatris eller åtkomstkontrollmatris
- Lista över applikationer, plattformar och datalagringsplatser inom omfattningen
- MFA-konfiguration hos identitetsleverantören
- Policyer för villkorsstyrd åtkomst och undantagslista
- Förteckning över privilegierade konton
- Underlag för PAM-arbetsflöden, inklusive godkännanden och sessionsloggar
- Resultat från senaste åtkomstgranskningskampanj
- Exempel på chefers intyganden och avhjälpande åtgärder
- HR-avslutsrapport matchad mot avaktiveringsloggar
- Förteckning över tjänstekonton, ägare, rotationsposter och underlag från nyckelvalv
- Rutin för break-glass-konton och testlogg
- Incident- eller larmunderlag som rör misslyckade inloggningsförsök, privilegiehöjning eller inaktiva konton
- Poster i tillämplighetsförklaringen för åtkomstrelaterade kontroller i bilaga A
Clarysecs policyer gör denna förväntan uttrycklig. I SME-versionen Åtkomstkontrollpolicy-sme är kravet enkelt och revisionsfokuserat:
”En säker post ska upprätthållas för all åtkomsttilldelning, alla ändringar och alla borttagningar.”
Från avsnittet ”Krav för genomförande av policyn”, klausul 6.1.1.
Samma SME-policy kopplar även RBAC och MFA direkt till rollansvar:
”Inför rollbaserad åtkomstkontroll (RBAC) och kräv stark autentisering (t.ex. flerfaktorsautentisering (MFA)).”
Från avsnittet ”Roller och ansvar”, klausul 4.2.3.
För större organisationer kräver företagspolicyn Policy för introduktion och avslut att IAM-systemet loggar kontoskapande, tilldelade roller och behörigheter samt avaktiveringshändelser, stödjer rollbaserade behörighetsmallar och integreras med HR-system för utlösare kopplade till nyanställningar, interna förflyttningar och avslut. Den klausulen hjälper till att berätta revisionshistorien på ett ställe: standardiserad introduktion, HR-utlöst identitetslivscykel och spårbara IAM-händelser.
Mappa IAM, MFA, PAM och granskningar mot ISO/IEC 27001:2022-kontroller
Clarysecs Zenith Controls: Vägledning för efterlevnad över flera regelverk behandlar åtkomstkontroll som en sammanhängande kontrollfamilj, inte som en punkt i en checklista. För ISO/IEC 27001:2022 är de mest relevanta kontrollerna:
- Kontroll 5.15, åtkomstkontroll
- Kontroll 5.16, identitetshantering
- Kontroll 5.17, autentiseringsinformation
- Kontroll 5.18, åtkomsträttigheter
- Kontroll 8.2, privilegierade åtkomsträttigheter
- Kontroll 8.3, begränsning av åtkomst till information
- Kontroll 8.5, säker autentisering
- Kontroll 8.15, loggning
- Kontroll 8.16, övervakningsaktiviteter
För autentiseringsinformation mappar Zenith Controls kontroll 5.17 som en förebyggande kontroll som stödjer konfidentialitet, riktighet och tillgänglighet, med den operativa förmågan identitets- och åtkomsthantering. Den knyter direkt till identitetshantering, säker autentisering, roller och ansvar, godtagbar användning och efterlevnad av policyer. Säkerhet för autentiseringsuppgifter omfattar livscykeln för autentiserare, säker utfärdandeprocess, lagring, återställning, återkallelse, MFA-tokens, privata nycklar och tjänsteautentiseringsuppgifter.
För åtkomsträttigheter mappar Zenith Controls kontroll 5.18 till formell tilldelning, granskning, ändring och återkallelse. Den knyter till åtkomstkontroll, identitetshantering, funktionsuppdelning, privilegierade åtkomsträttigheter och övervakning av efterlevnad. Detta är kontrollen som gör principen om minsta privilegium till revisionsunderlag.
För privilegierade åtkomsträttigheter mappar Zenith Controls kontroll 8.2 till den särskilda risken med förhöjda konton, inklusive domänadministratörer, root-användare, administratörer för molntenanter, databassuperanvändare och CI/CD-kontroller. Vägledningen kopplar privilegierad åtkomst till identitetshantering, åtkomsträttigheter, begränsning av åtkomst till information, säker autentisering, distansarbete, loggning och övervakning.
| Revisionstema | ISO/IEC 27001:2022-åtkomstunderlag | NIS2-mappning | DORA-mappning | GDPR-mappning |
|---|---|---|---|---|
| IAM-livscykel | Arbetsflöde för nyanställningar, interna förflyttningar och avslut, åtkomstbegäran, godkännanden, rollmallar, avaktiveringsloggar | Article 21 riskhanteringsåtgärder, åtkomstkontrollpolicyer och tillgångshantering | Articles 5, 6 and 9 styrning, IKT-riskramverk, logisk säkerhet och åtkomstkontroll | Articles 5, 25 and 32 ansvarsskyldighet, minimering och säkerhet |
| MFA | IdP-policy, skärmbilder från villkorsstyrd åtkomst, MFA-registreringsstatistik, undantagsgodkännanden | Article 21(2)(j) MFA eller kontinuerlig autentisering där det är lämpligt | Säker åtkomst till kritiska IKT-system och IKT-riskkontroller | Lämpliga tekniska åtgärder mot obehörig åtkomst |
| PAM | Förteckning över privilegierade konton, godkännanden, JIT-privilegiehöjning, sessionsloggar, rotation i nyckelvalv | Article 21(2)(i) riskbaserad åtkomstkontroll och tillgångshantering | Skydd av IKT-system, operativ resiliens och övervakning | Begränsning och revision av förhöjd åtkomst till personuppgifter |
| Åtkomstgranskning | Kvartalsvisa eller halvårsvisa granskningsposter, chefers intyganden, åtgärdsärenden | Cyberhygien, åtkomstkontrollpolicyer och tillgångshantering | Löpande övervakning, rollbaserad åtkomst och återkallelse | Dataskydd som standard och påvisbar ansvarsskyldighet |
| Offboarding | HR-lista över avslut, underlag för kontolåsning eller radering, återkallelse av token | Snabb borttagning av onödig åtkomst | Kontroll över IKT-åtkomst genom hela livscykeln | Förebyggande av obehörig åtkomst till personuppgifter |
En enda väl utformad åtkomstgranskningsrapport kan stödja ISO/IEC 27001:2022, NIS2, DORA och GDPR om den innehåller omfattning, systemägare, granskare, kontolista, rollmotivering, privilegieflagga, beslut, borttagningar, undantag och slutförandedatum.
MFA-underlag är mer än en skärmbild
Ett vanligt revisionsmisstag är att presentera en skärmbild där det står ”MFA aktiverat”. Revisorer behöver mer än så. De behöver veta var MFA tillämpas, vilka som är undantagna, hur undantag godkänns, om privilegierade konton omfattas och om den tekniska konfigurationen motsvarar policyn.
Från Zenith Blueprint, fasen Kontroller i praktiken, steg 19, kommer revisorer att fråga hur lösenords- och MFA-policyer tillämpas, vilka system som skyddas, vilka MFA gäller för och om kritiska applikationer kan testas med ett exempelkonto. Underlag kan omfatta IdP-konfiguration, policyer för villkorsstyrd åtkomst, MFA-registreringsstatistik och rutiner för lösenordsåterställning.
För företagsmiljöer anger Clarysecs Policy för hantering av användarkonton och privilegier:
”Där det är tekniskt möjligt är flerfaktorsautentisering (MFA) obligatorisk för: 6.3.2.1 administrativa konton och konton på root-nivå 6.3.2.2 fjärråtkomst (VPN, molnplattformar) 6.3.2.3 åtkomst till känsliga eller reglerade data”
Från avsnittet ”Krav för genomförande av policyn”, klausul 6.3.2.
Detta skapar en direkt revisionsbrygga. Om MFA är obligatoriskt för administratörskonton, fjärråtkomst och reglerade data bör underlagspaketet omfatta listor över administrativa konton och konton på root-nivå, konfiguration för fjärråtkomst, policyer för villkorsstyrd åtkomst till molnplattformar, listor över applikationer med känsliga data, MFA-registreringsrapporter, undantagsgodkännanden, kompenserande kontroller och aktuellt underlag från larmgranskning för misslyckade inloggningsförsök eller MFA-bypassförsök.
För NIST SP 800-53 Rev. 5 ligger detta i linje med IA-2 Identification and Authentication, IA-5 Authenticator Management, AC-17 Remote Access och AU-2 Event Logging. För COBIT 2019 stödjer det DSS05.04 Manage user identity and logical access och relaterade metoder för säkerhetsövervakning.
Stödjande ISO-standarder breddar bilden. ISO/IEC 27018:2020 utökar autentiseringsförväntningarna för publika moln som hanterar personuppgifter. ISO/IEC 24760-1:2019 stödjer bindning av autentiserare och livscykelhantering. ISO/IEC 29115:2013 introducerar tillitsnivåer för autentisering, användbart vid beslut om var hårdvarutoken eller phishingresistent MFA behövs. ISO/IEC 27033-1:2015 stödjer stark nätverksautentisering för fjärråtkomst eller åtkomst mellan nätverk.
PAM-underlag är den snabbaste vägen till en större iakttagelse eller en ren revision
Privilegierad åtkomst är området där revisorer blir skeptiska eftersom privilegierade konton kan kringgå kontroller, extrahera data, skapa persistens och ändra loggar. I Zenith Blueprint, steg 19, står det:
”I alla informationssystem är privilegierad åtkomst makt, och med den makten följer risk.”
Vägledningen fokuserar på vem som har privilegierad åtkomst, vad den medger, hur den hanteras och hur den övervakas över tid. Den rekommenderar en aktuell förteckning, principen om minsta privilegium, RBAC, tidsbaserad eller just-in-time-privilegiehöjning, godkännandearbetsflöden, unika personliga konton med namngiven användare, undvikande av delade konton, break-glass-loggning, PAM-system, rotation av autentiseringsuppgifter, valvlagring, sessionsinspelning, tillfällig privilegiehöjning, övervakning och regelbunden granskning.
Clarysecs företagsversion av Åtkomstkontrollpolicy gör detta till ett kontrollkrav:
”Administrativ åtkomst ska kontrolleras strikt genom: 5.4.1.1 separata privilegierade konton 5.4.1.2 sessionsövervakning och inspelning 5.4.1.3 flerfaktorsautentisering 5.4.1.4 tidsbegränsad eller arbetsflödesutlöst privilegiehöjning”
Från avsnittet ”Styrningskrav”, klausul 5.4.1.
Citatet är nästan ett revisionsskript. Om policyn anger separata administratörskonton, visa listan över privilegierade konton och styrk att varje konto kan kopplas till en namngiven person. Om den anger sessionsövervakning, visa inspelade sessioner eller PAM-loggar. Om den anger MFA, visa tillämpning för varje väg till privilegierad åtkomst. Om den anger tidsbegränsad privilegiehöjning, visa utgångstidsstämplar och godkännandeärenden.
SME-versionen är lika direkt. Policy för hantering av användarkonton och privilegier-sme anger:
”Förhöjda eller administrativa privilegier kräver ytterligare godkännande av verkställande chef eller IT-ansvarig och ska dokumenteras, vara tidsbegränsade och omfattas av periodisk granskning.”
Från avsnittet ”Krav för genomförande av policyn”, klausul 6.2.2.
För mindre organisationer är detta ofta skillnaden mellan ”vi litar på vår administratör” och ”vi kontrollerar privilegierad risk”. Revisorn kräver inte företagsverktyg i varje SME, men kräver underlag som står i proportion till risken. Ett ärende, ett godkännande, en tillfällig grupptilldelning, MFA-krav och en granskningspost kan vara tillräckligt när omfattningen är begränsad och risken lägre.
Åtkomstgranskningar visar att principen om minsta privilegium fungerar
Åtkomstgranskningar visar om behörigheter ackumuleras i det tysta. De visar också om chefer förstår vilken åtkomst deras team faktiskt har.
Företagsversionen av Policy för hantering av användarkonton och privilegier kräver:
”Kvartalsvisa granskningar av alla användarkonton och tillhörande privilegier ska genomföras av IT-säkerhet i samarbete med avdelningschefer.”
Från avsnittet ”Krav för genomförande av policyn”, klausul 6.5.1.
För SME:er anger Policy för hantering av användarkonton och privilegier-sme en proportionerlig frekvens:
”En granskning av alla användarkonton och privilegier ska genomföras var sjätte månad.”
Från avsnittet ”Krav för genomförande av policyn”, klausul 6.4.1.
En trovärdig åtkomstgranskning omfattar systemnamn, omfattning, granskarens namn, exportdatum, granskningsdatum, identitetsägare, avdelning, chef, anställningsstatus, roll eller rättighet, privilegieflagga, flagga för datakänslighet, beslut, åtgärdsärende, stängningsdatum, undantagsägare och utgångsdatum för undantag.
För Zenith Controls är åtkomsträttigheter 5.18 platsen där detta blir underlag för flera regelverk. Vägledningen mappar åtkomsträttigheter till GDPR Article 25 eftersom åtkomst ska begränsas genom design och som standard. Den mappar till NIS2 Article 21(2)(i) eftersom åtkomstkontrollpolicyer och tillgångshantering kräver riskbaserad tilldelning, snabb borttagning av onödig åtkomst och formell återkallelse. Den mappar till DORA eftersom finansiella IKT-system behöver rollbaserad åtkomst, övervakning och återkallelseprocesser.
NIST-orienterade revisorer testar ofta detta genom AC-2 Account Management, AC-5 Separation of Duties och AC-6 Least Privilege. COBIT 2019-revisorer tittar på DSS05.04 Manage user identity and logical access och DSS06.03 Manage roles, responsibilities, access privileges and levels of authority. ISACA ITAF-revisorer fokuserar på om underlaget är tillräckligt, tillförlitligt och fullständigt.
Offboarding och återkallelse av token är lätta att stickprova
Avgångar är ett av de enklaste områdena för att visa om livscykeln fungerar. Revisorer väljer ofta en nyligen avslutad anställning och begär HR:s avslutspost, ärendet, logg över inaktivering av konto, underlag för SaaS-avaktivering, borttagning av VPN, MFA-återkallelse, borttagning av API-token och återlämning av tillgångar.
I Policy för introduktion och avslut-sme anger Clarysec:
”Avslutade konton ska låsas eller raderas, och tillhörande åtkomsttoken ska återkallas, inklusive fjärråtkomst (VPN), bindningar till MFA-appar och API-token.”
Från avsnittet ”Krav för genomförande av policyn”, klausul 6.3.3.
Detta är viktigt eftersom modern åtkomst inte bara är ett användarnamn och lösenord. Åtkomst kan bestå genom refresh tokens, API-nycklar, SSH-nycklar, OAuth-tilldelningar, tjänstekonton, lokala administratörsrättigheter, mobila sessioner och tredjepartsportaler. En avaktiverad HR-post utan återkallelse av token är ofullständigt underlag.
Zenith Blueprint, fasen Kontroller i praktiken, steg 16, instruerar organisationer att vara redo med en dokumenterad avslutningschecklista, underlag från en nylig avgång, en logg över inaktivering av användarkonto från AD eller MDM, ett undertecknat formulär för återlämning av tillgångar och offboarding-dokumentation som inkluderar sekretesskyldigheter.
Marias revisor bad om en avgången senior utvecklare som hade privilegierad åtkomst till produktionsdatabaser. Hennes team presenterade Policy för introduktion och avslut-sme, avslutningschecklistan byggd från Zenith Blueprint steg 16, det HR-utlösta ITSM-ärendet, katalogens inaktiveringslogg, återkallelsen av VPN-certifikat, borttagningen från GitHub-organisationen, raderingen av AWS IAM-nyckeln och det stängda verifieringsärendet signerat av IT-chefen. Underlaget var fullständigt, snabbt och direkt kopplat tillbaka till policyn.
Genomför en underlagssprint med tre stickprov innan revisorn gör det
En praktisk beredskapsövning är att välja tre stickprov före revisionen:
- En nyanställd som började under de senaste 90 dagarna
- En privilegierad användare med administratörsåtkomst till moln, databas, produktion eller IAM
- En avgången eller rolländrad medarbetare från de senaste 90 dagarna
| Stickprov | Underlag att samla in | Godkänt villkor | Vanlig iakttagelse |
|---|---|---|---|
| Nyanställd | HR-startpost, åtkomstbegäran, godkännande, rolltilldelning, MFA-registrering, första inloggning | Åtkomst beviljad först efter godkännande och anpassad till rollen | Åtkomst beviljad före godkännande eller för bred roll |
| Privilegierad användare | Verksamhetsmässig motivering, separat administratörskonto, MFA-bevis, PAM-godkännande, sessionslogg, kvartalsvis granskning | Privilegiet är namngivet, motiverat, tidsbegränsat där möjligt, övervakat och granskat | Delat administratörskonto, saknad MFA, inget sessionsunderlag |
| Avgång eller intern förflyttning | HR-händelse, avsluts- eller rolländringsärende, avaktiveringsloggar, borttagning av VPN, återkallelse av MFA- eller API-token, stängd granskning | Åtkomst borttagen snabbt och fullständigt | SaaS-konto fortfarande aktivt, API-token inte återkallad, gammalt gruppmedlemskap kvar |
Koppla sedan varje stickprov till ISMS-posterna: riskscenario, behandlingsbeslut, kontrollval i tillämplighetsförklaringen, policyklausul, teknisk konfiguration, granskningspost och korrigerande åtgärd om någon brist finns.
Detta gör revisionsförberedelse till kontrollverifiering i stället för dokumentsamling.
Förbered er för olika revisionsperspektiv
Olika revisionsbakgrunder leder till olika frågor, även när underlaget är detsamma.
| Revisorsperspektiv | Primärt fokus | Underlag de förväntar sig |
|---|---|---|
| ISO/IEC 27001:2022-revisor | ISMS-process, riskbehandling och kontrollfunktion | Riskbedömning, SoA, godkända policyer, åtkomstbegäran, granskningsposter, avaktiveringsloggar |
| ISO/IEC 19011:2018 revisionspraxis | Stickprov, bekräftelse från flera källor och konsekvens | Lösenordsinställningar, låsningströsklar, godkännandetidsstämplar, genomförandeposter, intervjuer |
| ISO/IEC 27007:2020 ISMS-revisor | Genomförande och effektivitet i ISMS-revision | Rolldefinitioner jämförda med faktiska behörigheter, spår för privilegierade godkännanden, återkallelseloggar |
| NIST-fokuserad bedömare | Teknisk implementation och kontrolltestning | AC-2, AC-5, AC-6, AC-17, IA-2, IA-5 och AU-2-underlag från IAM-, PAM- och SIEM-verktyg |
| COBIT 2019- eller ISACA-revisor | Styrning, ägarskap och underlagets tillförlitlighet | Processunderlag för DSS05.04 och DSS06.03, mätetal, undantag, uppföljning av åtgärder |
| DORA-granskare | IKT-risk, resiliens och kritikalitet | Åtkomstlistor för kritiska system, övervakning av privilegierad åtkomst, administratörskontroller för tredje part, länkar till resiliensprovning |
| NIS2-granskare | Ledningens ansvarsskyldighet och riskåtgärder | Styrelsetillsyn, Article 21-åtgärder för åtkomstkontroll, MFA-täckning, incidentberedskap |
| GDPR-granskare | Konfidentialitet för personuppgifter och ansvarsskyldighet | Åtkomstbegränsningar för personuppgifter, underlag för Article 25-dataskydd som standard, Article 32-säkerhetsåtgärder |
Att förbereda underlag som tillgodoser alla dessa perspektiv visar ett moget efterlevnadsprogram och minskar dubbelarbete.
Vanliga iakttagelser och förebyggande åtgärder
Iakttagelser inom åtkomstkontroll är förutsägbara. Det är även de förebyggande åtgärderna.
| Iakttagelse | Varför det spelar roll | Förebyggande åtgärd |
|---|---|---|
| Åtkomstgranskningar finns men privilegierade konton undantas | Administratörsrättigheter skapar den högsta konsekvensrisken | Inkludera privilegieflagga, PAM-poster och administratörsgrupper i varje granskning |
| MFA är aktiverat för anställda men inte för servicedesk, uppdragstagare eller molnadministratörer | Angripare riktar in sig på undantag | Upprätthåll rapport över MFA-täckning och undantagsregister med utgångsdatum |
| Processen för nyanställningar är dokumenterad men interna förflyttningar hanteras inte | Behörighetsanhopning byggs upp efter rolländringar | Utlös åtkomstgranskning vid varje avdelnings- eller rolländring |
| Delade administratörskonton finns utan kompenserande kontroller | Ansvarsskyldigheten är svag | Ersätt med namngivna administratörskonton eller kräv uttag från valv och sessionsloggning |
| Avgångna medarbetare inaktiveras i katalogen men är aktiva i SaaS-plattformar | Åtkomst kvarstår utanför den centrala IdP:n | Upprätthåll applikationsförteckning och offboarding-checklista för varje system |
| Lösenord för tjänstekonton är okända eller roteras aldrig | Icke-mänskliga identiteter blir dolda bakdörrar | Tilldela ägare, lagra hemligheter i valv, rotera autentiseringsuppgifter och granska användningsloggar |
| Policyn säger kvartalsvis granskning men underlaget visar årlig granskning | Policy och faktisk praxis skiljer sig åt | Justera frekvensen baserat på risk eller tillämpa det dokumenterade kravet |
| Åtkomstgodkännanden finns i e-post utan bevaranderegel | Revisionsspåret är sårbart | Använd ITSM-arbetsflöden och bevarande anpassat till policyn |
Företagsversionen av Åtkomstkontrollpolicy lägger till ett krav på bevarande som förebygger ett av de vanligaste underlagsfelen:
”Godkännandebeslut ska loggas och bevaras för revisionsändamål i minst 2 år.”
Från avsnittet ”Styrningskrav”, klausul 5.3.2.
Om godkännanden försvinner efter e-poststädning kan kontrollen ha fungerat, men revisionen kan inte förlita sig på den. Bevarande är en del av kontrolldesignen.
Ledningens ansvarsskyldighet kräver åtkomstmätetal
NIS2 Article 20 och DORA Articles 5 and 6 gör åtkomstkontroll till en ledningsfråga eftersom komprometterade identiteter kan leda till driftstörning, regulatorisk rapportering, personuppgiftsincident och kundskada. ISO/IEC 27001:2022 Clauses 5.1 to 5.3 kräver också att högsta ledningen anpassar ISMS till verksamhetsstrategin, tillhandahåller resurser, kommunicerar betydelsen, tilldelar ansvar och främjar ständig förbättring.
Användbara mätetal för åtkomstkontroll omfattar:
- Andel kritiska system som omfattas av SSO
- Andel privilegierade konton med MFA
- Antal stående privilegierade konton jämfört med JIT-konton
- Slutförandegrad för åtkomstgranskningar
- Antal återkallade överdrivna behörigheter
- Efterlevnad av SLA för avaktivering vid avgång
- Antal inaktiva konton
- Täckning för ägare av tjänstekonton
- Täckning för PAM-sessionsinspelning
- Antal och ålder på MFA-undantag
Dessa mätetal hjälper ledningen att godkänna riskbehandling och visa tillsyn. De gör också revisioner mer trovärdiga eftersom organisationen kan visa att åtkomstkontroll övervakas som en levande risk, inte återupptäcks inför varje revision.
Omvandla spritt underlag till revisionsförtroende
Om ISO/IEC 27001:2022-underlag för åtkomstkontroll är utspritt över HR, ITSM, IAM, PAM, molnkonsoler och kalkylblad är nästa steg inte en ny policyomskrivning. Nästa steg är underlagsarkitektur.
Börja med denna ordning:
- Definiera system, identiteter och data inom omfattningen.
- Mappa NIS2, DORA, GDPR och avtalskrav till ISMS-kontexten.
- Använd riskscenarier enligt ISO/IEC 27005:2022 för att prioritera IAM, MFA, PAM och åtkomstgranskningar.
- Uppdatera tillämplighetsförklaringen och riskbehandlingsplanen.
- Anpassa policyklausuler till faktiska IAM- och PAM-arbetsflöden.
- Genomför underlagssprinten med tre stickprov.
- Åtgärda brister innan revisorn hittar dem.
- Upprätthåll ett återanvändbart underlagspaket för certifiering, kundernas leverantörsgranskningar och regulatoriska granskningar.
Clarysec kan hjälpa er att genomföra detta med Zenith Blueprint: En revisors 30-stegs färdplan, korsmappa krav med Zenith Controls: Vägledning för efterlevnad över flera regelverk och omsätta krav i drift med rätt Clarysec-policyuppsättning, inklusive Åtkomstkontrollpolicy, Policy för hantering av användarkonton och privilegier och Policy för introduktion och avslut.
Beredskap för revision av åtkomstkontroll handlar inte om att bevisa att ni har köpt ett IAM-verktyg. Det handlar om att visa att processer för identitet, autentisering, privilegier och granskning minskar verklig verksamhetsrisk och uppfyller de standarder och regelverk som är viktiga för er organisation.
Ladda ner Clarysec-verktygspaketen, genomför underlagssprinten med tre stickprov och omvandla ert åtkomstkontrollunderlag från ett utspritt kaos till en tydlig, repeterbar och försvarbar revisionsportfölj.
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
