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

Содержание

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

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

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

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

Например, если пользователь:

создает задание из шаблона в Automation Controller, то именно Automation Controller проверяет, есть ли у пользователя привилегии на запуск задания;
публикует коллекцию в Private Automation Hub, то проверка выполняется в Private Automation Hub;
создает правило в Event-Driven Automation, то решение принимает сам компонент Event-Driven Automation.

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

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

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

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

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

Аутентификация – подтверждение личности (например, через локальную учетную запись или внешнюю систему аутентификации).
Определение контекста – система определяет, какие роли назначены пользователю напрямую и через команды пользователей.
Проверка привилегий – компонент (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 включительно.

Встроенные роли Astra Automation#

Ниже приведены роли, определенные в компонентах платформы, и ресурсы, к которым они применяются.

Роли в Automation Controller#

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

Ресурс	Роль	Описание
Credential	Credential Admin	Управление полномочиями
Credential	Credential Use	Использование полномочий
Execution Environment	ExecutionEnvironment Admin	Управление средой выполнения
Inventory	Inventory Admin	Управление инвентарным списком
Inventory	Inventory Update	Обновление инвентарного списка
Inventory	Inventory Use	Использование инвентарного списка при запуске заданий
Inventory	Inventory Adhoc	Выполнение ad-hoc команд
Instance Group	InstanceGroup Admin	Управление группой исполняющих узлов
Instance Group	InstanceGroup Use	Использование группы исполняющих узлов
Job Template	JobTemplate Admin	Управление шаблоном задания
Job Template	JobTemplate Execute	Запуск шаблона задания без возможности редактирования
Notification Template	NotificationTemplate Admin	Управление одним шаблоном уведомлений
Organization	Organization ExecutionEnvironment Admin	Управление средами выполнения внутри организации
Organization	Organization Project Admin	Управление проектами внутри организации
Organization	Organization NotificationTemplate Admin	Управление шаблонами уведомлений внутри организации
Organization	Organization JobTemplate Admin	Управление шаблонами заданий внутри организации
Organization	Organization Credential Admin	Управление полномочиями внутри организации
Organization	Organization WorkflowJobTemplate Admin	Управление шаблонами потока заданий внутри организации
Organization	Organization Inventory Admin	Управление инвентарными списками внутри организации
Organization	Organization Member	Использование назначенных ресурсов
Project	Project Admin	Управление проектом
Project	Project Update	Запуск обновления проекта (SCM Sync)
Project	Project Use	Использование проекта в шаблонах заданий
Team	Team Admin	Управление командой
Team	Team Member	Наследование привилегий, назначенных команде
Workflow Job Template	WorkflowJobTemplate Admin	Управление шаблоном потока заданий
Workflow Job Template	WorkflowJobTemplate Execute	Запуск шаблона потока заданий без возможности редактирования
Workflow Job Template	WorkflowJobTemplate Approve	Одобрение или отклонение запуска шаблона потока заданий, если включено подтверждение

Роли в Private Automation Hub#

В компоненте Private Automation Hub ролевое управление регулирует доступ к коллекциям, контейнерам и пространствам имен. Роли определяют, кто может публиковать, изменять, модерировать и использовать контент. Полный список ролей представлен в таблице ниже:

Ресурс	Роль	Описание
Repository	galaxy.ansible_repository_owner	Управление репозиториями Ansible
Remote	galaxy.collection_remote_owner	Управление внешними репозиториями
Execution Environment	galaxy.execution_environment_publisher	Публикация новых версий сред исполнения
Execution Environment	galaxy.execution_environment_namespace_owner	Полный контроль над пространствами имен сред исполнения
Execution Environment	galaxy.execution_environment_collaborator	Изменение существующих сред исполнения
Namespace	galaxy.collection_namespace_owner	Управление пространством имен
Namespace	galaxy.collection_publisher	Добавление коллекций в пространстве имен
Team	Galaxy Team Member	Наследование привилегий, назначенных команде
Team	Team Admin	Управление одной командой и наследует все назначения ролей этой команды
Team	Team Member	Наследование привилегий, назначенных команде
System	galaxy.collection_admin	Управление всеми коллекциями
System	galaxy.collection_curator	Согласование и синхронизация коллекций
System	galaxy.content_admin	Управление всеми типами контента
System	galaxy.execution_environment_admin	Управление средами исполнения

Роли в Event-Driven Automation#

В компоненте Event-Driven Automation роли управляют объектами автоматизации: активациями, проектами, окружениями принятия решений и потоками событий. Полный список ролей представлен в таблице ниже:

Ресурс	Роль	Описание
Activation	Activation Admin	Управление активации свода правил и связанными с ней ресурсами
Activation	Activation Use	Использование активации свода правил
Decision Environment	Decision Environment Admin	Управление средой принятия решений
Decision Environment	Decision Environment Use	Использование среды принятия решений
EDA Credential	EDA Credential Admin	Управление полномочиями Event-Driven Automation
EDA Credential	EDA Credential Use	Использование полномочиями Event-Driven Automation
Event Stream	Event Stream Admin	Управление потоком событий
Event Stream	Event Stream Use	Использование потока событий
Organization	Organization Admin	Полный контроль над организацией и всеми ее ресурсами
Organization	Organization Member	Участник организации с доступом к ее ресурсам
Organization	Organization Editor	Создание и изменение ресурсов внутри организации
Organization	Organization Contributor	Создание, изменение ресурсов организации, а также управление активациями rulebook
Organization	Organization Operator	Управление запуском активаций и просмотр ресурсов
Organization	Organization Viewer	Просмотр ресурсов организации
Organization	Organization Project Admin	Управление проектами внутри организации
Organization	Organization Decision Environment Admin	Управление средами принятия решений внутри организации
Organization	Organization Eda Credential Admin	Управление полномочиями Event-Driven Automation внутри организации
Organization	Organization Activation Admin	Управление активациями сводов правил внутри организации
Organization	Organization Event Stream Admin	Управление потоками событий внутри организации
Project	Project Admin	Управление проектом и связанными rulebook
Project	Project Use	Использование проекта при создании активаций сводов правил
Team	Team Admin	Управление командой
Team	Team Member	Наследование привилегий, назначенных команде

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

Ниже приведены примеры типовых сценариев, демонстрирующих применение ролевой модели доступа в 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 и сохраняйте результаты в централизованное хранилище событий;
храните архивные копии журналов в изолированном каталоге с ограниченным доступом и контролем привилегий.

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