Stel je voor dat een aanvaller morgen toegang wil krijgen tot je systemen. Zou hij de moeite nemen om een ​​van je medewerkers te phishen? Waarschijnlijk niet. De makkelijkere route is om een ​​sleutel te pakken die je software ergens heeft laten rondslingeren. Zonder wachtwoord om te kraken en zonder MFA-prompt, vinden ze gewoon een inloggegeven en kunnen ze zo binnenkomen.
Dergelijke inloggegevens behoren meestal toe aan een niet-menselijke identiteit (NHI) . Dit zijn de softwarecomponenten die in plaats van mensen inloggen: een app die communiceert met een database, een script dat een API aanroept, een pipeline die code verzendt, een AI-agent die taken uitvoert. In plaats van een wachtwoord heeft elk van deze componenten een geheim, zoals een API-sleutel, een token of een certificaat, en dat geheim bewijst de identiteit ervan.
In bedrijfsomgevingen blijkt uit een rapport dat niet-menselijke identiteiten nu ongeveer 144 keer zo talrijk zijn als mensen, en dat de meeste daarvan haastig zijn aangemaakt en vervolgens vergeten. De vraag is dus niet of u een risico loopt op niet-menselijke identiteiten, want dat doet u al. De vraag is welke risico's u als eerste moet aanpakken.
Dergelijke aantallen zijn niet per ongeluk ontstaan, en het is belangrijk te begrijpen hoe ze zijn gegroeid. De cloud heeft grote applicaties opgesplitst in talloze kleine services die elk een eigen identiteit nodig hebben, automatisering genereert nu zelf inloggegevens en AI-agenten zijn de nieuwste generatie, die sneller toegang creëren dan wie dan ook kan bijhouden. Machines vermenigvuldigen zich nu met de snelheid van software, terwijl wij ze nog steeds met een menselijke snelheid beheren, en die discrepantie is precies waar het risico van identiteitsfraude door niet-menselijke bronnen ontstaat.
Een nadere blik op elk risico
Deze risico's zijn algemeen bekend in de sector. OWASP noemt de tien belangrijkste risico's in zijn Top 10 van niet-menselijke identiteiten voor 2025, en we zullen ze alle tien in dezelfde volgorde behandelen. Elk onderdeel legt het risico uit en wat je eraan kunt doen.
Onjuiste uitdiensttreding
Een 'verweesde' NHI is een inloggegevens die nog steeds bestaat, maar niet langer nodig is. Een project wordt afgerond, een dienst wordt uitgefaseerd of de persoon die het heeft ontwikkeld vertrekt, en de inloggegevens blijven gewoon functioneren zonder dat iemand er toezicht op houdt. Dit komt vaker voor dan je denkt: onderzoek wees uit dat 91 procent van de inloggegevens van voormalige werknemers nog steeds actief was.
Aanvallers richten zich juist op deze identiteiten omdat niemand ze in de gaten houdt. De oplossing is om het uitschakelen automatisch te laten verlopen, zodat het buiten gebruik stellen van een service ook de bijbehorende identiteiten uitschakelt. Geef elke NHI een benoemde eigenaar en voer regelmatig een opschoonactie uit om alles uit te schakelen wat geen functie meer vervult.
Geheime lekkage
Een geheim lekt wanneer een token, sleutel of certificaat terechtkomt op een plek waar het niet hoort, het klassieke voorbeeld hiervan is rechtstreeks in de broncode opgenomen. Het kan ook in configuratiebestanden, logbestanden en af ​​en toe in chatberichten of supporttickets terechtkomen. Een onderzoek in de praktijk wees uit dat 44 procent van de tokens onbeschermd aanwezig was op plekken zoals codecommits, tickets en chattools.
Het engste is dat er geen slimme truc nodig is. Wie het geheim vindt, kan het gewoon gebruiken. Dit heeft ook bekende bedrijven getroffen, niet alleen kleine teams. Houd geheimen daarom volledig buiten de code en bewaar ze in een kluis of geheimenbeheerder. Scan je repositories en logs op alles wat openbaar is gemaakt en roteer alles wat mogelijk is ontdekt. ​​Nog beter is het om lang bewaard geheim helemaal te verwijderen, zoals we hieronder in het gedeelte 'Lang bewaard geheim' bespreken.
Kwetsbare NHI van derden
Moderne softwareontwikkeling draait om externe tools: SaaS-applicaties, IDE-extensies en integraties. Elke tool krijgt doorgaans een eigen NHI (Network Health Information) met toegang tot uw systemen. Dat is handig, maar het betekent ook dat een zwak punt in de software van een ander ongemerkt uw probleem kan worden. Als een tool van een derde partij wordt gehackt of een slechte update uitbrengt, kunnen aanvallers direct toegang krijgen tot uw omgeving. Zo beginnen veel supply-chain-aanvallen .
Je kunt andermans code niet repareren, maar je kunt wel de schade beperken. Houd een lijst bij van alle integraties met derden, controleer de reikwijdte van elke integratie, beperk de machtigingen tot het minimum en verbreek de verbinding met de integraties die je niet meer gebruikt.
Onveilige authenticatie
Elke NHI (National Health Information) moet zich authenticeren bij de service waarmee deze verbinding maakt voordat toegang wordt verleend. Veel applicaties vertrouwen hiervoor nog steeds op zwakke of verouderde mechanismen, zoals legacy-protocollen of statische gedeelde geheimen die gemakkelijk te onderscheppen zijn. Wanneer het authenticatiemechanisme zwak is, kan een aanvaller zich voordoen als de gebruiker of zijn bevoegdheden ongemerkt verhogen.
De oplossing is om de oude methoden af ​​te schaffen en in plaats daarvan sterke, op standaarden gebaseerde methoden te gebruiken. Correct geconfigureerd zijn OAuth, wederzijdse TLS en kortstondige, op certificaten gebaseerde identiteiten veel veiliger dan een ouderwets, gedeeld wachtwoord dat nooit verandert.
Overbevoorrechte NHI
Dit is bijna overal het geval. Een NHI met te veel privileges heeft simpelweg meer toegang dan nodig is. Het komt zo vaak voor dat uit een onderzoek bleek dat 97 procent van de NHI's buitensporige privileges heeft. Dit gebeurt niet zonder reden: het verlenen van ruime toegang is de snelste manier om iets te laten werken, en niemand gaat later terug om die toegang te beperken.
Dit is cruciaal, omdat het bepaalt hoe ernstig een inbreuk kan zijn. Als een aanvaller een identiteit steelt met strikt afgebakende rechten, blijft de schade beperkt. Als een identiteit met te veel rechten wordt gestolen, erft de aanvaller al die extra bevoegdheden en wordt een kleine fout een groot incident. Pas het principe van minimale bevoegdheden toe door elke NHI alleen de toegang te geven die nodig is en controleer die rechten periodiek om te verwijderen wat niet langer wordt gebruikt.
Onveilige cloudimplementatieconfiguraties
CI/CD-pipelines vereisen toegang tot uw cloudomgeving om code automatisch te bouwen, te testen en te implementeren. Het risico ontstaat wanneer die toegang is geconfigureerd met statische inloggegevens, die kunnen uitlekken via repositories, buildlogs of configuratiebestanden. Een gecompromitteerde pipeline-referentie kan ernstige gevolgen hebben en een aanvaller langdurige, bevoorrechte toegang rechtstreeks tot de productieomgeving geven.
Het is beter om statische referenties over te slaan en in plaats daarvan OpenID Connect (OIDC) te gebruiken. Met OIDC gebruikt de pipeline zijn geverifieerde identiteit om een ​​kortstondig token te verkrijgen, waardoor er geen permanent geheim is dat gestolen kan worden. Valideer de claims van het token zorgvuldig en zorg ervoor dat alleen de workloads die u wilt toegang krijgen.
Langdurige geheimen
Een langdurig geheim is een inloggegeven dat zelden verloopt. Teams beschikken over dergelijke inloggegevens omdat het handmatig wijzigen ervan lastig is. Ze stellen daarom eenmalig een sleutel in en gaan verder. Het probleem ontstaat wanneer zo'n sleutel wordt gestolen. Omdat het inloggegeven nooit verloopt, kan de aanvaller het zo lang blijven gebruiken als hij wil. Een sleutel die twee jaar geleden is gelekt, kan vandaag de dag nog steeds geldig en misbruikt worden.
De oplossing is om geheimen een korte levensduur te geven. In plaats van een statische sleutel, geef je referenties uit die op aanvraag worden gegenereerd en binnen enkele minuten of uren verlopen. Certificaat- en sleutellevenscyclusbeheerders doen dit automatisch, en kortstondige certificaten doen hetzelfde voor machine-naar-machine-verbindingen. Hoe korter de levensduur, hoe kleiner de kans dat een aanvaller toeslaat.
Omgevingsisolatie
Het is goede praktijk om je ontwikkel-, test- en productieomgevingen gescheiden te houden. Dit risico ontstaat wanneer dezelfde identiteit in verschillende omgevingen wordt hergebruikt, vooral tussen test en productie. Testomgevingen zijn doorgaans het minst beveiligd, dus wanneer ze een identiteit delen met de productieomgeving, kan een beveiligingslek aan de zwakkere testzijde zich direct uitbreiden naar de productieomgeving.
Zorg voor een strikte scheiding tussen de omgevingen. Wijs aparte identiteiten en geheimen toe voor ontwikkeling, testen en productie, en bewaar deze gescheiden. Deel geen inloggegevens tussen omgevingen, zodat inloggegevens uit de testomgeving nooit de productieomgeving kunnen bereiken.
NHI-hergebruik
NHI-hergebruik vindt plaats wanneer dezelfde identiteit of hetzelfde geheim wordt gedeeld tussen verschillende applicaties, services of componenten, vaak omdat het creëren van een aparte identiteit voor elke workload tijdrovend is. Dit gemak brengt risico's met zich mee. Als die ene identiteit op één plek wordt gecompromitteerd, kan een aanvaller dezelfde inloggegevens gebruiken om toegang te krijgen tot elk ander systeem dat ervan afhankelijk is, waardoor een kleine inbreuk snel kan uitgroeien tot een grote.
Geef elke workload een eigen, specifieke identiteit en geheim, zodat een inbreuk beperkt blijft tot één enkele service. Houd bij welke identiteit bij welke applicatie hoort, vermijd het delen van inloggegevens tussen componenten en roteer ze onafhankelijk van elkaar. Unieke identiteiten maken het bovendien veel gemakkelijker om de toegang voor één service in te trekken zonder de rest te verstoren.
Menselijk gebruik van NHI
Het gebruik van NHI door mensen vindt plaats wanneer een persoon een niet-menselijke identiteit, zoals een serviceaccount of API- token, gebruikt om handmatige taken uit te voeren die eigenlijk onder hun eigen account zouden moeten vallen. Dit is eenvoudig omdat het serviceaccount vaak al brede toegangsrechten heeft. Omdat de meeste platforms geen onderscheid kunnen maken tussen een mens en een workload die dezelfde identiteit gebruikt, lijken hun activiteiten vrijwel identiek. Het resultaat is dat mensen verhoogde privileges krijgen, er een zwak controletraject is en acties moeilijk te herleiden zijn als er iets misgaat.
Houd menselijke en niet-menselijke identiteiten gescheiden. Geef mensen hun eigen accounts met passende rollen voor handmatig werk en onderhoud, en reserveer niet-menselijke identiteiten voor geautomatiseerde processen. Monitor hoe niet-menselijke identiteiten worden gebruikt, zodat menselijke activiteiten opvallen, en pas contextbewuste toegangscontroles toe die een persoon die zich aanmeldt als serviceaccount markeren of blokkeren.
We hebben nu alle risico's met betrekking tot niet-menselijke identiteiten doorgenomen, van gelekte geheimen tot mensen die voor handmatige taken afhankelijk zijn van machine-identiteiten . Het is veel informatie om in één keer te verwerken, dus het helpt om even afstand te nemen en ze in hun geheel te bekijken.
Heb je het patroon opgemerkt?
Als we de tien risico's samen bekijken, komt een duidelijk patroon naar voren. Het zijn niet echt tien afzonderlijke problemen. Het zijn dezelfde drie gewoonten die zich in verschillende vormen manifesteren: geheimen die te lang bewaard blijven, identiteiten met te veel toegang en identiteiten die nooit worden opgeruimd. Gelekte geheimen, statische sleutels, accounts met te veel privileges en accounts die niet meer in gebruik zijn, wijzen allemaal op dezelfde kernproblemen.
Je hebt geen tien verschillende tools nodig. Je hebt een paar solide gewoontes nodig die je overal toepast: weet wat je hebt, houd de toegang beperkt, zorg ervoor dat inloggegevens kort geldig zijn en schakel apparaten uit wanneer ze niet meer nodig zijn. En als je een startpunt zoekt dat een aantal van deze punten tegelijk aanpakt, kijk dan eens naar je certificaten. Certificaten zijn machine-identiteiten die je al in duizenden aantallen gebruikt, en ze staan ​​precies in het midden van deze lijst. Als je ze niet gebruikt, worden ze langdurig geldig, veroorzaken ze storingen wanneer ze ongemerkt verlopen en stapelen ze zich sneller op dan iemand handmatig kan bijhouden.
Als je ze onder controle krijgt, sluit je geruisloos een groot deel van je NHI-risico uit. Het beheren hiervan op grote schaal is meer dan een handmatige klus , en dat is precies waar een speciaal ontwikkeld platform zijn waarde bewijst.
Hoe encryptieconsultancy kan helpen
Het op orde brengen van uw certificaten is de eenvoudigste manier om snel een groot deel van het NHI-risico te verminderen, en Encryption Consulting staat klaar om u daarbij te helpen met CertSecure Manager.
Een van de grootste obstakels bij het beheer van de levenscyclus van certificaten is het gebrek aan inzicht. Veel organisaties beschikken niet over een volledig overzicht van hun certificaten, waardoor het lastig is om de eigenaar te achterhalen, vervaldatums te bewaken of risico's in te schatten. Onze CertSecure Manager lost dit probleem op door continu certificaten te detecteren in cloudservices, servers, applicaties, loadbalancers en andere bedrijfssystemen. Zo kunnen organisaties voorheen onbekende certificaten opsporen en beheren. Dit vermindert het aantal onbekende of onbeheerde certificaten, die vaak operationele blinde vlekken vormen.
Zodra certificaten zijn gevonden, worden ze samengevoegd in een centrale inventaris die een overzicht biedt van de status, het eigenaarschap, de locatie en de levenscyclus van de certificaten. Hierdoor kunnen beveiligings- en operationele teams gemakkelijker inzicht krijgen in welke certificaten er zijn, wie ervoor verantwoordelijk is en wanneer actie vereist is.
Om organisaties te helpen bij het beheren van de toenemende aantallen verlengingen, ondersteunt ons platform geautomatiseerde verlengingsworkflows die handmatige inspanningen verminderen en de vervanging van certificaten stroomlijnen. Door levenscyclusprocessen te automatiseren, kunnen organisaties het risico op storingen als gevolg van verlengingen verlagen en de administratieve last voor interne teams verminderen.
Het platform biedt ook risicobewaking voor verlopen certificaten met proactieve waarschuwingen en meldingen voor certificaten die bijna verlopen. Hierdoor kunnen teams zich richten op het oplossen van problemen voordat deze de dienstverlening beïnvloeden.
Naarmate de levensduur van certificaten richting de 47 dagen gaat, wordt schaalbaarheid steeds belangrijker. Ons platform is ontworpen om grote en groeiende certificaatinventarissen te ondersteunen in cloud-, hybride en on-premises omgevingen, waardoor organisaties inzicht en controle behouden, zelfs wanneer de certificaatactiviteit aanzienlijk toeneemt.
Door ontdekking, inzicht, monitoring en automatisering te combineren, biedt ons platform een ​​praktische aanpak voor het beheren van certificaten in een omgeving waar handmatig certificaatbeheer steeds moeilijker vol te houden is.
En als u een stap terug wilt doen en het grotere plaatje wilt bekijken, biedt Encryption Consulting ook adviesdiensten op het gebied van encryptie . Het team kan uw huidige situatie beoordelen en helpen bij het opstellen van een duidelijke strategie en routekaart, zodat uw volledige machine-identiteits- en encryptieprogramma hand in hand vooruitgaat. CertSecure Manager helpt u bij het beheer van de certificaatlevenscyclus, en de adviesdiensten op het gebied van encryptie geven vorm aan de bredere strategie hieromheen.
Conclusie
Niet-menselijke identiteiten vormen nu de grootste groep in uw omgeving, en de tien bovengenoemde risico's zijn de risico's waar aanvallers zich doorgaans als eerste op richten. Het goede nieuws is dat ze allemaal terug te voeren zijn op een paar fundamentele gewoonten, waardoor u prioriteiten kunt stellen in plaats van te proberen alles tegelijk aan te pakken.
Je hoeft niet alles tegelijk aan te pakken. Een praktische eerste stap is het buiten gebruik stellen van identiteiten die niemand meer gebruikt, omdat die het gemakkelijkst te dichten zijn. Haal vervolgens je geheimen uit de broncode en bewaar ze in een kluis waar ze regelmatig worden geroteerd. Zodra dat geregeld is, beperk je de toegang tot alles wat verder gaat dan wat het werk daadwerkelijk vereist. Het beheren van je certificaten is de meest effectieve stap, omdat je daarmee meerdere risico's in één keer wegneemt. Als je hierbij deskundige hulp wilt, kunnen we je laten zien hoe CertSecure Manager elk certificaat in je omgeving detecteert, vernieuwt en beheert.
