Vilket säkerhetskopieringslager bör hantera krypteringsnycklarna: klienten, lagringsplatsen eller det externa målet?

Eva Wong

IceWhale author

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.

Which Backup Layer Should Own Encryption Keys: Client, Repository, or Off-Site Target?

För de flesta säkerhetskopior av hemservrar bör säkerhetskopieringsprogrammet eller klienten kontrollera den kryptering som krävs för att läsa säkerhetskopian, medan krypteringen hos lagringsleverantören utanför platsen bör ses som ett extra lager. Det hindrar att en kompromettering av moln- eller fjärrlagringen automatiskt avslöjar säkerhetskopiornas innehåll, samtidigt som ett säkerhetskopieringsformat bevaras som fortfarande kan deduplicera, verifiera och återställa data effektivt.

Den viktiga skillnaden är inte bara ”klientkryptering kontra serverkryptering”. Du måste avgöra vilken feldomän som äger dekrypteringshemligheten. Om den enda nyckeln finns på källservern kan en död eller ransomwarekrypterad källa förstöra möjligheten till återställning. Om målet utanför platsen innehar den enda meningsfulla nyckeln kan måloperatören eller ett komprometterat målkonto fortfarande befinna sig inom förtroendegränsen. Den bästa utformningen separerar säkerhetskopieringsdata, arkivautentiseringsuppgifter och återställningsnycklar.

Det finns tre olika platser där kryptering kan ske

Uttrycket ”krypterad säkerhetskopia” döljer flera arkitekturer. Källfilerna kan krypteras innan säkerhetskopieringsverktyget ser dem. Säkerhetskopieringsverktyget kan kryptera sitt arkivformat innan objekt skickas till lokal eller fjärrlagring. Eller så kan mållagringssystemet ta emot data och kryptera den i vila med sitt eget nyckelhanteringslager.

Lager	Vem utför krypteringen?	Vem måste inneha en återställningshemlighet?	Huvudsaklig styrka	Huvudsaklig svaghet
Förkryptering på klientsidan	Källprogram eller krypteringsverktyg	Klient-/användarägare av nyckeln	Stark separering från säkerhetskopieringsarkivet och leverantören	Kan minska deduplicering som är anpassad för säkerhetskopiering, metadatasynlighet och bekvämligheten med detaljerad återställning
Kryptering av säkerhetskopieringsarkiv	Säkerhetskopieringsprogram före lagring	Innehavare av arkivnyckel eller lösenfras	Bästa balansen mellan konfidentialitet och säkerhetskopieringsfunktioner	En förlorad nyckel eller lösenfras kan göra hela arkivet oläsligt
Kryptering av lagring utanför platsen	Moln-, NAS- eller lagringstjänst	Leverantörs-, KMS- eller kundhanterad målnyckel	Enkelt skydd för data i vila	Målet är fortfarande en del av dekrypteringens förtroendegräns

Kryptering på arkivnivå är vanligtvis det bästa standardvalet

Moderna säkerhetskopieringsverktyg är utformade för att kryptera data som en del av arkivformatet. Restics krypteringsdokumentation behandlar kryptering som en central arkivfunktion och stöder flera åtkomstnycklar och lösenord. Kopia beskriver på liknande sätt sina arkiv som att de lägger till kryptering och deduplicering ovanpå lagringsbackendar som filsystem, S3 och molnbaserade objektlager.

Borg gör förtroendemodellen särskilt tydlig. Dess säkerhetsdokumentation utgår från att klientmiljön är betrodd och att arkivet kan vara fientligt. Borg krypterar lokalt så att ett arkiv på annan plats inte får klartextfilerna eller den okrypterade säkerhetskopieringsnyckeln.

Detta mönster är attraktivt för en NAS i hemmet eftersom säkerhetskopieringsprogrammet fortfarande kan se originalfilerna när säkerhetskopian skapas. Det kan utföra segmentering, deduplicering, komprimering, hantering av metadata för ögonblicksbilder, verifiering och selektiva återställningar före eller samtidigt med krypteringen. Lagringsmålet tar emot krypterade arkivobjekt i stället för vanliga läsbara filer.

Blanda inte ihop arkivnyckeln med lagringsautentiseringsuppgiften

En åtkomstnyckel till en molnbucket, en privat SFTP-nyckel, ett lösenord till en NAS på annan plats och en dekrypteringsnyckel för säkerhetskopian är olika hemligheter, även när ett automatiseringsskript behöver alla. Lagringsautentiseringsuppgiften besvarar frågan ”får denna klient läsa eller skriva arkivobjekt?” Arkivnyckeln besvarar frågan ”kan dessa objekt dekrypteras till säkerhetskopierade data?”

Att separera de två är viktigt under en incident. En angripare som stjäl en autentiseringsuppgift för en skrivbar bucket ska inte automatiskt få tillgång till dekrypteringshemligheten för arkivet. Omvänt ska innehav av lösenfrasen för säkerhetskopian inte nödvändigtvis ge administrativ åtkomst till kontot för lagring på annan plats.

ZimaSpace-guiden om att verifiera varje nyckel som krävs för en krypterad återställning är ett användbart komplement, eftersom den behandlar åtkomst till arkivet, säkerhetskopieringskryptering, mållagring, containerhemligheter och hemligheter på programnivå som separata återställningsberoenden.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

Klientkryptering före uppladdning är bäst för smala datamängder med hög känslighet

Att kryptera filer innan säkerhetskopieringsprogrammet läser dem kan vara meningsfullt när en viss datamängd måste förbli ogenomskinlig även för de vanliga verktygen eller administratörerna som hanterar säkerhetskopieringen. Exempel är ett mindre juridiskt arkiv, en exporterad lösenordsdatabas, ett paket med privata nycklar eller en klientstyrd krypterad container.

Nackdelen är att kryptering som utförs för tidigt kan dölja strukturer som säkerhetskopieringssystemet annars skulle kunna utnyttja. Om varje ändrad fil blir helt annorlunda krypterad utdata kan komprimering och deduplicering bli mindre effektiva. Detaljerad filbläddring kan också bli en återställning i två steg: återställ först det krypterade objektet och lås sedan upp det med ett annat verktyg.

Därför är förkryptering av hela datamängden vanligtvis en svagare standardarkitektur för säkerhetskopiering i hemmet än att använda ett säkerhetskopieringsverktyg med inbyggd autentiserad kryptering av arkiv. Använd det när du medvetet behöver en andra förtroendegräns runt en delmängd av data.

Serversideskryptering utanför platsen skyddar lagringen, inte hela säkerhetsmodellen för säkerhetskopiering

Molnbaserade objektlagringstjänster krypterar vanligtvis data i vila. Amazon S3 använder till exempel serversideskryptering som standard och stöder AWS-hanterade eller kundhanterade KMS-nycklar. Dess dokumentation om SSE-KMS beskriver hur S3 utför krypteringen vid destinationen medan AWS KMS styr nycklar och behörigheter.

Backblaze B2 stöder på samma sätt leverantörshanterad SSE-B2 och kundhanterad SSE-C. Dess dokumentation om serversideskryptering anger att SSE skyddar fildata i vila och att data blir oåterställbara om en kundhanterad SSE-C-nyckel går förlorad.

Serversideskryptering är värdefull. Den bidrar till att skydda fysisk media och lagringsinfrastruktur, och KMS-policyer som hanteras av kunden kan skapa starka organisatoriska kontroller. Men om måltjänsten kan dekryptera data när en auktoriserad lagringsbegäran kommer in, befinner sig måltjänsten fortfarande inom konfidentialitetsgränsen. Detta skiljer sig från att ladda upp ett Borg-, restic- eller Kopia-arkiv som redan var krypterat innan det nådde leverantören.

Använd kryptering utanför platsen som ett extra skyddslager

Det praktiska svaret är ofta ”båda”. Låt säkerhetskopieringsprogrammet kryptera arkivets innehåll före uppladdning och låt sedan målets normala kryptering i vila vara aktiverad som ytterligare en kontroll. De två lagren skyddar mot olika händelser.

Fel eller hot	Arkivkryptering	Målets kryptering på serversidan
Exponering av molndisk eller lagringsmedium	Skyddar innehållet	Skyddar innehållet
Lagringsleverantören kan läsa auktoriserade objekt	Kan hålla leverantören utanför klartextens förtroendegräns	Vanligtvis inte i sig
Stulen bucket-autentiseringsuppgift	Data kan förbli oläsbar utan arkivnyckeln	Auktoriserade läsningar kan fortfarande utlösa dekryptering
Förlorad lösenfras/nyckel för säkerhetskopian	Kan göra arkivet oåterställbart	Återställer inte arkivnyckeln
Förlorad leverantörshanterad lagringsnyckel	Arkivlagret kan inte åtgärda otillgängliga måldata	Leverantörens/KMS:ets återställningspolicy gäller

Nyckeln måste överleva maskinen den skyddar

Den viktigaste regeln för nyckelplacering är enkel: förvara inte den enda återställningskopian av krypteringshemligheten på servern som säkerhetskopieras. Borgs aktuella guide för initiering av arkiv rekommenderar uttryckligen att en säkerhetskopia av Borg-nyckeln förvaras utanför både arkivet och systemet som skapar säkerhetskopiorna.

Samma logik gäller för restic-lösenord, Kopia-arkivlösenord, age-nycklar, LUKS-återställningsmaterial, administration av moln-KMS och programmets huvudnycklar. Ett perfekt krypterat arkiv är värdelöst om den enda dekrypteringshemligheten försvinner med den trasiga startenheten.

För ett hushåll eller ett mindre labb bör du ha minst en återställningskopia offline eller i ett separat system för autentiseringsuppgifter som inte är beroende av att NAS-enheten fungerar. Testa sedan en återställning på en ren maskin. Ett nedskrivet lösenord som aldrig har använts för att öppna arkivet är bevis på dokumentation, inte på återställningsbarhet.

Vilket lager bör hantera nyckeln i vanliga hemserverdesigner?

Hemnätverks-NAS som säkerhetskopierar till objektlagring

Använd inbyggd kryptering av arkivet i restic, Borg, Kopia eller ett jämförbart säkerhetskopieringsverktyg innan data lämnar NAS-enheten. Förvara arkivnyckeln/lösenfrasen utanför NAS-enheten. Låt bucket-kryptering vara aktiverad som ett extra skyddslager. Då blir molnmålet inte den enda konfidentialitetskontrollen.

Hemnätverks-NAS som säkerhetskopierar till en väns fjärrserver

Föredra klient- eller arkivkryptering där klartextnyckeln inte finns på vännens server. Fjärrvärden kan lagra ogenomskinliga arkivobjekt och upprätthålla begränsade skrivbehörigheter. Detta är särskilt värdefullt eftersom fysisk och administrativ kontroll över fjärrmaskinen tillhör en annan feldomän.

Lokal säkerhetskopieringsdisk som förvaras i samma hus

Arkivkryptering skyddar fortfarande konfidentialiteten om disken förloras eller stjäls. Full diskkryptering på säkerhetskopieringsdisken kan vara ett användbart extra lager, men låt inte diskens upplåsningsnyckel bli den enda vägen till säkerhetskopieringsarkivet.

Molnsäkerhetskopiering med leverantörens återställningsfunktioner

Leverantörshanterad kryptering kan vara rimlig när enkelhet och återställning med leverantörens hjälp är viktigare än att hålla leverantören utanför klartextens förtroendegräns. Förstå att detta är ett annat säkerhetsbeslut än klientkryptering av zero-knowledge-typ.

Lägg inte alla säkerhetskopieringshemligheter i en enda automatiseringsfil

Ett obevakat säkerhetskopieringsjobb behöver autentiseringsuppgifter, men bekvämlighet kan sudda ut dina säkerhetsgränser. Restics vägledning för automatisering varnar för att sättet lösenord tillhandahålls på kan exponera autentiseringsuppgifter och rekommenderar att lösenordsfiler skyddas noggrant.

För en hemmaserver bör du, där det är praktiskt möjligt, separera åtminstone följande roller:

En autentiseringsuppgift med snävt definierade behörigheter som kan nå säkerhetskopieringsmålet.
Arkivets dekrypteringslösenord eller -nyckel.
En offlinekopia av återställningslösenordet eller -nyckeln.
Administrativa autentiseringsuppgifter som kan radera lagringsprinciper, buckets eller fjärrkonton.

Denna åtskillnad är viktigare än beslutet om huruvida en specifik hemlighet lagras i en fil, miljövariabel, lösenordshanterare, hårdvarutoken eller KMS. Arkitekturen bör förhindra att en stulen automatiseringsuppgift samtidigt kan läsa klartext, radera arkivet och förstöra den enda återställningsnyckeln.

Kryptering ersätter inte oföränderlighet eller återställningstester

Sekretess, integritet, motståndskraft mot radering och återställningsbarhet är separata mål. Ett krypterat arkiv kan fortfarande raderas. En oföränderlig bucket kan fortfarande innehålla säkerhetskopior vars dekrypteringsnyckel har gått förlorad. Ett säkerhetskopieringsjobb som slutförts utan fel kan fortfarande misslyckas under återställningen.

Jämförelsen från ZimaSpace av en fjärrsäkerhetskopieringsserver kontra molnobjektlagring för säkerhetskopiering av virtuella maskiner når samma operativa slutsats: målets etikett spelar mindre roll än om en verklig återställning har testats.

Beslutsmatris

Prioritet	Föredraget ägarskap för nyckeln
Håll moln-/fjärradministratören borta från klartext	Klient eller krypterat säkerhetskopieringsarkiv
Bevara deduplicering och återställningar med stöd för säkerhetskopiering	Inbyggd kryptering av arkivet
Lägst operativ komplexitet	Målkryptering som hanteras av leverantören, med bredare förtroende som följd
Starkt försvar i flera lager	Kryptering av arkivet + kryptering av målservern på serversidan
Skydda en mycket liten, extremt känslig del separat	Förkryptering på klienten + vanlig säkerhetskopiering till arkivet
Katastrofåterställning efter förlust av källan	Alla modeller med en oberoende, testad återställningskopia av nyckeln

Slutligt omdöme

För de flesta egenhostade säkerhetskopieringssystem bör du låta säkerhetskopieringsklienten eller arkivformatet äga gränsen för innehållskrypteringen och låta målet på annan plats kryptera igen i vila. Detta bevarar säkerhetskopieringsfunktioner som deduplicering och verifiering, samtidigt som det minskar hur mycket du måste lita på att fjärrlagringssystemet håller klartexten skyddad.

Nyckelhanteringsplanen är komplett först när dekrypteringshemligheten överlever förlusten av källservern, lagringsmålet och den vanliga administratörsdatorn. Testa det antagandet från en ren dator innan du kallar säkerhetskopian återställningsbar.

Vanliga frågor

Räcker molnets kryptering på serversidan för säkerhetskopiering hemma?

Den skyddar data i vila, men låter vanligtvis lagringstjänsten ingå i dekrypteringsgränsen. Använd även kryptering som är inbyggd i säkerhetskopieringen när du inte vill att leverantören eller stulna lagringsuppgifter ska räcka för åtkomst till klartext.

Bör arkivnyckeln lagras i arkivet?

Vissa säkerhetskopieringsformat lagrar ett krypterat nyckelobjekt i arkivet, men återställningen är fortfarande beroende av en annan hemlighet, till exempel en stark lösenfras. Förvara oberoende återställningsmaterial utanför både arkivet och källsystemet.

Förbättrar kryptering av filer före säkerhetskopiering säkerheten?

Det kan skapa en ytterligare förtroendegräns för känsliga delmängder, men om allt krypteras innan säkerhetskopieringsverktyget ser det kan deduplicering, komprimering, metadataöverblick och bekvämligheten vid återställning försämras.

Vilket är det viktigaste testet av nyckelhanteringen?

Återställ från en ren dator efter att ha låtsats att den ursprungliga NAS-enheten är helt otillgänglig. Om du inte kan hitta alla inloggningsuppgifter och dekryptera representativa data är nyckelplanen ofullständig.