Hantering av hemligheter

Hemligheter är uppgifter eller värden som ger åtkomst till system och måste förbli konfidentiella. De inkluderar API-nycklar, databaslösenord, privata TLS-certifikat, OAuth-klienthemligheter, privata SSH-nycklar och krypteringsnycklar. Det som skiljer en hemlighet från vanlig konfiguration är konsekvens. Om ett värdnamn läcker komprometteras ingenting omedelbart, om ett databaslösenord läcker har angriparen direkt åtkomst.

En hemlighets livscykel sträcker sig från skapande, distribution till auktoriserade konsumenter, användning i körande system, rotation till ett nytt värde och återkallelse av det gamla. Varje steg i denna livscykel är en möjlighet för ett misstag. Hemligheter skapas ofta med alltför långa giltighetstider, distribueras till fler system än nödvändigt, roteras aldrig och återkallas aldrig.

Långlivade hemligheter är särskilt farliga eftersom exponeringsfönstret är långt. En hemlighet som stals för sex månader sedan men aldrig roterades är fortfarande användbar för angriparen. Korttidshemligheter som löper ut inom minuter eller timmar minskar dramatiskt detta fönster. Även om de stjäls löper de ut innan de kan utnyttjas meningsfullt.

Många organisationer underskattar hur många hemligheter de har. En enda applikation kan ackumulera dussintals. Uppgifter för varje externt API den anropar, uppgifter för varje databas, uppgifter för varje meddelandekö, TLS-certifikat och krypteringsnycklar. Att hitta och inventera alla dessa är det första steget mot att hantera dem effektivt.

Ett hemlighetsgvalv är ett dedikerat system för att lagra, hantera och distribuera hemligheter till applikationer som behöver dem. Istället för att bädda in hemligheter i kod eller konfigurationsfiler autentiserar sig applikationer mot gvalvet vid start eller vid behov och hämtar de specifika hemligheter de är auktoriserade att komma åt. Gvalvet är den enda källan till sanning, vilket gör rotation och återkallelse enkla.

HashiCorp Vault är det mest utbreda öppen källkodsgvalvet. Det stöder flera autentiserings-backends (Kubernetes-tjänstkonton, AWS IAM, LDAP, certifikatbaserade) och flera hemlighets-backends (nyckel-värde, databas, PKI, molnleverantörsuppgifter). Dess dynamiska hemligheter genererar unika, korttidsuppgifter för varje förfrågan, vilket eliminerar problemet med statiska delade lösenord.

Molnbaserade hemlighetsgvalv (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager) integreras sömlöst med respektive molnplattformar. De stöder automatisk rotation via molntjänstintegration, finkornig IAM-baserad åtkomstkontroll och detaljerade granskningsloggar. Team som redan använder en molnplattform bör överväga det molnbaserade gvalvet som första alternativ.

Bootstrap-problemet är den viktigaste utmaningen vid adoption av ett hemlighetsgvalv. Applikationen behöver fortfarande en uppgift för att autentisera sig mot gvalvet. Den korrekta lösningen är att använda en plattformsbaserad autentiseringsmekanism snarare än en lagrad hemlighet. I Kubernetes autentiserar sig pods mot Vault med Kubernetes-tjänstkontots token.

Hemlighetslotation är processen att ersätta en hemlighet med ett nytt värde på ett definierat schema eller som svar på en säkerhetshändelse. Målet är att begränsa skadan från stöld av uppgifter genom att säkerställa att stulna uppgifter löper ut innan (eller snabbt efter) att de utnyttjas. Rotation begränsar också exponeringsfönstret från tysta intrång.

Automatiserad rotation är det enda praktiska tillvägagångssättet i stor skala. Manuell rotation kräver samordning mellan team, uppdatering av varje konsumerande system och verifiering att inget gick sönder. Automatiserad rotation hanterar hela orkestreringen. Skapar en ny uppgift, uppdaterar konsumerande system, verifierar framgång och tar sedan bort den gamla uppgiften.

Blå/grön-rotationsmönstret förhindrar driftstopp under uppgiftsändringar. Den nya uppgiften skapas vid sidan av den gamla, applikationer uppdateras för att använda den nya uppgiften medan den gamla förblir giltig, när alla applikationer har bytt återkallas den gamla. Detta överlappande giltighetsperiodsmönster eliminerar rastillståndet.

Akutrotation, utlöst av ett bekräftat eller misstänkt intrång, följer ett annat tillvägagångssätt. Den gamla uppgiften måste återkallas omedelbart, och acceptera eventuellt tjänstavbrott, eftersom att lämna den aktiv ger angriparen fortsatt åtkomst. Procedurer för akutrotation bör dokumenteras och övas innan de behövs.

Hemlighetsinjektion är processen att tillhandahålla hemligheter till körande applikationer utan att hårdkoda dem i källkod eller konfigurationsfiler. Applikationer bör aldrig innehålla hemlighetsvärden vid byggtid, hemligheter bör injiceras vid driftsättningstid eller hämtas vid körning från ett gvalv. Denna separation säkerställer att artefakten (containeravbildning, kompilerat binärfil) är identisk i alla miljöer.

Miljövariabelinjektion är det vanligaste mönstret. Driftsättningssystemet hämtar hemligheter från ett gvalv och ställer in dem som miljövariabler i processen innan den startar. Containerorkestrare som Kubernetes kan hämta hemligheter via Secrets Store CSI Driver och exponera dem som miljövariabler eller monterade filer. Applikationen läser hemligheten från miljön.

Filbaserad injektion har fördelar jämfört med miljövariabler i vissa scenarier. Miljövariabler är synliga för alla underordnade processer och kan förekomma i processlistningar och kraschrapporter. Filer monterade med restriktiva behörigheter är mer kontrollerade. Secrets Store CSI Driver synkroniserar hemligheter från externa gvalv och monterar dem direkt i pods som filer.

Ett vanligt misstag är att lagra hemligheter i Kubernetes inbyggda Secret-objekt utan ytterligare skydd. Som standard är Kubernetes Secrets base64-kodade (inte krypterade) i etcd. Den föredragna metoden är att använda Secrets Store CSI Driver eller en Vault-agentsidecar för att hämta hemligheter direkt från ett externt gvalv, så att de aldrig finns kvar i Kubernetes API.

Hemlighetsgranskning är praxis att logga och övervaka varje interaktion med hemligheter. Vem som kom åt en hemlighet, när, från vilket system, vad de gjorde och om åtkomsten var auktoriserad. Granskningsloggar är det primära mekanismen för att detektera obehörig åtkomst, uppfylla efterlevnadskrav och genomföra undersökningar efter incidenter.

HashiCorp Vault, AWS Secrets Manager och liknande verktyg genererar detaljerade granskningshändelser för varje hemlighetshämtning, skapande, rotation och radering. Dessa loggar bör skickas till en centraliserad SIEM där de kan korreleras med andra säkerhetshändelser. Ett tjänstkonto som komprometterades och används för att läsa hemligheter visas i gvalvets granskningslogg.

Effektiv granskning kräver avisering om misstänkta mönster. En tjänst som aldrig normalt kommer åt en viss hemlighet och plötsligt begär den är misstänkt. Åtkomst från en oväntad käll-IP är misstänkt. Massuthämtning av många hemligheter på kort tid tyder på rekognoscering eller dataexfiltrering. Automatiserade detektionsregler i SIEM kan hitta dessa mönster.

Granskningsspår krävs också för efterlevnad. Förordningar som PCI DSS kräver demonstration av att åtkomst till känsliga uppgifter loggas och att loggarna är skyddade mot manipulation. Att skicka gvalvgranskningsloggar till ett oföränderligt loggarkiv (S3 med Object Lock eller ett WORM-kompatibelt logghanteringssystem) säkerställer att loggar kan betraktas som bevis.

Hemligheter förekommer i två olika sammanhang i modern programvaruleverans. CI/CD-pipelines (där de behövs under bygge, test och driftsättning) och körningsmiljöer (där de konsumeras av långlivade tjänster). Varje sammanhang har olika säkerhetskrav och riskprofiler, och de bör använda olika uppgifter.

CI/CD-hemligheter är särskilt känsliga eftersom CI/CD-systemet har privilegierad åtkomst till produktionsmiljöer och artefaktregister. Det föredragna tillvägagångssättet är att undvika att lagra långlivade CI-hemligheter alls genom att använda OIDC-federation. CI-jobbet tar emot en kortlivad token från CI-plattformen som det byter mot temporära molnuppgifter. Ingen hemlighet lagras.

Körningshemligheter konsumeras av långlivade tjänster och har olika hanteringskrav. De måste överleva omstarter och uppdateras automatiskt vid rotation. Med hjälp av ett Vault-agentsidecar-mönster, en separat process i samma pod, hämtas hemligheter från gvalvet och hålls aktuella, med nya värden skrivna till en delad volym.

Ett vanligt misstag är att använda samma uppgifter för CI/CD och körning. En driftsättningspipeline som bygger, testar och driftsätter bör använda driftsättningsomfattade uppgifter som är helt separata från de produktionsdatabas-uppgifter som används av den körande applikationen. Att blanda dem innebär att en komprometterad CI-uppgift ger direkt åtkomst till produktionsdatabasen.