Wenn CA-Ausnahmen zur Schatten Governance werden ist das ein CIO Problem

Guest Sprawl entsteht nicht durch fehlende Features, sondern durch fehlende Zuständigkeit. Zugriffe bleiben liegen, CA-Ausnahmen werden zur Abkürzung, und niemand räumt sie wieder auf.

Ausnahmen sind kein Design, sie sind Schulden.

Cross-tenant access settings als verbindlicher Kontrollpunkt bringt Ordnung rein. Entscheidungen über tenantübergreifenden Zugriff und Trust werden nachvollziehbar. Der Preis ist klar: restriktivere Defaults und ein konsequentes Partner Onboarding statt schneller Ausnahmen.

Satz aus dem Lenkungskreis: „Collaboration ja. Aber externe Zugriffe müssen erklärbar und rückbaubar bleiben.“

Was hier mit Identity Operating Model gemeint ist

Die Kernfrage ist nicht, ob B2B genutzt wird. Entscheidend ist, wer Defaults setzt, wer Abweichungen genehmigt, und wer Trust für MFA und Device Claims freigibt. Ohne diese klaren Rollen endet es schnell in Doppel-MFA, Device Blocks und unkontrollierte Exclusions. Der Grund: Sign-in-, MFA- und Device-Informationen aus dem Home-Tenant werden ohne korrektes CTAS-Trust-Setup nicht vollständig in den Resource-Tenant übertragen respektive akzeptiert. Fehlen diese Signale, erzwingt der Conditional Access im Resource-Tenant unweigerlich eigene, zusätzliche Anforderungen.

Drei Betriebsmodelle die in der Praxis funktionieren

Die Modellwahl steuert Risikooberfläche, Betriebsaufwand und Nutzererlebnis. Ein Mischbetrieb ohne Zuordnung erzeugt Reibung, weil Conditional Access und Trust je Tenant unterschiedlich wirken. Lege pro Partnerklasse und Datenklasse ein Zielmodell fest. Dann entstehen wiederholbare Controls, und du musst im Zweifel auch Nein sagen können.

Modell 1 Guest first B2B Collaboration

Passt für Vendor, Supplier und JVs mit begrenztem Trust. Externe bleiben Guest, und Einladungen laufen gesteuert, zum Beispiel über Entitlement Management. Ohne CTAS Trust bezahlst du das häufig mit Doppel MFA oder Device Blocks.

Modell 2 Multi-Tenant Organization plus Cross-tenant Synchronization

Passt für Holding Tochter Setups, wenn Konzern Collaboration gewollt ist, die Tenants aber getrennt bleiben. Cross-tenant sync provisioniert B2B Nutzer zwischen Tenants, und Access bleibt im Zieltenant über lokale Gruppen steuerbar. Member Einsatz nur nach Review der Default Permissions. Der Preis ist striktes Zieltenant Design, sobald Member ins Spiel kommt.

Modell 3 B2B Direct Connect für definierte Use Cases

Passt primär für Teams Shared Channels. Direct connect erfordert beidseitige CTAS Konfiguration und bleibt auf diesen Use Case begrenzt. Der Preis ist geringe Wiederverwendung für allgemeinen App Zugriff.

Praxisnotiz: An M&A Tag 1 braucht ein Integrationsteam oft sofort Teams und SharePoint über mehrere Tenants. Wenn Ownership nicht klar ist, bleibt später Unklarheit zurück.

So gehst du vor ein Ablauf in sechs Schritten

Der Ablauf muss Defaults, Ausnahmen, Testbarkeit und Evidence verbinden. Sonst bleibt es Portal Arbeit ohne Steuerwirkung. Default Block ohne Analyse lädt Ausfälle ein.

Vorarbeit: Partnerklassen, Datenklassen und Zugriffstypen festlegen. M365 und Apps trennen. Grundsatz deny by default allow by contract.

• Schritt 1 Zugriffe erheben über Workbook und Sign in Logs, bei Bedarf SIEM Export.

• Schritt 2 Default Settings setzen. Outbound restriktiv. Partner nur über Organizational settings erlauben. Breakage Risiko als Entscheidung dokumentieren.

• Schritt 3 Trust Settings bewusst wählen. Trust MFA reduziert Mehrfach MFA. Device Claims nur für High Trust Partner und kompatible Device Strategie.

• Schritt 4 CA-Baseline definieren. Authentication strengths für sensible Ziele. Rollout über Report only. Emergency access accounts sauber excluden.

• Schritt 5 Identity Governance als Pflichtlayer. Access Packages mit Approval und Expiration. Access Reviews für externe Identitäten und Review history reports als Audit Output.

• Schritt 6 Tenant restrictions v2 und optional universal tenant restrictions über Global Secure Access gegen Schattennutzung. Enforcement nur bei Sign ins in andere Tenants.

Was hier bewusst nicht gemacht wird

• Keine Tenant Konsolidierung als Abkürzung.

• Kein Endpoint Deep Dive. Device Claims nur soweit für Trust und CA notwendig.

• Keine dauerhaften Exclusions als Reparaturbetrieb.

Betrieb und Governance die Audit überlebt

Governance ist erst belastbar, wenn du Ownership und Evidence nachweisen kannst. Ohne Logs und Reviews bleibt Kontrolle eine Behauptung.

RACI Minimum

• Holding setzt Defaults und betreibt Monitoring auf Cross-tenant Kategorien.

• Tochter verantwortet Partnerregeln und CTS Betrieb, plus Rollout von Tenant restrictions dort, wo Device und Network betroffen sind.

• App Owner und Security steuern Scopes, Reviews, Trust Freigaben, CA-Baseline und privilegiertes Monitoring.

Joiner und Leaver kurz gedacht: Joiner bevorzugt über Access Packages. Leaver bei CTS über automatisches Entfernen, sonst über Reviews und definierte Expiration.

Evidence, die du zeigen können musst: Audit Logs, Sign in Logs, Provisioning logs für CTS, und Review history reports. Für regulated Umfelder braucht es least privilege, privilegiertes Logging und regelmäßige Rezertifizierung.

Incident Learning: „Ein CTAS Change sperrt Outbound. Ohne Monitoring wird daraus ein Business Incident.“

Typische Fehler und Quick Wins

Die meisten Probleme sind vorhersehbar. Offene Defaults, dazu Exclusions ohne Ablauf und ohne Review.

Fehler, die teuer werden

• Default Outbound offen lassen und später mit Conditional Access flicken.

• Require compliant device für Externals ohne Device Trust.

• Trust MFA aktivieren, aber Ausnahmen übersehen, bis sie Standard werden.

• Direct connect nur einseitig konfigurieren.

• Member verteilen ohne Review der Default Permissions.

• Einladungen ohne Lifecycle und ohne Rezertifizierung.

• Evidence nicht planen. Reports fehlen im Audit. Quick Wins

• Workbook als Steuerungsartefakt nutzen.

• Emergency access accounts festlegen und ein Runbook dazu pflegen.

• Externe Conditional Access Policies zunächst per Report only betreiben.

• Invitation Governance setzen und Einladungen kontrollieren.

• Access Packages als Default für Vendor Zugriffe etablieren.

• Access Reviews für Teams und High Value Apps starten.

• Default Outbound restriktiv setzen und Monitoring auf Cross-tenant Kategorien aufsetzen.

Fazit

Tenantübergreifende Zusammenarbeit funktioniert nicht über Einladungen und Ausnahmen. Sie funktioniert über Defaults, Trust Entscheidungen und Evidence. Im Konzern ist das eine Risiko und Betriebsfrage, keine Stilfrage.

Konsequentes deny by default und Trust nur dort, wo Partnerklasse und Datenklasse es rechtfertigen. Das bringt stabileren Betrieb und weniger Schattennutzung. Der Preis ist Priorisierung und klare Ablehnung von Sonderwegen.

Messbar wird es über KPIs wie externe Konten ohne Sign ins über eine definierte Frist, Review coverage und Completion Rate, sowie blockierte Sign ins zu nicht allowlisted Tenants.