HashiCorp Vault в российском контексте: что реально угрожает, а что - паника

HashiCorp на прошлой неделе подтвердила ограничения для российских пользователей: enterprise-лицензии не продаются и не продлеваются. Одновременно вышел Vault 1.11 с заметными улучшениями в PKI - кросс-подпись сертификатов, улучшенная ротация корневых CA, OCSP-поддержка. В чате у нескольких клиентов тут же появился вопрос: «а нам не нужно срочно от Vault уходить?».

Мы пользуемся Vault в нескольких инфраструктурах - как в своей, так и у клиентов. Поэтому сели и разобрались без паники.

Что именно ввела HashiCorp

Ограничения касаются enterprise-продуктов: Vault Enterprise, Consul Enterprise, Terraform Enterprise и HCP (HashiCorp Cloud Platform). Продажа новых лицензий и продление существующих для РФ закрыты. Это часть санкционного compliance крупных американских вендоров - ничего неожиданного на фоне того, что мы уже видели с VMware, GitLab, Atlassian.

Vault Community Edition (он же open-source, бывший Vault OSS) - не затронут. Это MPL 2.0, исходники на GitHub, никаких лицензионных ключей. Скачать, развернуть, использовать - можно. Именно это издание стоит у подавляющего большинства российских компаний, которые не платили за enterprise-фичи.

Так что первый вопрос - какое именно издание у вас стоит. Если enterprise с активной лицензией - это реальная проблема. Если community - читайте дальше, там интереснее.

Риски community-издания: что реально

Технически Vault Community - это самостоятельный продукт, который работает независимо от HashiCorp-серверов. Никакого phone-home при операциях с секретами нет. Лицензионных проверок нет. Если у вас сейчас работает Vault 1.10 или 1.11 на своих серверах - он продолжит работать после любых действий HashiCorp в отношении российского рынка.

Реальные риски выглядят иначе:

• Обновления и патчи безопасности. Vault открытый, исходники доступны, CVE-патчи публикуются на GitHub. Получить новую версию - не проблема. Но если завтра HashiCorp закроет репозиторий для РФ на уровне IP (как сделал, например, GitHub в своё время с определёнными категориями аккаунтов) - нужен зеркальный репозиторий. Пока этого нет, но иметь внутреннее зеркало - разумная гигиена.

• Документация и Discuss. HashiCorp Discuss и learn.hashicorp.com пока доступны. Если доступ закроется - это неудобство, не катастрофа: документация версионируется вместе с кодом.

• Провайдеры и плагины. Vault-провайдер для Terraform, AWS/GCP/Azure auth backends - всё это open-source. Но если появится тенденция к закрытию облачных бэкендов через политику самих облаков - это отдельный разговор.

• Долгосрочная поддержка. HashiCorp определяет, какие версии получают security-патчи. Если компания решит сократить окно поддержки или изменить политику - open-source форк становится единственным путём. Такой сценарий реален, но пока не мейнстрим.

Чего нет в реальных рисках

Внезапная «смерть» продукта. Vault 1.11 работающий сегодня продолжит работать без изменений - это не SaaS, который можно отключить кнопкой.

Угроза текущим секретам. Данные зашифрованы вашим ключом (или HSM), Vault сам по себе не имеет доступа к расшифрованным значениям без unseal-ключей, которые у вас. HashiCorp физически не может «забрать» секреты или заблокировать доступ к ним.

Обязательный переход прямо сейчас. Если enterprise-лицензий нет - торопиться некуда. Это не та ситуация, что с VMware, где лицензия буквально истекает в Q4.

Что нужно сделать

Независимо от геополитики - это базовая гигиена для любой secrets management инфраструктуры:

• Внутреннее зеркало дистрибутивов. Поднять Nexus или Artifactory с зеркалом Vault-релизов. Делается за день, снимает зависимость от внешней доступности releases.hashicorp.com.

• Ревизия enterprise vs community. Пройтись по всем инсталляциям и выяснить, какое издание где стоит. Если где-то enterprise с истекающей лицензией - это приоритет.

• Резервный план для auth backends. Если используются облачные auth-методы (AWS IAM, GCP, Azure AD) - понять, что происходит, если доступ к облаку пропадёт. Для КИИ это вообще отдельный вопрос с точки зрения требований ФСТЭК.

• Документация unseal-процедуры. Это должно быть и без всяких санкций, но если не сделано - сейчас хороший повод.

Vault 1.11 и что там с PKI

Новый релиз пришёл с улучшениями, которые мы ждали для нескольких клиентов. Кросс-подпись сертификатов при ротации корневого CA - это был давний pain point: при замене корневого сертификата старые сертификаты переставали проверяться, нужна была ручная работа. Теперь PKI Secrets Engine умеет выпускать промежуточный CA, подписанный одновременно старым и новым корнем, что позволяет плавно мигрировать без downtime.

OCSP-поддержка для проверки статуса сертификатов - тоже полезная вещь для тех, кто строит внутренний PKI на Vault вместо внешнего CA.

Обновиться до 1.11 в текущей обстановке мы не стали бы откладывать - патчи безопасности важны, а новые PKI-возможности полезны. Зеркало репозитория - сначала, обновление - потом.

Общий вывод

Ситуация с Vault примерно в той же категории, что и с Ansible: open-source инструмент, где санкционные риски реальны, но управляемы. Не то что с enterprise-SaaS, где одна кнопка вендора закрывает доступ к данным.

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

Если Vault стоит на объектах КИИ или в ГИС - вопрос другой: там нужно смотреть на соответствие требованиям ФСТЭК, а не только на санкционные риски. Реестра отечественного ПО для secrets management практически нет, что само по себе интересная ситуация.

Мы провели такую ревизию у нескольких клиентов в рамках аудита защищённости - картина примерно везде одинаковая: community-издание, никаких enterprise-лицензий, риски управляемые. Рекомендации - зеркало + документация процедур - вопрос пары дней работы, не реархитектуры.