Wiederholung von Sicherheit, Identität und Governance

Für die Prüfung wichtige Fakten zu Entra ID: Entra ID (früher Azure AD) ist der cloudbasierte Identitätsdienst von Microsoft — und nicht mit dem lokalen Active Directory Domain Services (AD DS) gleichzusetzen. Ein Mandant in Entra ID stellt eine cloudbasierte Identitätsinstanz einer Organisation dar. Ein Mandant kann mehrere Abonnements haben, aber jedes Abonnement vertraut genau einem Mandanten. Wichtige Objekte: Benutzer (individuelle Konten), Gruppen (Sammlungen von Benutzern oder Geräten), Dienstprinzipale (Anwendungsidentitäten) und verwaltete Identitäten (von Azure verwaltete Dienstprinzipale).

Eine bei AZ-900 häufig verwechselte Unterscheidung: Azure RBAC steuert den Zugriff auf Azure-Ressourcen (VMs, Speicherkonten, Ressourcengruppen) und gilt für Abonnements, Ressourcengruppen oder einzelne Ressourcen. Entra-ID-Rollen steuern den Zugriff auf Entra-ID-Objekte (Benutzer, Gruppen, Anwendungen, Geräte) und gelten innerhalb des Entra-ID-Mandanten. Ein Global Administrator in Entra ID hat nicht automatisch Zugriff auf Azure-Abonnements. Ein Contributor in Azure RBAC kann keine Entra-ID-Benutzer verwalten. Die beiden Rollensysteme sind voneinander getrennt.

Multi-Factor Authentication (MFA) verlangt von Benutzern, ihre Identität mit mindestens zwei Faktoren zu bestätigen: etwas, das sie wissen (Kennwort), besitzen (Authentifizierungs-App, SMS) oder sind (biometrisches Merkmal). In Entra ID wird MFA über Richtlinien für bedingten Zugriff erzwungen. Eine Richtlinie für bedingten Zugriff wertet Signale aus (Benutzeridentität, Gerätekonformität, Standort, aufgerufene App) und setzt anschließend Zugriffssteuerungen durch (MFA verlangen, Zugriff blockieren, konformes Gerät verlangen). In der Prüfung wird gefragt, welche Entra-ID-Lizenzstufe bedingten Zugriff umfasst — die Antwort lautet Entra ID P1 oder höher.

Das Zero-Trust-Sicherheitsmodell von Microsoft basiert auf drei Prinzipien: Explizit überprüfen — jede Anforderung anhand aller verfügbaren Datenpunkte authentifizieren und autorisieren (Identität, Standort, Gerät, Dienst, Datenklassifizierung). Zugriff mit geringstmöglichen Berechtigungen verwenden — den Benutzerzugriff mithilfe von Just-in-Time- und Just-Enough-Access sowie risikobasierten adaptiven Richtlinien begrenzen. Von einer Sicherheitsverletzung ausgehen — den Wirkungsbereich durch Mikrosegmentierung von Netzwerken und durchgehende Verschlüsselung minimieren sowie mithilfe von Analysen Transparenz schaffen und die Erkennung von Bedrohungen vorantreiben. In der AZ-900-Prüfung müssen Sie Zero-Trust-Prinzipien in Szenariofragen erkennen.

Wichtige Prüfungspunkte zu Defender for Cloud: Der Dienst stellt einen Secure Score bereit — einen Prozentsatz, der zeigt, wie gut Ihre Umgebung den Sicherheitsempfehlungen von Microsoft entspricht. Empfehlungen sind in Sicherheitskontrollen gruppiert (z. B. „Sicherheitskonfigurationen beheben“ und „Erweiterte Datensicherheit implementieren“). Defender for Cloud funktioniert in Azure, lokalen Umgebungen (über Azure Arc) und anderen Clouds. Es gibt zwei Modi: Free (nur grundlegendes CSPM und Sicherheitsempfehlungen) und Defender-Pläne (kostenpflichtig, ergänzt erweiterten Bedrohungsschutz je nach Workloadtyp — VMs, SQL, Storage, Container usw.).

Prüfungsfakten zu Azure Key Vault: Key Vault speichert drei Arten von Objekten — Secrets (Kennwörter, Verbindungszeichenfolgen), Keys (RSA- oder EC-Schlüssel für Verschlüsselungsvorgänge) und Certificates (X.509-Zertifikate mit Lebenszyklusverwaltung). Der Zugriff auf Key Vault wird durch RBAC (neuere, empfohlene Option) oder das ältere Modell der Key Vault-Zugriffsrichtlinien gesteuert. Key Vault lässt sich in verwaltete Identitäten integrieren, sodass Anwendungen niemals Anmeldeinformationen speichern müssen. Key Vault verfügt über zwei Tarife: Standard (softwaregeschützte Schlüssel) und Premium (durch HSMs nach FIPS 140-2 Level 2 geschützte Schlüssel).

Prüfungspunkte zu Azure Policy: Eine Richtliniendefinition legt fest, was ausgewertet werden soll und welche Aktion auszuführen ist (Audit, Deny, DeployIfNotExists, Modify). Eine Richtlinienzuweisung wendet eine Definition auf einen Bereich an (Verwaltungsgruppe, Abonnement oder Ressourcengruppe). Eine Richtlinieninitiative (auch Richtliniensatz genannt) fasst mehrere Definitionen zusammen. Der Effekt DeployIfNotExists ist besonders — er stellt automatisch eine Ressource zur Behebung bereit, wenn die Bedingung erfüllt ist (z. B. einen Log Analytics-Agent für VMs bereitstellen, auf denen dieser fehlt). Konformitätsergebnisse werden im Konformitätsdashboard als Prozentsätze angezeigt.

Fakten zu Verwaltungsgruppen: Unterhalb der Stamminstanz können Sie Verwaltungsgruppen bis zu 6 Ebenen tief verschachteln. Die Tenant Root Group ist die oberste Verwaltungsgruppe und wird automatisch erstellt. Auf Ebene einer Verwaltungsgruppe vorgenommene Richtlinien- und RBAC-Zuweisungen werden von allen untergeordneten Verwaltungsgruppen und darunterliegenden Abonnements geerbt. Ein übliches Unternehmensdesign lautet: Stamm → Platform (Abonnements für Konnektivität, Identität und Verwaltung) → Landing Zones (Produktion, Nichtproduktion) → produktspezifische Abonnements. Diese Hierarchie ermöglicht Governance im großen Maßstab.

Fakten zu Ressourcensperren: Die Sperre CanNotDelete erlaubt das Lesen und Ändern, verhindert aber das Löschen. Die Sperre ReadOnly erlaubt ausschließlich Lesevorgänge — keine Änderungen oder Löschungen. Sperren können auf Abonnement-, Ressourcengruppen- oder Ressourcenebene angewendet werden und werden von untergeordneten Ressourcen geerbt. Nur die Rollen Owner und User Access Administrator können Sperren erstellen oder löschen. Ressourcentags sind Schlüssel-Wert-Metadatenpaare; sie werden im Gegensatz zu Sperren und Richtlinien NICHT geerbt. Pro Ressource sind bis zu 50 Tags zulässig, mit einer maximalen Länge von 512 Zeichen für den Tagnamen und 256 Zeichen für den Wert.

Netzwerksicherheitsdienste für AZ-900: Azure DDoS Protection Basic ist kostenlos und schützt automatisch alle Azure-Ressourcen vor häufigen DDoS-Angriffen auf Layer 3 und Layer 4. Azure DDoS Protection Standard ist kostenpflichtig (ca. 2.944 USD/Monat pro geschütztem VNet), bietet adaptive Anpassung, Echtzeitmetriken zu Angriffen und Analysen nach Angriffen. Azure Firewall ist eine verwaltete zustandsbehaftete Firewall mit integrierter Hochverfügbarkeit und automatischer Skalierung — sie ist keine NSG. Azure Firewall arbeitet auf Layer 7 (Anwendungsregeln mit FQDN-Filterung), während NSGs auf Layer 4 arbeiten (Port-/IP-Regeln).

Typische Szenarien für Sicherheitsfragen in AZ-900:

• Versehentliches Löschen einer VM verhindern → Ressourcensperre (CanNotDelete)
• Für alle Ressourcen ein CostCentre-Tag erzwingen → Azure Policy (Deny-Effekt)
• Benachrichtigt werden, wenn sich ein Benutzer von einem ungewöhnlichen Standort anmeldet → Entra ID Identity Protection / bedingter Zugriff
• Das Datenbankkennwort einer Anwendung sicher speichern → Azure Key Vault Secret
• Sicherheitsempfehlungen und den Konformitätswert anzeigen → Microsoft Defender for Cloud Secure Score
• Bedrohungen in Überwachungsprotokollen eines Abonnements erkennen → Microsoft Sentinel

Testen Sie Ihr Verständnis der in dieser Lektion behandelten Konzepte von Microsoft Azure Fundamentals (AZ-900).

In dieser Lektion haben Sie Folgendes wiederholt: Entra ID im Vergleich zu Azure RBAC (zwei getrennte Zugriffssteuerungssysteme für Cloudidentität bzw. Azure-Ressourcen), Defender for Cloud Secure Score (misst die Sicherheitslage und stellt Empfehlungen bereit) und ReadOnly-Sperren setzen sich gegenüber RBAC durch (selbst Owner können keine Schreibvorgänge an ReadOnly-gesperrten Ressourcen durchführen). Als Nächstes behandeln wir Prüfungsstrategie und Zeitmanagement für AZ-900.