Шифрование данных на стороне клиента в SaaS: критерии выбора
Обычное шифрование облачного сервиса защищает данные при передаче и хранении, но часто оставляет ключи под контролем провайдера.
В этом случае оператор инфраструктуры или злоумышленник, получивший доступ к его среде, потенциально может добраться до расшифрованного содержимого. Шифрование данных на стороне клиента в SaaS меняет границу доверия: приложение шифрует данные до отправки в облако, а ключи расшифровки остаются у клиента.
Само обозначение CSE, или Client-Side Encryption, еще не подтверждает нужный уровень защиты. В одном сервисе под ним может подразумеваться сквозное шифрование, при котором провайдер не располагает ключами. В другом клиент может управлять ключом, но передать его сервису на время обработки. Эти архитектуры решают разные задачи. При выборе нужно выяснить, где создаются ключи, кто ими управляет и какие операции SaaS способен выполнять над зашифрованными данными.
Механика клиентского шифрования: что именно видит провайдер
В базовом сценарии клиентское приложение берет данные, шифрует их локально и отправляет в SaaS уже шифротекст. Провайдер хранит и передает зашифрованные блоки. Чтобы открыть содержимое, пользователь или доверенный компонент на его стороне должен получить соответствующий ключ и выполнить расшифрование.
Это отличается от двух распространенных механизмов облачной защиты:
- TLS защищает данные при передаче между клиентом и сервером. После завершения TLS-соединения сервер обычно получает данные в открытом виде.
- Server-Side Encryption шифрует информацию на стороне провайдера перед записью в хранилище. Оператор контролирует инфраструктуру и, как правило, располагает средствами расшифрования.
- CSE выполняет шифрование до передачи в облачную инфраструктуру. В строгой модели ключ расшифрования недоступен провайдеру.
Эти механизмы могут работать одновременно. TLS 1.3 защищает канал связи, а CSE — содержимое на уровне приложения. Если сервер получает только шифротекст, компрометация базы данных не дает атакующему автоматически прочитать документы. Однако это не закрывает уязвимости клиентских устройств, учетных записей, процессов восстановления доступа и самого приложения.
Шифрование защищает содержимое в пределах конкретной границы. Надежность системы определяется тем, где эта граница проходит и кто может пересечь ее вместе с ключом.
Перед оценкой сервиса нужно определить, какие именно данные требуется скрыть от провайдера. Это могут быть файлы и вложения, текст сообщений, поля базы данных, резервные копии или весь пользовательский контент. Метаданные часто остаются видимыми: например, размер и время загрузки файла, идентификатор учетной записи, адреса взаимодействующих пользователей или сведения о том, кто и когда обращался к объекту. Наличие CSE не означает, что скрыта вся информация о работе компании в SaaS.
Есть и функциональная цена. Сервису сложнее выполнять поиск по содержимому, индексировать документы, извлекать текст, строить предпросмотр или запускать серверную аналитику, если он не получает открытые данные. Иногда такие функции сохраняются через локальную обработку или специальные схемы поиска. Иногда отключаются. Спецификация должна объяснять, какие операции проходят на устройстве пользователя, какие на сервере и какие требуют временного доступа к ключу.
Вопросы к архитектуре до закупки
Попросите поставщика описать поток данных для конкретного сценария, а не ограничиваться формулировкой «данные шифруются». В ответе должны быть понятны:
1. Где происходит шифрование: в браузере, настольном клиенте, мобильном приложении или отдельном агенте.
2. В какой момент открытый текст покидает устройство пользователя.
3. Может ли сервер получить ключ или материал для его восстановления.
4. Что происходит с ключами при синхронизации между устройствами и при восстановлении учетной записи.
5. Какие типы данных и метаданные остаются доступными серверной части.
6. Как реализованы удаление, экспорт и восстановление зашифрованных данных.
Особое внимание требуется веб-клиентам. Если код приложения каждый раз загружается с сервера провайдера, оператор, контролирующий развертывание, потенциально может изменить этот код и попытаться перехватить данные до шифрования. Это не доказывает наличие такой практики, но влияет на модель угроз. Для корпоративного использования стоит выяснить, есть ли подписанные клиенты, проверяемые релизы, контроль версий и возможность ограничить обновления.
Криптографический стек: алгоритм не заменяет спецификацию
Для шифрования больших объемов данных обычно применяют симметричные алгоритмы. В фактуре указан AES-256. Для защиты обмена ключами используют асимметричные механизмы, например RSA или ECC. Такое разделение ролей типично: симметричный алгоритм обрабатывает содержимое, а асимметричная криптография помогает безопасно передать или согласовать ключ.
Название алгоритма само по себе мало что говорит о качестве реализации. Нужно понимать, как создаются ключи, как они защищены, как часто обновляются и что случается при потере устройства или увольнении сотрудника. В спецификации также должны быть указаны режим работы алгоритма, использование случайных значений, проверка целостности и порядок обработки ошибок. Формулировка «используется AES-256» без этих деталей не дает возможности оценить архитектуру.
TLS 1.3 отвечает за защищенный канал связи. Он снижает риск перехвата и подмены трафика между клиентом и сервером при корректной настройке соединения. Но TLS не мешает серверу прочитать содержимое после завершения защищенной сессии, если приложение передало ему открытые данные. Поэтому проверка TLS и проверка CSE относятся к разным уровням.
| Параметр | TLS 1.3 | Серверное шифрование | Клиентское шифрование |
|---|---|---|---|
| Где действует защита | На канале передачи | В хранилище провайдера | До отправки данных в облако |
| Что получает сервер | Данные после завершения соединения | Обычно данные и средства доступа к ключам | В строгой модели — шифротекст |
| Основная задача | Защита сетевого обмена | Защита данных на носителе | Ограничение доступа провайдера к содержимому |
| Типичный остаточный риск | Доступ к данным на конечных точках | Компрометация учетной записи или ключей провайдера | Потеря клиентского ключа, компрометация устройства, утечка метаданных |
При оценке бенчмарка производительности нельзя переносить результаты одного сервиса на другой. Накладные расходы зависят от размера объектов, частоты операций, устройства, реализации клиента и того, шифруется ли весь объект целиком или отдельные блоки. Исследовательская фактура не содержит надежных универсальных процентов замедления. Их нужно измерять на пилоте с реальными рабочими данными: загрузкой файлов, поиском, совместным редактированием и синхронизацией.
Проведите пилот на нескольких типах устройств и сетевых условий. Зафиксируйте время открытия и сохранения типового объекта, поведение при потере соединения, расход памяти и нагрузку на клиент. Отдельно проверьте, не превращается ли криптографическая функция в причину обходного процесса: если сотрудники ради поиска начинают выгружать документы в сторонние инструменты, фактическая безопасность системы падает.
BYOK и HYOK: кто держит ключ
Модели управления ключами определяют, насколько заказчик контролирует расшифрование. Обозначения BYOK и HYOK встречаются в корпоративных SaaS, но поставщики могут реализовывать их по-разному. Название в коммерческом предложении не заменяет технического описания.
BYOK означает Bring Your Own Key: заказчик предоставляет или создает собственный ключ для использования сервисом. Ключ может храниться во внешней системе управления ключами или аппаратном модуле HSM. Однако провайдеру может требоваться доступ к нему во время обработки данных. Такая схема повышает контроль заказчика над жизненным циклом ключа, но не обязательно скрывает содержимое от сервиса.
HYOK означает Hold Your Own Key: заказчик удерживает ключ у себя и стремится сохранить контроль над операциями расшифрования. В зависимости от архитектуры это может ограничивать доступ SaaS к содержимому сильнее, чем BYOK. Цена — больше интеграционной сложности и ограничений на серверные функции. Нужно выяснить, где именно происходит расшифрование и может ли провайдер запросить ключ автоматически.
| Параметр | BYOK | HYOK |
|---|---|---|
| Контроль заказчика над ключом | Выше, чем при управлении ключами только провайдером | Обычно более строгий |
| Доступ SaaS к ключу | Может понадобиться для выполнения операций | По модели заказчик старается сохранить ключ вне контроля SaaS |
| Совместимость с функциями сервиса | Часто шире, зависит от реализации | Может ограничивать поиск, обработку и автоматизацию |
| Основной риск | Формальный контроль над ключом при фактическом доступе сервиса | Потеря доступности при сбое внешнего контура или ошибке интеграции |
| Что уточнять | Условия использования и отзыв ключа | Где выполняются расшифрование и проверка полномочий |
Для обеих моделей нужен ответ на вопрос о полном цикле ключа: генерация, хранение, выдача, ротация, отзыв, резервирование и уничтожение. Если поставщик обещает хранить ключ во внешнем HSM, уточните, кто администрирует модуль, кто может инициировать операции и какие события попадают в аудит. HSM защищает ключевой материал при определенных сценариях, но сам по себе не отвечает на вопрос, кто имеет право использовать ключ.
Потеря ключа — не абстрактный крайний случай. При строгом CSE провайдер может не иметь технической возможности восстановить данные за клиента. Поэтому план восстановления должен быть частью внедрения. Нужны назначенные владельцы ключей, резервный доступ, процедура замены устройства и проверяемый порядок действий при уходе сотрудника. Если ключ можно восстановить через аккаунт провайдера, выясните, кто участвует в процедуре и какой материал становится доступен оператору.
Zero Trust, доступы и соответствие требованиям
Клиентское шифрование встраивается в более широкую архитектуру безопасности. Zero Trust предполагает проверку каждого доступа с учетом пользователя, устройства, контекста и полномочий. Шифротекст в облаке не отменяет аутентификацию: захваченная учетная запись может дать атакующему доступ к данным через легитимный клиент, который сам выполнит расшифрование.
Для SaaS с CSE следует сочетать управление ключами с многофакторной аутентификацией, минимальными привилегиями, контролем устройств и аудитом действий. MFA снижает риск захвата аккаунта, но не устраняет фишинг, вредоносное ПО на конечном устройстве или злоупотребление правами администратора. Zero Trust также не является отдельным криптографическим механизмом. Это политика проверки и ограничения доступа.
Соответствие GDPR, PCI DSS или HIPAA нельзя вывести из факта применения AES-256. Регуляторные требования охватывают обработку данных, доступы, хранение, уведомление об инцидентах, договорные роли и организационные меры. Шифрование может быть одним из контролей, но заявленная поддержка стандарта должна подтверждаться документацией и областью сертификации. Уточните, распространяется ли она на конкретный продукт, регион размещения и выбранную конфигурацию.
Практический порядок проверки выглядит так:
1. Опишите данные и угрозы. Разделите содержимое, метаданные и служебную информацию. Укажите, от кого требуется защита: внешнего атакующего, администратора провайдера, скомпрометированного аккаунта или пользователя с избыточными правами.
2. Запросите схему потоков данных. Проследите путь от устройства до хранилища, включая предпросмотр, поиск, резервное копирование, экспорт и поддержку.
3. Разберите модель ключей. Зафиксируйте владельца, место хранения, доступные операции и порядок восстановления. Для BYOK и HYOK отдельно оцените, может ли SaaS расшифровать содержимое.
4. Проверьте клиентскую часть. Установите, где выполняется шифрование, как подписываются и обновляются клиенты и возможно ли независимо контролировать версию.
5. Проведите пилот. Сравните производительность и доступность рабочих функций с базовым сценарием. Проверьте отзыв доступа, смену ключа и восстановление после потери устройства.
6. Закрепите эксплуатационные правила. Определите ответственных, роли администраторов, журналирование, процедуру инцидента и порядок удаления данных.
Сильная криптография не компенсирует слабый процесс управления ключами. В корпоративной среде ключи и полномочия требуют такого же контроля, как учетные записи и привилегии.
Риск утечки и границы экономической оценки
Стоимость утечки помогает оценить масштаб риска, но не заменяет модель угроз. В отчете IBM Cost of a Data Breach 2024 приведена средняя стоимость одного инцидента для организаций в размере 4,45 млн долларов США. Это агрегированная оценка, а не прогноз ущерба для конкретной компании и не обещание, что CSE предотвратит потери на такую сумму.
Клиентское шифрование может снизить последствия компрометации серверного хранилища, если атакующий получает только шифротекст и не имеет доступа к ключам. Оно не предотвращает все сценарии утечки. Данные могут быть извлечены до шифрования с зараженного устройства, через украденную сессию, из экспортированного файла или через пользователя с законными полномочиями. Провайдер также продолжает отвечать за безопасность инфраструктуры, доступность сервиса и защиту тех данных, которые остаются в его распоряжении.
При экономическом сравнении учитывайте стоимость интеграции, поддержки ключевой инфраструктуры, обучения пользователей и ограничений функций. Сюда же относится операционный риск: если потеря ключа блокирует доступ к критичным данным, компании нужен резервный сценарий. Если сотрудники массово выгружают файлы ради функций, недоступных при CSE, архитектурное преимущество остается на бумаге.
Перед подписанием договора закрепите проверяемые требования: какие категории данных шифруются до отправки, кто контролирует ключи, какие метаданные доступны провайдеру, как устроено восстановление и какие события аудируются. Для высокочувствительных данных нужен тест не только штатного доступа, но и аварийных сценариев: отзыв ключа, компрометация учетной записи, смена администратора, потеря устройства и прекращение договора.
Выбор SaaS с поддержкой шифрования сводится к соответствию модели угроз конкретной реализации. Если цель — защита данных при передаче и хранении, TLS вместе с серверным шифрованием может покрыть часть требований. Если провайдер не должен читать содержимое, требуется строгая клиентская модель с контролем ключей и проверяемым потоком данных. В спецификации должны быть названы границы защиты, доступные функции и цена восстановления. Без этих трех пунктов аббревиатура CSE не является основанием для решения.