Аудит прав доступа в 1С через нейросеть: выгрузили файл - и спрашиваете словами
Иван Недомолков · Chop etilgan:
Вопросы про права доступа приходят регулярно и всегда не вовремя: аудит, проверка безопасности, новый сотрудник, увольнение старого. “У кого полные права?”, “кто может проводить документы по складу?”, “почему у кассира виден чужой отчёт?”. В типовой конфигурации сотни ролей - в Рознице для Казахстана их 326 из коробки, в ERP больше тысячи. Ответ на каждый такой вопрос собирается руками: конфигуратор, сличение галочек, Excel со сводными.
Этот разбор о том, как отвечать на такие вопросы быстрее: права выгружаются в один текстовый файл, файл отдаётся нейросети, и дальше вы спрашиваете обычным языком. Ниже вся механика - от функции платформы, которая делает это возможным, до границ метода и правил проверки ответов.
Где в 1С лежат права и почему их трудно разбирать руками
Модель доступа платформы устроена в несколько слоёв:
- роли - базовый слой: какие права (чтение, добавление, изменение, удаление, проведение и десятки других) роль даёт на какие объекты метаданных;
- пользователи - каждому назначен набор ролей, итоговые права складываются из всех ролей сразу;
- профили групп доступа (в конфигурациях на БСП) - обёртка над ролями, которой пользуются администраторы;
- ограничения на уровне записей (RLS) - фильтры внутри уже выданных прав: видеть документы только своего склада.
Трудность не в каком-то одном слое, а в их произведении. Итоговый ответ на вопрос “что может Иванов” - это объединение прав всех его ролей по каждому из тысяч объектов, с поправкой на RLS. В конфигураторе это не видно одним экраном ни для одного пользователя, тем более для всех сразу.
Живой пример вопроса, на который штатными средствами не ответить: пользователь жалуется, что отчёт пустой, а ошибки нет ни одной - и виновато оказывается право просмотра на одно поле, которое СКД выбросила молча.
Штатные отчёты по правам существуют, но отвечают на заранее заложенные вопросы. Живой вопрос почти всегда чуть в стороне: не “права роли Кассир”, а “чем Кассир отличается от Старшего кассира и кому из людей это важно”. Под каждый такой вопрос отчёт приходится строить заново.
Функция, которая делает аудит программируемым
Распространённое мнение: права ролей лежат в конфигурации и из встроенного языка недоступны. Это неправда. У функции ПравоДоступа есть третий параметр, и туда передаётся роль:
// Есть ли у роли ПолныеПрава право Чтение на справочник Контрагенты
Есть = ПравоДоступа("Чтение",
Метаданные.Справочники.Контрагенты,
Метаданные.Роли.ПолныеПрава);Функция возвращает Истину или Ложь для конкретной тройки “право - объект - роль”. То есть полная матрица прав читается прямо в работающей базе, штатным методом, без конфигуратора, без выгрузки конфигурации в XML и без разбора служебных файлов. Мы проверяли на живой базе с несколькими сотнями ролей: аргумент роли честно учитывается, чтение конкретного справочника из 366 ролей давали 9.
Две засады, о которых стоит знать до того, как вы начнёте это использовать:
- Неприменимое право - это исключение, а не Ложь. Спросите “Проведение” у справочника - получите не отрицательный ответ, а ошибку времени выполнения. Поэтому перед основным проходом надо определить, какие права вообще применимы к типу объекта: надёжный способ - проверить набор прав-кандидатов на роли с полными правами, где применимое право заведомо Истина, а неприменимое бросает исключение.
- На некоторых старых платформах проверка прав записи завышает ответ. Мы ловили на 8.3.17 ситуацию, когда право изменения возвращало Истину для ролей, дающих только чтение. Универсальная защита опирается на инвариант платформы: права записи без права чтения не бывает, поэтому запись засчитывается только вместе с чтением.
Зачем здесь нейросеть
Матрицу можно читать кодом - но тогда под каждый вопрос снова нужен программист. Идея в другом: выгрузить права один раз в формат, который понимает языковая модель, и переложить на неё перевод человеческих вопросов в поиск по матрице.
Файл собирается в Markdown из нескольких блоков:
- роли - имя, синоним, комментарий: справочник для расшифровки;
- пользователи и их роли - связка, которая позволяет отвечать на вопросы поимённо;
- матрица прав по выбранным объектам - таблица “роль на право” по конкретному документу или справочнику;
- профили ролей и эквивалентность - по скольким объектам роль даёт чтение и запись, что может менять, у каких ролей права совпадают полностью.
Кусок настоящей выгрузки, чтобы был понятен формат:
### Документ.РеализацияТоваровУслуг
| Роль | Чтение | Добавление | Изменение | Удаление | Проведение |
| --- | --- | --- | --- | --- | --- |
| ПолныеПрава | + | + | + | + | + |
| ДобавлениеИзменениеПродаж | + | + | + | | + |
| ЧтениеПродаж | + | | | | |Модель читает такую таблицу как структуру, а не как текст, и дальше отвечает на вопросы по ней. В начало файла кладётся короткая инструкция: прочитав её, модель сама объясняет, что в файле, и предлагает список вопросов - формулировки придумывать не нужно.
Какие вопросы это закрывает
Из практики четыре группы, по типу того, что спрашивают:
По пользователям. У кого полные права - списком фамилий. Кто остался без ролей. У кого одинаковые наборы ролей. Какие роли у конкретного сотрудника.
По ролям. Что даёт роль на самом деле, а не по названию. Чем две похожие роли отличаются. Какие роли дают запись, но не дают проведение. Какие роли никому не назначены.
По объектам. Кто может изменять справочник Номенклатура. Кто проводит реализации. Каких прав не хватает сотруднику для работы с конкретным документом - вопрос, на который руками уходит час сравнения ролей.
По функциональности. Кто может работать со складом, у кого доступ к финансам, кто дотягивается до персональных данных. Здесь модель опирается на синонимы и комментарии ролей из того же файла: перевод с человеческого “доступ к деньгам” на имена регистров она делает сама.
Отдельный класс ответов - кандидаты на упрощение. Группы ролей с полностью совпадающими правами (в типовых конфигурациях это обычно роли-переключатели разделов интерфейса) - повод объединить. Роль с правом записи, не назначенная никому, - кандидат на удаление. Пользователь с набором ролей шире, чем у коллег на той же должности, - вопрос службе безопасности.
Доверять ли ответам модели
Главное возражение к любому применению нейросетей в админских задачах: а не выдумает ли она. Здесь у метода есть честное преимущество: модель отвечает не из общих знаний о 1С, а по таблицам из файла, и каждую строку ответа можно проверить глазами - открыть файл, найти роль, сверить. Это принципиально отличается от вопроса “расскажи про права в 1С” без файла, где модель охотно сочиняет несуществующие галочки.
Рабочее правило такое: черновую работу - перелопатить сотни строк и найти нужное - делает модель, контроль остаётся за человеком. Ответы, которые уходят дальше (безопаснику, аудитору, в приказ), сверяются с файлом; на это уходит минута против часа ручного сбора с нуля.
Границы метода: что в выгрузку не попадает
Про ограничения надо говорить прямо, потому что именно на них ловят такие инструменты:
- RLS в выгрузке нет. Права сравниваются на уровне объектов метаданных; ограничения на уровне записей, права на отдельные реквизиты и команды не выгружаются. Две роли с одинаковыми объектными правами и разными RLS-шаблонами будут выглядеть эквивалентными - перед физическим объединением ролей RLS сверяется в конфигураторе.
- Полная матрица по всей конфигурации не нужна и не влезает. Сотни ролей на тысячи объектов - миллионы проверок и файл больше контекста модели. Поэтому матрица строится по выбранным объектам, а по всей базе считаются агрегаты: профили ролей и эквивалентность.
- В файле имена людей. Список пользователей - это персональные данные вашей организации. Прежде чем нести файл во внешний чат, оцените это по своей политике безопасности; для чувствительных случаев данные обезличиваются до отправки - у нас для этого есть отдельный разбор про обезличивание выгрузок 1С.
И важная граница применения: этот метод отвечает на вопрос “как устроены права сейчас”. Если вы меняете права и хотите доказать, что после изменения никто не увидел лишнего и не потерял своего, нужен другой инструмент - матрица эквивалентности прав с хеш-срезами до и после. Эти два подхода дополняют друг друга: нейросеть - для разведки и аудита, хеш-матрица - для регресс-контроля изменений.
Готовая обработка
Чтобы не собирать выгрузку руками, мы оформили весь описанный подход в обработку “Матрица прав доступа 1С для нейросети” на Инфостарте. Одна кнопка - и файл со ролями, пользователями, матрицей по выбранным объектам и полным анализом сохраняется на компьютер; дальше он прикрепляется в любой чат с моделью. Работает на любой конфигурации (читает только штатные Метаданные.Роли, ПравоДоступа, ПользователиИнформационнойБазы), ничего не пишет в базу. Базовый режим отрабатывает за секунду, полный анализ на большой базе - до пары минут.
Как этот инструмент рождался и как выглядит работа с ним в чате - в нашей статье на Инфостарте: там история одного аудита от первого лица, со скриншотами диалога с моделью.
Соседи по линейке “1С и нейросети”, с которыми обработка работает в связке:
- Выгрузка структуры метаданных 1С для нейросети - объясняет модели устройство базы: объекты, реквизиты, связи. Подробный разбор подхода - в отдельной статье;
- Анонимизатор выгрузки 1С PRO - обезличивает данные перед отправкой в чат и расшифровывает ответ обратно;
- Локальная LLM на встроенном языке 1С - бесплатный учебный стенд с открытым кодом: трансформер посчитан на BSL, и на каждом символе видно распределение вероятностей. Удобно показывать тем, кто спрашивает, можно ли верить ответу модели.
Отдельный слой, который матрица прав не покрывает: внешние обработки из справочника дополнительных отчётов и обработок. Права им выдаёт не роль, а факт запуска - они работают с правами того, кто нажал кнопку, и что именно они делают с данными, из матрицы не видно. Смотреть надо их код, а он в среднем не читан никем: проверка своих же обработок анализатором дала 239 замечаний на семнадцать файлов, 186 из них критичные.
Частые вопросы
Это работает только с ChatGPT?
Нет. Файл - обычный Markdown, его понимает любая современная чат-модель с загрузкой файлов. Разница между моделями проявляется на больших файлах: чем больше контекст модели, тем больше ролей и объектов влезает за один раз.
Насколько это безопасно для данных?
Обработка ничего никуда не отправляет: она читает базу и сохраняет файл на компьютер. Дальше решение за вами - какой модели файл показывать и показывать ли вообще. В файле нет данных документов и справочников, только структура доступа: имена ролей, имена пользователей и матрица прав. Самое чувствительное в нём - список сотрудников.
Можно ли так проверить права после обновления конфигурации?
Для быстрой разведки - да: выгрузили до и после, попросили модель сравнить составы ролей. Но для строгого регресс-контроля (“докажите, что видимость данных не изменилась”) нужен воспроизводимый замер с эталоном - это матрица эквивалентности с хеш-срезами, другой инструмент под другую задачу.
Почему не сделать это обычным отчётом без нейросети?
Отчёт отвечает на вопросы, которые в него заложили заранее. Сила связки “файл плюс модель” в свободной формулировке: “кого можно перевести на общую роль без потери доступа” - вопрос, под который никто отчёт не проектировал, а модель отвечает по той же матрице. Плюс вопросы задаёт не только программист: руководителю или безопаснику проще спросить “у кого доступ к деньгам”, чем оперировать именами регистров.
Что делать с найденными дублями ролей?
Сначала проверить руками: эквивалентность в выгрузке считается по объектным правам, без RLS и прав на реквизиты. Если роли действительно идентичны - объединять, а перед массовым изменением снять эталонные срезы видимости, чтобы было чем доказать отсутствие регресса. Если разбирать доступ в вашей базе некому, мы делаем аудит и оптимизацию 1С как услугу - права и роли входят в контур работ.
Отдельный вопрос - под какими правами в базу ходит сама автоматика. Если через один сервис к базам подключается нейросеть, права этой учётной записи определяют потолок ущерба при ошибке: разбор такой схемы - “MCP для 1С: один сервер на десять баз”.
