Ролевая модель доступа

Содержание

Ролевая модель доступа#

Ролевая модель доступа (RBAC) предоставляет единый интерфейс управления доступом к ресурсам всех основных компонентов платформы: Automation Controller, Private Automation Hub и Event-Driven Automation. При этом реализация привилегий и ролей обеспечивается самими компонентами.

Иерархия уровней доступа#

RBAC в Astra Automation действует по принципу наложения уровней:

Тип пользователя задает исходный уровень доверия. Например, Astra Automation Administrator всегда имеет глобальные привилегии, а обычный пользователь – только те, которые назначены ему через роли.
Роль предоставляет набор привилегий для выполнения определенных действий.
Привилегия позволяет выполнять конкретное действие над конкретным ресурсом.

Система определяет эффективные привилегии пользователя динамически. Она объединяет все роли, назначенные пользователю напрямую и через команды пользователей, формируя итоговый набор привилегий. Это гарантирует, что пользователь сможет выполнять только те действия, которые ему явно предоставлены.

Типы пользователей#

Каждый пользователь имеет назначенный тип, который определяет его базовые возможности на уровне всей платформы. При создании учетной записи необходимо выбрать тип пользователя.

Доступны следующие типы:

Cистемный администратор (Astra Automation Administrator) – может иметь полный доступ ко всем функциям и ресурсам платформы либо только к отдельным компонентам (Automation Controller, Private Automation Hub, Event-Driven Automation) в зависимости от параметров, выбранных при создании пользователя. Этот тип используется для первоначальной настройки и обслуживания системы.
Системный аудитор (Astra Automation Auditor) – обладает привилегиями только на просмотр. Может просматривать любую информацию о платформе, но не может изменять ресурсы или выполнять действия.
Обычный пользователь (Normal user) – не имеет привилегий по умолчанию. Его доступ ограничен назначенными ролями внутри конкретных организаций и компонентов.

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

Роли#

Роли – основной механизм назначения привилегий. Каждая роль определяет, какие действия пользователь может выполнять и с какими типами ресурсов. Например, роль может разрешать изменение шаблонов заданий или публикацию коллекций.

Роли бывают двух типов:

Встроенные (Built-in) – предопределенные платформой.

Примечание

Полный список встроенных ролей и их описание доступны в справочнике.
Собственные (Custom) – создаются администраторами под конкретные задачи. Такие роли позволяют гибко комбинировать привилегии и точно контролировать доступ к отдельным ресурсам.

Система позволяет создавать роль только в контексте конкретного компонента – Automation Controller, Event-Driven Automation или Private Automation Hub. Это значит, что одна роль не может содержать привилегии для управления, например, шаблонами заданий Automation Controller и средами принятия решений Event-Driven Automation.

Внимание

Роли этого типа не могут включать привилегии на управление командами (team) или организациями (organization), поскольку такие действия заблокированы на уровне системы RBAC. При попытке создания такой роли появится сообщение “Creating custom roles that include team permissions is disabled”.

В зависимости от области действия роль может быть двух типов:

предоставляющая привилегии по отношению ко всем объектам определенного типа (привилегии на тип ресурсов, например на все проекты организации);
предоставляющая привилегии по отношению к одному конкретному ресурсу, например привилегии на один проект или шаблон заданий.

Чтобы предоставить пользователю роли первого типа, необходимо в графическом интерфейсе открыть профиль организации и в списке пользователей нажать на кнопку настройки ролей конкретного пользователя. Более подробно см. в описании окна Организации (Organizations).

Для назначения роли второго типа следует открыть профиль конкретного ресурса и во вкладке Доступ (Access) использовать встроенного помощника, следуя описанию графического интерфейса для соответствующего типа ресурса.

Привилегии#

Привилегия – минимальная единица контроля доступа, позволяющая выполнять конкретное действие над конкретным типом ресурса. Например: просмотреть полномочие, создать инвентарь, удалить среду исполнения.

Изменить существующие привилегии или создать новые нельзя.

Привилегии группируются по типам ресурсов, таким как проекты, шаблоны заданий, инвентарные списки, среды исполнения и так далее.

Каждая роль объединяет одну или несколько привилегий, относящихся к одному типу содержимого. Например, чтобы пользователь мог управлять полномочиями и средами исполнения, требуется две разные роли – по одной для каждого типа ресурса.

Пользователи#

Пользователю можно назначить различные роли, в том числе в разных организациях и командах.

Примечание

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

Необходимые привилегии можно предоставить пользователю следующими способами:

Установить флаг суперпользователя.

Флаг суперпользователя предоставляет полный доступ ко всем ресурсам Astra Automation. Снять флаг суперпользователя с самого себя нельзя.
Назначить пользователю роль на уровне организации.
Сделать пользователя участником команды, обладающей необходимыми ролями.
Назначить пользователю необходимую роль индивидуально.

Организации#

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

На уровне организации роли могут быть назначены отдельным пользователям и командам.

Если на уровне организации роль назначена команде, то привилегии распространяются на всех членов команды.

Пусть пользователю на уровне организации назначены роли «Администратор проекта» (Organization Project Admin), «Администратор учетных данных» (Organization Credential Admin) и «Участник» (Organization Member):

../../_images/user-organization-roles-light.svg

../../_images/user-organization-roles-dark.svg

Назначенные роли предоставляют пользователю следующие привилегии на ресурсы организации:

полный доступ ко всем проектам;
полный доступ ко всем полномочиям;
просмотр сведений об организации.

При развертывании платформы в ней создается организация с названием «Default». Если другие организации отсутствуют, то все создаваемые ресурсы, пользователи и команды будут принадлежать этой организации.

Связи с другими объектами#

Для некоторых объектов связь с организацией обязательна. В таблице приведены все объекты, которые требуют связи с организацией.

Объект	Связь с организацией
Шаблон задания	Обязательна Принадлежит организации через проект
Проект	Обязательна
Инвентарный список	Обязательна
Управляемый узел	Обязательна Принадлежит организации через инвентарный список
Уведомления	Обязательна
Команда	Обязательна
Активация свода правил	Обязательна
Среда принятия решений	Обязательна
Поток событий	Обязательна
Полномочия для запуска сводов правил	Обязательна

Максимальное количество узлов#

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

Контроль лимитов подписки.

Этот параметр ограничивает количество узлов, которыми могут управлять участники организации.
Разделение ресурсов между организациями.

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

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

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

Особенности использования ограничения на количество узлов:

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

Команды#

Команда пользователей существует в рамках одной организации и используется для группового назначения ролей.

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

Например, если команде назначена роль ExecutionEnvironment Admin в рамках конкретной организации, все ее участники смогут управлять всеми средами исполнения этой организации. Если та же роль назначена на конкретную среду исполнения, то участники команды смогут управлять только этим ресурсом: изменять, удалять и использовать его.

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

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

Роли команды «Team 1» предоставляют к ресурсу «Resource 1» привилегии на исполнение (execution) и изменение (editing), а к ресурсу «Resource 2» – на использование (using). Роли команды «Team 2» предоставляют к ресурсу «Resource 1» привилегии полного доступа (full access), а к ресурсу «Resource 2» – на использование и только чтение (read only).

Все пользователи, входящие одновременно в команды «Team 1» и «Team 2», получают следующие привилегии на ресурсы:

«Resource 1» – исполнение, изменение и полный доступ;
«Resource 2» – использование и только чтение.

Пример#

Рассмотрим связь пользователей, команд, ролей и привилегий на примере. Пусть имеются следующие ресурсы:

один пользователь, не являющийся суперпользователем;
две команды, Alpha и Beta;
четыре роли, Role 1 – Role 4;
восемь привилегий, A – H.

Роли предоставляют следующие привилегии:

Role 1 – A, B.
Role 2 – C, D, E.
Role 3 – F, G;
Role 4 – H.

Команда Alpha связана с ролями Role 1 и Role 2, а команда Beta – с ролями Role 3 и Role 4.

Пользователь является участником обеих команд, а значит, он получает привилегии всех связанных с ними ролей, от A до H включительно.

Принципы управления#

RBAC реализует централизованное управление и распределенное применение. Это означает, что информация о пользователях, группах и назначенных ролях хранится и управляется централизованно, но проверка привилегий выполняется там, где совершается действие – в соответствующем компоненте платформы.

Например, если пользователь создает задание из шаблона в Automation Controller, то именно Automation Controller проверяет, есть ли у пользователя привилегии на запуск задания.

Принцип наименьших привилегий#

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

Проверка привилегий и принятие решений#

Каждый запрос пользователя проходит несколько этапов:

Аутентификация – подтверждение личности (например, через локальную учетную запись или внешнюю систему аутентификации).
Определение контекста – система определяет, какие роли назначены пользователю напрямую и через команды пользователей.
Проверка привилегий – компонент (Automation Controller, Private Automation Hub или Event-Driven Automation) сверяет запрашиваемое действие с набором привилегий, предоставленных пользователю.
Принятие решения – если привилегии достаточны, действие выполняется, если нет – отклоняется.
Аудит – результат фиксируется в потоке активности и системных журналах.

При проверке доступа компонент учитывает не только факт наличия роли, но и назначение роли на конкретный объект, членство пользователя в командах, автоматически выданные привилегии, а также дополнительные ограничения на уровне UI и API.

Итоговый набор привилегий пользователя является суммой привилегий, полученных от нескольких источников:

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

Примечание

Отсутствие явного назначения роли еще не означает отсутствие доступа, и наоборот – назначенная роль может не дать ожидаемого действия из‑за ограничений компонентов.

Подробные списки ролей и привилегий приведены в Справочнике.

Область действия ролей#

В RBAC роль определяется не только набором привилегий, но и областью действия (scope), в которой роль применена.

Даже если две роли содержат одинаковые привилегии, их поведение может различаться, если:

роли назначены на разные объекты (разный контекст);
роли имеют разную область действия (например, уровень организации или уровень ресурса);
доступ к объектам зависит от родительских отношений (например, наличие или отсутствие «пути» от родителя к дочернему объекту);
для компонента действуют ограничения.

Исходя из этого при анализе инцидентов доступа и при тестировании нужно фиксировать не только какая роль назначена, но и:

на какой объект назначена роль;
через какой источник доступ получен (пользователь, команда, создатель, родитель);
какой компонент выполняет проверку доступа.

Одна и та же роль может давать различимый эффект в зависимости от области действия:

роль может быть назначена на тип ресурса в организации (например, на все проекты организации);
роль может быть назначена на конкретный ресурс (например, на один проект);
роль может быть получена напрямую или через команду пользователей.

Поэтому две роли с одинаковым набором привилегий могут вести себя по-разному.

Ключевые правила RBAC#

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

Выполнение без просмотра#

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

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

Просмотр списка без возможности просмотра деталей объекта#

Привилегии на просмотр списка объектов и привилегии на просмотр конкретного объекта могут проверяться по-разному. Это приводит к ситуации, когда пользователь видит объект в списке, но при попытке посмотреть информацию об объекте получает отказ в доступе.

Привилегии создателя#

Привилегии создателя реализуются как реальная роль, которая создается и назначается пользователю при создании объекта, если обнаруживается, что пользователю не хватает привилегий на действия по умолчанию.

Такие привилегии имеют следующие ключевые свойства:

набор привилегий создателя зависит от настроек действий по умолчанию и особенности модели создаваемого ресурса;
в разных компонентах роль создателя может действовать по-разному, например в Event-Driven Automation есть особенности при создании проекта;
появление доступа сразу после создания ресурса объясняется эффектом создателя.

Привилегии на дочерние объекты#

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

Из-за этого пользователь может получить возможность создавать дочерние объекты, даже если на уровне конкретного объекта ему еще не назначали роли.

Пример дополнительных ограничений компонентов#

В Private Automation Hub итоговый доступ определяется не только через RBAC, но и политиками компонента, которые могут ограничивать или уточнять действия пользователя.

К таким механизмам относятся:

AccessPolicy – политика доступа, которая дополняет правила компонента;
ALLOW_LOCAL_RESOURCE_MANAGEMENT – настройка, влияющая на возможность управлять локальными ресурсами;
ComplexUserPermissions – механизм агрегирования или расширения пользовательских привилегий, который применяется поверх обычных назначений.

Указанные механизмы не управляются через интерфейс и не являются частью модели RBAC.

В качестве примера можно рассмотреть Django-настройку ALLOW_LOCAL_RESOURCE_MANAGEMENT. Ее значение задано в коде Private Automation Hub по умолчанию, но может быть переопределено через переменные окружения контейнера Private Automation Hub (например, в манифесте Kubernetes) в зависимости от используемого способа развертывания платформы.

При ALLOW_LOCAL_RESOURCE_MANAGEMENT = False возникают следующие ограничения на методы HTTP API:

GET/HEAD – разрешены;
PUT/PATCH – разрешены с ограничениями;
POST/DELETE – запрещены.

Ограничения для PUT/PATCH:

разрешено менять только поле is_superuser (прочие поля запрещены, кроме игнорируемых);
запрещено снимать привилегии с последнего суперпользователя;
суперпользователь может изменять привилегии других пользователей;
обычный пользователь может снимать привилегии только у самого себя.

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

Особенности RBAC в Event-Driven Automation при миграции с предыдущей версии#

При миграции платформы с предыдущей версии 1.x и изменении модели RBAC в Event-Driven Automation возможна ситуация, когда ранее выданные назначения ролей начинают действовать только в контексте организации по умолчанию.

Если после обновления пользователи потеряли доступ к ресурсам Event-Driven Automation, проверьте, в какой организации назначены их роли, и при необходимости переназначьте роли в целевой организации.

Примеры сценариев#

Ниже приведены примеры типовых сценариев, демонстрирующих применение ролевой модели доступа в Astra Automation.

Назначение ролей пользователю#

Например, когда новый DevOps-инженер должен запускать шаблоны, но не изменять их конфигурацию, администратор должен выполнить следующие действия:

Добавить DevOps-инженера в список пользователей.
Создать команду DevOps.
Если команда DevOps уже существует, добавить туда инженера.
Найти необходимый шаблон заданий и назначить команде DevOps роль Job Template Execute.
Проверить, что у пользователей команды DevOps нет привилегий на изменение шаблона.

Управление доступом к ресурсам#

Этот пример демонстрирует разграничение доступа на уровне отдельных ресурсов. Например, когда QA-команде необходимо просматривать инвентарь TestCluster и запускать шаблон RunTests без привилегий на внесение изменений в шаблон, администратор должен выполнить следующие действия:

Создать команду QA.
Назначить команде QA роль Inventory Read для инвентаря TestCluster.
Назначить команде QA роль Job Template Execute для шаблона заданий RunTests.
Проверить, что у пользователей команды QA нет привилегий на внесение изменений.

Делегирование Team Admin#

Следующий сценарий иллюстрирует делегирование привилегий внутри организации. Например, чтобы Team Lead мог самостоятельно управлять своей командой, например, DevOps, добавлять и удалять участников, не обращаясь к системному администратору, администратор должен назначить пользователю Team Lead роль Team Admin.

Управление журналами RBAC#

Astra Automation реализует централизованную систему контроля доступа (RBAC) для всех ключевых компонентов (Automation Controller, Private Automation Hub, Event-Driven Automation) и поддерживает аудит всех операций, связанных с ролями, привилегиями и ресурсами.

Назначение#

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

соответствие требованиям информационной безопасности;
отслеживание изменений привилегий и ролей;
подотчетность действий администраторов;
интеграцию с SIEM-системами.

Регистрация событий в журналах#

Фиксируются следующие категории событий:

Категория	Журналируемые события
Пользователи	Создание, удаление, изменение профиля, вход и выход из системы
Роли	Назначение и отзыв ролей, создание кастомных ролей
Команды	Добавление и удаление пользователей из команды
Организации	Назначение ролей и изменение параметров организации
Ресурсы	Выдача и отзыв привилегий на Job Template, Inventory, Credentials и другие ресурсы
Собственные (custom) роли	Создание, редактирование и удаление ролей с произвольным набором привилегий
Аутентификация	Входы, выходы и ошибки при попытках аутентификации
Журналы	Экспорт журналов и изменение каналов журналирования

Просмотр журналов#

Система журналирования Astra Automation обеспечивает полное отслеживание всех операций, связанных с управлением доступом, назначением ролей и изменением конфигурации объектов. Журналы служат инструментом аудита и контроля безопасности, позволяя анализировать действия пользователей и состояние компонентов платформы. Все события записываются в поток активности (Activity Stream) и, при необходимости, могут пересылаться во внешние системы мониторинга.

Activity Streams#

Activity Streams – это встроенный механизм фиксации всех действий, выполняемых пользователями через графический интерфейс или API. Он обеспечивает прозрачность всех изменений и позволяет анализировать историю операций на уровне платформы, организации, команды или конкретного ресурса.

Каждый компонент Astra Automation ведет собственный поток активности, доступный через REST API:

Platform Gateway

Фиксирует изменения, происходящие на уровне всей платформы: создание и модификацию организаций, пользователей, подключение компонентов (Automation Controller, Private Automation Hub, Event-Driven Automation). Используется для централизованного просмотра и анализа событий из всех подсистем.

Точка API: /api/gateway/v1/activitystream/
Automation Controller

Отслеживает действия пользователей с объектами автоматизации: шаблонами заданий, инвентарями, проектами, учетными данными, командами и расписаниями. Поддерживает фильтры: object_type (тип объекта), user (пользователь), action (действие), timestamp (время выполнения). Эти параметры позволяют быстро находить нужные события при анализе журналов.

Точка API: /api/v2/activity_stream/

API#

Для анализа активности пользователей можно использовать REST API. Точки доступа API позволяют выполнять фильтрацию, экспорт и интеграцию журналов с внешними средствами анализа. Доступны следующие запросы:

GET /api/v2/activity_stream/?page_size=1000
GET /api/gateway/v1/activitystream/?page_size=1000

Доступ к журналам#

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

Роль	Уровень доступа
System Administrator	Полный просмотр, экспорт и настройка параметров журналирования
System Auditor	Просмотр всех журналов системы
Organization Admin	Просмотр журналов организации
Team Admin	Просмотр событий, связанных с ресурсами команды
Пользователь	Просмотр только собственных действий

Защита и целостность журналов#

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

Файлы журналов должны принадлежать пользователю и группе awx:awx, чтобы обеспечить корректный доступ сервисов. Это обеспечивает корректный доступ всех сервисов, выполняемых от имени пользователя awx, к операциям записи и чтения журналов.
Задайте для файлов журналов права доступа chmod 600. В этом режиме только владелец имеет право читать и изменять файлы. Такая настройка предотвращает просмотр журналов посторонними и снижает риск утечки чувствительной информации.
Ротацию журналов выполняйте с помощью logrotate, чтобы предотвратить переполнение хранилища и обеспечить регулярное обновление файлов.
Для защиты от удаления или подмены включите атрибут неизменяемости (chattr +a).
Для контроля целостности используйте инструменты AIDE, Tripwire или мандатный контроль каталогов в Astra Linux.

Экспорт и интеграция с системами SIEM#

Для централизованного анализа событий безопасности журналы платформы Astra Automation можно экспортировать во внешние системы класса SIEM (Security Information and Event Management). Такие системы собирают и коррелируют события из разных источников, чтобы выявлять инциденты, несанкционированные изменения привилегий и подозрительные действия пользователей.

Интеграция с системами SIEM позволяет выполнять следующие действия:

получать единое представление о событиях безопасности во всех компонентах Astra Automation;
отслеживать изменения ролей, назначений и попытки аутентификации в реальном времени;
формировать отчеты и уведомления о подозрительных действиях администраторов;
выполнять долгосрочный аудит, даже при удалении или ротации локальных журналов.

Интеграция осуществляется следующими способами:

в графическом интерфейсе;
через API.

Для интеграции через API возможно прямое подключение к потоку активности (Activity Stream). Пример запроса:

GET /api/gateway/v1/activitystream/?page_size=1000&object_type=role

Этот способ позволяет собирать события напрямую, без использования Syslog-агентов, и обрабатывать их в формате JSON средствами системы SIEM.

При необходимости данные журналов можно фильтровать по типу событий, пользователю, действию и ресурсу. Рекомендуется пересылать следующие категории событий:

аутентификация пользователей;
назначение и отзыв ролей;
создание или изменение собственных (custom) ролей;
операции с организациями и командами;
попытки доступа к неразрешенным ресурсам.

Особенности собственных ролей#

Собственные (custom) роли позволяют администратору создавать наборы привилегий для нестандартных сценариев использования платформы. Поскольку такие роли напрямую влияют на модель безопасности, система фиксирует все действия с ними в журнале активности. Каждое создание, изменение или удаление роли фиксируется в потоке активности (Activity Stream) и доступно для анализа администраторам и аудиторам.

Отслеживание изменений позволяет:

контролировать, кто создает или изменяет роли, и в какой момент это происходит;
выявлять несанкционированные модификации структуры RBAC;
проводить аудит изменений при настройке делегирования привилегий в организациях.

Для поиска соответствующих событий в Activity Stream можно использовать API-запрос с фильтрацией по типу ресурса и операции:

GET /api/v2/activity_stream/?object_type=role&operation=update&page_size=1000

В ответе API будут возвращены записи обо всех действиях, связанных с ролями. Чтобы выделить именно пользовательские роли, анализируйте элементы, где объект имеет атрибут custom.

Пример типичных событий:

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

Рекомендуется регулярно проверять Activity Stream на наличие подобных операций, особенно в системах с делегированным управлением ролями. Такой контроль помогает своевременно выявлять несогласованные изменения в модели доступа.

Общие рекомендации#

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

используйте контроль целостности журналов с помощью AIDE или аналогичных инструментов;
применяйте фильтры по собственным ролям и пользователям в интерфейсе потока активности (Activity Stream) для быстрой аналитики изменений RBAC;
регулярно экспортируйте поток активности через API и сохраняйте результаты в централизованное хранилище событий;
храните архивные копии журналов в изолированном каталоге с ограниченным доступом и контролем привилегий.

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