Valv och hemlighetslager

Vault skyddar sina data med en mekanism för försegling och öppning. När Vault startar är det förseglat – det vet var de krypterade data finns, men kan inte dekryptera dem.

Huvudnyckeln som dekrypterar lagringen är i sin tur krypterad med en öppningsnyckel. Med hjälp av Shamir's Secret Sharing delas öppningsnyckeln upp i flera delar som distribueras till olika operatörer.

Ett konfigurerbart tröskelvärde, till exempel 3 av 5 delar, måste tillhandahållas för att återskapa nyckeln och öppna Vault. Ingen enskild person kan öppna det ensam, vilket skyddar mot insiderkompromettering.

Innan en klient får läsa en hemlighet måste den autentisera sig för att få en token. Vault stöder många autentiseringsmetoder som är anpassade till olika identiteter:

• AppRole för applikationer och CI-system (role ID + secret ID).
• Kubernetes använder poddens tjänstekontotoken.
• AWS/GCP/Azure IAM litar på molnplattformens identitet.
• OIDC/LDAP för mänskliga användare via SSO.

Den centrala principen är att identiteten kommer från plattformen, inte från ett långlivat lösenord. En Kubernetes-pod bevisar vem den är med sitt eget tjänstekontotoken – ingen bootstrap-hemlighet som kan läcka.

Autentisering bevisar identiteten; policyer avgör vad identiteten får göra. Vault-policyer skrivs i HCL och följer principen om minsta behörighet – de beviljar endast de sökvägar och funktioner som en arbetslast behöver.

Den här policyn låter en tjänst läsa endast sin egen databashemlighet och inget annat:

Funktionerna motsvarar API-verb: read, create, update, delete och list. Neka som standard och bevilja uttryckligen.

Om ni kör i ett enda moln tar leverantörens hanterade lager bort det operativa arbetet – ingen försegling eller öppning och inga servrar att patcha:

• AWS Secrets Manager integreras med IAM och stöder inbyggda Lambdas för rotation.
• Azure Key Vault lagrar hemligheter, nycklar och certifikat med RBAC.
• GCP Secret Manager erbjuder versionshanterade hemligheter som skyddas av IAM-bindningar.

Åtkomsten styrs av molnets IAM, så en arbetslast läser en hemlighet med sin befintliga roll – inget separat lösenord behövs. Nackdelen är leverantörsberoende och svagare stöd för flera moln jämfört med Vault.

Ibland vill ni inte lagra en hemlighet alls – ni vill kryptera applikationsdata utan att applikationen någonsin har krypteringsnyckeln. Vaults Transit engine gör precis detta.

Applikationen skickar klartext till Vault, får tillbaka chiffertext och ser aldrig nyckeln. Dekryptering fungerar på samma sätt. Detta kallas kryptering som tjänst.

Fördelen är att nycklarna endast finns i Vault, kan roteras centralt och att en komprometterad applikation inte kan läcka en nyckel som den aldrig har haft.

Ett valv är bara användbart om applikationer kan använda hemligheter utan att hårdkoda sökvägen eller token. Vanliga mönster för injicering är:

• Sidecar/agent en Vault Agent körs tillsammans med applikationen, autentiserar sig och skriver hemligheter till en delad minnesbaserad volym.
• CSI-drivrutin Kubernetes monterar hemligheter som filer via Secrets Store CSI driver.
• Hämtning via SDK applikationen anropar valvets API direkt vid uppstart.

Föredra montering i ett minnesbaserat filsystem (tmpfs) framför miljövariabler och undvik att skriva hemligheter till disk där de kan bli kvar.

Varje läs-, skriv- och autentiseringshändelse i ett valv bör registreras i en granskningslogg. Det är detta som gör hanteringen av hemligheter spårbar och försvarbar under en incident.

Granskningsloggar besvarar de kritiska frågorna: vem som fick åtkomst till vilken hemlighet, när och från var. Vault hashar känsliga värden i loggarna så att själva loggen inte läcker hemligheter.

Skicka granskningsloggarna till ett manipulationssäkert, separat system (SIEM), så att en angripare som tar över valvets värd inte också kan radera bevisen på vad de fick åtkomst till.

Ett centraliserat lager koncentrerar risken: om valvet faller, faller allt. Härda det som er mest kritiska tillgång:

• Kör med TLS på alla endpoints; exponera aldrig API:t okrypterat.
• Håll valvet i ett privat nätverk bakom strikta brandväggsregler.
• Aktivera auto-unseal via en moln-KMS för att undvika manuell hantering av nyckeldelar, men skydda KMS-nyckeln noggrant.
• Använd korta token-TTL:er och förnybara leases så att stulna tokens snabbt löper ut.
• Installera uppdateringar omgående och övervaka granskningsloggar efter avvikelser.

Valvet byter ut många felpunkter mot en enda som är extremt väl skyddad.

Det finns inget verktyg som är bäst i alla situationer; anpassa lagringen efter er miljö:

• Ett enda moln och enkla behov använd den inbyggda hanteraren (AWS/Azure/GCP) för minsta möjliga driftsarbete.
• Multimoln eller on-prem HashiCorp Vault ger ett konsekvent och portabelt abstraktionslager.
• Behov av dynamiska hemligheter eller kryptering som tjänst Vaults engines erbjuder mest funktionalitet.
• Kubernetes-tung miljö kombinera ett lager med CSI-drivrutinen eller en operator som External Secrets.

Oavsett vad ni väljer är målet detsamma: en enda granskad och åtkomststyrd sanningskälla som ersätter utspridda värden i klartext.

Ni har lärt er hur utspridda hemligheter kan ersättas med ett centraliserat och granskat lager.

• Ett hemlighetslager tillhandahåller centraliserad lagring, åtkomstkontroll, granskningsloggning och kryptering.
• HashiCorp Vault använder utbytbara secrets engines och en seal/unseal-modell som skyddas av Shamir's Secret Sharing.
• Autentiseringsmetoder härleder identitet från plattformen (Kubernetes, IAM, AppRole), och policyer upprätthåller minsta möjliga behörighet.
• Molnnativa lager (AWS, Azure, GCP) byter portabilitet mot mindre driftsarbete.
• Transit engine erbjuder kryptering som tjänst, så att appar aldrig behöver hantera nycklar.
• Injicera hemligheter via agenter eller CSI i minnesbaserad lagring, logga varje åtkomst och härda valvet som er mest kritiska tillgång.

Därefter gör vi hemligheter ännu säkrare genom att generera dem dynamiskt och ge dem kort livslängd.