Før eller siden når alle teams dertil, hvor loginoplysningerne ligger for mange steder: en .env på hver bærbar, en fastgjort besked i Slack, et regneark kaldet ”logins”, en CI-variabel, som nogen satte for to år siden. En cloud secret manager findes for at samle alt det ét sted, der er krypteret, har adgangsstyring og bliver revideret.
Denne guide forklarer, hvad en cloud secret manager gør, hvordan du vælger mellem de vigtigste muligheder, hvordan du indfører en uden en lang migrering, og den ene opgave, den ikke løser: at få en hemmelighed frem til et menneske, der ikke er inde i din cloudkonto.
Hvad en cloud secret manager gør
En secret manager gemmer følsomme værdier og udleverer dem til autoriserede identiteter, når de beder om dem. Kernefunktionerne er de samme hos alle udbydere:
- Krypteret lagring i hvile, med nøgler i udbyderens tjeneste til nøgleadministration, og TLS under overførslen.
- Adgang baseret på identitet: Hver hemmelighed har en politik, der angiver, hvilke brugere, roller eller workloads der må læse, skrive eller rotere den. Et program godkender sig med sin egen identitet, ikke med en masteradgangskode.
- Revisionslogning af hver læsning, skrivning og rotation, med hvem, hvad og hvornår.
- Versionering og rotation: En ny værdi kan klargøres, programmerne kan skifte over, og den gamle version kan udfases. Mange secret managers roterer loginoplysninger til databaser automatisk.
- Hentning ved kørsel: Programmet henter hemmeligheden, når det starter, eller når det har brug for den, så værdien aldrig skrives ind i kode, images eller konfigurationsfiler.
En hemmelighed er alt, der giver adgang. Konfiguration, der blot beskriver adfærd, fx et portnummer eller et funktionsflag, hører hjemme i almindelig konfiguration. Blander man de to, bliver lageret til hemmeligheder rodet og konfigurationslageret farligt.
Sådan vælger du en
Valget afhænger som regel af, hvor dine workloads kører, og hvor mange clouds du bruger.
| Mulighed | Passer bedst til | Hold øje med |
|---|---|---|
| AWS Secrets Manager / Parameter Store | Workloads, der allerede kører på AWS, med IAM-identiteter overalt | Pris pr. hemmelighed i Secrets Manager; Parameter Store er billigere til almindelige værdier |
| Google Secret Manager | GCP-projekter og workloads på Cloud Run og GKE | Valg af regional replikering |
| Azure Key Vault | Workloads på Azure og behov for styring af certifikaters livscyklus | Separate vaults pr. miljø, så politikkerne forbliver enkle |
| HashiCorp Vault | Flere clouds eller egne servere, dynamiske loginoplysninger med kort levetid | Du skal selv drive det, medmindre du bruger den hostede version |
| Doppler, Infisical, 1Password Secrets Automation | Små teams, der vil have udviklervenlig synkronisering til mange platforme | Endnu en leverandør i tillidskæden |
Fire spørgsmål afgør de fleste valg. Kan den integreres med dine deploymentværktøjer og dit runtime-miljø uden specialkode? Kan dine workloads godkende sig over for den med den identitet, de allerede har? Kan den rotere de typer loginoplysninger, du faktisk har? Og ender dens revisionslogge der, hvor dit sikkerhedsteam allerede kigger? Priser, regioner og compliance-certificeringer kommer efter de fire.
Indførelse uden et projekt på seks måneder
- Lav en oversigt, og udpeg ejere. Skriv alle hemmeligheder ned: hvor de ligger, hvad der bruger dem, og hvem der har ansvaret. Ejeren bestemmer politikken for rotation og listen over, hvem der har adgang.
- Opret identiteterne først. Opret roller eller servicekonti for hver workload og hvert miljø, før du flytter en eneste værdi. Adgangspolitikker, der siger ”denne tjeneste, dette miljø, kun læseadgang”, er hele pointen.
- Migrer i rækkefølge efter risiko. Først adgangskoder til produktionsdatabaser og betalingsnøgler, derefter API-nøgler fra tredjeparter og så resten. Fjern hver værdi fra kode, CI-variabler og konfigurationsfiler, når den flyttes, og roter den undervejs, fordi den gamle værdi allerede er blevet kopieret rundt.
- Skift måden, programmerne læser hemmeligheder på. Erstat hårdkodede værdier og miljøfiler med et kald til secret managerens SDK ved opstart, eller indsæt dem med platformens egen integration.
- Slå rotation til for alt, hvad secret manageren selv kan rotere, og skriv en rotationsfunktion eller en driftsvejledning til resten.
- Lav alarmer på det usædvanlige. En hemmelighed, der læses af en ny identitet, en pludselig stigning i antallet af læsninger eller en læsning fra en region, du ikke deployer til, er værd at blive vækket for.
De almindelige fejl er forudsigelige: De gamle kopier bliver liggende efter migreringen, en workload får læseadgang til hele lageret i stedet for kun sine egne hemmeligheder, og den hentede værdi logges i programmets logge.
Hullet, en secret manager ikke dækker
En secret manager er bygget til maskiner og til folk inden for dit identitetssystem. Den er ikke bygget til det øjeblik, hvor loginoplysninger skal frem til nogen uden for det: en ekstern konsulent, der har brug for en midlertidig adgangskode til en database, en kunde, der skal have sit første administratorlogin, en leverandørs tekniker, der skal bruge et token en eftermiddag, en nyansat på første dag, før vedkommendes SSO-konto findes.
De overdragelser sker alligevel, og uden en godkendt vej sker de via e-mail og chat, præcis der, hvor secret managers skulle have fået loginoplysningerne væk fra. Den godkendte vej er et hemmeligt engangslink. Værdien krypteres i din browser, før den gemmes, beskeden indeholder kun et link, den gemte kopi destrueres, første gang linket åbnes, og linket udløber efter en fast tid, hvis ingen åbner det.
Det mønster, der virker: Secret manageren er det autoritative system, og engangslinket er leveringsmetoden, når et menneske uden for systemet har brug for en værdi én gang. Generer loginoplysningerne, gem dem i secret manageren, send dem til personen via et engangslink, og roter dem, når personens adgang ophører. Hemmelige links og adgangskodeadministratorer bruger samme ræsonnement på teamets adgangskodeadministrator, og guiden om loginoplysninger mellem teams gennemgår rutinen.
En kort tjekliste
- Hver hemmelighed har en ejer, en adgangspolitik og en regel for rotation.
- Workloads godkender sig med deres egen identitet, aldrig med en delt nøgle.
- Efter migreringen findes der ingen hemmeligheder i kode, images, CI-variabler eller chat.
- Læsninger logges et sted, hvor en person faktisk kigger.
- Folk uden for identitetssystemet modtager hemmeligheder via et engangslink, ikke i en besked.
Gør du de fem ting, holder din secret manager op med at være et produkt, du har købt, og bliver grunden til, at loginoplysninger holdt op med at lække.