Модуль 3.1: Microsoft Entra ID та Azure RBAC

Складність: [MEDIUM] | Час на виконання: 2.5 год | Передумови: Cloud Native 101

Чому цей модуль важливий

У березні 2021 року дослідник з безпеки виявив, що неправильно налаштований додаток Azure Active Directory в одній із компаній Fortune 500 відкрив доступ до поштових скриньок та файлів SharePoint понад 16 000 співробітників. Додаток був зареєстрований роками раніше підрядником, який давно пішов з компанії. Ніхто не відкликав дозволи, бо ніхто не знав про його існування. Секрет додатка потрапив у публічний репозиторій GitHub, і зловмисник місяцями читав листування керівництва. Збитки склали понад $30 мільйонів.

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

У цьому модулі ви дізнаєтеся, як працює Microsoft Entra ID (раніше Azure Active Directory) як хребет ідентифікації Azure. Ви зрозумієте ієрархію Management Groups та Subscriptions. Ви навчитеся відрізняти ролі Entra ID від ролей Azure RBAC — різниця, на якій помиляються навіть досвідчені інженери. І ви опануєте Managed Identities, які дозволяють вашим додаткам працювати взагалі без паролів та ключів.

Фундамент ідентифікації: Microsoft Entra ID

Microsoft Entra ID (все ще часто згадується як Azure AD) — це хмарний сервіс управління ідентифікацією та доступом. Це “вишибала” на дверях Azure.

Tenant (Тенент): Ваша межа ідентифікації

Тенент — це виділений екземпляр Entra ID вашої організації. Це ваша квартира у величезному будинку. Ви ділите інфраструктуру з іншими, але ваша квартира ізольована — ніхто інший не бачить ваших користувачів чи груп.

Ієрархія ресурсів Azure

Azure організовує ресурси на чотирьох рівнях. Доступ успадковується зверху вниз.

Management Groups: Для управління багатьма підписками (групування за департаментами).
Subscriptions (Підписки): Межа для білінгу та контролю доступу.
Resource Groups (Групи ресурсів): Логічний контейнер. Якщо ви видаляєте групу — видаляються ВСІ ресурси всередині.
Resources: Самі сервіси (ВМ, БД, мережі).

Типи ідентифікаторів

Користувачі: Люди, які входять у систему.
Групи: Для спрощення доступу (надавайте права групі, а не людям).
Service Principals: Ідентичність для додатків (як сервісні акаунти в інших хмарах).
Managed Identities: Найкращий спосіб. Azure сам керує паролями та ротацією ключів для ваших ВМ або Kubernetes подів. Ви їх навіть не бачите.

Azure RBAC vs Entra ID Roles: Велика плутанина

Це місце, де найчастіше виникають помилки:

Entra ID Roles: Керують самим сервісом ідентифікації (хто може створювати користувачів, міняти паролі). Напр. Global Administrator.
Azure RBAC Roles: Керують ресурсами Azure (хто може створювати ВМ, читати дані). Напр. Owner, Contributor, Reader.

Важливо: Global Administrator НЕ має автоматично прав на видалення віртуальних машин у вашій підписці. Він має спочатку “підняти” свої права.

Типові помилки

Помилка	Чому це стається	Як виправити
Паролі в коді додатка	”Так простіше підключитися”	Використовуйте Managed Identities; додаток отримає доступ автоматично
Права `Owner` для всіх	Contributor здається недостатнім	Використовуйте принцип найменших привілеїв; краще створити Custom Role
Плутанина ролей	Entra ID vs RBAC	Запам’ятайте: Entra ID = люди/групи, RBAC = сервери/мережі
Окремі права кожному юзеру	Швидше зробити прямо зараз	Завжди надавайте права групам, а не окремим користувачам

Тест

1. Що станеться з Managed Identity (system-assigned), якщо видалити віртуальну машину, до якої вона прикріплена?

Вона буде видалена автоматично разом із машиною. Це головна перевага system-assigned ідентичностей — вони не залишають “сміття” в системі.

2. Чи може користувач із роллю Reader на рівні підписки видалити базу даних у конкретній Resource Group?

Ні. Оскільки права успадковуються зверху вниз, роль Reader на рівні підписки забороняє будь-які зміни в усій підписці, включаючи всі групи ресурсів.

Практична вправа: Права доступу

Створіть групу ресурсів lab-identity.
Створіть Managed Identity (user-assigned).
Надайте їй роль Storage Blob Data Reader на конкретний бакет (Storage Account).
Приєднайте цю ідентичність до віртуальної машини.
Перевірте, чи може машина читати файли без використання логіна та пароля.

Наступний модуль

Переходьте до Модуля 3.2: Віртуальні мережі (VNet) — ви навчитеся будувати мережевий фундамент Azure, налаштовувати файрволи (NSG) та з’єднувати мережі через піринг.