Фильтрация данных по правам

ℹ️ О фильтрации данных

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

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

Обзор системы фильтрации

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

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

  • Автоматическая фильтрация — данные фильтруются автоматически при каждом запросе
  • Серверная обработка — фильтрация происходит на сервере до отправки данных клиенту
  • Прозрачность для пользователя — пользователь не видит недоступные ресурсы
  • Производительность — оптимизированные SQL-запросы с учетом прав
  • Консистентность — единые правила фильтрации во всей системе

Области применения фильтрации

Область Что фильтруется Основа фильтрации
Узлы сети Дерево узлов, списки серверов Права на объекты (/objects/.../)
Тикеты Список тикетов Helpdesk Права на организации (/orgs/.../)
Меню Пункты навигационного меню Права на меню (/menu/.../)
Мониторинг Дашборды, метрики Права на узлы + права на меню
Сессии История удаленных подключений Права на узлы
✅ Безопасность по умолчанию

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

Фильтрация узлов сети

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

Принцип фильтрации узлов

Алгоритм фильтрации

  1. Проверка прав администратора — если пользователь администратор (/:/:allow), показываются все узлы
  2. Проверка прав на каждый узел — для каждого узла проверяется наличие любого права (edit или remoteConnect)
  3. Включение родительских папок — если узел доступен, включаются все родительские папки для построения дерева
  4. Построение дерева — из отфильтрованных узлов строится иерархическое дерево

Где применяется фильтрация узлов

Компонент Описание
Дерево узлов Основное иерархическое представление узлов в левой панели
Просмотр по сетям Группировка узлов по сетевым сегментам
Просмотр по агентам Группировка узлов по наличию агентов
Просмотр по приложениям Группировка узлов по установленным приложениям
Выбор узла в формах Выпадающие списки для выбора узлов (например, при создании тикета)
Дашборды мониторинга Отображение метрик только для доступных узлов
История сессий Показ подключений только к доступным узлам

Пример фильтрации

Исходная структура

/objects
├── /datacenter1
│   ├── /production
│   │   ├── server1
│   │   └── server2
│   └── /development
│       └── server3
└── /datacenter2
    └── server4

Права пользователя

/objects/datacenter1/production/server1:/objects/edit:allow
/objects/datacenter2/server4:/objects/remoteConnect:allow

Отфильтрованное дерево

/objects
├── /datacenter1
│   └── /production
│       └── server1
└── /datacenter2
    └── server4

Примечание: Папки /datacenter1, /production и /datacenter2 включены автоматически для построения правильной иерархии, даже если на них нет явных прав.

⚠️ Видимость родительских папок

Родительские папки отображаются в дереве, даже если у пользователя нет прав на саму папку. Это необходимо для правильного отображения иерархии. Однако операции с этими папками (редактирование, удаление, добавление дочерних узлов) будут недоступны.

Фильтрация тикетов

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

Принцип фильтрации тикетов

Правила фильтрации

  1. Доступ к организации — пользователь видит тикеты только тех организаций, к которым у него есть доступ
  2. Собственные тикеты — пользователь всегда видит тикеты, где он является автором или исполнителем
  3. Права Helpdesk — пользователи с правом /menu/support/tickets:/menu/allow могут видеть тикеты разрешенных организаций
  4. Права "Мои тикеты" — пользователи с правом /menu/my/tickets:/menu/allow видят только свои тикеты

Сценарии фильтрации

Роль Права Видимые тикеты
Администратор /:/:allow Все тикеты всех организаций
Администратор Helpdesk /menu/support/tickets:/menu/allow
/orgs/*:/organizations/access-to-organization:allow 		Все тикеты всех организаций
Сотрудник поддержки /menu/support/tickets:/menu/allow
/orgs/1:/organizations/access-to-organization:allow
/orgs/5:/organizations/access-to-organization:allow 		Тикеты организаций ID=1 и ID=5
Пользователь /menu/my/tickets:/menu/allow
/orgs/1:/organizations/allow-create-tickets-by-org:allow 		Только свои тикеты организации ID=1

Фильтрация при назначении исполнителей

При назначении исполнителя тикета система автоматически фильтрует список доступных сотрудников:

Критерии отбора исполнителей

  • Пользователь должен иметь право /menu/support/tickets:/menu/allow
  • Пользователь должен иметь доступ к организации тикета
  • Учитываются как конкретные права, так и wildcard (/orgs/*)
💡 Автоматическая изоляция

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

Технические детали

Методы фильтрации

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

Метод Назначение
filterNodesByAcl() Фильтрация массива узлов по правам доступа
getFilteredNodesInfo() Получение полной информации об узлах с фильтрацией
prepareNodesForWebSocket() Подготовка данных узлов для WebSocket с фильтрацией
getCurrentUserOrganizations() Получение списка доступных организаций для текущего пользователя
canViewNode() Проверка возможности просмотра конкретного узла

Оптимизация производительности

Подходы к оптимизации

1. Кэширование прав

Права пользователя хранятся в сессии и не запрашиваются при каждой проверке.

2. Фильтрация на уровне запросов

Для больших наборов данных фильтрация применяется непосредственно в SQL-запросах.

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

Для администраторов (/:/:allow) фильтрация пропускается, возвращая все данные без дополнительных проверок.

4. Обработка wildcards

Права с wildcard (*) обрабатываются оптимизированными алгоритмами для минимизации количества проверок.

WebSocket и реального времени

Фильтрация данных применяется также для обновлений в реальном времени через WebSocket:

Особенности WebSocket фильтрации

  • При подключении клиента данные фильтруются на основе его прав
  • Обновления отправляются только для доступных узлов
  • При изменении прав пользователя требуется переподключение
  • Фильтрация происходит на сервере до отправки данных

Рекомендации

Лучшие практики работы с фильтрацией данных

1. Полагайтесь на автоматическую фильтрацию

  • Не пытайтесь реализовать дополнительную фильтрацию на клиенте
  • Доверяйте серверной фильтрации данных
  • При возникновении вопросов о доступности данных проверяйте права пользователя

2. Тестирование прав

  • После назначения прав проверьте фильтрацию под учетной записью пользователя
  • Убедитесь, что недоступные узлы действительно не отображаются
  • Проверьте работу фильтрации в различных представлениях (дерево, сети, агенты)

3. Организация структуры узлов

  • Группируйте узлы логически для упрощения назначения прав
  • Используйте папки для создания уровней доступа
  • Помните, что родительские папки будут видны пользователям

4. Права на организации

  • Четко разграничивайте доступ к организациям для изоляции данных клиентов
  • Используйте wildcard (/orgs/*) только для администраторов Helpdesk
  • Регулярно проверяйте назначенные права на организации

5. Мониторинг доступа

  • Следите за тем, какие данные видят пользователи
  • При обнаружении проблем с доступом проверяйте логику фильтрации
  • Используйте методы проверки прав для диагностики
⚠️ Важно для разработчиков

Если вы разрабатываете дополнительные модули или интеграции с INFRAX, всегда используйте стандартные методы фильтрации данных. Не обходите встроенные механизмы безопасности и не реализуйте собственную логику фильтрации без крайней необходимости.