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

Модель безопасности Charo — шифрование учётных данных, вход и разграничение доступа, что уходит наружу и как развернуть систему в закрытом контуре.

Принципы

Charo работает на вашей инфраструктуре: документы, поисковый индекс, история чатов и учётные данные хранятся только там, где вы её развернули. Наружу трафик уходит к тем внешним сервисам, которые вы подключили сами: облачным LLM-провайдерам, облачным провайдерам эмбеддингов, а из источников данных — к Google Drive и к почтовым серверам, если они внешние. Телеметрию разработчику продукт не отправляет.

Три исходящих запроса включены по умолчанию, и в закрытом контуре их нужно учесть:

Запрос	Когда	Как отключить
Список одноразовых почтовых доменов	при регистрации пользователя	пустое значение `DISPOSABLE_EMAIL_DOMAINS_URL` — проверка продолжит работать по встроенному списку
Загрузка модели эмбеддингов	при первом использовании модели	`MODELS_BUCKET_URL` на внутреннее зеркало
Обновление лицензионного ключа	по кнопке в админке, вручную	пустое значение `CHARO_LICENSE_SERVER_URL` — кнопка перестаёт предлагаться

Сама лицензия проверяется полностью локально, по подписи ключа: для работы системы обращений к лицензионному серверу не требуется. Запрос к нему делает только администратор, нажав «Обновить лицензию»; автоматических обращений нет.

Хранение учётных данных

В зашифрованном виде в PostgreSQL хранятся учётные данные коннекторов, ключи API языковых моделей и провайдеров эмбеддингов, токены OAuth и секреты хуков, а также заголовки авторизации внешних действий. Шифрование — AES в режиме CBC, ключ берётся из переменной окружения ENCRYPTION_KEY_SECRET.

Что важно знать про этот ключ:

Он создаётся при установке автоматически — случайные 32 байта — и записывается в файл .env с правами доступа 600. Задавать его вручную не нужно.
Сохраните его в менеджере секретов. Без ключа учётные данные из резервной копии базы прочитать нельзя.
Ключ должен быть случайным, а не парольной фразой. Функции усиления ключа в кодеке нет, стойкость равна энтропии первых 32 символов. Если задаёте значение сами — openssl rand -hex 32.
Сменить ключ на работающей инсталляции нельзя. Перешифрования не предусмотрено: после смены все сохранённые учётные данные придётся ввести заново.
Если ключ не задан вовсе, секреты лежат в базе открытым текстом, и система предупреждает об этом в журнале при запуске.

Вход

Почта и пароль. Пароли хранятся в виде хешей argon2id. По умолчанию требуется пароль от 8 символов; требования к регистру, цифрам и спецсимволам включаются переменными окружения PASSWORD_REQUIRE_*.
Корпоративный SSO по OIDC (по лицензии). Настраивается тремя значениями: адрес конфигурации провайдера (OpenID discovery), идентификатор и секрет клиента. Поддерживаются PKCE и переопределение набора запрашиваемых прав. Адрес возврата берётся из настройки WEB_DOMAIN, а не из заголовков запроса.

Сессия живёт 7 суток (настраивается) и хранится на стороне сервера; куку защищают флаги HttpOnly и SameSite=lax, а флаг Secure добавляется автоматически, когда адрес системы начинается с https.

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

Разграничение доступа

Роли и права. Основных ролей три — пользователь, куратор, администратор; кроме них есть глобальный куратор, пользователь с ограниченным доступом и внешний пользователь с наследованными правами. Поверх ролей действует набор именованных прав на разделы админки. Подробнее — «Права доступа».
Фильтрация поиска. На каждый запрос собирается список доступов пользователя — он сам, публичные документы, его группы и группы, унаследованные из источника, — и по нему фильтруется выдача.
Наследование прав из источников поддерживают четыре коннектора: Confluence, BookStack, Google Drive и Jira — все четыре переносят и документы, и группы. Для остальных коннекторов доступ задаётся группами внутри Charo.
Группы пользователей и роли кураторов — функция, которую открывает лицензия.

Честное ограничение: права применяются на уровне приложения. Администратор сервера с доступом к базе данных технически может прочитать её содержимое — защищайте сам сервер (доступ по SSH, шифрование дисков, резервные копии).

Ключи для интеграций

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

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

Пользователей и группы можно заводить автоматически из корпоративного каталога по SCIM 2.0 (проверено на Okta) — это также лицензируемая функция.

Обращения по внешним адресам

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

Наружу открыт только обратный прокси; служебные адреса метрик через него намеренно не проксируются, а размер тела запроса ограничен 512 МБ.

Контроль использования

История запросов (с активной лицензией) — администратор видит, какие вопросы задавались и какие документы попадали в ответы.
Лимиты расходов (с активной лицензией) — ограничение потребления токенов моделей.
Журналы компонентов доступны стандартными средствами Docker (docker compose logs).

Развёртывание в закрытом контуре

Модели — локальные: Ollama или vLLM для чата, локальная модель эмбеддингов (см. «Языковые модели»).
Источники — системы, развёрнутые внутри контура: Confluence, Jira, BookStack, S3-совместимые хранилища, почтовые серверы и внутренние порталы.
TLS. Обратный прокси входит в поставку: если при установке указать домен, сертификат выпускается автоматически. В контуре без выхода в интернет поставьте перед инсталляцией свой прокси с корпоративными сертификатами.
Исходящий трафик — закройте межсетевым экраном, предварительно отключив два запроса по умолчанию (см. таблицу в начале страницы). Для работы лицензии и поиска доступ в интернет не нужен.
Образы и модели переносите заранее через внутренний реестр образов и зеркало хранилища моделей — готового офлайн-пакета в поставке нет.

Подробные требования к контуру — на странице «Требования».

Что уходит наружу при облачных моделях

Если подключён облачный LLM-провайдер, на его API уходят: вопрос пользователя и фрагменты документов, отобранные поиском как контекст ответа. Если подключён облачный провайдер эмбеддингов — содержимое всех индексируемых документов. Выбирайте провайдера с учётом этого; для чувствительных данных используйте локальные модели.

Если вы нашли уязвимость

Порядок сообщения об уязвимости и выпуска исправлений описан на странице «Требования».