Миграция на Microsoft Defender для Office 365 — этап 3. Подключение


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

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

  1. Начало подключения команд безопасности
  2. (Необязательно) Освобождение пользователей пилотного проекта от фильтрации по существующей службе защиты
  3. Настройка спуфинга аналитики
  4. Настройка защиты олицетворения и аналитики почтовых ящиков
  5. Использование данных из сообщений, сообщаемого пользователем, для измерения и настройки
  6. (Необязательно) Добавление дополнительных пользователей в пилотный проект и итерации
  7. Расширение защиты Microsoft 365 для всех пользователей и отключение правила потока обработки почты SCL=-1
  8. Переключение записей MX

Шаг 1. Начало подключения команд безопасности

Если в вашей организации есть группа реагирования на вопросы безопасности, пришло время начать интеграцию Microsoft Defender для Office 365 в процессы реагирования, включая системы обработки запросов. Этот процесс является целым темой для себя, но иногда его упускают из виду. Заблаговременное привлечение группы реагирования на вопросы безопасности гарантирует, что ваша организация готова к борьбе с угрозами при переключении записей MX. Реагирование на инциденты должно быть хорошо подготовлено для выполнения следующих задач:

Если ваша организация приобрела Microsoft Defender для Office 365 план 2, они должны начать знакомство с такими функциями, как Обозреватель угроз, расширенная охота и инциденты. Соответствующие учебные материалы см. в разделе https://aka.ms/mdoninja.

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

SIEM/SOAR

Дополнительные сведения об интеграции с SIEM/SOAR см. в следующих статьях:

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

Роли RBAC

Разрешения в Defender для Office 365 основаны на управлении доступом на основе ролей (RBAC) и описаны в разделе Разрешения на портале Microsoft Defender. Ниже приведены важные моменты, которые следует помнить.

  • Microsoft Entra роли предоставляют разрешения для всех рабочих нагрузок в Microsoft 365. Например, если добавить пользователя к администратору безопасности в портал Azure, он будет иметь разрешения администратора безопасности везде.
  • Email & роли совместной работы на портале Microsoft Defender предоставляют разрешения для портала Microsoft Defender и Портал соответствия требованиям Microsoft Purview. Например, если добавить пользователя в администратор безопасности на портале Microsoft Defender, у него есть доступ к администратору безопасности только на портале Microsoft Defender и Портал соответствия требованиям Microsoft Purview.
  • Многие функции портала Microsoft Defender основаны на командлетах PowerShell Exchange Online и поэтому требуют членства в группах ролей (технически, группах ролей) в Exchange Online (в частности, для доступа к соответствующей Exchange Online PowerShell). командлеты).
  • На портале Microsoft Defender существуют Email & роли совместной работы, которые не имеют эквивалента Microsoft Entra ролям и важны для операций безопасности (например, роль предварительной версии и роль Поиск и очистки).

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

Шаг 2. (Необязательно) Освобождение пользователей пилотного проекта от фильтрации по существующей службе защиты

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

Примечание.

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

Шаг 3. Настройка спуфинга аналитики

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

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

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

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

Шаг 4. Настройка защиты олицетворения и аналитики почтовых ящиков

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

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

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

Примечание.

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

Настройка аналитики почтовых ящиков

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

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

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

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

Сведения об изменении политик см. в статье Настройка политик защиты от фишинга в Defender для Office 365.

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

Настройка защиты олицетворения пользователя

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

Проверьте аналитические сведения олицетворения , чтобы узнать, что блокируется при попытках олицетворения пользователя.

Сведения об изменении политик см. в статье Настройка политик защиты от фишинга в Defender для Office 365.

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

Настройка защиты олицетворения домена

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

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

Сведения об изменении политик см. в статье Настройка политик защиты от фишинга в Defender для Office 365.

Наблюдайте за результатами и при необходимости вносите любые корректировки.

Шаг 5. Использование данных из сообщений, сообщаемого пользователем, для измерения и настройки

Когда пользователи пилотного проекта сообщают о ложных срабатываниях и ложноотрицательных результатах, сообщения отображаются на вкладке Пользователь сообщил на странице Отправки на портале Microsoft Defender. Вы можете сообщить о неправильном идентифицировать сообщения в корпорацию Майкрософт для анализа и использовать их для настройки параметров и исключений в пилотных политиках при необходимости.

Используйте следующие функции для мониторинга и итерации параметров защиты в Defender для Office 365:

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

Шаг 6. (Необязательно) Добавление дополнительных пользователей в пилотный проект и выполнение итерации

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

  • Microsoft 365 создает оповещения, когда политики организации разрешают фишинговые сообщения с высоким уровнем достоверности. Чтобы определить эти сообщения, можно выбрать следующие варианты:

    • Переопределяет в отчете о состоянии защиты от угроз.
    • Фильтр в Обозреватель угрозы для идентификации сообщений.
    • Фильтр в разделе Расширенная охота для идентификации сообщений.

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

  • Также рекомендуется изучить ненужные переопределения. Иными словами, посмотрите на вердикты, которые Microsoft 365 предоставила бы в сообщениях. Если Microsoft 365 вынес правильный вердикт, потребность в переопределении значительно уменьшается или устраняется.

Шаг 7. Расширение защиты Microsoft 365 для всех пользователей и отключение правила потока обработки почты SCL=-1

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

  1. Распространение пилотных политик на всю организацию. По сути, существуют различные способы расширения политик:

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

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

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

  2. Отключите правило потока обработки почты SCL=-1 (его можно отключить, не удаляя).

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

На этом этапе можно приостановить запись и настройку данных в более крупном масштабе.

Шаг 8. Переключение записей MX

Примечание.

  • При переключении записи MX для домена может потребоваться до 48 часов для распространения изменений в Интернете.
  • Рекомендуется снизить значение TTL для записей DNS, чтобы обеспечить более быстрый ответ и возможный откат (при необходимости). Вы можете отменить изменения к исходному значению срока жизни после завершения переключения и проверки.
  • Рекомендуется начать с изменения доменов, которые используются реже. Перед переходом на более крупные домены можно приостановить и отслеживать. Однако даже если это сделать, все равно следует убедиться, что все пользователи и домены охвачены политиками, так как вторичные домены SMTP разрешаются в первичные домены до применения политики.
  • Несколько записей MX для одного домена технически будут работать, что позволяет использовать разделенную маршрутизацию при условии, что вы выполнили все рекомендации, приведенные в этой статье. В частности, следует убедиться, что политики применяются ко всем пользователям, что правило потока обработки почты SCL=-1 применяется только к почте, которая проходит через существующую службу защиты, как описано в разделе Настройка Шаг 3. Обслуживание или создание правила потока обработки почты SCL=-1. Однако в этой конфигурации реализовано поведение, которое значительно усложняет устранение неполадок, поэтому мы обычно не рекомендуем его, особенно в течение длительных периодов времени.
  • Перед переключением записей MX убедитесь, что следующие параметры не включены для входящего соединителя из службы защиты в Microsoft 365. Как правило, соединитель будет иметь один или несколько из следующих параметров:
    • и требуют, чтобы имя субъекта в сертификате, используемом партнером для проверки подлинности с помощью Office 365 соответствовало этому доменному имени (RestrictDomainsToCertificate).
    • Отклонить сообщения электронной почты, если они не отправляются из этого диапазона IP-адресов (RestrictDomainsToIPAddresses). Если тип соединителя — Partner и любой из этих параметров включен, доставка почты в домены завершится ошибкой после переключения записей MX. Перед продолжением необходимо отключить эти параметры. Если соединитель является локальным соединителем, используемым для гибридного использования, изменять локальный соединитель не нужно. Но вы по-прежнему можете проверка наличие соединителя партнера.
  • Если текущий шлюз почты также обеспечивает проверку получателя, может потребоваться проверка, что домен настроен как полномочный в Microsoft 365. Это может предотвратить ненужную передачу сообщений.

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

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

Дальнейшие действия

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

Теперь вы начинаете нормальную работу и обслуживание Defender для Office 365. Мониторинг и watch проблем, которые похожи на проблемы, с которыми вы столкнулись во время пилотного проекта, но в более крупном масштабе. Аналитика спуфинга и олицетворение наиболее полезны, но рассмотрите возможность регулярного выполнения следующих действий: