B2B-Zugriffe im Multi-Tenant-Konzern: drei Betriebsmodelle und sechs Schritte

Wenn Ausnahmen im Conditional Access zur Schatten-Governance werden, ist das ein CIO-Problem

Guest Sprawl, also Wildwuchs bei Gastkonten, entsteht durch fehlende Zuständigkeit. Zugriffe bleiben liegen, Ausnahmen im Conditional Access (CA) werden zur Abkürzung, und niemand räumt sie wieder auf.

Die Cross-tenant access settings (CTAS) als verbindlicher Kontrollpunkt bringen Ordnung hinein. Entscheidungen über tenantübergreifenden Zugriff und Trust werden nachvollziehbar. Der Preis sind restriktivere Defaults und ein konsequentes Partner-Onboarding.

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

Identity Operating Model

Die Kernfrage 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 unkontrollierten Ausnahmen. Der Grund: Ohne Trust Settings für eingehenden Zugriff erkennt der Resource-Tenant die MFA und die Device Claims aus dem Home-Tenant nicht an. Verlangt dort eine Conditional-Access-Policy MFA, müssen Gäste sie im Resource-Tenant erneut erledigen. Verlangt sie ein konformes oder hybrid eingebundenes Gerät, wird der Zugriff blockiert.

Drei Betriebsmodelle

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

Modell 1: Guest first (B2B Collaboration)

Das Modell passt für Anbieter, Lieferanten und Joint Ventures mit begrenztem Trust. Externe bleiben Guest, und Einladungen laufen gesteuert, zum Beispiel über Entitlement Management. Ohne Trust Settings in den CTAS zahlen Sie das häufig mit Doppel-MFA oder Device Blocks.

Modell 2: Multitenant Organization plus Cross-tenant Synchronization

Das Modell passt für Holding-Tochter-Setups, wenn Konzern-Collaboration gewollt ist, die Tenants aber getrennt bleiben. Die Cross-tenant Synchronization (CTS) provisioniert B2B-Nutzer zwischen den Tenants, und der Zugriff bleibt im Ziel-Tenant über lokale Gruppen steuerbar. CTS legt Nutzer standardmäßig als Member an. Prüfen Sie deshalb vor der ersten Synchronisierung die Default Permissions. Der Preis ist ein striktes Ziel-Tenant-Design, sobald Member ins Spiel kommen.

Modell 3: B2B Direct Connect für Shared Channels in Teams

Das Modell passt nur für Shared Channels in Teams (Teams Connect). Direct Connect erfordert eine beidseitige Konfiguration der CTAS. Der Preis ist, dass es sich für allgemeinen App-Zugriff nicht wiederverwenden lässt.

Praxisnotiz: Direkt nach dem Closing braucht ein Integrationsteam oft Teams und SharePoint über mehrere Tenants. Ist die Ownership dann nicht geklärt, bleiben diese Zugriffe später ohne Verantwortlichen liegen.

Vorgehen in sechs Schritten

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

Vor Schritt 1 legen Sie Partnerklassen, Datenklassen und Zugriffstypen fest und trennen M365 von anderen Apps. Grundsatz: Zugriff bleibt gesperrt, solange kein Vertrag ihn erlaubt (Deny by Default, Allow by Contract).

• Schritt 1: Zugriffe über das Workbook und die Sign-in-Logs erheben, bei Bedarf per SIEM-Export.

• Schritt 2: Default Settings setzen, Outbound restriktiv. Partner nur über die Organizational Settings erlauben. Das Breakage-Risiko als Entscheidung dokumentieren.

• Schritt 3: Trust Settings bewusst wählen. Trust für MFA reduziert Mehrfach-MFA. Device Claims nur für High-Trust-Partner mit kompatibler Device-Strategie.

• Schritt 4: CA-Baseline definieren, mit Authentication Strengths für sensible Ziele und Rollout im Modus „Report-only“. Für Externe setzen phishing-resistente Authentication Strengths Trust für MFA voraus. Emergency Access Accounts sauber ausnehmen.

• Schritt 5: Identity Governance als Pflicht-Layer: Access Packages mit Approval und Expiration, Access Reviews für externe Identitäten und Review-History-Reports als Nachweis für das Audit.

• Schritt 6: Tenant Restrictions v2 und optional Universal Tenant Restrictions über Global Secure Access gegen Schattennutzung. Sie greifen nur bei Anmeldungen mit Konten fremder Tenants.

Abgrenzung

• Keine Tenant-Konsolidierung als Abkürzung.

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

• Keine dauerhaften Ausnahmen als Reparaturbetrieb.

Betrieb und Nachweise für das Audit

Belastbar ist die Governance erst, wenn Sie Ownership und Kontrollen über Logs und Reviews belegen können.

RACI-Minimum

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

• Die Tochter verantwortet die Partnerregeln und den Rollout der Tenant Restrictions dort, wo Device und Network betroffen sind. Ist sie Quell-Tenant, betreibt sie auch die CTS.

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

Joiner und Leaver kurz gedacht: Joiner kommen bevorzugt über Access Packages. Leaver werden bei CTS automatisch entfernt, sonst greifen Reviews und eine definierte Expiration.

Für den Nachweis brauchen Sie Audit-Logs, Sign-in-Logs, Provisioning-Logs für CTS und Review-History-Reports. In regulierten Umfeldern kommen Least Privilege, privilegiertes Logging und regelmäßige Rezertifizierung hinzu.

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 und Ausnahmen ohne Ablaufdatum und ohne Review.

Fehler

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

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

• Trust für 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.

• Nachweise nicht planen, sodass im Audit die Reports fehlen.

Quick Wins

• Workbook als Steuerungsartefakt nutzen.

• Emergency Access Accounts festlegen und ein Runbook dazu pflegen.

• Conditional-Access-Policies für Externe zunächst im Modus „Report-only“ betreiben.

• Guest Invite Settings einschränken 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 das Monitoring auf die Cross-tenant-Kategorien aufsetzen.

Fazit

Tenantübergreifende Zusammenarbeit braucht restriktive Defaults, bewusste Trust-Entscheidungen und Nachweise. Im Konzern ist das eine Risiko- und Betriebsfrage.

Konsequentes Deny by Default und Trust nur dort, wo Partnerklasse und Datenklasse es rechtfertigen, bringen einen stabileren Betrieb und weniger Schattennutzung. Der Preis sind Priorisierung und die klare Ablehnung von Sonderwegen.

Messbar wird das über KPIs wie externe Konten ohne Anmeldung innerhalb einer definierten Frist, Review Coverage und Completion Rate sowie blockierte Anmeldungen bei Tenants, die nicht auf der Allowlist stehen.