Secretsbeheer voor niet-menselijke identiteiten bij audits in 2026

De waarschuwing van 02:13 die niemand kon toeschrijven

Om 02:13 op een dinsdagochtend licht het kanaal van het Security Operations Center op. Vanuit een intern automatiseringsaccount is een export van een productiedatabase gestart. Het toegangspad is legitiem. Het token is geldig. Het bron-IP-adres hoort bij een cloudrunner die door het engineeringteam wordt gebruikt. Er is geen malware zichtbaar. Er is geen phishingmelding.

De CISO stelt de eerste voor de hand liggende vraag: “Wie is eigenaar van deze identiteit?”

Stilte.

De DevOps-lead herinnert zich dat het token twee jaar geleden is aangemaakt tijdens een klantmigratie. Het platformteam zegt dat het mogelijk wordt gebruikt door een facturatie-integratie. De databasebeheerder zegt dat het leestoegang heeft omdat het verwijderen ervan ooit een nachtelijke job heeft gebroken. Juridische Zaken vraagt of er persoonsgegevens bij betrokken waren. Compliance vraagt of dit een meldingsplichtig incident is onder NIS2, DORA of GDPR. De auditor vraagt om bewijsmateriaal waaruit blijkt dat serviceaccounts, API-sleutels, certificaten en CI/CD-secrets zijn geïnventariseerd, beoordeeld, geroteerd, gemonitord en ingetrokken.

Om 09:00 krijgt de concept-auditbevinding al vorm. In een vergeten microservice is een hardcoded, niet-geroteerde API-sleutel aangetroffen. Die sleutel verleent brede toegang tot een productiedatabase met klanttransacties. De ontwikkelaar die de sleutel heeft aangemaakt, is twee jaar geleden vertrokken. Het systeem heeft geen eigenaar op naam, geen gedocumenteerd doel, geen rotatieregistratie en geen monitoringregel.

Dit is het probleem van niet-menselijke identiteiten in 2026.

De meeste organisaties hebben de toegangsbeveiliging voor mensen verbeterd. Ze hebben MFA, workflows voor instroom, doorstroom en uitstroom, toegangsrechtenbeoordelingen voor geprivilegieerde toegang en logboeken van identiteitsproviders. Maar machine-identiteiten zijn sneller gegroeid dan de governance. Serviceaccounts, workload-identiteiten, API-sleutels, OAuth-tokens, SSH-sleutels, certificaten, Kubernetes-secrets, SaaS-integratietokens, accounts voor robotic process automation en CI/CD-deploymentcredentials voeren nu kritieke bedrijfshandelingen uit zonder in menselijke zin “gebruikers” te zijn.

Voor SaaS-aanbieders, fintechs, managed service providers, cloudoperators en datarijke mkb-organisaties zijn onbeheerde niet-menselijke identiteiten niet langer alleen een kwestie van technische hygiëne. Ze vormen een risico voor weerbaarheid en compliance op bestuursniveau. NIS2 behandelt toegangsbeveiliging, beheer van bedrijfsmiddelen, beveiliging van de toeleveringsketen, incidentenafhandeling en cyberbeveiligingshygiëne als kernmaatregelen voor cyberbeveiligingsrisicobeheer. DORA legt ICT-risico, operationele weerbaarheid, incidentmelding en ICT-risico’s van derde partijen voor financiële entiteiten onder de verantwoordingsplicht van het leidinggevend orgaan. GDPR vereist dat verwerkingsverantwoordelijken en verwerkers persoonsgegevens beschermen en verantwoordingsplicht kunnen aantonen.

De uitdaging is niet aantonen dat secrets bestaan. De uitdaging is aantonen dat elke niet-menselijke identiteit een eigenaar, doel, levenscyclus, risicoclassificatie, goedgekeurde toegang, veilige opslagmethode, rotatieregel, monitoringdekking en intrekkingspad heeft.

Waarom niet-menselijke identiteiten het nieuwe probleem van geprivilegieerde toegang zijn geworden

Een niet-menselijke identiteit, of NHI, is elke digitale identiteit die door software, infrastructuur of geautomatiseerde processen wordt gebruikt in plaats van door een persoon. In de praktijk omvat dit serviceaccounts die door applicaties worden gebruikt, API-sleutels die door SaaS-integraties worden gebruikt, OAuth- en refresh tokens die door applicaties van derden worden gebruikt, SSH-sleutels voor automatisering, TLS-certificaten en private sleutels, CI/CD-secrets, cloud-workload-identiteiten, databaseverbindingsstrings, ingebedde credentials, RPA-botaccounts en door leveranciers beheerde integratiecredentials.

Deze identiteiten hebben vaak drie kenmerken die auditors ongerust maken.

Ten eerste zijn ze langlevend. Een menselijke gebruiker kan inloggegevens roteren, van rol veranderen en via een formeel offboardingproces vertrekken. Een API-token dat tijdens een releasevenster is aangemaakt, kan jarenlang actief blijven omdat niemand het risico wil lopen productieprocessen te verstoren.

Ten tweede zijn ze krachtig. Een deploymenttoken kan infrastructuur wijzigen. Een cloud service principal kan opslag aanmaken. Een databaseaccount kan klantregistraties exporteren. Een ondertekeningssleutel kan de integriteit van de softwaretoeleveringsketen compromitteren.

Ten derde zijn ze slecht toerekenbaar. Menselijke identiteiten zijn gekoppeld aan HR-registraties. Niet-menselijke identiteiten zijn vaak gekoppeld aan scripts, pipelines, leveranciers, vergeten projecten of ongedocumenteerde integraties.

Clarysec’s Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint benoemt dit rechtstreeks in de fase Controls in Action, stap 22:

En vergeet de niet-menselijke identiteiten niet. Hier brengen audits vaak stille blootstelling aan het licht. Worden API-tokens gevolgd? Zijn integratieaccounts gekoppeld aan personen, of zweven ze in niemandsland? Wanneer is die databasetoegangsstring, ingebed in een decennia oud script, voor het laatst geroteerd?

Identiteitsbeheer is niet glamoureus, maar wel structureel. Zonder identiteitsbeheer is uw ISMS slechts een verzameling gesloten deuren, zonder zekerheid over wie de sleutels in handen heeft.

Die laatste zin is de kern. Een organisatie kan een strak beleid voor toegangsbeveiliging hebben en toch zakken voor een audit als machine-identiteiten onbeheerd zijn. Een ISMS dat niet kan uitleggen wie eigenaar is van een secret, waarom die bestaat en wanneer die voor het laatst is beoordeeld, functioneert nog niet als een beheerst systeem.

ISO/IEC 27001:2022 maakt van secretsbeheer bewijsmateriaal

ISO/IEC 27001:2022 is effectief omdat de norm secretsbeheer niet behandelt als een geïsoleerde engineeringtaak. De norm vereist een risicogebaseerd ISMS met een gedefinieerde scope, eisen van belanghebbenden, leiderschapsverantwoordelijkheid, risicobeoordeling, risicobehandeling, selectie van beheersmaatregelen, een Verklaring van Toepasselijkheid en voortdurende verbetering.

Voor niet-menselijke identiteiten moet de organisatie niet beginnen met de aanschaf van tooling. Zij moet beginnen met scope en verplichtingen.

Onder ISO/IEC 27001:2022-clausules 4.1 tot en met 4.4 bepaalt de organisatie interne en externe kwesties, belanghebbenden, wettelijke, regelgevende en contractuele eisen, interfaces en afhankelijkheden. In de NHI-context moet de ISMS-scope cloudomgevingen, SaaS-platforms, CI/CD-systemen, productieapplicaties, klantintegraties, externe gegevensverwerkers, managed service providers en cryptografische diensten identificeren waar machinecredentials bestaan.

Clausules 5.1 tot en met 5.3 maken het management verantwoordelijk voor beleid, middelen, rollen en prestatierapportage. Dit is belangrijk omdat NHI-remediatie vaak operationele spanning veroorzaakt. Het roteren van een credential voor een productiedatabase, het vervangen van een legacy gedeeld serviceaccount of het afdwingen van vault-gebaseerde secretsinjectie kan kwetsbare workflows verstoren. Zonder executive sponsor stellen teams de opschoning uit.

Clausules 6.1.1 tot en met 6.1.3 en 6.2 vormen de motor voor beheersing. De organisatie definieert risicocriteria, identificeert risico’s voor vertrouwelijkheid, integriteit en beschikbaarheid, wijst risico-eigenaren toe, beoordeelt waarschijnlijkheid en impact, kiest behandelopties, selecteert beheersmaatregelen, stelt de Verklaring van Toepasselijkheid op en volgt meetbare doelstellingen.

In praktische termen moet een risicobehandelingsplan voor niet-menselijke identiteiten antwoord geven op:

• Welke systemen en bedrijfsdiensten zijn afhankelijk van NHI’s?
• Welke secrets kunnen toegang geven tot persoonsgegevens, gereguleerde financiële diensten, productie-infrastructuur of kritieke klantdiensten?
• Welke identiteiten zijn geprivilegieerd, inactief, gedeeld, door leveranciers beheerd of onbeheerd?
• Welke beheersmaatregelen verlagen het risico, zoals opslag in vaults, rotatie, het principe van minimale rechten, verval, certificaatlevenscyclusbeheer, CI/CD-scanning, monitoring en noodintrekking?
• Welke restrisico’s vereisen zakelijke goedkeuring?

ISO/IEC 27002:2022 biedt vervolgens de catalogus van beheersmaatregelen in Annex A. De meest relevante beheersmaatregelen zijn 5.9 Inventaris van informatie en andere bijbehorende bedrijfsmiddelen, 5.15 Toegangscontrole, 5.16 Identiteitsbeheer, 5.17 Authenticatie-informatie, 5.18 Toegangsrechten, 5.19 Informatiebeveiliging in leveranciersrelaties, 5.20 Informatiebeveiliging binnen leveranciersovereenkomsten adresseren, 5.21 Beheer van informatiebeveiliging in de ICT-toeleveringsketen, 5.23 Informatiebeveiliging bij gebruik van cloudservices, 5.24 Planning en voorbereiding van incidentbeheer, 5.28 Verzameling van bewijsmateriaal, 8.2 Geprivilegieerde toegangsrechten, 8.3 Beperking van informatietoegang, 8.5 Veilige authenticatie, 8.15 Logging, 8.16 Monitoringactiviteiten, 8.24 Gebruik van cryptografie, 8.25 Veilige ontwikkelingslevenscyclus, 8.26 Vereisten voor applicatiebeveiliging, 8.28 Veilig programmeren en 8.31 Scheiding van ontwikkel-, test- en productieomgevingen.

Clarysec’s Zenith Controls: The Cross-Compliance Guide Zenith Controls brengt deze ISO/IEC 27002:2022-relaties in kaart op een manier die auditors en eigenaren van beheersmaatregelen kunnen gebruiken. Voor beheersmaatregel 5.16, Identiteitsbeheer, legt Zenith Controls de relatie tussen identiteit en inloggegevens uit:

Identiteitsbeheer levert het wie, terwijl authenticatie-informatie het hoe borgt door te verifiëren dat de persoon die een identiteit claimt legitiem is. 5.16 regelt het beheer van de identiteitslevenscyclus, terwijl 5.17 waarborgt dat wachtwoorden, tokens, certificaten en andere credentials veilig aan die identiteiten zijn gekoppeld en correct worden beheerd ter ondersteuning van sterke authenticatie.

Die relatie is essentieel voor NHI’s. Een token zonder identiteitseigenaar is niet auditwaardig. Een serviceaccount zonder toegangsrechtenbeoordeling voldoet niet aan het principe van minimale rechten. Een certificaat zonder levenscyclusstatus is geen beheerste cryptografie. Een leveranciersintegratiecredential zonder contractuele voorwaarden is geen effectief beheer van risico’s van derde partijen.

Het Clarysec-beheersingspatroon: identiteit, secret, privilege, bewijsmateriaal

Clarysec implementeert beheer van niet-menselijke identiteiten en secrets via een herhaalbaar beheersingspatroon. Wij behandelen “secrets” niet uitsluitend als een DevOps-aangelegenheid en “serviceaccounts” niet uitsluitend als een IAM-aangelegenheid. Wij verbinden identiteit, secret, privilege en bewijsmateriaal.

De beleidslaag maakt dit afdwingbaar.

Voor mkb-organisaties stelt Clarysec’s Beleid inzake beheer van gebruikersaccounts en privileges-sme Beleid inzake beheer van gebruikersaccounts en privileges-sme:

Serviceaccounts (gebruikt door systemen of applicaties) moeten worden gedocumenteerd, beperkt tot specifieke systemen en nooit worden gebruikt voor interactieve aanmeldingen.

Dit voorkomt het klassieke antipatroon waarbij een serviceaccount verandert in een gedeelde beheerderslogin. Het geeft een auditor ook een duidelijke test: toon de inventaris van serviceaccounts, toon de systeembeperking en toon aan dat interactieve aanmelding is uitgeschakeld of technisch wordt verhinderd.

Clarysec’s Beleid inzake beheer van bedrijfsmiddelen-sme Beleid inzake beheer van bedrijfsmiddelen-sme breidt de definitie van bedrijfsmiddelen uit met:

Digitale credentials en diensten: domeinnamen, digitale certificaten, API-sleutels, e-mailaccounts, cloudlogins

Dit is belangrijk omdat veel organisaties alleen servers, laptops en applicaties inventariseren. In 2026 kan een API-sleutel gevoeliger zijn dan een laptop. Een private sleutel van een certificaat kan een authenticatieasset voor productie zijn. Een cloudlogin die door automatisering wordt gebruikt, kan leiden tot blootstelling van gereguleerde gegevens. Credentials als bedrijfsmiddelen behandelen is de basis voor auditklaar secretsbeheer.

Voor enterprise-omgevingen legt Clarysec’s Beleid inzake beheer van gebruikersaccounts en privileges Beleid inzake beheer van gebruikersaccounts en privileges de lat voor bewijsmateriaal hoger:

De organisatie moet een gedetailleerde inventaris bijhouden van alle actieve en inactieve credentials, geprivilegieerde accounts en serviceaccounts op systeemniveau. Deze inventaris moet continu worden bijgewerkt en per kwartaal worden beoordeeld.

De kwartaalbeoordeling is het moment waarop veel hiaten zichtbaar worden. Inactieve credentials, verweesde service principals, oude integratiegebruikers, onbeheerde leveranciersaccounts en noodtokens worden pas zichtbaar wanneer iemand het register vergelijkt met de feitelijke IAM-, vault-, CI/CD- en cloudregistraties.

Secrets zijn authenticatie-informatie, geen ontwikkelaarsgemak

De gevaarlijkste uitdrukking in secretsbeheer is “tijdelijke sleutel”.

Tijdelijke sleutels worden permanent. Testcredentials bereiken productie. Broncode onthult tokens. Buildlogboeken leggen wachtwoorden bloot. Supportteams delen certificaten via tickets. Ontwikkelaars kopiëren omgevingsbestanden naar chat. Een contractant maakt een cloud service principal aan en vertrekt.

De Zenith Blueprint, fase Controls in Action, stap 22, beschrijft authenticatie-informatie breed:

Deze beheersmaatregel gaat niet alleen over wachtwoorden, hoewel wachtwoorden zeker deel uitmaken van het geheel. Het gaat om elke credential die wordt gebruikt om identiteit aan te tonen: wachtwoorden, pincodes, cryptografische sleutels, biometrische sjablonen, smartcards, tokens, certificaten, OAuth-tokens, SSH-sleutels, API- secrets. Dit zijn de sleutels tot het koninkrijk, en Beheersmaatregel 5.17 zorgt ervoor dat die sleutels met de ernst worden behandeld die zij verdienen.

Laat dit duidelijk zijn: slecht authenticatiebeheer blijft een van de belangrijkste oorzaken achter inbreuken. Zwakke of gedeelde wachtwoorden. Hardcoded credentials in broncode. Ongewijzigde standaardlogins op beheerportalen. Certificaten met verlopen of onbekend eigenaarschap. In elk van die gevallen is niet de identiteit gefaald, maar de bescherming en governance van het mechanisme dat wordt gebruikt om die identiteit te bewijzen.

Clarysec-beleid vertaalt dit naar operationele regels.

Het Beleid inzake cryptografische beheersmaatregelen-sme Beleid inzake cryptografische beheersmaatregelen-sme stelt:

Sleutels mogen niet in platte tekst worden opgeslagen of worden ingebed in broncode, documenten of e-mails

Het Beleid inzake veilige ontwikkeling-sme Beleid inzake veilige ontwikkeling-sme stelt:

Geen hardcoded credentials of secrets in broncode

Voor enterprise-teams stelt het Beleid inzake veilige ontwikkeling Beleid inzake veilige ontwikkeling:

Secrets mogen niet hardcoded zijn of in platte tekst in repositories worden opgeslagen.

En het Beleid inzake vereisten voor applicatiebeveiliging Beleid inzake vereisten voor applicatiebeveiliging is nog directer:

De opslag van wachtwoorden of cryptografische sleutels in platte tekst is strikt verboden.

Deze beleidsbepalingen creëren een duidelijke audittrail. Securityteams kunnen repositories, CI/CD-variabelen, containerimages, configuratieopslag, issue-trackers, documentatieplatforms en logboeken toetsen aan expliciete eisen. Ze ondersteunen ook GDPR Article 32 Beveiliging van de verwerking, omdat blootstelling van secrets rechtstreeks kan leiden tot ongeautoriseerde toegang tot persoonsgegevens.

Cryptografische governance in enterprise-omgevingen vereist ook eigenaarschap. Clarysec’s Beleid inzake cryptografische beheersmaatregelen Beleid inzake cryptografische beheersmaatregelen vereist:

Er moet een gecentraliseerd sleutelbeheerregister worden bijgehouden om alle cryptografische sleutels, hun levenscyclusstatus, toegewezen beheerders en gebruikscontexten vast te leggen.

Voor niet-menselijke identiteiten moet dat register certificaatsleutels, ondertekeningssleutels, API-sleutels en door de cloud beheerde sleutels verbinden met het bredere NHI-register. De auditor moet een productiecertificaat kunnen traceren van bedrijfsdienst, naar eigenaar, naar beheerder, naar vervaldatum, naar rotatiebewijsmateriaal, naar incidentresponsprocedure.

NIS2, DORA en GDPR: één bewijsmodel, veel toezichthouders

Governance van niet-menselijke identiteiten is een probleem dat meerdere compliancedomeinen raakt, omdat dezelfde tekortkoming meerdere verplichtingen kan activeren.

Een gelekt API-token bij een SaaS-aanbieder kan leiden tot verstoring van dienstverlening onder NIS2, blootstelling van persoonsgegevens onder GDPR en contractuele incidentmelding aan financiële klanten onder DORA-verwachtingen voor de toeleveringsketen. Een gecompromitteerd CI/CD-secret bij een ICT-dienstverlener kan invloed hebben op klantweerbaarheid, software-integriteit en operationele continuïteit. Een vergeten leveranciersintegratieaccount kan toegang geven tot gereguleerde systemen zonder passende due diligence of contractuele beheersmaatregelen.

NIS2 Article 21 vereist passende en evenredige technische, operationele en organisatorische maatregelen. De minimumgebieden omvatten risicoanalyse, beveiligingsbeleid voor informatiesystemen, incidentenafhandeling, bedrijfscontinuïteit, beveiliging van de toeleveringsketen, veilige verwerving, ontwikkeling en onderhoud, kwetsbaarheidsafhandeling, beoordeling van de doeltreffendheid, cyberhygiëne, cryptografie, HR-beveiliging, toegangscontrole en beheer van bedrijfsmiddelen, en waar passend MFA of continue authenticatie. Niet-menselijke identiteiten lopen door vrijwel al deze gebieden heen. NIS2 Article 23 creëert ook gefaseerde rapportage van significante incidenten, waaronder een vroegtijdige waarschuwing binnen 24 uur, incidentmelding binnen 72 uur en een eindrapport uiterlijk één maand na de incidentmelding.

DORA is van toepassing vanaf 17 januari 2025 en bestrijkt ICT-risicobeheer, rapportage van majeure ICT-gerelateerde incidenten, testen van operationele weerbaarheid, informatie-uitwisseling en ICT-risico’s van derde partijen. Articles 5 en 6 vereisen governance, verantwoordingsplicht van het leidinggevend orgaan en een gedocumenteerd ICT-risicobeheerkader. Article 8 vereist identificatie van door ICT ondersteunde bedrijfsfuncties, informatieactiva en afhankelijkheden. Articles 17 tot en met 19 vereisen incidentbeheer, classificatie en rapportage. Articles 28 tot en met 30 vereisen beheer van ICT-risico’s van derde partijen, contractregisters, due diligence, beveiligingsstandaarden, auditrechten, incidentondersteuning, beheersmaatregelen voor onderaanneming en exitstrategieën.

GDPR is van toepassing waar persoonsgegevens binnen de territoriale reikwijdte ervan worden verwerkt. Article 5 vereist integriteit, vertrouwelijkheid en verantwoordingsplicht. Article 32 vereist passende technische en organisatorische maatregelen voor Beveiliging van de verwerking. Als een serviceaccount of API-sleutel toegang kan geven tot persoonsgegevens, worden onbeheerde secrets een falen van privacybeheersing, niet alleen een IT-kwestie.

Hetzelfde bewijsmateriaal kan ISO/IEC 27001:2022-certificering, NIS2-toezicht, DORA-onderzoeken en GDPR-verantwoordingsplicht ondersteunen wanneer het correct is gestructureerd.

NIST CSF 2.0 kan als communicatielaag voor hetzelfde bewijsmateriaal worden gebruikt. De GOVERN-functie omvat verwachtingen van stakeholders, wettelijke en contractuele verplichtingen, risicobereidheid, leiderschapsverantwoordelijkheid, beleid en toezicht. De operationele uitkomsten omvatten inventarissen van bedrijfsmiddelen, door leveranciers geleverde diensten, identiteits- en credentialbeheer, het principe van minimale rechten, gegevensbeveiliging, logging, monitoring, incidentrespons en herstel.

COBIT 2019 en assurance-teams in ISACA-stijl kijken doorgaans naar governance en procesvolwassenheid. Zij zullen vragen of verantwoordelijkheid is toegewezen, of beheersmaatregelen zijn ingebed in operationele processen, of uitzonderingen zijn goedgekeurd, of metrieken aan het management worden gerapporteerd en of bewijsmateriaal herhaalbaarheid aantoont in plaats van een eenmalige opschoning.

Een praktische sprint om een register van niet-menselijke identiteiten op te bouwen

Een praktisch Clarysec-traject start vaak met een gerichte sprint, niet met een toolingprogramma van zes maanden. Het doel is een verdedigbaar NHI-register, risicorangschikking en remediatieplan op te leveren dat kan doorstromen naar het ISO/IEC 27001:2022-risicobehandelingsplan en de Verklaring van Toepasselijkheid.

Begin met één bedrijfsdienst, zoals een klantfacturatieplatform, handelsapplicatie, patiëntenportaal of beheersysteem voor SaaS-tenants. Neem productie, staging, CI/CD, cloudinfrastructuur, monitoringtools, databases, SaaS-integraties en door leveranciers beheerde diensten mee.

Koppel dit aan Zenith Blueprint, fase Risk Management, stap 14, waar Clarysec behandelbeleid afstemt op regelgevende kruisverwijzingen. In die stap omvatten veilige ontwikkeling en beheersmaatregelen voor pipelines geen hardcoded secrets, peer review, geautomatiseerde statische analyse, dependency scanning, scheiding van ontwikkeling, test en productie, MFA voor pipelinetoegang, integriteit van buildartefacten en CI/CD-logging.

Verzamel identiteiten en secrets uit de identiteitsprovider, cloud-IAM, secrets-vault, Kubernetes, CI/CD-variabelen, repository-instellingen, databasegebruikers, SaaS-beheerconsoles, certificaatbeheertools en leveranciersdocumentatie.

Beoordeel identiteiten op risico wanneer zij productietoegang, geprivilegieerde rechten, toegang tot persoonsgegevens, afhankelijkheid van kritieke of belangrijke functies, leveranciersbeheer, langlevende tokens, geen eigenaar, geen rotatie, geen monitoring of hardcoded opslag hebben. Gebruik de ISO/IEC 27001:2022-risicocriteria om waarschijnlijkheid en impact te scoren. Gebruik DORA-analyse van kritieke of belangrijke functies waar van toepassing. Gebruik GDPR-impactoverwegingen waar persoonsgegevens toegankelijk zijn. Gebruik NIS2-service-impact waar verstoring of schade voor klanten plausibel is.

Pas voor elke NHI met hoog risico behandelacties toe. Verplaats secrets uit broncode, documenten en CI/CD-variabelen in platte tekst naar een vault of beheerde secret store. Vervang gedeelde serviceaccounts door unieke workload-identiteiten. Schakel interactieve aanmelding voor serviceaccounts uit. Pas het principe van minimale rechten en omgevingsspecifieke credentials toe. Configureer rotatie, verval en noodintrekking. Koppel secrets aan eigenaren en beheerders. Voeg logging toe voor authenticatie, tokengebruik en gevoelige acties. Voeg waarschuwingen toe voor afwijkende geografie, ongebruikelijk tijdstip, ongebruikelijk volume of nieuwe resourcetoegang. Werk leverancierscontracten bij voor omgang met credentials, incidentondersteuning en auditrechten. Documenteer uitzonderingen met goedkeuring door de risico-eigenaar en een vervaldatum.

Het Beleid inzake testgegevens en testomgevingen Beleid inzake testgegevens en testomgevingen ondersteunt omgevingsscheiding:

Integratie met CI/CD-pijplijnen moet de scheiding van omgevingen en authenticatiecredentials afdwingen.

Die bepaling is vaak doorslaggevend. Als ontwikkeling, test en productie secrets delen, kan een omgeving met laag risico een pad naar een productie-inbreuk worden.

De sprint moet eindigen met een bewijspakket, niet alleen met een lijst van bevindingen. Neem de export van het NHI-register, risicobeoordelingsregistraties, behandelplan, mapping op de Verklaring van Toepasselijkheid, beleidsverwijzingen, screenshots van vaults, rotatielogboeken, goedkeuringen van toegangsrechtenbeoordelingen, resultaten van CI/CD-secret-scanning, definities van monitoringregels, verantwoordelijkhedenmatrix voor leverancierscredentials, incidentdraaiboek en uitzonderingen met eigenaren en vervaldatums op.

Logging en detectie: aantonen dat gebruik van machine-identiteiten zichtbaar is

Een machine-identiteit die goed is geïnventariseerd maar onzichtbaar blijft in logboeken, blijft gevaarlijk. Detectie maakt deel uit van het beheersingsverhaal.

Clarysec’s Beleid voor logging en bewaking-sme Beleid voor logging en bewaking-sme omvat authenticatiebewijsmateriaal:

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

Voor NHI’s moet deze eis worden toegepast op machine-authenticatie. Mogelijk heeft u geen MFA-gebruik voor een workload-identiteit, maar u moet wel beschikken over authenticatiegebeurtenissen, tokengebruik, certificaatgebruik, metadata van API-aanroepen, bron-workload, doeldienst, tokenlevensduur, faalgebeurtenissen en geprivilegieerde acties.

In Zenith Controls is ISO/IEC 27002:2022-beheersmaatregel 8.2, Geprivilegieerde toegangsrechten, gekoppeld aan logging en monitoring omdat geprivilegieerde accounts gedetailleerde registraties en toezicht vereisen. Zenith Controls koppelt 8.2 ook aan identiteitsbeheer, toegangsrechten, beperking van informatietoegang en veilige authenticatie. Voor auditors betekent dit dat geprivilegieerde niet-menselijke identiteiten met dezelfde ernst moeten worden beoordeeld en gemonitord als menselijke beheerders, soms zelfs strenger.

Goede monitoringvragen zijn onder meer:

• Heeft een serviceaccount zich geauthenticeerd vanaf een onverwachte workload of IP-range?
• Heeft een API-sleutel toegang gekregen tot een nieuw endpoint of een nieuwe dataset?
• Is een certificaat gebruikt nadat het was vervangen?
• Heeft een CI/CD-token buiten een goedgekeurde pipeline uitgerold?
• Heeft een alleen-lezenaccount schrijfbewerkingen geprobeerd?
• Is een inactieve credential actief geworden?
• Heeft een leveranciersintegratie toegang gehad tot gegevens buiten overeengekomen tijden of volumes?

Wanneer de waarschuwing van 02:13 optreedt, moet u kunnen beantwoorden welke identiteit is gebruikt, welk secret deze heeft geauthenticeerd, welke toegangsrechten zijn uitgeoefend, welke gegevens of systemen zijn geraakt, of de activiteit verwacht was, welke eigenaar deze kan valideren en of meldingsdrempels voor incidenten zijn bereikt.

De blik van de auditor: hetzelfde proces, andere vragen

De sterkste auditpositie is niet “wij voldoen aan alles”. Het is “wij werken met één beheerst proces dat bewijsmateriaal voor meerdere verplichtingen oplevert”. Verschillende auditors zullen dat proces verschillend inspecteren.

Over deze perspectieven heen zijn de terugkerende bevindingen voorspelbaar: geen NHI-inventaris, geen eigenaar voor machine-identiteiten, secrets opgeslagen in code of documentatie, gedeelde credentials tussen omgevingen, geen rotatie of verval, door leveranciers beheerde credentials buiten toegangsrechtenbeoordelingen, monitoring die mensen maar geen machines dekt, en incidentdraaiboeken die secretlekkage negeren.

Elke bevinding is logisch te mappen op Clarysec-beheersmaatregelen, beleid en remediatiesjablonen. Belangrijker nog: elke bevinding kan binnen het ISMS worden omgezet in meetbaar bewijsmateriaal.

Hoe Clarysec u helpt gereed te zijn voor audits

De aanpak van Clarysec is praktisch omdat deze begint met het bewijsmateriaal dat auditors zullen opvragen en terugwerkt naar beheersmaatregelen, beleid en operationele routines.

In de Zenith Blueprint, fase Controls in Action, stap 19, geeft Clarysec directe richtlijnen voor machine-to-machine-authenticatie:

Voor machine-to-machine-authenticatie, zoals serviceaccounts of API-aanroepen, moeten sleutels, certificaten en tokens even strikt worden beschermd. Vermijd het inbedden van credentials in code. Gebruik secretsbeheersystemen of vaults om ze veilig op te slaan en te roteren.

Een typische Clarysec-werkstroom voor niet-menselijke identiteiten omvat NHI-detectie over cloud, SaaS, CI/CD, repositories, vaults en databases heen, beoordeling van beleidshiaten ten opzichte van Clarysec-beleidsets voor mkb of enterprise, ISO/IEC 27001:2022-risicobeoordeling en behandelmapping, actualiseringen van de Verklaring van Toepasselijkheid, evidence mapping voor NIS2, DORA, GDPR en NIST CSF, ontwerp van het NHI-register, afstemming met het sleutelbeheerregister, secretscanning, processen voor toegangsrechtenbeoordeling, verantwoordelijkhedenmatrices voor leverancierscredentials, incidentdraaiboeken en auditpakketten met screenshots, exports, logboeken, goedkeuringen en registraties van uitzonderingen.

Voor mkb-organisaties is de aanpak evenredig. Een SaaS-aanbieder met 70 medewerkers heeft niet dezelfde tooling footprint nodig als een wereldwijde bank, maar heeft wel eigenaarschap, beleid, risicobehandeling en bewijsmateriaal nodig. Voor gereguleerde financiële entiteiten en ICT-aanbieders schaalt hetzelfde model door naar DORA-mapping van kritieke functies, governance van risico’s van derde partijen en testen van weerbaarheid.

Als uw volgende audit in 2026 plaatsvindt, wacht dan niet tot de auditor niet-menselijke identiteiten voor u ontdekt. Begin met één kritieke dienst en stel vijf vragen:

1. Kennen we elk serviceaccount, elke API-sleutel, elk token, elk certificaat en elk CI/CD-secret dat door deze dienst wordt gebruikt?
2. Heeft elke NHI een eigenaar op naam, beheerder, doel en risicoclassificatie?
3. Worden secrets in vaults opgeslagen, geroteerd en beschermd tegen broncode, documenten, e-mails en opslag in platte tekst?
4. Worden geprivilegieerde machine-identiteiten beoordeeld, gemonitord en beperkt voor interactief gebruik?
5. Kunnen we bewijsmateriaal voor ISO/IEC 27001:2022, NIS2, DORA en GDPR produceren vanuit één beheerst proces?

Gebruik Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint om uw ISMS-implementatietraject te structureren. Gebruik Zenith Controls: The Cross-Compliance Guide Zenith Controls om ISO/IEC 27002:2022-identiteit, authenticatie, privilege, logging, cryptografie, veilige ontwikkeling en leveranciersbeheersmaatregelen te verbinden met regelgevend bewijsmateriaal. Gebruik Clarysec’s beleidsbibliotheek voor mkb en enterprise, waaronder het Beleid inzake beheer van gebruikersaccounts en privileges-sme Beleid inzake beheer van gebruikersaccounts en privileges-sme, Beleid inzake cryptografische beheersmaatregelen Beleid inzake cryptografische beheersmaatregelen, Beleid inzake veilige ontwikkeling Beleid inzake veilige ontwikkeling en Beleid inzake vereisten voor applicatiebeveiliging Beleid inzake vereisten voor applicatiebeveiliging, om goede intenties om te zetten in afdwingbare eisen.

De waarschuwing van 02:13 zal ergens plaatsvinden. De vraag is of uw organisatie met bewijsmateriaal kan beantwoorden wie de sleutel in handen had, wat die opende, waarom die bestond en hoe snel u de situatie veilig kunt maken.