Szyfrowanie po stronie klienta vs po stronie serwera dla przesyłanych plików

Dlaczego wybór szyfrowania ma znaczenie dla przesyłanych dokumentów

Jeśli Twoja aplikacja pozwala na przesyłanie plików, nie przechowujesz tylko „dokumentów”. Często przechowujesz drugą tożsamość użytkownika: podpisane umowy, zdjęcia paszportu lub prawa jazdy, formularze medyczne i wyniki badań. Pliki są małe. Ryzyko z nimi związane już nie.

Wycieknięta umowa może wywołać konsekwencje prawne i finansowe: ceny stają się publiczne, podpisy mogą zostać skopiowane, a spory szybko robią się brzydkie. Skradziony skan dowodu tożsamości może prowadzić do kradzieży tożsamości i przejęć kont. Dokumenty medyczne mogą ujawnić prywatne informacje o zdrowiu, których ludzie nie spodziewali się upubliczniać. Jeden błąd może naruszyć zaufanie na lata.

Zespoły często mówią „zaszyfrowane przechowywanie”, mając na myśli różne rzeczy. Czasem chodzi o zaszyfrowane połączenie przy przesyłaniu (HTTPS). Innym razem o zaszyfrowanie pliku na dysku (szyfrowanie w spoczynku). Jeszcze innym o zaszyfrowanie pliku zanim opuści urządzenie użytkownika, tak by serwer nigdy nie widział jawnej treści (szyfrowanie po stronie klienta). To nie są synonimy. Chronią przed różnymi rodzajami awarii.

Wybory dotyczące bezpieczeństwa kształtują też codzienną użyteczność i wsparcie. Większa prywatność może oznaczać więcej tarcia: dodatkowe kroki by obejrzeć plik, trudniejsze udostępnianie, ograniczone wyszukiwanie i podglądy oraz bolesne odzyskiwanie, gdy ktoś utraci urządzenie lub klucz. Łatwiejszy dostęp umożliwia indeksowanie, skanowanie antywirusowe, podglądy i resetowanie haseł, ale też zwiększa to, co Twój serwer (i każdy, kto go skompromituje) może zobaczyć.

Wyobraź sobie małą klinikę przesyłającą zdjęcia ubezpieczeń i PDF-y medyczne. Personel musi szybko znaleźć właściwy plik, ale klinika chce też ograniczyć szkody, jeśli konto administratora zostanie zhakowane. „Właściwy” model zależy od tego, która awaria zaszkodzi najbardziej i jaką niedogodność użytkownicy są skłonni zaakceptować.

Krótkie definicje: szyfrowanie po stronie klienta vs po stronie serwera

Pytanie praktyczne jest proste: kiedy plik jest szyfrowany i kto może go później odszyfrować?

Szyfrowanie po stronie serwera oznacza, że plik dociera do backendu w postaci czytelnej, a Twój serwer szyfruje go przed zapisaniem. To jest szyfrowanie w spoczynku: jeśli ktoś ukradnie dysk lub uzyska surowy dostęp do koszyka obiektów, zobaczy pomieszane dane. Twój serwer nadal może odszyfrować plik, gdy zajdzie taka potrzeba.

Szyfrowanie po stronie klienta oznacza, że plik jest szyfrowany na urządzeniu użytkownika (przeglądarka lub aplikacja mobilna) przed wysłaniem. Twój serwer przechowuje tylko szyfrogram. W normalnej pracy serwer nie widzi treści dokumentu, chyba że ma dostęp do klucza odszyfrowującego.

Własność kluczy to prawdziwa granica rozdziału:

• Przy szyfrowaniu po stronie serwera klucze są zarządzane przez backend (często za pomocą usługi zarządzania kluczami), a backend odszyfrowuje pliki dla uprawnionych użytkowników.
• Przy szyfrowaniu po stronie klienta klucze są kontrolowane przez użytkownika, jego urządzenie lub sekret przechowywany po stronie klienta, a backend głównie egzekwuje zasady przechowywania i dostępu.

W obu modelach wciąż potrzebujesz uwierzytelniania i uprawnień. Szyfrowanie nie zastępuje kontroli dostępu.

Ludzie mówią też o „szyfrowaniu end-to-end”, mając na myśli: plik jest szyfrowany na urządzeniu nadawcy, pozostaje zaszyfrowany na serwerze i jest odszyfrowywany tylko na zatwierdzonym urządzeniu odbiorcy. To może poprawić poufność, ale utrudnia podglądy serwerowe, pełnotekstowe wyszukiwanie, skanowanie antywirusowe i łatwe odzyskiwanie, chyba że zaakceptujesz inny model zagrożeń.

Modele zagrożeń: przed czym właściwie chcesz się chronić

Szyfrowanie pomaga tylko wtedy, gdy jesteś jasny co do ryzyk, które chcesz zmniejszyć. „Nikt poza zamierzonym użytkownikiem nie może czytać pliku” prowadzi do innych wyborów niż „ograniczyć szkody, jeśli wycieknie magazyn danych”.

Typowe zagrożenia dla aplikacji przechowujących umowy, dowody tożsamości lub dokumenty medyczne obejmują:

• Skradzione lub ponownie użyte hasła (przejęcie konta)
• Nadmierny dostęp od wewnątrz (wsparcie, administratorzy, kontraktorzy)
• Skompromitowane konto chmurowe lub źle skonfigurowany koszyk przechowywania
• Błąd lub wyciek ujawniający bazy danych lub kopie zapasowe
• Złośliwe oprogramowanie na urządzeniu użytkownika

Pomocne jest też rozdzielenie miejsc, gdzie może nastąpić ekspozycja:

• W tranzycie: plik przesyłany z urządzenia na serwer
• W spoczynku: magazyn obiektów, rzędy w bazie, kopie zapasowe, logi
• Podczas przeglądania/przetwarzania: podglądy, OCR, wyszukiwanie, konwersje

Oto zasadnicza różnica. Przy szyfrowaniu po stronie serwera Twój system może odszyfrować, więc może tworzyć podglądy, skanować i indeksować. Przy szyfrowaniu po stronie klienta serwer przechowuje szyfrogram i nie może odczytać zawartości bez kluczy użytkownika. To zwykle zmniejsza obszar rażenia przy kompromitacji serwera i dostępie od wewnątrz.

Szyfrowanie nie zatrzyma wszystkiego. Jeśli urządzenie jest zainfekowane, malware może przechwycić plik przed zaszyfrowaniem lub po odszyfrowaniu. Jeśli ktoś widzi dokument, nadal może wykonać zrzut ekranu, ponownie go udostępnić lub wydrukować.

Co każdy model chroni (a czego nie)

Przydatny sposób porównania to pytanie: kto może zobaczyć plik w postaci jawnej w dowolnym momencie? Ta odpowiedź kształtuje wpływ wycieku, ryzyko od wewnątrz i bezpieczeństwo kopii zapasowych.

Przy szyfrowaniu po stronie serwera naruszenie serwera może nadal ujawnić dużo. Backend zwykle ma dostęp do kluczy odszyfrowujących (lub może ich żądać), ponieważ musi generować podglądy, uruchamiać skanowanie antywirusowe, obsługiwać wyszukiwanie lub udostępnianie. W najgorszym scenariuszu atakujący, który uzyska zarówno dane, jak i dostęp do kluczy, może odszyfrować wszystko.

Przy szyfrowaniu po stronie klienta atakujący, który złamie Twoją infrastrukturę, zwykle kradnie zaszyfrowane bloby. Bez kluczy trzymanych przez użytkowników te bloby są dużo mniej użyteczne.

Różnica jest najbardziej widoczna przy dostępie od wewnątrz. Przy szyfrowaniu po stronie serwera uprzywilejowany pracownik, administrator chmury lub skompromitowane konto wsparcia może często uzyskać dostęp do dokumentów, podszywając się pod aplikację lub wykonując zapytania do magazynu. Przy szyfrowaniu po stronie klienta Twoja infrastruktura może przechowywać i przenosić pliki, ale nie może ich odczytać, chyba że udostępnione zostaną klucze.

Szyfrowanie po stronie klienta nie naprawi zhakowanego urządzenia. Dla przesyłek wysokiego ryzyka, takich jak dowody tożsamości i PDF-y medyczne, bezpieczeństwo urządzenia i ochrona konta są równie ważne jak szyfrowanie przechowywania.

Zwróć też uwagę na wycieki poza „magazynem plików”. Wiele incydentów zdarza się przez:

• Kopie zapasowe i snapshoty, które zawierają odszyfrowane pliki lub klucze
• Logi, które zapisują nazwy plików, metadane lub wyodrębniony tekst
• Miniatury, podglądy i indeksy wyszukiwania
• Eksporty do e-maili, czatów lub narzędzi ticketowych
• Pliki tymczasowe tworzone podczas przesyłania lub konwersji

Kompromisy UX, które użytkownicy odczują od razu

Największa różnica to nie matematyka. To co użytkownicy mogą robić łatwo, a co staje się trudne.

Szyfrowanie po stronie serwera często jest niewidoczne. Użytkownicy logują się, przesyłają i natychmiast widzą podglądy. Wsparcie może zresetować dostęp. Administratorzy zazwyczaj mogą przypisać uprawnienia, gdy ktoś jest nieobecny.

Szyfrowanie po stronie klienta zmienia onboarding i codzienną pracę. Użytkownicy mogą potrzebować mocniejszego hasła, lokalnego klucza przechowywanego na urządzeniu lub dodatkowego kroku odblokowania. Zmiana urządzenia, wyczyszczenie przeglądarki lub reinstalacja aplikacji mogą zerwać dostęp, jeśli nie przewidziano kopii zapasowej kluczy i procedury odzyskiwania.

Odzyskiwanie konta to obszar, który zaskakuje zespoły. Jeśli tylko użytkownik posiada klucz odszyfrowujący, „Zapomniałem hasła” może oznaczać „utraciłem dostęp”. Możesz dodać klucz odzyskiwania lub flow eskrowania, ale musisz szczerze wyjaśnić, co to oznacza.

Udostępnianie też się komplikuje. Przy szyfrowaniu po stronie serwera udostępnianie to zazwyczaj kwestia uprawnień. Przy szyfrowaniu po stronie klienta udostępnianie często wiąże się z dzieleniem kluczy, a to rodzi pytania o unieważnianie i co dzieje się ze starymi kopiami.

Funkcje wyszukiwania i wygody mogą wymagać odszyfrowania gdzieś. Pełnotekstowe wyszukiwanie, podglądy i OCR są najłatwiejsze, gdy serwer może odczytać plik. Jeśli chcesz prywatności w stylu end-to-end, musisz rozważyć OCR po stronie klienta, lokalne indeksowanie lub ograniczone wyszukiwanie (np. tylko nazwy plików i tagi).

Przykład: klinika przesyła PDF-y z wynikami badań i chce OCR, by znaleźć nazwiska pacjentów w skanach. Szyfrowanie po stronie serwera wspiera szybki OCR i wyszukiwanie. Szyfrowanie po stronie klienta przenosi tę pracę na urządzenia użytkowników, co może być wolniejsze i trudniejsze do obsługi na webie i mobilnie.

Potrzeby specyficzne dla dokumentów: umowy, dowody tożsamości i dokumenty medyczne

Najlepszy wybór zależy mniej od typu pliku, a bardziej od przepływu pracy: kto musi go czytać, jak szybko, jak często i przez jaki czas.

Umowy

Umowy często wymagają przeglądu, nanoszenia poprawek, zatwierdzeń i ścieżek audytu. Zespoły chcą też niezawodnego wyszukiwania, udostępniania i zasad retencji.

Jeśli Twoja aplikacja wspiera współpracę wewnątrz produktu, szyfrowanie po stronie serwera jest praktycznym domyślnym wyborem, ponieważ system może renderować podglądy, wykonywać wyszukiwanie i egzekwować dostęp oparty na rolach bez zmuszania użytkowników do zarządzania kluczami.

Szyfrowanie po stronie klienta może pasować, jeśli aplikacja działa głównie jako sejf, np. przechowując finalne podpisane PDF-y dla małej grupy kierowniczej. Kompromisem jest mniejsza wygoda wbudowana, chyba że dodasz narzędzia po stronie klienta.

Dowody tożsamości (paszporty, prawa jazdy)

Dowody tożsamości są wysokiego ryzyka, ale często krótkotrwałe. Wiele zespołów potrzebuje ich tylko na czas weryfikacji osoby, potem je usuwa. Przepływ to szybkie obejrzenie i ścisłe zasady obsługi, a nie współpraca.

Częstym podejściem jest szyfrowanie po stronie serwera połączone z surową kontrolą dostępu, silnymi logami audytu i krótkim okresem przechowywania. Szyfrowanie po stronie klienta może się sprawdzić, jeśli personel obsługi nie powinien nigdy widzieć dowodów, ale wtedy potrzebujesz innej metody weryfikacji.

Dokumenty medyczne

Dokumenty medyczne niosą za sobą silniejsze oczekiwania prywatności. Użytkownicy często zakładają, że tylko minimalny zestaw osób może je zobaczyć.

Szyfrowanie po stronie klienta może zmniejszyć ekspozycję w przypadku naruszenia serwera lub nadużyć administracyjnych. Może jednak stworzyć realne problemy UX i operacyjne: resetowanie haseł, zmiany urządzeń i awaryjny dostęp stają się skomplikowane.

Zanim wybierzesz, odwzoruj każdy typ dokumentu względem przepływu pracy:

• Kto musi go czytać (i skąd)
• Jak szybko musi się ładować
• Jak długo go przechowujesz
• Które funkcje produktu są ważne (podgląd, wyszukiwanie, automatyczne usuwanie)

Jak wybrać: krok po kroku proces decyzyjny

Zacznij od spisania tego, co przechowujesz i kto ma z tym styczność. Folder o nazwie „uploads” to nie polityka.

Krok 1: zamapuj dostęp, nie tylko „użytkowników”

Wypisz role i odpowiedz na dwa pytania: kto musi móc otwierać plik, i kto nigdy nie powinien móc go otworzyć (włączając administratorów)? Uwzględnij też zasady retencji.

Krok 2: wybierz swoje założenia dotyczące zagrożeń

Bądź bezpośredni w kwestii przed czym się bronisz.

• Jeśli ryzyko od wewnątrz jest kluczowe, szyfrowanie po stronie klienta staje się bardziej atrakcyjne.
• Jeśli utrata urządzenia i reset hasła są powszechne, zapłacisz za to złożonością odzyskiwania.

Następnie przetestuj doświadczenie:

1. Odzyskiwanie i wsparcie: Co się dzieje, gdy ktoś zapomni hasła lub straci telefon? Jeśli musisz odzyskać dostęp, czyste szyfrowanie po stronie klienta może nie pasować.

2. Funkcje niezbędne: Czy potrzebujesz podglądów, wyszukiwania, OCR, podpisów elektronicznych lub przetwarzania przez API? Wiele z tych funkcji jest prostszych, gdy gdzieś po drodze plik jest odszyfrowany po stronie serwera.

3. Audyty i zgodność: Czy potrzebujesz jasnych logów kto i kiedy coś przeglądał? Oba modele mogą logować dostęp, ale projekty klienta wymagają dodatkowej uwagi, by uniknąć sytuacji „nie możemy pomóc”.

Większość zespołów kończy z hybrydą: szyfrowanie po stronie serwera dla większości dokumentów i szyfrowanie po stronie klienta dla niewielkiego zestawu plików „nigdy nie widocznych dla personelu”.

Częste błędy i pułapki do uniknięcia

Największą pułapką jest traktowanie szyfrowania jako całej historii. Prywatność i zgodność zależą też od tego, kto może uzyskać dostęp do danych, jak zatwierdzany jest dostęp, co jest logowane, jak długo pliki są przechowywane i jak obsługiwane są żądania usunięcia.

Na drugim miejscu jest budowanie szyfrowania po stronie klienta bez planu odzyskiwania. Jeśli użytkownik straci urządzenie, zapomni frazy lub odejdzie z firmy, czy możesz przywrócić dostęp bez złamania obietnicy bezpieczeństwa? „Nie możemy pomóc” może być akceptowalne dla prywatnej skrytki, ale zwykle zawodzi w aplikacjach biznesowych.

Te błędy powodują rzeczywiste wycieki i obejścia:

• Nadanie administratorom ukrytej ścieżki „zobacz wszystko” albo pozwolenie wsparciu na podszywanie się pod użytkowników bez surowych logów i zatwierdzeń.
• Odszyfrowywanie w przeglądarce lub aplikacji i pozostawianie kopii (podglądy w pamięci podręcznej, tymczasowe pobrania, synchronizowane foldery).
• Wysyłanie „bezpiecznych” dokumentów przez niechronione kanały później (e-maile z załącznikami, zrzuty ekranu w czatach, załączanie plików do ticketów).
• Uczynienie bezpiecznego przepływu tak trudnym, że użytkownicy zaczynają korzystać z prywatnych dysków lub robić zdjęcia ekranu.
• Zakładanie, że „szyfrowanie w spoczynku” automatycznie spełnia wymogi zgody, historii dostępu, retencji i raportowania naruszeń.

Przykład: klinika szyfruje formularze przyjęć, a potem personel eksportuje raport rozliczeniowy, który tworzy lokalny nieszyfrowany folder. Ta kopia trafia do kopii zapasowej na współdzielonym dysku. Wycieczka zdarza się w przepływie pracy, nie w kryptografii.

Szybka lista kontrolna przed podjęciem decyzji

Napisz jedno proste zdanie: kto powinien móc czytać te pliki, a kto nigdy nie powinien, nawet jeśli ktoś uzyska dostęp do Twoich serwerów.

Następnie sprawdź:

• Kto może odszyfrować i kiedy? Wypisz dokładne role i warunki. Jeśli Twoja polityka mówi „tylko przesyłający”, nie dodawaj po cichu tylnego wejścia przez współdzielone klucze.
• Czy możesz szybko odebrać dostęp? Offboarding to prawdziwy test. Zdecyduj, czy dostęp jest powiązany z kontem, urządzeniem czy grupą.
• Co się dzieje po utracie urządzenia lub resecie hasła? Jeśli potrzebujesz odzyskiwania, zabezpiecz je silnymi zatwierdzeniami.
• Czy potrzebujesz podglądów, skanowania antywirusowego lub OCR? Jeśli tak, zaplanuj, gdzie ma się odbywać odszyfrowanie i kto może je uruchomić.
• Czy Twoje logi audytu są wystarczająco szczegółowe? Zdefiniuj, co liczy się jako „wyświetlono” kontra „pobrano” i rejestruj użytkownika, czas, urządzenie i powód.

Przykładowy scenariusz: mały zespół przechowujący dowody tożsamości i PDF-y medyczne

Mała klinika ma aplikację, w której personel przesyła skierowania pacjentów (PDF) i zdjęcia ubezpieczeń. Celem jest szybkie przekazanie dokumentów właściwym osobom, przy jednoczesnym ograniczeniu szkód wynikających z utraty urządzeń, przejętych kont lub pomyłek w chmurze.

Jednym z praktycznych podejść jest szyfrowanie po stronie serwera z surowymi rolami. Pliki są szyfrowane w spoczynku, a dostęp kontrolowany przez uprawnienia: recepcja może przesyłać, dział rozliczeń może przeglądać dowody, a lekarze widzą skierowania. To zazwyczaj jest łatwiejsze na co dzień, ponieważ personel może otwierać dokumenty na desktopie i mobilnie bez dodatkowych kroków, a przełożeni mogą przypisać dostęp podczas nieobecności.

Inne podejście to użycie szyfrowania po stronie klienta dla najbardziej wrażliwych materiałów. Plik jest zaszyfrowany na urządzeniu przed wysłaniem, więc serwer przechowuje szyfrogram. To może zmniejszyć wpływ wycieków serwera i dostępu od wewnątrz, ale zmienia operacje:

• Resety haseł normalnie przywracają dostęp przy szyfrowaniu po stronie serwera; przy szyfrowaniu po stronie klienta resety mogą zablokować użytkowników, chyba że klucze są bezpiecznie zapisane kopii zapasowej.
• Rotacja personelu jest prostsza przy szyfrowaniu po stronie serwera; przy szyfrowaniu po stronie klienta musisz mieć plan transferu lub eskrowania kluczy, by dokumenty pozostały dostępne.

Użytkownicy odczują tarcie przy udostępnianiu, dostępie mobilnym i odzyskiwaniu po utracie telefonu. Te detale mają równie duże znaczenie co sam model szyfrowania.

Następne kroki: zdecyduj, udokumentuj politykę i wdroż

Zacznij od zapisania swoich założeń dotyczących zagrożeń w prostym języku. Wybierz najprostsze podejście, które spełnia Twoje ryzyko, a następnie zaostrzaj je tylko tam, gdzie dokumenty naprawdę to uzasadniają.

Włóż decyzję w krótki zestaw zasad wewnętrznych, które ludzie będą mogli stosować:

• Które typy plików są dozwolone i gdzie mogą być przechowywane
• Kto może je przeglądać i udostępniać oraz jak zatwierdzany jest dostęp
• Zasady retencji i usuwania
• Jak działa odzyskiwanie po resetach haseł i utracie urządzeń
• Jak obsługiwane są eksporty (pobrania, e-maile, wiadomości) i kiedy są blokowane

Następnie zaprojektuj implementację wokół tych zasad: kontrole ról, audytowane działania (wyświetlenie, pobranie, udostępnienie), bezpieczne podglądy i ostrożne obchodzenie się z kluczami.

Jeśli budujesz na platformie no-code takiej jak AppMaster (appmaster.io), pomocne jest wczesne zamodelowanie ról i przepływów zatwierdzania, a potem ich dostosowywanie wraz ze zmieniającymi się wymaganiami bez przepisywania całej aplikacji. Najważniejsze jest, by bezpieczna ścieżka była jednocześnie prostą ścieżką dla rzeczywistych użytkowników.