Защита данных в корпоративном мессенджере

Почему одного шифрования мало

Защита данных в корпоративном мессенджере у многих сводится к вопросу «зашифрованы ли сообщения?». На деле сообщение за свою жизнь проходит несколько состояний: оно создаётся на вашем устройстве, передаётся по сети, маршрутизируется на сервере и хранится на устройстве получателя. В каждом состоянии своя угроза — и для каждой нужна своя защита.

Поэтому серьёзное решение строится по модели «эшелонированной защиты» (defense in depth): даже если один слой пробит, данные остаются под следующим. Разберём ключевые слои по порядку.

E2E-шифрование сообщений

Сквозное (E2E) шифрование шифрует сообщение на устройстве отправителя и расшифровывает только на устройстве получателя. Сервер видит лишь зашифрованные байты и не может прочитать текст. Современный стандарт — протокол Signal: обмен ключами через X3DH и новый ключ для каждого сообщения через Double Ratchet.

• Forward secrecy — даже если один ключ скомпрометирован, старые сообщения остаются защищёнными.
• Групповые чаты — обычно шифруются симметричным ключом группы (AES-256-GCM).
• Сервер не видит содержимое — это главное отличие E2E от обычного «шифрования на стороне сервера».

Данные на устройстве (encryption at rest)

E2E защищает данные только «в пути». Но после получения сообщение хранится в локальной базе устройства. Если эта база лежит в открытом виде, всю историю переписки можно прочитать с украденного или бесконтрольного ноутбука.

Решение — шифровать локальную базу. На десктоп-клиентах распространённый способ — SQLCipher: надстройка над SQLite, при которой весь файл базы записывается на диск зашифрованным AES. Даже если файл базы украдут, без ключа открыть его нельзя.

Ключи в защищённом хранилище ОС

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

• Windows — DPAPI / Credential Manager, привязка к сеансу пользователя.
• macOS — Keychain.
• Linux — Secret Service (keyring).

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

Защита в транспорте, контроль доступа и размещение данных

Эшелонированную защиту дополняют ещё три важных элемента:

• TLS 1.3 — весь трафик между устройством и сервером идёт через шифрованный канал. Это защищает метаданные и токены аутентификации от атаки «человек посередине».
• RBAC (контроль доступа на основе ролей) — определяет на уровне ролей, кто к каким каналам, документам и модулям имеет доступ. Защищает от внутренних угроз и избыточных прав.
• Размещение данных (data residency) — в какой стране стоят серверы, та юрисдикция и действует. Для организаций Узбекистана размещение данных внутри страны или в собственной инфраструктуре — требование суверенитета.

Практический чек-лист

• Сообщения действительно E2E (сервер не видит открытый текст)?
• Локальная база шифруется на диске (at rest)?
• Ключи хранятся в защищённом хранилище ОС?
• Весь трафик идёт по TLS 1.3?
• Доступ ограничен ролями (RBAC)?
• Где физически хранятся данные и кто провайдер?

Как это решено в HAMA

HAMA — единая защищённая платформа для организаций Узбекистана — объединяет все перечисленные слои:

• Сообщения шифруются E2E по протоколу Signal (X3DH + Double Ratchet); для групп — AES-256-GCM.
• Локальная база шифруется с помощью SQLCipher, то есть данные защищены на устройстве в состоянии at rest.
• Ключи шифрования хранятся в защищённом хранилище операционной системы.
• Весь транспорт работает только через TLS 1.3.
• Доступ управляется через RBAC; доступные модули: мессенджер, видеоконференции, HR/оргструктура, helpdesk и другие.
• Сервер размещается в защищённом дата-центре в Узбекистане или в собственной инфраструктуре организации (on-premise) — данные хранятся в Узбекистане.

HAMA также ведёт подготовку к соответствию O'z DSt ISO/IEC 27001:2023 и требованиям ПП-167 (критическая информационная инфраструктура).