Комментарий пользователя
У нас около 200 серверов и человек 15 с доступом по SSH. Две недели назад ушел админ, я пошел удалять его ключ и понял, что не знаю, на скольких машинах он вообще лежит. Прогнал ad-hoc grep по authorized_keys через Ansible, нашел на 40 хостах, вычистил. Но уверенности, что нашел везде, у меня нет. Как выстроить это так, чтобы отзыв доступа был одним действием?
Ответ специалиста
Здравствуйте, Денис!
К сожалению, уверенности быть не может, пока сами ключи лежат на серверах. Это архитектурное свойство authorized_keys: файл хранится локально на каждом хосте, у ключей по умолчанию нет срока действия, и «отозвать доступ» физически означает вычистить строку на всех машинах. Один пропущенный сервер означает, что вход остается рабочим. Однако масштаб проблемы обычно недооценивают: по разным оценкам, в крупных инфраструктурах до 90% ключей никто не использует и не администрирует, причем часть из них дает доступ на уровне root.
Из комментария видно и вторую половину проблемы: серверы, поднятые руками и не попавшие в инвентарь. Пока источник правды о доступах — файлы на хостах, любой пробел в инвентаре автоматически становится пробелом в безопасности. Решение здесь всегда одно и то же: убрать хранение ключей с серверов.
Первый и самый простой шаг — указание параметра AuthorizedKeysCommand в sshd_config. Он задает команду, которая динамически возвращает список разрешенных ключей вместо чтения статического файла. Источником обычно служит база данных или LDAP-каталог. После этого отзыв доступа становится ровно одним действием: заблокировали запись в центральном хранилище и ключ перестал работать на всех узлах сразу, включая те, о которых вы забыли. Ту же задачу решает LDAP как таковой: ключи, пароли и учетные записи живут в едином каталоге, изменения сразу видны всем SSH-серверам.
Второй шаг — короткоживущие сертификаты, которые позволят закрыть тему окончательно. В модели SSH CA сервер доверяет не списку конкретных ключей, а подписи центра сертификации: в sshd_config прописывается TrustedUserCAKeys /etc/ssh/ca_user.pub, а пользовательские ключи подписываются на CA с ограниченным сроком действия (флаг -V у ssh-keygen). На практике сертификаты выдают на срок от нескольких часов до суток. Тогда неактивная учетная запись закрывается сама: человек просто перестает получать новые сертификаты, делать для этого ничего не нужно. Если сертификат нужно отозвать досрочно, есть списки отозванных ключей:
ssh-keygen -k -f /etc/ssh/ca_revoked_keys # создать KRL
ssh-keygen -k -u -f /etc/ssh/ca_revoked_keys compromised-cert.pub # добавить сертификат
Спикеры
Готовый вариант того же подхода — решения класса PAM и Zero Trust Access: Teleport, Boundary, Delinea, CyberArk. Они выдают сессионный сертификат после аутентификации через SSO и ведут журнал сеансов, но требуют серьезной интеграции с инфраструктурой.
Что мы я рекомендовал сделать в вашей ситуации по порядку.
- Пройтись по
authorized_keysна всех хостах и сопоставить каждый ключ с действующим сотрудником. На этом шаге обычно и находятся забытые root-доступы. - Удалить ключи без владельца и ввести правило, что ключ без ответственного удаляется автоматически.
- Перенести список ключей во внешний источник и запретить ручное добавление строк в файлы на серверах: без этого запрета все вернется через месяц.
- Если понадобится, надстроить CA.
Важная оговорка, если пойдете в сертификаты
Центр сертификации нужно защищать серьезнее, чем любой отдельный ключ. Компрометация CA позволяет выпускать сертификаты от имени любого пользователя. Базовый минимум защиты здесь — приватный ключ на изолированной машине, подписание только после аутентификации, журналирование всех операций, разделение ролей, автоматическая ротация ключей CA и бэкапы.
Подробнее об управлении ключами SSH — в отдельной статье. В ней мы рассмотрели важные нюансы организации работы с ключами в команде или при большом парке.
