Внутри IT индустрии, и, особенно, большого (относительно) нового мира облачных сервисов, можно сказать, что безопасность не на первом месте у всех разработчиков или консультантов по облачным технологиям. Каждая команда участвующая в процессе разработки облачных сервисов имеет задачи в своем поле деятельности, а безопасность зачастую остается на задних сидениях поезда облачных технологий. Пока Zero Trust Network Architecture (ZTNA — Сетевая архитектура нулевого доверия) становится все более популярным, и принимаемым как один из наиболее безопасных принципов, которых стоит придерживаться, нам необходимо определить и использовать технологии, что позволяют обеспечить мощный центральный механизм политик и соответствующее их исполнение, в то же время обеспечивая возможность автоматизации и внедрения в более масштабные процессы, текущую работу и проекты для гибкости и масштабируемости в долгосрочной перспективе.

Техническое задание

Одна из главных задач, возникающих при работе с публичным облаком, это как обеспечить административный доступ к ресурсам (таким, как внутренние базы данных), в то же время сохраняя разделение между уровнями приложений без использования хоста-бастиона или VPN-архитектуры. С точки зрения администратора облака, трудно сбалансировать безопасный доступ к ресурсам, так чтобы политики Security Group, IAM или Resource-Based не разрешали слишком многого, жонглировать раскрытием критических ресурсов в сеть и выдавать правильные данные записей и уровни доступа администраторам инфраструктуры. В идеальном мире, было бы замечательно иметь систему производства где никто бы не имел прямого доступа к базовым системам или составляющим их базам данных.

Как мы можем придерживаться руководства CNCF (Cloud Native Computing Foundation) и поддерживать эту практику на всем пути разработки? На самом деле, нам приходится применять практики, которые соответствуют текущей необходимости и адаптировать их для работы в нашей конкретной среде и вариантах использования, чтобы в итоге удовлетворить потребности нашего бизнеса.

Это может быть настоящим испытанием. К счастью, мы можем взглянуть на более широкую экосистему внедрения CNFC, где существуют инструменты, что помогут облегчить эту сложность.

Коротко: Зачем вам HashiCorp Boundary?

1. Я технарь, что Boundary будет для меня делать?

• Boundary существует с полностью открытым исходным кодом и предоставляет доступ механизмам безопасности к хостам и критически важным системам через различных поставщиков раздельно, без необходимости в настройке индивидуальных учетных данных для соответствующих систем, так как он интегрирован с поставщиками идентификаторов и устраняет необходимость раскрытия вашей инфраструктуры.
• Boundary фокусируется на масштабируемости, как на ключевой части системы, которая применяется как к масштабированию организаций через использование различных организаций, объемов и методов аутентификации, так и к масштабированию RPS, предоставляющего разделение между масштабами организаций и доступом к ресурсам, используя облачную инфраструктуру для того, чтобы при необходимости способствовать необходимому росту.
• Легко внедряется в рабочий процесс через API для быстрого изменения и динамичного окружения.
• Создает безопасное окружение администрирования, что работает на принцип Zero Trust Network Architecture, ведь каждое административное соединение отслеживается и аутентифицируется.
• Boundary построен на опыте HashiCorp Vault, с точки зрения лучших практик безопасности.

2. Я топ-менеджер или владелец, как это поможет моему бизнесу?

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

Что же такое Boundary более развернуто?

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

Boundary это проект с открытым исходным кодом для детального управления доступом клиент-сервер. Вкратце, он позволяет пользователям, аутентифицированным локально или через поставщика идентификаторов (вроде Google, Okta, Azure AD и т.д.), получать авторизованный доступ к определенным системам безопасности (которые определены в boundary) внутри частных сетей, без предоставления доступа к системам напрямую или открытия более крупной сети где эти системы находятся — вспомним Application Proxy — вместе с любыми другими системами внутри той же сети, где некоторые администраторы не должны иметь прав. Все это обеспечивается централизованно с возможностью конфигурации, конечно же, для большей доступности, а доступ предоставляется через балансировщик нагрузки Cloud Native. В зависимости от конфигурации и реализации, Boundary может работать с доступом к IAM от разработки до выпуска инфраструктуры.

Boundary определенно представляет собой необходимый инструмент для добавления в инструментарий разработчика или менеджера безопасности. Это компонент более широкой стратегии облачной безопасности с потенциалом для других вариантов использования в будущем. Будучи предложением от HashiCorp, он имеет возможность легкого внедрения в рабочий процесс, то есть облегчает деплой в архитектуре Infrastructure as Code с Terraform внутри большинства публичных облачных платформ. Необходимый код уже находится на GitHub и готов к использованию. Boundary также API-управляемая система, предоставляющая CLI, Go SDK и десктопное приложение для простоты использования.

Основные особенности и преимущества

• Доступ на основе идентификаторов
• Мониторинг и управление сеансом
• Безопасный доступ к динамическим окружениям
• Не зависит от платформы
• Интеграция в портфолио HashiCorp

Как это работает?

https://learn.hashicorp.com/tutorials/boundary/getting-started-intro?in=boundary/getting-started

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

$ boundary connect ssh -target-id ttcp_1234567890

Boundary разработан для интеграции с существующими продуктами HashiCorp, а именно: Consul (сетевая платформа) для динамического обнаружения сервисов, Vault для управления секретами (подробнее далее), и Terraform для деплоя/интеграции в конкретное окружение.

https://www.boundaryproject.io

Зачем использовать Boundary вместо обычной архитектуры бастион хост?

Использование Boundary в качестве интерфейса соединения с вашей backend инфраструктурой убирает необходимость в дополнительных механизмах фильтрации, вроде NVA для ограничения соединения к бастион хосту, или других слоев ограничения бастион хоста в необходимой инфраструктуре, что может быть интегрировано с другими механизмами контроля, основанными на ролях.

Как это будет выглядеть в моей компании?

В типичном облачном окружении, мы ожидаем что структура организации будет выглядеть следующим образом:

Пример конфигурации архитектуры Boundary

Как это масштабируется?

В интересах улучшения рабочих процессов и автоматизации во время использования Terraform в AWS окружении, например, мы можем использовать EventBridge для планировки CodeBuild при создании, тегировании или удалении экземпляра EC2, в целях повторного применения Terraform, пока новый сервер создается или удаляется с особым тэгом, к примеру #Boundary-Web-Frontend. Таким образом сервера, созданные с этим тэгом, смогут добавляться в группу хостов Web-Frontend-Targets (группа серверов) и легко управляться существующими администраторами с минимальными дополнительными затратами.

Как мы открыли его?

Мы приступили к настройке окружения HA без разработчиков в AWS, рекомендованной платформой, предоставляющей код Terraform:

https://learn.hashicorp.com/tutorials/boundary/getting-started-next-steps?in=boundary/getting-started

Основные принципы разработки:

• Multi-AZ архитектура
• Публично доступен только ALB, который обеспечивает доступ к узлам контроллера
• Монитор состояния для ключевых TCP-портов контроллера (9200)
• Отказоустойчивый контроллер и настройка рабочего узла
• Узлы контроллеров отвечают за уровень управления, в то время как рабочие узлы за уровень данных (при необходимости могут работать как единое целое)
• Автомасштабирование групп для гарантии дублирования и масштабируемости

Мой опыт

Учебный портал HashiCorp обеспечивает прочную основу для начала работы с Boundary.

Между установкой тестового окружения через онлайн песочницу, или скачиванием локально, и установкой экземпляра разработчика есть буквально 5 минут разницы для начала работы и знакомства с основными принципами Boundary. Портал предоставляет простую инструкцию расписанную по шагам: управление пользователями, ролями, принципами, сессиями, соединением с целью, а также использованием консольного приложения Boundary в плане разработки. В заключение дается инструкция по настройке приложения Boundary с помощью Terraform.

Использование scope -

$ boundary scopes create -scope-id=global -name=IT_Support -description=”IT Support Team”

• в сочетании с использованием раздельных методов аутентификации проектов/пользователей/групп/принципов/ролей предоставляет простой и естественный метод сегрегации ресурсов, контроля доступа и ограничения возможностей отдельных объектов:

$ boundary auth-methods create oidc \
-issuer “https://ISSUER_URL" \
-client-id CLIENT_ID \
-client-secret CLIENT_SECRET \
-signing-algorithm RS256 \
-api-url-prefix “http://localhost:9200" \
-name “auth0”
$ boundary groups create -name=”group01" -description=”A test group” -scope-id=$ORG_ID
$ boundary users create -name=”tester01" -description=”A test user” -scope-id=$ORG_ID

Простота использования API позволяет легко интегрировать динамические и быстро меняющиеся окружения в Boundary и использовать с такими сервисами как Lambda, CodeBuild, и Terraform для внедрения в более крупные рабочие процессы.

Начиная с версии 0.4.0, с возможностью более широкой интеграции экосистемы, интеграция с Vault также предоставляет возможность хранить Vault секреты для сессий Boundary, что с точки зрения безопасности является значительным обновлением. Полная информация по установке здесь, однако в целом, шаги будут следующими:

1. Для начала настройте политику управления boundary в Vault, что позволит Vault проверять, обновлять и отзывать любые токены и аренду по мере необходимости, что требуется для управления и предоставления учетных данных надлежащим образом.
2. Создайте систему секретов базы данных и связанных ролей для генерации учетных данных, вместе с политикой, разрешающей доступ к БД из этих ролей.
3. Затем необходимо создать Vault Token для доступа к хранилищу учетных данных Boundary.
4. Создайте объект Boundary для созданных ролей базы данных.
5. И наконец, создайте хранилище учетных данных (указывая на Vault) и библиотеки данных для каждой роли БД и свяжите все друг с другом.

https://learn.hashicorp.com/tutorials/boundary/vault-cred-brokering-quickstart?in=boundary/configuration

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

Ограничения Boundary

Стоит упомянуть, что Boundary это весьма новый проект (релиз 0.5.0 на момент этой статьи), так что некоторые возможности еще не реализованы, но команда разработчиков работает над их добавлением.

Одна из основных возможностей, в необходимость которой мы верим и которая еще не добавлена — это возможность для Boundary блокировать доступ пользователю после нескольких неудачных попыток. Возможно, это может быть реализовано на уровне IDP/функциональной конечной точки. На данный момент Boundary этой технологи лишен, но в планах есть ее реализация.

Мысли по итогу

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

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

Учитывая то, что проект с открытым кодом, пришло время внести существенный вклад сообществу, которого мы с нетерпением ждем.

BA

Если вам интересны новости о мире DevOps, или вы готовы поделиться своими мыслями по какой-то актуальной теме, — подписывайтесь на наш Telegram-канал DevOps FM.

Переводчик: DanayDemenir
Редактор: DariaRogoz