Vault Transit или облачный KMS: где шифровать данные приложений

Прикладное шифрование часто начинают с простого требования: база данных должна хранить не открытые значения, а шифротекст, при этом ключ нельзя размещать рядом с данными. На практике DevOps-команде приходится выбирать не только алгоритм, но и место выполнения криптографической операции. Приложение может отправлять данные в собственный кластер Vault Transit либо обращаться к KMS облачного провайдера.

Оба варианта относятся к модели cryptography-as-a-service. Приложение не получает постоянный мастер-ключ, а вызывает API для шифрования, расшифрования, подписи или других операций. Разница заключается в границе доверия: в случае Vault её контролирует ваша команда, а в случае облачного KMS — провайдер и его инфраструктура.

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

Как работают Vault Transit и облачный KMS

Vault Transit

Transit — secrets engine Vault, который предоставляет шифрование как API. Приложение передаёт открытые данные в Vault и получает шифротекст, содержащий информацию о версии использованного ключа. При расшифровании шифротекст отправляется обратно. Сами прикладные данные Vault не сохраняет: хранить результат должна база данных, объектное хранилище или другая система приложения.

Ключи создаются и версионируются внутри контура Vault. Их защита зависит от архитектуры seal, безопасности хранилища Vault, настроек доступа и состояния кластера. После разблокировки Vault может выполнять операции с ключевым материалом, не выдавая его приложению. Кроме шифрования и расшифрования, Transit поддерживает подпись, проверку подписей, HMAC, хеширование и выдачу ключей данных для envelope encryption.

Типовой поток выглядит так:

1. Приложение аутентифицируется в Vault и получает ограниченный по сроку и возможностям токен.
2. Открытое значение отправляется на endpoint шифрования конкретного именованного ключа.
3. Vault выполняет операцию и возвращает версионированный шифротекст.
4. Приложение записывает результат в своё основное хранилище.
5. Для чтения приложение передаёт шифротекст на endpoint расшифрования и получает открытое значение.

Облачный KMS

Внешний KMS предоставляет аналогичный API, но мастер-ключ размещается в инфраструктуре облачного провайдера. В зависимости от услуги и выбранного класса защиты ключ может обслуживаться программным криптографическим модулем либо HSM. Приложение вызывает KMS напрямую через SDK или API, а доступ регулируется облачным IAM.

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

Возможен и промежуточный вариант, когда Vault предоставляет приложениям собственные политики и идентификацию, а криптографические операции выполняет внешний сервис. Подтверждённый пример — Google Cloud KMS secrets engine: он позволяет через API Vault создавать и ротировать ключи Google Cloud KMS, шифровать и расшифровывать данные, а также выполнять поддерживаемые операции подписи. Это не Vault Transit: выполнение запроса зависит и от Vault, и от Google Cloud KMS.

Такую схему нельзя автоматически переносить на любой облачный KMS. Наличие интеграции, способ установки плагина, поддерживаемые алгоритмы, операции и требования к полномочиям зависят от конкретного провайдера и реализации secrets engine. Перед проектированием нужно проверить документацию выбранной связки, а не исходить из общей совместимости Vault со всеми KMS.

Где фактически находится открытый текст

Фраза «ключ не покидает KMS» не означает, что открытые данные никогда не выходят из процесса приложения. При прямом вызове Transit или симметричного API облачного KMS приложение отправляет открытый текст удалённой службе по защищённому соединению. Служба видит данные в рамках выполняемой операции и возвращает шифротекст.

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

При envelope encryption приложение генерирует случайный ключ данных — DEK — и локально шифрует им полезную нагрузку. KMS или Vault защищает только DEK с помощью мастер-ключа — KEK. Вместе с данными сохраняются шифротекст, зашифрованный DEK и необходимые параметры алгоритма. Для чтения служба расшифровывает DEK, после чего приложение локально обрабатывает основной объём данных.

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

Сравнение хранения и контроля ключей

Ключи в Vault Transit

При использовании Transit жизненным циклом ключей управляет Vault. Команда определяет, где работает кластер, какое хранилище используется, как выполняются seal и unseal, кто имеет административный доступ и как создаются резервные копии. Это даёт высокий уровень контроля, но одновременно переносит на владельца системы ответственность за её безопасность.

Компрометация одной учётной записи приложения не обязана приводить к раскрытию ключа: политика может разрешать только вызов нужного endpoint. Однако захват привилегированного управления Vault, его хоста или критичных компонентов seal-инфраструктуры создаёт значительно более серьёзный риск. Размещение Vault на той же VDS и под той же административной учётной записью, что и приложение, формально отделяет ключ от базы, но оставляет общий домен компрометации.

Ключи в облачном KMS

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

Такой вариант отделяет ключи от VDS и её администратора. Даже полный доступ к диску сервера не даёт мастер-ключ автоматически. Но злоумышленник, получивший действующие облачные полномочия приложения, может использовать KMS от его имени. Следовательно, защищать нужно не только ключ, но и идентичность workload, с помощью которой вызывается API.

Задержка и производительность

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

Self-hosted Vault можно разместить близко к приложениям — в том же дата-центре, приватной сети или сегменте облака. Это обычно делает сетевой маршрут короче и предсказуемее. Но экономить задержку размещением Vault на том же одиночном сервере не стоит: выигрыш в миллисекундах сопровождается общей точкой отказа и единым периметром компрометации.

Облачный KMS наиболее предсказуем, когда workload и ключ находятся в совместимом регионе и используют внутреннюю сеть провайдера. Обращение из внешней VDS к облачному KMS проходит через дополнительные сетевые границы. На него влияют доступность интернет-канала или частного соединения, маршрутизация, DNS и состояние облачной IAM-инфраструктуры.

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

Для производительности полезны следующие принципы:

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

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

IAM и разделение полномочий

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

Облачный KMS использует IAM провайдера. Наиболее естественно он работает с workload identity: роль назначается виртуальной машине, сервисной учётной записи, pod или другому исполняемому объекту без постоянного ключа в конфигурационном файле. Для VDS вне облака может потребоваться федерация идентичности либо сервисные полномочия. Второй вариант проще внедрить, но появляется долгоживущий секрет, который нужно безопасно выдавать и регулярно менять.

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

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

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

Ротация и повторное шифрование

Ротация обычно создаёт новую версию ключа, которая применяется к последующим операциям. Старые версии сохраняются, чтобы ранее созданный шифротекст оставался доступным. Это относится и к Transit, и к большинству моделей KMS, хотя названия состояний и механика выбора активной версии различаются.

Ротация мастер-ключа сама по себе не обновляет уже сохранённые записи. В Transit старый шифротекст можно передать на операцию rewrap: Vault расшифрует его старой версией и сразу зашифрует актуальной, не возвращая открытый текст вызывающей стороне. Внешние KMS предлагают собственные варианты повторного шифрования либо требуют реализовать миграционный процесс на стороне приложения.

Для envelope encryption обновить защищённый DEK обычно дешевле, чем повторно шифровать весь объект. Полезная нагрузка остаётся зашифрованной тем же DEK, а меняется только его обёртка под новой версией KEK. Но такая схема допустима лишь при сохранении требуемой криптографической стойкости DEK и отсутствии причины считать его скомпрометированным.

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

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

Аудит криптографических операций

Vault способен централизованно фиксировать обращения к Transit через audit devices. Это позволяет связать запрос с идентичностью, политикой, путём API и результатом операции. Журналы должны отправляться в отдельный защищённый контур: локальный файл на том же узле не помогает, если сервер потерян или скомпрометирован.

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

При использовании подтверждённой интеграции Vault с внешним KMS, такой как Google Cloud KMS secrets engine, появляются два слоя журналов. Запись Vault отвечает на вопрос, какое приложение вызвало его API, а запись провайдера — какая идентичность Vault обратилась к KMS. Для расследования нужно заранее сохранить связь между этими событиями: синхронизировать время, передавать корреляционный идентификатор там, где это возможно, и настроить совместимые сроки хранения. Для других провайдеров состав событий и возможность корреляции зависят от конкретного плагина и аудита KMS.

Аудит не ограничивается включением логов. Команда должна обнаруживать:

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

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

Отказоустойчивость и зависимость приложения

Self-hosted Vault на VDS

Один экземпляр Vault на одной VDS не является отказоустойчивой криптографической службой. При остановке сервера приложение теряет возможность расшифровывать данные, даже если база остаётся доступной. Для критичной нагрузки нужны несколько узлов Vault, поддерживаемое HA-хранилище, балансировка или корректная обработка перенаправления запросов, контролируемая процедура разблокировки, мониторинг и проверяемое восстановление.

В HA-режиме один узел Vault становится активным, а остальные работают как standby и могут перенаправлять запросы либо передавать их активному узлу. Возможность такого режима определяется выбранным storage backend или отдельным HA backend. Поэтому требования к числу узлов хранилища, кворуму, сетевой связности и размещению нельзя задавать одинаково для любой установки Vault: они зависят от архитектуры backend.

Если используется Vault Integrated Storage на основе Raft, доступность записи и выбор лидера зависят от кворума голосующих узлов. В этом случае узлы следует распределять между независимыми доменами отказа, сохраняя стабильную и достаточно быструю связь между участниками Raft. Большое географическое расстояние и нестабильная сеть между голосующими узлами увеличивают задержку репликации и риск потери кворума.

При использовании другого поддерживаемого HA-хранилища, например отдельного кластера Consul, свойства консенсуса, кворума и географического размещения определяются уже этим backend. Сами серверы Vault используют механизм активного узла и standby, но устойчивость всей системы зависит также от доступности внешнего хранилища и HA-блокировки. Высокую доступность Vault и аварийное восстановление между площадками нужно проектировать отдельно, а не считать синонимами.

Резервная копия хранилища Vault необходима, но недостаточна. Команда должна понимать, как восстановить выбранный storage backend, seal-зависимости, конфигурацию, сертификаты, DNS и сетевые политики. Проверка восстановления проводится в изолированной среде: наличие файла резервной копии ещё не доказывает возможность получить старые ключи.

Внешний облачный KMS

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

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

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

Не каждую ошибку следует скрывать повторными запросами. Если KMS или Vault недоступен, приложение должно ограниченно повторить операцию и затем перейти в заранее определённый режим:

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

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

Что выбрать для VDS

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

Однако установка Vault только ради нескольких операций шифрования может оказаться непропорционально сложной. Без нескольких узлов, поддерживаемого HA-хранилища, мониторинга и безопасного seal-механизма self-hosted решение рискует стать менее надёжным, чем управляемый KMS.

Облачный KMS можно использовать и с внешней VDS. Он обеспечивает физическое отделение ключа от сервера и избавляет от эксплуатации кластера, но требует надёжного канала до провайдера и безопасной облачной идентичности. Перед выбором необходимо оценить задержку из дата-центра VDS, стоимость операций, доступность федерации идентичности и последствия блокировки облачной учётной записи. Для размещения приложения и отдельных узлов Vault подойдёт VPS-сервер с возможностью разделить роли и сетевые контуры.

Облачный VDS-сервер

Виртуальные серверы с быстрым запуском и гибкой конфигурацией от 390₽ / мес

Доступные локации

Россия Нидерланды

Смотреть тарифы

Что выбрать для облачных приложений

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

Vault Transit остаётся оправданным, если организации нужна единая модель криптографического API для нескольких облаков и собственных площадок, централизованные политики Vault или функции Transit, вокруг которых уже построены приложения. Цена такой унификации — эксплуатация Vault и дополнительная сетевая зависимость между workload и кластером.

В мультиоблачной среде нет универсального решения. Единый Vault уменьшает различия прикладного API, но становится общей критичной платформой. Отдельный KMS в каждом облаке сокращает локальную задержку и использует нативный IAM, но требует адаптеров, согласования политик и продуманного формата шифротекста. Выбор зависит от того, что важнее: единый контроль или минимальная зависимость между площадками.

Практическая матрица выбора

• Выбирайте Vault Transit, если нужен единый API в разных инфраструктурах, команда уже надёжно эксплуатирует Vault, важен контроль над местом размещения и приемлема ответственность за HA и восстановление.
• Выбирайте прямой облачный KMS, если workload находится в одном облаке, использует нативный IAM, требуется управляемая инфраструктура ключей или HSM-вариант, а зависимость от провайдера допустима.
• Рассмотрите подтверждённую интеграцию Vault с KMS, если приложения должны работать через политики и идентичности Vault, но ключ обязан находиться во внешнем сервисе. Google Cloud KMS secrets engine является примером такой схемы. Для другого KMS сначала проверьте наличие плагина и список поддерживаемых операций; в любом случае учитывайте двойную зависимость, задержку и два слоя аудита.
• Используйте envelope encryption, если шифруются файлы, резервные копии, крупные объекты или высокочастотный поток. Удалённая служба должна защищать DEK, а не обрабатывать весь объём данных.
• Не размещайте одиночный Vault рядом с приложением как формальность. Такая схема не обеспечивает ни полноценного разделения доменов отказа, ни устойчивости.

Вопросы перед внедрением

1. Какие данные шифруются и должен ли открытый текст покидать процесс приложения?
2. Где проходят границы доверия: VDS, дата-центр, облачная организация, конкретный регион?
3. Как приложение получает машинную идентичность без постоянных ключей в конфигурации?
4. Нужны ли только encrypt и decrypt либо также подпись, HMAC и выдача DEK?
5. Сколько криптографических операций выполняется на один пользовательский запрос?
6. Какое увеличение задержки допустимо и измерено ли оно из реальной сети?
7. Что произойдёт с чтением и записью при недоступности Vault, KMS или IAM?
8. Кто может создавать, ротировать, отключать и уничтожать версии ключа?
9. Как будут мигрировать старые шифротексты после ротации?
10. Можно ли связать прикладной запрос с событием в журнале криптографической службы?
11. Проверено ли восстановление ключей из резервной копии, а не только создание бэкапа?
12. Содержит ли формат шифротекста идентификатор ключа, версию схемы и необходимые параметры?

Распространённые ошибки

Подмена шифрования хранилищем секретов. Запись мастер-ключа в KV и загрузка его приложением возвращает ответственность за защиту ключа в процесс и конфигурацию приложения. Transit и KMS нужны именно для ограничения прямого доступа к мастер-ключу.

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

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

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

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

Удаление старых версий без инвентаризации. Результатом может стать необратимая потеря доступа к архиву или резервной копии, обнаруженная спустя месяцы.

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

Итог

Vault Transit и облачный KMS различаются не столько базовой возможностью шифровать данные, сколько моделью ответственности. Transit даёт DevOps-команде единый контролируемый сервис и гибкие политики, но требует самостоятельно обеспечить безопасность хранилища, seal, обновления, аудит, поддерживаемую HA-архитектуру и аварийное восстановление. Если выбран Integrated Storage на основе Raft или другой консенсусный backend, отдельно учитываются его требования к кворуму и сетевой связности. Облачный KMS переносит эксплуатацию ключевой инфраструктуры провайдеру и хорошо интегрируется с нативным IAM, но создаёт зависимость от его сети, регионов, квот и административного контура.

Для облачной нагрузки у одного провайдера рациональной отправной точкой обычно становится прямой KMS. Для VDS, нескольких площадок и уже зрелой инфраструктуры Vault — Transit. Если нужно совместить политики Vault с внешним размещением ключа, следует искать конкретную поддерживаемую интеграцию. Например, Google Cloud KMS secrets engine позволяет выполнять операции с ключами Google Cloud KMS через Vault, но аналогичная схема не гарантирована для любого провайдера.

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