Translated ['src/README.md', 'src/banners/hacktricks-training.md', 'src/

2026-01-12 13:05:19 -08:00 · 2024-12-31 20:42:16 +00:00
parent 4ecda9fe96
commit 92eaf7ce11
245 changed files with 9813 additions and 12533 deletions
--- a/src/pentesting-cloud/azure-security/az-basic-information/README.md
+++ b/src/pentesting-cloud/azure-security/az-basic-information/README.md
@@ -1,376 +1,372 @@
-# Az - Basic Information
+# Az - Основна інформація

 {{#include ../../../banners/hacktricks-training.md}}

-## Organization Hierarchy
+## Ієрархія організації

 <figure><img src="https://lh7-rt.googleusercontent.com/slidesz/AGV_vUcVrh1BpuQXN7RzGqoxrn-4Nm_sjdJU-dDTvshloB7UMQnN1mtH9N94zNiPCzOYAqE9EsJqlboZOj47tQsQktjxszpKvIDPZLs9rgyiObcZCvl7N0ZWztshR0ZddyBYZIAwPIkrEQ=s2048?key=l3Eei079oPmVJuh8lxQYxxrB" alt=""><figcaption><p><a href="https://www.tunecom.be/stg_ba12f/wp-content/uploads/2020/01/VDC-Governance-ManagementGroups-1536x716.png">https://www.tunecom.be/stg_ba12f/wp-content/uploads/2020/01/VDC-Governance-ManagementGroups-1536x716.png</a></p></figcaption></figure>

-### Management Groups
+### Групи управління

- It can contain **other management groups or subscriptions**.
- This allows to **apply governance controls** such as RBAC and Azure Policy once at the management group level and have them **inherited** by all the subscriptions in the group.
- **10,000 management** groups can be supported in a single directory.
- A management group tree can support **up to six levels of depth**. This limit doesn’t include the root level or the subscription level.
- Each management group and subscription can support **only one parent**.
- Even if several management groups can be created **there is only 1 root management group**.
-  - The root management group **contains** all the **other management groups and subscriptions** and **cannot be moved or deleted**.
- All subscriptions within a single management group must trust the **same Entra ID tenant.**
+- Вона може містити **інші групи управління або підписки**.
+- Це дозволяє **застосовувати контроль управління** такі як RBAC та Azure Policy один раз на рівні групи управління і мати їх **успадкованими** всіма підписками в групі.
+- **10,000 груп управління** можуть підтримуватися в одному каталозі.
+- Дерево груп управління може підтримувати **до шести рівнів глибини**. Це обмеження не включає кореневий рівень або рівень підписки.
+- Кожна група управління та підписка можуть підтримувати **тільки одного батька**.
+- Навіть якщо кілька груп управління можуть бути створені, **існує лише 1 коренева група управління**.
+- Коренева група управління **містить** всі **інші групи управління та підписки** і **не може бути переміщена або видалена**.
+- Усі підписки в межах однієї групи управління повинні довіряти **одному й тому ж орендарю 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 Subscriptions
+### Підписки Azure

- It’s another **logical container where resources** (VMs, DBs…) can be run and will be billed.
- Its **parent** is always a **management group** (and it can be the root management group) as subscriptions cannot contain other subscriptions.
- It **trust only one Entra ID** directory
- **Permissions** applied at the subscription level (or any of its parents) are **inherited** to all the resources inside the subscription
+- Це ще один **логічний контейнер, де можуть бути запущені ресурси** (ВМ, БД…) і за які буде виставлено рахунок.
+- Його **батьком** завжди є **група управління** (і це може бути коренева група управління), оскільки підписки не можуть містити інші підписки.
+- Він **довіряє лише одному каталогу Entra ID**
+- **Дозволи**, застосовані на рівні підписки (або будь-якого з її батьків), **успадковуються** всіма ресурсами всередині підписки

-### Resource Groups
+### Групи ресурсів

-[From the docs:](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-python?tabs=macos#what-is-a-resource-group) A resource group is a **container** that holds **related resources** for an Azure solution. The resource group can include all the resources for the solution, or only those **resources that you want to manage as a group**. Generally, add **resources** that share the **same lifecycle** to the same resource group so you can easily deploy, update, and delete them as a group.
+[З документів:](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-python?tabs=macos#what-is-a-resource-group) Група ресурсів є **контейнером**, який містить **пов'язані ресурси** для рішення Azure. Група ресурсів може включати всі ресурси для рішення або лише ті **ресурси, які ви хочете керувати як групою**. Загалом, додавайте **ресурси**, які мають **один життєвий цикл**, до однієї групи ресурсів, щоб ви могли легко розгортати, оновлювати та видаляти їх як групу.

-All the **resources** must be **inside a resource group** and can belong only to a group and if a resource group is deleted, all the resources inside it are also deleted.
+Усі **ресурси** повинні бути **всередині групи ресурсів** і можуть належати лише до однієї групи, і якщо група ресурсів видаляється, всі ресурси всередині неї також видаляються.

 <figure><img src="https://lh7-rt.googleusercontent.com/slidesz/AGV_vUfe8U30iP_vdZCvxX4g8nEPRLoo7v0kmCGkDn1frBPn3_GIoZ7VT2LkdsVQWCnrG_HSYNRRPM-1pSECUkbDAB-9YbUYLzpvKVLDETZS81CHWKYM4fDl3oMo5-yvTMnjdLTS2pz8U67xUTIzBhZ25MFMRkq5koKY=s2048?key=gSyKQr3HTyhvHa28Rf7LVA" alt=""><figcaption><p><a href="https://i0.wp.com/azuredays.com/wp-content/uploads/2020/05/org.png?resize=748%2C601&#x26;ssl=1">https://i0.wp.com/azuredays.com/wp-content/uploads/2020/05/org.png?resize=748%2C601&#x26;ssl=1</a></p></figcaption></figure>

-### Azure Resource IDs
+### Ідентифікатори ресурсів Azure

-Every resource in Azure has an Azure Resource ID that identifies it.
+Кожен ресурс в Azure має ідентифікатор ресурсу Azure, який його ідентифікує.

-The format of an Azure Resource ID is as follows:
+Формат ідентифікатора ресурсу Azure виглядає так:

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

-For a virtual machine named myVM in a resource group `myResourceGroup` under subscription ID `12345678-1234-1234-1234-123456789012`, the Azure Resource ID looks like this:
+Для віртуальної машини з ім'ям 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

-Azure is Microsoft’s comprehensive **cloud computing platform, offering a wide range of services**, including virtual machines, databases, artificial intelligence, and storage. It acts as the foundation for hosting and managing applications, building scalable infrastructures, and running modern workloads in the cloud. Azure provides tools for developers and IT professionals to create, deploy, and manage applications and services seamlessly, catering to a variety of needs from startups to large enterprises.
+Azure є комплексною **хмарною обчислювальною платформою Microsoft, що пропонує широкий спектр послуг**, включаючи віртуальні машини, бази даних, штучний інтелект та зберігання. Вона слугує основою для хостингу та управління додатками, створення масштабованих інфраструктур і виконання сучасних навантажень у хмарі. Azure надає інструменти для розробників та ІТ-фахівців для створення, розгортання та управління додатками та послугами безперешкодно, задовольняючи різноманітні потреби від стартапів до великих підприємств.

-### Entra ID (formerly Azure Active Directory)
+### Entra ID (раніше Azure Active Directory)

-Entra ID is a cloud-based **identity and access management servic**e designed to handle authentication, authorization, and user access control. It powers secure access to Microsoft services such as Office 365, Azure, and many third-party SaaS applications. With features like single sign-on (SSO), multi-factor authentication (MFA), and conditional access policies among others.
+Entra ID є хмарною **послугою управління ідентифікацією та доступом**, призначеною для обробки аутентифікації, авторизації та контролю доступу користувачів. Вона забезпечує безпечний доступ до послуг Microsoft, таких як Office 365, Azure та багатьох сторонніх SaaS-додатків. З функціями, такими як єдине входження (SSO), багатофакторна аутентифікація (MFA) та умовні політики доступу серед інших.

-### Entra Domain Services (formerly Azure AD DS)
+### Послуги домену Entra (раніше Azure AD DS)

-Entra Domain Services extends the capabilities of Entra ID by offering **managed domain services compatible with traditional Windows Active Directory environments**. It supports legacy protocols such as LDAP, Kerberos, and NTLM, allowing organizations to migrate or run older applications in the cloud without deploying on-premises domain controllers. This service also supports Group Policy for centralized management, making it suitable for scenarios where legacy or AD-based workloads need to coexist with modern cloud environments.
+Послуги домену Entra розширюють можливості Entra ID, пропонуючи **керовані доменні послуги, сумісні з традиційними середовищами Windows Active Directory**. Вони підтримують застарілі протоколи, такі як LDAP, Kerberos та NTLM, що дозволяє організаціям мігрувати або запускати старі додатки в хмарі без розгортання локальних контролерів домену. Ця служба також підтримує групову політику для централізованого управління, що робить її придатною для сценаріїв, де застарілі або на основі AD навантаження повинні співіснувати з сучасними хмарними середовищами.

-## Entra ID Principals
+## Принципи Entra ID

-### Users
+### Користувачі

- **New users**
-  - Indicate email name and domain from selected tenant
-  - Indicate Display name
-  - Indicate password
-  - Indicate properties (first name, job title, contact info…)
-    - Default user type is “**member**”
- **External users**
-  - Indicate email to invite and display name (can be a non Microsft email)
-  - Indicate properties
-    - Default user type is “**Guest**”
+- **Нові користувачі**
+- Вказати ім'я електронної пошти та домен з вибраного орендаря
+- Вказати відображуване ім'я
+- Вказати пароль
+- Вказати властивості (ім'я, посада, контактна інформація…)
+- Тип користувача за замовчуванням - “**член**”
+- **Зовнішні користувачі**
+- Вказати електронну пошту для запрошення та відображуване ім'я (може бути не Microsoft електронна пошта)
+- Вказати властивості
+- Тип користувача за замовчуванням - “**Гість**”

-### Members & Guests Default Permissions
+### Дефолтні дозволи для членів та гостей

-You can check them in [https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions](https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions) but among other actions a member will be able to:
+Ви можете перевірити їх у [https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions](https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions), але серед інших дій член зможе:

- Read all users, Groups, Applications, Devices, Roles, Subscriptions, and their public properties
- Invite Guests (_can be turned off_)
- Create Security groups
- Read non-hidden Group memberships
- Add guests to Owned groups
- Create new application (_can be turned off_)
- Add up to 50 devices to Azure (_can be turned off_)
+- Читати всіх користувачів, групи, додатки, пристрої, ролі, підписки та їх публічні властивості
+- Запрошувати гостей (_може бути вимкнено_)
+- Створювати групи безпеки
+- Читати неприховані членства груп
+- Додавати гостей до власних груп
+- Створювати нові додатки (_може бути вимкнено_)
+- Додавати до 50 пристроїв до Azure (_може бути вимкнено_)

 > [!NOTE]
-> Remember that to enumerate Azure resources the user needs an explicit grant of the permission.
+> Пам'ятайте, що для перерахунку ресурсів Azure користувачеві потрібен явний дозвіл.

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

- **Members (**[**docs**](https://learn.microsoft.com/en-gb/entra/fundamentals/users-default-permissions#restrict-member-users-default-permissions)**)**
-  - Register Applications: Default **Yes**
-  - Restrict non-admin users from creating tenants: Default **No**
-  - Create security groups: Default **Yes**
-  - Restrict access to Microsoft Entra administration portal: Default **No**
-    - This doesn’t restrict API access to the portal (only web)
-  - Allow users to connect work or school account with LinkedIn: Default **Yes**
-  - Show keep user signed in: Default **Yes**
-  - Restrict users from recovering the BitLocker key(s) for their owned devices: Default No (check in Device Settings)
-  - Read other users: Default **Yes** (via Microsoft Graph)
- **Guests**
-  - **Guest user access restrictions**
-    - **Guest users have the same access as members** grants all member user permissions to guest users by default.
-    - **Guest users have limited access to properties and memberships of directory objects (default)** restricts guest access to only their own user profile by default. Access to other users and group information is no longer allowed.
-    - **Guest user access is restricted to properties and memberships of their own directory objects** is the most restrictive one.
-  - **Guests can invite**
-    - **Anyone in the organization can invite guest users including guests and non-admins (most inclusive) - Default**
-    - **Member users and users assigned to specific admin roles can invite guest users including guests with member permissions**
-    - **Only users assigned to specific admin roles can invite guest users**
-    - **No one in the organization can invite guest users including admins (most restrictive)**
-  - **External user leave**: Default **True**
-    - Allow external users to leave the organization
+- **Члени (**[**документи**](https://learn.microsoft.com/en-gb/entra/fundamentals/users-default-permissions#restrict-member-users-default-permissions)**)**
+- Реєстрація додатків: За замовчуванням **Так**
+- Обмежити неадміністративним користувачам створення орендарів: За замовчуванням **Ні**
+- Створення груп безпеки: За замовчуванням **Так**
+- Обмежити доступ до порталу адміністрування Microsoft Entra: За замовчуванням **Ні**
+- Це не обмежує доступ API до порталу (тільки веб)
+- Дозволити користувачам підключати робочий або шкільний обліковий запис до LinkedIn: За замовчуванням **Так**
+- Показати, щоб користувач залишався підписаним: За замовчуванням **Так**
+- Обмежити користувачів від відновлення ключа BitLocker для їхніх власних пристроїв: За замовчуванням Ні (перевірте в налаштуваннях пристрою)
+- Читати інших користувачів: За замовчуванням **Так** (через Microsoft Graph)
+- **Гості**
+- **Обмеження доступу для користувачів-гостей**
+- **Користувачі-гості мають такий же доступ, як і члени**, надає всі дозволи користувачів-членів користувачам-гостям за замовчуванням.
+- **Користувачі-гості мають обмежений доступ до властивостей та членств об'єктів каталогу (за замовчуванням)** обмежує доступ гостей лише до їхнього власного профілю користувача за замовчуванням. Доступ до інформації про інших користувачів та групи більше не дозволяється.
+- **Доступ користувачів-гостей обмежений до властивостей та членств їхніх власних об'єктів каталогу** є найобмежувальнішим.
+- **Гості можуть запрошувати**
+- **Будь-хто в організації може запрошувати користувачів-гостей, включаючи гостей та неадміністраторів (найбільш інклюзивно) - За замовчуванням**
+- **Користувачі-члени та користувачі, призначені на конкретні адміністративні ролі, можуть запрошувати користувачів-гостей, включаючи гостей з правами членів**
+- **Тільки користувачі, призначені на конкретні адміністративні ролі, можуть запрошувати користувачів-гостей**
+- **Ніхто в організації не може запрошувати користувачів-гостей, включаючи адміністраторів (найбільш обмежувально)**
+- **Зовнішні користувачі можуть залишити**: За замовчуванням **Правда**
+- Дозволити зовнішнім користувачам залишити організацію

 > [!TIP]
-> Even if restricted by default, users (members and guests) with granted permissions could perform the previous actions.
+> Навіть якщо за замовчуванням обмежено, користувачі (члени та гості) з наданими дозволами можуть виконувати попередні дії.

-### **Groups**
+### **Групи**

-There are **2 types of groups**:
+Є **2 типи груп**:

- **Security**: This type of group is used to give members access to aplications, resources and assign licenses. Users, devices, service principals and other groups an be members.
- **Microsoft 365**: This type of group is used for collaboration, giving members access to a shared mailbox, calendar, files, SharePoint site, and so on. Group members can only be users.
-  - This will have an **email address** with the domain of the EntraID tenant.
+- **Безпека**: Цей тип групи використовується для надання членам доступу до додатків, ресурсів та призначення ліцензій. Користувачі, пристрої, службові принципали та інші групи можуть бути членами.
+- **Microsoft 365**: Цей тип групи використовується для співпраці, надаючи членам доступ до спільної поштової скриньки, календаря, файлів, сайту SharePoint тощо. Членами групи можуть бути лише користувачі.
+- Це матиме **електронну адресу** з доменом орендаря EntraID.

-There are **2 types of memberships**:
+Є **2 типи членств**:

- **Assigned**: Allow to manually add specific members to a group.
- **Dynamic membership**: Automatically manages membership using rules, updating group inclusion when members attributes change.
+- **Призначене**: Дозволяє вручну додавати конкретних членів до групи.
+- **Динамічне членство**: Автоматично керує членством за допомогою правил, оновлюючи включення групи, коли змінюються атрибути членів.

-### **Service Principals**
+### **Службові принципали**

-A **Service Principal** is an **identity** created for **use** with **applications**, hosted services, and automated tools to access Azure resources. This access is **restricted by the roles assigned** to the service principal, giving you control over **which resources can be accessed** and at which level. For security reasons, it's always recommended to **use service principals with automated tools** rather than allowing them to log in with a user identity.
+**Службовий принципал** - це **ідентифікація**, створена для **використання** з **додатками**, хостинговими службами та автоматизованими інструментами для доступу до ресурсів Azure. Цей доступ **обмежений ролями, призначеними** службовому принципалу, що дає вам контроль над **тим, які ресурси можуть бути доступні** і на якому рівні. З міркувань безпеки завжди рекомендується **використовувати службові принципали з автоматизованими інструментами**, а не дозволяти їм входити з ідентифікацією користувача.

-It's possible to **directly login as a service principal** by generating it a **secret** (password), a **certificate**, or granting **federated** access to third party platforms (e.g. Github Actions) over it.
+Можливо **безпосередньо увійти як службовий принципал**, згенерувавши йому **секрет** (пароль), **сертифікат** або надавши **федеративний** доступ до сторонніх платформ (наприклад, Github Actions) через нього.

- If you choose **password** auth (by default), **save the password generated** as you won't be able to access it again.
- If you choose certificate authentication, make sure the **application will have access over the private key**.
+- Якщо ви виберете **автентифікацію за паролем** (за замовчуванням), **збережіть згенерований пароль**, оскільки ви не зможете отримати до нього доступ знову.
+- Якщо ви виберете автентифікацію за сертифікатом, переконайтеся, що **додаток матиме доступ до приватного ключа**.

-### App Registrations
+### Реєстрації додатків

-An **App Registration** is a configuration that allows an application to integrate with Entra ID and to perform actions.
+**Реєстрація додатка** - це конфігурація, яка дозволяє додатку інтегруватися з Entra ID та виконувати дії.

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

-1. **Application ID (Client ID):** A unique identifier for your app in Azure AD.
-2. **Redirect URIs:** URLs where Azure AD sends authentication responses.
-3. **Certificates, Secrets & Federated Credentials:** It's possible to generate a secret or a certificate to login as the service principal of the application, or to grant federated access to it (e.g. Github Actions).&#x20;
-   1. If a **certificate** or **secret** is generated, it's possible to a person to **login as the service principal** with CLI tools by knowing the **application ID**, the **secret** or **certificate** and the **tenant** (domain or ID).
-4. **API Permissions:** Specifies what resources or APIs the app can access.
-5. **Authentication Settings:** Defines the app's supported authentication flows (e.g., OAuth2, OpenID Connect).
-6. **Service Principal**: A service principal is created when an App is created (if it's done from the web console) or when it's installed in a new tenant.
-   1. The **service principal** will get all the requested permissions it was configured with.
+1. **Ідентифікатор додатка (Client ID):** Унікальний ідентифікатор для вашого додатка в Azure AD.
+2. **URI перенаправлення:** URL-адреси, куди Azure AD надсилає відповіді на аутентифікацію.
+3. **Сертифікати, секрети та федеративні облікові дані:** Можливо згенерувати секрет або сертифікат для входу як службовий принципал додатка або надати федеративний доступ до нього (наприклад, Github Actions).&#x20;
+1. Якщо **сертифікат** або **секрет** згенеровано, особа може **увійти як службовий принципал** за допомогою CLI-інструментів, знаючи **ідентифікатор додатка**, **секрет** або **сертифікат** та **орендар** (домен або ID).
+4. **API Дозволи:** Визначає, до яких ресурсів або API додаток може отримати доступ.
+5. **Налаштування автентифікації:** Визначає підтримувані потоки автентифікації додатка (наприклад, OAuth2, OpenID Connect).
+6. **Службовий принципал**: Службовий принципал створюється, коли створюється додаток (якщо це робиться з веб-консолі) або коли він встановлюється в новому орендарі.
+1. **Службовий принципал** отримає всі запитувані дозволи, з якими він був налаштований.

-### Default Consent Permissions
+### Дефолтні дозволи на згоду

-**User consent for applications**
+**Згода користувачів на додатки**

- **Do not allow user consent**
-  - An administrator will be required for all apps.
- **Allow user consent for apps from verified publishers, for selected permissions (Recommended)**
-  - All users can consent for permissions classified as "low impact", for apps from verified publishers or apps registered in this organization.
-  - **Default** low impact permissions (although you need to accept to add them as low):
-    - User.Read - sign in and read user profile
-    - offline_access - maintain access to data that users have given it access to
-    - openid - sign users in
-    - profile - view user's basic profile
-    - email - view user's email address
- **Allow user consent for apps (Default)**
-  - All users can consent for any app to access the organization's data.
+- **Не дозволяти згоду користувачів**
+- Для всіх додатків буде потрібен адміністратор.
+- **Дозволити згоду користувачів на додатки від перевірених видавців, для вибраних дозволів (рекомендується)**
+- Усі користувачі можуть дати згоду на дозволи, класифіковані як "низький вплив", для додатків від перевірених видавців або додатків, зареєстрованих в цій організації.
+- **За замовчуванням** низько впливові дозволи (хоча вам потрібно прийняти, щоб додати їх як низькі):
+- User.Read - увійти та прочитати профіль користувача
+- offline_access - підтримувати доступ до даних, до яких користувачі надали доступ
+- openid - входити користувачів
+- profile - переглядати основний профіль користувача
+- email - переглядати електронну адресу користувача
+- **Дозволити згоду користувачів на додатки (за замовчуванням)**
+- Усі користувачі можуть дати згоду на будь-який додаток для доступу до даних організації.

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

- Users can request admin consent to apps they are unable to consent to
- If **Yes**: It’s possible to indicate Users, Groups and Roles that can consent requests
-  - Configure also if users will receive email notifications and expiration reminders&#x20;
+- Користувачі можуть запитувати згоду адміністратора на додатки, на які вони не можуть дати згоду
+- Якщо **Так**: Можливо вказати Користувачів, Групи та Ролі, які можуть давати згоду на запити
+- Налаштуйте також, чи отримуватимуть користувачі електронні сповіщення та нагадування про закінчення терміну&#x20;

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

-Managed identities in Azure Active Directory offer a solution for **automatically managing the identity** of applications. These identities are used by applications for the purpose of **connecting** to **resources** compatible with Azure Active Directory (**Azure AD**) authentication. This allows to **remove the need of hardcoding cloud credentials** in the code as the application will be able to contact the **metadata** service to get a valid token to **perform actions** as the indicated managed identity in Azure.
+Керовані ідентичності в Azure Active Directory пропонують рішення для **автоматичного управління ідентичністю** додатків. Ці ідентичності використовуються додатками для **підключення** до **ресурсів**, сумісних з автентифікацією Azure Active Directory (**Azure AD**). Це дозволяє **усунути необхідність жорсткого кодування облікових даних хмари** в коді, оскільки додаток зможе звертатися до **служби метаданих**, щоб отримати дійсний токен для **виконання дій** як вказана керована ідентичність в Azure.

-There are two types of managed identities:
+Існує два типи керованих ідентичностей:

- **System-assigned**. Some Azure services allow you to **enable a managed identity directly on a service instance**. When you enable a system-assigned managed identity, a **service principal** is created in the Entra ID tenant trusted by the subscription where the resource is located. When the **resource** is **deleted**, Azure automatically **deletes** the **identity** for you.
- **User-assigned**. It's also possible for users to generate managed identities. These are created inside a resource group inside a subscription and a service principal will be created in the EntraID trusted by the subscription. Then, you can assign the managed identity to one or **more instances** of an Azure service (multiple resources). For user-assigned managed identities, the **identity is managed separately from the resources that use it**.
+- **Призначена системою**. Деякі служби Azure дозволяють вам **увімкнути керовану ідентичність безпосередньо на екземплярі служби**. Коли ви увімкнете керовану ідентичність, призначену системою, **службовий принципал** створюється в орендарі Entra ID, довіреному підписці, де розташований ресурс. Коли **ресурс** **видаляється**, Azure автоматично **видаляє** **ідентичність** за вас.
+- **Призначена користувачем**. Також можливо, щоб користувачі генерували керовані ідентичності. Вони створюються всередині групи ресурсів в межах підписки, і службовий принципал буде створений в EntraID, довіреному підписці. Потім ви можете призначити керовану ідентичність одному або **кільком екземплярам** служби Azure (кільком ресурсам). Для керованих ідентичностей, призначених користувачем, **ідентичність управляється окремо від ресурсів, які її використовують**.

-Managed Identities **don't generate eternal credentials** (like passwords or certificates) to access as the service principal attached to it.
+Керовані ідентичності **не генерують вічні облікові дані** (як паролі або сертифікати) для доступу як службовий принципал, прикріплений до них.

-### Enterprise Applications
+### Підприємницькі додатки

-It’s just a **table in Azure to filter service principals** and check the applications that have been assigned to.
+Це просто **таблиця в Azure для фільтрації службових принципалів** та перевірки додатків, які були призначені.

-**It isn’t another type of “application”,** there isn’t any object in Azure that is an “Enterprise Application”, it’s just an abstraction to check the Service principals, App registrations and managed identities.
+**Це не інший тип "додатка",** в Azure немає жодного об'єкта, який є "підприємницьким додатком", це просто абстракція для перевірки службових принципалів, реєстрацій додатків та керованих ідентичностей.

-### Administrative Units
+### Адміністративні одиниці

-Administrative units allows to **give permissions from a role over a specific portion of an organization**.
+Адміністративні одиниці дозволяють **надавати дозволи з ролі на конкретну частину організації**.

-Example:
+Приклад:

- Scenario: A company wants regional IT admins to manage only the users in their own region.
- Implementation:
-  - Create Administrative Units for each region (e.g., "North America AU", "Europe AU").
-    - Populate AUs with users from their respective regions.
-      - AUs can **contain users, groups, or devices**
-      - AUs support **dynamic memberships**
-      - AUs **cannot contain AUs**
-    - Assign Admin Roles:
-      - Grant the "User Administrator" role to regional IT staff, scoped to their region's AU.
- Outcome: Regional IT admins can manage user accounts within their region without affecting other regions.
+- Сценарій: Компанія хоче, щоб регіональні ІТ-адміністратори управляли лише користувачами у своєму регіоні.
+- Реалізація:
+- Створіть адміністративні одиниці для кожного регіону (наприклад, "Північна Америка AU", "Європа AU").
+- Заповніть AU користувачами з їхніх відповідних регіонів.
+- AU можуть **містити користувачів, групи або пристрої**
+- AU підтримують **динамічні членства**
+- AU **не можуть містити AU**
+- Призначити адміністративні ролі:
+- Надати роль "Адміністратор користувачів" регіональному ІТ-персоналу, обмежену до AU їхнього регіону.
+- Результат: Регіональні ІТ-адміністратори можуть управляти обліковими записами користувачів у своєму регіоні, не впливаючи на інші регіони.

-### Entra ID Roles
+### Ролі Entra ID

- In order to manage Entra ID there are some **built-in roles** that can be assigned to Entra ID principals to manage Entra ID
-  - Check the roles in [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)
- The most privileged role is **Global Administrator**
- In the Description of the role it’s possible to see its **granular permissions**
+- Для управління 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)
+- Найпривілейованішою роллю є **Глобальний адміністратор**
+- У описі ролі можна побачити її **деталізовані дозволи**

-## Roles & Permissions
+## Ролі та дозволи

-**Roles** are **assigned** to **principals** on a **scope**: `principal -[HAS ROLE]->(scope)`
+**Ролі** призначаються **принципалам** на **обсязі**: `principal -[HAS ROLE]->(scope)`

-**Roles** assigned to **groups** are **inherited** by all the **members** of the group.
+**Ролі**, призначені **групам**, **успадковуються** всіма **членами** групи.

-Depending on the scope the role was assigned to, the **role** cold be **inherited** to **other resources** inside the scope container. For example, if a user A has a **role on the subscription**, he will have that **role on all the resource groups** inside the subscription and on **all the resources** inside the resource group.
+Залежно від обсягу, до якого була призначена роль, **роль** може бути **успадкована** до **інших ресурсів** всередині контейнера обсягу. Наприклад, якщо користувач A має **роль на підписці**, він матиме цю **роль на всіх групах ресурсів** всередині підписки та на **всіх ресурсах** всередині групи ресурсів.

-### **Classic Roles**
+### **Класичні ролі**

-| **Owner**                     | <ul><li>Full access to all resources</li><li>Can manage access for other users</li></ul> | All resource types |
+| **Власник**                  | <ul><li>Повний доступ до всіх ресурсів</li><li>Може управляти доступом для інших користувачів</li></ul> | Усі типи ресурсів |
 | ----------------------------- | ---------------------------------------------------------------------------------------- | ------------------ |
-| **Contributor**               | <ul><li>Full access to all resources</li><li>Cannot manage access</li></ul>              | All resource types |
-| **Reader**                    | • View all resources                                                                     | All resource types |
-| **User Access Administrator** | <ul><li>View all resources</li><li>Can manage access for other users</li></ul>           | All resource types |
+| **Співробітник**             | <ul><li>Повний доступ до всіх ресурсів</li><li>Не може управляти доступом</li></ul>              | Усі типи ресурсів |
+| **Читач**                    | • Перегляд усіх ресурсів                                                                     | Усі типи ресурсів |
+| **Адміністратор доступу користувачів** | <ul><li>Перегляд усіх ресурсів</li><li>Може управляти доступом для інших користувачів</li></ul>           | Усі типи ресурсів |

-### Built-In roles
+### Вбудовані ролі

-[From the docs: ](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) has several Azure **built-in roles** that you can **assign** to **users, groups, service principals, and managed identities**. Role assignments are the way you control **access to Azure resources**. If the built-in roles don't meet the specific needs of your organization, you can create your own [**Azure custom roles**](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)**.**

-**Built-In** roles apply only to the **resources** they are **meant** to, for example check this 2 examples of **Built-In roles over Compute** resources:
+**Вбудовані** ролі застосовуються лише до **ресурсів**, для яких вони **призначені**, наприклад, перевірте ці 2 приклади **вбудованих ролей** для ресурсів **Обчислення**:

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

-This roles can **also be assigned over logic containers** (such as management groups, subscriptions and resource groups) and the principals affected will have them **over the resources inside those containers**.
+Ці ролі також можуть **призначатися над логічними контейнерами** (такими як групи управління, підписки та групи ресурсів), і принципали, які підпадають під їхній вплив, матимуть їх **над ресурсами всередині цих контейнерів**.

- Find here a list with [**all the Azure built-in roles**](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles).
- Find here a list with [**all the Entra ID built-in roles**](https://learn.microsoft.com/en-us/azure/active-directory/roles/permissions-reference).
+- Знайдіть тут список з [**усіма вбудованими ролями 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).

-### Custom Roles
+### Кастомні ролі

- It’s also possible to create [**custom roles**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)
- They are created inside a scope, although a role can be in several scopes (management groups, subscription and resource groups)
- It’s possible to configure all the granular permissions the custom role will have
- It’s possible to exclude permissions
-  - A principal with a excluded permission won’t be able to use it even if the permissions is being granted elsewhere
- It’s possible to use wildcards
- The used format is a JSON
-  - `actions` are for control actions over the resource
-  - `dataActions` are permissions over the data within the object
-
-Example of permissions JSON for a custom role:
+- Також можливо створити [**кастомні ролі**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)
+- Вони створюються всередині обсягу, хоча роль може бути в кількох обсягах (групи управління, підписка та групи ресурсів)
+- Можливо налаштувати всі детальні дозволи, які матиме кастомна роль
+- Можливо виключити дозволи
+- Принципал з виключеним дозволом не зможе його використовувати, навіть якщо дозвіл надається в іншому місці
+- Можливо використовувати підстановочні знаки
+- Використовуваний формат - JSON
+- `actions` призначені для контролю дій над ресурсом
+- `dataActions` - це дозволи над даними в об'єкті

+Приклад JSON дозволів для кастомної ролі:
 ```json
 {
-  "properties": {
-    "roleName": "",
-    "description": "",
-    "assignableScopes": ["/subscriptions/9291ff6e-6afb-430e-82a4-6f04b2d05c7f"],
-    "permissions": [
-      {
-        "actions": [
-          "Microsoft.DigitalTwins/register/action",
-          "Microsoft.DigitalTwins/unregister/action",
-          "Microsoft.DigitalTwins/operations/read",
-          "Microsoft.DigitalTwins/digitalTwinsInstances/read",
-          "Microsoft.DigitalTwins/digitalTwinsInstances/write",
-          "Microsoft.CostManagement/exports/*"
-        ],
-        "notActions": [
-          "Astronomer.Astro/register/action",
-          "Astronomer.Astro/unregister/action",
-          "Astronomer.Astro/operations/read",
-          "Astronomer.Astro/organizations/read"
-        ],
-        "dataActions": [],
-        "notDataActions": []
-      }
-    ]
-  }
+"properties": {
+"roleName": "",
+"description": "",
+"assignableScopes": ["/subscriptions/9291ff6e-6afb-430e-82a4-6f04b2d05c7f"],
+"permissions": [
+{
+"actions": [
+"Microsoft.DigitalTwins/register/action",
+"Microsoft.DigitalTwins/unregister/action",
+"Microsoft.DigitalTwins/operations/read",
+"Microsoft.DigitalTwins/digitalTwinsInstances/read",
+"Microsoft.DigitalTwins/digitalTwinsInstances/write",
+"Microsoft.CostManagement/exports/*"
+],
+"notActions": [
+"Astronomer.Astro/register/action",
+"Astronomer.Astro/unregister/action",
+"Astronomer.Astro/operations/read",
+"Astronomer.Astro/organizations/read"
+],
+"dataActions": [],
+"notDataActions": []
+}
+]
+}
 }
 ```
-
 ### Permissions order

- In order for a **principal to have some access over a resource** he needs an explicit role being granted to him (anyhow) **granting him that permission**.
- An explicit **deny role assignment takes precedence** over the role granting the permission.
+- Щоб **суб'єкт мав доступ до ресурсу**, йому потрібно явно надати роль (будь-яким чином), **яка надає йому це дозволення**.
+- Явне **призначення ролі заборони має пріоритет** над роллю, що надає дозволення.

 <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 is a role from Entra ID that grants **complete control over the Entra ID tenant**. However, it doesn't grant any permissions over Azure resources by default.
+Global Administrator — це роль з Entra ID, яка надає **повний контроль над орендою Entra ID**. Однак за замовчуванням вона не надає жодних дозволів на ресурси Azure.

-Users with the Global Administrator role has the ability to '**elevate' to User Access Administrator Azure role in the Root Management Group**. So Global Administrators can manage access in **all Azure subscriptions and management groups.**\
-This elevation can be done at the end of the page: [https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/\~/Properties](https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties)
+Користувачі з роллю 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>

 ### Azure Policies

-**Azure Policies** are rules that help organizations ensure their resources meet specific standards and compliance requirements. They allow you to **enforce or audit settings on resources in Azure**. For example, you can prevent the creation of virtual machines in an unauthorized region or ensure that all resources have specific tags for tracking.
+**Azure Policies** — це правила, які допомагають організаціям забезпечити відповідність їх ресурсів певним стандартам і вимогам. Вони дозволяють **застосовувати або перевіряти налаштування на ресурсах в Azure**. Наприклад, ви можете заборонити створення віртуальних машин в несанкціонованому регіоні або забезпечити, щоб усі ресурси мали певні теги для відстеження.

-Azure Policies are **proactive**: they can stop non-compliant resources from being created or changed. They are also **reactive**, allowing you to find and fix existing non-compliant resources.
+Azure Policies є **проактивними**: вони можуть зупинити створення або зміну несумісних ресурсів. Вони також є **реактивними**, дозволяючи вам знаходити та виправляти існуючі несумісні ресурси.

 #### **Key Concepts**

-1. **Policy Definition**: A rule, written in JSON, that specifies what is allowed or required.
-2. **Policy Assignment**: The application of a policy to a specific scope (e.g., subscription, resource group).
-3. **Initiatives**: A collection of policies grouped together for broader enforcement.
-4. **Effect**: Specifies what happens when the policy is triggered (e.g., "Deny," "Audit," or "Append").
+1. **Policy Definition**: Правило, написане в JSON, яке визначає, що дозволено або вимагається.
+2. **Policy Assignment**: Застосування політики до конкретної області (наприклад, підписка, група ресурсів).
+3. **Initiatives**: Збірка політик, згрупованих разом для ширшого застосування.
+4. **Effect**: Визначає, що відбувається, коли політика спрацьовує (наприклад, "Заборонити", "Аудит" або "Додати").

-**Some examples:**
+**Деякі приклади:**

-1. **Ensuring Compliance with Specific Azure Regions**: This policy ensures that all resources are deployed in specific Azure regions. For example, a company might want to ensure all its data is stored in Europe for GDPR compliance.
-2. **Enforcing Naming Standards**: Policies can enforce naming conventions for Azure resources. This helps in organizing and easily identifying resources based on their names, which is helpful in large environments.
-3. **Restricting Certain Resource Types**: This policy can restrict the creation of certain types of resources. For example, a policy could be set to prevent the creation of expensive resource types, like certain VM sizes, to control costs.
-4. **Enforcing Tagging Policies**: Tags are key-value pairs associated with Azure resources used for resource management. Policies can enforce that certain tags must be present, or have specific values, for all resources. This is useful for cost tracking, ownership, or categorization of resources.
-5. **Limiting Public Access to Resources**: Policies can enforce that certain resources, like storage accounts or databases, do not have public endpoints, ensuring that they are only accessible within the organization's network.
-6. **Automatically Applying Security Settings**: Policies can be used to automatically apply security settings to resources, such as applying a specific network security group to all VMs or ensuring that all storage accounts use encryption.
+1. **Забезпечення відповідності певним регіонам Azure**: Ця політика забезпечує, щоб усі ресурси розгорталися в певних регіонах Azure. Наприклад, компанія може захотіти, щоб усі її дані зберігалися в Європі для відповідності GDPR.
+2. **Забезпечення стандартів іменування**: Політики можуть забезпечувати дотримання стандартів іменування для ресурсів Azure. Це допомагає в організації та легкому ідентифікуванні ресурсів за їхніми іменами, що корисно в великих середовищах.
+3. **Обмеження певних типів ресурсів**: Ця політика може обмежити створення певних типів ресурсів. Наприклад, політика може бути встановлена для заборони створення дорогих типів ресурсів, таких як певні розміри ВМ, для контролю витрат.
+4. **Забезпечення політик тегування**: Теги — це пари ключ-значення, пов'язані з ресурсами Azure, які використовуються для управління ресурсами. Політики можуть забезпечувати, щоб певні теги були присутні, або мали конкретні значення, для всіх ресурсів. Це корисно для відстеження витрат, власності або категоризації ресурсів.
+5. **Обмеження публічного доступу до ресурсів**: Політики можуть забезпечувати, щоб певні ресурси, такі як облікові записи зберігання або бази даних, не мали публічних кінцевих точок, забезпечуючи, щоб вони були доступні лише в межах мережі організації.
+6. **Автоматичне застосування налаштувань безпеки**: Політики можуть використовуватися для автоматичного застосування налаштувань безпеки до ресурсів, таких як застосування конкретної групи безпеки мережі до всіх ВМ або забезпечення, щоб усі облікові записи зберігання використовували шифрування.

-Note that Azure Policies can be attached to any level of the Azure hierarchy, but they are **commonly used in the root management group** or in other management groups.
+Зверніть увагу, що Azure Policies можуть бути прикріплені до будь-якого рівня ієрархії Azure, але вони **зазвичай використовуються в кореневій групі управління** або в інших групах управління.

 Azure policy json example:
-
 ```json
 {
-  "policyRule": {
-    "if": {
-      "field": "location",
-      "notIn": ["eastus", "westus"]
-    },
-    "then": {
-      "effect": "Deny"
-    }
-  },
-  "parameters": {},
-  "displayName": "Allow resources only in East US and West US",
-  "description": "This policy ensures that resources can only be created in East US or West US.",
-  "mode": "All"
+"policyRule": {
+"if": {
+"field": "location",
+"notIn": ["eastus", "westus"]
+},
+"then": {
+"effect": "Deny"
+}
+},
+"parameters": {},
+"displayName": "Allow resources only in East US and West US",
+"description": "This policy ensures that resources can only be created in East US or West US.",
+"mode": "All"
 }
 ```
+### Спадкування дозволів

-### Permissions Inheritance
+В Azure **дозволи можуть бути призначені будь-якій частині ієрархії**. Це включає управлінські групи, підписки, групи ресурсів та окремі ресурси. Дозволи **спадкуються** від вміщених **ресурсів** сутності, до якої вони були призначені.

-In Azure **permissions are can be assigned to any part of the hierarchy**. That includes management groups, subscriptions, resource groups, and individual resources. Permissions are **inherited** by contained **resources** of the entity where they were assigned.
-
-This hierarchical structure allows for efficient and scalable management of access permissions.
+Ця ієрархічна структура дозволяє ефективно та масштабовано управляти доступом до дозволів.

 <figure><img src="../../../images/image (26).png" alt=""><figcaption></figcaption></figure>

-### Azure RBAC vs ABAC
+### Azure RBAC проти ABAC

-**RBAC** (role-based access control) is what we have seen already in the previous sections: **Assigning a role to a principal to grant him access** over a resource.\
-However, in some cases you might want to provide **more fined-grained access management** or **simplify** the management of **hundreds** of role **assignments**.
+**RBAC** (контроль доступу на основі ролей) - це те, що ми вже бачили в попередніх розділах: **Призначення ролі суб'єкту для надання йому доступу** до ресурсу.\
+Однак у деяких випадках ви можете захотіти надати **більш детальне управління доступом** або **спростити** управління **сотнями** призначень ролей.

-Azure **ABAC** (attribute-based access control) builds on Azure RBAC by adding **role assignment conditions based on attributes** in the context of specific actions. A _role assignment condition_ is an **additional check that you can optionally add to your role assignment** to provide more fine-grained access control. A condition filters down permissions granted as a part of the role definition and role assignment. For example, you can **add a condition that requires an object to have a specific tag to read the object**.\
-You **cannot** explicitly **deny** **access** to specific resources **using conditions**.
+Azure **ABAC** (контроль доступу на основі атрибутів) базується на Azure RBAC, додаючи **умови призначення ролей на основі атрибутів** у контексті конкретних дій. _Умова призначення ролі_ - це **додаткова перевірка, яку ви можете за бажанням додати до вашого призначення ролі** для надання більш детального контролю доступу. Умова фільтрує дозволи, надані в рамках визначення ролі та призначення ролі. Наприклад, ви можете **додати умову, яка вимагає, щоб об'єкт мав певний тег для читання об'єкта**.\
+Ви **не можете** явно **заборонити** **доступ** до конкретних ресурсів **за допомогою умов**.

-## References
+## Посилання

 - [https://learn.microsoft.com/en-us/azure/governance/management-groups/overview](https://learn.microsoft.com/en-us/azure/governance/management-groups/overview)
 - [https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/organize-subscriptions](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/organize-subscriptions)
@@ -379,7 +375,3 @@ You **cannot** explicitly **deny** **access** to specific resources **using cond
 - [https://stackoverflow.com/questions/65922566/what-are-the-differences-between-service-principal-and-app-registration](https://stackoverflow.com/questions/65922566/what-are-the-differences-between-service-principal-and-app-registration)

 {{#include ../../../banners/hacktricks-training.md}}
-
-
-
-