Volgens onderzoek van GitGuardian en CyberArk gaf 79% van de IT-beslissers aan een geheimlek te hebben ervaren, vergeleken met 75% in het rapport van vorig jaar. Tegelijkertijd is het aantal gelekte inloggegevens nog nooit zo hoog geweest, met alleen al in openbare GitHub-opslagplaatsen ruim 12,7 miljoen hardgecodeerde inloggegevens. Een van de meest verontrustende aspecten van dit rapport is dat meer dan 90% van de gevonden en gerapporteerde geldige geheimen langer dan vijf dagen geldig bleven.
Volgens hetzelfde onderzoek kost het organisaties gemiddeld 27 dagen om gelekte inloggegevens te herstellen. Combineer dat met het feit dat niet-menselijke identiteiten minstens 45:1 groter zijn dan menselijke identiteiten, en het is gemakkelijk in te zien waarom veel organisaties zich realiseren dat het stoppen van de wildgroei van geheimen betekent dat ze een manier moeten vinden om met deze machine-identiteitscrisis om te gaan. Helaas blijkt uit het onderzoek ook dat veel teams in verwarring zijn over wie de eigenaar is van de beveiliging van deze identiteiten. Het is een perfecte storm van risico.
Waarom duurt de rotatie zo lang?
Dus waarom duurt het zo lang voordat de inloggegevens worden gerouleerd als we weten dat dit een van de gemakkelijkste aanvalsroutes voor tegenstanders is? Een belangrijke factor die hieraan bijdraagt, is een gebrek aan duidelijkheid over hoe onze inloggegevens worden goedgekeurd. Machtigingen bepalen welke specifieke dingen een entiteit, zoals een Kubernetes-werklast of een microservice, met succes kan opvragen bij een andere service of gegevensbron.
Laten we niet vergeten wat het verhelpen van een incident met de wildgroei van geheimen inhoudt: u moet een geheim veilig vervangen zonder iets te breken of nieuwe, te ruime machtigingen te verlenen, wat mogelijk meer veiligheidsrisico’s voor uw bedrijf met zich mee zou brengen. Als je al volledig inzicht hebt in de levenscyclus van je niet-menselijke identiteiten en de bijbehorende geheimen, is dit een vrij eenvoudig proces om ze te vervangen door nieuwe geheimen met dezelfde machtigingen. Dit kan behoorlijk wat tijd in beslag nemen als je dat inzicht nog niet hebt, omdat je moet hopen dat de ontwikkelaar die het oorspronkelijk heeft gemaakt er nog steeds is en heeft gedocumenteerd wat er is gedaan.
Laten we eens kijken waarom het beheer van rechten vooral een uitdaging is in omgevingen die worden gedomineerd door NHI’s, de uitdagingen onderzoeken waarmee ontwikkelaars en beveiligingsteams worden geconfronteerd bij het balanceren van toegangscontrole en productiviteit, en bespreken hoe een model voor gedeelde verantwoordelijkheid zou kunnen helpen.
Wie is werkelijk de eigenaar van de wildgroei van geheimen?
De verspreiding van geheimen verwijst over het algemeen naar de verspreiding van toegangssleutels, wachtwoorden en andere gevoelige inloggegevens in ontwikkelomgevingen, opslagplaatsen en services zoals Slack of Jira. GitGuardian’s nieuwste Voice of the Practitioners-rapport benadrukt dat 65% van de respondenten de verantwoordelijkheid voor herstel volledig bij de IT-beveiligingsteams legt. Tegelijkertijd geeft 44% van de IT-leiders aan dat ontwikkelaars de best practices voor geheimbeheer niet volgen.
De wildgroei aan geheimen en de onderliggende kwesties van te veel toegestane, langlevende referenties zullen in deze kloof blijven vallen totdat we erachter komen hoe we beter kunnen samenwerken in een model van gedeelde verantwoordelijkheid.
Het perspectief van de ontwikkelaar op machtigingen
Ontwikkelaars staan onder enorme druk om snel functies te bouwen en te implementeren. Het zorgvuldig beheren van machtigingen, met best practices op het gebied van beveiliging, kan echter arbeidsintensief zijn. Elk project of elke applicatie heeft vaak zijn eigen unieke toegangsvereisten, die tijd vergen om te onderzoeken en goed in te stellen, waardoor het bijna voelt als een fulltime baan naast het werk om de applicaties te maken en te implementeren. Best practices voor het maken en beheren van machtigingen worden te vaak niet gelijkmatig over teams toegepast, worden zelden op de juiste manier gedocumenteerd of worden helemaal vergeten nadat de ontwikkelaar de applicatie werkend heeft gekregen.
Wat het probleem nog verergert, is dat ontwikkelaars in te veel gevallen simpelweg te veel rechten verlenen aan deze machine-identiteiten. Uit één rapport bleek dat slechts 2% van de verleende machtigingen daadwerkelijk wordt gebruikt. Als we nader bekijken waar ze mee te maken hebben, is het gemakkelijk te begrijpen waarom.
Denk bijvoorbeeld aan het beheren van rechten binnen Amazon Web Services. Het Identity and Access Management (IAM) -beleid van AWS staat bekend om zijn flexibiliteit, maar is ook complex en verwarrend om te navigeren. IAM ondersteunt verschillende beleidstypen (identiteitsgebaseerd, resourcegebaseerd en permissiegrenzen) die allemaal nauwkeurige configuraties vereisen. AWS biedt ook meerdere toegangspaden voor inloggegevens, waaronder IAM-rollen en KMS-toekenningen (Key Management Service), die elk hun eigen unieke toegangsconfiguraties hebben. Het leren van dit systeem is geen sinecure.
Een ander veel voorkomend voorbeeld van een service waarbij machtigingen moeilijk te beheren kunnen worden, is GitHub. API-sleutels kunnen machtigingen verlenen aan opslagplaatsen in verschillende organisaties, waardoor het een uitdaging wordt om de juiste toegangsgrenzen te garanderen. Eén enkele sleutel kan onbedoeld overmatige toegang bieden in verschillende omgevingen wanneer ontwikkelaars lid zijn van meerdere organisaties. De druk is groot om het goed te doen, terwijl de klok voortdurend tikt en de achterstand steeds groter wordt.
Waarom beveiligingsteams dit alleen niet kunnen oplossen
Het lijkt misschien logisch om beveiligingsteams de verantwoordelijkheid te geven voor het monitoren en doorgeven van geheimen; dit is tenslotte een veiligheidsprobleem. De realiteit is dat deze teams vaak niet over de gedetailleerde kennis op projectniveau beschikken die nodig is om veranderingen veilig door te voeren. Beveiligingsteams beschikken niet altijd over de context om te begrijpen welke specifieke machtigingen essentieel zijn om applicaties draaiende te houden. Een ogenschijnlijk kleine wijziging in de toestemming kan bijvoorbeeld een CI/CD-pijplijn kapot maken, de productie verstoren of zelfs een bedrijfsbrede trapsgewijze mislukking veroorzaken als de verkeerde service verdwijnt.
De verspreide aard van het geheimbeheer over teams en omgevingen vergroot ook het aanvalsoppervlak. Omdat niemand echt de leiding heeft, wordt het veel moeilijker om consistentie in toegangscontroles en audittrails te handhaven. Deze fragmentatie resulteert er vaak in dat overmatige of verouderde inloggegevens en de bijbehorende machtigingen veel te lang, mogelijk voor altijd, actief blijven. Het kan het moeilijk maken om te weten wie op een bepaald moment legitieme of onwettige toegang heeft tot welke geheimen.
Een gedeeld verantwoordelijkheidsmodel voor snellere rotatie
Ontwikkelaars en beveiligingsteams kunnen deze problemen helpen aanpakken door elkaar in het midden te ontmoeten en een model voor gedeelde verantwoordelijkheid op te bouwen. In een dergelijk model zijn ontwikkelaars meer verantwoordelijk voor het consistent beheren van hun machtigingen door middel van de juiste tools, zoals CyberArk’s Conjur Secrets Manager of Vault van HashiCorp, terwijl ze ook de machtigingen en reikwijdte van de noodzakelijke machtigingen beter documenteren op projectniveau. Beveiligingsteams moeten ontwikkelaars helpen door te werken aan het automatiseren van de rotatie van geheimen, te investeren in de juiste observatietools om duidelijkheid te krijgen over de staat van geheimen, en samen te werken met IT om langlevende inloggegevens helemaal te elimineren.
Als ontwikkelaars duidelijk documenteren welke machtigingen nodig zijn in hun vereisten, kan dit beveiligingsteams helpen snellere en nauwkeurigere audits uit te voeren en het herstel te versnellen. Als beveiligingsteams ervoor zorgen dat het gemakkelijkste en snelste algemene pad naar het implementeren van een nieuw niet-menselijk identiteitsgeheim ook de veiligste en meest schaalbare route is, zullen er veel minder incidenten zijn waarvoor noodroulatie nodig is, en wint iedereen.
Het doel van ontwikkelaars moet zijn om ervoor te zorgen dat het beveiligingsteam de inloggegevens in hun applicaties met vertrouwen en zelfstandig kan roteren of bijwerken, in de wetenschap dat ze de productie niet in gevaar brengen.
Belangrijke vragen die u moet beantwoorden rond toestemming
Wanneer u nadenkt over wat er moet worden gedocumenteerd, volgen hier een paar specifieke gegevenspunten om deze teamoverschrijdende inspanningen soepeler te laten verlopen:
- Wie heeft de referentie gemaakt? – Veel organisaties vinden het moeilijk om het eigendom van inloggegevens bij te houden, vooral wanneer een sleutel wordt gedeeld of gerouleerd. Deze kennis is essentieel om te begrijpen wie verantwoordelijk is voor het roteren of intrekken van inloggegevens.
- Tot welke bronnen heeft het toegang? – API-sleutels hebben vaak toegang tot een reeks services, van databases tot integraties van derden, waardoor het essentieel is om machtigingen tot het absoluut noodzakelijke minimum te beperken.
- Welke machtigingen verleent het? – Machtigingen variëren sterk, afhankelijk van rollen, op bronnen gebaseerd beleid en beleidsvoorwaarden. In Jenkins kan een gebruiker met de machtiging ‘Overall/Read’ bijvoorbeeld algemene informatie bekijken, terwijl ‘Overall/Administer’ volledige controle over het systeem geeft.
- Hoe kunnen we het intrekken of roteren? – Het gemak van intrekking verschilt per platform, en in veel gevallen moeten teams handmatig sleutels en machtigingen op verschillende systemen opsporen, wat het herstel bemoeilijkt en de blootstelling aan bedreigingen verlengt.
- Is de referentie actief? – Weten of een identificatie nog steeds in gebruik is, is van cruciaal belang. Wanneer NHI’s API-sleutels met een lange levensduur gebruiken, kunnen deze inloggegevens voor onbepaalde tijd actief blijven, tenzij ze op de juiste manier worden beheerd, waardoor aanhoudende toegangsrisico’s ontstaan.
Machtigingen zijn een uitdaging, maar we kunnen ze samen als één team beheren
Volgens het GitGuardian-rapport is de realiteit vaak heel anders, terwijl 75% van de respondenten vertrouwen uitdrukte in hun mogelijkheden voor geheimbeheer. De gemiddelde hersteltijd van 27 dagen weerspiegelt deze kloof tussen vertrouwen en praktijk. Het is tijd om opnieuw na te denken over de manier waarop we als organisatie geheimen en hun toestemmingen implementeren en communiceren.
Hoewel ontwikkelaars hard werken om de beveiliging en functionaliteit in evenwicht te brengen, vergroot het gebrek aan gestroomlijnde machtigingsprocessen en niet-gecentraliseerde of niet-gestandaardiseerde documentatiepaden de risico’s alleen maar. Beveiligingsteams alleen kunnen deze problemen niet effectief oplossen vanwege hun beperkte inzicht in projectspecifieke behoeften. Ze moeten bij elke stap nauw samenwerken met ontwikkelaars.
GitGuardian bouwt de volgende generatie geheime beveiligingstools, waarmee beveiligings- en IT-teams grip krijgen op de verspreiding van geheimen. Weten welke leesbare, langlevende inloggegevens in uw code en andere omgevingen worden weergegeven, is een noodzakelijke eerste stap om deze bedreiging te elimineren. Begin vandaag nog met GitGuardian.
