Sikker håndtering af secrets og miljøvariabler

Hardkodede hemmeligheder — API-nøgler, databaseadgangskoder, private TLS-nøgler og OAuth-tokens, der er indlejret direkte i kildekoden — er en af de mest almindelige og forebyggelige sikkerhedssårbarheder. Hemmeligheder i kildekoden bliver eksponeret i versionsstyringens historik (selv efter sletning), er synlige for alle udviklere med adgang til repositoriet og lækkes ofte, når repositorier ved en fejl gøres offentligt tilgængelige. Værktøjer som GitGuardian og truffleHog scanner løbende platforme som GitHub for lækkede hemmeligheder.

Miljøvariabler fjerner hemmeligheder fra kildekoden ved at indsætte dem under kørsel via værtsoperativsystemet eller containerorkestratoren. Applikationen læser os.environ['DB_PASSWORD'] i stedet for en hardkodet værdi. Det er bedre end hardkodning, men miljøvariabler har svagheder: De vises i proceslister, nedarves af underprocesser, ender ofte i nedbrudsdumps og fejlfindingslogge og kræver manuel rotation. De er velegnede til udvikling, men er ikke tilstrækkelige alene til håndtering af hemmeligheder i produktion.

Systemer til håndtering af hemmeligheder er specialbyggede systemer til lagring, rotation og kontrol af adgang til hemmeligheder. Blandt de førende løsninger er HashiCorp Vault (open source og enterprise), AWS Secrets Manager, Azure Key Vault og Google Cloud Secret Manager. Applikationer godkender sig over for systemet til håndtering af hemmeligheder under kørsel, henter hemmeligheden og bruger den — ingen hemmeligheder gemmes nogensinde på disk eller i miljøvariabler. Al adgang logges, så det er muligt at kontrollere, hvem der har tilgået hvilken hemmelighed og hvornår.

En vigtig fordel ved systemer til håndtering af hemmeligheder frem for miljøvariabler er automatisk rotation. AWS Secrets Manager kan automatisk rotere RDS-databaseadgangskoder efter en plan (f.eks. hver 30. dag) uden at kræve, at applikationen implementeres igen. Systemet til håndtering af hemmeligheder opdaterer adgangskoden i databasen og den gemte hemmelighed samtidigt. Applikationer, der henter hemmeligheder ved hver forbindelse, modtager automatisk de nye legitimationsoplysninger. Det eliminerer den almindelige praksis med »permanente« adgangskoder til tjenestekonti, som aldrig roteres.

Den første forsvarslinje mod committede hemmeligheder er en korrekt vedligeholdt .gitignore-fil, der udelukker alle filer, som kan indeholde hemmeligheder. .gitignore forhindrer dog kun fremtidige commits — hemmeligheder, der allerede er committet, bliver i git-historikken. Hvis hemmeligheder ved en fejl bliver committet, skal de straks behandles som kompromitterede: rotér hemmeligheden, og brug derefter eventuelt værktøjer som git filter-repo til at omskrive historikken (påkrævet af hensyn til compliance, men utilstrækkeligt alene, eftersom hemmeligheden allerede kan være blevet hentet ud).

Filer med infrastruktur som kode (IaC) (Terraform, CloudFormation, Kubernetes-manifester) indeholder ofte hemmeligheder — forbindelsesstrenge til databaser, API-nøgler i deklarationer af miljøvariabler og TLS-certifikater. Disse filer bliver ofte committet til versionsstyring, hvilket skaber risiko for eksponering af hemmeligheder. Løsninger omfatter dynamiske hemmeligheder i Vault (Vault genererer en kortlivet legitimationsoplysning specifikt til hver Terraform-kørsel), Kubernetes Secrets (gemmes i etcd og skal krypteres under lagring) samt external-secrets-operator, der synkroniserer fra en hemmelighedshåndtering til Kubernetes under kørsel.

Hver applikation eller tjeneste bør kun have adgang til de hemmeligheder, den specifikt kræver — princippet om mindst mulige privilegier anvendt på hemmeligheder. En webapplikation har brug for databaseadgangskoden, men ikke den private CA-nøgle. Et rapporteringsjob har brug for skrivebeskyttede databaselegitimationsoplysninger, ikke skriveadgang. Hemmelighedshåndteringer håndhæver dette gennem adgangspolitikker, der angiver, hvilke identiteter (IAM-roller, tjenestekonti, AppRoles) der må læse hvilke hemmeligheder, mens al adgang logges af hensyn til revision.

Dynamiske hemmeligheder genereres efter behov til en specifik anmoder og udløber automatisk. Vault kan generere en midlertidig databaselegitimationsoplysning, der er gyldig i 1 time og knyttet til den specifikke tjeneste, der anmodede om den. Efter udløbet tilbagekaldes legitimationsoplysningen automatisk af databasen. Denne tilgang betyder, at der ikke findes langtidsholdbare statiske legitimationsoplysninger, som kan stjæles — selv hvis en angriber opsnapper en dynamisk legitimationsoplysning, udløber den hurtigt og er knyttet til den anmodende identitet i revisionsloggene.

CI/CD-arbejdsgange kræver ofte hemmeligheder — legitimationsoplysninger til cloududbydere ved udrulning, tokens til Docker-registre og signeringsnøgler. Gem aldrig hemmeligheder i arbejdsgangsscripts eller konfigurationsfiler. Brug i stedet platformens indbyggede hemmelighedslager (GitHub Actions Secrets, GitLab CI Variables, Jenkins Credentials Store), eller hent hemmeligheder fra et centralt lager under kørsel ved hjælp af en maskinidentitet. Markér hemmelighedsvariabler som maskeret i loggene for at forhindre utilsigtet eksponering i build-outputtet.

Hemmelighedshåndteringer leverer omfattende revisionslogge over hver hændelse med adgang til en hemmelighed: hvilken identitet der tilgik hvilken hemmelighed, fra hvilken IP-adresse, på hvilket tidspunkt, og om adgangen lykkedes eller blev afvist. Disse logge er afgørende for compliance (SOC 2, PCI-DSS) og håndtering af hændelser. Når en legitimationsoplysning mistænkes for at være kompromitteret, viser revisionsloggene, hvilke systemer der tilgik den, og hvornår — så det hurtigt bliver muligt at identificere potentielt berørte systemer og træffe beslutninger om begrænsning af skaden.

Pre-commit-hooks er scripts, der automatisk køres, før hvert git-commit færdiggøres, så hemmeligheder kan opdages, før de kommer ind i versionsstyringens historik. Værktøjer som detect-secrets (Yelp), GitLeaks og git-secrets (AWS) integreres som pre-commit-hooks og scanner de staged filer for mønstre, der matcher API-nøgler, forbindelsesstrenge, private nøgler og JWT-tokens. Hvis der opdages en hemmelighed, afvises committet, og udvikleren bliver bedt om at fjerne legitimationsoplysningen. pre-commit-rammeværket gør det nemt at tilføje og dele hook-konfigurationer på tværs af teams.

I denne lektion har du lært, at hardkodede hemmeligheder i kildekode skal fjernes og erstattes med hemmelighedshåndteringer som Vault eller AWS Secrets Manager, at automatisk rotation fjerner langtidsholdbare legitimationsoplysninger, som angribere kan misbruge selv efter det første kompromis, og at dynamiske hemmeligheder og adgangspolitikker baseret på mindst mulige privilegier begrænser værdien af enhver enkelt hemmelighed, der bliver eksponeret. Som det næste ser vi på afhængighedssikkerhed og analyse af softwaresammensætning.