Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Эта статья поможет оценить и выбрать поддерживаемый способ интеграции службы безопасности электронной почты без Microsoft с Microsoft 365, включая компромиссы и рекомендации по поддержке для каждого варианта.
Хотя корпорация Майкрософт предоставляет комплексную платформу для обеспечения безопасности электронной почты, мы понимаем, что некоторые клиенты внедряют стратегию глубокой защиты электронной почты , добавляя службу безопасности, не относясь к корпорации Майкрософт. Существует два соображения по включению служб безопасности, отличных от Майкрософт, в Microsoft 365:
Повышает ли служба, не относящаяся к Microsoft, уровень защищенности вашей организации и какие компромиссы с этим связаны. Например, вы можете:
- Дополнительные затраты.
- Больше сложности.
- Скорость ложноположительных результатов (хорошие элементы, помеченные как плохие) увеличивается по мере добавления дополнительных продуктов.
- Как служба безопасности, отличная от Microsoft, интегрируется по всей цепочке. Например, вы можете:
- Сторонняя служба должна обеспечивать такой пользовательский опыт, при котором пользователям не нужно задумываться о том, какой карантин использовать.
- Служба сторонних поставщиков должна интегрироваться с существующими процессами и инструментами операций безопасности (SecOps). Например, управление информационной безопасностью и событиями безопасности (SIEM), оркестрация безопасности, автоматизация и реагирование (SOAR) и т. д.
Примечание.
Безопасность электронной почты — это среда постоянного противостояния. С распространением массового фишинга и наборов инструментов для атак атаки быстро развиваются и видоизменяются. Microsoft Defender для Office 365 является частью Microsoft Defender — нашего многоуровневого подхода к обеспечению корпоративной кибербезопасности до и после нарушения безопасности.
Независимо от того, сколько уровней защиты электронной почты существует, общая защита никогда не достигает 100 процентов.
Как сторонняя служба сканирует и обрабатывает сообщения электронной почты. Как правило, службы безопасности, не относящиеся к корпорации Майкрософт, предлагают следующие три варианта интеграции, и не все из них в настоящее время поддерживаются корпорацией Майкрософт в равной степени.
Интеграция через маршрутизацию почты DNS (запись MX указывает на службу, не относящуюся к Microsoft)
Расширенная фильтрация соединителей позволяет Microsoft 365 определить исходный источник сообщений, передаваемых через другую службу почты, прежде чем достичь Exchange Online. Использование расширенной фильтрации для коннекторов, когда перед Microsoft 365 размещена служба, отличная от Microsoft, подробно рассматривается в статье «Расширенная фильтрация для коннекторов в Exchange Online», и Microsoft полностью поддерживает такой сценарий. Authenticated Received Chain (ARC) сохраняет результаты аутентификации электронной почты, когда сообщения проходят через промежуточные службы. Поставщики безопасности электронной почты, поддерживающие работу ARC, лучше всего работают, но существуют ограничения. Например, не используйте Safe Links для проверки и оборачивания ссылок с помощью службы, не принадлежащей Microsoft, которая также переписывает ссылки. Двойное оборачивание ссылок может помешать Safe Links проверять состояние ссылок, проверять ссылки на наличие угроз и может также привести к срабатыванию одноразовых ссылок. Рекомендуется отключить функцию упаковки ссылок в службе сторонних поставщиков.
Дополнительные сведения о маршрутизации почты через облачную службу, не Microsoft до Exchange Online, см. в статье "Управление потоком обработки почты с помощью облачной службы, отличной от Microsoft" с Exchange Online.
Интеграция с помощью microsoft API Graph
Important
Эта интеграция обычно требует предоставления службы без Microsoft полного доступа к почтовым ящикам. Прежде чем предоставлять это разрешение, ознакомьтесь с рекомендациями по обеспечению безопасности и поддержки служб сторонних поставщиков.
Некоторые службы, не относящиеся к Корпорации Майкрософт, выполняют проверку подлинности и используют API Graph Майкрософт для сканирования сообщений после их доставки в почтовые ящики пользователей. Использование Microsoft API Graph для сканирования сообщений после доставки также позволяет службе без Microsoft удалять сообщения, которые они считают вредоносными или нежелательными.
Интеграция с помощью маршрутизации почты
Маршрутизация входящей и исходящей почты позволяет записи MX указывать на Microsoft 365. Однако служба сторонних поставщиков работает после защиты и обработки электронной почты Microsoft 365, как показано на следующей схеме:
Совет
Расширенная фильтрация для соединителей не работает с маршрутизацией почты с выходом и повторным входом, при которой почта покидает Microsoft 365 и затем снова поступает в него. Расширенная фильтрация для коннекторов предназначена для сценариев, в которых служба не Майкрософт находится перед Microsoft 365 в маршруте прохождения почты (запись MX указывает на службу не Майкрософт). Эта конфигурация позволяет использовать полный стек защиты электронной почты, при этом интеллектуально предотвращая ложные срабатывания при определении спуфинга, связанные с инфраструктурой отправки службы, не принадлежащей Microsoft. Вы не можете использовать расширенную фильтрацию для соединителей, чтобы по своей сути доверять всем сообщениям с IP-адресов Microsoft 365.
Маршрутизация входящей и исходящей почты требует, чтобы сообщение покинуло пределы службы Microsoft 365. Сообщения, возвращаемые из службы сторонних поставщиков, обрабатываются в Microsoft 365 как совершенно новые сообщения. Это приводит к следующим проблемам и сложностям:
Сообщения учитываются дважды в большинстве средств создания отчетов, включая Explorer (Threat Explorer), Расширенный поиск угроз и автоматизированное расследование и реагирование (AIR). Такое поведение затрудняет правильную корреляцию вердикта сообщения и действий.
Поскольку сообщения, возвращаемые в Microsoft 365, скорее всего, не пройдут проверки подлинности электронной почты, они могут быть распознаны как подмена (ложноположительные срабатывания). Некоторые службы, не относящиеся к Корпорации Майкрософт, рекомендуют использовать правила потока обработки почты (правила транспорта) или фильтрацию IP-подключений для устранения этой проблемы, но это может привести к доставке ложноотрицательных данных.
Самое главное, машинное обучение в Defender для Office 365 работает не так эффективно, как это возможно. Алгоритмы машинного обучения используют точные данные для принятия решений о содержимом. Несогласованные или измененные данные могут негативно повлиять на процесс обучения, что приводит к снижению общей эффективности Defender для Office 365. Вот некоторые примеры.
- Репутация. Со временем модели машинного обучения обнаруживают элементы, связанные с хорошим и плохим содержимым (IP-адреса, отправляющие домены, URL-адреса и т. д.). Когда сообщения возвращаются из сторонней службы, не относящейся к Microsoft, исходные IP-адреса отправителей не сохраняются, что может снизить эффективность использования IP-адресов при вынесении верного решения. Это поведение также может повлиять на ложные отрицательные и ложные положительные отправки электронной почты в Microsoft, как описано на шаге 3. Отправка ложных отрицательных и ложных положительных сообщений электронной почты.
- Изменения содержимого сообщений. Многие службы безопасности электронной почты добавляют заголовки сообщений, добавляют заявления об отказе, изменяют содержимое текста сообщения и (или) перезаписывают URL-адреса в сообщениях. Машинное обучение может по ошибке счесть сообщения с такими изменениями вредоносными, поскольку автоматическое удаление в нулевой час (ZAP) обнаружило и удалило вредоносные сообщения, которые содержали такие изменения.
По этим причинам мы настоятельно рекомендуем избегать такой конфигурации и работать с сторонним поставщиком услуг, чтобы использовать другие варианты интеграции, описанные в этой статье. Тем не менее, если необходимо внедрить маршрутизацию почты в режиме "вне сети", настоятельно рекомендуется использовать следующие параметры и операции, чтобы максимально повысить уровень защиты:
Настройте действия политики Defender для Office 365 так, чтобы все отрицательные вердикты отправлялись в карантин. Хотя эта конфигурация может быть менее удобной для пользователя, чем использование папки «Нежелательная почта», обработка нежелательной почты выполняется только после окончательной доставки сообщения в почтовый ящик. Письмо, которое должно было попасть в папку "Нежелательная почта", вместо этого было отправлено в службу, не относящуюся к Microsoft. Если или когда это сообщение возвращается в Корпорацию Майкрософт, нет никакой гарантии, что исходный вердикт (например, спам) будет сохранен. Это приводит к снижению общей эффективности.
Совет
Правила потока обработки почты (правила транспорта), которые рассматривают исходные вердикты, не являются идеальными, так как они могут создавать другие проблемы и создавать проблемы с эффективностью.
Сведите к минимуму ложные срабатывания, настроив переопределение для спуфинга сообщений электронной почты, поступающих из службы, не принадлежащей Microsoft. Например, если у сторонней службы есть IP-адрес 172.17.17.35, создайте две разрешённые записи поддельного отправителя в списке разрешений/блокировок арендатора: одну внешнюю и одну внутреннюю, как показано на следующем снимке экрана:
Обязательно удалите эти записи переопределения, если вы перестанете использовать службу защиты не от Microsoft или измените принцип ее работы.
Ложноотрицательная (недопустимая почта разрешена) и ложноположительные отправки сообщений в Корпорацию Майкрософт должны поступать из первоначальной версии сообщения, а не из той, которая возвращается из службы сторонних поставщиков. Ложные срабатывания, относящиеся к службе, не принадлежащей Microsoft, следует отправлять в эту службу. Это требование может быть сложным для управления:
- Ложноотрицательный результат Майкрософт (пропущен при первоначальном приеме): перед доставкой в почтовый ящик требуется копия сообщения. Отправьте копию из карантина службы, не относящейся к Microsoft, если она доступна.
- Ложноотрицательный результат Microsoft и сторонней службы: Если обе службы не обнаружили его, рекомендуется сообщить об исходном элементе в Microsoft и сообщить об элементе в почтовом ящике получателя сторонней службе. Элемент, возвращенный в Microsoft 365 из службы, не являющейся корпорацией Майкрософт, содержит сведения из службы, не являющейся корпорацией Майкрософт (например, ip-адреса, пользовательские заголовки и т. д.), что может привести к снижению эффективности машинного обучения.
- Ложное срабатывание Microsoft: Если Microsoft перехватила сообщение раньше, чем сторонняя служба, отправка этой копии из карантина будет эффективной.
- Ложное срабатывание сторонней службы (не Майкрософт): Если сообщение было задержано сторонней службой, необходимо отправить это сообщение им, так как Майкрософт не может исправить эту проблему.
Интеграция средств создания отчетов о сообщениях сторонних организаций
В Defender для Office 365 есть параметры сообщений, сообщаемых пользователями, которые работают со встроенной кнопкой «Сообщить» в поддерживаемых версиях Outlook.
Учитывая, что сторонние службы безопасности могут включать собственные средства и процессы для сообщения о ложноположительных и ложноотрицательных срабатываниях (включая мероприятия по обучению и повышению осведомленности пользователей), Microsoft Defender для Office 365 поддерживает отправку данных из сторонних средств отправки сообщений. Эта возможность помогает упростить отправку отчетов о ложноположительных и ложноотрицательных результатах в Microsoft и позволяет вашей команде безопасности (SecOps) воспользоваться возможностями Microsoft Defender по управлению инцидентами и автоматизированному расследованию и реагированию (AIR).
Дополнительные сведения см. в разделе Параметры средств создания отчетов сторонних организаций.
Совет
В обучении моделированию атак в Defender для Office 365, план 2 имитационные сообщения, о которых сообщают сторонние средства, не относящиеся к Microsoft, не отражаются в отчетах по моделированию атак.