Переход на 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 на всех пользователей и отключите правило обхода фильтрации почтовых потоков
  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, он будет иметь разрешения администратора безопасности везде.
  • Роли для электронной почты и совместной работы на портале Microsoft Defender предоставляют права доступа к порталу Microsoft Defender и порталу Microsoft Purview. Например, если добавить пользователя в администратор безопасности на портале Microsoft Defender, у него есть доступ к администратору безопасности только на портале Microsoft Defender и на портале Microsoft Purview.
  • Многие функции портала Microsoft Defender основаны на командлетах Exchange Online PowerShell и поэтому требуют членства в соответствующих ролях (технически — в группах ролей) в Exchange Online (в частности, для доступа к соответствующим командлетам Exchange Online PowerShell).
  • На портале Microsoft Defender существуют роли для электронной почты и совместной работы, для которых нет эквивалентов среди ролей Microsoft Entra и которые важны для операций по обеспечению безопасности (например, роль Preview и роль Search and Purge).

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

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

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

Примечание.

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

Шаг 3: Настройте систему выявления спуфинга

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

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

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

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

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

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

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

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

Примечание.

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

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

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

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

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

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

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

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

Настройте защиту от имитации пользователя

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

Откройте аналитику по имперсонации, чтобы узнать, какие попытки имперсонации пользователей блокируются.

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

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

Настройте защиту от подмены домена

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Шаг 7: Расширите защиту Microsoft 365 на всех пользователей и отключите правило обхода фильтрации почтовых потоков

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

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

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

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

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

  2. Отключите правило обхода фильтрации почтовых потоков (уровень доверия к спаму или SCL -1). Вы можете отключить её, не удаляя.

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

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

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

Примечание.

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

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

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

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

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

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

  • Last updated on