Hvordan beskytter man sine API-nøgler? Guide til sikker håndtering af applikationshemmeligheder

Hvordan beskytter man sine API-nøgler? Det korte svar

For at beskytte dine API-nøgler skal du holde dem ude af din kode, samle dem ét sted med adgangskontrol, give mindst mulige rettigheder, holde levetiden kort, rotere løbende og logge hver adgang.

De seneste års databrud har en ubehagelig fællesnævner: angriberne behøvede sjældent bryde nogen kryptering. De fandt bare en hemmelighed, der lå et sted, den ikke burde, tit hardcodet i koden eller eksponeret i en frontend. At beskytte sine secrets er vigtigere end nogensinde. Resten af guiden viser, hvordan du strammer din API-nøgle håndtering i praksis, og hvordan du beskytter dine hemmeligheder uden at det bliver et fuldtidsjob.

Hvorfor lækker API-nøgler og applikationshemmeligheder?

En API-nøgle er reelt et bearer token: enhver, der har strengen, kan bruge den. Det gør den nem at tage i brug og lige så nem at miste kontrollen over. De klassiske lækager:

• .env-filer, der bliver kopieret, delt på chat eller efterladt i en backup.
• Git-historik, hvor en nøgle blev committet én gang og aldrig forsvinder igen.
• CI/CD-logs, hvor secrets utilsigtet printes under et build.
• Hardcodede værdier i koden eller i en frontend-bundle, browseren kan hente.
• Delte credentials uden ejerskab, som ingen tør rotere.

Fælles for dem alle er, at nøglen er en kopierbar streng med lang levetid og brede rettigheder. Beskyttelse handler om at fjerne hvert af de tre kendetegn.

Sådan beskytter du dine API-nøgler i praksis

Syv principper for sikker API-nøgle håndtering, fra det grundlæggende til det mest effektive.

1. Tag dine secrets ud af koden

Ingen API-nøgler i kode, billeder eller config-filer, der følger med repoet, og slet ikke i en frontend, browseren kan hente. Dine applikationshemmeligheder hører til ét centralt, kontrolleret sted, ikke spredt ud over servere og udviklerlaptops.

2. Giv mindst mulige rettigheder

Hver nøgle skal kunne præcis det, den skal, og ikke mere. En read-only token til én service skal ikke også kunne slette i en anden.

3. Hold levetiden kort

Jo længere en nøgle lever, jo større er vinduet for misbrug. Korte levetider og automatisk udløb begrænser skaden, hvis en nøgle slipper ud.

4. Roter løbende, og gør det smertefrit

Rotation, der kræver manuelt arbejde, bliver ikke gjort. Når en nøgle kan skiftes uden nedetid, kan du rotere ofte og rotere med det samme, hvis du har mistanke om et læk.

5. Log hver adgang

Du kan ikke beskytte det, du ikke kan se. En audit-log over hvem der læste hvad og hvornår gør et brud synligt i stedet for usynligt.

6. Bind adgang til identitet i stedet for en streng

Det stærkeste skift er at lade en maskine bevise, hvem den er, med en signatur, frem for at fremvise en hemmelig streng. Så er der ingen streng at kopiere fra en log, en .env-fil eller et JavaScript-bundle.

7. Centralisér, så du kan håndhæve det hele ét sted

Spredte secrets kan ikke styres. Et centralt vault gør rotation, rettigheder og logning til noget, du sætter op én gang i stedet for per service.

Beskyt dine hemmeligheder uden at det bliver et fuldtidsjob

God secrets management bør være noget, du sætter op én gang og så kan stole på, ikke endnu et system, der skal passes døgnet rundt. Når dine hemmeligheder ligger ét sted, og maskiner henter dem ved runtime med deres egen identitet, bliver rotation, adgangsstyring og logning til konfiguration frem for løbende vedligehold. At beskytte dine hemmeligheder bliver standardvejen, ikke ekstraarbejdet.

Sådan fungerer SikkerKey

SikkerKey bygger på signerede maskinidentiteter. En maskine fremviser ikke en hemmelig nøgle for at få adgang, den beviser, hvem den er, ved at signere hvert request.

• Maskiner autentificerer med en signatur. Når en maskine sættes op, genereres et Ed25519 keypair lokalt, og kun den ikke-hemmelige nøgle sendes til SikkerKey. Hvert request underskrives med timestamp og en nonce, så den ikke kan genbruges.
• Dine secrets er krypteret i vaulten med AES-256 og udleveres kun til godkendte maskiner i det rette projekt.
• Du henter dem direkte i din kode med en SDK til Python, Node.js, Go, .NET, Kotlin/JVM og PHP. SDK'en finder selv maskinens identitet, så du ikke skal hardcode nogen nøgle. Til scripts og CI henter sikkerkey run --all -- <kommando> dine secrets ind som miljøvariabler, så .env-filen helt kan udgå.
• Rotation, policies og canaries er indbygget. Roter enhver hemmelighed efter en plan, stram adgang med time windows, IP-allowlists, rate limits, co-signing og udløb, og plant canaries, der fryser projektet, hvis de bliver læst af en maskine.
• Hver læsning logges og er knyttet til en konkret maskine i en audit-log.

Arkitekturen fjerner en hel klasse af problemer ved design: der er ikke noget bearer token i flowet, så der er ingen hemmelig streng at committe, printe i en log eller dele ved en fejl. Den private nøgle ligger lokalt på maskinen og skal beskyttes som enhver anden lokal nøgle. Den kan kopieres, hvis maskinen selv bliver kompromitteret, men den havner aldrig i en git-historik eller en CI-log, sådan som et token gør. Og fordi SikkerKey kun gemmer de ikke-hemmelige nøgler, giver et brud på SikkerKey ikke en angriber noget at logge ind med. SikkerKey dekrypterer hemmeligheder ved at sende projektets datanøgle til et orakel på en anden server gennem en sikker og krypteret WireGuard-forbindelse. Oraklet udleverer datanøglen dekrypteret, der efterfølgende bruges til at dekryptere hemmelighederne in-memory.

Kom i gang

Vil du beskytte dine API-nøgler og resten af dine hemmeligheder uden at stå med endnu et system at passe? Læs mere her, eller dyk ned i dokumentationen.