Entra Datenschutzinformationen: nutzbare Mandanten-URL

Was Entra Datenschutzinformationen bereitstellen

Entra Datenschutzinformationen werden über einen Link auf Organisationsebene zu dem Dokument bereitgestellt, das erläutert, wie Ihre Organisation mit den Daten von Menschen umgeht. Konfigurieren Sie ihn zusammen mit einem gepflegten Datenschutzkontakt, damit Beschäftigte und externe Gäste die für sie bestimmten Informationen finden. Das nützliche Ergebnis ist ein lesbares, relevantes Dokument mit einem erreichbaren Verantwortlichen und kein bloß ausgefülltes Feld, das niemand geprüft hat.

Microsofts Anleitung zum Einrichten der Datenschutzinformationen behandelt sowohl den globalen Datenschutzkontakt als auch die URL der Erklärung. Sie beschreibt deren Verwendung für interne Beschäftigte und externe Gäste, einschließlich des B2B-Einladungsablaufs. Wenn keines der beiden Felder angegeben ist, zeigt Learn eine Meldung unter Review Permissions, laut der die Organisation keine Links zur Überprüfung bereitgestellt hat. Nehmen Sie diese Darstellung zum Anlass, den tatsächlichen Ablauf für Gäste zu prüfen; leiten Sie daraus nicht ab, dass Einladungen blockiert werden.

Legen Sie vor einer Änderung am Mandanten fest, wer für das Dokument verantwortlich ist. Ein eingeladener Partner benötigt möglicherweise andere Informationen als die im internen Mitarbeiterhandbuch. Lassen Sie die zuständigen Datenschutz- und Rechtsverantwortlichen den Geltungsbereich und die Sprache des Dokuments bestätigen. Eine fehlende Mandanten-URL ist eine Beobachtung zur Konfiguration; sie belegt weder einen allgemein geltenden Rechtsverstoß noch bestimmt sie die Pflichten Ihrer Organisation.

Wie sich Datenschutzinformationen von der Annahme eines Dokuments unterscheiden

Die Graph-Ressource privacyProfile trennt contactEmail von statementUrl. Beide Eigenschaften sind im Schema optional. Die E-Mail-Adresse benennt den Kontakt für die Datenschutzerklärung, während die URL auf die Erklärung der Organisation verweist. Auch ein optionales API-Feld kann für Ihre betrieblichen Anforderungen nützlich sein; seine Optionalität entscheidet nicht darüber, ob Ihre Organisation die Informationen benötigt.

Learn definiert eine URL der Erklärung, die mit HTTP oder HTTPS beginnt. Wählen Sie bei einer neuen Bereitstellung ein stabiles HTTPS-Ziel und testen Sie es aus Sicht der Personen, die es lesen sollen. Ein Dokument, das erst nach der Anmeldung als Beschäftigter verfügbar ist, kann für einen neu eingeladenen externen Mitarbeiter ungeeignet sein. Gehen Sie nicht davon aus, dass ein Gast die Seite erreichen kann, nur weil ein Administrator sie öffnen kann.

Die Veröffentlichung dieses Links stellt Informationen bereit. Sie konfiguriert keine Conditional Access-Zugriffssteuerung, die eine Annahme verlangt, erzeugt keinen Annahmenachweis und belegt nicht, dass jemand den Text gelesen hat. Der Leitfaden zu Entra-Nutzungsbedingungen und ihrer Annahme mit Conditional Access behandelt diese gesonderte Anforderung: Eine genehmigte Vereinbarung und eine durchsetzende Richtlinie müssen verbunden werden, wenn die Annahme als Zugangsbedingung dienen soll.

Erkennung: Konfiguration, Ziel und Darstellung für Gäste prüfen

Das Organisationsprofil mit geeigneten Graph-Berechtigungen lesen

Bestätigen Sie zunächst den Mandanten, den Sie prüfen. Kontrollieren Sie im Entra admin center Entra ID > Overview > Properties, einschließlich des globalen Datenschutzkontakts und der URL der Datenschutzerklärung. Bewahren Sie den Beobachtungszeitpunkt und die exakten Werte auf, damit Sie das Portal mit einer unabhängigen API-Abfrage vergleichen können.

Microsofts Dokumentation zu List organization unterstützt GET /organization und den Abfrageparameter $select. Rufen Sie das Profil mit dieser Anfrage ab:

GET https://graph.microsoft.com/v1.0/organization?$select=privacyProfile
Authorization: Bearer {token}

Dies ist eine Anfragevorlage für Ihren autorisierten Client und keine für diesen Artikel in einem Kundenmandanten ausgeführte Abfrage. Prüfen Sie sowohl privacyProfile.contactEmail als auch privacyProfile.statementUrl in der zurückgegebenen Organisation. Bewahren Sie die Antwort und Erfassungsfehler zusammen mit dem Prüfprotokoll auf; ersetzen Sie bei der Untersuchung des Erfassungsverhaltens ein API-Ergebnis nicht durch einen Screenshot des Portals.

Die Dokumentation zum Lesen der Organisation führt Organization.Read.All für den Anwendungszugriff auf und unterstützt diese Berechtigung auch für delegierten Zugriff mit Geschäfts- oder Schulkonten. Sie weist ausdrücklich darauf hin, dass User.Read nur id, displayName und verifiedDomains zugänglich macht und andere Eigenschaften null zurückgeben. Verwenden Sie mindestens Organization.Read.All, um das Datenschutzprofil zu lesen, und prüfen Sie die unterstützten Rollenanforderungen für einen delegierten Client. Eine erfolgreiche Antwort mit unzureichender Sichtbarkeit der Eigenschaften darf nicht als Beleg für deren Fehlen dienen.

Das Ziel unabhängig von der Graph-Abfrage testen

Eine abgeschlossene Organisationsabfrage und ein verfügbares Datenschutzdokument sind unterschiedliche Beobachtungen. Dokumentieren Sie die exakt zurückgegebene URL und senden Sie anschließend eine unabhängige HTTP-Anfrage an dieses Ziel. Für eine autorisierte öffentliche Erklärung kann eine diagnostische Anfrage so aussehen:

curl --location --silent --show-error --output privacy-statement.html --write-out 'HTTP %{http_code}\nFinal URL %{url_effective}\n' 'https://example.org/privacy'

Ersetzen Sie das Beispiel durch das genehmigte Ziel. Prüfen Sie die endgültige Antwort und den gespeicherten Inhalt, statt allein den Statuscode zu akzeptieren. Eine erfolgreiche Antwort könnte eine allgemeine Startseite, ein Anmeldeformular oder ein sachfremdes Dokument enthalten. Kontrollieren Sie Weiterleitungen, die im Text genannte Organisation und ob die Seite den vorgesehenen Umgang mit Daten erläutert. Prüfen Sie sie außerdem im Browser, einschließlich Navigation und Lesbarkeit.

Testen Sie den Zugriff aus einem Mitarbeiterkontext und einem externen Kontext, der den Einladungsablauf abbildet. Falls das Ziel eine Anmeldung verlangt, klären Sie vor dem Beitritt des Gasts, ob diese Anforderung beabsichtigt und praktikabel ist. Dokumentieren Sie eine nicht verfügbare Seite, eine unerwartete Weiterleitung, ein veraltetes Dokument oder eine ungeeignete Sprache als Problem des Ziels, auch wenn das Mandantenfeld ausgefüllt ist. Bestätigen Sie gesondert, dass der angegebene Kontakt überwacht wird und einem Verantwortlichen zugewiesen ist.

Eine repräsentative B2B-Einladung durchspielen

Verwenden Sie eine genehmigte Testeinladung und beobachten Sie die tatsächliche Erfahrung des Gasts. Prüfen Sie die angezeigte Organisation, die angebotenen Datenschutzinformationen, das beim Öffnen des Links erreichte Ziel und den dargestellten Kontakt. Dokumentieren Sie den Gastkontext und den verwendeten Ablauf, da ein bestehender Gast, der zu einer Anwendung zurückkehrt, keine neue Einladung nachstellt.

Die Prüfung von Conditional Access für Gäste und externer Zusammenarbeit hilft, die vorgesehene externe Zielgruppe und ihre Zugriffseinstellungen einzuordnen. Bewahren Sie diese Zugriffsprüfung zusammen mit der Informationsprüfung auf. Ein funktionierender Datenschutzlink belegt nicht, dass Gasteinladungen, Richtlinienzuweisungen, Anwendungszugriff oder Lebenszykluseinstellungen Ihre Anforderungen erfüllen.

Abhilfe: eine nutzbare Mandanten-URL veröffentlichen und pflegen (Remediation)

1. Verantwortliche für Dokument und Kontakt benennen

Bestimmen Sie den für die Erklärung zuständigen Prüfer und das Team, das Datenschutzfragen beantwortet. Vereinbaren Sie die vorgesehenen Mitarbeiter- und Gastzielgruppen, Sprachen und den Veröffentlichungsort. Geben Sie dem Mandantenadministrator genehmigte Werte zur Eingabe. Lassen Sie den Administrator den Datenschutztext nicht selbst erfinden, nur um einen Auditbefund zu beseitigen.

Verwenden Sie eine Kontaktadresse mit einem ausdrücklichen Übergabeprozess bei Personalwechseln. Legen Sie fest, wer eingehende Nachrichten prüft und wer einen defekten Dokumentlink bearbeitet. Halten Sie fest, wo das genehmigte Dokument gepflegt wird und wie Änderungen seines Geltungsbereichs geprüft werden. Dies sind vor Ort zu treffende betriebliche Entscheidungen und keine aus der Mandanteneinstellung abgeleiteten rechtlichen Schlussfolgerungen.

2. Das Ziel vor der Konfiguration von Entra validieren

Veröffentlichen Sie die genehmigte Erklärung unter einer stabilen URL. Prüfen Sie, ob die vorgesehenen internen und externen Leser den relevanten Inhalt erreichen können und die unterstützten Sprachen von diesem Ziel aus zugänglich bleiben. Halten Sie die Seite verständlich, ohne dass ein Gast eine nur für Beschäftigte zugängliche Dokumentbibliothek durchsuchen muss.

Dokumentieren Sie den Zieltest getrennt von der Mandantenänderung. Falls Ihr Veröffentlichungssystem den Link weiterleitet, prüfen Sie das endgültige Ziel und stellen Sie sicher, dass künftige Weiterleitungen unter der Kontrolle des Dokumentverantwortlichen bleiben. Eine dauerhafte Organisations-URL lässt sich leichter pflegen als ein Link zu einer zeitlich begrenzten Kampagne, einem persönlichen Arbeitsbereich oder einem ablaufenden Freigabetoken.

3. Die Werte in Properties eingeben

Folgen Sie dem Properties-Verfahren von Learn: Melden Sie sich mindestens als Billing Administrator an, navigieren Sie zu Entra ID > Overview > Properties, geben Sie Global privacy contact und Privacy statement URL ein und wählen Sie wie dokumentiert Accept. Diese Portalaktion speichert die Informationen der Organisation; sie ist keine Annahme Ihres Dokuments durch einen Gast.

Falls Ihr genehmigter Änderungsprozess stattdessen Graph verwendet, dokumentiert Update organization PATCH /organization/{id} mit Organization.ReadWrite.All für delegierten Zugriff mit Geschäfts- oder Schulkonten sowie für Anwendungszugriff. Verwenden Sie die verifizierte Organisations-ID und prüfen Sie vor dem Schreiben die Anforderungen an delegierte Rollen. Senden Sie die vorgesehenen Profilwerte, ohne sachfremde Organisationseigenschaften zu ändern:

PATCH https://graph.microsoft.com/v1.0/organization/{organization-id}
Authorization: Bearer {token}
Content-Type: application/json

{
  "privacyProfile": {
    "contactEmail": "[email protected]",
    "statementUrl": "https://example.org/privacy"
  }
}

Das Beispiel ist ein dokumentiertes Anfragemuster mit Platzhalterwerten und keine ausgeführte Mandantenänderung. Halten Sie Schreibberechtigungen vom nur lesenden Prüfclient getrennt. Eine erfolgreiche Aktualisierungsantwort ist der Ausgangspunkt für die Verifikation und kein abschließender Nachweis dafür, dass Menschen das Dokument nutzen können.

4. Das Profil erneut lesen und den Gasttest wiederholen

Wiederholen Sie die Organisationsabfrage per GET mit ausgewählten Eigenschaften und vergleichen Sie beide Eigenschaften mit den genehmigten Werten. Prüfen Sie das Ziel erneut unabhängig und wiederholen Sie anschließend die repräsentative Einladungsprüfung. Bewahren Sie Fehler ebenso wie erfolgreiche Beobachtungen auf. Falls das Profil abweicht, untersuchen Sie den Mandantenkontext und das Aktualisierungsergebnis, bevor Sie erneut schreiben.

Wenn die Informationen konfiguriert sind, aber der geprüfte Gastablauf sie nicht wie erwartet zeigt, bewahren Sie die API-Nachweise und die beobachtete Darstellung als getrennte Fakten auf. Untersuchen Sie diesen Ablauf, statt wiederholt eine korrekte URL zu ersetzen. Fügen Sie keine Anforderung zu Nutzungsbedingungen als improvisierte Lösung für fehlende Datenschutzinformationen hinzu; eine Annahme benötigt einen eigenen genehmigten Zweck und Geltungsbereich.

5. Sprachen, Links und Verantwortlichkeiten pflegen

Prüfen Sie die Erklärung erneut, wenn sich Datenverarbeitung, Dokumenthosting, Gastzielgruppen oder die Verantwortung für den Kontakt ändern. Aktualisieren Sie Übersetzungen zusammen mit dem genehmigten Quelldokument. Wiederholen Sie nach einer Hostingmigration die HTTP- und Browserprüfungen, auch wenn die Mandanten-URL unverändert bleibt. Verifizieren Sie nach einer Kontaktübergabe, dass die Adresse weiterhin das zuständige Team erreicht.

Bewahren Sie genehmigte Werte, Graph-Rückleseergebnisse, Zielprüfungen, Gastbeobachtungen und Entscheidungen der Verantwortlichen zusammen auf. So können Sie Konfigurationsabweichungen von einer Veröffentlichungsstörung oder einer Änderung des Einladungsablaufs unterscheiden. Definieren Sie einen für Ihre Organisation geeigneten Prüfturnus, statt das erste erfolgreiche Speichern als dauerhaften Nachweis zu betrachten.

Wie EtcSec dies erkennt

Der etc-collector-Detektor AZ_NO_PRIVACY_STATEMENT liest AzurePrivacyStatementProbed und AzurePrivacyStatementURL. Seine Detect()-Implementierung hat drei Zweige:

Count 1 ist die Anzahl des Befunds und keine Anzahl betroffener Gäste. Nicht abgefragt bedeutet nicht fehlend, und der Info-Zweig ist kein Compliance-Urteil. Beheben Sie Erfassungsfehler, bevor Sie eine Schlussfolgerung zur Konfiguration ziehen.

Der Provider sendet GET /organization?$select=privacyProfile, liest statementUrl der ersten Organisation und gibt eine leere Zeichenfolge ohne Fehler zurück, wenn die Organisationsliste leer ist oder das Profil fehlt. Anfrage- und Dekodierungsfehler werden gesondert zurückgegeben. Ein unerwartet leeres Inventar verdient deshalb eine Untersuchung zusammen mit Berechtigungen und Mandantenkontext.

Weder der Provider noch dieser Detektor entfernt Leerzeichen aus der Zeichenfolge: Whitespace ist nicht leer und besteht den Vergleich. Keiner von beiden ruft die URL der Erklärung auf, verifiziert den Kontakt oder prüft Dokumentinhalt und Sprachen. Der Provider erfasst contactEmail für diese Prüfung nicht. Eine nicht leere URL kann diesen Befund beseitigen, während das Ziel nicht verfügbar oder ungeeignet ist. Ergänzen Sie dieses eng begrenzte Konfigurationsergebnis durch die oben beschriebenen unabhängigen Ziel- und Einladungstests und bewahren Sie die Eignungsentscheidung des Dokumentverantwortlichen auf.