Почему ключи шифрования нельзя держать рядом с данными

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

Key Management Service решает не все вопросы секретов, но закрывает важный слой: управление криптографическими ключами. Вместо хранения ключа в приложении сервис получает controlled-доступ к операции шифрования, расшифрования или подписи. Ключ при этом остаётся внутри специализированной системы с аудитом, политиками доступа и ротацией.

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

Что именно хранит KMS

Важно разделять секреты и ключи. Secret manager обычно хранит значения: пароль, токен, строку подключения. KMS хранит криптографические ключи или управляет операциями с ними. Приложение может использовать KMS напрямую или через связку с secret manager.

Типичные задачи KMS:

создание мастер-ключей;
шифрование и расшифрование data keys;
подпись и проверка подписи;
ротация ключей;
разграничение доступа через IAM;
аудит операций;
защита ключевого материала в HSM или изолированном контуре.

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

Envelope encryption на практике

Частый паттерн — envelope encryption. Данные шифруются не мастер-ключом, а отдельным data key. Затем сам data key шифруется мастер-ключом в KMS и хранится рядом с зашифрованными данными.

Схема выглядит так:

приложение запрашивает data key;
KMS возвращает открытый data key и его зашифрованную версию;
приложение шифрует данные открытым data key;
открытый data key удаляется из памяти;
зашифрованные данные и encrypted data key сохраняются вместе.

При чтении приложение отправляет encrypted data key в KMS, получает расшифрованный data key и расшифровывает объект. Мастер-ключ не покидает KMS, а компрометация одного data key не раскрывает все данные системы.

Модель доверия к облаку

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

Есть несколько уровней:

provider-managed keys — ключи полностью управляются платформой;
customer-managed keys — ключи создаёт и настраивает клиент;
bring your own key — ключевой материал импортируется клиентом;
external key management — операции завязаны на внешний KMS или HSM.

Чем выше контроль, тем больше ответственности. Собственный HSM не поможет, если нет процедуры восстановления, ротации и мониторинга. С другой стороны, для большинства SaaS и внутренних систем customer-managed keys с жёсткими IAM-политиками уже дают большой выигрыш.

IAM важнее красивой схемы

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

Полезные правила:

отдельные ключи для разных доменов данных;
отдельные сервисные аккаунты для приложений;
запрет wildcard-доступа к операциям decrypt;
минимальные права для CI/CD;
отдельные политики для администраторов и runtime-сервисов;
обязательный аудит операций decrypt и key policy changes.

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

Ротация ключей без простоя

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

Если используется envelope encryption, ротация мастер-ключа может быть относительно безопасной: данные не обязательно перешифровывать сразу. Достаточно переобернуть data keys новым мастер-ключом. Для больших хранилищ это критично: полное перешифрование всех объектов может занять часы или дни.

Перед ротацией нужно проверить:

поддерживает ли приложение несколько версий ключа;
где хранится key id;
как обрабатываются старые объекты;
есть ли лимиты KMS API;
что произойдёт при частичной ошибке;
как откатиться, если новая политика сломала доступ.

Хорошая ротация — это процедура, а не ручная команда в панели управления.

Что мониторить

KMS должен быть частью observability. Минимальный набор метрик и событий:

количество encrypt/decrypt операций;
ошибки доступа;
рост latency;
изменения политик ключей;
создание и удаление ключей;
попытки decrypt из неожиданных сервисов;
превышение лимитов API;
операции администраторов.

Алерт на неожиданный рост decrypt может показать утечку, неправильный batch job или ошибку приложения. Алерт на изменение политики ключа часто важнее, чем обычные инфраструктурные метрики.

Практический вывод

KMS полезен не потому, что «так безопаснее» в абстрактном смысле. Он даёт конкретные инженерные свойства: ключи не лежат в конфиге, доступ управляется через IAM, операции аудируются, ротация становится процедурой, а компрометация одного сервиса не обязана раскрывать все данные.

Начинать стоит с самых чувствительных данных: бэкапы, документы, персональная информация, токены интеграций. Затем можно выносить шифрование объектов, секреты CI/CD и подпись артефактов. Главное — не ограничиться фактом подключения KMS, а построить вокруг него права, мониторинг и понятный процесс восстановления.