scryp
Все статьи
8 мин чтения

Шифрование на стороне сервера vs. на стороне клиента: решающее отличие

Почти каждый сервис транскрипции рекламирует «шифрование». Но не каждая форма шифрования защищает одинаково хорошо. Решающее отличие не в алгоритме - а в том, кто держит ключ.

Эта статья объясняет разницу между шифрованием на стороне сервера и на стороне клиента и почему она означает принципиальное отличие для ваших аудиофайлов.

Что на самом деле означает «шифрование at rest»

«Шифрование at rest» означает: данные хранятся в зашифрованном виде. Подвох: ключ держит поставщик. Каждый сотрудник с доступом к базе данных, каждый администратор облака и каждый хакер, скомпрометировавший сервер, может расшифровать данные.

Большинство облачных сервисов шифруют данные, когда они оказываются на диске. Это защищает от кражи физических дисков - сценарий, который в профессиональных ЦОД встречается редко. Это не защищает от:

  • Атак на приложение: Кто взламывает приложение, получает доступ к функции расшифровки.
  • Внутреннего доступа: Администраторы поставщика могут в любой момент прочитать данные.
  • Запросов властей: Поставщик может расшифровать данные и передать их.
  • Обучения ИИ: Поставщик мог бы использовать ваши данные для улучшения своих моделей.

Короче говоря: шифрование на стороне сервера защищает диск, а не ваши данные.

Что делает иначе шифрование на стороне клиента

При шифровании на стороне клиента ваш аудиофайл шифруется в браузере, прежде чем попасть на сервер. Сервер хранит только зашифрованные блобы - ключ он не хранит. Без вашего пароля сохранённые данные прочитать нельзя.

Процесс подробно:

  • 1. Генерация ключа: Для каждого файла в браузере генерируется отдельный 256-битный ключ (File Encryption Key).
  • 2. Локальное шифрование: Аудиофайл шифруется с помощью AES-256-GCM прямо в браузере. Сервер получает только зашифрованные байты.
  • 3. Защита ключа: Ключ файла шифруется вашим личным мастер-ключом и в таком виде хранится на сервере. Без вашего пароля никто не имеет к нему доступа.

Результат: на сервере всегда лежат только зашифрованные данные. Без вашего ключа никто не может их расшифровать, а поставщик ключ не хранит.

Прямое сравнение

Следующая таблица показывает разницу с первого взгляда:

  • Кто шифрует? Шифрование на стороне сервера: поставщик. Шифрование на стороне клиента: ваш браузер.
  • Кто может разблокировать ключ? Шифрование на стороне сервера: поставщик. Шифрование на стороне клиента: только вы, с помощью своего пароля.
  • Может ли поставщик прочитать сохранённые данные без вашего пароля? Шифрование на стороне сервера: да. Шифрование на стороне клиента: нет.
  • Защита при утечке? Шифрование на стороне сервера: ограниченная (часто скомпрометирован и ключ). Шифрование на стороне клиента: высокая, поскольку без вашего пароля данные не прочитать (ключ хранится на сервере только в зашифрованном виде).
  • Раскрытие властям? Шифрование на стороне сервера: поставщик может расшифровать. Шифрование на стороне клиента: поставщик хранит только зашифрованные блобы и не хранит ключа.
  • Ст. 34 п. 3 подп. a) GDPR? Шифрование на стороне сервера: обязанность уведомления при утечке. Шифрование на стороне клиента: уведомлять субъектов данных согласно ст. 34 п. 3 подп. a) GDPR, как правило, не требуется, поскольку без пароля данные нечитаемы.

Что хранится на сервере

При шифровании на стороне клиента на сервере постоянно хранятся только зашифрованные данные. Транскрипция хранится в зашифрованном виде; ключ к ней поставщик не хранит. Исходные аудиофайлы автоматически удаляются после обработки - на сервере остаётся только зашифрованная версия для воспроизведения.

Результат: сохранённые транскрипции и аудиофайлы нельзя прочитать без вашего пароля, а ключ к ним мы не храним.

Как определить, какой тип шифрования использует сервис

Если сервис транскрипции говорит «ваши данные зашифрованы», спросите конкретно:

  • «Кто держит ключ расшифровки?»- Если его держит поставщик, это шифрование на стороне сервера.
  • «Могут ли ваши сотрудники читать мои транскрипции?»- У честных поставщиков, использующих шифрование на стороне сервера, ответ звучит: теоретически да.
  • «Что происходит в случае утечки данных?»- Если поставщик упоминает обязанности уведомления по ст. 34 GDPR, это указывает на расшифровываемые данные.
  • «Могу ли я сам проверить шифрование?»- При шифровании на стороне клиента вы можете на вкладке сети браузера проверить, что загружаются только зашифрованные байты.

Когда достаточно шифрования на стороне сервера?

Шифрование на стороне сервера не является плохим по своей сути. Для некритичного контента - например, при транскрипции публичного подкаста - его может быть достаточно. Но для:

  • Медицинской диктовки и разговоров с пациентами
  • Разговоров с клиентами в юридических фирмах
  • Заседаний правления и стратегических обсуждений
  • Журналистских интервью с конфиденциальными источниками
  • HR-бесед и оценок сотрудников
  • Судебных заседаний и показаний свидетелей

… шифрование на стороне клиента является единственной архитектурой, обеспечивающей настоящую защиту. Потому что здесь вопрос не в том, злоупотребит ли поставщик вашими данными - а в том, что он не может прочитать сохранённые данные без вашего пароля.

Заключение

«Зашифровано» - не то же самое, что «защищено». Решающее отличие - в том, кто контролирует ключ. Шифрование на стороне сервера защищает диски. Шифрование на стороне клиента защищает ваши данные: без вашего пароля сохранённые данные никто не может прочитать. Каждый, кто работает с конфиденциальными аудиозаписями, должен знать это отличие.