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

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

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

Как MTA-STS защищает исходящую почту

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

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

Как MTA-STS защищает входящую почту

Владельцы домена могут принять меры для защиты сообщений электронной почты, отправленных на их домены с помощью 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 должна содержать v=STSv1; до тех пор, пока не будет поддерживаться STSv2, и идентификатор политики. Идентификатор ДОЛЖЕН быть уникальным для владельца домена и политики, так как изменение идентификатора сигнализирует отправителям о необходимости повторного получения политики. Идентификатор не обязательно должен быть уникальным в глобальном масштабе, не беспокойтесь об идентификаторах политики других владельцев домена. После обновления политики MTA-STS требуется обновлять идентификатор, иначе отправители продолжат использовать кэшированные политики для вашего домена, пока не истечет срок действия max_age кэшированной политики.

Повторяемый шаблон для установки уникального идентификатора — это использование времени UTC в качестве такового:
id=<yyyymmddhh0000>Z;

Следующая запись TXT является примером, который заявляет о поддержке MTA-STS. Идентификатор был установлен на 8 утра 1 января 2022 г. по времени UTC:

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

Политика 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.

В следующем примере показано содержимое файла политики MTA-STS (mta-sts.txt). Поле version объявляет версию протокола, указывает, mode применяется ли политика или находится в стадии тестирования, mx определяет авторизованный почтовый сервер и max_age определяет, как долго (в секундах) отправители должны кэшировать политику:

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

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

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

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

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

Существует два ресурса Azure, которые можно использовать для размещения политики MTA-STS: статическое веб-приложение Azure и функции 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

Выполните следующие действия для размещения политики MTA-STS с помощью Azure Static Web App с Azure DevOps для развертывания.

1. Создайте организацию Azure DevOps или используйте уже существующую организацию. В этой процедуре Azure Static Web App для размещения политики MTA-STS используется организация с именем "ContosoCorporation".

   

2. В Files репозитория >клонируйте свой репозиторий в любой интегрированной среде разработки, которую вы предпочитаете. В этом пошаговом руководстве по Azure DevOps репозиторий клонирован в Visual Studio.

   

3. После клонирования репозитория создайте путь к 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>
        

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

     

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

4. Создайте новое статическое веб-приложение Azure со следующей конфигурацией:

   • Имя: MTA-STS-StaticWebApp
   • Тип плана: Standard
   • Сведения о развертывании: DevOps Azure
   • Организация: ContosoCorporation
   • Проект: MTA-STS_Project
   • Хранилище: MTA-STS_Project
   • Отрасль: master
   • Предварительные сборки: Angular
   • Расположение приложения: /домашняя страница

   

5. После создания статического веб-приложения и подготовки ресурса перейдите в раздел "Обзор > " Управление маркером развертывания, а затем скопируйте маркер, так как он будет вставлен как переменная конвейера при создании конвейера развертывания.

6. Перейдите в раздел Pipelines > Create Pipeline > Azure Repos Git > MTA-STS_Project и выполните следующие подзадачи:

   1. Перейдите в раздел "Переменные" > и введите следующее:

      1. Имя: маркер
      2. Значение: (вставьте маркер, скопированный ранее, на шаге 5)

   2. После сохранения переменной вернитесь в Review your pipeline 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 во время развертывания возникнет ошибка, размещенный параллелизм не был приобретен или предоставлен, либо запросите через эту бесплатную форму запроса на предоставление параллелизма, либо реализуйте конфигурацию с помощью параметров > организации Параллельные задания > Размещенные > в Майкрософт Изменение > оплачиваемых параллельных заданий таким образом, чтобы были разрешены "Оплачиваемые параллельные задания".

7. После успешного завершения задания можно проверить развертывание на портале Azure, перейдя в браузер статической среды > веб-приложений > Azure. Вы должны видеть index.html содержимое файла.

8. Добавьте личный домен в статическое веб-приложение > Azure Личные домены > Добавление. Вам потребуется создать запись CNAME через поставщика услуг DNS (например, GoDaddy), чтобы проверить, принадлежит ли вам эта зона. По окончании проверки Azure выдаст сертификат и автоматически привяжет его к вашему статическому веб-приложению.

9. Проверьте, https://mta-sts.опубликована ли ваша политика MTA-STS через: [домен]/.well-known/mta-sts.txt.

10. Создайте запись 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.contoso.com. 3600 IN TXT v=STSv1; id=20220101080000Z;

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

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

Выполните следующие действия для размещения политики MTA-STS в качестве бессерверного кода с помощью Функции Azure. В этом случае необходимо выпустить собственный сертификат TLS для поддомена mta-sts .

1. Создайте новое приложение-функцию Azure со следующей конфигурацией:

   • Функция Имя приложения: [На ваш выбор]
   • Опубликовать: код
   • Стек среды выполнения: .NET
   • Версия: 6
   • Операционная система: Windows
   • Тип плана: [на ваш выбор]

   

2. Добавьте свой личный домен в приложение "Функция". Вам потребуется создать запись CNAME , чтобы подтвердить, принадлежит ли домен вам.

   

3. Свяжите свои "мта-ст. [ваш домен]" в приложение-функцию.

   

4. В файле приложения добавьте следующее расширение в host.json приложения-функции, чтобы удалить префикс routePrefix. Это добавление необходимо для удаления /api из URL-адреса функции.

   "extensions": {
     "http": {
       "routePrefix": ""
     }
   }
   

   

5. В приложении "Функция" перейдите в раздел "Функции > " Создайте и настройте следующие параметры:

   Примечание.

   Хотя в этом примере описывается разработка функции через портал, вы можете использовать VS Code или любой другой инструмент, который вам нравится.

   • Среда разработки: [В качестве вашего выбора; в этом примере будет использоваться "Разработка на портале"]
   • Выберите шаблон: HTTP-триггер
   • Новая функция: [На ваш выбор]
   • Уровень авторизации: Анонимный

   

6. После создания функции откройте Code + Test и разработайте в C# простой асинхронный HTTP-ответ, который будет вашей политикой MTA-STS. В следующем примере указывается, что Exchange Online должен получать сообщения электронной почты:

   Примечание.

   Рекомендуется, чтобы режим политики изначально был настроен как тестирование. Затем, в конце настройки и убедившись, что политика работает должным образом, обновите файл, mta-sts.txt чтобы режим был принудительным.

   

7. В разделе Integration > HTTP (req) измените значение триггера, задав следующие значения:

   • Шаблон маршрута: .well-known/mta-sts.txt
   • Выбранные методы HTTP: GET

   

8. Убедитесь, что ваша политика MTA-STS опубликована по адресу: https://mta-sts.[ваш домен]/.well-known/mta-sts.txt.

9. Создайте запись 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.contoso.com. 3600 IN TXT v=STSv1; id=20220101080000Z;

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

Устранение проблем с входящим MTA-STS путем переключения в режим «тестирования»

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

Шаг 1. Обновление файла политики

Измените значение режима политики на "Тестирование".

Если задать режим политики таким образом testing , чтобы отправители получали ее, но не применяли ее, при этом отправляя отчеты TLS.

Шаг 2. Отправка обновленного файла политики

Отправьте обновленный файл на сервер HTTPS вашего домена по адресу:

https://mta-sts.<your-domain>/.well-known/mta-sts.txt

Шаг 3. Обновление записи DNS TXT

Обновите запись, _mta-sts.<your-domain> DNS TXT изменив значение id на новую уникальную строку (например, метку времени UTC).

Повторяющийся шаблон для установки уникального идентификатора заключается в использовании текущего времени в формате UTC для обновления политики: id=<yyyymmddhh0000>Z;

Следующая запись TXT является примером обновленной записи TXT MTA-STS. Обновление происходит в 8:00 1 января 2022 г. по времени UTC:

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

Шаг 4. Отладка и проверка

После внесения изменений:

• Проверьте:

  • Файл политики доступен и содержит правильно отформатированные поля с точными значениями MX для вашего домена.
  • Запись DNS TXT обновлена и видна.
  • Сертификат HTTPS политики действителен.

• Проверьте отчеты TLS-RPT (если они настроены) на наличие признаков проблем с доставкой или неправильной конфигурации.