Erstellen Sie Ihre eigenen adaptiven Aufbewahrungsrichtlinien mit Azure Automation

Vermeiden Sie High-End-Lizenzen mit DIY-Adaptive-Aufbewahrungsrichtlinien

In meinem letzten Artikel über adaptive Bereiche für Microsoft 365-Aufbewahrungsrichtlinien habe ich erläutert, wie Sie benutzerdefinierte Azure AD-Attribute verwenden, um den Satz von Konten für die Aufbewahrungsverarbeitung zu identifizieren. Abgesehen davon, dass die Auswertung und Meldung der von der Bereichsabfrage gefundenen Kontengruppe zu lange dauert, funktionieren adaptive Bereiche gut und sind eine gute Möglichkeit, sicherzustellen, dass die Microsoft Purview-Aufbewahrungsverarbeitung automatisch auf bestimmte Kontengruppen angewendet wird, ohne dass ein Administrator fortlaufende Aktualisierungen vornehmen muss.

Der Nachteil adaptiver Bereiche besteht darin, dass sie Office 365 E5- oder Microsoft 365 E5-Konformitätslizenzen erfordern. Microsoft möchte unbedingt den Umsatz seiner Cloud-Benutzerbasis maximieren, möglicherweise aufgrund des langsameren Benutzerwachstums von Office 365. Das Fazit ist, dass für jede Funktion, die eine automatische Verarbeitung beinhaltet, insbesondere im Compliance-Bereich, in der Regel High-End-Lizenzen erforderlich sind.

Statische Aufbewahrungsrichtlinien

Microsoft 365-Aufbewahrungsrichtlinien mit statischen Bereichen stehen Office 365 E3-Mandanten zur Verfügung. Ein statischer Bereich bedeutet, dass Administratoren für die Verwaltung der von einer Richtlinie verarbeiteten Standorte verantwortlich sind. Ein Standort kann ein Postfach, eine Website, eine Gruppe, ein Team oder ein OneDrive-Konto sein.

Manchmal ist keine Verwaltung erforderlich, beispielsweise wenn eine Aufbewahrungsrichtlinie für alle Standorte eines bestimmten Typs gilt (z. B. alle Postfächer oder alle Websites). Unter anderen Umständen kann es erheblich aufwändig sein, sicherzustellen, dass die in einer Richtlinie angegebenen statischen Standorte korrekt sind.

PowerShell und Azure Automation stellen Updates für adaptive Aufbewahrungsrichtlinien bereit

Mir kam der Gedanke, dass es möglich sein sollte, eine Form der adaptiven Aufbewahrungsverarbeitung zum Selbermachen mit einer Kombination aus einem PowerShell-Skript und Azure Automation zu erstellen. Die Kombination repliziert die Leistung adaptiver Oszilloskope, ohne dass High-End-Lizenzen erforderlich sind. In diesem Szenario das PowerShell-Skript:

• Identifiziert die Gruppe von Speicherorten, die von der Aufbewahrungsrichtlinie verarbeitet werden sollen. Adaptive Bereiche fragen Azure AD ab, um diese Informationen zu finden. Unser Skript kann dasselbe tun.
• Überprüft die bereits in der Aufbewahrungsrichtlinie angegebenen Standorte, um Standorte zu berechnen, die entfernt und hinzugefügt werden sollen.
• Aktualisiert die Aufbewahrungsrichtlinie mit den neuen Standorten.

Azure Automation führt das Skript nach einem Zeitplan aus, um Änderungen an der Aufbewahrungsrichtlinie zu erkennen und anzuwenden. Die kürzlich durch Version 3.0 des Exchange Online-Verwaltungsmoduls hinzugefügte Unterstützung für verwaltete Identitäten erleichtert diesen Prozess, auch wenn die Cmdlets, die für den Compliance-Endpunkt ausgeführt werden, weiterhin Anmeldeinformationen zum Herstellen einer Verbindung erfordern (Microsoft arbeitet an der Behebung dieses Problems und könnte möglicherweise eine Lösung finden). verfügbar sein, wenn Sie diesen Artikel lesen).

Eine Beispielimplementierung

Um zu beweisen, dass das Prinzip funktioniert, habe ich ein Azure Automation-Runbook geschrieben (eine Version eines Skripts zur Ausführung in der Azure Automation-Umgebung). Adaptive Bereiche können Benutzer und Gruppen oder SharePoint Online-Sites verarbeiten. Für diese Demonstration verarbeitet das Skript Benutzerkonten, indem es die Exchange Online-Postfächer und OneDrive for Business-Konten aktualisiert, die den von der Abfrage gefundenen Benutzerkonten gehören.

Zunächst habe ich eine neue statische Aufbewahrungsrichtlinie mit einem statischen Geltungsbereich erstellt und einen Speicherort für Postfächer und OneDrive-Konten definiert (Abbildung 1). Obwohl dies wie ein seltsamer Schritt erscheinen mag, ist es wichtig, dies zu tun und die Richtlinie nicht auf alle verfügbaren Standorte auszurichten. Eine Richtlinie, bei der „Alle“ für einen Standort angezeigt wird, sucht nach allen Standorten und verarbeitet sie. Wenn Sie sich beispielsweise für die Verarbeitung aller Postfächer entscheiden, verarbeitet die Richtlinie alle Benutzer-, freigegebenen und inaktiven Postfächer.

Microsoft Purview behandelt Aufbewahrungsrichtlinien unterschiedlich, wenn sie alle verfügbaren Speicherorte für eine Arbeitslast (wie alle Postfächer) verarbeiten. Das vom Skript verwendete Cmdlet Set-RetentionCompliancePolicy kann Standorte nur aktualisieren, wenn die Richtlinie für die Verarbeitung ausgewählter Standorte eingerichtet ist. Mit anderen Worten: Das Cmdlet Set-RetentionCompliancePolicy kann eine Richtlinie nicht zwischen All-in- und selektiver Verarbeitung umschalten.

Das Drehbuch schreiben

Mit einer Zielrichtlinie, gegen die wir vorgehen müssen, können wir einige Postfächer und OneDrive-Konten finden, die verarbeitet werden müssen. Das Skript führt Folgendes aus:

• Stellt eine Verbindung zum Microsoft Graph PowerShell SDK mit einer verwalteten Identität her, um das Cmdlet Get-MgOrganization auszuführen und die Standarddomäne für den Mandanten zu finden. Wir benötigen dies, um die URLs für die OneDrive for Business-Zielkonten zu berechnen.
• Stellen Sie mit einer verwalteten Identität eine Verbindung zu Exchange Online her.
• Stellen Sie mithilfe der in Azure Key Vault gespeicherten Kontoanmeldeinformationen eine Verbindung zum Compliance-Endpunkt her. Die Notwendigkeit, gespeicherte Anmeldeinformationen zu verwenden, wird nicht mehr erforderlich sein, wenn Microsoft die Compliance-Cmdlets aktualisiert, um verwaltete Identitäten zu verwenden (oder die zertifikatbasierte Authentifizierung behebt).
• Verwenden Sie dieselben Kontoanmeldeinformationen, um eine Verbindung zum SharePoint Online-Verwaltungsendpunkt herzustellen.
• Suchen Sie die Gruppe der Zielpostfächer. In diesem Beispiel wird dasselbe benutzerdefinierte Attribut zum Markieren von Postfächern verwendet wie im vorherigen Artikel.
• Suchen Sie den Satz von OneDrive for Business-Konten im Mandanten und speichern Sie den Besitzernamen und die URL in einer Hashtabelle.
• Durchlaufen Sie die Postfächer, um den Benutzerprinzipalnamen für jedes Postfach anhand der OneDrive-Hash-Tabelle zu überprüfen. Wenn eine Übereinstimmung gefunden wird, wissen wir, dass das OneDrive-Konto dem Postfachbesitzer gehört, und speichern es daher in einer Liste.
• Rufen Sie den Satz aktueller Speicherorte in der Richtlinie mit dem Cmdlet Get-RetentionCompliancePolicy ab.
• Überprüfen Sie, welche Postfächer nicht im aktuellen Standortsatz enthalten sind, und erstellen Sie eine Liste mit Postfächern, die Sie der Richtlinie hinzufügen möchten. Machen Sie dasselbe für OneDrive-Konten.
• Überprüfen Sie, ob Postfächer und OneDrive-Konten in den Geltungsbereich der Richtlinie fallen, dies aber nicht der Fall sein sollte. Wenn wir welche finden, fügen wir sie einer Liste von Standorten hinzu, die aus der Richtlinie entfernt werden sollen.
• Rufen Sie das Cmdlet Set-RetentionCompliancePolicy auf, um Standorte hinzuzufügen, die in der Richtlinie enthalten sein sollten, und diejenigen zu entfernen, die nicht enthalten sein sollten.
• Rufen Sie das Cmdlet Get-RetentionCompliancePolicy auf, um die jetzt von der Richtlinie abgedeckten Standorte zu melden.

Ich habe den Code, den Microsoft verwendet, um aktive Bereiche für Aufbewahrungsrichtlinien zu implementieren, noch nie gesehen, aber ich bin mir sicher, dass fast die gleiche Art von Verarbeitung stattfindet, um herauszufinden, welche Speicherorte eine Richtlinie abdecken soll. Ich bin sicher, dass der Microsoft-Code eleganter und präziser ist als meiner (und nicht in PowerShell geschrieben), aber der Punkt ist, dass der Code funktioniert und die gleiche Aufgabe erfüllt wie ein adaptiver Bereich.

Beachten Sie, dass eine Compliance-Richtlinie maximal 1.000 einzelne Postfächer unterstützt. Noch wichtiger ist, dass der Grenzwert für SharePoint Online-Websites und OneDrive for Business-Konten niedriger ist (100). Tests und Fehlerbehandlung für in der Produktion verwendete Skripte müssen diese Einschränkungen berücksichtigen. Um die Beschränkungen zu umgehen, können Sie mehrere Richtlinien mit denselben Aufbewahrungseinstellungen erstellen, die auf verschiedene Gruppen von Postfächern, Websites und Konten abzielen.

Cybersicherheitsrisikomanagement für Active Directory

Entdecken Sie, wie Sie AD-Angriffe mit diesen Cybersicherheits-Risikomanagementlösungen verhindern und sich davon erholen können.

Ausführen des Skripts

Sie können das Skript von GitHub herunterladen und selbst testen. Das Skript wird in Azure Automation ausgeführt. Einige Änderungen am Authentifizierungsabschnitt des Codes sorgen dafür, dass er interaktiv ausgeführt wird.

Abbildung 2 zeigt die Ergebnisse des Skripts nach der Ausführung im Testbereich einer Azure Automation-Sitzung. Die Ausgabe zeigt Objektkennungen für die Postfächer, die hinzugefügt und entfernt werden sollen, während URLs für OneDrive for Business-Konten verwendet werden. Dies sind die Werte, die zur internen Identifizierung von Standorten verwendet werden. Wenn Sie möchten, wäre es einfach, die Ausgaben so zu ändern, dass sie die Namen der Konten anzeigen. Da das Skript jedoch als geplante Azure Automation-Aufgabe ausgeführt wird, wird sich wahrscheinlich niemand die Ausgabe ansehen, es sei denn, es geht etwas schief.

Abbildung 3 zeigt die Eigenschaften der Aufbewahrungsrichtlinie nach der Ausführung des Skripts. Während zuvor nur ein Standort für Exchange Online und OneDrive for Business angegeben war, umfasst die Richtlinie jetzt 24 Postfächer und 23 Konten. Die Diskrepanz zwischen den beiden Zahlen ist auf ein neues Konto zurückzuführen, das sich noch nicht bei OneDrive angemeldet hat.

Das gleiche hier erläuterte Prinzip könnte auf die Erstellung einer adaptiven Aufbewahrungsrichtlinie für Microsoft 365-Gruppen oder SharePoint Online-Sites ausgedehnt werden. Es ist nur eine Frage der PowerShell-Programmierung.

DIY ist nicht immer möglich

Die Neuerstellung einer Microsoft 365-Funktion mit DIY-Code ist nicht immer möglich. In diesem Fall ist es relativ einfach, eine benutzerdefinierte Form der adaptiven Aufbewahrungsverarbeitung zu erstellen. Die Kombination von PowerShell und Azure Automation repliziert effektiv, was Microsoft in adaptiven Bereichen bereitstellt.