Від охоронця до спостерігача: поєднуємо безпеку до та після автентифікації

By Mirko Peters · 2026-08-11

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

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

Ласкаво просимо назад до подкасту та нашого супутнього технічного огляду! Якщо ви колись відчували, що стратегія безпеки ідентичності має сліпу зону одразу після того, як користувач успішно увійшов у систему, ви точно не самотні. Упродовж багатьох років організації покладалися насамперед на засоби контролю до автентифікації, щоб не пустити зловмисників, і вважали вхідні двері останнім рубежем безпеки. Але що відбувається, коли супротивник проникає повз ці двері з дійсним токеном або викраденим набором облікових даних? Саме ця дилема стала центральною темою нашого нещодавнього епізоду Conditional Access with Defender for Identity Signals. У цій публікації ми розвинемо ці концепції та розберемо, як поєднати охоронця до автентифікації зі спостерігачем після автентифікації, щоб побудувати справді стійку архітектуру ідентичності.

Основна ідея (коротко)

Щоб по-справжньому зрозуміти сучасний захист ідентичності, розглядайте свої інструменти як спеціалізовані ролі, що працюють разом у реальному часі:

• Conditional Access (CA) — це ваш вишибала. Він надзвичайно добре ухвалює рішення до автентифікації на основі того, хто намагається увійти, звідки він це робить і стану його пристрою.
• Defender for Identity (DfI) — це ваша система відеоспостереження в поєднанні з охороною приміщень. Він добре відстежує поведінку після автентифікації, бічне переміщення та внутрішні аномалії.
• Справжня стійкість досягається лише тоді, коли ризик після автентифікації автоматично та динамічно підвищує рівень тертя до автентифікації — саме тут, під час сеансу.

Ментальна модель

Уточнімо ментальну модель того, як ці компоненти взаємодіють у вашій екосистемі:

• Охоронець (CA): оцінює, хто входить у систему, звідки, стан пристрою, ризик під час входу, і застосовує негайні контролі сеансу.
• Спостерігач (DfI + M365 Defender): шукає бічне переміщення, аномальні шаблони доступу до ресурсів, Kerberoasting, зловживання NTLM та неочікувані підвищення привілеїв.
• Петля зворотного зв'язку: спостерігач позначає підозрілу поведінку, що, своєю чергою, підвищує оцінку ризику користувача або ризику сеансу. Це змушує охоронця негайно посилити контролі: увімкнути додаткову перевірку MFA, повністю заблокувати доступ або обмежити активний сеанс.

План інтеграції (що увімкнути й у якому порядку)

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

1. Conditional Access з урахуванням ризиків (базовий рівень)
   • Entra ID Protection: увімкніть оцінювання ризику користувача та ризику входу.
   • Створіть політики CA:
     • Блокувати, коли ризик користувача = високий (або вимагати зміну пароля, якщо ваші процеси служби підтримки це дозволяють).
     • Вимагати MFA, коли ризик входу ≥ середній.
     • Вимагати відповідний пристрій для застосунків із середнім і високим рівнем чутливості; використовуйте фільтри пристроїв для некерованих кінцевих точок, щоб одразу направляти їх до обмежених контролів сеансу.
2. Дозвольте спостерігачу взаємодіяти з охоронцем
   • Переконайтеся, що DfI активно передає сповіщення до Microsoft 365 Defender і Sentinel (якщо ви використовуєте його для SIEM/SOAR).
   • Автоматизуйте дії "Підтвердити компрометацію" для користувачів у разі сповіщень DfI високої серйозності. Це встановлює ризик користувача = високий у Entra ID Protection, і ваші політики CA миттєво реагують.
   • Шлях автоматизації: інцидент M365 Defender → Logic App або Power Automate → Graph Security/Identity Protection API (/riskDetections, /riskyUsers:confirmCompromised) → за бажанням примусовий вихід із системи.
   • Увімкніть Continuous Access Evaluation (CAE) для всіх підтримуваних застосунків (Exchange, SharePoint, Graph), щоб зміни політик справді завершували чинні токени.
3. Контроль сеансу для локалізації загрози
   • Для некерованих або ризикованих сеансів розгорніть Defender for Cloud Apps (проксі сеансу) безпосередньо з CA:
     • CA → Використовувати Conditional Access App Control (спочатку моніторинг, потім блокування витоку даних, як-от завантаження, копіювання та вставлення, друк і синхронізація).
   • Поєднайте це з ризиком пристрою MDE → відповідність Intune → CA «Require compliant device» для всіх чутливих застосунків.
4. Захисні бар'єри для привілейованої ідентичності
   • PIM має забезпечувати доступ Just-in-Time; перед наданням підвищених прав вимагайте MFA + відповідний пристрій + відсутність ризикованого стану користувача.
   • Налаштуйте політику CA, яка блокує привілейовані ролі, якщо ризик користувача ≥ Low (так, навіть за низького ризику), щоб примусити негайну перевірку до того, як адміністративну роль буде активовано.

«Якщо це, то те»: зіставлення сигналів DfI з діями CA

Зіставлення конкретних сигналів виявлення з Defender for Identity з автоматизованими діями Conditional Access і реагування дозволяє подолати розрив між пасивним спостереженням і активним захистом:

Почніть із запуску цих правил у режимі аудиту/моніторингу на 1–2 тижні, а потім переведіть реагування в режим примусового застосування для кожного класу сповіщень, коли зростатиме впевненість.

Зразки політик (практичні, мінімальні)

Щоб впровадити ці стратегії в роботу, ось чотири базові політики, які варто налаштувати:

1. Блокувати, коли ризик користувача = High
   • Призначення: всі користувачі (крім аварійних облікових записів), всі хмарні застосунки
   • Умови: ризик користувача = High
   • Надання доступу: блокувати доступ
2. Посилена перевірка за ризиком входу
   • Призначення: всі користувачі, застосунки високої цінності (портали адміністрування, Exchange, SharePoint, центр адміністрування Entra)
   • Умови: ризик входу ≥ Medium
   • Надання доступу: вимагати MFA + вимагати відповідний пристрій (або керований пристрій)
3. Сесія містить некерований вміст
   • Призначення: всі користувачі, SharePoint/OneDrive/Teams
   • Стан пристрою: Hybrid/Compliant = виняток; Unmanaged = застосовувати
   • Сесія: використовувати Conditional Access App Control (блокувати завантаження)
4. Захист від підвищення привілеїв
   • Призначення: ролі каталогу = привілейовані адміністративні ролі
   • Умови: ризик користувача ≥ Low АБО ризик входу ≥ Medium
   • Надання доступу: вимагати MFA + вимагати відповідний пристрій; блокувати, якщо ризик ≥ High

Плейбуки автоматизації (готові до підключення)

Автоматизація — це ключ до скорочення середнього часу локалізації інциденту (MTTC). Ось два плейбуки, які можна створити вже сьогодні:

Плейбук A: сповіщення DfI високої серйозності → локалізація ідентичності

• Тригер: інцидент M365 Defender з позначкою IdentityThreatHigh
• Дії:
  1. Graph API – підтвердити компрометацію користувача (встановлює ризик користувача High)
  2. Entra ID – негайно відкликати токени оновлення
  3. Intune/MDE – ізолювати пристрій (якщо з обліковим записом пов'язано один основний пристрій)
  4. ServiceNow/JSM – створити тикет інциденту з хронологією та зібраними артефактами
  5. Повідомити SOC і власника облікового запису через адаптивну картку Teams з кнопкою одноклікового відкату на випадок хибних спрацьовувань

Плейбук B: сплеск аномального доступу до SharePoint

• Тригер: сповіщення Defender «Незвичне завантаження файлу»
• Дії:
  1. Позначити користувача UnderInvestigation через розширювані атрибути AAD
  2. Перевести користувача до політики CA, яка перенаправляє його до App Control (блокування завантажень і друку)
  3. Запустити утримання eDiscovery для уражених сайтів SharePoint (необов'язково, залежно від вимог відповідності)
  4. Автоматично завершувати локалізацію через 72 години, якщо SOC вручну не продовжить її

Полювання на загрози та корисні запити

Превентивне полювання допомагає виявити прогалини до того, як ними скористаються зловмисники. Використовуйте ці запити в розширеному полюванні M365 Defender:

Сплеск доступу користувача до сайтів SharePoint порівняно з його 30-денним базовим рівнем:

let lookback=30d;
let recent=1h;
let baseline = CloudAppEvents
    | where Timestamp between (ago(lookback) .. ago(recent))
    | where Application == "SharePoint" and ActionType == "FileAccessed"
    | summarize uniqSites=dcount(SiteUrl) by AccountUpn;
CloudAppEvents
| where Timestamp >= ago(recent)
| where Application == "SharePoint" and ActionType in ("FileDownloaded","FileAccessed")
| summarize curSites=dcount(SiteUrl), dls=sumif(1, ActionType=="FileDownloaded") by AccountUpn
| join kind=leftouter baseline on AccountUpn
| where curSites > 3 * coalesce(uniqSites,1) or dls > 500

Сплески ризику входу, тісно пов'язані з наступними сигналами DfI:

let riskySignIns = IdentityLogonEvents
| where RiskLevelDuringSignIn in ("medium","high")
| project AccountUpn, Timestamp, RiskLevelDuringSignIn;
let dfiAlerts = IdentityDirectoryEvents
| where EventType startswith "DefenderForIdentity"
| project AccountUpn, DfiTime=Timestamp, AlertType=EventType;
riskySignIns
| join kind=inner dfiAlerts on AccountUpn
| where DfiTime between (Timestamp .. Timestamp + 4h)

Метрики, що це підтверджують

Щоб показати керівництву відчутне зниження ризиків, потрібні метрики. Відстежуйте такі ключові показники ефективності:

• Середній час локалізації інциденту (MTTC) для інцидентів з ідентифікацією (від генерації сповіщення до застосування політики CA) ↓
• Час перебування зловмисника (від першої підозрілої дії до повного усунення наслідків) ↓
• Заблоковані ризиковані сесії (події, що спрацювали за політикою) ↑, тоді як частота хибних спрацювань ↓
• Вік невирішених справ про ризикових користувачів (відкриті справи старші за 24 години) ↓
• Затримка відкликання токенів (вимірюється в секундах) ↓
• Збої підвищення привілеїв через ризик (виявлені на ранньому етапі, до завдання шкоди) ↑, а потім з часом нормалізуються
• Secure Score для Identity, Devices та Apps ↑ за відсутності відповідного сплеску звернень до служби підтримки

Стратегія розгортання 30/60/90

Не намагайтеся змінити все за одну ніч. Скористайтеся поетапним планом:

Дні 0–30 (основи)

• Увімкніть налаштування ризику користувача та входу в Entra, розгорніть базові політики CA в режимі аудиту, а потім переведіть їх у режим примусового застосування.
• Підключіть Defender for Identity до M365 Defender; перевірте сповіщення та основні відповідності сутностей.
• Увімкніть Continuous Access Evaluation (CAE) для підтримуваних застосунків і інтегруйте ризик пристрою MDE з відповідністю Intune.

Дні 31–60 (зворотний зв’язок і локалізація)

• Створіть плейбуки A і B у Logic Apps та ретельно протестуйте їх у стані пробного запуску.
• Запустіть пілотний проєкт App Control для некерованих сесій у 2–3 командах, які активно співпрацюють.
• Впровадьте політику обмеження підвищення привілеїв PIM.

Дні 61–90 (примусове застосування і вимірювання)

• Переведіть автоматизовані плейбуки в повний режим примусового застосування для сповіщень з високою достовірністю.
• Створіть робочу книгу з безпеки ідентифікації (у Sentinel або Power BI), що відстежує метрики, перелічені вище.
• Проводьте щоквартальні навчання purple team, щоб перевірити MTTC, швидкість відкликання токенів і перемикання політик CA у реальному сценарії атаки.

Типові пастки (і безпечніші налаштування за замовчуванням)

Остерігайтеся цих типових помилок під час впровадження:

• Пастка: покладатися лише на ризик входу з CA → Виправлення: реагуйте також на ризик користувача і сповіщення DfI після автентифікації.
• Пастка: CAE не налаштовано, тож застарілі токени підтримують скомпрометовані сесії → Виправлення: увімкніть CAE і вбудуйте відкликання токенів безпосередньо в автоматизовані плейбуки.
• Пастка: масове блокування завантаження файлів у всій організації, що викликає бурхливе невдоволення користувачів → Виправлення: застосовуйте App Control вибірково, лише коли сесії є некерованими або ризиковими.
• Пастка: лавина сповіщень і хибні спрацювання через надто агресивні автоматичні сценарії реагування → Виправлення: пускайте автоматизацію лише після перевірки за кількома сигналами (наприклад, сповіщення DfI високого рівня + незвично великий обсяг завантажень + доступ у неробочий час).
• Пастка: облікові записи аварійного доступу випадково блокуються автоматичними політиками ризику → Виправлення: виключіть два ретельно відстежуванні облікові записи аварійного доступу та щокварталу змінюйте їхні облікові дані.

Готові фрагменти для копіювання

Щоб донести ці зміни до всієї організації, скористайтеся такими готовими текстами:

Один рядок для керівництва (CAB):

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

Примітка про зміни для адміністраторів:

• Нові політики умовного доступу можуть запитувати додаткову автентифікацію MFA або блокувати доступ, коли виявлено аномальний ризик. Активні токени автентифікації тепер можна відкликати під час сесії на основі телеметрії. Облікові записи аварійного доступу залишаються явно виключеними. Будь ласка, стежте за робочою книгою Identity Resilience для аналізу впливу.

Автоматична картка сповіщення для власників у Teams:

• «Ми помітили незвичну активність із файлами з вашого облікового запису. Ми застосували тимчасові захисні заходи (наприклад, вимкнули завантаження на некерованих пристроях). Якщо це були ви, просто натисніть Підтвердити; якщо ні, будь ласка, негайно натисніть Повідомити.»