Миграция на Microsoft Defender для Office 365 — этап 2. Настройка

Этап 1. Подготовка	Этап 2. Настройка	Этап 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 используйте эти группы в качестве условий, определяющих, к кому применяется политика.

Примечания.

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

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

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

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

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

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

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

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

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

• Встроенная кнопка "Отчет" в Outlook

• Поддерживаемые средства создания отчетов, отличные от Microsoft.

  Совет

  В обучении моделированию атак в Defender для Office 365, план 2 имитационные сообщения, о которых сообщают сторонние средства, не относящиеся к Microsoft, не отражаются в отчетах по моделированию атак.

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

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

Шаг 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, чтобы узнать, откуда на самом деле поступили интернет-сообщения. Расширенная фильтрация для коннекторов значительно повышает точность стека фильтрации Microsoft (особенно аналитики спуфинга и возможностей после компрометации в Threat Explorer и Automated Investigation & Response (AIR).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Защита от спуфинга
• Параметры олицетворения в политиках защиты от фишинга
• Настройте политики защиты от фишинга в Defender для Office 365.

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

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

• Перейдите к этапу 3. Подключение.