Назад | Перейти на главную страницу

Шлюз доступа SSH для многих серверов

Управление несколькими серверами, более 90 в настоящее время с 3 DevOps через Ansible. Все работает отлично, однако сейчас существует огромная проблема безопасности. Каждый devop использует свой собственный локальный ключ ssh для получения доступа непосредственно к серверам. Каждый devop использует портативный компьютер, и каждый портативный компьютер потенциально может быть взломан, что откроет всю сеть prod-серверов для атаки.

Я ищу решение для централизованного управления доступом и, таким образом, блокирования доступа для любого заданного ключа. Не отличается от того, как ключи добавляются в битбакет или гитхаб.

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

Это хорошая логика? Кто-нибудь уже видел решение этой проблемы?

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

Это стандартный подход.

Инженерам не следует запускать ansible напрямую со своего ноутбука, если это не среда разработки / тестирования.

Вместо этого используйте центральный сервер, который извлекает модули Runbook из git. Это позволяет использовать дополнительные элементы управления (четыре глаза, проверка кода).

Совместите это с бастионом или прыгуном, чтобы еще больше ограничить доступ.

OneIdentity (ex-Balabit) SPS это именно то, что вам нужно в этом сценарии. С помощью этого устройства вы можете управлять идентификаторами пользователей практически на любых машинах, отслеживать поведение пользователей, отслеживать и предупреждать, а также индексировать все, что делают пользователи, для последующих проверок.

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, которая в своей основе использует систему единого входа для аутентификации инженеров, а затем выдает учетные данные пользователя с краткосрочными сертификатами для аутентификации SSH бастиона для экземпляра. Эти недолговечные учетные данные снижают связанный с ними риск потери. Мы расскажем, как этот подход позволяет нам проводить аудит и автоматически предупреждать постфактум, вместо того, чтобы замедлять работу инженеров перед предоставлением доступа.

Их программное обеспечение доступно здесь: https://github.com/Netflix/bless

Некоторые интересные выводы, даже если вы не реализуете их решение полностью:

  • они используют сертификаты SSH вместо ключей; вы можете поместить в сертификат гораздо больше метаданных, что позволит установить множество ограничений на требования, а также упростить аудит.
  • использование очень краткосрочного (например, 5 минут) срока действия сертификатов (сеансы SSH остаются открытыми даже после истечения срока действия сертификата)
  • использование 2FA, чтобы также усложнить создание сценариев и вынудить разработчиков искать другие решения
  • определенный подмодуль, находящийся за пределами их инфраструктуры и должным образом защищенный с помощью механизмов безопасности, предлагаемых облаком, в котором он работает, обрабатывает создание сертификатов динамически, так что каждый разработчик может получить доступ к любому хосту

Мое предложение - запретить доступ по SSH с пользовательских машин.

Вместо этого вам следует

  1. Размещайте playbooks в Git.
  2. Превратите «Сервер доступа» в сервер Jenkins.
  3. Гранту нужен был доступ Jenkins только к пользователям DevOps.
  4. Execute Ansible играет с Jenkins поверх заданий сборки через HTTP.
  5. В качестве дополнительной меры безопасности при необходимости отключите Jenkins CLI.

Образец модели исполнения,

  1. Плагин Jenkins Ansible: https://wiki.jenkins.io/display/JENKINS/Ansible+Plugin

ИЛИ

  1. Классическая оболочка -выполняет тип задания. Добавьте шаги сборки вручную, включая git checkout.

Если вы ограничены в ресурсах сервера, тот же сервер Jenkins может также размещать Git (scm-manager), хотя есть дополнительная угроза безопасности, если одна из машин разработчика заражена. Вы можете смягчить это, отключив сервер Jenkins от Интернета и разрешив зависимости Ansible локально.