Как мы развернули корпоративный защищённый мессенджер в облачной инфраструктуре

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

Мы решили проверить, возможно ли развернуть полностью автономный защищённый мессенджер в собственной облачной инфраструктуре — так, чтобы он не зависел от внешних сервисных сетей. В качестве технологической основы взяли open-source проект Signal — один из самых известных мессенджеров с end-to-end шифрованием. На практике задача оказалась значительно сложнее обычного развёртывания open-source сервиса.

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

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

Чтобы запустить автономную систему коммуникаций, нам пришлось решить несколько ключевых задач.

Разобрать архитектуру серверной части. Мы изучили структуру серверных сервисов и зависимости между компонентами системы — без какой-либо документации, только по исходному коду.

Воспроизвести инфраструктуру. Нужно было запустить все сервисы в изолированном контуре, независимо от инфраструктуры основной сети Signal.

Повторить реализацию криптографических механизмов. Часть компонентов использовала доверенные вычислительные среды на базе Intel SGX — нам предстояло разобраться, как это устроено, и воспроизвести у себя.

Создать собственную документацию. Поскольку официальных инструкций не было вовсе, мы формировали документацию по ходу работы — с нуля.

Работа над проектом заняла около трёх месяцев до первого рабочего запуска и продолжалась в режиме поддержки и обновлений ещё два года.

Анализ архитектуры. Мы детально изучили серверную часть Signal: определили состав микросервисов, их роли и взаимодействие. Для этого пришлось читать исходный код и отслеживать изменения между версиями проекта.

Воспроизведение инфраструктуры. Для запуска системы мы собрали распределённую облачную инфраструктуру на нескольких платформах одновременно: AWS, Microsoft Azure, Google Cloud, а также специализированные инстансы с процессорами Intel для работы с SGX-компонентами. Такая конфигурация позволила воспроизвести требования всех сервисов системы.

Повторение реализации криптографического контура. Отдельной задачей стала работа с компонентами на базе Intel SGX — технологии защищённых вычислений на уровне процессора. В апреле 2025 года Intel прекратил поддержку облачной схемы аттестации (Intel IAS / EPID). Старая конфигурация перестала работать. Signal переписали свой код под новую локальную схему, но документации по её запуску не было никакой — ни у Signal, ни в публичном поле.

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

В ходе работы мы столкнулись с несколькими серьёзными техническими сложностями:

— полное отсутствие документации по развёртыванию;

— сложная распределённая архитектура с зависимостями от нескольких облачных платформ одновременно;

— отключение критического инфраструктурного компонента (Intel IAS) в процессе работы;

— необходимость ежемесячного ручного анализа upstream-изменений без каких-либо release notes.

Чтобы решить эти задачи, мы выполнили reverse engineering архитектуры системы и разработали собственную схему развёртывания и поддержки.

В результате мы воспроизвели рабочий форк Signal, развёрнутый в собственной облачной инфраструктуре. Система работает независимо от основной сети сервиса и поддерживается в актуальном состоянии с ежемесячными обновлениями.

Полученная архитектура позволяет запускать систему автономно, контролировать хранение данных, адаптировать функциональность и синхронизироваться с upstream-проектом.

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

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

Облачная инфраструктура: AWS, Microsoft Azure, Google Cloud — одновременно, для разных компонентов системы.

Технологии безопасности: Intel SGX (доверенные вычисления на уровне процессора), enclave-среды, механизмы удалённой аттестации, генерация ключей и управление сертификатами.

Архитектурные подходы: multi-cloud инфраструктура, reverse engineering системы без документации, собственный процесс обновлений и внутренняя техническая документация.