Шифрование данных в облаке: что должен уметь провайдер и что на стороне клиента

Шифрование данных в облаке — тема, где легко ошибиться. И те, кто выстроил рабочую систему, и те, кто просто включил галочку по умолчанию, говорят одно и то же: у нас всё зашифровано. Но разницу между подходами можно пропустить на аудите и увидеть только в момент реального инцидента. Разобраться нужно в четырёх вещах: где именно происходит шифрование, при передаче или при хранении, кто держит ключи и кто реально контролирует доступ к ним, что случится при компрометации учётных данных; и как не потерять сами данные из-за ошибки в управлении ключами.

В облаке действует модель разделения ответственности (shared responsibility): провайдер защищает инфраструктуру, а клиент — свои данные и конфигурацию сервисов. Именно эта граница определяет, где начинаются реальные инциденты. В статье разберём, что обязан обеспечить провайдер, что должен настроить клиент, какие ошибки приводят к утечкам даже при включённом шифровании и как выбрать модель управления ключами. В конце — чек-лист провайдер vs клиент и план мини-аудита на один рабочий день.

Модель разделения ответственности

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

Что обычно делает провайдер

Провайдер берёт на себя:

• Физическую безопасность ЦОД: контроль доступа, видеонаблюдение, охрану, ограждения, резервное питание. Стандарты физической безопасности стоит проверить в SLA или документации.
• Шифрование дисков гипервизора и сетевых каналов между компонентами платформы — это базовое шифрование инфраструктуры клиент не видит и не контролирует, оно работает на уровне железа.
• Сегментацию сетей, межсетевые экраны платформенного уровня и изоляцию арендаторов.
• Контроль доступа к платформе — управление учётными записями своих сотрудников и ограничение доступа инженеров к данным клиентов.
• Внутренний аудит и логирование операций с инфраструктурой, часто недоступное клиенту напрямую. Отдельная зона — сертификации: ISO 27001, PCI DSS, локальные регуляторные требования. Актуальность сертификатов стоит проверять на сайте провайдера, поскольку они имеют срок действия.

Всё перечисленное — защита самой платформы, а не данных клиента внутри неё.

За что отвечает клиент

Клиент отвечает за:

• IAM и роли — кто имеет доступ к каким ресурсам и с какими правами;
• настройку сервисов — включено ли шифрование для конкретного бакета, диска, базы данных, очереди сообщений;
• выбор режима шифрования: SSE (server-side encryption) с ключами провайдера или управляемыми ключами, либо CSE (client-side encryption), когда данные шифруются до отправки в облако.

Дальше идёт управление ключами — где они хранятся, кто имеет к ним доступ, настроена ли ротация, TLS-конфигурация в приложениях — использование HTTPS, корректные сертификаты, запрет устаревших протоколов, управление секретами — где лежат и как ротируются пароли, токены, API-ключи, логирование и мониторинг — включены ли access logs, настроен ли алертинг на аномалии, и бэкапы с их шифрованием, причём с отдельными ключами.

Граница здесь чёткая: провайдер не может защитить данные клиента от него самого — от неправильной конфигурации, от IAM с правами admin на всё, от ключей, утекших в Git.

Два слоя шифрования: in transit и at rest

Шифрование работает на двух уровнях, и оба обязательны. Отсутствие одного из них оставляет уязвимость, которую не закрывает второй.

Шифрование данных in transit

Шифрование данных in transit защищает информацию в момент перемещения — между клиентом и сервером, между микросервисами, между ЦОД. Без него данные легко перехватить на любом промежуточном узле.

Основа — TLS 1.2 и TLS 1.3. TLS 1.0 и 1.1 считаются устаревшими и небезопасными, их нужно явно запрещать. TLS 1.3 быстрее за счёт сокращённого handshake и убирает ряд уязвимых cipher suites, существовавших в 1.2.

Шифрование in transit применяется в API-запросах к облачным сервисам, при доступе к веб-приложениям через HTTPS, при подключении к базам данных (PostgreSQL и MySQL поддерживают TLS-соединения), в S3-совместимых эндпоинтах объектного хранилища, в VPN-туннелях между локальной сетью и облаком и в межсервисном взаимодействии, где рекомендуется mTLS.

Стоит проверить набор поддерживаемых шифров (cipher suites), настройку HSTS для веб-сервисов, корректность и актуальность сертификатов, запрет устаревших протоколов на уровне балансировщиков и приложений.

TLS не заменяет шифрование at rest: данные, передаваемые зашифрованно по сети, могут лежать на диске в открытом виде — это разные слои защиты.

Шифрование данных at rest

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

Оно применяется к блочным дискам и томам виртуальных машин, объектному хранилищу (S3-совместимые бакеты), managed-базам данных (PostgreSQL, MySQL, MongoDB и другим), файловым хранилищам (NFS/SMB), снапшотам виртуальных машин и дисков, резервным копиям, а также к временным файлам и swap-разделам.

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

Типовые алгоритмы — AES-256 для симметричного шифрования, RSA-2048 или RSA-4096 для асимметричного. У провайдера стоит уточнять, какие алгоритмы используются по умолчанию и можно ли выбрать другие.

Что должен уметь провайдер

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

Шифрование по умолчанию и прозрачность реализации

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

Стоит проверить, шифруются ли по умолчанию блочные диски при создании ВМ, новые бакеты объектного хранилища, managed-БД, очереди, кэши; какой алгоритм используется и задокументирован ли он, а не просто упомянут в белой книге; можно ли выбрать ключ — provider-managed key (PMK) или customer-managed key (CMK). Если провайдер не публикует техническую документацию по реализации шифрования, это повод запросить её явно или поискать другого провайдера.

KMS: управление ключами шифрования

KMS (Key Management Service) — сервис, который централизованно создаёт, хранит, использует и уничтожает криптографические ключи. Без него управление ключами быстро превращается в хаос: ключи хранятся в файлах, передаются по почте, теряются при смене сотрудника.

Что должен уметь KMS провайдера:

1. Создание и хранение ключей. Генерация криптографически стойких ключей, защищенное хранение (в идеале с использованием HSM на уровне платформы).
2. Key policies. Детальные политики: кто из пользователей или сервисных аккаунтов может использовать ключ для шифрования, кто для расшифрования, кто для управления.
3. IAM-интеграция. Привязка политик ключей к ролям и учетным записям облачной платформы.
4. Ротация. Автоматическая и ручная ротация ключей. Автоматическая ротация каждые 12 месяцев — минимальный стандарт, некоторые регуляторы требуют раз в 90 дней.
5. Версионирование ключей. Старые версии ключей должны сохраняться для расшифрования ранее зашифрованных данных, но не использоваться для нового шифрования.
6. Аудит операций. Журнал: кто, когда, какой ключ использовал (encrypt/decrypt/describe). Без этого журнала расследование инцидента невозможно.
7. Интеграция с сервисами. KMS должен быть связан с дисками, объектным хранилищем, БД, секретами. Иначе управление ключами придется выстраивать вручную для каждого сервиса.
8. Возможность отключить или удалить ключ при инциденте или по истечении срока действия. Уточните: мгновенное удаление или с задержкой? Задержка в 7–30 дней — разумная защита от случайного удаления.

HSM: когда нужен аппаратный модуль

HSM (Hardware Security Module) — физическое устройство для генерации и хранения ключей, сертифицированное по стандарту FIPS 140-2 Level 3 или выше. Ключи никогда не покидают HSM в открытом виде — все криптографические операции выполняются внутри устройства.

HSM нужен, если регулятор явно требует аппаратного хранения ключей (финансовый сектор, государственные системы), если политика ИБ требует FIPS 140-2 Level 3 или PCI HSM, или если компания хочет гарантий, что провайдер технически не может получить доступ к ключу.

У провайдера стоит уточнить: HSM выделенный (dedicated) или мультиарендный (shared) — для чувствительных данных нужен только выделенный; какой стандарт сертификации — FIPS 140-2 Level 2 это минимум, Level 3 для серьёзных требований; и какой SLA на доступность HSM, потому что простой этого сервиса означает невозможность расшифровать данные.

Поддержка BYOK и HYOK

Два подхода дают клиенту больше контроля над ключами.

BYOK (Bring Your Own Key) — клиент генерирует ключ самостоятельно, например на своём HSM, и импортирует его в KMS провайдера: провайдер хранит и использует ключ, но не генерировал его. Плюс — контроль над происхождением ключа, минус — ключ всё равно существует в инфраструктуре провайдера.

HYOK (Hold Your Own Key) — ключи остаются в инфраструктуре клиента, а провайдер запрашивает разрешение на каждую операцию шифрования или расшифрования. Плюс — провайдер технически не может расшифровать данные без участия клиента, минус — значительно выше сложность и требования к доступности собственной инфраструктуры.

Оба подхода доступны не у всех провайдеров и не для всех сервисов, поэтому у вашего провайдера стоит уточнить, что именно поддерживается.

Логи, аудит и доказуемость

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

Должны логироваться каждая операция с ключом (encrypt, decrypt, generate, describe, delete), кто её запросил — пользователь или сервисный аккаунт, с какого IP и когда, доступ к данным через сервисы — кто и когда открывал объект в бакете или обращался к БД, а также изменения политик ключей и IAM-ролей.

Хороший признак зрелого провайдера — логи экспортируются в SIEM (Splunk, Elastic или собственные решения), поддерживаются WORM-логи, которые нельзя изменить задним числом, и есть алертинг на аномалии — массовый decrypt, доступ из нестандартной геолокации.

Резервирование и отказоустойчивость KMS

KMS — критичный сервис: если он недоступен, данные не расшифровать, даже если сами данные физически целы. Это означает простой.

Стоит проверить, есть ли георезервирование KMS — ключи должны реплицироваться минимум в два независимых ЦОД, какой SLA на доступность (99,9% означает до 8,7 часов простоя в год, для критичных систем нужно 99,99%), задокументирована ли процедура восстановления при аварии и проводятся ли по ней учения, и что происходит с данными, если клиент случайно удалил ключ — есть ли период мягкого удаления (soft delete).

Что должен сделать клиент

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

Выбрать модель ключей

Есть три базовые модели с разным балансом контроля и сложности.

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

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

Настроить IAM по принципу наименьших привилегий

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

Роли стоит разделять: администратор облачной платформы не должен автоматически получать права на decrypt в KMS — это разные роли для разных людей, а admin KMS, admin данных и admin IAM должны быть разными функциями. Широкие права вроде : или kms:* для сервисных аккаунтов — красный флаг: каждый аккаунт должен получать минимум прав для своей задачи, а у каждого сервиса — свой собственный сервисный аккаунт. Для всех, кто может управлять ключами или получить доступ к критичным данным, обязательна MFA.

Стоит проверить, кто из пользователей и сервисных аккаунтов имеет kms:Decrypt на ключи production-среды — если список длиннее пяти позиций, там почти наверняка лишние.

Ротация ключей и жизненный цикл

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

Для CMK базовый стандарт — ротация раз в 12 месяцев, регуляторы в финансовом секторе могут требовать раз в 90 дней. Сервисные токены и пароли ротируют чаще, в идеале автоматически. После ротации старый ключ деактивируется, а не удаляется — данные, зашифрованные им, должны оставаться доступными, для этого хранят версии ключа. Процедуру ротации стоит протестировать заранее: создать новый ключ, перешифровать критичные данные, деактивировать старый. И у этого процесса должен быть конкретный ответственный, зафиксированный в регламенте.

Управление секретами

Секреты в коде — одна из самых распространённых причин утечек. Разработчик добавляет токен API в .env «на время», коммитит в Git, и токен остаётся в истории репозитория навсегда, даже если его удалили в следующем коммите.

Нельзя хранить ключи шифрования, пароли от БД и API-токены в .env-файлах в репозитории, выводить секреты в логи CI/CD-пайплайнов, которые часто доступны всей команде, вшивать секреты в образы контейнеров на этапе сборки или передавать ключи через переменные окружения без шифрования.

Вместо этого стоит использовать выделенный сервис для хранения и выдачи секретов — HashiCorp Vault или облачный аналог, короткоживущие токены с TTL (токен на час несравнимо безопаснее вечного), автоматическую ротацию секретов через API secrets manager, а для CI/CD — интеграцию с secrets manager вместо хранения секретов как переменных в настройках пайплайна.

TLS на стороне клиента и приложения

Даже если провайдер обеспечивает TLS на уровне платформы, приложение может его обойти — случайно или намеренно «для отладки».

HTTPS должен быть везде — для всех внешних и внутренних эндпоинтов, без исключений. HSTS не должен давать браузерам возможность откатиться на HTTP. Самоподписанные сертификаты в production недопустимы — нужны сертификаты от доверенных CA или автоматизация через Let's Encrypt или внутренний CA. Для межсервисного взаимодействия нужен mTLS, при котором обе стороны проверяют сертификат друг друга. Проверку сертификата нельзя отключать никогда: verify=False, ssl_verify=False, InsecureSkipVerify: true в production — это не временный фикс, а дыра без исключений. И S3-эндпоинты должны работать только по HTTPS, поскольку многие S3-клиенты по умолчанию могут использовать HTTP, если это не запрещено явно.

Шифрование бэкапов, снапшотов и экспортов

Бэкап без шифрования — это копия данных с пониженной защитой, и именно там атакующий ищет в первую очередь: production обычно защищён хорошо, а бэкапы — нет.

Стоит убедиться, что снапшоты ВМ и дисков наследуют шифрование источника — это нужно проверить явно для конкретного провайдера, а не считать само собой разумеющимся. Бэкапы БД должны шифроваться, а ключ храниться отдельно от бэкапа. Экспорты данных — CSV, дампы, аналитические выгрузки — нужно шифровать перед передачей или хранением. Для prod и backup стоит использовать отдельные ключи: если prod-ключ скомпрометирован, атакующий не должен автоматически получить доступ к бэкапам. И стоит проверить контроль доступа к бэкапам — часто бакет с ними имеет более широкие права, чем production-данные, и это нужно исправлять.

Типовые ошибки, из-за которых шифрование не спасает

Шифрование не работает как щит само по себе. Вот семь ошибок, каждая из которых сводит его эффект к нулю.

1. «Шифрование включили, IAM оставили admin всем». Если 30 человек имеют права admin, кто угодно из них может расшифровать любые данные. Практический вывод: внедрение шифрования без ревизии IAM — работа вполовину.

2. Один ключ на всё: prod, dev, бэкапы и тестовые среды. Компрометация одного ключа открывает всё. Практический вывод: один ключ на один контекст использования. Минимум — отдельные ключи для production и non-production.

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

4. Ключи и токены утекли в Git или CI-логи. Один из самых частых векторов. Коммит с токеном в config.py или вывод printenv в лог CI, и секрет доступен всем, у кого есть доступ к репозиторию. Практический вывод: настройте pre-commit hooks для обнаружения секретов, используйте secrets scanner (truffleHog, GitGuardian).

5. Отключили проверку TLS-сертификата «чтобы работало» requests.get(url, verify=False) или аналог в другом стеке. Это MITM-атака, ожидающая своего часа. Практический вывод: никогда не выключать verify в production. Если есть проблема с сертификатом, исправьте сертификат, а не обходите проверку.

6. Потеряли доступ к KMS или ключу (уволился сотрудник, нет break-glass). Единственный человек, знавший пароль от KMS-аккаунта, уволился. Или ключ удален, а период soft delete истек. Данные зашифрованы и недоступны навсегда. Практический вывод: задокументируйте и протестируйте процедуру break-glass. Доступ к KMS должен быть у минимум двух независимых лиц.

7. Логи не включены — инцидент нечем расследовать. Через три месяца после инцидента ИБ-команда пытается восстановить хронологию — а логов нет. Ни кто расшифровал данные, ни когда, ни откуда. Практический вывод: включите audit logs в KMS и для всех сервисов с чувствительными данными с первого дня. Логи дешевы — расследование без них бесценно дорого.

Мини-аудит за один рабочий день

1. Инвентаризация данных и сервисов. Составьте список: какие данные есть, где хранятся, какого класса конфиденциальности. Диски ВМ, бакеты, базы данных, очереди, файловые хранилища, бэкапы. Без этой карты непонятно, что вообще проверять.

2. Проверка шифрования at rest по сервисам. По каждому ресурсу из инвентаря: включено ли шифрование? Какой ключ используется (provider-managed или customer-managed)? Снапшоты и бэкапы — тоже зашифрованы? Обратите особое внимание на объекты, созданные давно: они могли быть созданы до того, как шифрование стало обязательным.

3. Проверка TLS. Запустите сканер конфигурации TLS для всех публичных эндпоинтов (testssl.sh, SSL Labs). Проверьте: используются ли TLS 1.0/1.1? Есть ли слабые cipher suites? Актуальны ли сертификаты и цепочки CA? Для внутренних эндпоинтов — аналогичная проверка через внутренний сканер.

4. Проверка KMS: кто имеет decrypt, включены ли логи, настроена ли ротация. Выгрузите список пользователей и ролей с правами kms:Decrypt на ключи production. Оцените список: все ли позиции оправданы? Проверьте, включено ли логирование операций с ключами. Проверьте дату создания ключей: если старше 12 месяцев без ротации, это пункт в отчет.

5. Проверка секретов: где лежат токены, есть ли ротация. Проверьте репозитории на наличие хардкодных секретов (secrets scanner). Проверьте CI/CD-переменные: нет ли там долгоживущих токенов с широкими правами. Проверьте, есть ли secrets manager и подключены ли к нему ключевые сервисы.

6. Тест break-glass: кто и как восстановит доступ при инциденте. Смоделируйте сценарий: ответственный за KMS недоступен, его аккаунт заблокирован. Кто и как восстанавливает доступ? Задокументирована ли эта процедура? Как давно она тестировалась? Если ответ «не знаю» или «никогда» — это критичный пробел.

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

Заключение

Шифрование данных в облаке — это не продукт, который можно один раз настроить и забыть, а сочетание двух вещей. Первая — возможности провайдера: KMS с аудитом, HSM, георезервирование, прозрачная документация алгоритмов, SLA на критичные сервисы. Вторая — дисциплина клиента: IAM с минимальными привилегиями, управляемые ключи с ротацией, TLS везде, секреты вне кода, зашифрованные бэкапы и работающие процедуры восстановления.

Ни одна из сторон не закрывает картину целиком: провайдер не настроит IAM клиента, а клиент не проверит физическую безопасность ЦОД. Работает только связка. Лучшее шифрование — то, которое можно доказать аудитом и которое не ломает процедуры восстановления: если логи показывают, кто и когда работал с ключами, а break-glass задокументирован и протестирован, значит, система выстроена правильно.