Переход на Microsoft Defender для Office 365 — этап 2. Настройка


Этап 1. Подготовка.
Этап 1. Подготовка
Этап 2. Настройка.
Этап 2. Настройка
Этап 3. Подключение.
Этап 3. Подключение
Вы здесь!

Добро пожаловать в этап 2. Настройкамиграции на Microsoft Defender для Office 365! Этот этап миграции включает в себя следующие шаги.

  1. Создание групп рассылки для пилотных пользователей
  2. Настройка параметров сообщений, сообщаемого пользователем
  3. Обслуживание или создание правила потока обработки почты SCL=-1
  4. Настройка расширенной фильтрации для соединителей
  5. Создание пилотных политик защиты

Шаг 1. Создание групп рассылки для пилотных пользователей

Группы рассылки необходимы в Microsoft 365 для следующих аспектов миграции:

  • Исключения для правила потока обработки почты SCL=-1. Вы хотите, чтобы пилотные пользователи получили полный эффект защиты от Defender для Office 365, поэтому вам потребуется Defender для Office 365 для сканирования входящих сообщений. Этот результат можно получить, определив пилотных пользователей в соответствующих группах рассылки в Microsoft 365 и настроив эти группы как исключения из правила потока обработки почты SCL=-1.

    Как описано в разделе Подключение, шаг 2. (необязательно) Исключить пилотных пользователей от фильтрации по существующей службе защиты, следует рассмотреть возможность исключения этих же пилотных пользователей от проверки существующей службой защиты. Устранение возможности фильтрации по существующей службе защиты и использование исключительно Defender для Office 365 — это лучшее и ближайшее представление о том, что произойдет после завершения миграции.

  • Тестирование определенных функций защиты Defender для Office 365. Даже для пилотных пользователей вы не хотите включать все сразу. Использование поэтапного подхода к функциям защиты, которые действуют для пользователей пилотного проекта, упрощает устранение неполадок и настройку. Учитывая этот подход, мы рекомендуем использовать следующие группы рассылки:

    • Пилотная группа "Безопасные вложения": например, MDOPilot_SafeAttachments
    • Пилотная группа "Безопасные ссылки": например, MDOPilot_SafeLinks
    • Пилотная группа для стандартных параметров политики защиты от нежелательной почты и фишинга: например, MDOPilot_SpamPhish_Standard
    • Пилотная группа для параметров политики строгой защиты от нежелательной почты и фишинга: например, MDOPilot_SpamPhish_Strict

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

Когда вы будете готовы приступить к тестированию, добавьте эти группы в качестве исключений в правило потока обработки почты SCL=-1. При создании политик для различных функций защиты в Defender для Office 365 используйте эти группы в качестве условий, определяющих, к кому применяется политика.

Примечания.

  • Термины "Стандартный" и "Строгий" относятся к рекомендуемым параметрам безопасности, которые также используются в предустановленных политиках безопасности. В идеале мы бы сказали вам определить пилотных пользователей в стандартных и строгих предустановленных политиках безопасности, но мы не можем этого сделать. Почему? Так как вы не можете настроить параметры в предустановленных политиках безопасности (в частности, действия, выполняемые с сообщениями). Во время тестирования миграции вы хотите узнать, что Defender для Office 365 будет делать с сообщениями, проверить нужный результат и, возможно, настроить конфигурации политики, чтобы разрешить или запретить эти результаты.

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

  • Если вы хотите поэкспериментировать с параметрами, которые значительно отличаются от стандартных или строгих рекомендуемых значений, следует рассмотреть возможность создания и использования дополнительных и конкретных групп рассылки для пилотных пользователей в этих сценариях. Вы можете использовать анализатор конфигурации, чтобы узнать, насколько безопасны параметры. Инструкции см. в статье Анализатор конфигурации для политик защиты в EOP и Microsoft Defender для Office 365.

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

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

Шаг 2. Настройка параметров сообщений, сообщаемого пользователем

Возможность для пользователей сообщать о ложных срабатываниях или ложноотрицательных результатах из Defender для Office 365 является важной частью миграции.

Вы можете указать почтовый ящик Exchange Online для получения сообщений, которые пользователи сообщают как вредоносные или не вредоносные. Инструкции см. в разделе Параметры, сообщаемые пользователем. Этот почтовый ящик может получать копии сообщений, отправленных пользователями в Корпорацию Майкрософт, или же почтовый ящик может перехватывать сообщения, не сообщая о них корпорации Майкрософт (ваша команда безопасности может анализировать и отправлять сообщения вручную). Однако подход к перехвату не позволяет службе автоматически настраиваться и учиться.

Необходимо также убедиться, что все пользователи в пилотном проекте имеют поддерживаемый способ сообщать о сообщениях, которые получили неверный вердикт от Defender для Office 365. Среди них:

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

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

Шаг 3. Обслуживание или создание правила потока обработки почты SCL=-1

Так как входящие сообщения электронной почты направляются через другую службу защиты, которая находится перед Microsoft 365, скорее всего, у вас уже есть правило потока обработки почты (также известное как правило транспорта) в Exchange Online, которое задает уровень достоверности спама (SCL) для всех входящих сообщений со значением -1 (обход фильтрации нежелательной почты). Большинство сторонних служб защиты поощряют это правило потока обработки почты SCL=-1 для клиентов Microsoft 365, которые хотят использовать свои службы.

Если вы используете какой-то другой механизм для переопределения стека фильтрации Майкрософт (например, список разрешенных IP-адресов), рекомендуется переключиться на правило потока обработки почты SCL=-1, если вся входящая интернет-почта в Microsoft 365 поступает из сторонней службы защиты (нет потоков почты напрямую из Интернета в Microsoft 365).

Правило потока обработки почты SCL=-1 важно во время миграции по следующим причинам:

  • Вы можете использовать Обозреватель угроз (Обозреватель), чтобы узнать, какие функции в стеке Майкрософт могли бы работать с сообщениями, не влияя на результаты существующей службы защиты.

  • Вы можете постепенно изменить, кто защищен стеком фильтрации Microsoft 365, настроив исключения для правила потока обработки почты SCL=-1. Исключениями являются члены пилотных групп рассылки, которые мы рекомендуем далее в этой статье.

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

Дополнительные сведения см. в статье Использование правил потока обработки почты для задания уровня достоверности нежелательной почты (SCL) в сообщениях в Exchange Online.

Примечания.

  • Если вы планируете разрешить передачу почты через существующую службу защиты и непосредственно в Microsoft 365 одновременно, необходимо ограничить правило потока обработки почты SCL=-1 (почта, которая обходит фильтрацию нежелательной почты) только для почты, которая прошла через существующую службу защиты. Вы не хотите, чтобы нефильтрованные интернет-почты отправились в почтовые ящики пользователей в Microsoft 365.

    Чтобы правильно определить почту, уже проверенную существующей службой защиты, можно добавить условие в правило потока обработки почты SCL=-1. Например:

    • Для облачных служб защиты. Вы можете использовать заголовок и значение заголовка, которые уникальны для вашей организации. Сообщения с заголовком не проверяются Microsoft 365. Сообщения без заголовка проверяются в Microsoft 365
    • Для локальных служб защиты или устройств: можно использовать исходные IP-адреса. Сообщения с исходных IP-адресов не проверяются Microsoft 365. Сообщения, не полученные от исходных IP-адресов, проверяются Microsoft 365.
  • Не полагайтесь исключительно на записи MX для управления фильтрацией почты. Отправители могут легко игнорировать запись MX и отправлять сообщения электронной почты непосредственно в Microsoft 365.

Шаг 4. Настройка расширенной фильтрации для соединителей

Первое, что нужно сделать, — настроить расширенную фильтрацию для соединителей (также известный как пропустить список) на соединителе, который используется для потока обработки почты из существующей службы защиты в Microsoft 365. Для идентификации соединителя можно использовать отчет о входящих сообщениях .

Расширенная фильтрация для соединителей требуется Defender для Office 365, чтобы узнать, откуда на самом деле поступили интернет-сообщения. Расширенная фильтрация для соединителей значительно повышает точность стека фильтрации Майкрософт (особенно спуфинга аналитики и возможности после нарушения безопасности в Обозреватель угроз и автоматического исследования & реагирования (AIR).

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

Чтобы убедиться, что расширенная фильтрация для соединителей работает, убедитесь, что входящие сообщения содержат один или оба следующих заголовка:

  • X-MS-Exchange-SkipListedInternetSender
  • X-MS-Exchange-ExternalOriginalInternetSender

Шаг 5. Создание пилотных политик защиты

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

Важно!

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

Создание пилотных политик безопасных вложений

Безопасные вложения — это самая простая Defender для Office 365 функция для включения и тестирования перед переключением записи MX. Безопасные вложения имеют следующие преимущества:

  • Минимальная конфигурация.
  • Крайне низкая вероятность ложноположительных результатов.
  • Аналогично поведению защиты от вредоносных программ, которая всегда включена и не зависит от правила потока обработки почты SCL=-1.

Рекомендуемые параметры см. в разделе Рекомендуемые параметры политики безопасных вложений. Стандартные и строгие рекомендации совпадают. Сведения о создании политики см. в статье Настройка политик безопасных вложений. Обязательно используйте групповую MDOPilot_SafeAttachments в качестве условия политики (к кому применяется политика).

Примечание.

Предустановленная политика безопасности встроенной защиты обеспечивает защиту безопасных вложений для всех получателей, которые не определены ни в одной из политик безопасных вложений. Дополнительные сведения см. в разделе Предустановленные политики безопасности в EOP и Microsoft Defender для Office 365.

Примечание.

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

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

Рекомендуемые параметры см. в разделе Параметры политики безопасных ссылок. Стандартные и строгие рекомендации совпадают. Сведения о создании политики см. в статье Настройка политик безопасных ссылок. Обязательно используйте групповую MDOPilot_SafeLinks в качестве условия политики (к кому применяется политика).

Примечание.

Предустановленная политика безопасности встроенной защиты обеспечивает защиту безопасных ссылок для всех получателей, которые не определены ни в одной политике безопасных ссылок. Дополнительные сведения см. в разделе Предустановленные политики безопасности в EOP и Microsoft Defender для Office 365.

Создание пилотных политик защиты от нежелательной почты

Создайте две политики защиты от нежелательной почты для пилотных пользователей:

  • Политика, использующая стандартные параметры. Используйте групповую MDOPilot_SpamPhish_Standard в качестве условия политики (к кому применяется политика).
  • Политика, использующая строгие параметры. Используйте групповую MDOPilot_SpamPhish_Strict в качестве условия политики (к кому применяется политика). Эта политика должна иметь более высокий приоритет (меньшее число), чем политика с параметрами "Стандартный".

Рекомендуемые стандартные и строгие параметры см. в разделе Рекомендуемые параметры политики защиты от нежелательной почты. Сведения о создании политик см. в статье Настройка политик защиты от нежелательной почты.

Создание пилотных политик защиты от фишинга

Создайте две политики защиты от фишинга для пилотных пользователей:

  • Политика, использующая стандартные параметры, за исключением действий обнаружения олицетворения, как описано ниже. Используйте групповую MDOPilot_SpamPhish_Standard в качестве условия политики (к кому применяется политика).
  • Политика, использующая строгие параметры, за исключением действий обнаружения олицетворения, как описано ниже. Используйте групповую MDOPilot_SpamPhish_Strict в качестве условия политики (к кому применяется политика). Эта политика должна иметь более высокий приоритет (меньшее число), чем политика с параметрами "Стандартный".

Для обнаружения спуфингов рекомендуемое действие "Стандартный" — Переместить сообщение в папки нежелательной Email получателей, а рекомендуемое действие Strict — поместить сообщение в карантин. Используйте аналитику спуфинга для наблюдения за результатами. Переопределения описаны в следующем разделе. Дополнительные сведения см. в статье Аналитика спуфинга в EOP.

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

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

Используйте аналитические сведения олицетворения для наблюдения за результатами. Дополнительные сведения см. в статье Анализ олицетворения в Defender для Office 365.

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

Дополнительные сведения см. в следующих статьях:

Следующее действие

Поздравляем! Вы завершили этап установкимиграции на Microsoft Defender для Office 365!