Хабр, и снова здравствуй) На связи Алексей Боровиков, архитектор Astra Cloud. Тут такое дело, мы выкатили мажорный релиз нашей облачной платформы. Работа была проделана колоссальная, я не буду писать все изменения, иначе это будет не статья, а книга. Поэтому решил сфокусироваться на одном компоненте и рассказать, как мы его сделали и почему. Речь идет про IAM — Identity and Access Management. Он отвечает на главные вопросы облачной безопасности: кто, что сделал и имел ли на это право. Итаааак…
Все круто, но…
Когда мы только приступили к созданию собственной облачной платформы у нас имелся набор самодостаточных продуктов: ОС Astra Linux SE, ПК СВ «Брест», BILLManager, ALD Pro и т.д.
До их совместной тусовки внутри облачного контура каждый развивался в рамках собственной логики, имел продуктовый роадмап и реализацию необходимых ИБ-функций. Плюс — своя база пользователей по отдельности и, естественно, собственные реализации механизмов аутентификации и авторизации.
Казалось бы, план идеальный: просто взять и интегрировать продукты между собой внутри платформы. Если промоделировать такой сценарии заранее, то становится понятно, к чему он приведет:
множественные точки неоднородных механизмов аутентификации и авторизации;
необходимость поддержки консистентности сведений о пользователях во множестве подсистем;
избыточные и конфликтующие политики доступа;
сложность аудита и управления.
Ловушка «простой интеграции»
Простая интеграция компонентов между собой на бумаге выглядит быстрым решением, но означает «кривую ИБ» — фрагментированную систему безопасности, где права приходится настраивать отдельно в каждой подсистеме. На практике это боль в режиме «постоянно синхронизировать пользовательские базы» и бесконечное решение конфликтов политик доступа.
Если мои мысли сейчас читает специалист больше продуктовый, чем разработчик, перевожу: сценарий «давайте просто все засунем в облако, как есть и все» оборачивается повышением порога входа потенциальных пользователей облачной платформы → увеличением нагрузки на персонал сопровождения → повышенным риском утечек и ошибок.
IAM надо было делать. Без вариантов.
Ну что, проектируем IAM? Нет, еще рано
Прежде чем добавить IAM в качестве полноценного компонента Astra Cloud Platform, мы неслабо озадачились:
а какие функции облачной платформы являются общими для всех подсистем?
можно ли их как-то классифицировать?
если да, то по каким общим правилам эти функции будут выполняться?
по каким общим правилам подсистемы будут взаимодействовать между собой и с внешним миром?
В процессе логика ответов немного изменилась, но в итоге мы докопались до истины. Сервисы внутри облачной платформы мы разделили на:
функциональные, предоставляющие бизнес-ценность пользователям (ВМ, диски, образы, сети и т.д.);
платформенные, которые включают в себя управление тенантами, аутентификацию и авторизацию, потребление, биллинг, квоты.
Другими словами, одними пользуется клиент, а вторые формируют одну среду из разрозненных самодостаточных систем.
Мы погрузились еще дальше и определили для платформенных сервисов точки исполнения их функций, сформировали правила и последовательности вызовов между подсистемами в процессе предоставления функций облачной платформы.
Как итог: исключение дублирования + закрепление зоны ответственности сервисов.
Есть нюансы
Все компоненты облачной платформы интегрировать с IAM с первого раза нереально.
Изменение механизмов информационной безопасности в существующих системах (а тем более в сертифицированных системах!) не происходит по щелчку пальцами, необходимо провести анализ и планирование:
Оценка возможности перехода — не все legacy системы в состоянии изменить механизмы аутентификации и авторизации;
Согласование контрактов API — системы имеют свои особенности интеграции, часто просто не совместимые между собой;
План миграции на новые сервисы — необходимо четкое планирование этапов замены внутренних функций системы на внешние сервисы, их этапность и последовательность.
Другими словами, нельзя просто так взять и выкинуть функции безопасности из сертифицированного ПО и заменить его внешней системой. А у нас оооочень много сертифицированного ПО. Как минимум, ПК СВ «Брест».
Если мы просто уберем его встроенные функции безопасности и заменим их на функции IAM, то получим НЕ сертифицированный продукт виртуализации в облаке, который нужно будет сертифицировать по-новой, так как в него добавляется функционал. В реальности это занимает полгода минимум.
Мы не можем так поступить и с самим продуктом, и с дорогими заказчиками, которые его успешно используют очень давно. Если вы умеете сертифицировать ПО по требованиям ФСТЭК России за, допустим, неделю, пожалуйста, напишите нам)
Кажется, что круг замкнутый, но на самом деле нет. В процессе работы у нас появился ПЛАН. Мы двигаемся по нему и постепенно заменяем функции безопасности продуктов на функции безопасности IAM, параллельно готовясь его сертифицировать.
Последним на замену функций будет ПК СВ «Брест», когда мы:
протестируем продукт сначала на себе (мы так всегда делаем с новыми решениями);
выработаем методику замены функций ИБ продукта на функции ИБ IAM;
сертифицируем IAM.
На данный момент с IAM уже интегрированы SDN, который тоже новый в Astra Cloud Platform 2.1 и о нем мы напишем отдельную статью, ALD Pro и Astra Monitoring.
Что еще сделано
✅ Адекватные сценарии единого входа. Пользователь один раз вводит логин и пароль и получает доступ ко всем своим подсистемам.
✅ Под капотом работают более 10 микросервисов в среде Astra Linux Special Edition.
✅ Токены оперативно хранит Tarantool, основная база данных работает на Tantor.
✅ Интеграция с существующим каталогом на базе ALD Pro готова.
✅ Двухфакторная аутентификация реализована через одноразовые ключи. Если у заказчика есть SMS-шлюз, работает отправка кодов смсками.
✅ Ролевая модель устроена понятно. Учетная запись создается в службе каталогов, добавляется в каталожную группу, которая связана с ролями в IAM. Роль как сущность попадает непосредственно в токен.
Наши планы по развитию
Тут без романтики и мечты о небесных пирожках, хоть мы и говорим про облака. Роадмап IAM как компонента Astra Cloud Platform прозрачный. Коротко и по факту.
Откроем интеграцию с внешними поставщиками идентификации и продолжим усложнять ролевую модель. Построим отдельные интерфейсы для потребителей и администраторов. Добавим оповещения о подозрительной активности.
IAM и его место в Astra Cloud Platform
В скором будущем наш IAM должен стать главным инструментом реализации платформенного контекста для всех подсистем Astra Cloud Platform. Он будет одновременно и обслуживать их потребности, и задавать правила работы в части идентификации, аутентификации (ИАФ) и авторизации (УПД). Также IAM должен стать единой точкой входа, отвечающей за интеграции с внешними системами в тех же частях идентификации, аутентификации и авторизации.
Словом, вроде бы пользователь сталкивается с ним не особо часто, только при входе, но чтобы такого добиться, необходимо проделать N-количество действий.
Теперь скажу еще раз, более по ИБ.
IAM становится центральным элементом архитектуры облачной платформы, его ответственность должна распространяться на все действия субъектов любого вида (пользователи, подсистемы или внешние системы) в облачной платформе и ее объектах управления. Главная ценность компонента заключается в его 100% гарантии, что доступ к данным и сервисам получают только те, у кого есть доступ и необходимость.
Памятка для тех, кто тоже будет делать IAM, а потом его захочет сертифицировать
Управление доступом строится вокруг трех базовых сущностей — субъекта, объекта и действия. Кто выполняет операцию, над чем она выполняется и что именно происходит. IAM-мышление укладывается в эту троицу, с нее мы и начали.
Базовые функции тоже ничем не удивляют. Управление идентификацией охватывает создание, жизненный цикл и удаление пользователей и сервисных учеток. Аутентификация включает MFA и SSO. Авторизация работает через RBAC, ABAC и политики. Учет и аудит закрывают логирование попыток доступа, мониторинг аномалий и отчетность.
Облачная платформа добавляет свою специфику, вот тут начинается интересное. Появляются тенанты — контейнеры безопасности, изолирующие ресурсы друг от друга. Они связаны с учетом потребления, квотами и биллингом. Кто-то тенантом владеет, кто-то им управляет, а это означает, что тенант сам становится объектом доступа.
Добавляется самообслуживание. Управление пользователями тенантов лежит на самих потребителях облака, а не на нас. Значит, нужно уметь их отличать от администраторов платформы. Мы разделили всех на два типа — сотрудники оператора и потребители ресурсов.
Дальше требования сыпятся одно за другим. IAM должен пройти сертификацию по ФСТЭК России. Читаем (и радуемся с отделом ИБ) документы, после чего определяем нужный набор функций на доработку:
ИАФ, УПД, РСБ (регистрация событий безопасности), короче, пишем много
буковдокументов;поддержка Zero Trust, Least Privilege и модное слово Security by Design;
работа с SAML, OAuth 2.0, OIDC, генерация и валидирование токенов;
интеграция с внешними поставщиками идентификации вроде LDAP и IdM.
Плюс архитектурные обязательные хотелки. Платформа не статична, роли и сервисы меняются, поэтому IAM должен адаптироваться к росту и выдерживать высокую нагрузку с гарантией 24/7.
В общем, все стандартно, ничего нового) Космолет мы не придумывали и вам не советуем.
IAM в массы!
IAM — не опциональный компонент, это фундамент. Без него любая облачная платформа превращается в набор изолированных продуктов, которые сложно обслуживать, опасно эксплуатировать и невозможно нормально аудировать.
Советы от того, кому этот мир уже абсолютно понятен.
Если делать IAM с нуля, начинать надо с требований высших сил регулятора и архитектуры, а не с кода. Модель доступа — RBAC, ABAC или их комбинация — определяет все остальное. Внедряйте постепенно, с тестированием и миграцией. Zero Trust и Least Privilege держите в голове как реальные ограничители на каждом шаге.
Мы почти прошли этот путь и финиш уже близко. Не быстро, но того стоит. Что скажете?)
______
P.S. Я свой гештальт закрыл, передаю эстафету моим коллегам на продолжение рассказов о новых компонентах Astra Cloud Platform 2.1)
