Translated ['src/pentesting-cloud/azure-security/az-basic-information/RE

2026-01-13 05:16:32 -08:00 · 2025-02-10 00:25:55 +00:00
parent 6c7658a707
commit 9c2071c2c3
2 changed files with 81 additions and 80 deletions
--- a/src/pentesting-cloud/azure-security/az-basic-information/README.md
+++ b/src/pentesting-cloud/azure-security/az-basic-information/README.md
@@ -8,22 +8,22 @@

 ### Групи управління

- Вона може містити **інші групи управління або підписки**.
- Це дозволяє **застосовувати контроль управління** такі як RBAC та Azure Policy один раз на рівні групи управління і мати їх **успадкованими** всіма підписками в групі.
- **10,000 груп** управління можуть підтримуватися в одному каталозі.
+- Вони можуть містити **інші групи управління або підписки**.
+- Це дозволяє **застосовувати контроль управління** такі як RBAC та Azure Policy один раз на рівні групи управління, і вони будуть **успадковані** всіма підписками в групі.
+- **10,000 груп управління** можуть підтримуватися в одному каталозі.
 - Дерево груп управління може підтримувати **до шести рівнів глибини**. Це обмеження не включає кореневий рівень або рівень підписки.
 - Кожна група управління та підписка можуть підтримувати **тільки одного батька**.
- Навіть якщо кілька груп управління можуть бути створені, **існує лише 1 коренева група управління**.
+- Навіть якщо можна створити кілька груп управління, **існує лише 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 Підписки

- Це ще один **логічний контейнер, де можуть бути запущені ресурси** (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
+### Azure Resource IDs

-Кожен ресурс в Azure має ідентифікатор ресурсу Azure, який його ідентифікує.
+Кожен ресурс в Azure має Azure Resource ID, який його ідентифікує.

-Формат ідентифікатора ресурсу Azure виглядає наступним чином:
+Формат Azure Resource ID виглядає наступним чином:

 - `/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{resourceProviderNamespace}/{resourceType}/{resourceName}`

-Для віртуальної машини з назвою myVM у групі ресурсів `myResourceGroup` під підпискою ID `12345678-1234-1234-1234-123456789012`, ідентифікатор ресурсу Azure виглядає так:
+Для віртуальної машини з назвою myVM у групі ресурсів `myResourceGroup` під підпискою ID `12345678-1234-1234-1234-123456789012`, Azure Resource ID виглядає так:

 - `/subscriptions/12345678-1234-1234-1234-123456789012/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM`

-## Azure vs Entra ID vs Послуги домену Azure AD
+## Azure vs Entra ID vs Azure AD Domain Services

 ### Azure

@@ -54,11 +54,11 @@ 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 (раніше Azure AD DS)
+### Entra Domain Services (раніше Azure AD DS)

-Послуги домену Entra розширюють можливості Entra ID, пропонуючи **керовані доменні послуги, сумісні з традиційними середовищами Windows Active Directory**. Вони підтримують застарілі протоколи, такі як LDAP, Kerberos та NTLM, що дозволяє організаціям мігрувати або запускати старі додатки в хмарі без розгортання локальних контролерів домену. Ця служба також підтримує групову політику для централізованого управління, що робить її придатною для сценаріїв, де застарілі або на основі AD навантаження повинні співіснувати з сучасними хмарними середовищами.
+Entra Domain Services розширює можливості Entra ID, пропонуючи **керовані доменні служби, сумісні з традиційними середовищами Windows Active Directory**. Вона підтримує застарілі протоколи, такі як LDAP, Kerberos та NTLM, що дозволяє організаціям мігрувати або запускати старі додатки в хмарі без розгортання локальних контролерів домену. Ця служба також підтримує групову політику для централізованого управління, що робить її придатною для сценаріїв, де застарілі або AD-орієнтовані навантаження повинні співіснувати з сучасними хмарними середовищами.

 ## Принципи Entra ID

@@ -71,11 +71,11 @@ 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 ID є хмарною **послугою управління іденти
 > [!NOTE]
 > Пам'ятайте, що для перерахунку ресурсів Azure користувачеві потрібен явний дозвіл.

-### Дефолтні налаштовувані дозволи для користувачів
+### Стандартні налаштовувані дозволи для користувачів

 - **Члени (**[**документи**](https://learn.microsoft.com/en-gb/entra/fundamentals/users-default-permissions#restrict-member-users-default-permissions)**)**
 - Реєстрація додатків: за замовчуванням **Так**
@@ -103,16 +103,16 @@ Entra ID є хмарною **послугою управління іденти
 - Обмежити користувачів від відновлення ключа BitLocker для їхніх власних пристроїв: за замовчуванням Ні (перевірте в налаштуваннях пристрою)
 - Читати інших користувачів: за замовчуванням **Так** (через Microsoft Graph)
 - **Гості**
- **Обмеження доступу для користувачів-гостей**:
+- **Обмеження доступу користувачів-гостей**:
 - **Гості мають такий же доступ, як і члени**.
 - **Гості мають обмежений доступ до властивостей і членств об'єктів каталогу (за замовчуванням)**. Це обмежує доступ гостей лише до їхнього власного профілю користувача за замовчуванням. Доступ до інформації про інших користувачів та групи більше не дозволяється.
- **Доступ гостей обмежений до властивостей і членств їхніх власних об'єктів каталогу** є найбільш обмежувальним.
+- **Доступ користувачів-гостей обмежений до властивостей і членств їхніх власних об'єктів каталогу** є найбільш обмежувальним.
 - **Опції запрошення гостей**:
- **Будь-хто в організації може запрошувати користувачів-гостей, включаючи гостей і неадміністраторів (найбільш інклюзивно) - За замовчуванням**
+- **Будь-хто в організації може запрошувати користувачів-гостей, включаючи гостей і неадміністраторів (найбільш інклюзивно) - за замовчуванням**
 - **Користувачі-члени та користувачі, призначені на конкретні адміністративні ролі, можуть запрошувати користувачів-гостей, включаючи гостей з правами членів**
 - **Тільки користувачі, призначені на конкретні адміністративні ролі, можуть запрошувати користувачів-гостей**
 - **Ніхто в організації не може запрошувати користувачів-гостей, включаючи адміністраторів (найбільш обмежувально)**
- **Зовнішні користувачі можуть залишити**: За замовчуванням **Правда**
+- **Зовнішні користувачі можуть залишити**: за замовчуванням **Правда**
 - Дозволити зовнішнім користувачам залишити організацію

 > [!TIP]
@@ -122,7 +122,7 @@ Entra ID є хмарною **послугою управління іденти

 Є **2 типи груп**:

- **Безпека**: Цей тип групи використовується для надання членам доступу до додатків, ресурсів та призначення ліцензій. Членами можуть бути користувачі, пристрої, службові принципали та інші групи.
+- **Безпекові**: Цей тип групи використовується для надання членам доступу до додатків, ресурсів та призначення ліцензій. Членами можуть бути користувачі, пристрої, службові принципали та інші групи.
 - **Microsoft 365**: Цей тип групи використовується для співпраці, надаючи членам доступ до спільної поштової скриньки, календаря, файлів, сайту SharePoint тощо. Членами групи можуть бути лише користувачі.
 - Це матиме **електронну адресу** з доменом орендаря EntraID.

@@ -135,7 +135,7 @@ Entra ID є хмарною **послугою управління іденти

 **Службовий принципал** - це **ідентифікація**, створена для **використання** з **додатками**, хостинговими службами та автоматизованими інструментами для доступу до ресурсів Azure. Цей доступ **обмежений ролями, призначеними** службовому принципалу, що дає вам контроль над **тим, які ресурси можуть бути доступні** і на якому рівні. З міркувань безпеки завжди рекомендується **використовувати службові принципали з автоматизованими інструментами**, а не дозволяти їм входити з ідентифікацією користувача.

-Можливо **увійти безпосередньо як службовий принципал**, згенерувавши йому **секрет** (пароль), **сертифікат** або надавши **федеративний** доступ до сторонніх платформ (наприклад, Github Actions).
+Можливо **безпосередньо увійти як службовий принципал**, згенерувавши йому **секрет** (пароль), **сертифікат** або надавши **федеративний** доступ до сторонніх платформ (наприклад, Github Actions).

 - Якщо ви виберете **автентифікацію за паролем** (за замовчуванням), **збережіть згенерований пароль**, оскільки ви не зможете отримати до нього доступ знову.
 - Якщо ви виберете автентифікацію за сертифікатом, переконайтеся, що **додаток матиме доступ до приватного ключа**.
@@ -146,16 +146,16 @@ Entra ID є хмарною **послугою управління іденти

 #### Ключові компоненти:

-1. **Ідентифікатор додатка (Client ID):** Унікальний ідентифікатор для вашого додатку в Azure AD.
+1. **Ідентифікатор додатка (Client ID):** Унікальний ідентифікатор для вашого додатка в Azure AD.
 2. **URI перенаправлення:** URL-адреси, куди Azure AD надсилає відповіді на аутентифікацію.
-3. **Сертифікати, секрети та федеративні облікові дані:** Можливо згенерувати секрет або сертифікат для входу як службовий принципал додатку або надати федеративний доступ до нього (наприклад, Github Actions).
+3. **Сертифікати, секрети та федеративні облікові дані:** Можливо згенерувати секрет або сертифікат для входу як службовий принципал додатка або надати федеративний доступ до нього (наприклад, Github Actions).
 1. Якщо **сертифікат** або **секрет** згенеровано, особа може **увійти як службовий принципал** за допомогою CLI-інструментів, знаючи **ідентифікатор додатка**, **секрет** або **сертифікат** та **орендар** (домен або ID).
-4. **Дозволи API:** Визначає, до яких ресурсів або API може отримати доступ додаток.
+4. **Дозволи API:** Визначає, до яких ресурсів або API додаток може отримати доступ.
 5. **Налаштування аутентифікації:** Визначає підтримувані потоки аутентифікації додатка (наприклад, OAuth2, OpenID Connect).
 6. **Службовий принципал**: Службовий принципал створюється, коли створюється додаток (якщо це робиться з веб-консолі) або коли він встановлюється в новому орендарі.
-1. **Службовий принципал** отримає всі запитані дозволи, з якими він був налаштований.
+1. **Службовий принципал** отримає всі запитувані дозволи, з якими він був налаштований.

-### Дефолтні дозволи на згоду
+### Стандартні дозволи на згоду

 **Згода користувачів на додатки**

@@ -163,7 +163,7 @@ Entra ID є хмарною **послугою управління іденти
 - Адміністратор буде потрібен для всіх додатків.
 - **Дозволити згоду користувачів на додатки від перевірених видавців, для вибраних дозволів (рекомендується)**
 - Усі користувачі можуть дати згоду на дозволи, класифіковані як "низький вплив", для додатків від перевірених видавців або додатків, зареєстрованих в цій організації.
- **Дефолтні** дозволи низького впливу (хоча вам потрібно прийняти, щоб додати їх як низькі):
+- **Стандартні** дозволи низького впливу (хоча вам потрібно прийняти, щоб додати їх як низькі):
 - User.Read - увійти та прочитати профіль користувача
 - offline_access - підтримувати доступ до даних, до яких користувачі надали доступ
 - openid - увійти користувачів
@@ -172,13 +172,13 @@ Entra ID є хмарною **послугою управління іденти
 - **Дозволити згоду користувачів на додатки (за замовчуванням)**
 - Усі користувачі можуть дати згоду на будь-який додаток для доступу до даних організації.

-**Запити на згоду адміністратора**: За замовчуванням **Ні**
+**Запити на згоду адміністратора**: за замовчуванням **Ні**

 - Користувачі можуть запитувати згоду адміністратора на додатки, на які вони не можуть дати згоду
 - Якщо **Так**: Можливо вказати Користувачів, Групи та Ролі, які можуть давати згоду на запити
 - Налаштуйте також, чи отримуватимуть користувачі електронні сповіщення та нагадування про закінчення терміну

-### **Керована ідентичність (Метадані)**
+### **Керована ідентичність (метадані)**

 Керовані ідентичності в Azure Active Directory пропонують рішення для **автоматичного управління ідентичністю** додатків. Ці ідентичності використовуються додатками для **підключення** до **ресурсів**, сумісних з аутентифікацією Azure Active Directory (**Azure AD**). Це дозволяє **усунути необхідність жорсткого кодування облікових даних хмари** в коді, оскільки додаток зможе звертатися до **служби метаданих**, щоб отримати дійсний токен для **виконання дій** як вказана керована ідентичність в Azure.

@@ -193,7 +193,7 @@ Entra ID є хмарною **послугою управління іденти

 Це просто **таблиця в Azure для фільтрації службових принципалів** та перевірки додатків, які були призначені.

-**Це не інший тип "додатку",** в Azure немає жодного об'єкта, який є "підприємницьким додатком", це просто абстракція для перевірки службових принципалів, реєстрацій додатків та керованих ідентичностей.
+**Це не ще один тип "додатка",** в Azure немає жодного об'єкта, який є "підприємницьким додатком", це просто абстракція для перевірки службових принципалів, реєстрацій додатків та керованих ідентичностей.

 ### Адміністративні одиниці

@@ -208,58 +208,52 @@ Entra ID є хмарною **послугою управління іденти
 - AU можуть **містити користувачів, групи або пристрої**
 - AU підтримують **динамічні членства**
 - AU **не можуть містити AU**
- Призначити адміністративні ролі:
+- Призначте адміністративні ролі:
 - Надати роль "Адміністратор користувачів" регіональному ІТ-персоналу, обмежену AU їхнього регіону.
 - Результат: Регіональні ІТ-адміністратори можуть управляти обліковими записами користувачів у своєму регіоні, не впливаючи на інші регіони.

-### Ролі Entra ID
+### Ролі та дозволи Entra ID

 - Для управління Entra ID існують деякі **вбудовані ролі**, які можуть бути призначені принципалам Entra ID для управління Entra ID
 - Перевірте ролі в [https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference)
+- Ролі, позначені як **`PRIVILEGED`** EntraID, слід призначати з обережністю, оскільки, як пояснює Microsoft [в документації](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference): Призначення привілейованих ролей можуть призвести до підвищення привілеїв, якщо їх не використовувати безпечно та за призначенням.
 - Найбільш привілейована роль - **Глобальний адміністратор**
- У описі ролі можна побачити її **деталізовані дозволи**
+- Ролі групують **докладні дозволи**, і їх можна знайти в їхніх описах.
+- Можливо **створити користувацькі ролі** з бажаними дозволами. Хоча з якоїсь причини не всі докладні дозволи доступні для адміністраторів для створення користувацьких ролей.
+- Ролі в Entra ID повністю **незалежні** від ролей в Azure. Єдина зв'язок полягає в тому, що принципали з роллю **Глобальний адміністратор** в Entra ID можуть підвищити до ролі **Адміністратор доступу користувачів** в Azure.
+- **Не можливо використовувати підстановочні знаки** в ролях Entra ID.

-## Ролі та дозволи
+## Ролі та дозволи Azure

-**Ролі** призначаються **принципалам** на **обсязі**: `principal -[HAS ROLE]->(scope)`
-
-**Ролі**, призначені **групам**, **успадковуються** всіма **членами** групи.
-
-Залежно від обсягу, на якому була призначена роль, **роль** може бути **успадкована** до **інших ресурсів** всередині контейнера обсягу. Наприклад, якщо користувач A має **роль на підписці**, він матиме цю **роль на всіх групах ресурсів** всередині підписки та на **всіх ресурсах** всередині групи ресурсів.
-
-### Класичні ролі
-
-| **Власник**                  | <ul><li>Повний доступ до всіх ресурсів</li><li>Може управляти доступом для інших користувачів</li></ul> | Усі типи ресурсів |
-| ----------------------------- | ---------------------------------------------------------------------------------------- | ------------------ |
-| **Співробітник**             | <ul><li>Повний доступ до всіх ресурсів</li><li>Не може управляти доступом</li></ul>              | Усі типи ресурсів |
-| **Читач**                    | • Переглядати всі ресурси                                                                     | Усі типи ресурсів |
-| **Адміністратор доступу користувачів** | <ul><li>Переглядати всі ресурси</li><li>Може управляти доступом для інших користувачів</li></ul>           | Усі типи ресурсів |
+- **Ролі** призначаються **принципалам** на **обсязі**: `principal -[HAS ROLE]->(scope)`
+- **Ролі**, призначені **групам**, **успадковуються** всіма **членами** групи.
+- Залежно від обсягу, до якого була призначена роль, **роль** може бути **успадкована** до **інших ресурсів** всередині контейнера обсягу. Наприклад, якщо користувач A має **роль на підписці**, він матиме цю **роль на всіх групах ресурсів** всередині підписки та на **всіх ресурсах** всередині групи ресурсів.

 ### Вбудовані ролі

-[З документації: ](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)**.**
+[З документації: ](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).

 **Вбудовані** ролі застосовуються лише до **ресурсів**, для яких вони **призначені**, наприклад, перевірте ці 2 приклади **вбудованих ролей для ресурсів Compute**:

-| [Читач резервного копіювання диска](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#disk-backup-reader)                 | Надає дозвіл резервному сховищу виконувати резервне копіювання диска.      | 3e5e47e6-65f7-47ef-90b5-e5dd4d455f24 |
+| [Disk Backup Reader](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 |
+| [Virtual Machine User Login](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).

-### Кастомні ролі
+### Користувацькі ролі

 - Також можливо створити [**кастомні ролі**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)
 - Вони створюються всередині обсягу, хоча роль може бути в кількох обсягах (групи управління, підписка та групи ресурсів)
- Можливо налаштувати всі детальні дозволи, які матиме кастомна роль
+- Можливо налаштувати всі докладні дозволи, які матиме кастомна роль
 - Можливо виключити дозволи
 - Принципал з виключеним дозволом не зможе його використовувати, навіть якщо дозвіл надається в іншому місці
- Можливо використовувати шаблони
+- Можливо використовувати підстановочні знаки
 - Використовуваний формат - JSON
- `actions` відносяться до дозволів на управлінські операції з ресурсами, такі як створення, оновлення або видалення визначень ресурсів та налаштувань.
+- `actions` стосуються дозволів на управлінські операції над ресурсами, таких як створення, оновлення або видалення визначень ресурсів і налаштувань.
 - `dataActions` - це дозволи на операції з даними в межах ресурсу, що дозволяє вам читати, записувати або видаляти фактичні дані, що містяться в ресурсі.
 - `notActions` та `notDataActions` використовуються для виключення конкретних дозволів з ролі. Однак **вони не забороняють їх**, якщо інша роль надає їх, принципал матиме їх.
 - `assignableScopes` - це масив обсягів, де роль може бути призначена (такі як групи управління, підписки або групи ресурсів).
@@ -296,14 +290,14 @@ 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

-Global Administrator — це роль з Entra ID, яка надає **повний контроль над орендою Entra ID**. Однак за замовчуванням вона не надає жодних прав на ресурси Azure.
+Global Administrator — це роль з Entra ID, яка надає **повний контроль над орендою Entra ID**. Однак за замовчуванням вона не надає жодних дозволів на ресурси 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)
@@ -318,7 +312,7 @@ Global Administrator — це роль з Entra ID, яка надає **повн

 Так само, як і призначення ролей, **заперечення** використовуються для **контролю доступу до ресурсів Azure**. Однак **заперечення** використовуються для **явного заперечення доступу** до ресурсу, навіть якщо користувачу було надано доступ через призначення ролі. **Заперечення** мають пріоритет над **призначеннями ролей**, що означає, що якщо користувачу надано доступ через призначення ролі, але йому також явно заперечено доступ через заперечення, заперечення матиме пріоритет.

-Так само, як і призначення ролей, **заперечення** застосовуються до певної області, що вказує на постраждалі принципали та права, які заперечуються. Більше того, у випадку заперечень можливо **запобігти успадкуванню заперечення** дітьми ресурсів.
+Так само, як і призначення ролей, **заперечення** застосовуються до певної області, що вказує на постраждалі принципали та дозволи, які заперечуються. Більше того, у випадку заперечень можливо **запобігти успадкуванню заперечення** дітьми ресурсів.

 ### Azure Policies

@@ -326,19 +320,19 @@ Global Administrator — це роль з Entra ID, яка надає **повн

 Azure Policies є **проактивними**: вони можуть зупинити створення або зміну ресурсів, які не відповідають вимогам. Вони також є **реактивними**, дозволяючи вам знаходити та виправляти існуючі ресурси, які не відповідають вимогам.

-#### **Ключові концепції**
+#### **Key Concepts**

-1. **Визначення політики**: Правило, написане в JSON, яке вказує, що дозволено або вимагається.
-2. **Призначення політики**: Застосування політики до певної області (наприклад, підписка, група ресурсів).
-3. **Ініціативи**: Збірка політик, об'єднаних для більш широкого застосування.
-4. **Ефект**: Вказує, що відбувається, коли політика спрацьовує (наприклад, "Заперечити", "Аудит" або "Додати").
+1. **Policy Definition**: Правило, написане в JSON, яке вказує, що дозволено або вимагається.
+2. **Policy Assignment**: Застосування політики до певної області (наприклад, підписка, група ресурсів).
+3. **Initiatives**: Збірка політик, об'єднаних для ширшого застосування.
+4. **Effect**: Вказує, що відбувається, коли політика спрацьовує (наприклад, "Заперечити", "Аудит" або "Додати").

 **Деякі приклади:**

 1. **Забезпечення відповідності певним регіонам Azure**: Ця політика забезпечує, щоб усі ресурси розгорталися в певних регіонах Azure. Наприклад, компанія може захотіти, щоб усі її дані зберігалися в Європі для відповідності GDPR.
-2. **Забезпечення стандартів іменування**: Політики можуть забезпечувати дотримання стандартів іменування для ресурсів Azure. Це допомагає в організації та легкому ідентифікуванні ресурсів за їхніми іменами, що корисно в великих середовищах.
+2. **Забезпечення стандартів найменування**: Політики можуть забезпечувати дотримання стандартів найменування для ресурсів Azure. Це допомагає в організації та легкому ідентифікуванні ресурсів за їхніми назвами, що корисно в великих середовищах.
 3. **Обмеження певних типів ресурсів**: Ця політика може обмежити створення певних типів ресурсів. Наприклад, політика може бути встановлена для запобігання створенню дорогих типів ресурсів, таких як певні розміри ВМ, для контролю витрат.
-4. **Забезпечення політик тегування**: Теги — це пари ключ-значення, пов'язані з ресурсами Azure, які використовуються для управління ресурсами. Політики можуть забезпечувати, щоб певні теги були присутні або мали певні значення для всіх ресурсів. Це корисно для відстеження витрат, власності або категоризації ресурсів.
+4. **Забезпечення політик тегування**: Теги — це пари ключ-значення, пов'язані з ресурсами Azure, які використовуються для управління ресурсами. Політики можуть забезпечувати, щоб певні теги були присутні, або мали певні значення, для всіх ресурсів. Це корисно для відстеження витрат, власності або категоризації ресурсів.
 5. **Обмеження публічного доступу до ресурсів**: Політики можуть забезпечувати, щоб певні ресурси, такі як облікові записи зберігання або бази даних, не мали публічних кінцевих точок, забезпечуючи, щоб вони були доступні лише в межах мережі організації.
 6. **Автоматичне застосування налаштувань безпеки**: Політики можуть використовуватися для автоматичного застосування налаштувань безпеки до ресурсів, таких як застосування певної групи безпеки мережі до всіх ВМ або забезпечення, щоб усі облікові записи зберігання використовували шифрування.