Корпоративная платформа · On-Premise · 2026

Мессенджер,
где данные остаются
только у вас

Чаты, звонки, файлы, видеоконференции — всё это умеют десятки готовых решений. Ни одно из них не готово дать полный контроль над хранилищем. Спроектировали с нуля — с полным On-Premise, аудитом каждого действия и тремя архитектурными противоречиями, которые пришлось решать по-честному.

On-Premise RBAC + ABAC DLP-интеграция E2EE 500+ пользователей TLS 1.3 · AES-256

уровней ролей
и прав доступа

99.9%

SLA
доступность

500

активных
пользователей

суток TTL
+ холодный архив

Зачем бизнесу свой мессенджер

Когда сотрудники используют обычные мессенджеры, данные уходят на чужие серверы. Для авиагрузовой компании это означает: утечка коммерческой информации, переписки клиентов, внутренних документов и персональных данных.

Проблема

Корпоративные данные хранятся за рубежом или в облаке без контроля.

Решение

On-Premise мессенджер: все данные остаются внутри инфраструктуры компании.

Результат

Полный аудит каждого действия, DLP-контроль, 0 инцидентов утечки.

Ключевые показатели

Размещение данных Только внутри компании

Доступность 99.9% SLA

Аудит действий Полный

DLP-контроль 4 уровня секретности

Шифрование TLS 1.3 · AES-256

Сколько стоит одна утечка данных

Оценочные риски для компании, где корпоративные коммуникации не контролируются

Штрафы по 152-ФЗ

100K+ ₽

за утечку персональных данных

Коммерческая тайна

Миллионы ₽

потери от утечки контрактов и ставок

Репутация и аудиты

Недели

на расследование инцидента

Реальная история

До внедрения сотрудники использовали сторонние мессенджеры для оперативных вопросов. После внедрения On-Premise системы все коммуникации перешли внутрь, аудит показывает каждое действие, DLP блокирует попытки утечки.

0 инцидентов

утечек после запуска

С чего всё началось

«Нам нужен мессенджер — но данные должны оставаться у нас»

Express.ms, Bitrix24, Teams, Slack — всё это отличные продукты. Но каждый из них в той или иной мере хранит данные на своей инфраструктуре: «под предлогом бэкапов», «в целях надёжности», «только метаданные». Когда у авиагрузовой компании появилось требование — все коммуникации исключительно на собственных серверах, без исключений — готовые решения один за другим садились в лужу. Пришлось проектировать платформу с нуля. А заодно выяснилось, что у заказчика ещё 150 страниц ТЗ с требованиями, три из которых прямо противоречат друг другу.

Постановка задачи

Что хотел заказчик

Авиагрузовая компания. Международные рейсы, режимный объект, служба безопасности с конкретными требованиями к аудиту. Задача формулировалась просто: «закрытый мессенджер, который мы полностью контролируем».

On-Premise, только в нашем контуре

Никаких облаков, никакого AWS и никаких «мы храним данные в Германии». Всё разворачивается на серверах заказчика. СУБД — PostgreSQL 14+ или что-то сертифицированное ФСТЭК.

Сквозное шифрование E2EE

Приватные диалоги должны быть зашифрованы end-to-end. Никто, кроме участников, не должен читать переписку.

Противоречие: следующий пункт требует ровно обратного

Администратор читает все сообщения

Служба безопасности должна иметь «комплаенс-доступ» ко всем чатам для расследований инцидентов и выполнения требований DLP.

Решение: E2EE только в режиме «Приватный диалог» с явным предупреждением. Глобально — отключено

Удалять сообщения через 15 дней

Сообщения старше 15 суток автоматически удаляются. Экономия места, минимизация данных.

Противоречие: служба безопасности требует хранить данные 3 года для расследований

Хранить всё 3 года

Инциденты расследуются месяцами. Нужно хранить историю коммуникаций для аудита, SIEM и потенциальных разбирательств.

Решение: «холодный архив» — через 15 дней данные уходят из активной БД в Data Lake, но не удаляются физически

Полное удаление для топ-менеджмента

ТОП-менеджеры и администраторы безопасности должны иметь возможность безвозвратно стереть сообщение из всех хранилищ без возможности восстановления.

Решение: криптографическое уничтожение — стирание ключей шифрования. В критическом аудите — метка действия без содержимого

Видимость контактов по иерархии

Сотрудник не должен видеть человека из несвязанного подразделения. Гость — только участников общих чатов. RBAC + ABAC одновременно.

GeoIP + сетевые ACL

Из корпоративной сети — полный доступ. С удалёнки — ограниченный функционал (нельзя скачивать файлы). Проверка — при каждой сессии, не только при логине.

Архитектурное решение

Жизненный цикл сообщения

Как примирили «удалять через 15 дней» и «хранить 3 года» в одной системе.

Отправлено
сообщение

активная БД

15 дней

Холодный
архив

Data Lake (до 3 лет)

срок политики

Физическое
удаление

+ событие в SIEM

Аудит-лог
каждого события

JSON → SIEM / CEF

Исключения по ролям

Топ-менеджмент: TTL = «Без удаления»
Проектные чаты: индивидуальный TTL
Гости: TTL по умолчанию (не изменяется)

Ручное удаление

Обычный сотрудник: только в окне 5 мин.
Сообщение скрыто в UI — но живёт в БД
В аудите: «Удалено пользователем X»

Криптоудаление (ТОП)

Стирание ключей шифрования — не запись в БД
Данные технически недоступны сразу
Критический аудит: действие без содержимого

Живое демо

Попробуйте сами: DLP в действии

Напишите что-нибудь в чат. Попробуйте отправить номер паспорта — система заблокирует сообщение и запишет событие в аудит. Это и есть DLP.

ОГ

Оперативная группа

5 участников · Закрытый чат

DLP активен

Чат создан · 09:00

Коллеги, жду документы по рейсу VDA-4482.

09:12

Готовлю, будет через 10 минут.

09:13

Хорошо, не забудьте приложить груз-манифест.

09:14

Аудит-лог в реальном времени (SIEM → JSON)

[09:12:04] SEND · user:ivanov · chat:ops-group · len:38

[09:13:11] SEND · user:petrov · chat:ops-group · len:31

[09:14:22] SEND · user:ivanov · chat:ops-group · len:45

[09:14:55] SYS · DLP daemon started · rules:247 loaded

Быстрые сценарии:

Как работает DLP: каждое исходящее сообщение проверяется по набору regex-правил (номера документов, ключевые слова, паттерны ПД) ещё до записи в БД. Заблокированное сообщение не уходит адресатам, но событие фиксируется в аудите.

Модель доступа

Пять ролей — пять уровней видимости

Не «права на кнопки», а контроль над тем, кого человек вообще может найти в системе. RBAC определяет что можно делать, ABAC — с кем.

Гость (External)

Видит только участников общих чатов. Глобального поиска нет. Не может начать диалог первым — только отвечать или быть приглашённым. Типичный кейс: подрядчик, внешний аудитор.

Ограниченный

Сотрудник (Employee)

«Серая зона»: видит прямое руководство, коллег по отделу и смежные подразделения согласно матрице ответственности. Несвязанные департаменты — невидимы. Удаление — только в окне 5 минут.

Базовый

Руководитель (Manager)

Видит весь свой отдел и подчинённые подразделения. Верификатор в цепочке запросов доступа. Опционально: «мягкое удаление» в подчинённых чатах.

Расширенный

ТОП-менеджер (TM)

Полная адресная книга. Полномочия всех ролей включая административные. Жёсткое (криптографическое) удаление. Системные оповещения по всей иерархии — получатели не могут игнорировать.

Привилегированный

Администратор (Admin)

Полная адресная книга + «супервизор-доступ» ко всем чатам. Управление политиками TTL, ролями, ACL, DLP-правилами, LDAP-интеграцией. Не несёт жёсткое удаление без права ТОП-менеджера.

Системный

Процедура запроса доступа к контакту

Сотрудник А ищет Б — не находит

Система предлагает «Запрос доступа»

Запрос → руководителю А

Нет доступа к Б? → эскалация выше

Одобрение / Отклонение · Аудит

Что умеет система

Полный функциональный стек

Коммуникации

Безопасность

Поиск

Администрирование

Клиенты

Чаты

Личные и групповые (500+ участников). Папки, метки, алиасы контактов, закрепление.

Аудио/Видео звонки

P2P и конференции с демонстрацией экрана. Собственный TURN/STUN — никакого WebRTC через облако.

Файлы и предпросмотр

Изображения, PDF, офисные документы прямо в чате. Хранение в On-Premise объектном хранилище (S3).

Иерархические оповещения

От уровня «Руководитель» и выше. По подчинённости. Нельзя скрыть до прочтения.

Шифрование

TLS 1.3 транспорт, AES-256 хранение. Ключи не покидают периметр. E2EE опционально в приватных диалогах.

DLP-интеграция

API для внешних DLP-агентов или встроенная regex-проверка. Анализ текста и файлов до записи в БД.

GeoIP + ACL

«Только корпоративная сеть» или «удалённый с ограничениями». Проверка при каждой сессии.

Аудит-лог

Каждое действие в JSON. SIEM в форматах CEF/LEEF. Поисковые запросы тоже логируются.

Полнотекстовый поиск по сообщениям

Русская и английская морфология
Точная фраза в кавычках, минус-слова
Фильтры: чат, отправитель, даты, тип
Контекстный блок вокруг найденного
Клик → переход к сообщению в чате
Отклик < 3 с (95-й перцентиль)

Безопасность поиска

Нет результатов вне зоны видимости
Нет «скрытых совпадений» из закрытых чатов
Все запросы логируются → SIEM
Паттерны «пароль», «секрет» — мониторинг
E2EE-диалоги: поиск только на клиенте

Управление пользователями

Создание, блокировка, назначение ролей. Синхронизация из AD/LDAP. Источник истины — корпоративный каталог.

Политики безопасности

TTL и исключения, окно ручного удаления, ACL, права на E2EE, DLP-правила.

Мониторинг и аудит

Просмотр логов, экспорт CSV/JSON, дашборды. Метрики PostgreSQL → Zabbix.

Интеграции

LDAP, SIEM (CEF/LEEF), DLP API, S3. OpenAPI на все методы.

Web

Chrome, Firefox, Safari, Yandex. SPA, от 1024px. Offline с очередью.

Desktop

Windows 10/11, macOS 11+. MSI/pkg, системные уведомления, горячие клавиши.

Mobile

iOS 14+, Android 8+. Push через MDM. AppStore / Google Play / корпоративный EMM.

Нефункциональные требования

Цифры, которые не обсуждаются

0.9%

SLA доступности
(без плановых простоев)

<0мс

Задержка доставки
сообщения P99

Активных пользователей
(начальная архитектура)

0ч

RTO восстановления
из резервной копии

0мин

RPO — допустимая
потеря данных

<0с

Отклик поискового
запроса (95%)

Почему не Telegram, Teams или готовый корпоративный мессенджер

Готовые решения не дают полного контроля, который нужен для режимных процессов

Контроль над ключами

E2EE в готовых мессенджерах работает на ключах вендора. У нас ключи управляются внутри компании — администратор может восстановить доступ при необходимости.

Полный аудит

Кто, когда, что отправил, редактировал, удалил. В обычных мессенджерах это невозможно или ограничено.

DLP по классам секретности

Public, Internal, Confidential, Secret — каждый уровень со своими правилами. Готовые решения не знают вашей классификации.

Интеграция с SIEM

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

Соответствие требованиям

Архитектура учитывает российские и отраслевые требования к защите данных

152-ФЗ

Персональные данные хранятся внутри страны, под контролем компании.

ФЗ-187

Критическая информационная инфраструктура — контроль и аудит.

ФСТЭК

Средства защиты информации, классификация данных, доступ.

Внутренние

Регламенты компании по хранению, удалению и архивированию.

500

пользователей в пилоте

5000

целевой масштаб

4 ч

RTO при сбое

«Для нас критично, чтобы переписка, файлы и звонки не покидали нашу инфраструктуру. Готовые мессенджеры этого не гарантируют. Сейчас у нас полный контроль: кто, что и когда отправил, кто удалил, кто скачал. Это не просто удобно — это требование бизнеса».

Сергей Волков

CISO, крупная авиагрузовая компания

500+ пользователей в пилоте

Технологический стек

Что под капотом

СУБД

PostgreSQL 14+Master-Slave HA

Файлы

S3-совместимоеOn-Premise

Поиск

PostgreSQL FTSElasticsearch

Транспорт

TLS 1.3WebSocket

Шифрование

AES-256Signal Protocol (E2EE)

Мониторинг

ZabbixSIEM (CEF/LEEF)

DevOps

DockerNginxCI/CD

DLP-классификация данных

Четыре уровня секретности

Каждое сообщение и файл получает метку. Метка влияет на то, кто видит контент, может ли DLP его пропустить, индексируется ли он в поиске.

Public

Открытые данные. Индексируются в поиске. DLP-проверка минимальная.

Internal

Внутренние документы. Только авторизованные сотрудники. Стандартная DLP-проверка.

Confidential

Конфиденциально. Ограниченный круг. Усиленный аудит при скачивании и пересылке.

Secret

Строго секретно. Только ТОП и Admin. E2EE принудительно. Скачивание заблокировано.

Бесплатный аудит требований безопасности коммуникаций

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

АК

Разработал Артур Карданов

18 лет автоматизации производств, складов и логистики

Частые вопросы

Все вопросы

Зачем компании свой корпоративный мессенджер?

Для контроля над данными и инфраструктурой. Корпоративная переписка, файлы и звонки не уходят на сторонние серверы. Можно настроить классификацию сообщений по уровню секретности, интегрировать с внутренними системами и обеспечить соответствие требованиям информационной безопасности.

Как обеспечивается безопасность данных в корпоративном мессенджере?

Развёртывание On-Premise — на серверах компании. Шифрование сообщений и файлов, классификация по уровням секретности (Public, Internal, Confidential, Secret), аудит действий пользователей, интеграция с корпоративной аутентификацией.

Даёте ли вы гарантии на результат?

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

Что такое MVP и почему вы начинаете с него?

MVP — минимальная рабочая версия системы, которая решает одну конкретную боль. Например, оперативный учёт смены на одном участке или адресное хранение на одной зоне склада. За 6–12 недель получаем реальный результат, проверяем гипотезу и дальше масштабируем. Это быстрее и безопаснее, чем пытаться сделать всё сразу.

Почему вы не продаёте готовое коробочное решение?

Потому что «среднестатистического предприятия» не существует. У каждого завода, склада и логистической компании — свои операции, методики расчёта и ограничения. Коробка заставляет подстраивать бизнес под систему. Мы делаем наоборот — систему под процесс.