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 (багато ресурсів). Для керованих ідентичностей, призначених користувачем, ідентичність управляється окремо від ресурсів, які її використовують.
Ролі та дозволи
Ролі призначаються принципалам на області: principal -[HAS ROLE]->(scope)
Ролі, призначені групам, успадковуються всіма членами групи.
Залежно від області, до якої була призначена роль, роль може бути успадкована до інших ресурсів всередині контейнера області. Наприклад, якщо користувач A має роль на підписці, він матиме цю роль на всіх групах ресурсів всередині підписки та на всіх ресурсах всередині групи ресурсів.
Класичні ролі
Вбудовані ролі
З документації: Контроль доступу на основі ролей Azure (Azure RBAC) має кілька вбудованих ролей Azure, які ви можете призначити користувачам, групам, службовим принципалам та керованим ідентичностям. Призначення ролей - це спосіб контролювати доступ до ресурсів Azure. Якщо вбудовані ролі не відповідають конкретним потребам вашої організації, ви можете створити свої власні кастомні ролі Azure.
Вбудовані ролі застосовуються лише до ресурсів, для яких вони призначені, наприклад, перевірте ці 2 приклади вбудованих ролей для ресурсів обчислення:
Ці ролі також можуть призначатися над логічними контейнерами (такими як групи управління, підписки та групи ресурсів), і принципали, на яких це вплине, матимуть їх над ресурсами всередині цих контейнерів.
Знайдіть тут список з усіма вбудованими ролями 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. Це допомагає в організації та легкому ідентифікуванні ресурсів на основі їхніх імен, що корисно в великих середовищах.
Обмеження певних типів ресурсів: Ця політика може обмежити створення певних типів ресурсів. Наприклад, політика може бути встановлена, щоб запобігти створенню дорогих типів ресурсів, таких як певні розміри VM, для контролю витрат.
Забезпечення політик тегування: Теги - це пари ключ-значення, пов'язані з ресурсами Azure, які використовуються для управління ресурсами. Політики можуть забезпечувати, щоб певні теги були присутні, або мали конкретні значення, для всіх ресурсів. Це корисно для відстеження витрат, власності або категоризації ресурсів.
Обмеження публічного доступу до ресурсів: Політики можуть забезпечувати, щоб певні ресурси, такі як облікові записи зберігання або бази даних, не мали публічних кінцевих точок, гарантуючи, що вони доступні лише в межах мережі організації.
Автоматичне застосування налаштувань безпеки: Політики можуть використовуватися для автоматичного застосування налаштувань безпеки до ресурсів, таких як застосування конкретної групи безпеки мережі до всіх VM або забезпечення того, щоб усі облікові записи зберігання використовували шифрування.
Зверніть увагу, що політики Azure можуть бути прикріплені до будь-якого рівня ієрархії Azure, але вони зазвичай використовуються в кореневій групі управління або в інших групах управління.
Область дозволів
У Azure дозволи можуть бути призначені будь-якій частині ієрархії. Це включає групи управління, підписки, групи ресурсів та окремі ресурси. Дозволи успадковуються від вміщених ресурсів сутності, до якої вони були призначені.
Ця ієрархічна структура дозволяє ефективно та масштабовано управляти дозволами доступу.
Azure RBAC vs ABAC
RBAC (контроль доступу на основі ролей) - це те, що ми вже бачили в попередніх розділах: Призначення ролі принципалу для надання йому доступу до ресурсу. Однак у деяких випадках ви можете захотіти надати більш детальне управління доступом або спростити управління сотнями призначень ролей.
Azure ABAC (контроль доступу на основі атрибутів) базується на Azure RBAC, додаючи умови призначення ролей на основі атрибутів у контексті конкретних дій. Умова призначення ролі є додатковою перевіркою, яку ви можете за бажанням додати до свого призначення ролі, щоб забезпечити більш детальний контроль доступу. Умова фільтрує дозволи, надані як частина визначення ролі та призначення ролі. Наприклад, ви можете додати умову, яка вимагає, щоб об'єкт мав певний тег для його читання. Ви не можете явно заборонити доступ до конкретних ресурсів за допомогою умов.
Дозволи за замовчуванням для користувачів
Звичайний користувач матиме деякі дозволи за замовчуванням для перерахування деяких частин AzureAD:
Читати всіх користувачів, групи, програми, пристрої, ролі, підписки та їхні публічні властивості
Запрошувати гостей (може бути вимкнено)
Створювати групи безпеки
Читати неприховані членства груп
Додавати гостей до власних груп
Створювати нові програми (може бути вимкнено)
Додавати до 50 пристроїв до Azure (може бути вимкнено)
Ви можете переглянути повний список дозволів за замовчуванням для користувачів у документації. Більше того, зверніть увагу, що в цьому списку ви також можете побачити список дозволів за замовчуванням для гостей.
Пам'ятайте, що для перерахування ресурсів Azure користувачеві потрібен явний дозвіл.
Управління привілейованими ідентичностями (PIM)
Управління привілейованими ідентичностями (PIM) в Azure - це інструмент, який управляє, контролює та моніторить привілейований доступ в Azure Active Directory та Azure. Він підвищує безпеку, надаючи доступ з обмеженим часом та за запитом, забезпечуючи робочі процеси затвердження та вимагаючи додаткову аутентифікацію. Цей підхід мінімізує ризик несанкціонованого доступу, гарантуючи, що підвищені дозволи надаються лише тоді, коли це необхідно, і на конкретний період.
Токени аутентифікації
Існує три типи токенів, що використовуються в OIDC:
Токени доступу: Клієнт представляє цей токен серверу ресурсів для доступу до ресурсів. Він може використовуватися лише для конкретної комбінації користувача, клієнта та ресурсу і не може бути відкликаний до закінчення терміну дії - це 1 година за замовчуванням. Виявлення цього токена є низьким.
ID токени: Клієнт отримує цей токен від сервера авторизації. Він містить основну інформацію про користувача. Він прив'язаний до конкретної комбінації користувача та клієнта.
Токени оновлення: Надаються клієнту разом з токеном доступу. Використовуються для отримання нових токенів доступу та ID токенів. Він прив'язаний до конкретної комбінації користувача та клієнта і може бути відкликаний. За замовчуванням термін дії 90 днів для неактивних токенів оновлення та без терміну дії для активних токенів.
Інформація для умовного доступу зберігається всередині JWT. Тому, якщо ви запитуєте токен з дозволеної IP-адреси, ця IP-адреса буде збережена в токені, і тоді ви зможете використовувати цей токен з недозволеної IP-адреси для доступу до ресурсів.
Перегляньте наступну сторінку, щоб дізнатися різні способи запиту токенів доступу та входу з ними:
Найпоширеніші кінцеві точки API:
Azure Resource Manager (ARM): management.azure.com
Microsoft Graph: graph.microsoft.com (Azure AD Graph, який застарів, - це graph.windows.net)
Посилання
Last updated
