Chat Access Control for Bitrix24 (On-Premise)

Application-level control of administrator access to chat content when using “Log in as user” (impersonation)—logging, policies, and compensating controls for compliance.



The Problem

Bitrix24 on-premise includes a built-in “Log in as user” (impersonation) feature. It is intended for support and investigations: an administrator can sign in as a given employee and reproduce an issue.

In that mode, the administrator gains access to that user’s personal and work chat history without separate approval and without a detailed record of who accessed what and when. This is not a platform bug but a designed capability.

In corporate environments the risks are clear: access to personal data, confidential business discussions, and negotiations. The standard Bitrix24 audit does not answer “which admins logged in as which users,” “which dialogs were accessed,” or “when.” For privileged-access auditors and internal security policies, that is not enough.

Control requirements come from multiple frameworks: GDPR (minimization of access, accountability), ISO/IEC 27001 (privileged access control, logging), jurisdictional rules (e.g., 152-FZ for Russian deployments), and internal policies on communications and NDAs. The common need is that administrator access to sensitive data must be recorded, retained, and available for review when required.

Engineering Approach

The approach is not to disable the feature but to add an application-level control layer: detect impersonation, evaluate policy, and either block chat content access or allow it with mandatory logging and notifications.

Compensating controls:

  Application-level checks on top of the platform’s standard mechanisms;
  Access policies (deny, allow with logging, log-only);
  Detailed logging of each access attempt;
  Control of access modes and protection of module configuration.




Functionality

  Master Password and Configuration Protection
  Settings are protected by a master password. Sensitive parameters are encrypted. Triggers on b_option prevent direct changes to the module’s options via the performance monitor or SQL.

  Control Modes
  DENY—full block on chat content access; READONLY—read allowed with logging; LOG_ONLY—logging only, no blocking. Optional whitelist of trusted administrators and per-rule exceptions.

  Access Log
  Each attempt (who, when, which dialog/chat, action type, IP, User-Agent, URI) is written to a dedicated audit table. Export to CSV/JSON for SIEM or internal audit.

  Notifications
  Alerts to the security officer (IM, email, webhook); optionally, notify the user when their chats are accessed.

  Emergency Override
  Time-limited access window (1–24 hours) with mandatory reason, enhanced logging, and automatic expiration.

  Export and SIEM Integration
  Log export in standard formats; REST API and webhook for SIEM/GRC.




Architecture

The module operates at the application layer: Bitrix events (core and im module), handlers that run before data is returned. Calls related to message and dialog listing are intercepted; messenger REST methods are wrapped—impersonation and policy are checked first; on deny, an entry is written to the log, notifications are sent, and an empty result or error is returned. The decision is made on the server; the client UI is aligned with that decision.

Application-layer boundaries: all logic stays within the application (Bitrix events, REST wrappers, custom UI, triggers on the module’s tables). The module does not control direct database SELECTs, SSH access, or code substitution. Triggers provide integrity and block changes via Bitrix’s standard interfaces but do not replace infrastructure-level DBMS auditing.

A JS extension passes the impersonation flag and policy into the messenger; the UI can hide content, show a placeholder, and display a banner that actions are logged. This does not replace server-side checks but aligns the interface with them.

Limitations

The module does not protect against an administrator with direct server access (SSH, file system, code changes). It does not protect against direct database reads (DBA, backups, dumps). It does not replace infrastructure controls: access segregation, 2FA, VPN, DBMS and OS-level auditing. It is not a DLP solution.

The solution addresses the scenario “administrator logs into Bitrix24 as a user and views chat content through the normal interface”—with logging, notifications, and optional blocking. It is a compensating control for “privileged access via UI,” not protection against anyone with full infrastructure access.

Who It Is For

Corporate portals on Bitrix24 on-premise. Organizations with a security function and requirements for privileged access control. Audited organizations (e.g., subject to 152-FZ, GDPR, ISO 27001). Integrators deploying the on-premise product in compliance-heavy environments.

Next Steps

The module is implemented and is being published on the Bitrix24 Marketplace. Two editions are available—Standard and Pro. If this is relevant to your environment, we can discuss deployment architecture and adaptation to your policies.

Scope of the Solution

The application-level module provides control and audit of chat access through the platform’s standard mechanisms (web UI and Bitrix24 API). It does not protect against an administrator with direct server or database access and should be used together with organizational and infrastructure security measures.