Po co szyfrować przed wysyłką: ograniczenie zaufania do dostawcy
Dostawca chmury ma techniczną możliwość wglądu w dane, chyba że zaszyfrujesz je po swojej stronie. Szyfrowanie client-side sprawia, że operator widzi jedynie zaszyfrowane bloki i nie odczyta treści bez klucza. Zmniejszasz też ryzyko wycieku po stronie dostawcy lub w wyniku błędnej konfiguracji udostępnienia folderu.
Jest jeszcze jeden powód: zgodność z politykami bezpieczeństwa. W wielu firmach zasada brzmi: żadnych danych w chmurze w formie jawnej. Prywatni użytkownicy zyskują przede wszystkim spokój — dostęp do zdjęć, dokumentów i haseł pozostaje pod kontrolą właściciela klucza.
Kiedy szyfrować po stronie klienta, a kiedy wystarczy szyfrowanie chmurowe
Po stronie klienta szyfruj zawsze, gdy:
- przechowujesz dane wrażliwe (dane osobowe, finanse, repozytoria haseł, kod źródłowy);
- musisz ograniczyć zaufanie do dostawcy lub jego pracowników;
- chcesz mieć pełną kontrolę nad rotacją i przechowywaniem kluczy;
- migrujesz między dostawcami i nie chcesz blokady dostawcy (vendor lock-in).
Możesz polegać głównie na szyfrowaniu chmurowym, jeśli kopia jest publiczna lub mało wrażliwa, a priorytetem jest prostota (np. archiwum instalatorów). Nawet wtedy włącz w chmurze szyfrowanie po stronie serwera i kontrolę dostępu. Minusy takiego podejścia: kluczami zwykle zarządza dostawca, a dane bywają odszyfrowywane w trakcie przetwarzania.
Algorytmy i protokoły: co wybrać bez dywagacji
Do szyfrowania treści użyj sprawdzonych prymitywów:
- AES‑256 w trybach GCM lub XTS (GCM daje integralność; XTS w narzędziach dyskowych);
- ChaCha20‑Poly1305 — szybki w sprzęcie i oprogramowaniu, świetny na słabszych CPU;
- PBKDF2, scrypt lub Argon2 do wyprowadzania kluczy z hasła (minimum: sól i wiele iteracji/„koszt”).
Do ochrony i dystrybucji kluczy użyj kryptografii asymetrycznej:
- RSA 2048/3072+ do kompatybilności z wieloma narzędziami;
- ECDSA/Ed25519 lub X25519, jeśli narzędzie na to pozwala — nowocześniejsze i lżejsze;
- Podpisy (np. HMAC lub podpis cyfrowy) zapewniają wykrycie manipulacji.
Zarządzanie kluczami: lokalnie, HSM, KMS
Najczęstsze modele:
- Lokalnie: klucz w menedżerze haseł lub w pliku zaszyfrowanym hasłem. Plus: pełna kontrola. Minus: łatwo stracić.
- HSM (sprzętowy moduł bezpieczeństwa) lub token FIDO2/OpenPGP: ochrona przed eksportem klucza, wymaga procedur.
- KMS klienta (np. własny serwer lub usługa dostawcy, ale z kluczem zarządzanym przez Ciebie): wygodna rotacja i audyt.
Praktyka dnia codziennego: trzy kopie materiału kluczowego (hasło, klucz prywatny, seed) — jedna offline (papier/metal lub nośnik odłączony), jedna w sejfie firmowym, jedna u osoby uprawnionej. Nigdy nie trzymaj klucza razem z zaszyfrowaną kopią w tej samej chmurze.
Narzędzia: co działa w praktyce
Open‑source:
- rclone z modułem „crypt” — szyfruje nazwy i treść, działa z większością chmur, łatwa automatyzacja.
- restic — od razu szyfruje repozytorium (AES‑256/Poly1305), deduplikacja, weryfikacje, backendy S3/REST/SSH.
- Borg/Borgmatic — wydajne, z kompresją i deduplikacją, wbudowane szyfrowanie, dobre do serwerów.
- VeraCrypt — kontenery lub całe wolumeny; proste w scenariuszach „zmontuj, skopiuj, odmontuj”.
Komercyjne (gdy potrzebne polityki, SSO, wsparcie): Acronis Cyber Protect, Veeam (AES‑256, KMS), Arq Backup, CloudBerry/ MSP360. Zwróć uwagę, czy narzędzie szyfruje przed wysyłką i jak rozwiązuje rotację kluczy.
Krok po kroku: od klucza do wysyłki
1) Przygotowanie klucza
Wybierz silne hasło (co najmniej kilka losowych słów z menedżera haseł) lub wygeneruj klucz. Zapisz frazę odzyskiwania. Utwórz bezpieczną kopię offline.
2) Lokalne szyfrowanie plików
Przykład z restic:
- restic init — tworzy repozytorium;
- restic backup /katalog — szyfruje i wysyła do wskazanego backendu (może być lokalny dysk lub S3 zgodny z API);
- restic snapshots/check — sprawdza spójność.
Przykład z rclone:
- rclone config — dodaj zdalny magazyn i „crypt” nad nim;
- rclone copy /katalog remote-crypt:backup — zaszyfrowana wysyłka;
- rclone cryptcheck remote-crypt:backup /katalog — weryfikacja integralności.
VeraCrypt: utwórz kontener z silnym hasłem, zamontuj, skopiuj dane, odmontuj, a następnie wyślij sam kontener.
3) Weryfikacja przed wysyłką
Wygeneruj sumy kontrolne (SHA‑256) dla istotnych plików, porównaj po stronie chmury narzędziem cryptcheck lub weryfikacją repozytorium. Upewnij się, że nazwy plików też są zaciemnione (rclone crypt potrafi to zrobić; nie każde narzędzie szyfruje metadane).
Automatyzacja: mniej klikania, mniej błędów
Użyj harmonogramu (cron/Task Scheduler) i skryptów z nieinteraktywną autoryzacją. Restic i Borg wspierają repozytoria z kluczami środowiskowymi i plikami haseł w sejfie systemowym. Do monitoringu dorzuć logi i alerty e‑mail/Slack po nieudanym przebiegu. Rclone/Restic mają wbudowane komendy „check” — uruchamiaj je cyklicznie.
Praktyczny trik: snapshoty „lockowane” na wersję — nie nadpisuj wszystkiego. Deduplikacja w restic/Borg zmniejszy transfer, a polityka „pruning” utrzyma koszty pod kontrolą.
Pułapki i realne problemy
Utrata klucza = trwała utrata danych. Nie ma „zapomnianego hasła”. Zadbaj o procedurę odzysku i test przyjęcia nowych pracowników do systemu backupu.
Zgodność formatów: nie każdy klient S3 obsłuży te same nagłówki czy regiony; testuj na małym zestawie. Metadane: część narzędzi nie szyfruje nazw plików ani rozmiarów — może to ujawnić strukturę danych. Włącz szyfrowanie nazw lub korzystaj z kontenerów.
Throttling i limity API potrafią przerywać duże wysyłki — ustaw retry i wznawianie transferów. Zmień rozmiar chunków, jeśli narzędzie na to pozwala.
Test odszyfrowania: kopia jest tyle warta, ile restore
Raz w miesiącu (lub zgodnie z polityką) pobierz losowy fragment kopii i wykonaj pełny proces przywracania: odszyfruj, porównaj sumy, uruchom aplikację na przywróconych danych. Sprawdź też scenariusz utraty urządzenia: czy z samego klucza i dokumentacji potrafisz odtworzyć środowisko?
Rekomendacje praktyczne: krótkie reguły, które działają
- Domyślnie szyfruj lokalnie przed wysyłką (AES‑256‑GCM lub ChaCha20‑Poly1305).
- Klucz i hasło trzymaj poza chmurą, w co najmniej trzech kopiach, w dwóch lokalizacjach.
- Rotuj klucze przy każdej większej zmianie personelu lub co pewien ustalony okres.
- Automatyzuj backup i okresowe „check/restore”. Bez testu odzysku backup nie istnieje.
- Szyfruj także nazwy plików lub używaj kontenerów, gdy metadane są wrażliwe.
FAQ: krótkie odpowiedzi na częste pytania
Czy wystarczy hasło do archiwum ZIP?
Nie. Starsze metody w ZIP bywają słabe. Jeśli już, używaj ZIP z AES‑256 i długim hasłem, ale lepsze są restic/Borg lub kontener VeraCrypt.
Co, jeśli potrzebuję współdzielić kopię z innym działem?
Użyj szyfrowania asymetrycznego lub repozytorium z wieloma kluczami publicznymi. Każdy dostaje własny klucz, a dostęp można cofnąć bez zmiany całego procesu.
Jak dobrać hasło?
Generator haseł w menedżerze i fraza składająca się z losowych słów. Unikaj wzorców i recyklingu haseł.
