SSH Key Management для команды: Ansible, Vault, ротация

Почему управление SSH ключами ломается при росте команды

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. Пилотный контур. Меняем схему на одной группе серверов и смотрим, как она живёт в ежедневной работе: кто не смог зайти, каким сервисам не хватило прав, как проходит плановый отзыв.

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

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

Шаблоны ролей, политик доступа и регламентов ротации

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

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

Кейс: окно доступа сократилось с недель до минут

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

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

Метрики до и после

Подключение нового инженера сократилось с 3–5 рабочих дней до 15–20 минут вместе с проверкой прав. Закрытие доступа после ухода — с нескольких недель до одной команды: ключ отзывается из реестра и перестаёт работать на всех узлах сразу. Число копий ключей на человека упало с 6–8 до одной.

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

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

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

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

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

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

Технические сомнения: совместимость, откат и аудит

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

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

Что происходит при сбое и как выглядит откат?

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

Как подтверждается, что доступ действительно отозван?

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

Как разделяется доступ подрядчиков?

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

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

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

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

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

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