Gids Cybersecurity IT-beheer

Machineidentiteiten: het aanvalsoppervlak dat uw beveiligingsteam niet beheert

API-sleutels, serviceaccounts, TLS-certificaten en OAuth-tokens overtreffen menselijke accounts met 45 op 1 in bedrijfsomgevingen. De meeste organisaties hebben geen volledige inventaris van deze identiteiten. Aanvallers scannen er continu op.

Ryland Deakin

Lead Consultant, Cyvra

18 juni 2026

9 minuten lezen

Belangrijkste punten

Machineidentiteiten overtreffen menselijke identiteiten met 45 op 1 in bedrijfsomgevingen, maar de meeste beveiligingsteams hebben slechts een fractie geïnventariseerd
Serviceaccounts, API-sleutels, TLS-certificaten en OAuth-tokens zijn elk een potentieel toegangspunt als ze onbeheerd zijn
Verlopen certificaten veroorzaken storingen; blootgestelde API-sleutels veroorzaken datalekken; verlaten serviceaccounts maken laterale beweging mogelijk
Secrets management-tools lossen het opslagprobleem op, maar inventarisatie moet vóór rotatie plaatsvinden
Zero Trust werkt alleen als machine-naar-machine-vertrouwen even streng wordt beheerd als gebruikerstoegang

Wat telt als een machineidentiteit

Machineidentiteiten zijn credentials die systemen gebruiken om zich bij elkaar te authenticeren. Een gebruiker logt in met een gebruikersnaam en wachtwoord. Een machine gebruikt iets anders: een TLS-certificaat, een API-sleutel, een SSH-sleutel, een OAuth-token, een serviceaccount of een Kubernetes-serviceaccounttoken.

Cloudinfrastructuur, microservices, containers, CI/CD-pipelines en integraties met externe API's hebben het aantal machine-naar-machine-verbindingen in de meeste organisaties in het afgelopen decennium met een orde van grootte vermenigvuldigd. Elke verbinding vereist authenticatie. Organisaties hebben formele processen voor gebruikersaccounts. Vrijwel geen enkele heeft gelijkwaardige processen voor machines.

45:1

verhouding machine- versus menselijke identiteiten in bedrijfsomgevingen

68%

van datalekken betreft gecompromitteerde credentials (Verizon DBIR)

250k+

machineidentiteiten in een typisch groot bedrijf

Waarom de aantallen de hand uitliepen

Het accumuleert in kleine, onopvallende stappen. Een DevOps-team maakt een serviceaccount aan voor een deployment-pipeline. Een engineer maakt een API-sleutel aan om twee SaaS-tools te verbinden. Een ontwikkelaar voegt credentials toe aan een testomgeving-configuratiebestand. Een containerimage draagt een hardgecodeerd secret van de machine van een ontwikkelaar naar productie.

Niets van dit alles ziet eruit als een beveiligingsincident op het moment. Tegen de tijd dat uw beveiligingsteam de eerste inventaris uitvoert, overtreffen machine-credentials het personeelsbestand met een factor die de meeste teams verrast.

Gebruikersaccounts hebben een logische deprovisioneringstrigger: de persoon vertrekt. Machine-credentials hebben geen equivalent. Serviceaccounts accumuleren. API-sleutels worden gedeeld tussen teams en nooit geroteerd. TLS-certificaten verlopen op de dag dat een engineer op verlof is. Kubernetes-tokens van een deployment twee jaar geleden blijven geldig en niemand weet meer waarvoor ze waren.

Hoe aanvallers dit misbruiken

De Verizon DBIR vindt gecompromitteerde credentials in de meerderheid van datalekken. Machine-credentials vormen een groot en onderbelicht deel van dat aanvalsoppervlak.

Een aanvaller die een API-sleutel in een publieke GitHub-repository vindt, heeft onmiddellijk toegang tot wat die sleutel autoriseert. Een gecompromitteerde CI/CD-pipeline laat een aanvaller credentials in build-artefacten injecteren. Een serviceaccount met buitensporige rechten geeft een aanvaller een voertuig voor laterale beweging zodra ze het in handen hebben.

Detectietools die zijn gebouwd rond menselijke gedragspatronen zullen geen vlag zetten bij een serviceaccount dat doet wat serviceaccounts normaal doen. Daarom blijven gecompromitteerde machine-credentials vaak maandenlang onopgemerkt.

Gebruikerssessies verlopen. Machine-credentials, tenzij iemand ze expliciet roteert of intrekt, blijven meestal onbeperkt geldig. Een API-sleutel van een service die niet meer bestaat, kan nog steeds werken. Een serviceaccount van een afgerond project twee jaar geleden kan nog steeds domeinbeheerdersrechten hebben.

Vier controles die ertoe doen

Eerst inventariseren

U kunt niet beheren wat u niet kunt zien. Een inventaris van machineidentiteiten omvat serviceaccounts in Active Directory en Azure AD, API-sleutels bij cloudproviders en SaaS-tools, TLS-certificaten, SSH-sleutels, OAuth-tokens en Kubernetes-serviceaccounttokens. De eerste ontdekkingsfase is de fase die de meeste organisaties onderschatten.

Secrets management centraliseren

Hardgecodeerde secrets in code, configuratiebestanden en omgevingsvariabelen zijn de meest voorkomende bron van blootstelling aan credentials. Secrets managers (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) bieden een centrale opslag met toegangscontroles, auditlogs en geautomatiseerde rotatie.

Minimale privileges afdwingen

Een serviceaccount dat uit één S3-bucket moet lezen, hoeft geen schrijftoegang tot vijf andere te hebben. Machineidentiteiten accumuleren rechten omdat het gemakkelijker is om brede toegang te verlenen dan exacte vereisten te definiëren. Een privileges-review onthult meer dan de meeste teams verwachten.

Certificaatbeheer automatiseren

Het verlopen van TLS-certificaten is een opgelost probleem. ACME-gebaseerde automatisering (Let's Encrypt, AWS Certificate Manager, HashiCorp Vault PKI) vernieuwt certificaten automatisch vóór het verlopen. Storingen door verlopen certificaten zijn het gevolg van handmatige processen in omgevingen waar automatisering beschikbaar was en niet werd gebruikt.

Vóór u roteert

Het in bulk roteren van secrets vóór een volledige inventaris leidt tot nieuwe problemen. Services die afhankelijk zijn van credentials die u niet kende, zullen uitvallen. Eerst inventariseren, dan roteren, met geautomatiseerde rollback voor elke service die de nieuwe credential niet oppikt.

Waar te beginnen

Begin met serviceaccounts in Active Directory en Azure AD. De audit kost niets en brengt de hoogste risico's meteen naar boven: geprivilegieerde accounts zonder duidelijke eigenaar en zonder recent gebruik. Zodra u weet welke systemen in scope zijn, volgt de ontdekking van API-sleutels en certificaten vanzelf.

Haal credentialinventaris vroeg op bij uw cloudproviders. AWS IAM Credential Reports, Azure AD App Registrations en GCP Service Account-lijsten vangen geen secrets die in repositories of externe SaaS-tools zijn hardgecodeerd, maar ze geven u een meetbare basis.

NIS2, ISO 27001 en de meeste interne auditframeworks markeren credential- en toegangsbeheer als een kerncontrolegebied. Als machineidentiteiten in uw auditbevindingen staan, is een gestructureerde beoordeling de snelste weg om die lacune te dichten.

Hoe Cyvra helpt

Cyvra voert machineidentiteitsbeoordelingen uit, bouwt secrets management-mogelijkheden op en integreert certificaatlevenscyclusautomatisering in bestaande cloud- en CI/CD-omgevingen. Als uw laatste audit credentialbeheer als aandachtspunt heeft aangemerkt, is dat waar we beginnen.

Veelgestelde vragen

Wat is een machineidentiteit?

Een machineidentiteit is elke credential die een systeem gebruikt om zich te authenticeren bij een ander systeem: een TLS-certificaat, een API-sleutel, een SSH-sleutel, een serviceaccount, een OAuth-token of een Kubernetes-serviceaccounttoken. De teams die systemen bouwen en draaien beheren deze credentials, niet individuele gebruikers. Ze overtreffen gebruikersidentiteiten in de meeste organisaties, en het beheer erover is veel zwakker.

Hoe vinden aanvallers blootgestelde machine-credentials?

Aanvallers vinden ze het vaakst in publieke coderepositories waar ontwikkelaars per ongeluk credentials committen (GitHub, GitLab, Bitbucket), in verkeerd geconfigureerde cloudopslag en omgevingsvariabele-dumps, in gecompromitteerde ontwikkelaarswerkstations en in CI/CD-pipeline-artefacten. Geautomatiseerde scantools doorzoeken publieke repositories en cloudmetadata-endpoints dag en nacht, en aanvallers draaien ze op schaal.

Wat is secrets management en welke tools verwerken het?

Secrets management is de praktijk van het opslaan, controleren van toegang tot, roteren en auditeren van machine-credentials. De belangrijkste platforms zijn HashiCorp Vault (open source en enterprise), AWS Secrets Manager, Azure Key Vault en GCP Secret Manager. Elk integreert met cloudinfrastructuur en kan rotatie automatiseren. De keuze hangt voornamelijk af van uw cloudomgeving.

Hoe verhoudt machineidentiteitsbeheer zich tot Zero Trust?

Zero Trust vereist dat elk verzoek wordt geverifieerd en geautoriseerd, ongeacht de herkomst. Voor machines betekent dat elke service-naar-service-aanroep een geldige, actuele credential draagt, alleen de benodigde rechten heeft en een auditspoor produceert. Zonder dat geldt Zero Trust voor gebruikers, maar niet voor de infrastructuur waarop ze vertrouwen.

Hoe lang zou een machine-identiteitscredential geldig moeten zijn?

Streef naar credentiallevensduur zo kort als de workload zelf. Voor gecontaineriseerde workloads is het doel uren of minuten, niet maanden. Credentials korter dan 24 uur laten aanvallers geen bruikbaar venster: zelfs als ze er een vinden, is het al verlopen. Uw platform dient credentials aan Kubernetes-pods en Lambda-functies bij het opstarten te verstrekken en deze bij het afsluiten in te trekken. API-sleutels voor integraties van derden vereisen leverancierscoördinatie om te roteren; 90 dagen is een realistisch minimum hiervoor.

Wat is het verschil tussen een machine-identiteit en een serviceaccount?

Een serviceaccount is een logische identiteit die wordt aangemaakt in een directory (Active Directory, Entra ID) zodat een machine of applicatie zich kan authenticeren met een gebruikersnaam en wachtwoord. Serviceaccounts zijn één type machine-identiteit. Machine-identiteit is de bredere categorie: het omvat TLS-certificaten, API-sleutels en cloud IAM-rollen naast directoryaccounts. Traditionele serviceaccounts gebruiken wachtwoordgebaseerde authenticatie. Moderne machine-identiteitsprogramma’s vervangen die wachtwoorden door certificaat- of tokengebaseerde credentials die het platform op een schema roteert.

Is machine-identiteitsbeheer hetzelfde als PAM (Privileged Access Management)?

PAM begon als een discipline voor bevoorrechte menselijke accounts: beheerderswachtwoorden en break-glass-credentials. Machine-identiteitsbeheer omvat de niet-menselijke equivalenten: elke credential die een applicatie of infrastructuurcomponent gebruikt om te authenticeren. De grens is smaller geworden. Grote PAM-leveranciers waaronder CyberArk en BeyondTrust omvatten nu machine-identiteitsfuncties, en veel organisaties beheren beide onder één programma. NIS2 artikel 21 en ISO 27001 bijlage A.8.2 (bevoorrechte toegangsrechten) vereisen beide controles over niet-menselijke bevoorrechte identiteiten.

Over de auteur

Ryland Deakin

Lead Consultant, Cyvra · CISM · CompTIA Security+ · MCP

Ryland leidt cybersecurity-, compliance- en IT-beheertrajecten voor gereguleerde organisaties in het VK, Nederland en Brazilië met meer dan 20 jaar ervaring, inclusief senior functies bij Microsoft, ING en de NHS. Volledig profiel

Hulpmiddelen voor machine-identiteitsbeheer op schaal

De toolingcategorie is goed gevestigd. Dit zijn de platforms die Europese bedrijven en gereguleerde omgevingen het meest gebruiken.

HashiCorp Vault (nu IBM) is de dominante open-source secretsmanager. Vault genereert op aanvraag kortlevende credentials, certificaten en API-sleutels, en trekt deze in wanneer de workload eindigt, waardoor de behoefte aan langlevende secrets verdwijnt. De Enterprise-editie voegt naamruimten en governancecontroles toe voor grotere implementaties. Financiële instellingen en grote technologiebedrijven waaronder Shopify en GitHub gebruiken het op schaal.

CyberArk Secrets Manager breidt het privileged access management-platform van het bedrijf uit naar machine-identiteiten. Het produceert een volledige audittrail van credentialstoegang en integreert met CI/CD-pipelines, waardoor het de standaardkeuze is in gereguleerde sectoren waaronder financiële dienstverlening. Prijsstelling is op enterprise-niveau.

AWS Secrets Manager past bij organisaties die al zijn toegewijd aan het AWS-ecosysteem. Het roteert RDS-wachtwoorden en API-sleutels op een gedefinieerd schema. Tegen circa €0,40 per secret per maand is het kosteneffectief voor AWS-native workloads, en rotatie van AWS-native services brengt geen extra kosten met zich mee.

Venafi Trust Protection Platform (nu CyberArk) pakt certificaatverspreiding aan, waarbij organisaties duizenden TLS-certificaten verzamelen en de vervaldatums uit het oog verliezen. Venafi houdt de certificaatverloop bij over het gehele IT-landschap en verlengt certificaten automatisch via integraties met DigiCert en Let’s Encrypt. Het is speciaal gebouwd voor organisaties waar certificaatbeheer spreadsheets en handmatige processen heeft overschreden.

Microsoft Entra Workload ID is de natuurlijke keuze voor Microsoft-gerichte omgevingen. Het federeert met GitHub Actions en andere CI/CD-tools zonder opgeslagen secrets, met behulp van tokengebaseerde authenticatie. Het past in organisaties die Entra ID al gebruiken voor menselijk identiteitsbeheer.

Toolselectie volgt de cloudtoewijding: AWS-omgevingen passen bij Secrets Manager, Azure-omgevingen bij Entra, en multi-cloud of on-premises estates bij Vault of CyberArk. Voer een inventarisatie uit voordat u zich aan een platform committeert. De meeste organisaties ontdekken meer machine-identiteiten dan verwacht, en dat basisgetal bepaalt welke tooling bij het landschap past.

Praat met Cyvra

Klaar om zicht te krijgen op uw machineidentiteiten?

We helpen organisaties de credentials te vinden, te beheren en te automatiseren die de meeste beveiligingstools over het hoofd zien.

Neem contact op Cybersecuritydiensten

Vrijwaring: Dit artikel is uitsluitend bedoeld voor algemene informatiedoeleinden en vormt geen juridisch, regelgevend of professioneel advies. Cyvra geeft geen garantie met betrekking tot de juistheid of volledigheid van deze inhoud. Lezers moeten onafhankelijk advies inwinnen dat geschikt is voor hun specifieke omstandigheden. Cyvra aanvaardt geen aansprakelijkheid voor enig verlies dat voortvloeit uit het vertrouwen op deze inhoud.