DevSecOps Talks

Всем привет! Мы уже неоднократно писали про различные модули продукта CyberArk Application Access Manager (AAM) и сегодня решили немного агрегировать информацию для демонстрации полноты картины.

Что такое AAM?
Простыми словами, AAM - это про Secret Management на уровне приложений. На самом деле это набор модулей, предназначенных для организации безопасного взаимодействия между различными системами. Глобально каждый инструмент решает одну и ту же задачу – встраивание защитных механизмов в код приложения/скрипты с целью изъятия хранящихся в открытом виде паролей. Различие заключается в специфике приложений (контейнеризованные, неконтейнеризованные и пр.).

Модули AAM:
🍡Credential Provider (CP) – агент, устанавливаемый на АРМ разработчика и/или сервер системы, где функционирует разработанное приложение. Для интеграции в приложение используются библиотеки (Java, C/C++, .NET) или CLI. Доступен для Windows и *nix систем. Для неконтейнеризованных приложений
🍡Central Credential Provider (CCP) – веб-версия Credential Provider. Для интеграции в приложение используются REST API/SOAP запросы (агенты не требуются). Для неконтейнеризованных приложений
🍡Application Server Credential Provider (ASCP) – агент, который устанавливается на сервер приложений (JBoss, Web Logic, WebSphere, Tomcat). Для неконтейнеризованных приложений
🍡Dynamic Access Provider (DAP) – система с поддержкой различных инструментов, используемых для интеграции с контейнеризованными приложениями и контейнерными средами. Имеет open source версию, которая называется CyberArk Conjur

Что еще нужно знать:
Для функционирования продуктов группы AAM требуются дополнительные компоненты CyberArk. Большая часть компонентов – это компоненты продукта CyberArk PAS, которые является решением класса Privileged Account Management (PAM) и о котором, скорее всего, вы уже наслышаны. Это решение давно присутствует на российском рынке для решения задач по контролю действий привилегированных пользователей. Суммарный перечень компонентов представлен ниже.

🍡CyberArk EPV – компонент защищенного хранения паролей (здесь и будут храниться пароли, которые забирает AAM при вызове функций из скрипта или приложения)
🍡CyberArk CPM – компонент управления паролями
🍡CyberArk PVWA – компонент консоли управления (веб-интерфейс)
🍡CyberArk Vault Synchronizer – компонент, который используется для синхронизации секретов в модуль AAM (CyberArk DAP)

Более подробную информацию про AAM можно найти тут.

Привет!

Git – распределенная система управления версиями, без которой не обходится не одна разработка ПО в наше время.

По ссылкам (ENG/РУС) приведен материал, в которым крайне наглядно и доступно приводится описание must have команд, которые рекомендуется знать, даже если вы – Sec, особенно в начале пути:

🍭 init
🍭add & commit
🍭push
🍭branch
🍭checkout и т.д.

Можно скачать cheatsheet, в котором собрано все необходимое, а в самом конце – небольшая подборка материалов с более детальными разборами. Надеемся, что вам это пригодится!

P.S. Preview не работает, поэтому дублируем ссылки еще раз:
ENG: https://rogerdudler.github.io/git-guide/
РУС: https://rogerdudler.github.io/git-guide/index.ru.html

Всем привет!

И еще один потрясный доклад с сессии AppSec California, 2019! На этот раз от RIOT Games (тех самых, что придумали League of Legends и убили DotA)!

Автор рассказывает, как они определяли приоритеты развития в достаточно сложных условиях: большое количество команд (порядка 80), территориальная распределенность, крайне сильная независимость и автономность команд, а также невозможность использования подхода «top down» применительно к Security.

Началось все с того, что ребята решили некоторое время наблюдать за работой команд. На основании этих наблюдений удалось определить собственную модель зрелости, которая состоит из 4-ух уровней:
🍭 Level 1: «Absence» – ИБ отсутствует
🍭 Level 2: «Reactive» – ИБ «держится» на 1-ом человеке
🍭 Level 3: «Proactive» – ИБ – это уже практически постоянная практика
🍭 Level 4: «Proactive mindset» – ИБ это часть приложения, однако, практики этих команд не получится «перенести» на уровни ниже, т.к. Security является частью их жизни и она "естественна" для них

После анализа собранной информации (более 80 команд) был получен ожидаемый вывод – около 90% команд находятся на уровне 1 и 2.

Что RIOT сделали потом? Потом они взяли данные по Bug Bounty, BB (данные по количеству, выплатам, времени на устранение и т.д.) и провели корреляцию с уровнями команд! Получилась следующая картина:
🍭 Level 1 – BB avg pay: $ 1x; BB avg time to fix high risk: 1x
🍭 Level 2 – BB avg pay: $ 0,8x; BB avg time to fix high risk: 0,65x
🍭 Level 3 – BB avg pay: $ 0,65x; BB avg time to fix high risk: 0,45x
🍭 Level 4 – BB avg pay: $ 0,55x; BB avg time to fix high risk: 0,3x

Кроме Bug Bounty RIOT проанализировали количество запросов на Security Review, с которыми к ним приходили команды. И опять весьма предсказуемый результат: Level 1 практически не обращался за помощью, а Level 4 – разработчики сами проводили Security Code Review и обращались к Sec, как к еще одной «паре глаз» для формирования более точного результата.

Что тут интересного – спросите вы? Нам понравилось, что такой подход показал количественное подтверждение тезисам, что а) безопасность – это важно, б) безопасность может позволять экономить и в) можно реализовать безопасность даже в условиях agile и распределенности.

А что же сделали RIOT с этим знанием? Они определили стратегию – переход с уровня 3 на уровень 4 достаточно сложен (effort + cost / value), поэтому они пришли к выводу, что необходимо «подтянуть» команды Level 1 и 2 до Level 3. Как именно они решили это сделать – смотрите видео, time code ~ 22 минута ☺️

На наш взгляд это крайне интересный и познавательный доклад, поэтому рекомендуем Вам с ним ознакомиться ☺️ Надеемся, что вам он понравится также как и нам!

Пример в коде

Всем привет!

И снова животрепещущая тема управления секретами!
Сегодня, в рубрике For Dummies, покажем пример использования, наглядно демонстрирующий пользу от систем Secret management и механизм их работы. Пример приведён с использованием продукта CyberArk Central Credential Provider (группа продуктов Application Access Manager), о котором ранее рассказали

🍩Вводные:
У нас есть монолитное, не контейнерное приложение, работающее на сервере приложений и имеющее зашитый в коде пароль в открытом, текстовом виде. Например, пароль для подключения к БД

🍩Проблема:
При удачной атаке на приложение этот пароль может стать доступен нарушителю, который с его помощью получит доступ к БД. Дальше ничего хорошего...

🍩Решение:
Заменить открытый пароль функцией вызова к системе управления секретами.

🍩 Что мы делаем?
1. Вместо пароля мы добавляем в код функцию обращения к системе управления и запроса секрета (пример на скриншоте)
2. В переменных функции (строка 10) мы указываем заранее определенные адрес хранилища, каталог с нужным секретом в нем, идентификатор приложения и идентификатор конкретного секрета.
3. Настраиваем параметры аутентификации приложения (разрешения на уровне системы управления секретами) по одному или нескольким параметрам: идентификатор конкретного приложения, контрольная сумма, ip адрес сервера приложения, пользователя, под которым оно запускается и т.д.

🍩Что в итоге получим:
1. Пароль из кода исчезнет
2. За конкретным паролем приложение через агента сделает запрос в хранилище, идентифицировав при этом себя.
3. Хранилище сверит с какого сервера, от какого приложения, каким агентом, к какому секрету пришел запрос. Если все условия получения соблюдены, хранилище в зашифрованном виде вернет секрет, который будет записан в переменную вызова.

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

Та-дам!

И снова привет!

Есть большое количество заведомо уязвимых приложений, на которых можно поучиться базовым (и не только) способам атак/защиты.
А инфраструктура? Да, есть «уязвимые образы виртуальных машин», а что делать с кластером Kubernetes? Ответ есть и это… Kubernetes Goat!

Да, это уязвимая Kubernetes-среда, в которой можно попробовать реализовать такие сценарии как:

🍭 Sensitive keys in codebases
🍭 DIND (docker-in-docker) exploitation
🍭 Container escape to access host system
🍭 Attacking private registry
🍭 NodePort exposed services
🍭 Kubernetes Namespaces bypass
🍭 DoS the memory/CPU resources и другие

Kubernetes Goat можно в том числе посмотреть и на Katacoda. Guide доступен по ссылке: https://madhuakula.com/kubernetes-goat/ ☺️ Enjoy !

Привет!

Взять приложение. Просканировать. Найти множество недостатков. Написать отчет. Скинуть команде со словами – «Разберитесь!». Получить какой-то небольшой результат (если повезет) … Знакомо?

И это описание того, как обстояли дела в Netflix до тех пор, пока они не признали такой подход несостоятельным. Что-что, а вот с фантазией у ребят просто отлично!

AppSec команда приняла волевое решение – необходимо построить долгосрочные отношения с Dev. Для этого команда Netflix определило свои 5 шагов (5 steps to approach partnership):

🍭 Step 1. Engagement Identification. Определение Dev команды, приложений с которыми она работает. AppSec убеждается, что Dev готова пойти на встречу

🍭 Step 2. Discovery Meeting. Знакомство с командой, сбор информации. AppSec Netflix собирает всю доступную информацию, включая оценку рисков, в зависимости от характеристик приложения. Их цель на данном этапе – показать Dev, что «домашнее задание» выполнено и они собрали информацию, которую могли, понять контекст (context) и что делает приложение

🍭 Step 3. Security Review. При помощи ранее собранной информации определяется перечень активностей по ИБ, которые формируются в Security initiatives Doc. Специалисты Netflix считают, что не всем приложениям нужен pentest или детальная модель угроз. Задача этого этапа сделать перечень инициатив ИБ, адаптированный под приложение

🍭 Step 4. Alignment on the Security Initiatives Doc. Обсуждение предложений по безопасности с Dev, «выравнивание приоритетов» задач

🍭 Step 5. Ongoing Relationship Management. Dev включает Security Initiatives в свой Roadmap. Далее – осуществляется синхронизация между Dev и AppSec (например, раз в две недели/месяц)

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

Выступление команды Netflix, разбор каждого этапа (Step), а также используемые средства автоматизации можно посмотреть по ссылке!

Привет!

11 ноября будет вебинар, посвящённый KubeLibrary – библиотеки из RobotFramework (open source проект, использующийся для тестирования средств автоматизации и роботизации).

KubeLibrary может быть использована для тестирования состояния объектов кластера Kubernetes, например:

🍭 Nodes
🍭 Jobs
🍭 Configmaps
🍭 PV Claims
🍭 Services и иных объектов

Зачем это надо? Например, вы хотите провести аудит настроек вашего кластера Kubernetes. Все, что потребуется - это написать необходимые проверки, запустить их на кластере, собрать и проанализировать результат. Получится быстрее, чем проведение аналогичных действий "в ручную".

Вкратце про библиотеку можно почитать в этой статье или вот в этой, а примеры использования – посмотреть на вебинаре, ссылка на который была в самом начале статьи!

В недавнем опросе очень немногие любопытные проявили интерес к концептуальным темам. Этот пост для вас.

Microsoft следует заветам Simon Wardley и продолжает системно развивать инструменты для разработчиков: вот-вот выйдет релиз 1.0 Dapr. Это рантайм для распределенных систем, где из коробки умеет:
📍дискаверинг сервисов и вызовы по gRPC и HTTP
📍очереди сообщений
📍управление секретами
📍bindings для обработки событий
📍трейсинг и не только.

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

https://thenewstack.io/the-dapr-distributed-runtime-nears-production-readiness/

Всем пятница!

В статье собрана отличная подборка курсов (бесплатных (!)), которые помогут совершить первые шаги в изучении Docker и Kubernetes.

В подборке проводится обзор следующих курсов:

🍭 Docker Mastery Tutorial : The Complete Toolset From a Docker Captain (Udemy)
🍭 Free Docker Training Courses Online (LinkedIn Learning)
🍭 Docker and Kubernetes: The Complete Guide (Udemy)
🍭 Docker Technologies Course for DevOps and Developers (Udemy)
🍭 Docker Tutorial from A to Z™: Swarm + Jenkins (Udemy)
🍭 Docker, Apache Mesos & DCOS: Run and manage cloud datacenter
🍭 Docker for Beginners Course
🍭 Docker Swarm Mastery: DevOps Style Cluster Orchestration
🍭 Hands on With Docker & Docker Compose Tutorial From a Docker Captain
🍭 Grow your Docker Skills (Pluralsight)

Для каждого курса приведено краткое описание, а также сильные стороны и его «рейтинг». Все подробности и ссылки можно найти в самой статье!

Всем привет!

Не так давно мы писали про решение по управлению секретами в контейнерной среде CyberArk DAP.
Сегодня затронем другой компонент продуктовой линейки Application Access Manager (AAM), предназначенный для выведения hardcoded секретов (паролей, токенов и тд) в монолитных приложениях - это CyberArk Credential Provider.

Концептуально модуль представляет из себя набор библиотек для популярных языков программирования, таких как:

🍩 Java
🍩 C/C++
🍩 .NET

Эти библиотеки обеспечивают выполнение вызовов от приложений к хранилищу CyberArk Vault с применением:

🍩 политик выдачи секретов приложениям
🍩 периодической ротации секретов
🍩 аутентификацией хостов и приложений.

У решения есть 2 полезные фичи, которые пригодятся в случае отсутствия библиотек для конкретных языков программирования или невозможности установки Credential Provider на сервер с приложением:
🍩 возможность делать вызовы через утилиту CLI (её можно также использовать в bash/powershell скриптах)
🍩 централизация путем добавления к Credential Provider веб-сервера IIS. В этом случае в приложение добавляются SOAP/REST API запросы

И разумеется, решение может быть интегрировано в уже имеющуюся инфраструктуру CyberArk, используя общее хранилище секретов.

Более подробно с решением можно ознакомится на сайте вендора

Всем привет!

А вы знали, что Red Hat (IBM) не только включает в свою документацию разделы по безопасности, но и выпускает отдельные Security Guides для платформы оркестрации Red Hat OpenShift?

14 октября как раз появилась обновленная версия этого документа для платформы v4.5.

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

Вот перечень вопросов, ответы на которые можно найти в гайде:
🍡Почему безопасность контейнеров важна и как она ложится на стандарты безопасности?
🍡Какие меры по безопасности контейнеров реализуются на уровне ОС и на уровне платформы?
🍡Как проверять контейнеры на наличие уязвимостей?
🍡Как контролировать доступ к контейнерам, используя аутентификацию и авторизацию?
🍡Как обеспечивается контроль сетевых взаимодействий и безопасности подключенных к платформе хранилищ?
И пр.

Документ доступен по ссылке.

Сегодня мы хотим поговорить не о инструментах и технологиях, а о подходах. Думаю, многие из вас слышали такой подход, как GitOps. Он в свое время появился и получил распространение благодаря компании WeaveWorks (https://www.weave.works/).

GitOps - это метод / подход / практика / модель (называйте как удобно) к управлению кластером Kubernetes, и доставке приложений, которые в этом кластере работают. Чем-то это напоминает подход Infrastructure-as-a-Code, но чем-то и отличается. Если коротко, то, согласно блогу той же WeaveWorks (https://www.weave.works/technologies/gitops/), у вас GitOps, если:

🍬 Ваша система описана декларативно
🍬 Целевое требуемое состояние описано в едином источнике - Git
🍬 Автоматическое применение изменений
🍬 Софт, отслеживающий корректность фактического состояния

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

Но сегодня мы не об этом ) Сегодня как раз хотим поговорить не о том, почему это хорошо. А о том, почему это не (очень/всегда) хорошо.

Как и у любого подхода, у GitOps есть свои ограничения. Недавно наткнулись на интересную и познавательную статью - GitOps: The Bad and the Ugly (https://blog.container-solutions.com/gitops-limitations). В ней описаны следующие ситуации и проблемы, которые порождаются при GitOps - подходе:

🍬 Конфликты при апдейтах репозитория. Единый источник правды - Git - это и благо, и нет. Когда у вас большое окружение, сложное ПО с большим количеством микросервисов, конфликты при апдейтах неизбежны
🍬 Отсюда же следует вторая проблема: в попытке уйти от единого репозитория, их количество начинает расти большими темпами, и в итоге вы оказываетесь в ситуации, когда приходится тратить значительную часть времени на управление самими репозиториями, pull-request management, правильная настройка прав доступа, и т.д.
🍬 Недостаток наглядности, как следствие первых двух проблем. Понять и отследить фактическое состояние кластера, когда у вас много репозиториев - сложно
🍬 Сложность управления секретами (secrets management). GitOps не заточен для решения этой задачи сам по себе, и не особенно помогает ее решать. Потребуется единая точка управления секретами в виде отдельного хранилища
🍬 Аналогично и в части аудита изменения конфигураций. Бывают ситуации, когда отследить историю изменений сложно
🍬 Недостаток валидации артефактов на входе. В отличие от обращения к кластеру по API, при котором валидность проверяется, при простом коммите в git за корректность отвечает сам пользователь

Понятно, что не все из этих пунктов применимы ко всем кластерам, окружениям и компаниями. И нужно смотреть case-by-case.
Даже среди нас эти пункты вызвали дискуссии и разные мнения. Поэтому хотим обсудить это с вами - что вы думаете? Актуален ли для вас GitOps подход в целом? Применяете его? Сталкивались ли с проблемами и ограничениями? Поделитесь вашим опытом и соображениями на этот счет в комментариях!

П.с. А чтобы вам интереснее было читать статью - для затравки, в ней дано видение на подход, альтернативный GitOps'у.
П.с.2. И в этой же статье - ссылка на статью "11 причин зачем вам нужен GitOps" :) Enjoy!

Привет!

Недавно натолкнулись на еще один интересный open source проект, хотя бы потому, что вся его документация на бразильском португальском ☺️

Проект называется Horusec и используется для того, чтобы агрегировать проверки (статический анализ) :

🍭 Python(3.x) => (Bandit and Safety)
🍭 Ruby => (Brakeman)
🍭 Javascript => (Npm Audit and Yarn Audit)
🍭 GoLang => (Gosec)
🍭 .NetCore(3.x) => (.NetCore)
🍭 Java => (HorusecJava)
🍭 Kotlin => (HorusecKotlin)
🍭 Terraform => (Tfsec)
🍭 Leaks => (HorusecLeaks)
🍭 Leaks(optional search in git history) => (GitLeaks)

Проект поддерживается и развивается, по ссылке на Git можно найти roadmap, согласно которому будут добавляться новые функции, поддержки языков!

Ссылка на документацию (на английском): https://zup-products.gitbook.io/horusec/v/v1-eng/

Всем привет!

Сегодня пятница - день хороших новостей 🎂🍩🍪 Павел Новожилов и Анастасия Дитенкова из "Инфосистемы Джет" готовят вебинар на тему - Контейнеры vs Compliance. Не секрет, что требования регуляторов не всегда получается приземлить на эфемерные контейнерные среды, а выполнение некоторых из них кажется невозможным. Но нет ничего невозможного 😉

Мы поделимся опытом, как выполнить неприменимые к контейнерным средам требования ГОСТ для финансовых организаций, а так же расскажем как можно организовать:

🍩 Регистрацию событий рабочих нагрузок
🍩 Контроль целостности в контейнерной среде
🍩 Сегментирование контейнерных сетей
🍩 Управление уязвимостями

Регистрируйтесь, приходите и задавайте вопросы! Вебинар состоится 10 ноября в 16:00 МСК.

Привет!

Недавно мы написали про одно из двух решений, представленных HashiCorp (HashiCorp Boundary). Самое время рассказать про второе!

Встречаем HashiCorp Waypoint [Development]! Решение, которое позволяет разработчикам build, deploy и release приложений между различными платформами.

Причина, по которой Hashi решили сделать свое решение достаточно проста: сокращение сложности для разработчиков, которые просто хотят deploy, а не containers, schedulers, YAML, serverless и прочие нюансы cloud native мира.

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

🍭 Build: Сборка артефакта и помещение его в используемый реестр
🍭 Deploy: артефакт, собранный на предыдущем этапе, разворачивается на целевой инфраструктуре
🍭 Release: настройка потоков траффика на приложение

Просто пример deploy приложения на Kubernetes будет выглядеть так:

project = "HashiCorp Waypoint"

app "waypoint-up" {
    build {
        use "docker" {}
        registry {
            use "docker" {
                image = "hashicorp/wpmini"
                tag = gitrefpretty()
            }
         }        
      }

    deploy {
        use "kubernetes" {
            probe_path="/"
            service_port=80
        }
     }

    release {
        use "kubernetes" {
            load_balancer=true
            port=80
         }
     }

}

В результате будет собран образ, создан deployment в namespace и открыт порт для работы с приложением. И да, все будет реализовано с использованием одной команды: waypoint up!

Кроме Kubernetes Waypoint поддерживает HashiCorp Nomad, Amazon ECS, Google Cloud Run, Azure Container Instances, Docker, Buildpacks (перечень не полный 😉)

Это лишь часть функционала решения, подробности можно почитать по ссылкам:

🍭 https://www.waypointproject.io/docs/intro (документация)
🍭 https://www.waypointproject.io/docs/getting-started (простой пример использования)

Привет!

Что общего у Docker и Xerox? На первый взгляд может показаться, что ничего. А если немного задуматься, то можно обнаружить интересное сходство: Docker, как и Xerox стал нарицательным именем для определенной технологии и может сложиться мнение, что управление контейнерами и образами – это Docker. И ничего больше.

В статье автор делает краткий обзор на существующие механизмы Container Engine, Image Build, Container Runtime и Image Distribution. Цель статьи проста и понятна – показать, что Docker не единственный инструмент и, возможно, вы сможете подобрать себе то, что устроит вас в большей степени (хотя бы для того, чтобы убрать daemon, запускаемый из-под root, что не всегда безопасно). Какие же есть альтернативы?

Container Engine

🍭 Podman – потенциально самый «сильный» конкурент Docker, разработанный Red Hat
🍭 LXD — средство управления LXC (Linux Containers). Используется для решения достаточно узкого круга задач
🍭CRI-O – не совсем engine, больше runtime, специализированный для Kubernetes
🍭 rkt — rocker, container engine, разрабоатнный CoreOS. Увы, проект не поддерживается в настоящее время

Image Build

🍭Buildah – инструмент, созданный Red Hat для разработки образов. Есть интересная история, связанная с его названием – советуем погуглить
🍭Kaniko (не путать с Calico ☺️ ) – решение от Google, которое представляет из себя контейнер и в большей степени пригодно для использования на кластерах
🍭Buildkit – если все же не хочется «отворачиваться» от Docker, то это решение для вас: может быть «включен» в Docker, в качестве experimental feature

Container Runtime

🍭 runc – вероятно, самый популярный container runtime, созданный в соответствии со спецификациями OCI (используется Docker, Podman, CRI-O)
🍭 crun – решение, разработанное Red Hat

Image Distribution

🍭 Skopeo – инструмент разработанные Red Hat, завершает «триаду» - Podman/Buildah/Skopeo

"А будут ли проблемы совместимости, если я все же захочу использовать что-либо отличное от Docker? ” – можете подумать вы. Нет, не будет. Все указанные инструменты разработаны с использованием спецификаций OCI (как и сам Docker). Например, alias docker=podman и проблем нет, даже команды те же самые, а местами даже больше! Чего стоит один только:

buildah rmi –a (какая мелочь, а сколько счастья ☺️)

Вставлять множество ссылок на представленные инструменты не стали, все можно найти в статье, если захочется узнать больше!

P.S. Если вам понравилась статья и вы бы хотели, чтобы мы перевели ее на русский язык полностью – пишите в комментариях под постом или в чате – сделаем! ☺️

Всем привет!

На предыдущей неделе HashiCorp анонсировала сразу 2(!) новых продукта, которые расширят их и без того впечатляющий портфель!

Первый – это HashiCorp Boundary [Security]
Обеспечение безопасности удаленного доступа, основанное на trusted identity.

Решение предлагает альтернативный «классическим» VPN/хост-бастион SSH подход, что может быть удобно для распределенных команд, особенно в условиях «эфемерности и динамичности» окружений. Также решение позволяет гранулярно управлять доступом, получаемым извне компании.

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

🍭 Gateway
🍭 Локального агента на машине пользователя
🍭 IdP (identity provider, любой из существующих)
🍭 Настроенных политик управления доступом, реализованных с учетом RBAC

позволяет контролировать доступ пользователей к определенной группе ресурсов. При этом, контроль осуществляется для логических групп («базы данных»), а не для "фиксированного перечня ресурсов" (перечень IP-адресов).

Это позволяет «убрать» целый перечень чувствительных данных (VPN/SSH credentials, перечень целевых IP-адресов, учетные данные целевых систем и т.д.), которые могут быть скомпрометированы.

Таким образом упрощается процедура предоставления доступа и повышается безопасность. Подробнее о том, как это работает можно посмотреть в видео, доступном по ссылке на решение ☺️