mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-12 13:05:19 -08:00
Translated ['src/pentesting-cloud/azure-security/az-basic-information/RE
This commit is contained in:
Translator
@@ -10,20 +10,20 @@
|
||||
|
||||
- Вона може містити **інші групи управління або підписки**.
|
||||
- Це дозволяє **застосовувати контроль управління** такі як RBAC та Azure Policy один раз на рівні групи управління і мати їх **успадкованими** всіма підписками в групі.
|
||||
- **10,000 груп управління** можуть підтримуватися в одному каталозі.
|
||||
- **10,000 груп** управління можуть підтримуватися в одному каталозі.
|
||||
- Дерево груп управління може підтримувати **до шести рівнів глибини**. Це обмеження не включає кореневий рівень або рівень підписки.
|
||||
- Кожна група управління та підписка можуть підтримувати **тільки одного батька**.
|
||||
- Навіть якщо кілька груп управління можуть бути створені, **існує лише 1 коренева група управління**.
|
||||
- Коренева група управління **містить** всі **інші групи управління та підписки** і **не може бути переміщена або видалена**.
|
||||
- Всі підписки в межах однієї групи управління повинні довіряти **одному й тому ж Entra ID орендарю.**
|
||||
- Всі підписки в межах однієї групи управління повинні довіряти **одному й тому ж орендарю Entra ID.**
|
||||
|
||||
<figure><img src="../../../images/image (147).png" alt=""><figcaption><p><a href="https://td-mainsite-cdn.tutorialsdojo.com/wp-content/uploads/2023/02/managementgroups-768x474.png">https://td-mainsite-cdn.tutorialsdojo.com/wp-content/uploads/2023/02/managementgroups-768x474.png</a></p></figcaption></figure>
|
||||
|
||||
### Azure Підписки
|
||||
### Підписки Azure
|
||||
|
||||
- Це ще один **логічний контейнер, де можуть бути запущені ресурси** (VMs, DBs…) і за які буде виставлено рахунок.
|
||||
- Це ще один **логічний контейнер, де можуть бути запущені ресурси** (VM, БД…) і за які буде виставлено рахунок.
|
||||
- Його **батьком** завжди є **група управління** (і це може бути коренева група управління), оскільки підписки не можуть містити інші підписки.
|
||||
- Він **довіряє лише одному Entra ID** каталогу.
|
||||
- Він **довіряє лише одному каталогу Entra ID**.
|
||||
- **Дозволи**, застосовані на рівні підписки (або будь-якого з її батьків), **успадковуються** всіма ресурсами всередині підписки.
|
||||
|
||||
### Групи ресурсів
|
||||
@@ -34,19 +34,19 @@
|
||||
|
||||
<figure><img src="https://i0.wp.com/azuredays.com/wp-content/uploads/2020/05/org.png?resize=748%2C601&ssl=1" alt=""><figcaption><p><a href="https://i0.wp.com/azuredays.com/wp-content/uploads/2020/05/org.png?resize=748%2C601&ssl=1">https://i0.wp.com/azuredays.com/wp-content/uploads/2020/05/org.png?resize=748%2C601&ssl=1</a></p></figcaption></figure>
|
||||
|
||||
### Azure Resource IDs
|
||||
### Ідентифікатори ресурсів Azure
|
||||
|
||||
Кожен ресурс в Azure має Azure Resource ID, який його ідентифікує.
|
||||
Кожен ресурс в Azure має ідентифікатор ресурсу Azure, який його ідентифікує.
|
||||
|
||||
Формат Azure Resource ID виглядає наступним чином:
|
||||
Формат ідентифікатора ресурсу Azure виглядає наступним чином:
|
||||
|
||||
- `/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{resourceProviderNamespace}/{resourceType}/{resourceName}`
|
||||
|
||||
Для віртуальної машини з ім'ям myVM у групі ресурсів `myResourceGroup` під підпискою ID `12345678-1234-1234-1234-123456789012`, Azure Resource ID виглядає так:
|
||||
Для віртуальної машини з назвою myVM у групі ресурсів `myResourceGroup` під підпискою ID `12345678-1234-1234-1234-123456789012`, ідентифікатор ресурсу Azure виглядає так:
|
||||
|
||||
- `/subscriptions/12345678-1234-1234-1234-123456789012/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM`
|
||||
|
||||
## Azure vs Entra ID vs Azure AD Domain Services
|
||||
## Azure vs Entra ID vs Послуги домену Azure AD
|
||||
|
||||
### Azure
|
||||
|
||||
@@ -54,13 +54,13 @@ Azure є комплексною **хмарною обчислювальною п
|
||||
|
||||
### Entra ID (раніше Azure Active Directory)
|
||||
|
||||
Entra ID є хмарною **службою управління ідентифікацією та доступом**, призначеною для обробки аутентифікації, авторизації та контролю доступу користувачів. Вона забезпечує безпечний доступ до служб Microsoft, таких як Office 365, Azure та багатьох сторонніх SaaS-додатків. З функціями, такими як єдине входження (SSO), багатофакторна аутентифікація (MFA) та умовні політики доступу серед інших.
|
||||
Entra ID є хмарною **послугою управління ідентифікацією та доступом**, призначеною для обробки аутентифікації, авторизації та контролю доступу користувачів. Вона забезпечує безпечний доступ до послуг Microsoft, таких як Office 365, Azure та багатьох сторонніх SaaS-додатків. З функціями, такими як єдине входження (SSO), багатофакторна аутентифікація (MFA) та умовні політики доступу серед інших.
|
||||
|
||||
### Entra Domain Services (раніше Azure AD DS)
|
||||
### Послуги домену Entra (раніше Azure AD DS)
|
||||
|
||||
Entra Domain Services розширює можливості Entra ID, пропонуючи **керовані доменні служби, сумісні з традиційними середовищами Windows Active Directory**. Вона підтримує застарілі протоколи, такі як LDAP, Kerberos та NTLM, що дозволяє організаціям мігрувати або запускати старі додатки в хмарі без розгортання локальних контролерів домену. Ця служба також підтримує групову політику для централізованого управління, що робить її придатною для сценаріїв, де застарілі або на основі AD навантаження повинні співіснувати з сучасними хмарними середовищами.
|
||||
Послуги домену Entra розширюють можливості Entra ID, пропонуючи **керовані доменні послуги, сумісні з традиційними середовищами Windows Active Directory**. Вони підтримують застарілі протоколи, такі як LDAP, Kerberos та NTLM, що дозволяє організаціям мігрувати або запускати старі додатки в хмарі без розгортання локальних контролерів домену. Ця служба також підтримує групову політику для централізованого управління, що робить її придатною для сценаріїв, де застарілі або на основі AD навантаження повинні співіснувати з сучасними хмарними середовищами.
|
||||
|
||||
## Entra ID Принципали
|
||||
## Принципи Entra ID
|
||||
|
||||
### Користувачі
|
||||
|
||||
@@ -71,11 +71,11 @@ Entra Domain Services розширює можливості Entra ID, пропо
|
||||
- Вказати властивості (ім'я, посада, контактна інформація…)
|
||||
- Тип користувача за замовчуванням - “**член**”
|
||||
- **Зовнішні користувачі**
|
||||
- Вказати електронну пошту для запрошення та відображуване ім'я (може бути не Microsoft електронна пошта)
|
||||
- Вказати електронну пошту для запрошення та відображуване ім'я (може бути електронна пошта не від Microsoft)
|
||||
- Вказати властивості
|
||||
- Тип користувача за замовчуванням - “**Гість**”
|
||||
|
||||
### Стандартні дозволи для членів та гостей
|
||||
### Дефолтні дозволи для членів та гостей
|
||||
|
||||
Ви можете перевірити їх у [https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions](https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions), але серед інших дій член зможе:
|
||||
|
||||
@@ -90,7 +90,7 @@ Entra Domain Services розширює можливості Entra ID, пропо
|
||||
> [!NOTE]
|
||||
> Пам'ятайте, що для перерахунку ресурсів Azure користувачеві потрібен явний дозвіл.
|
||||
|
||||
### Стандартні налаштовувані дозволи для користувачів
|
||||
### Дефолтні налаштовувані дозволи для користувачів
|
||||
|
||||
- **Члени (**[**документи**](https://learn.microsoft.com/en-gb/entra/fundamentals/users-default-permissions#restrict-member-users-default-permissions)**)**
|
||||
- Реєстрація додатків: за замовчуванням **Так**
|
||||
@@ -133,16 +133,16 @@ Entra Domain Services розширює можливості Entra ID, пропо
|
||||
|
||||
### **Службові принципали**
|
||||
|
||||
**Службовий принципал** є **ідентифікацією**, створеною для **використання** з **додатками**, хостинговими службами та автоматизованими інструментами для доступу до ресурсів Azure. Цей доступ **обмежений ролями, призначеними** службовому принципалу, що дає вам контроль над **тим, які ресурси можуть бути доступні** і на якому рівні. З міркувань безпеки завжди рекомендується **використовувати службові принципали з автоматизованими інструментами**, а не дозволяти їм входити з ідентифікацією користувача.
|
||||
**Службовий принципал** - це **ідентифікація**, створена для **використання** з **додатками**, хостинговими службами та автоматизованими інструментами для доступу до ресурсів Azure. Цей доступ **обмежений ролями, призначеними** службовому принципалу, що дає вам контроль над **тим, які ресурси можуть бути доступні** і на якому рівні. З міркувань безпеки завжди рекомендується **використовувати службові принципали з автоматизованими інструментами**, а не дозволяти їм входити з ідентифікацією користувача.
|
||||
|
||||
Можливо **безпосередньо увійти як службовий принципал**, згенерувавши йому **секрет** (пароль), **сертифікат** або надавши **федеративний** доступ до сторонніх платформ (наприклад, Github Actions).
|
||||
Можливо **увійти безпосередньо як службовий принципал**, згенерувавши йому **секрет** (пароль), **сертифікат** або надавши **федеративний** доступ до сторонніх платформ (наприклад, Github Actions).
|
||||
|
||||
- Якщо ви виберете **автентифікацію за паролем** (за замовчуванням), **збережіть згенерований пароль**, оскільки ви не зможете отримати до нього доступ знову.
|
||||
- Якщо ви виберете автентифікацію за сертифікатом, переконайтеся, що **додаток матиме доступ до приватного ключа**.
|
||||
|
||||
### Реєстрації додатків
|
||||
|
||||
**Реєстрація додатка** є конфігурацією, яка дозволяє додатку інтегруватися з Entra ID та виконувати дії.
|
||||
**Реєстрація додатка** - це конфігурація, яка дозволяє додатку інтегруватися з Entra ID та виконувати дії.
|
||||
|
||||
#### Ключові компоненти:
|
||||
|
||||
@@ -150,12 +150,12 @@ Entra Domain Services розширює можливості Entra ID, пропо
|
||||
2. **URI перенаправлення:** URL-адреси, куди Azure AD надсилає відповіді на аутентифікацію.
|
||||
3. **Сертифікати, секрети та федеративні облікові дані:** Можливо згенерувати секрет або сертифікат для входу як службовий принципал додатку або надати федеративний доступ до нього (наприклад, Github Actions).
|
||||
1. Якщо **сертифікат** або **секрет** згенеровано, особа може **увійти як службовий принципал** за допомогою CLI-інструментів, знаючи **ідентифікатор додатка**, **секрет** або **сертифікат** та **орендар** (домен або ID).
|
||||
4. **Дозволи API:** Визначає, до яких ресурсів або API додаток може отримати доступ.
|
||||
5. **Налаштування аутентифікації:** Визначає підтримувані додатком потоки аутентифікації (наприклад, OAuth2, OpenID Connect).
|
||||
4. **Дозволи API:** Визначає, до яких ресурсів або API може отримати доступ додаток.
|
||||
5. **Налаштування аутентифікації:** Визначає підтримувані потоки аутентифікації додатка (наприклад, OAuth2, OpenID Connect).
|
||||
6. **Службовий принципал**: Службовий принципал створюється, коли створюється додаток (якщо це робиться з веб-консолі) або коли він встановлюється в новому орендарі.
|
||||
1. **Службовий принципал** отримає всі запитані дозволи, з якими він був налаштований.
|
||||
|
||||
### Стандартні дозволи на згоду
|
||||
### Дефолтні дозволи на згоду
|
||||
|
||||
**Згода користувачів на додатки**
|
||||
|
||||
@@ -163,7 +163,7 @@ Entra Domain Services розширює можливості Entra ID, пропо
|
||||
- Адміністратор буде потрібен для всіх додатків.
|
||||
- **Дозволити згоду користувачів на додатки від перевірених видавців, для вибраних дозволів (рекомендується)**
|
||||
- Усі користувачі можуть дати згоду на дозволи, класифіковані як "низький вплив", для додатків від перевірених видавців або додатків, зареєстрованих в цій організації.
|
||||
- **Стандартні** дозволи низького впливу (хоча вам потрібно прийняти, щоб додати їх як низькі):
|
||||
- **Дефолтні** дозволи низького впливу (хоча вам потрібно прийняти, щоб додати їх як низькі):
|
||||
- User.Read - увійти та прочитати профіль користувача
|
||||
- offline_access - підтримувати доступ до даних, до яких користувачі надали доступ
|
||||
- openid - увійти користувачів
|
||||
@@ -185,7 +185,7 @@ Entra Domain Services розширює можливості Entra ID, пропо
|
||||
Існує два типи керованих ідентичностей:
|
||||
|
||||
- **Призначена системою**. Деякі служби Azure дозволяють вам **увімкнути керовану ідентичність безпосередньо на екземплярі служби**. Коли ви увімкнете керовану ідентичність, призначену системою, **службовий принципал** створюється в орендарі Entra ID, довіреному підписці, де розташований ресурс. Коли **ресурс** **видаляється**, Azure автоматично **видаляє** **ідентичність** за вас.
|
||||
- **Призначена користувачем**. Також можливо, щоб користувачі генерували керовані ідентичності. Вони створюються всередині групи ресурсів в межах підписки, і службовий принципал буде створений в EntraID, довіреному підписці. Потім ви можете призначити керовану ідентичність одному або **кільком екземплярам** служби Azure (кільком ресурсам). Для керованих ідентичностей, призначених користувачем, **ідентичність управляється окремо від ресурсів, які її використовують**.
|
||||
- **Призначена користувачем**. Також можливо, щоб користувачі генерували керовані ідентичності. Вони створюються всередині групи ресурсів в межах підписки, і службовий принципал буде створено в EntraID, довіреному підписці. Потім ви можете призначити керовану ідентичність одному або **кільком екземплярам** служби Azure (кільком ресурсам). Для керованих ідентичностей, призначених користувачем, **ідентичність управляється окремо від ресурсів, які її використовують**.
|
||||
|
||||
Керовані ідентичності **не генерують вічні облікові дані** (як паролі або сертифікати) для доступу, оскільки службовий принципал, прикріплений до них.
|
||||
|
||||
@@ -193,7 +193,7 @@ Entra Domain Services розширює можливості Entra ID, пропо
|
||||
|
||||
Це просто **таблиця в Azure для фільтрації службових принципалів** та перевірки додатків, які були призначені.
|
||||
|
||||
**Це не ще один тип "додатку",** в Azure немає жодного об'єкта, який є "Підприємницьким додатком", це просто абстракція для перевірки службових принципалів, реєстрацій додатків та керованих ідентичностей.
|
||||
**Це не інший тип "додатку",** в Azure немає жодного об'єкта, який є "підприємницьким додатком", це просто абстракція для перевірки службових принципалів, реєстрацій додатків та керованих ідентичностей.
|
||||
|
||||
### Адміністративні одиниці
|
||||
|
||||
@@ -201,7 +201,7 @@ Entra Domain Services розширює можливості Entra ID, пропо
|
||||
|
||||
Приклад:
|
||||
|
||||
- Сценарій: Компанія хоче, щоб регіональні ІТ-адміністратори управляли лише користувачами у своїй власній області.
|
||||
- Сценарій: Компанія хоче, щоб регіональні ІТ-адміністратори управляли лише користувачами у своєму регіоні.
|
||||
- Реалізація:
|
||||
- Створіть адміністративні одиниці для кожного регіону (наприклад, "Північна Америка AU", "Європа AU").
|
||||
- Заповніть AU користувачами з їхніх відповідних регіонів.
|
||||
@@ -209,8 +209,8 @@ Entra Domain Services розширює можливості Entra ID, пропо
|
||||
- AU підтримують **динамічні членства**
|
||||
- AU **не можуть містити AU**
|
||||
- Призначити адміністративні ролі:
|
||||
- Надати роль "Адміністратор користувачів" регіональному ІТ-персоналу, обмежену до AU їхнього регіону.
|
||||
- Результат: Регіональні ІТ-адміністратори можуть управляти обліковими записами користувачів у межах свого регіону, не впливаючи на інші регіони.
|
||||
- Надати роль "Адміністратор користувачів" регіональному ІТ-персоналу, обмежену AU їхнього регіону.
|
||||
- Результат: Регіональні ІТ-адміністратори можуть управляти обліковими записами користувачів у своєму регіоні, не впливаючи на інші регіони.
|
||||
|
||||
### Ролі Entra ID
|
||||
|
||||
@@ -225,7 +225,7 @@ Entra Domain Services розширює можливості Entra ID, пропо
|
||||
|
||||
**Ролі**, призначені **групам**, **успадковуються** всіма **членами** групи.
|
||||
|
||||
Залежно від обсягу, до якого була призначена роль, **роль** може бути **успадкована** до **інших ресурсів** всередині контейнера обсягу. Наприклад, якщо користувач A має **роль на підписці**, він матиме цю **роль на всіх групах ресурсів** всередині підписки та на **всіх ресурсах** всередині групи ресурсів.
|
||||
Залежно від обсягу, на якому була призначена роль, **роль** може бути **успадкована** до **інших ресурсів** всередині контейнера обсягу. Наприклад, якщо користувач A має **роль на підписці**, він матиме цю **роль на всіх групах ресурсів** всередині підписки та на **всіх ресурсах** всередині групи ресурсів.
|
||||
|
||||
### Класичні ролі
|
||||
|
||||
@@ -237,7 +237,7 @@ Entra Domain Services розширює можливості Entra ID, пропо
|
||||
|
||||
### Вбудовані ролі
|
||||
|
||||
[З документації: ](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles)[Azure рольова модель доступу (Azure RBAC)](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview) має кілька **вбудованих ролей Azure**, які ви можете **призначити** **користувачам, групам, службовим принципалам та керованим ідентичностям**. Призначення ролей - це спосіб контролю **доступу до ресурсів Azure**. Якщо вбудовані ролі не відповідають конкретним потребам вашої організації, ви можете створити свої власні [**кастомні ролі Azure**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)**.**
|
||||
[З документації: ](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles)[Azure role-based access control (Azure RBAC)](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview) має кілька **вбудованих ролей Azure**, які ви можете **призначити** **користувачам, групам, службовим принципалам та керованим ідентичностям**. Призначення ролей - це спосіб контролю **доступу до ресурсів Azure**. Якщо вбудовані ролі не відповідають конкретним потребам вашої організації, ви можете створити свої власні [**кастомні ролі Azure**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)**.**
|
||||
|
||||
**Вбудовані** ролі застосовуються лише до **ресурсів**, для яких вони **призначені**, наприклад, перевірте ці 2 приклади **вбудованих ролей для ресурсів Compute**:
|
||||
|
||||
@@ -259,10 +259,10 @@ Entra Domain Services розширює можливості Entra ID, пропо
|
||||
- Принципал з виключеним дозволом не зможе його використовувати, навіть якщо дозвіл надається в іншому місці
|
||||
- Можливо використовувати шаблони
|
||||
- Використовуваний формат - JSON
|
||||
- `actions` відносяться до дозволів на управлінські операції над ресурсами, такі як створення, оновлення або видалення визначень ресурсів та налаштувань.
|
||||
- `actions` відносяться до дозволів на управлінські операції з ресурсами, такі як створення, оновлення або видалення визначень ресурсів та налаштувань.
|
||||
- `dataActions` - це дозволи на операції з даними в межах ресурсу, що дозволяє вам читати, записувати або видаляти фактичні дані, що містяться в ресурсі.
|
||||
- `notActions` та `notDataActions` використовуються для виключення конкретних дозволів з ролі. Однак **вони не забороняють їх**, якщо інша роль надає їх, принципал матиме їх.
|
||||
- `assignableScopes` - це масив обсягів, в яких роль може бути призначена (такі як групи управління, підписки або групи ресурсів).
|
||||
- `assignableScopes` - це масив обсягів, де роль може бути призначена (такі як групи управління, підписки або групи ресурсів).
|
||||
|
||||
Приклад JSON дозволів для кастомної ролі:
|
||||
```json
|
||||
@@ -294,60 +294,53 @@ Entra Domain Services розширює можливості Entra ID, пропо
|
||||
}
|
||||
}
|
||||
```
|
||||
### Порядок дозволів
|
||||
### Permissions order
|
||||
|
||||
- Щоб **суб'єкт мав доступ до ресурсу**, йому потрібно явно надати роль (будь-яким чином), **яка надає йому це дозволення**.
|
||||
- Явне **заперечення має пріоритет** над роллю, що надає дозволення.
|
||||
- Щоб **принципал мав доступ до ресурсу**, йому потрібно явно надати роль (будь-яким чином), **яка надає йому це право**.
|
||||
- Явне **заперечення має пріоритет** над роллю, що надає це право.
|
||||
|
||||
<figure><img src="../../../images/image (191).png" alt=""><figcaption><p><a href="https://link.springer.com/chapter/10.1007/978-1-4842-7325-8_10">https://link.springer.com/chapter/10.1007/978-1-4842-7325-8_10</a></p></figcaption></figure>
|
||||
|
||||
### Глобальний адміністратор
|
||||
### Global Administrator
|
||||
|
||||
Глобальний адміністратор - це роль з Entra ID, яка надає **повний контроль над орендою Entra ID**. Однак за замовчуванням вона не надає жодних дозволів на ресурси Azure.
|
||||
Global Administrator — це роль з Entra ID, яка надає **повний контроль над орендою Entra ID**. Однак за замовчуванням вона не надає жодних прав на ресурси Azure.
|
||||
|
||||
Користувачі з роллю Глобального адміністратора мають можливість '**підвищити' до ролі адміністратора доступу користувачів Azure в кореневій групі управління**. Таким чином, Глобальні адміністратори можуть керувати доступом у **всіх підписках Azure та групах управління.**\
|
||||
Користувачі з роллю Global Administrator мають можливість '**підвищити' до ролі User Access Administrator Azure в кореневій групі управління**. Таким чином, Global Administrators можуть керувати доступом у **всіх підписках Azure та групах управління.**\
|
||||
Це підвищення можна здійснити в кінці сторінки: [https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/\~/Properties](https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties)
|
||||
|
||||
<figure><img src="../../../images/image (349).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Умови призначення та MFA
|
||||
### Assignments Conditions & MFA
|
||||
|
||||
Згідно з **[документацією](https://learn.microsoft.com/en-us/azure/role-based-access-control/conditions-role-assignments-portal)**: Наразі умови можуть бути додані до вбудованих або користувацьких призначень ролей, які мають **дії з даними блобів або дії з даними черг**.
|
||||
|
||||
Можливо **встановити деякі умови, коли роль призначається** суб'єкту. Загальною умовою є вимога MFA для доступу до деяких дозволів ролі:
|
||||
```bash
|
||||
az role assignment create \
|
||||
--assignee <user-or-service-principal-id> \
|
||||
--role <custom-role-id-or-name> \
|
||||
--scope "/subscriptions/9291ff6e-6afb-430e-82a4-6f04b2d05c7f" \
|
||||
--condition "PrincipalClaims['amr'] contains 'mfa'" \
|
||||
--condition-version 2.0
|
||||
```
|
||||
### Deny Assignments
|
||||
|
||||
Так само, як і призначення ролей, **deny assignments** використовуються для **контролю доступу до ресурсів Azure**. Однак **deny assignments** використовуються для **явного відмовлення в доступі** до ресурсу, навіть якщо користувачу було надано доступ через призначення ролі. **Deny assignments** мають пріоритет над **role assignments**, що означає, що якщо користувачу надано доступ через призначення ролі, але йому також явно відмовлено в доступі через deny assignment, deny assignment матиме пріоритет.
|
||||
Так само, як і призначення ролей, **заперечення** використовуються для **контролю доступу до ресурсів Azure**. Однак **заперечення** використовуються для **явного заперечення доступу** до ресурсу, навіть якщо користувачу було надано доступ через призначення ролі. **Заперечення** мають пріоритет над **призначеннями ролей**, що означає, що якщо користувачу надано доступ через призначення ролі, але йому також явно заперечено доступ через заперечення, заперечення матиме пріоритет.
|
||||
|
||||
Так само, як і призначення ролей, **deny assignments** застосовуються до певного обсягу, що вказує на постраждалі принципали та дозволи, які відмовляються. Більше того, у випадку deny assignments можливо **запобігти успадкуванню відмови** дітьми ресурсів.
|
||||
Так само, як і призначення ролей, **заперечення** застосовуються до певної області, що вказує на постраждалі принципали та права, які заперечуються. Більше того, у випадку заперечень можливо **запобігти успадкуванню заперечення** дітьми ресурсів.
|
||||
|
||||
### Azure Policies
|
||||
|
||||
**Azure Policies** — це правила, які допомагають організаціям забезпечити відповідність їх ресурсів певним стандартам і вимогам. Вони дозволяють вам **забезпечувати або перевіряти налаштування ресурсів в Azure**. Наприклад, ви можете запобігти створенню віртуальних машин в несанкціонованому регіоні або забезпечити, щоб усі ресурси мали певні теги для відстеження.
|
||||
**Azure Policies** — це правила, які допомагають організаціям забезпечити відповідність їх ресурсів певним стандартам і вимогам. Вони дозволяють **забезпечувати або перевіряти налаштування ресурсів в Azure**. Наприклад, ви можете запобігти створенню віртуальних машин в несанкціонованому регіоні або забезпечити, щоб усі ресурси мали певні теги для відстеження.
|
||||
|
||||
Azure Policies є **проактивними**: вони можуть зупинити створення або зміну ресурсів, які не відповідають вимогам. Вони також є **реактивними**, дозволяючи вам знаходити та виправляти існуючі ресурси, які не відповідають вимогам.
|
||||
|
||||
#### **Key Concepts**
|
||||
#### **Ключові концепції**
|
||||
|
||||
1. **Policy Definition**: Правило, написане в JSON, яке вказує, що дозволено або вимагається.
|
||||
2. **Policy Assignment**: Застосування політики до певного обсягу (наприклад, підписка, група ресурсів).
|
||||
3. **Initiatives**: Збірка політик, згрупованих разом для більш широкого застосування.
|
||||
4. **Effect**: Вказує, що відбувається, коли політика спрацьовує (наприклад, "Deny", "Audit" або "Append").
|
||||
1. **Визначення політики**: Правило, написане в JSON, яке вказує, що дозволено або вимагається.
|
||||
2. **Призначення політики**: Застосування політики до певної області (наприклад, підписка, група ресурсів).
|
||||
3. **Ініціативи**: Збірка політик, об'єднаних для більш широкого застосування.
|
||||
4. **Ефект**: Вказує, що відбувається, коли політика спрацьовує (наприклад, "Заперечити", "Аудит" або "Додати").
|
||||
|
||||
**Деякі приклади:**
|
||||
|
||||
1. **Ensuring Compliance with Specific Azure Regions**: Ця політика забезпечує, щоб усі ресурси розгорталися в певних регіонах Azure. Наприклад, компанія може захотіти забезпечити, щоб усі її дані зберігалися в Європі для відповідності GDPR.
|
||||
2. **Enforcing Naming Standards**: Політики можуть забезпечувати дотримання стандартів іменування для ресурсів Azure. Це допомагає в організації та легкому ідентифікуванні ресурсів на основі їхніх імен, що корисно в великих середовищах.
|
||||
3. **Restricting Certain Resource Types**: Ця політика може обмежити створення певних типів ресурсів. Наприклад, політика може бути встановлена для запобігання створенню дорогих типів ресурсів, таких як певні розміри ВМ, для контролю витрат.
|
||||
4. **Enforcing Tagging Policies**: Теги — це пари ключ-значення, пов'язані з ресурсами Azure, які використовуються для управління ресурсами. Політики можуть забезпечувати, щоб певні теги були присутні, або мали певні значення, для всіх ресурсів. Це корисно для відстеження витрат, власності або категоризації ресурсів.
|
||||
5. **Limiting Public Access to Resources**: Політики можуть забезпечувати, щоб певні ресурси, такі як облікові записи зберігання або бази даних, не мали публічних кінцевих точок, забезпечуючи, щоб вони були доступні лише в межах мережі організації.
|
||||
6. **Automatically Applying Security Settings**: Політики можуть використовуватися для автоматичного застосування налаштувань безпеки до ресурсів, таких як застосування певної групи безпеки мережі до всіх ВМ або забезпечення того, щоб усі облікові записи зберігання використовували шифрування.
|
||||
1. **Забезпечення відповідності певним регіонам Azure**: Ця політика забезпечує, щоб усі ресурси розгорталися в певних регіонах Azure. Наприклад, компанія може захотіти, щоб усі її дані зберігалися в Європі для відповідності GDPR.
|
||||
2. **Забезпечення стандартів іменування**: Політики можуть забезпечувати дотримання стандартів іменування для ресурсів Azure. Це допомагає в організації та легкому ідентифікуванні ресурсів за їхніми іменами, що корисно в великих середовищах.
|
||||
3. **Обмеження певних типів ресурсів**: Ця політика може обмежити створення певних типів ресурсів. Наприклад, політика може бути встановлена для запобігання створенню дорогих типів ресурсів, таких як певні розміри ВМ, для контролю витрат.
|
||||
4. **Забезпечення політик тегування**: Теги — це пари ключ-значення, пов'язані з ресурсами Azure, які використовуються для управління ресурсами. Політики можуть забезпечувати, щоб певні теги були присутні або мали певні значення для всіх ресурсів. Це корисно для відстеження витрат, власності або категоризації ресурсів.
|
||||
5. **Обмеження публічного доступу до ресурсів**: Політики можуть забезпечувати, щоб певні ресурси, такі як облікові записи зберігання або бази даних, не мали публічних кінцевих точок, забезпечуючи, щоб вони були доступні лише в межах мережі організації.
|
||||
6. **Автоматичне застосування налаштувань безпеки**: Політики можуть використовуватися для автоматичного застосування налаштувань безпеки до ресурсів, таких як застосування певної групи безпеки мережі до всіх ВМ або забезпечення, щоб усі облікові записи зберігання використовували шифрування.
|
||||
|
||||
Зверніть увагу, що Azure Policies можуть бути прикріплені до будь-якого рівня ієрархії Azure, але вони **зазвичай використовуються в кореневій групі управління** або в інших групах управління.
|
||||
|
||||
@@ -373,7 +366,7 @@ Azure policy json example:
|
||||
|
||||
В Azure **дозволи можуть бути призначені будь-якій частині ієрархії**. Це включає управлінські групи, підписки, групи ресурсів та окремі ресурси. Дозволи **спадкуються** від вміщених **ресурсів** сутності, до якої вони були призначені.
|
||||
|
||||
Ця ієрархічна структура дозволяє ефективно та масштабовано управляти доступом до дозволів.
|
||||
Ця ієрархічна структура дозволяє ефективно та масштабовано управляти дозволами доступу.
|
||||
|
||||
<figure><img src="../../../images/image (26).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@@ -382,7 +375,7 @@ Azure policy json example:
|
||||
**RBAC** (контроль доступу на основі ролей) - це те, що ми вже бачили в попередніх розділах: **Призначення ролі суб'єкту для надання йому доступу** до ресурсу.\
|
||||
Однак у деяких випадках ви можете захотіти надати **більш детальне управління доступом** або **спростити** управління **сотнями** призначень ролей.
|
||||
|
||||
Azure **ABAC** (контроль доступу на основі атрибутів) базується на Azure RBAC, додаючи **умови призначення ролей на основі атрибутів** у контексті конкретних дій. _Умова призначення ролі_ - це **додаткова перевірка, яку ви можете за бажанням додати до свого призначення ролі** для надання більш детального контролю доступу. Умова фільтрує дозволи, надані в рамках визначення ролі та призначення ролі. Наприклад, ви можете **додати умову, яка вимагає, щоб об'єкт мав певний тег для читання об'єкта**.\
|
||||
Azure **ABAC** (контроль доступу на основі атрибутів) базується на Azure RBAC, додаючи **умови призначення ролі на основі атрибутів** у контексті конкретних дій. _Умова призначення ролі_ - це **додаткова перевірка, яку ви можете за бажанням додати до свого призначення ролі** для надання більш детального контролю доступу. Умова фільтрує дозволи, надані в рамках визначення ролі та призначення ролі. Наприклад, ви можете **додати умову, яка вимагає, щоб об'єкт мав певний тег для читання об'єкта**.\
|
||||
Ви **не можете** явно **заборонити** **доступ** до конкретних ресурсів **за допомогою умов**.
|
||||
|
||||
## Посилання
|
||||
|
||||
Reference in New Issue
Block a user