Welke back-uplaag moet de encryptiesleutels beheren: client, repository of externe bestemming?

Eva Wong

IceWhale author

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

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

Voor de meeste back-ups van thuisservers moet de back-upapplicatie of client de versleuteling beheren die nodig is om de back-up te lezen, terwijl de versleuteling van de externe opslagprovider moet worden beschouwd als een extra laag. Zo wordt voorkomen dat een inbreuk op cloud- of externe opslag automatisch de inhoud van de back-up blootlegt, terwijl een back-upindeling behouden blijft die gegevens efficiënt kan dedupliceren, verifiëren en herstellen.

Het belangrijke onderscheid is niet simpelweg ‘versleuteling aan de clientzijde versus aan de serverzijde’. Je moet bepalen welk foutdomein het geheim voor ontsleuteling beheert. Als de enige sleutel op de bronserver staat, kan een defecte of door ransomware versleutelde bron het herstel onmogelijk maken. Als het externe doel de enige betekenisvolle sleutel beheert, kan de doelbeheerder of een gecompromitteerd doelaccount nog steeds binnen de vertrouwensgrens vallen. Het beste ontwerp scheidt back-upgegevens, repositoryreferenties en herstelsleutels.

Versleuteling kan op drie verschillende plaatsen plaatsvinden

De term ‘versleutelde back-up’ verbergt verschillende architecturen. De bronbestanden kunnen worden versleuteld voordat de back-uptool ze ziet. De back-uptool kan zijn repositoryindeling versleutelen voordat objecten naar lokale of externe opslag worden verzonden. Of het doelopslagsysteem kan gegevens ontvangen en deze in rust versleutelen met zijn eigen sleutelbeheerlaag.

Laag	Wie voert de versleuteling uit?	Wie moet een herstelsecretet bewaren?	Belangrijkste sterkte	Belangrijkste zwakte
Versleuteling aan de clientzijde vooraf	Bronapplicatie of versleutelingstool	Eigenaar van de client-/gebruikerssleutel	Sterke scheiding van de back-uprepository en provider	Kan deduplicatie met kennis van back-ups, zichtbaarheid van metadata en gebruiksgemak bij gedetailleerd herstel verminderen
Versleuteling van de back-uprepository	Back-upsoftware vóór de opslag	Beheerder van de repositorysleutel of wachtwoordzin	Beste balans tussen vertrouwelijkheid en back-upfuncties	Een verloren sleutel of wachtwoordzin kan de volledige repository onleesbaar maken
Versleuteling van het externe doel	Cloud-, NAS- of opslagdienst	Door de provider, KMS of klant beheerde doelsleutel	Eenvoudige bescherming van gegevens in rust	Het doel blijft onderdeel van de vertrouwensgrens voor ontsleuteling

Versleuteling op repositoryniveau is doorgaans de beste standaard

Moderne back-uptools zijn ontworpen om gegevens te versleutelen als onderdeel van het repositoryformaat. De versleutelingsdocumentatie van restic behandelt versleuteling als een volwaardige repositoryfunctie en ondersteunt meerdere toegangssleutels en wachtwoorden. Kopia beschrijft zijn repositories op vergelijkbare wijze als opslaglocaties die versleuteling en deduplicatie toevoegen boven op opslagback-ends zoals bestandssystemen, S3 en cloudobjectopslag.

Borg maakt het vertrouwensmodel bijzonder duidelijk. De beveiligingsdocumentatie gaat ervan uit dat de clientomgeving betrouwbaar is, terwijl de repository mogelijk kwaadaardig is. Borg versleutelt lokaal, zodat een externe repository geen bestanden in platte tekst of een onversleutelde back-upsleutel ontvangt.

Dit patroon is aantrekkelijk voor een thuis-NAS, omdat de back-upapplicatie de oorspronkelijke bestanden nog steeds kan zien tijdens het maken van de back-up. De applicatie kan chunking, deduplicatie, compressie, verwerking van snapshotmetagegevens, verificatie en selectief herstel uitvoeren vóór of gelijktijdig met de versleuteling. Het opslagdoel ontvangt versleutelde repositoryobjecten in plaats van gewone leesbare bestanden.

Verwar de repositorysleutel niet met de opslagreferentie

Een toegangssleutel voor een cloudbucket, een privésleutel voor SFTP, een wachtwoord voor een externe NAS en een ontsleutelingssleutel voor back-ups zijn verschillende geheimen, ook wanneer een automatiseringsscript ze allemaal nodig heeft. De opslagreferentie beantwoordt de vraag: “Mag deze client repositoryobjecten lezen of schrijven?” De repositorysleutel beantwoordt de vraag: “Kunnen deze objecten worden ontsleuteld tot back-upgegevens?”

Het scheiden van deze zaken is tijdens een incident belangrijk. Een aanvaller die een bucketreferentie met schrijfrechten steelt, zou niet automatisch het ontsleutelingsgeheim van de repository mogen verkrijgen. Omgekeerd zou het bezit van de back-upwachtzin niet noodzakelijkerwijs administratieve toegang tot het externe opslagaccount mogen geven.

De ZimaSpace-handleiding over het controleren van elke sleutel die nodig is voor een versleuteld herstel is een nuttige aanvulling, omdat daarin toegang tot de repository, back-upversleuteling, doelopslag, containergeheimen en geheimen op applicatieniveau als afzonderlijke herstelafhankelijkheden worden behandeld.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

Client-side versleuteling is het beste voor beperkte, zeer gevoelige gegevens

Bestanden versleutelen voordat de back-uptoepassing ze leest, kan zinvol zijn wanneer een specifieke dataset zelfs voor de gebruikelijke back-uptools of beheerders ondoorzichtig moet blijven. Voorbeelden zijn een klein juridisch archief, een geëxporteerde wachtwoorddatabase, een bundel met privésleutels of een door de klant beheerde versleutelde container.

Het nadeel is dat versleuteling die te vroeg wordt uitgevoerd, de structuur kan verbergen waar het back-upsysteem anders gebruik van zou maken. Als elk gewijzigd bestand volledig andere versleutelde uitvoer oplevert, kunnen compressie en deduplicatie minder effectief worden. Ook kan het doorzoeken van afzonderlijke bestanden veranderen in een herstelproces in twee stappen: herstel eerst het versleutelde object en ontgrendel het daarna met een andere tool.

Daarom is volledige versleuteling van de dataset vooraf doorgaans een zwakkere standaardarchitectuur voor back-ups thuis dan het gebruik van een back-uptool met native geauthenticeerde repositoryversleuteling. Gebruik dit wanneer je bewust een tweede vertrouwensgrens rond een subset van de gegevens nodig hebt.

Versleuteling aan de serverzijde op afstand beschermt de opslag, niet het volledige vertrouwensmodel van back-ups

Cloudobjectopslag versleutelt gegevens doorgaans in rust. Amazon S3 past bijvoorbeeld standaard versleuteling aan de serverzijde toe en ondersteunt door AWS beheerde of door de klant beheerde KMS-sleutels. In de SSE-KMS-documentatie wordt beschreven hoe S3 de versleuteling op de bestemming uitvoert, terwijl AWS KMS de sleutels en machtigingen beheert.

Backblaze B2 ondersteunt eveneens door de provider beheerde SSE-B2 en door de klant beheerde SSE-C. In de documentatie over versleuteling aan de serverzijde staat dat SSE bestandsgegevens in rust beschermt en dat het verlies van een door de klant beheerde SSE-C-sleutel de gegevens onherstelbaar maakt.

Versleuteling aan de serverzijde is waardevol. Het helpt fysieke media en opslaginfrastructuur te beschermen, en door de klant beheerde KMS-beleidsregels kunnen sterke organisatorische controles creëren. Maar als de doelservice gegevens kan ontsleutelen zodra een geautoriseerd opslagverzoek binnenkomt, valt het doel nog steeds binnen de vertrouwelijkheidsgrens. Dit verschilt van het uploaden van een Borg-, restic- of Kopia-repository die al was versleuteld voordat deze de provider bereikte.

Gebruik off-siteversleuteling als extra verdedigingslaag

Het praktische antwoord is vaak ‘beide’. Laat de back-upapplicatie de repository-inhoud versleutelen voordat die wordt geüpload en laat vervolgens de normale versleuteling-at-rest op de bestemming ingeschakeld als extra maatregel. De twee lagen beschermen tegen verschillende gebeurtenissen.

Storing of dreiging	Repositoryversleuteling	Versleuteling aan de serverzijde van het doel
Blootstelling van clouddisk of -media	Beschermt de inhoud	Beschermt de inhoud
De opslagprovider kan geautoriseerde objecten lezen	Kan de provider buiten de vertrouwensgrens voor leesbare gegevens houden	Doorgaans niet op zichzelf
Gestolen bucketgegevens voor toegang	Gegevens kunnen zonder repositorysleutel onleesbaar blijven	Geautoriseerde leesbewerkingen kunnen nog steeds ontsleuteling activeren
Verloren back-upwachtwoord/-sleutel	Kan de repository onherstelbaar maken	Herstelt de repositorysleutel niet
Verloren door de provider beheerde opslagsleutel	De repositorylaag kan gegevens die op de bestemming niet beschikbaar zijn niet herstellen	Het herstelbeleid van de provider/KMS is van toepassing

De sleutel moet de machine die hij beschermt overleven

De belangrijkste regel voor sleutelplaatsing is eenvoudig: bewaar de enige herstelkopie van het versleutelingsgeheim niet op de server waarvan een back-up wordt gemaakt. De actuele handleiding voor het initialiseren van repositories van Borg raadt expliciet aan een back-up van de Borg-sleutel buiten zowel de repository als het systeem dat de back-ups maakt te bewaren.

Dezelfde logica geldt voor restic-wachtwoorden, Kopia-repositorywachtwoorden, age-sleutels, LUKS-herstelgegevens, cloud-KMS-beheer en hoofdsleutels van toepassingen. Een perfect versleutelde repository is nutteloos als het enige geheim voor ontsleuteling verdwijnt met de defecte opstartschijf.

Bewaar voor een huishouden of klein lab ten minste één herstelkopie offline of in een afzonderlijk systeem voor inloggegevens dat niet afhankelijk is van een actieve NAS. Test vervolgens een herstel op een schone machine. Een opgeschreven wachtwoord dat nooit is gebruikt om de repository te openen, bewijst dat de documentatie bestaat, maar niet dat herstel mogelijk is.

Welke laag moet de sleutel beheren in gangbare thuisserverontwerpen?

Back-up van een thuis-NAS naar objectopslag

Gebruik native repositoryversleuteling in restic, Borg, Kopia of een vergelijkbare back-uptool voordat de gegevens de NAS verlaten. Bewaar de repositorysleutel of het wachtwoord buiten de NAS. Laat bucketversleuteling ingeschakeld als extra verdedigingslaag. Zo blijft de cloudbestemming niet de enige vertrouwelijkheidsmaatregel.

Back-up van een thuis-NAS naar de externe server van een vriend

Geef de voorkeur aan client- of repositoryversleuteling waarvan de sleutel voor de platte tekst niet op de server van de vriend staat. De externe host kan ondoorzichtige repositoryobjecten opslaan en beperkte schrijfrechten afdwingen. Dit is vooral waardevol omdat de fysieke en administratieve controle over de externe machine tot een ander foutdomein behoort.

Lokale back-upschijf die in hetzelfde huis wordt bewaard

Versleuteling van de repository beschermt de vertrouwelijkheid nog steeds als de schijf verloren gaat of wordt gestolen. Volledige schijfversleuteling op de back-upschijf kan een nuttige tweede beveiligingslaag zijn, maar laat de ontgrendelingssleutel van de schijf niet de enige toegang tot de back-uprepository worden.

Beheerde cloudback-up met herstelfuncties van de provider

Versleuteling die door de provider wordt beheerd, kan redelijk zijn wanneer eenvoud en herstel met hulp van de leverancier belangrijker zijn dan de provider buiten de vertrouwensgrens van de platte tekst houden. Begrijp dat dit een andere beveiligingskeuze is dan clientversleuteling volgens het zero-knowledgeprincipe.

Zet niet alle back-upgeheimen in één automatiseringsbestand

Een onbeheerde back-uptaak heeft referenties nodig, maar gemak kan je beveiligingsgrenzen laten vervagen. De richtlijnen voor automatisering van restic waarschuwen dat de manier waarop wachtwoorden worden aangeleverd referenties kan blootleggen en raden aan wachtwoordbestanden zorgvuldig te beveiligen.

Scheid voor een thuisserver waar praktisch mogelijk ten minste deze rollen:

Een beperkt toegangsrecht dat toegang biedt tot het back-updoel.
Het ontsleutelingswachtwoord of de ontsleutelingssleutel van de repository.
Een offline herstelkopie van dat wachtwoord of die sleutel.
Beheerdersreferenties waarmee retentiebeleid, buckets of externe accounts kunnen worden verwijderd.

Deze scheiding is belangrijker dan beslissen of één specifiek geheim wordt opgeslagen in een bestand, omgevingsvariabele, wachtwoordmanager, hardwaretoken of KMS. De architectuur moet voorkomen dat één gestolen automatiseringsreferentie tegelijkertijd leesrechten op platte tekst geeft, de repository kan verwijderen en de enige herstelsleutel kan vernietigen.

Versleuteling vervangt onveranderlijkheid of hersteltests niet

Vertrouwelijkheid, integriteit, verwijderingsbestendigheid en herstelbaarheid zijn afzonderlijke doelstellingen. Een versleutelde repository kan nog steeds worden verwijderd. Een onveranderlijke bucket kan nog steeds back-ups bevatten waarvan de ontsleutelingssleutel verloren is gegaan. Een succesvol voltooide back-uptaak kan nog steeds mislukken tijdens het herstel.

De vergelijking van ZimaSpace tussen een externe back-upserver en cloudobjectopslag voor back-ups van virtuele machines komt tot dezelfde operationele conclusie: het label van het doel is minder belangrijk dan de vraag of een daadwerkelijk herstel is getest.

Beslismatrix

Prioriteit	Voorkeursbeheer van sleutels
Houd cloud-/externe beheerders weg van platte tekst	Client of versleutelde back-uprepository
Behoud deduplicatie en back-upbewuste herstelbewerkingen	Systeemeigen repositoryversleuteling
Laagste operationele complexiteit	Door de provider beheerde doelversleuteling, met acceptatie van een bredere vertrouwensgrens
Sterke defense-in-depth	Repositoryversleuteling + versleuteling aan de serverzijde van het doel
Bescherm een zeer kleine, uiterst gevoelige subset afzonderlijk	Voorversleuteling door de client + normale repositoryback-up
Herstel na een ramp na verlies van de bron	Elk model met een onafhankelijke, geteste herstelkopie van de sleutel

Eindoordeel

Laat bij de meeste zelfgehoste back-upsystemen de back-upclient of de repositoryindeling de grens voor inhoudsversleuteling bepalen, en laat het off-sitedoel opnieuw versleutelen tijdens opslag. Zo blijven back-upfuncties zoals deduplicatie en verificatie behouden, terwijl u minder hoeft te vertrouwen op het externe opslagsysteem voor toegang tot platte tekst.

Het sleutelbeheerplan is pas compleet wanneer het ontsleutelingsgeheim behouden blijft na verlies van de bronserver, het opslagdoel en het normale beheerderswerkstation. Test die aanname vanaf een schoon systeem voordat u de back-up herstelbaar noemt.

Veelgestelde vragen

Is versleuteling aan de serverzijde van de cloud voldoende voor thuisback-ups?

Het beschermt gegevens in rust, maar houdt de opslagdienst doorgaans binnen de vertrouwensgrens voor ontsleuteling. Gebruik ook versleuteling die eigen is aan de back-up wanneer u niet wilt dat de provider of een gestolen opslagreferentie voldoende is om toegang tot platte tekst te krijgen.

Moet de sleutel van de repository in de repository worden opgeslagen?

Sommige back-upindelingen slaan een versleuteld sleutelobject op in de repository, maar herstel blijft afhankelijk van een ander geheim, zoals een sterk wachtwoord. Bewaar onafhankelijk herstelmateriaal buiten zowel de repository als het bronsysteem.

Verbetert het versleutelen van bestanden vóór de back-up de beveiliging?

Het kan een extra vertrouwensgrens creëren voor gevoelige subsets, maar als u alles versleutelt voordat de back-uptool het ziet, kunnen deduplicatie, compressie, zichtbaarheid van metadata en het gemak van herstellen afnemen.

Wat is de belangrijkste test voor sleutelbeheer?

Herstellen vanaf een schoon systeem nadat u ervan bent uitgegaan dat de oorspronkelijke NAS volledig onbeschikbaar is. Als u niet elke inloggegevens kunt terugvinden en representatieve gegevens kunt ontsleutelen, is het sleutelplan onvolledig.