Проектирование RBAC с 31 правом для баз знаний ИИ

Почему базам знаний ИИ нужен настоящий контроль доступа

Рабочее пространство ИИ концентрирует самые чувствительные операционные знания: внутренние документы, историю чатов с RAG-цитатами, конфигурации агентов и подключения к внешним системам. Когда эта поверхность открыта всей компании, «кто что видит» перестаёт быть приятным запросом на функцию и становится той же категорией проблемы, что и права в базе данных: решением, которое должно быть корректным по построению.

Simmetric Chat относится к этому именно так. Каждый аутентифицированный запрос проходит проверку роли и прав, прежде чем коснуться бизнес-данных, и та же модель, что защищает историю чатов, управляет и тем, какие части приложения пользователь вообще может видеть в боковой панели. Эта статья описывает, как устроена система: 31 право, покрывающих поверхность ресурсов платформы, 13 разделов меню, отображающих эти права на пользовательский интерфейс, и защита на уровне запросов, не позволяющая аутентифицированным пользователям добраться до записей, которые им не принадлежат.

Модель прав: 31 гранулярное право

В основе модели — фиксированный словарь из 31 права. Каждое право называет ресурс и действие по конвенции ресурс:действие. Рабочие пространства, проекты, чаты и документы несут каждый полную тройку чтение/запись/удаление, потому что это ресурсы, которые пользователи создают и уничтожают в ходе обычной работы:

• workspace:read, workspace:write, workspace:delete
• project:read, project:write, project:delete
• chat:read, chat:write, chat:delete
• document:read, document:write, document:delete

Вокруг этого ядра — права для самого процесса создания (workspace:create, project:create), для администрирования платформы (admin:users, admin:settings, admin:roles) и для чтения или настройки LLM-провайдеров (provider:read, provider:write). Архивы получают ту же тройку, что и основные ресурсы, потому что архивированные разговоры остаются чувствительными данными.

Кластер из шести прав резервного копирования разделяет управление назначениями, выполнение заданий, просмотр журналов и операции восстановления — разделение важно, потому что «уметь запустить бэкап» и «уметь восстановить производственные данные в произвольное пространство» — разные уровни доверия. Наконец, memory:read и memory:write покрывают систему памяти на пользователя и на пространство, а filters:manage ограничивает администрирование фильтров только администраторами.

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

{
"name": "archivist",
"permissions": ["workspace:read", "document:read", "archive:read", "chat:read"]
}

Из коробки поставляются две роли по умолчанию. Роль администратора держит все 31 право; роль пользователя держит рабочий поднабор — чтение рабочих пространств и провайдеров, чтение/запись чатов и документов, чтение архивов, создание пространств и проектов, а также полное управление собственными памятями. Ни одна роль не имеет особого статуса в логике приложения; обе — обычные строки, которые middleware прав разрешает как любые другие.

Разделы меню: права, формирующие интерфейс

Контроль доступа, защищающий только API-маршруты, даёт запутанный опыт — пользователи нажимают кнопки, которые не работают. Поэтому Simmetric Chat отображает права и на 13 разделов меню, управляющих видимостью боковой панели. Разделы — структурная анатомия приложения:

dashboard, chat, documents, knowledgeBase, workspaces, projects, marketplace, mcpConnections, eventLog, analytics, widget, settings и uploads.

Каждая роль несёт свой список разделов меню, хранимый строками, чтобы новые разделы можно было добавлять без миграции базы. Роль пользователя может видеть dashboard, chat, documents, knowledgeBase, workspaces, widget и uploads, а роль администратора — все 13. В результате сам интерфейс отражает, что роль может делать: пользователь без прав аналитики никогда не встретит точку входа в аналитику, по которой можно кликнуть.

Проверки прав и видимость меню — два выражения одной и той же роли, а значит, есть единый источник истины для рассуждений во время аудита.

Защита на уровне запросов: RBAC как middleware

Каждый API-запрос разрешает пользователя вместе с ролями и правами (с кэшем) и прикрепляет разрешённую личность к запросу. Поверх сидят четыре защитных middleware, каждый отвечает на свой вопрос:

• requirePermission — администраторы проходят всегда; все остальные должны держать каждое перечисленное право для маршрута. Неаутентифицированные запросы получают 401; аутентифицированные пользователи без достаточных прав получают 403 с явной ошибкой «Insufficient permissions».
• requireAdmin — жёсткий шлюз административных маршрутов, отвечающий 403 «Admin access required» для не-админов.
• requireProjectAccess — IDOR-проверка против владения проектом и явных строк доступа.
• requireWorkspaceAccess — та же категория проверки для рабочих пространств, принимающая владение пространством, владение родительским проектом или явное предоставление доступа.

Последние два заслуживают внимания, потому что они закрывают класс уязвимостей, поражающий мультитенантные системы. IDOR-атака (insecure direct object reference) происходит, когда /api/workspaces/123 доверяет идентификатору в URL больше, чем личности вызывающего. Пользователь, который аутентифицирован, но не авторизован для пространства 123, не должен иметь возможности читать его документы, угадывая идентификаторы. Simmetric Chat отвечает на такие запросы 401, когда пользователь не аутентифицирован, и 403 «Insufficient permissions», когда пользователю просто не хватает доступа, вместо того чтобы раскрывать существование или содержимое ресурса.

Защита маршрутов декларативна. CRUD пространств требует requireWorkspaceAccess; создание пространства требует права workspace:create и соблюдает лимиты плана; администрирование ролей живёт за requireAdmin. Таблица маршрутов читается как политика безопасности — именно то свойство, которое нужно, когда новый инженер спрашивает «что может этот эндпоинт?»

Журналы аудита: знать, кто что сделал

Проверки прав отвечают «должно ли это действие быть разрешено?»; журналы аудита отвечают «что фактически произошло?». Simmetric Chat записывает журнал аудита значимых действий платформы — события аутентификации, операции с документами, изменения настроек и административные действия — в просматриваемый журнал событий.

Сочетание делает RBAC операционным, а не теоретическим. Когда происходит неожиданное удаление документа, журнал событий называет актора и действие; модель прав объясняет, какая роль его позволила; и корректировка либо прав роли, либо её разделов меню закрывает разрыв. Поверхность аудита сама закрыта правами через раздел меню eventLog, поэтому запись активности, связанной с безопасностью, видна только ролям, которым её доверили.

Чувствительные изменения хранения — например, настройка дней хранения сообщений чата — сами аудируются, поэтому даже контролы, управляющие жизненным циклом данных, оставляют собственный след.

Как это выглядит на практике

Рассмотрим развёртывание с тремя ролями. Администраторы держат полный набор из 31 права и все 13 разделов меню. Роль ежедневного пользователя работает в чатах, документах и собственных пространствах и никогда не видит журнал событий или настройки провайдеров. Аудитор соответствия получает права только на чтение документов, чатов и архивов плюс доступ к журналу событий — способен всё инспектировать, ничего не менять.

Ничто из этого не потребовало форка приложения или написания собственного middleware. Потребовалось собрать права в роли и отобразить разделы меню. Это и есть цель дизайна, которой служит модель из 31 права: достаточно гранулярна, чтобы выражать реальные организационные границы, и достаточно проста, чтобы политика умещалась в голове.

Чтобы увидеть полный словарь прав и эндпоинты управления ролями, прочтите справочник API. Для практического обзора ролей, прав и разделов меню в интерфейсе администратора см. руководство по использованию.