VPN szyfruje podróż, a nie kopię na dysku czy w chmurze

Prześledź jeden plik od laptopa do kolegi: istnieje na dysku, przechodzi przez tunel, trafia do zasobnika w chmurze i zostaje skopiowany do kopii zapasowej. Tylko jeden z tych odcinków jest objęty VPN i jest to ten najkrócej istniejący. Pozostałe kopie trwają po zamknięciu tunelu, pod takim szyfrowaniem pamięci masowej, jakie ich właściciele faktycznie skonfigurowali. Wiedza o tym, która kopia jest czym chroniona, powstrzymuje przed braniem działającego tunelu za politykę ochrony danych.

Śledź jeden plik przez trzy kopie

Zacznij od tego, gdzie bajty spoczywają, potem od tego, gdzie się przemieszczają, a na końcu od tego, gdzie są znowu przechowywane. Tunel zajmuje środkowy etap. Po obu jego stronach szyfrowanie pamięci masowej, szyfrowanie aplikacji i kontrola dostępu to odrębne mechanizmy z odrębnymi opiekunami kluczy.

Narysuj tę ścieżkę, zanim cokolwiek wybierzesz. Rysunek zwykle pokazuje, że kopia, o którą najbardziej się martwimy, ta w drodze, istnieje najkrócej w sekundach. Pokazuje też, który przeskok nie ma nikogo w pokoju, i zwykle to on wymaga uwagi.

Praca tunelu kończy się na jego własnym punkcie końcowym

Konwencjonalny VPN szyfruje odcinek między swoimi dwoma punktami końcowymi. Za dalekim punktem końcowym ruch znów jest zwykłym IP, chyba że chroni go coś innego; dlatego sesja przeglądarki może pozostać szyfrowana od końca do końca, podczas gdy tunel obejmuje tylko pierwszy etap.

Nic w tym odcinku nie mówi, jak usługa odbierająca przechowuje wysyłkę, co zapisuje w swoich dziennikach ani jakie metadane konta zachowuje. To właściwości systemu odbierającego i pozostają prawdziwe niezależnie od tego, czy żądanie przyszło przez tunel. Operator reklamujący szyfrowany transport opisał podróż, a nie magazyn.

Twój dysk i twój magazyn kluczy to osobne decyzje

Szyfrowanie całego dysku chroni wolumin, gdy maszyna jest wyłączona, i zależy od klucza, który urządzenie lub użytkownik dostarcza przy starcie. Sejf menedżera haseł szyfruje własną zawartość kluczem pochodnym od głównego sekretu. Włączenie VPN nie robi żadnej z tych rzeczy i nie zaszyfruje eksportu w postaci zwykłego tekstu, który już leży w folderze pobierania.

Przy eksportach staje się to konkretne. Eksport sejfu napisany na potrzeby migracji to plik zwykłego tekstu ze wszystkimi sekretami, i przetrwa tunel, sesję i restart, o ile ktoś go nie usunie.

file export-notes.json
head -c 80 export-notes.json
sha256sum export-notes.json

Jeśli ten wynik jest czytelnym tekstem, plik jest niechroniony. Usuń go, gdy tylko migracja się skończy, i pamiętaj, że bezpieczne kasowanie na nowoczesnej pamięci masowej zależy od urządzenia, a nie jest jednym przenośnym poleceniem.

Co faktycznie obejmuje szyfrowanie po stronie chmury

Szyfrowanie po stronie serwera chroni przechowywany obiekt przed kimś, kto zdobędzie nośnik bazowy, a dostawca nadal ma klucze pozwalające go odczytać. Szyfrowanie po stronie klienta, w którym plik jest szyfrowany przed wysłaniem, trzyma zwykły tekst poza zasięgiem dostawcy, ale przenosi przechowywanie kluczy i odzyskiwanie na ciebie.

Żaden z modeli nie jest błędny i odpowiadają one na różne pytania o to, kto powinien móc czytać dane. Sprawdź rzeczywistą konfigurację produktu, zamiast zakładać, że jeden implikuje drugi. Czytaj dosłownie oświadczenie o przechowywaniu kluczy, w tym co się dzieje, gdy pomoc techniczna odzyskuje konto. Jeśli dostawca może przywrócić dostęp bez twojego klucza, to dostawca może odczytać obiekt.

Kopie mnożą się po cichu. Udostępniony link, klient synchronizacji, lokalna pamięć podręczna i zadanie kopii zapasowej tworzą każde kolejny obiekt w ramach polityki, której być może nie wybrałeś. Wymień je dla danych, które się liczą, bo najsilniejsze szyfrowanie na ścieżce jest bez znaczenia, jeśli kopia w zwykłym tekście leży w udostępnionym folderze.

Dowodem jest odtworzenie, nie prędkość wysyłania

Użytecznym dowodem projektu przechowywania jest to, że zamierzone osoby mogą odzyskać dane, a niezamierzone nie. Przepustowość wysyłania mierzy coś zupełnie innego i schlebia każdemu projektowi, który nigdy nie został odtworzony. Wybierz jeden plik z każdej kopii, na której polegasz, i udowodnij, że wraca.

Odtwórz jeden plik z każdej kopii, na której polegasz, używając materiału odtworzeniowego, a nie sesji, która go utworzyła. Klucz trzymany tylko w maszynie, która uległa awarii, nie jest planem odtworzenia, a kopia zapasowa, której odtworzenie wymaga utraconego sejfu, jest innym rodzajem jednego punktu awarii.

Wytyczne NIST dotyczące zarządzania kluczami obejmują kwestie cyklu życia, które przeżywają każdą pojedynczą decyzję produktową. Przechowuj odpowiedzi razem z danymi, które chronią, i przeglądaj je, gdy zmienia się kopia, odbiorca lub dostawca pamięci masowej.