Информационная безопасность почтовых систем как элемент стратегии бизнеса

Для почтового контура это означает отказ от модели «настроили SPF, DKIM, DMARC — и забыли». Контроли, учётные записи, внешние сервисы и маршруты доставки должны проверяться непрерывно.

Причины не меняются: ошибки сотрудников, компрометация credentials, уязвимые или неверно настроенные внешние сервисы, риски подрядчиков. Почта пересекается со всеми этими точками входа.

Почтовый контур — часть поверхности атаки

APT-кампании, по оценке Полянского, используют традиционные способы проникновения, но выбирают цель и готовятся к атаке длительное время. Для MTA это практический вывод: не ограничивайте защиту антиспамом на входе.

Проверьте:

• кто имеет доступ к панели домена, DNS и почтовому шлюзу;
• какие сервисные учётные записи могут отправлять почту от имени домена;
• нет ли устаревших SMTP-релеев, открытых API, legacy-авторизации и неиспользуемых интеграций;
• совпадают ли SPF-записи с фактическими отправителями;
• проходят ли DKIM-подписи на всех рабочих потоках, включая CRM, тикет-системы и подрядные платформы;
• применяется ли DMARC-политика, а отчёты DMARC разбираются регулярно.

PTR, TLS и выравнивание доменов сами по себе не остановят компрометацию аккаунта. Но они сокращают число обходных маршрутов и ускоряют диагностику инцидента.

Закрывайте уязвимости по срокам, а не по остаточному принципу

В материале «Ведомостей» отмечены конкретные сроки, установленные приказом ФСТЭК № 117: критические уязвимости необходимо устранять в течение суток, высокого уровня — в течение семи дней. Также упоминаются отдельные требования к защите систем с технологиями ИИ и расширение круга затрагиваемых организаций.

Для администратора почты здесь нет отдельного режима. Включите MTA, webmail, антиспам-шлюз, DNS-панель, VPN и IdP в общий процесс vulnerability management. Не ждите планового окна, если обновление закрывает критический дефект на внешнем сервисе.

Минимальный порядок действий:

1. Инвентаризируйте все публичные почтовые узлы и административные интерфейсы.

2. Назначьте владельца каждого сервиса и резервного ответственного.

3. Разделите доступы: администратор DNS не должен автоматически получать права на MTA и почтовые ящики.

4. Настройте журналирование аутентификации, изменений DNS, правил пересылки и транспортных политик.

5. Отработайте отзыв паролей, токенов и ключей DKIM без остановки легитимной доставки.

ИИ не отменяет базовую дисциплину

Отдельный пост на «Хабре» описывает компрометацию части инфраструктуры Hugging Face через вредоносный датасет и последующую работу с учётными данными. В публикации прямо отмечено: независимого подтверждения полностью автономной атаки нет, а часть технических деталей не раскрыта. Поэтому переносить этот кейс в разряд установленного шаблона атаки нельзя.

Но эксплуатационный вывод остаётся прежним: не допускайте выполнения непроверенного кода в обработчиках данных, ограничивайте права worker-окружений, ротируйте секреты и изолируйте сервисные аккаунты. Для почтовых систем тот же принцип применяется к фильтрам, парсерам вложений, webhook-обработчикам и интеграциям с LLM.

Не исключайте защитные меры по одной причине или одному инструменту. Логика близка к тому, почему нельзя слепо исключать продукты из рациона ради похудения: важна не единичная мера, а контролируемая система с понятными ограничениями и проверяемым результатом.