Интерактивная визуализация иерархии баз данных, ролей пользователей и систем безопасности.
data_base/ (Общие документы)
data_base_history/ (Заказы и Брак)
Детализированный срез прав пользователей по всем узлам и базам данных в табличном виде.
| Сущность / База данных | Уровень | Роль пользователя | Просмотр (👁️) | Редактирование (✏️) |
|---|---|---|---|---|
| БД_1 (data_base/) | База Данных | пользователь | ✓ | - |
| БД_1 (data_base/) | База Данных | менеджер | ✓ | - |
| БД_1 (data_base/) | База Данных | менеджер по качеству | ✓ | - |
| БД_1 (data_base/) | База Данных | администратор | ✓ | ✓ |
| БД_2 → ЗАКАЗЫ 🔒 PII | Раздел L2 | менеджер | ✓ (MFA) | - |
| БД_2 → ЗАКАЗЫ 🔒 PII | Раздел L2 | администратор | ✓ | - |
| БД_2 → БРАК 🔑 ID-Only | Раздел L2 | менеджер по качеству | ✓ (ID-Only) | - |
| БД_2 → БРАК | Раздел L2 | администратор | ✓ | - |
| БД_3 → Сотрудники 📝 Log | Раздел L2 | администратор | ✓ | ✓ (Log) |
| БД_3 → Клиенты 📝 Log | Раздел L2 | администратор | ✓ | ✓ (Log) |
Системные метки и ограничения, применяемые на схеме доступа
Ни один реальный контакт клиента (ФИО, Email, Телефон) не передается в оперативную память LLM. Алгоритмы поиска по шаблонам на уровне API находят конфиденциальные данные и заменяют их на заглушки общего вида [Name], [Email], [Phone].
Предотвращает массовый парсинг отчетов о браке. Менеджер по качеству не может запросить агрегированные данные. Поиск и извлечение файла [id].json строго привязаны к явному верифицированному ID транзакции/пользователя в текущем запросе.
Защита от внутренних угроз. Любое изменение записи (INSERT/UPDATE/DELETE) Администратором автоматически фиксируется в изолированной СУБД по принципу Append-Only (разрешена только вставка новых строк без возможности стирания истории).
Для получения доступа к заказам или спискам клиентов требуется дополнительный фактор верификации (ввод одноразового OTP-кода, нажатие аппаратного токена или ручное подтверждение согласия с регламентом обработки персональных данных).
Алгоритмическая логика обработки информации в RAG Base assist
Перед каждым обращением языковой модели к хранилищу RAG, система проводит автоматический невмешательный аудит сессии пользователя. Проверяется ролевое соответствие (User Role Context). При запросе конфиденциальных слоев (БД_2 и БД_3) система запрашивает явное подтверждение прав (OTP-код/MFA). При несовпадении прав сессия мгновенно изолируется с выдачей стандартной формулировки отказа.
Исключает риск утечки приватной информации за рамки периметра компании через запросы к внешним API-моделям. Все данные, запрашиваемые из базы заказов перед помещением в контекст LLM, прогоняются через автоматический фильтр. Реальные текстовые совпадения с именами, телефонами или адресами перекодируются в безопасные системные маркеры. Ассистент работает только со «стерильными» транзакциями.
Критически важные задачи для настройки поведения LLM в зависимости от роли