Администратор может читать переписку сотрудников в Bitrix24. Это нормально?

Impersonation в Bitrix24: почему «войти под пользователем» беспокоит ИБ и как закрыть это прикладным слоем

1. Введение: корпоративный контекст

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

Важно: это не баг и не «дыра» платформы, а штатная возможность Bitrix24. Задача — не обвинять продукт, а решить инженерную проблему: как в корпоративной среде сохранить пользу от impersonation и при этом обеспечить прозрачность и контроль доступа к переписке. В статье разбираем техническую суть, регуляторный контекст и прикладной подход — модуль контроля доступа к переписке (imsecurity), его архитектуру и честные границы. Решение уже реализовано и на момент публикации проходит модерацию в Маркетплейсе Bitrix24; доступны две редакции — базовая (Standard) и расширенная (Pro).

2. Технический разбор: как устроен impersonation

Контекст сессии, а не права. При «входе под пользователем» в сессии хранятся два идентификатора: реальный администратор (ADMIN_ID) и пользователь, под которым выполнен вход (USER_ID). Критерий маскировки: ADMIN_ID > 0 и ADMIN_ID != USER_ID. Права в системе при этом не меняются — администратор по-прежнему обладает своими привилегиями; меняется контекст выполнения запросов: все вызовы REST и AJAX мессенджера (получение диалогов, истории сообщений, поис��) выполняются от имени «маскированного» пользователя. Платформа не различает «обычного» пользователя и админа, вошедшего под ним, — для мессенджера это один и тот же контекст доступа.

Что оказывается под ударом. В зоне риска — личные и групповые чаты, история сообщений, превью в списке диалогов, при определённых сценариях экспорт и поиск. Главная боль для compliance — отсутствие детального журналирования именно доступа к переписке в режиме impersonation. Стандартный аудит Bitrix24 не даёт ответа на вопросы «кто из админов заходил под пользователем», «к каким диалогам обращался», «в какое время». Для аудиторов привилегированного доступа и для внутренних регламентов ИБ этого недостаточно: действия с чувствительными данными должны быть прозрачными и доказуемыми.

3. Compliance и практический контекст

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

На практике это проявляется так. В организации на 500+ человек служба ИБ требует: «Либо мы видим, кто и когда смотрел переписку при входе под пользователем, либо такой вход в мессенджере запрещаем». В другой компании аудитор запрашивает доказательства контроля привилегированного доступа к персональным данным в мессенджере — штатных отчётов Bitrix24 не хватает. В обоих случаях нужен дополнительный слой: прикладной (модуль с логированием и политиками) или организационно-инфраструктурный (жёсткие процедуры, доступ к серверу/БД только для узкого круга). Ниже — про прикладной вариант.

4. Прикладное решение: идея и реализация

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

Ключевые элементы:

• Детектирование режима impersonation по сессии (ADMIN_ID / USER_ID).

• Перехват и блокировка/ограничение вызовов REST (im.dialog.messages.get, im.dialog.get, im.recent.get и др.) и AJAX-контроллеров мессенджера в этом режиме.

• Политики: DENY (полный запрет), READONLY (разрешить с логированием), LOG_ONLY (только лог); опционально whitelist доверенных админов с отдельными правилами.

• Журналирование каждой попытки доступа (кто, когда, к какому диалогу/чату, тип действия, IP, User-Agent, URI) в отдельную таблицу аудита.

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

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

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

Реализация вышла в двух редакциях: базовая (логирование, политики, уведомления, экстренный доступ, защита настроек) и Pro (дашборды, отчёты по стандартам, REST API для SIEM/GRC).

5. Архитектура и граница прикладного уровня

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

Схема 1 — поток запроса при просмотре переписки в режиме «под пользователем»:

  [Браузер]                    [Сервер Bitrix24]
       |  REST / AJAX (im.*, im.v2.*)  |
       |------------------------------>|
       |                    +----------+----------+
       |                    | Модуль контроля     |
       |                    | 1. ADMIN_ID != USER_ID? |
       |                    | 2. Политика (DENY/READONLY/LOG) |
       |                    | 3. Лог + уведомление |
       |                    | 4. Отдать данные или блок |
       |                    +----------+----------+
       |<------------------------------|
       |  Ответ или «доступ запрещён»   |

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

Аудит и целостность логов. Записи пишутся в таблицу вида b_im_guard_log (ADMIN_ID, IMPERSONATED_ID, действие, диалог/чат, IP, User-Agent, URI, дата). Анти-спам по TTL снижает дубли. Опционально включается защита целостности журнала: триггеры BEFORE UPDATE/DELETE на таблице логов — при попытке изменить или удалить запись в отдельную таблицу инцидентов пишется событие (операция, ID записи, снимок до изменения, пользователь БД, время). Подчистку лога это не блокирует при прямом доступе к СУБД, но делает её заметной и доказуемой.

Защита настроек. Доступ к настройкам — по мастер-паролю; критичные параметры шифруются. На таблицу b_option навешаны триггеры BEFORE UPDATE и BEFORE DELETE: прямое изменение или удаление записей с MODULE_ID модуля (из монитора производительности Bitrix или произвольным SQL) отклоняется на уровне БД, если операция не инициирована кодом модуля через форму настроек (с паролем). То есть граница «изменить настройки прямым SQL» для этого модуля закрыта триггерами — запрос не выполнится, пока код модуля не выставит служебную переменную сессии, что делается только при сохранении через форму. «Тихо» отключить контроль через админку или консоль СУБД нельзя.

Граница прикладной модели. Вся логика работает в рамках приложения плюс триггеры на таблицах модуля. Триггеры на b_option закрывают прямой SQL (и монитор производительности) для изменения настроек — UPDATE/DELETE по нашим опциям блокируются. Не закрывают: прямые SELECT к данным переписки (триггеры не перехватывают чтение), доступ по SSH, подмену кода. Защита целостности логов (триггеры на таблице журнала) не блокирует удаление записей при прямом доступе к СУБД, но фиксирует попытку в отдельной таблице инцидентов. Итого: изменение настроек модуля прямым SQL — заблокировано; чтение данных переписки прямым SQL и обход через инфраструктуру — вне зоны контроля прикладного модуля. Гарантируется поведение при работе через штатный веб-интерфейс и API Bitrix24.

Схема 2 — жизненный цикл попытки доступа:

  [Запрос переписки] --> [Impersonation?] --нет--> [Штатная обработка]
           |                      да
           |                      v
           |              [Политика: DENY / READONLY / LOG_ONLY]
           |                      |
           +---------> [Лог] --> [Блок или отдача данных]
                     +--> [Офицер ИБ: IM / e-mail / webhook]
                     +--> [Пользователю (опционально)]

Схема 3 — уровни и граница:

  +------------------+     +------------------+
  | UI (JS Guard)    |     | REST / AJAX      |
  | отображение,     |     | перехват, решение|
  | баннер           |     | отдать/блок      |
  +--------+---------+     +--------+---------+
           |                        |
           v                        v
  +-------------------------------------------------------------------+
  | Детектор impersonation + политики + лог (прикладной уровень)      |
  | Триггеры на b_option: блокируют UPDATE/DELETE по настройкам модуля |
  +-------------------------------------------------------------------+
           |
           |  Закрыто триггерами: прямой SQL / монитор — изменить настройки
           |  Не закрыто: прямой SELECT к переписке, SSH, замена кода
           v
  +-------------------------------------------------------------------+
  | БД (чтение данных), сервер, инфраструктура — отдельный контур ИБ   |
  +-------------------------------------------------------------------+

6. Ограничения

• Не защищает от администратора с прямым доступом к серверу (SSH, файловая система, замена кода).

• Не защищает от прямого чтения БД (DBA, бэкапы, дампы): триггеры не перехватывают SELECT. При этом изменение настроек модуля прямым SQL или через монитор производительности блокируется триггерами на b_option (UPDATE/DELETE по нашим опциям отклоняются).

• Не заменяет инфраструктурные меры: разграничение доступа к серверам, 2FA, VPN, аудит на уровне СУБД и ОС.

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

7. Выводы

Что закрыто прикладным модулем: детектирование impersonation, блокировка или ограничение чтения переписки по политике, полное журналирование попыток доступа, уведомления ИБ и пользователей, экстренный дос��уп с обоснованием и таймером, защита настроек мастер-паролем и триггерами на b_option. Служба ИБ получает прозрачность и доказательную базу по действиям привилегированных пользователей в мессенджере; это помогает закрывать требования 152-ФЗ, GDPR, ISO 27001 в части контроля доступа к переписке на уровне приложения.

Что остаётся инфраструктурой: защита от доступа к серверу и БД, аудит на уровне СУБД и ОС, SIEM, разграничение окружений. Эти задачи решаются политиками и инфраструктурными средствами, а не одним прикладным модулем.

Вопрос к сообществу: как у вас балансируют необходимость «войти под пользователем» для поддержки и расследований с требованием не допускать бесконтрольного доступа к переписке? Используете прикладные дополнения к коробке или делаете упор на процедуры и инфраструктурный аудит?

Решение, о котором идёт речь в статье, реализовано и готовится к публикации в Маркетплейсе Bitrix24 (две редакции — Standard и Pro). Если тема для вас актуальна, после выхода модуля можно будет оценить его в своей среде.

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

Статья носит технический и дискуссионный характер; не является рекламой и не содержит призывов к покупке.