Перейти к содержанию

Управление пользователями

AppSec.AIGate использует ролевую модель доступа (RBAC) с интеграцией через Keycloak и OAuth2 Proxy. В этом разделе описано, как работает аутентификация, какие роли существуют и как управлять пользователями через UI.

Одна инсталляция — одна организация

AppSec.AIGate поставляется как изолированная инсталляция для одной организации (single-tenant). Разграничение доступа обеспечивается ролевой моделью (RBAC); отдельного разделения данных «по организациям» внутри инсталляции нет.

Роли и полномочия

В системе определены четыре роли. Каждый пользователь может иметь одну или несколько ролей.

admin

Назначение:  Полный контроль над системой
Типичный пользователь: CISO, DevSecOps-инженер, администратор платформы

Роль admin даёт неограниченный доступ ко всем функциям системы. Только администраторы могут:

  • Управлять пользователями — создавать, удалять, блокировать учётные записи, назначать роли.
  • Удалять ресурсы — провайдеров, профили, контентные политики, экспортеры (безвозвратное удаление).
  • Просматривать аудит — журнал всех действий всех пользователей (см. Аудит и журнал действий).
  • Настраивать retention — политики хранения данных (см. Настройки хранения данных).
  • Управлять всеми ресурсами — создавать, редактировать, активировать провайдеров, профили, политики и экспортеры.

Рекомендация: Минимизируйте количество пользователей с ролью admin. Для повседневных операций (настройка профилей, реагирование на инциденты) используйте роль operator.

operator

Назначение:  Операционное управление безопасностью
Типичный пользователь: SOC-аналитик, AppSec-инженер, DevOps

Роль operator предназначена для ежедневной работы с системой. Операторы могут:

  • Создавать и редактировать — провайдеров, профили безопасности, контентные политики, экспортеры.
  • Генерировать отчёты — создавать и скачивать отчёты о соответствии.
  • Анализировать события — просматривать события безопасности, фильтровать по типам и времени.
  • Мониторить Dashboard — видеть статистику, графики, последние инциденты.

Ограничения:

  • Не может удалять провайдеров, профили, политики (только admin).
  • Не может управлять пользователями — создавать, удалять, назначать роли.
  • Не может просматривать аудит — журнал действий доступен только admin.
  • Не может изменять retention settings — только admin.

viewer

Назначение:  Только просмотр (read-only)
Типичный пользователь: Аудитор, менеджер, внешний проверяющий

Роль viewer ограничена чтением данных без возможности изменений:

  • Просматривать — все провайдеры, профили, политики, экспортеры, события, Dashboard.
  • Скачивать отчёты — ранее сгенерированные отчёты (PDF, CSV).

Ограничения:

  • Не может создавать, редактировать или удалять любые ресурсы.
  • Не может генерировать отчёты (только скачивать существующие).
  • Не может управлять пользователями.
  • Не может просматривать аудит и retention settings.

Когда использовать: Для предоставления доступа внешним аудиторам или руководству без риска случайного изменения конфигурации.

Матрица прав доступа (RBAC)

Полная таблица разрешений по ролям:

Ресурс / Операция admin operator viewer
Providers
Просмотр списка и деталей ✓ ✓ ✓
Создание ✓ ✓ —
Редактирование ✓ ✓ —
Удаление ✓ — —
Profiles
Просмотр списка и деталей ✓ ✓ ✓
Создание ✓ ✓ —
Редактирование / активация ✓ ✓ —
Удаление / архивация ✓ — —
Content Policies
Просмотр ✓ ✓ ✓
Создание / редактирование ✓ ✓ —
Удаление ✓ — —
Exporters
Просмотр ✓ ✓ ✓
Создание / редактирование ✓ ✓ —
Удаление ✓ — —
Reports
Генерация (создание) ✓ ✓ —
Скачивание ✓ ✓ ✓
Удаление ✓ ✓ —
Security Events
Просмотр и фильтрация ✓ ✓ ✓
Dashboard
Просмотр метрик и графиков ✓ ✓ ✓
Audit Log
Просмотр журнала действий ✓ — —
Retention Settings
Просмотр и изменение ✓ — —
Users
Просмотр списка ✓ — —
Создание / редактирование ✓ — —
Удаление / блокировка ✓ — —
Назначение ролей ✓ — —

Правило приоритета ролей: Если пользователю назначено несколько ролей (например, admin и viewer), применяется максимальный уровень привилегий.

Управление пользователями

Страница Пользователи доступна только пользователям с ролью admin по адресу /users в Admin UI.

Список пользователей

На странице отображается таблица со всеми зарегистрированными пользователями:

Столбец Описание
Username Имя пользователя (уникальное)
Email Электронная почта
ФИО Имя и фамилия пользователя
Статус Бейдж: Активный (зелёный) или Заблокирован (красный)
Email verified Бейдж: ✓ Подтверждён или ⏳ Не подтверждён
Действия Кнопки: просмотр, редактирование, управление ролями, блокировка/разблокировка, удаление

Создание пользователя

  1. Нажмите кнопку Добавить пользователя в правом верхнем углу.

  2. Заполните форму:

    Поле Обязательное Валидация Описание
    Username Да Мин. 3 символа, уникальное Логин для входа в систему
    Email Да RFC 5322, уникальный Email (используется для уведомлений и восстановления пароля)
    Имя Да — Имя пользователя
    Фамилия Да — Фамилия пользователя
    Пароль Да Мин. 8 символов Начальный пароль пользователя
    Подтвердите пароль Да Должен совпадать с паролем Повтор пароля
    Роль Да Admin, Operator или Viewer Роль, назначаемая пользователю при создании

  3. Нажмите Создать пользователя.

  4. Пользователь создаётся в Keycloak с enabled=true и emailVerified=false.

Редактирование пользователя

  1. Нажмите иконку карандаша (✏️) в строке пользователя.
  2. Измените нужные поля: username, email, имя, фамилия.
  3. Нажмите Сохранить.

Ограничения:

  • Пароль нельзя изменить через Admin UI — используйте Keycloak Admin Console (http://localhost:8080) или функцию сброса пароля.

Управление ролями

  1. Нажмите иконку щита (🛡) в строке пользователя — откроется модальное окно Управление ролями пользователя.

  2. В окне отображаются текущие роли пользователя с кнопками:

    • Назначить — добавить роль (выбор из: admin, operator, viewer).
    • Отозвать — убрать роль.

  3. Изменения применяются немедленно — при следующем запросе OAuth2 Proxy получит обновлённый токен с новыми ролями.

Пример: Новый SOC-аналитик — создайте пользователя, назначьте роль operator. Он получит доступ к Dashboard, событиям, профилям и политикам, но не сможет удалять ресурсы или управлять пользователями.

Блокировка / разблокировка

  1. Нажмите иконку питания (⏻) в строке пользователя.
  2. Система попросит подтверждение.
  3. Заблокированный пользователь (enabled=false) не сможет авторизоваться в Keycloak — его текущая сессия продолжит работать до истечения TTL cookie OAuth2 Proxy.

Когда использовать: Временная блокировка при расследовании инцидента, увольнение сотрудника. Для немедленного прекращения доступа также очистите сессии в Keycloak Admin Console.

Удаление пользователя

  1. Нажмите иконку корзины (🗑) в строке пользователя.
  2. Подтвердите удаление в диалоговом окне.
  3. Пользователь безвозвратно удаляется из Keycloak.

Внимание

Удаление необратимо. Аудитные записи, созданные этим пользователем, сохраняются (содержат имя и email на момент действия), но учётная запись восстановлению не подлежит — потребуется создать заново.

Архитектура аутентификации

Система аутентификации состоит из трёх компонентов:

  • OAuth2 Proxy — проверяет сессию пользователя и перенаправляет на вход, если сессии нет.
  • Keycloak — поставщик учётных записей (Identity Provider): хранит пользователей и роли, выполняет вход и выдаёт токены доступа.
  • Серверная часть (Admin API) — при каждом запросе проверяет права доступа (роль пользователя).

Поток аутентификации:

  1. Пользователь открывает Admin UI в браузере.
  2. OAuth2 Proxy проверяет наличие активной сессии.
  3. Если сессия отсутствует или истекла — пользователь перенаправляется на страницу входа Keycloak.
  4. Пользователь вводит логин и пароль в Keycloak.
  5. Keycloak выдаёт токен доступа с данными пользователя: имя, email, роли (groups).
  6. OAuth2 Proxy создаёт сессию и возвращает пользователя в Admin UI.
  7. При каждом запросе серверная часть проверяет роль пользователя на основе данных из токена.

Keycloak интеграция

Начальная конфигурация

При первом запуске в production-режиме (make prod) автоматически выполняется инициализация Keycloak через контейнер keycloak-init:

  1. Создание realm llm-firewall с настройками:

    • Вход по email разрешён.
    • Дублирование email запрещено.
    • Защита от brute force включена.
    • Сброс пароля включён.
    • Редактирование username отключено.

  2. Создание ролей в realm: admin, operator, viewer.

  3. Создание OAuth2 клиента admin-api:

    • Тип: public client (без client secret).
    • Протокол: OpenID Connect.
    • Redirect URIs: http://localhost:4180/*, http://localhost:4180/oauth2/callback.
    • Standard flow + Direct access grants.

  4. Создание начального администратора:

    • Username: значение ADMIN_USER_EMAIL (по умолчанию admin@llm-firewall.local).
    • Пароль: значение ADMIN_USER_PASSWORD (по умолчанию AdminPassword123!).
    • Роль: admin.

Важно

Смените пароль начального администратора сразу после первого входа!

Настройка для production

Для production-развёртывания рекомендуется изменить следующие параметры:

Параметр Где Значение по умолч. Рекомендация
KEYCLOAK_ADMIN_PASSWORD docker-compose admin Сложный пароль (16+ символов)
ADMIN_USER_PASSWORD docker-compose AdminPassword123! Сложный пароль
ADMIN_USER_EMAIL docker-compose admin@llm-firewall.local Реальный email
SSL Required Keycloak Admin Console none all (принудительный HTTPS)
Redirect URIs Keycloak Admin Console http://localhost:4180/* Реальный домен: https://admin.company.com/*

Дополнительные политики паролей

Базовые требования к паролям (минимум 8 символов) можно ужесточить через Keycloak Admin Console:

  1. Откройте http://localhost:8080 → Realm llm-firewall → Authentication → Password Policy.
  2. Добавьте правила:
Правило Описание Рекомендация
Minimum Length Минимальная длина 12+ символов
Uppercase Characters Обязательная заглавная буква 1+
Lowercase Characters Обязательная строчная буква 1+
Digits Обязательная цифра 1+
Special Characters Обязательный спецсимвол 1+
Not Username Пароль ≠ username Включить
Password History Запрет повторных паролей 5 последних
Hashing Algorithm Алгоритм хеширования pbkdf2-sha256 (по умолч.)

Аудит действий пользователей

Все изменения, выполняемые пользователями, записываются в журнал аудита (подробнее см. Аудит и журнал действий). Для каждого действия фиксируется:

Поле Описание Пример
user_id Имя пользователя john.doe
user_email Email john@company.com
user_role Роль на момент действия admin
action HTTP-метод POST, PUT, DELETE
resource_type Тип ресурса providers, profiles, users
resource_id ID ресурса a1b2c3d4-...
request_body Тело запроса (с редакцией) {"username": "new.user", "password": "***REDACTED***"}
response_status HTTP-статус ответа 201, 403
timestamp Время действия 2026-03-13T14:30:00Z

Редакция чувствительных данных: Поля password, secret, token, api_key в теле запроса автоматически заменяются на ***REDACTED*** перед записью в аудит.

Типичные конфигурации

Сценарий 1: Небольшая команда (5–10 человек)

1 admin    — DevSecOps lead (управление системой, пользователями)
2 operator — SOC-аналитики (настройка профилей, реагирование)
2 viewer   — Руководители (просмотр Dashboard, скачивание отчётов)

Один набор провайдеров и профилей на инсталляцию.

Сценарий 2: Аудит / compliance-проверка

Создать временного пользователя с ролью viewer:
  username: auditor-2026-q1

Аудитор получает read-only доступ к:
  - Dashboard (метрики)
  - Security Events (инциденты)
  - Reports (скачивание)

После проверки — заблокировать или удалить аккаунт.

Типичные проблемы и решения

Проблема: HTTP 403 при попытке операции

Симптом: Пользователь авторизован, но получает 403 при попытке создать/удалить ресурс.

Причины:

# Причина Диагностика Решение
1 Недостаточные права роли viewer не может создавать ресурсы Назначьте роль operator или admin
2 Нет назначенных ролей Откройте модальное окно Управление ролями пользователя в строке пользователя и проверьте текущие роли Назначьте роль (см. Управление ролями)

Проблема: начальный пароль не подходит

Симптом: Не удаётся войти под admin@llm-firewall.local с паролем по умолчанию.

Решение:

  1. Проверьте, что keycloak-init контейнер выполнился успешно:

    docker-compose logs keycloak-init | tail -20

  2. Если realm не создался (Keycloak не был готов) — перезапустите:

    docker-compose restart keycloak-init

  3. Для ручного сброса — через Keycloak Admin Console:

    http://localhost:8080 → admin/admin → Realm: llm-firewall → Users → admin → Credentials → Reset Password

Проблема: OAuth2 Proxy redirect loop

Симптом: Браузер зацикливается на странице логина Keycloak.

Причины:

# Причина Решение
1 Redirect URI не совпадает В Keycloak: Clients → admin-api → Valid Redirect URIs → добавьте ваш домен
2 Cookies не передаются (SameSite) Настройте HTTPS или --cookie-samesite=lax в OAuth2 Proxy
3 Keycloak не доступен Проверьте docker-compose ps keycloak, логи