Предустановленные и пользовательские политики защиты от фишинга в Microsoft Defender for Office 365
By Mirko Peters ·
Узнайте, когда использовать предустановленные и пользовательские политики защиты от фишинга в Microsoft Defender for Office 365, как избежать ловушек с приоритетом и защитить ваш клиент Microsoft 365.
Automatically translated with AI from the original post. Read the English original

Выбор между предустановленными политиками безопасности и пользовательскими конфигурациями в Microsoft Defender for Office 365 определяет, насколько эффективно ваша организация блокирует целевые фишинговые атаки. В этом руководстве разбирается порядок оценки политик, скрытые ловушки с приоритетом и практическая схема, помогающая понять, когда пользовательские правила действительно оправданы по сравнению со встроенными рекомендациями Microsoft.
Главное
- Microsoft оценивает политики защиты электронной почты строго сверху вниз: предустановленная «Строгая», предустановленная «Стандартная», пользовательские политики и, наконец, встроенная защита.
- Оценка останавливается на первом совпадении, поэтому пользователи в областях действия предустановленных политик полностью обходят любые пользовательские политики защиты от фишинга, которые вы создали.
- Предустановленные политики безопасности снимают с вас нагрузку по обслуживанию и управлению расхождением политик, а Microsoft обеспечивает автоматическое обновление базового уровня защиты от новых угроз.
- Пользовательские политики требуют существенных административных усилий и должны использоваться только для реальных, задокументированных бизнес-исключений.
- Пользователей с высоким риском, таких как руководители, сотрудники финансового отдела и ИТ-администраторы, следует включать в области строгих предустановленных политик, а не в индивидуально настроенные правила изоляции.
Ловушка приоритета политик: почему пользовательские правила тихо не срабатывают
Многие администраторы безопасности электронной почты тратят дни на создание пользовательских политик защиты от фишинга в портале Microsoft Defender. Они тщательно настраивают уровни уверенности в фишинге, формируют обширные списки защищаемых пользователей и задают конкретные действия для попыток подмены личности. Портал показывает обнадёживающий статус «Включено», и конфигурация выглядит безупречно на бумаге. Однако, несмотря на всю эту работу, политика может так и не сработать ни для одного пользователя.
Суть проблемы в том, как Microsoft 365 обрабатывает несколько пересекающихся правил. Механизм оценки не объединяет настройки и не выбирает самое строгое правило. Вместо этого он проходит по жёсткой иерархии: сначала оценивается строгая предустановленная политика, затем стандартная предустановленная, далее пользовательские политики и, в самом низу, встроенная защита. Как только получатель попадает под политику, стоящую выше в цепочке, оценка останавливается окончательно. Если сотрудники финансового отдела попадают в область действия стандартной предустановленной политики, ваше пользовательское правило защиты от фишинга для финансов полностью игнорируется. Никаких сообщений об ошибках и оповещений не появляется, и возникает невидимая брешь в безопасности, которой злоумышленники могут легко воспользоваться.
Предустановленные и пользовательские политики: административный компромисс
Понимание принципиального различия между предустановленными политиками безопасности Microsoft и пользовательскими конфигурациями клиента необходимо для долгосрочного управления облачной архитектурой. Предустановленные политики («Стандартная» и «Строгая») отражают коллективные знания, собранные на основе миллионов глобальных почтовых ящиков. Microsoft постоянно обновляет эти настройки на основе телеметрии угроз в реальном времени, поэтому вы получаете преимущество от наблюдений по всей отрасли, которых отдельный клиент никогда не смог бы получить самостоятельно.
Напротив, пользовательская политика отражает субъективное мнение одного администратора, применённое к конкретной организации в определённый момент времени. Пользовательские правила дают детальный контроль над отдельными потоками почты или специфическими требованиями бизнеса, но создают серьёзную нагрузку на обслуживание. Когда векторы атак меняются, пользовательские политики остаются полностью статичными. Без выделенного цикла проверки пользовательские настройки незаметно расходятся с современными стандартами безопасности и создают уязвимости, которые после инцидента бывает трудно выявить.
Когда пользовательские политики защиты от фишинга действительно оправданы?
Поскольку предустановленные политики эффективно решают большинство пользовательских сценариев, пользовательские политики следует рассматривать как исключения, а не как стратегию развёртывания по умолчанию. Чтобы оправдать постоянные затраты на обслуживание пользовательского правила, оно, как правило, должно относиться к одной из трёх конкретных операционных категорий:
- Персонально заданные списки защищаемых пользователей: Если в организации требуется точно определённый перечень руководителей, членов совета директоров или утверждающих финансовые операции, защищаемых индивидуально настроенными порогами подмены личности, пользовательские политики защиты от фишинга позволяют указать именно These имена.
- Нестандартные потоки почты: Подразделения, которые регулярно получают нестандартные внешние файлы или зависят от внутренних автоматизированных систем, склонных вызывать ложные срабатывания, могут требовать узко ограниченных пользовательских правил для поддержания непрерывности бизнеса.
- Сторонние почтовые шлюзы: Организации, которые направляют почту через внешний шлюз безопасности перед Microsoft 365, часто сталкиваются с изменёнными сведениями о подключении и результатами аутентификации, что требует специальной обработки в параметрах пользовательской политики.
Если причиной создания пользовательского правила является лишь предпочтение других значений шкалы или смутное ощущение, что настройки по умолчанию слишком мягкие, политика, скорее всего, не оправдывает своей долгосрочной операционной стоимости.
Заключение и дальнейшие шаги
Баланс между автоматизированным интеллектом и точечными пользовательскими настройками является признаком зрелой стратегии безопасности в облаке. Используя предустановленные политики Microsoft для основной массы сотрудников и оставляя пользовательские правила исключительно для документированных исключений, вы снижаете административную нагрузку и одновременно повышаете эффективность обнаружения угроз. Чтобы изучить более глубокие стратегии внедрения, циклы настройки и метрики отчётности, послушайте полный выпуск подкаста M365 FM, где экспертные советы и практические рекомендации помогут оптимизировать безопасность вашей платформы Microsoft 365 уже сегодня.
Часто задаваемые вопросы
Что происходит, если пользователь включён и в предустановленную, и в пользовательскую политику?
Механизм оценки Microsoft 365 обрабатывает политики в строгом порядке, отдавая приоритет предустановленным политикам (сначала Strict, затем Standard) перед пользовательскими. Если пользователь соответствует предустановленной политике, система прекращает дальнейшую оценку, и пользовательская политика для этого получателя полностью пропускается.
Обновляются ли предустановленные политики безопасности Microsoft автоматически?
Да. Предустановленные политики поддерживаются напрямую корпорацией Microsoft. Когда меняется ландшафт угроз и изменяются рекомендуемые базовые значения, Microsoft автоматически обновляет основные параметры предустановок Standard и Strict, избавляя администраторов от ручных циклов проверки.
Почему пользователей с высоким риском, например руководителей, стоит включать в строгие предустановленные политики, а не в пользовательские правила?
Роли с высоким риском являются основными целями для целенаправленных фишинговых атак и атак с подменой личности. Строгие предустановки применяют агрессивные пороги защиты, опирающиеся на глобальную телеметрию Microsoft, обеспечивая комплексную защиту без необходимости вручную поддерживать сложные пользовательские списки исключений.
Как проверить, какая политика действительно применяется к почтовому ящику конкретного пользователя?
Действующие политики можно проверить с помощью Configuration Analyzer в портале Microsoft Defender или выполнив расширенные запросы поиска угроз по событиям электронной почты, чтобы выяснить, какие конкретные механизмы обнаружения и политики обработали входящие сообщения пользователя.