Облачная система MULTIFACTOR прошла сертификацию ФСТЭК для защиты корпоративных данных

Для команд, которые строят защищённый доступ к корпоративной почте, админкам и удалённым рабочим местам, это не просто новость про очередной сертификат: в гибридном контуре теперь заявлен аттестованный облачный компонент. А значит, при выборе 2FA можно меньше дробить стек между локальной инфраструктурой и облаком.

Аттестован не только периметр

Как сообщается, MULTIFACTOR состоит из облачной и клиентской частей. В аттестованный состав вошли сертифицированная версия облака, адаптеры и мобильное приложение из сертифицированного состава решения.

Система заявлена как соответствующая требованиям по защите информации для класса защищённости К1 и уровня защищённости персональных данных УЗ1, а также приказам ФСТЭК России № 17 и № 21. Гибридная версия, по данным источников, отвечает 4-му уровню доверия и может применяться в государственных организациях с высокими требованиями к безопасности.

Практический смысл для почтовой инфраструктуры понятный: MFA перестаёт быть «надстройкой на входе» и становится частью единого контура доступа. Особенно там, где сотрудники подключаются к ресурсам не только из офиса, а доступы размазаны между VPN, удалёнными рабочими столами, VDI, SSH и облачными сервисами.

Где здесь профит для почтовой команды

MULTIFACTOR предназначен для двухфакторной аутентификации при удалённых подключениях, включая RDP, VPN, VDI и SSH. Для администраторов корпоративной почты это повод проверить не только логин в веб-интерфейс, но и всю цепочку привилегированного доступа: кто может попасть на сервер, в панель управления доменом, к резервным копиям и настройкам маршрутизации.

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

Минимальный чек-лист после новости:

• запросить у поставщика состав именно аттестованного решения, а не ограничиться формулировкой «есть облачная MFA»;
• сверить, какие адаптеры и мобильные компоненты входят в этот состав;
• отдельно описать доступы к почтовым системам, VPN, RDP и SSH — это разные сценарии и разные риски;
• проверить, не живут ли учётные записи администраторов в той же логике, что и обычные пользовательские доступы;
• заложить обновления в процесс эксплуатации: компания сообщила, что планирует обновлять аттестованную часть вместе с сертифицированной версией.

Не путать статус решения с готовностью вашего контура

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

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

Для ИТ-команд из разных отраслей, включая компании, которые следят за ростом рынка подключаемых гибридов в России, логика одинаковая: чем больше цифровых контуров и удалённых подключений, тем важнее заранее понимать, где именно проходит граница защищённого доступа.