Безопасность почтовой инфраструктуры: уроки истории и аудит

В профессиональной ИБ-повестке одновременно всплыли два смежных сигнала: на Хабре вышел материал Сергея Кубана из СберТеха об истории развития информационной безопасности, а ICT-Online опубликовал интервью Кирилла Тимофеева из «ОБИТ» о мониторинге разнородной корпоративной инфраструктуры. Для почтовой инфраструктуры это не отвлечённая теория. MTA, DNS, антиспам, СЗИ, облачные сервисы и бизнес-приложения давно живут в одном контуре риска, но часто контролируются разными командами и разными панелями.

История ИБ как операционная память, а не музей

В материале на Хабре автор прямо проводит аналогию с «Историей военного искусства» и предлагает рассматривать историю ИБ как дисциплину, полезную для подготовки кибербезопасников. Речь не об академическом рейтинге и не о полной хронологии: сам автор подчёркивает, что это личный взгляд, основанный на профессиональном опыте.

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

Проверьте, есть ли в вашей документации не только текущая схема SPF, DKIM и DMARC, но и история изменений. Кто менял политику. Когда менял. Почему менял. Какие инциденты были до этого. Без такой памяти инфраструктура повторяет одни и те же ошибки: временно ослабленный DMARC остаётся постоянным, старый MX забывают в DNS, тестовый домен начинает принимать боевой трафик.

Разнородная инфраструктура требует аудита до покупки новых средств

В интервью ICT-Online Кирилл Тимофеев называет главным вызовом неоднородность инфраструктуры: в одной компании могут одновременно работать старое оборудование, зарубежные решения, российские продукты и собственные разработки. В качестве фундамента отказоустойчивой инфраструктуры он выделяет ИТ-аудит. Пока состояние ИТ-активов не описано, решения о поддержке и развитии принимаются вслепую.

Для почты это особенно критично. Почтовый сервис редко состоит только из одного сервера. Обычно есть MTA, шлюз антиспама, DNS-зона, каталоги пользователей, DLP или архив, веб-почта, мобильный доступ, резервные MX, внешние рассылочные платформы, CRM и облачные компоненты. Если они не сведены в единую карту, невозможно корректно оценить риск.

Начните с инвентаризации. Зафиксируйте все домены, MX, PTR, SPF-записи, DKIM-селекторы, DMARC-политики, почтовые шлюзы, интеграции с CRM и рассылочными системами. Отдельно отметьте устаревшие узлы и сервисы, которые «ещё работают». Именно они чаще всего выпадают из мониторинга, патч-менеджмента и нормальной схемы ответственности.

Мониторинг: превентивность, омниканальность, понятная картина

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

Для почтового контура это означает минимум: контролируйте очереди MTA, задержки доставки, отказы SMTP, состояние DNS, репутационные признаки, работу антиспам-шлюзов, валидность DKIM-подписей и результат DMARC-проверок. Не держите эти сигналы в разных местах без корреляции. Если бизнес видит только «почта работает», а инженер видит только логи одного узла, инцидент уже начался.

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

Что проверить после этой повестки

Проведите аудит почтовых активов. Сверьте DNS, MTA, антиспам, облачные сервисы и бизнес-приложения. Запретите неучтённые отправители. Уберите лишние MX. Проверьте PTR для исходящих узлов. Подтвердите актуальность SPF, DKIM и DMARC.

Дальше настройте мониторинг не по одному серверу, а по сервису целиком. Почта — это маршрут. Если контролируется только конечный ящик, отказ уже пропущен. Если контролируется только SMTP, пропущены DNS и политики домена. Если контролируется только антиспам, пропущены бизнес-интеграции.

История ИБ полезна ровно настолько, насколько она превращается в регламент. Разнородная инфраструктура безопасна ровно настолько, насколько она описана, наблюдаема и управляется из проверяемой модели. Для почтового домена это не рекомендация. Это базовая гигиена эксплуатации.