Модель прав доступа

📚 Настройка прав в IDENTYX

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

📖 Управление правами доступа в IDENTYX

ℹ️ О модели прав

В этом разделе подробно описывается техническая модель прав доступа INFRAX: формат записи, механизм работы wildcards, алгоритм проверки прав и взаимодействие Deny/Allow разрешений.

Содержание раздела

Формат записи прав

Каждое право в INFRAX записывается в виде строки, состоящей из трех компонентов, разделенных двоеточием:

Полный формат

путь:действие:разрешение
Компонент Описание Примеры
Путь (path) Иерархический путь к объекту или ресурсу /objects/Production
/menu/settings
/orgs/1
Действие (action) Тип операции, которую можно выполнить /objects/edit
/menu/allow
/organizations/access-to-organization
Разрешение (allow/deny) Тип разрешения: allow или deny allow
deny

Упрощенный формат

При проверке прав можно использовать упрощенный формат без указания типа разрешения:

путь:действие

Система автоматически добавит :allow при проверке. Например:

  • /menu/settings:/menu/allow → проверяется как /menu/settings:/menu/allow:allow
  • /objects/Production:/objects/edit → проверяется как /objects/Production:/objects/edit:allow
⚠️ Важно

При назначении прав в системе IDENTYX всегда необходимо указывать полный формат с :allow или :deny. Упрощенный формат используется только при программной проверке прав.

Структура путей

Пути в системе прав имеют иерархическую структуру, аналогичную файловой системе Unix:

Типы путей

1. Пути к узлам сети (/objects/...)

Отражают структуру папок и узлов в системе:

/objects/
/objects/Production
/objects/Production/WebServers
/objects/Production/WebServers/web01
/objects/Development
/objects/Development/TestServers

2. Пути к меню (/menu/...)

Соответствуют структуре меню интерфейса:

/menu/settings
/menu/support/tickets
/menu/administration/network-objects
/menu/administration/automation/tasks
/menu/administration/automation/scheduler
/menu/administration/automation/scripts
/menu/dashboards/specialized/monitoring
/menu/dashboards/specialized/support
/menu/my/tickets

3. Пути к организациям (/orgs/...)

Используют ID организации:

/orgs/1
/orgs/42
/orgs/*
💡 Корневой уровень

Путь / (корень) используется только для прав администратора и представляет доступ ко всей системе.

Типы действий

Действия группируются по областям применения:

Действия для узлов (/objects/...)

Действие Описание Что разрешает
/objects/edit Редактирование узла • Изменение настроек узла
• Настройка мониторинга
• Управление учетными данными
• Настройка сервисов подключения
/objects/execute Выполнение скриптов • Выполнение скриптов через агента
• AI команды в хелпдеске
• Автоматизация через задания
/objects/vm-manage Управление виртуальными машинами и контейнерами Виртуальные машины:
• Запуск, остановка, перезагрузка ВМ
• Создание и удаление снапшотов
• Откат к снапшоту
• Изменение ресурсов ВМ
• Изменение размера дисков

Docker контейнеры:
• Запуск, остановка, перезагрузка контейнеров
• Удаление контейнеров
• Управление Docker образами
• Массовые операции с образами
• Очистка неиспользуемых образов
• Управление Docker Compose проектами
• Запуск новых контейнеров
/objects/remoteConnect/rdp Удаленное подключение через RDP • Только RDP подключения к узлу
• Используется для ограничения доступа к Windows-серверам
/objects/remoteConnect/ssh Удаленное подключение через SSH • Только SSH подключения к узлу
• Используется для ограничения доступа к Linux-серверам
/objects/remoteConnect/vnc Удаленное подключение через VNC • Только VNC подключения к узлу
• Удаленный рабочий стол через веб-интерфейс
/objects/remoteConnect/winbox Удаленное подключение через Winbox • Только Winbox подключения
• Управление устройствами MikroTik RouterOS
/objects/remoteConnect/web Удаленное подключение через Web • Только доступ к веб-интерфейсу
• Для устройств с веб-панелью управления
/objects/remoteConnect/proxmox Подключение к консоли Proxmox • Доступ к VNC консоли виртуальных машин
• Управление через консоль Proxmox
/objects/remoteConnect/vmware Подключение к консоли VMware • Доступ к VNC консоли виртуальных машин VMware
• Управление через консоль ESXi/vCenter
💡 Гранулярные права на подключение

Права на удаленное подключение детализированы по типам протоколов:

  • /objects/remoteConnect/{тип} - доступ к конкретному типу подключения (rdp, ssh, vnc, winbox, web, proxmox, vmware)
  • Детализированные права работают независимо и могут комбинироваться
  • Для доступа ко всем типам подключений назначьте все необходимые права отдельно
💡 Право на просмотр

Для узлов действие /objects/view дает право на просмотр узла без возможности редактирования или подключения. Это полезно для пользователей, которым нужен только обзор инфраструктуры.

Действия для меню (/menu/...)

Действие Описание
/menu/allow Доступ к пункту меню и связанному функционалу

Действия для организаций (/organizations/...)

Действие Описание
/organizations/access-to-organization Базовый доступ к организации и её данным
/organizations/allow-create-tickets-by-org Создание тикетов от имени организации

Механизм wildcards

Символ * (asterisk, wildcard) используется для массового назначения прав на множество объектов.

Принцип работы wildcards

Wildcard заменяет один уровень иерархии и все его содержимое. Он может использоваться как в пути, так и в действии:

Wildcards в пути

/objects/*                              - все объекты на первом уровне
/objects/Production/*                   - все объекты в папке Production
/objects/Production/WebServers/*        - все узлы в папке WebServers

Wildcards в действии

/objects/Production:/*                  - все действия с папкой Production
/menu/settings:/*                       - все действия с меню настроек

Полный wildcard (права администратора)

/*:/*:allow                             - все пути, все действия, разрешено

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

Пример 1: SSH доступ ко всем узлам

/objects/*:/objects/remoteConnect/ssh:allow

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

Пример 2: Редактирование всего в Production

/objects/Production/*:/objects/edit:allow

Результат: Пользователь может редактировать все узлы в папке Production и её подпапках.

Пример 3: Доступ ко всем организациям

/orgs/*:/organizations/access-to-organization:allow

Результат: Пользователь видит тикеты всех организаций.

⚠️ Безопасность wildcards

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

Алгоритм расширения прав

При проверке права система автоматически генерирует все возможные варианты этого права с учетом wildcards. Это ключевой механизм, обеспечивающий иерархическое наследование.

Как работает расширение

Для права /objects/Production/WebServers/web01:/objects/edit система генерирует следующие варианты для проверки:

Allow варианты:

/objects/Production/WebServers/web01:/objects/edit:allow          (точное совпадение)
/objects/Production/WebServers/web01:/*:allow                     (wildcard action)
/objects/Production/WebServers/web01/*:/objects/edit:allow        (следующий уровень)
/objects/Production/WebServers/web01/*:/*:allow                   (следующий уровень + wildcard action)
/objects/Production/WebServers/*:/objects/edit:allow              (родительский уровень 1)
/objects/Production/WebServers/*:/*:allow
/objects/Production/*:/objects/edit:allow                         (родительский уровень 2)
/objects/Production/*:/*:allow
/objects/*:/objects/edit:allow                                    (родительский уровень 3)
/objects/*:/*:allow
/*:/objects/edit:allow                                            (корневой уровень)
/*:/*:allow                                                       (полный wildcard)

Deny варианты:

Аналогичный набор генерируется с :deny вместо :allow.

Пример расширения

Проверяем право:

/menu/administration/automation/tasks:/menu/allow

Расширенные варианты:

Уровень Право
Точное /menu/administration/automation/tasks:/menu/allow:allow
Wildcard action /menu/administration/automation/tasks:/*:allow
Уровень 1 /menu/administration/automation/*:/menu/allow:allow
Уровень 1 + wildcard /menu/administration/automation/*:/*:allow
Уровень 2 /menu/administration/*:/menu/allow:allow
Уровень 2 + wildcard /menu/administration/*:/*:allow
Уровень 3 /menu/*:/menu/allow:allow
Уровень 3 + wildcard /menu/*:/*:allow
Корень /*:/menu/allow:allow
Администратор /*:/*:allow
✅ Преимущество алгоритма

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

Алгоритм проверки прав

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

Пошаговый процесс проверки

  1. Проверка администратора

    Система проверяет, есть ли у пользователя право /:/:allow. Если да — немедленно возвращает true без дальнейших проверок.

  2. Расширение проверяемого права

    Система генерирует все возможные варианты проверяемого права с учетом wildcards (см. "Алгоритм расширения прав").

  3. Проверка Deny прав

    Система последовательно проверяет, есть ли в правах пользователя хотя бы одно Deny право из сгенерированного списка.

    Если найдено Deny право → возвращает false (доступ запрещен).

  4. Проверка Allow прав

    Если Deny прав не найдено, система проверяет наличие хотя бы одного Allow права из сгенерированного списка.

    Если найдено Allow право → возвращает true (доступ разрешен).

  5. Отказ по умолчанию

    Если не найдено ни Deny, ни Allow прав → возвращает false (доступ запрещен по умолчанию).

Диаграмма алгоритма

Начало проверки права
    ↓
[Пользователь администратор?] → Да → Разрешено ✅
    ↓ Нет
[Расширить право с wildcards]
    ↓
[Есть Deny право?] → Да → Запрещено ❌
    ↓ Нет
[Есть Allow право?] → Да → Разрешено ✅
    ↓ Нет
Запрещено ❌ (по умолчанию)
🔒 Приоритет безопасности

Важно понимать порядок проверок: Deny всегда проверяется раньше Allow. Это означает, что даже если у пользователя есть множество Allow прав, одно Deny право полностью блокирует доступ.

Примеры прав

Базовые примеры

Право Описание Что разрешает
/:/:allow Права администратора Полный доступ ко всей системе
/objects/*:/objects/edit:allow Редактирование всех узлов Редактирование любых узлов во всех папках
/objects/*:/objects/remoteConnect/rdp:allow RDP подключение ко всем узлам Удаленный рабочий стол к любым узлам
/menu/support/tickets:/menu/allow:allow Доступ к Helpdesk Просмотр и управление тикетами
/menu/my/tickets:/menu/allow:allow Доступ к "Мои тикеты" Просмотр только собственных тикетов
/orgs/1:/organizations/access-to-organization:allow Доступ к организации #1 Просмотр тикетов организации #1

Примеры с wildcards

Право К чему даёт доступ
/objects/Production/*:/objects/edit:allow Редактирование всех узлов в Production и подпапках:
• /objects/Production/web01
• /objects/Production/Databases/db01
• /objects/Production/Monitoring/zabbix01
/menu/administration/*:/menu/allow:allow Доступ ко всем подразделам меню Администрирование:
• /menu/administration/network-objects
• /menu/administration/automation/tasks
• /menu/administration/automation/scheduler
/orgs/*:/organizations/access-to-organization:allow Доступ ко всем организациям:
• /orgs/1
• /orgs/2
• /orgs/42

Примеры с Deny

Комбинация прав Результат
/objects/*:/objects/edit:allow
/objects/Production/*:/objects/edit:deny 		Разрешено: редактировать все узлы
Запрещено: редактировать узлы в Production
Итог: доступ ко всем узлам кроме Production
/objects/*:/objects/remoteConnect/ssh:allow
/objects/Confidential/*:/objects/remoteConnect/ssh:deny 		Разрешено: SSH подключение ко всем узлам
Запрещено: SSH подключение к узлам в Confidential
Итог: можно подключаться по SSH ко всем узлам кроме Confidential
/orgs/*:/organizations/access-to-organization:allow
/orgs/5:/organizations/access-to-organization:deny 		Разрешено: доступ ко всем организациям
Запрещено: доступ к организации #5
Итог: видны тикеты всех организаций кроме #5

Сложные сценарии

Сценарий 1: Разработчик с ограниченным доступом

Требования:

  • Доступ к Helpdesk для просмотра своих тикетов
  • Просмотр всех узлов сети
  • Подключение только к узлам Development
  • Запрет подключения к Production

Назначенные права:

/menu/my/tickets:/menu/allow:allow
/objects/*:/objects/edit:allow
/objects/Development/*:/objects/remoteConnect/rdp:allow
/objects/Development/*:/objects/remoteConnect/ssh:allow
/objects/Production/*:/objects/remoteConnect/rdp:deny
/objects/Production/*:/objects/remoteConnect/ssh:deny

Результат:

  • ✅ Видит свои тикеты в разделе "Мои тикеты"
  • ✅ Видит все узлы в дереве
  • ✅ Может редактировать настройки всех узлов
  • ✅ Может подключаться к узлам Development по RDP и SSH
  • ❌ Не может подключаться к узлам Production (deny блокирует)

Сценарий 2: Администратор Helpdesk

Требования:

  • Полный доступ к Helpdesk
  • Доступ ко всем организациям
  • Просмотр узлов сети (для привязки к тикетам)
  • Запрет удаленного подключения к узлам
  • Доступ к дашборду Helpdesk

Назначенные права:

/menu/support/tickets:/menu/allow:allow
/menu/dashboards/specialized/support:/menu/allow:allow
/orgs/*:/organizations/access-to-organization:allow
/objects/*:/objects/edit:allow
/objects/*:/objects/remoteConnect:deny

Результат:

  • ✅ Полный доступ к системе тикетов
  • ✅ Видит тикеты всех организаций
  • ✅ Видит дашборд Helpdesk с аналитикой
  • ✅ Видит все узлы для привязки к тикетам
  • ✅ Может редактировать узлы (настраивать мониторинг)
  • ❌ Не может подключаться к узлам (deny блокирует)

Сценарий 3: Пользователь с доступом к конкретным папкам

Требования:

  • Доступ только к узлам в папке ClientA
  • Полные права на узлы ClientA (редактирование и подключение)
  • Доступ к своим тикетам
  • Доступ к тикетам организации ClientA

Назначенные права:

/menu/my/tickets:/menu/allow:allow
/objects/ClientA/*:/objects/edit:allow
/objects/ClientA/*:/objects/remoteConnect/rdp:allow
/objects/ClientA/*:/objects/remoteConnect/ssh:allow
/orgs/15:/organizations/access-to-organization:allow

Результат:

  • ✅ Видит только узлы в папке ClientA
  • ✅ Может редактировать узлы ClientA
  • ✅ Может подключаться к узлам ClientA по RDP и SSH
  • ✅ Видит свои тикеты
  • ✅ Видит тикеты организации ClientA (ID=15)
  • ❌ Не видит другие папки и узлы
  • ❌ Не видит тикеты других организаций

Сценарий 4: Специалист по автоматизации

Требования:

  • Доступ к разделу задач и планировщика
  • Доступ к разделу скриптов
  • Просмотр всех узлов (для настройки задач)
  • Запрет редактирования узлов
  • Подключение к узлам для отладки

Назначенные права:

/menu/administration/automation/tasks:/menu/allow:allow
/menu/administration/automation/scheduler:/menu/allow:allow
/menu/administration/automation/scripts:/menu/allow:allow
/objects/*:/objects/view:allow
/objects/*:/objects/remoteConnect/ssh:allow

Результат:

  • ✅ Доступ к управлению задачами
  • ✅ Доступ к планировщику (cron)
  • ✅ Доступ к созданию и редактированию скриптов
  • ✅ Видит все узлы в дереве
  • ✅ Может подключаться к узлам по SSH для отладки
  • ❌ Не может редактировать настройки узлов
💡 Комбинирование прав

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