Шлюз доступу SSH для багатьох серверів

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

Я шукаю рішення централізованого управління доступом і таким чином блокувати доступ до будь-якого даного ключа. Не відрізняється від того, як ключі додаються до бітбукета чи github.

Вгорі голови я б припустив, що рішенням буде тунель від однієї машини, шлюзу, до потрібного сервера prod ... під час передачі шлюзу запит підніме новий ключ і використає для отримання доступу до програми сервер. Результатом буде те, що ми зможемо швидко та ефективно знищити доступ для будь-якого девіпа протягом декількох секунд, просто заборонивши доступ до шлюзу.

Це хороша логіка? Хтось бачив рішення вже там, щоб запобігти цій проблемі?

Це занадто складно (перевірити, чи ключ має доступ до певного сервера prod). Використовуйте сервер шлюзу як хост стрибка, який приймає кожен дійсний ключ (але може легко видалити доступ до певного ключа, який видаляє доступ до всіх серверів по черзі), а потім додайте лише дозволені ключі до кожного відповідного сервера. Після цього переконайтесь, що ви можете дістатися до порту SSH кожного сервера лише через хост стрибка.

Це стандартний підхід.

Інженери не повинні працювати у відповідь безпосередньо зі свого ноутбука, якщо це не середовище розробки / тестування.

Натомість мати центральний сервер, який витягує бігові книги з git. Це дозволяє додатково контролювати (чотири очі, перегляд коду).

Поєднайте це з бастіоном або хост-стрибком, щоб надалі обмежити доступ.

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-доступ-до-екземплярів працює-у-виробництві з основним моментом:

Ми розглянемо нашу архітектуру бастіонів SSH, яка в своїй основі використовує SSO для автентифікації інженерів, а потім видає на кожну облікову інформацію користувачів короткотривалі сертифікати для SSH аутентифікації бастіону до екземпляра. Ці короткочасні облікові дані знижують ризик, пов'язаний з їх втратою. Ми розкриємо, як такий підхід дозволяє нам перевіряти та автоматично оповіщати про факт, замість того, щоб сповільнювати інженерів до надання доступу.

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

Деякі цікаві проблеми, навіть якщо ви не реалізуєте ціле рішення:

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

OneIdentity (колишній Balabit) SPS - це саме те, що вам потрібно в цьому сценарії. За допомогою цього пристрою ви можете керувати особами користувачів на будь-яких машинах, відстежувати поведінку користувачів, контролювати та попереджувати, а також індексувати все, що користувачі роблять для подальших оглядів.

Моя пропозиція - заборонити доступ SSH з машин користувача.

Натомість слід

1. Ведучі ігрових книг у Git.
2. Перетворіть "Сервер доступу" на сервер Дженкінса.
3. Грант лише потребував доступу Дженкінса для користувачів, що віддають себе.
4. Виконувати відповіді грає на Jenkins над створенням завдань за допомогою HTTP.
5. Як додатковий захід безпеки, відключіть Jenkins CLI, якщо це необхідно.

Зразок моделі виконання,

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

АБО

2. Класична оболонка -виконати тип роботи. Додайте свої кроки збирання вручну, включаючи git checkout.

Якщо ви обмежені серверними ресурсами, той самий сервер Дженкінса може розміщувати і Git (scm-менеджер), хоча існує додатковий ризик безпеки, якщо інфікований хтось із розробників. Ви можете це пом'якшити, відключивши сервер Дженкінса від Інтернету та вирішивши відповідні залежності на місцевому рівні.