Системно призначені та призначені користувачем керовані ідентичності Azure: яку обрати?

By Mirko Peters · 2026-10-26

Порівняйте системно призначені та призначені користувачем керовані ідентичності Azure. Дізнайтеся, який тип ідентичності обрати, щоб зменшити адміністративні витрати та безпечно масштабувати рішення.

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

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

Головне

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

Розуміння основних відмінностей

Коли ви починаєте проєктувати безпечні хмарні застосунки без жорстко закодованих секретів і рядків підключення, потрібно вирішити, як ваші робочі навантаження автентифікуватимуться в Microsoft Entra ID. Azure пропонує два різні види керованих ідентичностей: системно призначені та призначені користувачем. Розуміння того, як вони працюють «під капотом», заощадить вашій інженерній команді безліч годин на усунення несправностей і адміністративне обслуговування.

Як працюють системно призначені ідентичності

Системно призначена керована ідентичність вмикається безпосередньо всередині конкретного ресурсу Azure, наприклад віртуальної машини Azure, App Service або Function App. Уявіть, що вона народжується разом із ресурсом і разом із ним зникає. Коли ви вмикаєте системно призначену ідентичність на віртуальній машині, Azure створює в Microsoft Entra ID ідентичність із точно такою самою назвою, як у цього ресурсу.

Основна перевага такого підходу – простота та зв’язаність з життєвим циклом. Оскільки ідентичність прив’язана до ресурсу, вам не треба турбуватися про «осиротілі» ідентичності, які залишаються у вашому каталозі після виведення віртуальної машини з експлуатації. Якщо ви видаляєте ресурс, Azure автоматично видаляє й ідентичність. Водночас така тісна прив’язка створює архітектурні обмеження, якщо кільком ресурсам потрібні однакові дозволи доступу.

Як працюють ідентичності, призначені користувачем

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

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

Адміністративні витрати та призначення ролей

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

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

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

Архітектурні пастки та граничні випадки

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

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

І навпаки, ідентичності, призначені системою, виявляють свої переваги в двох конкретних сценаріях:

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

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

Висновок

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

Щоб глибше розібратися, як видаються токени, як Azure Key Vault інтегрується без паролів і яких поширених помилок безпеки варто уникати, обов'язково послухайте повний випуск подкасту, де експерти діляться практичними стратегіями.

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

Чи може один ресурс Azure використовувати одночасно ідентичності, призначені системою, та ідентичності, керовані користувачем?

Так. Ресурс Azure, наприклад віртуальна машина або App Service, може мати одну ідентичність, призначену системою, і одну або кілька ідентичностей, керованих користувачем, увімкнених одночасно. Це дає змогу поєднувати індивідуальні та спільні стратегії автентифікації.

Що станеться з ідентичністю, керованою користувачем, коли ресурс Azure, до якого вона приєднана, буде видалено?

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

Чому Microsoft рекомендує ідентичності, керовані користувачем, для більшості сценаріїв із кількома ресурсами?

Microsoft рекомендує ідентичності, керовані користувачем, насамперед для зменшення адміністративного навантаження та розростання призначень ролей. Спільне використання однієї ідентичності кількома обчислювальними ресурсами значно зменшує кількість призначень RBAC, які потрібно створювати та підтримувати.

Чи коштує що-небудь запуск керованих ідентичностей в Azure?

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