Почтовый сервер для компании: архитектура, выбор модели и настройка безопасности

Электронная почта остаётся одним из основных каналов деловой коммуникации. Через корпоративные ящики проходят договоры, счета, документы и переписка с партнёрами. За адресом вида имя@компания.ru стоит инфраструктура, которую нужно поддерживать: настраивать домен, контролировать безопасность, создавать резервные копии и следить за доставляемостью.

Ниже разберём основные варианты организации корпоративной почты, требования к инфраструктуре, DNS-настройки, защиту и порядок миграции.

Главное сразу:

• Корпоративная почта включает маршрутизацию, хранение, защиту и управление доступом.
• Выбор между собственной инфраструктурой, IaaS и готовым сервисом зависит от требований бизнеса и возможностей IT-команды.
• Собственный сервер сам по себе не обеспечивает хорошую доставляемость. На неё влияют настройки аутентификации, DNS и репутация отправителя.
• RAID повышает отказоустойчивость хранилища, но не заменяет резервное копирование.

Почтовая система принимает, отправляет, фильтрует и хранит сообщения от имени домена организации.

Есть три базовых варианта её размещения:

• собственное оборудование в офисе или дата-центре;
• виртуальный сервер у IaaS-провайдера;
• управляемая почтовая услуга.

Почтовый хостинг можно рассматривать как упрощённый вариант управляемого сервиса с меньшим набором корпоративных функций.

Главное различие между этими моделями заключается в распределении ответственности. В собственной инфраструктуре организация самостоятельно отвечает за оборудование, ОС, программное обеспечение, защиту и резервирование. При IaaS физический уровень обслуживает провайдер, а ОС и почтовое ПО остаются в зоне ответственности заказчика. В SaaS значительную часть инфраструктурных задач берёт на себя поставщик услуги.

SMTP, IMAP и POP3

SMTP используется для передачи сообщений от клиента на сервер и между почтовыми системами. Для защиты соединения может применяться TLS. Поддержка и политика его использования зависят от настроек обеих сторон.

IMAP позволяет хранить письма и их состояние на сервере. После синхронизации изменения, например отметка о прочтении, становятся доступны другим подключённым клиентам.

POP3 предназначен главным образом для загрузки писем на устройство. Классический сценарий предполагает удаление сообщений после получения, хотя современные клиенты позволяют оставлять копии на сервере. Для работы с одним ящиком на нескольких устройствах обычно удобнее IMAP.

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

При расчёте объёма дисков нельзя ориентироваться только на сумму квот ящиков. Нужно учитывать:

• служебные данные;
• поисковые индексы;
• журналы;
• временные файлы;
• рост объёма переписки;
• архивы;
• резервные копии.

Точный запас лучше рассчитывать по документации выбранной платформы и фактической динамике использования.

Если корпоративная переписка содержит персональные данные, необходимо учитывать требования Федерального закона Российской Федерации № 152-ФЗ «О персональных данных». При использовании зарубежных сервисов отдельно учитываются требования к трансграничной передаче персональных данных.

Использование личных ящиков сотрудников для рабочих задач затрудняет контроль доступа и сохранение истории коммуникаций.

Корпоративный домен позволяет централизованно управлять учётными записями. После увольнения сотрудника доступ можно заблокировать, не теряя переписку и связанные с ней данные.

Основные преимущества

Централизованное управление. Администратор создаёт, блокирует и изменяет учётные записи из единой системы.

Архивирование и аудит. Можно организовать хранение переписки в соответствии с внутренними регламентами и применимыми требованиями законодательства. Срок хранения определяется типом документов и правилами организации.

Интеграция. Почтовую систему можно связать с LDAP, Active Directory, CRM, ERP и другими корпоративными сервисами.

Управление доменной репутацией. Организация самостоятельно настраивает SPF, DKIM, DMARC и другие механизмы, влияющие на доверие к исходящей почте.

Сам адрес на корпоративном домене не гарантирует попадание во «Входящие». Доставляемость зависит от совокупности технических и репутационных факторов.

Собственный сервер

Организация устанавливает почтовое программное обеспечение на собственном или выделенном оборудовании.

В этом случае IT-команда контролирует ОС, хранилище, сетевые настройки, политики безопасности и резервное копирование.

Такой вариант подходит, если есть требования к изоляции данных, особые интеграции или внутренние правила, которые сложно реализовать в готовом сервисе.

При этом потребуется постоянное сопровождение:

• установка обновлений;
• мониторинг;
• настройка антиспама;
• контроль репутации IP;
• резервное копирование;
• реагирование на инциденты.

Почтовый сервер в IaaS

Виртуальная машина арендуется у облачного провайдера.

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

Ресурсы виртуальной машины обычно проще изменить, чем конфигурацию собственного физического сервера. Однако увеличение CPU или RAM в некоторых облаках требует перезагрузки или остановки виртуальной машины.

Готовая облачная почта

В SaaS-модели заказчик получает готовые ящики на своём домене.

Инфраструктура, обновления и значительная часть защиты находятся на стороне поставщика. Администратор компании управляет пользователями, правами, группами и внутренними политиками.

Срок запуска зависит от количества ящиков, объёма переносимой переписки, структуры доменов и требований к миграции.

Для организаций без собственной IT-команды такой вариант часто оказывается проще в сопровождении.

Почтовый хостинг

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

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

Цена одного почтового ящика показывает только часть расходов. При сравнении нужно учитывать полную стоимость владения:

• лицензирование;
• оборудование или облачные ресурсы;
• резервирование;
• мониторинг;
• работу администратора;
• защиту;
• восстановление после сбоев;
• стоимость простоя.

У On-Premise и IaaS также разный уровень контроля. Собственное оборудование позволяет управлять и физической инфраструктурой. В IaaS оборудование и гипервизор контролирует провайдер, а клиент отвечает за ОС и приложения.

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

Процессор

Маршрутизация обычных писем сама по себе редко создаёт максимальную нагрузку. Значительная часть CPU может использоваться для:

• антиспам-проверок;
• антивирусного анализа;
• TLS;
• индексации;
• поиска;
• веб-интерфейса.

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

Пороговые значения лучше определять по нормальному профилю конкретной системы.

Оперативная память

RAM используют почтовые процессы, базы данных, поисковые индексы, антивирусное ПО и веб-интерфейс.

При её нехватке возрастает обращение к swap или pagefile, после чего задержки начинают зависеть от скорости накопителей.

Размер памяти подбирают по фактической загрузке и рекомендациям используемой платформы.

Накопители

Почтовая инфраструктура создаёт большое количество операций с небольшими файлами и индексами.

При выборе хранилища нужно учитывать:

• IOPS;
• latency;
• скорость последовательного чтения и записи;
• стабильность характеристик;
• резервирование.

SSD и NVMe обычно обеспечивают более низкую задержку, чем HDD, что особенно заметно при активной работе с индексами и большим количеством мелких операций. Однако конкретный тип накопителей нужно подбирать по нагрузке.

Сеть

Для почты обычно важны стабильность соединения и доступность сервиса.

Пропускную способность нужно рассчитывать по:

• объёму входящей и исходящей переписки;
• среднему размеру вложений;
• числу пользователей;
• резервному копированию;
• другим сервисам, использующим тот же канал.

Если принимающий SMTP-сервер временно недоступен, отправляющие системы обычно сохраняют сообщение в очереди и повторяют попытку доставки. Кратковременный обрыв связи сам по себе не означает потерю входящей почты.

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

Для современной корпоративной почты обычно настраивают MX, SPF, DKIM, DMARC и корректный reverse DNS.

MX

MX указывает, какие серверы принимают почту для домена.

У домена может быть один или несколько MX с разными приоритетами. Количество записей не определяет производительность сервиса.

SPF

SPF описывает разрешённые источники отправки от имени домена.

В запись должны входить все легитимные серверы и сервисы, которые отправляют почту для организации.

DKIM

DKIM добавляет к исходящим сообщениям криптографическую подпись.

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

При этом DKIM не защищает от всех видов мошенничества. Если злоумышленник получил доступ к легитимной учётной записи, письмо также может быть корректно подписано.

DMARC

DMARC использует результаты SPF и DKIM вместе с проверкой соответствия домена аутентификации адресу в поле From.

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

DMARC-отчёты не показывают, попало конкретное письмо во «Входящие» или в «Спам».

PTR

PTR используется для обратного DNS и связывает IP-адрес с доменным именем.

Для исходящего сервера желательно, чтобы reverse DNS и прямая A/AAAA-запись были согласованы.

У нового IP ещё нет истории отправок. Поэтому объём исходящей почты лучше увеличивать постепенно.

Фиксированного срока «прогрева» нет. Он зависит от объёма писем, реакции получателей, жалоб, возвратов и правил принимающих систем.

Резкое увеличение объёма рассылки может привести к ограничениям, ухудшению репутации и блокировкам. Особенно опасны случаи компрометации учётной записи, когда через корпоративный сервер начинает отправляться большое количество нежелательной почты.

Почтовый сервер должен принимать соединения из интернета, поэтому его необходимо регулярно обновлять и контролировать.

Сетевой уровень

Неиспользуемые сервисы и порты закрываются.

Для клиентского доступа и отправки писем пользователями применяется TLS. Межсерверный SMTP также должен поддерживать защищённое соединение там, где это возможно.

Административные интерфейсы желательно ограничить VPN, внутренней сетью или списком доверенных адресов.

Публично открытый TCP-порт 25 сам по себе не делает сервер open relay. Такой сервер появляется при неправильных настройках ретрансляции, когда сторонний пользователь может отправить через него письмо на внешний домен без соответствующего разрешения.

Учётные записи

Минимальный набор мер:

• многофакторная аутентификация;
• ограничения попыток входа;
• контроль подозрительных авторизаций;
• своевременная блокировка уволенных сотрудников;
• отдельные административные учётные записи.

Проверка содержимого

Для защиты используются:

• антиспам;
• антивирус;
• анализ ссылок;
• фильтрация опасных типов вложений;
• sandbox для подозрительных файлов, если он предусмотрен выбранной системой.

Технические средства стоит дополнять обучением сотрудников. Особенно это важно при целевом фишинге и попытках получить доступ к корпоративным аккаунтам.

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

Но RAID не создаёт независимую копию данных.

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

Что нужно резервировать

В зависимости от платформы в резервную копию включают:

• почтовые базы;
• содержимое ящиков;
• конфигурацию;
• учётные записи;
• политики доступа;
• сертификаты и ключи;
• DKIM-ключи;
• правила маршрутизации;
• алиасы;
• необходимые параметры DNS.

Глубина хранения определяется требованиями RPO и RTO, временем обнаружения инцидентов и внутренними правилами организации.

Резервные копии должны быть изолированы от основной среды. Это можно реализовать:

• на отдельной площадке;
• у другого провайдера;
• в другом регионе;
• в отдельном аккаунте того же облака;
• через immutable-хранилище или другие механизмы защиты от изменения.

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

Периодически нужно выполнять тестовое восстановление. Без такой проверки нельзя быть уверенным, что архив действительно пригоден для аварийного восстановления.

Для повышения доступности могут применяться:

• несколько интернет-каналов;
• резервные серверы;
• репликация;
• кластеризация;
• несколько MX;
• резервирование хранилища.

Резервный MX не обязан содержать полную копию всех ящиков. Он может временно принимать почту и передавать её основному узлу после восстановления связи.

При этом резервный сервер необходимо корректно настроить как relay и защитить не хуже основного.

Число сотрудников само по себе не определяет подходящую архитектуру.

Для небольшой организации важнее понять, кто будет отвечать за почтовую инфраструктуру.

Если штатного администратора нет, готовый сервис или управляемый почтовый хостинг обычно проще в эксплуатации.

Свой сервер имеет смысл рассматривать при наличии конкретных требований:

• особая юрисдикция хранения;
• нестандартные интеграции;
• собственные политики безопасности;
• необходимость полного контроля конфигурации;
• ограничения используемого SaaS.

По мере увеличения организации обычно повышаются требования к:

• SLA;
• централизованной авторизации;
• аудиту;
• архивированию;
• API;
• распределению административных ролей;
• защите мобильных устройств;
• интеграции с CRM и ERP.

Такие возможности могут предоставляться как собственной инфраструктурой, так и корпоративными SaaS-платформами.

Поэтому размер компании не является автоматическим основанием для перехода на собственный сервер.

Выбор ОС и почтовой платформы зависит от существующей IT-инфраструктуры и компетенций специалистов.

Windows

Microsoft Exchange хорошо интегрируется с Active Directory и экосистемой Microsoft. Он предоставляет функции почты, календарей, контактов и централизованного управления.

При выборе нужно учитывать модель лицензирования и требования к серверным ресурсам.

Linux

На Linux можно построить систему из отдельных компонентов, например Postfix и Dovecot, либо использовать готовую платформу.

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

Главные критерии выбора:

• работа с LDAP или AD;
• календари и совместная работа;
• мобильный доступ;
• API;
• безопасность;
• возможности масштабирования;
• доступные компетенции администраторов.

Этот вопрос относится прежде всего к месту размещения инфраструктуры.

Облако

IaaS позволяет обойтись без закупки физических серверов и быстрее изменять доступные вычислительные ресурсы.

При этом заказчик зависит от возможностей поставщика. Некоторые изменения конфигурации могут потребовать перезагрузки виртуальной машины.

Собственная площадка

Своё оборудование даёт максимальный физический контроль.

Одновременно организация отвечает за:

• серверы;
• резервное питание;
• охлаждение;
• сеть;
• замену оборудования;
• физическую безопасность.

Расширение нужно планировать с учётом фактического темпа роста и сроков закупки.

Выбор нужно делать по требованиям к безопасности, интеграциям, SLA, стоимости владения и возможностям команды.

Миграцию желательно выполнять по заранее подготовленному плану.

1. Собрать список ящиков, алиасов, групп и служебных адресов.
2. Определить объём переписки.
3. Подготовить новую платформу.
4. Создать пользователей и проверить права.
5. Выполнить предварительный перенос исторических сообщений.
6. Настроить SPF, DKIM, DMARC и reverse DNS для нового отправляющего узла.
7. Заранее снизить TTL MX-записи. Это нужно сделать как минимум за один действующий старый TTL до переключения.
8. Изменить MX.
9. Контролировать доставку на старый и новый узел.
10. Выполнить дополнительную синхронизацию сообщений, которые пришли в переходный период.
11. Отключать старую инфраструктуру только после анализа логов и подтверждения, что актуальная входящая почта на неё больше не поступает.

DNS-записи не имеют фиксированного времени «распространения». Рекурсивные DNS-серверы могут продолжать использовать старое значение до истечения TTL из своего кэша.

Чек-лист перед запуском

• Домен и делегирование настроены корректно.
• MX указывает на нужный сервер.
• SPF содержит все легитимные источники отправки.
• DKIM настроен и проверен.
• DMARC опубликован.
• Для отправляющего IP настроен корректный reverse DNS.
• HELO/EHLO использует резолвимое имя.
• Используется статический публичный IP, если этого требует выбранная схема.
• TLS настроен для клиентских подключений.
• SMTP поддерживает STARTTLS.
• Сертификаты действительны.
• Отправка и получение проверены.
• Антиспам и антивирус работают.
• Брутфорс-защита включена.
• Неиспользуемые сервисы закрыты.
• Административный доступ ограничен.
• Настроен мониторинг очередей.
• Контролируется свободное место.
• Работает резервное копирование.
• Выполнено тестовое восстановление.
• Определены лимиты ящиков.
• Настроена политика отключения учётных записей.
• Проверена доставляемость исходящих сообщений.
• Подготовлен план расширения ресурсов.

Отсутствие мониторинга дисков

Полное исчерпание свободного места может привести к ошибкам записи, остановке отдельных компонентов и проблемам с приёмом или обработкой сообщений.

Порог предупреждения следует выбирать с учётом скорости роста данных и времени, которое понадобится на расширение хранилища.

Open relay

Причина open relay заключается в неправильной настройке ретрансляции.

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

Отсутствие контроля очереди

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

Порог алерта лучше определять относительно нормального профиля конкретного пользователя или домена, дополняя его абсолютными лимитами.

Ошибки DNS-аутентификации

Отсутствие требуемых принимающей стороной SPF, DKIM, DMARC или корректного reverse DNS может ухудшить доставляемость или привести к отказам.

Конкретные требования зависят от почтового оператора и характера отправки.

RAID вместо бэкапа

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

Массовые рассылки через основной домен

Резкое увеличение объёма массовой почты способно ухудшить репутацию IP и домена.

Для маркетинговых рассылок обычно целесообразно отдельно продумывать инфраструктуру, политики отправки и контроль репутации.

Сколько времени занимает прогрев нового IP?

Фиксированного срока нет. Объём исходящих сообщений лучше увеличивать постепенно и контролировать SMTP-ответы, жалобы, возвраты и репутацию отправителя.

Что делать, если IP попал в чёрный список?

Сначала нужно определить причину блокировки: компрометация ящика, ошибки конфигурации, спам или проблемы с репутацией IP. После устранения причины изучают правила конкретного DNSBL. Одни списки снимают блокировку автоматически, другие требуют заявки.

Нужен ли отдельный почтовый антивирус?

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

Когда стоит уходить с SaaS на собственный сервер?

Переход имеет смысл, если готовый сервис перестал выполнять требования по интеграциям, безопасности, юрисдикции, SLA или стоимости владения. Сам рост количества пользователей не является достаточным основанием.

Что происходит после изменения MX?

Часть DNS-резолверов может продолжать использовать прежний MX до истечения его TTL. Поэтому старый сервер оставляют доступным на переходный период и контролируют его логи до прекращения входящей доставки.

Можно ли хранить резервную копию у того же облачного провайдера?

Да, если backup изолирован от основной инфраструктуры. Для этого могут использоваться отдельный аккаунт, регион, защищённое от изменения хранилище и независимые права доступа.