Нативные права 1С не защищают от ИИ: что RLS и журнал регистрации не покрывают

Компания на оптовой торговле, конфигурация УТ 11, около сорока пользователей. Коммерческому отделу подключили ИИ-ассистента, чтобы быстрее собирать аналитику по продажам: обороты по клиентам, остатки, динамику отгрузок. Сделали всё по уму. Завели отдельного служебного пользователя под интеграцию, выдали ему роль только на чтение, настроили RLS по организации и складу. Логика понятная: права урезаны, RLS стоит, всё пишется в журнал регистрации, значит контур закрыт.

Через пару недель клиенты начали получать предложения от конкурента, слово в слово по тем же позициям и ценам. Стали разбираться. Оказалось, менеджер перед увольнением попросил ассистента: «выгрузи всех контрагентов с телефонами, почтой и суммами отгрузок за два года, отсортируй по обороту». Ассистент под учёткой интеграции с правами на чтение спокойно всё вернул, и ответ ушёл во внешнюю облачную модель, потому что MCP-сервер стоял сырой, без управляющего слоя.

Самое неприятное вскрылось на разборе. RLS настроили на документы (Заказы клиентов, Реализации) по складу, а справочник Контрагенты и связанные регистры сведений с контактами и условиями договоров под ограничение не попали. Так бывает сплошь и рядом: писать RLS на контрагентов трудоёмко и дорого по производительности, поэтому справочник оставляют под широкую роль. Журнал регистрации показал ровно одно: служебный пользователь выполнял запросы. Ни текста промпта, ни того, что за ним стоял конкретный человек, ни внятного объёма выгрузки.

Это не история про дырявую 1С. Права, RLS и журнал отработали именно так, как спроектированы. Проблема в том, что спроектированы они под другую модель угроз.

Почему RLS останавливает человека, но не ИИ-канал

RLS в 1С, ограничение доступа на уровне записей, привязано к роли и сеансу конкретного пользователя. Для интерактивной работы это сильный механизм: бухгалтер видит свою организацию, кладовщик свой склад, менеджер своих клиентов. ИИ ломает три допущения, на которых механизм держится.

Первое: ИИ ходит в базу не под человеком, а под учёткой интеграции. RLS считается относительно прав этого служебного аккаунта, а не сотрудника, который сформулировал запрос. Гранулярность схлопывается до того, что видит один сервисный пользователь, а привязка к живому человеку теряется на входе.

Второе: RLS решает, какие записи доступны, но молчит про объём, темп и намерение. Если чтение справочника Контрагенты разрешено, то и массовая выгрузка всего справочника разрешена. RLS не отличает «покажи одного контрагента по ИНН» от «отдай всю клиентскую базу»: для строки ограничения это один и тот же легальный доступ на чтение. RLS режет горизонталь (какие строки видны), но не вертикаль: какой это канал, с какой скоростью и зачем он читает.

Третье: RLS почти всегда неполон. Типовые дыры сидят в справочниках, регистрах сведений и накопления, планах обмена, внешних источниках данных. Часть защиты вообще живёт не в RLS, а на уровне управляемых форм (условное оформление, доступность реквизитов, обработчики проверки заполнения), и всё это обходится, как только обращение идёт через прямой интерфейс запросов, а не через форму. Добавьте привычку ради скорости отчётов сажать интеграцию на широкую роль: аккуратные шаблоны ограничений тормозят запросы. В самосборных схемах встречается совсем грубое: точку входа (HTTP-сервис в расширении) публикуют без аутентификации 1С, а код внутри исполняется в привилегированном режиме, и тогда ни роли, ни RLS уже не в игре.

Журнал регистрации фиксирует сеансы, а не диалог с ИИ

Второе возражение звучит так: «но ведь всё пишется в журнал». Журнал регистрации 1С действительно фиксирует события платформы: входы, изменение данных, проведение документов, отказы в доступе. Для расследования действий людей это рабочий инструмент.

Для ИИ-канала журнал регистрации 1С как средство аудита проседает сразу по нескольким пунктам. Он видит сеанс служебного аккаунта, а не человека за промптом, не текст запроса, не то, какой инструмент был вызван и с какими параметрами. Детальный аудит чтения в нём обычно не ведётся: пооперационная запись каждого прочитанного справочника и регистра раздула бы журнал, поэтому чтение через запрос или СКД по умолчанию не фиксируется пообъектно. Сам журнал ротируется и чистится администратором: это операционный лог платформы, а не защищённый от изменения реестр действий модели. И главное, он реактивен: это разбор постфактум, он не останавливает выгрузку в тот момент, когда ИИ её делает.

Итог: журнал регистрации 1С закрывает аудит людей, а не аудит действий ИИ. Первое есть из коробки, второго в платформе нет.

Достаточно ли прав 1С для ИИ

Прямой ответ: для интерактивной работы людей внутри периметра да, для ИИ-канала нет. Почему конкретно.

Штатная модель безопасности 1С исходит из того, что за клиентом сидит один человек, данные не покидают периметр, а темп и объём операций человеческие. ИИ нарушает все три посылки. Один служебный аккаунт мультиплексирует запросы многих сотрудников. Сырой MCP-сервер отправляет ответ во внешнюю модель, то есть данные уходят из контура. И читает ИИ быстрее и шире любого оператора.

Сверх этого у платформы просто нет понятия «это ИИ-канал, к нему нужна отдельная политика». Штатными правами не сказать «на боевой базе ассистент только читает, а людям писать можно». Не навесить лимит именно на ИИ-запросы, отдельный от людей. Не развести доступ по средам так, чтобы прод был жёстко read-only для модели, а тест открыт.

Есть и правовая сторона. Контрагенты, физлица в документах, сотрудники в ЗУП относятся к персональным данным в смысле 152-ФЗ, а закон требует ещё и учёта того, кто к этим данным обращается. Когда доступ ИИ схлопывается в один сервисный аккаунт, этот учёт деградирует. Цена вопроса выросла: с 30 мая 2025 года (поправки в статью 13.11 КоАП, закон 420-ФЗ) штрафы для юрлиц за утечку персональных данных достигают 15 млн рублей при массовой утечке (свыше ста тысяч субъектов) и стартуют от 3 млн при утечке от тысячи субъектов, а за повторную добавили оборотные штрафы от 1 до 3% годовой выручки, вплоть до 500 млн. Держать модель и данные на своём железе и сокращать объём того, что вообще уходит наружу, риск снижает. Но это про то, где физически стоит контроль, а не про галочку «соответствия», и сами по себе RLS с журналом про этот канал ничего не знают.

Что реально закрывает разрыв

Разрыв закрывает не ещё один набор ролей внутри 1С, а управляющий слой перед инфобазой. Важно, что он не подменяет и не наследует права 1С, а добавляет отдельный слой политики поверх них, ровно под ИИ-канал:

• Отдельные ролевые профили для ассистента (RBAC), заданные независимо от того, что может человек.
• Полный аудит ИИ-действий: кто спросил, к какой базе, что было разрешено, а что заблокировано. Ровно то, чего журнал регистрации не даёт: запрос, инструмент, параметры, вердикт шлюза.
• Жёсткий fail-closed read-only на боевых базах: запись на проде блокируется на самом шлюзе, даже если у аккаунта формально есть права.
• Маршрутизация по нескольким базам и квоты на каждую: массовую выгрузку гасит лимит на окно, а не добрая воля сотрудника.
• Лицензирование по местам и привязка к рабочим местам команды, чтобы за запросом стоял конкретный человек, а не безликий служебный пользователь.
• Один автономный бинарь on-prem, данные не выходят из контура (как устроена локальная граница, подробно разобрано в отдельной статье про on-premise 1С).

Маскирование персональных данных на выходе шлюза идёт отдельной возможностью корпоративной редакции и сейчас в разработке. Но и без неё перечисленного достаточно, чтобы та самая выгрузка «всех контрагентов с телефонами» упёрлась в роль, квоту и запись в аудите с именем инициатора.

Здесь же проходит граница между категориями инструментов. Сырые MCP-серверы без governance-слоя просто пробрасывают запрос в модель. Токен-маскировщики прячут значения, но не дают ни ролей, ни аудита. Решения с execute_code за грубым списком разрешений отдают ИИ произвольный код в привилегиях. Наборы из нескольких Docker-контейнеров с правилами на стороне клиента переносят контроль туда, где его проще всего отключить. Ни один из этих подходов не отвечает на вопрос «кто, что и в каком объёме спросил у базы».

Что проверить, если вы уже подключаете ассистента

• Не сажайте ИИ на широкий сервисный аккаунт: заведите ему отдельную узкую роль, отличную от людских.
• Логируйте не только изменения в базе, но и само обращение: промпт, целевую базу, объём выдачи и вердикт.
• Делайте прод read-only в точке входа, а не в расчёте на то, что «модель не станет писать».
• Считайте RLS и журнал регистрации необходимыми, но недостаточными для ИИ-канала.

Коротко

Нативные права, RLS и журнал регистрации защищают сеансы людей, и делают это хорошо. ИИ-канал они не покрывают: теряют инициатора, не видят объём и намерение, не пишут диалог с моделью и не умеют быть строже на проде. Это не повод отказываться от ИИ в 1С, это повод не полагаться на штатные механизмы там, где они по своей природе не работают.

Feenlace MCP-1C работает как управляемый шлюз перед вашими базами on-prem и добавляет ИИ-каналу роли, аудит, read-only на проде и квоты по базам. Открытая редакция бесплатна и с открытым исходным кодом, посмотреть можно на feenlace.ru. Если вы подключаете ассистента к боевой 1С, начните с одного вопроса к себе: что именно увидит ваш журнал регистрации, если завтра кто-то попросит выгрузить всё.