VPN krypterar resan, inte kopian på disken eller i molnet
En tunnel skyddar ett segment av en enda överföring. Diskvolymer, lösenordsvalv och molnkopior behöver var sin kryptering och var sin nyckelhantering.
Följ en fil från en bärbar dator till en kollega: den finns på disken, korsar en tunnel, landar i en molnbucket och kopieras till en säkerhetskopia. Bara ett av dessa segment täcks av VPN:en, och det är det kortast levande. De andra kopiorna finns kvar efter att tunneln stängts, under vilken lagringskryptering deras ägare faktiskt har konfigurerat. Att veta vilken kopia som skyddas av vad hindrar en fungerande tunnel från att misstas för en dataskyddspolicy.
Följ en fil genom tre kopior
Börja med var byten vilar, sedan var den rör sig, sedan var den lagras igen. Tunneln sitter i det mellersta steget. På båda sidor om den är lagringskryptering, applikationskryptering och åtkomstkontroll separata mekanismer med separata nyckelförvarare.
Rita den vägen innan du väljer något. Ritningen visar oftast att kopian som de flesta oroar sig för, den under transport, är den som finns i minst sekunder. Den visar också vilket hopp som inte har någon ägare i rummet, och det är oftast det som behöver uppmärksamhet.
Tunnelns uppgift slutar vid dess egen ändpunkt
Ett konventionellt VPN krypterar segmentet mellan sina två ändpunkter. Bortom den bortre ändpunkten är trafiken återigen vanlig IP, om inte något annat skyddar den, och därför kan en webbläsarsession förbli krypterad hela vägen medan tunneln bara täcker den första etappen.
Inget i det segmentet säger hur mottagartjänsten lagrar uppladdningen, vad den skriver i sina loggar eller vilka kontometadata den behåller. Det är egenskaper hos det mottagande systemet, och de gäller oavsett om begäran kom via en tunnel eller inte. En leverantör som annonserar krypterad transport har beskrivit resan, inte lagret.
Din disk och din nyckelförvaring är separata beslut
Full diskkryptering skyddar volymen när maskinen är avstängd, och den beror på en nyckel som enheten eller användaren tillhandahåller vid start. Ett lösenordshanterarvalv krypterar sitt eget innehåll med en nyckel som härleds från en huvuduppgift. Att slå på ett VPN gör inget av detta, och det krypterar inte en klartextsexport som redan ligger i en nedladdningsmapp.
Vid exporter blir det konkret. En valvexport skriven för en migrering är en klartextfil med alla hemligheter i, och den överlever tunneln, sessionen och omstarten om inte någon tar bort den.
file export-notes.json
head -c 80 export-notes.json
sha256sum export-notes.json
Om den utskriften är läsbar text är filen oskyddad. Radera den så snart migreringen är klar, och kom ihåg att säker radering på modern lagring är enhetsspecifik och inte ett enda portabelt kommando.
Vad kryptering på molnsidan faktiskt täcker
Serversidig kryptering skyddar det lagrade objektet från någon som får tag i det underliggande mediet, och leverantören har fortfarande nycklar som kan läsa det. Klientsidig kryptering, där filen krypteras före uppladdning, håller klartexten utom leverantörens räckvidd men flyttar nyckelförvaring och återställning till dig.
Ingen av modellerna är fel, och de besvarar olika frågor om vem som bör kunna läsa data. Kontrollera den faktiska produktkonfigurationen i stället för att anta att den ena förutsätter den andra. Läs uttalandet om nyckelförvaring bokstavligt, inklusive vad som händer när ett konto återställs av supporten. Om leverantören kan återställa åtkomst utan din nyckel kan leverantören läsa objektet.
Kopior förökar sig tyst. En delad länk, en synkklient, en lokal cache och ett säkerhetskopieringsjobb skapar var sitt objekt under en policy du kanske inte valt. Räkna upp dem för de data som betyder något, för den starkaste krypteringen i vägen är irrelevant om en klartextkopia ligger i en delad mapp.
Beviset är en återställning, inte en uppladdningshastighet
Det användbara beviset för en lagringsdesign är att de avsedda personerna kan återställa data och de oavsedda inte. Uppladdningsgenomströmning mäter något helt annat, och det smickrar varje design som aldrig återställdes. Välj en fil från varje kopia du förlitar dig på och bevisa att den kommer tillbaka.
Återställ en fil från varje kopia du förlitar dig på, med återställningsmaterialet i stället för sessionen som skapade den. En nyckel som bara finns i maskinen som gick sönder är ingen återställningsplan, och en säkerhetskopia vars återställning kräver valvet du förlorade är på ett annat sätt en enda felpunkt.
NIST:s vägledning för nyckelhantering täcker livscykelfrågorna som överlever varje enskilt produktbeslut. Förvara svaren tillsammans med de data de skyddar, och granska dem när en kopia, en mottagare eller en lagringsleverantör ändras.