Sicherheit und Berechtigungen

Diese Seite erklärt das Sicherheitsmodell hinter Icon Map for Fabric: wie Identität, Berechtigungen und Datenspeicherung funktionieren. Sie richtet sich an alle, die eine Sicherheitsprüfung durchführen.

Sie suchen die schrittweise Einrichtung durch Administratoren (Mandanteneinstellungen, Administratoreinwilligung, Berechtigungen für Dienstprinzipale)? Siehe den Abschnitt Onboarding und Einrichtung.

Der Leitgedanke ist, dass Icon Map mit Ihren Daten, in Ihrem Mandanten arbeitet: Es liest Ihre Daten dort, wo sie liegen, handelt unter der Identität des angemeldeten Benutzers und speichert alles, was es schreibt, in Ihrem eigenen OneLake.

Identitätsmodell

Erstellen und Lesen einer Karte (in Fabric). Der Icon Map-Editor und -Viewer laufen in der Fabric-Umgebung und handeln als angemeldeter Benutzer mit dessen Microsoft Entra-Identität. OneLake-Dateien (etwa Kachel- und Bilddateien) werden mit einer kurzlebigen, benutzerdelegierten SAS gelesen, die im Namen des Benutzers bezogen wird, sodass ein Benutzer nur Daten sieht, auf die er bereits zugreifen darf. Power BI-Semantikmodell-Quellen werden über das Modell abgefragt, das die Measures, Beziehungen und Sicherheit auf Zeilenebene des Modells durchsetzt.

Da Icon Map die Fabric-Berechtigungen übernimmt, wird für das normale Erstellen und Anzeigen kein separates Zugriffssystem eingeführt: Ihre vorhandenen Arbeitsbereichsrollen und OneLake-Berechtigungen bestimmen, wer was sehen kann.

Berechtigungen für das Erstellen

Um Karten zu erstellen, benötigt ein Benutzer:

  • Zugriff auf den Arbeitsbereich, der das Icon Map-Element enthält (Mitwirkender oder höher, um Elemente zu erstellen und zu bearbeiten; Betrachter, um sie im Anzeigemodus zu öffnen).
  • Lesezugriff auf die Daten, mit denen er sich verbindet (Lakehouse, Warehouse/SQL, Semantikmodell, Eventhouse/KQL-Datenbank oder Datei), unter seiner eigenen Identität.
  • Für einen Organisationskatalog OneLake-Berechtigungen für den Repository-Ordner des Katalogs, die bestimmen, wer seine Ebenen nutzen kann.

Für das Erstellen oder Lesen einer Karte sind keine erhöhten Rechte oder Dienstanmeldeinformationen erforderlich. Damit das Erstellen ohne wiederholte Einwilligungsaufforderungen funktioniert, erteilt ein Administrator den beiden Icon Map-Workload-Anwendungen (Frontend und Backend) die mandantenweite Administratoreinwilligung. Sie genehmigt die delegierten Berechtigungen vorab, gewährt aber keinen eigenständigen Zugriff auf Ihre Daten.

Einbetten außerhalb von Fabric: zwei Modi

Eine Karte kann auf zwei Arten außerhalb von Fabric angezeigt werden, und ihre Sicherheitsmodelle unterscheiden sich.

Benutzer besitzt die Daten (Einbetten in Ihre eigene Anwendung). Jeder Betrachter meldet sich mit seiner eigenen Microsoft Entra-Identität an, und die Karte liest das Element, seine OneLake-Dateien und seine Live-Abfragen als dieser Betrachter. Es gibt keinen Veröffentlichungsschritt, keine Kopie Ihrer Daten und überhaupt keinen Dienstprinzipal. Da die Lesevorgänge die des Betrachters sind, gilt Ihre native Fabric- und Power BI-Sicherheit auf Zeilenebene automatisch pro Betrachter, und ein Betrachter kann nie etwas sehen, was seine Fabric-Berechtigungen nicht ohnehin erlauben. Verwenden Sie diesen Modus für interne Portale und Fachanwendungen. Siehe Einbetten für Ihre Organisation.

Veröffentlichte Karten. Für Zielgruppen ganz ohne Fabric-Zugriff veröffentlicht ein Autor eine Karte, und der öffentliche eingebettete Viewer stellt sie bereit. Diesen Modus beschreibt der Rest dieses Abschnitts.

Veröffentlichung und die Identität des Viewers

Das Veröffentlichen einer Karte zur Anzeige außerhalb von Fabric ist der einzige Fall, in dem eine Identität beteiligt ist, die kein Benutzer ist: Der öffentliche eingebettete Viewer liest die eingefrorenen, veröffentlichten Dateien aus Ihrem OneLake mit einem eigenen, schreibgeschützten Einbettungsdienstprinzipal. Er ist eine von der Workload getrennte Microsoft Entra-Anwendung, authentifiziert sich mit einem Zertifikat aus Azure Key Vault und fordert keine API-Berechtigungen an. Sein einziger Zugriff ist eine schreibgeschützte OneLake-Datenzugriffsrolle für das Lakehouse, das Ihre veröffentlichten Karten enthält, automatisch beim Veröffentlichen unter der eigenen Identität des Autors erteilt, niemals die Rolle Mitwirkender im Arbeitsbereich. Unternehmen können für diesen Lesezugriff stattdessen ihren eigenen Dienstprinzipal bereitstellen. Die Einrichtung wird unter Veröffentlichung einrichten beschrieben. Wichtige Sicherheitseigenschaften:

  • Eine Veröffentlichung gewährt nicht mehr, als ihr Autor hat. Beim Veröffentlichen prüft der Dienst unter der eigenen Identität des Autors, ob der Autor jede Datenquelle, Datei und jedes Element erreichen kann, auf die die Karte verweist, und lehnt die Veröffentlichung andernfalls ab. Mit dem Veröffentlichen lassen sich daher keine Daten offenlegen, die der Autor nicht ohnehin öffnen könnte.
  • Manipulationssichere veröffentlichte Karten. Veröffentlichte Anweisungen sind kryptografisch signiert, und die Signatur wird bei jedem Lesen geprüft; eine nach dem Veröffentlichen veränderte Karte wird abgelehnt statt ausgeliefert.
  • Momentaufnahme oder live. Eine Veröffentlichung als Momentaufnahme friert die Daten zum Zeitpunkt der Veröffentlichung ein; eine Live-Veröffentlichung führt bei jedem Laden die fixierten Abfragen der Karte aus, mit serverseitig validierten Parametern und einem täglichen Abfragebudget (standardmäßig 500 neue Abfragen pro Tag, 50.000 Zeilen pro Abfrage), das Sie senken können.
  • Sicherheit auf Zeilenebene für Betrachter. In veröffentlichten Karten ist RLS pro Betrachter nur mit signierten Einbettungstoken verfügbar, bei denen Token-Claims auf deklarierte, serverseitig validierte Filterparameter abgebildet werden. Anonyme veröffentlichte Links können keine RLS pro Betrachter anwenden: Veröffentlichen Sie nur Daten, die Sie mit allen teilen möchten, die den Link haben. Wenn Ihre vorhandene Fabric-RLS pro Betrachter gelten soll, verwenden Sie stattdessen den oben beschriebenen Modus Benutzer besitzt die Daten, in dem sie nativ gilt, weil jeder Betrachter als er selbst liest.
  • Zulässige Ursprünge. Tokengeschützte Einbettungen müssen angeben, welche Websites sie hosten dürfen (Platzhalter-Subdomänen werden unterstützt); das wird im Browser über Content-Security-Policy durchgesetzt. Einbettungstoken gelten höchstens vier Stunden.
  • Keine Anmeldeinformationen für Betrachter. Schlüssel für schlüsselgeschützte Kartendienste werden beim Veröffentlichen aus den veröffentlichten Inhalten entfernt, in Ihrem OneLake aufbewahrt und serverseitig angehängt, wenn Kacheln weitergeleitet werden; die für den Browser bestimmte Form einer Karte enthält keine Abfragetexte, Tabellen- oder Dateinamen, Spaltenlisten oder Verbindungsdetails.
  • Widerruf. Jeder veröffentlichte Link kann jederzeit in der Veröffentlichungsverwaltung widerrufen werden; der Widerruf wird innerhalb von 30 Sekunden wirksam.
  • Organisationsweiter Ausschalter. Das eingebettete Veröffentlichen kann für Ihren Mandanten oder für einzelne Arbeitsbereiche deaktiviert werden: Die Aktion zum Veröffentlichen wird aus dem Editor entfernt, und der Einbettungsdienst liefert die betroffenen Karten nicht mehr aus, auch solche, die vor der Änderung veröffentlicht wurden.
  • Schreibgeschützte, eingeschränkte Identität. Der Einbettungsdienstprinzipal hat keinen Schreibzugriff auf Ihren Arbeitsbereich, nur eine schreibgeschützte Datenzugriffsrolle für das Veröffentlichungs-Lakehouse. Große Raster-Tilesets werden direkt aus ihrem eigenen Lakehouse gelesen (damit sie aktuell bleiben), abgedeckt durch dieselbe schreibgeschützte Rolle.
  • Was wo gespeichert wird. Veröffentlichte Dateien liegen in Ihrem OneLake, in einem Lakehouse (IconMap_Published) in Ihrem Arbeitsbereich, unter Files/_published/<publish-id>/ (ein signiertes manifest.json mit Stil und Konfiguration ohne Geheimnisse oder Verbindungszeichenfolgen, eine Momentaufnahme data.json und Ressourcen). Icon Map kopiert oder speichert Ihre Kartendaten nicht auf eigenen Servern zwischen.

Anmeldeinformationen für Quellen

Bei Quellen, die Anmeldeinformationen benötigen (zum Beispiel ein authentifizierter WMS-Dienst oder ein GTFS-Feed), werden die gespeicherten Anmeldeinformationen im eigenen OneLake-Ordner des Kartenelements, geschützt durch Arbeitsbereichsrollen, abgelegt und serverseitig angehängt, wenn die Quelle abgerufen wird. Sie werden nicht in der Konfiguration der Ebene gespeichert.

Berechtigungen für das Rückschreiben

Das Rückschreiben, mit dem Betrachter die Daten hinter einer Karte ergänzen oder bearbeiten können, schreibt in Dateien in Ihrem OneLake (den Anmerkungsspeicher der Karte oder die GeoJSON-/CSV-Datei einer Ebene), und zwar als angemeldeter Benutzer. Es setzt die Fabric-Schreibberechtigung des Benutzers für das Element voraus und steht daher Benutzern mit Schreibzugriff auch im Anzeigemodus zur Verfügung. In dieser Vorschau können anonyme Betrachter veröffentlichter bzw. eingebetteter Karten nicht zurückschreiben.

Vertraulichkeitsbezeichnungen

Icon Map-Elemente sind gewöhnliche Fabric-Elemente: Sie können im Dialogfeld zum Erstellen des Elements, in seiner Kopfzeile oder in seinen Einstellungen eine Microsoft Purview-Vertraulichkeitsbezeichnung anwenden, und jede an diese Bezeichnung gebundene Purview-Schutzrichtlinie steuert, wer das Element öffnen kann, genau wie bei nativen Elementen.

Icon Map beachtet auch die Bezeichnungen der Daten, die eine Karte liest. Wenn eine Karte ein Lakehouse, Warehouse, Eventhouse, Semantikmodell oder eine OneLake-Datei mit einer Vertraulichkeitsbezeichnung verwendet, prüft die Workload diese Bezeichnung als angemeldeter Benutzer, bevor Daten das Element verlassen. Die Prüfung umfasst Downloads (CSV, GeoJSON, GeoParquet, Tourvideos, Grundrisse), Kopien in die Zwischenablage, in einem Lakehouse gespeicherte Dateien, das Veröffentlichen zur Anzeige außerhalb von Fabric und Screenshots, die einem Supportbericht angehängt werden.

  • Eine Bezeichnung ohne Schutzeinstellungen erzeugt eine Warnung, die die Bezeichnung nennt. Der Benutzer kann fortfahren; die exportierte Datei trägt die Bezeichnung nicht. Das entspricht dem Umgang von Fabric mit Exporten aus eigenen Elementen, die nicht zu Power BI gehören.
  • Eine Bezeichnung mit Schutzeinstellungen (Verschlüsselung mit Nutzungsrechten) wird durchgesetzt. Ein Benutzer ohne das Recht Exportieren der Bezeichnung kann die Daten nicht herunterladen oder speichern, ohne das Recht Extrahieren kann er sie nicht kopieren. Daten unter einer geschützten Bezeichnung können überhaupt nicht zur Anzeige außerhalb von Fabric veröffentlicht werden.
  • Anonyme Links sind für eine Karte, die bezeichnete Daten liest, nie verfügbar, unabhängig von den Einstellungen der Bezeichnung.
  • Live veröffentlichte Karten liefern eine Datenquelle, deren Bezeichnung sich nach dem Veröffentlichen ändert, nicht mehr aus, bis der Autor die Karte erneut veröffentlicht.

Zwei organisationsweite Einstellungen prägen dieses Verhalten. export.labelGate steht standardmäßig auf enforce; warn macht aus jeder Sperre eine Warnung, für Organisationen, die nur das Verhalten von Fabric wünschen, und off deaktiviert die Prüfung. export.blockedLabelIds listet Bezeichnungen ohne Schutzeinstellungen auf, die Exporte dennoch sperren sollen. Beide werden auf Anfrage über support@icon-map.com angewendet und können auf einen Mandanten, eine Kapazität oder einen Arbeitsbereich beschränkt werden.

Die Prüfung benötigt die Microsoft Graph-Berechtigung SensitivityLabel.Read der Backend-Anwendung, für die nur ein Administrator einwilligen kann (siehe Administratoreinwilligung). Solange diese Einwilligung fehlt, werden Exporte bezeichneter Daten abgelehnt statt erlaubt. Die Bezeichnungs-APIs von Purview sind nur in der globalen Cloud verfügbar; in anderen Clouds kann die Workload erkennen, dass Daten bezeichnet sind, aber nicht, was die Bezeichnung durchsetzt, und warnt daher stattdessen. Kein Exportformat, das Icon Map erzeugt, kann eine Purview-Bezeichnung tragen, daher werden exportierten Dateien nie Bezeichnungen zugewiesen.

Nächste Schritte