Veilig beheer van secrets en omgevingsvariabelen

Beheerders van geheimen zijn speciaal ontwikkelde systemen voor het opslaan, roteren en controleren van toegang tot geheimen. Toonaangevende oplossingen zijn onder andere HashiCorp Vault (open source en enterprise), AWS Secrets Manager, Azure Key Vault en Google Cloud Secret Manager. Applicaties authenticeren tijdens runtime bij de beheerder van geheimen, halen het geheim op en gebruiken het — geheimen worden nooit op schijf of in omgevingsvariabelen opgeslagen. Alle toegang wordt vastgelegd in logboeken, zodat kan worden gecontroleerd wie welk geheim en wanneer heeft geraadpleegd.

Een belangrijk voordeel van beheerders van geheimen ten opzichte van omgevingsvariabelen is automatische rotatie. AWS Secrets Manager kan wachtwoorden van RDS-databases automatisch volgens een schema roteren (bijvoorbeeld elke 30 dagen), zonder dat de applicatie opnieuw hoeft te worden geïmplementeerd. De beheerder van geheimen werkt het wachtwoord in de database bij en werkt tegelijkertijd het opgeslagen geheim bij. Applicaties die bij elke verbinding geheimen ophalen, ontvangen automatisch de nieuwe aanmeldingsgegevens. Zo verdwijnt de gangbare praktijk van 'permanente' wachtwoorden voor serviceaccounts die nooit worden geroteerd.

De eerste verdedigingslinie tegen geheimen die worden vastgelegd, is een goed onderhouden .gitignore-bestand dat alle bestanden uitsluit die geheimen kunnen bevatten. .gitignore voorkomt echter alleen toekomstige vastleggingen — geheimen die al zijn vastgelegd, blijven in de git-geschiedenis staan. Als geheimen per ongeluk worden vastgelegd, moet je er onmiddellijk van uitgaan dat ze zijn gecompromitteerd: roteer het geheim en gebruik eventueel hulpmiddelen zoals git filter-repo om de geschiedenis te herschrijven (vereist voor naleving, maar op zichzelf onvoldoende omdat het geheim mogelijk al is buitgemaakt).

Bestanden voor infrastructuur als code (IaC) (Terraform, CloudFormation, Kubernetes-manifesten) bevatten vaak geheimen — verbindingsreeksen voor databases, API-sleutels in declaraties van omgevingsvariabelen en TLS-certificaten. Deze bestanden worden vaak vastgelegd in versiebeheer, waardoor het risico ontstaat dat geheimen worden blootgesteld. Oplossingen zijn onder andere dynamische geheimen van Vault (Vault genereert specifiek voor elke Terraform-uitvoering een referentie met een korte levensduur), Kubernetes Secrets (opgeslagen in etcd en versleuteld tijdens opslag) en external-secrets-operator, die tijdens runtime synchroniseert vanuit een geheimenbeheerder naar Kubernetes.

Elke toepassing of service mag alleen toegang hebben tot de geheimen die deze specifiek nodig heeft — het principe van minimale bevoegdheden toegepast op geheimen. Een webtoepassing heeft het databasewachtwoord nodig, maar niet de persoonlijke sleutel van de CA. Een rapportagetaak heeft alleen-lezenreferenties voor de database nodig, geen schrijftoegang. Geheimenbeheerders dwingen dit af met toegangsbeleid waarin staat welke identiteiten (IAM-rollen, serviceaccounts, AppRoles) welke geheimen mogen lezen. Alle toegang wordt vastgelegd voor controledoeleinden.

Dynamische geheimen worden op aanvraag gegenereerd voor een specifieke aanvrager en verlopen automatisch. Vault kan een tijdelijke database-referentie genereren die 1 uur geldig is en is gekoppeld aan de specifieke service die erom heeft gevraagd. Na het verlopen wordt de referentie automatisch ingetrokken door de database. Hierdoor zijn er geen statische referenties met een lange levensduur die kunnen worden gestolen — zelfs als een aanvaller een dynamische referentie onderschept, verloopt deze snel en is deze in de controleregisters gekoppeld aan de identiteit van de aanvrager.

CI/CD-pijplijnen hebben vaak geheimen nodig — referenties van cloudproviders voor implementatie, tokens voor Docker-registers en ondertekeningssleutels. Sla geheimen nooit op in pijplijnscripts of configuratiebestanden. Gebruik in plaats daarvan de ingebouwde geheimenopslag van het pij platform (GitHub Actions Secrets, GitLab CI Variables, Jenkins Credentials Store) of haal tijdens runtime geheimen op uit een centrale kluis met behulp van een machine-identiteit. Markeer geheimvariabelen als gemaskeerd in logboeken om te voorkomen dat ze per ongeluk in de uitvoer van een build zichtbaar worden.

Geheimenbeheerders leveren uitgebreide controleregisters van elke gebeurtenis waarbij toegang tot een geheim plaatsvindt: welke identiteit welk geheim heeft benaderd, vanaf welk IP-adres, op welk tijdstip en of de toegang geslaagd of geweigerd was. Deze logboeken zijn essentieel voor naleving (SOC 2, PCI-DSS) en voor het reageren op incidenten. Wanneer wordt vermoed dat een referentie is gecompromitteerd, laten de controleregisters zien welke systemen deze hebben gebruikt en wanneer — zodat je mogelijk getroffen systemen snel kunt identificeren en beslissingen over indamming kunt nemen.

Pre-commit-hooks zijn scripts die automatisch worden uitgevoerd voordat elke git-commit definitief wordt gemaakt. Zo kunnen geheimen worden gedetecteerd voordat ze in de geschiedenis van het versiebeheer terechtkomen. Hulpmiddelen zoals detect-secrets (Yelp), GitLeaks en git-secrets (AWS) kunnen als pre-commit-hooks worden geïntegreerd en geënsceneerde bestanden scannen op patronen die overeenkomen met API-sleutels, verbindingsreeksen, persoonlijke sleutels en JWT-tokens. Als een geheim wordt gedetecteerd, wordt de commit geweigerd en krijgt de ontwikkelaar het verzoek de referentie te verwijderen. Met het pre-commit-framework kun je hookconfiguraties eenvoudig toevoegen en delen binnen teams.

In deze les heb je geleerd dat hardgecodeerde geheimen in broncode moeten worden verwijderd en vervangen door geheimenbeheerders zoals Vault of AWS Secrets Manager, dat automatische rotatie referenties met een lange levensduur verwijdert die aanvallers zelfs na een eerste compromittering kunnen misbruiken, en dat dynamische geheimen en toegangsbeleid met minimale bevoegdheden de waarde beperken van elk afzonderlijk geheim dat wordt blootgesteld. Hierna bekijken we beveiliging van afhankelijkheden en analyse van softwaresamenstelling.