Каковы лучшие практики управления ключами SSH в команде?

В моей компании мы используем 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 могут служить альтернативным путем доступа. До сих пор мы только что предоставили учетным записям пользователей этих автоматизированных систем только минимальный доступ, необходимый им для выполнения своей работы, и согласились с тем, что злоумышленник (который уже должен быть инженером с производственным доступом) также может выполнять те же действия частично. анонимно с помощью ключа приложения.

Лично мне нравится идея о том, что у каждого сотрудника есть один ключ на выделенной машине-бастионе ssh, на которой у них есть базовая учетная запись. Эта учетная запись пользователя имеет 1 ключ ssh, который предоставляет доступ ко всем серверам, которые им нужны. (эти другие серверы также должны быть отключены брандмауэром, чтобы был разрешен только ssh-доступ с машины-бастиона)

Затем на своих повседневных рабочих машинах, ноутбуках, планшетах и ​​т. Д. Они могут выбирать между одной клавишей или несколькими клавишами.

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

У меня была ситуация, когда мне нужно было предоставить доступ по SSH-ключу команде из 40 разработчиков к ~ 120 удаленным серверам клиентов.

Я контролировал доступ, заставляя разработчиков подключаться через единственный «узел перехода». На этом хосте я сгенерировал закрытые / открытые ключи и отправил их на серверы клиентов. Если разработчикам требовался доступ с ноутбука, они могли использовать ту же пару ключей в своей локальной системе.

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

Один из подходов, о котором я слышал, но не использовал сам, заключается в том, чтобы у каждого пользователя был пакет (например, .deb, .rpm), содержащий его конфигурацию открытого ключа ssh, а также любые точечные файлы, которые они хотели бы настроить (.bashrc , .profile, .vimrc и т. д.). Он подписывается и хранится в репозитории компании. Этот пакет также может отвечать за создание учетной записи пользователя, или он может дополнять что-то еще, создавая учетную запись (cfengine / puppet и т. Д.), Или центральную систему аутентификации, такую ​​как LDAP.

Затем эти пакеты устанавливаются на хосты с помощью любого механизма, который вы предпочитаете (cfengine / puppet и т. Д., Cron job). Один из подходов - иметь метапакет, который зависит от пакетов для каждого пользователя.

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

Если у вас разнородные системы и вам нужно поддерживать файлы .rpm и .deb, я вижу, что это немного раздражает, хотя такие инструменты, как alien, могут сделать это несколько проще.

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

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

Если у вас есть общие ключи между пользователями - даже если вы небольшая группа - отзыв ключа доставит неудобства всем остальным.

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

Несколько лет назад Envy Labs написала инструмент под названием Keymaster (в партнерстве с клиентским Gatekeeper), чтобы сделать что-то подобное для команд разработчиков.

Последние два года проект не пользовался особой любовью, но, вероятно, с ним можно было бы поработать и, возможно, вернуть к жизни?

Репо доступно в github: https://github.com/envylabs/keymaster

Подход может заключаться в настройке сервера NIS с общим доступом / home через NFS. Это в сочетании с sudo на серверах и позволяет только пользователям, которых вы хотите, на каждый сервер через конфигурацию ssh.

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

С Уважением,

Рафаэль