Как работают права доступа

Обновлено: 21.08.2025

Основные понятияОсновные понятия

• RBAC (Role-Based Access Control) или Ролевая модель — модель доступа, в которой права назначаются ролям, а пользователи получают доступ через назначенные им роли.

• ACL (Access Control List) или Список прав — модель доступа, при которой для каждого объекта хранится список субъектов (пользователей, групп, ролей) и выданных им прав.

• Hierarchical ACL (иерархический ACL) — разновидность ACL, при которой объект может наследовать права доступа от родительского объекта.

Пример для Вики:

• Через RBAC пользователю назначается набор прав «Проектный менеджер».
• Через ACL странице «Архитектура системы» выдаются права:
  • группа «Архитекторы» — редактирование;
  • группа «Аналитики» — просмотр.

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

Пример использования Hierarchical ACL:

• статья Вики наследует права от родительской страницы;
• корневая страница наследует права от Wiki-пространства.

Общая модель доступаОбщая модель доступа

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

• Лицензия (License) — лицензионные ограничения на использование функциональности;
• RBAC — права, назначенные пользователю через наборы прав;
• ACL — права, назначенные для конкретных объектов;
• Workflow Assignment — назначение пользователю задачи в рамках бизнес-процесса.

Уровень базового доступаУровень базового доступа

Основной уровень доступа пользователя формируется комбинацией лицензии, RBAC и ACL. Этот уровень определяет, может ли пользователь:

• видеть сущности в списках, досках и поиске;
• открывать сущности;
• просматривать связанные данные;
• выполнять разрешённые действия.

Формально:

Permission = License AND (RBAC OR ACL)

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

Ролевой доступ (RBAC)Ролевой доступ (RBAC)

Системные ролиСистемные роли

В Timetta предусмотрен фиксированный список системных ролей:

• Пользователь;
• Управление командой;
• Управление проектами;
• Управление ресурсами;
• Управление финансами;
• Управление клиентами;
• Администратор.

Роль определяет доступ к области системы:

Наборы правНаборы прав

Для каждой системной роли может быть создан один или несколько наборов прав. Каждый набор прав состоит из гранул — минимальных единиц настройки доступа. Например:

• Артефакты;
• Изменение типа учёта проекта.

Большинство гранул разделяются на области действия. Например:

• «Мои проекты»;
• «Все проекты».

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

• просмотр;
• редактирование (включает создание);
• удаление (чаще отсутствует и равно редактированию).

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

Назначение наборов правНазначение наборов прав

Наборы прав можно назначать:

• конкретному пользователю;
• группе пользователей (рекомендуется для больших команд).

Итоговые права пользователя формируются объединением всех назначенных ему наборов прав.

Списки прав (ACL)Списки прав (ACL)

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

• пользователям;
• группам пользователей;
• наборам прав;
• ролям.

ACL дополняет RBAC и позволяет более точно управлять доступом к отдельным сущностям.

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

Задание вокрфлоу (Workflow Assignment)Задание вокрфлоу (Workflow Assignment)

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

Особенности:

• действует только для конкретной сущности;
• не предоставляет доступ к спискам и поиску;
• не заменяет RBAC и ACL.

Применение и проверка правПрименение и проверка прав

Проверка прав при созданииПроверка прав при создании

Для создаваемой сущности проверяется её будущее состояние — значения, которые будут сохранены после создания:

• например, при создании проекта учитывается указанный менеджер проекта, поскольку от него могут зависеть правила RBAC;
• собственных записей ACL у новой сущности ещё нет;
• если используется Hierarchical ACL, дополнительно проверяются права, наследуемые от родительского объекта;
• все проверки выполняются до создания сущности.

Проверка прав при редактировании и удаленииПроверка прав при редактировании и удалении

Для редактирования проверяется право доступа к сущности в её текущем состоянии:

• например, пользователь имеет право «Мои проекты», а у проекта в данный момент он указан менеджером проекта — в этом случае редактирование разрешено;
• после сохранения проект может перейти в состояние, при котором пользователь потеряет к нему доступ (например, если изменён менеджер проекта) — это не препятствует выполнению операции.

Итоговая логика доступаИтоговая логика доступа

Для списков и выборок данных:

License AND (RBAC OR ACL)

Для открытия конкретной сущности:

License AND (RBAC OR ACL OR Workflow Assignment)

ПримерыПримеры

• Минимальные права для входа в систему — набор прав роли Пользователь.
• Чтобы сотрудник видел только раздел «Моя работа», достаточно назначить набор прав роли Пользователь и не назначать других наборов.
• Чтобы пользователь мог редактировать только свои проекты, ему необходимо назначить набор прав роли Управление проектами с правом «Редактирование» для области «Мои проекты», не предоставляя доступ к области «Все проекты».