Обработка и защита данных в SaaS: пошаговый гайд по шифрованию

Для инженера по информационной безопасности — это пустой токен.

Нужны параметры: где именно шифруются данные, каким алгоритмом, кто управляет ключами, что попадает в резервные копии, какие объекты исключены из BYOK и что происходит с доступом сотрудника, который открыл файл легитимно. Обработка и защита данных в SaaS начинается не с галочки «encryption enabled», а с разложения системы на конкретные слои.

В облачном продукте данные постоянно меняют состояние: идут из браузера в API, попадают в очередь, записываются в базу, индексируются для поиска, копируются в бэкап, выгружаются в отчёт или интеграцию. Если провайдер говорит только «мы используем AES-256», он описывает один слой. Иногда — даже не самый проблемный.

Разложите данные на три состояния, а не на одну абстрактную «облачную среду»

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

Данные в передаче: TLS 1.3 — базовый минимум, не премиальная опция

Когда пользователь работает с SaaS через браузер, мобильное приложение, API или интеграцию, информация движется по сети. Здесь нужен TLS 1.3 — актуальный стандарт защищённого канала передачи данных.

TLS решает несколько задач одновременно:

• шифрует трафик между клиентом и сервисом, чтобы содержимое сессии не читалось в пути;
• подтверждает подлинность сервера через сертификат;
• снижает риск подмены трафика при корректной настройке;
• защищает не только веб-интерфейс, но и API-вызовы, webhook-и, обмен с интеграциями.

Однако строка «поддерживаем HTTPS» ещё не закрывает вопрос. В рабочей итерации проверки стоит смотреть шире:

1. Какие каналы входят в контур. Не только основной домен приложения, но и API, файловое хранилище, SMTP-уведомления, интеграционные шлюзы, мобильные клиенты.

2. Как устроена аутентификация API. TLS защищает канал, но не отменяет утечку токена доступа из CI/CD, браузерного расширения или лога.

3. Не выводятся ли персональные данные в URL и технические журналы. Шифрованный канал не мешает сервису сохранить чувствительный параметр внутри собственного access log.

4. Как ограничены интеграции. В SaaS-стеках именно автоматические коннекторы часто получают слишком широкие OAuth-разрешения и остаются активными после завершения проекта.

Данные в хранении: AES-256, но с уточнением контекста

Для шифрования данных «в покое» — в базах, файловых хранилищах и резервных копиях — распространён симметричный алгоритм AES-256. AES был принят как стандарт ещё в 2001 году, а ключ длиной 256 бит остаётся типовым выбором для корпоративных платформ.

Но фраза «база зашифрована AES-256» требует ещё минимум четырёх уточнений:

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

Шифрование баз данных защищает накопленный массив данных при компрометации носителя, некорректном физическом доступе к инфраструктуре или части сценариев с неправомерным извлечением хранилища. Но оно не останавливает пользователя с валидной сессией, который нажал «Экспортировать CSV». Это разные классы угроз, и смешивать их — классическая ошибка анкеты безопасности.

Шифрование отвечает на вопрос «сможет ли кто-то прочитать украденное хранилище», а управление доступом — «кому система вообще позволит увидеть данные».

Данные в использовании: здесь заканчивается магия AES

Когда SaaS-сервис строит отчёт, ищет карточку клиента, показывает документ сотруднику или передаёт запись в CRM через API, данные должны быть расшифрованы для разрешённой операции. Это неизбежно.

Поэтому безопасность персональных данных нельзя строить вокруг одного криптографического слоя. Рядом должны работать:

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

Шифрование в такой архитектуре — не замена этим механизмам, а опорный слой. Без него SaaS-платформа оставляет слишком широкую поверхность для последствий инфраструктурного инцидента.

Конвертное шифрование: почему KMS не должен шифровать каждый файл напрямую

На старте многие команды мыслят так: есть облачный KMS — сервис управления ключами, значит, можно отправлять в него каждый объект для шифрования. В реальной SaaS-архитектуре этот подход быстро упирается в задержки, стоимость вызовов и лимиты API.

Рабочий паттерн здесь — конвертное шифрование, или Envelope Encryption. Его логика довольно механическая, и именно поэтому она хорошо масштабируется.

1. Сервис создаёт ключ шифрования данных — DEK. Обычно он применяется к конкретному файлу, объекту, набору записей или ограниченному сегменту данных.

2. DEK шифрует сам массив данных. Для этой операции используется быстрый симметричный алгоритм, например AES-256.

3. Отдельный главный ключ — KEK — шифрует DEK. KEK хранится и контролируется через KMS либо аппаратный модуль безопасности HSM.

4. Рядом с зашифрованными данными сохраняется зашифрованный DEK. При чтении система получает разрешение на расшифровку DEK, а затем им открывает данные.

5. При ротации мастер-ключа переоборачиваются DEK, а не весь массив. Это критический параметр для больших баз и файловых архивов.

Если проводить аналогию без лишней литературности: данные лежат в коробках, каждая закрыта своим ключом DEK; сами ключи от коробок заперты главным ключом KEK. Менять один главный ключ намного дешевле, чем заново шифровать миллиарды записей.

В корректно спроектированной схеме конвертное шифрование сокращает количество API-вызовов к KMS более чем на 99%. Это не косметическая оптимизация. Для крупного SaaS это разница между безопасностью, встроенной в продуктовый поток, и безопасностью, которая начинает ломать latency и бюджет.

Что спросить у провайдера про KMS и HSM

Здесь не нужен аудит на 80 вопросов. Для первой итерации достаточно получить ясные ответы на несколько конкретных пунктов:

• Используется ли envelope encryption для файлов, БД и резервных копий?
• Где размещён KEK: в облачном KMS, отдельном HSM или внутри собственной инфраструктуры провайдера?
• Соответствует ли криптографический модуль требованиям FIPS 140-2, если это требуется вашей отраслью или внутренней политикой?
• Как запускается ротация ключей и влияет ли она на доступность сервиса?
• Что происходит с ключами после удаления клиента, истечения договора или запроса на удаление данных?
• Отдельно ли изолированы ключи разных тенантов в многопользовательской архитектуре?

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

BYOK и HYOK: похожие аббревиатуры, разный контроль

Управление ключами — место, где маркетинговая генерация особенно любит галлюцинации. В описаниях продуктов BYOK, CMK, customer-managed encryption и HYOK нередко оказываются в одном абзаце как синонимы. Это ошибка: граница контроля у них разная.

BYOK, Bring Your Own Key, означает, что клиент генерирует собственный ключ и импортирует его в KMS провайдера или выбранного облака. Клиент получает больше контроля над жизненным циклом ключа: может управлять политиками, ротацией, отключением и удалением в рамках возможностей платформы.

HYOK, Hold Your Own Key, идёт дальше. Ключ остаётся исключительно в инфраструктуре клиента — например, в собственном on-premises HSM. Провайдер SaaS не хранит этот ключ у себя.

BYOK — сильный вариант, но не абсолютный разрыв доверия с поставщиком. Ключ уже находится в KMS его облачного контура, поэтому нельзя заявлять, что BYOK полностью исключает техническую возможность доступа провайдера. Это не повод отказываться от модели; это причина не подменять термины.

HYOK лучше соответствует организациям, для которых внешний контроль ключей — принципиальное требование: финансовые структуры, здравоохранение, часть государственных и критических контуров. Цена такого контроля — сложная интеграция, зависимость от доступности собственного HSM и ограничения в функциях SaaS.

Проверяйте не только наличие BYOK, но и покрытие данных

Одна из самых неприятных находок в документации — «BYOK поддерживается», а через пару экранов мелким текстом: не для всех сервисов. У реальных платформ под клиентское управление ключами могут не попадать интерактивные доски, некоторые метаданные, поисковые индексы, телеметрия, системные логи или отдельные новые модули.

Например, в SaaS-продуктах клиентское управление мастер-ключами может быть реализовано через AWS KMS или Azure Key Vault, но распространяться не на все типы контента. Следовательно, вопрос должен звучать не «Есть ли BYOK?», а так:

• какие именно данные покрывает BYOK;
• шифруются ли вложения и версии файлов;
• распространяется ли модель на резервные копии;
• что происходит с индексами полнотекстового поиска;
• входят ли в контур метаданные: названия проектов, адреса пользователей, временные метки, права доступа;
• есть ли исключения для досок, комментариев, AI-функций и сторонних интеграций.

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

У BYOK ценность не в красивой аббревиатуре, а в праве клиента остановить доступ к конкретному криптографическому контуру.

Привяжите криптографию к регламенту обработки данных

Техническая схема не существует отдельно от процессов. GDPR, HIPAA, PCI DSS, ISO 27001 и SOC 2 различаются по предмету и юридической силе, но для SaaS-покупателя они сводятся к практической задаче: провайдер должен показать контролируемую обработку данных, а не просто перечислить знакомые стандарты на лендинге.

Для внутреннего регламента обработки данных полезно зафиксировать следующие слои.

Классификация и минимизация

Сначала определите, какие данные вообще входят в SaaS:

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

Дальше — минимизация. Если сервису для работы не нужен паспортный номер, не надо отправлять его в CRM «на всякий случай». Если для тестирования интеграции достаточно синтетического датасета, не используйте production-выгрузку. Это самый недооценённый метод защиты: удалить из потока то, что не должно было туда попадать.

Карта обработки

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

Минимальный набор полей:

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

Эта карта быстро обнаруживает разрыв между политикой и фактической генерацией данных. Например, отдел продаж считает, что работает только в CRM, но контактные данные параллельно уезжают в сервис рассылок, систему записи встреч, транскрибацию звонков и AI-ассистента для составления писем.

Доказательства вместо деклараций

Сертификаты ISO 27001 и отчёты SOC 2 полезны как индикатор зрелости процессов. Но они не заменяют уточнений по вашему сценарию. Для отраслей с требованиями HIPAA или PCI DSS особенно опасно считать, что любой SaaS с общим словом «compliant» автоматически подходит под конкретный поток данных.

Запрашивайте у провайдера актуальное описание мер контроля, границ ответственности и перечня покрываемых функций. Если SaaS предлагает отдельный enterprise-тариф для расширенного шифрования или BYOK, надо сопоставить его не с общей политикой компании, а с данными в конкретном рабочем пространстве.

Четыре ошибки, которые ломают хорошую криптографию

Шифрование часто внедряют правильно, а утечка всё равно происходит через соседний слой. Вот четыре паттерна, которые я регулярно вижу в SaaS-стеках.

1. Оставить административные аккаунты без MFA.

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

2. Раздать интеграциям доступ «на всякий случай».

OAuth-токен с правом читать все файлы — это ключ от данных в прикладном смысле. Нужны минимальные scopes, инвентаризация подключений, сроки жизни токенов и регулярный отзыв неиспользуемых интеграций.

3. Считать резервные копии второстепенными данными.

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

4. Игнорировать экспорт и теневые копии.

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

Соберите рабочую последовательность, а не коллекцию настроек

Если SaaS уже используется, порядок действий я бы строил так. Не пытайтесь за один спринт «закрыть безопасность»: сначала получите карту, затем устраните самые опасные разрывы.

1. Инвентаризируйте сервисы и данные. Выявите основной SaaS, подключённые приложения, теневые инструменты и AI-функции. Отдельно отметьте персональные, платёжные, медицинские и коммерчески чувствительные данные.

2. Проверьте шифрование в передаче и хранении. Зафиксируйте TLS 1.3 для каналов и AES-256 либо эквивалентно обоснованную схему для данных, БД и бэкапов.

3. Разберите модель ключей. Узнайте, используется ли KMS/HSM, envelope encryption, доступен ли BYOK, возможен ли HYOK и что реально входит в покрытие.

4. Закройте доступы. Включите MFA, минимальные роли, ревизию гостевых пользователей, контроль сервисных аккаунтов и API-ключей.

5. Настройте наблюдаемость. Логи входов, экспорта, изменения прав, создания интеграций и операций с ключами должны попадать в понятный процесс реагирования.

6. Проверьте сценарий отключения. Что произойдёт при отзыве ключа, удалении сотрудника, расторжении договора и запросе на удаление данных? Если ответ не протестирован, это гипотеза, а не контроль.

Финальная граница здесь проста. Шифрование — обязательный параметр зрелого SaaS, но не самостоятельная стратегия. TLS 1.3 закрывает передачу, AES-256 защищает хранение, конвертное шифрование делает криптографию масштабируемой, BYOK и HYOK меняют степень контроля над ключами. Но доступы, интеграции, резервные копии и поведение людей остаются отдельными поверхностями атаки.

Хорошая обработка и защита данных выглядит не как одна строка в security whitepaper. Это воспроизводимая система: известно, какие данные есть, где они проходят, чем зашифрованы, кто открывает ключи и что команда делает в момент, когда ключ, токен или учётная запись перестают быть доверенными.