Типові та користувацькі політики захисту від фішингу в Microsoft Defender for Office 365

By Mirko Peters · 2026-10-29

Дізнайтеся, коли варто використовувати вбудовані (preset) та власні (custom) політики захисту від фішингу в Microsoft Defender for Office 365, як уникнути пасток із пріоритетністю та захистити свій хмарний клієнт.

Automatically translated with AI from the original post. Read the English original

Вибір між вбудованими політиками безпеки та власними конфігураціями в Microsoft Defender for Office 365 визначає, наскільки ефективно ваша організація зупиняє цілеспрямовані фішингові атаки. У цьому посібнику розібрано порядок оцінювання політик, приховані пастки пріоритетності та практичну модель для визначення, коли власні правила справді виправдані понад рекомендації Microsoft.

Головне

• Microsoft оцінює політики захисту електронної пошти суворо зверху вниз: спочатку Strict preset, потім Standard preset, далі власні політики і насамкінець вбудований захист.
• Механізм оцінювання зупиняється на першому ж збігу, тож користувачі в межах вбудованих політик повністю обходять будь-які власні політики захисту від фішингу, які ви створили.
• Вбудовані політики безпеки передають Microsoft обслуговування та контроль відхилень політик, тож ваш базовий рівень автоматично оновлюється проти нових загроз.
• Власні політики обходяться дорого з погляду адміністративних витрат, тому їх варто залишати лише для справжніх, задокументованих бізнес-винятків.
• Користувачам із високим ризиком, як-от керівникам, фінансовому персоналу та ІТ-адміністраторам, місце в межах суворих вбудованих політик, а не у власних ізольованих правилах.

Пастка пріоритетності політик: чому власні правила тихо не працюють

Багато адміністраторів безпеки пошти витрачають дні на створення власних політик захисту від фішингу в порталі Microsoft Defender. Вони ретельно налаштовують рівні впевненості щодо фішингу, формують великі списки захищених користувачів і задають дії для спроб підробки особи. Портал показує заспокійливий статус «Enabled», а конфігурація виглядає бездоганно на папері. Проте, попри всю цю ретельну роботу, політика може жодного разу не спрацювати для жодного користувача.

Основна проблема полягає в тому, як Microsoft 365 обробляє кілька накладних правил. Механізм оцінювання не поєднує налаштування і не обирає найсуворіше правило. Натомість він проходить жорстку ієрархію: спочатку оцінюється строга вбудована політика, потім стандартна вбудована, далі власні політики і наостанок вбудований захист унизу. Щойно одержувач потрапляє до політики вищого рівня, оцінювання зупиняється назавжди. Якщо члени вашої фінансової команди опиняються в межах стандартної вбудованої політики, ваше власне правило захисту від фішингу для фінансового відділу повністю ігнорується. Жодних повідомлень про помилки не з'являється, сповіщень не надходить, і виникає невидима прогалина в безпеці, яку зловмисники легко можуть використати.

Вбудовані та власні політики: адміністративний компроміс

Розуміння принципової різниці між вбудованими політиками безпеки Microsoft і власними конфігураціями клієнта є важливим для довгострокового управління хмарною архітектурою. Вбудовані політики (Standard і Strict) відображають колективний досвід, зібраний на мільйонах глобальних поштових скриньок. Microsoft постійно оновлює ці налаштування на основі телеметрії загроз у реальному часі, тож ви користуєтеся спостереженнями в масштабах галузі, яких окремий клієнт ніколи не зміг би отримати самостійно.

І навпаки, власна політика відображає суб'єктивне судження одного адміністратора, застосоване до однієї організації в певний момент часу. Власні правила дають детальний контроль над окремими потоками пошти або特殊 бізнес-вимогами, але вони створюють серйозне навантаження на супровід. Коли вектори атак змінюються, власні політики залишаються повністю статичними. Без окремого циклу перегляду власні налаштування непомітно відхиляються від сучасних стандартів безпеки, створюючи вразливості, які після інциденту важко виявити.

Коли власні політики протидії фішингу справді виправдані?

Оскільки попередні налаштування ефективно обробляють більшість сценаріїв користувачів, власні політики слід розглядати як винятки, а не як стандартну стратегію розгортання. Щоб виправдати постійні витрати на супровід власного правила, воно, як правило, має підпадати під одну з трьох конкретних операційних категорій:

• Персонально визначені списки захищених користувачів: Якщо вашій організації потрібен чіткий перелік керівників, членів правління або осіб, які затверджують фінансові операції, захищених адаптованими порогами імітації, власні політики протидії фішингу дають змогу вказати саме ці імена.
• Нестандартні потоки пошти: Бізнес-підрозділи, які регулярно отримують нестандартні зовнішні файли або покладаються на внутрішні автоматизовані системи, схильні до хибних спрацьовувань, можуть потребувати вузько спрямованих власних правил для збереження безперервності бізнесу.
• Сторонні шлюзи електронної пошти: Організації, які спрямовують пошту через зовнішній шлюз безпеки перед Microsoft 365, часто стикаються зі зміненими деталями з'єднання та результатами автентифікації, що потребує спеціальної обробки в параметрах власної політики.

Якщо ваша мотивація створити власне правило полягає лише в бажанні інших значень повзунків або в туманному відчутті, що стандартні налаштування занадто м'які, політика, найімовірніше, не виправдовує своєї довгострокової операційної вартості.

Висновки та наступні кроки

Поєднання автоматизованого інтелекту з точковими власними налаштуваннями є ознакою зрілої стратегії безпеки в хмарі. Покладаючись на попередні політики Microsoft для широкої бази співробітників і залишаючи власні правила виключно для задокументованих винятків, ви зменшуєте адміністративне навантаження та водночас максимізуєте ефективність виявлення загроз. Щоб дізнатися більше про стратегії впровадження, цикли налаштування та метрики звітності, прослухайте повний епізод подкасту M365 FM з експертними порадами та практичними рекомендаціями для підвищення рівня безпеки вашого Microsoft 365 уже сьогодні.

Поширені запитання

Що відбувається, якщо користувач включений і до попередньої, і до власної політики?

Механізм оцінювання Microsoft 365 обробляє політики у строгому порядку, надаючи перевагу попереднім політикам (спочатку Strict, потім Standard) над власними. Якщо користувач відповідає попередній політиці, система припиняє подальше оцінювання, і власна політика для цього одержувача повністю ігнорується.

Чи оновлюються попередні політики безпеки Microsoft автоматично?

Так. Попередні політики підтримує безпосередньо Microsoft. Коли ландшафт загроз змінюється і рекомендовані базові значення оновлюються, Microsoft автоматично змінює базові параметри в попередніх налаштуваннях Standard і Strict, звільняючи адміністраторів від ручних циклів перегляду.

Чому користувачів з високим ризиком, як-от керівників, варто розміщувати в суворих попередніх політиках, а не у власних правилах?

Ролі з високим ризиком є основними цілями для витончених атак spear-phishing та імітації. Суворі попередні політики застосовують агресивні пороги захисту, підкріплені глобальною телеметрією Microsoft, забезпечуючи комплексний захист без необхідності вручну підтримувати складні списки власних винятків.

Як перевірити, яка саме політика застосовується до поштової скриньки конкретного користувача?

Ефективні політики можна перевірити за допомогою Configuration Analyzer у порталі Microsoft Defender або запустивши розширені запити полювання (advanced hunting) до подій електронної пошти, щоб простежити, які саме механізми виявлення та політики вплинули на вхідні повідомлення користувача.