Безопасность

5.1. Безопасность платформы

5.1. Безопасность платформы

Безопасность платформы

Общий подход

Безопасность - один из ключевых принципов архитектуры ТожеБот. Платформа использует многоуровневый подход к защите данных, изоляции проектов, контролю взаимодействий с ИИ-агентами и регистрации событий безопасности.

Защита строится на нескольких взаимодополняющих механизмах:

  • Изоляция пользователей и проектов - разграничение доступа к тенантам, агентам и ресурсам.
  • Контроль полномочий агентов - ограничение доступа к инструментам и базам знаний.
  • ML-защита взаимодействий - обнаружение потенциально вредоносных инструкций и выявление персональных данных с помощью OGL-Mini.
  • Криптографическая защита - шифрование поддерживаемых полей данных с использованием пост-квантового протокола шифрования QuarkDash.
  • Мониторинг безопасности - регистрация срабатываний защитных механизмов и потенциально подозрительных событий.
  • Аудит обработки персональных данных - регистрация предусмотренных операций с данными для внутреннего контроля и подготовки отчётности.

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

1. Изоляция пользователей, проектов и агентов

Пользователи и проекты

ТожеБот организует ресурсы через проекты (тенанты). Каждый пользователь получает доступ к проектам в соответствии со своей ролью и назначенными полномочиями.

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

Это позволяет разделять рабочие пространства разных команд и ограничивать доступ к данным за пределами разрешённого проекта.

Изоляция агентов

Внутри проекта каждый агент имеет собственную конфигурацию и назначенные ресурсы. Наличие доступа у одного агента не означает автоматического предоставления такого же доступа другим агентам.

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

Доступ к инструментам

Инструменты позволяют агентам взаимодействовать с внешними системами и выполнять предусмотренные действия.

ТожеБот хранит настройки инструментов и их связь с агентами. Исполнение поддерживает встроенные инструменты, вебхуки и интеграции с внешними системами, включая CRM и MCP-инструменты.

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

Доступ к базам знаний

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

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

2. ML-защита взаимодействий с ИИ-агентами

Для дополнительной защиты взаимодействий с агентами ТожеБот использует собственный слой безопасности на базе OGL-Mini (Open Guard Layer).

Репозиторий и техническая документация:

OGL-Mini - гибридный механизм защиты ИИ-приложений, сочетающий эвристические проверки, классификацию содержимого и обнаружение персональных данных. В ТожеБот используется последняя версия моделей, специально до-обученная для широкого применения.

Обнаружение потенциальных угроз

Защитный слой предназначен для выявления таких типов содержимого, как:

  • Prompt injection - попытки изменить поведение агента с помощью недоверенных инструкций.
  • Jailbreak - попытки обойти предусмотренные ограничения модели.
  • Подозрительные инструкции - содержимое, которое может указывать на попытку манипуляции агентом.
  • Персональные данные - сведения, которые могут требовать дополнительной защиты при передаче в модель.
  • Некоторые обфусцированные атаки - например, инструкции с необычным форматированием или маскировкой текста, если они распознаются используемой версией защитной модели.

Мы постоянно изучаем свежие версии спецификаций и рекомендаций по предотвращению угроз. На данный момент мы закрываем OWASP 2025 / 2026 при помощи собственных ML-моделей.

Проверка входящих сообщений

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

Результат проверки содержит обнаруженные флаги, оценку риска и обработанный текст. События срабатывания могут сохраняться в журнале безопасности и прикрепляться к истории беседы.

В текущей реализации этот механизм работает в умеренном режиме: обнаружение угрозы само по себе не означает, что запрос будет заблокирован. OGL-Mini следует рассматривать как дополнительный механизм обнаружения и обработки рисков, а не как жесткий барьер, который гарантированно останавливает все атаки (защита от ложных срабатываний).

Обнаружение и маскирование персональных данных

В платформе реализовано обнаружение ряда типов персональных данных с помощью регулярных выражений и ML-классификатора с OGL-Mini.

В частности, эвристические проверки охватывают адреса электронной почты, телефоны, Telegram-идентификаторы, некоторые номера документов и банковские карты. ML-модель может дополнять эти проверки в пределах поддерживаемых классов данных.

Обнаруженные значения могут заменяться временными маркерами, например [EMAIL_1] или [PHONE_1], до передачи обработанного сообщения языковой модели. В соответствующих сценариях оригинальные значения могут восстанавливаться после генерации ответа.

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

Также важно учитывать, что исходные сообщения и некоторые фрагменты текста могут сохраняться для истории беседы или регистрации событий безопасности. Маскирование перед передачей модели не означает автоматического удаления оригинала из хранилища или журналов, однако там они защищены пост-квантовым шифрованием (см. ниже).

3. Криптографическая защита данных

ТожеБот использует собственный криптографический протокол QuarkDash для шифрования поддерживаемых полей данных.

Репозиторий и техническая документация:

QuarkDash - гибридный криптографический протокол с постквантовым подходом. Его реализация включает механизмы обмена ключевым материалом, выработки ключей, шифрования и проверки целостности.

Что означает постквантовый подход

Постквантовая криптография рассматривает угрозы, связанные с потенциальными возможностями будущих квантовых компьютеров. Один из важных сценариев риска - сбор зашифрованных данных сегодня с целью попытаться расшифровать их в будущем.

QuarkDash, используемый в платформе, проектировался с учётом таких угроз.

Шифрование полей данных

В серверном коде ТожеБот реализован общий механизм шифрования полей, настроенных с использованием протокола QuarkDash.

При работе с такими полями система обрабатывает значения через криптографический слой и хранит зашифрованное представление данных. При чтении значения расшифровываются для авторизованной обработки приложением.

Управление ключами

В платформе реализован менеджер ключей, который поддерживает версии ключевого материала и планирование ротации. Ключевой материал не хранится непосредственно в записи keyring: там сохраняются соль и метаданные версий, а ключи повторно выводятся из мастер-секрета и соответствующих параметров. Доступ к техническому хранилищу ключей ограничен серверной логикой.

Ротация и перешифрование

Смена ключей поддерживается менеджером ключей. Платформа отслеживает версии ключей и состояние фоновых задач перешифрования.

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

4. Мониторинг событий безопасности

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

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

Предусмотрены категории событий, связанные с:

  • обнаружением потенциального prompt injection;
  • обнаружением персональных данных;
  • превышением лимитов запросов;
  • подозрительной активностью при входе;
  • нарушениями CSRF-защиты.

Использование событий

Журнал безопасности помогает:

  • анализировать срабатывания защитных механизмов;
  • выявлять повторяющиеся типы подозрительных запросов;
  • сопоставлять события с проектом и беседой;
  • оценивать необходимость изменения настроек или защитных правил;
  • проводить внутренний разбор инцидентов.

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

5. Аудит обработки персональных данных

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

При проектировании этого механизма учитываются требования российского Федерального закона № 152-ФЗ «О персональных данных» и Общего регламента ЕС по защите данных (GDPR), когда соответствующее законодательство применимо к обработке.

Какие события регистрируются

Для коллекций с персональными данными предусмотрена регистрация событий создания, изменения и удаления записей.

Запись аудита может содержать:

  • дату и время события;
  • тип операции;
  • название коллекции и идентификатор записи;
  • пользователя, инициировавшего операцию, если он определён;
  • связанный проект;
  • категории обрабатываемых персональных данных;
  • цель обработки;
  • правовое основание;
  • применимые нормативные рамки;
  • доступные технические метаданные запроса, например IP-адрес и User-Agent.

Экспорт аудита

В платформе предусмотрен экспорт журнала аудита в CSV для подготовки отчётов и дальнейшего анализа.

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

Правовые требования и границы соответствия

Наличие технического журнала аудита помогает выполнять отдельные задачи внутреннего контроля, однако само по себе не подтверждает полное соответствие 152-ФЗ или GDPR, поскольку платформа не может регулировать подключенные внешние сервисы. Соответствие зависит также от правовых оснований обработки, информирования субъектов данных, управления согласиями там, где они необходимы, сроков хранения и удаления, обработки запросов субъектов данных, трансграничной передачи, договорных отношений и организационных мер.

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

6. Рекомендации по безопасной настройке

Для снижения рисков при использовании ТожеБот рекомендуем:

  1. Предоставлять пользователям доступ только к необходимым проектам.
  2. Ограничивать каждому агенту список доступных инструментов и баз знаний.
  3. По возможности использовать минимальные полномочия во внешних интеграциях.
  4. Не предоставлять агентам возможность выполнять критические действия без необходимых проверок и подтверждений.
  5. Анализировать срабатывания журнала безопасности и расследовать повторяющиеся инциденты.
  6. Не включать пароли, ключи API и другие секреты в инструкции агентов и общедоступные базы знаний.
  7. Ограничивать доступ к аудит-логам, экспортированным файлам и другим материалам, содержащим персональные данные.
  8. Регулярно проверять права пользователей, подключённые интеграции и настройки агентов.

7. Ограничения и ответственность

Безопасность ИИ-систем зависит не только от платформы, но и от настроек агентов, подключённых сервисов, обрабатываемых данных и полномочий инструментов.

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

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

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

Заключение

ТожеБот использует многоуровневый подход к защите данных и взаимодействий с ИИ-агентами. Он включает изоляцию пользователей и проектов, разграничение полномочий агентов, ML-защиту на базе OGL-Mini, криптографическую защиту данных с помощью QuarkDash, управление версиями ключей, мониторинг событий безопасности и аудит предусмотренных операций с персональными данными.

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

Безопасность - это совокупность технических мер, корректной конфигурации и постоянного контроля.