Szyfrowanie at rest vs in transit: oba są ważne

Szyfrowanie in transit chroni dane przemieszczające się między dwoma punktami — np. Twoją przeglądarką a serwerem — przy użyciu TLS 1.3 z AES-256-GCM lub ChaCha20-Poly1305. Szyfrowanie at rest chroni dane zapisane na dysku, zazwyczaj za pomocą AES-256-XTS dla szyfrowania pełnego dysku lub AES-256-GCM dla poszczególnych plików. Żadne z nich osobno nie wystarczy. TLS chroni przed podsłuchiwaniem sieci, ale odszyfrowuje na serwerze; szyfrowanie at rest chroni przechowywane dane, ale jest bezużyteczne, jeśli klucze leżą obok zaszyfrowanego tekstu. Prawdziwe bezpieczeństwo pochodzi z łączenia obu — najlepiej z szyfrowaniem po stronie klienta (end-to-end), by serwer nigdy nie widział tekstu jawnego.

Dwa różne zagrożenia, dwa różne mechanizmy kontroli

Zagrożenia wyglądają inaczej w zależności od tego, gdzie przebywają Twoje dane:

In transit (ścieżka sieciowa): atakujący w kawiarni z analizatorem pakietów, skompromitowany router ISP, przechwycenie przez podmorskie kable. Dokumenty Snowdena z 2013 roku ujawniły program NSA MUSCULAR podsłuchujący wewnętrzne łącza światłowodowe Google. Ochrona: TLS 1.3, najlepiej z przypinaniem certyfikatów dla aplikacji.

At rest (przechowywanie): skradziony laptop, wyciek taśmy z kopią zapasową, źle skonfigurowany zasobnik S3, nieuczciwy pracownik centrum danych z dostępem do dysku. Naruszenie Equifax z 2017 roku ujawniło dane 147 milionów osób częściowo dlatego, że były przechowywane bez szyfrowania. Ochrona: LUKS, BitLocker, FileVault dla dysków; AES-256-GCM lub AES-256-XTS dla poszczególnych plików lub bloków.

Błędem jest traktowanie jednego jako substytutu drugiego. TLS nie chroni zrzutu bazy danych. Szyfrowanie dysku nie zatrzyma ataku man-in-the-middle.

Jak TLS 1.3 chroni dane in transit

TLS 1.3, znormalizowany w RFC 8446 (2018), jest nowoczesnym standardem. Używa:

Tajności przekazywania domyślnie poprzez efemeryczną wymianę kluczy ECDHE. Nawet jeśli długoterminowy klucz serwera wycieknie, poprzednie sesje pozostają chronione.
Wyłącznie szyfrów AEAD — AES-128-GCM, AES-256-GCM lub ChaCha20-Poly1305. Stare tryby CBC i RC4 zostały wyeliminowane.
Jednorazowego uzgadniania (1-RTT) lub bez uzgadniania (0-RTT) przy wznowieniu.
Zaszyfrowanego uzgadniania, więc pasywni obserwatorzy nie widzą łańcucha certyfikatów.

Każda wiarygodna usługa transferu plików — WeTransfer, SwissTransfer, Tresorit, Proton Drive, HexaTransfer — działa na TLS 1.3 z nagłówkami HSTS wymuszającymi HTTPS przez co najmniej 12 miesięcy. Możesz to sprawdzić narzędziem SSL Labs testssl; cokolwiek poniżej A- ma problemy z konfiguracją.

Jak działa szyfrowanie at rest na serwerze

Gdy pliki docierają i TLS się kończy, przejmuje szyfrowanie at rest. Istnieje kilka warstw:

Na poziomie bloku (pełny dysk): AES-256-XTS w LUKS (Linux), BitLocker (Windows), FileVault (macOS) lub odpowiedniki chmurowe jak szyfrowanie AWS EBS. Chroni przed kradzieżą dysków.
Na poziomie systemu plików: eCryptfs, Fscrypt na ext4/F2FS. Pliki każdego użytkownika szyfrowane oddzielnymi kluczami.
Na poziomie przechowywania obiektów: AWS S3 SSE-KMS, Azure Blob z szyfrowanie usługi Storage Service Encryption, Google Cloud Storage z kluczami zarządzanymi przez klienta. Każdy obiekt szyfrowany za pomocą AES-256-GCM.
Na poziomie aplikacji: usługa szyfruje każdy plik we własnym kodzie przed zapisem do przechowywania, z kluczami przechowywanymi w KMS lub HSM.

Poziom aplikacyjny jest najsilniejszy, ponieważ szyfrowanie następuje zanim jakikolwiek system pamięci masowej zobaczy dane. AWS KMS pobiera 1 USD/klucz/miesiąc plus 0,03 USD za 10 000 żądań — wystarczająco tanie, by poważne usługi stosowały to per plik.

Pułapka kluczy obok zaszyfrowanego tekstu

Tu szyfrowanie at rest często zawodzi. Jeśli klucze są przechowywane na tym samym serwerze co zaszyfrowany tekst, atakujący który naruszy serwer, zdobywa oba. Dostawca może technicznie zaznaczyć „szyfrowanie at rest" dla celów zgodności, oferując zerową rzeczywistą ochronę przed kompromitacją serwera.

Dobre architektury rozdzielają obowiązki:

Zaszyfrowany tekst na S3 lub podobnym przechowywaniu obiektów.
Klucze szyfrowania w AWS KMS, Google Cloud KMS, Azure Key Vault lub dedykowanym HSM.
Dostęp do kluczy bramkowany krótkotrwałymi poświadczeniami IAM i dziennikami audytu.

Świetne architektury idą dalej: klucze nigdy nie istnieją na serwerze. Szyfrowanie po stronie klienta (E2EE) oznacza, że przeglądarka użytkownika generuje klucz, szyfruje plik i zachowuje klucz. Serwer przechowuje zaszyfrowany tekst i nie ma nic do ujawnienia.

Gdzie pojawiają się luki w szyfrowaniu

Nawet przy obu mechanizmach kontroli, dane są chwilowo jako czysty tekst w kilku miejscach:

W pamięci serwera podczas przetwarzania przesyłania, skanowania antywirusowego lub generowania miniatur. Zrzut pamięci w tym oknie ujawnia czysty tekst.
W logach dostępu, jeśli nazwy plików lub fragmenty zawartości są rejestrowane do celów debugowania.
Na taśmach z kopiami zapasowymi, jeśli kopie nie dziedziczą tego samego szyfrowania.
Podczas kompresji lub transkodowania, gdy usługa przetwarza zawartość pliku.
W pamięci podręcznej przeglądarki po pobraniu, jeśli użytkownik jej nie wyczyści.

Te luki są powodem, dla którego szyfrowanie zero-knowledge (po stronie klienta) ma znaczenie. Gdy pliki są szyfrowane w przeglądarce przed przesłaniem, luki po stronie serwera stają się nieistotne — serwer widzi wyłącznie zaszyfrowany tekst.

Co faktycznie robią największe usługi

Przybliżona klasyfikacja na podstawie publicznej dokumentacji:

Google Drive, Dropbox, OneDrive: TLS 1.3 in transit, AES-256 at rest z kluczami w posiadaniu dostawcy. Nie zero-knowledge — dostawca może odczytać Twoje pliki.
WeTransfer (bezpłatny poziom): TLS 1.3, AES-256 at rest na AWS S3. Dostawca posiada klucze.
Box Enterprise: TLS 1.3, AES-256-GCM at rest, opcjonalne klucze zarządzane przez klienta (Box KeySafe).
Tresorit, Proton Drive, SwissTransfer E2EE, HexaTransfer: TLS 1.3 in transit, AES-256-GCM at rest, ale klucze per plik są generowane po stronie klienta i nigdy nie trafiają na serwer. Efektywnie zero-knowledge.

Dla wrażliwych danych tylko ta ostatnia kategoria zapewnia rzeczywistą ochronę przed zagrożeniami wewnętrznymi i prawidłowymi żądaniami prawnymi.

Zgodność z przepisami i wymóg obrony warstwowej

Organy regulacyjne wyraźnie wymagają obu:

Art. 32 RODO nakazuje „pseudonimizację i szyfrowanie danych osobowych" bez ograniczeń co do stanu, w którym dane się znajdują.
Reguła bezpieczeństwa HIPAA 45 CFR § 164.312(a)(2)(iv) i (e)(2)(ii) wymaga szyfrowania ePHI zarówno in transit, jak i at rest.
PCI DSS 4.0 Wymagania 3 i 4 oddziela „ochronę przechowywanych danych posiadaczy kart" (at rest) od „ochrony danych posiadaczy kart silną kryptografią podczas transmisji" (in transit).
Walidacja FIPS 140-3 dotyczy modułów kryptograficznych używanych w obu kontekstach.

Zapewnienie tylko jednego jest nieprzestrzeganiem przepisów, zanim stanie się naruszeniem bezpieczeństwa.

Jak zweryfikować, czy oba są aktywne

Pięć szybkich testów dla każdej usługi transferu plików:

Uruchom testssl.sh https://dostawca.com, by potwierdzić TLS 1.3 z wyłącznie mocnymi szyframi.
Sprawdź nagłówki HSTS z max-age co najmniej 31 536 000 (jeden rok).
Przeczytaj biały papier bezpieczeństwa pod kątem wyraźnej wzmianki o AES-256-GCM lub AES-256-XTS at rest.
Potwierdź, że klucze są przechowywane w KMS lub HSM, a nie w bazie danych aplikacji.
Poszukaj certyfikatu SOC 2 Type II lub ISO 27001 — oba wymagają udokumentowanych mechanizmów kontroli at rest i in transit.

Dodatkowo: sprawdź, czy dostępne jest szyfrowanie po stronie klienta. Jeśli tak, włącz je dla wszystkiego, co jest wrażliwe.

Prawidłowe łączenie warstw

Wzorzec, który naprawdę działa:

Przeglądarka szyfruje plik losowym kluczem AES-256-GCM (po stronie klienta).
Zaszyfrowany tekst podróżuje przez TLS 1.3 do serwera (in transit).
Serwer przechowuje zaszyfrowany tekst na zaszyfrowanym magazynie AES-256 (at rest).
Klucz deszyfrujący istnieje tylko w fragmencie URL udostępniania, nigdy nie jest wysyłany do serwera.

Trzy niezależne warstwy. Złam jedną, pozostałe trzymają. To projekt stosowany przez HexaTransfer, Tresorit Send, łącza udostępniania Proton Drive i tryb E2EE SwissTransfer.

Wypróbuj na hexatransfer.com — bezpłatnie, bez konta, do 10 GB.