В моей компании мы используем LDAP для создания согласованного набора учетных записей на всех компьютерах, а затем используем инструмент управления конфигурацией (в нашем случае в настоящее время cfengine) для распределения authorized_keysфайлов для каждого пользователя по всем серверам. Сами файлы ключей хранятся (вместе с другой информацией о конфигурации системы) в репозитории git, чтобы мы могли видеть, когда ключи приходят и уходят. cfengine также распространяет sudoersфайл, который контролирует, кто имеет доступ для запуска от имени пользователя root на каждом хосте, используя пользователей и группы из каталога LDAP.
На наших производственных серверах аутентификация по паролю полностью отключена, поэтому аутентификация по SSH-ключу обязательна. Политика поощряет использование отдельного ключа для каждого ноутбука / настольного компьютера / любого другого устройства и использование ключевой фразы для всех ключей, чтобы уменьшить влияние потерянного / украденного ноутбука.
У нас также есть бастионный хост, который используется для доступа к хостам в производственной сети, что позволяет нам иметь очень строгие правила брандмауэра в этой сети. У большинства инженеров есть специальная конфигурация SSH, чтобы сделать это прозрачным:
Host prod-*.example.com
User jsmith
ForwardAgent yes
ProxyCommand ssh -q bastion.example.com "nc %h %p"
Добавление нового ключа или удаление старого требует некоторой церемонии в этой настройке. Я бы сказал, что для добавления нового ключа желательно, чтобы он был операцией, которая оставляет контрольный журнал и видна всем. Однако из-за накладных расходов я думаю, что люди иногда забывают удалить старый ключ, когда он больше не нужен, и у нас нет реального способа отследить это, кроме как очистить, когда сотрудник уходит из компании. Это также создает некоторые дополнительные трения при подключении нового инженера, поскольку им необходимо сгенерировать новый ключ и распространить его среди всех хостов, прежде чем они станут полностью продуктивными.
Однако самым большим преимуществом является наличие отдельного имени пользователя для каждого пользователя, что позволяет легко выполнять более детальный контроль доступа, когда нам это необходимо, и дает каждому пользователю удостоверение личности, которое отображается в журналах аудита, что может быть очень полезно при попытке отследить Производственная проблема возвращается к действию системного администратора.
При такой настройке утомительно иметь автоматизированные системы, которые принимают меры против рабочих хостов, поскольку их «хорошо известные» ключи SSH могут служить альтернативным путем доступа. До сих пор мы только что предоставили учетным записям пользователей этих автоматизированных систем только минимальный доступ, который им необходим для выполнения своей работы, и признали, что злонамеренный пользователь (который должен быть уже инженером с производственным доступом) также может выполнять те же самые действия на полпути. анонимно используя ключ приложения.