Within SAP®’s portfolio of solutions for access and identity control, since 2018, there exists a solution named SAP IAG (Identity Access Governance). This solution, similarly to GRC AC, allows for centralized access management for clients in their SAP environments. However, one of the main innovations of this recent tool is that it is natively connectable to SAP On-Premise systems (just like GRC AC), but also to SAP’s public cloud systems, such as Ariba, Fieldglass, S/4 HANA Cloud; among others; whereas GRC AC does not (only, as an exception, SFEC).
Focusing now on SAP IAG, we can also draw certain equivalences between the modules of GRC AC, and the (now services) of SAP IAG. Below, a graph shows the main functionalities of SAP IAG:
In this article, we will only explain in detail the Access Analysis service, whose purpose is to monitor the access risks present in the users in the monitored systems, in the same way as the mitigation and/or remediation of these risks.
The first thing to understand is that SAP IAG is a product that exists within SAP BTP (Business Technology Platform). Therefore, clients who wish to have SAP IAG, must have access to this platform.
Moreover, SAP IAG currently has 2 contracting models:
- As the sole access control tool (i.e., without GRC AC).
- As an extension of SAP GRC AC for Cloud environments.
In this article, we will only address the first point, assuming that SAP IAG is the sole tool designated for access control. Additionally, we will monitor access control in an On-Premise system (SAP S/4 HANA).
Before this, it is necessary to understand that SAP IAG, is a product that exists in the public cloud of SAP, and thus is not within the internal network of clients.
To facilitate this task, clients are provided with the software Cloud Connector which allows exposing those function modules that will be used by IAG (in this case) to carry out the risk analyses.
Once the software is installed and configured, the next step is to create the connection in SAP BTP, which will then be used by SAP IAG. This is, in a manner similar to what would be done in SAP GRC AC, creating an RFC connection.
Once this step is completed, you can begin the specific configuration of the application within the SAP IAG tool itself.
Configuration AAS
Application Creation
Thus, the first step would be the creation in IAG of the application to be monitored. For this, you can access the path:
Administration Applications
You must choose the type of system (as previously mentioned, it will be an S/4 HANA On-Premise, in this case), and cover the HCP Destination, which must match the connector created in BTP previously.
Creation of Business Function Groups
Another configuration option is the creation of Business Function Groups:
Administration Business Function Groups
In a similar manner to SAP GRC AC with the connector groups, it allows creating system groups to cluster the different natures of risks by application. In this case, such a group would be created, and associated with the necessary application:
Risk Levels and Business Processes
It is also possible to create own risk levels, and own business processes in the options:
Administration Risk Level
Administration Business Processes
Parameters
Also, as in GRC AC (although to a considerably lesser extent) there are certain parameters of configuration that allow adapting the operation of risk analysis to the needs of each client. This option can be accessed through the path:
Administration Application Parameters
For more information about these parameters, the OSS Note can be consulted: 3278498 – IAG – Optimization of Access Analysis job – SAP for Me
Once these steps are completed, all the necessary IAG configuration would be ready to begin performing risk analyses.
Risk Matrix
To be able to have a risk matrix, it is important to understand that in SAP IAG we do not have BC Sets as happens in SAP GRC AC (SCPR20) where the client can activate the risk matrix for themselves. In the case of IAG; it is necessary to contact SAP so that they can register the risk matrix in the IAG system of the client. In the following OSS Note, the details are explained: 2782388 – IAG – How to load default standard ruleset?
However, a client may also equally edit or create their own risk matrix from scratch. Below are the existing alternatives:
Administration Rule Setup
Here, you can first download the rules and adjust them to the specific needs of each client, by connector group or directly all, to then load them again.
It is important to understand that, once these rules are loaded, the upload file must have a predefined structure.
Below, the correct setup is shown where the upload file does not have nested subfolders
And below, an incorrect way:
Execution of Risk Analysis
At this point, the next step, as also happens in SAP GRC AC, is to perform the synchronization of users, roles, and profiles in SAP IAG. This can be done from the option:
Administration Job Scheduler
You select the type of program (Repository Sync), the type of system (S/4 HANA On-Prem) and the application to synchronize.
From the option:
Administration Job History List
You can consult the result of the scheduled job, marked as “Completed” if it finished successfully
Finally, only launching the risk analysis, remains to be done in order to know the risks present in the users in the desired system. Just like the job of synchronizing users, roles, and profiles, this is done from the option:
Administration Job Scheduler
Although in this case, the type of program to be launched will be Access Analysis
And will appear as completed if it finished successfully.
Risk Analysis Results
Thus, it will now be possible to consult the risks present in the users, and proceed with the mitigation and/or remediation of these. For this, reports are available in the Access Analysis section.
In this case, we can see what risks are present in which users, and through which permissions (roles, groups, etc.).
As for the remediation, one of the advantages of IAG is that it proposes a simple framework for carrying out such remediation actions. Traditionally, one of the main remediation actions is to eliminate the risks present in users who have not been used for a certain period of time. IAG already incorporates this logic, and proposes to IAG users the elimination of such accesses, as well as other series of conditions to facilitate remediation:
In case the risk cannot be remedied, it is also possible to mitigate the risk through mitigating controls created in the option:
Administration Mitigating Control
Conclusions
In summary, it has been demonstrated how SAP IAG Access Analysis Service allows, in a manner similar to SAP GRC AC ARA, to perform risk analyses to be able to know the presence of these in the users, and to carry out the remediation and/or mitigation.
Additionally, the great novelty of IAG is to be able to analyze, in a natively manner to SAP Cloud systems, whereas GRC AC can only be natively integrated with SFEC.
Currently, the tool is under development by SAP, progressively incorporating functionalities. To consult, access can be had to the roadmap of the tool:
