Product Information
GRC Risk Analysis for Cloud systems
Overview
SAP Cloud Identity and Access Governance is a Cloud based GRC solution to integrate cloud and on-premise applications. With various services in place, access analysis service, is a service that will be used to perform the risk analysis functionality and we are focusing on integration of SAP Access Control to SAP Cloud SAP Cloud Identity and Access Governance.
Possible Scenarios
There are so many questions regarding the risk analysis for cloud applications and how to extend the solution for existing SAP Access Control implementation. This blog post gives you a complete overview of options and steps for risk analysis for both stand alone SAP Cloud Identity and Access Governance implementation and SAP Access Control bridge scenario.
- SAP Cloud Identity and Access Governance only option – You have only SAP Cloud Identity and Access Governance solution and wanted to integrate with cloud and on-premise solutions for risk analysis.
- SAP Cloud Identity and Access Governance with bridge option – You have existing SAP Access Control solution with on-premise integrations and now want to integrate the cloud applications. There is no direct integration with SAP Access Control and hence you are using SAP Cloud Identity and Access Governance solution for risk analysis.
Note: Please refer the integration and bridge documents at help.sap.com for technical details to setup the below scenarios.
Scenario 1: Risk analysis from SAP Cloud Identity Access Governance
This is a simple scenario where the risk analysis is running in SAP Cloud Identity and Access Governance for cloud and on-premise applications. Follow the below steps for getting the risk analysis results for ex, SAP Ariba.
- Create a destination for SAP Ariba in SAP Business Technology Platform cockpit (previously called as SAP Cloud Platform)
- Create a system entry in System tile pointing to the destination. While creating the system, make sure you enter the exact destination name you created in step 1 (case sensitive)
- Create an incident to SAP Support for component GRC-IAG to load the ruleset for SAP Ariba.
- If you are changing the ruleset for SAP Ariba(custom), make sure you download the standard ruleset and keep it for backup. Because, once changed you cannot get the standard one. You can also create a new business function group as say for ex, Ariba_Group and load the changed ruleset for this new group and assign the Ariba system to this group and leave the default group (SAP_ARIBA_LG) which was created by default. This way, you have two groups, one for standard and one for changed ruleset.
- Run the Repository Sync job from Job Scheduler tile.
- Once completed, make sure you see the Roles/Groups in Access Maintenance tile and Users in Maintain User Data tile.
- Run the Access Analysis from Job Scheduler tile. This is not specific to any system but for all. When you schedule, it picks up all the objects that were changed after the last time the job successfully completed. When you run first time, it will take time as it runs for all the objects including roles/groups and users and for all the systems.
- If all the above steps are completed successfully, then you can see the risk analysis reports from Access Analysis for Users and under Access Maintenance for Roles/Groups.
Scenario 2: Risk analysis from SAP Access Control via SAP Cloud Identity Access Governance
This scenario involves more steps than previous one. You have SAP Access Control and you would like to run the risk analysis for cloud applications. Risk analysis for cloud applications are not supported directly from SAP Access Control and hence the bridge scenario is used. SAP Cloud Identity and Access Governance is used as a bridge between the SAP Access Control and the cloud applications.
Switch
The risk analysis behavior is based on SPRO configuration parameter 1090, which behaves like a switch.
- 1090 = YES
- Risk analysis from Access request will get the risk analysis results from SAP Cloud Identity and Access Governance and no analysis happens in SAP Access Control12.0 side.
- This parameter is applicable for risk analysis for request only and not for any User/Role level analysis under Access Management or Reports and Analytics in SAP Access Control.
- If you run the analysis in User Level analysis for ex, then the risk analysis is performed for on-premise applications inside SAP Access Control only.
- It is advisable to run the reports in SAP Cloud Identity and Access Governance once this parameter is set to YES.
- You have to move all the rulesets and authorization objects to SAP Cloud Identity and Access Governance to run the analysis for both cloud and on-premise solution at one place.
- 1090 = NO,
- the risk analysis works as per SAP Access Control and no change.
- In this case only on-premise systems and SF system is supported in SAP Access Control. Cloud applications are not supported even if you have SIAG setup for cloud applications.
- Simply, there is no change in behavior from existing functionality.
Follow the below steps to run the risk analysis for all applications including on-premise and cloud using bridge scenario
- You have the connector created and assigned to SAP Cloud Identity and Access Governance connector type in SPRO configurations in SAP Access Control. This is a similar step as any other on-premise systems you set up in SAP Access Control. Please check the steps in SAP Cloud Identity and Access Governance Bridge document for complete details.
- Make sure Scenario 1 Risk analysis from SAP Cloud Identity Access Governance is completely setup and running for cloud applications.
- Create a new destination for SAP Access Control system as ABAP RFC type in SAP Business Technology Platform cockpit (previously called as SAP Cloud Platform),
- Create a new system for type SAP Access Control under Systems tile for the destination created in the previous step.
- You have to move the rulesets for on-premise applications from SAP Access Control to SAP Cloud Identity and Access Governance by running Access Control – Risk Definition Sync job from Job Scheduler for the system created above. This will bring all the logical group, connectors, rulesets loaded in SAP Access Control. If you are using the SAP Cloud Identity and Access Governance only for risk analysis, then do not create any logical group or connectors in SAP Cloud Identity and Access Governance.
- You have to move the Mitigation Controls for on-premise applications from SAP Access Control to SAP Cloud Identity and Access Governance by running Access Control – Mitigation Control Transfer job from Job Scheduler for Access Control system. This will bring all the mitigation controls defined in SAP Access Control to SAP Cloud Identity and Access Governance.
- Run the Repository Sync job for SAP Access Control system to bring all the objects and authorization from SAP Access Control to SAP Cloud Identity and Access Governance . This is used for running the risk analysis.
- SAP Access Control may not have Authorization data for the corresponding objects. Hence, you may have to run the repository sync for on-premise systems with Role/Profile Authorization data option selected in repository sync job in SAP Access Control. This also provides Value Help during Function creation in SAP Cloud Identity and Access Governance.
- You must select the Role Import option also in Repository Sync join in SAP Access Control. This option takes care of the BRM role import and hence you don’t need to setup the roles manually in BRM.
- Run the Access Analysis job under Job Scheduler.
How risk analysis works in SAP Cloud Identity and Access Governance ?
- Risk analysis results are not running when you request instead it is analyzed and the reports are ready to consume. This is the fundamental difference on how risk analysis works in SAP Access Control and SAP Cloud Identity and Access Governance.
- You need to schedule a recurring job for Repository Sync for all the systems including the SAP Access Control and other cloud applications based on your need.
- You need to schedule a recurring job for Access Analysis. This runs for all the systems.
- Please schedule the above jobs based on your need and how frequent the objects are changed in the connected systems. It is not advisable to run frequently like every 5mins.
- Based on the above jobs, the risk analysis results are updated.
- If there is any change in the ruleset, then risk analysis job will run for all objects and it will take time even though there are no object changes in the connected systems.
Where do you see the results?
- You can check the risk analysis results for groups/roles under Access Maintenance tile in SAP Cloud Identity and Access Governance.
- You can check the risk analysis results for Users under Access Analysis and Analyze User Access tile in SAP Cloud Identity and Access Governance.
- You can check the violations in Access request from SAP Access Control.
Conclusion
The above explanation should have given you a complete picture of how this whole integration works. Based on this, you can setup your risk analysis solution and this is a functional overview only. For more details document on how to setup the bridge solution, you should check the help.sap.com for SAP Cloud Identity Access Governance.
References
Please check the below documents from https://help.sap.com/viewer/product/SAP_CLOUD_IDENTITY_ACCESS_GOVERNANCE
- (IAG Bridge) SAP Access Control 12.0 (on-premise) to IAG and Cloud Target Application
- Integration Scenarios
Note: Please share your feedback or thoughts in a comment below or ask questions in the Q&A tag area here about SAP Cloud Identity Access Governance or https://answers.sap.com/tags/01200615320800000796
Hello Prem,
Many thanks, this is very useful!
A quick question - beyond ARM requests, is there any way to run a direct risk analysis for users on Cloud applications (e.g. ARIBA) from GRC 12 via the IAG Bridge Scenario?
That is, can I somehow create an ARIBA connector on GRC 12 on-prem, upload ruleset data for ARIBA against that connector, and run risk analysis directly against the ARIBA connector? I know that there are other ways of integrating GRC 12 with Cloud applications (like this one) but, can we leverage IAG-Bridge for this?
Hi Rohit,
No, you have to use the IAG for risk analysis reports. Ariba integration is supported from IAG only.
Thanks,
Prem
Hi Prem,
Thanks for this blog, it's very insightful.
How does it work for cross-system risk analysis? Let's say if a userdoes some of the buisness steps in S/4 HANA and some in Ariba. Does IAG allow us to run cross-system risk analysis?
Regards,
Priyank.
Hi Priyank,
Yes, you can create a cross system rule like AC and it should return.
Thanks,
Prem
Thanks Prem.
Hi Prem,
thank you for the great blog and clarity on a number of topics.
In your blog post, you are mentioning that simulation of role risk for users is not supported in the bridge scenario. Can you elaborate more on that, since in a call with SAP, they firmly confirmed that such scenario is supported. I explain below:
Please let me know if according to you the above scenario is feasible with the current functionality of the IAG bridge.
Thanks,
Todor
Hello Todor
When an Access Request is created for the Cloud system, GRC reaches out to the IAG to read the ARA results & based on that workflow proceeds. But it doesn't store the ARA results in it's repository.
Additionally, running ARA from ACCESS MGMT. tab in GRC AC for the cloud systems, won't fetch you any results because GRC doesn't have the capability to read data from IAG only for ARA purpose, without the CUP request.
Others can correct me, if I am wrong 😉
Regards
Sanjeev Sharma.
Hi Sanjeev,
What you say is in your first part of the reply seems correct, however, we are interested in the specifics of the this sentence - > "GRC reaches out to the IAG to read the ARA results".
The question here is - is GRC reading the already pre-run analysis reports or is it doing a calculation based on the new requested role?
Additionally for the second part, i am not quite sure that GRC is not capable of fetching results from IAG, this would be somehow suspicious.
BR,
Todor
Hello Todor
No, GRC doesn't have the capability yet to run ARA for the CLOUD Systems on its own. That's why we have the IAG BRIDGE in between, to communicate with the CLOUD Systems & the analysis happens in real time with the newly requested roles, but on IAG & not on GRC.
& yes, I know it's sound unreal but sadly it's true. GRC itself is not having the out of the box capability to perform/store the CLOUD system's RISK analysis in it's repository. So, ARA for cloud systems won't fetch you anything on GRC. For Cloud systems, you need to run the ARA in the IAG directly.
Regards
Sanjeev Sharma.
Hi Sanjeev,
maybe I formulated my question wrong, but what I meant is exactly the case where GRC sends the analysis to IAG and gets the results back and I am pretty sure that this should be possible. Otherwise how would you integrate an existing GRC flow with additional cloud applications from IAG.
That is what the IAG bridge scenario is there for. Even there is one additional service, which can be setup, which reports the status of the provisioning for cloud applications through IAG, but this is something different.
Talking about risk analysis - a flow/request started in GRC with proper configurations in SPRO is sending all its roles (not only cloud) for analysis to IAG and gets back the results and then can decide what to do with those - e.g. continue workflow, cancel, additional approval, etc.
The unclear step in the whole process is - is IAG capable of doing on-demand simulation of risk based on newly requested roles from GRC.
BR,
Todor
Hi Todor,
Thanks.
Please let me know where it is confusing and I can change it. Your scenario is possible as long as the new role Q is analyzed in IAG and ready to consume. If the new role is not synced/analyzed in IAG, then it will not show the results.
Thanks,
Prem
Hi Prem,
thanks for reaching out. I think the availability of the role in IAG is an absolute must, otherwise GRC wouldn't know about it either, right?
I think this type of scenario cannot be simply explained with words. If you can share 15-20 minutes, we can have a quick call to discuss.
Thanks,
Todor
Hi Todor,
Yes, you are right.
You can always reach out via incident or Expert Chat or Schedule an Expert session and I am happy to discuss with you further.
Thanks,
Prem
Hi Prem,
thanks for the blogpost. it clarifies the much needed basics.
i am not able to understand the statement "Risk analysis results are not running when you request instead it is analyzed and the reports are ready to consume. ".
In this thread it is also mentioned that "... the analysis happens in real time". So, does your above statement also mean the same
Regards
Plaban
Hi Plaban,
No, whenever you go to IAG for analysis it is always processed data and keep your analysis up to date. You have to make sure you run the sync and analysis job frequently (based on how frequent you change privileges and assignment).
Hope this clarifies.
Thanks,
Prem
Hi Prem,
for a new user, there will be no such pre-analyzed data. So, how does a new user's access gets risk analyzed. Also, i had few more questions, if you may help.
In your scenario 2 diagram. the arrows are pointing to GRC AC, But as per sync, it should point towards IAG, isn't it.
And in scenario 2, can you please advise as to how does provisioning occur for Cloud systems, i.e after the workflow has been processed at GRC AC , how does the user and it's assigned roles are sent to cloud applications.
Regards
Plaban
Hi Prem,
Would you be letting know on my above query on new users.
And my understanding on your blogpost is as below. Requesting you to correct, wherever is wrong
Regards
Plaban