Объекты и действия безопасности

ℹ️ О разделе

В этом разделе описывается работа с объектами и действиями безопасности — основными элементами системы прав доступа IDENTYX. Вы узнаете, как создавать иерархическую структуру объектов и действий, как использовать наследование прав и что такое wildcard-правила.

Что такое объекты и действия

Система прав доступа IDENTYX построена на двух ключевых концепциях:

🔐 Объекты безопасности

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

Примеры: /iam, /menu, /orgs, /myapp

⚡ Действия безопасности

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

Примеры: /menu/allow, /iam/super-admin, /myapp/read

Права доступа в IDENTYX формируются как комбинация объекта и действия. Например, право /menu/support:/menu/allow означает "разрешён доступ к объекту меню поддержки".

Иерархия объектов

Системные объекты

IDENTYX создаёт несколько системных объектов, которые используются для управления самой системой:

  • / — корневой объект системы
  • /iam — объект самой системы IDENTYX и её административных функций
  • /orgs — корень дерева организаций
⚠️ Защита системных объектов

Объекты /, /iam и все объекты, начинающиеся с /iam/, являются системными и защищены от изменения и удаления. Это сделано для обеспечения стабильности и безопасности системы.

Объекты приложений

Когда вы регистрируете OIDC приложение в IDENTYX, для него автоматически создаётся корневой объект. Например, при регистрации приложения "HelpDesk" может быть создан объект /helpdesk.

Внутри корневого объекта приложения вы можете создавать любую иерархию подобъектов:

  • /helpdesk — корневой объект приложения
  • /helpdesk/tickets — подобъект для заявок
  • /helpdesk/tickets/urgent — подобъект для срочных заявок
  • /helpdesk/settings — подобъект для настроек
💡 Гибкость структуры

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

Объекты организаций

Для каждой созданной организации автоматически создаётся объект в дереве /orgs. Например:

  • /orgs/company — объект для организации "Компания"
  • /orgs/company/sales — объект для дочерней организации "Отдел продаж"
⚠️ Управление организациями

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

Иерархия действий

Системные действия

IDENTYX предоставляет несколько предустановленных системных действий:

  • /iam/super-admin — полный административный доступ к системе IDENTYX
  • /iam/local-admin — ограниченное администрирование конкретных организаций
  • /menu/allow — доступ к разделам меню интерфейса
⚠️ Защита системных действий

Все действия, начинающиеся с /iam, являются системными и не могут быть изменены или удалены.

Действия приложений

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

  • /helpdesk/view — просмотр данных
  • /helpdesk/create — создание новых записей
  • /helpdesk/edit — редактирование записей
  • /helpdesk/delete — удаление записей
  • /helpdesk/admin — административный доступ к приложению

Вы также можете создавать вложенную структуру действий:

  • /helpdesk — корневое действие
  • /helpdesk/tickets — действия с заявками
  • /helpdesk/tickets/view — просмотр заявок
  • /helpdesk/tickets/edit — редактирование заявок

Управление объектами

Для управления объектами безопасности перейдите в раздел Объекты безопасности главного меню.

Просмотр дерева объектов

На странице отображается полное дерево объектов безопасности в иерархическом виде. Для каждого объекта показывается:

  • Иконка — визуальный индикатор типа объекта (корень, IAM, организация, приложение)
  • Название — понятное название объекта
  • Путь — полный путь объекта в иерархии
  • Действия — кнопки для управления объектом (для несистемных объектов)
ℹ️ Индикация объектов

Системные объекты отмечены тегом "Системный", объекты организаций — тегом "Организация". Такие объекты нельзя редактировать на этой странице.

Создание объекта

Чтобы создать новый объект:

  1. Нажмите кнопку Добавить объект в правом верхнем углу страницы, чтобы создать корневой объект приложения
  2. Или нажмите кнопку с иконкой + (плюс) рядом с существующим объектом, чтобы создать дочерний объект
  3. В открывшемся окне заполните поля:
    • Имя — понятное название объекта на русском языке
    • Путь — уникальный идентификатор объекта (латинские буквы, цифры, дефисы)
  4. Нажмите Сохранить
✅ Правила именования
  • Имя может быть любым и должно быть понятным для пользователей
  • Путь должен быть уникальным в рамках родительского объекта
  • Используйте короткие понятные идентификаторы для пути (например, tickets, settings)
  • Система автоматически формирует полный путь объекта, добавляя путь родителя
🚫 Ограничения создания
  • Нельзя создавать объекты непосредственно в корне (нужно создать приложение)
  • Нельзя создавать дочерние объекты для системных объектов /iam
  • Нельзя создавать объекты в дереве /orgs (используйте страницу Организации)

Редактирование объекта

Чтобы изменить название объекта:

  1. Нажмите кнопку с иконкой карандаша рядом с объектом
  2. Или откройте контекстное меню правым кликом на объекте и выберите Редактировать
  3. Измените Имя объекта (путь изменить нельзя)
  4. Нажмите Сохранить
⚠️ Изменение пути

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

Удаление объекта

Чтобы удалить объект:

  1. Нажмите кнопку с иконкой корзины рядом с объектом
  2. Или откройте контекстное меню правым кликом на объекте и выберите Удалить
  3. Подтвердите удаление в диалоговом окне
⚠️ Каскадное удаление

При удалении объекта автоматически удаляются все его дочерние объекты! Кроме того, объект удаляется из всех правил доступа (ACL), где он был использован. Эту операцию невозможно отменить.

Управление действиями

Для управления действиями безопасности перейдите в раздел Действия над объектами безопасности главного меню.

Просмотр дерева действий

На странице отображается дерево действий безопасности с теми же возможностями, что и для объектов. Системные действия отмечены тегом "Системное" и защищены от изменений.

Создание действия

Процесс создания действия аналогичен созданию объекта:

  1. Нажмите кнопку Добавить действие в правом верхнем углу
  2. Или нажмите кнопку с иконкой + рядом с существующим действием для создания дочернего
  3. Заполните поля:
    • Имя — понятное описание действия
    • Путь — уникальный идентификатор действия
  4. Нажмите Сохранить
💡 Рекомендации по действиям
  • Используйте стандартные пути для действий: view, edit, create, delete, admin
  • Создавайте действия в том же пространстве имён, что и объекты (например, для объектов /helpdesk/* используйте действия /helpdesk/*)
  • Имя действия должно отражать, что именно разрешается или запрещается

Редактирование действия

Редактирование действия выполняется так же, как и редактирование объекта — можно изменить только имя, но не путь.

Удаление действия

При удалении действия:

  1. Удаляются все дочерние действия в иерархии
  2. Действие удаляется из всех правил доступа (ACL), где оно использовалось
  3. Операция необратима
⚠️ Перед удалением

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

Wildcard-правила и наследование

Что такое wildcard

Wildcard (символ подстановки) позволяет создавать правила доступа, которые автоматически применяются ко всем дочерним объектам в иерархии. В IDENTYX для этого используется флаг "Распространение на дочерние объекты" при создании правила доступа.

Когда этот флаг включён, система внутренне преобразует путь объекта, добавляя /* в конце. Например:

  • /menu/support с флагом распространения → /menu/support/*
  • /helpdesk/tickets с флагом распространения → /helpdesk/tickets/*

Как работает wildcard

При проверке прав система автоматически учитывает иерархию объектов. Например, если пользователю дано право:

/menu/support/*:/menu/allow:allow

То он получит доступ к:

  • /menu/support — родительскому объекту
  • /menu/support/tickets — дочернему объекту
  • /menu/support/tickets/urgent — любым вложенным объектам на любой глубине
✅ Преимущества wildcard
  • Простота управления — не нужно создавать отдельное правило для каждого подобъекта
  • Автоматическое применение — новые дочерние объекты автоматически попадают под действие правила
  • Масштабируемость — легко расширять структуру объектов без изменения прав

Иерархическая проверка прав

При проверке права система автоматически проверяет всю иерархию снизу вверх. Например, при проверке права на объект /menu/support/tickets/urgent система последовательно проверит:

  1. /menu/support/tickets/urgent:/menu/allow — точное совпадение
  2. /menu/support/tickets/*:/menu/allow — wildcard на уровне tickets
  3. /menu/support/*:/menu/allow — wildcard на уровне support
  4. /menu/*:/menu/allow — wildcard на уровне menu
  5. /*:/* — универсальное право на всё

Доступ будет разрешён, если найдено хотя бы одно разрешающее право на любом уровне иерархии (при отсутствии запрещающих прав).

💡 Автоматическая проверка

Вам не нужно вручную проверять иерархию или думать о wildcard-вариантах. Система IDENTYX делает это автоматически при каждой проверке прав.

Примеры использования wildcard

📋 Пример 1: Доступ к меню

Задача: Дать доступ ко всем разделам поддержки.

Решение: Создать правило:

  • Объект: /menu/support
  • Действие: /menu/allow
  • Распространение: Включено

Результат: Доступ к /menu/support, /menu/support/tickets, /menu/support/knowledge-base и всем другим подразделам.

🔒 Пример 2: Исключение

Задача: Дать доступ ко всем разделам приложения, кроме администрирования.

Решение: Создать два правила:

  1. Разрешить: /helpdesk/*:/helpdesk/view:allow
  2. Запретить: /helpdesk/admin:/helpdesk/view:deny

Результат: Пользователь может просматривать все разделы, кроме /helpdesk/admin.

Wildcard для действий

Wildcard-правила работают не только для объектов, но и для действий. Например, можно дать право на все действия в рамках одного пространства имён:

  • /helpdesk/tickets:/helpdesk/*:allow — разрешены все действия /helpdesk/* над объектом /helpdesk/tickets
⚠️ Осторожно с широкими правами

Использование wildcard для действий может дать слишком широкие права. Предпочтительнее явно указывать конкретные действия (view, edit) вместо wildcard на все действия.

Наследование прав по дереву

От родителя к детям

Когда для объекта установлено право с флагом "Распространение на дочерние объекты", это право автоматически применяется ко всем дочерним объектам, независимо от глубины вложенности.

Пример иерархии:

/helpdesk
  /helpdesk/tickets
    /helpdesk/tickets/new
    /helpdesk/tickets/in-progress
    /helpdesk/tickets/closed
  /helpdesk/settings

Если дано право /helpdesk/*:/helpdesk/view:allow, то доступ разрешён ко всем объектам в этой иерархии.

Несколько уровней прав

Можно комбинировать права на разных уровнях иерархии. Например:

  • Право 1: /helpdesk/*:/helpdesk/view:allow — просмотр всего
  • Право 2: /helpdesk/settings:/helpdesk/edit:allow — редактирование только настроек

В результате пользователь сможет:

  • Просматривать все разделы /helpdesk/*
  • Редактировать только /helpdesk/settings

Переопределение через deny

Права запрета (deny) можно использовать для создания исключений из wildcard-правил:

  1. Базовое право: /menu/*:/menu/allow:allow — доступ ко всем разделам меню
  2. Исключение: /menu/admin:/menu/allow:deny — запрет доступа к разделу администрирования

Результат: Пользователь получит доступ ко всем разделам меню, кроме /menu/admin.

🚫 Приоритет deny

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

Лучшие практики

Продумывайте структуру заранее

  • Планируйте иерархию — перед созданием объектов продумайте логическую структуру приложения
  • Используйте понятные пути — пути должны быть интуитивно понятными (/helpdesk/tickets, а не /hd/t1)
  • Группируйте по функциям — создавайте подобъекты для логических модулей приложения

Используйте wildcard разумно

  • Предпочитайте wildcard — вместо создания множества правил на каждый подобъект создайте одно правило с распространением
  • Не делайте слишком широкие права — избегайте wildcard в корне (/*), если это не суперадминистратор
  • Используйте исключения — применяйте deny-правила для точечных ограничений в рамках широкого разрешения

Соглашения по именованию

  • Для путей объектов: используйте существительные (tickets, users, settings)
  • Для путей действий: используйте глаголы (view, create, edit, delete)
  • Единообразие: придерживайтесь одного стиля именования во всём приложении
  • Латиница в путях: используйте только латинские буквы, цифры, дефисы и подчёркивания в путях

Документируйте структуру

  • Понятные имена — давайте объектам и действиям понятные имена на русском языке
  • Описание прав — при создании правил ACL указывайте понятные названия правил (например, "Просмотр тикетов для менеджеров")
  • Схема прав — ведите документацию по структуре объектов и действий для своего приложения

Тестируйте права

  • Проверяйте wildcard — после создания wildcard-правила проверьте, что оно применяется ко всем нужным объектам
  • Тестируйте deny — убедитесь, что deny-правила работают корректно и не блокируют больше, чем нужно
  • Используйте тестовых пользователей — создайте тестовую учётную запись для проверки прав перед назначением большой группе

Типичные паттерны использования

Паттерн CRUD

Типичная структура для приложения с операциями создания, чтения, обновления и удаления:

Объекты:

  • /myapp
  • /myapp/entities

Действия:

  • /myapp/view — просмотр
  • /myapp/create — создание
  • /myapp/edit — редактирование
  • /myapp/delete — удаление

Паттерн ролей

Разные уровни доступа для разных ролей:

  • Читатель: /myapp/*:/myapp/view:allow
  • Редактор: /myapp/*:/myapp/view:allow + /myapp/*:/myapp/edit:allow
  • Администратор: /myapp/*:/myapp/*:allow

Паттерн модулей

Разделение прав по модулям приложения:

/erp
  /erp/sales     — модуль продаж
  /erp/warehouse — модуль склада
  /erp/finance   — модуль финансов

Каждому отделу даются права только на свой модуль с помощью wildcard.

✅ Готовы продолжить?

Переходите к разделу Правила доступа (ACL), чтобы узнать, как создавать правила доступа и назначать права пользователям и группам.