Bezpieczny transfer plików projektu: szyfrowane udostępnianie

Bezpieczny transfer plików projektu oznacza, że pliki są nieczytelne dla kogokolwiek poza nadawcą i odbiorcą — łącznie z samą usługą transferu. Mechanizmem, który to zapewnia, jest szyfrowanie end-to-end z AES-256-GCM, klucz derywowany z hasła uzgodnionego przez obie strony niezależnie od linku. Przesyłanie szyfruje dane w przeglądarce; pobieranie deszyfruje w przeglądarce. Serwer przechowuje wyłącznie szyfrogram. Slack, załączniki e-mailowe i zwykłe przechowywanie w chmurze nie spełniają tego wymogu. Dla plików projektu zawierających specyfikacje produktów, niepublikowany kod lub dane klientów objęte umową NDA, link transferowy w modelu zero-wiedzy to minimalny dopuszczalny kanał.

Co sprawia, że transfer jest „bezpieczny" w konkretnym sensie

„Bezpieczny" to słowo nadużywane przez firmy. Oto lista kontrolna ze szczegółami:

Szyfrowanie w tranzycie: TLS 1.3 (RFC 8446) z nowoczesnymi zestawami szyfrów (TLS_AES_256_GCM_SHA384). Standard w każdej przeglądarce i serwerze od 2018 roku.
Szyfrowanie w spoczynku: AES-256 na warstwie składowania, klucze rotowane. Każdy poważny dostawca to stosuje.
Szyfrowanie end-to-end (E2EE): klucz jawny nigdy nie istnieje na serwerze. To najtrudniejsza część — większość „bezpiecznych" usług ją pomija.
Szyfrowanie uwierzytelnione: AES-256-GCM (NIST SP 800-38D) wytwarza szyfrogram i 128-bitowy tag. Manipulacja jest wykrywalna podczas deszyfrowania.
Silna derywacja klucza: PBKDF2-HMAC-SHA256 z 600 000+ iteracjami (wytyczne OWASP 2023) lub Argon2id.
Brak wycieku metadanych: nazwy plików i rozmiary nie są ujawniane serwerowi ponad konieczność.
Wygaśnięcie i odwołanie: linki usuwane automatycznie; nadawca może odwołać przed wygaśnięciem.

Większość narzędzi korporacyjnych spełnia pierwsze dwa warunki. Bardzo niewiele — wszystkie siedem.

Dlaczego Slack, e-mail i OneDrive nie wystarczają

Bezpłatny Slack kompresuje załączniki, ogranicza do 1 GB na plik w planach płatnych i przechowuje wszystko na AWS, a Slack posiada klucze deszyfrowania. Administrator Slacka — lub każdy z dostępem do eksportu przestrzeni roboczej — może odczytać każdy kiedykolwiek wysłany plik. To akceptowalne dla publicznego dokumentu marketingowego; nie jest akceptowalne dla pokoju danych transakcji fuzji i przejęć.

E-mail (SMTP + TLS) jest szyfrowany punkt-do-punktu między serwerami, co oznacza, że każdy serwer pocztowy po drodze deszyfruje i ponownie szyfruje. S/MIME i PGP są end-to-end, ale wymagają zarządzania certyfikatami/kluczami, które 99% zespołów nigdy nie konfiguruje.

OneDrive, Google Drive i Dropbox szyfrują w spoczynku. Dostawca posiada klucze. Ważne postanowienie sądu, nieuczciwy administrator lub zhakowana usługa zarządzania kluczami naraża każdy plik.

Szyfrowanie end-to-end krok po kroku

Oto co się dzieje, gdy przesyłasz archiwum projektu do właściwie zbudowanej usługi E2EE:

Wpisujesz hasło w przeglądarce. Usługa derywuje 256-bitowy klucz za pomocą PBKDF2-HMAC-SHA256, używając losowej 128-bitowej soli i 600 000 iteracji. Hasło nigdy nie opuszcza przeglądarki.
Plik dzielony jest na 5 MB fragmenty. Każdy fragment otrzymuje świeży 96-bitowy IV (nonce).
Każdy fragment szyfrowany jest za pomocą AES-256-GCM. Wynik: szyfrogram + 128-bitowy tag uwierzytelniania na fragment.
Zaszyfrowane fragmenty przesyłane są na serwer przez TLS 1.3. Serwer widzi zaszyfrowane bajty, IV i tag. Nigdy klucz, nigdy hasło.
Usługa zwraca URL. Udostępniasz URL jednym kanałem (e-mail, Slack) i hasło innym (SMS, telefon, udostępniony skarbiec menedżera haseł).
Odbiorca otwiera URL, wpisuje hasło, przeglądarka ponownie derywuje ten sam klucz (sól przesyłana jest razem z szyfrogramem), deszyfruje każdy fragment i składa plik.

Jeśli serwer zostanie jutro zhakowany, atakujący otrzyma szyfrogramy i sole — bezużyteczne bez hasła. To jest model zero-wiedzy z definicji.

Ochrona kanału hasła

Najsilniejsze szyfrowanie zawodzi, jeśli hasło podróżuje w tym samym e-mailu co link. Oddzielne kanały:

Link e-mailem, hasło SMS-em
Link w wiadomości Slack DM, hasło przez Signal
Link w narzędziu do zarządzania projektem, hasło w 1Password Shared Vault
W przypadku wysokich stawek: link online, hasło przez telefon

Dla zespołów używaj menedżera haseł (1Password, Bitwarden, Keeper) z udostępnionymi skarbcami przypisanymi do projektu. Hasło tam żyje; ludzie widzą je dołączając do skarbca; nikt nie wkleja go do e-maila.

Typy plików projektu i ich zawartość

| Plik | Typowa zawartość | Dlaczego szyfrowanie ma znaczenie | | --- | --- | --- | | .fig kopia zapasowa Figma | Niepublikowany UI, znaki towarowe | Ryzyko wycieku konkurencyjnego | | .rvt model Revit | Plany budynku, adres klienta | Implikacje dla bezpieczeństwa fizycznego | | .psd master Photoshop | Kreatywne materiały kampanii przed premierą | Ryzyko reputacyjne marki | | .docx szkic umowy | Ceny, warunki, strony | Odpowiedzialność za naruszenie NDA | | .zip kod źródłowy | Własnościowe algorytmy | Kradzież własności intelektualnej | | .dicom obrazowanie medyczne | Dane zdrowotne pacjenta | Naruszenie HIPAA / RODO | | .csv eksport klientów | Dane osobowe | Uruchamia Art. 32 RODO |

Usługa transferu mogąca odczytać plik staje się uczestnikiem ryzyka. E2EE usuwa usługę z modelu zagrożeń.

Retencja i cykl życia projektu

Dopasuj wygaśnięcie transferu do kamieni milowych projektu. Dla dostarczenia sprintu dwutygodniowego 14-dniowe wygaśnięcie jest idealne — plik znika gdy sprint się kończy. Dla kwartalnego raportu klienta 30 dni. Dla długoterminowego pokoju danych M&A używaj dedykowanego VDR (Virtual Data Room) — Intralinks lub Firmex — nie ogólnego linku transferowego.

Po wygaśnięciu sprawdź, czy coś było ponownie wysyłane. Jeśli ten sam plik projektu krąży w pięciu oddzielnych transferach, lepiej umieścić go w zaszyfrowanej przestrzeni roboczej (Tresorit, Proton Drive lub samodzielnie hostowany Nextcloud z szyfrowaniem po stronie serwera).

Ślady audytu dla zespołów regulowanych

Zespoły podlegające ISO 27001, SOC 2 Type II lub RODO muszą rejestrować, kto co wysłał, kiedy i kiedy zostało pobrane. Dobra usługa transferu udostępnia:

Tożsamość nadawcy (lub znacznik czasu przesyłania + IP jeśli anonimowy)
Znacznik czasu pobrania przez odbiorcę
Znacznik wygaśnięcia i usunięcia
Webhook przy pobraniu, wysyłany e-mailem lub do Slacka

HexaTransfer rejestruje te zdarzenia bez przechowywania treści pliku w postaci jawnej. Ślad audytu potwierdza dostarczenie bez naruszania właściwości zero-wiedzy.

Porównanie bezpiecznych usług transferu dla zespołów

| Usługa | Szyfrowanie E2E | Hasło na linku | Wygaśnięcie | Webhook pobierania | Maks. rozmiar (bezpłatny) | | --- | --- | --- | --- | --- | --- | | Przesyłanie pliku Slack | Nie | Nie | Retencja przestrzeni | Nie | 1 GB | | Link Google Drive | Nie | Opcjonalne | Ręczne | Nie | Limit 15 GB | | Tresorit Send | Tak (wspomagane serwerem) | Tak | Do 7 dni | Tak | 5 GB bezpłatnie | | WeTransfer Pro | Nie | Tak | Do 365 dni | Tak | 20 GB | | HexaTransfer | Tak (AES-256-GCM w przeglądarce) | Tak | Konfigurowalne | Tak | 10 GB |

Jedna kwestia na zakończenie: nie szyfruj podwójnie tego, co jest już zaszyfrowane

Jeśli plik źródłowy to zaszyfrowane GPG .asc lub .7z z wbudowanym AES-256, dodanie szyfrowania w przeglądarce jest zbędne i nie zwiększa bezpieczeństwa. Wybierz jedną warstwę, zrób ją właściwie, przekaż klucz poza pasmem i idź dalej.

Bezpieczny transfer to kwestia modelu zagrożeń, nie tekstu marketingowego. E2EE oddaje kontrolę tam, gdzie należy — do dwóch osób, które powinny móc odczytać plik.

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