Защита переписки в чатах Bitrix24

Прикладной контроль доступа администраторов к корпоративной переписке при использовании функции «Авторизоваться под пользователем» — с логированием, политиками и compliance-ориентированной архитектурой.

Проблема

В коробочной версии Bitrix24 предусмотрена штатная функция «Авторизоваться под пользователем»: администратор может войти в систему от имени любого сотрудника и выполнять действия в его контексте. Для технической поддержки и расследований это удобно. Для службы информационной безопасности — источник рисков.

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

Важно: это не баг и не уязвимость, а штатная возможность продукта. Проблема — в отсутствии прозрачности и контроля при корпоративном использовании.

Журналирование. Стандартный аудит Bitrix24 не даёт ответов на вопросы «кто из админов заходил под пользователем», «к каким диалогам обращался», «в какое время». Для аудиторов привилегированного доступа и внутренних регламентов ИБ этого недостаточно.

Регуляторный контекст. Требования задаются разными рамками: 152-ФЗ (ограничение доступа и учёт действий с ПДн), GDPR (минимизация доступа, подотчётность), ISO/IEC 27001 (контроль привилегированного доступа, логирование). Общий запрос: действия администраторов при доступе к чувствительным данным должны фиксироваться, храниться и при необходимости предъявляться.

Инженерный подход

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

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

Контроль режимов доступа. Решение принимается на сервере; клиентский слой согласует интерфейс с принятой политикой. Блокировка и ограничения действуют при работе через штатный веб-интерфейс, мобильные и десктопные приложения, REST API.

Функциональность

Мастер-пароль и защита конфигурации. Доступ к настройкам модуля — по отдельному мастер-паролю. Чувствительные параметры хранятся в зашифрованном виде. Триггеры на таблице b_option блокируют прямое изменение настроек модуля через монитор производительности или SQL — отключить контроль в обход формы и пароля нельзя.

Режимы контроля. Три политики: DENY (полный запрет доступа к переписке), READONLY (чтение разрешено с логированием и уведомлениями), LOG_ONLY (только логирование без блокировки). Поддерживается whitelist доверенных администраторов с отдельными правилами.

Журнал доступа. Каждая попытка доступа фиксируется: кто, когда, к какому диалогу или чату, тип действия, IP, User-Agent, URI. Записи хранятся в отдельной таблице аудита. Опционально — защита целостности журнала: триггеры фиксируют попытки изменения или удаления записей в отдельную таблицу инцидентов.

Уведомления. Алерты назначенному офицеру безопасности (IM, e-mail, webhook). Опционально — уведомление пользователю о попытке доступа к его чатам.

Emergency Override. Временное окно доступа (1–24 часа) с обязательным указанием причины, усиленным логированием и автоматическим окончанием по таймеру.

Экспорт и интеграция с SIEM. Экспорт логов в CSV и JSON для передачи в SIEM, GRC или внутреннего аудита. В расширенной редакции — REST API для прямой интеграции.

Архитектура

Модуль опирается на события Bitrix (ядро и модуль im): обработчики срабатывают до штатной выдачи данных. Перехватываются вызовы, связанные с получением списка сообщений и диалогов; REST-методы мессенджера оборачиваются — сначала проверка impersonation и политики, при отказе — запись в лог, уведомление и возврат пустого набора или ошибки.

Границы прикладного уровня. Вся логика работает в рамках приложения: события Bitrix, обёртки над REST, свой UI. Решение не модифицирует ядро платформы и не контролирует прямые запросы к БД, доступ по SSH или подмену кода.

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

Ограничения

Решение не защищает от администратора с прямым доступом к серверу (SSH, файловая система, замена кода). Не защищает от прямого чтения БД (DBA, бэкапы, дампы). Не заменяет инфраструктурные меры: разграничение доступа к серверам, 2FA, VPN, аудит на уровне СУБД и ОС. Не является DLP-системой.

Закрывается сценарий «администратор заходит в Bitrix24 под пользователем и смотрит переписку через обычный интерфейс» — с логированием, уведомлениями и при необходимости блокировкой. Это компенсирующий контроль для риска «привилегированный доступ через UI», а не защита от любого лица с полным доступом к инфраструктуре.

Для кого подходит решение

Корпоративные порталы на коробочном Bitrix24 с требованиями к контролю доступа к переписке. Компании со службой информационной безопасности, нуждающиеся в прозрачности действий администраторов. Организации, проходящие аудит по 152-ФЗ, GDPR, ISO 27001 — решение помогает закрывать требования к учёту привилегированного доступа к персональным и конфиденциальным данным на уровне приложения. Интеграторы и системные администраторы, внедряющие коробку в средах с жёсткими compliance-требованиями.

Модуль доступен для внедрения

Решение реализовано в виде модуля для Bitrix24 и проходит публикацию в Маркетплейсе. Доступны две редакции: базовая (Standard) и расширенная (Pro) с дашбордами, compliance-отчётами и REST API для SIEM.

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

Граница применимости решения

Модуль предназначен для контроля и аудита доступа к переписке через штатные механизмы платформы — веб-интерфейс, мобильные и десктопные приложения, REST API. Он должен использоваться вместе с организационными и инфраструктурными мерами ИБ. Гарантии ограничены сценарием работы через штатный интерфейс Bitrix24; прямые SQL-запросы, доступ к серверу и подмена кода остаются вне зоны контроля прикладного решения.