Filter-based security in Power Platform
Eindelijk security op basis van je data?
Filter-based security komt naar Dataverse en gaat een belangrijk gat binnen Dataverse vullen!
Ik ben vast niet de enige die online, en zeker op LinkedIn, zijn feed helemaal vol heeft staan met berichten over nieuwe AI-features. Iedere dag lijkt er wel weer een nieuw LLM-model beschikbaar te komen, waarmee dan weer het model van één maand geleden “dead is”. 90% van je feed gaat over AI of is gemaakt door AI.
Ook bij Microsoft gaat er onmiskenbaar veel aandacht uit naar Copilot. Des te meer was ik verrast toen ik begin deze maand het nieuws hoorde over een nieuwe previewfunctie: Filter-based security.
Yes, dacht ik! Hier kunnen we wat mee. Dit raakt namelijk een probleem waar we bij het ontwerpen van Dataverse-oplossingen regelmatig tegenaan lopen.
Maar gek genoeg krijgt deze veelbelovende preview veel te weinig aandacht online. Een feature die veel potentie heeft, maar geen AI is, komt simpelweg nauwelijks door het online AI-geweld heen.
Vandaar deze blog. Want naar mijn mening is dit potentieel een van de grootste Dataverse-securitygerelateerde nieuwe features van de afgelopen jaren! En wellicht zelfs nog groter dan Modernized Business Units.
Dataverse security
Voordat ik dieper inga op de nieuwe previewfunctionaliteit, eerst nog even de basisbeginselen van het securitymodel binnen Dataverse.
In het traditionele securitymodel van Dataverse speelt de business unit van de gebruiker een grote rol. Een gebruiker hoort bij één business unit en daarmee hoort ook “zijn data” bij zijn business unit. Met securityrollen kan vervolgens per CRUD-actie ingericht worden tot welk niveau toegang gegeven kan worden: persoonlijk, business unit, parent business unit of organization.
Het traditionele securitymodel zie je veruit het meest. Ter aanvulling hierop bestaan er ook al lang andere opties, zoals:
Access Teams
Hiërarchiebeveiliging
In veel situaties kan je prima uit de voeten met het traditionele securitymodel, maar zeker binnen matrixorganisaties begint dat in de praktijk te knellen.
Om dit probleem te tackelen kwam Microsoft enkele jaren geleden met Modernized Business Units. Met deze feature zit data niet meer zo rigide vast aan de business unit van de gebruiker die toevallig “owner” is van dat record. Records kregen zelf een Owning Business Unit. Hierdoor hoeft de business unit van de gebruiker niet langer te bepalen tot welke business unit-data die gebruiker toegang kan krijgen.
Dat lijkt misschien een kleine technische wijziging, maar architectonisch was het een belangrijke stap.
Om Neil Armstrong er toch maar even bij te halen: voor Dataverse-security was dit zeker wel een sprong. En ja... Neil Armstrong citeren is cliché.
Soms ontwerpen we ons datamodel rondom security
Het securitymodel binnen Dataverse is sterk, maar het model is nog steeds rigide en kent zeker zijn beperkingen.
Bij het ontwerpen van een oplossing binnen Dataverse moet vooraf al goed worden nagedacht over de implicaties van het datamodel.
Dit resulteert er in de praktijk ook vaak genoeg in dat de oplossing of het datamodel rondom het securitymodel wordt ontworpen. Dat resulteert niet altijd in de meest overzichtelijke oplossingen. Los van het datamodel is er voor de totaaloplossing ook vaak veel automatisering nodig om ervoor te zorgen dat de juiste gebruikers bij de juiste data kunnen.
En dat is precies waarom ik Filter-based security interessant vind.
Wat als de data zelf de security boundary bepaalt?
En nu staan we weer op de vooravond van een belangrijke sprong binnen Dataverse: Filter-based security.
Met Filter-based security kunnen securityrollen voorzien worden van filters op basis van FetchXML, gekoppeld aan CRUD-acties.
In plaats van:
Wie is eigenaar van dit record?
kun je dus veel meer denken vanuit:
Aan welke eigenschappen voldoet dit record?
Stel dat we één generieke tabel gebruiken voor project budget items.
Ieder record heeft bijvoorbeeld een Domain:
Finance
HR
Legal
Procurement
Een HR-gebruiker mag alleen HR-records lezen en wijzigen.
Finance alleen Finance.
En iemand vanuit Compliance mag misschien alle records lezen zodra de status Approved is.
De security boundary volgt dan niet uit de eigenaar van het record, maar uit de inhoud van het record. Dat is een wezenlijk ander uitgangspunt.
En tuurlijk, deze requirements zijn nu ook wel te realiseren met de opties die al beschikbaar zijn in de Dataverse-legodoos. Dit vergt echter wel een hoop inrichting en logica. Met Filter-based security gaat het legobouwwerk er wel wat meer gestructureerd uitzien.
Als vijf gebruikers moeten samenwerken aan één specifiek dossier, dan past een access team daar prima bij.
Hetzelfde geldt voor sharing. Als iemand tijdelijk toegang moet krijgen tot één specifiek record, is daar al jaren een prima mechanisme voor.
Filter-based security lost een ander probleem op: situaties waarin toegang structureel moet worden bepaald door eigenschappen van records, en niet door wie eigenaar is of met wie een record gedeeld is.
Filter-based security
Met deze previewfunctie kan je door middel van FetchXML filters maken per tabel. Deze filters kunnen vervolgens in een securityrol gekoppeld worden aan een CRUD-actie.
Deze filters kunnen toegepast worden bovenop het traditionele model met user/team-owned en organization-owned tabellen. Belangrijk hierbij is dat deze filters bovenop de bestaande rechten komen. Een filter geeft dus aanvullende rechten naast de rechten die een gebruiker op deze tabel via een andere route verkrijgt, zoals een securityrol, sharing of een access team.
Het is dus eigenlijk weer een extra laagje in de securitytaart. Je kan hiermee niet afdwingen dat gebruikers alleen records zien die voldoen aan de FetchXML-criteria, omdat ze via andere routes bredere rechten kunnen krijgen.
Filtered ownership
Maar de preview heeft ook hier een veelbelovende oplossing voor: een nieuw ownership-type, Filtered.
Bij een Filtered ownership-tabel bestaat er geen record owner.
Je kunt een record niet assignen zoals bij een user/team-owned tabel en je kunt het ook niet delen.
Recordtoegang wordt volledig bepaald door filterprivileges. En juist dat vind ik interessant voor generieke tabellen.
Hier onder volgt een korte demo.
Een paar belangrijke dingen die mij opvielen tijdens het testen:
In mijn testomgeving werd bij een gebruiker met wel leesrechten, maar zonder bewerkrechten, de validatie van een update pas uitgevoerd bij het opslaan. Dit in tegenstelling tot wat gebruikelijk is bij beveiliging, waarbij een record direct als read-only wordt getoond aan de gebruiker.
In mijn demo wijzigde ik een veld dat onderdeel was van mijn filtercriterium. Door die wijziging voldeed het record niet meer aan het filter en had ik dus geen rechten meer om het record te zien. Ik mocht de wijziging zelf wel uitvoeren, maar kon het record daarna niet meer openen. Overigens kan dit in veel scenario's precies het gedrag zijn dat je wilt.
Ook de foutafhandeling voelde in mijn test nog wat buggy aan wanneer je in Power Apps een actie probeert uit te voeren die niet is toegestaan op basis van je filter-based securityrollen.
Security wordt onderdeel van je datamodel
Misschien is dat voor mij wel de grootste verandering.
Tot nu toe denk ik bij Dataverse-security vooral aan gebruikers, teams, business units, ownership en securityrollen.
Filter-based security voegt daar iets belangrijks aan toe: de inhoud van het record.
Microsoft noemt hierbij onder andere Attribute-Based Access Control, oftewel ABAC.
Je toegang wordt daarmee niet alleen bepaald door wie je bent en welke rol je hebt, maar ook door eigenschappen van het object waartoe je toegang probeert te krijgen.
Dat opent andere mogelijkheden bij het ontwerpen van oplossingen en verandert de manier waarop je over security kunt nadenken binnen Dataverse.
En daarom vind ik het opvallend hoe weinig aandacht deze preview op dit moment krijgt.
Tuurlijk begrijp ik dat dit minder sexy is voor een LinkedIn-post. Maar voor mensen die Dataverse-oplossingen ontwerpen, zou dit op termijn weleens een veel grotere impact kunnen hebben dan “Copilot Record Summaries”.