Eigene M365 Terms of Use Teil 1: Tenantweite Einstellungen
Vermutlich eines der klassischsten Deutschen "Probleme" ist es, sich im Datenschutz sicher zu fühlen. Wir wollen gerne einen Vertrag mit jedem schließen, der irgendetwas tut. Jeder, der das Gebäude betritt, soll unterschreiben, und idealerweise sollten alle, mit denen wir sprechen, mit einem Wachssiegel bekräftigen das wir mit ihnen sprechen durften.
In der IT bildet sich dies so aus, dass wir gerne eine explizite Bestätigung von jedem Kooperationspartner haben. Sonst dürften wir ja nicht seine Audio- und Chatdaten "verarbeiten", in SharePoint wird er übrigens auch in der File Historie auftauchen. Oder vielleicht sollen auch bei der Anmeldung Geheimhaltungsvereinbarungen bestätigt werden, oder Verhaltensregeln, oder, oder, oder.
Der Einfachheit halber fasse ich mal all diese digitalen Dokumente als "Terms of Use" (ToU) zusammen.
Ich habe für M365 erst kürzlich wieder zusammensuchen müssen, welche Möglichkeiten man für Terms of Use hat. Da ich keine gute Zusammenfasung bei meiner Recherche gefunden habe denke ich, dass meine Ergebnisse auch für andere von interesse sein könnten.
In diesem ersten Teil werde ich die Einstellungen beschreiben, die für die gesamte M365-Umgebung einer Organisation und alle angebundenen Anwendungen wirken sollten.
Benutzertypen
Da es für verschiedene Benutzertypen unterschiedliche Optionen und Verhaltensweisen gibt, müssen wir vorab Begriffe abgleichen.
-
Interne Benutzer: Benutzer innerhalb des eigenen Tenants. Einverständnis wird in der Regel durch eine Betriebsvereinbarung oder Vertragsverhältnis bestätigt. Oftmals sind aber auch Dienstleister enthalten, von denen die Zustimmung zu Nutzungsbedingungen erforderlich ist.
Nicht "Interne Mitarbeiter"! Es ist der technische Account gemeint, nicht, welchem Unternehmen ein Benutzer organisatorisch angehört.
-
Gäste: Tenantfremde Benutzer, die explizit eingeladen wurden und sich authentifizieren müssen.
-
Sonstige / Anonyme Benutzer: Benutzer, die nicht in den Tenant eingeladen wurden und sich nicht authentifizieren. Diese erscheinen beispielsweise in Teams Meetings als „Unverified“
Mit diesem gemeinsamen Verständnis etabliert, steigen wir in die Einstellungen ein.
Privacy Statement URL
Der für Entra-Administratoren offensichtlichste Ort, um Datenschutzinformationen zu hinterlegen, ist in der Organisationsübersicht des Entra ID Admin Centers.
Da nur eine URL hinterlegt werden kann, ist ein Webserver erforderlich, auf dem die entsprechenden Inhalte gehostet werden.
Die gleiche Einstellung ist auch im M365 Admin Center verfügbar. Eine Änderung der URL in einem der beiden Admin-Center wird automatisch in beiden Ansichten übernommen.
Die etwas weniger detaillierte Microsoft Dokumentation
Die hinterlegte URL ersetzt in vielen (aber nicht allen) Microsoft-365-Produkten (z. B. Teams und SharePoint) den standardmäßigen „Privacy Statement“-Link.
Zwei Beispiele:
| Invite Link aus SharePoint | "Teams Meeting Join Experience" |
|---|---|
 |
 |
Neben diesen In-App URLs können Interner Benutzer oder Gäste auch immer in der MyAccount Page das Privacy Statement der aktuellen Organisation einsehen:
In der Praxis werden diese Links hauptsächlich von Datenschutzbeauftragten oder interessierten Benutzern aufgerufen, die als Hobby AGBs lesen. Rein theoretisch könnte sich aber natürlich auch ein anonymer Benutzer auf die URL verirren, wenn er auf einer der unterstützen Seiten landet. Es besteht weder eine Pflicht, diese Links anzusehen, noch sie zu bestätigen.
Aus rechtlicher Sicht könnte diese Einstellung in den meisten Fällen ausreichend sein, aber
⚠️ Ich bin kein Anwalt! ⚠️
Tenant Login Seite
Eine wichtige Ausnahme für die Änderung der „Privacy Statement“-URL ist der Login-Prozess – also die Seite, auf der sich Benutzer an der Umgebung der Organisation anmelden. Hier greift stattdessen das „Company Branding“ des Entra ID Admin Centers.
Diese Einstellungen gelten nur wenn man Entra ID Authentifizierung nutzt! Wurde ADFS oder ein 3rd Party Identity Provider föderiert , muss die Login erfahrung dort Konfiguriert werden.
Im Standard wird beim Anmeldevorgang – vom Eingeben des Benutzernamens bis zum Abschluss der Multi-Faktor-Authentifizierung – kein Footer angezeigt. Wird der Footer aktiviert, können sowohl der Text als auch die URLs für „Terms of Use“ und „Privacy and Cookies“ für individuelle Zwecke angepasst werden.
| Footer aktivieren | URLs setzen |
|---|---|
 |
 |
Weitere Informationen finden Sie in der zugehörigen Microsoft Dokumentation
Auch hier bleibt es unwahrscheinlich, dass Benutzer häufig auf diesen Link klicken.
Conditional Access
Wenn die explizite Bestätigung der Nutzungsbedingungen erforderlich ist, gibt es auf Tenant-Ebene keine Alternative zu den ‚Terms of Use‘, die über Conditional Access gesteuert werden.
Mit einer zugehörigen Conditional Access Policy, die für alle oder bestimmte Anwendungen gilt, müssen Benutzer vor dem Zugriff bestätigen, dass sie die als PDF hochgeladenen Terms of Use gelesen und akzeptiert haben.
Folgende Optionen sind verfügbar:
- Mehrsprachigkeit: Die ToU können in verschiedenen Sprachen bereitgestellt werden.
- Ausklappen erzwingen: Benutzer können dazu verpflichtet werden, das Dokument vor der Bestätigung auszuklappen.
- Zeitliche Erneuerung: Die Zustimmung kann nach einem festgelegten Zeitraum erneut eingefordert werden.
Es gibt allerdings einige Einschränkungen:
- Da es sich um ein Conditional Access Feature Handelt, ist für alle Benutzer, die im Umfang der ToU Pflicht sein sollen, eine Entra ID P1 Lizenz notwendig
- Wir werden oft gefragt, die Terms of Use für SharePoint, Teams oder Exchange einzeln einzurichten. Dies ist leider nicht wirklich möglich, da die M365 Applikationen so eng miteinander verdrahtet sind, dass immer "Office 365" als eine einzige Applikation behandelt werden sollte – die ToU muss also all diese Applikationen abdecken.
- Es darf maximal 40 Terms of Use geben, also sollte es nicht zu viele Applikationsspezifische ToUs geben
- Da Conditional Access nur bei der Authentifizierung greift, kann auf diesem Weg kein Einverständnis von Anonymen Benutzern eingeholt werden
Die Konfiguration von ToU ist bereits sehr gut behandelt, hier sind die besten Ressourcen die ich gesehen habe:
- Blog-Post aus der Perspektive eines Citrix-Administrators: How to use Azure AD Conditional Access to add a Terms of Use EULA
- Microsoft-Dokumentation zur Konfiguration: Terms of Use in Conditional Access
Zusammenfassung
Die bisherigen Optionen zeigen einige Herausforderungen in der Abdeckung:
| Einstellung | Trifft Benutzertypen | Wo Sichtbar | Explizite Bestätigung |
|---|---|---|---|
| Tenant Privacy Info | Alle (Je nach Anwendungsfall nur Interne Benutzer und Gäste) |
MyAccount, diverse Invite Mails / M365 App Seiten | ❌ Nicht erforderlich |
| Tenant Organisational Branding | Interne Benutzer, Gäste | Auf der Microsoft Login Seite | ❌ Nicht erforderlich |
| Conditional Access ToU | Interne Benutzer, Gäste | Bei Login (nach Bestätigungsintervall); pro Applikation eigene ToU möglich (bis zu 40) | ✅ Erforderlich |
Es gibt weiterhin Lücken in der Abdeckung bestimmter Benutzertypen oder in der Anforderung einer expliziten Bestätigung.
Dies sind jedoch noch nicht alle verfügbaren Möglichkeiten.
Im nächsten Teil werfen wir einen Blick auf Tools in Enterprise Apps, Teams, Intune und Exchange, um weitere Anwendungsfälle abzudecken und vorhandene Lücken soweit wie möglich zu schließen.
Kommentare