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 przechowuje klucza. Bez Twojego hasła przechowywanych danych nie da się odczytać.

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 znajdują się tylko zaszyfrowane dane. Bez Twojego klucza nikt nie może ich odszyfrować, a dostawca nie przechowuje 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 może odblokować klucz? Szyfrowanie po stronie serwera: dostawca. Szyfrowanie po stronie klienta: tylko Ty, swoim hasłem.
• Czy dostawca może odczytać przechowywane dane bez Twojego hasła? 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: wysoka, ponieważ bez Twojego hasła nie da się odczytać danych (klucz jest na serwerze tylko w postaci zaszyfrowanej).
• Ujawnienie urzędom? Szyfrowanie po stronie serwera: dostawca może odszyfrować. Szyfrowanie po stronie klienta: dostawca przechowuje tylko zaszyfrowane bloby i nie przechowuje żadnego klucza.
• Art. 34 ust. 3 lit. a) RODO? Szyfrowanie po stronie serwera: obowiązek powiadomienia w razie naruszenia. Szyfrowanie po stronie klienta: zawiadomienie osób, których dane dotyczą, zgodnie z art. 34 ust. 3 lit. a) RODO z reguły nie jest wymagane, ponieważ bez hasła 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; klucza do niej dostawca nie przechowuje. Oryginalne pliki audio są automatycznie usuwane po przetworzeniu - na serwerze pozostaje tylko zaszyfrowana wersja do odtwarzania.

Wynik: przechowywanych transkrypcji i plików audio nie da się odczytać bez Twojego hasła, a klucza do nich nie przechowujemy.

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 nie może odczytać przechowywanych danych bez Twojego hasła.

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: bez Twojego hasła przechowywane dane są nieczytelne dla nikogo. Każdy, kto pracuje z poufnymi nagraniami audio, powinien znać tę różnicę.