Безопасность и соответствие
Аутентификация
Заголовок раздела «Аутентификация»- Access-токены - это короткоживущие JWT (15 минут), которые проверяются на API-шлюзе; refresh-токены живут 30 дней при простое и не более 90 дней, меняются при каждом использовании и хранятся в cookie с флагами HttpOnly, Secure и SameSite. Повторное использование заменённого refresh-токена отзывает всю цепочку.
- Ключи подписи меняются каждые 90 дней с перекрытием; открытые ключи публикуются на
/.well-known/jwks.json. - Разрешения не встраиваются в токены: они считываются при каждом запросе, поэтому смена роли действует немедленно, а любую сессию можно отозвать централизованно.
- Двухфакторная аутентификация (TOTP) может быть необязательной, обязательной для владельцев и администраторов или обязательной для всех. Единый вход через Google Workspace и Apple доступен на всех тарифах. SAML 2.0, ключи доступа (passkeys) и провижининг через SCIM запланированы и пока недоступны.
- API-ключи показываются один раз, хранятся в виде хеша SHA-256, получают области доступа из закрытого каталога, ограничены разрешениями своего владельца и отзываются мгновенно. См. Аутентификация.
- Вход ограничен по IP и по e-mail; десять неудачных попыток блокируют аккаунт на 30 минут; неудачные попытки с одного IP-адреса учитываются и записываются, но по умолчанию этот адрес не блокируют. Каждый вход, неудачная попытка, обновление токена, смена разрешений и действие администратора записываются в журнал аудита.
Изоляция клиентов
Заголовок раздела «Изоляция клиентов»Каждая строка в каждом сервисе содержит аккаунт, которому она принадлежит, и каждый запрос автоматически фильтруется по нему; отключение фильтра требует явного вызова из списка разрешённых, который используется только для межклиентских операций сотрудников и покрыт тестами. Роли на уровне сайтов добавляют поверх фильтр по сайту. Запрос ресурса другого аккаунта возвращает 404, а не 403, чтобы ID нельзя было перебрать. Каждый эндпоинт записи использует строгий список разрешённых полей. Тест доступа между аккаунтами обязателен для каждого нового эндпоинта.
Заголовок X-Account-Id в каждом запросе сверяется с токеном, поэтому ошибка в клиенте или повторно использованный токен никогда не могут незаметно прочитать данные другого клиента.
Шифрование
Заголовок раздела «Шифрование»TLS 1.2 или новее для каждого публичного эндпоинта, взаимный TLS между сервисами, TLS до каждого хранилища данных, зашифрованные тома в состоянии покоя и конвертное шифрование чувствительных полей для каждого аккаунта. Публичные сертификаты выпускаются и продлеваются автоматически; внутренние сертификаты короткоживущие.
Секреты
Заголовок раздела «Секреты»Все секреты, включая ключи ваших провайдеров по модели BYOK и секреты вебхуков, хранятся в отдельном менеджере секретов - зашифрованными, с ограничением по сервисам и с аудитом. Ничего не попадает в систему контроля версий (это обеспечивается сканированием перед каждым коммитом) или в образы контейнеров (проверяется в CI). По умолчанию у разработчиков нет доступа к секретам продакшена; экстренный доступ требует двух одобрений, выдаётся ненадолго и записывается в канал, который нельзя заглушить.
Вебхуки
Заголовок раздела «Вебхуки»Исходящие доставки подписываются HMAC-SHA256 по метке времени и сырому телу, содержат nonce и ID события, отклоняются вне пятиминутного окна и повторяются с нарастающей задержкой вплоть до очереди недоставленных сообщений. Секреты меняются с окном перекрытия и могут быть отозваны мгновенно. Входящие вебхуки провайдеров проверяются по схеме каждого провайдера до какой-либо обработки. Подробнее: Вебхуки.
Ограничение запросов
Заголовок раздела «Ограничение запросов»Четыре уровня: защита от DDoS и ботов на пограничной сети, лимиты по IP на обратном прокси, корзины токенов по аккаунту и по личности на API-шлюзе и доменные лимиты внутри сервисов. Лимиты приведены в обзоре API.
Каждое изменение записывается в журнал аудита, доступный только для добавления и связанный цепочкой хешей, с двумя классами хранения: общие события и события соответствия (запросы субъектов данных, утечки, субподрядчики и записи KYC). Класс присваивается при записи; никто не может изменить или удалить журнал, а автоматическая очистка по классам пока не работает. Владельцы и администраторы могут фильтровать и экспортировать его. Пароли, токены и ключи никогда не пишутся в логи; слой логирования скрывает заведомо чувствительные ключи.
Защита данных
Заголовок раздела «Защита данных»- Запросы субъектов данных по GDPR, UK GDPR, CCPA и LGPD (доступ, экспорт, удаление) принимаются и отслеживаются в консоли соответствия со сроками. Удаление выполняют сотрудники RolChat, и запрос закрывается только после их подтверждения; автоматического удаления по всем модулям пока нет.
- Размещение данных: данные хранятся в ЕС. Регион не выбирается по стране при регистрации; настройка региона в настройках аккаунта только записывается и пока не переносит данные.
- Хранение по тарифу: 1, 2 или 3 года. Удалённые беседа или контакт скрываются до конца этого срока; удаление аккаунта - это запрос с 30 днями на отмену, после чего сотрудники стирают данные; неоплаченный аккаунт хранится 90 дней, затем данные стираются. Автоматическая очистка, которая обеспечивает эти сроки, внедряется.
- Соглашение об обработке данных (DPA), список субподрядчиков, политика конфиденциальности и политика cookie опубликованы на rolchat.com; DPA принимается при регистрации.
- Уведомление об утечке в течение 72 часов, как того требует статья 33 GDPR.
Управление уязвимостями
Заголовок раздела «Управление уязвимостями»Зависимости отслеживаются непрерывно; lock-файлы фиксируются в репозитории; базовые образы закреплены по дайджесту; действия CI закреплены по коммиту. Ежегодный сторонний тест на проникновение запланирован начиная с беты и охватывает API, виджет и публичные страницы, а также внутренний сценарий с предполагаемым взломом. С выходом общей доступности последует закрытая программа bug bounty. Сообщайте о проблемах безопасности на security@rolchat.com.
Доступность сервиса
Заголовок раздела «Доступность сервиса»Платформа работает на нескольких узлах с автоматическим переключением при отказе для сервисов без состояния и управляемой репликацией для баз данных. Целевые показатели доступности по тарифу указаны в вашем договоре.
Реагирование на инциденты
Заголовок раздела «Реагирование на инциденты»Регламенты для каждого сервиса, график дежурств, внешняя система оповещения, которая работает, даже когда не работает наша собственная инфраструктура, и обязательства по уведомлению клиентов, встроенные в процесс.