Rules in SAP GRC technical architecture and access controls help to mitigate corporate risk and create efficiencies. This article examines these GRC rules and details some best practices for key GRC rules.
Rule sets define categories or groupings of rules. A rule set is used for determining the group of access risks that are to be used when running an access risk analysis. Several Rules are combined together in a Ruleset. The Rules are available as Rule ID in a separate table called GRACACTRULE. The Ruleset Information is available in table GRACRULESET.
Picture 2: shows the Ruleset that is stored in table GRACRULESET. Several rules combined together are stored in a Ruleset.
A newly installed GRC system comes with a starter package of Rules bundled in a Ruleset called “GLOBAL”. Note: It is important to activate a BC set to fill the GRACRULESET tables with standard SAP Data.
The purpose of Risk Recognition is to determine and classify risks, and to construct rules that determine the existence of these risks in analyzed objects, such as users, roles, profiles, and so on. Actions and permissions combine to form functions. Functions in certain combinations result in a risk. Risks are associated with business processes and all the components come together to form rules.
Picture 3: shows the relationship between the Ruleset and Rules. Rules are generated by the Risks based on the Risk ID and stored in a table GRACACTRULE.
Rules in GRC can be uploaded using transaction code GRAC_UPLOAD_RULES, generated for the specific Risks using tcode GRAC_GENERATE_RULES, delete rules using tcode GRAC_RULE_DELETE. GRC 10.1 can now allow you to transport rules using tcode: GRAC_RULE_TRANSPORT.
Functions are the building blocks of access risks. They define a collection of one or more tasks that an employee needs to complete to perform a specific goal. These tasks are called Actions. When you define a function, you associate one or more actions to the function. Each of these actions has an associated permission (security object) that defines the scope of access for the action.
Functions – Actions
Functions and Actions are related to each other using the table GRACFUNCACT. This table shows the relationship between the Function ID and the associated Actions (Transaction Codes) including the connectors or the target systems as shown in Picture 4 where the Actions are associated. GRACFUNC is the parent table which holds the Function Information.
Picture 4: shows the relationship between the Functions and Actions.
Functions – Actions – Permissions
Picture 5: shows the relationship between the Functions, Actions and Permissions.
Functions, Actions and Permissions are related using the table GRACFUNCPRM. This table shows the relationship between Functions, the associated Transaction codes or Actions and the Authorization Objects for the tcodes as shown in Picture 5. The connector information is available as well which helps to determine the source of the Transaction codes and Authorization Objects.
Business Process is a key component in the Access Controls Architecture. Risks and Functions are associated with a Business Process for example, Risk ID’s related to Finance are assigned the business process Finance. Functions that are associated to a specific Risk is associated to a specific business Process. This relationship between the Functions and Business Process is stored in a table called GRACBPROC. The other tables where the risks and functions have the Business Process information are GRACFUNC and GRACSODRISK.
Picture 6: shows the relationship between the Functions and Business Process.
Risk Owners are stored in table GRACOWNER. Every Risk ID is associated with an owner which indicates the responsibility or the ownership of the Risk’s in the system.
Picture 7: shows the relationship between the Functions, Actions and Permissions.
There are several Owners that can be assigned to users in GRC system Picture 8 shows the list and Picture 7 shows the table information.
The following Picture shows the list of Owners in the GRC system.
To learn more, read Part I of our GRC Technical Architecture blog series.