Secure messaging comparison

SANKET и SalaX: сравнение защищённых платформ обмена сообщениями

Защищённый обмен сообщениями SalaX и Sanket предназначены для организаций, работающих в регулируемых отраслях. Оба решения допускают развёртывание на собственных серверах и в изолированных от сетей средах с ключами под контролем заказчика. Sanket построен на Signal Protocol с постквантовыми механизмами PQXDH и SPQR, шифрованием AES-256 на каждом уровне, подписанными списками устройств, взаимной аутентификацией устройств по TLS и ключами администраторов FIDO2. Продукт разрабатывается и поддерживается в Индии.

Запросить демонстрацию Читать технический документ

О SalaX Secure Messaging

SSH Коммьюникейшнз Секьюрити Ойю · Финляндия

Защищённый обмен сообщениями SalaX - компонент для обмена сообщениями в реальном времени в составе платформы защищённой совместной работы SalaX от SSH Communications Security, финской компании, создавшей исходный протокол SSH. Он построен на платформе Element и стандарте Matrix с шифрованием Olm и Megolm. Доступен как программное обеспечение по модели предоставления услуг из европейского облака или для размещения на собственных серверах, в том числе в изолированной от сетей среде, с ключами под контролем заказчика.

Sanket и SalaX Secure Messaging: параллельное сравнение

Критерий	SANKET	Защищённый обмен сообщениями SalaX
Кто контролирует инфраструктуру	Заказчик. По одной выделенной установке на каждую организацию, на принадлежащей ей или выбранной ею инфраструктуре, без управляемого поставщиком сервиса на пути передачи сообщений.	У заказчика (на собственных серверах, в частном или публичном облаке) либо как сервис из европейского облака.
Варианты развертывания	Выделенная установка в любом выбранном заказчиком облаке и регионе (или на инфраструктуре Tosh Defence), на серверах заказчика либо в полностью изолированной от сетей среде; на одном сервере или в конфигурации высокой доступности с восстановлением на второй площадке.	Программное обеспечение как услуга, развёртывание на собственных серверах, частное облако, публичное облако, изоляция от сетей и внеполосная связь.
У кого находятся ключи и кто контролирует идентификацию	Заказчик и его пользователи. Ключи создаются на каждом устройстве и защищены аппаратными средствами хранения; идентификаторами служат Sanket ID, контролируемые заказчиком, без необходимости привязки к личному номеру телефона.	Ключи шифрования принадлежат заказчику (поставщик). Требование указать номер телефона: в открытой документации не описано.
Протокол шифрования	Signal Protocol реализован через официальную библиотеку libsignal от Signal, прошедшую независимый аудит. Сообщения защищены шифрованием AES-256-CBC и проверкой подлинности HMAC-SHA256 внутри libsignal; для файлов и звонков используется AES-256-GCM; для TLS применяются только наборы шифров с AES-256-GCM.	Matrix с Olm и Megolm, AES-256; на базе платформы Element.
Постквантовая защита	Да, в текущем выпуске: PQXDH с обязательным постквантовым предварительным ключом Kyber и храповым механизмом SPQR (тройной храповой механизм), а также гибридный обмен ключами X25519MLKEM768 на пограничном узле TLS.	Not publicly documented
Сквозное шифрование групп и звонков включено по умолчанию	Да. Личные и групповые сообщения, реакции, зашифрованные широковещательные сообщения и файлы всегда защищены сквозным шифрованием; для голосовых и видеозвонков применяется шифрование кадров AES-256-GCM с пятью новыми ключами для кадров в секунду внутри SRTP AES-256-GCM.	По заявлению поставщика, чаты, аудио- и видеозвонки и передача файлов защищены сквозным шифрованием.
Поставщик удостоверений заказчика (SSO / LDAP)	Да. Вход через собственный каталог заказчика по протоколам OIDC, SAML 2.0 или LDAP, создание учётных записей через SCIM 2.0 и аппаратные ключи безопасности FIDO2 для администраторов.	Проверка с помощью многофакторной аутентификации, одноразового пароля, персонального идентификационного номера, единого входа или банковского идентификатора (защищённая совместная работа SalaX).
Средства администрирования и управление устройствами	Одобрение и отзыв доступа устройств, режим потери и удаленное стирание данных, подписанные списки устройств, взаимная аутентификация устройств по TLS, политики хранения сообщений, пересылки и буфера обмена, метки классификации, определяемые заказчиком, и журнал аудита с цепочкой хешей для системы SIEM заказчика.	Перекрёстная проверка устройств по цифровым подписям; бот для аудита и ведение записей.
Суверенитет данных (юрисдикция, разработано в Индии)	Разработано в Индии компанией Tosh Defence. Данные остаются в выбранной заказчиком юрисдикции и на выбранной им инфраструктуре. В продуктах нет аналитики сторонних поставщиков и зависимости от зарубежных компонентов при работе.	SSH Communications Security Oyj, Хельсинки, Финляндия; развёртывание в отдельных регионах ЕС или отдельных странах.
Целостность выпусков и контроль обновлений	Выпуски подписаны с помощью Ed25519 и проверяются перед установкой; предусмотрены фиксация версии и защита от отката на предыдущую версию, а при сбое обновления автоматически восстанавливается прежнее состояние. Заказчик сам решает, когда обновляться: через интернет или с помощью подписанного автономного пакета.	Not publicly documented
Платформы	Нативные приложения для iOS, Android, Windows, macOS и Linux. Отсутствие браузерного клиента предусмотрено архитектурой: атаковать через него невозможно.	Приложения для настольных компьютеров, мобильных устройств и браузеров.

Кто контролирует инфраструктуру

SANKET

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