ИИ с доступом к корпоративной базе данных: как ограничить запросы, права и объём данных, который модель может прочитать или изменить

Ни для кого не секрет, что пользователь может ненароком выгрузить в ИИшку лишние рабочие данные, чтобы составить табличку. Или, например, вы просите корпоративного ИИ посчитать продажи за месяц. Через минуту вам присылают готовый отчёт, но сколько информации понадобилось помощнику для ответа? Три итоговые суммы или вся история сделок вместе с контактами клиентов и внутренними комментариями? По красивой таблице этого не понять. А для безопасности разница принципиальная.

Ради удобства ИИ подключают к рабочим данным, чтобы сотрудник мог получить отчёт, найти заказ или изменить заявку обычной фразой, без SQL и обращения к разработчикам. Только за привычным окном чата теперь стоят реальные полномочия. Ассистент может прочитать лишнее, получить сведения, недоступные самому сотруднику, или запустить изменение не тех записей, если приложение это допускает. Просьба в промпте «будь осторожен» выданных прав не отменяет. Хотя в качестве плана защиты выглядит удивительно бюджетно.

Если приложение не проверяет права сотрудника, ограничение, которое годами работало в CRM, может оказаться бесполезным в новом удобном чате. Цифровая трансформация состоялась, однако безопасность сюда не пригласили. Поэтому при подключении ИИ к рабочей базе важно контролировать не только ответы, но и действия ассистента: какие сведения приложение получает для модели, сколько может выгрузить за несколько обращений и какие записи способно изменить. Разберём, что ограничить в самой БД, что проверять на стороне приложения и как убедиться, что защита действительно работает.

Схема подключения

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

Это и есть место для обязательных проверок: кто запросил данные, разрешена ли операция, какие ограничения применяются. Учётные данные БД храните в защищенном хранилище секретов, доступном сервису, а не в промпте или истории диалога, сетевое подключение разрешайте только нужным компонентам. Не оставляйте альтернативный маршрут, по которому инструмент может обратиться к базе в обход проверок.

Важно помнить, что системный промпт не заменяет управление доступом. Инструкция «не показывай конфиденциальные данные» может влиять на поведение модели, но разрешать выполнение операции должна серверная логика.

Права на таблицы, строки и поля

Для пользовательского ассистента доступ определяйте пересечением полномочий сотрудника и разрешений конкретного инструмента. Если сотруднику доступны только собственные сделки, помощник должен работать в тех же границах.

Личность пользователя и его организацию определяйте по проверенной сессии. Не доверяйте полям user_id или organization_id, которые предложила модель, это параметры запроса, а не подтверждение полномочий. При общей технической учётной записи передавайте проверенный контекст через серверную логику и не позволяйте модели его подменять. Если определить пользователя или проверить его права не удалось, запрос отклоняйте без перехода на запасной аккаунт с доступом «ко всему».

Ограничения настройте на трёх уровнях.

• Таблицы и операции. Создайте отдельную роль для интеграции. Разрешите только необходимые объекты; чтение и изменение разделите. Не выдавайте права администратора, владельца таблиц, управления пользователями и схемой базы.
• Строки. Ограничьте доступ нужным подразделением, клиентом или проектом, тестируйте ограничения под реальной ролью интеграции.
• Поля. Подготовьте представления или отдельные наборы данных только с нужными столбцами. Для ответа о доставке достаточно номера заказа, статуса и даты. Паспортные данные покупателя и комментарии службы безопасности передавать незачем. У роли интеграции не должно оставаться обходного доступа к исключённым сведениям.

Лишние данные убирайте до передачи модели. Если приложение отправило ей полную карточку клиента, а пользователю показало только статус заказа, ограничение чтения уже не выполнено.

Проверка SQL-запросов

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

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

Разбор SQL это лишь дополнительная защита. Он не отменяет ограничения роли в СУБД. Ошибка проверки запроса не должна автоматически открывать доступ ко всему серверу.

Ограничения объёма и нагрузки

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

Проверяйте размер результата до включения в контекст модели. При превышении лимита останавливайте выдачу и предлагайте сузить запрос. Автоматически выгрузить оставшееся следующими порциями значит обойти собственное ограничение.

Счётчики должны находиться в приложении и учитывать обращения из разных диалогов. Модель не должна сама решать, исчерпала ли она лимит. Ограничения шагов, повторов и времени автономной работы также задаются вне модели.

Нагрузку на БД контролируйте отдельно, небольшой результат не гарантирует дешёвый запрос. Установите ограничения времени выполнения, ожидания блокировок и числа параллельных запросов. После тайм-аута убедитесь, что запрос в БД действительно остановлен, а не продолжает работать после того, как приложение перестало ждать ответ. Когда пользователю нужен итог продаж, рассчитывайте его в базе и передавайте итог, а не все сделки.

Запись и удаление данных

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

• Перед выполнением повторно проверьте полномочия и актуальность записи. Если другой сотрудник уже изменил заявку, не применяйте согласованное действие к новому состоянию без проверки.
• Количество изменяемых записей ограничивайте до фиксации транзакции. Задавайте точные объекты и разрешённые поля. Если фактический объём изменений превысил допустимый, откатывайте операцию. Учтите связанные действия: триггеры, обновление других таблиц, отправку сообщений. Уведомления и внешние вызовы проектируйте отдельно от изменения БД.
• Защитите операции от повторов. После сетевого сбоя повторный вызов с тем же идентификатором не должен создавать ещё одну заявку или повторное начисление. Для этого реализуют идемпотентность — обработку повторного запроса без повторения результата действия.

Защита от инструкций внутри данных

Комментарии клиентов, письма и описания заявок могут содержать текст, который пытается управлять моделью, например, запросить дополнительные данные, изменить действие или отправить результат наружу. Это не прямая инструкция приходит через материал, который ассистент читает. Такие инструкции могут находиться и в базе данных.

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

Журналирование и проверка ограничений

В журнале связывайте пользователя, вызов инструмента и операцию в БД единым идентификатором. Фиксируйте техническую роль, результат проверки прав, количество прочитанных или изменённых записей, размер выдачи, подтверждение изменения и причину отказа. Полные результаты запросов и секреты по умолчанию туда не записывайте, ваш журнал не должен становиться резервной копией клиентской базы.

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

До запуска проведите проверки на тестовых данных:

• Чужие данные. Сотрудник запрашивает записи другого подразделения. Они не должны попасть ни в ответ, ни в контекст модели.
• Выборка частями. Пользователь открывает несколько чатов и запрашивает следующие порции. Общий лимит продолжает действовать.
• Подмена и повтор операции. После согласования меняют параметры либо повторяют вызов после сбоя. Изменённое действие отклоняется, выполненное не дублируется.
• Инструкция в комментарии. Тестовая запись требует расширить доступ или отправить данные наружу. Запрещённая операция не выполняется.

Результаты лучше проверять по журналам приложения и состоянию БД. Также предусмотрите аварийное отключение инструментов и прекращение выполняющихся запросов, а для каждого действия назначьте ответственного.

Заключение

Начинайте с узкой задачи: определённые пользователи, нужные строки и поля, подготовленные запросы и проверенные лимиты. Право изменять данные добавляйте отдельно через ограниченные операции, с контролем объёма, подтверждением там, где оно необходимо, и защитой от повторов.

Если чужие данные не выданы, общий лимит не обойдён, несогласованное изменение не выполнено, ИИ действительно помогает работать. А если у вас еще остались вопросы, «Астрал. Безопасность» всегда готовы с этим помочь!

Автор статьи: Филиппова Анастасия, специалист по информационной безопасности «Астрал. Безопасность».