Show TOC

BI Content for SAP GRC Access Control

Technical Data

Product Version

5.3

Area

Access Control Compliant User Provisioning (AE); Access Control Compliance Calibrator (CC)

Country Relevance

Valid for all countries

 

As of SAP NetWeaver 7.0 BI Content Add-On 3 SP09, new business content is available for the Access Control function. Listed first, below, is the BI Content for the area Access Control Compliant User Provisioning (AE).

Listed secondly, below, is the BI Content for the area Access Control Compliance Calibrator (CC)

Access Control Compliant User Provisioning (AE)

The following new objects exist. InfoArea:

SAP GRC Compliant User Provisioning (AE) (0GRC_AE)

GRC AE MASTER DATA (0GAE_MD)

Role:

General Role for the AE BI Cont. SAP_BW_GRC_AE_ROLE

Queries:

GRC AE : Access Requests 0GAE_MP02_Q0001

GRC AE: Service Levels 0GAE_MP02_Q0002

GRC AE: User Provisioning 0GAE_MP02_Q0003

GRC AE: Role Provisioning 0GAE_MP02_Q0004 GRC AE: Risk Violations 0GAE_MP02_Q0005

GRC AE: SOD Review 0GAE_MP02_Q0006

GRC AE: User Access Review 0GAE_MP02_Q0007

InfoCubes:

Request Header 0GAE_C01

Risk Violations 0GAE_C02 Role Provisioning 0GAE_C06

User Provisioning 0GAE_C07

Archived data not available in Source system 0GAE_C08

MultiProviders:

General Reporting MP 0GAE_MP01

AE Reporting - Cube based common query layer 0GAE_MP02

Process Chains:

GRC AE: Master Data Attributes 0GAE_MD

GRC AE: Master Data Text 0GAE_TEXT

GRC AE: Transaction (incl. long texts) Init/Full 0GAE_TRANSACTION

GRC AE: Archived (from Source System) Transaction Full 0GAE_TRANSACTION_AR

GRC AE: Analytical layer General process chain 0GAE_ANALYTICAL_GENERAL

GRC AE: Load of Archived REQ to be unavailable in Source Sys. 0GAE_ARCH_TO_CUBE

DataStore Objects:

Application Log 0GAE_APLG

Business Process Locale 0GAE_BUPL

Business Sub Process Locale 0GAE_BSPL

Company Locale 0GAE_COML

Connector Locale 0GAE_CNTL

Custom Field 0GAE_CMFD

Custom Field Locale 0GAE_CMFL

Custom Field Value 0GAE_CTVL

Custom Field Value Locale 0GAE_CFVL

Employee Locale 0GAE_EMPL

Employee Type 0GAE_EMTP

Function Area Locale 0GAE_FNAL

Message 0GAE_MSG

Message Parameters 0GAE_MSGP

Request Application 0GAE_APL

Request Attachmen 0GAE_ATCH

Request Attachment Archive 0GAE_ARAT

Request Custom Fields 0GAE_CSFL

Request Header 0GAE_HDR

Request Header I: 0GAE_HDR1

Request History 0GAE_HST

Request HistoryArchive0GAE_ARHS

Request Mitigation 0GAE_MTGN

Request Organizational Role 0GAE_ORGR

Request PD Profile Role 0GAE_PDRL

Request Review Coordinator 0GAE_RVCR

Request Role Profile 0GAE_RLPR

Request Segregation of Duties Custom Field 0GAE_SODC

Request Segregation of Duties Function 0GAE_SODF

Request Segregation of Duties Risk 0GAE_SODR

Request Type Locale 0GAE_TYPL

Request User Access Review 0GAE_UARW

Request Users 0GAE_USER

Request Work Flow Transactions 0GAE_WTRN

Request Workflow History 0GAE_WHST

Role Approver 0GAE_RLAP

Role Details 0GAE_RLDT

Role Details Locale 0GAE_RDTL

Role Provisioning 0GAE_D02

User Access Review Role 0GAE_UARO

User Access Review Role W0 0GAE_UAR

User Provisioning Overview 0GAE_D01

User Sequence 0GAE_USSQ

Master Data Attribute and Text:

Business Process 0GAE_BUSPRC

Business Sub Process 0GAE_BUSUPR

Role Profile Name 0GAE_RLPRLN

Role Type 0GAE_RLTYP

System 0GAE_SYSTEM

Master Data Attribute:

Request Number 0GAE_REQNO

Request Priority 0GAE_RQPRIY

KeyFigures:

Counter 0GAE_COUNT

Extra Counter 1 0GAE_COUNT1

Extra Counter 2 0GAE_COUNT2

Role Usage 0GAE_RLUSGE

Usage Count 0GAE_USGCNT

Violation Count 0GAE_VIOCNT

Characteristics:

373 Characteristics are currently available.

Access Control Compliance Calibrator (CC)

The SAP Business Information Warehouse-Compliance Calibrator (BI-CC) Business Content 7.03 SP 09 for SAP GRC AC Compliance Calibrator (CC) 5.3 provides DataSources, InfoProviders, necessary transformations, required pseudo delta functionality, history storage, long descriptions, supporting master data, process chains and some representative queries for the following primary areas of CC:

  • Permission Violations (User, Role, Profile)

  • Management Reporting (Summary Total, Business Process, Risk, Risk Detail and Alerts)

  • Mitigations (User, User Organization Rule, Role, Profile and HR Object)

  • Alerts (Header and Detail)

  • Critical Violations (Action, Role and Profile)

  • Rules (Critical Role, Critical Profile, Function-Permission, Risk-Function, Risk-Owner, Risk-Permission, Risk-Rule Set, Supplementary)

Extraction technology is based on UD Connect in order to provide straightforward, database independent extracts from a J2EE source system such as CC.

Below are descriptions and explanations for some of these areas:

Permission Violations Delta Processing:

Permission Violations are categorized by User, Role and Profile Permission Violations. Since the volume of data for these sources can be extremely large and they are not generally combined in reports, they are stored in separate InfoProviders in BI BC. Separate InfoProviders for current and historical data have been provided due to data volume, InfoProvider maintenance and delta processing. Configuration for supplying the historical data from the history DSO to the history cube has not been provided but the customer may choose to implement this if they plan to perform involved analysis on the historical data. MultiCubes have not been delivered with BI BC but customers may choose to create them for reporting on current and historical data concurrently.

Permission Violations data comes from table VIRSA_CC_PRMVL provided via DataSources 0GCC_PRMVL_USER_VIOLS, 0GCC_PRMVL_ROLE_VIOLS and 0GCC_PRMVL_PROF_VIOLS filtered in InfoPackages by GENOBJTP = 1, 2 or 3, respectively. Full extract InfoPackages are delivered to provide the initial load of this data. After the initial full loads, the recurring pseudo delta procedure (described below) should be performed.

Due to the volume of violations data and the need for storing historical changes, a delta capability is provided. However, neither a delta queue nor reverse postings are provided by the source system. And due to the limited flexibility of data selection when using UD Connect, a pseudo delta procedure is required.

The Permission Violations delta procedure is driven by the RUNDATE field in source system tables VIRSA_CC_PRMVL and VIRSA_CC_GENOBJ. VIRSA_CC_GENOBJ is a change log table representing changed users, roles and profiles (including permissions changes) with a date stamp. In the example of User Permission Violations processing, after the initial full extract the delta InfoPackage ABAP Routine selection criteria will select records from VIRSA_CC_PRMVL which have been changed since the previous successful BI extract using the RUNDATE value. In CC, if the permissions for a user have changed, all of their violations records will be deleted and replaced with the new values and all records will contain the new Run Date.

Therefore, BI needs to extract all of these records and replace the existing current violations in the DSO and InfoCube with these new values. The extract dates are stored in table GRCCC_EXTRACTS and managed by programs RS_BCT_GRC_CC_ADD_EXTR_DATE and RS_BCT_GRC_CC_ACT_EXTR_DATE as executed in the process chains. The extract date recorded in this table and used for the InfoPackage selection range is the current date minus one. This will help to prevent missing newly added records in the system (although it is highly recommended that extracts occur when the CC system is quiet).

Prior to loading the new values, the current records in BI for the changed users need to be extracted from the current DSO and loaded into the History DSO. This is done by executing an InfoPackage against the User/Role/Profile Change Log DSO filtered by 0GCC_OBJTYP = ‘1’ (for the User example). These values are then used by the start routine for the History DSO to pull in the violation records associated with these users from the Current DSO. This will create a history of the permission violation changes by user by run date.

Additionally, prior to loading the newly extracted source system records via the DTP, the previous values for the changed users need to be deleted from the current DSO and InfoCube. In order to do this, the programs ‘RS_BCT_GRC_CC_DEL_DSO_DATA’ and ‘RS_BCT_GRC_CC_DEL_CUBE_DATA’ are used. These programs use as input the values of changed users from the User/Role/Profile Change Log DSO to delete the associated records from the current User Permission Violations DSO and InfoCube. Then the DTP can be executed to load the new user permission violation values for the changed users to either replace the previous violation values or to add a new user’s violations.

Aggregates are not provided with the delivered InfoCubes since they should be built on the specific needs of the customer based on their reporting requirements. Note, however, that the use of aggregates will cause the selective deletion program mentioned above to run significantly longer as the aggregates will be recalculated. So the tradeoff will be quicker extracts via the pseudo delta versus longer loads in providing faster query results using aggregates.

Management Reporting:

There are two types of tables in CC for Management Reporting. One type of table keeps the history as changes occur by refreshing only the current month. The other type of table is fully refreshed each time CC processes Management Reporting. The Management Report – Summary Total extract performs a complete refresh of this DSO in order to enable the monthly delta of the other Management Report areas. For the extracts from tables where the history is maintained in CC, an InfoPackage selection criteria extracts on records based on the YEARMONTH belonging to the latest month processed for Management Reporting based on the highest 0CALMONTH value in the Summary Total DSO. For the Risk Detail extract (which is based on a table which is fully refreshed in CC) a start routine is used to determine the 0CALMONTH which will be recorded in the DSO based on the latest 0CALMONTH value in the Summary Total DSO (since the date is not recorded in the CC table for Risk Detail or Critical Action).

Mitigations:

No historical tracking is recorded in BI for mitigations. InfoCubes with full refreshes are used to store the information.

Alert Header and Detail Data:

The table in CC storing the Alert Header data is an ongoing file that will be extracted in delta mode from BI using an InfoPackage selection criteria based on records with RUNDATE since the latest BI extract date. This information will be stored in a current InfoCube but additionally, an Alert Header DSO is used support the pseudo delta procedure described in the next paragraph.

The Alert Detail table is extracted in a pseudo delta mode by using a start routine that eliminates any incoming records which are not part of the most recently extracted header records. This is performed by looking up these values as recorded in the Alert Header DSO.

Critical Violations:

No historical tracking is recorded in CC or BI for critical violations. InfoCubes with full refreshes are used to store the information.

Rules Delta Processing:

Full extracts and DSO refreshes are performed in order to maintain an accurate snapshot of the current rules and relationship data. Additionally, the history of changes to these rules and relationships is stored in historical DSOs by using the Risk-Function Change Log DSO and a start routine which filters out all of the records from the incoming full extract that are not in the change log DSO. The history of changes is maintained for the following Rules DSOs: Risk-Rule Set, Risk-Owner, Risk-Function and Function-Permission. All other Rules will only have the current values refreshed in the Current DSO via a full extract.

Long Descriptions:

Many descriptive fields in CC contain more than 60 characters. This causes a problem in BI since the maximum length of any object is 60 characters. And since most of these descriptive fields in CC are language dependent, the following method was designed to store and report on these long descriptions.

InfoObjects containing source fields with language dependent descriptions from CC have a DSO created for storing this information. The key to the DSO is the InfoObject and the Language value. The long descriptive fields are extracted from CC and broken up into 60 character pieces and stored in separate InfoObjects within these DSOs for each language that is maintained. If, for example, the user wants to report on the Risk long descriptions while performing Role Permission Violations analysis, an InfoSet needs to be set up between the Role Permission Violations InfoCube and the Risk Long Description DSO. Then, when a user is reporting on the Role Permission Violations InfoCube, a jump-to can be executed to run a query off the InfoSet based on the selection criteria from the Role Permission Violation query and the user supplied language key showing the language dependent long descriptions of the risks.

Business Content Activation:

Business Content activation may be done in several standard ways of the installer’s choice but one method is to gather all of the InfoCubes and DSOs that start with ‘0GCC*’ and selecting ‘Collect Automatically’ and ‘In Dataflow Before and Afterwards’ while choosing the proper UD Connect Source System and the Myself Source System. There are two things to be aware of:

  1. Be sure to deselect any DataSources, Transfer Rules, etc associated with delivered BI-HR InfoObjects such as 0EMPLOYEE, 0COUNTRY, 0COMP_CODE, etc. These InfoObjects are included in the BI-CC model in order to provide reporting by these user attributes but their associated source system related objects (if desired) should to be activated from the proper R/3 source system in a separate BC activation step.

  2. Prior to activating DSO 0GCC_URP you may first need to activate the 3.x Export DataSource 80GCC_URP using ‘In Dataflow Before and Afterwards’ and choosing the Myself Source System. This will activate the DataSource as well as the associated Communication Structure, Transfer Structure and Transfer Rules. Then you can activate the 0GCC_URP DSO using ‘In Dataflow Before and Afterwards’.

Process Chains:

There are two strings of data loading which are necessary to make your CC reporting operational in BI. First, the initial full load of the Permission Violations and Management data needs to be processed. This is initiated by the Process Chain ‘GRC CC (Risk Analysis & Remed) Perm Viols/Mgmt Initial Load’ which in turn will call ‘GRC CC (Risk Analysis and Remediation) Initial Master Data’ and ‘GRC CC (Risk Analysis and Remediation) Mgmt Rpts Initial Extr’. The loading of the Permission Violations data could take a very long time using UD Connect, perhaps up to several days.

The initial full load of the CC data is not intended to set the customer up for reporting but simply to accomplish the potentially enormous Permissions Violations full load and to initialize the Management Reporting extracts. The strategy is to immediately follow up the initial, one time full load with the recurring extract ‘GRC CC (Risk Analysis and Remediation) Start Recurring Extr’. This will fully populate all supporting data as well as the other areas of reporting such as Critical Violations, Rules, Alerts, Mitigations, etc as well as the delta loads for the Permission Violations and Management Reporting.

Customers may choose to create their own process chains but the supplied steps are necessary for accurate delta processing and for enabling master data attribute lookups. Extracts are designed to be run while the CC system is quiet since delta queues are not provided. Otherwise, inconsistent data in BI can occur.