Sicherheit in Microsoft-Clouds mit Maester 2.0 testen
Das Gesetz bin ich
Veröffentlicht in Ausgabe 07/2026 - PRAXIS
Die Absicherung von Cloudumgebungen hat sich in den vergangenen Jahren grundlegend verändert. Wenn Sie im Microsoft-Ökosystem aktiv sind – also rund um Entra ID, Azure oder Microsoft 365 –, kennen Sie vermutlich aus eigener Erfahrung, wie schnell sich Anforderungen und die darauf aufbauenden Konfigurationen Ihrer Dienste im Alltag verändern. Konfigurationen erfolgen heute nicht mehr einmalig und auf Dauer, sondern sind fortlaufend an dynamische Umgebungen anzupassen: Neue Anwendungen werden registriert, Conditional-Access-Richtlinien verändert, Benutzerrollen erweitert oder eingeschränkt. Hinzu kommt, dass Konfigurationen, die gestern noch als sicher galten, heute bereits eine Lücke darstellen können. Die Herausforderung besteht daher längst nicht mehr allein darin, Sicherheitsrichtlinien zu definieren, sondern sicherzustellen, dass diese auch dauerhaft gültig sind.
Sicherheitskonfigurationen als ausführbarer Code
Klassische Methoden setzen im beschriebenen Umfeld auf manuelle Audits, punktuelle Reviews von Regelsätzen oder GUI-basierte Werkzeuge zur Analyse bestehender Richtlinien. Wie in anderen Bereichen der IT verschiebt sich aber auch hier der Fokus zunehmend in Richtung Automatisierung und kontinuierlicher Validierung. Genau an dieser Stelle setzt Maester 2.0 [1] an: ein Open-Source- Testframework, das Sicherheitskonfigurationen in Microsoft-Clouddiensten in Form von Code überprüfbar macht.
Die zentrale Idee hinter Maester, von einem internationalen Team um den Microsoft-Mitarbeiter Merill Fernando entwickelt, ist konzeptionell nicht neu, in der Identity- und SaaS-Welt jedoch noch vergleichsweise ungewohnt: Sicherheitskonfigurationen gelten dabei als ein sich kontinuierlich veränderndes System, das regelmäßiger Überprüfung bedarf. Die zugrundeliegende Logik ist aus der Softwareentwicklung bekannt, wo Entwickler Code schreiben, testen, bereitstellen und fortlaufend überwachen.
Die Absicherung von Cloudumgebungen hat sich in den vergangenen Jahren grundlegend verändert. Wenn Sie im Microsoft-Ökosystem aktiv sind – also rund um Entra ID, Azure oder Microsoft 365 –, kennen Sie vermutlich aus eigener Erfahrung, wie schnell sich Anforderungen und die darauf aufbauenden Konfigurationen Ihrer Dienste im Alltag verändern. Konfigurationen erfolgen heute nicht mehr einmalig und auf Dauer, sondern sind fortlaufend an dynamische Umgebungen anzupassen: Neue Anwendungen werden registriert, Conditional-Access-Richtlinien verändert, Benutzerrollen erweitert oder eingeschränkt. Hinzu kommt, dass Konfigurationen, die gestern noch als sicher galten, heute bereits eine Lücke darstellen können. Die Herausforderung besteht daher längst nicht mehr allein darin, Sicherheitsrichtlinien zu definieren, sondern sicherzustellen, dass diese auch dauerhaft gültig sind.
Sicherheitskonfigurationen als ausführbarer Code
Klassische Methoden setzen im beschriebenen Umfeld auf manuelle Audits, punktuelle Reviews von Regelsätzen oder GUI-basierte Werkzeuge zur Analyse bestehender Richtlinien. Wie in anderen Bereichen der IT verschiebt sich aber auch hier der Fokus zunehmend in Richtung Automatisierung und kontinuierlicher Validierung. Genau an dieser Stelle setzt Maester 2.0 [1] an: ein Open-Source- Testframework, das Sicherheitskonfigurationen in Microsoft-Clouddiensten in Form von Code überprüfbar macht.
Die zentrale Idee hinter Maester, von einem internationalen Team um den Microsoft-Mitarbeiter Merill Fernando entwickelt, ist konzeptionell nicht neu, in der Identity- und SaaS-Welt jedoch noch vergleichsweise ungewohnt: Sicherheitskonfigurationen gelten dabei als ein sich kontinuierlich veränderndes System, das regelmäßiger Überprüfung bedarf. Die zugrundeliegende Logik ist aus der Softwareentwicklung bekannt, wo Entwickler Code schreiben, testen, bereitstellen und fortlaufend überwachen.
Maester überträgt dieses Prinzip konsequent auf Konfigurationen im Microsoft-Universum. Sie schreiben Tests als Code und lassen diese automatisiert gegen die Konfiguration ihres Tenants ausführen. Sobald Sie beginnen, mit Maester zu arbeiten, verändert sich zwangsläufig Ihre Sicht auf Sicherheit. Anstatt zu fragen, ob eine bestimmte Einstellung gesetzt ist, formulieren Sie eine konkrete Erwartung. Sie definieren beispielsweise, dass alle privilegierten Konten in Ihrem Tenant durch Multifaktor-Authentifizierung geschützt sein müssen. Diese Erwartung ist dabei nicht lediglich auf geduldigem Papier dokumentiert, sondern als ausführbarer Test implementiert.
Dieses Vorgehen hat weitreichende Konsequenzen, denn es macht Sicherheitsanforderungen auf dieser Ebene reproduzierbar, versionierbar und überprüfbar. Sie können nachvollziehen, seit wann eine Regel gilt, zu welchem Zeitpunkt eine Konfigurationsänderung gegen die Regel verstieß und wann sie anschließend wieder erfüllt war. So gestalten Sie Sicherheit in Ihrem Tenant als ein überprüfbares Artefakt.
Schlanke Architektur auf Basis des Microsoft-Graph-API
Betrachten wir Maester zunächst rein technisch, fällt vor allem die bewusst schlanke Architektur auf. Maester ist kein eigenständiger Dienst, sondern ein Framework, das PowerShell als Ausführungsumgebung nutzt und für die Testlogik auf dem dort etablierten Framework Pester basiert. Seine eigentliche Stärke entfaltet das Werkzeug im direkten Zusammenspiel mit dem Microsoft-Graph-API. Diese Designentscheidung ist nicht zufällig, sondern spiegelt die Nähe zu gängigen DevOps-Praktiken wider. Maester bringt keine eigene Datenhaltung mit, sondern greift über das API unmittelbar auf Schnittstellen von Microsoft Entra und Azure zu. Haben Sie bereits mit PowerShell-Modulen wie "Microsoft.Graph" [2] oder "Azure CLI" [3] gearbeitet, sind Sie höchstwahrscheinlich bereits mit dem Graph-API in Berührung gekommen, vielleicht ohne es bewusst wahrzunehmen.
Wenn Sie Maester in Ihrem Tenant ausführen, erfolgt zunächst die Authentifizierung gegen Entra. Anschließend ruft das Framework über das Graph-API die relevanten Konfigurationsdaten ab. Dazu gehören unter anderem Benutzerobjekte, Rollen und Gruppen, Conditional-Access-Richtlinien sowie App-Registrierungen. Maester arbeitet damit vollständig zustandsbasiert. Es greift auf dieselben Datenquellen zu, die auch das Entra Admin Center und andere Microsoft-Werkzeuge verwenden. Die Ergebnisse, die Sie in Maester sehen, beruhen damit auf denselben Informationen, die auch Microsoft selbst nutzt. Bewertet wird stets der aktuelle Zustand Ihres Tenants, ohne dass Maester selbst Änderungen vornimmt. Gerade diese Trennung zwischen rein lesender Analyse und Konfiguration ist in produktiven Umgebungen ein entscheidender Vorteil, weil sie Risiken minimiert und den Einsatz auch in sensiblen Szenarien ermöglicht.
Testgetriebene Validierung technischer Anforderungen
Der Mehrwert von Maester besteht nicht allein darin, die Konfiguration Ihres Tenants über das Graph-API auszulesen. Das Framework unterstützt Sie vielmehr dabei, Tests zu entwickeln, die Ihre individuellen Anforderungen abbilden, und bestehende Richtlinien systematisch zu überprüfen. Ein typischer Test folgt einem klaren Muster: Zunächst ermittelt das Werkzeug einen aktuellen Zustand, etwa vorhandene Conditional-Access-Richtlinien. Anschließend erfolgt die Bewertung anhand definierter Kriterien, bevor das Ergebnis als "Pass" oder "Fail" mit ergänzenden Kontextinformationen ausgegeben wird. Was einfach erscheint, erweist sich in der Praxis als äußerst wirkungsvoll.
Betrachten wir als Beispiel die Absicherung administrativer Konten. Ziel ist es, sicherzustellen, dass alle Benutzer mit privilegierten Rollen durch Multifaktor-Authentifizierung (MFA) geschützt sind. Während klassische Werkzeuge lediglich den Ist-Zustand dokumentieren, erfordert Maester die Formulierung einer klaren Anforderung: "Alle Benutzer mit privilegierten Rollen müssen eine MFA-Policy zugewiesen haben." Diese Anforderung bilden wir als Test in Code ab. In der Praxis erkennen Sie so nicht nur, ob eine Konfiguration vorhanden ist, sondern ob sie exakt den definierten Vorgaben entspricht. Gerade bei komplexen Conditional-Access-Szenarien ist dieser Unterschied entscheidend.
Einrichtung und erste Schritte
Das Aufsetzen von Maester ist bewusst einfach gehalten und spiegelt die leichtgewichtige Architektur des Frameworks wider. Als Grundlage dient eine aktuelle PowerShell-Version, idealerweise die 7. Unter Windows lässt sich diese über folgende Befehle installieren und starten:
winget install --id Microsoft. PowerShell --source winget
pwsh
Im nächsten Schritt installieren Sie die benötigten Module. Neben Maester selbst gehört dazu auch das Test-Framework Pester:
Install-Module Pester -Scope CurrentUser
Install-Module Maester -Scope CurrentUser
Gegebenenfalls müssen Sie die Installation aus dem entsprechenden Repository bestätigen. Anschließend empfiehlt es sich, die mitgelieferten Testbibliotheken zu laden, um ein Gefühl für die Struktur und den Umfang der Prüfungen zu bekommen. Dazu wechseln wir in ein Arbeitsverzeichnis und führen
Install-MaesterTests aus. Maester legt daraufhin mehrere Verzeichnisse mit vorgefertigten Tests gegen Ihren Tenant an. Dazu gehört ein Ordner mit CISA-Tests, die sich an Empfehlungen der US-amerikanischen Cybersecurity and Infrastructure Security Agency orientieren. Darüber hinaus finden sich Checks auf Basis offizieller Microsoft-Guidelines sowie im Verzeichnis "EIDSCA" eine Sammlung allgemeiner Best Practices.Diese Tests bieten einen guten Einstieg, Sie sollten sie jedoch nicht unkritisch übernehmen, denn sie sind zum Teil generisch gehalten und bilden nicht zwangsläufig die spezifischen Anforderungen Ihrer Organisation ab. In der Praxis dienen sie daher eher als Ausgangspunkt für eigene Testdefinitionen. Da es sich um PowerShell-Skripte handelt, profitieren Admins von bestehenden Kenntnissen mit Pester. Bevor die Tests gegen einen Tenant laufen, verbinden wir Maester mit der entsprechenden Umgebung mittels
Connect-Maester.Anschließend werden Sie im Browser zur Anmeldung aufgefordert. Dabei wird eine relativ große Menge an Berechtigungen abgefragt (siehe Bild 1), allerdings ausschließlich mit Leseberechtigung. Ein schreibender Zugriff ist für den Betrieb von Maester nicht erforderlich, da das Framework rein zur Analyse dient.
Ersten Testlauf starten
Nach erfolgreicher Authentifizierung können Sie den ersten Testlauf mit
Invoke- Maester starten. Standardmäßig führt das Tool dabei alle verfügbaren Tests aus. Die Ergebnisse zeigen sich zunächst in der Konsole als Zusammenfassung und zusätzlich als HTML-Report im Browser (Bild 2). Bereits dieser erste Durchlauf liefert einen aussagekräftigen Eindruck vom aktuellen Zustand Ihres Tenants. Anstelle einer reinen Auflistung von Konfigurationen erhalten Sie eine strukturierte Bewertung, die auf den definierten Anforderungen basiert. Abweichungen hebt das Werkzeug dabei klar hervor und versieht sie mit Kontextinformationen.Gerade in komplexeren Umgebungen führt dieser Ansatz häufig zu neuen Erkenntnissen. Konfigurationen, die im Alltag entstanden sind und die der IT-Verantwortliche bisher nicht systematisch überprüft hat, werden sichtbar und lassen sich gezielt analysieren. Je nach Implementierung des Tests gelangen Sie mit einem Klick auf das Ergebnis direkt zur entsprechenden Konfigurationseinstellung bei Microsoft.
Keine Sorge bei nicht ausgeführten Tests
Bei der ersten Nutzung von Maester fällt häufig auf, dass das Framework nicht alle verfügbaren Tests tatsächlich ausführt. In den Berichten zeigen sich solche Fälle typischerweise als "Skipped" oder "Not tested". Dieses Verhalten ist eine direkte Folge der Architektur und der generischen Ausrichtung des Frameworks; die Ausführbarkeit hängt stark von den Rahmenbedingungen im jeweiligen Tenant ab.
Eine wesentliche Rolle spielt die verfügbare Funktionalität: Viele sicherheitsrelevante Features – etwa Conditional-Access, Identity-Protection oder risikobasierte Bewertungen – setzen bestimmte Lizenzstufen voraus, zum Beispiel Entra-ID-P1 oder -P2. Sind diese Funktionen nicht vorhanden, lassen sich entsprechende Tests nicht sinnvoll bewerten, da die zugrundeliegenden Daten fehlen.
Darüber hinaus beeinflusst das Berechtigungsmodell die Ausführung. Maester greift über das Microsoft-Graph-API auf Konfigurationsdaten zu. Auch wenn Sie die angeforderten Berechtigungen grundsätzlich erteilen, sind in der Praxis nicht immer alle benötigten Informationen vollständig verfügbar. In solchen Fällen bleibt eine Bewertung aus, und das Werkzeug überspringt den Test. Schließlich spielen strukturelle Unterschiede eine Rolle: Nicht jede Umgebung nutzt dieselben Dienste oder identische Konfigurationsmuster. Einige Tests sind daher so gestaltet, dass sie nur unter bestimmten Voraussetzungen ablaufen.
Die Ergebnisse richtig interpretieren
Aus diesen Rahmenbedingungen ergibt sich eine zentrale Anforderung an die Interpretation der Ergebnisse. Ein Maester-Bericht sollte niemals isoliert betrachtet werden. Ein vollständig "grünes" Ergebnis bedeutet nicht zwangsläufig, dass Sie alle relevanten Sicherheitsaspekte geprüft haben. Ebenso ist ein fehlgeschlagener Test nicht automatisch als kritische Fehlkonfiguration zu verstehen, sondern kann auf fehlende Voraussetzungen zurückzuführen sein.
Entscheidend ist die Einordnung im Kontext der jeweiligen Umgebung: Welche Funktionen stehen tatsächlich zur Verfügung, welche Berechtigungen sind vergeben und welche Dienste werden aktiv genutzt? Vor diesem Hintergrund ist auch die Zielsetzung beim Einsatz von Maester zu verstehen. Es geht nicht darum, eine möglichst vollständige Testabdeckung zu erreichen. Der Mehrwert entsteht vielmehr dadurch, dass wir die für die eigene Infrastruktur relevanten Prüfungen identifizieren sowie zuverlässig und reproduzierbar ausführen. Das selektive Verhalten von Maester ist kein Nachteil, sondern ein Ergebnis seines generischen Ansatzes. Es zwingt Administratoren dazu, Sicherheitsanforderungen explizit zu formulieren und an die tatsächlichen Gegebenheiten des Tenants anzupassen.
Teststrategie schrittweise einführen
In der Praxis zeigt sich schnell, dass ein umfassender Ansatz von Beginn an nur bedingt zielführend ist. Der Versuch, eine vollständige Testabdeckung sofort zu erreichen, führt häufig zu einer Vielzahl von Ergebnissen, die sich nur schwer priorisieren lassen. Zielführender ist es, mit klar abgegrenzten Bereichen zu beginnen, etwa privilegierten Identitäten oder Conditional-Access-Richtlinien.
Auf dieser Grundlage lässt sich die Test- abdeckung schrittweise erweitern und parallel in automatisierte Prozesse überführen. Der Fokus verschiebt sich dabei von punktuellen Analysen hin zu einer kontinuierlichen Überwachung. Mit zunehmender Reife verändert sich auch die Zielsetzung: Während anfangs häufig versucht wird, möglichst viele Tests erfolgreich abzuschließen, rückt später die Frage in den Vordergrund, welche Anforderungen für die eigene Umgebung tatsächlich relevant sind. Abweichungen sind dabei nicht zwangsläufig als Fehler zu verstehen, sondern können das Ergebnis bewusst getroffener Entscheidungen sein.
Integration in CI/CD-Prozesse
In der Praxis setzen Sie Maester vermutlich zunächst als punktuelles Prüfwerkzeug ein. Einzelne Testläufe liefern einen Überblick über den Zustand eines Tenants und helfen dabei, offensichtliche Abweichungen von Best Practices zu identifizieren. Sein volles Potenzial entfaltet das Frame- work jedoch erst im kontinuierlichen Betrieb. Maester ist dann ein fester Bestandteil operativer Prozesse. Änderungen an der Konfiguration werden nicht mehr retrospektiv bewertet, sondern fortlaufend gegen definierte Anforderungen geprüft.
Hierfür bietet sich die Integration in bestehende Automatisierungsprozesse an. CI/CD-Plattformen wie Azure DevOps oder GitHub Actions sind hierfür ideal, da sie auf reproduzierbare Abläufe ausgelegt sind. In einem typischen Setup versionieren Sie Testdefinitionen in einem Repository und führen diese regelmäßig über Pipelines aus. Dies kann zeitgesteuert erfolgen, zum Beispiel in Form nächtlicher Prüfungen, oder ereignisbasiert nach Änderungen an Conditional-Access-Richtlinien. Jede relevante Anpassung im Tenant validieren Sie so implizit gegen die definierten Anforderungen.
Mit der Integration in CI/CD-Prozesse stellt sich zwangsläufig die Frage nach der sicheren Authentifizierung. Die Verwendung persönlicher Zugangsdaten in Pipeline-Konfigurationen ist dabei keine tragfähige Option. Maester nutzt in diesem Kontext moderne Authentifizierungsmechanismen wie die Workload Identity Federation. Anstelle von Client Secrets oder Zertifikaten baut es eine Vertrauensbeziehung zwischen der Pipeline und einer App- Registrierung in Entra auf, basierend auf etablierten OAuth-2.0-Mechanismen.
Dieser Ansatz reduziert nicht nur den Verwaltungsaufwand für Zugangsdaten, sondern minimiert gleichzeitig das Risiko kompromittierter Credentials. In der Praxis trägt dies wesentlich dazu bei, die Integration von Maester in produktive Umgebungen sicher und skalierbar umzusetzen.
Tests mit Tags strukturieren
Mit zunehmender Anzahl von Tests wird deren Strukturierung zu einem entscheidenden Faktor für die praktische Nutzbarkeit. Maester bietet hierfür die Möglichkeit, Tests über Tags logisch zu gruppieren. Auf diese Weise lassen sich beispielsweise MFA-relevante Prüfungen gezielt zusammenfassen und unabhängig von anderen Testbereichen ausführen. Ebenso können Sie sicherheitskritische Prüfungen von weniger kritischen Analysen trennen. Mit dem folgenden Kommando führen Sie alle Tests aus, die mit dem Tag "Teams" markiert sind:
Invoke-Maester -Tag "Teams"
In größeren Umgebungen entsteht bei konsequenter Nutzung von Tags eine modulare Teststrategie. Häufig ausgeführte Pipelines konzentrieren sich auf besonders relevante Prüfungen, während umfassendere Analysen in größeren Intervallen stattfinden. Dies ermöglicht es, Prüfungsumfang und Ausführungsfrequenz bewusst aufeinander abzustimmen und an betriebliche Anforderungen anzupassen.
Ergebnisse in anderen Systemen nutzen
Mit der zunehmenden Automatisierung der Testausführung gewinnt auch die Auswertung der Ergebnisse an Bedeutung. Standardmäßig stellt Maester die Ergebnisse als HTML-Reports bereit, die sich für eine manuelle Analyse eignen. Für den operativen Einsatz ist jedoch insbesondere die Weiterverarbeitung in strukturierten Formaten relevant.
Maester unterstützt hierfür unter anderem JSON-Ausgaben, die sich in bestehende Systeme integrieren lassen. Testergebnisse können wir beispielsweise in SIEM-Plattformen übernehmen, in Dashboards visualisieren oder zur automatisierten Erstellung von Tickets nutzen. Damit wird Maester nicht nur zu einem Prüfwerkzeug, sondern zu einer Datenquelle innerhalb einer übergeordneten Sicherheitsarchitektur. Die Ergebnisse dienen nicht allein der Bewertung, sondern bilden die Grundlage für weiterführende Prozesse und automatisierte Entscheidungen.
Grenzen und operative Realität
Trotz aller dargestellten Vorteile erfordert der Einsatz von Maester eine realistische Einordnung. Das Framework ist kein wartungsfreies System. Die direkte Nutzung des Microsoft-Graph-API bringt eine Abhängigkeit von dessen Stabilität und Datenmodellen mit sich. Änderungen an Schnittstellen können Anpassungen bestehender Tests erforderlich machen.
Hinzu kommt, dass die Definition sinnvoller Tests ein fundiertes Verständnis der eigenen Umgebung voraussetzt. Ohne klar formulierte Anforderungen besteht die Gefahr, dass Prüfungen entweder zu generisch bleiben oder nicht den tatsächlichen Bedarf abbilden. Auch organisatorische Aspekte sind nicht zu unterschätzen.
Fazit
Maester verschiebt den Fokus von der reinen Konfiguration hin zur systematischen Überprüfung von Sicherheitsanforderungen. Dieser Artikel hat gezeigt, wie an die Stelle punktueller Audits mit Maester ein Ansatz tritt, bei dem Konfigurationen kontinuierlich gegen definierte Erwartungen validiert werden. Für Organisationen mit dynamischen Cloudumgebungen und etablierten Automatisierungsprozessen bietet dies einen klaren Mehrwert.
Gleichzeitig ist Maester kein universelles Werkzeug. In Umgebungen mit geringer Veränderungsdynamik oder ohne entsprechende Automatisierungsstrukturen kann der Aufwand den Nutzen übersteigen. In solchen Szenarien bleiben klassische Audit-Ansätze weiterhin eine pragmatische Alternative. Richtig eingesetzt ist Maester weniger als einzelnes Produkt zu verstehen, sondern als methodischer Ansatz, um Sicherheit in modernen Cloudumgebungen strukturiert und nachvollziehbar umzusetzen.
(jp)
Links
[1] Maester 2.0: https://it-a.eu/q7p11
[2] Microsoft Graph PowerShell SDK: https://it-a.eu/q7p12
[3] Azure CLI: https://it-a.eu/q7p13