Styring af hemmeligheder for maskinidentiteter ved revisioner i 2026

Alarmen kl. 02:13, som ingen kunne henføre

Kl. 02:13 en tirsdag morgen lyser kanalen for sikkerhedsdrift op. En eksport fra en produktionsdatabase er startet fra en intern automatiseringskonto. Adgangsvejen er legitim. Tokenet er gyldigt. Kilde-IP-adressen tilhører en runner i cloudmiljøet, som udviklingsteamet bruger. Der er ingen synlig malware. Der foreligger ingen phishingrapport.

CISO’en stiller det første oplagte spørgsmål: “Hvem ejer denne identitet?”

Tavshed.

DevOps-lederen husker, at tokenet blev oprettet under en kundemigrering for to år siden. Platformteamet siger, at det muligvis bruges af en faktureringsintegration. Databaseadministratoren siger, at det har læseadgang, fordi fjernelse af det engang brød et natligt job. Jura spørger, om personoplysninger var involveret. Compliance spørger, om dette er en rapporteringspligtig hændelse efter NIS2, DORA eller GDPR. Revisoren beder om revisionsbevis for, at servicekonti, API-nøgler, certifikater og CI/CD-hemmeligheder er registreret i en fortegnelse, gennemgået, roteret, overvåget og tilbagekaldt.

Kl. 09:00 er udkastet til revisionskonstatering allerede ved at tage form. En hårdkodet API-nøgle, der ikke er roteret, er fundet i en glemt mikroservice. Den giver bred adgang til en produktionsdatabase med kundetransaktioner. Udvikleren, der oprettede den, fratrådte for to år siden. Systemet har ingen navngiven ejer, intet dokumenteret formål, ingen rotationsregistrering og ingen overvågningsregel.

Det er problemet med ikke-menneskelige identiteter i 2026.

De fleste organisationer har forbedret adgangsstyringen for mennesker. De har MFA, arbejdsgange for tiltrædelse, rolleændring og fratrædelse, gennemgang af privilegeret adgang og logfiler fra identitetsudbydere. Men maskinidentiteter er vokset hurtigere end styringen. Servicekonti, workload-identiteter, API-nøgler, OAuth-tokens, SSH-nøgler, certifikater, Kubernetes-hemmeligheder, SaaS-integrationstokens, konti til robotbaseret procesautomatisering og legitimationsoplysninger til CI/CD-udrulning udfører nu kritiske forretningshandlinger uden at være “brugere” i menneskelig forstand.

For SaaS-udbydere, fintechvirksomheder, udbydere af managed services, cloudoperatører og datatunge SMV’er er uadministrerede ikke-menneskelige identiteter ikke længere blot et spørgsmål om teknisk cyberhygiejne. De er en risiko for robusthed og compliance på bestyrelsesniveau. NIS2 behandler adgangsstyring, politik for aktivstyring, sikkerhed i forsyningskæden, hændelseshåndtering og cyberhygiejne som centrale foranstaltninger til styring af cybersikkerhedsrisici. DORA placerer IKT-risiko, operationel robusthed, hændelsesrapportering og IKT-tredjepartsrisiko under ledelsesorganets ansvar for finansielle enheder. GDPR kræver, at dataansvarlige og databehandlere beskytter personoplysninger og kan dokumentere ansvarlighed.

Den svære del er ikke at dokumentere, at hemmeligheder findes. Den svære del er at dokumentere, at hver ikke-menneskelig identitet har en ejer, et formål, en livscyklus, en risikovurdering, godkendt adgang, en sikker lagringsmetode, en rotationsregel, overvågningsdækning og en tilbagekaldelsesvej.

Hvorfor ikke-menneskelige identiteter blev det nye problem for privilegeret adgang

En ikke-menneskelig identitet, eller NHI, er enhver digital identitet, der bruges af software, infrastruktur eller automatiserede processer i stedet for en person. I praksis omfatter det servicekonti, der bruges af applikationer, API-nøgler, der bruges af SaaS-integrationer, OAuth- og refresh-tokens, der bruges af tredjepartsapplikationer, SSH-nøgler, der bruges til automatisering, TLS-certifikater og private nøgler, CI/CD-hemmeligheder, cloud-workload-identiteter, databaseforbindelsesstrenge, indlejrede legitimationsoplysninger, RPA-botkonti og leverandøradministrerede legitimationsoplysninger til integrationer.

Disse identiteter har ofte tre egenskaber, som gør revisorer bekymrede.

For det første er de langlivede. En menneskelig bruger kan rotere legitimationsoplysninger, skifte rolle og forlade organisationen gennem en formel fratrædelsesproces. Et API-token, der er oprettet i et releasevindue, kan forblive aktivt i årevis, fordi ingen vil risikere at bryde produktionen.

For det andet er de kraftfulde. Et udrulningstoken kan ændre infrastruktur. En cloud service principal kan oprette lagerressourcer. En databasekonto kan eksportere kunderegistre. En signeringsnøgle kan kompromittere integriteten i softwareforsyningskæden.

For det tredje er de vanskelige at henføre. Menneskelige identiteter er knyttet til HR-registreringer. Ikke-menneskelige identiteter er ofte knyttet til scripts, pipelines, leverandører, glemte projekter eller udokumenterede integrationer.

Clarysecs Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint fremhæver dette direkte i Controls in Action-fasen, trin 22:

Og glem ikke de ikke-menneskelige identiteter. Det er her, revisioner ofte afdækker stille eksponering. Bliver API-tokens sporet? Er integrationskonti knyttet til personer, eller svæver de i limbo? Hvornår blev den databaseadgangsstreng, der er indlejret i et årtier gammelt script, sidst roteret?

Identitetsstyring er ikke glamourøst, men det er strukturelt. Uden den er jeres ISMS blot en samling låste døre uden mulighed for at være sikker på, hvem der har nøglerne.

Den sidste sætning er pointen. En virksomhed kan have en velformuleret politik for adgangsstyring og stadig fejle en revision, hvis maskinidentiteter ikke styres. Et ISMS, der ikke kan forklare, hvem der ejer en hemmelighed, hvorfor den findes, og hvornår den sidst blev gennemgået, fungerer endnu ikke som et kontrolleret system.

ISO/IEC 27001:2022 gør styring af hemmeligheder til revisionsbevis

ISO/IEC 27001:2022 er effektiv, fordi standarden ikke behandler styring af hemmeligheder som en isoleret engineering-opgave. Den kræver et risikobaseret ISMS med defineret omfang, krav fra interessenter, ledelsesansvar, risikovurdering, risikobehandling, kontroludvælgelse, en Anvendelseserklæring og løbende forbedring.

For ikke-menneskelige identiteter bør organisationen ikke starte med at købe et værktøj. Den bør starte med omfang og forpligtelser.

Efter ISO/IEC 27001:2022-klausulerne 4.1 til 4.4 fastlægger organisationen interne og eksterne forhold, interessenter, retlige, regulatoriske og kontraktlige krav, grænseflader og afhængigheder. I NHI-konteksten bør ISMS-omfanget identificere cloudmiljøer, SaaS-platforme, CI/CD-systemer, produktionsapplikationer, kundeintegrationer, databehandlere, udbydere af managed services og kryptografiske tjenester, hvor maskinlegitimationsoplysninger findes.

Klausulerne 5.1 til 5.3 gør ledelsen ansvarlig for politik, ressourcer, roller og performancerapportering. Det er vigtigt, fordi afhjælpning af NHI ofte skaber driftsmæssige spændinger. Rotation af en legitimationsoplysning til en produktionsdatabase, udskiftning af en ældre delt servicekonto eller håndhævelse af vault-baseret injektion af hemmeligheder kan bryde skrøbelige arbejdsgange. Uden opbakning fra den øverste ledelse udsætter teams oprydningen.

Klausulerne 6.1.1 til 6.1.3 og 6.2 udgør kontrolmotoren. Organisationen definerer risikokriterier, identificerer risici for fortrolighed, integritet og tilgængelighed, tildeler risikoejere, vurderer sandsynlighed og konsekvens, vælger behandlingsmuligheder, udvælger kontroller, udarbejder Anvendelseserklæringen og følger målbare målsætninger.

I praksis bør en risikobehandlingsplan for ikke-menneskelige identiteter besvare:

• Hvilke systemer og forretningstjenester afhænger af NHI’er?
• Hvilke hemmeligheder kan give adgang til personoplysninger, regulerede finansielle tjenester, produktionsinfrastruktur eller kritiske kundetjenester?
• Hvilke identiteter er privilegerede, inaktive, delte, leverandøradministrerede eller uadministrerede?
• Hvilke kontroller reducerer risikoen, f.eks. vaulting, rotation, mindst mulige rettigheder, udløb, livscyklusstyring af certifikater, CI/CD-scanning, overvågning og nødtilbagekaldelse?
• Hvilke restrisici kræver forretningsmæssig godkendelse?

ISO/IEC 27002:2022 giver derefter kontrolkataloget i Annex A. De mest relevante kontroller omfatter 5.9 Fortegnelse over information og andre tilknyttede aktiver, 5.15 Adgangsstyring, 5.16 Identitetsstyring, 5.17 Autentifikationsoplysninger, 5.18 Adgangsrettigheder, 5.19 Informationssikkerhed i leverandørrelationer, 5.20 Håndtering af informationssikkerhed i leverandøraftaler, 5.21 Styring af informationssikkerhed i IKT-forsyningskæden, 5.23 Informationssikkerhed ved brug af cloudtjenester, 5.24 Planlægning og forberedelse af hændelsesstyring, 5.28 Indsamling af bevismateriale, 8.2 Privilegerede adgangsrettigheder, 8.3 Begrænsning af informationsadgang, 8.5 Sikker autentifikation, 8.15 Logning, 8.16 Overvågningsaktiviteter, 8.24 Anvendelse af kryptografi, 8.25 Sikker udviklingslivscyklus, 8.26 Krav til applikationssikkerhed, 8.28 Sikker kodning og 8.31 Adskillelse af udviklings-, test- og produktionsmiljøer.

Clarysecs Zenith Controls: The Cross-Compliance Guide Zenith Controls kortlægger disse ISO/IEC 27002:2022-sammenhænge på en måde, som revisorer og kontrolansvarlige kan bruge. For kontrol 5.16, Identitetsstyring, forklarer Zenith Controls forbindelsen mellem identitet og legitimationsoplysninger:

Identitetsstyring giver hvem, mens autentifikationsoplysninger sikrer hvordan ved at verificere, at den person, der hævder en identitet, er legitim. 5.16 styrer identitetens livscyklus, mens 5.17 sikrer, at adgangskoder, tokens, certifikater og andre legitimationsoplysninger er sikkert knyttet til disse identiteter og administreres korrekt for at understøtte stærk autentifikation.

Denne sammenhæng er afgørende for NHI’er. Et token uden en identitetsejer kan ikke revideres. En servicekonto uden gennemgang af adgangsrettigheder følger ikke princippet om mindst mulige rettigheder. Et certifikat uden livscyklusstatus er ikke kontrolleret kryptografi. En legitimationsoplysning til en leverandørintegration uden kontraktvilkår er ikke effektiv tredjepartsrisikostyring.

Clarysec-kontrolmønsteret: identitet, hemmelighed, privilegium, revisionsbevis

Clarysec implementerer styring af ikke-menneskelige identiteter og hemmeligheder gennem et gentageligt kontrolmønster. Vi behandler ikke “hemmeligheder” som kun et DevOps-anliggende eller “servicekonti” som kun et IAM-anliggende. Vi forbinder identitet, hemmelighed, privilegium og revisionsbevis.

Politiklaget er dér, dette bliver håndhævbart.

For SMV’er angiver Clarysecs User Account and Privilege Management Policy-sme User Account and Privilege Management Policy-sme:

Servicekonti, der bruges af systemer eller applikationer, skal dokumenteres, begrænses til specifikke systemer og må aldrig bruges til interaktive login.

Dette forebygger det klassiske antimønster, hvor en servicekonto bliver et delt administratorlogin. Det giver også en revisor en klar test: vis servicekontofortegnelsen, vis systembegrænsningen, og vis, at interaktivt login er deaktiveret eller teknisk forhindret.

Clarysecs Asset Management Policy-sme Asset Management Policy-sme udvider definitionen af aktiver til at omfatte:

Digitale legitimationsoplysninger og tjenester: domænenavne, digitale certifikater, API-nøgler, e-mailkonti, cloudlogin

Det er vigtigt, fordi mange organisationer kun registrerer servere, laptops og applikationer. I 2026 kan en API-nøgle være mere følsom end en laptop. En privat certifikatnøgle kan være et autentifikationsaktiv i produktionsmiljøet. Et cloudlogin, der bruges af automatisering, kan skabe eksponering af regulerede data. At behandle legitimationsoplysninger som aktiver er grundlaget for revisionsklar styring af hemmeligheder.

For enterprise-miljøer hæver Clarysecs User Account and Privilege Management Policy User Account and Privilege Management Policy kravene til revisionsbevis:

Organisationen skal vedligeholde en detaljeret fortegnelse over alle aktive og inaktive legitimationsoplysninger, privilegerede konti og servicekonti på systemniveau. Denne fortegnelse skal opdateres løbende og gennemgås kvartalsvist.

Kvartalsvis gennemgang er dér, mange huller kommer frem. Inaktive legitimationsoplysninger, forældreløse service principals, gamle integrationsbrugere, uadministrerede leverandørkonti og nødtokens bliver først synlige, når nogen sammenligner fortegnelsen med faktiske IAM-, vault-, CI/CD- og cloudregistreringer.

Hemmeligheder er autentifikationsoplysninger, ikke udviklerbekvemmelighed

Den farligste vending i styring af hemmeligheder er “midlertidig nøgle”.

Midlertidige nøgler bliver permanente. Testlegitimationsoplysninger når produktion. Kildekode afslører tokens. Build-logfiler eksponerer adgangskoder. Supportteams deler certifikater via sager. Udviklere kopierer miljøfiler ind i chat. En kontrahent opretter en cloud service principal og forlader organisationen.

Zenith Blueprint, Controls in Action-fasen, trin 22, beskriver autentifikationsoplysninger bredt:

Denne kontrol handler ikke kun om adgangskoder, selv om adgangskoder bestemt er en del af billedet. Den handler om enhver legitimationsoplysning, der bruges til at bekræfte en identitet: adgangskoder, PIN-koder, kryptografiske nøgler, biometriske skabeloner, smartcards, tokens, certifikater, OAuth-tokens, SSH-nøgler, API- hemmeligheder. Det er nøglerne til kongeriget, og kontrol 5.17 sikrer, at disse nøgler behandles med den alvor, de fortjener.

Lad os være tydelige: dårlig styring af autentifikation er fortsat en af de vigtigste rodårsager bag brud. Svage eller delte adgangskoder. Hårdkodede legitimationsoplysninger i kildekode. Uændrede standardlogin på administratorportaler. Certifikater med udløbet eller ukendt ejerskab. I alle disse tilfælde er det ikke identiteten, der fejler; det er manglen på beskyttelse og styring af den mekanisme, der bruges til at dokumentere identiteten.

Clarysec-politikker omsætter dette til driftsmæssige regler.

Cryptographic Controls Policy-sme Cryptographic Controls Policy-sme angiver:

Nøgler må ikke lagres i klartekst eller indlejres i kildekode, dokumenter eller e-mails.

Secure Development Policy-sme Secure Development Policy-sme angiver:

Ingen hårdkodede legitimationsoplysninger eller hemmeligheder i kildekode.

For enterprise-teams angiver Secure Development Policy Secure Development Policy:

Hemmeligheder må ikke være hårdkodede eller lagres i klartekst i repositories.

Og Application Security Requirements Policy Application Security Requirements Policy er endnu mere direkte:

Lagring af adgangskoder eller kryptografiske nøgler i klartekst er strengt forbudt.

Disse politikklausuler skaber et klart revisionsspor. Sikkerhedsteams kan teste repositories, CI/CD-variabler, container-images, konfigurationslagre, sagsstyringssystemer, dokumentationsplatforme og logfiler mod eksplicitte krav. De understøtter også GDPR Article 32 behandlingssikkerhed, fordi eksponering af hemmeligheder direkte kan føre til uautoriseret adgang til personoplysninger.

Enterprise-styring af kryptografi kræver også ejerskab. Clarysecs Cryptographic Controls Policy Cryptographic Controls Policy kræver:

Et centraliseret register for nøglestyring skal vedligeholdes for at registrere alle kryptografiske nøgler, deres livscyklusstatus, tildelte forvaltere og anvendelseskontekster.

For ikke-menneskelige identiteter bør dette register forbinde certifikatnøgler, signeringsnøgler, API-nøgler og kundeadministrerede nøgler i cloud med den bredere NHI-fortegnelse. Revisoren skal kunne spore et produktionscertifikat fra forretningstjeneste til ejer, til forvalter, til udløb, til rotationsbevis, til procedure for hændelseshåndtering.

NIS2, DORA og GDPR: én evidensmodel, mange regulatorer

Styring af ikke-menneskelige identiteter er et tværgående compliance-problem, fordi den samme fejl kan udløse flere forpligtelser.

Et lækket API-token hos en SaaS-udbyder kan medføre driftsafbrydelser efter NIS2, eksponering af personoplysninger efter GDPR og kontraktlig hændelsesrapportering til finansielle kunder efter DORA-forventninger til forsyningskæden. En kompromitteret CI/CD-hemmelighed hos en IKT-tjenesteudbyder kan påvirke kunders robusthed, softwareintegritet og driftskontinuitet. En glemt leverandørintegrationskonto kan skabe adgang til regulerede systemer uden korrekt due diligence eller kontraktkontroller.

NIS2 Article 21 kræver passende og forholdsmæssige tekniske, driftsmæssige og organisatoriske foranstaltninger. Minimumsområderne omfatter risikoanalyse, politikker for informationssystemers sikkerhed, hændelseshåndtering, forretningskontinuitet, sikkerhed i forsyningskæden, sikker anskaffelse, udvikling og vedligeholdelse, håndtering af sårbarheder, effektivitetsvurdering, cyberhygiejne, kryptografi, HR-sikkerhed, adgangsstyring og aktivstyring samt, hvor relevant, MFA eller løbende autentifikation. Ikke-menneskelige identiteter går på tværs af næsten alle disse områder. NIS2 Article 23 etablerer også trinvis rapportering af væsentlige hændelser, herunder tidlig advarsel inden for 24 timer, hændelsesunderretning inden for 72 timer og en endelig rapport senest én måned efter hændelsesunderretningen.

DORA finder anvendelse fra 17. januar 2025 og dækker styring af IKT-risiko, rapportering af større IKT-relaterede hændelser, test af operationel robusthed, informationsdeling og IKT-tredjepartsrisiko. Articles 5 og 6 kræver governance, ledelsesorganets ansvarlighed og et dokumenteret rammeværk for IKT-risikostyring. Article 8 kræver identifikation af IKT-understøttede forretningsfunktioner, informationsaktiver og afhængigheder. Articles 17 til 19 kræver hændelsesstyring, klassificering og rapportering. Articles 28 til 30 kræver styring af IKT-tredjepartsrisiko, kontraktregistre, due diligence, sikkerhedsstandarder, revisionsrettigheder, hændelsesstøtte, kontroller for underleverandører og exitstrategier.

GDPR gælder, hvor personoplysninger behandles inden for det territoriale anvendelsesområde. Article 5 kræver integritet, fortrolighed og ansvarlighed. Article 32 kræver passende tekniske og organisatoriske foranstaltninger for behandlingssikkerhed. Hvis en servicekonto eller API-nøgle kan få adgang til personoplysninger, bliver uadministrerede hemmeligheder et kontrolsvigt i databeskyttelsen, ikke kun et IT-forhold.

Det samme revisionsbevis kan understøtte ISO/IEC 27001:2022-certificering, NIS2-tilsyn, DORA-gennemgange og GDPR-ansvarlighed, når det struktureres korrekt.

NIST CSF 2.0 kan bruges som kommunikationslag for det samme revisionsbevis. GOVERN-funktionen dækker interessentforventninger, retlige og kontraktlige forpligtelser, risikovillighed, ledelsesansvar, politik og tilsyn. De operationelle resultater dækker aktivfortegnelser, leverandørleverede tjenester, identitets- og legitimationsstyring, mindst mulige rettigheder, datasikkerhed, logning, overvågning, hændelseshåndtering og genopretning.

COBIT 2019- og ISACA-lignende assurance-teams vil typisk se på governance og proceskapabilitet. De vil spørge, om ansvar er tildelt, om kontroller er indlejret i driftsprocesser, om undtagelser er godkendt, om metrikker rapporteres til ledelsen, og om revisionsbeviset dokumenterer gentagelighed snarere end en engangsoprydning.

Et praktisk sprint til at opbygge en fortegnelse over ikke-menneskelige identiteter

Et praktisk Clarysec-forløb starter ofte med et fokuseret sprint, ikke et seks måneders værktøjsprogram. Målet er at udarbejde en forsvarlig NHI-fortegnelse, en risikorangering og en afhjælpningsplan, der kan føde ind i ISO/IEC 27001:2022-risikobehandlingsplanen og Anvendelseserklæringen.

Start med én forretningstjeneste, f.eks. en kundefaktureringsplatform, handelsapplikation, patientportal eller et system til administration af SaaS-tenants. Medtag produktion, staging, CI/CD, cloudinfrastruktur, overvågningsværktøjer, databaser, SaaS-integrationer og leverandøradministrerede tjenester.

Knyt dette til Zenith Blueprint, Risk Management-fasen, trin 14, hvor Clarysec tilpasser behandlingspolitikker med regulatoriske krydshenvisninger. I dette trin omfatter sikker udvikling og pipeline-kontroller ingen hårdkodede hemmeligheder, peer code review, automatiseret statisk analyse, scanning af afhængigheder, adskillelse af udvikling, test og produktion, MFA for pipeline-adgang, integritet af build-artefakter og CI/CD-logning.

Indsaml identiteter og hemmeligheder fra identitetsudbyderen, cloud-IAM, secrets vault, Kubernetes, CI/CD-variabler, repositoryindstillinger, databasebrugere, SaaS-administrationskonsoller, værktøjer til certifikatstyring og leverandørdokumentation.

Risikovurdér identiteter, der har adgang til produktionsmiljøer, privilegerede rettigheder, adgang til personoplysninger, afhængighed af kritiske eller vigtige funktioner, leverandørkontrol, langlivede tokens, ingen ejer, ingen rotation, ingen overvågning eller hårdkodet lagring. Brug ISO/IEC 27001:2022-risikokriterier til at score sandsynlighed og konsekvens. Brug DORA-analyse af kritiske eller vigtige funktioner, hvor det er relevant. Brug GDPR-konsekvensovervejelser, hvor personoplysninger er tilgængelige. Brug NIS2-tjenestepåvirkning, hvor afbrydelse eller kundeskade er plausibel.

For hver højrisiko-NHI skal der gennemføres behandlingshandlinger. Flyt hemmeligheder fra kildekode, dokumenter og CI/CD-klartekstvariabler til en vault eller et administreret secret store. Erstat delte servicekonti med unikke workload-identiteter. Deaktiver interaktivt login for servicekonti. Anvend mindst mulige rettigheder og miljøspecifikke legitimationsoplysninger. Konfigurer rotation, udløb og nødtilbagekaldelse. Knyt hemmeligheder til ejere og forvaltere. Tilføj logning for autentifikation, tokenbrug og følsomme handlinger. Tilføj alarmering for anomale geografiske placeringer, usædvanlige tidspunkter, usædvanlige volumener eller adgang til nye ressourcer. Opdater leverandørkontrakter for håndtering af legitimationsoplysninger, hændelsesstøtte og revisionsrettigheder. Dokumentér undtagelser med godkendelse fra risikoejer og udløbsdato.

Test Data and Test Environment Policy Test Data and Test Environment Policy understøtter miljøadskillelse:

Integration med CI/CD-pipelines skal håndhæve adskillelse af miljøer og autentifikationsoplysninger.

Denne klausul er ofte afgørende. Hvis udvikling, test og produktion deler hemmeligheder, kan et lavrisikomiljø blive en vej til brud i produktionen.

Sprintet bør afsluttes med en evidenspakke, ikke kun en liste over konstateringer. Medtag eksport af NHI-fortegnelse, risikovurderingsposter, behandlingsplan, kortlægning til Anvendelseserklæring, politikreferencer, vault-skærmbilleder, rotationslogfiler, godkendelser af gennemgang af adgangsrettigheder, resultater fra CI/CD-scanning for hemmeligheder, definitioner af overvågningsregler, ansvarsmatrix for leverandørlegitimationsoplysninger, hændelsesrunbook og undtagelser med ejere og udløbsdatoer.

Logning og detektion: dokumentation for, at brug af maskinidentiteter er synlig

En maskinidentitet, der er godt registreret i en fortegnelse, men usynlig i logfiler, er fortsat farlig. Detektion er en del af kontrolhistorien.

Clarysecs Logging and Monitoring Policy-sme Logging and Monitoring Policy-sme omfatter autentifikationsbevis:

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

For NHI’er skal dette krav tilpasses maskinautentifikation. Du har måske ikke MFA-brug for en workload-identitet, men du bør have autentifikationshændelser, tokenbrug, certifikatbrug, API-kaldsmetadata, kilde-workload, destinationstjeneste, tokenlevetid, fejlhændelser og privilegerede handlinger.

I Zenith Controls er ISO/IEC 27002:2022-kontrol 8.2, Privilegerede adgangsrettigheder, knyttet til logning og overvågning, fordi privilegerede konti kræver detaljerede registreringer og tilsyn. Zenith Controls knytter også 8.2 til identitetsstyring, adgangsrettigheder, begrænsning af informationsadgang og sikker autentifikation. For revisorer betyder det, at privilegerede ikke-menneskelige identiteter bør gennemgås og overvåges med samme alvor som menneskelige administratorer, nogle gange større.

Gode overvågningsspørgsmål omfatter:

• Autentificerede en servicekonto sig fra en uventet workload eller et uventet IP-interval?
• Fik en API-nøgle adgang til et nyt endpoint eller datasæt?
• Blev et certifikat brugt efter udskiftning?
• Udrullede et CI/CD-token uden for en godkendt pipeline?
• Forsøgte en skrivebeskyttet konto at udføre skrivehandlinger?
• Blev en inaktiv legitimationsoplysning aktiv?
• Fik en leverandørintegration adgang til data uden for aftalte tidspunkter eller volumener?

Når alarmen kl. 02:13 opstår, skal I kunne svare på, hvilken identitet der blev brugt, hvilken hemmelighed der autentificerede den, hvilke adgangsrettigheder der blev udøvet, hvilke data eller systemer der blev påvirket, om aktiviteten var forventet, hvilken ejer der kan validere den, og om tærsklerne for hændelsesrapportering er opfyldt.

Revisorens perspektiv: samme proces, forskellige spørgsmål

Den stærkeste revisionsposition er ikke “vi overholder alt”. Det er “vi driver én kontrolleret proces, der producerer revisionsbevis til flere forpligtelser”. Forskellige revisorer vil inspicere processen forskelligt.

På tværs af disse perspektiver er de tilbagevendende konstateringer forudsigelige: ingen samlet NHI-fortegnelse, ingen ejer af maskinidentiteter, hemmeligheder lagret i kode eller dokumentation, delte legitimationsoplysninger på tværs af miljøer, ingen rotation eller udløb, leverandøradministrerede legitimationsoplysninger uden for gennemgang af adgangsrettigheder, overvågning der dækker mennesker, men ikke maskiner, og hændelsesrunbooks, der ignorerer lækage af hemmeligheder.

Hver konstatering kan naturligt kortlægges til Clarysec-kontroller, politikker og afhjælpningsskabeloner. Endnu vigtigere kan hver af dem omsættes til målbart revisionsbevis i ISMS’et.

Sådan hjælper Clarysec jer med at blive revisionsklar

Clarysecs tilgang er praktisk, fordi den starter med det revisionsbevis, revisorer vil anmode om, og arbejder baglæns til kontroller, politikker og driftsrutiner.

I Zenith Blueprint, Controls in Action-fasen, trin 19, giver Clarysec direkte vejledning til maskine-til-maskine-autentifikation:

Ved maskine-til-maskine-autentifikation, f.eks. servicekonti eller API-kald, skal nøgler, certifikater og tokens beskyttes lige så strengt. Undgå at indlejre legitimationsoplysninger i kode. Brug systemer til styring af hemmeligheder eller vaults til at lagre og rotere dem sikkert.

Et typisk Clarysec-arbejdsspor for ikke-menneskelige identiteter omfatter NHI-discovery på tværs af cloud, SaaS, CI/CD, repositories, vaults og databaser, vurdering af politikhuller mod Clarysecs SMV- eller enterprise-politiksæt, ISO/IEC 27001:2022-risikovurdering og behandlingskortlægning, opdateringer af Anvendelseserklæring, kortlægning af revisionsbevis til NIS2, DORA, GDPR og NIST CSF, design af NHI-fortegnelse, tilpasning til register for nøglestyring, scanning for hemmeligheder, processer for gennemgang af adgangsrettigheder, ansvarsmatricer for leverandørlegitimationsoplysninger, hændelsesrunbooks og revisionspakker med skærmbilleder, eksporter, logfiler, godkendelser og undtagelsesregistreringer.

For SMV’er er tilgangen forholdsmæssig. En SaaS-udbyder med 70 personer har ikke brug for samme værktøjsomfang som en global bank, men den har brug for ejerskab, politik, risikobehandling og revisionsbevis. For regulerede finansielle enheder og IKT-udbydere skalerer den samme model til DORA-kortlægning af kritiske funktioner, styring af tredjepartsrisiko og robusthedstest.

Hvis jeres næste revision er i 2026, skal I ikke vente på, at revisoren opdager de ikke-menneskelige identiteter for jer. Start med én kritisk tjeneste, og stil fem spørgsmål:

1. Kender vi hver servicekonto, API-nøgle, token, certifikat og CI/CD-hemmelighed, der bruges af denne tjeneste?
2. Har hver NHI en navngiven ejer, forvalter, formål og risikovurdering?
3. Er hemmeligheder lagt i vault, roteret og beskyttet mod kildekode, dokumenter, e-mails og klartekstlagring?
4. Er privilegerede maskinidentiteter gennemgået, overvåget og begrænset mod interaktiv brug?
5. Kan vi producere revisionsbevis for ISO/IEC 27001:2022, NIS2, DORA og GDPR fra én kontrolleret proces?

Brug Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint til at strukturere jeres ISMS-implementeringsrejse. Brug Zenith Controls: The Cross-Compliance Guide Zenith Controls til at forbinde ISO/IEC 27002:2022-identitet, autentifikation, privilegier, logning, kryptografi, sikker udvikling og leverandørkontroller med regulatorisk revisionsbevis. Brug Clarysecs SMV- og enterprise-politikbibliotek, herunder User Account and Privilege Management Policy-sme User Account and Privilege Management Policy-sme, Cryptographic Controls Policy Cryptographic Controls Policy, Secure Development Policy Secure Development Policy og Application Security Requirements Policy Application Security Requirements Policy, til at omsætte gode intentioner til håndhævelige krav.

Alarmen kl. 02:13 vil opstå et sted. Spørgsmålet er, om jeres organisation med revisionsbevis kan svare på, hvem der havde nøglen, hvad den åbnede, hvorfor den fandtes, og hvor hurtigt I kan gøre den sikker.