Бастион? Мы говорим об инди-игре?

Не в этот раз! (хоть и хорошая игра!).



В OVHcloud изрядное количество инфраструктур построено на базе Linux. У нас много разных вкусов; таких как Debian, Ubuntu, Red Hat… и этот список можно продолжить. Однажды у нас даже был старый добрый Gentoos! Все они хранятся на голых серверах, на виртуальных машинах и повсюду в контейнерах. Если у него есть ЦП (или виртуальный ЦП), мы, вероятно, загрузили на него какой-то дистрибутив Linux. Но это еще не все. У нас также были коробки Solaris, которые позже превратились в коробки OmniOS, которые теперь превратились в блестящие коробки FreeBSD. У нас также есть много сетевых устройств, разбитых по разным конструкторам, охватывающих широкий диапазон поколений моделей.



Как вы, наверное, догадались, у нас есть разнородные системы, которые предоставляют несколько различных услуг. Но, несмотря на эту неоднородность, знаете ли вы, что у всех них общего? Да, все ping, но есть кое-что поинтереснее: ими можно управлять ssh.

Эта проблема

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

Есть два обычных способа его использования: либо вы просто вводите пароль своей учетной записи, когда удаленный сервер запрашивает его, что более или менее похоже rlogin(без передачи вашего пароля в виде открытого текста по сети); или вы используете аутентификацию с открытым ключом, генерируя так называемую «пару ключей», при этом закрытый ключ находится на вашем столе (или на смарт-карте), а соответствующий открытый ключ находится на удаленном сервере.

Проблема в том, что ни один из этих двух способов не является действительно удовлетворительным в контексте предприятия.

Парольная аутентификация

Во-первых, способ пароля. Что ж, мы все уже знаем, что пароли — отстой. Либо вы выбираете тот, который слишком легко взломать, либо вы выбираете очень сложный, который никогда не вспомните. Это заставляет вас использовать менеджер паролей, защищенный… мастер-паролем. Даже надежные парольные фразы, такие как « Correct Horse Battery Staple », в конечном итоге являются не более чем тщательно продуманным паролем. Они приносят целый ряд проблем, таких как тот факт, что они всегда подвергаются атакам грубой силы, и некоторые пользователи могут пострадать от чумы повторного использования паролей… Как системный администратор, вы никогда не спите спокойно, если знаете, что безопасность вашей системы находится всего в одном пароле. Конечно, есть способы снизить риск, такие как принудительное периодическое обновление пароля, минимальная длина и / или сложность пароля, или отключение учетной записи после нескольких сбоев и т. Д. Но вы просто возлагаете дополнительную нагрузку на своих пользователей и по-прежнему не достигается удовлетворительный уровень безопасности.

Аутентификация с открытым ключом

Во-вторых, способ pubkey. Это долгий путь к устранению проблем с паролями, но затем проблема заключается в масштабируемости. Отправить ваш открытый ключ на домашний сервер легко, но когда у вас есть десятки тысяч серверов / устройств, а также тысячи сотрудников, управляющих некоторым постоянно меняющимся подмножеством указанных серверов / устройств, это быстро усложняется. Действительно, делать это правильно и поддерживать в долгосрочной перспективе в контексте предприятия — настоящая проблема.

Аутентификация на основе PKI

Для полноты — потому что отсюда я слышу вас, гуру SSH! — в последних версиях серверов SSH есть третий способ, а именно аутентификация на основе PKI с доверенным центром сертификации (CA). Вы устанавливаете общедоступный сертификат своего ЦС на все свои серверы, и они будут принимать любое соединение, подтвержденное сертификатом, предоставленным указанным ЦС, полагаясь наsubjectNameсертификата. Это определяет, среди прочего, к какой учетной записи можно получить доступ на сервере. Это очень централизованный способ управления доступом, когда вся власть находится в руках того, кто контролирует ваш ЦС. Это может быть очень успешным, если делать это очень осторожно, с большим количеством процессов безопасности и процессов доставки сертификатов. Правильное управление центром сертификации — не шутка, и неправильное выполнение может сильно вас укусить. Это также было несколько недавним дополнением к OpenSSH, и, учитывая неоднородность, которую мы описали выше, это оставило бы множество систем на стороне. Есть еще одна причина, по которой мы не выбрали этот метод, но прежде чем погрузиться в него, давайте поговорим о наших потребностях.

Что нам нужно

В OVHcloud у нас есть различные технические группы, которые управляют своей собственной инфраструктурой, а не полагаются на общий внутренний ИТ-отдел. Этот принцип является частью корпоративной культуры и ДНК. У него есть свои недостатки; такие как дополнительная сложность в ведении исчерпывающего и актуального инвентаря наших собственных активов, но его преимущества намного перевешивают их: несколько команд могут выполнять итерацию быстрее, поскольку они могут использовать существующие продукты OVHcloud в качестве строительных блоков для создания новых инновационных продуктов. Однако это не должно происходить за счет безопасности, которая лежит в основе всего, что мы делаем в OVHcloud.

Но как нам удалось разработать системы безопасности для управления всеми этими серверами по SSH, не мешая различным рабочим группам?



Требуются несколько важных вещей:

• ДЕЛЕГАЦИЯ
  
  • Любая централизованная «группа безопасности», отвечающая за разрешение доступа для всей компании, недопустима. Он не масштабируется, как бы вы это ни делали.
  • Менеджеры или технические руководители должны быть полностью автономными в управлении своим собственным периметром, с точки зрения серверов / систем / устройств, а также в отношении тех лиц, которым предоставлен доступ в пределах их периметра.
  • Переход члена команды в другую команду или выход из компании должен быть полностью непрерывным, независимо от того, к каким системам у этого человека был доступ (помните о неоднородности выше?).
  • Предоставление доступа новому члену команды также должно быть беспрепятственным, чтобы он мог испачкать руки как можно быстрее.
  • Временное предоставление доступа кому-либо за пределами команды (или компании) к данному активу на ограниченный период времени должно быть простым.
  • Все это должно быть автономным

• АУДИТОРИЯ И ОТСЛЕЖИВАНИЕ
  
  • Каждое действие необходимо регистрировать с большим количеством деталей; будь то изменение зазора или подключение к системе; будь то успех или нет. Мы также хотим, чтобы он был доступен для некоторых SIEM .
  • Каждая терминальная сессия должна быть записана. Ага, вы правильно прочитали. Это та функция, которая вам никогда не понадобится… пока вы этого не сделаете.
  • Создание отчетов для проверки доступа должно быть простым.

• БЕЗОПАСНОСТЬ И УСТОЙЧИВОСТЬ
  
  • Мы должны обеспечить большую безопасность, чем простой прямой доступ по SSH без дополнительных затрат.
  • Любой компонент, который мы должны добавить, чтобы удовлетворить эти потребности, должен быть постоянно в рабочем состоянии, даже (и особенно), когда остальная часть вашей инфраструктуры разваливается, потому что именно тогда вам понадобится SSH.

Так по какой другой причине мы не выбрали путь PKI? Что ж, это ограничило бы автономию руководителей группы: только центр сертификации может доставлять или отзывать сертификаты, но мы хотим, чтобы эта власть находилась в руках руководителей нашей группы. С помощью PKI, если бы мы хотели дать им некоторую власть, нам пришлось бы реализовать сложную логику вокруг CA, чтобы сделать это возможным, и мы не хотели идти по этому пути.

Войдите в бастион!

Чтобы соответствовать нашим сложным требованиям, у нас есть специализированная машина, которая находится между администраторами и инфраструктурой — бастион, задача которого — обрабатывать все важные элементы, указанные выше, в дополнение к разделению этапов аутентификации и авторизации. Мы будем использовать аутентификацию с открытым ключом с обеих сторон. Давайте посмотрим на простой пример рабочего процесса подключения с использованием этого дизайна:

• Администратор хочет подключиться к машине с именем server42
• Он не может использовать SSH напрямую со своего корпоративного ноутбука на server42, потому что server42 защищен брандмауэром и разрешает входящие SSH-соединения только из бастионных кластеров компании
• Вместо этого администратор запускает сеанс SSH с бастионом, используя на нем свою именную учетную запись. Его ноутбук согласовывает сеанс SSH, используя свой закрытый ключ. Это этап аутентификации: бастион гарантирует, что администратор, представляющий себя Джоном Админом, действительно является этим человеком, что возможно благодаря тому, что открытый ключ Джона Админа находится внутри его учетной записи-бастиона. Мы называем это * входящим * подключением.
• После аутентификации Джон Админ просит бастион открыть соединение с учетной записью root на server42.
• Бастион проверяет, разрешен ли Джон Админ доступ к учетной записи root на server42, это часть авторизации. Предположим, для этого примера, что Джон Админ действительно может подключаться к этому серверу, используя закрытый ключ бастиона его команды (подробнее об этом позже).
• Бастион инициирует SSH-соединение с server42 от имени Джона Админа, используя закрытый ключ бастиона своей команды.
• Брандмауэр server42 разрешает входящие SSH-соединения с бастиона, и соединение успешно согласовывается, поскольку открытый ключ бастиона группы администраторов John Admin установлен в учетной записи root server42. Мы называем это * исходящим * соединением.

Теперь у нас есть два установленных SSH-соединения: входящее соединение между администратором Джона и бастионом и выходное соединение между бастионом и server42.

Теперь происходит некоторая магия, и бастион «соединяет» эти два соединения вместе с помощью псевдотерминала (a pty) между ними. Джон Админ теперь считает, что он напрямую подключен к server42 и может взаимодействовать с ним, как если бы это было так.
Между тем, бастион может записывать все, что набирает Джон Админ (или, точнее, все, что * видит * Джон Админ, мы не будем записывать пароли, которые он набирает на noechoтерминалах!), Этим занимается ovh-ttyrecпрограмма.

Чтобы быть совершенно ясным, server42 не знает, кто такой Джон Админ, и ему это не нужно: мы отделили аутентификацию и авторизацию. Только бастиону необходимо знать и аутентифицировать администратора, удаленный сервер знает только бастион и доверяет ему (или, точнее, существование команды Джона Админа на бастионе). Это открывает целый ряд возможностей… но об этом в следующем посте!

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