Федерация корпоративного мессенджера: как связать независимые On-Premise-контуры и сохранить контроль над данными
Корпоративный мессенджер обычно разворачивается внутри контролируемой ИТ-инфраструктуры. Организация самостоятельно управляет учетными записями, правами доступа, политиками информационной безопасности, хранением файлов и журналированием действий. Однако реальные рабочие процессы редко ограничиваются рамками одной компании.
Проектные команды взаимодействуют с подрядчиками, поставщиками, дочерними обществами и стратегическими партнерами. Если для таких коммуникаций использовать публичные сервисы, часть рабочего контекста неизбежно выходит за пределы корпоративного периметра. Федерация позволяет решить эту задачу иначе: связать независимые инсталляции мессенджера, не объединяя их инфраструктуру и системы управления.
В ноябре 2025 года была выпущена федерация VK WorkSpace для двух On-Premise-инсталляций. В релизе 26.2, который вышел в июле 2026 года, ограничение на парное взаимодействие сняли: теперь в одном групповом чате могут одновременно работать пользователи нескольких независимых контуров.
Что дает федерация
Федерация объединяет отдельные инсталляции таким образом, чтобы каждая организация сохраняла собственные серверы, базы данных, администраторские роли и политики безопасности. При этом участники могут обмениваться разрешенными сообщениями, файлами и событиями.
Модель доступа состоит из двух уровней.
Первый уровень - доверие между инсталляциями. Одна организация отправляет приглашение, а другая подтверждает установление связи. Сам факт наличия такого соединения еще не означает, что все сотрудники получают возможность общаться между собой.
Второй уровень - допуск конкретных пользователей. Администратор каждой стороны самостоятельно определяет, каким сотрудникам разрешена внешняя коммуникация в рамках выбранного траста.
Одна инсталляция может иметь несколько независимых связей - например, с дочерними обществами, подрядчиками и партнерами. Для каждого отношения задаются отдельные правила. Поэтому организация контролирует не только список доверенных контуров, но и перечень сотрудников, которым разрешено пользоваться внешними чатами.
Полный корпоративный справочник между сторонами не синхронизируется. Во внешнюю организацию передается только необходимая карточка пользователя: имя, фамилия, рабочий адрес электронной почты и признак принадлежности к другой компании. Это снижает объем раскрываемых данных и упрощает соблюдение внутренних политик безопасности.
При отзыве траста или индивидуального допуска новые действия пользователя блокируются. При этом история переписки, которая уже была получена организацией, остается в ее локальном контуре и не исчезает автоматически.
Федерация, мультидоменность и гостевой доступ
Эти механизмы решают разные задачи.
Федерация предназначена для постоянного взаимодействия независимых организаций с раздельным администрированием и взаимно согласованным доверием.
Мультидоменность применяется, когда подразделения или домены находятся внутри одного тенанта и работают по единой модели управления.
Гостевой доступ подходит для временного подключения внешнего участника к конкретному чату, встрече или обсуждению. В этом случае постоянного доверия между инфраструктурами не требуется.
Таким образом, федерация необходима там, где внешняя коммуникация становится регулярной, а стороны не готовы объединять свои контуры или передавать управление общей инфраструктурой.
Архитектурные варианты
Для реализации подобного сценария можно использовать несколько подходов.
Первый вариант - хранить сообщения и файлы только в одной, хостовой инсталляции, а пользователям остальных организаций предоставлять удаленный доступ через прокси. Такой подход экономит дисковое пространство, но формирует зависимость от владельца данных. Если хостовая сторона станет недоступной, разорвет траст или изменит политики, другие участники могут потерять доступ к истории и вложениям.
Кроме того, прокси-модель усложняет разграничение прав, аудит и обработку сетевых сбоев. Для корпоративного мессенджера потребуется отдельная логика удаленного доступа к каждому объекту, включая сообщения, файлы, реакции и служебные события.
Второй путь - использование открытого федеративного протокола, например Matrix. В такой модели события комнаты реплицируются между homeserver-ами участников. Единственного сервера-владельца комнаты нет, а обмен строится через стандартизованный Server-Server API. Открытая спецификация облегчает совместимость, но требует адаптации существующей бизнес-логики, клиентских приложений, модели прав и механизмов хранения.
Третий подход - локальная репликация данных в каждом участвующем контуре. Именно его выбрали для федерации VK WorkSpace. Каждая сторона получает собственную копию разрешенных объектов, хранит ее в своей инфраструктуре и самостоятельно отвечает за доступ к ней.
Почему выбрали локальную репликацию
При локальной репликации участник не зависит от постоянной доступности сервера другой организации. Если между контурами временно нарушена связь, уже доставленные сообщения и файлы остаются доступными локальным пользователям в соответствии с их правами.
Такой подход лучше соответствует требованиям On-Premise-развертываний:
- данные хранятся внутри контролируемого контура;
- каждая организация самостоятельно отвечает за резервное копирование;
- аудит выполняется локальными средствами;
- политики хранения и удаления применяются независимо;
- сбой одного контура не обязательно делает недоступной историю в другом;
- администраторы сохраняют раздельный контроль над пользователями и доступами.
Репликация не означает полное копирование корпоративной базы. Между сторонами передаются только объекты, связанные с разрешенным взаимодействием. Служебные данные, внутренние справочники и переписки, не относящиеся к федерации, остаются изолированными.
Как работает обмен
После установки доверия стороны обмениваются техническими параметрами и идентификаторами инсталляций. Когда пользователь создает сообщение во внешнем чате, его контур проверяет наличие разрешения, формирует событие и передает его принимающей стороне.
Получатель проверяет источник, подпись, права участников и принадлежность события нужному чату. После успешной валидации данные записываются в локальное хранилище и становятся частью локальной истории.
События должны обрабатываться идемпотентно: повторная доставка одного и того же сообщения не должна приводить к созданию дублей. Для этого используются идентификаторы событий, контроль последовательности и механизмы повторной отправки при временных ошибках.
Отдельно обрабатываются файлы. В чат передается не только сообщение, но и информация о вложении, после чего принимающая сторона получает файл и сохраняет его в своем контуре. Это позволяет применять локальные ограничения на размер, типы данных, срок хранения и антивирусную проверку.
Что пришлось изменить в клиентских приложениях
Для пользователя внешний чат должен выглядеть привычно, но при этом интерфейс обязан четко показывать границы организаций. Поэтому в карточках участников, списках диалогов и сообщениях отображается внешний контекст.
Пользователь должен понимать:
- кто является внешним участником;
- из какой организации он пришел;
- можно ли отправить ему сообщение;
- какие действия доступны в таком чате;
- где хранятся переданные файлы;
- кто управляет правами доступа.
Это не только вопрос удобства. Явная маркировка снижает риск случайной отправки конфиденциальной информации не тому адресату.
Одним из важных принципов стала фильтрация недоступных действий. Если пользователь не может пригласить участника, переслать файл или изменить параметры чата из-за межконтурных ограничений, интерфейс не должен показывать такую кнопку как рабочую. Скрытие или корректное отключение недоступных операций уменьшает число ошибок и обращений в поддержку.
Как развивали решение после пилота
Первый релиз поддерживал взаимодействие между двумя отдельными инсталляциями. Практика показала, что реальным организациям требуется более сложная модель: один чат может объединять представителей нескольких компаний, а не только двух сторон.
После этого были расширены правила маршрутизации событий, модель участников и обработка внешнего контекста в клиентских приложениях. Система должна была учитывать, что сообщение может проходить через несколько независимых контуров, а права каждого пользователя определяются его собственной организацией.
Дополнительно потребовалось обеспечить согласованную работу с редактированием сообщений, удалением, реакциями, упоминаниями, ответами и вложениями. Для каждой операции нужно было определить, какие данные реплицируются, как фиксируется авторство и что происходит, если одна сторона временно недоступна.
Самые сложные задачи
1. Не показывать неработающие действия
В распределенной системе доступность функции зависит не только от роли пользователя, но и от состояния траста, политики другой организации и типа объекта. Поэтому недостаточно проверить права локального пользователя. Нужно учитывать межконтурные ограничения и состояние внешней стороны.
2. Сохранять внешний контекст во всем интерфейсе
Маркер внешнего пользователя должен присутствовать не в одном месте, а во всех важных сценариях: в сообщениях, результатах поиска, профиле, списке участников, уведомлениях и окне пересылки. Иначе пользователь может забыть о границе между организациями.
3. Добавлять федеративные возможности без переписывания ядра
Базовый мессенджер изначально проектировался для единого контура. Поэтому федерацию важно было встроить поверх существующей логики, не разрушая модели чатов и сообщений. Для этого использовались дополнительные идентификаторы, признаки внешнего происхождения, отдельные проверки прав и слой межконтурного обмена.
Ограничения текущей версии
Федерация не превращает несколько компаний в единую организацию. У каждой стороны остаются собственные правила безопасности, лимиты, политики хранения и процедуры расследования инцидентов.
Не все функции могут работать одинаково во всех комбинациях контуров. Ограничения возможны для массовых рассылок, администрирования групп, изменения состава участников, работы с удаленными сообщениями и некоторых корпоративных интеграций.
Также необходимо учитывать юридические требования к хранению данных. Локальная репликация повышает автономность, но одновременно увеличивает количество копий информации. Организациям требуется заранее определить сроки хранения, порядок удаления и правила обработки резервных копий.
Что важно предусмотреть при внедрении
Перед запуском федерации следует сформировать реестр доверенных организаций и описать цели каждой связи. Для подрядчика, дочернего общества и стратегического партнера могут потребоваться разные правила доступа.
Нужно заранее определить:
- кто утверждает установление траста;
- какие сотрудники получают внешние права;
- какие типы файлов разрешены;
- как контролируется передача конфиденциальной информации;
- кто отвечает за расследование инцидентов;
- как отзывается доступ при увольнении или смене проекта;
- как синхронизируются политики хранения;
- какие журналы событий доступны администраторам.
Отдельное внимание стоит уделить мониторингу. Администратору важно видеть состояние связей, задержки доставки, ошибки репликации, число внешних пользователей и события отзыва доступа. Без таких метрик федерация превращается в непрозрачный интеграционный слой, который сложно сопровождать.
Перспективы развития
Дальнейшее развитие федерации может включать более гибкие политики для разных типов чатов, расширенный аудит, автоматическое управление допусками через корпоративные каталоги и более подробные настройки для файлов и внешних интеграций.
Перспективным направлением остается автоматизация жизненного цикла доверия: создание связи по согласованному регламенту, временный доступ для проектной команды, автоматический отзыв после завершения договора и регулярная переоценка прав.
Федерация становится практичным компромиссом между полной изоляцией и переносом коммуникаций в публичные сервисы. Организации сохраняют независимость инфраструктуры и контроль над данными, а сотрудники получают единое рабочее пространство для взаимодействия с внешними командами. Именно сочетание локального хранения, взаимного доверия и раздельного администрирования делает такую модель пригодной для защищенных корпоративных сценариев.