Latest / M365.FM – Microsoft 365, Copilot & AI podcast in het Nederlands / Beveiliging op rijniveau in Power BI en Fabric: hoe DAX, rollen en groepen echt bepalen wie wat ziet (AI-nasynchronisatie)

Transcript

Beveiliging op rijniveau in Power BI en Fabric: hoe DAX, rollen en groepen echt bepalen wie wat ziet (AI-nasynchronisatie) · M365.FM – Microsoft 365, Copilot & AI podcast in het Nederlands

0:00
Speaker 2: Klaar voor 10 dagen vol Microsoft 365, Copilot, AI, Azure
0:05
Speaker 2: en de mensen die de toekomst van werk vormgeven? In
0:08
Speaker 2: januari is M365 komt terug en we pakken het groter aan.
0:12
Speaker 2: Doe mee aan live sessies, praktijkdemonstraties en praktische kennis van
0:16
Speaker 2: MVP's en experts uit de hele wereld. Geen generieke sliedes,
0:20
Speaker 2: geen eindeloze modewoorden. We pakken de echte uitdagingen aan Copilot Studio,
0:25
Speaker 2: AI Agents, Fabric, Beveiliging, Governance en Automatisering. Of je nu
0:30
Speaker 2: een IT-professional, ontwikkelaar of bedrijfsleider bent, er zijn sessies speciaal
0:34
Speaker 2: voor jou. Gedurende tien volle dagen kun je verschillende technologieën
0:38
Speaker 2: verkennen en in contact komen met een wereldwijde community. Kijk
0:41
Speaker 2: live mee en neem praktische inzichten mee terug naar je organisatie.
0:44
Speaker 2: Januari 2027, tien dagen, één Microsoft Community. Registratie is nu geopend.
0:59
Speaker 2: Meld je nu aan op m365com.net en we zien je
1:03
Speaker 2: live in januari. Heb je je ooit afgevraagd wie jouw
1:06
Speaker 2: data in Power BI daadwerkelijk kan zien? Spoiler alert, het
1:09
Speaker 2: is niet zo privé als je misschien denkt, tenzij je
1:10
Speaker 2: beveiliging op rijniveau onder de knie hebt. In deze aflevering
1:13
Speaker 2: gaan we niet alleen de optie beveiliging op rijniveau aanvinken,
1:16
Speaker 2: maar ontleden we de verschillende onderdelen, van roldefinities tot de
1:19
Speaker 2: DAX-expressies die stilletjes bepalen wie wat kan zien. De meeste
1:22
Speaker 2: mensen stoppen bij de installatie, maar wij laten je zien
1:24
Speaker 2: hoe elke beslissing met elkaar verbonden is, zodat je gegevens
1:27
Speaker 2: niet alleen vergrendeld zijn, maar ook ontworpen zijn voor beveiliging.
1:30
Speaker 2: Waarom beveiliging op rijniveau een systeem is, geen vinkje. Als
1:33
Speaker 2: je gewend bent om een gevoelige spreadsheet te beveiligen door
1:36
Speaker 2: er een wachtwoord op te zetten, weet je al dat
1:38
Speaker 2: er een kloof is tussen wat je bedoelt en wat
1:40
Speaker 2: je gegevens daadwerkelijk beschermt. Powerbee met beveiliging op rijniveau kan
1:44
Speaker 2: precies hetzelfde aanvoelen. Je zet de beveiliging op rijniveau schakelaar aan,
1:48
Speaker 2: wijst een paar rollen toe en denkt dat je klaar bent.
1:50
Speaker 2: Maar de realiteit is anders. Gevoelige gegevens vinden een weg
1:54
Speaker 2: naar buiten wanneer de verbanden tussen rollen, filters en gebruikers
1:56
Speaker 2: niet zorgvuldig in kaart worden gebracht. Mensen praten zelden over
1:59
Speaker 2: de momenten waarop iemand in het verkoopteam een dashboard opende
2:02
Speaker 2: en ineens inzicht kreeg in cijfers die ze nooit hadden
2:05
Speaker 2: mogen zien. Maar het gebeurt, en het begint bijna altijd
2:07
Speaker 2: met de aanname dat RLS, Raw Level Security, slechts een
2:10
Speaker 2: extra vakje is dat tijdens de installatie moet worden aangevinkt.
2:12
Speaker 2: Stel je voor dat je dashboardtoegang hebt gegeven, denkend dat
2:15
Speaker 2: je daarmee een collega meer bevoegdheden geeft. Dat lijkt onschuldig, toch?
2:19
Speaker 2: Maar in te veel organisaties betekent toegang tot één dashboard
2:22
Speaker 2: toegang tot alles wat er achter de schermen gebeurt. Ik
2:24
Speaker 2: heb omgevingen gezien waar één globale manager per ongeluk junior
2:27
Speaker 2: gebruikers toegang gaf tot vertrouwelijke hour gegevens, simpelweg omdat de
2:31
Speaker 2: naamgeving niet overeen kwam met de werkelijkheid. Dit is geen
2:33
Speaker 2: zeldzaam incident. Het is eerder regel dan uitzondering, vooral wanneer
2:37
Speaker 2: een bedrijf groeit en het aantal dashboards toeneemt. Iedereen wil
2:41
Speaker 2: snel vooruit, maar zonder structuur ontstaan er kleine hiaten die
2:44
Speaker 2: tijdens een audit kunnen uitgroeien tot grote problemen. Op papier
2:48
Speaker 2: klinkt RLS heel eenvoudig. Maak een rol aan, bijvoorbeeld, verkoop,
2:52
Speaker 2: voeg een filter toe zoals regio gelijk aan VS en
2:55
Speaker 2: koppel gebruikers eraan. Maar achter elk drop-down menu en selectievakje
2:59
Speaker 2: in Power BI zit een systeem dat beslissingen neemt over
3:01
Speaker 2: welke gegevens waarheen gaan. Als je een relatie mist of
3:04
Speaker 2: een filter een nieuwe gegevensbron niet detecteert, is dat niet
3:07
Speaker 2: zomaar een technische fout. Het is een potentieel beveiligingsincident. Je
3:11
Speaker 2: komt er pas achter als iemand gegevens tegenkomt die hij
3:13
Speaker 2: of zij niet zou mogen zien, en soms zelfs dan
3:15
Speaker 2: nog niet. Dat maakt deze kleine foutjes zo moeilijk te ontdekken.
3:19
Speaker 2: Ze gaan niet gepaard met waarschuwingssignalen en standaard-audits gaan vaak
3:22
Speaker 2: niet diep genoeg om ze op te merken. Wat vaak
3:25
Speaker 2: over het hoofd wordt gezien, is hoe nauw de RLS-componenten
3:28
Speaker 2: met elkaar verbonden zijn. De meeste tutorials behandelen de installatie
3:31
Speaker 2: in een mum van tijd en leiden je door de
3:32
Speaker 2: basisprincipes van het aanmaken van rollen en filters. Ze laten
3:35
Speaker 2: zien hoe je gebruikers koppelt en een voorbeeldvenster aanvinkt, maar
3:38
Speaker 2: bijna niemand staat stil bij de vraag hoe een filter
3:40
Speaker 2: op de verkooptabel bijvoorbeeld van invloed is op een tabel
3:42
Speaker 2: met gerelateerde gebieden. Elke logica in RLS heeft invloed op
3:46
Speaker 2: de andere componenten, toewijzingen, DAX-expressies en zelfs de naamgeving van
3:50
Speaker 2: de rollen zelf. Beschouw die keuzes als geïsoleerde stappen en
3:53
Speaker 2: je vertrouwt erop dat het systeem geen losse eindjes heeft.
3:56
Speaker 2: Maar één vergeten filter en plotseling is je zorgvuldig ingestelde
4:00
Speaker 2: rollen en zeef. Dit is een van die situaties waarin
4:04
Speaker 2: een gesloten deur niet de juiste vergelijking is, maar een
4:06
Speaker 2: weerwar van draden. Verander je één onderdeel, dan kan het
4:10
Speaker 2: hele systeem ineens verschuiven. Mis je een draad, dan creëer
4:13
Speaker 2: je een lek dat pas opvalt als het wordt misbruikt.
4:15
Speaker 2: Werkelijke incidenten laten zien hoe dit in de praktijk werkt.
4:18
Speaker 2: Interne verhalen van analyse-teams vertellen over het moment... waarop de
4:21
Speaker 2: Europese salesmanager per ongeluk data uit de Noord-Amerikaanse pipeline ontdekte.
4:25
Speaker 2: Dat was geen inbraak, maar een verkeerd toegepast filter... een
4:28
Speaker 2: onbedoelde standaardinstelling of een rol die niemand had gecontroleerd. Het
4:32
Speaker 2: zijn niet alleen horrorverhalen uit de praktijk. Microsoft's eigen kwetsbaarheidsrapporten
4:36
Speaker 2: noemen verkeerd geconfigureerde beveiliging op rijniveau als een van de
4:40
Speaker 2: belangrijkste oorzaken van genante datalekken bij grote organisaties. Voor elke
4:44
Speaker 2: krantenkop over een grote datalek zijn er tientallen die niet
4:47
Speaker 2: worden gemeld, maar wel blijvende gevolgen hebben achter de schermen.
4:51
Speaker 2: Wat deze problemen met elkaar verbindt, is het valse gevoel
4:54
Speaker 2: van veiligheid dat RLS biedt wanneer je het beschouwt als
4:57
Speaker 2: een simpel item op een takenlijst. Studies van Microsoft Beveiligingsteams
5:02
Speaker 2: benadrukken dat het stapelen van filters, het toepassen ervan op tabellen,
5:06
Speaker 2: het gebruik van extra DAX-expressies of het combineren van statische
5:10
Speaker 2: en dynamische logica zowel de beveiliging als de complexiteit verhoogt.
5:13
Speaker 2: Elke extra laag maakt de boel niet alleen veiliger, maar
5:16
Speaker 2: vermenigvuldigt ook het aantal punten waar een configuratiefout kan optreden.
5:21
Speaker 2: In plaats van een simpele poortwachter aan de deur, krijg
5:24
Speaker 2: je een complex web waarin één gemiste schakel maandenlange beveiligingsplanning
5:27
Speaker 2: kan ondermijnen. Laten we ook de praktische realiteit niet negeren.
5:32
Speaker 2: Een systeem werkt misschien prima in de testomgeving, maar breng
5:35
Speaker 2: het in productie met echte gebruikers, echte afdelingen en constant
5:39
Speaker 2: wisselende teams en je krijgt situaties waarin iemand die vorig
5:43
Speaker 2: kwartaal van team is veranderd nog steeds toegang heeft tot
5:45
Speaker 2: de kwartaalcijfers. Namen en taken die in het begin logisch leken,
5:50
Speaker 2: veranderen in mysterieuze, verouderde artefacten. Niemand wil er aan zitten,
5:54
Speaker 2: voor het geval dat ze nog steeds in gebruik zijn.
5:56
Speaker 2: Als je RLS alleen tijdens de installatie inschakelt en verder gaat,
5:59
Speaker 2: bescherm je je gegevens niet. Je hoopt dat niemand per
6:01
Speaker 2: ongeluk aan de verkeerde deur klopt, of dat nu uit
6:04
Speaker 2: nieuwsgierigheid of per ongeluk is. Dit alles leidt tot één
6:07
Speaker 2: fundamentele waarheid. Beveiliging op rijniveau is dynamisch. Het verandert mee
6:11
Speaker 2: met je organisatie. Elke rol die je aanmaakt, elk taxfilter
6:13
Speaker 2: dat je toepast, elke groep die je toewijst, dit zijn
6:16
Speaker 2: geen kleine keuzes. Ze vormen samen een levend, ademend beveiligingssysteem of,
6:20
Speaker 2: als ze genegeerd worden, een web vol gaten. Dus, voordat
6:23
Speaker 2: je verder gaat naar het volgende dashboard of een model overdraagt,
6:25
Speaker 2: sta even stil en vraag jezelf af, beheer ik eigenlijk
6:28
Speaker 2: wel een beveiligingssysteem of hoop ik alleen maar dat het
6:30
Speaker 2: inschakelen voldoende is? Het volgende deel van dit verhaal begint
6:33
Speaker 2: met het onderdeel dat centraal staat, de filterlogica zelf, en
6:37
Speaker 2: hoe deze elke andere beslissing die je neemt beïnvloedt. Het
6:40
Speaker 2: bouwen van een veilige basis, data filtering en rolontwerp. Als
6:44
Speaker 2: je ooit beveiliging op rijniveau hebt ingesteld in de veronderstelling
6:46
Speaker 2: dat het alleen maar ging om het verbergen van bepaalde rijen,
6:48
Speaker 2: dan ben je niet de enige. De belangrijkste reden waarom RLS,
6:50
Speaker 2: Real Level Security, problemen veroorzaakt, is een simpel misverstand. Het
6:53
Speaker 2: gaat niet alleen om wat zichtbaar is, maar om de
6:55
Speaker 2: vormgeving van de gehele gebruikerservaring. Eén kleine misstap en plotseling
7:00
Speaker 2: verschijnt die vertrouwelijke bonustabel of dat salarisscijfer van een directielid
7:04
Speaker 2: in iemands dashboard. Mensen ontdekken deze lekken echter pas wanneer
7:08
Speaker 2: rapporten al in omloop zijn en tegen die tijd kan
7:10
Speaker 2: het lastig zijn om de fout te herstellen. Het vervelende
7:13
Speaker 2: is dat deze fouten zelden dramatisch lijken. Het gaat meestal
7:16
Speaker 2: om een uitzonderlijk geval. Een manager in de VS logt
7:18
Speaker 2: in en ziet precies wat hij of zij hoort te zien,
7:20
Speaker 2: maar een collega in Londen opent hetzelfde model en ziet,
7:22
Speaker 2: zonder dat iemand het doorheeft, het cijfer van New York staan.
7:26
Speaker 2: Neem bijvoorbeeld een fabric model voor wereldwijde verkoop. Je wilt
7:29
Speaker 2: dat managers in verschillende regio's alleen hun eigen gegevens zien.
7:33
Speaker 2: De eerste reactie is om een filter toe te voegen,
7:35
Speaker 2: iets simpels. Regio gelijk aan VS of land gelijk aan VK.
7:39
Speaker 2: Maar hier zit de crux. Hoe je dat filter schrijft
7:42
Speaker 2: en hoe je het in je model integreert, bepaalt of
7:45
Speaker 2: je systeem wel of niet overeind blijft zodra de zaken
7:47
Speaker 2: complexer worden. Veel mensen denken dat het dood simpel is,
7:50
Speaker 2: een DAX filter van één regel en gaan dan verder.
7:53
Speaker 2: Maar niet alle DAX gedraagt zich hetzelfde. Sterker nog, die
7:57
Speaker 2: nuance zorgen vaak voor problemen later, vooral wanneer je overstapt
8:00
Speaker 2: van Power BI Desktop naar Fabric. waar eigenaardigheden op cloudniveau
8:03
Speaker 2: de kop op steken. RLS wordt al snel ingewikkeld als
8:06
Speaker 2: je je erin verdiept. Mensen vertrouwen vaak op functies zoals
8:09
Speaker 2: gebruikersnaam of gebruikersprincipaalnaam... in de veronderstelling dat ze hetzelfde doen
8:13
Speaker 2: of gewoon de functie gebruiken die in een blogpost wordt gebruikt.
8:16
Speaker 2: Maar vervang gebruikersnaam, die je Windowsnaam in desktop ophaalt, door gebruikersprincipaalnaam...
8:21
Speaker 2: die je e-mailadres in Fabric ophaalt en plotseling begint je
8:24
Speaker 2: filterlogica te wankelen. Als je ooit een test hebt gehad
8:27
Speaker 2: die in desktop werkte, maar crashte zodra je publiceerde naar Fabric,
8:30
Speaker 2: dan is dit waarschijnlijk de reden. En door de verkeerde
8:32
Speaker 2: te kiezen, ontstaan er stilletjes gaten waardoor de verkeerde mensen
8:35
Speaker 2: toegang krijgen tot gegevens waar ze nooit toegang toe zouden
8:37
Speaker 2: mogen hebben. Laten we concreet worden. Voor basisscenario's werkt een
8:41
Speaker 2: hard gecodeerde controle. Regio gelijk aan VS betekent dat alleen
8:45
Speaker 2: rijen worden weergegeven waar de regio VS is. Dat is
8:47
Speaker 2: een schoolvoorbeeld van statische RLS. Het is snel, eenvoudig en
8:51
Speaker 2: voor vaste indelingen, zoals een rapport dat alleen bedoeld is
8:53
Speaker 2: voor managers in de VS, voldoet het prima. Maar zodra
8:56
Speaker 2: iemand dynamische beveiliging nodig heeft, verandert de situatie. Mogelijk moet
8:59
Speaker 2: u de toegang niet alleen bepalen op basis van de
9:01
Speaker 2: rapport viewer, maar ook op basis van relaties in een
9:03
Speaker 2: andere tabel, bijvoorbeeld een tabel met gebruikerstoegang die aangeeft welke
9:06
Speaker 2: gebruikers welke regio's kunnen zien. Nu is uw RLS-filter geen
9:09
Speaker 2: vaste waarde meer. Het is een formule die in real-time
9:11
Speaker 2: opzoekt tot welke regio's elke persoon toegang zou moeten hebben.
9:15
Speaker 2: Hier kan DAX mislukken als u niet voorzichtig bent. U
9:17
Speaker 2: zou bijvoorbeeld een gebruikersprincipaalnaam kunnen gebruiken en die vervolgens proberen
9:21
Speaker 2: te koppelen aan uw toegangstabel. Maar als uw DAX afhankelijk
9:24
Speaker 2: is van berekende kolommen of logica gebruikt die niet reageert
9:27
Speaker 2: op de gebruikerscontext tijdens het bekijken van het rapport, kunt
9:30
Speaker 2: u per ongeluk het dynamische filter verstoren. Een praktijkvoorbeeld, een
9:34
Speaker 2: bedrijf stelt een dynamisch filter in op basis van een
9:37
Speaker 2: berekende kolom in de feitetabel, maar komt er later achter
9:40
Speaker 2: dat berekende kolommen worden geëvalueerd wanneer de gegevens worden geladen,
9:44
Speaker 2: niet wanneer ze worden bekeken. Dit betekent dat gebruikers hun
9:47
Speaker 2: gepersonaliseerde rijen niet kunnen zien, of erger nog, te veel zien.
9:50
Speaker 2: Je merkt het pas als een gebruiker je een bericht
9:52
Speaker 2: stuurt met de vraag waarom een rapporter voor hem of
9:54
Speaker 2: haar anders uitziet dan voor iemand anders in hetzelfde team.
9:57
Speaker 2: De documentatie van Microsoft en een lange reeks MVP-blogposts blijven
10:01
Speaker 2: maar hoepen. Vertrouw geen berekende kolommen met RLS. Berekende kolommen
10:05
Speaker 2: zijn vergrendeld bij het vernieuwen. Ze veranderen niet per gebruiker.
10:09
Speaker 2: Om RLS daadwerkelijk te laten reageren op de gebruiker, moet
10:12
Speaker 2: je filterlogica worden opgebouwd als een DAX-expressie op tabellen die
10:15
Speaker 2: worden bijgewerkt in de rapportcontext. Negeer je dit, dan zullen
10:18
Speaker 2: je dashboards je stiekem in de steek laten en dezelfde
10:21
Speaker 2: rijen tonen, ongeacht wie er is ingelogd. Statisch versus dynamisch
10:25
Speaker 2: RLS is niet alleen een technisch verschil. Het gaat erom
10:28
Speaker 2: wanneer en hoe gegevens worden gefilterd. Een statisch RLS is
10:32
Speaker 2: snel en rigide, ideaal wanneer je precies weet welke rol
10:36
Speaker 2: welke gegevens nodig heeft. Als je een rapport alleen voor
10:40
Speaker 2: een financiële of verkoopgroep opent, werkt dit prima. Maar bij
10:43
Speaker 2: een dynamische aanpak vindt elke toegangsbeslissing direct plaats, meestal door
10:47
Speaker 2: de huidige gebruikersidentiteit te vergelijken met een item in een
10:50
Speaker 2: opzoektabel met machtigingen. De flexibiliteit is krachtig, vooral voor grote
10:54
Speaker 2: organisaties of multitenant implementaties, maar elke stap in flexibiliteit voegt
10:58
Speaker 2: complexiteit toe en complexiteit brengt altijd verborgen risico's met zich mee.
11:02
Speaker 2: Zelfs ervaren beheerders struikelen vaak over de gedachte dat filters
11:06
Speaker 2: altijd eenvoudig zijn. De structuur van uw organisatie verandert voortdurend
11:10
Speaker 2: en uw DAX filters moeten daarop inspelen. Veel filters falen
11:13
Speaker 2: omdat men zich niet realiseert hoe de RLS-logica wordt toegepast,
11:16
Speaker 2: niet tijdens het laden van gegevens, maar elke keer dat
11:19
Speaker 2: een gebruiker interactie heeft met het rapport. Vergeet dat en
11:22
Speaker 2: u kunt per ongeluk hele delen van uw datamodel openen
11:25
Speaker 2: of blokkeren zonder het te beseffen. Kortom, als de basis
11:29
Speaker 2: verkeerd is, doet de rest van wat u met RLS
11:32
Speaker 2: bouwt er niet toe. De manier waarop u uw DAC schrijft,
11:35
Speaker 2: het soort filters dat u gebruikt en waar u ze toepast,
11:38
Speaker 2: bepalen samen uw werkelijke beveiligingspositie. Negeer de nuances en u
11:42
Speaker 2: krijgt een configuratie die in theorie werkt, maar in de
11:44
Speaker 2: praktijk lekt. Dit alles gebeurt nog voordat je gebruikers aan
11:48
Speaker 2: rollen koppelt, wat vaak het volgende punt is waar het misgaat.
11:52
Speaker 2: Het koppelen van rollen aan gebruikers, de valkuil. Je hebt
11:55
Speaker 2: je rollen ingesteld, de filters gemaakt en aan de modelzijde
11:59
Speaker 2: ziet alles er goed uit. De volgende stap, het toewijzen
12:01
Speaker 2: van gebruikers, lijkt een fluitje van een cent, maar hier
12:04
Speaker 2: beginnen de meeste beveiligingsplannen op rolniveau stilletjes te haperen. Dit
12:07
Speaker 2: is het kruispunt van IT-denken. De technische logica is aanwezig,
12:12
Speaker 2: maar nu gok je erop dat de menselijke kant, je
12:14
Speaker 2: gebruikers- en groepstoewijzingen, daadwerkelijk overeenkomt met de realiteit van hoe
12:18
Speaker 2: je bedrijf werkt. Het lijkt eenvoudig omdat er een groepsveld
12:21
Speaker 2: en een lijst met rollen is, maar de ervaring leert
12:23
Speaker 2: dat hier fouten zich graag verschuilen. Stel je voor, je
12:26
Speaker 2: hebt een managersrol aangemaakt. Je zorgvuldig opgebouwde filter eraan toegevoegd
12:30
Speaker 2: en de rol in Power B of Fabric gekoppeld aan
12:33
Speaker 2: een Azure AD groep genaamd Managers. Je controleert het nog eens,
12:36
Speaker 2: laat er misschien zelfs iemand anders naar kijken en rolt
12:39
Speaker 2: het uit naar de organisatie. In eerste instantie lijkt het
12:41
Speaker 2: allemaal heel eenvoudig. Dat is nu juist het probleem, want groepslogica,
12:45
Speaker 2: vooral in grote organisaties, blijft zelden lang simpel. Teams veranderen,
12:48
Speaker 2: afdelingen reorganiseren, rollen evolueren, mensen verlaten het ene project en
12:52
Speaker 2: sluiten zich aan bij een ander. Wat gebeurt er als
12:54
Speaker 2: iemand van Sales naar Operations overstapt en niemand de oude
12:56
Speaker 2: groepslidmaatschappen verwijdert? Plotseling heeft uw waterdichte RLS-blauwdruk een gebruiker op
13:01
Speaker 2: twee plaatsen tegelijk. En er is een reëel risico dat
13:04
Speaker 2: die gebruiker toegang krijgt tot gegevens die niet langer van
13:06
Speaker 2: hem of haar zijn. Het is gemakkelijk om aan te
13:08
Speaker 2: nemen dat iedereen in een bepaalde Azure AD-groep dezelfde toegang
13:11
Speaker 2: zou moeten hebben. Maar in werkelijkheid kunnen groepslidmaatschappen verouderen. Iemand
13:14
Speaker 2: kan naar een andere regio verhuizen, maar zijn of haar
13:17
Speaker 2: naam blijft in de oorspronkelijke teamlijst staan. Zelfs als u
13:21
Speaker 2: als beheerder zeer gedisciplineerd bent met opruimen, houden groepseigenaren zelden
13:25
Speaker 2: alle wijzigingen bij, vooral tijdens een drukke periode. En vergeet
13:29
Speaker 2: niet dat de synchronisatie tussen Azure AD en Power BI
13:32
Speaker 2: of Fabric niet altijd direct is. Soms loopt het uren
13:35
Speaker 2: achter en dat is meer dan genoeg tijd voor iemand
13:37
Speaker 2: om na een wijziging iets te zien wat hij of
13:38
Speaker 2: zij niet zou moeten zien. Wacht op een nachtelijke batchverwerking
13:41
Speaker 2: en een vertrekkende medewerker kan met veel meer context vertrekken
13:45
Speaker 2: dan je had bedoeld. Schaduwtoewijzingen klinken misschien dramatisch, maar ze
13:48
Speaker 2: zijn bijna routine. In de meeste praktijksituaties kan één gebruiker
13:52
Speaker 2: gemakkelijk in meerdere groepen terechtkomen, elk gekoppeld aan verschillende RLS-rollen.
13:56
Speaker 2: Het ontwerp is bedoeld om flexibel te zijn, wat in
13:59
Speaker 2: theorie goed is. In de praktijk betekent het dat je
14:01
Speaker 2: jong leert met een web van overgeërfde machtigingen en dat
14:04
Speaker 2: het niet altijd duidelijk is wie wat kan zien, tenzij
14:06
Speaker 2: je het handmatig nagaat. Als Sarah van de financiële afdeling
14:09
Speaker 2: bijvoorbeeld naar Auer verhuist en niemand haar uit de financiële
14:11
Speaker 2: groep haalt, heeft ze nu twee petten op, een actuele
14:14
Speaker 2: en een verouderde. De meeste mensen merken het niet eens
14:16
Speaker 2: totdat Sarah zelf een rapport probeert te openen dat bedoeld
14:19
Speaker 2: is voor de financiële afdeling en er nog steeds toegang
14:21
Speaker 2: toe krijgt, lang nadat ze naar een andere afdeling is overgeplaatst.
14:24
Speaker 2: De beveiligingsteams van Microsoft zelf wijzen fouten in roltoewijzingen aan
14:28
Speaker 2: als de belangrijkste oorzaak van onbedoelde datalekken in analyseomgevingen. De
14:32
Speaker 2: rekensom is simpel. Hoe meer groepen en hoe meer gebruikers
14:35
Speaker 2: er van rol wisselen, hoe gemakkelijker het is om over
14:37
Speaker 2: het hoofd te zien wie er daadwerkelijk aan welke rol
14:39
Speaker 2: is gekoppeld. Wat het extra lastig maakt, is het gebrek
14:42
Speaker 2: aan duidelijke feedback. In tegenstelling tot andere beveiligingsfouten krijg je
14:46
Speaker 2: geen foutmelding of een onderbreking in de gebruikersinterface. Er is
14:49
Speaker 2: meestal geen geautomatiseerde waarschuwing of verplichte controle en onjuiste toewijzingen
14:52
Speaker 2: kunnen maandenlang onopgemerkt blijven, om pas aan het licht te
14:55
Speaker 2: komen tijdens een audit of wanneer iemand per ongeluk toegang
14:57
Speaker 2: krijgt tot gegevens waar hij of zij geen toegang toe
14:58
Speaker 2: had mogen hebben. Zelfs de beste bedoelingen worden teniet gedaan
15:01
Speaker 2: door de dagelijkse realiteit. Het controleren van groepslidmaatschappen is een
15:05
Speaker 2: best practice die iedereen aanbeveelt, maar weinig teams volgen deze
15:08
Speaker 2: daadwerkelijk nauwgezet op. Vanuit het perspectief van de beheerder is
15:11
Speaker 2: het een vervelende klus. Handmatige groepsbeoordelingen staan niet bepaald bovenaan
15:15
Speaker 2: de prioriteitenlijst, vooral niet als het analytics team andere problemen
15:18
Speaker 2: moet oplossen. En in de meeste organisaties is er geen
15:20
Speaker 2: proces voor regelmatige audits, omdat ervan wordt uitgegaan dat wijzigingen
15:24
Speaker 2: in HRET vanzelf worden doorgevoerd. Maar juist die aannames zorgen
15:27
Speaker 2: ervoor dat machtigingen kunnen verschuiven en dat heimelijke toegang kan
15:30
Speaker 2: blijven bestaan. Het resultaat is dat je RLS-model, hoe nauwkeurig
15:34
Speaker 2: het er op papier ook uitziet, na verloop van tijd
15:36
Speaker 2: niet meer synchroon loopt met wie wat daadwerkelijk zou moeten zien.
15:39
Speaker 2: Geautomatiseerde additools kunnen helpen bij het opsporen van deze achtergebleven toewijzingen,
15:43
Speaker 2: maar het opzetten ervan vergt werk. Ze moeten verbinding maken
15:46
Speaker 2: met uw Azure AD, wijzigingen signaleren en mogelijk zelfs een
15:49
Speaker 2: workflow activeren wanneer iemands groepslidmaatschap niet meer overeenkomt met zijn
15:52
Speaker 2: of haar bedrijfseenheid. Niet elke Power BI-omgeving beschikt over dit
15:55
Speaker 2: soort controles, vooral niet bij kleinere bedrijven of projecten met
15:58
Speaker 2: strakke deadlines. Daardoor is wildgroei aan groepen onvermijdelijk. Hoe langer
16:02
Speaker 2: uw RLS-systeem in gebruik is, hoe groter de kans dat
16:05
Speaker 2: machtigingen verouderen of, erger nog, Doorcijpelen naar verschillende lagen die
16:09
Speaker 2: u niet eens bijhoudt. Wat mensen echt verrast, is dat
16:12
Speaker 2: toewijzingen niet zomaar een vinkje zijn. Ze vormen de continu
16:15
Speaker 2: schakel die uw beveiligingslogica verbindt met echte mensen. Laat ze
16:18
Speaker 2: maar los en alle slimme DAC's ter wereld zullen u
16:21
Speaker 2: niet redden. Het onderhouden van toewijzingen is een actief proces,
16:24
Speaker 2: geen eenmalige instelling. Systemen evolueren, gebruikers verplaatsen zich, uw model
16:28
Speaker 2: moet die veranderingen bijhouden, anders bent u afhankelijk van geluk.
16:31
Speaker 2: en geluk is geen beveiligingsstrategie. Zelfs met de meest strikte
16:34
Speaker 2: toewijzingsprocessen komt er een grote verrassing op het moment dat
16:37
Speaker 2: je je zorgvuldig opgebouwde oplossing van Power BI Desktop naar
16:40
Speaker 2: de cloud-omgeving van Fabric overzet. Tot nu toe testen de
16:44
Speaker 2: meeste teams in een lokale sandbox op hun eigen machine
16:47
Speaker 2: met alleen testaccounts. Alles lijkt voorspelbaar, maar bij de overstap
16:51
Speaker 2: naar Fabric komen allerlei subtiele verschillen in gebruikerscontext, groepsresolutie en
16:56
Speaker 2: authenticatietijd aan het licht. Dat is waar we de eigenaardigheden
16:59
Speaker 2: tegenkomen die niemand verwacht en waarom toewijzingen die in theorie
17:02
Speaker 2: perfect lijken... in productie spectaculair kunnen mislukken. Van desktop naar Fabric,
17:07
Speaker 2: de verborgen verschuivingen in RLS-gedrag. Als je er ooit van
17:10
Speaker 2: overtuigd bent geweest... dat je de beveiliging op rijniveau volledig
17:12
Speaker 2: onder controle had in Power BI Desktop... maar vervolgens zag
17:15
Speaker 2: hoe alles instortte op het moment dat je publiceerde naar Fabric...
17:17
Speaker 2: dan ben je hier aan het juiste adres. Dit is
17:19
Speaker 2: het deel waar niemand je over vertelt in RLS Tutorials...
17:23
Speaker 2: het moment waarop al die vlekkeloze rol en filterlogica botst
17:26
Speaker 2: met de realiteit van de cloud. Je hebt elk filter gecontroleerd...
17:29
Speaker 2: Elke groep zorgvuldig toegewezen en zelfs de randgevallen netjes toegewezen.
17:33
Speaker 2: Maar zodra je overstapt naar de Fabric Service verandert er
17:37
Speaker 2: iets dat zelfs doorgewinterde beheerders verrast. Laten we beginnen met
17:40
Speaker 2: wat je in de desktopversie ziet. De preview werkt precies
17:43
Speaker 2: zoals je zou verwachten. Je test gebruikersrollen, je schakelt tussen voorbeeldidentiteiten.
17:47
Speaker 2: Alles klopt, de cijfers komen overeen en even lijkt het
17:50
Speaker 2: alsof je een eenvoudig proces onder de knie hebt. Maar
17:53
Speaker 2: zodra je teamgenoten hetzelfde Power BI bestand in de cloud openen,
17:57
Speaker 2: beginnen de problemen zich op te stapelen. Iemand meldt dat
18:00
Speaker 2: hij of zij cijfers buiten de eigen regio ziet, of
18:03
Speaker 2: erger nog, iemand heeft geen toegang tot een dataset die
18:05
Speaker 2: absoluut noodzakelijk is voor het werk. De frustratie neemt toe
18:08
Speaker 2: wanneer je beseft dat dezelfde RLS-configuratie die op jouw computer
18:11
Speaker 2: perfect werkte, nu meer als een suggestie dan als een
18:13
Speaker 2: regel fungeert. Maar die verwarring komt voort uit verschillen die
18:16
Speaker 2: je pas ziet na publicatie. De cloud-omgeving van Fabric opereert
18:20
Speaker 2: in een andere wereld als het gaat om beveiliging, identiteit
18:23
Speaker 2: en datacontext. Een klassiek probleem raakt de kern van dynamische RLS-patronen.
18:28
Speaker 2: In de desktopversie haalt een DAX-functie zoals username je lokale
18:32
Speaker 2: Windows-aanmelding op. Eenvoudig, voorspelbaar en binnen je eigen omgeving geruststellend stabiel.
18:37
Speaker 2: Maar op Fabric gebruikt diezelfde gebruikersnaam oproep je volledige e-mailadres.
18:41
Speaker 2: Het klinkt misschien onbeduidend, maar als je Filter of Lookup
18:43
Speaker 2: domeinnamen gebruikt, of als je beveiligingstabel korte formaten in plaats
18:47
Speaker 2: van volledige e-mailadressen gebruikt, stort het hele systeem in elkaar
18:50
Speaker 2: zodra gebruikers de cloud gebruiken. Onvermijdelijk krijg je dan klachten.
18:55
Speaker 2: Dit is wat er in de praktijk gebeurt. Een rapport
18:57
Speaker 2: toont een landspecifieke uitsplitsing op de desktop, maar na publicatie
19:01
Speaker 2: zien gebruikers wereldwijde cijfers. Misschien was je model gebaseerd op
19:05
Speaker 2: de gebruikersprincipaalnaam omdat al je toegangsleutels e-mailadressen zijn. Dat is
19:09
Speaker 2: goede praktijk voor de cloud, maar als je op de
19:10
Speaker 2: desktop bent begonnen en niet wist dat deze verschuiving plaatsvindt,
19:13
Speaker 2: ben je bezig met het oplossen van een probleem dat
19:15
Speaker 2: lokaal niet bestaat, maar op grote schaal escaleert. De waarheid
19:18
Speaker 2: is dat wat op je laptop werkt eerder een degelijk
19:20
Speaker 2: prototype is dan een afgewerkte oplossing. Lokale logica kan een
19:24
Speaker 2: valkuil bevatten die alleen door cloud-authenticatie wordt geactiveerd. Fabric heeft
19:28
Speaker 2: ook een aantal onzichtbare mechanismen die zonder waarschuwing in werking treden.
19:32
Speaker 2: Gegevensverversingen kunnen bijvoorbeeld worden uitgevoerd met andere referenties of terechtkomen
19:36
Speaker 2: bij een andere modeleigenaar dan verwacht. Als de eigenaar van
19:38
Speaker 2: de gepubliceerde dataset niet in de juiste groep zit, kan
19:41
Speaker 2: het gebeuren dat gebruikers helemaal geen gegevens zien of per
19:43
Speaker 2: ongeluk toegang krijgen tot alles. Het wijzigen van eigenaarschap in
19:46
Speaker 2: de cloud heeft niet alleen gevolgen voor machtigingen. Het kan
19:49
Speaker 2: verbindingen met gateway verbreken of de manier veranderen... waarop referenties
19:52
Speaker 2: worden geëvalueerd ten opzichte van bron-systemen. Soms verbergen tenant-instellingen verouderd
19:56
Speaker 2: gedrag of staan er standaardopties op... die de instellingen overschrijven
19:59
Speaker 2: die u tijdens desktop-tests hebt geconfigureerd. Voor organisaties met gelaagde
20:03
Speaker 2: tenant-beleidsregels kan iets kleins als het in- of uitschakelen van extern...
20:06
Speaker 2: delen de logica van wie wat ziet van de ene
20:08
Speaker 2: op de andere dag veranderen. Wat mensen vaak verbaast, is
20:11
Speaker 2: hoe subtiel deze veranderingen zijn. Ze roepen niet, hé, je
20:14
Speaker 2: RLS werkt nu niet meer. In plaats daarvan werken dingen
20:16
Speaker 2: stilletjes verkeerd. Een kleine wijziging in authenticatie of de manier
20:20
Speaker 2: waarop een model groepslidmaatschap bepaalt tijdens het aanmelden, verandert de
20:23
Speaker 2: beveiligingscontext volledig. Microsoft ondersteuningsforums staan vol met beheerders die horrorverhalen
20:29
Speaker 2: delen over rapporten die elke desktoptest doorstonden, maar vervolgens volledig
20:33
Speaker 2: in de soep liepen zodra gebruikers ze in de cloud
20:36
Speaker 2: gingen gebruiken. Je ziet discussies waarin teams na een uithol
20:39
Speaker 2: in AllerL al hun RLS-hollen proberen te patchen of opnieuw
20:42
Speaker 2: te ontwerpen. Niet omdat de logica slecht was, maar omdat
20:45
Speaker 2: de overstap naar Fabric de identiteitscontext zodanig heeft veranderd dat
20:49
Speaker 2: alles onbetrouwbaar is geworden. Zelfs cloud-upgrades of tenant-brede updates kunnen
20:53
Speaker 2: de beveiliging in nieuwe richtingen sturen. Soms synchroniseren groepstoewijzingen die
20:57
Speaker 2: door Azure AD worden beheerd na een update net iets
21:00
Speaker 2: anders dan voorheen, waardoor schaduwtoewijzingen plotseling meer prioriteit krijgen of
21:04
Speaker 2: bepaalde dynamische zoekopdrachten al waarden opleveren waar je een match verwachtte.
21:08
Speaker 2: Kleine veranderingen tellen op. Een kleine aanpassing in één onderdeel
21:11
Speaker 2: van de stack heeft gevolgen voor het hele beveiligingsnetwerk en
21:14
Speaker 2: je meest betrouwbare patroon van het vorige kwartaal is vandaag
21:16
Speaker 2: de dag niet meer voldoende. Daarom zijn teams in de
21:18
Speaker 2: praktijk RLS-testen gaan behandelen als een productietaak en niet alleen
21:22
Speaker 2: als een lokale controle. Het is niet genoeg om de
21:24
Speaker 2: rollen op je eigen laptop te controleren. Je moet het
21:27
Speaker 2: model daadwerkelijk in Fabric implementeren, echte gebruikersaccounts importeren en de
21:32
Speaker 2: volledige permissiestroom doorlopen. Pas dan ontdek je subtiele authenticatiefouten of
21:38
Speaker 2: discrepanties tussen groepstoewijzingen en wat Power BI als actueel beschouwt
21:42
Speaker 2: in Azure AD. Sommige organisaties voeren zelfs periodieke RLS-audits uit
21:47
Speaker 2: in de cloud om te controleren op afwijkingen tussen de
21:49
Speaker 2: logica van het toewijzingsmodel en wat Fabric daadwerkelijk afdwingt. Er
21:53
Speaker 2: is geen kortere weg. Als je niet test met echte
21:56
Speaker 2: mensen in de omgeving waar je rapport daadwerkelijk draait, is
21:59
Speaker 2: je RLS in feite gebaseerd op hoop. De cloud is
22:02
Speaker 2: de uiteindelijke scheidsrechter en de enige manier om te zien
22:05
Speaker 2: hoe filters en rollen op grote schaal met identiteiten interageren,
22:08
Speaker 2: is door je RLS vanaf het begin te ontwerpen met
22:11
Speaker 2: productie in gedachte. Als je deze tests uitstelt, werk je
22:14
Speaker 2: in het duister en de gevolgen blootgestolde gegevens, gefrustreerde teams
22:17
Speaker 2: of zorgvuldig beveiligingswerk dat teniet wordt gedaan door een verborgen
22:20
Speaker 2: schakelaar kosten uiteindelijk veel meer om te herstellen zodra het
22:23
Speaker 2: rapport in gebruik is. In deze context is de grote
22:26
Speaker 2: vraag niet alleen of je je RLS moet bijwerken telkens
22:29
Speaker 2: wanneer er iets verandert. Het gaat erom of je een
22:31
Speaker 2: plan hebt dat werkt naarmate je Fabric configuratie complexer wordt,
22:35
Speaker 2: je data groeit en de bedrijfsbehoeften veranderen.