Шифрование данных: клиентский подход против серверного

В другом приложение отправляет данные на сервер в открытом виде, а шифрование начинается уже внутри инфраструктуры провайдера.

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

Механика защиты: где на самом деле происходит криптография

В типичной облачной системе есть несколько разных состояний данных:

• данные на устройстве — файл, сообщение, фотография или запись до отправки;
• данные в пути — информация, которая передаётся между клиентом и сервером;
• данные на сервере — содержимое, сохранённое в базе, объектном хранилище или файловой системе;
• данные в обработке — информация, которую сервер расшифровывает, индексирует, анализирует или выдаёт пользователю.

Главная ошибка — считать, что наличие HTTPS автоматически означает полную защиту. TLS шифрует канал между приложением и сервером. На сервере провайдер всё равно получает возможность расшифровать запрос и обработать его. Если сервис использует только транспортное шифрование, то между конечными точками защищён канал, но не обязательно само содержимое.

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

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

Это и есть базовая логика E2EE, или сквозного шифрования: данные защищаются на конечном устройстве и расшифровываются только на доверенном конечном устройстве получателя. В архитектуре Zero-Knowledge провайдер дополнительно строит систему так, чтобы не иметь доступа к ключам и не обладать технической возможностью расшифровать пользовательское хранилище.

HTTPS защищает дорогу до сервера. E2EE защищает данные от самого сервера. Это разные задачи, и путать их в 2026 году уже неловко.

Для симметричного шифрования обычно применяется AES: один и тот же секрет используется для шифрования и расшифровки данных. Но в многопользовательских системах этого недостаточно. Нужно безопасно обмениваться ключами, подтверждать устройства и управлять доступом нескольких участников. Поэтому в архитектуре E2EE применяются асимметричные алгоритмы и протоколы обмена ключами, включая Диффи — Хеллмана.

На практике безопасность определяется не названием алгоритма. AES сам по себе не спасёт систему, если ключ хранится в конфигурационном файле рядом с паролем базы данных, а резервная копия этого файла лежит в том же облачном бакете. Криптография не компенсирует плохую операционную модель. Она лишь честно превращает ошибки управления доступом в более дорогие ошибки.

Серверное шифрование: удобство за счёт доверия к провайдеру

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

Это не бесполезная защита. Серверное шифрование снижает последствия физической кражи дисков, неправильной утилизации накопителей и некоторых сценариев доступа к данным в состоянии покоя. Если злоумышленник вытащил диск из серверной стойки, содержимое не обязано лежать там открытым текстом. Для крупных облачных платформ это базовый гигиенический слой.

Но границы защиты нужно видеть без корпоративного тумана. Серверное шифрование не скрывает данные от провайдера, потому что провайдер управляет инфраструктурой и ключами. Даже если ключи вынесены в KMS или HSM, оператор системы обычно сохраняет возможность инициировать расшифровку в рамках рабочих процессов, политик доступа и полномочий сервисных аккаунтов.

KMS и HSM повышают качество управления ключами. Они помогают централизовать ротацию, аудит операций, разделение ролей и защиту ключевого материала. HSM может выполнять криптографические операции в специализированном защищённом модуле. Но это не превращает серверное шифрование в Zero-Knowledge. Если приложение имеет право отправить запрос на расшифровку, архитектура остаётся серверной.

У этой модели есть сильное преимущество: сервер видит данные и может с ними работать. Отсюда появляются функции, которые пользователи считают само собой разумеющимися:

• полнотекстовый поиск по документам;
• индексация содержимого;
• антивирусная проверка файлов на стороне сервиса;
• предпросмотр документов и изображений;
• автоматическая классификация;
• дедупликация;
• преобразование форматов;
• совместное редактирование;
• серверное резервное копирование и восстановление;
• анализ метаданных и работа корпоративных политик DLP.

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

Что именно защищает серверная модель

Серверное шифрование обычно закрывает несколько практических угроз:

1. Кража физических носителей. Данные на дисках хранятся в зашифрованном виде, если ключевая инфраструктура не скомпрометирована вместе с ними.

2. Некоторые ошибки утилизации оборудования. Старый накопитель не превращается автоматически в архив открытых документов.

3. Несанкционированный доступ к объектному хранилищу. Злоумышленнику может понадобиться не только получить файл, но и добраться до ключей.

4. Часть сценариев компрометации резервных копий. Бэкап без ключа бесполезнее, чем бэкап в открытом виде.

5. Снижение риска при доступе к инфраструктурному слою. Например, когда атакующий видит хранилище, но не получает доступ к системе управления ключами.

При этом серверная модель не защищает от каждого сценария, где сервер является доверенной частью системы. Компрометация приложения, привилегированного администратора, сервисного аккаунта или процесса выдачи ключей может открыть доступ к расшифрованным данным.

Тут и появляется неприятная для маркетинга формулировка: зашифрованные данные на сервере могут быть защищены от кражи диска, но не обязательно от владельца сервера.

Клиентское шифрование и Zero-Knowledge: ключи остаются у владельца

Клиентское шифрование меняет порядок операций. Сначала приложение на устройстве пользователя получает данные, затем шифрует их, и только после этого отправляет в облако. Сервер хранит шифротекст. Если архитектура действительно построена по модели Zero-Knowledge, провайдер не знает ключ и не может расшифровать содержимое по собственной инициативе.

Для персональных данных, финансовых документов, медицинской информации, коммерческой тайны и внутренних корпоративных материалов это меняет профиль риска. Компрометация серверной инфраструктуры уже не означает автоматического раскрытия содержимого файлов. А судебный запрос к оператору не превращается в команду выдать открытый текст, если у оператора нет технического доступа к ключам.

Однако слово «Zero-Knowledge» часто используют как упаковку для набора менее впечатляющих функций. Нужно разделять маркетинговое заявление и реальную модель:

• где создаётся ключ;
• кто владеет мастер-ключом;
• покидает ли ключ устройство;
• может ли служба поддержки сбросить пароль и восстановить содержимое;
• хранится ли ключ в облачной синхронизации;
• какие данные остаются в метаданных;
• может ли сервер выдавать новые ключи клиенту;
• как добавляется новое устройство;
• что происходит при потере всех доверенных устройств.

Если техническая поддержка способна восстановить доступ к содержимому без участия пользователя, это сильный сигнал, что у провайдера есть механизм доступа к ключам или к резервной копии ключевого материала. В Zero-Knowledge такой комфорт обычно недоступен. Потеря мастер-пароля или приватного ключа может означать потерю данных. Поддержка не сможет просто открыть хранилище «по паспорту» или после стандартного сброса учётной записи.

Это не баг. Это цена отсутствия доверия к провайдеру.

Клиентская модель против серверной

Клиентская архитектура не делает систему неуязвимой. Она просто переносит критическую точку отказа. Раньше нужно было защищать сервер и его KMS. Теперь к этому добавляются конечные устройства, клиентское приложение, механизм обмена ключами, восстановление доступа и процедура подключения нового устройства.

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

Функциональность против конфиденциальности: где архитектура начинает мешать

Главный конфликт между клиентским и серверным шифрованием возникает не в математике, а в функциях. Серверные продукты привыкли видеть данные. На этом построен почти весь современный облачный комфорт.

Пользователь загружает документ, а сервер сразу строит индекс. Вводит слово в строку поиска — получает результат по содержимому файлов. Загружает изображение — система создаёт миниатюру. Отправляет архив — антивирус проверяет его внутри облака. Подключает коллегу — сервис мгновенно применяет права доступа.

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

Полнотекстовый поиск по зашифрованным данным — не бесплатная функция. Даже если содержимое не раскрывается напрямую, сервер может видеть размеры объектов, время загрузки, частоту обращений, идентификаторы пользователей и другие признаки. Метаданные иногда достаточно информативны, чтобы восстановить структуру работы организации. Файл с непонятным именем всё равно может многое рассказать, если известно, когда он появился, кто его скачивал и как часто менялся.

Клиентское шифрование также влияет на совместную работу. Чтобы несколько устройств получили доступ к одному объекту, система должна безопасно передать или производно получить ключ. Для корпоративных команд добавляются вопросы увольнения сотрудника, ротации ключей, восстановления доступа, делегирования полномочий и аварийного доступа.

На серверной стороне эти процессы проще. Администратор меняет права в панели, блокирует пользователя, восстанавливает доступ, выгружает архив. В клиентской модели любое действие, затрагивающее содержимое, должно быть согласовано с криптографической схемой. Иначе при удалении сотрудника из группы пользователь исчезнет из списка, а старый ключ останется у него на ноутбуке. Доступ закрыт на уровне интерфейса, но не обязательно на уровне уже полученных данных.

Поэтому при выборе архитектуры нужно смотреть не на рекламное слово «шифрование», а на жизненный цикл информации:

• кто создаёт данные;
• кто должен их читать;
• на каких устройствах они открываются;
• как добавляются новые устройства;
• как отключаются старые;
• нужен ли поиск по содержимому;
• кто выполняет антивирусную проверку;
• допустима ли потеря данных при утрате ключа;
• требуется ли аварийный доступ со стороны компании;
• какие метаданные считаются чувствительными.

Если продукт обещает одновременно абсолютную приватность, мгновенный серверный поиск, полное восстановление доступа через поддержку и бесшовную совместную работу, нужно внимательно читать техническую документацию. Обычно хотя бы одно из обещаний держится на очень широком определении слова «приватность».

Производительность: шифрование не бесплатное, но цифры нельзя рисовать из воздуха

Клиентская криптография добавляет работу конечному устройству. Файл нужно зашифровать до загрузки и расшифровать перед просмотром. Для больших объёмов данных важны процессор, скорость накопителя, реализация криптографической библиотеки и способ обработки потока.

Но универсального процента падения производительности здесь нет. Он зависит от размера объектов, количества операций, типа устройства, сетевого протокола, кэширования и конкретного приложения. Утверждения вроде «E2EE замедляет систему на 30%» без описания стенда — декоративная аналитика, пригодная разве что для слайда с корпоративным градиентом.

В серверной модели часть нагрузки переносится в облако. Серверная инфраструктура обычно лучше масштабируется, а обработку можно распределять между узлами. Но это не означает, что пользователь получает бесплатную производительность. Сервер должен расшифровывать объекты, выполнять индексацию, поддерживать поиск и обслуживать параллельные запросы.

Клиентское шифрование особенно заметно в трёх сценариях:

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

2. Слабые мобильные устройства. На старом смартфоне криптографическая операция и последующая расшифровка могут конкурировать за ресурсы с интерфейсом и другими приложениями.

3. Синхронизация между несколькими клиентами. Каждый доверенный endpoint должен уметь корректно получать, хранить и использовать ключи.

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

Серверное шифрование выигрывает там, где требуется интенсивная обработка данных. Клиентское — там, где важнее минимизация доверия к инфраструктуре. Выбирать только по производительности — значит оптимизировать не ту часть системы.

Риски управления ключами: главный провал обычно находится не в алгоритме

Криптографический алгоритм может быть стандартным и проверенным. Управление ключами при этом способно превратить всю конструкцию в бутафорию.

В серверной модели ключи хранятся в KMS, HSM или иной системе управления секретами. Для безопасности критичны политики доступа, разделение ролей, аудит запросов, ротация, резервное копирование и изоляция сред. Доступ к данным может быть закрыт на уровне хранилища, но открыт через сервисный аккаунт приложения. Или ключи могут быть защищены, а журнал операций — нет. Или резервная копия ключей окажется доступна той же группе администраторов, которая управляет данными.

В клиентской модели риски другие. Мастер-ключ нельзя бездумно сохранять в локальном хранилище, отправлять в аналитику или включать в резервную копию устройства без защиты. Особенно опасны:

• логи с фрагментами открытых данных;
• резервные копии клиентских баз;
• экспорт конфигурации вместе с секретами;
• автоматическая синхронизация ключей через незащищённые каналы;
• повторное использование ключей между пользователями;
• слабая процедура подтверждения нового устройства;
• отсутствие отзыва ключей после компрометации;
• хранение ключевого материала в памяти дольше необходимого;
• восстановление через поддержку без чёткой криптографической модели.

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

Отдельная проблема — потеря ключа. В серверной архитектуре восстановление обычно является частью штатного процесса: администратор сбрасывает пароль, выдаёт доступ, возвращает файл из резервной копии. В Zero-Knowledge это невозможно без заранее подготовленного механизма восстановления. Если такого механизма нет, потеря мастер-пароля означает потерю расшифровки.

Здесь нет правильного ответа для всех. Для личного архива, где приоритетом является конфиденциальность, отсутствие восстановления может быть приемлемой ценой. Для предприятия с юридическими обязательствами, регламентом хранения и необходимостью доступа к данным после увольнения сотрудника — уже нет. Организация, которая выбирает E2EE, должна заранее решить, кто владеет ключами, кто имеет право на аварийный доступ и как фиксируется такая операция.

Zero-Knowledge убирает провайдера из цепочки доверия. Вместе с ним исчезает и привычная кнопка «восстановить всё через поддержку».

Как выбирать архитектуру без веры в рекламные обещания

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

Серверная модель рациональнее, когда сервису требуется активно обрабатывать содержимое. Это корпоративные хранилища с полнотекстовой индексацией, системы совместного редактирования, платформы с централизованным DLP, облачные архивы с развитым поиском и процессы, где аварийное восстановление важнее минимизации доверия к оператору.

Перед внедрением политики безопасности нужно зафиксировать несколько решений:

1. Разделить шифрование в пути и шифрование содержимого. TLS нужен почти всегда, но он не заменяет E2EE.

2. Определить владельца ключей. Формулировка «ключи защищены KMS» ничего не говорит о том, кто может инициировать расшифровку.

3. Проверить модель восстановления. Если провайдер обещает восстановить данные без пользовательского ключа, это нужно рассматривать как часть модели доступа, а не как чудо поддержки.

4. Описать компрометацию конечного устройства. E2EE не остановит малварь, которая читает документ после расшифровки.

5. Разобрать метаданные. Шифротекст не скрывает автоматически факт существования файла, его размер, время обращения и участников обмена.

6. Проверить добавление и отзыв устройств. Новый клиент должен проходить проверку, а скомпрометированный — терять доступ к будущим данным.

7. Проверить резервные копии. Нельзя защищать основной массив и оставлять открытой его копию.

8. Сопоставить требования бизнеса с криптографической моделью. Если компании нужен доступ к архиву после потери ключа сотрудником, это должно быть предусмотрено заранее.

9. Не принимать название архитектуры на веру. Требуйте описания потока данных, роли KMS/HSM, хранения ключей и процедуры восстановления.

10. Отдельно оценить серверные функции. Поиск, предпросмотр, антивирусная проверка и индексация могут означать, что сервер получает доступ к содержимому.

Шифрование данных на стороне клиента против серверного шифрования — это не выбор между «безопасным» и «небезопасным» вариантом. Это выбор между разными границами доверия.

Серверное шифрование защищает данные в состоянии покоя и поддерживает привычную облачную функциональность. Но провайдер остаётся частью доверенной зоны и обычно сохраняет возможность работать с содержимым. Клиентское шифрование и Zero-Knowledge сокращают эту зону, оставляя ключи у пользователя, но усложняют поиск, совместную работу, восстановление и управление устройствами.

Практический вывод простой. Если сервис говорит о шифровании, выясняйте не наличие AES в документации, а момент, когда данные впервые становятся шифротекстом, и момент, когда снова превращаются в открытый текст. Всё остальное — презентационная шелуха.