betool betool

Документация

Аудит и журнал доступа GDPR

Как betool отслеживает доступ к контенту пользователей, обрабатывает право на доступ (статья 15) и право на удаление (статья 17).

Аудит и журнал доступа GDPR

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

Журнал доступа

Выделенная таблица записывает для каждого межтенантного доступа:

  • Отметку времени (с точностью до микросекунды)
  • Целевую организацию (чей контент был прочитан)
  • Читающую организацию (как правило, поставщика)
  • Роль / agent / пользователя, выполнившего чтение
  • Тип сущности (закрытый словарь: exchange_text, knowledge_chunk, audio_segment…)
  • Идентификатор сущности
  • Контекст использования (миссия, тикет, предложение)

Словарь сущностей закрыт на уровне базы данных (ограничение CHECK) и закрыт на уровне кода (белый список приложения). Добавление типа требует новой миграции и обновления белого списка. Никаких неожиданных записей.

Право на доступ (статья 15)

Каждая организация может ознакомиться СО СВОИМИ СОБСТВЕННЫМИ журналами доступа через:

GET /api/admin/me/content-reads

Доступные фильтры: диапазон времени, тип сущности, идентификатор сущности, читающая идентичность. Экспорт в CSV / Excel для передачи специалисту по защите данных.

Никакого межорганизационного доступа к журналу аудита: поставщик никогда не видит журналы аудита клиента.

Право на удаление (статья 17)

Поддерживаются три уровня удаления:

  1. Удаление пользователя — конечный пользователь запрашивает удаление своих данных в рамках организации-клиента. Организация инициирует удаление через панель администратора или административный API.
  2. Удаление организации — организация покидает betool. Все её ресурсы удаляются: таблицы, отфильтрованные по org_id, файловое хранилище очищается, секреты удаляются. Договорной срок по умолчанию: 30 дней на отзыв, затем необратимая очистка.
  3. Юридическое удаление — по постановлению суда, удаление конкретных элементов без затрагивания остального. Регистрируется в журнале аудита со ссылкой на правовое основание.

Согласие и отзыв согласия на межтенантное чтение

По умолчанию согласие на межтенантное чтение установлено в FALSE. Организация может включить его в разделе Администрирование → Конфиденциальность → Межтенантное чтение.

Три режима:

  • Полный отказ — по умолчанию. Поставщик не может получить доступ к какому-либо контенту этой организации. Следствие: межорганизационная поддержка на уровне контента невозможна (структурная поддержка и бизнес-флаги остаются доступными).
  • Временное согласие — авторизация на фиксированный период времени, отзываемая.
  • Постоянное согласие — для клиентов, желающих проактивной поддержки (редко в банковской сфере, распространено в стандартном SaaS).

Поставщик НЕ МОЖЕТ активировать это согласие от имени клиента. Это фундаментальный тест: если поставщик может переключить его без действия клиента, значит архитектура нарушена.

Предохранитель деструктивных операций

Любая операция, которая уничтожает или заменяет контент (DELETE, REPLACE-IN-PLACE), отклоняется на уровне валидатора, если целевая организация не активировала согласие на чтение. Обоснование: без видимости оператор предложил бы полезную нагрузку, которая могла бы вслепую перезаписать существующий контент.

Каскадный отказ при недоступности аудита

Если база данных аудита недоступна (инцидент инфраструктуры), все межтенантные чтения отклоняются. Строгая политика: никакого чтения без следа.

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

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