Hantering av hemligheter för icke-mänskliga identiteter inför revisioner 2026

Larmet 02:13 som ingen kunde koppla till en ägare

Klockan 02:13 en tisdagsmorgon aktiveras kanalen för säkerhetsövervakning. En export från en produktionsdatabas har startats från ett internt automatiseringskonto. Åtkomstvägen är legitim. Token är giltig. Käll-IP-adressen tillhör en molnbaserad CI-runner som används av utvecklingsteamet. Ingen skadlig kod syns. Ingen phishingrapport finns.

Informationssäkerhetschefen ställer den första självklara frågan: ”Vem äger den här identiteten?”

Tystnad.

DevOps-ansvarig minns att token skapades vid en kundmigrering för två år sedan. Plattformsteamet säger att den kan användas av en faktureringsintegration. Databasadministratören säger att den har läsbehörighet eftersom borttagning av den en gång bröt ett nattligt jobb. Juridik frågar om personuppgifter berördes. Funktionen för regelefterlevnad frågar om detta är en rapporteringspliktig incident enligt NIS2, DORA eller GDPR. Revisorn begär underlag som visar att tjänstekonton, API-nycklar, certifikat och CI/CD-hemligheter är inventerade, granskade, roterade, övervakade och återkallade.

Vid 09:00 har utkastet till revisionsiakttagelse redan börjat ta form. En hårdkodad API-nyckel som inte har roterats har upptäckts i en bortglömd mikrotjänst. Den ger bred åtkomst till en produktionsdatabas med kundtransaktioner. Utvecklaren som skapade den slutade för två år sedan. Systemet har ingen namngiven ägare, inget dokumenterat syfte, ingen rotationshistorik och ingen övervakningsregel.

Detta är problemet med icke-mänskliga identiteter 2026.

De flesta organisationer har förbättrat åtkomstkontrollen för människor. De har flerfaktorsautentisering (MFA), arbetsflöden för nyanställningar, interna förflyttningar och avslut, granskningar av privilegierad åtkomst och loggar från identitetsleverantörer. Men maskinidentiteter har ökat snabbare än styrningen. Tjänstekonton, arbetslastidentiteter, API-nycklar, OAuth-token, SSH-nycklar, certifikat, Kubernetes-hemligheter, SaaS-integrationstoken, konton för robotiserad processautomatisering och CI/CD-uppgifter för driftsättning utför nu kritiska verksamhetsåtgärder utan att vara ”användare” i mänsklig mening.

För SaaS-leverantörer, fintechbolag, leverantörer av managed services, molnoperatörer och datatunga små och medelstora företag är ostyrda icke-mänskliga identiteter inte längre en fråga om teknisk hygien. De är en resiliens- och efterlevnadsrisk på styrelsenivå. NIS2 behandlar åtkomstkontroll, policy för tillgångshantering, säkerhet i leveranskedjan, incidenthantering och cyberhygien som centrala åtgärder för hantering av cybersäkerhetsrisker. DORA lägger IKT-risk, operativ resiliens, incidentrapportering och IKT-tredjepartsrisk under ledningsorganets ansvar för finansiella entiteter. GDPR kräver att personuppgiftsansvariga och personuppgiftsbiträden skyddar personuppgifter och kan visa ansvarsskyldighet.

Det svåra är inte att bevisa att hemligheter finns. Det svåra är att bevisa att varje icke-mänsklig identitet har en ägare, ett syfte, en livscykel, en riskklassificering, godkänd åtkomst, en säker lagringsmetod, en rotationsregel, övervakningstäckning och en process för återkallelse.

Varför icke-mänskliga identiteter blev det nya problemet för privilegierad åtkomst

En icke-mänsklig identitet, eller NHI, är en digital identitet som används av programvara, infrastruktur eller automatiserade processer i stället för av en person. I praktiken omfattar det tjänstekonton som används av applikationer, API-nycklar som används av SaaS-integrationer, OAuth- och refresh-token som används av tredjepartsapplikationer, SSH-nycklar som används av automatisering, TLS-certifikat och privata nycklar, CI/CD-hemligheter, molnbaserade arbetslastidentiteter, databasanslutningssträngar, inbäddade autentiseringsuppgifter, RPA-botkonton och leverantörshanterade integrationsuppgifter.

Dessa identiteter har ofta tre egenskaper som gör revisorer bekymrade.

För det första är de långlivade. En mänsklig användare kan rotera autentiseringsuppgifter, byta roll och avslutas genom en formell avvecklingsprocess. En API-token som skapades under ett driftsättningsfönster kan förbli aktiv i flera år eftersom ingen vill riskera att störa produktionen.

För det andra är de kraftfulla. En driftsättningstoken kan ändra infrastruktur. En tjänstprincipal i molnet kan skapa lagring. Ett databaskonto kan exportera kundregister. En signeringsnyckel kan äventyra integriteten i programvaruleveranskedjan.

För det tredje är de svåra att knyta till en ansvarig part. Mänskliga identiteter är kopplade till HR-poster. Icke-mänskliga identiteter är ofta kopplade till skript, pipelines, leverantörer, bortglömda projekt eller odokumenterade integrationer.

Clarysecs Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint lyfter detta direkt i fasen Controls in Action, steg 22:

Och glöm inte de icke-mänskliga identiteterna. Det är här revisioner ofta upptäcker tyst exponering. Spåras API-token? Är integrationskonton knutna till personer, eller svävar de fritt utan ägare? När roterades senast den databasåtkomststräng som ligger inbäddad i ett flera decennier gammalt skript?

Identitetshantering är inte glamoröst, men det är strukturellt. Utan det är ert ISMS bara en samling låsta dörrar, utan möjlighet att vara säker på vem som håller i nycklarna.

Den sista meningen är kärnan. Ett företag kan ha en välskriven åtkomstkontrollpolicy och ändå underkännas vid revision om maskinidentiteter är ostyrda. Ett ISMS som inte kan förklara vem som äger en hemlighet, varför den finns och när den senast granskades fungerar ännu inte som ett kontrollerat system.

ISO/IEC 27001:2022 gör hantering av hemligheter till revisionsunderlag

ISO/IEC 27001:2022 är effektiv eftersom den inte behandlar hantering av hemligheter som en isolerad ingenjörsuppgift. Den kräver ett riskbaserat ISMS med definierad omfattning, krav från intressenter, ledningens ansvarsskyldighet, riskbedömning, riskbehandling, val av kontroller, tillämpbarhetsförklaring och ständig förbättring.

För icke-mänskliga identiteter ska organisationen inte börja med att köpa ett verktyg. Den ska börja med omfattning och skyldigheter.

Enligt ISO/IEC 27001:2022 klausuler 4.1 till 4.4 fastställer organisationen interna och externa frågor, intressenter, rättsliga, regulatoriska och avtalsmässiga krav, gränssnitt och beroenden. I NHI-sammanhang bör ISMS-omfattningen identifiera molnmiljöer, SaaS-plattformar, CI/CD-system, produktionsapplikationer, kundintegrationer, biträden som behandlar data, leverantörer av managed services och kryptografiska tjänster där maskinautentiseringsuppgifter finns.

Klausuler 5.1 till 5.3 gör ledningen ansvarig för policy, resurser, roller och resultatrapportering. Detta är viktigt eftersom åtgärdande av NHI ofta skapar operativ friktion. Rotation av en uppgift till en produktionsdatabas, ersättning av ett äldre delat tjänstekonto eller krav på valvbaserad injicering av hemligheter kan bryta sköra arbetsflöden. Utan sponsring från verkställande ledning skjuter team upp saneringen.

Klausuler 6.1.1 till 6.1.3 och 6.2 utgör kontrollmotorn. Organisationen definierar riskkriterier, identifierar risker för konfidentialitet, riktighet och tillgänglighet, utser riskägare, bedömer sannolikhet och konsekvens, väljer behandlingsalternativ, väljer kontroller, tar fram tillämpbarhetsförklaringen och följer upp mätbara mål.

I praktiken bör en riskbehandlingsplan för icke-mänskliga identiteter besvara:

• Vilka system och verksamhetstjänster är beroende av NHI:er?
• Vilka hemligheter kan ge åtkomst till personuppgifter, reglerade finansiella tjänster, produktionsinfrastruktur eller kritiska kundtjänster?
• Vilka identiteter är privilegierade, inaktiva, delade, leverantörshanterade eller ostyrda?
• Vilka kontroller minskar risken, till exempel valvlagring, rotation, principen om minsta privilegium, utgångstid, certifikathantering, CI/CD-skanning, övervakning och akut återkallelse?
• Vilka kvarstående risker kräver verksamhetens godkännande?

ISO/IEC 27002:2022 tillhandahåller därefter kontrollkatalogen i bilaga A. De mest relevanta kontrollerna omfattar 5.9 Förteckning över information och andra tillhörande tillgångar, 5.15 Åtkomstkontroll, 5.16 Identitetshantering, 5.17 Autentiseringsinformation, 5.18 Åtkomsträttigheter, 5.19 Informationssäkerhet i leverantörsrelationer, 5.20 Hantering av informationssäkerhet i leverantörsavtal, 5.21 Hantering av informationssäkerhet i IKT-leveranskedjan, 5.23 Informationssäkerhet vid användning av molntjänster, 5.24 Planering och förberedelse för incidenthantering, 5.28 Insamling av bevis, 8.2 Privilegierade åtkomsträttigheter, 8.3 Begränsning av informationsåtkomst, 8.5 Säker autentisering, 8.15 Loggning, 8.16 Övervakningsaktiviteter, 8.24 Användning av kryptografi, 8.25 Säker utvecklingslivscykel, 8.26 Säkerhetskrav för applikationer, 8.28 Säker kodning och 8.31 Separation av utvecklings-, test- och produktionsmiljöer.

Clarysecs Zenith Controls: The Cross-Compliance Guide Zenith Controls mappar dessa ISO/IEC 27002:2022-relationer på ett sätt som revisorer och kontrollägare kan använda. För kontroll 5.16, Identitetshantering, förklarar Zenith Controls kopplingen mellan identitet och autentiseringsuppgifter:

Identitetshantering anger vem, medan autentiseringsinformation säkerställer hur det verifieras att den person som gör anspråk på en identitet är legitim. 5.16 styr identitetslivscykeln, medan 5.17 säkerställer att lösenord, token, certifikat och andra autentiseringsuppgifter är säkert knutna till dessa identiteter och hanteras korrekt för att stödja stark autentisering.

Den relationen är avgörande för NHI:er. En token utan identitetsägare går inte att granska. Ett tjänstekonto utan åtkomstgranskning följer inte principen om minsta privilegium. Ett certifikat utan livscykelstatus är inte kontrollerad kryptografi. En leverantörsintegrationsuppgift utan avtalsvillkor är inte effektiv tredjepartsriskhantering.

Clarysecs kontrollmönster: identitet, hemlighet, privilegium, underlag

Clarysec inför hantering av icke-mänskliga identiteter och hemligheter genom ett upprepbart kontrollmönster. Vi behandlar inte ”hemligheter” som endast en DevOps-fråga eller ”tjänstekonton” som endast en IAM-fråga. Vi kopplar samman identitet, hemlighet, privilegium och underlag.

Policylagret är där detta blir bindande.

För små och medelstora företag anger Clarysecs User Account and Privilege Management Policy-sme User Account and Privilege Management Policy-sme:

Tjänstekonton (som används av system eller applikationer) ska dokumenteras, begränsas till specifika system och aldrig användas för interaktiva inloggningar.

Detta förhindrar det klassiska antimönstret där ett tjänstekonto blir en delad administratörsinloggning. Det ger också revisorn ett tydligt test: visa förteckningen över tjänstekonton, visa systembegränsningen och visa att interaktiv inloggning är inaktiverad eller tekniskt förhindrad.

Clarysecs Asset Management Policy-sme Asset Management Policy-sme utökar definitionen av tillgångar till att omfatta:

Digitala autentiseringsuppgifter och tjänster: domännamn, digitala certifikat, API-nycklar, e-postkonton, molninloggningar

Detta är viktigt eftersom många organisationer bara inventerar servrar, bärbara datorer och applikationer. År 2026 kan en API-nyckel vara känsligare än en bärbar dator. En privat certifikatnyckel kan vara en produktionskritisk autentiseringstillgång. En molninloggning som används av automatisering kan skapa exponering av reglerade data. Att behandla autentiseringsuppgifter som tillgångar är grunden för revisionsklar hantering av hemligheter.

För företagsmiljöer höjer Clarysecs User Account and Privilege Management Policy User Account and Privilege Management Policy kraven på underlag:

Organisationen ska upprätthålla en detaljerad förteckning över alla aktiva och inaktiva autentiseringsuppgifter, privilegierade konton och tjänstekonton på systemnivå. Förteckningen ska uppdateras fortlöpande och granskas kvartalsvis.

Kvartalsvis granskning är där många luckor blir synliga. Inaktiva inloggningsuppgifter, föräldralösa tjänstprincipaler, gamla integrationsanvändare, ostyrda leverantörskonton och nödtoken blir synliga först när någon jämför registret med faktiska poster i IAM, valv, CI/CD och molnmiljöer.

Hemligheter är autentiseringsinformation, inte utvecklarbekvämlighet

Den farligaste frasen inom hantering av hemligheter är ”tillfällig nyckel”.

Tillfälliga nycklar blir permanenta. Testuppgifter når produktion. Källkod avslöjar token. Byggloggar exponerar lösenord. Supportteam delar certifikat via ärenden. Utvecklare kopierar miljöfiler till chatt. En konsult skapar en tjänstprincipal i molnet och slutar.

Zenith Blueprint, fasen Controls in Action, steg 22, beskriver autentiseringsinformation brett:

Den här kontrollen handlar inte bara om lösenord, även om lösenord absolut är en del av bilden. Den handlar om varje autentiseringsuppgift som används för att hävda identitet: lösenord, PIN-koder, kryptografiska nycklar, biometriska mallar, smarta kort, token, certifikat, OAuth-token, SSH-nycklar, API- hemligheter. Detta är nycklarna till kungariket, och kontroll 5.17 säkerställer att dessa nycklar behandlas med det allvar de förtjänar.

Låt oss vara tydliga: bristfällig autentiseringshantering är fortfarande en av de främsta rotorsakerna bakom intrång. Svaga eller delade lösenord. Hårdkodade autentiseringsuppgifter i källkod. Oförändrade standardinloggningar på administrationsportaler. Certifikat med utgånget eller okänt ägarskap. I vart och ett av dessa fall var det inte identiteten som brast, utan bristen i att skydda och styra den mekanism som används för att bevisa identiteten.

Clarysecs policyer översätter detta till operativa regler.

Cryptographic Controls Policy-sme Cryptographic Controls Policy-sme anger:

Nycklar får inte lagras i klartext eller bäddas in i källkod, dokument eller e-post

Secure Development Policy-sme Secure Development Policy-sme anger:

Inga hårdkodade autentiseringsuppgifter eller hemligheter i källkod

För företagsteam anger Secure Development Policy Secure Development Policy:

Hemligheter får inte hårdkodas eller lagras i klartext i kodarkiv.

Och Application Security Requirements Policy Application Security Requirements Policy är ännu tydligare:

Lagring av lösenord eller kryptografiska nycklar i klartext är strikt förbjuden.

Dessa policyklausuler skapar ett tydligt revisionsspår. Säkerhetsteam kan testa kodarkiv, CI/CD-variabler, containeravbildningar, konfigurationslager, ärendehanteringssystem, dokumentationsplattformar och loggar mot uttryckliga krav. De stödjer också GDPR Article 32 om säkerhet i behandlingen, eftersom exponering av hemligheter direkt kan leda till obehörig åtkomst till personuppgifter.

Kryptografisk styrning i företagsmiljöer kräver också ägarskap. Clarysecs Cryptographic Controls Policy Cryptographic Controls Policy kräver:

Ett centraliserat Key Management Register ska upprätthållas för att registrera alla kryptografiska nycklar, deras livscykelstatus, tilldelade förvaltare och användningssammanhang.

För icke-mänskliga identiteter bör detta register koppla certifikatnycklar, signeringsnycklar, API-nycklar och molnhanterade nycklar till det bredare NHI-registret. Revisorn ska kunna spåra ett produktionscertifikat från verksamhetstjänst, till ägare, till förvaltare, till utgångsdatum, till rotationsunderlag, till incidenthanteringsrutin.

NIS2, DORA och GDPR: en underlagsmodell, många tillsynskrav

Styrning av icke-mänskliga identiteter är en fråga om tvärgående regelefterlevnad eftersom samma brist kan utlösa flera skyldigheter.

En läckt API-token hos en SaaS-leverantör kan orsaka tjänstestörning enligt NIS2, exponering av personuppgifter enligt GDPR och avtalsbaserad incidentrapportering till finansiella kunder enligt DORA:s förväntningar på leveranskedjan. En komprometterad CI/CD-hemlighet hos en IKT-tjänsteleverantör kan påverka kundresiliens, programvaruintegritet och verksamhetskontinuitet. Ett bortglömt leverantörsintegrationskonto kan skapa åtkomst till reglerade system utan korrekt leverantörsgranskning eller avtalskontroller.

NIS2 Article 21 kräver lämpliga och proportionerliga tekniska, operativa och organisatoriska åtgärder. Minimiområdena omfattar riskanalys, säkerhetspolicyer för informationssystem, incidenthantering, verksamhetskontinuitet, säkerhet i leveranskedjan, säker anskaffning, utveckling och underhåll, sårbarhetshantering, effektivitetsbedömning, cyberhygien, kryptografi, HR-säkerhet, åtkomstkontroll och policy för tillgångshantering samt, där så är lämpligt, MFA eller kontinuerlig autentisering. Icke-mänskliga identiteter spänner över nästan alla dessa områden. NIS2 Article 23 skapar också stegvis rapportering av betydande incidenter, inklusive tidig varning inom 24 timmar, incidentanmälan inom 72 timmar och en slutrapport senast en månad efter incidentanmälan.

DORA gäller från den 17 januari 2025 och omfattar IKT-riskhantering, rapportering av större IKT-relaterade incidenter, testning av operativ resiliens, informationsdelning och IKT-tredjepartsrisk. Articles 5 och 6 kräver styrning, ledningsorganets ansvarsskyldighet och ett dokumenterat ramverk för IKT-riskhantering. Article 8 kräver identifiering av IKT-stödda verksamhetsfunktioner, informationstillgångar och beroenden. Articles 17 till 19 kräver incidenthantering, klassificering och rapportering. Articles 28 till 30 kräver IKT-tredjepartsriskhantering, avtalsregister, leverantörsgranskning, säkerhetsstandarder, revisionsrätt, incidentstöd, kontroller för underleverantörer och exitstrategier.

GDPR gäller där personuppgifter behandlas inom dess territoriella tillämpningsområde. Article 5 kräver korrekthet, konfidentialitet och ansvarsskyldighet. Article 32 kräver lämpliga tekniska och organisatoriska åtgärder för säkerhet i behandlingen. Om ett tjänstekonto eller en API-nyckel kan ge åtkomst till personuppgifter blir ostyrda hemligheter ett fel i dataskyddskontroller, inte bara en IT-fråga.

Samma underlag kan stödja ISO/IEC 27001:2022-certifiering, NIS2-tillsyn, DORA-granskningar och ansvarsskyldighet enligt GDPR när det struktureras korrekt.

NIST CSF 2.0 kan användas som kommunikationslager för samma underlag. Funktionen GOVERN omfattar intressentförväntningar, rättsliga och avtalsmässiga skyldigheter, riskaptit, ledningens ansvarsskyldighet, policy och tillsyn. De operativa resultaten omfattar tillgångsförteckningar, leverantörstillhandahållna tjänster, hantering av identiteter och autentiseringsuppgifter, principen om minsta privilegium, datasäkerhet, loggning, övervakning, incidentrespons och återställning.

COBIT 2019 och ISACA-liknande assurance-team tittar vanligtvis på styrning och processförmåga. De kommer att fråga om ansvar är tilldelat, om kontroller är inbyggda i operativa processer, om undantag är godkända, om mätetal rapporteras till ledningen och om underlaget visar upprepbarhet snarare än en engångssanering.

En praktisk sprint för att bygga ett register över icke-mänskliga identiteter

Ett praktiskt Clarysec-uppdrag börjar ofta med en fokuserad sprint, inte ett sex månader långt verktygsprogram. Målet är att ta fram ett försvarbart NHI-register, en riskrangordning och en åtgärdsplan som kan matas in i riskbehandlingsplanen enligt ISO/IEC 27001:2022 och tillämpbarhetsförklaringen.

Börja med en verksamhetstjänst, till exempel en plattform för kundfakturering, en handelsapplikation, en patientportal eller ett system för hantering av SaaS-kunder. Inkludera produktion, staging, CI/CD, molninfrastruktur, övervakningsverktyg, databaser, SaaS-integrationer och leverantörshanterade tjänster.

Koppla detta till Zenith Blueprint, fasen Risk Management, steg 14, där Clarysec anpassar riskbehandlingspolicyer till regulatoriska korsreferenser. I det steget omfattar säker utveckling och pipeline-kontroller inga hårdkodade hemligheter, kollegial granskning, automatiserad statisk analys, beroendeskanning, separation av utveckling, testning och produktion, MFA för pipeline-åtkomst, integritet för byggartefakter och CI/CD-loggning.

Samla identiteter och hemligheter från identitetsleverantören, moln-IAM, hemlighetsvalv, Kubernetes, CI/CD-variabler, inställningar för kodarkiv, databasanvändare, SaaS-administrationskonsoler, verktyg för certifikathantering och leverantörsdokumentation.

Riskklassificera identiteter som har produktionsåtkomst, privilegierade rättigheter, åtkomst till personuppgifter, beroende av kritiska eller viktiga funktioner, leverantörskontroll, långlivade token, ingen ägare, ingen rotation, ingen övervakning eller hårdkodad lagring. Använd riskkriterier enligt ISO/IEC 27001:2022 för att poängsätta sannolikhet och konsekvens. Använd DORA-analys av kritiska eller viktiga funktioner där det är tillämpligt. Använd GDPR-konsekvensbedömningar där personuppgifter är åtkomliga. Använd NIS2-tjänstepåverkan där störning eller kundskada är rimlig.

För varje högrisk-NHI ska riskbehandlingsåtgärder tillämpas. Flytta hemligheter från källkod, dokument och CI/CD-variabler i klartext till ett valv eller en hanterad hemlighetslösning. Ersätt delade tjänstekonton med unika arbetslastidentiteter. Inaktivera interaktiv inloggning för tjänstekonton. Tillämpa principen om minsta privilegium och miljöspecifika autentiseringsuppgifter. Konfigurera rotation, utgångstid och akut återkallelse. Knyt hemligheter till ägare och förvaltare. Lägg till loggning för autentisering, tokenanvändning och känsliga åtgärder. Lägg till larmning för avvikande geografi, ovanlig tidpunkt, ovanlig volym eller åtkomst till nya resurser. Uppdatera leverantörsavtal för hantering av autentiseringsuppgifter, incidentstöd och revisionsrätt. Dokumentera undantag med riskägarens godkännande och utgångsdatum.

Test Data and Test Environment Policy Test Data and Test Environment Policy stödjer separation av miljöer:

Integration med CI/CD-pipelines ska kräva separation av miljöer och autentiseringsuppgifter.

Den klausulen är ofta avgörande. Om utveckling, test och produktion delar hemligheter kan en lågriskmiljö bli en väg till intrång i produktion.

Sprinten bör avslutas med ett underlagspaket, inte bara en lista över iakttagelser. Inkludera export av NHI-registret, riskbedömningsposter, riskbehandlingsplan, mappning mot tillämpbarhetsförklaringen, policyreferenser, skärmbilder från valv, rotationsloggar, godkännanden från åtkomstgranskningar, resultat från CI/CD-skanning av hemligheter, definitioner av övervakningsregler, ansvarsmatris för leverantörsuppgifter, incidentåterställningsanvisning och undantag med ägare och utgångsdatum.

Loggning och detektering: att bevisa att användning av maskinidentiteter är synlig

En maskinidentitet som är väl inventerad men osynlig i loggar är fortfarande farlig. Detektering är en del av kontrollberättelsen.

Clarysecs Logging and Monitoring Policy-sme Logging and Monitoring Policy-sme inkluderar autentiseringsunderlag:

Autentiseringsloggar: lyckade och misslyckade inloggningsförsök, sessionslängd, MFA-användning

För NHI:er ska detta krav anpassas till maskinautentisering. Du kanske inte har MFA-användning för en arbetslastidentitet, men du bör ha autentiseringshändelser, tokenanvändning, certifikatanvändning, metadata för API-anrop, källarbetslast, destinationstjänst, tokenlivslängd, felhändelser och privilegierade åtgärder.

I Zenith Controls är ISO/IEC 27002:2022-kontroll 8.2, Privilegierade åtkomsträttigheter, kopplad till loggning och övervakning eftersom privilegierade konton kräver detaljerade poster och tillsyn. Zenith Controls kopplar också 8.2 till identitetshantering, åtkomsträttigheter, begränsning av informationsåtkomst och säker autentisering. För revisorer innebär detta att privilegierade icke-mänskliga identiteter ska granskas och övervakas med samma allvar som mänskliga administratörer, ibland mer.

Bra övervakningsfrågor omfattar:

• Autentiserade ett tjänstekonto från en oväntad arbetslast eller ett oväntat IP-intervall?
• Fick en API-nyckel åtkomst till en ny slutpunkt eller ett nytt dataset?
• Användes ett certifikat efter att det hade ersatts?
• Gjorde en CI/CD-token en driftsättning utanför en godkänd pipeline?
• Försökte ett skrivskyddat konto utföra skrivoperationer?
• Blev en inaktiv autentiseringsuppgift aktiv?
• Fick en leverantörsintegration åtkomst till data utanför avtalade tider eller volymer?

När larmet 02:13 inträffar behöver ni kunna svara på vilken identitet som användes, vilken hemlighet som autentiserade den, vilka åtkomsträttigheter som utnyttjades, vilka data eller system som påverkades, om aktiviteten var förväntad, vilken ägare som kan validera den och om trösklarna för incidentrapportering är uppfyllda.

Revisorns perspektiv: samma process, olika frågor

Den starkaste revisionspositionen är inte ”vi uppfyller allt”. Den är ”vi driver en kontrollerad process som producerar underlag för flera skyldigheter”. Olika revisorer kommer att granska processen på olika sätt.

Över dessa perspektiv är de återkommande iakttagelserna förutsägbara: ingen samlad NHI-förteckning, ingen ägare för maskinidentiteter, hemligheter lagrade i kod eller dokumentation, delade autentiseringsuppgifter mellan miljöer, ingen rotation eller utgångstid, leverantörshanterade autentiseringsuppgifter utanför åtkomstgranskningar, övervakning som omfattar människor men inte maskiner och incidentåterställningsanvisningar som ignorerar läckage av hemligheter.

Varje iakttagelse mappar naturligt till Clarysecs kontroller, policyer och åtgärdsmallar. Än viktigare är att varje iakttagelse kan omvandlas till mätbart underlag inom ISMS.

Hur Clarysec hjälper er att bli revisionsklara

Clarysecs arbetssätt är praktiskt eftersom det börjar med det underlag som revisorer kommer att begära och arbetar bakåt till kontroller, policyer och operativa rutiner.

I Zenith Blueprint, fasen Controls in Action, steg 19, ger Clarysec direkt vägledning för maskin-till-maskin-autentisering:

För maskin-till-maskin-autentisering, till exempel tjänstekonton eller API-anrop, ska nycklar, certifikat och token skyddas lika strikt. Undvik att bädda in autentiseringsuppgifter i kod. Använd system för hantering av hemligheter eller valv för att lagra och rotera dem säkert.

Ett typiskt Clarysec-arbetsflöde för icke-mänskliga identiteter omfattar NHI-upptäckt i moln, SaaS, CI/CD, kodarkiv, valv och databaser, bedömning av policyluckor mot Clarysecs policyuppsättningar för små och medelstora företag eller företagsmiljöer, riskbedömning och riskbehandlingsmappning enligt ISO/IEC 27001:2022, uppdateringar av tillämpbarhetsförklaringen, underlagsmappning mot NIS2, DORA, GDPR och NIST CSF, utformning av NHI-register, anpassning till nyckelhanteringsregister, skanning av hemligheter, processer för åtkomstgranskning, ansvarsmatriser för leverantörsuppgifter, incidentåterställningsanvisningar och revisionspaket med skärmbilder, exporter, loggar, godkännanden och undantagsposter.

För små och medelstora företag är arbetssättet proportionerligt. En SaaS-leverantör med 70 personer behöver inte samma verktygsavtryck som en global bank, men den behöver ägarskap, policy, riskbehandling och underlag. För reglerade finansiella entiteter och IKT-leverantörer skalas samma modell till DORA-mappning av kritiska funktioner, tredjepartsriskstyrning och resiliensprövning.

Om er nästa revision är 2026 ska ni inte vänta på att revisorn upptäcker icke-mänskliga identiteter åt er. Börja med en kritisk tjänst och ställ fem frågor:

1. Känner vi till varje tjänstekonto, API-nyckel, token, certifikat och CI/CD-hemlighet som används av den här tjänsten?
2. Har varje NHI en namngiven ägare, förvaltare, ett syfte och en riskklassificering?
3. Är hemligheter lagrade i valv, roterade och skyddade från källkod, dokument, e-post och klartextlagring?
4. Är privilegierade maskinidentiteter granskade, övervakade och spärrade från interaktiv användning?
5. Kan vi ta fram underlag för ISO/IEC 27001:2022, NIS2, DORA och GDPR från en kontrollerad process?

Använd Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint för att strukturera er ISMS-implementering. Använd Zenith Controls: The Cross-Compliance Guide Zenith Controls för att koppla ISO/IEC 27002:2022-kontroller för identitet, autentisering, privilegier, loggning, kryptografi, säker utveckling och leverantörer till regulatoriskt underlag. Använd Clarysecs policybibliotek för små och medelstora företag och företagsmiljöer, inklusive 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 och Application Security Requirements Policy Application Security Requirements Policy, för att omvandla goda intentioner till bindande krav.

Larmet 02:13 kommer att inträffa någonstans. Frågan är om er organisation med underlag kan svara på vem som höll i nyckeln, vad den öppnade, varför den fanns och hur snabbt ni kan säkra den.