Een kijk op het begrijpen van bestuur van niet-menselijke identiteiten

Kan een identiteit bestaan zonder te worden verwezen door een andere identiteit? Hoe zouden we dat weten?

Dat lijkt misschien wat filosofisch voor een beveiligingstechnologie artikel, maar het is een belangrijk punt om in gedachten te houden bij het behandelen van het onderwerp van niet-menselijke identiteiten. Een betere vraag op het gebied van beveiliging zou eigenlijk zijn, “Zou een identiteit moeten bestaan als er niet mee kan worden geïnterageerd?” We kunnen misschien niet het antwoord vinden op die eerste vraag, aangezien het bewijzen van de aard van de realiteit een beetje buiten het bereik van de informatica ligt. Desalniettemin zijn veel mensen druk bezig geweest met het bouwen van de NHI Governance tools om te bepalen of een machine-identiteit bestaat, waarom het bestaat, en antwoord te geven op de vraag of het zou moeten bestaan. 

De toekomst van het elimineren van geheimen betekent grip krijgen op de levenscycli en onderlinge afhankelijkheden van de niet-menselijke identiteiten die vertrouwen op geheimen. Maar waarom nu? Laten we even teruggaan en enkele van onze aannames over NHIs en hun bestaan opnieuw bekijken.

Wat Zijn Niet-Menselijke Identiteiten?

Voordat we verder gaan, laten we NHI definiëren in de context van dit gesprek.

In the simplest terms, a non-human identity, also commonly referred to as a machine identity or a workload identity, is any entity that is not human and can perform an action within your system, most commonly interacting exclusively with other non-humans.

Dit kan een Kubernetes-pod zijn die moet communiceren met een gegevensbron en de verwerkte gegevens naar een rapportagesysteem moet sturen. Dit kan een Internet der Dingen (IoT) sensor zijn die gegevens levert aan een centrale server. Dit kan een Slack-gebaseerde chatbot zijn. Als er geen directe menselijke input nodig is na de initiële creatie voor de entiteit om werk te kunnen verrichten, dan zouden we die identiteit als ‘niet-menselijk’ moeten beschouwen.

Het enige dat al deze voorbeelden gemeen hebben, is dat ze interageren met een ander systeem. Als we willen dat ze communiceren met de hele wereld, is dat gemakkelijk, omdat we eenvoudig wijzen naar de andere niet-menselijke identiteiten en programmatisch beschrijven hoe ze moeten interageren. We willen echter waarschijnlijk dat deze systemen veilig communiceren, waarbij alleen specifieke identiteiten onder specifieke omstandigheden worden geautoriseerd. Dit heeft de evolutie van geheimen voor toegangsbeheer gedreven, van eenvoudige gebruikersnaam/wachtwoord combinaties tot API-sleutels tot certificaten.

Toegegeven, dat is een brede definitie van NHI. We kunnen echter verfijnen waar we ons zorgen over maken met machine-identiteiten door een stap terug te doen en te overwegen hoe deze entiteiten zich tot elkaar verhouden door de lens van hun geheimen, die toegang en communicatie mogelijk maken.

Alle NHI’s verbinden met andere systemen

Kunt u een zelfstandige applicatie bouwen die geen invoer accepteert, geen uitvoer produceert en geen aanspreekbare interface heeft? Bestaat er zo’n applicatie buiten een gedachte-experiment? Hoewel het leuk is om erover na te denken, is de realiteit dat alle NHI’s waar we om geven bestaan om te communiceren met andere identiteiten.

NHI’s vereisen van nature verbindingen met andere systemen en diensten om hun doel te vervullen. Deze onderlinge verbondenheid betekent dat elke NHI een knooppunt wordt in een web van onderlinge afhankelijkheden. Vanuit een NHI-governance perspectief vereist dit het onderhouden van een nauwkeurige en dynamische inventaris van deze verbindingen om de bijbehorende risico’s te beheren. Bijvoorbeeld, als een enkele NHI gecompromitteerd is, waar verbindt deze zich mee, en wat zou een aanvaller kunnen benaderen om later naar binnen te bewegen?

Een goede NHI-bestuur moet tools bevatten om deze relaties in kaart te brengen en te monitoren. Hoewel er veel manieren zijn om dit handmatig te doen, is wat we eigenlijk willen een geautomatiseerde manier om te bepalen wat met wat verbonden is, waarvoor het wordt gebruikt en door wie. Bij het denken in termen van het beveiligen van onze systemen, kunnen we een ander belangrijk feit over alle NHIs in een beveiligde applicatie benutten om die kaart op te bouwen, ze hebben allemaal, noodzakelijkerwijs, geheimen.

Alle Beveiligde NHIs Moeten een Geheim Hebben

Om vertrouwde communicatie tussen twee NHIs tot stand te brengen, moet er een uniek geheim, zoals een API-sleutel, token of certificaat, bestaan voor die entiteiten om zich te authenticeren. We kunnen het geheim gebruiken om de identiteit van een NHI te bewijzen en het in het ecosysteem in kaart te brengen. De vraag is dan, waar moeten we kijken voor deze geheimen?

In de moderne onderneming, vooral in grotere, zijn er in feite slechts twee plaatsen waar een geheim kan worden bewaard. Uw eerste optie is de beste praktijk en veiligste optie: een geheimenbeheersysteem, zoals CyberArk’s Conjur, Vault van HashiCorp of AWS Secrets Manager. De andere optie is veel minder veilig maar helaas al te gebruikelijk: buiten een kluis, in code of configuratie in platte tekst.

Enterprise geheimbeheerplatforms, vaak aangeduid als kluizen, zijn cruciaal voor het opslaan en beschermen van geheimen die door NHI’s worden gebruikt. Kluizen kunnen een enkele bron van waarheid bieden voor alle geheimen, waardoor ervoor gezorgd wordt dat ze versleuteld zijn in rust, strikt gecontroleerd op toegang, en gemonitord voor ongeautoriseerde toegangspogingen. Dit gaat ervan uit dat je gestandaardiseerd hebt op een enkel enterprise geheimbeheerplatform. De meeste organisaties hebben echter vaak meerdere kluizen tegelijkertijd in gebruik, wat synchronisatie tussen alle kluizen een extra uitdaging maakt.

Teams kunnen alle bestaande machine-identiteiten in kaart brengen op basis van het bestaan van deze geheimen. Voor ondernemingen met meerdere geheimbeheeroplossingen moet je weten welke kluizen wel en geen geheim bevatten en om de overhead van het redundant opslaan van dezelfde sleutel over verschillende kluizen te verminderen.

Alle NHI Geheimen Hebben een Oorsprongsverhaal

Machines kunnen zichzelf geen machtigingen en toegang verlenen. Elke machine-identiteit is gecreëerd door of vertegenwoordigt een menselijke identiteit. Governance van NHI’s moet het bijhouden van geheimcreatie omvatten om ervoor te zorgen dat elk geheim traceerbaar is naar zijn oorsprong, veilig wordt verspreid en verbonden is met een legitieme identiteit. Hoewel dit aspect kan worden verantwoord met het juiste gebruik van een geheimbeheerplatform, blijft onze data ons vertellen dat een bepaald percentage geheimen elk jaar lekt omdat we deze kluizenoplossingen niet consistent gebruiken.

We weten uit jarenlange ervaring in het helpen van teams bij het oplossen van incidenten dat de maker van een geheim bijna altijd degene zal zijn die de referentie voor het eerst in een ecosysteem introduceert. We kunnen ook zien aan de hand van de codegeschiedenis of andere systeemtijdstempelinformatie wanneer dit voor het eerst is gezien, wat het meest waarschijnlijke tijdstip is waarop het is gemaakt of op zijn minst op een zinvolle manier in het bestaan is gekomen.

Dit is een cruciaal detail dat misschien nooit ergens anders op de juiste manier is gelogd of gedocumenteerd. Zodra je begrijpt wie een geheim heeft gemaakt om te kunnen profiteren van een NHI, begrijp je echt het begin van onze NHI-levenscyclus.

Alle NHI-geheimen moeten een bepaalde set machtigingen verlenen

Elk NHI-geheim moet bij creatie een bepaalde set machtigingen krijgen. De reikwijdte bepaalt welke acties een identiteit kan uitvoeren en op welke systemen. Dit maakt machtigingsbereik en handhaving cruciale onderdelen van governance.

Kortom, twee risico’s maken het begrijpen van de reikwijdte van een geheim cruciaal voor de beveiliging van een onderneming. Het eerste is dat verkeerd geconfigureerde of over-geprivilegieerde geheimen onbedoeld toegang kunnen verlenen tot gevoelige gegevens of kritieke systemen, waardoor het aanvalsoppervlak aanzienlijk wordt vergroot. Stel je voor dat je per ongeluk schrijfrechten verleent aan een systeem dat toegang heeft tot de PII van je klanten. Dat is een tikkende tijdbom die wacht om door een bedreigingsacteur te worden gevonden en misbruikt.

Ook verontrustend is dat wanneer een geheim wordt gelekt of gecompromitteerd, een team het niet kan vervangen totdat ze eerst begrijpen hoe die rechten waren geconfigureerd. Stel bijvoorbeeld dat je weet dat het geheim van een missiekritieke microservice per ongeluk is gepusht naar een openbare GitHub-repo. In dat geval is het slechts een kwestie van tijd voordat het ontdekt en gebruikt zal worden door iemand buiten jouw organisatie. In ons recente Voice of the Practitioner-rapport gaven IT-besluitvormers toe dat het gemiddeld 27 dagen duurde om deze kritieke geheimen te roteren. Teams zouden in seconden of minuten moeten kunnen handelen, niet in dagen.

Tools die aanvullende context bieden over gedetecteerde geheimen, inclusief hun rollen en rechten, zijn nodig. Snel begrijpen welke activa blootgesteld zijn wanneer een lek optreedt en welke potentiële schade een dreigende actor kan toebrengen, is van groot belang bij het reageren op een incident. Precies weten hoe je het vanuit een dashboardweergave of API-oproep kunt vervangen, kan het verschil betekenen tussen een inbreuk en een gefrustreerde aanvaller die ontdekt dat de sleutel die ze hebben ongeldig is.

Alle NHI-geheimen moeten worden geroteerd

Een machine-identiteit kan, en waarschijnlijk zou moeten, gedurende zijn levensduur veel geheimen hebben. Als referenties maanden of jaren blijven bestaan, of in het ergste geval voor altijd, wordt de blootstelling of compromittering van NHI-geheimen steeds waarschijnlijker. Handmatige rotatie is foutgevoelig en operationeel belastend, vooral in omgevingen met duizenden NHIs. Het automatiseren van het geheimrotatieproces is een hoeksteen van NHI-beheer, waardoor wordt gegarandeerd dat geheimen worden vernieuwd voordat ze verlopen of worden gelekt.

Voor een van de geheimen in uw kluis moet rotatie een eenvoudige kwestie zijn van scripting. De meeste platforms voor geheimenbeheer bieden scripts of een andere mechanisme om de delicate dans van veilig vervangen en intrekken van het oude geheim te beheren.

Maar wat te denken van de NHI-geheimen die buiten deze kluizen leven, of misschien hetzelfde geheim dat verspreid is over meerdere kluizen? Een goed geheimscanningsplatform heeft naadloze integratie met deze kluizen nodig, zodat uw team deze geheimen gemakkelijker kan vinden en veilig kan opslaan in de geheimenmanager en de weg kan bereiden voor geautomatiseerde rotatie. De referentie-implementatie van GitGuardian met CyberArk’s Conjur gaat verder in op hoe u het volledige opslag- en rotatieproces volledig kunt automatiseren.

Door alle NHI’s te identificeren en te weten wanneer ze zijn aangemaakt, kunnen we ook voorspellen wanneer ze moeten worden vervangen. Terwijl elk team precies zal beoordelen hoe lang elk geheim moet leven, zijn alle geheimen die nooit zijn vervangen na hun creatie rijp om te worden vervangen. Elk geheim ouder dan een jaar, of voor sommige mission-critical systemen, een paar dagen, moet ook prioriteit krijgen voor vervanging zo snel mogelijk.

Alle NHI’s Hebben een Levensduur

NHI’s, net als hun menselijke tegenhangers, hebben een eindige levenscyclus. Ze kunnen worden buiten gebruik gesteld wanneer een dienst wordt gepensioneerd, vervangen of niet langer nodig is. Zonder de deactivatie en opruiming van NHI’s aan te pakken om de persistentie van ongebruikte geheimen of verouderde verbindingen te voorkomen, creëren we beveiligingsblinde vlekken. Maar hoe weten we wanneer we aan het eind van de rit zijn voor een NHI, vooral als het geheim geldig blijft?

Een antwoord is dat het niet langer moet bestaan wanneer een NHI niet langer verbinding maakt met een ander actief systeem. Dit zorgt ervoor dat aanvallers geen verouderde NHI-geheimen kunnen uitbuiten om een voet aan de grond te krijgen in uw omgeving. Vergeet niet dat aanvallers zich niet bekommeren om hoe een geheim op de juiste manier moet worden gebruikt; ze geven alleen om wat ze ermee kunnen doen.

Door alle relaties die de geheimen van een NHI mogelijk maken in kaart te brengen, kunt u identificeren wanneer een systeem niet langer is verbonden met een andere identiteit. Zodra er geen manieren meer zijn voor een identiteit om te communiceren, dan moet het en zijn geheimen niet langer bestaan. Dit betekent ook dat het geheim niet langer hoeft te worden opgeslagen in uw geheimenbeheerders, wat u één ding minder geeft om op te slaan en te beheren.

Het Begrijpen van de Wereld Rondom Uw NHI’s is Cruciaal voor Beveiliging

In 2022, toezicht van CyberArk toonde aan dat voor elke menselijke identiteit in een omgeving, minstens 45 niet-menselijke identiteiten beheerd moeten worden. Die verhouding ligt vandaag de dag waarschijnlijk dichter bij 1 op 100 en neemt voortdurend toe. De beste tijd om je te verhouden tot je NHI-beheer en levenscyclusbeheer was jaren geleden. De volgende beste tijd is nu.

Het is tijd voor een volledige benadering van de beveiliging van niet-menselijke identiteiten, waarbij niet alleen in kaart wordt gebracht waar je NHI-geheimen zijn, maar, net zo belangrijk, welke andere NHI’s verbonden zijn. We zijn over de streep, in alle sectoren, om NHI-beheer op grote schaal te implementeren. Het vinden en juist opslaan van je geheimen is slechts het begin van het verhaal. We moeten beter documenteren en begrijpen wat de reikwijdte van NHI-geheimen is, hun leeftijd, wie ze heeft geïmplementeerd, en andere contextuele informatie, zoals wanneer ze moeten worden vernieuwd.

Ook al overtreffen machine-identiteiten het aantal mensen, er is geen reden om alleen aan dit probleem te werken; we zitten er allemaal samen in.