Як ефективно керувати службовими принципалами в Entra ID

By Mirko Peters · 2026-03-22 · Updated 2026-03-24

Захистіть службові принципали в Microsoft Entra ID для посиленого управління ідентичностями. Дізнайтеся про об'єкти застосунків і службових принципалів у вашому клієнті.

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

Керування службовими принципалами та реєстраціями застосунків в Entra ID є критично важливим для підтримки безпеки та контролю доступу. Ефективне управління допомагає запобігти серйозним інцидентам безпеки, таким як підвищення привілеїв і компрометація клієнта. Наприклад, зловмисники можуть використати погано керовані службові принципали, щоб скинути паролі адміністраторів і отримати несанкціонований доступ до критичних систем. Застосовуючи надійні практики керування, ви можете знизити ці ризики та зберегти безпеку середовища. Ключові кроки включають розуміння того, що таке службові принципали, призначення відповідних дозволів і регулярний перегляд політик доступу.

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

1. Службові принципали відрізняються від об'єктів застосунків: Об'єкт застосунку є глобальним визначенням застосунку, а службовий принципал є локальною ідентичністю в клієнті. Один об'єкт застосунку може мати кілька службових принципалів у різних клієнтах.
2. Їхні облікові дані можуть не мати терміну дії: Entra ID дозволяє створювати клієнтські секрети або сертифікати без терміну дії, як через свідомий вибір, так і через неправильну конфігурацію, що підвищує довгостроковий ризик, якщо їх не ротувати вручну.
3. Керовані ідентичності під капотом використовують службові принципали: Як керовані ідентичності, призначені системою, так і призначені користувачем, представлені в каталозі як службові принципали, тож до них можуть застосовуватися політики RBAC та умовного доступу.
4. Службові принципали можна використовувати в умовному доступі: Хоча умовний доступ переважно орієнтований на користувачів, він може оцінювати контексти застосунків, а деякі політики можуть впливати на службові принципали, особливо в поєднанні з контекстом автентифікації застосунку.
5. Вони одночасно підтримують делеговані дозволи та дозволи застосунку: Один службовий принципал може мати і делеговані дозволи (від імені користувача), і дозволи застосунку (лише для застосунку), що ускладнює дотримання принципу найменших привілеїв.
6. Журнали входу містять неінтерактивні автентифікації застосунків: Entra ID фіксує входи службових принципалів, що дозволяє виявляти аномальну активність застосунків, але ці журнали часто залишаються поза увагою порівняно з входами користувачів.
7. Згода адміністратора та керування правами можуть створювати приховані шляхи доступу: Корпоративні застосунки та службові принципали, надані через згоду адміністратора або керування правами, можуть створювати непрямі шляхи доступу, які складно виявити без ретельного перегляду прав і дозволів.

Головне

• Розумійте різницю між реєстраціями застосунків і службовими принципалами в Entra ID.
• Переконайтеся, що маєте необхідні дозволи перед керуванням службовими принципалами, щоб уникнути перешкод.
• Дотримуйтеся чіткого процесу реєстрації застосунків в Entra ID, зокрема заповнюйте всі необхідні відомості.
• Використовуйте кілька методів автентифікації, щоб підвищити безпеку ваших застосунків.
• Впроваджуйте керування доступом на основі ролей (RBAC), щоб призначати службовим принципалам відповідні дозволи.
• Регулярно переглядайте політики доступу, щоб вони відповідали найкращим практикам безпеки.
• Проводьте аудити, щоб відстежувати зміни та виявляти несанкціонований доступ або дії.
• Дотримуйтеся принципу найменших привілеїв, надаючи службовим принципалам лише необхідні дозволи.

Передумови для керування Entra ID

Розуміння службових принципалів

Перш ніж керувати службовими принципалами в Entra ID, варто засвоїти кілька базових понять. Ось ключові моменти, які слід знати:

• Реєстрація застосунку (App) — це глобально унікальний об'єкт, що представляє застосунок в Entra ID.
• Службовий принципал (SP) — це конкретний екземпляр цього об'єкта застосунку в межах одного клієнта.
• Коли ви створюєте реєстрацію застосунку, у тому самому клієнті автоматично створюється обліковий запис служби (service principal).
• Облікові записи служб мають власні облікові дані та дозволи, які відрізняються від об'єкта застосунку.
• Дії в клієнті, наприклад створення користувача, виконує обліковий запис служби (Service Principal).

Портал Entra ID може бути заплутаним. Облікові записи служб відображаються в розділі «Корпоративні застосунки», а термін «Service Principal» майже не вживається. Через це можуть виникати непорозуміння щодо зв'язку між реєстраціями застосунків і обліковими записами служб.

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

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

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

Розуміючи ці передумови, ви закладаєте міцну основу для керування обліковими записами служб в Entra ID. Ці знання допоможуть вам орієнтуватися в складнощах керування доступом і зміцнити безпеку вашої організації.

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

Кроки реєстрації застосунку

Реєстрація застосунку в Entra ID є простим процесом. Щоб почати, виконайте такі кроки:

1. Увійдіть на портал Entra ID: використайте обліковий запис Microsoft Entra, щоб отримати доступ до порталу.
2. Перейдіть до розділу реєстрацій застосунків: у лівому меню виберіть «Реєстрації застосунків».
3. Натисніть «Нова реєстрація»: ця опція дає змогу створити новий застосунок.
4. Заповніть відомості про застосунок:
   • Назва: виберіть унікальну назву для застосунку.
   • Підтримувані типи облікових записів: виберіть, хто може користуватися застосунком (наприклад, лише облікові записи в цьому каталозі організації).
   • URI перенаправлення: вкажіть URI, на який користувачі будуть перенаправлятися після автентифікації. Це критично важливо для веб-застосунків.
5. Перевірте й зареєструйте: після заповнення необхідних відомостей натисніть «Зареєструвати», щоб створити застосунок.

Після реєстрації в одному клієнті з безкоштовною редакцією можна створити до 50 000 ресурсів Microsoft Entra. Якщо ви підтвердите свій домен, цей ліміт можна збільшити до 300 000 ресурсів. Також можна налаштувати облікові дані для щонайбільше 48 застосунків, які використовують єдиний вхід на основі пароля.

Налаштування параметрів застосунку

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

1. Налаштуйте кілька методів автентифікації Entra ID: використовуйте різні методи автентифікації, зокрема багатофакторну автентифікацію (MFA) і автентифікацію без пароля, щоб підвищити безпеку.
2. Використовуйте групи Entra ID для призначення дозволів: створюйте групи користувачів, щоб ефективно керувати контролем доступу. Так користувачі матимуть лише потрібні дозволи.
3. Використовуйте політики умовного доступу (CAP): впроваджуйте CAP, щоб визначати умови доступу до ресурсів. Це додає ще один рівень безпеки завдяки детальному контролю.

Крім того, варто провести інвентаризацію застосунків. Визначте та внесіть до каталогу всі застосунки, підключені до Entra, для ефективного керування ними. Регулярно перевіряйте дозволи, призначені кожному застосунку, щоб вони відповідали вашій стратегії безпеки. Вилучайте невикористовувані застосунки, щоб зменшити поверхню атаки.

Дотримуючись цих кроків і рекомендацій, ви можете гарантувати, що ваш застосунок правильно налаштовано та захищено в Entra ID.

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

Огляд RBAC

Role-Based Access Control (RBAC) — це ключова функція Entra ID. Вона допомагає керувати тим, хто і до яких ресурсів в організації має доступ. За допомогою RBAC ви можете призначати ролі субʼєктам-службам, гарантуючи, що вони мають потрібні дозволи для виконання своїх завдань без шкоди для безпеки.

В Entra ID є два типи визначень ролей:

• Вбудовані ролі: Мають фіксований набір дозволів. Їх не можна змінювати, але вони охоплюють типові сценарії.
• Користувацькі ролі: Дозволяють налаштувати дозволи під конкретні потреби. Створення користувацької ролі складається з двох кроків: визначення ролі та її призначення.

Розуміння цих типів ролей допомагає обрати правильний підхід для ваших застосунків. Щоб дізнатися більше про RBAC, ознайомтеся з оглядом управління доступом на основі ролей.

Призначення ролей

Призначення ролей субʼєктам-службам є важливим для ефективного керування. Дотримуйтеся цих кроків, щоб правильно призначити ролі:

1. Створіть призначення ролей: Скористайтеся центром адміністрування Microsoft Entra, Microsoft Graph PowerShell або Microsoft Graph API. Зверніть увагу, що Azure CLI для цього завдання не підтримується.
2. Зареєструйте свій застосунок: Переконайтеся, що ви зареєстрували застосунок Microsoft Entra та створили субʼєкт-службу через портал Azure.
3. Оберіть правильну роль: Перегляньте доступні ролі, щоб визначити, яка з них надає необхідні дозволи для вашого застосунку.

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

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

Методи автентифікації для Entra ID

Огляд автентифікації

Під час керування субʼєктами-службами в Entra ID доступні два основні методи автентифікації: автентифікація за секретом клієнта та автентифікація на основі сертифіката. Кожен метод має свої переваги та сфери застосування.

Автентифікація за секретом клієнта

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

• Переваги:

  • Легкий у впровадженні.
  • Підходить для тестових і робочих середовищ розробки.

• Недоліки:

  • Менш безпечний, ніж автентифікація на основі сертифіката.
  • Уразливий до витоку, якщо ним неналежно керувати.

Автентифікація на основі сертифіката

Автентифікація на основі сертифіката використовує цифровий сертифікат для автентифікації субʼєкта-служби. Цей метод безпечніший за секрети клієнта та рекомендується для робочих середовищ. Для максимальної безпеки використовуйте довірений сертифікат, виданий центром сертифікації (CA). Самопідписані сертифікати можна використовувати для тестування, але для робочих середовищ їх не рекомендовано.

• Переваги:

  • Вищий рівень безпеки.
  • Знижує ризик крадіжки облікових даних.

• Недоліки:

  • Складніше налаштовувати.
  • Потребує керування сертифікатами.

Налаштування автентифікації

Щоб налаштувати автентифікацію для вашого субʼєкта служби в Entra ID, виконайте такі кроки:

1. Відкрийте головну сторінку центру адміністрування Microsoft Entra.
2. Перейдіть до Entra ID > Реєстрації застосунків і виберіть свій застосунок.
3. На сторінці огляду застосунку скопіюйте значення Directory (tenant) ID і збережіть його в коді застосунку.
4. Скопіюйте значення Application (client) ID і збережіть його в коді застосунку.
5. Оберіть між автентифікацією на основі сертифіката або секрету клієнта. Рекомендовано завантажити довірений сертифікат, виданий центром сертифікації.
6. Якщо використовуєте сертифікат, завантажте його через Entra ID > Реєстрації застосунків > Certificates & secrets > Upload certificate.
7. Якщо використовуєте секрет клієнта, створіть його через Entra ID > Реєстрації застосунків > Certificates & secrets > Client secrets > New client secret.

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

Політики доступу в Entra ID

Розуміння політик доступу

Політики доступу в Entra ID відіграють важливу роль у захисті ваших застосунків і даних. Ці політики визначають, хто може отримати доступ до яких ресурсів і за яких умов. Ось деякі ключові типи політик доступу, які варто знати:

• Вимагати MFA для ризикованих входів: ця політика просить користувачів пройти багатофакторну автентифікацію, коли вхід видається підозрілим.
• Блокувати або усувати компрометовані облікові записи: ця політика автоматично обмежує доступ до облікових записів, які demonstrують ознаки компрометації.

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

Налаштування політик доступу

Налаштування політик доступу для субʼєктів служби в Entra ID є доволі простим. Виконайте такі кроки, щоб ефективно налаштувати ваші політики:

1. Увійдіть до центру адміністрування Microsoft Entra і перейдіть до Entra ID » Корпоративні застосунки.
2. Клацніть субʼєкт служби, який хочете обмежити, і перейдіть до Properties у розділі Manage.
3. Встановіть Enabled for users to sign-in? у значення No і натисніть Save, щоб вимкнути вхід користувачів до застосунку.
4. Щоб створити політику умовного доступу, увійдіть до центру адміністрування Microsoft Entra і перейдіть до Entra ID » Умовний доступ.
5. Клацніть +Create new policy і введіть назву політики.
6. У розділі Assignments перейдіть до Users or workload identities.
7. Виберіть Workload identities у пункті What does this policy apply to. У розділі Include натисніть Select service principals і виберіть потрібні субʼєкти служби зі списку.
8. У розділі Target resources перейдіть до Include і виберіть All resources (formerly 'All Cloud apps').
9. У розділі Conditions налаштуйте конкретні вимоги, щоб визначити, коли політика має спрацьовувати.
10. У розділі Access controls перейдіть до 'Grant', виберіть Block access і натисніть 'Select'.
11. Встановіть Enable policy у значення On і натисніть 'Create', щоб створити політику умовного доступу для робочих ідентичностей Microsoft Entra.

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

Найкращі практики для службових принципалів

Рекомендації щодо безпеки

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

• Використовуйте клієнтські сертифікати замість клієнтських секретів для підвищення безпеки.
• Використовуйте Azure Key Vault для безпечного керування сертифікатами та секретами.
• Застосовуйте принцип мінімальних привілеїв для службових принципалів. Це означає надавати лише ті дозволи, які необхідні для їхніх завдань.
• Відстежуйте входи службових принципалів через журнали входу Microsoft Entra. Це допомагає виявляти незвичну активність.
• Використовуйте умовний доступ, щоб обмежити доступ із ненадійних місцезнаходжень. Це додатковий рівень захисту.
• Регулярно перевіряйте членство в ролях рівня 0, щоб переконатися, що рівень привілеїв відповідає потребам. Це запобігає неавторизованому доступу до критично важливих ресурсів.

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

Регулярні аудити

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

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

Дотримуючись цих найкращих практик, ви можете ефективно керувати службовими принципалами в Entra ID, посилюючи безпеку та відповідність вимогам.

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

• Правильно реєструвати застосунки та налаштовувати їхні параметри.
• Призначати ролі відповідно до принципу мінімальних привілеїв.
• Впроваджувати надійні методи автентифікації.
• Регулярно переглядати політики доступу та дозволи.

Постійне керування є критично важливим. Зручність самообслуговування посилює потребу в покращеному керуванні доступом. Регулярні перевірки допомагають зберігати контроль над правами доступу. Кожен гостьовий обліковий запис повинен мати внутрішнього власника, відповідального за постійне обґрунтування доступу. Дотримуючись цих стратегій, ви можете посилити безпеку та забезпечити ефективне управління вашими службовими принципалами.

Цей контрольний список допомагає впровадити найкращі практики ефективного керування службовими принципалами в Entra ID.

• Інвентаризація та виявлення: визначте всі службові принципали в усіх клієнтах і підписках (створіть регулярне сканування або звіт).
• Зіставлення із застосунками та власниками: пов'яжіть кожен службовий принцип з відповідним застосунком, бізнес-власником і контактом служби підтримки.
• Класифікація доступу та призначення: задокументуйте призначення, середовище (prod/dev/test) і необхідні дозволи для кожного службового принципалу.
• Принцип мінімальних привілеїв: перевірте призначені ролі та дозволи; видаліть або зменшіть дозволи до мінімально необхідного рівня.
• Віддавайте перевагу керованим ідентичностям: там, де це можливо, замініть реєстрації застосунків і службові принципали керованими ідентичностями для ресурсів Azure.
• Гігієна облікових даних: уникайте довгостроковых облікових даних, віддавайте перевагу сертифікатам замість клієнтських секретів і регулярно оновлюйте облікові дані.
• Застосовуйте політики для облікових даних: впроваджуйте умовний доступ і політики паролів та секретів Azure AD для облікових даних застосунків, де це доречно.
• Вимагайте MFA та умовний доступ для інтерактивного використання: блокуйте або обмежуйте облікові дані, які дозволяють інтерактивний вхід, якщо це не необхідно й вони не захищені.
• Увімкніть just-in-time (JIT) або доступ з обмеженим часом: надавайте ролі з високими привілеями субʼєктам-службам на обмежений час там, де це можливо.
• Правила іменування та метадані: застосовуйте чіткі стандарти іменування та позначайте субʼєкти-служби метаданими про середовище, власника й термін дії.
• Політики закінчення терміну дії та життєвого циклу: встановлюйте термін дії для секретів і сертифікатів та автоматизуйте життєвий цикл (створення, оновлення, відкликання, деактивація).
• Вимикайте невикористовувані субʼєкти-служби: вимикайте або видаляйте субʼєкти-служби, які не використовувалися протягом визначеного періоду, після підтвердження з власниками.
• Відстежуйте входи та ризикову активність: увімкніть журналювання й сповіщення про аномальні входи, високоризикову активність і підвищення привілеїв.
• Централізоване журналювання та інтеграція з SIEM: передавайте журнали аудиту, події входу та зміни provisioning до вашої SIEM для кореляції та зберігання.
• Перегляди доступу та періодичні аудити: регулярно проводьте перегляди доступу, щоб підтверджувати необхідність кожного субʼєкта-служби та схвалення власника.
• Посилюйте API та дозволи: використовуйте делеговані дозволи з обмеженою областю дії або scope лише для застосунку, визначені вузько.
• Безпечне зберігання секретів: зберігайте клієнтські секрети та сертифікати в Azure Key Vault або еквівалентному сховищі; обмежуйте доступ до сховища лише для потрібних субʼєктів.
• Автоматизоване усунення проблем: впроваджуйте автоматизовані плейбуки для вимкнення скомпрометованих або прострочених субʼєктів-служб і ротації облікових даних.
• Примусове виконання політик: використовуйте Azure AD / Entra ID Conditional Access, Microsoft Entra permissions management і Azure Policy для дотримання стандартів.
• Документація та runbook-и: підтримуйте runbook-и для створення, екстреної ротації облікових даних і процедур деактивації.
• Тестування доступу та відмовостійкості: перевіряйте сценарії автентифікації застосунків після ротації облікових даних або змін конфігурації в непродуктивному середовищі.
• Безпечне підключення та відключення: інтегруйте створення й деактивацію субʼєктів-служб у CI/CD і процеси контролю змін.
• Сервісні облікові записи з мінімальними привілеями для автоматизації: використовуйте окремі субʼєкти-служби для завдань автоматизації з вузько обмеженими правами та чітко визначеним власником.
• Перегляньте зовнішній доступ і гостьові облікові записи: аудитуйте субʼєкти-служби, створені зовнішніми застосунками, і надавайте доступ лише після перевірки безпеки.
• Зберігайте докази відповідності: фіксуйте схвалення, перегляди та події ротації, щоб демонструвати відповідність внутрішнім і зовнішнім вимогам.
• Навчання команд і власників: навчайте власників застосунків і розробників ефективно керувати субʼєктами-службами в Entra ID та безпечним практикам роботи з обліковими даними.

FAQ: додаткові ресурси щодо субʼєктів-служб Microsoft Entra ID

Що таке субʼєкт-служба Microsoft Entra ID і чим він відрізняється від обʼєкта застосунку?

Субʼєкт-служба Microsoft Entra ID — це локальне представлення екземпляра застосунку в клієнті або каталозі; він створюється в кожному клієнті, де використовується застосунок, і посилається на глобально унікальний обʼєкт застосунку (обʼєкт застосунку розташований у домашньому клієнті). Обʼєкт застосунку визначає застосунок глобально, а субʼєкт-служба визначає політику доступу та те, що цей застосунок може робити в конкретному клієнті.

Як створюються субʼєкти-служби і коли саме?

Субʼєкт-служба зазвичай створюється автоматично, коли ви реєструєте застосунок Microsoft Entra і екземпляр застосунку використовується в клієнті, або коли користувач надає згоду на дозволи для багатоклієнтського застосунку. Ви також можете створити його вручну через Azure portal, Microsoft Graph або автоматизацію, коли застосунок розгортається в клієнті, де йому потрібен доступ до захищених ресурсів.

Які найкращі практики захисту субʼєктів-служб у Microsoft Entra?

Захищайте субʼєкти-служби, надаючи дозволи з мінімальними привілеями, ротуючи й захищаючи облікові дані (паролі та сертифікати), використовуючи керовані ідентичності там, де це можливо, застосовуючи політики умовного доступу, відстежуючи журнали входів і аудиту та виключаючи високоризикові субʼєкти за допомогою контролю доступу на основі фільтрів. Використовуйте умовний доступ для субʼєктів-служб, щоб вимагати відповідні пристрої або MFA для доступу до чутливих ресурсів.

Як керувати обліковими даними субʼєктів-служб, зокрема паролями та сертифікатами?

Зберігайте паролі та сертифікати в захищеному сховищі (Key Vault), встановлюйте терміни дії, за можливості використовуйте автентифікацію на основі сертифікатів і автоматизуйте ротацію за допомогою Microsoft Graph або конвеєрів CI/CD. Для довгостроковых облікових даних налаштуйте сповіщення про наближення закінчення терміну дії та застосовуйте схему й політику, які не дозволяють використовувати застарілі чи небезпечні секрети.

Як використовувати Microsoft Graph для запитів і керування субʼєктами-службами (service principals) в автоматизованому режимі?

Використовуйте Microsoft Graph API, щоб переглядати, фільтрувати, створювати, оновлювати та видаляти обʼєкти субʼєктів-служб Microsoft Entra ID. Можна виконувати запити з фільтрами, щоб знайти субʼєкти за appId, displayName або власником, керувати наданими дозволами, призначати власників і автоматизувати синхронізацію субʼєктів-служб між середовищами за допомогою скриптів або коннекторів, які посилаються на глобально унікальні ідентифікатори.

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

Призначення власників забезпечує делеговане адміністративне керування субʼєктом-службою: власники можуть керувати обліковими даними та дозволами. Використовуйте рольовий доступ і кількох власників для безперервності бізнесу, аудитуйте зміни власників і не призначайте права власника обліковим записам користувачів, не пов’язаним із довгостроковою ідентичністю. Краще обирати команду або обліковий запис служби, обмежений політикою.

Як синхронізація та міркування щодо клієнта або каталогу впливають на субʼєкти-служби?

Сценарії синхронізації, наприклад синхронізація корпоративних застосунків або ідентичностей між клієнтами, можуть створювати субʼєкти-служби в цільових клієнтах. Визначте, чи є застосунок однокористувацьким (single-tenant) чи багатокористувацьким (multi-tenant), домашній клієнт, де було зареєстровано застосунок, і чи повинен користувач із цього клієнта надати згоду. Плануйте синхронізацію так, щоб уникнути дублювання субʼєктів-служб, і використовуйте фільтрацію для виключення непотрібних обʼєктів.

Коли варто використовувати керовану ідентичність замість створеного субʼєкта-служби?

Використовуйте керовані ідентичності, коли робоче навантаження працює в Azure і може скористатися керованою платформою ідентичністю для отримання токенів без вбудованих облікових даних. Керовані ідентичності зменшують потребу в керуванні паролями, спрощують оновлення безпеки й є рекомендованим варіантом для захисту субʼєктів-служб у сценаріях Microsoft, де це підтримується.

Як аудитувати та усувати несправності доступу до ресурсів, захищених субʼєктами-службами?

Увімкніть і переглядайте журнали входу та журнали аудиту в Microsoft Entra ID і Azure AD, використовуйте Microsoft Graph для отримання подій, застосовуйте фільтри для звуження результатів і інтегруйте журнали з SIEM. Для технічної підтримки або складних проблем зберіть objectId і appId субʼєкта-служби, мітки часу та повідомлення про помилки, перш ніж звертатися до підтримки, а також скористайтеся Microsoft Learn і додатковими ресурсами для розслідування.