Azure Tenant-Härtung: Unsichere Defaults

Was Ist Azure Tenant-Härtung?

Microsoft aktiviert Security Defaults inzwischen automatisch für neue Microsoft 365- und Azure-Tenants — mit einer 24-Stunden-Karenzzeit vor der Durchsetzung, und nur wenn der Tenant noch keine Conditional-Access-Richtlinien oder Legacy-MFA pro Benutzer eingerichtet hat. In der Praxis laufen viele Produktions-Tenants weiterhin ohne echte Sicherheitsbaseline: Security Defaults wird deaktiviert, sobald ein Administrator beginnt, eine eigene Conditional-Access-Richtlinie aufzubauen, und die Ersatzrichtlinie wird nie fertiggestellt, Legacy-Authentifizierungsprotokolle bleiben erreichbar, Gasteinladungen stehen jedem Benutzer offen, und keine Conditional-Access-Richtlinie schließt die entstandenen Lücken.

Tenant-Härtung ist der Prozess der systematischen Überprüfung und Korrektur dieser Standardeinstellungen. Das ist keine glamouröse Arbeit, aber sie ist grundlegend: Jede andere Azure-Sicherheitskontrolle — Conditional Access, PIM, Identity Protection — hängt davon ab, dass die Tenant-Konfiguration korrekt ist.

Dieser Artikel behandelt die wichtigsten Prüfpunkte der Azure-Tenant-Konfiguration und zeigt, wie Sie sie validieren und korrigieren.

Wie Es Funktioniert

Die Azure-Tenant-Konfiguration wird an mehreren Stellen verwaltet:

• Entra ID > Eigenschaften — tenant-weite Einstellungen einschließlich Security Defaults
• Entra ID > Externe Identitäten — Einstellungen für Gäste und B2B-Zusammenarbeit
• Entra ID > Authentifizierungsmethoden — welche MFA-Methoden erlaubt sind
• Exchange Online Admin Center — Legacy-Auth-Einstellungen für E-Mail-Protokolle
• Microsoft 365 Admin Center — Sicherheitseinstellungen auf Dienstebene

Fehlkonfigurationen an jeder dieser Stellen können eine Angriffsfläche schaffen, die alle anderen Kontrollen umgeht. Eine perfekt konfigurierte Conditional-Access-Richtlinie ist irrelevant, wenn Legacy-Authentifizierung auf Exchange-Ebene weiterhin aktiviert ist.

Die Angriffskette

Ausnutzung Deaktivierter Security Defaults

Wenn Security Defaults deaktiviert sind und keine Conditional-Access-Richtlinie die Lücke schließt:

# Password Spraying gegen M365 ohne MFA-Baseline
o365spray --spray -U users.txt -P passwords.txt --domain corp.com

# Legacy-Auth-Bypass — IMAP-Zugriff ignoriert Conditional Access
curl -u [email protected]:Password1 imaps://outlook.office365.com/INBOX

Ausnutzung Offener B2B-Einstellungen

# Mit einem beliebigen Mitgliedskonto — vom Angreifer kontrollierte externe Identität einladen
New-MgInvitation -InvitedUserEmailAddress "[email protected]" `
    -InviteRedirectUrl "https://myapps.microsoft.com" `
    -SendInvitationMessage $false

Konfigurations-Audit-Checkliste

1. Security Defaults Status

Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgPolicyIdentitySecurityDefaultEnforcementPolicy | Select-Object IsEnabled
# Sollte True sein (wenn keine CA-Richtlinien vorhanden)

2. Status der Legacy-Authentifizierung

# Exchange-Online-Legacy-Auth-Richtlinien prüfen
Connect-ExchangeOnline
Get-AuthenticationPolicy | Select-Object Name, AllowBasicAuth*
# Alle AllowBasicAuth*-Werte sollten False sein

3. Gasteinladungseinstellungen

# Prüfen, wer Gäste einladen darf
Get-MgPolicyAuthorizationPolicy | Select-Object AllowInvitesFrom
# Gültige Werte: none, adminsAndGuestInviters, adminsGuestInvitersAndAllMembers, everyone
# Sollte sein: none oder adminsAndGuestInviters

4. Richtlinie für Authentifizierungsmethoden

# Aktivierte Authentifizierungsmethoden auflisten
Get-MgPolicyAuthenticationMethodPolicy | Select-Object -ExpandProperty AuthenticationMethodConfigurations |
    Where-Object {$_.State -eq "enabled"} | Select-Object Id, State
# Sicherstellen, dass SMS nicht die einzige MFA-Methode ist (phishbar) — Authenticator App oder FIDO2 bevorzugen

5. Cross-Tenant-Zugriffseinstellungen

# Prüfen, ob eingehende B2B-Zusammenarbeit für alle externen Organisationen offen ist
Get-MgPolicyCrossTenantAccessPolicyDefault | Select-Object -ExpandProperty B2BCollaborationInbound |
    Select-Object -ExpandProperty UsersAndGroups
# AccessType sollte für das Ziel "AllUsers" nicht ohne zusätzliche Einschränkungen "allowed" sein

Erkennung

Microsoft 365 Secure Score

Microsoft 365 Secure Score liefert eine automatisierte Bewertung der Tenant-Konfiguration gegenüber der von Microsoft empfohlenen Baseline. Zu finden unter security.microsoft.com > Secure Score.

Microsoft deckelt jede empfohlene Aktion bei maximal 10 Punkten und bewertet viele davon als Prozentsatz Ihrer Tenant-Konfiguration statt mit einem festen Wert — es gibt keinen universellen Punktwert pro Aktion. Beispiele aus Microsofts eigener Scoring-Anleitung: MFA für administrative Rollen verpflichtend zu machen ist 10 Punkte wert, sicherzustellen, dass alle Benutzer MFA abschließen können, ist 9 Punkte wert, und Legacy-Authentifizierung per Conditional Access zu blockieren ist 7 Punkte wert. Gasteinladungen einzuschränken und Privileged Identity Management zu aktivieren erhöhen den Score ebenfalls — die genauen Werte für Ihren Tenant finden Sie in der Empfehlungsliste von Secure Score selbst.

Entra ID Audit-Protokolle

// Deaktivierung von Security Defaults erkennen
AuditLogs
| where OperationName == "Update security defaults"
| mv-expand props = TargetResources.modifiedProperties
| where tostring(props.newValue) has "false"

Remediation

Security Defaults Aktivieren (Falls Kein Conditional Access)

Entra ID > Eigenschaften > Security Defaults verwalten > Aktiviert = Ja

Legacy-Authentifizierung Global Deaktivieren

# Authentifizierungsrichtlinie erstellen, die jegliche Basic-Auth blockiert
New-AuthenticationPolicy -Name "Block Basic Auth"
Set-AuthenticationPolicy -Identity "Block Basic Auth" `
    -AllowBasicAuthImap $false -AllowBasicAuthPop $false `
    -AllowBasicAuthSmtp $false -AllowBasicAuthWebServices $false `
    -AllowBasicAuthRpc $false -AllowBasicAuthMapi $false

# Auf alle Benutzer anwenden
Get-User -ResultSize Unlimited | Set-User -AuthenticationPolicy "Block Basic Auth"

Gasteinladungen Einschränken

Entra ID > Externe Identitäten > Einstellungen für externe Zusammenarbeit:
Gasteinladungseinstellungen = "Nur Benutzer mit bestimmten Admin-Rollen können einladen"

Phishing-Resistente MFA-Methoden Aktivieren

Entra ID > Authentifizierungsmethoden > FIDO2-Sicherheitsschlüssel = Aktiviert (für alle oder Admins)
Entra ID > Authentifizierungsmethoden > Microsoft Authenticator = Aktiviert
Entra ID > Authentifizierungsmethoden > SMS = Deaktiviert (phishbar, durch Authenticator ersetzen)

So Erkennt EtcSec Dies

EtcSec prüft Ihre komplette Azure-Tenant-Konfiguration bei jedem Scan und kontrolliert jede Einstellung, die die Sicherheitsbaseline beeinflusst.

AZ_SECURITY_DEFAULTS_DISABLED kennzeichnet Tenants, bei denen Security Defaults deaktiviert sind — eine grundlegende Baseline-Lücke, die tenant-weite Schutzmaßnahmen wie die verpflichtende Basis-MFA entfernt.

CA_NO_LEGACY_AUTH_BLOCK kennzeichnet das Fehlen einer Conditional-Access-Richtlinie, die Legacy-Authentifizierungsprotokolle blockiert, und lässt damit einen MFA-Bypass für jeden Angreifer mit einem gestohlenen Passwort offen.

GUEST_INVITATION_UNRESTRICTED kennzeichnet Tenants, bei denen die Gasteinladungsrichtlinie es jedem Benutzer erlaubt, externe Gäste einzuladen, statt Einladungen auf Admins oder bestimmte Rollen zu beschränken.

Review-Prioritäten

Azure Tenant-Härtung: Behebung unsicherer Standardkonfigurationen ab Werk sollte als reale Exposition innerhalb Ihres Entra-ID- und Azure-Tenants behandelt werden, nicht als einzelne isolierte Einstellung. Definieren Sie zuerst den Prüfumfang: welche Admins, Gäste, Service Principals, App-Registrierungen, Richtlinienausnahmen und Break-Glass-Konten betroffen sind, welche Geschäftsabläufe davon abhängen, welche Privilegien sie offenlegen, und welche Notfallausnahmen sich mit der Zeit angesammelt haben. Dieser Schritt verhindert oberflächliche Remediation, weil das technische Symptom oft kleiner ist als der operative Blast Radius. Indem das Team den gesamten Pfad von Konfiguration zu Privileg dokumentiert, kann es Änderungen priorisieren, die Risiko schnell reduzieren, ohne den Produktivzugriff zu unterbrechen. Das schafft außerdem eine belastbare Baseline für spätere Validierung und gibt der Leitung eine klare Erklärung, warum das Thema jetzt relevant ist.

Benachbarte Kontrollen Prüfen

Wenn Angreifer Ihren Entra-ID- und Azure-Tenant erreichen, bleiben sie selten beim ersten Schwachpunkt stehen. Rund um Azure Tenant-Härtung: Behebung unsicherer Standardkonfigurationen ab Werk testen sie normalerweise, ob sich der exponierte Pfad mit Legacy-Authentifizierung, schwacher Gast-Governance, breiten App-Zustimmungen, veralteten Notfallkonten und nie überprüften Rollen verketten lässt. Das bedeutet, Verteidiger sollten nicht nur die Hauptschwäche prüfen, sondern jede benachbarte Abhängigkeit, die aus Zugriff Persistenz oder Rechteeskalation macht. Bestätigen Sie, welche Identitäten, Rollen, Berechtigungen und Vertrauensannahmen von einem motivierten Angreifer wiederverwendet werden können. Wenn eine Korrektur nur ein einzelnes Objekt schließt, während benachbarte Privilegpfade unangetastet bleiben, ändert sich das effektive Risiko kaum. Eine disziplinierte Prüfung solcher Verkettungsmöglichkeiten macht aus diesem Thema eine praktische Härtungsübung statt eines einmaligen Häkchens.

Belege und Telemetrie Sammeln

Eine belastbare Reaktion auf Azure Tenant-Härtung: Behebung unsicherer Standardkonfigurationen ab Werk braucht Belege, die sowohl von Engineering- als auch von Detection-Teams geprüft werden können. Ziehen Sie Anmeldeprotokolle, Audit-Logs, Änderungen an Rollenzuweisungen, Consent-Ereignisse, Änderungen an Anwendungs-Credentials und riskante Anmeldesignale heran, vergleichen Sie aktuelle Änderungen mit bekannten Wartungsfenstern und isolieren Sie Konten oder Systeme, deren Verhalten sich ohne klaren geschäftlichen Grund geändert hat. Nutzen Sie diese Belege, um drei Fragen zu beantworten: wann der riskante Pfad entstanden ist, wer ihn noch nutzen kann, und ob eine ähnliche Exposition an anderer Stelle in Ihrem Entra-ID- und Azure-Tenant existiert. Eine gute Telemetrie-Prüfung hilft außerdem, geerbte technische Schulden von aktivem Missbrauch zu unterscheiden. Diese Unterscheidung ist wichtig, weil der Remediationsplan für eine veraltete Fehlkonfiguration anders aussieht als der Plan für einen Pfad, der bereits angreiferähnliches Verhalten oder wiederholte Richtlinienausnahmen zeigt.

Benachbarte Schwachstellen, Die Es Wert Sind, Geprüft Zu Werden

Nur wenige Umgebungen enthalten Azure Tenant-Härtung: Behebung unsicherer Standardkonfigurationen ab Werk isoliert. In der Praxis enthält dasselbe Tenant- oder Verzeichnissegment oft auch Legacy-Authentifizierung, schwache Gast-Governance, breite App-Zustimmungen, veraltete Notfallkonten und nie überprüfte Rollen, und genau diese benachbarten Schwachstellen entscheiden, ob das Problem nur störend oder wirklich kritisch ist. Prüfen Sie gemeinsame Owner, geerbte Berechtigungen, doppelte Ausnahmen und langlebige administrative Abkürzungen. Prüfen Sie, ob dasselbe Team ähnliche riskante Muster an mehreren Stellen genehmigt hat, denn wiederholte Entscheidungen weisen meist auf eine Prozesslücke hin und nicht auf einen einzelnen technischen Fehler. Diese breitere Prüfung verhindert eine nur teilweise Bereinigung und erhöht die Chance, den gesamten Angriffspfad zu entfernen. Sie verbessert außerdem die Audit-Bereitschaft, weil sich der Endzustand leichter erklären und über die Zeit leichter überwachen lässt.

Remediation-Reihenfolge, Die Das Risiko Schnell Senkt

Bei Azure Tenant-Härtung: Behebung unsicherer Standardkonfigurationen ab Werk sollte die Remediation einer Reihenfolge folgen, die die Exposition reduziert, bevor sie Perfektion anstrebt. Entfernen Sie zuerst die am leichtesten ausnutzbaren Pfade zur Rechteausweitung, härten Sie danach die wertvollsten Identitäten oder Objekte, und bereinigen Sie erst danach sekundäre Hygieneprobleme. Nutzen Sie Conditional Access, PIM, Least Privilege, Access Reviews, Prüfungen der Anwendungs-Ownership, Genehmigungsworkflows und starke MFA als Kontrollset, das den Zielzustand definiert. Jede Änderung sollte einen Verantwortlichen, eine Rollback-Notiz und einen Validierungsschritt haben. Das verhindert, dass lange Projekte nach der ersten technischen Korrektur ins Stocken geraten. Wenn ein vollständiges Redesign nicht sofort möglich ist, dokumentieren Sie Zwischenkontrollen, die das Missbrauchspotenzial schon heute senken, und planen Sie die strukturelle Arbeit im nächsten wöchentlichen Betriebsreview und monatlichen Härtungsreview ein. Entscheidend ist eine messbare Risikoreduzierung, nicht kosmetische Compliance.

Validierung Nach Jeder Änderung

Nach jeder Änderung an einer Einstellung rund um Azure Tenant-Härtung: Behebung unsicherer Standardkonfigurationen ab Werk sollte das Ergebnis sowohl aus administrativer Sicht als auch aus der Perspektive eines Angreiferpfads validiert werden. Bestätigen Sie, dass die vorgesehenen Benutzer und Systeme weiterhin funktionieren, und belegen Sie anschließend, dass der gefährliche Pfad nicht mehr dieselbe Hebelwirkung bietet. Wiederholen Sie die Beleg-Sammlung anhand von Anmeldeprotokollen, Audit-Logs, Änderungen an Rollenzuweisungen, Consent-Ereignissen, Änderungen an Anwendungs-Credentials und riskanten Anmeldesignalen, prüfen Sie Genehmigungsprotokolle und kontrollieren Sie, ob benachbarte Objekte noch einen Umgehungsweg offenhalten. Die Validierung sollte außerdem eine einfache schriftliche Erfolgsdefinition enthalten, damit das Team weiß, was Abschluss bedeutet. In reifen Teams verhindert genau dieser Schritt Rückfälle: Die Korrektur gilt erst dann als akzeptiert, wenn der riskante Pfad geschlossen ist, der Geschäftsdienst weiterhin funktioniert und der resultierende Zustand dem tatsächlich gewünschten Härtungsziel entspricht.

Azure Tenant-Härtung: Validierung Vor Dem Abschluss

Eine belastbare Prüfung der Azure Tenant-Härtung sollte mit Belegen aus der Produktion enden, nicht mit der Annahme, dass der riskante Pfad verschwunden ist. Bevor Sie den Befund schließen, prüfen Sie erneut Rollenzuweisungen, Richtlinien-Scope, App-Berechtigungen oder Gasteinstellungen, Anmelde-, Audit- oder Risikobelege aus dem echten Tenant sowie den Ausnahmepfad, der die Exposition stillschweigend wiederherstellen könnte. Bestätigen Sie, dass der sicherere Zustand für den Scope gilt, der tatsächlich zählt: die Produktions-OU, die effektive Rollenzuweisung, den Anwendungspfad oder den Trust- und Delegationspfad, den ein Angreifer wirklich ausnutzen würde. Dokumentieren Sie den technischen Verantwortlichen, die geschäftliche Abhängigkeit und die Rollback-Bedingung, damit die nächste Prüfung erkennen kann, ob der sicherere Zustand erhalten geblieben ist.

Nutzen Sie eine kurze Abschluss-Checkliste:

• bestätigen Sie, dass der riskante Zustand aus Sicht eines Angreifers verschwunden ist, nicht nur auf einem Admin-Screenshot
• bewahren Sie einen Vorher/Nachher-Export oder ein Log-Beispiel auf, das belegt, dass sich der betroffene Scope geändert hat
• dokumentieren Sie den Verantwortlichen und die Ausnahmeentscheidung, falls die Kontrolle nicht vollständig durchgesetzt werden konnte

Für benachbarte Expositionen gleichen Sie das Ergebnis mit AD & Azure Compliance: NIS2, ISO 27001, CIS, Entra ID bedingter Zugriff Luecken: welche Fehlkonfigurationen reale Angriffsflaechen lassen, Azure Privilegierter Zugriff: Zu Viele Globale Admins und AD-Audit-Tool-Vergleich: Wie sich PingCastle, Purple Knight und wiederholbare Audit-Workflows vergleichen lassen ab. Dieselbe Kontrolllücke taucht oft in benachbarten Identitätspfaden, Logging-Lücken oder delegierten Berechtigungen wieder auf, weshalb der finale Validierungsschritt genauso wichtig ist wie der ursprüngliche Befund.

Azure Tenant-Härtung: Belege Für Den Nächsten Review-Zyklus

Der nächste Prüfer sollte den Fall nicht aus dem Gedächtnis rekonstruieren müssen. Bewahren Sie die Belege auf, die den Befund ursprünglich begründet haben, den Nachweis, dass die Änderung angewendet wurde, und die Notiz, die erklärt, warum der Endzustand akzeptabel ist. Bei diesem Thema kombinieren die nützlichsten Belege meist den Tenant-Export oder Screenshot, der den betroffenen Scope zeigt, die Anmelde-, Audit- oder Richtlinienbelege, die beweisen, dass die Kontrolle jetzt greift, sowie die Notiz zu Verantwortlichem, Genehmigung und Ausnahme für den Endzustand. Dieses kompakte Paket macht quartalsweise oder änderungsbezogene Prüfungen deutlich schneller und hilft zu erklären, ob das Problem entfernt, reduziert oder formal akzeptiert wurde.

Wenn eine spätere Admin-, Richtlinien- oder Anwendungsänderung den Pfad wieder öffnet, erleichtert dieser historische Beleg auch den Nachweis, was sich verändert hat. Genau das macht aus Azure Tenant-Härtung einen wiederholbaren Assurance-Prozess statt einer einmaligen Prüfung.

Weiterführende Beiträge

Betrachten Sie dieses Thema zusammen mit Entra ID bedingter Zugriff Luecken: welche Fehlkonfigurationen reale Angriffsflaechen lassen, Azure Privilegierter Zugriff: Zu Viele Globale Admins, Azure Gastkonten: Die Vergessene Angriffsfläche in Ihrem Tenant, Azure App-Registrierungen: Sicherheitsrisiken und Azure Identity Protection: Geleakte Zugangsdaten Blockieren. Diese verwandten Beiträge zeigen, wie dieselben Identitätsschwächen in einem echten Assessment meist zusammenhängen, statt als isolierte Befunde aufzutreten.

• Entra ID bedingter Zugriff Luecken: welche Fehlkonfigurationen reale Angriffsflaechen lassen
• Azure Privilegierter Zugriff: Zu Viele Globale Admins
• Azure Gastkonten: Die Vergessene Angriffsfläche in Ihrem Tenant
• Azure App-Registrierungen: Sicherheitsrisiken
• Azure Identity Protection: Geleakte Zugangsdaten Blockieren

Diese Verweise halten die Remediationsdiskussion auf den gesamten Angriffspfad fokussiert statt auf eine einzelne Kontrolllücke.

Härtungsbaseline Über Die Zeit Validieren

Standardeinstellungen sollten als Ausgangspunkt behandelt werden, nicht als Endergebnis der Härtung. Nachdem sicherere Tenant-Defaults angewendet wurden, prüfen Sie, welche Teams sich weiterhin auf breite Ausnahmen verlassen, ob neue Anwendungen oder Benutzer die vorgesehenen Kontrollen umgehen können, und wie Drift über die Zeit überwacht wird. Ein gehärteter Tenant bleibt nur dann widerstandsfähig, wenn Ownership, Review-Rhythmus und Ausnahmebehandlung genauso diszipliniert gehandhabt werden wie der ursprüngliche Rollout.