Настройка Azure Key Vault под ключ: секреты, ключи, сертификаты

Настройка Azure Key Vault: где утекают секреты и ключи

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

Отдельная история — ключи доступа, выданные «временно». Их получают сборочный агент, аналитик для отладки, подрядчик на время проекта. Через месяц никто не помнит, какие из них ещё используются, поэтому ротация не выполняется: страшно отозвать рабочий ключ. Так один бессрочный доступ переживает несколько смен команды.

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

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

Что даёт управляемое хранение секретов и ключей

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

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

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

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

Варианты подключения приложений к хранилищу секретов

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

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

Порядок внедрения: от аудита секретов до передачи

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

1. Аудит секретов. Инвентаризируем хранилища паролей в репозиториях, переменные конвейеров, конфигурации приложений и файлы на серверах. Для каждой записи фиксируем владельца, критичность, срок жизни и дубликаты — без этого ротация и удаление невозможны.
2. Схема разграничения доступа. Разводим хранилища по средам, выдаём роли на конкретные секреты вместо прав на весь контур. Рабочие нагрузки читают значения через управляемые удостоверения, сервисные учётные записи с долгоживущими ключами выводим из оборота, публичный доступ закрываем.
3. Миграция секретов. Переносим поэтапно, с версионированием и сверкой значений с эталоном. Приложения и конвейеры переключаем на чтение из хранилища, старые копии помечаем к удалению и снимаем после контрольного периода.
4. Настройка ротации. Задаём срок жизни и расписание смены паролей и ключей, автоматизируем обновление и уведомления владельцу. Отдельно проверяем, что сервис подхватывает новую версию без перезапуска и ручного вмешательства.
5. Проверка отказов. Прогоняем сценарии: недоступность хранилища, отозванный доступ, забытый секрет, ошибочное удаление. Включаем защиту от безвозвратной потери и восстановление из резервной копии.
6. Приёмка и передача. Проверяем права из каждой среды по контрольным сценариям, отдаём карту хранилищ, матрицу ролей, регламент ротации и порядок восстановления. Дежурная команда получает инструкции и разбор типовых инцидентов.

Политики доступа, роли и схемы хранения ключей

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

• Роли и права доступа. Матрица «кто и что может»: администратор хранилища, ответственный за секреты, сервисный потребитель только на чтение. Права минимально необходимые, отдельный субъект на каждого, без общих учётных записей.
• Разделение сред. Разработка, предпродакшн и продакшн живут в отдельных хранилищах со своими правами: утечка тестовых значений не открывает доступ к рабочим.
• Политики хранилища. Мягкое удаление и защита от очистки, сетевые ограничения, журналирование обращений к секретам с выгрузкой в общий мониторинг.
• Регламент ротации секретов. По каждому классу: срок жизни, владелец, порядок выпуска новой версии и откат на предыдущую без остановки сервиса.
• Ротация сертификатов. Схема автопродления, календарь уведомлений заранее до истечения и ответственный за ручной выпуск, если автопродление недоступно.
• Документация по секретам. Карта хранилища: имя, назначение, владелец, потребитель, срок ротации, порядок восстановления.
• Выдача и отзыв доступа. Как запрашивается доступ и что снимается при уходе сотрудника или выводе сервиса из эксплуатации.

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

Кейс: как секреты переехали из конфигураций в хранилище

Заказчик — продуктовая команда с тремя средами и 30+ сервисами: строки подключения к базам, ключи внешних API и сертификаты лежали в переменных окружения и манифестах репозитория. Ротация одного ключа означала ручной обход сервисов, а уход человека с доступами запускал смену секретов во всём контуре. Один забытый манифест — и прод отдавал отказ авторизации при полностью живых экземплярах приложения.

Что изменили

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

Показатели до и после

Миграцию прошли 34 сервиса. Отказы из-за просроченных сертификатов и разъехавшихся ключей — 3-4 в квартал — ушли: продление идёт без участия человека. Ротация ключа занимает одну операцию вместо планового окна с обходом команд, а восстановление доступа после смены сотрудника — минуты вместо часов. Сканер секретов перестал находить значения в репозиториях, а журнал обращений к хранилищу показал реальные связи сервисов: видно, кто и что читает, и лишние права снимаются по факту, а не по памяти.

Чем хранилище секретов отличается от переменных окружения

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

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

Управляемое хранилище разделяет доступ и значение: приложение получает секрет по своему удостоверению, права выдаются ролью, а версии ключей и сертификатов меняются отдельно от релиза. В Azure Key Vault это подтверждает журнал обращений — видно, кто и когда читал секрет.

Выбор способа хранения сводится к трём вопросам: что будет, если значение попадёт в лог, кто и насколько быстро сможет его сменить, как отозвать доступ у ушедшего сотрудника. Если хотя бы на один ответ «никак» — место такого значения в хранилище.

Частые вопросы об интеграции хранилища с сервисами

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

Как подключаются сервисы вне облака?

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

Как проходит ротация без простоя?

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

Что с доступом после передачи проекта?

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

Обсудим задачу и вернёмся с оценкой и планом работ

Чтобы вернуться с оценкой работ и планом внедрения, нам нужен не полный пакет документации, а срез по нескольким пунктам. С этим набором исходных данных мы за один проход определяем объём работ, схему разделения хранилищ в Azure Key Vault и порядок переноса — без уточняющих кругов и переписки на две недели.

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

Описывайте картину как есть, даже если сейчас ключи передают в переписке: чем точнее исходные данные, тем меньше допущений в оценке. В ответ пришлём план этапов, состав работ, распределение ответственности и точку старта.