Workspaces Pooling: Governance für Microsoft 365 ohne tenant-weite Berechtigungen

Einige Unternehmen, die in einem geteilten Microsoft-365-Tenant arbeiten, schränken ein, welche Anwendungsberechtigungen eine Drittanbieter-Lösung halten darf. Das ist eine bewusste Entscheidung: Berechtigungen im Application-Kontext wie Group.ReadWrite.All geben einer Lösung tenant-weite Schreibrechte auf jede Microsoft-365-Gruppe, und ein Sicherheitsteam bevorzugt möglicherweise einen engeren Rahmen.

Für eine Workspace-Governance-Lösung entsteht daraus eine konkrete Herausforderung. Wenn ein Endanwender einen neuen Workspace beantragt, muss die Lösung normalerweise auf Anfrage eine Microsoft-365-Gruppe und die zugehörigen Teams- und SharePoint-Komponenten anlegen — Operationen, die traditionell genau auf diesen tenant-weiten Berechtigungen beruhen.

Valprovia Governance enthält einen integrierten Deployment-Modus, der genau für diese Situation entwickelt wurde: Workspaces Pooling, kombiniert mit einem rein delegierten Berechtigungsmodus.

Um welche Anwendungsberechtigungen es geht

Zwei Berechtigungen stehen üblicherweise im Zentrum des Gesprächs:

• Group.ReadWrite.All im Application-Kontext gewährt tenant-weite Schreibrechte auf jede Microsoft-365-Gruppe.
• Sites.FullControl.All im Application-Kontext gewährt Vollzugriff auf jede SharePoint Site Collection im gesamten Tenant.

Für viele Unternehmen sind diese Berechtigungen unproblematisch, und der Governance-Lösung wird zugetraut, sie angemessen zu nutzen. Für andere — insbesondere landesspezifische Bereitstellungen in einem Konzern-Tenant oder Organisationen mit strengen Sicherheitsanforderungen an Drittanbieter — gilt der Grundsatz, dass eine Governance-Lösung keine tenant-weiten Schreibrechte auf Ressourcen außerhalb ihres eigenen Wirkungsbereichs halten sollte.

Workspaces Pooling ist der Deployment-Modus, mit dem Valprovia Governance unter dieser Vorgabe arbeitet.

Workspaces Pooling im Überblick

Anstatt bei jedem Workspace-Antrag eine neue Microsoft-365-Gruppe anzulegen, erstellt die IT-Abteilung im Voraus eine Menge leerer Teams-Gruppen. Diese Gruppen liegen in einem Pool und warten darauf, beansprucht zu werden. Wenn ein Benutzer einen neuen Workspace beantragt, entnimmt die SharePoint Governance eine Gruppe samt zugehöriger Site Collection aus dem Pool, konfiguriert sie gemäß den Governance-Regeln und übergibt sie dem Benutzer.

Ein hilfreiches Bild dazu: Stellen Sie es sich wie einen Autoverleih vor. Die Autos (Teams-Gruppen) werden im Voraus gekauft und vorbereitet. Wenn ein Kunde (Endanwender) ankommt, erhält er ein verfügbares Auto, das seinen Anforderungen entspricht. Das Auto wird dann für ihn personalisiert (konfiguriert), bevor es übergeben wird.

Weil die Gruppen bereits existieren, wenn ein Antrag gestellt wird, muss Valprovia Governance zur Laufzeit niemals Gruppen anlegen — die sonst erforderlichen tenant-weiten Berechtigungen werden schlicht nicht benötigt.

Wie Pooling funktioniert

Workspaces Pooling besteht aus zwei Teilen: Producer und Consumer.

Producer — die IT-Abteilung

Ein Mitglied des IT-Teams führt ein von Valprovia bereitgestelltes PowerShell-Skript aus. Das Skript nimmt eine CSV-Datei entgegen, die beschreibt, wie viele Pool-Gruppen je Kombination aus Governance Template und Security Level angelegt werden sollen. Für jede Gruppe führt das Skript folgende Schritte aus:

• Legt eine Microsoft-365-Gruppe an und nimmt eine Grundkonfiguration vor (zum Beispiel, ob Gäste beitreten dürfen).
• Weist einen dedizierten Service-Benutzer als Owner und Member zu.
• Wandelt die Gruppe in eine Teams-Gruppe um.
• Wendet die SharePoint-Sharing-Einstellungen an, die zum Security Level passen.
• Setzt einen Marker in eine konfigurierbare Gruppen-Eigenschaft, der festhält, für welche Kombination aus Governance Template und Security Level die Gruppe vorbereitet wurde.

Das Skript wird von einem IT-Administrator mit den entsprechenden Rechten ausgeführt: Rechte zum Anlegen von Microsoft-365-Gruppen und Teams sowie SharePoint-Administrator-Rechte. Es verfügt über einen Preview-Modus, um die CSV zu validieren, bevor tatsächlich Änderungen vorgenommen werden.

Consumer — Valprovia Governance

Wenn ein Endanwender einen Workspace beantragt, durchsucht Valprovia Governance den Pool nach einer noch nicht beanspruchten Gruppe, deren Marker zu der vom Benutzer gewählten Kombination aus Governance Template und Security Level passt. Ist eine passende Gruppe verfügbar, wird sie beansprucht (als vergeben markiert, sodass kein anderer Antrag sie greifen kann), und die Provisionierung setzt sich fort: Anzeigename, Mitglieder, Kanäle und alle weiteren template-gesteuerten Einstellungen werden auf die reservierte Gruppe angewendet.

Ist keine passende Gruppe verfügbar, wird der Antrag abgelehnt, und die IT-Abteilung wird benachrichtigt, den Pool aufzufüllen.

Governance Templates und Security Levels

Zwei Konzepte sind hier für Leser wichtig, die mit Valprovia Governance weniger vertraut sind. Ein Governance Template ist eine Vorlage für einen Workspace-Typ — Namenskonventionen, Standard-Kanäle, Genehmigungsschritte. Ein Security Level ist ein Paket sicherheitsbezogener Einstellungen — Gastzugriff, SharePoint-Sharing, Gruppensichtbarkeit — das angewendet wird, wenn ein Template verwendet wird.

Der Pool benötigt einen eigenen Satz Gruppen für jede Kombination aus Template und Security Level, die Endanwender auswählen können, weil die Pooling-Funktion unter eingeschränkten SharePoint-Berechtigungen arbeitet. Diese Berechtigungen erlauben es nicht, Sharing-Einstellungen nach der Erstellung einer Gruppe zu ändern, sodass die Einstellung bereits beim Anlegen der Gruppe festgelegt werden muss. Bietet Ihr Unternehmen etwa „Project Team"-Workspaces mit drei Security Levels an, enthält der Pool drei separate Ausprägungen von Project-Team-Gruppen.

Wie sich die Workspace-Erstellung präsentiert

Unter Pooling ist das Workspace-Erstellungsformular etwas schlanker als in einer Standard-Bereitstellung. Einige Werte werden automatisch aus dem Pool zugewiesen, anstatt vom Antragsteller eingegeben zu werden — am sichtbarsten die Team-E-Mail-Adresse des Workspaces, die im Formular schreibgeschützt erscheint und einem vordefinierten, nicht editierbaren Namensschema folgt, das beim Anlegen des Pools festgelegt wurde.

Die Konfiguration der Templates im Admin Portal ist ebenfalls einfacher. Einstellungen, deren Werte bei der Erstellung der Pool-Gruppe entschieden werden — das SharePoint-Site-Theme, das Sensitivity Label, das Mail-Präfix — werden Administratoren nicht mehr pro Template zur Konfiguration angeboten. Jeder Workspace eines gegebenen Typs ist bereits konfiguriert; das Template muss diese Werte nicht mehr beschreiben.

Wählt ein Benutzer eine Kombination, für die keine Pool-Gruppe verfügbar ist, kann der Antrag nicht fortgesetzt werden. Valprovia Governance zeigt eine explizite Meldung, statt den Antrag anzunehmen, und die IT-Abteilung wird benachrichtigt, damit sie den Pool auffüllen kann.

Was bei der IT-Abteilung bleibt

Der zentrale Vorteil für das IT-Team: Die Governance-Lösung läuft mit einem kleinen, klar abgegrenzten Satz delegierter Berechtigungen — nicht mit den tenant-weiten Berechtigungen, die eine Standard-Bereitstellung benötigen würde. Der Service-Benutzer von Valprovia Governance ist ein regulärer Benutzer-Account — kein Administrator — geschützt durch MFA und Conditional-Access-Richtlinien, und er kann ausschließlich die Workspaces im eigenen Pool verwalten. Er hat keinerlei Zugriff auf andere Gruppen, Teams oder SharePoint-Sites im Tenant.

Weil Pool-Gruppen von der IT-Abteilung angelegt werden, behält die IT-Abteilung die volle Ownership über jedes governte Team. Die Erstellung der Gruppen, die initiale Konfiguration und das Auffüllen des Pools sind allesamt IT-gesteuert, laufen unter den eigenen Credentials eines IT-Administrators und auf einem Zeitplan, den das IT-Team festlegt.

Lifecycle-Aktionen funktionieren weiterhin

Archivieren, Wiederherstellen und Löschen eines Workspaces funktionieren unter einer Pooling-Bereitstellung uneingeschränkt weiter. Valprovia Governance verwendet Microsoft-Graph-Pfade, die die tenant-weiten Administrator-Berechtigungen — die bewusst nicht erteilt wurden — nicht erfordern. Die üblichen Lifecycle-Aktionen bleiben Administratoren und Workspace-Ownern somit über die gleichen Oberflächen zugänglich, die sie in jeder Valprovia-Governance-Bereitstellung nutzen würden.

Was der Endanwender sieht

Aus Sicht des Endanwenders fühlt sich eine Pooling-Bereitstellung genauso an wie jede andere Valprovia-Governance-Bereitstellung. Der Ablauf der Workspace-Erstellung ist in seiner Form unverändert: Template und Security Level wählen, einen Namen eingeben, den Antrag absenden, gegebenenfalls auf eine Genehmigung warten und eine Benachrichtigung erhalten, sobald der Workspace bereitsteht.

Zwei kleine technische Details sind es wert, benannt zu werden, weil sie nur in Randfällen sichtbar werden: Die SharePoint-Site-URL behält das Pool-Format bei, statt dem Workspace-Namen zu entsprechen, und dasselbe gilt für die E-Mail-Adresse, sofern sie nicht umbenannt wird. Ein Umbenennen ist heute nicht Bestandteil des Standard-Produktflusses, ist aber als Add-on verfügbar. Beides zeigt sich in den meisten Endanwender-Abläufen nicht.

Ein paar Punkte, die es zu planen gilt

Vor der Aktivierung einer Pooling-Bereitstellung lohnen sich ein paar Überlegungen:

• Dimensionierung des Pools je Kombination aus Template und Security Level. Wird eine Kombination zu klein dimensioniert, werden Anträge für diese Kombination abgelehnt, bis der Pool aufgefüllt ist. Die Nachfrage je Workspace-Typ abzuschätzen, ist eine Entscheidung des IT-Teams, die gemeinsam mit Valprovia während des Rollouts getroffen wird.
• Gelöschte Workspaces kehren nicht in den Pool zurück. Das Auffüllen erfolgt durch erneutes Ausführen des Pool-Skripts, nicht durch automatisches Recycling.
• Pool-Monitoring ist Teil des Releases. Valprovia Governance zeigt den Pool-Bestand an und benachrichtigt das IT-Team, wenn er zur Neige geht; das Auffüllen bleibt eine Aktion des IT-Teams.
• Eine SharePoint-Lifecycle-Aktion ist nicht möglich: die Wiederherstellung einer Site aus dem Papierkorb. Das Wiederherstellen einer gelöschten Site Collection erfordert tenant-weite SharePoint-Administrator-Berechtigungen — genau jene, die das Pooling-Modell bewusst nicht gewährt.

Wo Pooling passt

Workspaces Pooling ist ein Standard-Produktmerkmal von Valprovia Governance — kein kundenspezifischer Workaround.

Es ist der richtige Deployment-Modus für Organisationen, deren Global IT einschränkt, welche tenant-weiten Anwendungsberechtigungen eine Drittanbieter-Lösung halten darf, und für abgegrenzte Bereitstellungen innerhalb eines geteilten Tenants — sei die Abgrenzung ein Land, eine Abteilung oder eine von vielen Tochtergesellschaften in einer Konzernstruktur —, in denen die Governance-Lösung nur die Ressourcen erreichen soll, die sie direkt verwaltet.

Für Organisationen ohne diese Einschränkungen bleibt die Standard-Bereitstellung von Valprovia Governance verfügbar, und beide Modi werden als gleichwertige Optionen unterstützt.

Zusammengefasst

Workspaces Pooling ermöglicht es Valprovia Governance, in Microsoft-365-Tenants zu arbeiten, in denen breite tenant-weite Anwendungsberechtigungen nicht verfügbar oder nicht gewünscht sind. Die IT-Abteilung legt die Pool-Gruppen im Voraus an und behält die volle Ownership über jede Gruppe und jede SharePoint-Site, die die Governance-Lösung verwaltet. Endanwender erleben den Workspace-Erstellungsablauf so, wie sie ihn kennen. Lifecycle-Aktionen bleiben Workspace-Ownern und Administratoren über die gewohnten Valprovia-Governance-Oberflächen zugänglich — über Microsoft-Graph-Pfade, zu deren Aufruf der Service-Benutzer berechtigt ist.