Контроль и защита

Безопасность AI‑виджета и защита данных

Изоляция интерфейса, разрешённые сайты, серверные секреты и минимизация данных в текущей архитектуре.

Обновлено 22 июля 20269 минут чтенияПрактическое руководство

Как INWISE AI защищает виджет и подключение: разрешённые Origin, серверные секреты, Shadow DOM, локальная история чата и агрегированные метрики. Ниже — рабочие рекомендации, которые помогут настроить функцию осознанно и проверить результат до публикации.

Базовые принципы защиты

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

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

Разрешённые Origin

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

Серверные ключи и публичный код

Фрагмент установки неизбежно доступен браузеру, поэтому в нём не должно быть серверного API‑ключа модели, пароля администратора или других критичных секретов. Секретные значения хранятся и используются на серверной стороне.

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

История чата и аналитика

В текущей реализации история диалога хранится в sessionStorage активной браузерной сессии. Серверный отчёт использует агрегированные показатели и не сохраняет тексты сообщений, IP‑адреса и пользовательские идентификаторы.

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

Чек‑лист перед публикацией

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

Частые вопросы

Почему установочный код виден в браузере?

Клиентский фрагмент по своей природе публичен. Он не должен содержать серверные секреты; доступ дополнительно ограничивается разрешёнными Origin и серверной сессией.

Где хранится API‑ключ модели?

В текущей архитектуре ключ настраивается и используется на сервере и не передаётся в браузер пользователя.

Можно ли просить пользователя прислать пароль?

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