{"id":904,"date":"2024-12-31T20:05:35","date_gmt":"2024-12-31T19:05:35","guid":{"rendered":"https:\/\/sparrow365.de\/?p=904"},"modified":"2025-04-20T22:38:41","modified_gmt":"2025-04-20T20:38:41","slug":"eigene-m365-terms-of-use-teil-1-tenantweite-einstellungen","status":"publish","type":"post","link":"https:\/\/sparrow365.de\/index.php\/2024\/12\/31\/eigene-m365-terms-of-use-teil-1-tenantweite-einstellungen\/","title":{"rendered":"Eigene M365 Terms of Use Teil 1: Tenantweite Einstellungen"},"content":{"rendered":"

Vermutlich eines der klassischsten Deutschen "Probleme" ist es, sich im Datenschutz sicher<\/strong> zu f\u00fchlen. Wir wollen gerne einen Vertrag mit jedem schlie\u00dfen, der irgendetwas tut. Jeder, der das Geb\u00e4ude betritt, soll unterschreiben, und idealerweise sollten alle, mit denen wir sprechen, mit einem Wachssiegel bekr\u00e4ftigen das wir mit ihnen sprechen durften.<\/p>\n

In der IT bildet sich dies so aus, dass wir gerne eine explizite Best\u00e4tigung<\/strong> von jedem Kooperationspartner haben. Sonst d\u00fcrften wir ja nicht seine Audio- und Chatdaten "verarbeiten", in SharePoint wird er \u00fcbrigens auch in der File Historie auftauchen. Oder vielleicht sollen auch bei der Anmeldung Geheimhaltungsvereinbarungen best\u00e4tigt werden, oder Verhaltensregeln, oder, oder, oder. <\/p>\n

Der Einfachheit halber fasse ich mal all diese digitalen Dokumente als "Terms of Use" (ToU)<\/strong> zusammen.<\/p>\n

Ich habe f\u00fcr M365<\/strong> erst k\u00fcrzlich wieder zusammensuchen m\u00fcssen, welche M\u00f6glichkeiten man f\u00fcr Terms of Use<\/em><\/strong> hat. Da ich keine gute Zusammenfasung bei meiner Recherche gefunden habe denke ich, dass meine Ergebnisse auch f\u00fcr andere von interesse sein k\u00f6nnten. <\/p>\n

In diesem ersten Teil werde ich die Einstellungen beschreiben, die f\u00fcr die gesamte M365-Umgebung<\/strong> einer Organisation und alle angebundenen Anwendungen wirken sollten<\/em><\/strong>.<\/p>\n

\n

In Teil 2 gehe ich auf M\u00f6glichkeiten in eigenen angebundenen Applikationen ein<\/em><\/a><\/p>\n<\/blockquote>\n


<\/p>\n

\n

Benutzertypen<\/h2>\n

Da es f\u00fcr verschiedene Benutzertypen unterschiedliche Optionen und Verhaltensweisen gibt, m\u00fcssen wir vorab Begriffe abgleichen.<\/p>\n

    \n
  1. \n

    Interne Benutzer<\/strong>: Benutzer innerhalb des eigenen Tenants. Einverst\u00e4ndnis wird in der Regel durch eine Betriebsvereinbarung oder Vertragsverh\u00e4ltnis best\u00e4tigt. Oftmals sind aber auch Dienstleister enthalten, von denen die Zustimmung zu Nutzungsbedingungen erforderlich ist.<\/p>\n

    \n

    Nicht "Interne Mitarbeiter"!<\/strong> Es ist der technische Account gemeint, nicht, welchem Unternehmen ein Benutzer organisatorisch angeh\u00f6rt.<\/em><\/p>\n<\/blockquote>\n<\/li>\n

  2. \n

    G\u00e4ste<\/strong>: Tenantfremde Benutzer, die explizit eingeladen wurden und sich authentifizieren m\u00fcssen.<\/p>\n<\/li>\n

  3. \n

    Sonstige \/ Anonyme Benutzer<\/strong>: Benutzer, die nicht in den Tenant eingeladen wurden und sich nicht authentifizieren. Diese erscheinen beispielsweise in Teams Meetings als \u201eUnverified\u201c<\/p>\n<\/li>\n<\/ol>\n

    Mit diesem gemeinsamen Verst\u00e4ndnis etabliert, steigen wir in die Einstellungen ein.<\/p>\n


    <\/p>\n

    \n

    Privacy Statement URL<\/h2>\n

    Der f\u00fcr Entra-Administratoren offensichtlichste Ort, um Datenschutzinformationen zu hinterlegen, ist in der Organisations\u00fcbersicht des Entra ID Admin Centers<\/strong><\/a>.
    \nDa nur eine URL hinterlegt werden kann, ist ein Webserver erforderlich, auf dem die entsprechenden Inhalte gehostet werden.<\/p>\n

    \"PrivacyStatementURLinEntra\"<\/p>\n


    <\/p>\n

    Die gleiche Einstellung ist auch im M365 Admin Center<\/strong><\/a> verf\u00fcgbar. Eine \u00c4nderung der URL in einem der beiden Admin-Center wird automatisch in beiden Ansichten \u00fcbernommen.<\/p>\n

    \"M365AdminCenterPrivacyStatement\"<\/p>\n

    \n

    Die etwas weniger detaillierte<\/em> Microsoft Dokumentation<\/em><\/a><\/p>\n<\/blockquote>\n

    \n

    Die hinterlegte URL ersetzt in vielen (aber nicht allen<\/em>) Microsoft-365-Produkten (z. B. Teams und SharePoint) den standardm\u00e4\u00dfigen \u201ePrivacy Statement<\/strong>\u201c-Link. <\/p>\n

    Zwei Beispiele:<\/p>\n\n\n\n\n\n
    Invite Link aus SharePoint<\/th>\n"Teams Meeting Join Experience"<\/a><\/th>\n<\/tr>\n<\/thead>\n
    \"SharePoint<\/td>\n\"TeamsMeetingJoinUrl\"<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n


    <\/p>\n

    Neben diesen In-App URLs k\u00f6nnen Interner Benutzer<\/strong> oder G\u00e4ste<\/strong> auch immer in der MyAccount Page<\/strong><\/a> das Privacy Statement<\/strong> der aktuellen Organisation einsehen: <\/p>\n

    \"PrivacyStatementinMyAccount\"<\/p>\n

    \n


    <\/p>\n

    Will man sich die Privacy Statements aller Organisationen ansehen in denen man Mitglied oder Gast ist, kann man dies unter "Organisations"<\/strong><\/a> tun.<\/p>\n

    \"Privacy<\/p>\n

    \n


    <\/p>\n

    In der Praxis werden diese Links haupts\u00e4chlich von Datenschutzbeauftragten oder interessierten Benutzern aufgerufen, die als Hobby AGBs lesen. Rein theoretisch k\u00f6nnte sich aber nat\u00fcrlich auch ein anonymer Benutzer<\/strong> auf die URL verirren, wenn er auf einer der unterst\u00fctzen Seiten landet. Es besteht weder eine Pflicht, diese Links anzusehen, noch sie zu best\u00e4tigen<\/em><\/strong>.
    \nAus rechtlicher Sicht k\u00f6nnte diese Einstellung in den meisten F\u00e4llen ausreichend sein, aber
    \n\u26a0\ufe0f Ich bin kein Anwalt!<\/em> \u26a0\ufe0f<\/p>\n


    <\/p>\n

    \n

    Tenant Login Seite<\/h2>\n

    Eine wichtige Ausnahme f\u00fcr die \u00c4nderung der \u201ePrivacy Statement\u201c-URL ist der Login-Prozess \u2013 also die Seite, auf der sich Benutzer an der Umgebung der Organisation anmelden. Hier greift stattdessen das \u201eCompany Branding<\/a>\u201c des Entra ID Admin Centers.<\/p>\n

    \n

    Diese Einstellungen gelten nur wenn man Entra ID Authentifizierung nutzt! Wurde ADFS oder ein 3rd Party Identity Provider f\u00f6deriert , muss die Login erfahrung dort Konfiguriert werden.<\/em><\/p>\n<\/blockquote>\n

    \"LoginPageFooter\"<\/p>\n

    Im Standard wird beim Anmeldevorgang \u2013 vom Eingeben des Benutzernamens bis zum Abschluss der Multi-Faktor-Authentifizierung \u2013 kein Footer angezeigt. Wird der Footer aktiviert, k\u00f6nnen sowohl der Text als auch die URLs f\u00fcr \u201eTerms of Use\u201c und \u201ePrivacy and Cookies\u201c f\u00fcr individuelle Zwecke angepasst werden.<\/p>\n\n\n\n\n\n
    Footer aktivieren<\/th>\nURLs setzen<\/th>\n<\/tr>\n<\/thead>\n
    \"EnableFooter\"<\/td>\n\"Set<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
    \n

    Weitere Informationen finden Sie in der zugeh\u00f6rigen Microsoft Dokumentation<\/em><\/a><\/p>\n<\/blockquote>\n

    Auch hier bleibt es unwahrscheinlich, dass Benutzer h\u00e4ufig auf diesen Link klicken.<\/p>\n


    <\/p>\n

    \n

    Conditional Access<\/h2>\n

    Wenn die explizite Best\u00e4tigung der Nutzungsbedingungen erforderlich ist, gibt es auf Tenant-Ebene keine Alternative zu den ‚Terms of Use‘, die \u00fcber Conditional Access gesteuert werden.<\/p>\n

    Mit einer zugeh\u00f6rigen Conditional Access Policy, die f\u00fcr alle oder bestimmte Anwendungen gilt, m\u00fcssen Benutzer vor dem Zugriff best\u00e4tigen, dass sie die als PDF hochgeladenen Terms of Use gelesen und akzeptiert haben.<\/p>\n

    Folgende Optionen sind verf\u00fcgbar:<\/strong><\/p>\n