Policy Enforcer

Policy Enforcer überwacht die von Teams Manager verwalteten Microsoft-365-Gruppen und Teams, erkennt Änderungen, die gegen Ihre Governance-Richtlinien verstoßen, und behebt sie automatisch oder leitet sie in Microsoft Teams an eine prüfende Person weiter. Die Anwendung liest Änderungsereignisse aus dem Verzeichnis-Audit-Protokoll von Microsoft Entra über Microsoft Graph, gleicht sie mit den in Teams Manager definierten Richtlinien ab und stellt — nur dort, wo ein Administrator eine automatische Behebung konfiguriert hat — den letzten bekannten regelkonformen Wert im Tenant des Kunden wieder her. Die gesamte Verarbeitung läuft in von Solutions2Share betriebenen Azure-Diensten in der EU.

Datenverwaltungspraktiken

Alle Daten werden im Auftrag des Kunden-Tenants verarbeitet und pro Tenant isoliert (siehe Architektur- und Flussdiagramm). Policy Enforcer ist eine Erweiterung von Teams Manager: Richtliniendefinitionen und verwaltete Bereiche werden ausschließlich lesend aus Teams Manager übernommen; Policy Enforcer schreibt nie in Teams Manager. Alle Dienste und Datenspeicher von Policy Enforcer werden in Microsoft-Azure-Rechenzentren betrieben, die Solutions2Share in der Region Germany West Central (EU) nutzt. Die Anmeldung, Microsoft Graph und der Azure Bot Service, der Teams-Nachrichten zustellt, sind globale Microsoft-365-/Azure-Dienste.

Policy Enforcer liest keine Chat- oder Kanalnachrichten, keine E-Mails und keine Dokumentinhalte.

Die Anwendung greift auf folgende Datentypen zu, verarbeitet und speichert sie:

Governance-Konfiguration

Richtliniendefinitionen und verwaltete Bereiche (Microsoft-365-Gruppen-ID, Anzeigename, Vorlagenname und Teams-Manager-Metadatenwerte) aus der Teams-Manager-Instanz des Kunden sowie die Liste der Teams-Manager-Administratoren (Objekt-ID, UPN oder E-Mail-Adresse), anhand derer festgelegt wird, wer Policy Enforcer verwalten darf. Speicherung & Aufbewahrung: Azure SQL Database als Snapshot, der alle 30 Minuten aktualisiert wird; Aufbewahrung für die Laufzeit des Abonnements.

Gruppen-Änderungsereignisse und Verstöße

Gruppenverwaltungsereignisse aus dem Verzeichnis-Audit-Protokoll, ausschließlich für verwaltete Bereiche: die geänderte Eigenschaft (Team-Name, Sichtbarkeit, Vertraulichkeitsbezeichnung, Besitzer, Mitglieder), ihr alter und neuer Wert sowie die auslösende Person (UPN bzw. bei App-Änderungen der Anwendungsname). Ein erkannter Richtlinienverstoß wird zusammen mit seinem Bearbeitungsstatus, der prüfenden Person (Objekt-ID) und einem optionalen Kommentar gespeichert. Speicherung & Aufbewahrung: Azure SQL Database für die Laufzeit des Abonnements.

Regelkonforme Ausgangswerte

Der letzte regelkonforme Wert jeder überwachten Eigenschaft pro verwaltetem Bereich (z. B. der genehmigte Team-Name oder die Vertraulichkeitsbezeichnung), um ihn nach einem Verstoß wiederherstellen zu können. Speicherung & Aufbewahrung: Azure SQL Database für die Laufzeit des Abonnements.

Planner- und OneNote-Namen

Die Titel von Planner-Plänen und die Namen von OneNote-Notizbüchern verwalteter Gruppen. Aufgaben und Notizbuchseiten werden nicht gelesen. Speicherung & Aufbewahrung: Gespeichert werden nur geänderte Namen als Teil eines Verstoßes (siehe oben).

Verzeichnis-Profildaten (bei Bedarf gelesen)

Anzeigename, E-Mail-Adresse, UPN und Profilbild von Benutzern sowie Besitzer und Mitglieder verwalteter Gruppen — bei Bedarf gelesen, um Namen in der App und in Benachrichtigungen anzuzeigen und zu ermitteln, wer einen Verstoß prüfen muss. Speicherung & Aufbewahrung: keine Speicherung; Profilbilder werden höchstens eine Stunde im Arbeitsspeicher zwischengespeichert.

Daten für Microsoft-Teams-Benachrichtigungen

Für den Versand von Adaptive-Card-Benachrichtigungen speichert Policy Enforcer die Teams-Konversationsreferenz des Policy-Enforcer-Bots pro Empfänger sowie einen Zustellnachweis pro Karte (Objekt-ID des Empfängers, Teams-Nachrichten-ID, Zustellstatus). Speicherung & Aufbewahrung: Azure SQL Database für die Laufzeit des Abonnements.

Tenant- und Dienstkontodaten

Tenant-ID und -Name, Tenant-Einstellungen und — falls verbunden — die Objekt-ID des Dienstkontos für delegierte Vorgänge (siehe Microsoft Graph). Das Refresh-Token des Dienstkontos wird auf Anwendungsebene mit AES-256-GCM verschlüsselt und an die Tenant-ID gebunden; der Schlüssel liegt in Azure Key Vault. Speicherung & Aufbewahrung: Azure SQL Database für die Laufzeit des Abonnements.

Diagnosetelemetrie

Anfragen, Abhängigkeitsaufrufe und Fehler aus Web-UI, API und Hintergrundprozessen werden an Azure Application Insights / Log Analytics in derselben Region gesendet. In der Telemetrie von API und Web-UI werden E-Mail-Adressen, Objekt-IDs und Authorization-Header vor dem Versand entfernt. Erweitertes Diagnoseprotokoll von Microsoft-Graph-Anfrage- und -Antworttexten (maximal 16 KB, ohne Authorization-Header) ist standardmäßig deaktiviert und wird nur zur Fehleranalyse pro Tenant aktiviert. Speicherung & Aufbewahrung: 30 Tage.

Änderungserkennung ab Onboarding. Policy Enforcer bewertet Änderungen ab dem Zeitpunkt, an dem ein Tenant eingerichtet wird; historische Änderungen vor dem Onboarding werden weder durchsucht noch gemeldet.

Microsoft Graph

Policy Enforcer verwendet eine einzige mandantenfähige Microsoft-Entra-App-Registrierung. Ein Tenant-Administrator erteilt die Administratorzustimmung einmalig beim Onboarding. Erkennung und die meisten Behebungen laufen im Hintergrund mit Anwendungsberechtigungen. Einige wenige Vorgänge, die Microsoft Graph nicht mit Anwendungsberechtigungen unterstützt (Ändern der Vertraulichkeitsbezeichnung einer Gruppe, Umbenennen eines Planner-Plans, Lesen und Umbenennen von OneNote-Notizbüchern), laufen mit delegierten Berechtigungen eines dedizierten Dienstkontos, das ein Tenant-Administrator bei der Einrichtung verbindet. Abgesehen von der Installation der eigenen Teams-App für eine prüfende Person, die eine Benachrichtigung erhalten soll, schreibt Policy Enforcer nur in den Tenant, um eine verwaltete Gruppe nach einem Richtlinienverstoß auf ihren letzten regelkonformen Zustand zurückzusetzen — es löscht niemals Gruppen, Teams, Benutzer, Dateien oder Inhalte. Die Scope-Namen sind die Microsoft-Graph-Berechtigungsnamen, wie sie im Zustimmungsdialog angezeigt werden, und werden als Code dargestellt.

Vollständige Beschreibungen aller Berechtigungen sind in der Microsoft Graph-Berechtigungsreferenz veröffentlicht.

SharePoint-/weitere Workload-Berechtigungen

Nicht zutreffend. Policy Enforcer greift ausschließlich über Microsoft Graph auf Microsoft 365 zu. Die SharePoint-REST-API, Exchange Online, die Office 365 Management API oder andere Workload-APIs werden nicht verwendet, und es werden keine Berechtigungen dafür angefordert.

Microsoft Teams-Apps: Sicherheit und Compliance

Policy Enforcer wird als Microsoft Teams-App mit einer persönlichen Registerkarte (der Web-UI) und einem persönlichen Bot für Adaptive-Card-Benachrichtigungen bereitgestellt. Das App-Manifest fordert ausschließlich die Geräteberechtigungen identity und messageTeamMembers an, deklariert keine ressourcenspezifischen Zustimmungen (RSC), keine Messaging-Erweiterungen und keine Team- oder Gruppenchat-Bereiche und führt nur den Policy-Enforcer-Host als gültige Domain. Benutzer melden sich per Teams-Single-Sign-On an.

Der Bot sendet:

• Verstoßbenachrichtigungen — eine 1:1-Adaptive-Card an die Besitzer der betroffenen Gruppe und/oder die Policy-Enforcer-Administratoren mit einer Schaltfläche, die den Prüfdialog öffnet. Die Karte wird aktualisiert, sobald der Verstoß behoben oder verworfen wurde.
• Behebungshinweise — nach der Behebung bestimmter Verstöße einen Hinweis im Kanal „Allgemein“ des betroffenen Teams, den der Bot über den Teams-Kanal veröffentlicht, nicht über einen Schreibzugriff per Microsoft Graph.
• Antworten — eine Willkommensnachricht bei der Installation sowie kurze Hilfe-/Status-Antworten, wenn ein Benutzer dem Bot schreibt.

Der Bot liest den Text an ihn gesendeter Nachrichten nur, um diese Befehle zu erkennen; der Nachrichtentext wird nicht gespeichert.

Architektur- und Flussdiagramm

Datenfluss: (1) Ein Benutzer öffnet die Policy-Enforcer-App in Microsoft Teams, die die Web-UI aus App Service lädt und dessen API aufruft; (2) der Benutzer wird per Teams-Single-Sign-On angemeldet, und jede API-Anfrage trägt ein Microsoft-Entra-Token, das die API prüft (Signatur, Aussteller, Zielgruppe, Tenant); (3) alle 30 Minuten werden Richtliniendefinitionen und verwaltete Bereiche schreibgeschützt aus Teams Manager synchronisiert, über ein schreibgeschütztes Datenbankkonto, dessen Zugriff auf die Netzwerkadressen des Policy-Enforcer-Dienstes beschränkt ist; (4) alle 10 Minuten liest die Function App neue Gruppenverwaltungsereignisse aus dem Verzeichnis-Audit-Protokoll über Microsoft Graph, bewertet sie über Service-Bus-Warteschlangen anhand der Richtlinien, speichert erkannte Verstöße in Azure SQL und stellt — sofern der Administrator die automatische Behebung gewählt hat — den letzten regelkonformen Wert über Microsoft Graph wieder her, nachdem geprüft wurde, dass sich der Wert in der Zwischenzeit nicht erneut geändert hat; (5) Policy Enforcer sendet oder aktualisiert eine Adaptive Card über den Azure Bot Service, und die prüfende Person übernimmt im Prüfdialog eine Lösung oder verwirft den Verstoß. Alle Compute-Komponenten senden Telemetrie an Application Insights und Log Analytics.

Policy Enforcer verwendet drei bewusst getrennte Authentifizierungsabläufe auf einer einzigen mandantenfähigen Microsoft-Entra-App-Registrierung:

1. Anmeldung (delegiert). Benutzer melden sich per Teams-Single-Sign-On mit ihrem Microsoft-Geschäftskonto an. Die API akzeptiert nur für die Policy-Enforcer-App ausgestellte Token und leitet den Tenant aus dem geprüften Token ab.
2. Hintergrundverarbeitung (Anwendung). Nach der Administratorzustimmung beziehen Hintergrundprozesse Anwendungstoken für den Tenant des Kunden. Die Anmeldeinformationen der App liegen in Azure Key Vault und werden nie an den Browser übermittelt; der Browser erhält niemals ein Microsoft-Graph-Token.
3. Dienstkonto (delegiert, optional). Für die wenigen unter Microsoft Graph aufgeführten Vorgänge verbindet ein Tenant-Administrator ein dediziertes Dienstkonto. Dessen Refresh-Token wird mit AES-256-GCM verschlüsselt und an den Tenant gebunden; Token werden pro Vorgang mit dem minimal nötigen Scope angefordert.

Die Tenant-Isolation wird durch die in jedem Token enthaltene Tenant-ID erzwungen: Jede Anfrage ist auf den Tenant ihres geprüften Tokens beschränkt, jeder tenantbezogene Datensatz trägt diese Tenant-ID, und Graph-Token werden pro Tenant ausgestellt. Innerhalb eines Tenants ist der Zugriff rollenbasiert: Nur Teams-Manager-Administratoren können Policy Enforcer konfigurieren, und Gruppenbesitzer können — sofern aktiviert — Verstöße in ihren eigenen Bereichen prüfen. Alle Geheimnisse liegen in Azure Key Vault und werden von den Diensten über ihre systemseitig zugewiesenen verwalteten Identitäten gelesen; alle Endpunkte sind ausschließlich per HTTPS erreichbar, und die Datenbankverbindung ist verschlüsselt.

Ressourcen-Endpunkte

Domains, die aus dem Netzwerk bzw. Browser des Kunden erreichbar sein müssen.

Ausgehende Backend-Verbindungen (informativ)

Ausgehende Aufrufe des von Solutions2Share betriebenen Backends. Diese sind kundenseitig nicht konfigurierbar und werden aus Transparenzgründen aufgeführt.

Abhängigkeiten

Von Policy Enforcer verwendete Drittanbieter-Bibliotheken. Die Versionen entsprechen dem aktuellen Release.

Server

Client-Pakete

Build- und Test-Tooling

Wird ausschließlich zum Bauen und Testen der App verwendet; wird weder an den Browser ausgeliefert noch auf dem Server bereitgestellt.

Policy Enforcer verwendet keine Analyse- oder Werbe-Tracker von Drittanbietern. Das Backend von Policy Enforcer übermittelt Kundendaten ausschließlich an Microsoft-/Azure-Dienste und das Solutions2Share License Management Center.