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
@@ -21,9 +21,9 @@
|
||||
|
||||
### Azure Підписки
|
||||
|
||||
- Це ще один **логічний контейнер, де можуть бути запущені ресурси** (VM, DB…) і за які буде виставлено рахунок.
|
||||
- Її **батьком** завжди є **група управління** (і це може бути коренева група управління), оскільки підписки не можуть містити інші підписки.
|
||||
- Вона **довіряє лише одному Entra ID** каталогу.
|
||||
- Це ще один **логічний контейнер, де можуть бути запущені ресурси** (VMs, DBs…) і за які буде виставлено рахунок.
|
||||
- Його **батьком** завжди є **група управління** (і це може бути коренева група управління), оскільки підписки не можуть містити інші підписки.
|
||||
- Він **довіряє лише одному Entra ID** каталогу.
|
||||
- **Дозволи**, застосовані на рівні підписки (або будь-якого з її батьків), **успадковуються** всіма ресурсами всередині підписки.
|
||||
|
||||
### Групи ресурсів
|
||||
@@ -42,7 +42,7 @@
|
||||
|
||||
- `/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 Resource ID виглядає так:
|
||||
|
||||
- `/subscriptions/12345678-1234-1234-1234-123456789012/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM`
|
||||
|
||||
@@ -58,7 +58,7 @@ Entra ID є хмарною **службою управління ідентиф
|
||||
|
||||
### Entra Domain Services (раніше Azure AD DS)
|
||||
|
||||
Entra Domain Services розширює можливості Entra ID, пропонуючи **керовані доменні служби, сумісні з традиційними середовищами Windows Active Directory**. Вона підтримує застарілі протоколи, такі як LDAP, Kerberos та NTLM, що дозволяє організаціям мігрувати або запускати старі додатки в хмарі без розгортання локальних контролерів домену. Ця служба також підтримує групову політику для централізованого управління, що робить її придатною для сценаріїв, де застарілі або AD-орієнтовані навантаження повинні співіснувати з сучасними хмарними середовищами.
|
||||
Entra Domain Services розширює можливості Entra ID, пропонуючи **керовані доменні служби, сумісні з традиційними середовищами Windows Active Directory**. Вона підтримує застарілі протоколи, такі як LDAP, Kerberos та NTLM, що дозволяє організаціям мігрувати або запускати старі додатки в хмарі без розгортання локальних контролерів домену. Ця служба також підтримує групову політику для централізованого управління, що робить її придатною для сценаріїв, де застарілі або на основі AD навантаження повинні співіснувати з сучасними хмарними середовищами.
|
||||
|
||||
## Entra ID Принципали
|
||||
|
||||
@@ -105,10 +105,10 @@ Entra Domain Services розширює можливості Entra ID, пропо
|
||||
- **Гості**
|
||||
- **Обмеження доступу для користувачів-гостей**:
|
||||
- **Гості мають такий же доступ, як і члени**.
|
||||
- **Гості мають обмежений доступ до властивостей та членств об'єктів каталогу (за замовчуванням)**. Це обмежує доступ гостей лише до їхнього власного профілю користувача за замовчуванням. Доступ до інформації про інших користувачів та групи більше не дозволяється.
|
||||
- **Доступ гостей обмежений до властивостей та членств їхніх власних об'єктів каталогу** є найбільш обмежувальним.
|
||||
- **Гості мають обмежений доступ до властивостей і членств об'єктів каталогу (за замовчуванням)**. Це обмежує доступ гостей лише до їхнього власного профілю користувача за замовчуванням. Доступ до інформації про інших користувачів та групи більше не дозволяється.
|
||||
- **Доступ гостей обмежений до властивостей і членств їхніх власних об'єктів каталогу** є найбільш обмежувальним.
|
||||
- **Опції запрошення гостей**:
|
||||
- **Будь-хто в організації може запрошувати користувачів-гостей, включаючи гостей та неадміністраторів (найбільш інклюзивно) - За замовчуванням**
|
||||
- **Будь-хто в організації може запрошувати користувачів-гостей, включаючи гостей і неадміністраторів (найбільш інклюзивно) - За замовчуванням**
|
||||
- **Користувачі-члени та користувачі, призначені на конкретні адміністративні ролі, можуть запрошувати користувачів-гостей, включаючи гостей з правами членів**
|
||||
- **Тільки користувачі, призначені на конкретні адміністративні ролі, можуть запрошувати користувачів-гостей**
|
||||
- **Ніхто в організації не може запрошувати користувачів-гостей, включаючи адміністраторів (найбільш обмежувально)**
|
||||
@@ -133,16 +133,16 @@ Entra Domain Services розширює можливості Entra ID, пропо
|
||||
|
||||
### **Службові принципали**
|
||||
|
||||
**Службовий принципал** - це **ідентифікація**, створена для **використання** з **додатками**, хостинговими службами та автоматизованими інструментами для доступу до ресурсів Azure. Цей доступ **обмежений ролями, призначеними** службовому принципалу, що дає вам контроль над **тим, які ресурси можуть бути доступні** і на якому рівні. З міркувань безпеки завжди рекомендується **використовувати службові принципали з автоматизованими інструментами**, а не дозволяти їм входити з ідентифікацією користувача.
|
||||
**Службовий принципал** є **ідентифікацією**, створеною для **використання** з **додатками**, хостинговими службами та автоматизованими інструментами для доступу до ресурсів Azure. Цей доступ **обмежений ролями, призначеними** службовому принципалу, що дає вам контроль над **тим, які ресурси можуть бути доступні** і на якому рівні. З міркувань безпеки завжди рекомендується **використовувати службові принципали з автоматизованими інструментами**, а не дозволяти їм входити з ідентифікацією користувача.
|
||||
|
||||
Можливо **увійти безпосередньо як службовий принципал**, згенерувавши йому **секрет** (пароль), **сертифікат** або надавши **федеративний** доступ до сторонніх платформ (наприклад, Github Actions).
|
||||
Можливо **безпосередньо увійти як службовий принципал**, згенерувавши йому **секрет** (пароль), **сертифікат** або надавши **федеративний** доступ до сторонніх платформ (наприклад, Github Actions).
|
||||
|
||||
- Якщо ви виберете **автентифікацію за паролем** (за замовчуванням), **збережіть згенерований пароль**, оскільки ви не зможете отримати до нього доступ знову.
|
||||
- Якщо ви виберете автентифікацію за сертифікатом, переконайтеся, що **додаток матиме доступ до приватного ключа**.
|
||||
|
||||
### Реєстрації додатків
|
||||
|
||||
**Реєстрація додатка** - це конфігурація, яка дозволяє додатку інтегруватися з Entra ID та виконувати дії.
|
||||
**Реєстрація додатка** є конфігурацією, яка дозволяє додатку інтегруватися з Entra ID та виконувати дії.
|
||||
|
||||
#### Ключові компоненти:
|
||||
|
||||
@@ -151,9 +151,9 @@ Entra Domain Services розширює можливості Entra ID, пропо
|
||||
3. **Сертифікати, секрети та федеративні облікові дані:** Можливо згенерувати секрет або сертифікат для входу як службовий принципал додатку або надати федеративний доступ до нього (наприклад, Github Actions).
|
||||
1. Якщо **сертифікат** або **секрет** згенеровано, особа може **увійти як службовий принципал** за допомогою CLI-інструментів, знаючи **ідентифікатор додатка**, **секрет** або **сертифікат** та **орендар** (домен або ID).
|
||||
4. **Дозволи API:** Визначає, до яких ресурсів або API додаток може отримати доступ.
|
||||
5. **Налаштування автентифікації:** Визначає підтримувані потоки автентифікації додатку (наприклад, OAuth2, OpenID Connect).
|
||||
5. **Налаштування аутентифікації:** Визначає підтримувані додатком потоки аутентифікації (наприклад, OAuth2, OpenID Connect).
|
||||
6. **Службовий принципал**: Службовий принципал створюється, коли створюється додаток (якщо це робиться з веб-консолі) або коли він встановлюється в новому орендарі.
|
||||
1. **Службовий принципал** отримає всі запитувані дозволи, з якими він був налаштований.
|
||||
1. **Службовий принципал** отримає всі запитані дозволи, з якими він був налаштований.
|
||||
|
||||
### Стандартні дозволи на згоду
|
||||
|
||||
@@ -180,12 +180,12 @@ Entra Domain Services розширює можливості Entra ID, пропо
|
||||
|
||||
### **Керована ідентичність (Метадані)**
|
||||
|
||||
Керовані ідентичності в Azure Active Directory пропонують рішення для **автоматичного управління ідентичністю** додатків. Ці ідентичності використовуються додатками для **підключення** до **ресурсів**, сумісних з автентифікацією Azure Active Directory (**Azure AD**). Це дозволяє **усунути необхідність жорсткого кодування облікових даних хмари** в коді, оскільки додаток зможе звертатися до **служби метаданих**, щоб отримати дійсний токен для **виконання дій** як вказана керована ідентичність в Azure.
|
||||
Керовані ідентичності в Azure Active Directory пропонують рішення для **автоматичного управління ідентичністю** додатків. Ці ідентичності використовуються додатками для **підключення** до **ресурсів**, сумісних з аутентифікацією Azure Active Directory (**Azure AD**). Це дозволяє **усунути необхідність жорсткого кодування облікових даних хмари** в коді, оскільки додаток зможе звертатися до **служби метаданих**, щоб отримати дійсний токен для **виконання дій** як вказана керована ідентичність в Azure.
|
||||
|
||||
Існує два типи керованих ідентичностей:
|
||||
|
||||
- **Призначена системою**. Деякі служби 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 користувачами з їхніх відповідних регіонів.
|
||||
@@ -210,7 +210,7 @@ Entra Domain Services розширює можливості Entra ID, пропо
|
||||
- AU **не можуть містити AU**
|
||||
- Призначити адміністративні ролі:
|
||||
- Надати роль "Адміністратор користувачів" регіональному ІТ-персоналу, обмежену до AU їхнього регіону.
|
||||
- Результат: Регіональні ІТ-адміністратори можуть управляти обліковими записами користувачів у своєму регіоні, не впливаючи на інші регіони.
|
||||
- Результат: Регіональні ІТ-адміністратори можуть управляти обліковими записами користувачів у межах свого регіону, не впливаючи на інші регіони.
|
||||
|
||||
### Ролі Entra ID
|
||||
|
||||
@@ -225,15 +225,15 @@ Entra Domain Services розширює можливості Entra ID, пропо
|
||||
|
||||
**Ролі**, призначені **групам**, **успадковуються** всіма **членами** групи.
|
||||
|
||||
Залежно від обсягу, на який була призначена роль, **роль** може бути **успадкована** до **інших ресурсів** всередині контейнера обсягу. Наприклад, якщо користувач A має **роль на підписці**, він матиме цю **роль на всіх групах ресурсів** всередині підписки та на **всіх ресурсах** всередині групи ресурсів.
|
||||
Залежно від обсягу, до якого була призначена роль, **роль** може бути **успадкована** до **інших ресурсів** всередині контейнера обсягу. Наприклад, якщо користувач A має **роль на підписці**, він матиме цю **роль на всіх групах ресурсів** всередині підписки та на **всіх ресурсах** всередині групи ресурсів.
|
||||
|
||||
### **Класичні ролі**
|
||||
### Класичні ролі
|
||||
|
||||
| **Власник** | <ul><li>Повний доступ до всіх ресурсів</li><li>Може управляти доступом для інших користувачів</li></ul> | Усі типи ресурсів |
|
||||
| ----------------------------- | ---------------------------------------------------------------------------------------- | ------------------ |
|
||||
| **Співробітник** | <ul><li>Повний доступ до всіх ресурсів</li><li>Не може управляти доступом</li></ul> | Усі типи ресурсів |
|
||||
| **Читач** | • Перегляд усіх ресурсів | Усі типи ресурсів |
|
||||
| **Адміністратор доступу користувачів** | <ul><li>Перегляд усіх ресурсів</li><li>Може управляти доступом для інших користувачів</li></ul> | Усі типи ресурсів |
|
||||
| **Читач** | • Переглядати всі ресурси | Усі типи ресурсів |
|
||||
| **Адміністратор доступу користувачів** | <ul><li>Переглядати всі ресурси</li><li>Може управляти доступом для інших користувачів</li></ul> | Усі типи ресурсів |
|
||||
|
||||
### Вбудовані ролі
|
||||
|
||||
@@ -243,9 +243,9 @@ Entra Domain Services розширює можливості Entra ID, пропо
|
||||
|
||||
| [Читач резервного копіювання диска](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#disk-backup-reader) | Надає дозвіл резервному сховищу виконувати резервне копіювання диска. | 3e5e47e6-65f7-47ef-90b5-e5dd4d455f24 |
|
||||
| ----------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | ------------------------------------ |
|
||||
| [Користувач віртуальної машини](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#virtual-machine-user-login) | Перегляд віртуальних машин у порталі та вхід як звичайний користувач. | fb879df8-f326-4884-b1cf-06f3ad86be52 |
|
||||
| [Користувач віртуальної машини](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#virtual-machine-user-login) | Переглядати віртуальні машини в порталі та входити як звичайний користувач. | fb879df8-f326-4884-b1cf-06f3ad86be52 |
|
||||
|
||||
Ці ролі також можуть **призначатися над логічними контейнерами** (такими як групи управління, підписки та групи ресурсів), і принципали, які підпадають під їх дію, матимуть їх **над ресурсами всередині цих контейнерів**.
|
||||
Ці ролі також можуть **призначатися над логічними контейнерами** (такими як групи управління, підписки та групи ресурсів), і принципали, на яких вони впливають, матимуть їх **над ресурсами всередині цих контейнерів**.
|
||||
|
||||
- Знайдіть тут список з [**усіма вбудованими ролями Azure**](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles).
|
||||
- Знайдіть тут список з [**усіма вбудованими ролями Entra ID**](https://learn.microsoft.com/en-us/azure/active-directory/roles/permissions-reference).
|
||||
@@ -259,8 +259,10 @@ Entra Domain Services розширює можливості Entra ID, пропо
|
||||
- Принципал з виключеним дозволом не зможе його використовувати, навіть якщо дозвіл надається в іншому місці
|
||||
- Можливо використовувати шаблони
|
||||
- Використовуваний формат - JSON
|
||||
- `actions` призначені для контролю дій над ресурсом
|
||||
- `dataActions` - це дозволи над даними в об'єкті
|
||||
- `actions` відносяться до дозволів на управлінські операції над ресурсами, такі як створення, оновлення або видалення визначень ресурсів та налаштувань.
|
||||
- `dataActions` - це дозволи на операції з даними в межах ресурсу, що дозволяє вам читати, записувати або видаляти фактичні дані, що містяться в ресурсі.
|
||||
- `notActions` та `notDataActions` використовуються для виключення конкретних дозволів з ролі. Однак **вони не забороняють їх**, якщо інша роль надає їх, принципал матиме їх.
|
||||
- `assignableScopes` - це масив обсягів, в яких роль може бути призначена (такі як групи управління, підписки або групи ресурсів).
|
||||
|
||||
Приклад JSON дозволів для кастомної ролі:
|
||||
```json
|
||||
@@ -295,44 +297,61 @@ Entra Domain Services розширює можливості Entra ID, пропо
|
||||
### Порядок дозволів
|
||||
|
||||
- Щоб **суб'єкт мав доступ до ресурсу**, йому потрібно явно надати роль (будь-яким чином), **яка надає йому це дозволення**.
|
||||
- Явне **призначення ролі заборони має пріоритет** над роллю, що надає дозволення.
|
||||
- Явне **заперечення має пріоритет** над роллю, що надає дозволення.
|
||||
|
||||
<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>
|
||||
|
||||
### Глобальний адміністратор
|
||||
|
||||
Глобальний адміністратор — це роль з Entra ID, яка надає **повний контроль над орендою Entra ID**. Однак за замовчуванням вона не надає жодних дозволів на ресурси Azure.
|
||||
Глобальний адміністратор - це роль з Entra ID, яка надає **повний контроль над орендою Entra ID**. Однак за замовчуванням вона не надає жодних дозволів на ресурси Azure.
|
||||
|
||||
Користувачі з роллю глобального адміністратора мають можливість '**підвищити' до ролі адміністратора доступу користувачів Azure в кореневій групі управління**. Таким чином, глобальні адміністратори можуть керувати доступом у **всіх підписках Azure та групах управління.**\
|
||||
Користувачі з роллю Глобального адміністратора мають можливість '**підвищити' до ролі адміністратора доступу користувачів Azure в кореневій групі управління**. Таким чином, Глобальні адміністратори можуть керувати доступом у **всіх підписках 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>
|
||||
|
||||
### Політики Azure
|
||||
### Умови призначення та MFA
|
||||
|
||||
**Політики Azure** — це правила, які допомагають організаціям забезпечити відповідність їх ресурсів певним стандартам і вимогам. Вони дозволяють вам **забезпечувати або перевіряти налаштування ресурсів в Azure**. Наприклад, ви можете заборонити створення віртуальних машин в несанкціонованому регіоні або забезпечити, щоб усі ресурси мали певні теги для відстеження.
|
||||
Можливо **встановити деякі умови, коли роль призначається** суб'єкту. Загальною умовою є вимога 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
|
||||
|
||||
Політики Azure є **проактивними**: вони можуть зупинити створення або зміну несумісних ресурсів. Вони також є **реактивними**, дозволяючи вам знаходити та виправляти існуючі несумісні ресурси.
|
||||
Так само, як і призначення ролей, **deny assignments** використовуються для **контролю доступу до ресурсів Azure**. Однак **deny assignments** використовуються для **явного відмовлення в доступі** до ресурсу, навіть якщо користувачу було надано доступ через призначення ролі. **Deny assignments** мають пріоритет над **role assignments**, що означає, що якщо користувачу надано доступ через призначення ролі, але йому також явно відмовлено в доступі через deny assignment, deny assignment матиме пріоритет.
|
||||
|
||||
#### **Ключові концепції**
|
||||
Так само, як і призначення ролей, **deny assignments** застосовуються до певного обсягу, що вказує на постраждалі принципали та дозволи, які відмовляються. Більше того, у випадку deny assignments можливо **запобігти успадкуванню відмови** дітьми ресурсів.
|
||||
|
||||
1. **Визначення політики**: Правило, написане в JSON, яке вказує, що дозволено або вимагається.
|
||||
2. **Призначення політики**: Застосування політики до конкретної області (наприклад, підписка, група ресурсів).
|
||||
3. **Ініціативи**: Збірка політик, згрупованих разом для ширшого застосування.
|
||||
4. **Ефект**: Вказує, що відбувається, коли політика спрацьовує (наприклад, "Заборонити", "Аудит" або "Додати").
|
||||
### Azure Policies
|
||||
|
||||
**Azure Policies** — це правила, які допомагають організаціям забезпечити відповідність їх ресурсів певним стандартам і вимогам. Вони дозволяють вам **забезпечувати або перевіряти налаштування ресурсів в Azure**. Наприклад, ви можете запобігти створенню віртуальних машин в несанкціонованому регіоні або забезпечити, щоб усі ресурси мали певні теги для відстеження.
|
||||
|
||||
Azure Policies є **проактивними**: вони можуть зупинити створення або зміну ресурсів, які не відповідають вимогам. Вони також є **реактивними**, дозволяючи вам знаходити та виправляти існуючі ресурси, які не відповідають вимогам.
|
||||
|
||||
#### **Key Concepts**
|
||||
|
||||
1. **Policy Definition**: Правило, написане в JSON, яке вказує, що дозволено або вимагається.
|
||||
2. **Policy Assignment**: Застосування політики до певного обсягу (наприклад, підписка, група ресурсів).
|
||||
3. **Initiatives**: Збірка політик, згрупованих разом для більш широкого застосування.
|
||||
4. **Effect**: Вказує, що відбувається, коли політика спрацьовує (наприклад, "Deny", "Audit" або "Append").
|
||||
|
||||
**Деякі приклади:**
|
||||
|
||||
1. **Забезпечення відповідності певним регіонам Azure**: Ця політика забезпечує, щоб усі ресурси розгорталися в певних регіонах Azure. Наприклад, компанія може захотіти забезпечити, щоб усі її дані зберігалися в Європі для відповідності GDPR.
|
||||
2. **Забезпечення стандартів іменування**: Політики можуть забезпечувати дотримання стандартів іменування для ресурсів Azure. Це допомагає в організації та легкому ідентифікуванні ресурсів за їхніми іменами, що корисно в великих середовищах.
|
||||
3. **Обмеження певних типів ресурсів**: Ця політика може обмежити створення певних типів ресурсів. Наприклад, політика може бути встановлена для заборони створення дорогих типів ресурсів, таких як певні розміри ВМ, для контролю витрат.
|
||||
4. **Забезпечення політик тегування**: Теги — це пари ключ-значення, пов'язані з ресурсами Azure, які використовуються для управління ресурсами. Політики можуть забезпечувати, щоб певні теги були присутні, або мали конкретні значення для всіх ресурсів. Це корисно для відстеження витрат, власності або категоризації ресурсів.
|
||||
5. **Обмеження публічного доступу до ресурсів**: Політики можуть забезпечувати, щоб певні ресурси, такі як облікові записи зберігання або бази даних, не мали публічних кінцевих точок, забезпечуючи їх доступність лише в межах мережі організації.
|
||||
6. **Автоматичне застосування налаштувань безпеки**: Політики можуть використовуватися для автоматичного застосування налаштувань безпеки до ресурсів, таких як застосування конкретної групи безпеки мережі до всіх ВМ або забезпечення того, щоб усі облікові записи зберігання використовували шифрування.
|
||||
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**: Політики можуть використовуватися для автоматичного застосування налаштувань безпеки до ресурсів, таких як застосування певної групи безпеки мережі до всіх ВМ або забезпечення того, щоб усі облікові записи зберігання використовували шифрування.
|
||||
|
||||
Зверніть увагу, що політики Azure можуть бути прикріплені до будь-якого рівня ієрархії Azure, але вони **зазвичай використовуються в кореневій групі управління** або в інших групах управління.
|
||||
Зверніть увагу, що Azure Policies можуть бути прикріплені до будь-якого рівня ієрархії Azure, але вони **зазвичай використовуються в кореневій групі управління** або в інших групах управління.
|
||||
|
||||
Приклад політики Azure json:
|
||||
Azure policy json example:
|
||||
```json
|
||||
{
|
||||
"policyRule": {
|
||||
|
||||
Reference in New Issue
Block a user