Privacy by Design: zasady dla narzędzi transferu plików

Artykuł 25 RODO nakłada na projektantów oprogramowania obowiązek wbudowania ochrony danych osobowych bezpośrednio w architekturę systemu — zanim jeszcze zostanie napisana pierwsza linijka kodu. Dla narzędzi transferu plików oznacza to, że domyślna konfiguracja już chroni dane użytkowników bez konieczności zmieniania jakichkolwiek ustawień. UODO (Urząd Ochrony Danych Osobowych) systematycznie kontroluje, czy administratorzy faktycznie wdrażają zasadę Privacy by Design, a nie tylko deklarują jej stosowanie w politykach prywatności. Naruszenia kosztują — i to niemało.

Siedem zasad Cavoukian w praktyce transferu plików

Ann Cavoukian sformułowała swoją ramę w latach dziewięćdziesiątych, ale jej siedem zasad — proaktywność, prywatność jako domyślne ustawienie, wbudowanie w projekt, pełna funkcjonalność, bezpieczeństwo end-to-end, widoczność i przejrzystość, poszanowanie prywatności użytkownika — przekłada się bezpośrednio na architekturę narzędzi do przesyłania plików.

Proaktywność: wykrywanie słabych szyfrów w kodzie źródłowym przez automatyczne skanowanie SAST przed wdrożeniem produkcyjnym. Domyślne ustawienie: AES-256-GCM włączone bez możliwości wyłączenia. Wbudowanie: szyfrowanie zachodzi w potoku przesyłania, a nie jako osobny krok. Pełna funkcjonalność: zaszyfrowane pliki nadal obsługują podglądy poprzez odszyfrowanie po stronie klienta. Bezpieczeństwo end-to-end: platforma nigdy nie ma dostępu do tekstu jawnego. Przejrzystość: specyfikacja szyfrowania jest publicznie dostępna. Szacunek: użytkownicy kontrolują retencję i daty wygaśnięcia linków.

Artykuł 25 ust. 1 RODO: obowiązki na etapie projektowania

Artykuł 25 ust. 1 wymaga wdrożenia odpowiednich środków technicznych „zarówno przy określaniu sposobów przetwarzania, jak i w czasie samego przetwarzania". Oznacza to, że decyzje dotyczące prywatności muszą zapadać na etapie projektowania architektury, a nie jako późniejsze poprawki. Przed napisaniem pierwszej linii kodu należy wybrać: protokół transportowy (HTTPS z TLS 1.3), algorytm szyfrowania (AES-256-GCM lub XChaCha20-Poly1305), funkcję derywacji klucza (PBKDF2-SHA-256 przy 600 000 iteracjach lub Argon2id) oraz region przechowywania danych (UE). Wybory te należy udokumentować w rejestrze decyzji architektonicznych, aby przyszli inżynierowie rozumieli nałożone ograniczenia.

Artykuł 25 ust. 2 RODO: domyślna konfiguracja

Artykuł 25 ust. 2 określa cztery wymagania dotyczące domyślnych ustawień: minimalizacja ilości przetwarzanych danych osobowych, ograniczenie zakresu przetwarzania, ograniczenie okresu przechowywania oraz ograniczenie dostępności. Dla narzędzia transferu plików przekłada się to na: zbieranie wyłącznie adresów e-mail nadawcy i odbiorcy (bez imienia, numeru telefonu czy adresu), jednorazowe przetwarzanie pliku i jego usunięcie, domyślny 7-dniowy okres przechowywania oraz dostęp ograniczony wyłącznie do wskazanych odbiorców — nie do publicznych linków indeksowanych przez wyszukiwarki. Dla porównania, publiczne linki do udostępniania w bezpłatnym WeTransfer są wygodne, ale nie spełniają wymogów Artykułu 25 ust. 2 bez dodatkowych zabezpieczeń.

Minimalizacja danych w procesie przesyłania

Formularz przesyłania pliku to miejsce, gdzie zaczyna się minimalizacja. Złe podejście: zbieranie imienia, nazwiska, firmy, telefonu, danych odbiorcy i treści wiadomości — każde pole to dodatkowy punkt danych osobowych przechowywany i analizowany. Dobre podejście: tylko adres e-mail, opcjonalne pole wiadomości, brak pikseli śledzących. Metadane EXIF należy usuwać ze zdjęć po stronie serwera, jeśli usuwanie po stronie klienta nie jest dostępne. Nazwy plików zawierające dane osobowe należy haszować w dzienniku audytu, przechowując odwzorowanie wyłącznie po stronie serwera z odpowiednimi kontrolami dostępu.

Szyfrowanie domyślne bez kompromisów wydajnościowych

AES-256-GCM w nowoczesnych przeglądarkach za pomocą Web Crypto API działa z prędkością około 200–500 MB/s na laptopie z 2020 roku. Plik 100 MB szyfruje się w ułamku sekundy. Libsodium z XChaCha20-Poly1305 osiąga porównywalną wydajność. Argument o wydajności jako powodzie, dla którego szyfrowanie miałoby być opcjonalne, jest dziś bezpodstawny. Należy stosować klucze per-plik wywodzone z sekretu przechowywanego przez użytkownika — hasła lub losowego klucza osadzonego we fragmencie URL (po znaku #, który serwer nigdy nie widzi). Architektura Firefox Send z lat 2017–2019 stanowi sprawdzony wzorzec: klucz był przenoszony we fragmencie URL, serwer widział wyłącznie zaszyfrowany tekst.

Pseudonimizacja danych w systemie logowania

Artykuł 4 ust. 5 RODO definiuje pseudonimizację, a motyw 28 zachęca do jej stosowania przez cały cykl przetwarzania danych. W przypadku transferu plików pseudonimizacja oznacza zastępowanie bezpośrednich identyfikatorów w metadanych systemowych: adres e-mail nadawcy staje się skrótem SHA-256 w dzienniku audytu, przy czym tabela odwzorowania przechowywana jest oddzielnie z bardziej rygorystycznymi kontrolami dostępu. Jeśli atakujący uzyska dostęp wyłącznie do dziennika audytu, zobaczy wyłącznie skróty, a nie pełny graf kontaktów. Tabela odwzorowania — mniejsza i znajdująca się w oddzielnym sejfie — chroniona jest innymi kluczami i politykami dostępu.

Przejrzystość przez opublikowaną architekturę

Artykuł 25 RODO nie wymaga oprogramowania open source, ale przejrzystość jest fundamentalną zasadą Privacy by Design. Należy publikować: specyfikację szyfrowania (algorytm, KDF, liczba iteracji, długość tagu uwierzytelnienia), diagram przepływu danych, listę podmiotów przetwarzających z jurysdykcjami, harmonogram retencji, oś czasu powiadomień o naruszeniach oraz schemat dziennika audytu. Sformułowania o „szyfrowaniu klasy wojskowej" bez podania konkretnego algorytmu to sygnał ostrzegawczy. Jeśli dostawca nie podaje nazwy szyfru, należy założyć słabe zabezpieczenia. HexaTransfer publikuje pełną specyfikację techniczną swojej architektury szyfrowania.

Kontrole użytkownika jako domyślna funkcja

Privacy by Design traci sens, gdy kontrole bezpieczeństwa są dostępne wyłącznie w płatnych planach. Linki chronione hasłem nie powinny być płatną funkcją. Limity pobierania nie powinny wymagać subskrypcji premium. Cofnięcie dostępu do linku nie powinno wymagać kontaktu z pomocą techniczną. Minimalna ochrona prywatności — termin ważności, hasło, możliwość cofnięcia, powiadomienia o pobraniach — powinna być bezpłatna. Płatne plany mogą oferować skalowalność (więcej miejsca, zarządzanie zespołem) lub wygodę (linki z własną marką, dłuższa retencja). To zarówno podejście zgodne z RODO, jak i budujące zaufanie użytkowników.

Dzienniki audytu zgodne z zasadą minimalizacji

Same dzienniki audytu to dane osobowe. Zbyt obszerne logowanie tworzy nową powierzchnię potencjalnych naruszeń. Zbyt skąpe uniemożliwia spełnienie wymogów Artykułu 33 RODO i udowodnienie zgodności na podstawie Artykułu 5 ust. 2. Właściwa równowaga: rejestrowanie typu zdarzenia, znacznika czasu, skrótu identyfikatora pliku, skrótu identyfikatora aktora i wyniku operacji. Nie należy rejestrować pełnych adresów IP — należy skracać je do /24 dla IPv4 lub /64 dla IPv6. Nie należy rejestrować pełnych ciągów user-agent — wystarczy wyodrębnić rodzinę przeglądarki i wersję główną. Dzienniki należy przechowywać przez minimalny wymagany okres (zazwyczaj sześć miesięcy) i szyfrować potok logowania end-to-end.

Weryfikacja architektury przed wdrożeniem

Należy przeprowadzić audyt przepływu danych z inżynierem, który nie brał udziału w tworzeniu systemu. Pytania kontrolne: jakie dane osobowe przepływają przez każdy system? Gdzie są przechowywane? Jak długo? Kto ma do nich dostęp? Jak jest logowany dostęp? Jak dane są usuwane? Odpowiedzi należy porównać z zobowiązaniami Artykułu 25 udokumentowanymi w Ocenie Skutków dla Ochrony Danych (DPIA). Test penetracyjny powinien weryfikować zadeklarowaną architekturę: czy serwer rzeczywiście widzi wyłącznie zaszyfrowany tekst? Czy klucz we fragmencie URL naprawdę nie pojawia się w dziennikach? Usługi z HexaTransfer i 7-dniowym wygaśnięciem oraz szyfrowanie AES-256-GCM po stronie klienta przechodzą te testy, ponieważ architektura robi dokładnie to, co opisuje dokumentacja.

Prywatność należy wbudować od podstaw, a nie doklejać na końcu. Wypróbuj na hexatransfer.com — bezpłatnie, bez rejestracji, do 10 GB.