Всем привет. Название статьи говорит за себя, добавлю лишь, что расскажу об объединении IGA, PAM и Vault. Статья будет интересна DevSecOps-инженеров, специалистов по безопасности и администраторов инфраструктуры.
Первопричины изменений
Сначала служба безопасности заставила внедрить PAM. Учётные записи добавляли вручную. В сутки задействовали около 200 серверов, по 5-10 учётных записей на каждом — очень неудобно. Нагрузка была около 8000 сессий на инсталляцию. При этом у нас около 2000 информационных систем и 8000 команд.
Потом внедряли Vault, чтобы убрать секреты из конфигураций Kubernetes. Были проблемы с безопасностью секретов в OpenShift. Для каждого движка приходилось давать индивидуальный доступ. Для каждого аутентификатора — своя политика, на 10 инсталляций приходилось более 1 000 000 политик, нужно было это как-то автоматизировать.
Потом появилась задача обеспечить проверку прав на 300 тысячах серверов и 40 тысячах СУБД.
В результате решили, что пора внедрять IGA и заниматься role mining.
Польза от IAM и управления учётными записями
Identity and access management (IAM) — это дисциплина в сфере инфобезопасности, которая позволяет определённым людям получать доступ к определённым ресурсам в определённое время, определённым способом и по определённым причинам, и иметь возможность сообщать об этом доступе. IAM включает в себя решения, в которых задействованы люди, процессы и технологии.
Технологические среды становятся всё сложнее, и обеспечение надлежащего доступа к ресурсам в них имеет первостепенное значение для обеспечения безопасности среды, в дополнение к соблюдению всё более строгих нормативных требований.
Ещё одна тенденция: предоставление конечным пользователям интуитивно понятного и безопасного контроля над своими данными при одновременной защите их конфиденциальности.
Не буду здесь рассматривать Client Identity Access Management (CIAM). Упомяну лишь про WIAM и MIM:
Workforce Identity Access Management (WIAM):
сокращение времени на обслуживание;
повышение рентабельности;
повышение безопасности;
защита интеллектуальной собственности, торговой марки и предотвращение мошенничества;
управление доступом и SoD;
повышение уровня соответствия требованиям.
Machine Identity Management (MIM):
обеспечение уверенности в бизнес-практиках;
защита от внутренних угроз;
повышение соответствия нормативным требованиям;
повышение безопасности;
защита активов;
сокращение затрат на ИТ;
управление технологическим доступом.
Специфика применения WIAM- и MIM-функций в Сбере подразумевает управление двумя различными типами Identity — персонами (пользователями) и технологическими автоматизированными системами (machine identity).
Типы учётных записей
У нас есть учётные записи, которые не принадлежат организации и которые принадлежат. К первым относятся персональные учётные записи с федеративным доступом. Вторые делятся на аккаунты для доступа к приложениям и другим системам и сервисам, с дальнейшим ветвлением на привилегированные и непривилегированные.
Из всего этого многообразия мы выделяем привилегированные и технологические учётные записи. Их жизненный цикл связан с соответствующими приложениями и оборудованием. То есть когда увольняется человек, которому принадлежит определённая УЗ, то заблокировать её или отнять права уже нельзя, можно только присвоить кому-то другому. В основном технологические и привилегированные учётки различаются типом аутентификации — это локальные УЗ вне централизованных каталогов (Active Directory). И в целом их набирается много.
Подробнее про IAM можно почитать здесь:
Как работает управление привилегированным доступом
У нас есть некое решение, в которое загружается LDAP-каталог устройств. Пользователь создаёт сессию и аутентифицируется с помощью паролей и секретов, подключается к устройствам. Применяется многофакторная аутентификация, ведутся различные журналы, видеозапись и поведенческий контроль, собирается статистика.
По сути, PAM — это менеджер паролей, в который внедрены движки для ротации паролей на конечном оборудовании. Сегодня в моде — «прозрачное подключение», то есть избавление пользователей от ввода логинов и паролей.
Выбор продукта
На рынке есть немало готовых решений (часть из которых недоступна в России). Мы выбрали три наиболее перспективных и стали придирчиво анализировать, какой же из них станет «победителем». Оценивали по таким критериям:
Если у вас есть доступ к enterprise-версии Boundary, то рекомендую его:
Ещё обратите внимание Jump Server — новое китайское решение, выглядит очень интересно:
Также поделюсь ссылкой на статью про Teleport.
PAM в Сбере
У нас используются такие движки: Active Directory, Postgres и Linux local. Аутентификаторы: LDAP, Radius и многофакторка. Клиенты: RDP, Postgres, SSH и консоли. Отличия нашей реализации от классической:
Стараемся внедрить Just-in-time access, но пока не можем обойти все серверы для того, чтобы разблокировать учётки или присвоить права, их бывает очень много. Поэтому проверяем наличие тикета ITSM-системе на проведение каких-либо работ на объекте подключения.
Реализовать поддержку всех нестандартных консолей слишком трудоёмко, поэтому консоли должны поддерживать инъекции логинов-паролей (в основном в браузере) и аутентификацию через централизованный LDAP.
Схема работы нашего PAM:
Vault
Мы использовали Vault как хранилище секретов с возможностью ротации на ресурсах (конечных устройствах) и возможностью получать их с помощью разных типов аутентификации. Отличие от PAM — всё должно работать быстро и надёжно.
Схема работы точно такая же, как и в случае с PAM. В качестве клиента выступает машина. Она на основе политик получает с помощью аутентификации доступ к движкам и запрашивает приложение.
Однако сложность в том, что в Vault есть политики. И если ты даёшь кому-то права на управление ими, то это человек может сделать всё, что угодно. И политики нельзя разделить на группы с разными правами на редактирование. Поэтому либо нужен доверенный админ, либо self service.
Что выбрать в качестве хранилища?
В 2022 году конкурентов Vault не было, особенно для enterprise-версии. А у community-версии были недостатки: нет восстановления после сбоев и Performance Replication, проблемы с масштабированием.
У Conjur от CyberArk механизмы ротации и хранения заменили на такие же, как в PAM. Но мы его не рассматривали из-за обилия недостатков:
8 тыс. учётных записей в одном каталоге;
медленный поиск учётных записей;
устаревшее хранилище секретов;
используются специальные CPM.
Есть ещё проект Infisical. В 2022 году он был в версии 0.0.1 (сейчас 0.95). Платная версия очень похожа на Vault, есть HCM, AutoUnseal, движки секретов и аутентификации и т. д. А вот community-версия отличается, расскажу про неё подробнее.
Vault или Infisical (community-версии)
У Vault:
нет встроенного балансировщика;
проблемы со скоростью переключения HA;
нет Disaster Recovery и Active-Active Vault;
есть проблема с распаковкой slave-ноды, когда мастер переходит на slave;
движки «из коробки», KVv2.
У Infisical:
есть HA/Disaster Recovery;
нет KVv2 и движки не поставляются;
при наличии IGA можно управлять секретами в KV.
На что нужно обратить внимание при выборе: механизмы распаковки, HCM, наличие HA/DR, поддержка необходимых типов аутентификации, наличие библиотек для работы с секретами.
Vault в Сбере
У нас используются такие движки: Active Directory, PKI, Postgres и SSH-keys, K/V. Аутентификаторы: Kubernetes, Approle и LDAP (для доступа админа). Отличия нашей реализации от community:
PKI умеет получать сертификат с внешнего УЦ. Добавили метод fetch для работы с TTL cертификатов.
Доработали движок AD: два УЗ в одной роли по одному пути.
Tenant’ы для экземпляров АС.
Распаковка stand-by производится сразу.
Аппаратные балансировщики.
То есть мы решили проблемы с восстановлением после сбоев и высокой доступностью. Также увеличили запас производительности чтения с одного master.
Istio + Vault = Magic?!
В чём прелесть Vault для Kubernetes? Допустим, вы подняли под для обслуживания клиентского трафика, и там должен появиться серверный сертификат. Конечно, можно положить его на 10 лет, но потом вообще никто не вспомнит, как его менять. А можно сделать в Vault авторотацию и с помощью sidecar вставлять сертификат при каждом запуске Vault или при каждом изменении сертификата. Так можно обеспечить прозрачную ротацию чего угодно.
Схема работы:
На кластере создайте «мастер» сервис-аккаунт.
Настройте метод аутентификации Kubernеtes на конкретный кластер с токеном мастер-аккаунта.
Настройте роли в аутентификации: с каким именем сервис-аккаунта из какого проекта, с какими политиками можно аутентифицироваться.
К любому поду поднимите sidecar с аннотацией сервис-аккаунта и адресом, куда класть секреты.
Любой под при запуске забирает секреты из тех, что были заложены sidecar’ом.
Sidecar может обновить секреты хуками, а Istio умеет перечитывать секреты.
Подробнее об этом: статья, вебинар.
Примечание: валидацию сертификатов в других продуктах должна быть реализована НЕ на основе fingerprint/serial number, иначе при перевыпуске сертификата подключение будет невозможно. Также, если завязывать аутентификацию на атрибуты, то важно контролировать, чтобы никто не мог выписать себе сертификат с чужим атрибутом.
Опишу, как всё это реализовано у нас. У нас настроено две роли приложения (AppRole):
одна получает только secret-id для AppRole2, уничтожая предыдущие;
другая получает секреты. TTL secret-id = 30 min.
В Jenkins-creds кладём secret-id Approle1 с помощью IGA, secret-id командам не доступен. В приложение Jenkins доставляет secret-id Approle2.
То есть одна роль умеет только сбрасывать пароль от другой роли, а та имеет доступ к секретам. При развёртывании мы сбрасываем пароль и отправляем в приложение, а оно ротирует секрет от этой роли. Секрет никто не знает, он остаётся только там. Если кто-то вдруг сбросит токен, то у нас всё встанет и будет возможность разобраться, что же произошло.
IGA + PAM + Vault
Теперь самое интересное: как мы связали вместе всё вышеописанное.
У нас есть каталог устройств — CMDB. Когда в IGA попадает новый сервер (ресурс), создаётся событие, которое заставляет IGA пересчитывать роли. Механизм расчёта подбирает роли, которые могут быть применены к ресурсу по правилам распространения. Далее механизм проверяет наличие учетной записи, её параметров и т. д., создаёт её при необходимости и связывает эту учетную запись с ролью. Далее вспоминаем, что каталог в PAM равен роли. Главный плюс — ролями управляют пользователи.
Роль обеспечивает наличие учётной записи на конкретном ресурсе и её права. Если по каким-то причинам учётная запись перестаёт быть обеспечена ролью, то права отзываются, а УЗ блокируется. Роль решает задачу объединения кучи учётных записей в одну: например, 300 000 УЗ для сопровождения ОС собираются в одну роль. Кроме того, мы через свойства ролей мы реконсилируем учётные записи и их параметры. А механизмами расчётов решаем проблему управления учётками в PAM.
Схема учёта компонентов и систем
IT-Configuration Management
Для всего этого нужно управлять конфигурациями. Вот как это устроено у нас:
Есть автоматизированная система и её экземпляр. Внутри АС есть серверы, связанные с сущностями, которые я называют экземплярами технологического стека, а они уже связаны с самими техстеками. В стеках есть ответственные, которые перетекают в экземпляр нашего технологического стека.
Чтобы обеспечить доступ к управлению автоматизированными системами, мы обращаемся к Application Development Management, там у нас есть связь автоматизированной системы с командой. В команде есть сотрудники с определёнными ролями. Всё это мы транслировали и можем управлять экземплярами АС или всей АС.
Полезные ссылки про модели CMDB:
https://www.snow-mirror.com/wpcontent/uploads/2016/07/ServiceNow-Data-Model-v3.4.pdf
https://docs.bmc.com/docs/ac2105/service-modeling-1002216499.html
https://www.device42.com/cmdb-best-practices/cmdbvisualization/
IGA
Из CMDB мы получаем экземпляры автоматизированной системы и технологических стеков пользователей. Превращаем их в учётные карточки IDM. Учётные карточки экземпляров связываются с пользователями для обеспечения их доступа. Карточкам назначены роли, связанные с ресурсами. Ресурсы появляются из экземпляров технологического стека и ресурса, как в некой компиляции. Так получаются учётные записи с параметрами.
Роли создаются по принципу self service. При создании роли строятся маршруты согласования в зависимости от: наличия экземпляров техстека на сервере и выбранных прав. В зависимости от выдаваемых прав состав согласующих сотрудников меняется.
Мы используем IGA для:
создания УЗ, назначения прав, отправки учёток в Vault/PAM;
создания аутентификаторов, политик для Vault;
предоставления и согласования доступа к PAM/Vault;
обработки событий перемещения и удаления серверов;
Кроме того, при удалении сервером мы с помощью IGA удаляем учётные записи, деактивируем движки, пересматриваем доступы и проверяем права. Тем самым мы решаем задачу управления Vault. Ролевая модель Vault не предусматривает возможности разделения создания или модификации политик. Права на управление политиками невозможно ограничить. А у нас есть учётка у IDM и мастер, который управляет политиками, поэтому в IDM есть интерфейс разделения на экземпляры автоматизированной системы. Получается разделение зон для АС. Можно создавать аутентификаторы и политики, а также активировать движки только в своей зоне.
Кроме того, у нас реализованы PKI и возможность разграничить выпускаемые сертификаты по атрибутам для аутентификации в рамках всей организации, например, по CN. Выключены проверки по fingerprint\sn: можно менять сертификат на лету или внедрять с временем действия 1 минута для установки сессии.
Вендоры
В 2022 году мы изучили рынок (сегодня таблица уже отчасти устарела):
Мы выбрали российское решение от Avanpost.
Руководствовались такими критериями
-
Система должна обеспечивать управление ЖЦ:
ТУЗ, в т. ч. привязку учётных записей к стендам АС;
ПУЗ, в т. ч. привязку учётных записей к пользователю.
Система должна иметь расширяемую посредством плагинов (расширений, модулей) архитектуру.
Система должна быть реализована трёхзвенной архитектурой (БД, программное обеспечение для сервера приложений, web-интерфейс клиента) с разделением хранилища данных и среды исполнения бизнес-логики.
Система должна предоставлять возможность настройки и выполнения бизнес-процессов согласования заявки средствами самой системы, а также обеспечивать возможность интеграции с ITSM-системой для возможности создания заявок на ручное предоставление доступа, для внешнего согласования заявок на доступ, а также интеграцию со сторонним порталом самообслуживания.
Возможность реализации произвольных комплексных правил назначения ролей (скрипты, внешние правила), в т. ч. вызов сторонних систем по API.
Система не должна выполнять бизнес-логику на уровне СУБД.
Плагины (расширения, модули) должны иметь возможность использовать весь массив данных Системы.
Плагины (расширения, модули) должны позволять выполнять произвольный сторонний код, написанный на одном из высокоуровневых языков программирования.
-
Плагины (расширения, модули) должны позволять:
расширять web-интерфейс клиента;
расширять БД Системы;
расширять функциональность, доступную для вызова во внутренних скриптах.
Архитектура Системы должна предусматривать размещение серверов для подключения к target-системам (объектами доступа) в различных сетевых сегментах без прямого TCP соединения с возможностью интеграции их через шлюзы безопасности, принятые к использованию в инфраструктуре Заказчика, обеспечивающие передачу и фильтрацию трафика между различными сегментами по протоколу HTTP(s) в формате XML/JSON.
Система должна поддерживать горизонтальное и вертикальное масштабирование своих компонентов без изменения архитектуры.
Система должна обеспечивать возможность распределения заданий, реализующих бизнес-логику, по выбранным компонентам.
С системой должна поставляться документация на внутренний API, framework, скрипты и библиотеки для разработки функциональности.
Выбирая для себя решение, обратите внимание на:
Возможность создания identity (карточек) экземпляров АС.
Возможность ролью создавать уникальную учетную запись в ресурсе (конечной системе) и/или привязывать больше одной УЗ к identity (карточке) на одном ресурсе.
Возможность распространить роль на множество ресурсов.
Возможность унаследовать права от другой роли.
Возможность синхронизировать роли с ресурсом.
Возможность доработки интерфейса пользователя для заказа УЗ, прав и ролей.
Архитектуры
Зачем это всё?
Наверное, у вас давно назрел этот вопрос. Дело в том, что мы попытались перевести Linux на централизованную аутентификацию. А Linux-серверов у нас 300 000. FreeIPA, которая обеспечивает HBAC/управление sudo и др., оказалась недостаточно надёжна, ещё и приходится вручную восстанавливать доступ после её падения. Если использовать другой провайдер, то всё равно необходимо конфигурировать каждый хост. В итоге мы остановились на варианте локальных УЗ с ключами SSH, как подписанными Vault, так и обычными. И IGA позволяет прописать новый публичный ключ.
К преимуществам нашего решения можно отнести централизованный учёт, заказ, проверку на соответствие политикам, доступ к чувствительной информации через получение учётных данных. Есть и недостатки: нужна отдельная команда разработки и сопровождения сервиса, и централизованный сервис — ключ ко всем системам, нужно задуматься об обеспечении её защиты. За нами очень плотно следит кибербезопасность, и при каждом ручном действии с нас строго спрашивают о его причинах. Пока что от ручной работы полностью избавиться не успели, потому что все сценарии работы в 8000 команд сходу объять невозможно.
Сейчас наш сервис управляет более чем 500 000 ресурсов. Политик Vault более миллиона, учётных записей больше 15 млн, ролей больше 400 000. Скорость разливки изменения прав сопровождения техстека с необходимостью подключиться к системе (300 000 узлов) — около 3 часов. За это время система заходит на каждый ресурс, создаёт учётку, раздаёт права и ключи, выполняет проверки.
Результаты бенчмарка Vault на синтетических данных на двух хостах с 16 CPU и 128 ГБ RAM. Бэкенд: Postgres 16 CPU и 128 ГБ RAM Pantroni Repl Cluster. Нагрузка на Vault — 87 %, на СУБД — 22 %.
Если вам нужно что-то подобное
И напоследок несколько советов, если вы хотите реализовать у себя что-то из описанного.
Учёт конфигураций
Организуйте учёт конфигураций оборудования, серверов, адресов подключений, т. н. CMDB. Не обязательно брать модель ServiceNow, не обязательно внедрять системы для учета: можно вести учёт в таблицах любой СУБД.
Модель не должна быть сложной, на уровне ниже экземпляра АС не более 3-4 уровней.
Проверяйте модель сразу: ресурс должен собираться из уровней быстро и просто.
Некоторые логические уровни лучше заменить атрибутами.
Обязательно интегрировать скрипты развертывания инфраструктуры или портала самообслуживания с этой базой.
Сразу сделайте правила проверки этой базы на консистентность.
Не давайте вносить изменения в эти проверки.
Vault для использования с Kubernetes
Продумайте HA/DR/Perfomance. Если редко пишете в базу или ротируете пароли, то можно реплицировать между БД данных сторонними средствами. Если часто, тогда необходимо продумывать механизм программной синхронизации в коде Vault. Развитие: Stand-by, Performance Read Node, что доступны в Enterprise версии.
Если сервис не критичен, ставьте и пользуйтесь.
После установки все токены, политики, хранилища и т. д. заводите через средства автоматизации: Jenkins, TC и т. д.
Для работы команд/АС выделяйте namespace или создавайте некоторое количество Vault.
Развивайте красивый фронтенд, интегрированный с CMDB и служащий для запуска job.
Пишите историю об операциях и информацию о текущем состоянии для ускорения операций.
PAM
Стандартизируйте имена УЗ, права.
Разворачивайте УЗ только автоматизацией (скриптами), добавлять в PAM УЗ можно через свой портал, Jenkins, TC и т. д.
Автоматизация создания УЗ на Linux, Windows, DB
Напишите self-service в портале заказа инфраструктуры или на отдельном ресурсе что-то подобное механизму ролей, сделайте подбор ресурсов по условиям (из CMDB).
УЗ разворачивайте только скриптами автоматизации через Jenkins/TC/ansible/etc.
При создании/изменении роли проверяйте, не появилось ли что-то новое, попадающее под роль. Организуйте очередь обработки событий изменения ресурса/сервера.
Используйте существующие скрипты для PAM/Vault, если они уже есть.
Если нужно сразу всё
Решите: писать самим или покупать. Оцените бюджет и дальнейшее развитие, степень автоматизации.
Возьмите за основу решение midPoint, к нему нужно добавить self-service и orchestrator/bpmn-движок.
Для создания «динамических ролей» с правилами подбора ресурсов логику подбора ресурсов, убирайте под «капот» коннекторов или в self service держите мастер-роль, ее обработку и создание ролей на конкретных ресурсах.
Если уже есть портал self-service и скрипты из предыдущих пунктов, используйте готовые коннектор-серверы (можно адаптировать ConnId).
Функциональность реконсиляции, рисков, отчётности, визуализации можно подсмотреть у open source.