In een eerdere blog beschreef ik een oplossing voor het gebruik van Value Level Security (VLS) waarbij gebruikers lid kunnen zijn van meerdere rollen. (Het algemene concept van VLS wordt beschreven in ons boek Extreme DAX.) Het probleem met lidmaatschap van meerdere rollen is dat gebruikers toegang kunnen hebben tot zowel de positieve rijen (die […]
In een eerdere blog beschreef ik een oplossing voor het gebruik van Value Level Security (VLS) waarbij gebruikers lid kunnen zijn van meerdere rollen. (Het algemene concept van VLS wordt beschreven in ons boek Extreme DAX.) Het probleem met lidmaatschap van meerdere rollen is dat gebruikers toegang kunnen hebben tot zowel de positieve rijen (die privégegevens bevatten) als de negatieve rijen (die privégegevens verbergen) in de privétabel. . Houd er rekening mee dat dit geen beveiligingsprobleem is: de gebruiker heeft geen toegang tot gegevens die zij niet zou mogen zien; in plaats daarvan krijgen we een duplicaat van labels en resultaten in het Power BI-rapport.
De oplossing in mijn eerdere bericht lost dit probleem op wanneer de visual resultaten toont op het niveau van individuele rijen in de (privé) tabel door een filter op visueel niveau toe te voegen. Als de visual echter geaggregeerde resultaten bevat, wat gebeurt als we alleen een privékenmerk als label in de visual gebruiken, werkt een filter niet. In onderstaand voorbeeld ziet u een tabel, gebaseerd op hetzelfde voorbeeld uit het vorige bericht, met salariskosten volgens het privéattribuut ‘loonniveau’:
Op het eerste gezicht klopt er niets in deze tabel: we hebben salariskosten voor (werknemers met specifieke) loonniveaus, en we hebben salariskosten voor niet-gespecificeerde loonniveaus. Het probleem hier is dat het bedrag voor de lege loonniveaurij niet correct is! Om dit te verduidelijken heb ik de naam van de werknemer aan de tabel toegevoegd en gefilterd op Ambrocio Baker:
Zoals u kunt zien heeft Ambrocio iets meer dan 54.000 aan salariskosten, en dit bedrag wordt zowel onder het blanco loonniveau als onder loonniveau 29 gerapporteerd.
Met een filter op visueel niveau kunnen we alleen de lege rij met loonniveaus als geheel verbergen. Dit is uiteraard niet wat wij willen. De enige oplossing is daarom om de DAX-code voor de SalaryCosts-maatstaf te wijzigen, zodat alleen resultaten worden geretourneerd voor werknemers van wie we geen toegang hebben tot privégegevens.
Gelukkig is de DAX-code voor deze meting niet zo moeilijk, omdat we al een [ShowPrivate]-meting hebben die we hebben gebruikt voor het filter op visueel niveau. Wat we moeten doen, is deze maatregel per werknemer evalueren:
Salary Costs (secured) =
SUMX(
FILTER(DISTINCT(‘Employee (private)'[EmpNr]), [ShowPrivate] = 1),
[SalaryCosts]
)
Het resultaat voor Ambrocio is nu:
De meting levert correct geen resultaat op voor Ambrocio en het blanco loonniveau, omdat het resultaat al wordt geretourneerd voor loonniveau 29. De totaaltabel ziet er nu als volgt uit:
Conclusie
Het ontwerpdoel voor Value Level Security is om een oplossing te hebben die echt veilig is, en zonder tot minimale wijzigingen aan bestaande DAX-maatregelen. De conclusie die we kunnen trekken uit het algemene concept zoals beschreven in Extreme DAX en deze twee blogposts is:
