Поделиться через

Проверка подлинности электронной почты в Microsoft 365

Совет

Знаете ли вы, что вы можете попробовать функции в Microsoft Defender для Office 365 план 2 бесплатно? Используйте 90-дневную пробную версию Defender для Office 365 в центре пробных версий портала Microsoft Defender. Узнайте, кто может зарегистрироваться и использовать условия пробной версии на пробной Microsoft Defender для Office 365.

Как организация Microsoft 365 с почтовыми ящиками в Exchange Online или автономная организация Exchange Online Protection (EOP) без Exchange Online почтовых ящиков, защита целостности сообщений электронной почты от отправителей в ваших доменах имеет важное значение. Получатели должны быть уверены, что сообщения от отправителей в вашем домене действительно поступили от отправителей в вашем домене.

Email проверка подлинности (также известная как проверка электронной почты) — это группа стандартов для выявления и предотвращения доставки сообщений электронной почты от поддельных отправителей (также известных как спуфинг). Спуфинированные отправители обычно используются при компрометации бизнес-электронной почты (BEC), фишинге и других атаках электронной почты. К этим стандартам относятся:

  • Sender Policy Framework (SPF) — указывает исходные почтовые серверы, которым разрешено отправлять почту для домена.
  • DomainKeys Identified Mail (DKIM): использует домен для цифровой подписи важных элементов сообщения, чтобы убедиться, что сообщение не было изменено при передаче.
  • Проверка подлинности, отчеты и соответствие сообщений на основе домена (DMARC). Указывает действие для сообщений, которые не выполняют проверку SPF или DKIM на наличие отправителей в домене, и указывает, куда отправлять результаты DMARC (отчеты).
  • Цепочка получения с проверкой подлинности (ARC): сохраняет исходные сведения о проверке подлинности электронной почты известными службами, которые изменяют сообщения при передаче. Конечный почтовый сервер может использовать эти сведения для проверки подлинности сообщений, которые в противном случае завершаются ошибкой DMARC.

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

Чтобы настроить проверку подлинности электронной почты для почты, отправляемой из организаций Microsoft 365 с почтовыми ящиками в Exchange Online или автономных Exchange Online Protection организаций без Exchange Online почтовых ящиков, см. следующие статьи:

Чтобы предотвратить сбои проверки подлинности электронной почты из-за служб, которые изменяют входящие сообщения, отправляемые в организацию Microsoft 365, см. статью Настройка доверенных запечатывщиков ARC.

В остальной части этой статьи объясняется следующее:

Совет

В дополнение к этой статье ознакомьтесь с руководством по настройке Microsoft Defender для Office 365, чтобы ознакомиться с рекомендациями и защититься от угроз электронной почты, ссылок и совместной работы. Функции включают безопасные ссылки, безопасные вложения и многое другое. Чтобы настроить интерфейс на основе вашей среды, вы можете получить доступ к руководству по автоматической настройке Microsoft Defender для Office 365 в Центр администрирования Microsoft 365.

Зачем нужна проверка подлинности электронной почты в Интернете

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

Стандартное smtp-сообщение электронной почты состоит из конверта сообщения и содержимого сообщения:

  • Конверт сообщения содержит сведения для передачи и получения сообщения между SMTP-серверами. Конверт сообщения описан в документе RFC 5321. Получатели никогда не видят конверт сообщения, так как он создается в процессе передачи сообщения.
  • Содержимое сообщения разделяется на поля заголовка сообщения, которые в совокупности называются заголовком сообщения, и текста сообщения. Заголовок сообщения описан в rfc 5322.

В связи с такой структурой сообщение имеет несколько значений отправителя:

  • Адрес MAIL FROM (также известный 5321.MailFrom как адрес, отправитель P1 или отправитель конверта) — это адрес электронной почты, который используется при передаче сообщения между SMTP-серверами электронной почты. Этот адрес обычно записывается в поле Заголовок Return-Path в заголовке сообщения (хотя исходный почтовый сервер может назначить другой адрес электронной почты Return-Path ). Этот адрес электронной почты используется в отчетах о недоставке (также известных как недоставка или сообщения о недоставке).
  • Адрес от (также известный 5322.From как адрес или отправитель P2) — это адрес электронной почты в поле От заголовка и адрес электронной почты отправителя, который отображается в почтовых клиентах.

В следующем примере показана упрощенная расшифровка допустимой передачи сообщений между двумя SMTP-серверами электронной почты:

S: HELO woodgrovebank.com
S: MAIL FROM: dubious@proseware.com
S: RCPT TO: astobes@tailspintoys.com
S: DATA
S: To: "Andrew Stobes" <astobes@tailspintoys.com>
S: From: "Woodgrove Bank Security" <security@woodgrovebank.com>
S: Subject: Woodgrove Bank - Action required
S:
S: Greetings,
S:
S: We need to verify your banking details.
S: Please click the following link to verify that we have the right information for your account.
S:
S: https://short.url/woodgrovebank/updateaccount/12-121.aspx
S:
S: Thank you,
S: Woodgrove Bank
S: .

В этом примере:

  • Исходный почтовый сервер идентифицирует себя как woodgrovebank.com на целевой почтовый сервер tailspintoys.com в команде HELO.
  • Получатель сообщения — astobes@tailspintoys.com.
  • Адрес MAIL FROM в конверте сообщения (используется для передачи сообщения между SMTP-серверами электронной почты) имеет значение dubious@proseware.com.
  • Адрес from, отображаемый в почтовом клиенте получателя, имеет значение security@woodgrovebank.com.

Хотя это сообщение допустимо в соответствии с SMTP, домен адреса MAIL FROM (proseware.com) не соответствует домену в адресе From (woodgrovebank.com). Это сообщение является классическим примером спуфингов, когда намерение, скорее всего, обманет получателя путем маскирования истинного источника сообщения для использования в фишинговой атаке.

Очевидно, что электронная почта SMTP нуждается в помощи, чтобы убедиться, что отправители сообщений являются тем, за кого они претендуют!

Совместная работа SPF, DKIM и DMARC для проверки подлинности отправителей сообщений электронной почты

В этом разделе описывается, зачем нужны SPF, DKIM и DMARC для доменов в Интернете.

  • SPF. Как описано в разделе Настройка SPF для определения допустимых источников электронной почты для домена Microsoft 365, SPF использует запись TXT в DNS для определения допустимых источников почты из домена MAIL FROM и что делать, если конечный почтовый сервер получает почту из неопределенного источника ('hard fail' to отклонение сообщения; "обратимый сбой", чтобы принять и пометить сообщение).

    Проблемы С SPF:

    • SPF проверяет источники только для отправителей в домене MAIL FROM. SPF не учитывает домен в адресе From или выравнивании между доменами MAIL FROM и From:

      • Злоумышленник может отправить сообщение электронной почты, которое проходит проверку подлинности SPF (ложноотрицательный), выполнив следующие действия.
        • Зарегистрируйте домен (например, proseware.com) и настройте SPF для домена.
        • Отправьте сообщение электронной почты из допустимого источника для зарегистрированного домена с помощью параметра С адресов электронной почты в другом домене (например, woodgrovebank.com).
      • Допустимый почтовый сервис, который отправляет почту от имени других доменов, может управлять адресом MAIL FROM. Другие домены и домен MAIL FROM не совпадают, поэтому сообщения не могут пройти проверку подлинности SPF (ложноположительный результат).

    • SPF прерывается после того, как сообщения сталкиваются с серверной пересылкой электронной почты, которая перенаправляет или ретранслирует сообщения.

      • Серверная пересылка электронной почты изменяет источник сообщений с исходного сервера на сервер переадресации.
      • Сервер переадресации не авторизован для отправки почты из исходного домена MAIL FROM, поэтому сообщение не может пройти проверку подлинности SPF (ложноположительный результат).

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

  • DKIM: как описано в разделе Настройка DKIM для подписи почты из домена Microsoft 365, DKIM использует домен для цифровой подписи важных элементов сообщения (включая адрес from) и сохраняет подпись в заголовке сообщения. Целевой сервер проверяет, не были ли изменены подписанные элементы сообщения.

    Как DKIM помогает SPF: DKIM может проверять сообщения, которые завершаются сбоем SPF. Например:

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

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

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

    Как и SPF, злоумышленник может отправить сообщение электронной почты, которое проходит проверку подлинности DKIM (ложноотрицательный), выполнив следующие действия:

    • Зарегистрируйте домен (например, proseware.com) и настройте DKIM для домена.
    • Отправка электронной почты с помощью адреса электронной почты from в другом домене (например, woodgrovebank.com).

  • DMARC: как описано в статье Настройка DMARC для проверки домена from address для отправителей в Microsoft 365, DMARC использует SPF и DKIM для проверка для выравнивания между доменами в адресах MAIL FROM и From. DMARC также указывает действие, которое целевая система электронной почты должна выполнять с сообщениями, которые не удается DMARC, и определяет, куда отправлять результаты DMARC (как с передачей, так и сбоем).

    Как DMARC помогает SPF и DKIM. Как описано ранее, SPF не пытается сопоставить домен в доменах MAIL FROM и From. DKIM не волнует, соответствует ли домен, подписав его сообщение, домену в адресе From.

    DMARC устраняет эти недостатки с помощью SPF и DKIM, чтобы убедиться, что домены в адресах MAIL FROM и From совпадают.

    Проблемы С DMARC. Допустимые службы, которые изменяют сообщения при передаче перед доставкой, прерывают проверки SPF, DKIM и, следовательно, DMARC.

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

    Как ARC помогает DMARC: целевая система электронной почты может идентифицировать службу как доверенный запечатыватель ARC. Затем ARC может использовать сохраненные сведения о проверке подлинности электронной почты для проверки сообщения.

Проверка подлинности входящей электронной почты для почты, отправляемой в Microsoft 365

Из-за проблем фишинга и менее полного внедрения политик строгой проверки подлинности электронной почты отправителями электронной почты в Интернете Microsoft 365 использует неявную проверку подлинности электронной почты для проверка входящей электронной почты. Неявная проверка подлинности по электронной почте расширяет обычные проверки SPF, DKIM и DMARC с помощью сигналов из других источников для оценки входящих сообщений электронной почты. К этим источникам относятся:

  • Репутация отправителя.
  • Журнал отправителей.
  • Журнал получателей.
  • Анализ поведения.
  • Другие расширенные методы.

Чтобы просмотреть оригинальное объявление Майкрософт о неявной проверке подлинности, см. раздел Море фишинга, часть 2. Расширенная защита от спуфингов в Microsoft 365.

Используя эти другие сигналы, сообщения, которые в противном случае не прошли бы традиционные проверки проверки подлинности электронной почты, могут пройти неявную проверку подлинности и быть разрешены в Microsoft 365.

Многофакторная аутентификация

Результаты неявных проверок проверки подлинности Microsoft 365 объединяются и хранятся в одном значении с именем составной проверки подлинности или compauth сокращенно. Значение compauth добавляется в заголовок Authentication-Results в заголовках сообщений. В заголовке Authentication-Results используется следующий синтаксис:

Authentication-Results:
   compauth=<fail | pass | softpass | none> reason=<yyy>

Эти значения описываются в разделе Заголовок сообщения Authentication-results.

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

Совет

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

В следующих примерах основное внимание уделяется только результатам проверки подлинности электронной почты ( compauth значение и причина). Другие технологии защиты Microsoft 365 могут определять сообщения, которые проходят проверку подлинности электронной почты как подделанные, или определять сообщения, которые не прошли проверку подлинности электронной почты, как допустимые.

  • Сценарий. Домен в записи SPF или сигнатуре DKIM не соответствует домену в адресе From.

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

    Authentication-Results: spf=none (sender IP is 192.168.1.8)
  smtp.mailfrom=maliciousdomain.com; contoso.com; dkim=pass
  (signature was verified) header.d=maliciousdomain.com;
  contoso.com; dmarc=none action=none header.from=contoso.com;
  compauth=fail reason=001
From: chris@contoso.com
To: michelle@fabrikam.com

  • Сценарий. Домен fabrikam.com не содержит записей SPF, DKIM или DMARC.

  • Результат. Сообщения от отправителей в домене fabrikam.com могут завершиться ошибкой составной проверки подлинности:

    Authentication-Results: spf=none (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=none
  (message not signed) header.d=none; contoso.com; dmarc=none
  action=none header.from=fabrikam.com; compauth=fail reason=001
From: chris@fabrikam.com
To: michelle@contoso.com

  • Сценарий. Домен fabrikam.com имеет запись SPF и не содержит записи DKIM. Домены в адресах MAIL FROM и From совпадают.

  • Результат. Сообщение может пройти составную проверку подлинности, так как домен, который прошел SPF, соответствует домену в адресе From:

    Authentication-Results: spf=pass (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=none
  (message not signed) header.d=none; contoso.com; dmarc=bestguesspass
  action=none header.from=fabrikam.com; compauth=pass reason=109
From: chris@fabrikam.com
To: michelle@contoso.com

  • Сценарий. Домен fabrikam.com содержит запись DKIM без записи SPF. Домен, который DKIM подписал сообщение, соответствует домену в адресе From.

  • Результат. Сообщение может пройти составную проверку подлинности, так как домен в подписи DKIM соответствует домену в адресе From:

    Authentication-Results: spf=none (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=pass
  (signature was verified) header.d=outbound.fabrikam.com;
  contoso.com; dmarc=bestguesspass action=none
  header.from=fabrikam.com; compauth=pass reason=109
From: chris@fabrikam.com
To: michelle@contoso.com

  • Сценарий. Домен в записи SPF или сигнатуре DKIM не соответствует домену в адресе From.

  • Результат. Сообщение может завершиться ошибкой составной проверки подлинности:

    Authentication-Results: spf=none (sender IP is 192.168.1.8)
  smtp.mailfrom=maliciousdomain.com; contoso.com; dkim=pass
  (signature was verified) header.d=maliciousdomain.com;
  contoso.com; dmarc=none action=none header.from=contoso.com;
  compauth=fail reason=001
From: chris@contoso.com
To: michelle@fabrikam.com

Как избежать сбоев проверки подлинности электронной почты при отправке почты в Microsoft 365

Совет

Клиенты Microsoft 365 могут использовать следующие методы, чтобы разрешить сообщения от отправителей, которые определены как спуфингом или ошибками проверки подлинности:

  • Настройка записей SPF, DKIM и DMARC для доменов. Используйте сведения о конфигурации, предоставленные регистратором доменных имен или службой размещения DNS. Существуют также сторонние компании, которые помогают настроить записи проверки подлинности по электронной почте.

    Многие компании не публикуют записи SPF, так как не знают все источники электронной почты для сообщений в своем домене.

    1. Начните с публикации записи SPF, содержащей все известные источники электронной почты (особенно в том, где находится корпоративный трафик), и используйте значение правила принудительного применения "soft fail" (~all). Например:

      fabrikam.com IN TXT "v=spf1 include:spf.fabrikam.com ~all"

      Если вы создаете эту запись SPF, Microsoft 365 обрабатывает входящие сообщения электронной почты из корпоративной инфраструктуры как прошедшие проверку подлинности, но сообщения из неопознанных источников могут по-прежнему помечаться как поддельные в случае сбоя составной проверки подлинности. Однако это поведение по-прежнему является улучшением по сравнению со всеми письмами от отправителей в домене, помеченными Microsoft 365 как поддельные. Как правило, целевая система электронной почты принимает сообщения от отправителей в домене из неопознанных источников, если SPF настроен с правилом принудительного применения обратимого сбоя.

    2. Обнаружение и включение дополнительных источников электронной почты для сообщений. Например:

      • Локальные почтовые серверы.
      • Электронная почта, отправленная SaaS-поставщиком (программное обеспечение как услуга).
      • Электронная почта, отправленная службой размещения в облаке (Microsoft Azure, GoDaddy, Rackspace, Amazon Web Services и т. д.).

      Определив все источники электронной почты для домена, вы можете обновить запись SPF, чтобы использовать значение правила принудительного применения "hard fail" (-all).

    3. Настройка DKIM для цифровой подписи сообщений.

    4. Настройте DMARC, чтобы проверить соответствие доменов в адресах MAIL FROM и From, указать, что делать с сообщениями, которые не выполняют проверки DMARC (отклонение или карантин), а также определить службы отчетов для мониторинга результатов DMARC.

    5. Если вы используете массовых отправителей для отправки электронной почты от вашего имени, убедитесь, что домен в поле От адреса соответствует домену, который проходит SPF или DMARC.

  • Вы размещаете адрес электронной почты домена или предоставляете инфраструктуру размещения, которая может отправлять сообщения электронной почты:

    • Убедитесь, что у ваших клиентов есть документация, в которую показано, как настроить SPF для своих доменов.
    • Рассмотрите возможность подписывания DKIM исходящей почты DKIM, даже если клиент явно не настроит DKIM в своем домене (подпишите домен по умолчанию). Вы даже можете дважды подписать сообщение электронной почты с помощью подписей DKIM (с доменом вашей компании и доменом клиента, если или когда он доступен).

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