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

SSH CA: чем опасны разросшиеся статические ключи

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

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

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

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

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

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

Единая выдача доступов переносит решение на один центр сертификации. Инженер подтверждает личность (второй фактор, корпоративный вход), получает короткоживущий сертификат доступа и работает по нему; хост проверяет подпись центра и указанные в сертификате принципал и разрешения, а не содержимое файла ключа. Совместимость с OpenSSH при этом сохраняется — меняется источник доверия, а не клиент.

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

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

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

Форматы доступа: SSH CA против статических ключей

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

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

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

Внедрение по шагам: от аудита ключей до передачи

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

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

Артефакты на выходе: конфигурации, схемы и регламенты

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

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

Через полгода новый инженер выдаёт доступ, отзывает его и поднимает центр заново по этим материалам — без поисков автора настройки.

Кейс: отзыв доступа за минуты вместо нескольких дней

В одном проекте доступ к 40+ серверам выдавали копированием публичных ключей по инвентарю. Увольнение инженера превращалось в обход всех хостов и чистку authorized_keys: полный отзыв занимал 2–4 дня, и всё это время доступ оставался рабочим. Общий ключ на команду добивал картину — по логам нельзя было понять, кто именно подключился.

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

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

Что делать, если парк уже работает на статических ключах?

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

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

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

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

Частые технические возражения и ответы инженеров

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

Что будет, если узел выдачи недоступен?

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

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

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

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

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

На обсуждении разберём:

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

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