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

src/pentesting-cloud/azure-security/az-basic-information/README.md

@@ -11,10 +11,10 @@
 - Sie kann **andere Verwaltungsguppen oder Abonnements** enthalten.
 - Dies ermöglicht es, **Governance-Kontrollen** wie RBAC und Azure Policy einmal auf der Ebene der Verwaltungsguppe anzuwenden und sie von allen Abonnements in der Gruppe **zu erben**.
 - **10.000 Verwaltungsguppen** können in einem einzigen Verzeichnis unterstützt werden.
-- Ein Verwaltungsgruppenbaum kann **bis zu sechs Ebenen tief** sein. Diese Grenze schließt die Wurzelebene oder die Abonnementebene nicht ein.
+- Ein Verwaltungsgruppenbaum kann **bis zu sechs Ebenen tief** sein. Diese Grenze schließt die Root-Ebene oder die Abonnement-Ebene nicht ein.
 - Jede Verwaltungsguppe und jedes Abonnement kann **nur einen Elternteil** unterstützen.
-- Auch wenn mehrere Verwaltungsguppen erstellt werden können, gibt es **nur 1 Wurzelverwaltungsguppe**.
-- Die Wurzelverwaltungsguppe **enthält** alle **anderen Verwaltungsguppen und Abonnements** und **kann nicht verschoben oder gelöscht werden**.
+- Auch wenn mehrere Verwaltungsguppen erstellt werden können, gibt es **nur 1 Root-Verwaltungsguppe**.
+- Die Root-Verwaltungsguppe **enthält** alle **anderen Verwaltungsguppen und Abonnements** und **kann nicht verschoben oder gelöscht werden**.
 - Alle Abonnements innerhalb einer einzigen Verwaltungsguppe müssen dem **gleichen Entra ID-Mandanten** vertrauen.
 
 <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>
@@ -22,9 +22,9 @@
 ### Azure-Abonnements
 
 - Es ist ein weiterer **logischer Container, in dem Ressourcen** (VMs, DBs…) ausgeführt werden können und abgerechnet werden.
-- Sein **Elternteil** ist immer eine **Verwaltungsguppe** (und es kann die Wurzelverwaltungsguppe sein), da Abonnements keine anderen Abonnements enthalten können.
+- Sein **Elternteil** ist immer eine **Verwaltungsguppe** (und es kann die Root-Verwaltungsguppe sein), da Abonnements keine anderen Abonnements enthalten können.
 - Es **vertraut nur einem Entra ID**-Verzeichnis.
-- **Berechtigungen**, die auf der Abonnementebene (oder einer seiner Eltern) angewendet werden, werden **auf alle Ressourcen innerhalb des Abonnements vererbt**.
+- **Berechtigungen**, die auf der Abonnement-Ebene (oder einer seiner Eltern) angewendet werden, werden **auf alle Ressourcen innerhalb des Abonnements vererbt**.
 
 ### Ressourcengruppen
 
@@ -105,11 +105,11 @@ Sie können sie in [https://learn.microsoft.com/en-us/entra/fundamentals/users-d
 - **Gäste**
 - **Einschränkungen für den Zugriff von Gastbenutzern**:
 - **Gastbenutzer haben den gleichen Zugriff wie Mitglieder**.
-- **Gastbenutzer haben eingeschränkten Zugriff auf Eigenschaften und Mitgliedschaften von Verzeichnisobjekten (Standard)**. Dies schränkt den Gastzugriff standardmäßig nur auf ihr eigenes Benutzerprofil ein. Der Zugriff auf Informationen anderer Benutzer und Gruppen ist nicht mehr erlaubt.
-- **Der Zugriff von Gastbenutzern auf Eigenschaften und Mitgliedschaften ihrer eigenen Verzeichnisobjekte ist die restriktivste Option**.
-- **Gäste können einladen**:
+- **Gastbenutzer haben eingeschränkten Zugriff auf Eigenschaften und Mitgliedschaften von Verzeichnisobjekten (Standard)**. Dies schränkt den Gastzugriff standardmäßig auf nur ihr eigenes Benutzerprofil ein. Der Zugriff auf Informationen anderer Benutzer und Gruppen ist nicht mehr erlaubt.
+- **Der Zugriff von Gastbenutzern ist auf Eigenschaften und Mitgliedschaften ihrer eigenen Verzeichnisobjekte beschränkt** ist die restriktivste.
+- **Gäste können einladen** Optionen:
 - **Jeder in der Organisation kann Gastbenutzer einladen, einschließlich Gäste und Nicht-Administratoren (am inklusivsten) - Standard**
-- **Mitgliedsbenutzer und Benutzer, die bestimmten Administrationsrollen zugewiesen sind, können Gastbenutzer einladen, einschließlich Gäste mit Mitgliedsberechtigungen**
+- **Mitgliedbenutzer und Benutzer, die bestimmten Administrationsrollen zugewiesen sind, können Gastbenutzer einladen, einschließlich Gäste mit Mitgliedsberechtigungen**
 - **Nur Benutzer, die bestimmten Administrationsrollen zugewiesen sind, können Gastbenutzer einladen**
 - **Niemand in der Organisation kann Gastbenutzer einladen, einschließlich Administratoren (am restriktivsten)**
 - **Externe Benutzer verlassen**: Standard **Wahr**
@@ -133,11 +133,11 @@ Es gibt **2 Arten von Mitgliedschaften**:
 
 ### **Dienstprinzipale**
 
-Ein **Dienstprinzipal** ist eine **Identität**, die für die **Nutzung** mit **Anwendungen**, gehosteten Diensten und automatisierten Tools zur Zugriff auf Azure-Ressourcen erstellt wurde. Dieser Zugriff ist **durch die zugewiesenen Rollen** des Dienstprinzipals eingeschränkt, was Ihnen die Kontrolle darüber gibt, **auf welche Ressourcen zugegriffen werden kann** und auf welchem Niveau. Aus Sicherheitsgründen wird immer empfohlen, **Dienstprinzipale mit automatisierten Tools zu verwenden**, anstatt ihnen zu erlauben, sich mit einer Benutzeridentität anzumelden.
+Ein **Dienstprinzipal** ist eine **Identität**, die für die **Nutzung** mit **Anwendungen**, gehosteten Diensten und automatisierten Tools zur Zugriff auf Azure-Ressourcen erstellt wurde. Dieser Zugriff ist **durch die zugewiesenen Rollen** des Dienstprinzipals eingeschränkt, was Ihnen die Kontrolle darüber gibt, **auf welche Ressourcen zugegriffen werden kann** und auf welcher Ebene. Aus Sicherheitsgründen wird immer empfohlen, **Dienstprinzipale mit automatisierten Tools** zu verwenden, anstatt ihnen zu erlauben, sich mit einer Benutzeridentität anzumelden.
 
-Es ist möglich, sich **direkt als Dienstprinzipal anzumelden**, indem man ihm ein **Geheimnis** (Passwort), ein **Zertifikat** oder **föderierten** Zugriff auf Drittanbieterplattformen (z. B. Github Actions) gewährt.
+Es ist möglich, sich **direkt als Dienstprinzipal anzumelden**, indem man ihm ein **Geheimnis** (Passwort), ein **Zertifikat** oder den **föderierten** Zugriff auf Drittanbieterplattformen (z. B. Github Actions) gewährt.
 
-- Wenn Sie die **Passwort**-Authentifizierung (standardmäßig) wählen, **speichern Sie das generierte Passwort**, da Sie nicht mehr darauf zugreifen können.
+- Wenn Sie die **Passwort**-Authentifizierung (standardmäßig) wählen, **speichern Sie das generierte Passwort**, da Sie nicht erneut darauf zugreifen können.
 - Wenn Sie die Zertifikatsauthentifizierung wählen, stellen Sie sicher, dass die **Anwendung Zugriff auf den privaten Schlüssel hat**.
 
 ### App-Registrierungen
@@ -157,34 +157,34 @@ Eine **App-Registrierung** ist eine Konfiguration, die es einer Anwendung ermög
 
 ### Standardzustimmungsberechtigungen
 
-**Benutzereinwilligung für Anwendungen**
+**Benutzerzustimmung für Anwendungen**
 
-- **Benutzereinwilligung nicht zulassen**
+- **Benutzerzustimmung nicht zulassen**
 - Ein Administrator wird für alle Apps erforderlich sein.
-- **Benutzereinwilligung für Apps von verifizierten Herausgebern für ausgewählte Berechtigungen zulassen (empfohlen)**
-- Alle Benutzer können für Berechtigungen, die als "geringfügig" eingestuft sind, für Apps von verifizierten Herausgebern oder Apps, die in dieser Organisation registriert sind, zustimmen.
+- **Benutzerzustimmung für Apps von verifizierten Herausgebern für ausgewählte Berechtigungen zulassen (Empfohlen)**
+- Alle Benutzer können für Berechtigungen zustimmen, die als "geringfügig" eingestuft sind, für Apps von verifizierten Herausgebern oder Apps, die in dieser Organisation registriert sind.
 - **Standard** geringfügige Berechtigungen (obwohl Sie zustimmen müssen, um sie als geringfügig hinzuzufügen):
 - User.Read - anmelden und Benutzerprofil lesen
 - offline_access - Zugriff auf Daten aufrechterhalten, auf die Benutzer Zugriff gewährt haben
 - openid - Benutzer anmelden
 - profile - grundlegendes Benutzerprofil anzeigen
 - email - E-Mail-Adresse des Benutzers anzeigen
-- **Benutzereinwilligung für Apps zulassen (Standard)**
+- **Benutzerzustimmung für Apps zulassen (Standard)**
 - Alle Benutzer können für jede App zustimmen, um auf die Daten der Organisation zuzugreifen.
 
 **Anfragen zur Zustimmung des Administrators**: Standard **Nein**
 
-- Benutzer können die Zustimmung des Administrators für Apps anfordern, für die sie nicht zustimmen können.
-- Wenn **Ja**: Es ist möglich, Benutzer, Gruppen und Rollen anzugeben, die Anfragen zustimmen können.
-- Konfigurieren Sie auch, ob Benutzer E-Mail-Benachrichtigungen und Ablaufbenachrichtigungen erhalten.
+- Benutzer können die Zustimmung des Administrators für Apps anfordern, für die sie nicht zustimmen können
+- Wenn **Ja**: Es ist möglich, Benutzer, Gruppen und Rollen anzugeben, die Anfragen zustimmen können
+- Konfigurieren Sie auch, ob Benutzer E-Mail-Benachrichtigungen und Ablaufbenachrichtigungen erhalten
 
 ### **Verwaltete Identität (Metadaten)**
 
-Verwaltete Identitäten in Azure Active Directory bieten eine Lösung zur **automatischen Verwaltung der Identität** von Anwendungen. Diese Identitäten werden von Anwendungen verwendet, um sich mit **Ressourcen** zu verbinden, die mit der Azure Active Directory (**Azure AD**) Authentifizierung kompatibel sind. Dies ermöglicht es, die Notwendigkeit, Cloud-Anmeldeinformationen im Code festzulegen, zu **entfernen**, da die Anwendung in der Lage sein wird, den **Metadaten**-Dienst zu kontaktieren, um ein gültiges Token zu **erhalten**, um Aktionen als die angegebene verwaltete Identität in Azure auszuführen.
+Verwaltete Identitäten in Azure Active Directory bieten eine Lösung zur **automatischen Verwaltung der Identität** von Anwendungen. Diese Identitäten werden von Anwendungen verwendet, um sich mit **Ressourcen** zu verbinden, die mit der Azure Active Directory (**Azure AD**) Authentifizierung kompatibel sind. Dies ermöglicht es, die Notwendigkeit, Cloud-Anmeldeinformationen im Code festzulegen, zu **entfernen**, da die Anwendung in der Lage ist, den **Metadaten**-Dienst zu kontaktieren, um ein gültiges Token zu **erhalten**, um Aktionen als die angegebene verwaltete Identität in Azure auszuführen.
 
 Es gibt zwei Arten von verwalteten Identitäten:
 
-- **Systemzugewiesen**. Einige Azure-Dienste ermöglichen es Ihnen, **eine verwaltete Identität direkt auf einer Dienstinstanz zu aktivieren**. Wenn Sie eine systemzugewiesene verwaltete Identität aktivieren, wird ein **Dienstprinzipal** im Entra ID-Mandanten erstellt, dem das Abonnement, in dem sich die Ressource befindet, vertraut. Wenn die **Ressource** **gelöscht** wird, löscht Azure automatisch die **Identität** für Sie.
+- **Systemzugewiesen**. Einige Azure-Dienste ermöglichen es Ihnen, eine verwaltete Identität direkt auf einer Dienstinstanz **zu aktivieren**. Wenn Sie eine systemzugewiesene verwaltete Identität aktivieren, wird ein **Dienstprinzipal** im Entra ID-Mandanten erstellt, dem das Abonnement, in dem sich die Ressource befindet, vertraut. Wenn die **Ressource** **gelöscht** wird, löscht Azure automatisch die **Identität** für Sie.
 - **Benutzerzugewiesen**. Es ist auch möglich, dass Benutzer verwaltete Identitäten generieren. Diese werden innerhalb einer Ressourcengruppe innerhalb eines Abonnements erstellt, und ein Dienstprinzipal wird im EntraID erstellt, dem das Abonnement vertraut. Dann können Sie die verwaltete Identität einer oder **mehreren Instanzen** eines Azure-Dienstes (mehrere Ressourcen) zuweisen. Bei benutzerzugewiesenen verwalteten Identitäten wird die **Identität separat von den Ressourcen verwaltet, die sie verwenden**.
 
 Verwaltete Identitäten **erzeugen keine ewigen Anmeldeinformationen** (wie Passwörter oder Zertifikate), um auf den damit verbundenen Dienstprinzipal zuzugreifen.
@@ -205,7 +205,7 @@ Beispiel:
 - Implementierung:
 - Erstellen Sie Verwaltungseinheiten für jede Region (z. B. "Nordamerika AU", "Europa AU").
 - Füllen Sie AUs mit Benutzern aus ihren jeweiligen Regionen.
-- AUs können **Benutzer, Gruppen oder Geräte enthalten**.
+- AUs können **Benutzer, Gruppen oder Geräte** enthalten.
 - AUs unterstützen **dynamische Mitgliedschaften**.
 - AUs **können keine AUs enthalten**.
 - Administratorrollen zuweisen:
@@ -231,15 +231,15 @@ Je nach dem Bereich, dem die Rolle zugewiesen wurde, kann die **Rolle** auf **an
 
 | **Besitzer**                  | <ul><li>Vollzugriff auf alle Ressourcen</li><li>Kann den Zugriff für andere Benutzer verwalten</li></ul> | Alle Ressourcentypen |
 | ----------------------------- | ---------------------------------------------------------------------------------------- | ------------------ |
-| **Mitwirkender**              | <ul><li>Vollzugriff auf alle Ressourcen</li><li>Kann den Zugriff nicht verwalten</li></ul>              | Alle Ressourcentypen |
-| **Leser**                     | • Alle Ressourcen anzeigen                                                                     | Alle Ressourcentypen |
+| **Mitwirkender**             | <ul><li>Vollzugriff auf alle Ressourcen</li><li>Kann den Zugriff nicht verwalten</li></ul> | Alle Ressourcentypen |
+| **Leser**                    | • Alle Ressourcen anzeigen                                                                     | Alle Ressourcentypen |
 | **Benutzerzugriffsadministrator** | <ul><li>Alle Ressourcen anzeigen</li><li>Kann den Zugriff für andere Benutzer verwalten</li></ul>           | Alle Ressourcentypen |
 
-### Eingebaute Rollen
+### Vordefinierte Rollen
 
-[Aus den Dokumenten: ](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles)[Azure-Rollenbasierte Zugriffskontrolle (Azure RBAC)](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview) hat mehrere Azure **eingebaute Rollen**, die Sie **Benutzern, Gruppen, Dienstprinzipalen und verwalteten Identitäten** zuweisen können. Rollenzuweisungen sind der Weg, wie Sie **Zugriff auf Azure-Ressourcen** steuern. Wenn die eingebauten Rollen nicht den spezifischen Bedürfnissen Ihrer Organisation entsprechen, können Sie Ihre eigenen [**benutzerdefinierten Azure-Rollen**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)** erstellen.**
+[Aus den Dokumenten: ](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles)[Azure-Rollenbasierte Zugriffskontrolle (Azure RBAC)](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview) hat mehrere Azure **vordefinierte Rollen**, die Sie **Benutzern, Gruppen, Dienstprinzipalen und verwalteten Identitäten** zuweisen können. Rollenzuweisungen sind der Weg, wie Sie **Zugriff auf Azure-Ressourcen** steuern. Wenn die vordefinierten Rollen nicht den spezifischen Bedürfnissen Ihrer Organisation entsprechen, können Sie Ihre eigenen [**benutzerdefinierten Azure-Rollen**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)** erstellen.**
 
-**Eingebaute** Rollen gelten nur für die **Ressourcen**, für die sie **bestimmt** sind, zum Beispiel überprüfen Sie diese 2 Beispiele für **eingebaute Rollen über Compute**-Ressourcen:
+**Vordefinierte** Rollen gelten nur für die **Ressourcen**, für die sie **bestimmt** sind, zum Beispiel überprüfen Sie diese 2 Beispiele für **vordefinierte Rollen über Compute**-Ressourcen:
 
 | [Disk Backup Reader](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#disk-backup-reader)                 | Berechtigt das Backup-Repository, um ein Festplattensicherung durchzuführen.      | 3e5e47e6-65f7-47ef-90b5-e5dd4d455f24 |
 | ----------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | ------------------------------------ |
@@ -247,8 +247,8 @@ Je nach dem Bereich, dem die Rolle zugewiesen wurde, kann die **Rolle** auf **an
 
 Diese Rollen können **auch über logische Container** (wie Verwaltungsguppen, Abonnements und Ressourcengruppen) zugewiesen werden, und die betroffenen Prinzipale haben sie **über die Ressourcen innerhalb dieser Container**.
 
-- Finden Sie hier eine Liste mit [**allen Azure-eingebauten Rollen**](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles).
-- Finden Sie hier eine Liste mit [**allen Entra ID-eingebauten Rollen**](https://learn.microsoft.com/en-us/azure/active-directory/roles/permissions-reference).
+- Finden Sie hier eine Liste mit [**allen vordefinierten Azure-Rollen**](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles).
+- Finden Sie hier eine Liste mit [**allen vordefinierten Entra ID-Rollen**](https://learn.microsoft.com/en-us/azure/active-directory/roles/permissions-reference).
 
 ### Benutzerdefinierte Rollen
 
@@ -296,62 +296,55 @@ Beispiel für JSON-Berechtigungen für eine benutzerdefinierte Rolle:
 ```
 ### Berechtigungsreihenfolge
 
-- Damit ein **Principal Zugriff auf eine Ressource hat**, muss ihm eine explizite Rolle zugewiesen werden (in welcher Form auch immer), **die ihm diese Berechtigung gewährt**.
+- Damit ein **Principal Zugriff auf eine Ressource hat**, muss ihm eine explizite Rolle zugewiesen werden, die ihm **diese Berechtigung gewährt**.
 - Eine explizite **Ablehnung hat Vorrang** vor der Rolle, die die Berechtigung gewährt.
 
 <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>
 
 ### Globaler Administrator
 
-Der globale Administrator ist eine Rolle aus Entra ID, die **vollständige Kontrolle über den Entra ID-Mandanten** gewährt. Standardmäßig gewährt sie jedoch keine Berechtigungen für Azure-Ressourcen.
+Der globale Administrator ist eine Rolle aus Entra ID, die **vollständige Kontrolle über den Entra ID-Mandanten gewährt**. Standardmäßig gewährt sie jedoch keine Berechtigungen für Azure-Ressourcen.
 
-Benutzer mit der Rolle des globalen Administrators haben die Möglichkeit, sich zur Rolle des **User Access Administrator in der Root Management Group zu 'erhöhen'**. So können globale Administratoren den Zugriff in **allen Azure-Abonnements und Verwaltungsgruppen verwalten.**\
+Benutzer mit der Rolle des globalen Administrators haben die Möglichkeit, sich **zum Benutzerzugriffsadministrator-Rolle in der Root-Management-Gruppe zu "erheben"**. Global Administratoren können den Zugriff in **allen Azure-Abonnements und Managementgruppen verwalten.**\
 Diese Erhöhung kann am Ende der Seite durchgeführt werden: [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>
 
 ### Zuweisungsbedingungen & MFA
 
-Es ist möglich, **einige Bedingungen festzulegen, wenn eine Rolle einem Principal zugewiesen wird**. Eine gängige Bedingung ist, MFA für den Zugriff auf einige Rollenberechtigungen zu verlangen:
-```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
+Laut **[den Dokumenten](https://learn.microsoft.com/en-us/azure/role-based-access-control/conditions-role-assignments-portal)**: Derzeit können Bedingungen zu integrierten oder benutzerdefinierten Rollenzuweisungen hinzugefügt werden, die **Blob-Speicher-Datenaktionen oder Warteschlangen-Speicher-Datenaktionen** haben.
 
-Genau wie Rollenzuweisungen werden **deny assignments** verwendet, um **den Zugriff auf Azure-Ressourcen zu steuern**. Allerdings werden **deny assignments** verwendet, um **den Zugriff auf eine Ressource ausdrücklich zu verweigern**, selbst wenn einem Benutzer der Zugriff über eine Rollenzuweisung gewährt wurde. **Deny assignments** haben Vorrang vor **Rollenzuweisungen**, was bedeutet, dass, wenn einem Benutzer der Zugriff über eine Rollenzuweisung gewährt wird, aber auch ausdrücklich der Zugriff durch eine deny assignment verweigert wird, die deny assignment Vorrang hat.
+### Ablehnungszuweisungen
 
-Genau wie Rollenzuweisungen werden **deny assignments** über einen bestimmten Geltungsbereich angewendet, der die betroffenen Prinzipale und die verweigerten Berechtigungen angibt. Darüber hinaus ist es im Fall von deny assignments möglich, **zu verhindern, dass die Verweigerung von untergeordneten Ressourcen geerbt wird**.
+Ähnlich wie Rollenzuweisungen werden **Ablehnungszuweisungen** verwendet, um **den Zugriff auf Azure-Ressourcen zu steuern**. Allerdings werden **Ablehnungszuweisungen** verwendet, um **den Zugriff auf eine Ressource ausdrücklich zu verweigern**, selbst wenn einem Benutzer der Zugriff über eine Rollenzuweisung gewährt wurde. **Ablehnungszuweisungen** haben Vorrang vor **Rollenzuweisungen**, was bedeutet, dass, wenn einem Benutzer der Zugriff über eine Rollenzuweisung gewährt wird, aber auch ausdrücklich der Zugriff über eine Ablehnungszuweisung verweigert wird, die Ablehnungszuweisung Vorrang hat.
 
-### Azure Policies
+Ähnlich wie Rollenzuweisungen werden **Ablehnungszuweisungen** über einen bestimmten Geltungsbereich angewendet, der die betroffenen Principals und die verweigerten Berechtigungen angibt. Darüber hinaus ist es im Fall von Ablehnungszuweisungen möglich, **zu verhindern, dass die Ablehnung von untergeordneten Ressourcen geerbt wird**.
 
-**Azure Policies** sind Regeln, die Organisationen helfen, sicherzustellen, dass ihre Ressourcen bestimmten Standards und Compliance-Anforderungen entsprechen. Sie ermöglichen es Ihnen, **Einstellungen für Ressourcen in Azure durchzusetzen oder zu überprüfen**. Zum Beispiel können Sie die Erstellung von virtuellen Maschinen in einer nicht autorisierten Region verhindern oder sicherstellen, dass alle Ressourcen bestimmte Tags zur Nachverfolgung haben.
+### Azure-Richtlinien
 
-Azure Policies sind **proaktiv**: Sie können die Erstellung oder Änderung von nicht konformen Ressourcen stoppen. Sie sind auch **reaktiv**, sodass Sie bestehende nicht konforme Ressourcen finden und beheben können.
+**Azure-Richtlinien** sind Regeln, die Organisationen helfen, sicherzustellen, dass ihre Ressourcen bestimmten Standards und Compliance-Anforderungen entsprechen. Sie ermöglichen es Ihnen, **Einstellungen für Ressourcen in Azure durchzusetzen oder zu überprüfen**. Zum Beispiel können Sie die Erstellung von virtuellen Maschinen in einer nicht autorisierten Region verhindern oder sicherstellen, dass alle Ressourcen bestimmte Tags zur Nachverfolgung haben.
 
-#### **Key Concepts**
+Azure-Richtlinien sind **proaktiv**: Sie können die Erstellung oder Änderung von nicht konformen Ressourcen stoppen. Sie sind auch **reaktiv**, sodass Sie bestehende nicht konforme Ressourcen finden und beheben können.
 
-1. **Policy Definition**: Eine Regel, die in JSON geschrieben ist und angibt, was erlaubt oder erforderlich ist.
-2. **Policy Assignment**: Die Anwendung einer Richtlinie auf einen bestimmten Geltungsbereich (z. B. Abonnement, Ressourcengruppe).
-3. **Initiatives**: Eine Sammlung von Richtlinien, die zusammengefasst sind, um eine breitere Durchsetzung zu ermöglichen.
-4. **Effect**: Gibt an, was passiert, wenn die Richtlinie ausgelöst wird (z. B. "Deny", "Audit" oder "Append").
+#### **Schlüsselkonzepte**
+
+1. **Richtliniendefinition**: Eine Regel, die in JSON geschrieben ist und angibt, was erlaubt oder erforderlich ist.
+2. **Richtlinienzuweisung**: Die Anwendung einer Richtlinie auf einen bestimmten Geltungsbereich (z. B. Abonnement, Ressourcengruppe).
+3. **Initiativen**: Eine Sammlung von Richtlinien, die zusammengefasst sind, um eine breitere Durchsetzung zu ermöglichen.
+4. **Wirkung**: Gibt an, was passiert, wenn die Richtlinie ausgelöst wird (z. B. "Verweigern", "Überprüfen" oder "Anhängen").
 
 **Einige Beispiele:**
 
-1. **Sicherstellen der Einhaltung bestimmter Azure-Regionen**: Diese Richtlinie stellt sicher, dass alle Ressourcen in bestimmten Azure-Regionen bereitgestellt werden. Zum Beispiel möchte ein Unternehmen möglicherweise sicherstellen, dass alle seine Daten in Europa für die Einhaltung der DSGVO gespeichert werden.
+1. **Sicherstellen der Einhaltung bestimmter Azure-Regionen**: Diese Richtlinie stellt sicher, dass alle Ressourcen in bestimmten Azure-Regionen bereitgestellt werden. Zum Beispiel möchte ein Unternehmen sicherstellen, dass alle seine Daten in Europa für die Einhaltung der DSGVO gespeichert werden.
 2. **Durchsetzung von Namensstandards**: Richtlinien können Namenskonventionen für Azure-Ressourcen durchsetzen. Dies hilft bei der Organisation und der einfachen Identifizierung von Ressourcen basierend auf ihren Namen, was in großen Umgebungen hilfreich ist.
 3. **Einschränkung bestimmter Ressourcentypen**: Diese Richtlinie kann die Erstellung bestimmter Ressourcentypen einschränken. Zum Beispiel könnte eine Richtlinie festgelegt werden, um die Erstellung teurer Ressourcentypen, wie bestimmter VM-Größen, zur Kostenkontrolle zu verhindern.
 4. **Durchsetzung von Tagging-Richtlinien**: Tags sind Schlüssel-Wert-Paare, die mit Azure-Ressourcen verknüpft sind und für das Ressourcenmanagement verwendet werden. Richtlinien können durchsetzen, dass bestimmte Tags vorhanden sein müssen oder spezifische Werte haben müssen, für alle Ressourcen. Dies ist nützlich für die Kostenverfolgung, den Besitz oder die Kategorisierung von Ressourcen.
 5. **Einschränkung des öffentlichen Zugriffs auf Ressourcen**: Richtlinien können durchsetzen, dass bestimmte Ressourcen, wie Speicherkonten oder Datenbanken, keine öffentlichen Endpunkte haben, um sicherzustellen, dass sie nur innerhalb des Netzwerks der Organisation zugänglich sind.
 6. **Automatisches Anwenden von Sicherheitseinstellungen**: Richtlinien können verwendet werden, um automatisch Sicherheitseinstellungen auf Ressourcen anzuwenden, wie das Anwenden einer bestimmten Netzwerksicherheitsgruppe auf alle VMs oder das Sicherstellen, dass alle Speicherkonten Verschlüsselung verwenden.
 
-Beachten Sie, dass Azure Policies an jedem Level der Azure-Hierarchie angehängt werden können, aber sie werden **häufig in der Root-Management-Gruppe** oder in anderen Management-Gruppen verwendet.
+Beachten Sie, dass Azure-Richtlinien an jedem Level der Azure-Hierarchie angehängt werden können, aber sie werden **häufig in der Root-Management-Gruppe** oder in anderen Managementgruppen verwendet.
 
-Azure policy json example:
+Azure-Richtlinien JSON-Beispiel:
 ```json
 {
 "policyRule": {
@@ -379,7 +372,7 @@ Diese hierarchische Struktur ermöglicht eine effiziente und skalierbare Verwalt
 
 ### Azure RBAC vs ABAC
 
-**RBAC** (rollenbasierte Zugriffskontrolle) ist das, was wir bereits in den vorherigen Abschnitten gesehen haben: **Zuweisung einer Rolle an ein Subjekt, um ihm Zugriff** auf eine Ressource zu gewähren.\
+**RBAC** (rollenbasierte Zugriffskontrolle) ist das, was wir bereits in den vorherigen Abschnitten gesehen haben: **Zuweisen einer Rolle zu einem Subjekt, um ihm Zugriff** auf eine Ressource zu gewähren.\
 In einigen Fällen möchten Sie jedoch möglicherweise **feinere Zugriffsverwaltung** bereitstellen oder die Verwaltung von **Hunderte** von Rollen **zuweisungen** **vereinfachen**.
 
 Azure **ABAC** (attributbasierte Zugriffskontrolle) baut auf Azure RBAC auf, indem es **Bedingungen für die Rollen zuweisung basierend auf Attributen** im Kontext spezifischer Aktionen hinzufügt. Eine _Bedingung für die Rollen zuweisung_ ist eine **zusätzliche Überprüfung, die Sie optional zu Ihrer Rollen zuweisung hinzufügen können**, um eine feinere Zugriffskontrolle zu bieten. Eine Bedingung filtert die Berechtigungen, die als Teil der Rollendefinition und der Rollen zuweisung gewährt werden. Zum Beispiel können Sie **eine Bedingung hinzufügen, die erfordert, dass ein Objekt ein bestimmtes Tag hat, um das Objekt zu lesen**.\