Hoe SoD-regels een role daadwerkelijk toetsen
Het beveiligingsmodel van F&O is een hiërarchie: roles bevatten duties, duties bevatten privileges, privileges bevatten permissions. Segregation of Duties regels worden gedeclareerd tussen twee duties. Wanneer het systeem een roltoewijzing controleert op conflicten, vergelijkt het de namen van de duties die aan die role zijn gekoppeld met de rules tabel.
Microsoft's eigen documentatie over role-based security bevestigt dit mechanisme rechtstreeks: "Although you can assign privileges directly to roles, assign only duties to roles." Dat "although" doet in die zin echt werk: het systeem staat het toe, ook al is het niet de aanbevolen route.
Waarom de shortcut onzichtbaar is voor de rules engine
Wanneer een privilege rechtstreeks op een role staat, zonder een omhullende duty, is er geen duty-naam waaraan een SoD regel kan toetsen. De toegang is reëel. Een gebruiker met die role kan het privilege direct gebruiken. Maar de regel die bedoeld was om "dit privilege in combinatie met dat andere privilege" te signaleren, heeft niets om te evalueren, omdat de regel in termen van duties is geschreven, en dit privilege nooit als onderdeel van een duty is toegewezen.
Vermenigvuldig dit over een handvol shortcuts rond een livegang, consultant toegangsverzoeken, en "tijdelijke" oplossingen die het project overleven, en een omgeving kan een aanzienlijke hoeveelheid toegang opbouwen die het eigen SoD-programma nooit heeft kunnen zien.
Waarom dit zo blijft bestaan
De SoD rules pagina blijft gewoon elke geconfigureerde regel als voldaan tonen. Niets aan deze toegang verschijnt als overtreding, want er is nooit iets van geëvalueerd als zodanig. Een beheerder die de rules pagina bekijkt, heeft geen enkele reden om te vermoeden dat er iets mis is. Het gat is geen falen van de regel, het is een categorie toegang die de regel nooit is gebouwd om te controleren.
Wat dit wél opvangt
Privilege separation validation, een apart en minder gebruikt mechanisme onder de security tasks van de process hierarchy in F&O, analyseert privileges die rechtstreeks aan een role zijn toegewezen, in plaats van duty-namen, precies de laag waarop deze shortcut opereert. Weinig organisaties hebben dit geconfigureerd, omdat het niet dezelfde pagina is als de standaard SoD rules en er ook niet naast wordt gepromoot.
Hoe 2-Control dit soort toegang opspoort
Bij een Beoordelen Autorisaties traject richten wij ons expliciet op dit type gat: privileges die buiten een duty om, rechtstreeks aan een role gekoppeld zijn, en daardoor buiten het bereik van de standaard SoD-regels vallen. Onze consultants analyseren roles, duties en privileges op dit granulaire niveau, zodat u niet alleen weet of uw rules pagina op groen staat, maar ook of daadwerkelijk elke relevante toegangscombinatie is meegenomen. Staat u nog aan het begin van het inrichten van Segregation of Duties, dan bouwen wij dit al vanaf de eerste opzet correct in; zie ons artikel "Functiescheiding instellen in Dynamics 365 F&O" voor die aanpak.
Heeft een consultant tijdens uw laatste livegang een privilege rechtstreeks aan een role toegevoegd? Zou uw huidige SoD-opzet dat hebben opgemerkt? Neem contact met ons op om te laten beoordelen wat er daadwerkelijk in uw roles staat.
