Within the SAP® portfolio of solutions for identity and access control, a solution called SAP IAG (Identity Access Governance) has been available since 2018. This solution, like SAP GRC AC (Governance, risk, and compliance Access Control), enables centralised access management for customers in their SAP environments. However, one of the main innovations of this recent tool is that it is natively connectable to SAP public cloud systems (such as Ariba, Fieldglass, S/4 HANA Cloud, among others) and also to On-Premise systems, while GRC AC is not (only, as an exception, SFEC).
Focusing on SAP IAG, we can also draw some equivalence between the modules of GRC AC, and the (now services) of SAP IAG. Below is a chart showing the main functionalities of SAP IAG:
In this article, we will only explain in detail the Privileged Access Management service, the purpose of which is the management of super-privileged accesses necessary to carry out extraordinary tasks in a limited period of time.
The first thing to understand is that SAP IAG is a product that exists within the SAP BTP (Business Technology Platform). Therefore, customers who wish to have SAP IAG must have access to this platform.
In addition, SAP IAG currently has 2 procurement models:
1) As the only access control tool (i.e. no GRC AC is available).
2) As an extension of SAP GRC AC for Cloud environments.
In this article, only the first point will be dealt with, i.e. assuming that SAP IAG is the only tool for access control. In addition, emergency access management will be carried out in an On-Premise system (SAP S/4 HANA).
Currently, the PAM service can be used for:
– Any AS ABAP system, in the same way as GRC AC EAM.
– S/4 HANA Cloud.
In addition, it is necessary to understand that SAP IAG is a product that exists in the SAP public cloud, and therefore is not within the customers’ internal network.
In order to facilitate this task of interconnectivity from the public cloud to the customers’ internal network, the Cloud Connector software is delivered to expose those function modules that will be used by IAG (in this case) to manage emergency access in a secure manner.
Once the software has been installed and configured, the next step is to create the connection in SAP BTP, which will then be used by SAP IAG. This is, analogous to what would be done in SAP GRC AC, to create an RFC connection.
After this step has been completed, you can start to perform the application-specific configuration in the SAP IAG tool itself.
General Considerations PAM
Application methods
In the case of PAM, and as in SAP GRC AC, there are 2 methods of use. However, by contrast, both are not available for all types of systems where PAM can be used.
– Decentralised PAM: this is the only method of using PAM for AS ABAP systems.
– Centralised PAM: is the only method of use for Cloud systems (currently only S/4 HANA Cloud).
However, unlike GRC AC, there is only one method of use. Whereas in SAP GRC AC it was possible to use role-based or ID-based superuser accesses, in IAG it can only be configured via the latter.
PAM Configuration
Decentralised RFC creation
Exactly as in GRC AC, in order to be able to use decentralised PAM in AS ABAP systems, it is necessary to create an RFC connection in the target system pointing to the system itself, which allows the leap to the superuser. It is important that this connection, as well as the one in section 1. Introduction, have the same identifier.
Application creation
Thus, the first step would be the creation of the application to be monitored in IAG. To do this, you can access the route:
Administration > Applications
The type of system must be chosen (as previously mentioned, it will be an S/4 HANA On-Premise, in this case), and cover the HCP Destination, which has to coincide with the connector created in BTP previously.
Creating Reason Codes
Another configuration option is the creation of Reason Codes.
Administration > Request Reason
In order to be able to use emergency access, it is necessary to create 2 different types of reason codes:
- Access Request: these are reason codes transversal to any type of request, not only PAM, and that allow to categorise the nature of the request.
- Privileged Access Session: similar to GRC AC, when a superuser session is initiated, it is necessary to categorise it. This is where the superuser session reason codes come into play.
Business processes
It is also possible to create your own risk levels and business processes in the options:
Administration > Business Processes
The business processes are necessary to be able to categorise the business roles, which are then assigned to the superusers.
Business Roles
In IAG, only one type of roles can be managed, namely Business Roles. This type of role is a collection of technical roles/groups/etc. of one or several systems.
In SAP IAG, and unlike GRC AC where the roles are assigned to the emergency users in the target systems, the business roles are assigned in the central IAG system itself, and from this it is replicated to the target system.
Thus, the creation of business roles is necessary to provide the emergency user with the necessary authorisations to be able to carry out the emergency tasks.
PAM Flow Configuration
Another task necessary to start using emergency access is the configuration of the approval and review flow for the use of emergency access. This task is carried out in 2 steps:
Administration > Maintain Workflow Template
In this path, the different approval paths through which the requests (e.g. request and review of emergency accesses) will pass must be loaded.
An incident can be opened to SAP to cover the existing default information, but it is also possible to create them by the customer himself.
Administration > Configuration > Business Rule > Launch
In this service, the equivalent of the SAP GRC AC BRF+s can be configured, where the logic that routes requests through the different approval paths is configured.
In this case, it is stipulated that emergency access requests will flow through the approval path managerwf where the manager of the request will be in charge of approving.
PAM ID Lifecycle
Creation
Administration > Maintain Privileged Access
Unlike GRC AC, it is in IAG where emergency accesses are created centrally, and then replicated to the target systems.
These emergency accesses must be assigned a previously created Business Role that will contain the authorisations.
They must also be assigned a set of permitted activities. The usefulness of this functionality is that when reviewing the superuser usage logs, the executed tasks that are NOT part of this list will be marked in a special way to focus the review.
Once the emergency access has been created, it is necessary to run the Provisioning Job programme which will trigger the creation of the emergency access in the satellite system.
Request
Once the superuser has been created and is active, it can be requested to be assigned to users. To do so:
Access Request > Create Access Request
Here you must select the emergency access and the validity with which it will be assigned once it has been approved.
Approval
Depending on the approval flow configuration, the request will be approved by one or the other agent. After this approval, and without the need to run any programme, superuser access will be assigned to the user.
Use
As soon as the superuser access is tested, it shall be assigned to the user. In order to start the emergency session, the transaction SIAG_PAM_LAUNCH_PAD must be executed.
As in SAP GRC AC, the Logon button must be selected, and from there the parameters (reason code, explanation of the transactions to be used, etc.) must be entered.
Generation of Revision Tasks
Once the emergency access is used, it will be necessary to run 2 programs to generate the superuser access review tasks. To do this, navigate to the following path:
Administration > Job Scheduler
And launch the following programs in the order given:
– Privileged Access Log Sync Job
– Privileged Access Review Request
Once executed, and if there are superuser usage review tasks, these will be sent to the corresponding reviewers.
Review
After executing the above programs, the reviewer user will receive a task to perform the emergency access usage review.
Depending on the transactions executed by the superuser, and also depending on which activities have been configured as allowed, the review task will highlight certain transactions for review or not.
The review task allows for additional information such as attachments or comments by the reviewer.
Reporting
The SAP IAG tool has a number of reports that allow you to view the usage of superuser access at any time.
The most relevant is the Privileged Access Monitoring, which can be found in the Reports section.
Conclusions
By way of summary, it has been demonstrated how SAP IAG Privileged Access Management allows, in a similar way to SAP GRC AC EAM, the management of superuser accesses in order to manage the life cycle of superuser accesses (create them, request them, approve them, review them).
In addition, the great novelty of IAG with respect to GRC AC is to be able to integrate superuser accesses in cloud systems (for the moment, only S/4 HANA Cloud).
Lastly, the tool is under development by SAP, progressively incorporating new functionalities. To consult these, you can access the tool’s roadmap:
