Як керовані ідентичності усувають жорстко закодовані паролі в Azure

By Mirko Peters · 2026-08-13

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

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

Ласкаво просимо назад до супутнього блогу нашого подкасту! Якщо ви розробляєте застосунки вже достатньо довго, то, найімовірніше, стикалися з давньою проблемою: як підключити свій код до бази даних, API чи облікового запису хмарного сховища. Раніше розробники вирішували це, розміщуючи рядок підключення, пароль до бази даних або клієнтський секрет безпосередньо у файлі конфігурації, змінній середовища або, що ще гірше, жорстко прописуючи його у вихідному коді в репозиторії. Доки застосунок міг прочитати цей секрет, він міг автентифікуватися і виконувати свою роботу. Але що станеться, якщо цей код випадково буде опубліковано у публічному репозиторії GitHub? Що станеться, якщо незадоволений співробітник піде з компанії або зловмисник отримає доступ на читання до налаштувань вашого застосунку? Ваша вся інфраструктура миттєво опиниться під загрозою. У сучасній хмарній архітектурі такий ризик є неприйнятним. Сьогодні ми детально розглянемо, як керовані ідентичності в Microsoft Azure повністю усувають потребу в жорстко закодованих паролях, замінюючи статичні секрети динамічними короткоживучими маркерами доступу.

Вступ до безпеки хмари та жорстко закодованих секретів

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

Хмарні обчислення повністю зруйнували цей периметр. Наші робочі навантаження тепер охоплюють мультихмарні середовища, локальні дата-центри, SaaS-платформи та розподілені серверлес-функції. У цьому новому світі безпека має слідувати за ідентичністю самого робочого навантаження. Жорстко закодовані секрети — це бомби з відкладеним часом. Вони не оновлюються автоматично, їх надзвичайно складно аудитувати, і вони не залишають жодного запасу для помилки, якщо потраплять у чужі руки. Щоб досягти справжньої безпеки за моделлю Zero Trust, ми маємо повністю відокремити облікові дані від вихідного коду. Нам потрібен механізм автентифікації, за якого застосунки можуть довести, хто вони, без потреби знати чи зберігати пароль.

Розуміння ідентичностей користувачів і ідентичностей робочих навантажень у Entra ID

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

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

Ідентичності робочих навантажень, натомість, представляють програмне забезпечення. Сюди належать застосунки, фонові служби, скрипти автоматизації, Azure Functions, Logic Apps, конвеєри розгортання DevOps і ШІ-агенти. Робочі навантаження не п'ють каву, не клікають на фішингові листи і не можуть пройти інтерактивний запит багатофакторної автентифікації на смартфоні. Їм потрібна неінтерактивна, програмна та безперервна автентифікація. Ставитися до ідентичності робочого навантаження як до ідентичності користувача, призначаючи їй статичний пароль, — одна з найпоширеніших помилок у хмарній архітектурі. Ідентичності робочих навантажень потребують власних спеціалізованих моделей управління, керування життєвим циклом і автоматизованих потоків автентифікації.

Розбираємося з реєстраціями застосунків, субʼєктами служби та керованими ідентичностями

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

Реєстрація застосунку (Application Registration) — це глобальне визначення, або шаблон, вашого застосунку. Коли ви реєструєте застосунок у Microsoft Entra ID, ви створюєте його глобальну ідентичність у межах усієї багатоклієнтської екосистеми. Саме тут визначаються дозволи, які можуть знадобитися застосунку, кінцеві точки автентифікації, які він використовує, і URI, пов’язані з ним. Думайте про реєстрацію застосунку як про шаблон паспорта.

Субʼєкт-служба (Service Principal) — це локальний екземпляр цього застосунку в конкретному клієнті. Якщо застосунок багатоклієнтський, він має одну реєстрацію застосунку в клієнті видавця, але окремий субʼєкт-служба в кожному клієнті клієнта, де його розгорнуто та надано згоду. Саме в субʼєкті-службі адміністратори фактично призначають дозволи, застосовують політики умовного доступу та контролюють, хто може локально отримати доступ до застосунку. Думайте про субʼєкт-службу як про оформлений паспорт, із яким людина фактично в’їжджає в конкретну країну.

Керована ідентичність (Managed Identity) робить цю концепцію ще на крок далі, спеціально для ресурсів, що працюють у Microsoft Azure. Замість того щоб розробник вручну створював реєстрацію застосунку, генерував клієнтський секрет, зберігав цей секрет у змінній середовища та писав код для керування життєвим циклом автентифікації, Azure бере на себе весь процес за лаштунками. Azure створює, керує та автоматично ротує базові облікові дані за вас. Розробнику достатньо вказати ресурсу Azure використовувати його керовану ідентичність, а решту робить Azure.

Як керовані ідентичності усувають паролі та жорстко закодовані облікові дані

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

Коли вашому застосунку потрібен доступ до захищеного ресурсу, наприклад бази даних або API, він не шукає збережений пароль. Натомість застосунок локально звертається до кінцевої точки Azure Instance Metadata Service (IMDS), яка безпечно доступна лише зсередини цього конкретного ресурсу Azure. Базова платформа ресурсу Azure запитує безпосередньо в Microsoft Entra ID короткоживучий JSON Web Token (JWT) від імені застосунку.

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

Інтеграція Azure Key Vault і короткоживучих токенів доступу

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

Замість того щоб жорстко прописувати API-ключ сторонньої служби у вихідному коді, ви зберігаєте цей секрет безпечно всередині Azure Key Vault. Далі ви надаєте керованій ідентичності свого ресурсу Azure дозвіл читати секрети з цього Key Vault за допомогою Azure Role-Based Access Control (RBAC) або політик доступу Key Vault.

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

Захист робочих ідентичностей через мінімальні привілеї та управління

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

Перш за все, неухильно дотримуйтеся принципу найменших привілеїв. Не призначайте робочим ідентичностям широкі ролі учасника чи надмірні дозволи Microsoft Graph лише для того, щоб швидко все запрацювало. Якщо фоновому скрипту автоматизації потрібно лише читати елементи з конкретного контейнера Azure Storage, надайте йому доступ Storage Blob Data Reader саме до цього контейнера — і нічого більше. Якщо така робоча ідентичність колись буде скомпрометована, радіус ураження буде мінімальним.

По-друге, ви маєте постійно контролювати та аудитувати свої робочі ідентичності. Організації часто створюють субʼєкти служби та керовані ідентичності для проєктів доказу концепції, скриптів автоматизації й тимчасових інтеграцій, а потім залишають їх працювати на невизначений термін із високими привілеями. Регулярно проводьте перевірки безпеки, щоб знаходити осиротілі субʼєкти служби, невикористовувані облікові записи автоматизації та застарілі облікові дані. Використання таких функцій, як Microsoft Entra ID Protection, і налаштування надійного журналювання через Azure Monitor гарантує повну видимість того, коли й як ваші робочі ідентичності отримують доступ до середовища.

Вибір правильної стратегії ідентичності для кожного хмарного навантаження

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

Якщо ваш код працює всередині Microsoft Azure — чи то на Azure App Services, Azure Functions, віртуальних машинах, Container Instances або Azure Kubernetes Service — першим вибором завжди має бути керована ідентичність. Можна обрати між керованою ідентичністю, призначеною системою (її життєвий цикл має взаємозв’язок 1:1 із ресурсом Azure) або керованою ідентичністю, призначеною користувачем (її можна створити окремо та призначити кільком ресурсам Azure для зручнішого керування).

Якщо ваш застосунок працює поза Azure — наприклад, на локальних серверах, в AWS або як частина конвеєра CI/CD у GitHub Actions — керовані ідентичності, які надає інфраструктура Azure, не підходять. У таких сценаріях слід використовувати федерацію робочих ідентичностей. Вона дозволяє зовнішнім платформам напряму обмінювати токени з Microsoft Entra ID через довіру OpenID Connect (OIDC), повністю усуваючи потребу керувати, ротувати чи зберігати довгоживучі клієнтські секрети.

Нарешті, для традиційних custom-застосунків підприємства, які потребують автентифікації клієнта, коли ні керовані ідентичності, ні федерація неможливі, перевага завжди має надаватися ретельно керованим сертифікатам, а не довгоживучим клієнтським секретам. Поєднуючи Microsoft Entra Workload Identities, Azure Key Vault, принципи Zero Trust і доступ за принципом найменших привілеїв, ваша організація може повністю позбутися жорстко закодованих паролів і побудувати напрочуд стійку хмарну архітектуру.

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

Жорстко закодовані паролі та статичні рядки підключення — це релікти застарілої епохи в ІТ-безпеці. Прийнявши Microsoft Entra Workload Identities і Azure Managed Identities, ми можемо повністю усунути ризики, пов’язані з вбудованими обліковими даними, захистити наші репозиторії вихідного коду від випадкового витоку та забезпечити суворий доступ за принципом найменших привілеїв до всіх наших хмарно-нативних застосунків. Короткоживучі токени доступу гарантують, що навіть якщо токен буде перехоплено, його термін дії буде надто коротким, щоб завдати тривалої шкоди, і це фундаментально змінює наш підхід від реактивного захисту до проактивного.

Щоб зануритися ще глибше в цю тему та почути практичні поради з впровадження від практиків, обовʼязково послухайте пов’язаний епізод подкасту: Entra Workload Identities - Simply Explained. Слухайте, як ми розбираємо ці концепції ще детальніше, щоб допомогти вам захистити ваші середовища Azure та Microsoft 365 як справжній професіонал!