RBAC и разделение прав в helpdesk: кому что показывать

RBAC vs ABAC vs ACL — что для helpdesk

Три основные модели контроля доступа:

• ACL (Access Control List) — на каждый объект список «кто что может». Подходит для файловых систем. В helpdesk — мракобесие: миллион объектов и тысячи ACL.
• RBAC (Role-Based Access Control) — у юзера роль (USER / OPERATOR / AUDITOR), у роли — набор разрешений. Просто, понятно, на 90% случаев достаточно.
• ABAC (Attribute-Based) — права вычисляются по атрибутам: департамент, локация, чувствительность объекта. Гибко, но сложно настраивать и поддерживать.

В helpdesk оптимально RBAC + контекстные ограничения (команды, группы услуг, тэги доступа). Сложнее чем чистый RBAC, проще чем полноценный ABAC. Именно по этой модели работает TIQQET.

Типовые роли в helpdesk

• USER (инициатор) — создаёт заявки, отвечает на запросы оператора, видит только свои тикеты и где он подписчик. Базовая роль.
• OPERATOR — обрабатывает заявки, видит весь поток или поток своей команды. Может назначать, менять приоритет, закрывать.
• OPERATOR-LITE (L1) — то же, но без права закрывать сложные кейсы, отклонять с потерей SLA, менять каталог услуг.
• OPERATOR-LEAD (L2/L3) — расширенные права: bulk-операции, шаблоны заявок, автоматизация, отчёты по команде.
• AUDITOR — read-only. Видит всё (включая приватные комментарии), не может ничего изменять. Для внутреннего контроля и compliance.
• ADMINISTRATOR — настройки системы, пользователи, лицензии, интеграции.

В малой организации (до 10 операторов) хватает 3 ролей: USER / OPERATOR / ADMIN. В крупной — расщепление обязательно.

Разделение по командам

Кроме роли, нужно ограничивать видимость по командам. Логика:

• Команда «Сетевики» видит и обрабатывает только заявки по услугам «Сеть».
• Команда «1С» — только заявки по 1С.
• Тимлид видит свою команду + свои собственные.
• «Глобальный оператор» (например, дежурный 24/7) — видит все.

В TIQQET это реализовано через сущность Team. У оператора может быть membership в нескольких командах. У услуги — список команд, которые её обслуживают. При создании заявки заявка автоматически попадает в правильную команду.

Дополнительно — группы пользователей (см. каталог услуг с разграничением видимости). Это позволяет одной услуге быть видимой только пользователям из определённой группы (например, «Услуги для VIP-клиентов»).

Приватные комментарии и конфиденциальность

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

Стандартная функциональность — приватные комментарии:

• Видны только операторам и аудиторам.
• Не отправляются по email.
• Не попадают в публичный экспорт заявки.

Дополнительно нужен privacy-mode — режим, когда USER-инициатор видит обезличенного «Сотрудника технической поддержки» вместо ФИО конкретного оператора. Полезно для контакт-центров, где операторы регулярно меняются, и пользователи начинают писать «давайте мне Машу» вместо «у меня вопрос».

Антипаттерны RBAC

1. Слишком много ролей. Создали 15 ролей, у каждой по 3 человека. Реально работают 4. Остальные — мёртвый код. Лучше 3-5 ролей + контекстные ограничения.
2. Права через ФИО. «Иванов — может всё, Петров — только своё». Чем человек ушёл — нужно вспоминать и переделывать.
3. «Я оператор, дайте мне всё». Принцип наименьших прав. По умолчанию минимум, расширяем по необходимости.
4. Audit-log без ролей. Каждое действие должно содержать кто и какая роль на момент действия — иначе после смены роли невозможно восстановить, кто что мог.
5. Глобальный admin без 2FA. Самые опасные роли защищаются отдельно — двухфакторкой, IP-ограничением, audit-trail.