Maester ScubaGear Entra ID Sicherheitsbaseline Tests: Leitfaden

Was sind Maester ScubaGear Entra ID Sicherheitsbaseline Tests?

Maester ScubaGear Entra ID Sicherheitsbaseline Tests machen die Überprüfung der Sicherheitskonfiguration zu einer wiederholbaren Bewertung: dokumentierte Prüfaussagen auswählen, Mandanteneinstellungen erfassen, auswerten und die Ergebnisse aufbewahren. Maester bietet PowerShell-Testautomatisierung; ScubaGear bewertet die Microsoft-365-Konfiguration anhand der CISA-SCuBA-Baselines. Ihr Nutzen liegt in einer Überprüfung, die nach einer Änderung wiederholt werden kann und deren Umfang und Nachweise erhalten bleiben.

Ein Baseline-Ergebnis beantwortet eine klar begrenzte Frage. Es kann feststellen, dass eine Prüfaussage mit der für die Bewertung verfügbaren Konfiguration übereinstimmt. Es belegt weder, dass jeder Authentifizierungspfad geschützt ist, noch, dass kein Identitätsangriff stattgefunden hat. Der folgende Ablauf trennt Konfigurationsmessung, Untersuchung der Ergebnisse, kontrollierte Behebung und anschließende Verifizierung. Er enthält dokumentierte Befehle und echte Testkennungen, ohne ein Beispiel als von uns durchgeführte Mandantenbewertung darzustellen.

Zu den Fragen der Richtlinienabdeckung, die der Werkzeugauswahl vorausgehen, siehe Lücken in der Baseline-Richtlinienabdeckung von Conditional Access in Entra ID. Dieser Artikel untersucht, ob Richtlinien für Administratoren, Benutzer, Ressourcen und Geräte vorhanden sind. Dieser Leitfaden konzentriert sich auf wiederholbare Bewertungen und die Interpretation ihrer Ausgabe.

So arbeiten die Werkzeuge: Pester-Tests und SCuBA-Richtlinienauswertung

Maester und seine unterschiedlichen Testsuiten

Maester ist ein quelloffenes PowerShell-Framework, das die Sicherheitskonfiguration durch automatisierte Tests aufrechterhält. Sein Repository dokumentiert eigene Pester-Tests, Ergebnisexporte und Pipeline-Integrationen. Pester stellt das Ausführungsmodell für Tests bereit; Maester ergänzt dieses Modell um Sicherheitstests und Berichte. Das Framework ist erweiterbar. Halten Sie deshalb die tatsächlich installierten Tests fest, statt aus dem Produktnamen eine feste Abdeckung abzuleiten. README des Maester-Repositorys.

Die Suiten haben unterschiedliche Ursprünge. Die Maester-Suite enthält Sicherheitstests der Community für die Konfiguration. Die EIDSCA-Suite basiert auf dem Entra ID Security Config Analyzer und prüft Gegenmaßnahmen für Identitätsangriffsszenarien. Die CISA-Suite testet die Microsoft-365-Konfiguration anhand der SCuBA-Empfehlungen. Bewahren Sie Suite und Testkennung bei jedem Ergebnis auf, damit Leser deren Quellen unterscheiden können.

Die CISA-Tests von Maester belegen nicht, dass Maester die OPA-Engine von ScubaGear ausführt. Gemeinsame Baseline-Empfehlungen belegen auch keine identischen Implementierungen. Vergleichen Sie Befunde anhand der Anforderung, der Testimplementierung und des überprüften Releases. Zwei ähnlich benannte Tests können unterschiedliche Bedingungen untersuchen, wie die folgenden Beispiele zur Legacy-Authentifizierung zeigen.

ScubaGear und Baselines je Produkt

ScubaGear gehört zum Secure Cloud Business Applications-Projekt der CISA. Seine dokumentierte Bewertung trennt Erfassung und Auswertung: PowerShell fragt Microsoft-365-APIs ab, Open Policy Agent bewertet die erfassten Einstellungen anhand von Rego-Richtlinien, und das Werkzeug erstellt Ergebnisse in HTML, JSON und CSV. Das Baseline-Dokument beschreibt die Sicherheitserwartung; die automatisierte Implementierung bestimmt, was der Lauf messen kann. ScubaGear-README.

Das Repository stellt separate Baseline-Dokumente für Entra ID, die Sicherheitsproduktsuite, Exchange Online, Power BI, Power Platform, SharePoint und Teams bereit. Das Vorhandensein eines Baseline-Dokuments beweist nicht, dass jedes Release jede Produktbewertung ausführen kann. Insbesondere führt die Parametertabelle von v1.8.0 Entra ID als aad auf und nennt die akzeptierten Produktauswahlen. Prüfen Sie diese Tabelle, bevor Sie ein Produkt auswählen. Versioniertes README, Parameter von v1.8.0.

Für Arbeiten mit Entra-Schwerpunkt empfehlen wir, mit der Auswahl aad zu beginnen und deren Voraussetzungen zu prüfen. Erweitern Sie auf weitere Produkte, sobald die erforderlichen Verbindungen, Rollen und Verantwortlichen für Nachweise bereitstehen. Dies ist eine betriebliche Empfehlung und keine Behauptung, der Rest von Microsoft 365 werde ausschließlich über Graph bewertet.

Releases und sich weiterentwickelnde Dokumentation auseinanderhalten

Die am 3. Oktober 2026 für diesen Leitfaden geprüften Release-Referenzen sind Maester 2.2.0 und ScubaGear v1.8.0. Zum Prüfzeitpunkt besprach das main-README von ScubaGear bereits v2.0.0. Deshalb kennzeichnet dieser Leitfaden Referenzen zur Ausführung und zu Berechtigungen von v1.8.0 ausdrücklich; Aussagen zur sich weiterentwickelnden Baseline-Dokumentation werden separat belegt. Legen Sie vor der Übernahme dieser Beispiele Modulrelease, Abhängigkeitsversionen und Testrevision als Bewertungsspezifikation fest.

Graph-Lesezugriff vor der Bewertung vorbereiten

Lesezugriff hat zwei Dimensionen: was das Werkzeug tut und wozu seine Identität berechtigt ist. Microsoft Graph unterscheidet delegierten Zugriff im Namen eines angemeldeten Benutzers von Anwendungszugriff ohne diesen Benutzer. Zustimmung und unterstützte Verzeichnisrollen bleiben relevant. Eine Anwendung anzulegen, Zustimmung zu erteilen oder Authentifizierung einzurichten ist administrative Vorbereitung; sie sollte von den anschließenden Konfigurationslesevorgängen unterschieden werden. Referenz der Graph-Berechtigungen, Graph-PowerShell-Authentifizierung.

Beispielsweise ist das Auflisten von Conditional-Access-Richtlinien ein Graph-Lesevorgang mit der dokumentierten Berechtigung Policy.Read.All. Die Anforderung dieses Endpunkts rechtfertigt nicht allein den Zugriff für eine gesamte Bewertungssuite: andere Tests lesen andere Ressourcen. conditionalAccessPolicies auflisten.

Die Standardscopes von Maester

Der Get-MtGraphScope-Quellcode von 2.2.0 definiert die standardmäßigen Lesescopes, darunter Zugriff auf Verzeichnis, Richtlinien, Audit, Berichte, Geräteverwaltung, Identitätsrisiken und Authentifizierungsmethoden. Dies ist die Liste des Frameworks und nicht das Minimum für einen einzelnen Conditional-Access-Test. Directory.Read.All ist beispielsweise umfassender als das bloße Lesen der Richtliniensammlung.

Derselbe Quellcode trennt optionale Ergänzungen: -Privileged fügt ReportSettings.ReadWrite.All hinzu, -SendMail fügt Mail.Send hinzu, und -SendTeamsMessage fügt ChannelMessage.Send hinzu. Lassen Sie diese Ergänzungen außerhalb einer standardmäßigen Graph-Lesebewertung, sofern keine separat geprüfte Anforderung sie benötigt. Connect-Maester erläutert die optionalen Verbindungen und das Verhalten privilegierter Scopes.

Beschreiben Sie Maester nicht als unfähig, Protokolle zu lesen. Seine Standardliste enthält AuditLog.Read.All und ThreatHunting.Read.All; Microsofts Berechtigungsdefinitionen beschreiben Audit-Lesevorgänge und Hunting-Abfragen. Der enger gefasste Punkt ist, dass die hier besprochenen Baseline-Tests Konfigurationsprüfaussagen sind. Ihr Erfolg beweist nicht, dass eine bestimmte Anmeldung blockiert wurde.

Die Entra-Voraussetzungen von ScubaGear

ScubaGear v1.8.0 dokumentiert Global Reader für die interaktive Entra-Bewertung und folgende Graph-Berechtigungen: Directory.Read.All, Policy.Read.All, PrivilegedAccess.Read.AzureADGroup, PrivilegedEligibilitySchedule.Read.AzureADGroup, RoleManagement.Read.Directory, RoleManagementPolicy.Read.AzureADGroup und User.Read.All. Prüfen Sie vor dem Lauf den tatsächlichen Zustimmungsprozess mit dem Mandantenadministrator. Interaktive Voraussetzungen.

Die nicht interaktiven Voraussetzungen listen Berechtigungen je Produkt auf. Sie erläutern auch, dass SharePoint und Power Platform aufgrund von API-Anforderungen Berechtigungen mit Schreibrechten benötigen, obwohl ScubaGear diese Rechte nicht für Bewertungen verwendet. Daher sollte eine Bewertung aller Produkte nicht als ausschließlich mit Leseberechtigungen arbeitend beschrieben werden. Diese Unterscheidung gilt auch bei der Prüfung optionaler Maester-Dienstverbindungen.

Dokumentierte Befehle ausführen und ihren Umfang festhalten

Die folgenden Befehle sind Dokumentationsbeispiele. Sie wurden für diesen Artikel nicht gegen einen Mandanten ausgeführt. Stellen Sie zunächst die Bewertungsumgebung bereit und prüfen Sie sie; verwenden Sie anschließend die zum ausgewählten Release passende Dokumentation.

Schritt 1: Maester-Tests vorbereiten

Die Installationsanleitung enthält den Installationsbefehl für Pester:

Install-Module Pester -MinimumVersion 5.7.1 -MaximumVersion 5.7.1 -SkipPublisherCheck -Force -Scope CurrentUser

Sie installiert Maester separat:

Install-Module Maester -Scope CurrentUser

Dieser Befehl fixiert das Maester-Release nicht. Klären Sie die beabsichtigte Version, bevor Sie ihn für reproduzierbare Nachweise verwenden. Aus dem gewählten Testverzeichnis installiert die Anleitung die mitgelieferten Tests:

Install-MaesterTests

Schritt 2: Verbinden und auswerten

Das Graph-Verbindungsbeispiel in Connect-Maester lautet:

Connect-Maester

Dieselbe Dokumentation und die versionierte Scope-Hilfsfunktion nennen dieses direkte Graph-Äquivalent. Es verwendet die vom installierten Maester-Modul bereitgestellte Scopeliste:

Connect-MgGraph -Scopes (Get-MtGraphScope)

Dies sind alternative Verbindungswege. Das direkte Graph-Beispiel ist kein Anlass, beide auszuführen. Sobald die Tests verfügbar sind, lautet der dokumentierte Auswertungsbefehl:

Invoke-Maester

Die Invoke-Maester-Referenz beschreibt Testpfadauswahl, Tags, Ausschlüsse und Berichtsausgabe. Halten Sie die in Ihrem Lauf verwendete Auswahl fest. Sie nennt außerdem ein ausdrückliches Beispiel für die HTML-Ausgabe:

Invoke-Maester -OutputHtmlFile './test-results/TestResults.html'

Wählen Sie diese Berichtsvariante, wenn sie geeignet ist. Sie ist ein weiterer Bewertungsaufruf und nicht lediglich ein Befehl, der einen vorhandenen Bericht umbenennt. Fehlende optionale Dienstmodule oder Verbindungen können dazu führen, dass Tests übersprungen werden, wie die Installationsanleitung erläutert.

Schritt 3: ScubaGear-Produkte bewusst auswählen

Die Ausführungsanleitung von v1.8.0 beschreibt die Ausführung unter Windows, erforderliche Abhängigkeiten und den Import eines heruntergeladenen Moduls in PowerShell 5.1. Ihr wörtliches Beispiel für alle Produkte lautet:

Invoke-SCuBA -ProductNames *

Dies veranschaulicht den dokumentierten Platzhalter; verwenden Sie ihn erst, nachdem Sie die Voraussetzungen des erweiterten Umfangs geprüft haben. Ersetzen Sie für die Entra-only-Empfehlung dieses Leitfadens den Platzhalter durch aad gemäß dem dokumentierten Produktparameter. Diese Ersetzung ist eine Anpassung des Beispiels und kein wörtlicher Befehl aus der Ausführungsanleitung. Bewahren Sie die daraus resultierende Produktauswahl im Laufprotokoll auf.

Messen, was die Ergebnisse tatsächlich belegen

Maester liefert Testergebnisse und Berichtsexporte. ScubaGear liefert einen globalen HTML-Bericht, einzelne Produktberichte, strukturiertes JSON und Ergebnis-CSV. Das JSON von ScubaGear kann abhängig von den Optionen Laufkontext und Providerausgabe bewahren; ScubaResults.csv ist ein enger gefasster Ergebnisexport. ActionPlan.csv filtert fehlgeschlagene SHALL-Kontrollen und bietet Platz für Fehlererklärungen und Behebungszeitpläne. Es ist nicht das vollständige Bewertungsprotokoll. Exportfunktionen von Maester, ScubaGear-Berichte.

Wir empfehlen, Ergebnisse in getrennten Warteschlangen zu prüfen:

Dies sind Empfehlungen zum Umgang mit Ergebnissen, keine erfundenen Ergebnisbezeichnungen für jede Version der beiden Werkzeuge. Sie verhindern, dass eine Änderung der ausgewerteten Population mit einer Verbesserung verwechselt wird. Ein sinnvoller betrieblicher Vergleich hält fest, welche Prüfaussagen erfolgreich ausgeführt wurden, welche nicht ausgeführt werden konnten und welche eine andere Methode erfordern.

Die aktuelle SCuBA-Entra-Baseline begrenzt die automatisierte Auswertung von Conditional-Access-Bedingungen ausdrücklich auf die in ihren Implementierungen genannten Bedingungen. Sie kennzeichnet auch einige Anforderungen als manuell. Ein bestandenes automatisiertes Ergebnis lässt daher Fragen zu Bedingungen, Ausnahmen und betrieblicher Verifizierung offen, die von der Prüfaussage nicht abgedeckt werden.

Lesen Sie für die ergänzende Untersuchung Conditional-Access-Lücken und Anmeldenachweise. Dieser Artikel untersucht tatsächliche Richtlinienanwendung, Ausschlüsse und Authentifizierungspfade. Er ergänzt einen Baseline-Bericht, ohne Konfigurationstests in eine Aussage über jede Anmeldung zu verwandeln.

Erkennung durch wiederkehrende Bewertung und CI

Wiederkehrende Baseline-Bewertungen erkennen Änderungen zwischen erfolgreich beobachteten Konfigurationen. Wir empfehlen, für jeden Lauf Mandantenkennung, Zeitstempel, Release, Testrevision, Produktumfang, Berechtigungsprofil, Fehler, Berichte und Ausnahmen aufzubewahren. Vergleichen Sie Gleiches mit Gleichem. Ändert sich eine Suite oder Abhängigkeit, klären Sie zuerst, ob die Abweichung von der Mandantenkonfiguration, der Testlogik oder der Erfassungsabdeckung stammt.

Maesters GitHub-Monitoring-Anleitung dokumentiert Workload-Identitätsföderation mit OIDC, Anwendungsberechtigungen, geplante Ausführung und manuelle Workflow-Auslösung. Ihr Zeitplanbeispiel läuft täglich um 07:30 UTC. Wählen Sie einen Rhythmus für Ihre betrieblichen Anforderungen; das Beispiel belegt kein geeignetes Reaktionsintervall für jeden Mandanten. -NonInteractive steuert das Darstellungsverhalten, einschließlich der Unterdrückung des Browseröffnens, und richtet keine Authentifizierung ein. Invoke-Maester-Parameterreferenz.

Die Ausführungsdokumentation von ScubaGear beschreibt zertifikatbasierte Service-Principal-Ausführung für Pipelines und geplante Aufgaben. Die versionierten Voraussetzungen sollten die Berechtigungseinrichtung bestimmen. Wir empfehlen, Anwendungskennungen und Zertifikatreferenzen in der Aufgabenkonfiguration zu belassen und den tatsächlichen privaten Schlüssel über den genehmigten Anmeldeinformationsprozess der Organisation zu verwalten. Behandeln Sie Bereitstellung und Pflege der Anmeldeinformationen als separate administrative Arbeiten.

Für beide Werkzeuge empfehlen wir, Modul, Tests, Abhängigkeiten und CI-Action-Revision gemeinsam zu fixieren. Ein Aufgabenfehler sollte eine betriebliche Untersuchung auslösen, statt das günstige Ergebnis von gestern als heutigen Nachweis wiederzuverwenden. Leiten Sie Konfigurationsregressionen an ihre Verantwortlichen weiter und bewahren Sie die Begründung jeder akzeptierten Ausnahme auf. Dies sind Ablaufempfehlungen; hier wird weder eine Pipeline-Ausführung noch eine Reaktionsleistung behauptet.

Ein Bewertungszeitplan liefert Beobachtungen zu den Laufzeitpunkten. Er kann nicht beweisen, dass die Konfiguration dazwischen unverändert blieb. Behalten Sie die wiederkehrende Bewertung neben dem bestehenden Sicherheitsmonitoring bei und machen Sie das Datum der jüngsten erfolgreichen Erfassung für Prüfer sichtbar.

Behebung: vom fehlgeschlagenen Test zur verifizierten Änderung (Remediation)

Schritt 1: Maester MT.1009 präzise lesen

MT.1009 prüft auf eine Conditional-Access-Richtlinie, die andere Legacy-Authentifizierung blockiert. Die untersuchte Implementierung wählt aktivierte Richtlinien aus, entfernt Richtlinien mit passwordChange und sucht nach einer Block-Zugriffssteuerung mit Clienttyp other, eingeschlossenen Anwendungen All und eingeschlossenen Benutzern All. Sie gibt false zurück, wenn nichts übereinstimmt. Eine Entra-Free-Lizenzbedingung oder ein abgefangener Fehler kann stattdessen zu einem übersprungenen Ergebnis führen.

Schlägt dieser Test in Ihrer Bewertung fehl, untersuchen Sie die abgeglichenen Daten und bestätigen Sie, dass der Fehler die beabsichtigte Anforderung repräsentiert. Die Funktion beweist weder, dass keine Ausschlüsse vorhanden sind, noch, dass jede relevante Verbindung blockiert wird. Ihre Implementierung ist ein konkreter Ausgangspunkt für die Untersuchung, kein vollständiger Richtliniensimulator. Bewahren Sie die Quellcoderevision beim Befund auf, damit spätere Implementierungsänderungen von der Behebung unterscheidbar bleiben.

Schritt 2: SCuBA MS.AAD.1.1v1 vergleichen, ohne Gleichwertigkeit anzunehmen

MS.AAD.1.1v1 in der Baseline von v1.8.0 verlangt das Blockieren von Legacy-Authentifizierung. Ihre Implementierungsanweisungen verlangen, bestehende Legacy-Abhängigkeiten zu identifizieren, alle Benutzer und Ressourcen als Ziel auszuwählen, Exchange ActiveSync und Other clients auszuwählen und Block Access als Zugriffssteuerung festzulegen. Der other-Test von MT.1009 allein repräsentiert nicht all diese Anweisungen. Dies sind Maester- und SCuBA-Kennungen, keine CIS-Kontrollnummern.

Wir empfehlen, einen Behebungsdatensatz mit fehlgeschlagener Kennung, ausgewerteten Richtliniendaten, relevanter Anforderung, verantwortlicher Person, betroffenen Abhängigkeiten und vorgeschlagener Änderung anzulegen. Wird ein Ergebnis übersprungen, eröffnen Sie zuerst eine Untersuchung der Voraussetzungen. Ist es manuell, dokumentieren Sie die manuelle Methode. Keines dieser Beispiele ist ein beobachteter Fehler in einem für diesen Artikel bewerteten Mandanten.

Schritt 3: Auswirkungen vor der Durchsetzung validieren

Microsofts Anleitung zum Blockieren von Legacy-Authentifizierung startet die neue Richtlinie im Modus report-only, prüft die Auswirkungen und setzt sie nach der Validierung auf On. Folgen Sie der dokumentierten Behandlung von Notfallzugriffskonten und gegebenenfalls einem gestaffelten Rollout. Identifizieren Sie legitime Legacy-Abhängigkeiten und planen Sie deren Migration oder eine ausdrücklich geregelte Ausnahme vor der umfassenden Durchsetzung.

Wir empfehlen, repräsentative beabsichtigte Zugriffspfade zu testen und die Nachweise zu Richtlinienauswirkungen mit den Verantwortlichen zu prüfen. Halten Sie genau fest, wann die Durchsetzung aktiviert wird. Eine report-only-Richtlinie ist nützlich zur Bewertung der Auswirkungen, kann aber nicht belegen, dass die beabsichtigte Blockierung durchgesetzt wurde. Entfernen Sie den Validierungsschritt nicht bloß, um eine automatisierte Prüfaussage zu erfüllen, die nach dem aktivierten Zustand sucht.

Schritt 4: Erneut ausführen und dieselbe Prüfung einplanen

Führen Sie nach der genehmigten Änderung die relevanten Maester-Tests oder die ScubaGear-Produktbewertung mit der aufbewahrten Auswahl und den Versionen erneut aus. Prüfen Sie sowohl die neuen Daten als auch das Ergebnis. Hängen Sie beide Bewertungen an den Behebungsdatensatz an und bestätigen Sie das beabsichtigte Verhalten separat durch den dokumentierten Prozess zur Prüfung von Richtlinienauswirkungen und Anmeldungen. Maester-Ausführungsreferenz, ScubaGear-Ausführung, Microsoft-Validierungsverfahren.

Wir empfehlen, die behobene Prüfaussage in die wiederkehrende Prüfung aufzunehmen, mit einer verantwortlichen Person für Regressionen und einem Ablaufdatum für Ausnahmen. Verliert der nächste Lauf Berechtigungen oder überspringt den Test, öffnen Sie die Nachweisfrage erneut. Der Abschluss eines Behebungsdatensatzes sollte bedeuten, dass die definierte Anforderung erneut geprüft und ihre betriebliche Validierung abgeschlossen wurde.

So erkennt EtcSec dies

EtcSecs AZ_CIS_BENCHMARK_GAPS ist ein Konfigurationsaggregat mit vier unabhängigen Prüfungen. Die gelesene Implementierung ist public/internal/audit/detectors/azure/compliance/standards/cis-benchmark-gaps.go; Detect() beginnt in Zeile 68. Jede gezählte Bedingung erhöht den Wert um eins; Count reicht von 0 bis 4. Er ist weder ein Prozentsatz noch der vollständige CIS Microsoft 365 Foundations Benchmark.

Diese Bedingungen stehen in derselben Datei in den Zeilen 82–178. Die Warnung AZURE_CONDITIONAL_ACCESS_POLICIES_FAILED unterdrückt die drei richtlinienbasierten Prüfungen. Fehlende Mandantendaten können dazu führen, dass die Security-Defaults-Prüfung nicht gezählt wird. Ohne diese Warnung zählt eine leere Richtliniensammlung die drei fehlenden Richtlinien. Somit beweist Count = 0 nicht, dass alle vier Bedingungen erfolgreich bewertet wurden.

Die Funktion gibt ihren Befund auch bei null zurück; ein positiver Zähler und IncludeDetails bestimmen das Anhängen von Lückendetails. Sie liest Konfiguration und Erfassungswarnungen, ohne Maester-Ergebnisse, ScubaGear-Berichte oder Anmeldenachweise zu verarbeiten. Nutzen Sie sie, um diese vier Bedingungen über EtcSec-Audits hinweg zu verfolgen, und untersuchen Sie anschließend ihren Umfang. Behalten Sie vollständige Baseline-Auswertung und betriebliche Validierung der Durchsetzung als getrennte Teile der Prüfung bei.