Achter de schermen bij SAP GRC Access Control

Bij het horen van SAP GRC Access Control denken we al gauw aan een tool voor SoD analyse (Segregation of Duties oftewel functiescheiding), toegang en gebruikers management, firefighter en misschien rollenbeheer. Ook wel bekend als Access Risk Analysis (ARA), Access Request Management (ARM), Emergency Access Management (EAM) en Business Role Management (BRM). Dit zijn immers de belangrijkste modules van GRC Access Control en bieden organisaties de benodigde handvatten om beter in control te zijn als het gaat over hun access management processen.

Echter, minstens zo belangrijk of misschien wel belangrijker is de organisatie van Business & IT en de daarbij behorende procesinrichting die de GRC Access Control tool gebruiken. Daar komt namelijk best veel bij kijken en een GRC Access Control implementatie is pas écht waardevol als het ook breed in de organisatie gedragen en toegepast wordt. 

In dit blog gaan we 3 van de 4 veel voorkomende modules van SAP GRC Access Control toelichten namelijk: ARA, ARM en EAM. BRM laten we voor nu even buitenbeschouwing. Hierin beschrijven we de functionaliteit in het kort met daarbij een voorbeeld van het proces en bijbehorende organisatie.

GRC ARA - Access Risk Analysis

ARA kun je ook wel het brein van GRC Access Controls noemen. Het gaat om de functionaliteit om SoD analyses en simulaties te draaien op rol of op gebruiker niveau. Een Risk manager is verantwoordelijk voor de SoD risico’s en kan tevens eigenaar zijn van de GRC rule-set (verzameling van toetsnormen waar SoD’s mee gecheckt kunnen worden).

Afhankelijk van de business organisatie bestaat het risk management team uit één of meerdere specialisten dat elk een onderdeel van de SoD rapportage uitvoert of voortborduurt op de algemene management analyse van de risk manager. Deze risico’s - SoD conflicten of kritische toegangsconflicten - die uit de analyse komen kunnen verdeeld worden per proces waarbij de business risico’s van bijvoorbeeld Purchase-to-Pay door een verantwoordelijke proceseigenaar overlegd worden. In dit overleg zie je dat een autorisatieconsultant aanschuift die helpt met de analyse, interpreteert en meedenkt in mogelijkheden voor de oplossing en opschoning van SoD conflicten.

De organisatie achter de schermen in bovenstaand voorbeeld van GRC ARA:

• Risk Manager
• Rule-set eigenaar
• Proceseigenaren
• Autorisatie / GRC consultant

GRC ARM - Access Request Management

ARM is de functionaliteit waarmee het goedkeuringsproces vanaf toegang aanvraag tot aan de toekenning aan de gebruiker wordt gefaciliteerd. Dit proces is geïntegreerd met de ARA functionaliteit om het toegangsverzoek op voorhand al op SoD’s te controleren voordat men goedkeurt. Deze goedkeuringsstappen is in te richten met de MSMP Workflow functionaliteit van SAP.

Het is geheel afhankelijk per organisatie hoe het goedkeuringsproces van toegang verloopt, maar ook hierin is een combinatie van Business & IT terug te vinden. Het aanvraagproces begint in ieder geval met een gebruikersverzoek tot toegang voor een bepaald systeem. Dit kan zijn voor een nieuwe gebruiker of een reeds bestaande. De eerste vraag hierbij is; Hoe wil je de aanvraag tot toegang initiëren? Deze vraag is erg belangrijk maar zal per organisatie verschillend ingevuld worden door organisatie specifieke security policies, security volwassenheid en autorisatielandschappen.

Een voorbeeld van een dergelijk aanvraagproces is dat een verzoek voor toegang eerst wordt gevalideerd door een autorisatie key-user. Deze voert als het ware een pre-validatie check uit voordat er überhaupt iets gebeurd in GRC. Zodra deze pre-check is voldaan, kan het toegangsverzoek aangelegd worden in GRC. Vanaf hier begint het ARM proces, en is de eerste vraag; Wie gaat het toegangsverzoek aanmaken op GRC? Na de aanleg volgt de vraag; Wie moet het verzoek goedkeuren?

Deze zogenaamde workflows kun je als organisatie zo uitgebreid mogelijk en willekeurig inrichten. De SAP standaard workflow heeft zogenaamde ‘stages’ met de manager stage, roleigenaar stage en security (SoD) stage die je naar willekeurige volgorde kunt inrichten en op basis van ‘rules’ logisch kunt sturen.

De manager is de goedkeuring als leidinggevende van de aanvrager in de lijnorganisatie –hoort de aanvrager dit te kunnen doen voor het vervullen van zijn of haar functie?

De roleigenaar is de goedkeuring vanuit de procesketen gezien – wijkt het toegangsverzoek af van het bestaande algehele proces dat gevolgd moet worden?

De security stage is de goedkeuring vanuit de risico gedachte – veroorzaakt deze toegang risico’s en SoD conflicten / wat is er noodzakelijk en wat zijn de minst risicovolle alternatieven?

De organisatie achter de schermen in bovenstaand voorbeeld van GRC ARM:

• Gebruiker
• Autorisatie key-user
• Manager
• Rol / proceseigenaar
• Security: risk manager en autorisatie / GRC consultant

GRC EAM – Emergency Access Management

EAM of ook wel Firefighter genoemd is de functionaliteit om bij calamiteiten SAP brede noodtoegang te kunnen verlenen op een gecontroleerde wijze. EAM kan op twee manieren gebruikt worden; gecentraliseerd (vanuit GRC) of gedecentraliseerd (op het doelsysteem zelf).

EAM is het meest eenduidig als het gaat om de organisatorische inrichting. Binnen deze module bestaat de organisatie uit een aantal randvoorwaarden:  Firefighter ID,  Firefighter eigenaren, Firefighter Controllers en de Firefighter gebruikers.

Normaliter worden Firefighter ID’s met brede noodtoegang eenmalig aangelegd voor gebruik bij calamiteiten. Dit zijn meestal service accounts die hele brede rechten hebben. Elk van deze Firefighter ID heeft een eigenaar. De eigenaar van de Firefighter ID beoordeelt of de calamiteiten het gebruik van de Firefighter rechtvaardigen en de Firefighter ID aan desbetreffende gebruiker toekennen.  De FF ID eigenaren doen ook het toekennen van de Controllers die de uitgevoerde Firefighter activiteiten monitoren en controleren. Tenslotte heb je de gebruikers van de Firefighter die dus de calamiteiten verhelpen.

 De organisatie achter de schermen in bovenstaand voorbeeld van GRC EAM:

• Firefighter ID
• Eigenaar van Firefighter ID
• Controller
• Gebruiker van de Firefighter ID

De kern van het verhaal is hoe belangrijk IT & Business met elkaar verbonden zijn in de organisatie van GRC Access control. Het is daarom van belang dat de organisatie altijd en zo vroeg mogelijk meegenomen wordt bij de implementatie of uitbreiding van GRC Access Control functionaliteit. De verandering in processen en het inzichtelijk worden van verantwoordelijkheden binnen de organisatie vraagt namelijk om een duidelijke GRC Access Control visie en voldoende aandacht, kennis en training.