Az - Basic Information
Ієрархія Організації
Групи Управління
Якщо у вашій організації є багато підписок Azure, вам може знадобитися спосіб ефективно керувати доступом, політиками та відповідністю для цих підписок. Групи управління надають область управління вище підписок.
Зверніть увагу, що в одному каталозі може бути підтримано 10 000 груп управління, а дерево груп управління може підтримувати до шести рівнів глибини.
З документації: Кожному каталозу надається одна верхня група управління, яка називається кореневою групою управління. Коренева група управління вбудована в ієрархію для того, щоб всі групи управління та підписки складалися до неї. Ця коренева група управління дозволяє застосовувати глобальні політики та призначення ролей Azure на рівні каталогу. Глобальному адміністратору Azure AD потрібно підняти себе до ролі адміністратора доступу користувача цієї кореневої групи спочатку. Після підняття доступу адміністратор може призначати будь-яку роль Azure іншим користувачам або групам каталогу для управління ієрархією. Як адміністратор, ви можете призначити власний обліковий запис власником кореневої групи управління.
Кореневу групу управління не можна перемістити або видалити, на відміну від інших груп управління.
Групи управління надають вам управління на рівні підприємства незалежно від типу підписок, які у вас можуть бути. Однак всі підписки в межах однієї групи управління повинні довіряти одному і тому ж Azure Active Directory (Azure AD) тенанту.
Підписки Azure
У Azure підписка служить як логічний контейнер для надання бізнесових або технічних ресурсів. Цей контейнер зберігає деталі ресурсів, таких як віртуальні машини (VM), бази даних та інші. При створенні ресурсу Azure, наприклад, VM, вказується підписка, пов'язана з ним. Ця структура сприяє делегуванню доступу, використовуючи механізми контролю доступу на основі ролей.
Групи ресурсів
З документації: Група ресурсів - це контейнер, який містить пов'язані ресурси для рішення Azure. Група ресурсів може включати всі ресурси для рішення або лише ті ресурси, які ви хочете керувати як групу. Загалом додавайте ресурси, які мають однаковий цикл життя, до однієї групи ресурсів, щоб ви могли легко розгортати, оновлювати та видаляти їх як групу.
Усі ресурси повинні бути в межах групи ресурсів і можуть належати лише до групи, а якщо група ресурсів видаляється, всі ресурси всередині неї також видаляються.
Адміністративні одиниці
З документації: Адміністративні одиниці дозволяють вам розділити вашу організацію на будь-яку одиницю, яку ви хочете, а потім призначити конкретних адміністраторів, які можуть керувати тільки членами цієї одиниці. Наприклад, ви можете використовувати адміністративні одиниці для делегування дозволів адміністраторам кожної школи великого університету, щоб вони могли керувати доступом, керувати користувачами та встановлювати політику тільки в Школі інженерії.
Тільки користувачі, групи та пристрої можуть бути членами адміністративної одиниці.
Отже, адміністративна одиниця буде містити деяких членів, а інші принципали будуть призначені дозволи над тією адміністративною одиницею, які вони можуть використовувати для керування членами адміністративної одиниці.
Azure vs Azure AD vs Azure AD Domain Services
Важливо зауважити, що Azure AD - це сервіс всередині Azure. Azure - це хмарна платформа від Microsoft, тоді як Azure AD - це корпоративний ідентичність сервіс в Azure. Більше того, Azure AD не схожий на Windows Active Directory, це сервіс ідентичності, який працює зовсім по-іншому. Якщо ви хочете запустити Контролер домену в Azure для вашого середовища Windows Active Directory, вам потрібно використовувати Azure AD Domain Services.
Принципали
Azure підтримує різні типи принципалів:
Користувач: Звичайна особа з обліковими даними для доступу.
Група: Група принципалів, які керуються разом. Дозволи, надані групам, успадковуються її членами.
Службовий принципал/Підприємницькі додатки: Це ідентичність, створена для використання з додатками, хостованими сервісами та автоматизованими інструментами для доступу до ресурсів Azure. Цей доступ обмежується ролями, призначеними для службового принципала, що дозволяє вам контролювати які ресурси можна отримати доступ та на якому рівні. З міркувань безпеки завжди рекомендується використовувати службові принципали з автоматизованими інструментами замість дозволу їм увійти під обліковим записом користувача.
При створенні службового принципала ви можете вибрати між аутентифікацією за паролем або аутентифікацією за сертифікатом.
Якщо ви виберете аутентифікацію за паролем (за замовчуванням), збережіть згенерований пароль, оскільки ви не зможете знову отримати до нього доступ.
Якщо ви виберете аутентифікацію за сертифікатом, переконайтеся, що додаток матиме доступ до приватного ключа.
Управліні ідентичність (Метадані облікових даних): Управліні ідентичності в Azure Active Directory пропонують рішення для автоматичного управління ідентичністю додатків. Ці ідентичності використовуються додатками для підключення до ресурсів, сумісних з аутентифікацією Azure Active Directory (Azure AD). Використовуючи управліні ідентичності, додатки можуть захищати токени Azure AD, уникнувши необхідності прямо керувати обліковими даними. Існують два типи управлініх ідентичностей:
Системно призначена. Деякі служби Azure дозволяють вам увімкнути управліні ідентичність безпосередньо на екземплярі служби. Коли ви увімкнете системно призначену управліні ідентичність, ідентичність створюється в Azure AD. Ідентичність пов'язана з циклом життя цього екземпляра служби. Коли ресурс видаляється, Azure автоматично видаляє ідентичність за вас. За дизайном, лише цей ресурс Azure може використовувати цю ідентичність для запиту токенів від Azure AD.
Користувацько призначена. Ви також можете створити управліну ідентичність як окремий ресурс Azure. Ви можете створити користувацьку призначену управліну ідентичність та призначити її одному або **декільком екземплярам служби Azure (декілька ресурсі
Ролі та Дозволи
Ролі призначаються принципалам на обсягу: принципал -[МАЄ РОЛЬ]->(обсяг)
Ролі, призначені групам, успадковуються всіма членами групи.
Залежно від обсягу, до якого була призначена роль, роль може успадковуватися до інших ресурсів всередині контейнера обсягу. Наприклад, якщо користувач A має роль на підписку, він матиме цю роль на всіх групах ресурсів всередині підписки та на всіх ресурсах всередині групи ресурсів.
Класичні Ролі
Власник |
| Всі типи ресурсів |
Учасник |
| Всі типи ресурсів |
Читач | • Перегляд всіх ресурсів | Всі типи ресурсів |
Адміністратор доступу користувача |
| Всі типи ресурсів |
Вбудовані ролі
З документації: Контроль доступу на основі ролей Azure (Azure RBAC) має кілька вбудованих ролей Azure, які можна призначити користувачам, групам, службовим принципалам та керованим ідентифікаторам. Призначення ролей - це спосіб керування доступом до ресурсів Azure. Якщо вбудовані ролі не відповідають конкретним потребам вашої організації, ви можете створити свої власні ролі Azure.
Вбудовані ролі застосовуються тільки до ресурсів, для яких вони призначені, наприклад, перевірте ці 2 приклади вбудованих ролей для ресурсів обчислення:
Надає дозвіл на резервне копіювання диска в сховище. | 3e5e47e6-65f7-47ef-90b5-e5dd4d455f24 | |
Перегляд віртуальних машин у порталі та вхід як звичайний користувач. | fb879df8-f326-4884-b1cf-06f3ad86be52 |
Ці ролі також можуть бути призначені для логічних контейнерів (таких як групи управління, підписки та групи ресурсів), і принципали, яких це стосується, матимуть їх для ресурсів всередині цих контейнерів.
Ознайомтеся зі списком всіх вбудованих ролей Azure.
Ознайомтеся зі списком всіх вбудованих ролей Azure AD.
Власні Ролі
Azure також дозволяє створювати власні ролі з необхідними дозволами користувача.
Відмова в Доступі
Для того, щоб принципал мав доступ до ресурсу, йому потрібно явно надати роль (в будь-якому випадку), надаючи йому цей дозвіл.
Явне призначення ролі відмови має пріоритет над роллю, що надає дозвіл.
Глобальний Адміністратор
Користувачі з роллю Глобального Адміністратора мають можливість 'підняти' роль Azure Адміністратора доступу користувача до кореневої групи управління. Це означає, що Глобальний Адміністратор зможе керувати доступом до всіх підписок Azure та груп управління. Це підняття можна зробити на цій сторінці: https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties
Політики Azure
Політики Azure - це набір правил і регуляцій в Microsoft Azure, хмарному обчислювальному сервісі, які допомагають керувати та забезпечувати дотримання організаційних стандартів та оцінювати відповідність на шкалі. Ці політики забезпечують дотримання різних правил для ваших ресурсів Azure, забезпечуючи їх відповідність корпоративним стандартам та рівням обслуговування.
Політики Azure є важливими для управління хмарою та безпекою, допомагаючи забезпечити правильне та ефективне використання ресурсів, а також їх відповідність зовнішнім правилам та внутрішнім політикам. Деякі приклади:
Забезпечення Відповідності з Конкретними Регіонами Azure: Ця політика забезпечує, що всі ресурси розгортатимуться в конкретних регіонах Azure. Наприклад, компанія може хотіти забезпечити, що всі її дані зберігаються в Європі для відповідності з GDPR.
Застосування Стандартів Найменування: Політики можуть забезпечувати дотримання конвенцій найменування для ресурсів Azure. Це допомагає в організації та легкому ідентифікуванні ресурсів за їх назвами, що корисно в великих середовищах.
Обмеження Деяких Типів Ресурсів: Ця політика може обмежувати створення певних типів ресурсів. Наприклад, політика може бути встановлена для запобігання створенню дорогих типів ресурсів, наприклад, певних розмірів віртуальних машин, для контролю витрат.
Застосування Політик Міток: Мітки - це пари ключ-значення, пов'язані з ресурсами Azure, які використовуються для управління ресурсами. Політики можуть забезпечувати, що певні мітки повинні бути присутніми або мати конкретні значення для всіх ресурсів. Це корисно для відстеження витрат, власності або категоризації ресурсів.
Обмеження Глобального Доступу до Ресурсів: Політики можуть забезпечувати, що деякі ресурси, такі як облікові записи сховища або бази даних, не мають публічних кінцевих точок, забезпечуючи, що вони доступні лише в мережі організації.
Автоматичне Застосування Налаштувань Безпеки: Політики можуть бути використані для автоматичного застосування налаштувань безпеки до ресурсів, таких як застосування конкретної групи мережевої безпеки до всіх віртуальних машин або забезпечення того, що всі облікові записи сховища використовують шифрування.
Зверніть увагу, що Політики Azure можуть бути призначені для будь-якого рівня ієрархії Azure, але вони зазвичай використовуються в кореневій групі управління або в інших групах управління.
Обсяг Дозволів
У Azure дозволи можуть бути призначені для будь-якої частини ієрархії. Це включає групи управління, підписки, групи ресурсів та окремі ресурси. Дозволи успадковуються від ресурсів, які містяться в сутності, де вони були призначені.
Ця ієрархічна структура дозволяє ефективне та масштабоване управління дозволами на доступ.
Azure RBAC проти ABAC
RBAC (контроль доступу на основі ролей) - це те, що ми вже бачили в попередніх розділах: Призначення ролі принципалу для надання йому доступу до ресурсу. Однак у деяких випадках ви можете хотіти забезпечити більш деталізоване управління доступом або спростити управління сотнями ролей призначень.
Azure ABAC (контроль доступу на основі атрибутів) ґрунтується на Azure RBAC, додавши умови призначення ролей на основі атрибутів в контексті конкретних дій. Умова призначення ролі - це додаткова перевірка, яку ви може додати до свого призначення ролі для забезпечення більш деталізованого контролю доступу. Умова фільтрує надані дозволи як частину визначення ролі та призначення ролі. Наприклад, ви можете додати умову, яка вимагає, щоб об'єкт мав певний тег для читання об'єкта. Ви не можете явно відмовити в доступі до конкретних ресурсів за умовами.
Стандартні дозволи користувача
Базовий користувач матиме деякі стандартні дозволи для переліку деяких частин AzureAD:
Читати всіх користувачів, Групи, Застосунки, Пристрої, Ролі, Підписки та їхні публічні властивості
Запрошувати гостей (може бути вимкнено)
Створювати групи безпеки
Читати несховані членства в групах
Додавати гостей до власних груп
Створювати нові застосунки (може бути вимкнено)
Додавати до Azure до 50 пристроїв (може бути вимкнено)
Ви можете побачити повний список стандартних дозволів користувачів у документації. Крім того, зверніть увагу, що в цьому списку ви також можете побачити список стандартних дозволів гостей.
Пам'ятайте, що для переліку ресурсів Azure користувачеві потрібно явне надання дозволу.
Управління привілегованими ідентичностями (PIM)
Управління привілегованими ідентичностями (PIM) в Azure - це інструмент, який керує, контролює та моніторить привілегований доступ в Azure Active Directory та Azure. Він підвищує безпеку, забезпечуючи привілегований доступ в режимі реального часу та обмеженого часу, застосовуючи робочі процеси схвалення та вимагаючи додаткової аутентифікації. Цей підхід мінімізує ризик несанкціонованого доступу, забезпечуючи, що підвищені дозволи надаються лише тоді, коли це необхідно і на певний час.
Токени аутентифікації
Існує три типи токенів, які використовуються в OIDC:
Токени доступу: Клієнт представляє цей токен серверу ресурсів для доступу до ресурсів. Він може бути використаний лише для конкретної комбінації користувача, клієнта та ресурсу і не може бути відкликаний до закінчення терміну дії - за замовчуванням це 1 година. Використання цього токена має низьку виявність.
Токени ID: Клієнт отримує цей токен від сервера авторизації. Він містить базову інформацію про користувача. Він пов'язаний з конкретною комбінацією користувача та клієнта.
Токени оновлення: Надаються клієнту разом з токеном доступу. Використовується для отримання нових токенів доступу та ID. Він пов'язаний з конкретною комбінацією користувача та клієнта і може бути відкликаний. Термін дії за замовчуванням - 90 днів для неактивних токенів оновлення та безстроково для активних токенів.
Інформація для умовного доступу зберігається всередині JWT. Таким чином, якщо ви запитуєте токен з дозволеної IP-адреси, ця IP-адреса буде збережена в токені, і потім ви зможете використовувати цей токен з недозволеної IP-адреси для доступу до ресурсів.
Перевірте наступну сторінку, щоб дізнатися різні способи запиту токенів доступу та увійти за допомогою них:
pageAz - AzureAD (AAD)Найпоширеніші кінцеві точки API:
Менеджер ресурсів Azure (ARM): management.azure.com
Microsoft Graph: graph.microsoft.com (Azure AD Graph, який застарів, є graph.windows.net)
Посилання
Last updated
