Как выбрать защиту электронной почты (SEG): критерии, сценарии и чек-лист

Короткий ответ: сначала определите регуляторный статус организации — субъект КИИ или госсектор сужает выбор до продуктов с действующим сертификатом ФСТЭК, коммерческая компания без таких обязательств выбирает свободнее. Дальше зафиксируйте, какие каналы угроз должен закрывать SEG — не только массовый спам, но и целевой фишинг, BEC, вредоносные вложения и ссылки.

Определите модель развёртывания (облако, on-premise, гибрид) исходя из требований к передаче почтового трафика за периметр, проверьте, есть ли у кандидата готовая интеграция с вашей почтовой платформой, и только в конце сравнивайте лицензирование и совокупную стоимость владения.

SEG (Secure Email Gateway, шлюз защиты электронной почты) — класс средств, который проверяет входящую и исходящую корпоративную почту до её попадания в ящик пользователя и закрывает сразу несколько типов угроз: массовый спам, целевой фишинг, BEC-атаки (Business Email Compromise — компрометация деловой переписки через подмену отправителя или взлом аккаунта), вредоносные вложения и ссылки на вредоносные или фишинговые сайты.

В Реестре российского ПО этому набору функций соответствует класс «Защита почты» (код 03.18).

SEG нужен практически любой организации, где почта — рабочий канал коммуникации с сотрудниками и контрагентами: встроенный спам-фильтр почтовика закрывает массовые рассылки, но не таргетированные атаки, где письмо приходит от знакомого на вид адреса без явных признаков вредоноса. Если в компании есть финансовые операции по почте, доступ к персональным данным или коммерческой тайне, либо организация — субъект КИИ, отдельная защита от фишинга и BEC — не опция, а базовая мера.

Сравнение продуктов класса — на странице класса «Защита почты».

Модель развёртывания определяет и скорость внедрения, и требования к контуру, и то, кто отвечает за обновление сигнатур и правил детекта.

Встроенный антиспам — Exchange Online Protection, фильтр CommuniGate Pro, МойОфис Почты или другого почтовика — неплохо отсекает массовые рассылки по сигнатурам и репутации отправителя. Против таргетированного фишинга и BEC он работает слабее: письмо от скомпрометированного или похожего адреса технически не выглядит вредоносным, а у встроенных фильтров обычно нет песочницы для вложений и ссылок, отдельного детекта подмены отправителя и мониторинга DMARC-политики домена.

Ниже — критерии, которые проверяют у любого кандидата независимо от вендора и модели развёртывания.

1. Определите, обязателен ли для вас сертификат ФСТЭК (субъект КИИ, госорган, компания с госучастием).
2. Составьте список каналов угроз, которые нужно закрыть: спам, фишинг, BEC, вредоносные вложения, вредоносные ссылки.
3. Определите модель развёртывания — облако, on-premise или гибрид — исходя из требований к передаче данных за периметр.
4. Проверьте, поддерживает ли SEG вашу почтовую платформу нативно (Exchange/M365, CommuniGate Pro, МойОфис Почта, VK WorkMail) или только через универсальный релей.
5. Уточните, есть ли встроенная песочница для вложений и ссылок или нужен внешний модуль.
6. Проверьте поддержку и помощь в настройке DMARC/SPF/DKIM для собственного домена компании.
7. Оцените механизм защиты от подмены отправителя — lookalike-домены, display name spoofing.
8. Проверьте модель карантина — есть ли self-service release для пользователей.
9. Запросите у вендора данные о доле пропущенного спама и ложных срабатываний на своём трафике.
10. Сверьте срок действия сертификата ФСТЭК выбранного продукта в госреестре СЗИ ФСТЭК.
11. Посчитайте TCO на 3 года: лицензия по числу ящиков, внедрение, обучение сотрудников, поддержка.
12. Запросите пилот на реальном почтовом трафике компании, а не на демо-данных вендора.

• Полагаться только на встроенный антиспам почтовика. Базовая фильтрация закрывает массовый спам, но не покрывает BEC и целевой фишинг, где письмо приходит с легитимного на вид адреса.
• Не настраивать DMARC-политику для собственного домена. Без неё злоумышленники могут рассылать фишинг от имени компании, а сама компания не видит эти попытки и не может их пресечь.
• Выбирать облачный SEG без проверки требований к передаче данных за периметр. Для субъектов КИИ и госсектора это может создать проблему с регулятором уже после внедрения, а не до него.
• Недооценивать нагрузку на пользователей без self-service карантина. Каждое задержанное письмо без возможности самостоятельного разбора превращается в тикет в ИТ-поддержку.
• Сравнивать SEG только по списку функций из презентации вендора. Доля ложных срабатываний и пропущенного спама сильно зависит от специфики трафика конкретной компании — это стоит проверять на пилоте, а не на маркетинговых материалах.

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

Смежные классы, которые часто внедряют вместе с защитой почты: антивирус — проверка файлов по сигнатурам, дополняет антивирусный движок SEG; песочница (sandbox) — динамический анализ вложений и ссылок, если у SEG нет встроенного модуля; DLP — контроль исходящей почты на утечку данных, а не только входящих угроз. Для субъектов КИИ регуляторные требования — в разделе «КИИ» на SecRadar, для писем с персональными данными — в разделе 152-ФЗ.