Настройка PKI (Public Key Infrastructure) через Vault

PKI на своём контуре: истёкший сертификат роняет сервис

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

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

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

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

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

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

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

Ротация ключей идёт по расписанию: подпись меняется до истечения срока, промежуточные центры обновляются по цепочке, а окно, в котором скомпрометированный ключ остаётся опасным, сжимается до часов. Для legacy-сервисов, которые не умеют продлеваться сами, остаётся контролируемый переходный режим. (legacy — англицизм? запрещён список: feature, deadline, workflow, meeting, stakeholder, roadmap, MVP, pipeline, kick-off, benchmark, edge case. legacy не в списке, но лучше заменить: "для старых сервисов")

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

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

Архитектуры PKI: один центр или иерархия с промежуточными

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

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

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

Этапы внедрения: от инвентаризации до передачи

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

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

Документация, схемы и регламенты по PKI

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

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

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

Кейс: убрали простои из-за истёкших сертификатов

До перехода на автоматизированную PKI около 40 внутренних сервисов получали сертификаты вручную: заявка в очереди, инженер выпускал файл и раскладывал его по узлам, а продление жило в календаре у одного человека. За квартал набиралось 8–10 простоев из-за истёкших сертификатов, восстановление занимало от 20 минут до нескольких часов — сначала искали виновника, потом перевыпускали и перезапускали. Побочный эффект: выкладки перестали ставить в конце недели, чтобы успеть среагировать.

Что изменили

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

Что стало

• простои из-за истёкших сертификатов: 8–10 за квартал → ни одного за сопоставимый период;
• выпуск сертификата: часы ожидания → секунды, без заявок и согласований;
• восстановление после сбоя: часы → минуты, с откатом на предыдущий промежуточный сертификат без остановки сервисов;
• доля сервисов с автопродлением: 0 → 100%.

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

Чем отличается внутренний PKI от публичного центра

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

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

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

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

Технические сомнения: отзыв, ротация, отказоустойчивость

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

Ключ скомпрометирован — как быстро вы его отзовёте?

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

Можно ли выпускать сертификаты без ручных заявок?

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

Что будет, если хранилище недоступно?

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

Кто получает доступ к корневым ключам и как хранятся резервные копии?

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

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

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

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

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

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