Szyfrowanie po stronie serwera vs. po stronie klienta: decydująca różnica
Niemal każda usługa transkrypcji reklamuje “szyfrowanie”. Ale nie każda forma szyfrowania chroni równie dobrze. Decydująca różnica nie tkwi w algorytmie – lecz w tym, kto trzyma klucz.
Ten artykuł wyjaśnia różnicę między szyfrowaniem po stronie serwera a po stronie klienta i dlaczego oznacza ona fundamentalną różnicę dla Twoich plików audio.
Co naprawdę oznacza “szyfrowanie at rest”
“Szyfrowanie at rest” oznacza: dane są przechowywane w postaci zaszyfrowanej. Haczyk: klucz trzyma dostawca. Każdy pracownik z dostępem do bazy danych, każdy administrator chmury i każdy haker, który naruszy serwer, może odszyfrować dane.
Większość usług chmurowych szyfruje dane, gdy znajdą się na dysku. To chroni przed kradzieżą fizycznych dysków – scenariusz, który w profesjonalnych centrach danych zdarza się rzadko. Nie chroni jednak przed:
- Atakami na aplikację: Kto włamie się do aplikacji, ma dostęp do funkcji odszyfrowywania.
- Dostępem wewnętrznym: Administratorzy dostawcy mogą w każdej chwili odczytać dane.
- Żądaniami urzędów: Dostawca może odszyfrować dane i je przekazać.
- Treningiem AI: Dostawca mógłby wykorzystać Twoje dane do ulepszenia swoich modeli.
Krótko mówiąc: szyfrowanie po stronie serwera chroni dysk, a nie Twoje dane.
Co szyfrowanie po stronie klienta robi inaczej
Przy szyfrowaniu po stronie klienta Twój plik audio jest szyfrowany w przeglądarce, zanim trafi na serwer. Serwer przechowuje tylko zaszyfrowane bloby – nie trzyma klucza. Nawet dostawca nie może odczytać przechowywanych danych.
Proces szczegółowo:
- 1. Wygenerowanie klucza: Dla każdego pliku w przeglądarce generowany jest dedykowany 256-bitowy klucz (File Encryption Key).
- 2. Szyfrowanie lokalne: Plik audio jest szyfrowany za pomocą AES-256-GCM bezpośrednio w przeglądarce. Serwer otrzymuje tylko zaszyfrowane bajty.
- 3. Zabezpieczenie klucza: Klucz pliku jest szyfrowany Twoim osobistym kluczem głównym i w ten sposób przechowywany na serwerze. Bez Twojego hasła nikt nie ma do niego dostępu.
Wynik: na serwerze zawsze leżą tylko zaszyfrowane dane. Żaden pracownik dostawcy, żaden haker i żaden urząd nie może ich odszyfrować bez Twojego klucza.
Bezpośrednie porównanie
Poniższa tabela pokazuje różnicę na pierwszy rzut oka:
- Kto szyfruje? Szyfrowanie po stronie serwera: dostawca. Szyfrowanie po stronie klienta: Twoja przeglądarka.
- Kto trzyma klucz? Szyfrowanie po stronie serwera: dostawca. Szyfrowanie po stronie klienta: tylko Ty.
- Czy dostawca może to odczytać? Szyfrowanie po stronie serwera: tak. Szyfrowanie po stronie klienta: nie.
- Ochrona w razie naruszenia? Szyfrowanie po stronie serwera: ograniczona (często klucz też jest naruszony). Szyfrowanie po stronie klienta: pełna (klucza nie ma na serwerze).
- Ujawnienie urzędom? Szyfrowanie po stronie serwera: dostawca może odszyfrować. Szyfrowanie po stronie klienta: dostawca może dostarczyć tylko zaszyfrowane bloby.
- Art. 34 ust. 3 lit. a) RODO? Szyfrowanie po stronie serwera: obowiązek powiadomienia w razie naruszenia. Szyfrowanie po stronie klienta: brak obowiązku powiadomienia, bo dane są nieczytelne.
Co jest przechowywane na serwerze
Przy szyfrowaniu po stronie klienta na serwerze trwale przechowywane są tylko zaszyfrowane dane. Transkrypcja jest przechowywana w postaci zaszyfrowanej i może ją odszyfrować tylko sam użytkownik. Oryginalne pliki audio są automatycznie usuwane po przetworzeniu – na serwerze pozostaje tylko zaszyfrowana wersja do odtwarzania.
Wynik: nawet my jako dostawca nie możemy odczytać przechowywanych transkrypcji i plików audio.
Jak rozpoznać, którego typu szyfrowania używa usługa
Jeśli usługa transkrypcji mówi “Twoje dane są szyfrowane”, zapytaj konkretnie:
- “Kto trzyma klucz odszyfrowujący?”– Jeśli trzyma go dostawca, to szyfrowanie po stronie serwera.
- “Czy wasi pracownicy mogą czytać moje transkrypcje?” – U uczciwych dostawców używających szyfrowania po stronie serwera odpowiedź brzmi: teoretycznie tak.
- “Co dzieje się w razie wycieku danych?”– Jeśli dostawca wspomina o obowiązkach powiadomienia z art. 34 RODO, wskazuje to na dane możliwe do odszyfrowania.
- “Czy mogę sam zweryfikować szyfrowanie?”– Przy szyfrowaniu po stronie klienta możesz w karcie sieci przeglądarki sprawdzić, że przesyłane są tylko zaszyfrowane bajty.
Kiedy wystarczy szyfrowanie po stronie serwera?
Szyfrowanie po stronie serwera nie jest z natury złe. Dla treści niekrytycznych – np. przy transkrypcji publicznego podcastu – może wystarczyć. Ale dla:
- Dyktowania medycznego i rozmów z pacjentami
- Rozmów z klientami w kancelariach prawnych
- Posiedzeń zarządu i dyskusji strategicznych
- Wywiadów dziennikarskich z poufnymi źródłami
- Rozmów HR i ocen pracowniczych
- Rozpraw sądowych i zeznań świadków
… szyfrowanie po stronie klienta jest jedyną architekturą, która oferuje prawdziwą ochronę. Bo tutaj pytanie nie brzmi, czy dostawca nadużyje Twoich danych – lecz że technicznie nie może.
Podsumowanie
“Zaszyfrowane” to nie to samo co “chronione”. Decydująca różnica tkwi w tym, kto kontroluje klucz. Szyfrowanie po stronie serwera chroni dyski. Szyfrowanie po stronie klienta chroni Twoje dane – nawet przed samym dostawcą. Każdy, kto pracuje z poufnymi nagraniami audio, powinien znać tę różnicę.