Это вторая часть серии блогов, вот и первая. Ранее мы обнаружили, что бастион не является вашим обычным хостом перехода SSH (на самом деле, мы обнаружили, что это вообще не хост прыжка), и мы обсудили, как делегирование было одной из основных функций, которые нам изначально нужны. Итак, давайте погрузимся в эти концепции. На бастионе есть две совместимые модели доступа: персональный и групповой.

Личный доступ — кусок торта

На бастионе каждая учетная запись имеет (как минимум) один набор личных выходных ключей . Эти звери генерируются при первом создании учетной записи. Личный выходной закрытый ключ находится в домашней учетной записи бастиона. У пользователя учетной записи нет возможности увидеть его или экспортировать из бастиона, но он может использовать его через логику кода бастиона. Пользователь может получить соответствующий открытый ключ в любое время и установить его — или получить его — на удаленных серверах, к которым он должен получить доступ. В зависимости от вашего варианта использования и уровня автономии, который вы хотите предоставить командам, есть два способа управления этим личным доступом.

Угощайтесь

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

Спросите ИТ-специалистов

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

Групповой доступ — Let's Rock

Группа состоит из трех компонентов:

• Список участников (аккаунты, представляющие отдельных людей)
• По крайней мере, один набор групповых выходных ключей
• Список серверов (фактически IP)

Список серверов

Список серверов на самом деле представляет собой список IP-адресов или IP-блоков. Они сопоставляются с вашими серверами, сетевыми устройствами или чем-либо еще с поддержкой SSH, у которого есть IP (на котором был установлен ключ исходящей группы). Технически этот список фактически состоит из трех элементов: удаленный пользователь , удаленный IP (или блок IP), удаленный порт . То, что применяется к персональному доступу, также применимо и здесь: добавление сервера в список не дает волшебным образом доступа к нему, сначала необходимо установить открытый ключ исходящей группы. Конечно, управление установкой этих ключей вручную быстро становится непрактичным, но вы можете рассмотреть эту часть конфигурации серверов, поэтому ими следует управлять с помощью той централизованной системы конфигурации, которую вы уже используете (Puppet, Chef, Ansible, / bin / cp… подожди, нет, ударил последний ).

Список участников

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

У вас новый член команды? Просто добавьте их в свою группу, и они мгновенно получат доступ ко всем серверам группы. Кто-нибудь уходит из компании? Просто удалите там аккаунт на бастионе, и все доступы мгновенно пропадут. Это так, потому что все ваши серверы должны иметь входящие сеансы SSH, ограниченные вашими бастионами. Таким образом, любой мошеннический ключ SSH, который был бы добавлен, больше не используется.

И еще немного

Мы рассмотрели основы группового подхода, но, поскольку нам нужна большая гибкость и делегирование, есть еще кое-что. Помните, я сказал, что в группе 3 компонента? Я соврал. В группе больше, чем просто участники. Дополнительные групповые роли включают:

• Гости
• Привратники
• Aclkeepers
• Владельцы

Все это списки учетных записей, играющих определенную роль в группе.

Во-первых, гости . Они немного похожи на участников , но с меньшими привилегиями: они могут подключаться к удаленным машинам с помощью ключа группы, но не ко всем машинам группы, а только к подмножеству. Это полезно, когда кому-то за пределами группы нужен конкретный доступ к определенному серверу, потенциально на ограниченный период времени (поскольку для таких доступов может быть установлен срок действия).

Затем привратники . Эти ребята ведут список участников и гостей группы. Другими словами, они имеют право давать право доступа . Здесь нет ничего сложного. Затем есть помощники . Как вы уже догадались, они управляют списком серверов, входящих в группу. Если у вас есть автоматизация управления предоставлением серверов вашей инфраструктуры, эта роль может быть предоставлена ​​учетной записи робота, единственной целью которой будет обновление списка серверов на бастионе полностью интегрированным способом с вашей подготовкой. Вы даже можете пометить такие учетные записи, чтобы они никогда не смогли использовать SSH через бастион, даже если кто-то предоставит их по ошибке!

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

Глобальные роли — Приходите получить

Помимо только что описанных ролей, которые относятся к группе, существуют две дополнительные роли, охватывающие весь бастион: «супервладелец» и «администратор бастиона».

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

Головокружение еще не закончилось? Теперь о самой влиятельной роли: админке бастиона . Эта роль должна быть предоставлена ​​только нескольким лицам, поскольку они могут выдавать себя за кого угодно (даже если, конечно, когда они это делают, это регистрируется и заставляет наш SIEM покраснеть), и на практике не следует отдавать никому, кто еще не получил root-права в самой операционной системе бастиона. Помимо прочего, они управляют конфигурацией бастиона, где объявлены супервладельцы. Задержи дыхание. Готов? Им разрешено давать право давать право давать право давать право доступа. Вот почему делегирование лежит в основе системы: у каждого есть свой набор обязанностей и возможные действия, без необходимости спрашивать администратора бастиона.

Подведение итогов

Все концепции управления доступом, о которых мы говорили, сопоставлены с реальными командами. Их можно запустить на бастионе после аутентификации пользователя (известное входящее соединение). На бастионном жаргоне они называются командами osh. В этом случае нет исходящих соединений, так как эти команды взаимодействуют с самим бастионом:



Как вы могли заметить на скриншоте выше, версия программного обеспечения Bastion очень близка к 3.00.00 ! Может быть, приближается интересная веха?

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