Управление несколькими серверами, более 90 в настоящее время с 3 devops через Ansible. Все работает отлично, однако сейчас есть огромная проблема безопасности. Каждый devop использует свой собственный локальный ключ ssh для получения прямого доступа к серверам. Каждый devop использует ноутбук, и каждый ноутбук потенциально может быть скомпрометирован, тем самым открывая всю сеть prod-серверов для атаки.
Я ищу решение для централизованного управления доступом и, таким образом, блокирования доступа для любого заданного ключа. Не отличается от того, как ключи добавляются в bitbucket или github.
Навскидку я бы предположил, что решением будет туннель от одной машины, шлюза, к желаемому серверу prod... при прохождении шлюза запрос получит новый ключ и будет использовать его для получения доступа к серверу prod. В результате мы сможем быстро и эффективно закрыть доступ для любого devop в течение нескольких секунд, просто запретив доступ к шлюзу.
Это хорошая логика? Кто-нибудь уже видел решение, чтобы обойти эту проблему?
решение1
Это слишком сложно (проверка, имеет ли ключ доступ к определенному серверу prod). Используйте сервер шлюза как jump host, который принимает каждый действительный ключ (но может легко удалить доступ для определенного ключа, который удаляет доступ ко всем серверам по очереди), а затем добавьте только разрешенные ключи на каждый соответствующий сервер. После этого убедитесь, что вы можете получить доступ к порту SSH каждого сервера только через jump host.
Это стандартный подход.
решение2
Инженерам не следует запускать ansible напрямую со своего ноутбука, если только это не среда разработки/тестирования.
Вместо этого используйте центральный сервер, который берет книги задач из git. Это позволяет использовать дополнительные элементы управления (четыре глаза, обзор кода).
Объедините это с бастионом или джамп-хостом, чтобы еще больше ограничить доступ.
решение3
Netflix реализовал вашу настройку и выпустил бесплатное программное обеспечение, чтобы исправить эту ситуацию.
Посмотрите это видеоhttps://www.oreilly.com/learning/how-netflix-gives-all-its-engineers-ssh-accessили эта презентация наhttps://speakerdeck.com/rlewis/how-netflix-gives-all-its-engineers-ssh-access-to-instances-running-in-productionс основным моментом:
Мы рассмотрим нашу архитектуру SSH-бастиона, которая в своей основе использует SSO для аутентификации инженеров, а затем выдает учетные данные для каждого пользователя с краткосрочными сертификатами для SSH-аутентификации бастиона для экземпляра. Эти краткосрочные учетные данные снижают риск, связанный с их потерей. Мы рассмотрим, как этот подход позволяет нам проводить аудит и автоматически оповещать постфактум, вместо того чтобы замедлять работу инженеров перед предоставлением доступа.
Их программное обеспечение доступно здесь:https://github.com/Netflix/bless
Некоторые интересные выводы, даже если вы не реализуете все их решение:
- они используют сертификаты SSH вместо просто ключей; вы можете поместить в сертификат гораздо больше метаданных, тем самым обеспечивая множество ограничений по требованиям, а также упрощая аудит
- использование очень краткосрочных (например, 5 минут) сроков действия сертификатов (сеансы SSH остаются открытыми даже после истечения срока действия сертификата)
- использование 2FA также затрудняет написание скриптов и заставляет разработчиков искать другие решения
- определенный подмодуль, находящийся за пределами их инфраструктуры и должным образом защищенный с помощью механизмов безопасности, предлагаемых облаком, в котором он работает, динамически генерирует сертификаты, так что каждый разработчик может получить доступ к любому хосту
решение4
OneIdentity (бывший Balabit) SPSэто именно то, что вам нужно в этом сценарии. С помощью этого устройства вы можете управлять идентификацией пользователей практически на любых машинах, отслеживать поведение пользователей, контролировать и оповещать, а также индексировать все, что делают пользователи, для последующих проверок.