Кроки для аналізу використання service principal у вашому клієнті Microsoft 365

By Mirko Peters · 2026-03-09 · Updated 2026-09-13

Перевірте використання service principal за допомогою Microsoft Graph і журналів входу. Розгляньте необхідні дозволи, ідентичності застосунків, моніторинг і керування доступом.

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

Аналіз використання service principal за допомогою Service Principal Analysis є критично важливим для захисту вашого клієнта Microsoft 365. Моніторячи service principal, ви можете виявити потенційні ризики, зокрема shadow IT і слабкі налаштування безпеки. Ключові аспекти, на яких варто зосередитися:

• Некеровані облікові записи адміністраторів

• Непослідовна багатофакторна автентифікація (MFA)

• Зовнішній обмін без належного контролю

Розуміння активності входу за допомогою Service Principal Analysis допомагає вам виявляти незвичні шаблони і ефективно керувати доступом. Такий проактивний підхід не лише знижує ризики, а й забезпечує відповідність вимогам регуляторів, роблячи ваше середовище безпечнішим і простішим в управлінні.

Головне

• Регулярно моніторте активність входу service principal, щоб виявляти незвичні шаблони та посилювати безпеку.

• Переконайтеся, що маєте необхідні дозволи, наприклад AuditLog.Read.All, щоб ефективно аналізувати використання service principal.

• Дотримуйтесь принципу найменших привілеїв, надаючи кожному service principal лише необхідні дозволи.

• Автоматизуйте процеси моніторингу за допомогою інструментів на кшталт AdminDroid, щоб спростити керування і підвищити безпеку.

• Документуйте призначення і дозволи кожного service principal, щоб зберігати прозорість і відповідність вимогам.

1. Service principal є ідентичністю застосунку у вашому клієнті Microsoft 365: об’єкт застосунку є глобальним визначенням, а service principal є локальною ідентичністю, яка використовується для автентифікації, призначення ролей і контролю доступу у вашому клієнті Microsoft 365. Тому моніторинг використання service principal у клієнті Microsoft 365 критично важливий для відстеження того, хто і що може отримати доступ до ресурсів.
2. Кілька service principal можуть відповідати одному застосунку: один об’єкт застосунку може мати окремі service principal у кількох клієнтах, кожен із різними обліковими даними, наданими згодами і призначеннями ролей, тож той самий код застосунку може поводитися по-різному в різних клієнтах Microsoft 365.
3. Типи облікових даних впливають на поверхню атаки: service principal можуть використовувати клієнтські секрети, сертифікати або федеративну ідентичність. Довготривалі секрети розширюють поверхню атаки у вашому клієнті Microsoft 365, тоді як автентифікація на основі сертифікатів або федеративна автентифікація може знизити ризик за правильної конфігурації.
4. Делеговані дозволи та дозволи застосунку створюють різні ризики: дозволи лише для застосунку, надані service principal, забезпечують доступ незалежно від будь-якого користувача і можуть бути потужнішими за делеговані дозволи. Неправильно налаштовані дозволи застосунку є поширеною причиною надмірних привілеїв service principal у вашому клієнті Microsoft 365.
5. Згода користувача і згода адміністратора відрізняються залежно від області дії: користувачі можуть надавати згоду на певні делеговані дозволи для застосунків, але для дозволів застосунків із вищим рівнем ризику потрібна згода адміністратора. Відстеження подій згоди допомагає виявляти неочікуване використання service principal у вашому клієнті Microsoft 365.
6. Керовані ідентичності спрощують життєвий цикл, але прив’язані до клієнта: керовані ідентичності Azure AD (системні або призначені користувачем) автоматично створюють service principal для ресурсів, що спрощує керування обліковими даними у вашому клієнті Microsoft 365, але їх не можна перенести між клієнтами, тому переміщення ресурсів потребує повторного налаштування.
7. Умовний доступ і управління правами доступу застосовуються й до застосунків: Ви можете застосовувати політики умовного доступу та використовувати управління правами доступу (entitlement management), щоб керувати використанням субʼєктів-служб (service principal) у своєму клієнті Microsoft 365. Проте політики необхідно явно оцінювати в контексті застосунків, щоб запобігти несанкціонованому доступу до застосунків або горизонтальному переміщенню.

Передумови для аналізу субʼєктів-служб

Перш ніж аналізувати використання субʼєктів-служб, переконайтеся, що маєте необхідні дозволи та інструменти. Ця підготовка допоможе вам провести ґрунтовний аналіз і ефективно керувати субʼєктами-службами.

Необхідні дозволи

Щоб аналізувати активність субʼєктів-служб у Microsoft Entra та Microsoft 365, потрібні певні дозволи. У таблиці нижче наведено необхідну область дозволів:

Без належних дозволів можуть виникати помилки. Наприклад, якщо ви бачите повідомлення "Insufficient privileges to complete the operation", це означає, що у вас немає необхідного доступу. Таке обмеження може ускладнити управління субʼєктами-службами та їх аналіз.

Інструменти та ресурси

Правильні інструменти можуть прискорити процес аналізу. Ось кілька ефективних інструментів для аналізу субʼєктів-служб у середовищах Microsoft 365:

Щоб почати роботу з PowerShell, виконайте такі кроки:

1. Підключіться до Microsoft Graph PowerShell за допомогою: Connect-MgGraph -Scopes "AuditLog.Read.All"

2. Виконайте команду для аудиту входів субʼєктів-служб:

   Get-MgBetaAuditLogSignIn -Filter "signInEventTypes/any(t:t eq 'servicePrincipal')" -All | Select-Object CreatedDateTime, Id, ServicePrincipalId, ServicePrincipalName, ResourceDisplayName, ResourceId, @{Name = "Status"; Expression = { if ($_.Status.ErrorCode -eq 0) { "Success" } else { "Failed" } }} | Format-Table
   

Забезпечивши необхідні дозволи та інструменти, ви створюєте передумови для успішного аналізу субʼєктів-служб.

Створення субʼєкта-служби в Microsoft Entra

Створення субʼєкта-служби в Microsoft Entra передбачає реєстрацію застосунку. Це дозволяє вашому застосунку безпечно автентифікуватися та отримувати доступ до ресурсів. Ось як можна зареєструвати застосунок:

Реєстрація застосунку

Щоб зареєструвати застосунок у Microsoft Entra, виконайте такі кроки:

1. Увійдіть до центру адміністрування Microsoft Entra.

2. Перейдіть до Applications і виберіть New registration.

3. Заповніть обовʼязкові відомості, зокрема назву застосунку та URI перенаправлення.

4. Виберіть відповідний тип облікового запису залежно від ваших потреб.

5. Натисніть Register, щоб завершити процес.

Після реєстрації можна створити субʼєкта-службу. Цей субʼєкт-служба виступає ідентичністю вашого застосунку, коли той взаємодіє з іншими службами.

У Microsoft Entra для створення субʼєкта-служби можна використати кілька методів. Серед них:

• Завантаження довіреного сертифіката, виданого центром сертифікації.

• Створення та завантаження самопідписаного сертифіката для тестування.

• Створення нового клієнтського секрету.

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

Визначення ініціатора

Визначення того, хто ініціював створення субʼєкта-служби, є критично важливим для безпеки та аудиту. Цю інформацію можна відстежити так:

1. Увійдіть до центру адміністрування Microsoft Entra.

2. Перейдіть до Monitoring & health і виберіть Audit logs.

3. Установіть для Category значення ApplicationManagement і застосуйте фільтр.

4. Відфільтруйте Activity за значенням Add service principal і застосуйте фільтр.

5. Оберіть подію та розгорніть розділ Additional details. Шукайте властивості на кшталт ServicePrincipalProvisioningType, SubscribedSkus та AppOwnerOrganizationId.

Відстеження ініціатора допомагає зрозуміти, хто створює service principal-и і навіщо. Ця інформація критично важлива для підтримки безпеки та відповідності вимогам у вашій організації.

Ось короткий огляд атрибутів, які можна знайти в журналах аудиту:

Розуміючи, хто є ініціатором service principal, ви можете підвищити рівень безпеки та переконатися, що service principal-и створюють лише уповноважені користувачі.

Перегляд активності входу за допомогою Microsoft Graph

Доступ до Microsoft Graph API

Щоб отримати журнали входу для service principal-ів, можна скористатися Microsoft Graph API. Виконайте такі кроки, щоб отримати потрібні дані:

1. Використовуйте Microsoft Graph API для формування звіту про активність входу service principal-ів.

2. Виконайте команду Get-MgServicePrincipal, щоб отримати service principal-ів у вашому клієнті.

3. Створіть хеш-таблицю ідентифікаторів застосунків і відображуваних імен. Цей крок важливий, оскільки записи входу не містять назв застосунків.

4. Виконайте Get-MgBetaReportServicePrincipalSignInActivity, щоб знайти активність входу service principal-ів, останній вхід яких був більш ніж рік тому.

5. Складіть звіт про service principal-ів і експортуйте дані у файл CSV.

6. Згенеруйте статистику, зокрема клієнтів, яким належать застосунки, і загальну кількість service principal-ів.

Дотримуючись цих кроків, ви зможете ефективно отримувати та аналізувати журнали входу для своїх service principal-ів.

Аналіз журналів входу

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

Ось деякі поширені аномалії, які можна виявити в журналах входу service principal-ів:

• Незвичайне використання застосунків, наприклад, коли давно не використовувані або забуті застосунки знову активуються.

• Неочікувані довірчі відносини, які було додано до Azure AD.

• Зміни облікових даних service principal-ів, зокрема зміни дозволів.

Щоб ефективно аналізувати журнали входу, варто скористатися такими стратегіями:

1. Відстежуйте активність входу через центр адміністрування Microsoft Entra, щоб переглянути входи service principal-ів за останні 24 години.

2. Визначайте ризikові service principal-и, аналізуючи журнали входу на предмет незвичайних закономірностей.

3. Використовуйте такі інструменти, як Microsoft Entra та PowerShell, для детального аналізу журналів входу.

Застосовуючи ці стратегії, ви підвищите свою здатність виявляти підозрілу активність входу та вживати відповідних заходів для захисту вашого середовища.

Ефективне управління service principal-ами

Найкращі практики управління

Щоб ефективно керувати service principal-ами, варто дотримуватися низки найкращих практик. Їх застосування підвищить рівень безпеки та спростить роботу у вашому клієнті:

• Принцип найменших привілеїв: надавайте кожному service principal лише необхідні дозволи. Це обмежує потенційну шкоду, якщо service principal буде скомпрометовано.

• Регулярна ротація облікових даних: змінюйте облікові дані регулярно і автоматизуйте цей процес, коли це можливо. Це зменшує ризик використання застарілих або скомпрометованих облікових даних.

• Моніторинг активності: стежте за активністю service principal, щоб своєчасно помітити підозрілу поведінку. Це допомагає раніше виявити спроби несанкціонованого доступу.

• Надійна автентифікація: використовуйте надійні методи автентифікації, зокрема багатофакторну автентифікацію (MFA). Це додає ще один рівень захисту.

• Безпечне зберігання облікових даних: зберігайте та керуйте обліковими даними service principal безпечно, за допомогою рішення для керування секретами. Не зберігайте облікові дані в коді чи файлах конфігурації.

• Документація: документуйте призначення та дозволи кожного service principal. Ця практика допомагає розуміти їхні ролі у вашому клієнті.

• Політики управління: установіть чіткі політики управління для керування service principal. Регулярно переглядайте та аудитуйте дозволи, щоб забезпечити відповідність вимогам.

Автоматизація моніторингу

Автоматизація моніторингу service principal може суттєво підвищити ваш рівень безпеки. Ось кілька інструментів і стратегій, які варто розглянути:

• AdminDroid: цей інструмент пропонує функцію моніторингу активності входу. Вона допомагає відстежувати закономірності входу service principal і надає детальні звіти про використання та тенденції доступу.

• Звіт про зміни service principal: AdminDroid також пропонує звіт, який відстежує зміни в service principal. Цей звіт деталізує додавання, оновлення та видалення, а також дії входу, зокрема час, назву застосунку, статус і місцезнаходження.

Автоматизуючи моніторинг, ви отримуєте кілька переваг:

Впровадження цих практик та інструментів допоможе ефективно керувати service principal і підтримувати безпечне середовище у вашому клієнті Microsoft 365.

Підсумовуючи, аналіз використання service principal має важливе значення для захисту вашого клієнта Microsoft 365. Регулярно відстежуйте активність входу, керуйте дозволами та дотримуйтеся найкращих практик. Ось ключові висновки, які допоможуть покращити керування service principal:

Застосовуючи ці стратегії, ви зможете зміцнити рівень безпеки та забезпечити ефективне керування service principal в організації.

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

Що таке service principal у Microsoft 365?

Service principal є ідентичністю для застосунків, яка забезпечує безпечний доступ до ресурсів. Вона дозволяє застосункам проходити автентифікацію без облікових даних користувача.

Як відстежувати активність service principal?

Ви можете відстежувати активність service principal за допомогою Microsoft Graph API або таких інструментів, як AdminDroid. Ці інструменти надають інформацію про закономірності входу та тенденції використання.

Чому важливо аналізувати використання service principal?

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

Які дозволи потрібні для аналізу службових принципалів?

Щоб аналізувати активність службових принципалів у Microsoft Entra та Microsoft 365, потрібен дозвіл AuditLog.Read.All. Він дає доступ до необхідних журналів.

Як автоматизувати моніторинг службових принципалів?

Моніторинг можна автоматизувати за допомогою інструментів на кшталт AdminDroid. Вони можуть формувати звіти про активність входу та зміни службових принципалів, що спрощує адміністрування.

об'єкти застосунків у Microsoft Entra ID і створення службового принципала

Що таке службовий принципал і як він пов'язаний з об'єктами застосунків у Microsoft Entra ID?

Службовий принципал — це задіяний у безпеці суб'єкт, який представляє застосунок або службу у вашому клієнті Microsoft Entra. Він відповідає об'єкту застосунку (глобальному визначенню), а службовий принципал є екземпляром, створеним у вашому клієнті під час реєстрації застосунку або надання згоди на нього. Ідентифікатори застосунку (application ID) і клієнта (client ID) пов'язують ці два об'єкти, і якщо службовий принципал створено, ви побачите в Microsoft Entra як об'єкти застосунків, так і об'єкти службових принципалів.

Як створити службового принципала у своєму клієнті Microsoft 365?

Службового принципала можна створити, зареєструвавши застосунок у центрі адміністрування Microsoft Entra або через Azure CLI чи Microsoft Graph PowerShell SDK. Типові кроки такі: спершу створити застосунок (об'єкт застосунку), потім створити службового принципала у домашньому або володіючому клієнті, призначити дозволи та згенерувати облікові дані (секрет клієнта або сертифікат). Для автоматизованих скриптів використовуйте команду az ad sp create-for-rbac в Azure CLI або Microsoft Graph PowerShell SDK, щоб створити службового принципала.

Де знайти відомості про службового принципала та проаналізувати його активність входу?

Відомості про службового принципала доступні в центрі адміністрування Microsoft Entra, у розділі «Корпоративні застосунки» або «Реєстрації застосунків» залежно від типу. Можна переглянути такі властивості, як ім'я службового принципала, ідентифікатор застосунку, ідентифікатор клієнта та призначені ролі. Щоб проаналізувати активність входу, використовуйте журнали входу (Sign-ins) у Microsoft Entra або запитуйте звіти про входи через Microsoft Graph, щоб переглянути події автентифікації, події створення службових принципалів і телеметрію входів.

Як політики доступу та параметри автентифікації впливають на нового службового принципала?

Політики доступу та параметри автентифікації визначають, до яких ресурсів може звертатися службовий принципал і як він автентифікується. Налаштовуйте об'єкти застосунків і службових принципалів з мінімальними необхідними привілеями, призначайте ролі для ресурсів і використовуйте умовний доступ та політики доступу в центрі адміністрування Microsoft Entra. Обирайте методи автентифікації (секрет клієнта, сертифікат або керована ідентичність) відповідно до актуальних оновлень безпеки та рекомендацій, щоб знизити ризики.

Чи можуть застосунки першої сторони Microsoft або служби Microsoft створювати службових принципалів у моєму клієнті?

Так. Застосунки першої сторони Microsoft і служби Microsoft часто створюють об'єкти службових принципалів у Microsoft Entra ID, коли їх використовують у вашому клієнті. Такі об'єкти можуть відображатися як застосунки Entra або застосунки першої сторони Microsoft. Деякі служби створюють службових принципалів автоматично під час підключення; ви можете переглядати й контролювати їх у центрі адміністрування Microsoft Entra та, де це підтримується, застосовувати просту й відповідну до потреби (just-in-time) видачу доступу.

Як керувати дозволами та об'єктами принципалів у Microsoft Entra, щоб знизити ризики?

Аудитуйте події створення службових принципалів, перевіряйте дозволи, надані об'єктам службових принципалів у Microsoft Entra ID, і видаляйте зайві привілеї. Використовуйте призначення ролей, а де це доречно — дозволи застосунків замість делегованих, впроваджуйте умовний доступ і видачу доступу just-in-time (або службового принципала з правом на отримання доступу just-in-time), а також регулярно змінюйте облікові дані. Для докладних рекомендацій з безпеки та процедур технічної підтримки використовуйте Microsoft Learn та інші додаткові ресурси.

Які інструменти можна використовувати для автоматизації перевірки та створення службових принципалів (PowerShell, Azure CLI)?

Для автоматизації створення та перевіркиService Principal можна використовувати Microsoft Graph PowerShell SDK, Azure CLI або Microsoft Graph API. Команди на кшталт az ad sp create-for-rbac і їхні аналоги в Microsoft Graph PowerShell SDK дозволяють створити service principal і отримати client ID, application ID та tenant ID. Скрипти також можуть перелічувати об'єкти service principal у Microsoft Entra і збирати дані про входи або дозволи для звітності.

Як дізнатися, чи був service principal створений клієнтським застосунком або обліковим записом Microsoft?

Перегляньте відомості про service principal у центрі адміністрування Microsoft Entra або виконайте запит через Microsoft Graph, щоб побачити такі властивості, як власник застосунку, видавець і тип джерела створення. Service principal, створені клієнтським застосунком, посилаються на application ID або client ID і зазвичай показують, який суб'єкт їх створив, та час створення. Service principal, створені для служб Microsoft або застосунків першої сторони Microsoft, зазвичай містять видавця або відомі ідентифікатори Microsoft.

Де знайти додаткові ресурси й рекомендації щодо Office 365 для IT-фахівців і найкращих практик service principal?

Скористайтеся Microsoft Learn, документацією центру адміністрування Microsoft Entra, посібниками з платформи identity Microsoft і статтями для ІТ-фахівців Office 365. Додаткові ресурси включають документацію Microsoft Graph, довідники Azure CLI і Microsoft Graph PowerShell SDK, а також публікації Microsoft про безпеку. Для складних сценаріїв зверніться до служби технічної підтримки або перегляньте лабораторні роботи Microsoft Learn щодо об'єктів застосунків і service principal у вашому клієнті.