Комментарий пользователя
Начитался про SSH CA — выглядит красиво, но у нас 12 серверов и три администратора. Не будет ли это стрельбой из пушки по воробьям? Хочется понять, есть ли какой-то внятный порог, после которого переходить обязательно, или это вкусовщина. И если переходить, то что реально придется поменять в работе команды?
Ответ специалиста
Здравствуйте, Павел!
Речь не совсем о вкусовщине, выбор здесь определяется масштабом. Если вкратце, то на ваших цифрах я бы пока не переходил.
authorized_keys — базовый механизм OpenSSH: публичный ключ лежит строкой в файле на целевом сервере, sshd сверяет с ним подключение. Он остается актуальным, и для небольшого парка серверов и малого числа пользователей это простая и понятная схема, так как ничего не надо разворачивать, все видно глазами, работает из коробки. 12 хостов и три сотрудника — ровно такой случай.
Слабость указанного механизма в децентрализации, но проявляется она лишь с ростом. Ключи хранятся локально на каждом узле и не имеют встроенного срока действия, поэтому доступ остается открытым до ручного удаления. Обновление или отзыв прав превращается в многошаговый процесс, так как приходится править authorized_keys на всех серверах. При таких объемах рутины человеческий фактор неизбежен — опечатки, дублирование записей, забытые при увольнениях доступы. В итоге накапливаются неучтенные ключи, часть из которых дает права root. Обратите внимание: затраты на сопровождение растут непропорционально числу систем, то есть быстрее, чем сама инфраструктура.
SSH CA «переворачивает» модель и сервер начинает доверять подписи центра сертификации вместо перечня ключей. Сертификат — это публичный ключ, подписанный приватным ключом CA и снабженный метаданными (списком разрешенных логинов и сроком действия). Отсюда два главных плюса — централизованный контроль и встроенное истечение срока, которое автоматически делает ключ временным. Администрирование сводится к выпуску и отзыву сертификатов, разносить ключи по серверам больше не нужно, а надежная криптография позволяет полностью отказаться от паролей.
Цена — отдельная инфраструктура CA, которую надо развернуть и защищать: ее компрометация позволит выпускать поддельные сертификаты от имени любого пользователя. И второе, что часто недооценивают: команду придется обучить. Каждый сотрудник должен уметь сам получать и отзывать свои доступы. Этот момент вносит изменения в ежедневную работу сильнее, чем сама настройка.
Насчет порога. Формальной цифры нет, но можно выделить три практических признака, что пора:
- вы не можете «за пять минут» ответить, у кого прямо сейчас есть доступ к продовому серверу;
- при уходе сотрудника заводится отдельная задача формата «почистить ключи»;
- ключи выдаются копипастом в мессенджере, а не через какой-то процесс.
Если совпало хотя бы два — посчитайте, сколько часов за квартал уходит на выдачу, аудит и отзыв ключей, а затем сравните с внедрением CA.
И практический совет, чтобы не выбирать одно из двух сразу: между этими вариантами есть промежуточный шаг. Вынесите источник ключей за пределы серверов через AuthorizedKeysCommand или LDAP и оставьте authorized_keys как транспорт. Это не потребует переобучения всей команды, но уже закроет главную проблему — невозможность отозвать доступ одним действием. А CA поверх этого вы сможете надстроить позже и без спешки.
Подробнее об управлении ключами SSH — в отдельной статье. В ней мы рассмотрели важные нюансы организации работы с ключами в команде или при большом парке.
