Улучшение потока почты с помощью MTA-STS

Статья
08/18/2023

В Exchange Online добавлена поддержка стандарта SMTP MTA Strict Transport Security (MTA-STS). Стандарт был разработан для обеспечения использования TLS для подключений между почтовыми серверами. Кроме того, он позволяет отправлять серверы для проверки, что у получающего сервера доверенный сертификат. Если TLS не предлагается или сертификат недействителен, отправитель отказывается доставлять сообщения. Эти новые проверки улучшают общую безопасность SMTP и защищают от атак "злоумышленник в середине".

MTA-STS можно разбить на два сценария: входящая и исходящая защита. Входящая защита охватывает защиту доменов, размещенных в Exchange Online с помощью MTA-STS. Защита от исходящего трафика охватывает проверки MTA-STS, выполняемые Exchange Online при отправке сообщений электронной почты в домены, защищенные MTA-STS.

Совет

Если вы не являетесь клиентом E5, используйте 90-дневную пробную версию решений Microsoft Purview, чтобы узнать, как дополнительные возможности Purview могут помочь вашей организации управлять безопасностью данных и соответствием требованиям. Начните сейчас, перейдя в центр пробных версий на портале соответствия требованиям Microsoft Purview. Сведения о регистрации и условиях пробной версии.

Исходящая защита

Все сообщения, отправляемые из Exchange Online получателям, защищенным MTA-STS, проверяются с помощью этих дополнительных проверок безопасности, установленных стандартом MTA-STS. Администраторы ничего не должны делать, чтобы применить его. В нашей реализации исходящей защиты пожелания владельцев домена получателя выполняются с помощью политики MTA-STS. MTA-STS является частью инфраструктуры безопасности Exchange Online, поэтому она всегда включена (как и другие основные функции SMTP).

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

Код ошибки	Описание	Возможная причина	Дополнительные сведения
5.4.8	Узлы MX "{domain}" не прошли проверку MTA-STS	Конечный узел MX не был узлом, ожидаемым для политики STS домена.	Эта ошибка обычно указывает на проблему с политикой MTA-STS целевого домена, не содержащей узел MX. Дополнительные сведения о MTA-STS см. в разделе https://datatracker.ietf.org/doc/html/rfc8461.
5.7.5	Сбой проверки MTA-STS удаленного сертификата. Причина: {validityStatus}	Сертификат почтового сервера назначения должен быть привязан к доверенному корневому центру сертификации, а общее имя или альтернативное имя субъекта должно содержать запись для имени узла в политике STS.	Эта ошибка обычно указывает на проблему с сертификатом почтового сервера назначения. Дополнительные сведения о MTA-STS см. в разделе https://datatracker.ietf.org/doc/html/rfc8461.

Входящая защита

Владельцы домена могут принять меры для защиты сообщений электронной почты, отправленных на их домены с помощью MTA-STS, если их запись MX указывает на Exchange Online. Если запись MX указывает на промежуточную стороннюю службу, необходимо определить, выполняются ли требования MTA-STS, а затем следуйте их инструкциям.

После того как MTA-STS настроена для вашего домена, все сообщения, отправляемые от отправителей, которые поддерживают MTA-STS, будут выполнять проверки, изложенные в стандарте, чтобы обеспечить безопасное подключение. Если вы получаете сообщение от отправителя, который не поддерживает MTA-STS, оно все равно будет доставлено без дополнительной защиты. Аналогичным образом отправка сообщений не прерывается, если вы еще не используете службу MTA-STS, но отправитель поддерживает ее. Единственный сценарий, в котором сообщения не доставляются, — если обе стороны используют проверку MTA-STS и происходит сбой проверки MTA-STS.

Как принять MTA-STS

Стандарт MTA-STS позволяет домену объявить поддержку TLS и сообщить, какую запись MX и сертификат назначения следует ожидать. Он также указывает, что должен делать отправляющий сервер в случае возникновения проблемы. Это взаимодействие осуществляется с помощью сочетания записи DNS TXT и файла политики, опубликованного в виде веб-страницы HTTPS. Политика, защищенная https, представляет еще одну меру безопасности, которую должны преодолеть злоумышленники.

Доменная TXT-запись MTA-STS указывает отправителю о поддержке MTA-STS, после чего отправитель извлекает политику MTA-STS домена на основе HTTPS. Следующая TXT-запись является примером объявления поддержки MTA-STS:

_mta-sts.contoso.com. 3600 IN TXT v=STSv1; id=20220101000000Z;

Политика MTA-STS домена должна располагаться по заранее определенному URL-адресу, размещенному в веб-инфраструктуре домена. Синтаксис URL-адреса: https://mta-sts.<domain name>/.well-known/mta-sts.txt. Например, политика Microsoft.com находится по адресу: https://mta-sts.microsoft.com/.well-known/mta-sts.txt.

version: STSv1
mode: enforce
mx: *.mail.protection.outlook.com
max_age: 604800

Любой клиент, чьи записи MX указывают непосредственно на Exchange Online, может указать в своей политике те же значения, которые отображаются в https://mta-sts.microsoft.com/.well-known/mta-sts.txt. Уникальные обязательные сведения в политике — это запись MX, указывающая на Exchange Online (*mail.protection.outlook.com), а один и тот же сертификат предоставляется всем Exchange Online клиентам. Exchange Online позволяет только одной организации получать сообщения электронной почты для определенного домена, чтобы использование подстановочных знаков не ослабляло безопасность, однако это может быть не так для других служб электронной почты. Вы можете опубликовать политику в тестовом режиме, чтобы убедиться, что она действительна, прежде чем изменить ее на режим принудительного применения . Существуют сторонние средства проверки, которые могут проверить вашу конфигурацию.

Эти политики не являются тем, что Exchange Online может размещаться от имени клиентов, поэтому клиенты должны настроить политику службы stS своего домена с помощью предпочитаемых служб. Службы Azure можно легко использовать для размещения политик, и далее в этой статье описано пошаговое руководство по настройке. Политика должна быть защищена протоколом HTTPS с сертификатом для поддомена mta-sts.<domain name>.

После создания записи DNS TXT и доступа к файлу политики по необходимому URL-адресу HTTPS домен будет защищен С помощью MTA-STS. Сведения о MTA-STS доступны в RFC 8461.

Настройка входящих MTA-STS с помощью служб Azure

Примечание.

Эти потоки конфигурации были разработаны, чтобы помочь клиентам Microsoft Exchange Online размещать политику MTA-STS с помощью ресурсов Azure. Этот поток конфигурации предполагает, что вы являетесь клиентом Exchange Online, который знает, как работает MTA-STS и его требования. Дополнительные сведения о протоколе за пределами этого раздела см. в разделе RFC8461.

Для размещения политики MTA-STS можно использовать два ресурса Azure: Статическое веб-приложение Azure и Функции Azure. Хотя в этой статье описано, как развернуть политику с помощью обоих ресурсов, рекомендуемый метод — это статическое веб-приложение Azure , так как оно предназначено для размещения статических страниц, таких как политика STS, и Azure упрощает настройку, предоставляя сертификат TLS для веб-страницы MTA-STS без необходимости дополнительной настройки. Если вы не можете использовать статическое веб-приложение Azure, вы также можете разместить политику в виде бессерверного кода с помощью Функции Azure. Этот подход не является предпочтительным методом, так как Функции Azure — это функция, предназначенная для других сценариев, и она не выдает tls-сертификат автоматически, в отличие от Статические веб-приложения Azure. Таким образом, при использовании Функции Azure для MTA-STS требуется выдача собственных "mta-sts".[ ваш домен]" сертификат и привяжите его к функции.

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

Эти потоки конфигурации предназначены для предоставления только технических сведений о функциях Azure, которые можно использовать для размещения политики MTA-STS, и не предоставляют никаких сведений о расходах или расходах на компоненты Azure. Если вы хотите узнать о затратах на функции Azure, воспользуйтесь калькулятором цен Azure.

Вариант 1 (РЕКОМЕНДУЕТСЯ): Статическое веб-приложение Azure

Создайте организацию Azure DevOps или используйте организацию, которая уже существует. В этом примере для размещения политики MTA-STS будет использоваться организация ContosoCorporation.
В репозитории > Файлы клонируйте репозиторий в любой интегрированной среде разработки, которую вы предпочитаете. В этом примере репозиторий будет клонирован в Visual Studio.
После клонированного репозитория создайте путь к home\.well-known\папке . Затем создайте следующие файлы:
- Файл 1: home.well-known\mta-sts.txt
Примечание.

Эта конфигурация позволяет только Exchange Online получать сообщения от имени вашего домена. Если вы используете несколько поставщиков электронной почты, необходимо также ссылаться на узлы MX для доменов этих других поставщиков. Подстановочные знаки или "*" не должны использоваться в качестве префикса MX во всех сценариях MTA-STS; Приведенные ниже параметры относятся только к Exchange Online и НЕ должны использоваться в качестве общего руководства по настройке MTA-STS.
1. Введите следующий текст в mta-sts.txt файл:
```
   version: STSv1
   mode: testing
   mx: *.mail.protection.outlook.com
   max_age: 604800
```
  Примечание.
  
  Рекомендуется сначала задать режим политики как тестирование. Затем, в конце конфигурации и убедившись, что политика работает должным образом, обновите mta-sts.txt файл таким образом, чтобы режим был применен.
  
  Файл должен содержать только содержимое, как показано на следующем снимке экрана:
- Файл 2: home\index.html
1. Создайте index.html файл и введите в него следующий код:
```
    <!DOCTYPE html>
    <html lang="en">

    <head>
    <meta charset="UTF-8">
    <title>MTA-STS</title>
    </head>

    <body>
    <h1>MTA-STS Static Website index</h1>
    </body>

    </html>
```
Файл должен содержать только содержимое, как показано на следующем снимке экрана:

После создания пути к папке и файлов не забудьте зафиксировать изменения и отправить их в ветвь main.
Создайте статическое веб-приложение Azure со следующей конфигурацией:
- Имя: MTA-STS-StaticWebApp
- Тип плана: Стандартный
- Сведения о развертывании: Azure DevOps
- Организация: ContosoCorporation
- Проект: MTA-STS_Project
- Репозиторий: MTA-STS_Project
- Ветвь: master
- Предустановки сборки: Angular
- Расположение приложения: /home
После создания статического веб-приложения и подготовки ресурса перейдите в раздел Обзор > Управление маркером развертывания, а затем скопируйте маркер, который будет использоваться на следующем шаге.
Перейдите в раздел Создание конвейеров >> Azure Repos Git > MTA-STS_Project и выполните следующие подзадачи:
1. Перейдите в раздел Переменные > Новая переменная и введите следующее:
  1. Имя: токен
  2. Значение: (вставьте ранее скопированный маркер на шаге 5)
2. После сохранения переменной вернитесь в раздел Проверка конвейера YAML и вставьте следующий yml, сохраните и запустите его:
```
    trigger:
    - main

    pool:
    vmImage: ubuntu-latest

    steps:
    - checkout: self
    submodules: true
    - task: AzureStaticWebApp@0
    inputs:
     app_location: '/home'
     azure_static_web_apps_api_token: $(token)
```
  Если в Azure DevOps во время развертывания возникает ошибка Нет приобретения или предоставления размещенного параллелизма, запросите через эту форму или реализуйте конфигурацию с помощью параметров > организации Параллельные задания > Microsoft Hosted > Change > Paid Parallel jobs , чтобы разрешить "Платные параллельные задания".
После успешного завершения задания вы можете проверить развертывание с помощью портал Azure, перейдя в браузер среды > статических веб-приложений > Azure. Содержимое index.html файла должно отображаться.
Добавьте свой домен vanity в личные домены > статического веб-приложения > Azure Добавить. Вам потребуется создать запись CNAME через поставщика DNS (например, GoDaddy), чтобы проверить, принадлежит ли вам зона. После завершения проверки Azure выдаст сертификат и привяжет его к статическому веб-приложению автоматически.
Проверьте, опубликована ли политика MTA-STS через : https://mta-sts.[ваш домен]/.well-known/mta-sts.txt.
Создайте запись DNS ТИПА TXT MTA-STS с помощью поставщика DNS. Используется следующий формат:
```
    Hostname: _mta-sts.<domain name>
    TTL: 3600 (recommended)
    Type: TXT
    Text: v=STSv1; id=<ID unique for your domain’s STS policy>Z;
```
Примечание.

Пример записи ТИПА TXT MTA-STS можно найти в разделе Практическое руководство по внедрению MTA-STS.
Когда запись TXT будет доступна в DNS, проверьте конфигурацию MTA-STS. После успешной проверки конфигурации обновите mta-sts.txt файл, чтобы применить режим политики, а затем обновите идентификатор политики в записи TXT.

Вариант 2. Функция Azure

Создайте приложение-функцию Azure со следующей конфигурацией:
- Имя приложения-функции: [По вашему выбору]
- Публикация: код
- Стек среды выполнения: .NET
- Версия: 6
- Операционная система: Windows
- Тип плана: [По вашему выбору]
Добавьте личный домен в приложение-функцию. Вам потребуется создать запись CNAME , чтобы проверить, принадлежит ли вам домен.
Привязывай "mta-sts. [ваш домен]" в приложение-функцию.
В файле приложения добавьте следующее расширение в файл host.json приложения-функции, чтобы исключить routePrefix. Это добавление необходимо для удаления /api из URL-адреса функции.
```
    "extensions": {
"http": {
  "routePrefix": ""
  }
}
```
В приложении-функции перейдите в раздел Создание функций > и настройте следующие параметры:

Примечание.

Хотя в этом примере описывается разработка функции на портале, вы можете использовать VS Code или любое другое предпочитающее средство.
- Среда разработки: [По вашему выбору; в этом примере будет использоваться "Разработка на портале"]
- Выбор шаблона: триггер HTTP
- Новая функция: [по вашему выбору]
- Уровень авторизации: Анонимный
После создания функции откройте Code + Test и разработайте в C# простой асинхронный HTTP-ответ, который будет вашей политикой MTA-STS. В следующем примере показано, что ожидается, что Exchange Online будет получать сообщения электронной почты:

Примечание.

Рекомендуется сначала задать режим политики как тестирование. Затем, в конце конфигурации и убедившись, что политика работает должным образом, обновите mta-sts.txt файл таким образом, чтобы режим был применен.
В разделе HTTP интеграции > (req) измените триггер на следующие значения:
- Шаблон маршрута: .well-known/mta-sts.txt
- Выбранные методы HTTP: GET
Убедитесь, что политика MTA-STS опубликована с помощью: https://mta-sts.[ваш домен]/.well-known/mta-sts.txt.
Создайте запись DNS ТИПА TXT MTA-STS с помощью поставщика DNS в следующем формате:
```
   Hostname: _mta-sts.<domain name>
   TTL: 3600 (recommended)
   Type: TXT
   Text: v=STSv1; id=<ID unique for your domain’s STS policy>Z;
```
Примечание.

Пример записи ТИПА TXT MTA-STS можно найти в разделе Практическое руководство по внедрению MTA-STS.
Когда запись TXT будет доступна в DNS, проверьте конфигурацию MTA-STS. После успешной проверки конфигурации обновите mta-sts.txt файл, чтобы применить режим политики, а затем обновите идентификатор политики в записи TXT.