Vault SSH CA: централизованное управление доступом по сертификатам

Зачем нужен SSH Certificate Authority вместо статичных ключей

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

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

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

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

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

Что даёт централизованная выдача сертификатов доступа

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

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

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

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

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

Способы выдачи SSH-доступа: сравнение вариантов

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

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

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

Порядок внедрения: от аудита ключей до передачи регламентов

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

1. Инвентаризация парка. Собираем список хостов, сервисных учёток и людей, которые ходят по SSH, отмечаем, где осели статические ключи и какие давно не использовались. Без этой карты не понять, какие роли и принципаллы нужны.
2. Проектирование схемы доверия. Определяем роли выдачи, набор принципаллов, срок жизни сертификатов и шаблоны подписи; решаем, что делать с долгоживущими ключами и как устроить аварийный доступ.
3. Настройка выдачи. Разворачиваем Vault как центр сертификации, связываем его с каталогом пользователей, включаем журнал выдачи и проверку подписи на стороне хостов.
4. Пилотная группа. Переводим 5–10 инженеров и дежурную смену, проверяем штатный вход, истечение сертификата и отзыв доступа. Если дежурный не может войти в аварию, схема не готова.
5. Поэтапный перевод парка. Идём сегментами: сначала тестовые и внутренние хосты, затем рабочие сервисы, в последнюю очередь критичные узлы. На каждом этапе видно долю успешных входов и причины отказов.
6. Передача регламентов. Отдаём документацию: как выдать и отозвать сертификат, что делать при компрометации, порядок дежурства и подключения новых сотрудников.

Политики доступа, роли и документация после внедрения

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

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

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

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

Как было

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

Что изменили и что стало

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

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

Что делать, если статические ключи уже развёрнуты в парке серверов?

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

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

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

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

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

Технические сомнения: сроки жизни, отзыв и совместимость

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

Как отозвать доступ, если сотрудник ушёл, а сертификат ещё действует?

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

Как хост убеждается, что предъявленный сертификат подлинный?

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

Что попадёт в журналирование доступа?

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

Можно ли внедрять поэтапно, не останавливая работу?

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

Обсудим задачу: подберём схему доступа под ваш контур

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

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

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