Az - Grundinformationen

Reading time: 21 minutes

Organisationshierarchie

Verwaltungsguppen

• Es 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 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 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.

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 Root-Verwaltungsguppe sein), da Abonnements keine anderen Abonnements enthalten können.
• Es vertraut nur einem Entra ID-Verzeichnis.
• Berechtigungen, die auf der Abonnement-Ebene (oder einer seiner Eltern) angewendet werden, werden auf alle Ressourcen innerhalb des Abonnements vererbt.

Ressourcengruppen

Aus den Dokumenten: Eine Ressourcengruppe ist ein Container, der verwandte Ressourcen für eine Azure-Lösung enthält. Die Ressourcengruppe kann alle Ressourcen für die Lösung oder nur die Ressourcen, die Sie als Gruppe verwalten möchten, umfassen. Im Allgemeinen fügen Sie Ressourcen hinzu, die den gleichen Lebenszyklus teilen, zur gleichen Ressourcengruppe hinzu, damit Sie sie einfach als Gruppe bereitstellen, aktualisieren und löschen können.

Alle Ressourcen müssen innerhalb einer Ressourcengruppe sein und können nur zu einer Gruppe gehören. Wenn eine Ressourcengruppe gelöscht wird, werden auch alle Ressourcen darin gelöscht.

Azure-Ressourcen-IDs

Jede Ressource in Azure hat eine Azure-Ressourcen-ID, die sie identifiziert.

Das Format einer Azure-Ressourcen-ID ist wie folgt:

• /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{resourceProviderNamespace}/{resourceType}/{resourceName}

Für eine virtuelle Maschine mit dem Namen myVM in einer Ressourcengruppe myResourceGroup unter der Abonnement-ID 12345678-1234-1234-1234-123456789012 sieht die Azure-Ressourcen-ID so aus:

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

Azure vs Entra ID vs Azure AD-Domänendienste

Azure

Azure ist Microsofts umfassende Cloud-Computing-Plattform, die eine Vielzahl von Diensten anbietet, darunter virtuelle Maschinen, Datenbanken, künstliche Intelligenz und Speicher. Es dient als Grundlage für das Hosting und die Verwaltung von Anwendungen, den Aufbau skalierbarer Infrastrukturen und das Ausführen moderner Workloads in der Cloud. Azure bietet Entwicklern und IT-Profis Werkzeuge, um Anwendungen und Dienste nahtlos zu erstellen, bereitzustellen und zu verwalten, und erfüllt eine Vielzahl von Bedürfnissen von Startups bis hin zu großen Unternehmen.

Entra ID (ehemals Azure Active Directory)

Entra ID ist ein cloudbasierter Identitäts- und Zugriffsverwaltungsdienst, der für die Handhabung von Authentifizierung, Autorisierung und Benutzerzugriffskontrolle entwickelt wurde. Er ermöglicht sicheren Zugriff auf Microsoft-Dienste wie Office 365, Azure und viele Drittanbieter-SaaS-Anwendungen. Mit Funktionen wie Single Sign-On (SSO), Multi-Faktor-Authentifizierung (MFA) und bedingten Zugriffsrichtlinien unter anderem.

Entra-Domänendienste (ehemals Azure AD DS)

Entra-Domänendienste erweitern die Funktionen von Entra ID, indem sie verwaltete Domänendienste anbieten, die mit traditionellen Windows Active Directory-Umgebungen kompatibel sind. Es unterstützt veraltete Protokolle wie LDAP, Kerberos und NTLM, sodass Organisationen ältere Anwendungen in der Cloud migrieren oder ausführen können, ohne lokale Domänencontroller bereitzustellen. Dieser Dienst unterstützt auch Gruppenrichtlinien für eine zentrale Verwaltung, was ihn für Szenarien geeignet macht, in denen veraltete oder AD-basierte Workloads mit modernen Cloud-Umgebungen koexistieren müssen.

Entra ID-Prinzipale

Benutzer

• Neue Benutzer
• E-Mail-Namen und Domäne aus dem ausgewählten Mandanten angeben
• Anzeigename angeben
• Passwort angeben
• Eigenschaften angeben (Vorname, Berufsbezeichnung, Kontaktinformationen…)
• Standardbenutzertyp ist “Mitglied”
• Externe Benutzer
• E-Mail angeben, um einzuladen, und Anzeigename (kann eine Nicht-Microsoft-E-Mail sein)
• Eigenschaften angeben
• Standardbenutzertyp ist “Gast”

Standardberechtigungen für Mitglieder & Gäste

Sie können sie in https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions überprüfen, aber unter anderem kann ein Mitglied:

• Alle Benutzer, Gruppen, Anwendungen, Geräte, Rollen, Abonnements und deren öffentliche Eigenschaften lesen
• Gäste einladen (kann deaktiviert werden)
• Sicherheitsgruppen erstellen
• Nicht versteckte Gruppenmitgliedschaften lesen
• Gäste zu eigenen Gruppen hinzufügen
• Neue Anwendung erstellen (kann deaktiviert werden)
• Bis zu 50 Geräte zu Azure hinzufügen (kann deaktiviert werden)

Standardkonfigurierbare Berechtigungen für Benutzer

• Mitglieder (docs)
• Anwendungen registrieren: Standard Ja
• Einschränkung nicht administrativer Benutzer bei der Erstellung von Mandanten: Standard Nein
• Sicherheitsgruppen erstellen: Standard Ja
• Zugriff auf das Microsoft Entra-Verwaltungsportal einschränken: Standard Nein
• Dies schränkt den API-Zugriff auf das Portal nicht ein (nur Web)
• Benutzern erlauben, Arbeits- oder Schulkonten mit LinkedIn zu verbinden: Standard Ja
• Benutzer angemeldet halten: Standard Ja
• Benutzern die Wiederherstellung des BitLocker-Schlüssels für ihre eigenen Geräte verweigern: Standard Nein (Überprüfung in den Geräteeinstellungen)
• Andere Benutzer lesen: Standard Ja (über Microsoft Graph)
• 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 über andere 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
• 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
• Externen Benutzern erlauben, die Organisation zu verlassen

Gruppen

Es gibt 2 Arten von Gruppen:

• Sicherheit: Diese Art von Gruppe wird verwendet, um Mitgliedern Zugriff auf Anwendungen, Ressourcen zu gewähren und Lizenzen zuzuweisen. Benutzer, Geräte, Dienstprinzipale und andere Gruppen können Mitglieder sein.
• Microsoft 365: Diese Art von Gruppe wird für die Zusammenarbeit verwendet und gewährt Mitgliedern Zugriff auf ein gemeinsames Postfach, Kalender, Dateien, SharePoint-Website usw. Gruppenmitglieder können nur Benutzer sein.
• Dies wird eine E-Mail-Adresse mit der Domäne des EntraID-Mandanten haben.

Es gibt 2 Arten von Mitgliedschaften:

• Zugewiesen: Ermöglicht das manuelle Hinzufügen spezifischer Mitglieder zu einer Gruppe.
• Dynamische Mitgliedschaft: Verwaltet die Mitgliedschaft automatisch mithilfe von Regeln und aktualisiert die Gruppenaufnahme, wenn sich die Attribute der Mitglieder ändern.

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 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.

• 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 Zertifikatsauthentifizierung wählen, stellen Sie sicher, dass die Anwendung Zugriff auf den privaten Schlüssel hat.

App-Registrierungen

Eine App-Registrierung ist eine Konfiguration, die es einer Anwendung ermöglicht, sich mit Entra ID zu integrieren und Aktionen auszuführen.

Schlüsselkomponenten:

1. Anwendungs-ID (Client-ID): Eine eindeutige Kennung für Ihre App in Azure AD.
2. Umleitungs-URIs: URLs, an die Azure AD Authentifizierungsantworten sendet.
3. Zertifikate, Geheimnisse & föderierte Anmeldeinformationen: Es ist möglich, ein Geheimnis oder ein Zertifikat zu generieren, um sich als Dienstprinzipal der Anwendung anzumelden oder um ihr föderierten Zugriff zu gewähren (z. B. Github Actions).
4. Wenn ein Zertifikat oder Geheimnis generiert wird, ist es einer Person möglich, sich als Dienstprinzipal mit CLI-Tools anzumelden, indem sie die Anwendungs-ID, das Geheimnis oder Zertifikat und den Mandanten (Domäne oder ID) kennt.
5. API-Berechtigungen: Gibt an, auf welche Ressourcen oder APIs die App zugreifen kann.
6. Authentifizierungseinstellungen: Definiert die unterstützten Authentifizierungsflüsse der App (z. B. OAuth2, OpenID Connect).
7. Dienstprinzipal: Ein Dienstprinzipal wird erstellt, wenn eine App erstellt wird (wenn dies über die Webkonsole erfolgt) oder wenn sie in einem neuen Mandanten installiert wird.
8. Der Dienstprinzipal erhält alle angeforderten Berechtigungen, mit denen er konfiguriert wurde.

Standardzustimmungsberechtigungen

Benutzereinwilligung für Anwendungen

• Benutzereinwilligung nicht zulassen
• Ein Administrator wird für alle Apps erforderlich sein.
• Benutzereinwilligung für Apps von verifizierten Herausgebern, internen Apps und Apps, die nur ausgewählte Berechtigungen anfordern, zulassen (empfohlen)
• Alle Benutzer können Apps zustimmen, die nur Berechtigungen anfordern, die als "geringfügig" eingestuft sind, Apps von verifizierten Herausgebern und Apps, die im Mandanten registriert sind.
• Standard geringfügige Berechtigungen (obwohl Sie akzeptieren 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)
• 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.

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 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, der von dem Abonnement, in dem sich die Ressource befindet, vertraut wird. 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, der von dem Abonnement vertraut wird. 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.

Unternehmensanwendungen

Es ist einfach eine Tabelle in Azure, um Dienstprinzipale zu filtern und die Anwendungen zu überprüfen, die zugewiesen wurden.

Es ist kein anderer Typ von "Anwendung", es gibt kein Objekt in Azure, das eine "Unternehmensanwendung" ist, es ist nur eine Abstraktion, um die Dienstprinzipale, App-Registrierungen und verwalteten Identitäten zu überprüfen.

Verwaltungseinheiten

Verwaltungseinheiten ermöglichen es, Berechtigungen aus einer Rolle über einen bestimmten Teil einer Organisation zu erteilen.

Beispiel:

• Szenario: Ein Unternehmen möchte, dass regionale IT-Administratoren nur die Benutzer in ihrer eigenen Region verwalten.
• 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 unterstützen dynamische Mitgliedschaften.
• AUs können keine AUs enthalten.
• Administratorrollen zuweisen:
• Gewähren Sie dem regionalen IT-Personal die Rolle "Benutzeradministrator", die auf die AU ihrer Region beschränkt ist.
• Ergebnis: Regionale IT-Administratoren können Benutzerkonten innerhalb ihrer Region verwalten, ohne andere Regionen zu beeinträchtigen.

Entra ID-Rollen & Berechtigungen

• Um Entra ID zu verwalten, gibt es einige vordefinierte Rollen, die Entra ID-Prinzipalen zugewiesen werden können, um Entra ID zu verwalten.
• Überprüfen Sie die Rollen in https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference.
• Rollen, die von EntraID als PRIVILEGED gekennzeichnet sind, sollten mit Vorsicht zugewiesen werden, da Microsoft in den Dokumenten erklärt in den docs: Privilegierte Rollenzuweisungen können zu einer Erhöhung der Berechtigungen führen, wenn sie nicht sicher und beabsichtigt verwendet werden.
• Die privilegierteste Rolle ist Global Administrator.
• Rollen gruppieren feingranulare Berechtigungen, die in ihren Beschreibungen zu finden sind.
• Es ist möglich, benutzerdefinierte Rollen mit den gewünschten Berechtigungen zu erstellen. Obwohl aus irgendeinem Grund nicht alle feingranularen Berechtigungen für Administratoren verfügbar sind, um benutzerdefinierte Rollen zu erstellen.
• Rollen in Entra ID sind vollständig unabhängig von Rollen in Azure. Die einzige Beziehung besteht darin, dass Prinzipale mit der Rolle Global Administrator in Entra ID zur Rolle User Access Administrator in Azure aufsteigen können.
• Es ist nicht möglich, Platzhalter in Entra ID-Rollen zu verwenden.

Azure-Rollen & Berechtigungen

• Rollen werden Prinzipalen auf einem Bereich zugewiesen: principal -[HAS ROLE]->(scope)
• Rollen, die Gruppen zugewiesen sind, werden von allen Mitgliedern der Gruppe vererbt.
• Abhängig von dem Bereich, dem die Rolle zugewiesen wurde, kann die Rolle auf andere Ressourcen innerhalb des Bereichscontainers vererbt werden. Zum Beispiel, wenn ein Benutzer A eine Rolle im Abonnement hat, hat er diese Rolle in allen Ressourcengruppen innerhalb des Abonnements und auf allen Ressourcen innerhalb der Ressourcengruppe.

Eingebaute Rollen

Aus den Dokumenten: Azure-Rollenbasierte Zugriffskontrolle (Azure RBAC) 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 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:

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.
• Finden Sie hier eine Liste mit allen Entra ID-eingebauten Rollen.

Benutzerdefinierte Rollen

• Es ist auch möglich, benutzerdefinierte Rollen zu erstellen.
• Sie werden innerhalb eines Bereichs erstellt, obwohl eine Rolle in mehreren Bereichen (Verwaltungsgruppen, Abonnements und Ressourcengruppen) sein kann.
• Es ist möglich, alle feingranularen Berechtigungen zu konfigurieren, die die benutzerdefinierte Rolle haben wird.
• Es ist möglich, Berechtigungen auszuschließen.
• Ein Prinzipal mit einer ausgeschlossenen Berechtigung kann sie nicht verwenden, selbst wenn die Berechtigung anderswo gewährt wird.
• Es ist möglich, Platzhalter zu verwenden.
• Das verwendete Format ist JSON.
• actions beziehen sich auf Berechtigungen für Verwaltungsoperationen an Ressourcen, wie das Erstellen, Aktualisieren oder Löschen von Ressourcen-Definitionen und -Einstellungen.
• dataActions sind Berechtigungen für Datenoperationen innerhalb der Ressource, die es Ihnen ermöglichen, die tatsächlichen Daten, die in der Ressource enthalten sind, zu lesen, zu schreiben oder zu löschen.
• notActions und notDataActions werden verwendet, um spezifische Berechtigungen von der Rolle auszuschließen. Sie verweigern sie jedoch nicht, wenn eine andere Rolle sie gewährt, hat der Prinzipal sie.
• assignableScopes ist ein Array von Bereichen, in denen die Rolle zugewiesen werden kann (wie Verwaltungsgruppen, Abonnements oder Ressourcengruppen).

Beispiel für Berechtigungen JSON für eine benutzerdefinierte Rolle:

{
"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": []
}
]
}
}

Berechtigungsreihenfolge

• 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.

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.

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

Zuweisungsbedingungen & MFA

Laut den Dokumenten: Derzeit können Bedingungen zu integrierten oder benutzerdefinierten Rollenzuweisungen hinzugefügt werden, die Blob-Speicherdatenaktionen oder Warteschlangen-Speicherdatenaktionen haben.

Ablehnungszuweisungen

Ä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.

Ä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-Richtlinien

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.

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.

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. "Ablehnen", "Ü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 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-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-Richtlinien JSON-Beispiel:

{
"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"
}

Berechtigungsübertragung

In Azure können Berechtigungen jedem Teil der Hierarchie zugewiesen werden. Dazu gehören Verwaltungseinheiten, Abonnements, Ressourcengruppen und einzelne Ressourcen. Berechtigungen werden von enthaltenen Ressourcen der Entität, wo sie zugewiesen wurden, vererbt.

Diese hierarchische Struktur ermöglicht eine effiziente und skalierbare Verwaltung von Zugriffsberechtigungen.

Azure RBAC vs ABAC

RBAC (rollenbasierte Zugriffskontrolle) ist das, was wir bereits in den vorherigen Abschnitten gesehen haben: Zuweisen einer Rolle an ein 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 Rollen zuweisungsbedingungen basierend auf Attributen im Kontext spezifischer Aktionen hinzufügt. Eine Rollen zuweisungsbedingung 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.
Sie können den Zugriff auf spezifische Ressourcen nicht ausdrücklich verweigern mit Bedingungen.

Referenzen

• 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://abouttmc.com/glossary/azure-subscription/#:~:text=An%20Azure%20subscription%20is%20a,the%20subscription%20it%20belongs%20to.
• https://learn.microsoft.com/en-us/azure/role-based-access-control/overview#how-azure-rbac-determines-if-a-user-has-access-to-a-resource
• https://stackoverflow.com/questions/65922566/what-are-the-differences-between-service-principal-and-app-registration