Szyfrowanie po stronie serwera vs. po stronie klienta: Któremu modelowi możesz zaufać?

Szyfrowanie po stronie serwera szyfruje dane na serwerze po otrzymaniu tekstu jawnego — wymaga zaufania do dostawcy usługi. Szyfrowanie po stronie klienta szyfruje dane w twojej przeglądarce przed ich wysłaniem, więc serwer nigdy nie widzi tekstu jawnego. W przypadku udostępniania sekretów szyfrowanie po stronie klienta jest bezpieczniejsze, bo eliminuje usługę jako punkt zaufania — nawet skompromitowany serwer nie może odczytać twoich danych.

Ten wpis porównuje oba podejścia: jak działają, czego każde z nich wymaga od ciebie pod względem zaufania i gdzie leżą prawdziwe kompromisy. To nie jest argument za jedną ze stron — to framework do oceny, który model pasuje do twojego modelu zagrożeń.

Szybki przegląd tego, dlaczego szyfrowanie po stronie klienta ma znaczenie, znajdziesz w naszym wcześniejszym wpisie. Szczegółowy opis konkretnej implementacji Vaulted znajdziesz w naszym deep-dive o zero-knowledge.

Jak działa szyfrowanie po stronie serwera

W modelu serwerowym usługa zajmuje się szyfrowaniem w twoim imieniu. Typowy przebieg:

Wpisujesz sekret w przeglądarce
Twoja przeglądarka wysyła tekst jawny do serwera przez TLS
Serwer szyfruje dane kluczem, którym sam zarządza
Szyfrogram jest zapisywany w bazie danych
Gdy odbiorca żąda sekretu, serwer odszyfrowuje go i zwraca tekst jawny

Klucz szyfrowania nigdy nie opuszcza serwera. Może znajdować się w module bezpieczeństwa sprzętowego (HSM), chmurowej usłudze zarządzania kluczami (KMS) lub pliku konfiguracyjnym — ale serwer kontroluje go w pełni.

Serwerowy model zaufania

Przy szyfrowaniu po stronie serwera ufasz:

Operatorowi usługi, że nie odczyta twoich danych (ma klucz i tekst jawny w pamięci podczas szyfrowania/deszyfrowania)
Infrastrukturze, że nie zostanie skompromitowana (skompromitowany serwer ujawnia zarówno klucze, jak i dane)
Pracownikom operatora, że nie nadużyją dostępu (każdy z dostępem do serwera może potencjalnie odczytać sekrety)
Jurysdykcji prawnej, że nie wymusi ujawnienia danych (operator może zostać zmuszony do przekazania danych, bo posiada klucze)
Logom i monitoringowi serwera, że nie przechwycą tekstu jawnego (frameworki logowania mogą przypadkowo rejestrować dane wrażliwe)

To niekoniecznie zły model. Wiele usług korzysta z niego z powodzeniem — usługi przechowywania w chmurze, dostawcy poczty e-mail i usługi baz danych opierają się na szyfrowaniu po stronie serwera. Pytanie brzmi, czy ten kompromis pasuje do twojego przypadku użycia.

Jak działa szyfrowanie po stronie klienta

W modelu klienckim szyfrowanie odbywa się w przeglądarce, zanim jakiekolwiek dane dotrą do serwera. Przebieg jest inny:

Wpisujesz sekret w przeglądarce
Przeglądarka generuje klucz szyfrowania i szyfruje dane lokalnie
Do serwera wysyłany jest wyłącznie szyfrogram
Klucz szyfrowania jest dostarczany odbiorcy osobnym kanałem (zazwyczaj fragmentem URL)
Przeglądarka odbiorcy odszyfrowuje szyfrogram lokalnie

Serwer nigdy nie widzi tekstu jawnego i nigdy nie przechowuje klucza szyfrowania. Zapisuje i pobiera zaszyfrowane bloki danych — i nic więcej.

Vaulted używa tego modelu. Każdy sekret otrzymuje świeży klucz AES-256-GCM. Klucz jest umieszczany we fragmencie URL (#), który przeglądarki zgodnie z RFC 3986 nigdy nie dołączają do żądań HTTP. Serwer otrzymuje szyfrogram i losowy 12-bajtowy IV do przechowywania, ale klucz pozostaje wyłącznie w linku udostępnianym między nadawcą a odbiorcą.

Kliencki model zaufania

Przy szyfrowaniu po stronie klienta ufasz:

Przeglądarce, że poprawnie implementuje kryptografię (Web Crypto API deleguje do natywnych silników kryptograficznych, takich jak BoringSSL lub NSS)
Kodowi aplikacji, że faktycznie wykonuje szyfrowanie po stronie klienta (możesz to zweryfikować, sprawdzając żądania sieciowe)
Kanałowi dostarczania linku, że jest bezpieczny (każdy posiadający pełny URL wraz z fragmentem może odszyfrować sekret)
Urządzeniu odbiorcy, że nie jest skompromitowane (po odszyfrowaniu złośliwe oprogramowanie lub przechwytywanie ekranu może uzyskać dostęp do tekstu jawnego)

Nie ufasz serwerowi, operatorowi usługi, jego pracownikom ani jego jurysdykcji prawnej. Serwer to przekaźnik przechowujący zaszyfrowane dane, których nie może odczytać.

Porównanie kompromisów

Żaden model nie jest uniwersalnie lepszy. Każdy wiąże się z innymi kompromisami między bezpieczeństwem, wygodą użytkowania i bogactwem funkcji.

Właściwości bezpieczeństwa

Właściwość	Po stronie serwera	Po stronie klienta
Ekspozycja przy naruszeniu serwera	Klucze + szyfrogram ujawnione	Ujawniony tylko szyfrogram (bezużyteczny bez kluczy)
Operator może odczytać dane	Tak (posiada klucze)	Nie (nigdy nie ma kluczy)
Ryzyko przymusu prawnego	Operator może się zastosować (ma dostęp)	Operator nie może się zastosować (nie ma dostępu)
Ryzyko przechwycenia linku	Nie dotyczy (brak klucza w linku)	Pełny URL = pełny dostęp (łagodzone przez hasło/passphrase)
Atak man-in-the-middle	TLS chroni przesyłanie; serwer widzi tekst jawny	TLS chroni szyfrogram; klucz we fragmencie nigdy nie jest wysyłany

Właściwości wygody użytkowania

Właściwość	Po stronie serwera	Po stronie klienta
Obciążenie zarządzaniem kluczami	Żadne dla użytkownika (serwer to obsługuje)	Użytkownik musi bezpiecznie udostępnić link
Odzyskiwanie dostępu	Możliwe (serwer przechowuje klucze)	Niemożliwe (klucze tylko w linku)
Wyszukiwanie i indeksowanie	Serwer może przeszukiwać tekst jawny	Niemożliwe bez odszyfrowania
Elastyczność udostępniania	Serwer może ponownie zaszyfrować dla nowych odbiorców	Wymaga nowego linku dla każdego odbiorcy
Dostęp offline	Wymaga połączenia z serwerem do odszyfrowania	Możliwe, jeśli szyfrogram i klucz są lokalnie w pamięci podręcznej

Kompromisy funkcji

Funkcja	Po stronie serwera	Po stronie klienta
Audit logging treści	Możliwy	Niemożliwy (serwer nie może odczytać treści)
Polityki oparte na treści	Możliwe (DLP, skanowanie zgodności)	Niemożliwe bez odszyfrowania
Rotacja kluczy	Serwer może ponownie zaszyfrować nowymi kluczami	Wymaga regeneracji i ponownego udostępnienia linków
Wielostronna kontrola dostępu	Serwer może zarządzać kluczami per użytkownik	Każdy odbiorca potrzebuje klucza bezpośrednio
Gwarancja zero-knowledge	Nie	Tak

Kiedy szyfrowanie po stronie serwera jest dopuszczalne

Szyfrowanie po stronie serwera jest rozsądnym wyborem, gdy:

Ufasz operatorowi usługi i jego praktykom bezpieczeństwa
Potrzebujesz funkcji wymagających serwerowego dostępu do danych (wyszukiwanie, udostępnianie, skanowanie zgodności)
Wrażliwość danych nie uzasadnia kosztów wygody związanych z szyfrowaniem po stronie klienta
Działasz w regulowanym środowisku, gdzie certyfikaty zgodności operatora są ważniejsze niż gwarancje zero-knowledge
Złożoność zarządzania kluczami powinna spoczywać na usłudze, nie na użytkowniku

Usługi przechowywania w chmurze, korporacyjna poczta e-mail i zarządzane szyfrowanie baz danych — wszystkie skutecznie korzystają z tego modelu.

Kiedy szyfrowanie po stronie klienta jest konieczne

Szyfrowanie po stronie klienta staje się konieczne, gdy:

Nie możesz lub nie powinieneś powierzać swoich danych operatorowi usługi
Dane są na tyle wrażliwe, że naruszenie serwera nie może ujawnić tekstu jawnego
Potrzebujesz gwarancji zero-knowledge — matematycznego dowodu, że serwer nie może odczytać twoich danych
Wymogi prawne lub wymogi zgodności nakazują, aby operator usługi nie miał dostępu do treści
Chcesz ochrony przed zagrożeniami wewnętrznymi u dostawcy usługi

Udostępnianie sekretów jest jednym z najmocniejszych przypadków użycia szyfrowania po stronie klienta. Dane są z natury wrażliwe (hasła, klucze API, dane uwierzytelniające), udostępnianie jest przejściowe (z limitem wyświetleń, z limitem czasowym), a relacja zaufania jest minimalna (możesz nie znać operatora usługi lub mu nie ufać).

Jak Vaulted do tego podchodzi

Vaulted używa wyłącznie szyfrowania po stronie klienta. Każdy sekret jest szyfrowany w przeglądarce świeżym kluczem AES-GCM, zanim jakiekolwiek dane dotrą do serwera. Klucz podróżuje wyłącznie we fragmencie URL, a opcjonalna ochrona passphrase dodaje drugą warstwę poprzez derywację klucza PBKDF2 i zawijanie klucza (key wrapping) AES-KW.

Serwer przechowuje zaszyfrowany szyfrogram z czasem wygaśnięcia i licznikiem wyświetleń. Nie może odszyfrować, przeszukać ani zbadać treści. Całkowite naruszenie bazy danych ujawnia wyłącznie zaszyfrowane bloki — obliczeniowo bezużyteczne bez kluczy, które istnieją tylko w udostępnionych linkach.

Pełne szczegóły kryptograficzne — generowanie kluczy, obsługa IV, zawijanie passphrase i dokładne wywołania Web Crypto API — znajdziesz w naszym deep-dive o szyfrowaniu zero-knowledge.

Twój wybór

Właściwy model szyfrowania zależy od tego, co chronisz i komu jesteś gotów zaufać.

Jeśli potrzebujesz funkcji takich jak wyszukiwanie, odzyskiwanie lub scentralizowane zarządzanie kluczami, szyfrowanie po stronie serwera jest praktycznym wyborem. Jeśli potrzebujesz gwarancji, że nikt — ani usługa, ani jej pracownicy, ani nakaz sądowy — nie może odczytać twoich danych, szyfrowanie po stronie klienta to jedyny model, który to zapewnia.

W przypadku udostępniania sekretów odpowiedź jest prosta: dane są wrażliwe, interakcja jest krótka, a im mniej stron ma dostęp do tekstu jawnego, tym lepiej.

Gotowy udostępnić sekret z szyfrowaniem zero-knowledge? Utwórz sekret na Vaulted — twoje dane nigdy nie opuszczają przeglądarki niezaszyfrowane.

Powiązane

Dlaczego szyfrowanie po stronie klienta ma znaczenie — argument za szyfrowaniem w przeglądarce
Szyfrowanie zero-knowledge: jak Vaulted chroni twoje sekrety — deep-dive w implementację kryptograficzną
Bezpieczeństwo w Vaulted — podsumowanie naszego modelu bezpieczeństwa