Zero-trust udostępnianie plików: nie ufaj nikomu, szyfruj wszystko

Udostępnianie plików w modelu zero-trust zakłada, że sieć jest wroga, serwer jest skompromitowany, a urządzenie odbiorcy może być zainfekowane — i szyfruje odpowiednio. Pliki są szyfrowane w przeglądarce nadawcy za pomocą AES-256-GCM zanim jakikolwiek bajt trafi w sieć, klucze wyprowadzane są z hasła plus soli przechowywanej w fragmencie URL, a serwer obsługuje wyłącznie nieprzejrzysty kryptotekst. To model operacyjny skodyfikowany w NIST SP 800-207 zastosowany do transferu plików: weryfikuj explicite, nadawaj minimalne uprawnienia i zakładaj naruszenie na każdej warstwie.

Trzy założenia napędzające projekt

Zero trust zaczyna od trzech przesłanek. Po pierwsze: transport jest skompromitowany — korporacyjne proxy wykonują inspekcję TLS, kawiarniany Wi-Fi uruchamia ARP spoofing, a podsłuch szkieletowy na poziomie państwa istnieje (udokumentowany przez Snowdena w 2013 r., nadal operacyjny według raportów Bloomberg z 2024 r.). Po drugie: serwer jest skompromitowany — dostawcy chmury doznają naruszeń (AWS w 2019, Microsoft w 2023), administratorzy bywają nieuczciwi, a nakazy sądowe przychodzą cicho. Po trzecie: urządzenie odbiorcy może być zainfekowane — pracownik używa przestarzałego Chrome, złośliwe oprogramowanie zbiera odszyfrowane pliki. Każda decyzja projektowa wynika z tych trzech założeń.

Szyfrowanie po stronie klienta jako zasada nadrzędna

Jeśli serwer może zobaczyć plaintext, to nie jest zero trust. Wszystko zaczyna się od przeglądarki nadawcy uruchamiającej Web Crypto API: wygeneruj 256-bitowy klucz, wyprowadź go z hasła użytkownika przez PBKDF2 przy 600 000 iteracjach, zaszyfruj plik AES-256-GCM i dopiero wtedy prześlij strumieniowo kryptotekst do serwera. Firefox Send dowiódł, że to działa w skali konsumenckiej, zanim Mozilla zamknęła go w 2020 roku. Nowocześni następcy — HexaTransfer, Wormhole, Skiff — kontynuują ten wzorzec. Serwer przechowuje bajty, których nie może odczytać.

Materiał kluczowy nigdy nie opuszcza punktów końcowych

Klucz deszyfrujący musi dotrzeć do odbiorcy bez kontaktu z serwerem. Dwa mechanizmy działają. Pierwszy: sztuczka z fragmentem URL — klucz żyje po # w linku do pobrania, którego przeglądarki nigdy nie wysyłają w żądaniach HTTP. Drugi: klucze wyprowadzone z hasła — nadawca przekazuje odbiorcy hasło przez oddzielny kanał (Signal, rozmowa telefoniczna, 1Password Psst!), a przeglądarka odbiorcy ponownie wyprowadza klucz. Obydwa podejścia trzymają materiał kluczowy poza logami serwera, pamięciami podręcznymi CDN i kopiami zapasowymi bazy danych — co ma znaczenie, gdy nieuchronne naruszenie nastąpi.

Weryfikacja kodu działającego w przeglądarce

Zero trust po stronie klienta jest trudniejszy niż po stronie serwera, bo serwer dostarcza JavaScript wykonujący szyfrowanie. Złośliwy serwer mógłby wysłać zmanipulowany bundle do jednego konkretnego użytkownika. Środki zaradcze: publikuj skróty SHA-384 każdego wydania, podpisuj je Sigstore lub korporacyjnym kluczem PGP i zachęcaj zaawansowanych użytkowników do weryfikacji przez rozszerzenia przeglądarki jak Code Verify (Meta dostarcza je dla WhatsApp Web). Nagłówki CSP z script-src 'self' i Subresource Integrity blokują wstrzykiwanie ze skompromitowanych CDN. Żadne z tych rozwiązań nie jest doskonałe, ale zawęża powierzchnię ataku.

Uwierzytelnianie bez wspólnych sekretów przechowywanych w spoczynku

Hasła wysyłane mailem i przechowywane w bazach danych serwera to antypattern zero trust. Zastąp je passkeys WebAuthn powiązanymi z urządzeniem odbiorcy — klucz prywatny nigdy nie opuszcza Secure Enclave i serwer przechowuje tylko klucz publiczny. Dla transferów jednorazowych użyj OPAQUE (RFC 9380) do uwierzytelniania hasłem, które nigdy nie transmituje ani nie przechowuje hasła po stronie serwera. Magiczne linki wysyłane na wcześniej zweryfikowane adresy e-mail oferują drogę pośrednią: entropia tokenu (128 bitów) zastępuje konieczność przechowywania sekretu.

Segmentowanie transferów według wrażliwości

Nie każdy plik zasługuje na te same zabezpieczenia. Serwis zero-trust powinien pozwalać nadawcom klasyfikować przesyłki: publiczne (bez hasła, ważność 7 dni), wewnętrzne (hasło, ważność 48 godzin), poufne (hasło + 2FA, ważność 4 godziny, jednorazowe pobranie), zastrzeżone (passkey + powiązanie IP + ważność 15 minut). Automatyzuj klasyfikację według typu pliku tam, gdzie to możliwe: .pdf zeznania podatkowego → poufny; .docx umowy → wewnętrzny; .psd materiałów marketingowych → publiczny. NIST SP 800-171 nazywa to obsługą kontrolowanych niesklasyfikowanych informacji i mapuje się to na przepływy transferu.

Traktowanie urządzenia odbiorcy jako niezaufanego

Gdy Bob odszyfruje 5 MB brief prawny Alicji, plik trafia do jego folderu Pobrane. Jeśli jego laptop jest skompromitowany, plik wycieka. Myślenie zero-trust rozciąga się tu: zachęcaj odbiorców do deszyfrowania w efemerycznym magazynie (Tails OS, sesja gościa Chrome OS), unikania deszyfrowania na współdzielonych maszynach i agresywnego czyszczenia po użyciu. Dla transferów wysokiej stawki używaj chronionych podglądów, które deszyfrują do piaskownicy w zakładce przeglądarki i uniemożliwiają pobieranie — odbiorca widzi .pdf, ale nigdy nie dostaje bajtów na dysk. To oczywiście obniża UX; zarezerwuj to dla najwyższego poziomu.

Logowanie bez tworzenia systemu inwigilacji

Ścieżka audytu zero-trust loguje tyle, ile musi dla reagowania na incydenty i zgodności — nic więcej. Hashuj adresy IP dziennie, przechowuj tylko rodziny User-Agent (nie pełne ciągi), nigdy nie loguj haseł ani kluczy i retencjonuj przez minimalny okres wymagany przez każdą regulację — 90 dni dla celów art. 30 RODO, 6 lat dla HIPAA 164.316. Sam dziennik żyje na magazynie tylko do dopisywania (S3 Object Lock, tryb Compliance), żeby skompromitowany administrator nie mógł zatrzeć śladów. Codzienne publikowanie korzeni Merkle na publicznej tablicy ogłoszeń dodaje zewnętrzną weryfikację.

Gdzie zero trust spotyka rzeczywistość prawną

Zero trust nie zwalnia z obowiązku reagowania na wnioski organów ścigania. Zmienia to, co możesz przekazać — kryptotekst, którego nie możesz odszyfrować, skróty IP, których nie możesz odwrócić, dzienniki kto uzyskał dostęp do jakiego sluga. Zazwyczaj wystarczy to do spełnienia uzasadnionego nakazu, chroniąc dane użytkowników przed masową inwigilacją. Publikuj raport przejrzystości (na wzór dawnego Twittera) pokazujący wolumeny wniosków i wskaźniki odpowiedzi. Udokumentuj minimalizację danych w polityce prywatności, żeby użytkownicy rozumieli kompromisy: możesz zweryfikować, że transfer nastąpił, ale nie możesz go odczytać ani z pewnością zidentyfikować odbiorcy.

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