Latest / M365.FM – Microsoft 365, Copilot & KI Podcast auf Deutsch / Row-Level Security in Power BI und Fabric: wie DAX, Rollen und Gruppen wirklich entscheiden, wer was sieht (KI-Synchronfassung)

Transcript

Row-Level Security in Power BI und Fabric: wie DAX, Rollen und Gruppen wirklich entscheiden, wer was sieht (KI-Synchronfassung) · M365.FM – Microsoft 365, Copilot & KI Podcast auf Deutsch

• 0:00
  Bereit für 10 Tage Microsoft 365, Co-Pilot, KI, Azure und die Menschen, die die Zukunft der Arbeit gestalten?
• 0:07
  Ah, diesen Januar ist die M365-Coin zurück und zwar noch größer, größer.
• 0:12
  Seien Sie dabei bei Live-Sessions, Demos aus der Praxis und erfahren Sie praktisches Wissen von MVPs und Branchenexperten aus aller Welt.
• 0:18
  Keine generischen Folien, keine endlosen Schlagworte.
• 0:21
  Wir stellen uns den echten Herausforderungen.
• 0:23
  Co-Pilot Studio, KI Agents, Fabric, Sicherheit, Governance und Automatisierung.
• 0:28
  Ganz gleich, ob Sie IT-Experte, Entwickler oder Führungskraft sind, es gibt für Sie konzipierte Sessions.
• 0:35
  An 10 vollen Tagen können Sie verschiedene Technologien kennenlernen und sich mit einer globalen Community vernetzen.
• 0:40
  Sehen Sie sich die Live-Übertragung an und nehmen Sie praktische Einblicke mit nach Hause in Ihr Unternehmen.
• 0:45
  Januar 2027, 10 Tage, eine Microsoft-Community.
• 0:49
  Die Registrierung ist ab sofort möglich.
• 0:51
  Gehen Sie noch heute zu Ihrem Standort.
• 0:52
  Das ist M225560-con.net.
• 1:00
  Melden Sie sich jetzt unter M325560-con.net an und wir sehen uns im Januar live.
• 1:05
  Haben Sie sich jemals gefragt, wer Ihre Daten im Power BI eigentlich sehen kann?
• 1:07
  Boiler-Alarm, es ist nicht so privat, wie Sie vielleicht denken, wenn Sie die Sicherheit auf Zeilenebene nicht beherrschen.
• 1:12
  In dieser Folge aktivieren wir nicht nur das Kontrollkästchen für die Sicherheit auf Zeilenebene,
• 1:16
  sondern analysieren die beweglichen Teile von Rollendefinitionen bis hin zu DAX ausdrücken, die stillschweigend entscheiden, wer was sieht.
• 1:21
  Die meisten Leute hören beim Einrichten auf, aber wir zeigen Ihnen, wie jede Entscheidung miteinander verknüpft ist,
• 1:25
  sodass Ihre Daten nicht nur gesperrt, sondern auf Sicherheit ausgelegt sind.
• 1:30
  Warum Sicherheit auf Zeilenebene ein System und kein Kontrollkästchen ist.
• 1:33
  Wenn Sie es gewohnt sind, eine vertrauliche Tabelle durch ein Kennwort zu schützen,
• 1:36
  wissen Sie bereits, dass zwischen Ihren Absichten und dem, was Ihre Daten tatsächlich schützt, eine Lücke klafft.
• 1:41
  Klafft.
• 1:42
  Power BI mit Sicherheit auf Zeilenebene kann sich genauso anfühlen.
• 1:46
  Sie aktivieren den RLS-Schalter, weisen ein paar Rollen zu und denken, dass alles abgesichert ist.
• 1:50
  Aber die Realität sieht anders aus.
• 1:52
  Vertrauliche Daten finden einen Weg nach draußen, wenn diese Verbindungen zwischen Rollenfiltern und Benutzern nicht sorgfältig abgebildet werden.
• 1:58
  Es wird selten über die Situation gesprochen, in denen jemand aus dem Vertriebsteam ein Dashboard öffnete
• 2:01
  und am Ende einen klaren Einblick in Zahlen erhielt, die er nie hätte sehen dürfen.
• 2:06
  Aber es kommt vor und beginnt fast immer mit der Annahme, dass RLS nur ein weiteres Kästchen ist,
• 2:10
  das während der Einrichtung abgehakt werden muss.
• 2:12
  Versetzen wir uns in die Lage von jemandem, dem Zugriff auf ein Dashboard gewährt wird,
• 2:15
  weil er denkt, er würde damit einen Kollegen mehr Befugnis erteilen.
• 2:17
  Klingt harmlos, oder?
• 2:18
  Aber in zu vielen Unternehmen bedeutet der Zugriff auf ein Dashboard den Zugriff auf alles hinter den Kulissen.
• 2:24
  Ich habe Umgebungen erlebt, in denen eine einzige globale Managerrolle Junior-Benutzern versehentlich
• 2:27
  den Zugriff auf vertrauliche HR-Daten erlaubte,
• 2:30
  nur weil die Benennung nicht der Realität entsprach.
• 2:33
  Auch das ist kein Einzelfall.
• 2:34
  Es ist eher die Regel als die Ausnahme, insbesondere wenn ein Unternehmen wächst
• 2:37
  und sich die Dashboards vervielfachen.
• 2:40
  Alle wollen schnell vorankommen, aber wenn man ohne Struktur vorgeht,
• 2:42
  entstehen kleine Lücken, die sich bei einem Audit zu klaffenden Lücken entwickeln können.
• 2:47
  Auf dem Papier könnte RS nicht einfacher klingen.
• 2:50
  Erstellen Sie eine Rolle, nennen Sie sie vielleicht Vertrieb,
• 2:52
  fügen Sie einen Filter wie Region gleich USA hinzu und ordnen Sie Ihr Benutzer zu.
• 2:55
  Hinter jedem Dropdown und Kontrollkästchen im Power BI verbirgt sich jedoch ein System,
• 2:59
  das Entscheidungen darüber trifft, welche Daten wohin übertragen werden.
• 3:02
  Wenn Sie eine Beziehung übersehen oder ein Filter einer neuen Datenquelle nicht erfasst,
• 3:06
  handelt es sich nicht nur um einen technischen Fehler.
• 3:08
  Es handelt sich um einen Sicherheitsvorfall, den nur darauf wartet, was passiert.
• 3:11
  Sie werden es erst erfahren, wenn jemand über Daten stolpert, die er nicht sehen soll.
• 3:14
  Und manchmal nicht einmal dann.
• 3:16
  Deshalb sind diese kleinen Fehler so schwer zu erkennen.
• 3:19
  Sie werden nicht durch Warnsignale benachrichtigt
• 3:20
  und Standardprüfungen gehen oft nicht tief genug, um sie zu bemerken.
• 3:24
  Was übersehen wird, ist, wie eng die RLS-Komponenten tatsächlich miteinander verbunden sind.
• 3:29
  Die meisten Tutorials führen Sie schnell durch die Einrichtung
• 3:31
  und führen Sie durch die Grundlagen der Rollenerstellung und Filterung.
• 3:34
  Sie zeigen, wie Benutzer zugeordnet und ein Vorschaufeld aktiviert wird.
• 3:37
  Aber so gut wie niemand geht darauf ein, zu untersuchen,
• 3:39
  wie sich ein Filter in der Vertriebstabelle beispielsweise auf eine Tabelle mit zugehörigen Gebieten auswirkt.
• 3:44
  Jede Logik in RLS wirkt sich auf die anderen aus.
• 3:46
  Zuweisungen, DAX-Ausdrücke und sogar die Benennung der Rollen selbst.
• 3:51
  Betrachten Sie diese Entscheidungen als isolierte Schritte
• 3:53
  und vertrauen Sie darauf, dass das System keine losen Enden aufweist.
• 3:56
  Doch ein vergessener Filter und plötzlich ist Ihre sorgfältig eingerichtete Rolle wie ein Sieb.
• 4:01
  Dies ist einer jener Bereiche, in denen die richtige Analogie keine verschlossene Tür ist.
• 4:06
  Es ist ein Geflecht aus Fäden.
• 4:08
  Sie ändern einen Teil und plötzlich kann sich das Ganze verschieben.
• 4:12
  Übersehen Sie einen Faden, haben Sie ein Leck erzeugt,
• 4:13
  das nicht einmal offensichtlich ist, bis es ausgenutzt wird.
• 4:16
  Tatsächliche Vorfälle zeigen, wie sich dies auswirkt.
• 4:18
  Insider-Geschichten von Analyse-Teams berichten von dem Moment,
• 4:21
  als der europäische Vertriebsleiter zufällig auf Daten aus der nordamerikanischen Pipeline stieß.
• 4:25
  Das war kein Einbruch, sondern ein falsch angewendeter Filter,
• 4:28
  eine unbeabsichtigte Standardeinstellung oder eine Rolle, die niemand noch einmal überprüft hatte.
• 4:32
  Es gibt aber nicht nur Horrorgeschichten aus der realen Welt.
• 4:35
  Microsofts eigene Sicherheitslückenberichte nennen falsch konfigurierte Sicherheit auf Zeilenebene
• 4:39
  als einen der Hauptgründe für die peinliche Offenlegung öffentlicher Daten in großen Unternehmen.
• 4:44
  Auf jede Schlagzeile über eine große Sicherheitsverletzung kommen Dutzende,
• 4:47
  die nicht gemeldet werden, aber hinter den Kulissen dauerhafte Folgen haben.
• 4:50
  Was diese Probleme gemeinsam haben, ist das trügerische Sicherheitsgefühl,
• 4:54
  das RLS vermittelt, wenn man es wie einen einfachen Punkt behandelt,
• 4:57
  den man von einer To-Do-Liste streichen kann.
• 4:59
  Studien von Microsofts Sicherheitsteams unterstreichen, dass das Erstellen von Filterebenen,
• 5:03
  das Stapeln von Filtern über Tabellen hinweg, das Anwenden zusätzlicher DAX-Ausdrücke
• 5:06
  oder die Verwendung von Kombinationen aus statischer und dynamischer Logik
• 5:09
  sowohl den Schutz als auch die Komplexität erhöht.
• 5:11
  Sowohl den Schutz als auch die Komplexität erhöht.
• 5:13
  Jede hinzugefügte Ebene erhöht nicht nur die Sicherheit,
• 5:15
  sondern vervielfacht auch die Anzahl der Punkte, an denen ein Konfigurationsfehler auftreten kann.
• 5:21
  Anstelle eines einfachen Wächters an der Tür haben Sie ein komplexes Netz,
• 5:24
  in dem ein übersehener Knotenpunkt monatelange Sicherheitsplanung zunichte machen kann.
• 5:29
  Lassen Sie uns auch die praktischen Realitäten nicht außer Acht lassen.
• 5:32
  Ein System mag im Test einwandfrei funktionieren, aber wenn man es in die Produktion mit echten Benutzern,
• 5:37
  echten Abteilungen und sich ständig ändernden Teams überführt,
• 5:39
  kommt es zu Situationen, in denen jemand, der im letzten Quartal das Team gewechselt hat,
• 5:43
  immer noch Zugriff auf die vierteljährlichen Finanzzahlen hat.
• 5:47
  Namen und Zuweisungen, die anfangs noch Sinn machten, werden zu mysteriösen Altlasten.
• 5:53
  Niemand möchte etwas anfassen, nur weil er weiß, dass es noch verwendet wird.
• 5:56
  Wenn Sie RLS nur beim Setup aktivieren und dann fortfahren, schützen Sie Ihre Daten nicht.
• 6:00
  Sie hoffen, dass niemand aus Neugier oder Versehen an die falsche Tür klopft.
• 6:06
  All dies führt zu einer zentralen Wahrheit.
• 6:07
  Sicherheit auf Zeilenebene ist lebendig.
• 6:10
  Sie verändert sich mit Ihrem Unternehmen.
• 6:11
  Jede Rolle, die Sie erstellen, jeder DAX-Filter, den Sie anwenden,
• 6:14
  jede Gruppe, die Sie zuweisen, das sind keine kleinen Entscheidungen.
• 6:17
  Sie fließen zusammen und bilden ein lebendiges, atmendes Schutzsystem.
• 6:20
  Wenn Sie ignoriert werden, entsteht ein Netz voller Löcher.
• 6:22
  Bevor Sie also zum nächsten Dashboard wechseln oder ein Modell übergeben,
• 6:24
  halten Sie inne und fragen Sie sich,
• 6:26
  verwalte ich tatsächlich ein Sicherheitssystem oder hoffe ich nur, dass die Umstellung ausreicht?
• 6:30
  Der nächste Teil dieser Geschichte beginnt mit dem Kernstück des Ganzen,
• 6:34
  der Filterlogik selbst und wie sie jede andere Entscheidung, die Sie treffen, steuert.
• 6:40
  Aufbau einer sicheren Grundlage, Datenfilterung und Rollendesign.
• 6:44
  Wenn Sie jemals Sicherheit auf Zeilenebene eingerichtet haben und dachten,
• 6:46
  es ginge nur darum, bestimmte Zahlen zu verbergen, sind Sie nicht allein.
• 6:49
  Der Hauptgrund für die Unübersichtlichkeit von RLS ist ein einfaches Missverständnis.
• 6:52
  Dabei geht es nicht nur um das Sichtbare,
• 6:54
  sondern um die Gestaltung der gesamten Benutzererfahrung.
• 6:56
  Ein kurzer Fehltritt und plötzlich wird eine vertrauliche Bonustabelle
• 7:01
  oder ein vertrauliches Gehalt einer Führungskraft
• 7:03
  in das Dashboard eines anderen Unternehmens übernommen.
• 7:06
  Allerdings entdecken Nutzer diese Lacks erst, wenn bereits Berichte im Umlauf sind
• 7:09
  und zu diesem Zeitpunkt kann das Zurückverfolgen schwierig werden.
• 7:12
  Das Unangenehme daran ist, dass diese Aufschlüsselung selten dramatisch ist.
• 7:15
  Meistens handelt es sich um Sonderfälle,
• 7:17
  ein US-Manager meldet sich an und sieht nur das, was er sehen soll,
• 7:19
  aber ein Londoner Kollege öffnet dasselbe Modell
• 7:21
  und findet, ohne dass es jemand bemerkt, die Zahl aus New York direkt dort.
• 7:24
  Stellen Sie sich vor, Sie erstellen ein Fabrik-Modell für den weltweiten Vertrieb.
• 7:29
  Sie möchten, dass Manager in verschiedenen Regionen nur Ihre eigenen Daten sehen.
• 7:33
  Der Reflex besteht darin, ein Filter einzufügen, etwas Einfaches.
• 7:36
  Region gleich USA oder Land gleich Großbritannien.
• 7:39
  Aber hier ist der Haken in der Sache.
• 7:41
  Wie Sie diesen Filter schreiben und wie Sie ihn in Ihr Modell einbinden,
• 7:43
  entscheidet darüber, ob Ihr System tatsächlich zusammenhält oder auseinanderfällt,
• 7:46
  sobald die Dinge komplexer werden, sobald die Dinge komplexer werden.
• 7:49
  Viele Leute gehen davon aus, dass es sich um einen kinderleichten,
• 7:51
  einzelligen DAX-Filter handelt und können dann einfach weitermachen.
• 7:53
  Allerdings verhalten sich nicht alle DAX-Funktionen gleich.
• 7:56
  Tatsächlich führen diese Nuancen später häufig zu Problemen,
• 7:59
  insbesondere beim Wechsel von Power BI Desktop zu Fabric,
• 8:01
  wo die Eigenheiten der Cloud-Ebene zum Tragen kommen.
• 8:04
  RBLS wird ziemlich schnell unübersichtlich, wenn man sich mit den Details befasst.
• 8:08
  Oft verlassen sich Benutzer auf Funktionen wie Benutzername oder Benutzerprinzipalname
• 8:11
  und vermuten, dass diese dasselbe bewirken
• 8:13
  oder Sie übernehmen einfach die Funktion, die in einem Blogbeitrag verwendet wird.
• 8:15
  Wenn Sie jedoch den Benutzernamen, der Ihren Windows-Namen in Desktop abruft,
• 8:19
  durch den Benutzerprinzipalnamen ersetzen, der Ihre E-Mail-Adresse in Fabric abruft,
• 8:23
  gerät Ihre Filterlogik plötzlich ins Wanken.
• 8:26
  Wenn bei Ihnen schon einmal ein Test in Desktop funktioniert hat,
• 8:28
  der aber nach der Veröffentlichung in Fabric zusammenbricht, ist dies wahrscheinlich der Grund.
• 8:31
  Und wenn man die falsche Wahl trifft, entstehen auf diese Weise Lücken,
• 8:33
  die den falschen Personen unbemerkt Zugriff auf Daten gewähren,
• 8:36
  mit denen Sie niemals etwas zu tun haben sollten.
• 8:37
  Gehen wir es genauer an.
• 8:38
  Für grundlegende Szenarien funktioniert eine hart kodierte Prüfung.
• 8:43
  Region gleich USA bedeutet, dass nur Zeilen mit der Region USA angezeigt werden,
• 8:48
  dass statische RLS-Funktionierung steht.
• 8:50
  Sie ist schnell, einfach und erfüllt ihren Zweck für feste Unterteilung wie Zahn.
• 8:53
  Wie ein Bericht, der nur für US-Manager bestimmt ist.
• 8:55
  Sobald jedoch jemand dynamisch Sicherheit anfordert, ändern sich die Dinge.
• 8:58
  Möglicherweise müssen Sie den Zugriff nicht nur auf Grundlage des Berichtsbetrachters festlegen,
• 9:01
  sondern auch anhand von Beziehungen in einer anderen Tabelle.
• 9:03
  Wie einer Benutzerzugriffstabelle, in der aufgeführt ist, welche Benutzer welche Regionen sehen.
• 9:07
  Ihr RLS-Filter ist nun nicht nur ein fester Wert.
• 9:10
  Es handelt sich um eine Formel, die nachschlägt, auf welche Regionen jede Person in Echtzeit zugreifen soll.
• 9:15
  Hier kann DAX Ihnen ein Stolperstein sein, wenn Sie nicht aufpassen.
• 9:17
  Sie könnten nach etwas wie dem Benutzerprinzipalnamen suchen
• 9:19
  und dann versuchen, es mit Ihrer Zugriffstabelle zu verknüpfen.
• 9:23
  Wenn Ihr DAX jedoch auf berechneten Spalten basiert oder Logik einbindet,
• 9:26
  die beim Anzeigen nicht auf den Benutzerkontext reagiert,
• 9:28
  können Sie den dynamischen Filter versehentlich beschädigen.
• 9:31
  Ein Beispiel aus der Praxis.
• 9:34
  Ein Unternehmen richtet einen dynamischen Filter ein,
• 9:36
  der auf einer berechneten Spalte in seiner Fakten-Tabelle basiert,
• 9:39
  nur um später festzustellen,
• 9:40
  dass berechnete Spalten beim Laden der Daten ausgewertet werden,
• 9:43
  nicht beim Anzeigen.
• 9:46
  Das bedeutet, dass Benutzer ihre personalisierten Zeilen nicht
• 9:48
  oder schlimmer noch, zu viele davon sehen können.
• 9:50
  Sie bemerken es erst, wenn ein Benutzer Sie anpingt und fragt,
• 9:53
  warum ein Bericht für ihn anders aussieht,
• 9:54
  als für jemand anderen im selben Team.
• 9:56
  Die Dokumentation von Microsoft und eine lange Reihe von MVP-Blog-Beiträgen
• 10:00
  schreien immer wieder von den Dächern.
• 10:01
  Vertrauen!
• 10:01
  Sie berechneten Spalten mit RLS nicht.
• 10:04
  Starbe nicht.
• 10:04
  Berechnete Spalten werden bei der Akklusion gesperrt.
• 10:07
  Sie ändern sich nicht durch den Benutzer.
• 10:09
  Damit RLS tatsächlich auf den Betrachter reagiert,
• 10:12
  muss Ihre Filterlogik als DAX-Ausdruck für Tabellen erstellt werden,
• 10:15
  die im Berichtskontext aktualisiert werden.
• 10:17
  Ignorieren Sie dies,
• 10:18
  und Ihre Dashboards verraten Sie still und heimlich,
• 10:20
  indem Sie immer dieselben Zeilen anzeigen,
• 10:22
  egal wer angemeldet ist.
• 10:23
  Statisches und dynamisches RLS ist nicht nur eine technische Unterscheidung.
• 10:27
  Es geht darum, wann und wie Daten gefiltert werden.
• 10:29
  Statisches RLS ist schnell und starr ideal, wenn Sie im Voraus genau wissen, welche Rolle
• 10:36
  welche Daten benötigt.
• 10:38
  Wenn Sie einen Bericht nur mit einer Finanz- oder Vertriebsgruppe starten, funktioniert dies.
• 10:43
  Wenn Sie jedoch dynamisch vorgehen, erfolgt jede Zugriffsentscheidung spontan in der Regel
• 10:46
  durch den Abgleich der aktuellen Benutzeridentität mit einem Eintrag in einer Nachschlagetabelle
• 10:50
  mit Berechtigungen.
• 10:50
  Diese Flexibilität ist leistungsstark, insbesondere für große Organisationen oder Bereitstellungen
• 10:56
  mit mehreren Mandanten.
• 10:57
  Doch jeder Schritt in Richtung Flexibilität führt zu mehr Komplexität,
• 11:00
  und Komplexität birgt immer versteckte Risiken.
• 11:02
  Selbst erfahrene Administratoren stolpern, weil sie glauben, dass Filter immer einfach sind.
• 11:06
  Die tatsächliche Struktur Ihrer Organisation ändert sich ständig,
• 11:09
  und Ihre DAX-Filter müssen mithalten.
• 11:12
  Viele funktionieren nicht mehr, weil sie nicht wissen, wie die RLS-Logik angewendet wird.
• 11:16
  Nicht beim Laden der Daten, sondern jedes Mal, wenn ein Benutzer mit dem Bericht interagiert.
• 11:20
  Wenn Sie das vergessen, können Sie versehentlich ganze Abschnitte Ihres Datenmodells öffnen
• 11:24
  oder blockieren, ohne es zu merken.
• 11:27
  Unterm Strich gilt, wenn Sie das Fundament falsch legen, ist alles andere, was Sie mit
• 11:30
  RLS aufbauen, von Bedeutung, von Bedeutung.
• 11:34
  Die Art und Weise, wie Sie Ihr DAX schreiben, die Art der verwendeten Filter und wo Sie sie
• 11:37
  anwenden, all das zusammen, ergibt Ihre tatsächliche Sicherheitslage.
• 11:41
  Wenn Sie die Nuancen überspringen, erhalten Sie ein Setup, das theoretisch funktioniert,
• 11:44
  in der Praxis jedoch Undichtigkeiten um.
• 11:45
  Das alles geschieht, bevor Sie überhaupt Benutzerrollen zuordnen.
• 11:48
  Genau da liegt der nächste Punkt, an dem die Dinge still und heimlich schief gehen.
• 11:52
  Rollen Benutzern zuordnen, die Zuweisungsfalle.
• 11:55
  Sie haben also Ihre Rollen eingerichtet, die Filter erstellt und auf der Modellseite sieht
• 11:58
  alles gut aus.
• 12:00
  Der nächste Schritt, die Zuweisung von Benutzern, klingt nach einem Kinderspiel.
• 12:03
  Doch genau hier fangen die meisten Sicherheitspläne auf Rollenebene langsam anzubröckeln.
• 12:07
  Hier kommt das IT-Denken ins Spiel.
• 12:10
  Die technische Logik ist vorhanden, doch jetzt müssen Sie darauf wetten, dass die menschliche
• 12:13
  Ebene Ihre Benutzer- und Gruppenzuweisungen tatsächlich mit der Realität Ihres
• 12:16
  Unternehmensablaufs übereinstimmen.
• 12:18
  Es sieht einfach aus, weil es ein Gruppenfeld in der Liste von Rollen gibt.
• 12:22
  Doch die Erfahrung zeigt, dass sich hier gerne Fehler verstecken.
• 12:25
  Stellen Sie sich Folgendes vor.
• 12:26
  Sie haben eine Managerrolle erstellt, Ihren sorgfältig erstellten Filter darauf abgelegt
• 12:29
  und die Rolle in Power BI oder Fabric einer Azure-ID-Gruppe namens Manager zugeordnet,
• 12:34
  Manager zugeordnet.
• 12:35
  Sie überprüfen alles noch einmal, holen sich vielleicht sogar eine zweite Meinung dazu
• 12:38
  und führen die Lösung für die Organisation ein.
• 12:40
  Zunächst erscheint alles noch unkompliziert.
• 12:41
  Genau das ist das Problem.
• 12:43
  Denn Gruppenlogik bleibt insbesondere in großen Organisationen selten lange einfach.
• 12:47
  Teams verschieben sich, Abteilungen werden neu organisiert, Rollen entwickeln sich weiter,
• 12:50
  Mitarbeiter verlassen ein Projekt und wechseln zum anderen.
• 12:53
  Was passiert, wenn jemand vom Vertrieb in den Betrieb wechselt und niemand die alten Gruppenmitgliedschaften
• 12:56
  bereinigt?
• 12:58
  Plötzlich ist ein Benutzer in ihrer wasserdichten LS-Blaupause an zwei Orten gleichzeitig vorhanden.
• 13:03
  Und es besteht ein echtes Risiko, dass er Zugriff auf Daten erhält, die ihm nicht mehr gehören.
• 13:07
  Man könnte leicht davon ausgehen, dass jeder in einer bestimmten Azure-ID-Gruppe dieselben
• 13:10
  Zugriffsrechte haben sollte. In der Realität können Gruppenmitgliedschaften jedoch veralten.
• 13:14
  Jemand kann in eine andere Region wechseln, aber sein Name wird nie aus der ursprünglichen
• 13:17
  Teamliste entfernt.
• 13:18
  Äh.
• 13:20
  Selbst wenn Sie als Administrator beim Aufräumen recht diszipliniert sind, kommen Gruppenbesitzer.
• 13:25
  Selten mit jeder Umstrukturierung mit, insbesondere in einem arbeitsreichen Quartal.
• 13:29
  Denken Sie auch daran, dass die Synchronisierung zwischen Azure AD und Power BI oder Fabric nicht
• 13:33
  immer sofort erfolgt.
• 13:34
  Manchmal verzögert sie sich um Stunden und das ist mehr als genug Zeit, damit jemand nach einer
• 13:37
  Änderung etwas sieht, das er nicht sehen sollte.
• 13:40
  Warten Sie auf einen nächtlichen Badge und ein ausscheidender Mitarbeiter kann mit viel
• 13:43
  mehr Kontext gehen, als Sie beabsichtigt haben.
• 13:46
  Schattenzuweisungen mögen dramatisch klingen, sind aber fast schon Routine.
• 13:50
  In den meisten realen Umgebungen kann ein einzelner Benutzer leicht in mehreren Gruppen
• 13:53
  landen, die jeweils unterschiedlichen RAS-Rollen zugeordnet sind.
• 13:57
  Das Design soll flexibel sein, was theoretisch gut ist.
• 14:00
  In der Praxis bedeutet dies, dass Sie mit einem Netz aus geerbten Berechtigungen jonglieren
• 14:03
  und es ist nicht immer klar, wer was sehen kann, es sei denn, Sie gehen der Sache manuell
• 14:06
  nach.
• 14:06
  Wenn beispielsweise Sarah von der Finanzabteilung in die Personalabteilung wechselt und niemand
• 14:10
  sie aus der Finanzgruppe herausnimmt, hat sie jetzt zwei Hüte auf, einen aktuellen und
• 14:13
  einen veralteten.
• 14:15
  Die meisten Leute bemerken es nicht einmal, bis Sarah selbst versucht, auf einen für die
• 14:18
  Finanzabteilung bestimmten Bericht zuzugreifen und sich trotzdem noch einloggen kann, lange
• 14:21
  nachdem sie in eine andere Abteilung gewechselt ist.
• 14:24
  Die Sicherheitsteams von Microsoft selbst nennen Fehler bei der Rollenzuweisung als die häufigste
• 14:28
  Ursache für die versehentliche Offenlegung von Daten in Analyseumgebungen.
• 14:31
  Die Rechnung ist einfach.
• 14:33
  Je mehr Gruppen und je mehr wechselnde Benutzer, desto leichter ist es zu übersehen.
• 14:37
  Wer tatsächlich mit welcher Rolle verknüpft ist, ist.
• 14:40
  Was die Sache noch hinterhältiger macht, ist das Fehlen eines offensichtlichen Feedbacks.
• 14:44
  Anders als bei anderen Sicherheitsfehlern erhalten Sie keine Fehlermeldung oder eine
• 14:46
  Unterbrechung der Benutzeroberfläche.
• 14:48
  Es gibt in der Regel keine automatisierte Warnung oder erzwungene Überprüfung und eine
• 14:52
  falsche Zuordnung kann monatelang im Verborgenen bleiben und erst während eines Audits oder wenn
• 14:56
  jemand auf Daten stößt, die er nicht hätte anfassen dürfen, ans Licht kommen.
• 14:58
  Selbst die besten Absichten werden durch die alltägliche Realität zunichte gemacht.
• 15:03
  Die Überprüfung von Gruppenmitgliedschaften ist eine bewährte Methode, die jeder empfiehlt,
• 15:06
  aber nur wenige Teams wenden sie tatsächlich gewissenhaft an.
• 15:09
  Aus Sicht der Administratoren ist dies eine mühsame Arbeit.
• 15:12
  Manuelle Gruppenüberprüfungen haben nicht unbedingt oberste Priorität, vor allem wenn
• 15:16
  das Analyse-Team andere Probleme bekämpft.
• 15:19
  Und in den meisten Unternehmen gibt es keinen Prozess für regelmäßige Audits, da davon ausgegangen
• 15:22
  wird, dass Änderungen in HRIT nach und nach durchgesetzt werden.
• 15:25
  Aber genau diese Annahmen führen dazu, dass Berechtigungen, Abweichen und Schattenzugriffe
• 15:29
  bestehen bleiben.
• 15:31
  Das Ergebnis ist, dass ihr RLS-Modell, egal wie präzise auf dem Papier ist, mit der Zeit
• 15:34
  nicht mehr mit den Personen beeinstimmt, die wirklich was sehen sollten.
• 15:39
  Automatisierte Prüftools können dabei helfen, diese veralteten Zuweisungen zu erkennen, aber
• 15:42
  ihre Einrichtung erfordert viel Arbeit.
• 15:45
  Sie müssen ihr Azure AD-Verbinden Änderungen kennzeichnen und möglicherweise sogar ein Workflow
• 15:48
  auslösen, wenn die Gruppenmitgliedschaften einer Person nicht mehr mit ihrer Geschäftseinheit
• 15:52
  übereinstimmt. Nicht jede Power BI-Umgebung verfügt über solche Überprüfungen, insbesondere
• 15:56
  in kleineren Abteilungen oder bei Projekten mit engen Fristen. Daher wird ein Wildwuchs
• 16:00
  der Gruppen unvermeidlich. Je länger ihr RLS-System ungenutzt bleibt, desto wahrscheinlicher
• 16:04
  ist es, dass Berechtigungen veralten oder schlimmer noch, sich auf verschiedene Ebenen ausweiten,
• 16:08
  die sie nicht einmal nachverfolgen.
• 16:10
  Was die Leute wirklich überrascht ist, dass Zuweisungen nicht nur ein Häkchen sind.
• 16:14
  Sie sind das kontinuierliche Bindeglied, das ihre Sicherheitslogik an echte Personen bindet.
• 16:18
  Lassen Sie sich selbst überlassen, wenn Sie alle cleveren DRCs der Welt nicht retten.
• 16:22
  Die Zuweisungshygiene ist ein aktiver Prozess, keine einmalige Einrichtung. Systeme entwickeln
• 16:26
  sich weiter, Benutzer werden verschoben, Ihr Modell muss diese Änderung nachverfolgen
• 16:29
  oder Sie sind auf Ihr Glück angewiesen und Glück ist keine Sicherheitsstrategie.
• 16:33
  Selbst bei den strengsten Zuweisungsprozessen kommt es in dem Moment zu einer großen Herausforderung,
• 16:37
  indem Sie Ihre sorgfältig erstellte Lösung von Power BI Desktop in Fabric übernehmen.
• 16:42
  Bis zu diesem Zeitpunkt testen die meisten Teams die lokale Sandbox auf ihrem eigenen Computer
• 16:46
  nur mit Testkonten.
• 16:49
  Das Ganze erscheint vorhersehbar, doch beim Wechsel zu Fabric treten alle möglichen subtilen
• 16:52
  Unterschiede im Benutzerkontext, bei der Gruppenauflösung und beim Authentifizierungszeitpunkt
• 16:56
  auf, auf.
• 16:58
  Hier stoßen wir auf die Macken, die niemand erwartet und warum Zuweisungen, die theoretisch
• 17:01
  perfekt erscheinen, in der Produktion spektakulär scheitern können.
• 17:05
  Von Desktop zu Fabric, die versteckten Verschiebungen im Verhalten von RLS.
• 17:09
  Wenn Sie jemals davon überzeugt waren, die Sicherheit auf Zeilenebene in Power BI Desktop vollständig
• 17:13
  unter Kontrolle zu haben, dann aber alles in die Brüche gehen sah, sobald Sie in Fabric
• 17:15
  veröffentlichen, befinden Sie sich auf vertrautem Terrain, befinden Sie sich auf vertrautem
• 17:18
  Terrain.
• 17:19
  Dies ist der Teil, über den Ihnen in RLS-Tutorials niemand etwas erzählt, der Moment, in dem die
• 17:23
  gesamte fehlerfreie Rollen- und Filterlogik mit der Realität der Cloud konfrontiert wird.
• 17:27
  Sie haben jeden Filter überprüft, jede Gruppe sorgfältig zugeordnet, sogar diese Sonderfallzuweisungen
• 17:31
  bereinigt.
• 17:33
  Sobald Sie jedoch zum Fabric-Dienst wechseln, ändern sich die Dinge auf eine Weise, die selbst
• 17:37
  erfahrene Administratoren überrascht.
• 17:39
  Beginnen wir mit dem, was Sie auf dem Desktop sehen.
• 17:41
  Die Vorschau funktioniert genau wie erwartet.
• 17:43
  Sie testen Benutzerrollen und wechseln zwischen Beispiel-Identitäten.
• 17:47
  Alles passt perfekt zusammen, die Zahlen stimmen überein und für einen Moment fühlt es sich
• 17:50
  an, als hätten Sie einen einfachen Prozess gefunden.
• 17:53
  Doch sobald Ihre Teamkollegen dieselbe Power BI-Datei in der Cloud öffnen, werden die
• 17:57
  Geschichten immer lauter.
• 18:00
  Jemand meldet, dass Zahlen außerhalb seiner Region angezeigt werden oder schlimmer noch,
• 18:03
  jemand wurde von einem Dataset ausgesperrt, das er für seine Arbeit unbedingt benötigt.
• 18:07
  Die Frustration wächst, wenn Sie feststellen, dass dasselbe RLS-Setup, das auf Ihrem Computer
• 18:10
  wasserdicht war, jetzt eher wie ein Vorschlag als wie eine Regel fungiert.
• 18:14
  Diese Verwirrung ist jedoch auf Unterschiede zurückzuführen, die Sie erst nach der Veröffentlichung
• 18:17
  sehen können.
• 18:18
  Die Cloud-Umgebung von Fabric arbeitet in einer anderen Welt, wenn es um Sicherheit, Identität
• 18:22
  und Datenkontext geht.
• 18:24
  Ein klassischer Fallstrick trifft den Kern dynamischer RLS-Muster.
• 18:28
  Auf dem Desktop ruft eine DAX-Funktion wie Username Ihre lokalen Windows-Anmeldedaten
• 18:32
  ab.
• 18:33
  Einfach, vorhersehbar und in Ihrer Umgebung beruhigend stabil.
• 18:37
  Bei Fabric ruft derselbe Benutzernamensaufruf stattdessen Ihre vollständige E-Mail-Adresse
• 18:40
  an.
• 18:41
  Das klingt unbedeutend, aber wenn Ihr Filter oder Ihre Suche auf Domain-Namen verweist
• 18:44
  oder wenn Ihre Sicherheitstabellenschlüssel Kurzformate anstelle von vollständigen E-Mails
• 18:47
  verwenden, bricht das gesamte System zusammen, sobald Benutzer die Cloud aufrufen, sobald Benutzer
• 18:51
  die Cloud aufrufen.
• 18:52
  Unweigerlich kommt es zu Beschwerden.
• 18:55
  Folgendes geschieht in realen Umgebungen.
• 18:57
  Ein Bericht zeigt eine Länderaufschlüsselung auf dem Desktop an, nach der Veröffentlichung,
• 19:00
  er hat den Benutzern jedoch globale Zahlen angezeigt.
• 19:03
  Möglicherweise stützte sich Ihr Modell auf den Benutzerprinzipalnamen, da alle Ihre
• 19:06
  Zugriffsschlüssel E-Mail-Adressen sind.
• 19:08
  Das ist eine bewährte Vorgehensweise für die Cloud, aber wenn Sie mit dem Desktop begonnen
• 19:11
  haben und nicht wussten, dass diese Verschiebung stattfindet, debuggen Sie ein Problem, das lokal
• 19:15
  nicht existiert, aber in großem Umfang explodiert.
• 19:17
  Die Wahrheit ist, dass das, was auf Ihrem Laptop funktioniert, eher ein brauchbarer Prototyp
• 19:20
  als eine fertige Lösung ist.
• 19:23
  Lokale Logik kann ein Min-Feld verbergen, das nur durch die Cloud-Authentifizierung ausgelöst
• 19:27
  wird.
• 19:27
  Es gibt auch ein paar unsichtbare Hebel, die Fabric ohne Vorwarnung betätigt.
• 19:32
  Datenaktualisierungen können beispielsweise mit anderen Anmeldeinformationen ausgelöst
• 19:35
  werden oder bei einem anderen Modellbesitzer landen, als Sie erwartet haben.
• 19:38
  Wenn der Besitzer des veröffentlichten Datasets nicht zur richtigen Gruppe gehört, sieht er
• 19:41
  möglicherweise gar keine Daten oder erhält versehentlich Zugriff auf alle Daten.
• 19:45
  Eine Änderung des Besitzes in der Cloud wirkt sich nicht nur auf Berechtigung aus.
• 19:48
  Sie kann auch Verbindungen zu Gateways unterbrechen oder die Auswertung von Anmeldeinformationen
• 19:52
  anhand von Quellsystemen ändern.
• 19:53
  Manchmal verbergen Mandanteneinstellungen veraltetes Verhalten oder greifen auf Optionen
• 19:58
  zurück, die ihre Einstellungen während der Desktop-Tests außer Kraft setzen.
• 20:02
  Bei Unternehmen mit mehrschichtigen Mandantenrichtlinien kann eine kleine Änderung wie das Umschalten
• 20:06
  der externen Freigabe die Logik darüber, wer was sieht, über Nacht ändern.
• 20:09
  Was die Leute verwirrt ist, wie subtil diese Änderungen sind.
• 20:12
  Sie schreien nicht, hey, jetzt funktioniert euer RS nicht mehr.
• 20:15
  Stattdessen funktioniert alles still und heimlich falsch.
• 20:17
  Eine kleine Änderung bei der Authentifizierung oder der Art und Weise, wie ein Modell die
• 20:21
  Gruppenmitgliedschaft bei der Anmeldung auflöst, verändert den Sicherheitskontext vollständig.
• 20:24
  Vollständig.
• 20:25
  In den Support-Foren von Microsoft wimmelt es von Administratoren, die sich Horrorgeschichten
• 20:29
  über Berichte austauschen, die jeden Desktop-Test bestanden haben.
• 20:32
  Nur um dann zusammenzubrechen, sobald Benutzer in der Cloud darauf zugreifen, zu...
• 20:36
  Sie sehen Threads, in denen Teams nach einem Rollout sich darum bemühen, alle ihre RS-Rollen
• 20:40
  zu patchen oder neu zu gestalten.
• 20:43
  Nicht, weil die Logik schlecht war, sondern weil die Umstellung auf Fabric den Identitätskontext
• 20:47
  so stark verschoben hat, dass alles unzuverlässig wurde.
• 20:50
  Selbst Cloud-Upgrades oder mandantenweite Updates können die Sicherheit in neue Richtungen lenken.
• 20:55
  Manchmal werden von Azure AD verwaltete Gruppenzuordnungen nach einem Update ein wenig anders synchronisiert
• 21:00
  als zuvor, sodass Schattenzuweisungen plötzlich eine höhere Priorität haben oder bestimmte dynamische
• 21:04
  Suchvorgänge auf Null stoßen, wo sie eine Übereinstimmung erwartet haben, wo sie eine
• 21:07
  Übereinstimmung erwartet haben.
• 21:08
  Kleine Änderungen summieren sich.
• 21:10
  Eine Optimierung in einem Teil des Stapels wirkt sich auf das gesamte Sicherheitsnetz
• 21:13
  aus und ihr zuverlässigstes Muster aus dem letzten Quartal hält heute einfach nicht
• 21:16
  mehr stand.
• 21:17
  Aus diesem Grund haben Teams in der Praxis damit begonnen, RLS-Tests des Produktionsauftrags
• 21:21
  zu betrachten und nicht nur als lokale Überprüfung.
• 21:23
  Es reicht nicht aus, auf Ihrem eigenen Laptop durch die Rollen zu klicken.
• 21:26
  Sie müssen das Modell tatsächlich in Fabric bereitstellen, echte Benutzerkonten einbinden und den
• 21:31
  durchgängigen Berechtigungsablauf durchlaufen.
• 21:35
  Nur dann erkennen Sie subtile Authentifizierungsfehler oder Diskrepanzen zwischen Gruppenzuweisungen
• 21:40
  und den aktuellen Werten, die Power BI in Azure AD für aktuell hält.
• 21:44
  Einige Organisationen führen sogar regelmäßige RLS-Audits in der Cloud durch, um zu überprüfen,
• 21:48
  ob es Abweichungen zwischen der Logik des Zuweisungsmodells und den tatsächlich von
• 21:51
  Fabric erzwungenen Werten gibt.
• 21:53
  Hier gibt es keine Abkürzung.
• 21:54
  Wenn Sie nicht mit echten Personen in der Umgebung testen, in der sich Ihr Bericht tatsächlich
• 21:57
  befindet, basiert Ihre RLS im Grunde auf Hoffnung.
• 22:02
  Die Cloud ist der letzte Schiedsrichter und die einzige Möglichkeit, um zu sehen, wie
• 22:05
  Filter und Rollen mit Identität in großem Umfang interagieren, besteht darin, Ihre RLS
• 22:09
  von Anfang an mit Blick auf die Produktion zu entwickeln.
• 22:12
  Wenn Sie diese Tests auf später verschieben, agieren Sie blind und die Folgen offengelegte
• 22:16
  Daten, frustrierte Teams oder sorgfältige Sicherheitsmaßnahmen, die durch einen versteckten
• 22:19
  Schalter zunichte gemacht wurden, verursachen viel höhere Behebungskosten, sobald der Bericht
• 22:22
  verwendet wird.
• 22:23
  Angesichts dieser Situation besteht die große Frage nicht nur darin, Ihre RLS jedes Mal
• 22:28
  zu patchen, wenn sich etwas ändert.
• 22:31
  Es geht darum, ob Sie über einen Plan verfügen, der funktioniert, wenn Ihr Fabric Setup komplizierter
• 22:34
  wird, Ihre Daten wachsen und das Unternehmen.