Путь джедаев: создание компонента IAM в Astra Cloud Platform 2.1
В мажорном релизе Astra Cloud Platform 2.1 мы решили не распыляться на десятки изменений, а разобрать один узловой элемент, который напрямую влияет на безопасность и удобство эксплуатации облака, - IAM (Identity and Access Management). По сути, это "центр управления" идентичностями и доступами, который отвечает на базовые вопросы любой защищённой платформы: кто совершил действие, что именно произошло и имел ли пользователь право сделать это в конкретный момент времени.
Почему "просто интегрировать всё вместе" - плохая идея
На старте у нас уже был набор зрелых, самодостаточных продуктов: Astra Linux SE, ПК СВ "Брест", BILLManager, ALD Pro и другие компоненты. Каждый из них развивался по собственной логике: отдельные роадмапы, свои модели пользователей, собственные механизмы аутентификации и авторизации, свои правила аудита. На бумаге напрашивалось "быстрое решение": взять эти системы и аккуратно объединить внутри облачного контура.
Но если заранее смоделировать, к чему приводит сценарий "интегрируем как есть", картина получается типовая и неприятная:
- появляются множество точек входа с разными, неоднородными механизмами логина и выдачи прав;
- возникает обязанность поддерживать консистентность данных о пользователях сразу в нескольких базах;
- рождаются избыточные и конфликтующие политики доступа (в одной подсистеме разрешено, в другой запрещено);
- аудит превращается в квест: события и права размазаны по сервисам, а управление становится дорогим и рискованным.
Такая "простая интеграция" даёт фрагментированную безопасность: права настраиваются отдельно в каждой подсистеме, базы пользователей приходится непрерывно синхронизировать, а конфликты политик доступа становятся регулярной эксплуатационной болью. Если перевести это с инженерного на продуктовый язык, получается прямой удар по платформе: растёт порог входа для заказчика, увеличивается нагрузка на сопровождение, а вместе с ней - вероятность ошибок и утечек. Поэтому вывод был однозначным: IAM нужно делать, и альтернатив по сути нет.
"Ну что, проектируем IAM?" - не сразу
Парадокс в том, что прежде чем рисовать схемы IAM, приходится ответить на более фундаментальные вопросы: что в облачной платформе является общим для всех подсистем, как это классифицировать и по каким единым правилам эти функции должны выполняться. В итоге мы пришли к разделению сервисов на два больших слоя:
1) Функциональные сервисы, которые дают клиенту бизнес-ценность: виртуальные машины, диски, образы, сети и т.д.
2) Платформенные сервисы, которые склеивают разрозненные системы в единую среду: управление тенантами, аутентификация и авторизация, потребление, биллинг, квоты.
Иными словами, одними сервисами пользуется клиент как потребитель облака, а вторые обеспечивают "фундамент", единые правила жизни платформы и единые контуры управления.
Следующий шаг - не менее важный: мы определили точки исполнения функций платформенных сервисов и описали правила и последовательности вызовов между подсистемами при предоставлении облачных функций. Это позволило одновременно убрать дублирование и чётко закрепить зоны ответственности: кто проверяет право, кто выдаёт токен, кто пишет аудит, кто просто выполняет операцию.
Ловушка "интегрируем всё в IAM одним махом"
Как бы ни хотелось "включить IAM и подключить к нему весь зоопарк компонентов", реальность сложнее. Встроенные механизмы безопасности - особенно в зрелых и тем более сертифицированных решениях - не перестраиваются мгновенно. Переход на централизованный IAM требует анализа и планирования, иначе платформа быстро упрётся в ограничения legacy и регуляторные нюансы.
На практике всплывают три обязательных блока работ:
- Оценка возможности перехода. Не каждая legacy-система способна заменить внутреннюю аутентификацию/авторизацию на внешнюю без переписывания архитектуры.
- Согласование API-контрактов. У разных подсистем свои протоколы, форматы и особенности интеграции - иногда несовместимые напрямую.
- План миграции. Нужна чёткая этапность: какие функции и в каком порядке выносятся наружу, где остаются временные "мосты", как минимизируются риски.
И главное: нельзя просто вырезать функции безопасности из сертифицированного ПО и "подцепить" внешнюю систему, как будто это смена библиотеки. Любые изменения в контуре ИБ для таких решений требуют аккуратной стратегии и дисциплины.
---
Что важно учитывать, когда IAM становится "ядром" платформы (добавлено по теме)
Ниже - дополнительные аспекты, без которых IAM в облаке обычно либо не взлетает, либо превращается в "очередной сервис логина" вместо системообразующего компонента.
1) IAM - это не только вход, но и модель ответственности
Аутентификация - лишь первая ступень. В облаке критично, чтобы IAM задавал единые правила: как определяется субъект (пользователь/сервис), что является ресурсом, как описывается действие, как применяется политика. Без этой модели даже самый удобный SSO не спасает от "зоопарка прав".
2) Тенанты и изоляция: права всегда контекстные
Облачная платформа живёт в многопользовательской, многотенантной реальности. Один и тот же человек может быть администратором в одном тенанте и читателем в другом. Значит, IAM обязан поддерживать контекст: роль + область действия + набор ресурсов, иначе доступы либо окажутся избыточными, либо будут постоянно "ломаться" на границах ответственности.
3) Централизация аудита - ключ к ответу "кто и что сделал"
Если события безопасности остаются в разрозненных логах подсистем, расследование инцидента превращается в ручную корреляцию. Платформенный IAM логично дополнять единым подходом к аудиту: единые идентификаторы субъектов, единый формат событий, единый способ привязки действий к токену/сессии/контексту.
4) Конфликты политик неизбежны - важно уметь их разрешать
Даже при централизованном IAM конфликты встречаются: часть правил может жить в функциональных системах (по историческим причинам), часть - в платформенном контуре. Нужны понятные приоритеты: кто "последняя инстанция", как трактуется запрет, что делать при расхождении правил на стыке систем.
5) Миграция без остановки сервиса: гибридный режим как норма
Переход на IAM в большой платформе почти всегда происходит поэтапно. Это означает, что какое-то время сосуществуют старые и новые механизмы. Важно заранее проектировать гибрид: временные адаптеры, проксирование проверок, совместимость по сессиям и идентичностям, а также понятный план вывода "костылей".
6) Сервисные аккаунты и межсервисные вызовы - отдельная вселенная
В облаке много действий выполняют не люди, а сервисы. Для них нужны свои сущности и политики: сервисные аккаунты, минимальные права, ограничение по времени, ротация секретов. Если попытаться "натянуть" сервисные интеграции на пользовательские логики, получится либо небезопасно, либо неудобно для эксплуатации.
7) Единый каталог идентичностей снижает цену сопровождения
Когда пользовательские данные размножены по подсистемам, появляются синхронизации, расхождения, "фантомные" учётки и устаревшие роли. Централизованный IAM позволяет держать единый источник истины: кто существует, какие у него атрибуты, какие роли выданы и кем.
8) Встраивание в сертифицированные контуры требует осторожности
Если часть компонентов имеет жёсткие требования к ИБ-реализациям, IAM нельзя внедрять "в лоб". Нужны режимы совместимости, документирование зон ответственности, контролируемая замена функций и понятные границы: где безопасность обеспечивается платформой, а где остаётся внутри продукта.
9) Удобство администратора - фактор безопасности
Чем сложнее управление правами, тем выше вероятность ошибок. IAM должен не только быть правильным с точки зрения модели доступа, но и давать администратору ясные инструменты: предсказуемые роли, читаемые политики, понятные отчёты, простой аудит. Иначе безопасность "проваливается" в человеческий фактор.
---
В результате IAM в Astra Cloud Platform 2.1 - это не декоративная надстройка и не "один общий логин", а попытка выстроить единый платформенный слой, который связывает разрозненные продукты в управляемую и проверяемую с точки зрения ИБ систему. А главное - сделать так, чтобы безопасность не превращалась в ручную синхронизацию пользователей и бесконечную борьбу с конфликтами прав, а стала встроенным свойством платформы.
