Which are the tables of the SAP GRC Access Control product useful to know (out of the existing 2500)?

How could they be useful in your daily activities? When instead shouldn't they be used?

SAP GRC Access Control

Did you forget what this tool is used for? Read here.

Access Risk Analysis (ARA)

In this SAP GRC Access Control module, the rule matrix (ruleset) is the most important part:

• GRACFUNC - Function
• GRACFUNCT - Function Description Translations
• GRACFUNCACT - Function Action Relationship
• GRACFUNCPRM - Function Action Permission relationship
• Where ACTIVE = X means that the row is active

• GRACSODRISKFUNC - SOD Risk Function Relationship
• GRACRULESET - Rule Set
• GRACRULESETT - Rule Set Description
• GRACORGRULE - Organization Rules
• GRACACTRULE - SOD Action Rule Detail
• GRACSODRISKT - SOD Risk Description
• GRACSODRISK - SOD Risk
• RISKTYPE = 1: SOD, 2: Critical Action, 3: Critical Permission

• GRACSODRISKOWN - SOD Risk Owner
• GRACMITROLE - Role mitigating control assignment
• GRACMITUSER - User mitigating control assignment
• GRACCRPROFILE - Critical Profile Rule
• GRACCRROLE - Critical Role Rule
• GRACBPROC - Business Process
• GRACBPROT - Business Process Description
• GRACMGRISKD - Risk Analysis Mgmt Sum data for Batch Risk Analysis.
• HRP5320 - Defined mitigation controls
• HRT5320 - Defined mitigation controls
• GRACUSERPRMVL - User Permission Violation Table

Emergency Access Management (EAM)

In this SAP GRC Access Control module, the management of the super users or super roles is the most important part:

• GRACFFLOG - Details related to Firefighter ID Log On Information
• GRACFFREPMAPP - FFLOG and Repository Mapping for Firefighters
• GRACACTUSAGE - Action Usage
• GRACAUDITLOG - Security Audit Log table
• GRACSYSTEMLOG - System Security Log table
• GRACCHANGELOG - Data Change Log table
• GRACREASONCOD - Master table for Reason Codes
• GRACREASONSYS - Reason Code and System assignments
• GRACFFCTRL - Maintain assignment of FF ID or Role to Controllers
• GRACFFOBJECT - Maintain SPM Firefighter ID and Role details
• GRACFFUSER - Maintain SPM Firefighter Assignment to FF ID/Roles

Business Role Management (BRM)

In this SAP GRC Access Control module, the roles management is the most relevant part:

• GRACROLE - Role
• GRACROLEAPPRVR - Role Approver
• GRACROLESTATUS - Role Status Table
• GRACROLETYPE - Role Type Table
• GRACMTH - GRC Methodology
• GRACMTHT - GRC ERM Methodology Text

Access Request Management (ARQ)

It is a component to manage the operational workflows inside the Access Control suite. This part is managed through the usage of Business Rule Framework BRF+ and of the work framework called MSMP - Multi Stage Multi Path.

• GRACREQ - Request Header
• GRACREQPROVITEM - Line Items Associated with Request
• GRACREQUSER - User Associated with Request
• GRACEUPCONFIG - End User Personalization Fields
• GRFNMWCNPATH - MSMP Path
• GRFNMWCNROUTE - MSMP Route Mapping
• GRFNMWCNSDEF - MSMP Stage Definition
• GRFNMWRTAPPR - Current approver of Access Request (GRFNMWRTSTAPPR  only during runtime)
• SWWUSERWI - Task ID assigned to users
• HRUS_D2 - Delegation table

GRC Access Control Foundation

Some tables are shared between different modules, like the following:

• GRACCONFIG - Configuration Parameter Table

• GRACOWNER - Master table for Central Owner Administration
• GRACTASKEXECSTMP - Executed background jobs Table, here you can find the last date of execution of the synchronization jobs
• GRPCPHIO - GRC: Instances of Physical Information Objects, here you can find the information about the attachments to the requests

When is it useful to use and when they aren't?

In my opinion it's useful to use and know the tables for activities like troubleshooting and uploaded data.

It makes sense to create alternative reports to the standard ones? It depends. It could be useful as a control activity of the GRC configuration or to anticipate potential problems like:

• Usage of roles without approvers in approval-based workflows
• Problems in the SoD Matric (ruleset) read here for more information on the sod matrix
• To verify the EAM configuration for the management of the super users

Basing further processes on data extractions from the tables directly inside the GRC system is probably non the best solution. It's not possible to immediately guarantee, in case of update or modifications of the system, the original result of the extractions.

What do I mean with that?

If I create an approval process outside of the GRC system but it's based on the information inside the system, these last ones in the phases of upgrade or modifications to the GRC system logics could change. Therefore, the initial requisite of the approval process could fail.

Blog post originally translated from: https://www.aglea.com/blog/sap-grc-access-control-tables