Azure AD External Identities: Collaboration & Cross-Tenant Access Security Best Practices

Die Anforderungen an die Security werden – wie überall – auch beim Thema Collaboration immer höher.

Im folgenden Beitrag möchte die MFA Anforderungen an externe Benutzer und Gäste per Conditional Access Policy (CAP) für meinen Tenant definieren und die Collaboration Rechte für externe Benutzer/Gruppen/Tenants beschränken, bzw. im Standard keine Collaboration zulassen, sondern explizit für jede Collaboration-Situation die Rechte individuell definieren.

Conditional Access

Falls noch keine CAP besteht, die MFA für alle User (inkl. Guests) erfordert, ist diese anzulegen. Der im folgenden Beispiel gewählte User Scope Guests or external Users hat weitere Auswahl Optionen, z.B. für welche „Art“ von Gästen oder externen Benutzern es sich handeln soll. Zudem kann ausgewählt werden, ob die CAP für alle oder spezifische Azure AD Tenants gelten soll. Der Einfachheit halber soll die CAP alle Gäste und externen Benutzer erreichen.

Require daily MFA for all Guests

  • Users
    • Included users/groups
      • Guests or external users
    • Excluded users/groups
      • <Emergency Admins>
  • Cloud apps or actions
    • Included Cloud apps
      • All Cloud apps
  • Conditions
    • none
  • Grant
    • Allow access
      • Require multifactor authentication
  • Session
    • Sign-in frequency
      • Periodic reauthentication
        • 1 day
Conditional Access
Conditional Access
Default Settings für External Collaboration Settings

Im zweiten Schritt konfiguriere ich über die External collaboration settings die Grundeinstellungen in Bezug auf Gast-Zugriff, Einladungen, Self-Service Sign-up/Leave und Domain Restrictions. Die Einstellungen sollten natürlich möglichst restriktiv gewählt werden.

Guest user access / Guest user access restrictions
– Guest user access is restricted to properties and memberships of their own directory objects (most restrictive)

Ich möchte nicht, dass Gäste Eigenschaften/Mitgliedschaften von Benutzern meines Tenants und Gästen anderer Tenants sehen dürfen. Nur die Eigenschaften/Mitgliedschaften von anderen Gästen des gleichen Tenants sind möglich.

Guest invite settings / Guest invite restriction
– Only users assigned to specific admin roles can invite guest users

Ich möchte nicht, dass jeder Benutzer unseres Tenants Gäste einladen darf. Nur authorisierte Benutzer/Admins dürfen dies über die Rollenmitglieschaft.

Guest invite settings / Enable guest self-service sign up via user flows
– No

Ich möchte nicht, dass sich Gäste in meinem Tenant über User Flows selbst registrieren dürfen.

External user leave settings / Allow external users to remove themselves from your organization (recommended)
– Yes

Ich möchte, dass Gäste sich selbst aus meinem Tenant wieder entfernen dürfen. Dann muss ich das nicht tun :-).

Collaboration restrictions
– Allow invitations only to the specified domains (most restrictive)
– Target domains: tbd

Ich möchte Einladungen nur an definierte Tenant Domains zulassen, die ich hier definieren muss.

External Collaboration Settings
External Collaboration Settings
Default Settings für Cross-Tenant Access

Im dritten Schritt konfiguriere ich unter Cross-tenant access settings über die Default settings Option nun die Einstellungen, die erst mal ohne weitere Detailanpassung für den Inbound Access aller Gäste und externen User, sowie den Outbound Access meiner internen User gelten soll.

Cross-Tenant Access Settings: Default Settings (Default)
Cross-Tenant Access Settings: Default Settings (Default)

Der Inbound Access ist im Default so eingestellt, dass B2B Collaboration für alle externen Benutzer/Gruppen und für alle Applikationen erlaubt ist und B2B Direct Connect geblockt wird. Die Trust Settings sind alle deaktiviert (dies beinhaltet den Trust für MFA, Geräte-Compliance und Hybrid Join Status von externen Tenants.

Je nachdem, wie hoch der Sicherheitsanspruch ist, kann die Standardeinstellung strikter oder weniger strikt gewählt werden. In meinem Beispiel setze ich den Default strikter und lasse prinzipiell keine „unkontrollierte“ Collaboration zu.

Jeden externen Tenant, mit dem ich Inbound Collaboration in meinem Tenant betreiben möchte, schalte ich explizit frei nach Bedarf. Dadurch lässt sich granular einstellen, wer und welche App im Zuge der Collaboration verwendet werden darf/kann.

Der Outbound Access ist im Default ähnlich. B2B Collaboration ist für alle internen Benutzer/Gruppen und für alle Applikationen erlaubt und B2B Direct Connect ist geblockt. Trust Settings gibt es outbound nicht.

Auch hier hängt die Einstellung am Sicherheitsanspruch und auch hier setze ich den Default strikter und lasse erst mal keine generelle Outbound Collaboration zu.

Im Ergebnis bewirkt dies, dass meine internen User sich trotz Einladung aus einem anderen Tenant dort nicht anmelden können, solange ich dies nicht explizit für den Ziel-Tenant erlaube.

Cross-Tenant Access Settings: Default Settings (Custom)
Cross-Tenant Access Settings: Default Settings (Custom)
Organisationsspezifische Settings für Cross-Tenant Access

Für die Organisationen, mit denen ich nun Collaboration betreiben möchte, benötigt man nun eine eigene Konfiguration der Parameter, die vom Default abweichen, z.B. eben, dass den externen Benutzern (allen aus dem Tenant oder nur Teile) Zugriff auf den eigenen Tenant gewährt wird und häufig auch, dass der MFA, die der Tenant des externen Benutzers verwendet, vertraut wird (wenn nicht, kommt es häufig zu „doppelten“ MFAs, etc.).

Cross-Tenant Access Settings: Organizational Settings
Cross-Tenant Access Settings: Organizational Settings

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.