Checklista för rotation av hemligheter på hemmaservrar för appar, databaser och säkerhetskopior

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

Det säkra tillvägagångssättet är att behandla en inventeringsledd rotation med överlappande autentiseringsuppgifter, validering av konsumenter, återkallelse och uppdateringar av återställningsmaterial som en serie observerbara kontrollpunkter, inte som ett enda kommando.

På en hemserver med självvärdiga appar, databaser, säkerhetskopieringsjobb och automatisering är den praktiska risken att rotation av en autentiseringsuppgift kan slå ut dolda konsumenter, schemalagda säkerhetskopieringar eller programberoenden. Dokumentera den aktuella identiteten och återställningspunkten, börja med den minst ingripande särskiljande kontrollen, tolka godkända och underkända resultat innan du ändrar en annan variabel och avbryt när lagringen blir instabil eller den enda återställningsbara kopian skulle exponeras. Arbetsflödet nedan är inte slutfört förrän den ursprungliga arbetsbelastningen fungerar eller bevisläget når en eskaleringsgräns.

Inventera varje hemlighet och dess påverkansområde

Lista databaslösenord, API-token, nycklar till säkerhetskopieringsarkiv, krypteringsnycklar, webhook-hemligheter, proxyautentiseringsuppgifter och nycklar för tjänstekonton. Dokumentera för varje post utfärdare, behörigheter, lagringsplats, konsumenter, omladdningsmetod, beroende av säkerhetskopiering, återställningsansvarig och bevis på senaste användning utan att dokumentera själva värdet.

GitGuardians checklista för autentiseringsuppgifters påverkansområde utgår från påverkansområde och ägarskap: en autentiseringsuppgift kan finnas kvar längre än personen eller tjänsten som skapade den, och giltighet identifierar inte automatiskt alla konsumenter. Sök igenom konfiguration, hemlighetslagring, schemalagda jobb och CI-variabler innan du planerar återkallelse.

Klassificera nödrotation separat från planerad rotation. Om en kompromettering misstänks kan begränsning av incidenten och snabb återkallelse väga tyngre än drifttid; annars ska du kräva en återställningspunkt och en testad återställningsväg innan du ändrar en hemlighet som används av databaser eller säkerhetskopieringar.

Skapa överlappning och uppdatera utfärdaren först

Skapa om möjligt en andra autentiseringsuppgift med samma minsta behörigheter medan den gamla fortfarande är giltig. För databaser använder du en andra roll eller en funktion för dubbla lösenord; för API-tjänster utfärdar du en andra token; för krypteringsnycklar följer du produktens procedur för omförpackning eller nyckelplatser i stället för att byta ut nyckelfiler på måfå.

En guide för databasrotation utan driftstopp beskriver mönstret med två användare för rotation av autentiseringsuppgifter, där konsumenterna flyttas till en andra användare innan den ursprungliga återkallas. Metoden är säkrare än att byta ett gemensamt lösenord direkt eftersom varje konsument kan valideras separat.

Om överlappning är omöjlig ska du planera ett underhållsfönster, stoppa beroende skrivningar och säkerhetskopieringsjobb och dokumentera det exakta återställningskommandot. Skriv aldrig över det enda kända fungerande lösenordet till arkivet eller den enda kända fungerande krypteringsnyckeln innan ett separat återställningstest har bekräftat ersättningen.

Uppdatera varje konsument och bevisa ny användning

Uppdatera skyddade hemlighetsfiler eller hemlighetshanteraren och ladda sedan om eller återskapa en konsument i taget. Testa programinloggning, databasläsningar och -skrivningar, bakgrundsarbetare, övervakning, webhooks, fjärrreplikering samt både schemalagda och manuella säkerhetskopieringar. En körande container kan fortfarande ha det gamla värdet i minnet.

Använd ZimaSpaces guide för lagring av Docker-hemligheter för att hålla autentiseringsuppgifter borta från Compose YAML. Säkerställ att renderad konfiguration, miljöinspektion, loggar, skalsessionens historik och supportpaket inte avslöjar vare sig gamla eller nya värden.

Bevisa att varje konsument använder den nya autentiseringsuppgiften genom att kontrollera utfärdarens granskningsloggar eller tillfälligt testa den gamla autentiseringsuppgiften från en säker, isolerad sökväg. Återkalla inte förrän konsumentmatrisen har en ansvarig och ett godkänt resultat för varje beroende.

-15% OFF
Single board computer zimaboard2

Återkalla, städa upp och testa återställning

Återkalla den gamla autentiseringsuppgiften, ta bort den från aktiva hemlighetslager och inaktiverade jobb och övervaka autentiseringsfel och säkerhetskopieringsvarningar under minst en normal schemalagd cykel. Rotera underordnade sessionstoken eller cachade anslutningar när produkten kräver det.

Uppdatera krypterad återställningsdokumentation och skyddade offlinekopior av nycklar. Avgör om säkerhetskopior som innehåller en gammal hemlighet är säkert krypterade och omfattas av lagringsregler eller kräver särskild hantering; att skriva om historiska säkerhetskopior kan skada återställningsbarheten och är sällan den första åtgärden.

Rotationen är slutförd när den gamla autentiseringsuppgiften misslyckas, alla konsumenter fungerar med den nya, en säkerhetskopiering slutförs och en återställning eller återställningsinloggning lyckas. Återställ endast med den förskrivna metoden; oförklarade autentiseringsfel innebär att inventeringen var ofullständig och återkallelsen bör inte döljas med breda nya autentiseringsuppgifter.

Support och tips

Mer att läsa

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.