Endge

Тема

Права доступа (RBAC), политики и аудит ​

Единый анализ: роли, политики, проверки доступа и аудит действий пользователя в контексте платформы Endge.

Связь тем: права и аудит ​

  • Права (RBAC/политики) отвечают на вопрос «кто что может делать»: роли, разрешения на ресурсы/действия, проверки при входе на маршрут, при вызове API и при отображении UI.
  • Аудит отвечает на вопрос «кто что сделал и когда»: неизменяемый лог действий пользователя (и системных событий) для соответствия требованиям и разбора инцидентов.
  • Связь: аудит часто логирует те же сущности (пользователь, действие, ресурс), что и модель прав; идентификатор пользователя и роли — общий контекст. Поэтому разумно проектировать оба направления вместе: общая модель «субъект — действие — ресурс», единый контекст сессии, а реализацию разделять на слой проверки прав и слой записи аудита.

Текущее состояние ​

Роли и авторизация ​

  • Auth: Endge.auth (Keycloak), проверка токена, логин/логаут, isAuthenticated; в роутере — guard по meta.requiresAuth, редирект на логин.
  • Роли: константы в приложении (например, roles.ts: SUPER_ADMIN, ADMIN, USER); проверки в коде по роли; нет единого слоя «can user X do Y on resource Z».

Политики ​

  • В домене упоминается Policy (документ/сущность); в roadmap backend’а — политики на папки, проекты, CRUD модулей. На фронте нет выделенного модуля проверки политик: решения размазаны по компонентам и роутеру.

Аудит ​

  • Отдельного модуля аудита нет: нет записи «пользователь X выполнил действие Y над ресурсом Z в момент T» с сохранением на бэкенд или в диагностику.

Целевая модель ​

RBAC и политики ​

  • Роли: источник истины — бэкенд (Keycloak, Payload или свой сервис); фронт получает роли/разрешения при логине или из токена (claims) и кэширует в сессии.
  • Политики: правила вида «роль/группа может выполнять действие над ресурсом (или типом ресурса) в scope (проект, папка)». Вычисление на бэкенде; фронт либо получает «разрешённые действия» для текущего контекста (страница, документ), либо отправляет запрос «can I do X on Y» и получает да/нет.
  • Единый слой на фронте (модуль прав, например @endge/permissions или часть core):
    • can(action, resource?, context?) - boolean (или Promise с boolean-результатом при запросе к API).
    • Директивы/компоненты для UI: скрытие кнопок, пунктов меню, маршрутов по разрешениям.
    • Guards роутера: проверка доступа к маршруту по роли/политике перед входом на страницу.
  • Интеграция с Endge: при загрузке домена/проекта подтягивать политики для текущего пользователя и scope; runtime и UI обращаются к одному фасаду, а не к разным местам с ролями.

Аудит ​

  • События для записи: вход/выход, открытие/изменение/удаление сущностей (документы, настройки), критичные действия (публикация, откат, смена прав). Список можно расширять по требованиям.
  • Формат записи: кто (userId, sessionId), что (action, resourceType, resourceId), когда (timestamp), контекст (project, folder, IP, user agent при необходимости), опционально — до/после для изменений.
  • Куда писать: бэкенд (отдельная таблица/сервис аудита), либо сначала только в Endge.diagnostics с каналом audit и экспортером на сервер. Важно: аудит не подменяет общий лог ошибок; канал/тип записей отдельный.
  • Модуль на фронте: один API, например Audit.log({ action, resourceType, resourceId, details? }). Реализация — отправка на backend или запись в diagnostics с типом audit; без дублирования логики в каждом компоненте.

Связь с диагностикой и пользователем ​

  • Диагностика уже имеет контекст (userId, sessionId, project и т.д.); события аудита могут идти тем же путём (diagnostics.writeEvent с channel audit) с последующей доставкой в хранилище аудита через exporter. Альтернатива — отдельный HTTP endpoint только для аудита. Выбор зависит от требований к задержке, объёму и изоляции данных.
  • Роли и идентификатор пользователя — общий контекст для и проверки прав, и для подписи записей аудита; получать их из одного места (сессия/Endge.auth после логина).

Рекомендации по внедрению ​

  1. Модуль прав (RBAC/политики)

    • Ввести фасад can(action, resource?, context?) и заполнять его данными из бэкенда (роли, разрешения по контексту).
    • Добавить Vue-директиву/компонент для скрытия UI по разрешениям и guard для роутера.
    • Документировать набор действий и ресурсов, согласованный с бэкендом.

  2. Аудит

    • Определить список аудит-событий и формат записи; реализовать Audit.log(...) и вызывать его в ключевых точках (успешные критические действия).
    • Решить: только отправка на backend или также запись в diagnostics с каналом audit и экспортером.
    • Не логировать чувствительные данные (пароли, токены) в теле аудита.

  3. Общая модель

    • Использовать единые идентификаторы пользователя, сессии и контекста (project, folder) и для проверки прав, и для подписи записей аудита.
    • При появлении бэкенда политик и аудита — один контракт «субъект — действие — ресурс — контекст» для обоих подсистем.

Риски и ограничения ​

  • Источник истины для ролей и политик — бэкенд; фронт только кэширует и проверяет. При отсутствии API прав проверки на фронте будут неполными (обход через прямой вызов API). Аудит не должен содержать чувствительные данные (пароли, токены). Связь с Diagnostics_Logging_Telemetry: канал audit и экспортер в хранилище аудита.

Вывод ​

  • Права доступа (RBAC, политики) и аудит логично проектировать вместе: общий контекст пользователя и ресурсов, разное назначение (проверка доступа vs запись истории).
  • На фронте: один модуль прав (фасад + директивы + guards) и один модуль аудита (API записи события); оба опираются на сессию и при необходимости на Endge.diagnostics и бэкенд.
  • Модуль диагностики может использоваться как транспорт для аудита (канал audit и exporter в хранилище аудита), не смешивая с общим логированием ошибок.