Wednesday, 30 October 2013

SAP Access Control 10.1 Q&A with Deloitte's Kurt Hollis in sapinsider

Q1.Besides being HANA enabled, what are the major changes of 10.1 compared to 10.0 ?

Ans: Kurt Hollis

Here is the major changes below.
Also, it is based on NW 7.40, includes support for the new User Interface based on HTML5.

Simplified Access Request - SAP Access Control 10.1 features a new, simplified, and intuitive Access Request form allowing you to define Request Reasons and to use these reasons for request selection. You can click the role name and access critical information such as Tcodes and you can save a draft version of the request. You can also add comments for each role.
New side panels provide additional information such as the details of risk analysis.

Custom User Groups from SU01 Attributes - You can now create custom user groups based on SU01 attributes. You can use these groups when performing risk analysis.

System-Specific Org Rule Analysis - You can now define and activate the Org Rules for specific systems only. Using organizational rules in risk analysis can be time consuming especially in batch risk analysis. In most cases, Org Rules only apply to some of the connected ERP systems. By having system-specific Org Rules, only the relevant rules are used for risk analysis resulting in highly improved run times.

Org Rule Maintenance Wizard - The Org Rule Maintenance Wizard makes creating organizational rules faster and easier and eliminates possible invalid entries due to manual input errors. The wizard allows you to select the desired ERP system, select the Rule Sets, select the Organizational Levels from existing risks, and select Organizational Level values from the ERP system. You can then review and edit the new rule before generating it.

Context-Based Side Panels - This new user interface feature, an alternative to the dialog box, provides more on screen information about the process you are using without requiring you to leave the main screen. For example, while working on the access risk screen, you can use the Violation Historic View side panel to display the number of users associated with this access risk over time and also the number of mitigations over time.

Access Control for SAP HANA - This feature enables SAP Access Control to manage access and risk analysis for SAP HANA based authorizations to support SAP HANA Performance Applications and SAP HANA Business Analytics.

Role Search Personalization - You can now add custom fields to the role search criteria for access requests and configure the field attributes to the following values: Display only, Hidden, or Default.

Context Sensitive Help - You can directly access the help topics for the process you are executing by clicking on the application screen and accessing the Help Center.Enhanced Features

Improvements to Access Risk Analysis and Remediation:
1. Access Risk Root Cause Analysis - The access risk root cause analysis remediation view enables easier identification and remediation of access risks. It offers a set of tools for segmenting risk violations so you know which risks to target first. You can enable remediation workflow processes from the remediation view to ensure that the processing and auditing of remediation activities are followed and tracked.

2. Extended Remediation Capabilities - Remediation capabilities are extended by allowing reviewers to initiate removing roles or editing role validity dates directly from the access risk analysis results. These two new workflow processes are fully configurable and may reuse routing and approval rules from any other GRC workflow process. This functionality is available for both SAP Access Control and the integrated access risk analysis portion of SAP Process Control.

Reporting & Dashboard Authorization - Reports and dashboards are now secured using role-based authorizations. In addition, users’ authorizations can be displayed in a dialog box when desired. An administrator can enable or disable this link for display.


Q2Does GRC 10.1 work in at multiclient environment  at my former employer we used GRC in a single client environment  and it worked fine. But at my current employer they have had some problems with GRC in a multiclient environment  so the are not using it anymore. so does GRC 10.1 work in at multiclient environment  Or what are the challenges with GRC in a multi client environment?

Ans:   Kurt Hollis: 

      Yes, GRC works great in a multi-client environment. FOr the Development system this is very much recommended. I usually setup a golden client, a dev client, and a test client for using for refining rule set or trying new config items

Q3. When AC 10.1 will be available to all SAP customers who currently use AC 10.0?

Ans.Kurt Hollis: 
Rampup for 10.1 is available now and completed 1/31/2014. It will be availble to all customers.

Q4.
What is the reason for the release of 10.1 version of AC when AC10.0 was released in 2011? If new features were added then they could have been added to 10.0 via updates?

Ans:   Kurt Hollis: 

 Main reason is for native HANA support and support for the new HTML 5 and UI5 , these required a new Netweaver release.

Q5. Is it possible to use the same backend plugin for versions 10.0 and 10.1?



Ans:   Kurt Hollis:

Yes.
GRC Plugin 10.0 can be used with GRC 10.1 systems and GRC Plugin 10.1 can be used with GRC 10.0 systems:
Backward Compatibility for Access Control 10.0
The backward compatibility of GRCFND_A V1000 for Access Controls starts with Support Pack 10. Until SP10 both GRCFND_A and plug-in addons GRCPINW & GRCPIERP needs to be one the same level.
However, from SP10 onwards this is not required. Which means that the addon GRCFND_A on GRC system can be upgraded without the need to upgrade the plug-in addon to the same level, provided the plug-in is at a minimum SP level of SP10.
In other words, once the plug-in is on SP10, the GRC add-on GRCFND_A can be upgraded to SP11 or higher without upgrading the plug-in.

Backward Compatibility for Process Control 10.0
The backward compatibility of GRCFND_A V1000 for Process Controls has been introduced from support pack 12. Once the GRC system and GRC plug-ins are on SP12, it will no longer be mandatory to upgrade the plug-in in case the support pack in GRC system is upgraded to higher levels.
Please note the following points before upgrade to the AC 10.1 Plug-Ins.
Recommendation is to upgrade both front-end (GRCFND_A) and back-end plug-in (GRCPINW & GRCPIERP) components to AC 10.1 which also contains the AC 5.3 RTA.
During the time of transition, you can still connect to AC 10.1 Plug-in (GRCPINW & GRCPIERP) from AC 10.0 front-end.
And also, you can connect to AC 10.0 Plug-in (GRCPINW & GRCPIERP) from AC 10.1 front-end as long as support pack of AC 10.0 plug-in is SP10 and above. However, some new AC 10.1 functionalities such as Organization Rule Wizard, Custom User group creation and EAM DB log collection will not work.
(from SAP notes) 

Q6. What differences should we expect when we migrate from GRC 5.3 AC to AC 10.1 ? Can we migrate the data easily ?


Ans:  Kurt Hollis

There is a guide from SAP the Migration guide, you should get this guide on the help.sap.com website in the GRC area.

Yes the data can be migrated easily. Use the Java based migration tool to get the data out.

Some projects instead, just setup the new GRC 10.1 and transfer only the ruleset.

The workflow is thought to be better redone using the new MSMP and BRF delivered workflows and building on them rather then migrate these.

Not all data can transfer from the AC 5.3, some is historic data. The older systems is left running to access some of that data for audit purposes.


Q7. Do you control ITAR and EAR thru GRC 10.1?

Ans:  Kurt Hollis

 More from a regulation standpoint in PC.
You can use PC to comply with ITAR and EAR
also the GTS piece helps with actual compliance of those

Q8.What are the new features in AC10.1?

Ans:  Kurt Hollis

 Simplified Access Request - SAP Access Control 10.1 features a new, simplified, and intuitive Access Request form allowing you to define Request Reasons and to use these reasons for request selection. You can click the role name and access critical information such as Tcodes and you can save a draft version of the request. You can also add comments for each role.
New side panels provide additional information such as the details of risk analysis.

Custom User Groups from SU01 Attributes - You can now create custom user groups based on SU01 attributes. You can use these groups when performing risk analysis.

System-Specific Org Rule Analysis - You can now define and activate the Org Rules for specific systems only. Using organizational rules in risk analysis can be time consuming especially in batch risk analysis. In most cases, Org Rules only apply to some of the connected ERP systems. By having system-specific Org Rules, only the relevant rules are used for risk analysis resulting in highly improved run times.

Org Rule Maintenance Wizard - The Org Rule Maintenance Wizard makes creating organizational rules faster and easier and eliminates possible invalid entries due to manual input errors. The wizard allows you to select the desired ERP system, select the Rule Sets, select the Organizational Levels from existing risks, and select Organizational Level values from the ERP system. You can then review and edit the new rule before generating it.

Context-Based Side Panels - This new user interface feature, an alternative to the dialog box, provides more on screen information about the process you are using without requiring you to leave the main screen. For example, while working on the access risk screen, you can use the Violation Historic View side panel to display the number of users associated with this access risk over time and also the number of mitigations over time.

Access Control for SAP HANA - This feature enables SAP Access Control to manage access and risk analysis for SAP HANA based authorizations to support SAP HANA Performance Applications and SAP HANA Business Analytics.

Role Search Personalization - You can now add custom fields to the role search criteria for access requests and configure the field attributes to the following values: Display only, Hidden, or Default.

Context Sensitive Help - You can directly access the help topics for the process you are executing by clicking on the application screen and accessing the Help Center.Enhanced Features

Improvements to Access Risk Analysis and Remediation:
1. Access Risk Root Cause Analysis - The access risk root cause analysis remediation view enables easier identification and remediation of access risks. It offers a set of tools for segmenting risk violations so you know which risks to target first. You can enable remediation workflow processes from the remediation view to ensure that the processing and auditing of remediation activities are followed and tracked.

2. Extended Remediation Capabilities - Remediation capabilities are extended by allowing reviewers to initiate removing roles or editing role validity dates directly from the access risk analysis results. These two new workflow processes are fully configurable and may reuse routing and approval rules from any other GRC workflow process. This functionality is available for both SAP Access Control and the integrated access risk analysis portion of SAP Process Control.

Reporting & Dashboard Authorization - Reports and dashboards are now secured using role-based authorizations. In addition, users’ authorizations can be displayed in a dialog box when desired. An administrator can enable or disable this link for display.

Q9. How have you seen Access Control 10.1 integrated with BPC 10?

Ans:  Kurt Hollis

You can integrate with BPC 10 since it is a SAP ABAP Netweaver based system using the Plugin GRCPINW and manage security access controls same as other systems.

Q10. Hello Kurt! We are currently running GRC 5.3. We have recently joined ramp-up for 10.1 and are building out an entirely new landscape due to the switch from Java to ABAP. Do you know of a place where I can get more information on setting up the new plug-in connector settings say in an ECC system? I can't find anywhere on what to enter for Plug-In Connector and GRC Connecter parameter values. Just that it must match what is in the GRC system. Also, I've heard that once the new plug-ins are installed that your connections from the 5.3 system will break, however a future support pack may allow you to run both an AC 10.1 system and an AC 5.3 system in parallel until cutover is complete. Have you heard if that's definitely going to be a possibility?

Ans:  Kurt Hollis

The setup of the connectors includes 6 steps and it is all in the SPRO transaction. 3 of the steps are in the integration section and the other 3 steps are in the Access Control section.

1. First, set up RFC Connections to the Plug-In systems, such as the ERP system (the name of the connector will be critical)

2. Second, Each rule set is activated and linked into a separate logical group (technical name in brackets):
GRAC_RA_RULESET_SAP_R3: Rules for ERP including Basis and HR (SAP_R3_LG)
GRAC_RA_RULESET_SAP_HR: Rules for HR only (SAP_HR_LG)
GRAC_RA_RULESET_SAP_NHR: Rules for ERP excluding HR and Basis (SAP_NHR_LG)
GRAC_RA_RULESET_SAP_BASIS: Rules for Basis (SAP_BAS_LG)
GRAC_RA_RULESET_SAP_APO: Rules for APO (SAP_APO_LG)
GRAC_RA_RULESET_SAP_CRM: Rules for CRM (SAP_CRM_LG)
GRAC_RA_RULESET_SAP_ECCS: Rules for ECCS (SAP_ECC_LG)
GRAC_RA_RULESET_SAP_SRM: Rules for SRM (SAP_SRM_LG)
GRAC_RA_RULESET_JDE: Rules for JD Edwards (JDE_LG)
GRAC_RA_RULESET_ORACLE: Rules for Oracle Apps (ORACLE_LG)
GRAC_RA_RULESET_PSOFT: Rules for PeopleSoft HRMS (PSOFT_LG)

3. Next, set up Connector Assignments and Connector Groups
The Connector Group is important for the Rule Set activated (from Step 2)

4. Set up the Connector Assignment for each of the Integration Scenarios
Note: Must perform all scenarios’ setup regardless of using or not

5. Simple Setting to Map the Target Connector to the Application Type

6. Assign the Connector Group the Actions and the Target Connectors
Usually Assign all Actions, set default


The connector instructions are in the SPRO transaction in the text boxes in front of each step. No more config guide from SAP like with AC 5.3 had.

Yes, the VIRSA code is included in the new plugins for 10.1 and it is backwards compatible with GRC AC 5.3, SP18 and higher. THe exact version matching needs to be checking in the SAP notes
1662113 Using Access Control 5.3 with your 10.0 plug in systems
1590030 GRC10 Plug-in & 5.3 VIRSA Plug-in (RTA) Co-Existence 
1352498 Support Pack Numbering – GRC Access Control 

Q11. Today we only unitize RAR & CUP in 5.3. Do you recommend a "technical" upgrade with GRC 10 and then  implement BRM functionally later?

Ans:  Kurt Hollis

Your situation is common. RAR and CUP most popular. Of course the Firefighter is too.

You can implement the new ARA and EAM in 10.0 or 10.1 now and add the role management piece later. It is advised to plan the needed business configuration decisions into the new EAM setup to support the added role management to avoid going back and refitting the EAM to the Role management later.


Q12. I'm not sure if my last question got thru, but can you recommend any ways of validating the migration was successful, like any reports?

Ans:  Kurt Hollis

 During the import of the migrated data, it is validated and logs exist. Once the data is imported, you can view the data either in the application setup screens or view the contents of the tables. You can also download the data and compare them using spreadsheets if not to large of data. This is one area that is ore intensive work. The migration tool adis in both filtering, transformation of data, the validation of the loading of the data. But detailed verification and comparing is much manual work.

Q13. Have you been able to connect Access Control to BPC and implement it successfully at a client? Can you share details?

Ans:  Kurt Hollis

 I personally have not connected to BPC systems, but I see it no different then any other source system. The roles may be unique and the rule set may require more custom work, but that is the case with some systems not included in the delivered rule sets from SAP.

Q14. Have you already migrated a client from AC 10.0 to AC 10.1? How smooth was the migration? Any pitfalls to avoid ?

Ans:  Kurt Hollis

  The upgrade from GRC 10.0 to 10.1 involves mostly the Netweaver upgrade from 7.02 or 7.31 to 7.40 version. One struggle I had was generating the correct stack.xml file for the upgrade in solution manager. I had to update my solution manager content first. Then it was OK. No big issue really. Very smooth. I did not migrate it to HANA DB but that can be done using the system copy migration process.

Q15. Any new feature in 10.1 with respect to HR Triggers. also now can we have multiple rule for single HR trigger in BRF+ decision table?

Ans:  Kurt Hollis

 yes, based on a single trigger received on something like a new user creation, you can define multiple conditions on what access needs to be assigned to them based on business requirement.

Q16 .Kurt, any insight into the most pressing business case for moving to HANA-enabled Access Control? What does HANA bring to AC that changes its performance?

Ans:  Kurt Hollis

The main reason for HANA platform is to support custom reporting and queries not available in the standard delivered packages. Some of which are below. The BW custom reporting was available in the past, and this is a natural progress.

The (building blocks) prerequisites for creating ad hoc reports for analyzing the access risks, access risk violations, incidents of SoD risk and mitigating control risk violations, org rules, mitigating controls, actions, functions, critical actions/roles/profiles, action usage, incidents, Segregation of Duties (SoD) and user access risk. Analysis areas include risks library, rules library, users, roles

Based on this virtual data model, you can generate reports to answer the following business questions.

What are the access risk violations over the past six months?

What are the risk violations for a specific role?

What mitigating activities have been performed over the past three months?

What unmitigated risks exist in the system?

What is the history for SoD reviews?

What is the history for user access reviews?

For access requests:
How many access requests were created for the last three months?

What types of access requests were created: User Access, reviews of Segregation of Duties, Emergency Access?

What was the length of time for the access requests to be completed for the last five months?

What access requests are still pending? How long have they been open?

How many users and roles were provisioned for the last four months?

What are the most frequently requested roles?

What are the service level agreements for the requests?


Q17. Is there any reason with the new GRC 10.0 or 10.1 applications to have a plug-in installed on the same system as the GRC Access Control 10.1 application if it is a standalone ABAP system?

Ans:  Kurt Hollis

It is not required to have this plugin on the new GRC 10.1 system. Only needed if you wish to use the Access control features on the GRC  system itself, just like any other connected system.

Q18. When will GRC AC 10.1 certification available?

Ans:  Kurt Hollis

GRC 10.0 certification is available now and it usually takes 6-12 months until next one. I would go for the GRC 10.0 certification.

Q19.What are the new reporting capabilities in GRC AC 10.1 and What is the process to migrate GRC AC 10.1 From all Previous versions?

Ans:  Kurt Hollis

  The reporting capabilities in GRC AC 10.1 are similar to 10.0 and expanded once integrated with SAP HANA. See the post about the GRC HANA reporting prior.

The upgrade from GRC 5.3 is a Java to ABAP migration and involves extra steps to migrate the Java based data into a new build of GRC 10.1 on ABAP.

The upgrade from GRC 10.0 to GRC 10.1 is more straight forward ABAP NW 7.02 or 7.31 to NW 7.40 ABAP based systems upgrade, basically on version upgrade. The data and application will not be changed much and then you can take advantage of the new release features of 10.1. See the prior post on the new release fatures of 10.1


Q20.Is it comparable in terms of workload to set up user request workflows compliant user provisioning tool (CUP 5.3) or Manage and Provision users (10.X), for a workflow of similar complexity? How different is the set up from one GRC version to the other? Are there predefined templates available in 10.X?

Ans:  Kurt Hollis

  The workflows are pre delivered and can be almost ready to use out of the box just like in AC 5.3. There are steps to make assignments and configure them before using. They are delivered in the BCSET. You can setup using the SPRO and IMG. The setup is more of a learning curve and a bit more complex but a lot more powerful.

Q21.Do you suggest any kind of validation reporting to use when validating the migration was successful?

Ans:  Kurt Hollis

 During the import of the migrated data, it is validated and logs exist. Once the data is imported, you can view the data either in the application setup screens or view the contents of the tables. You can also download the data and compare them using spreadsheets if not to large of data. This is one area that is ore intensive work. The migration tool adis in both filtering, transformation of data, the validation of the loading of the data. But detailed verification and comparing is much manual work.
Not as automated as we would prefer, but still a good process to work with during migration. The best practice is to make sure the export is clean as possible before the import, this saves cleanup later in the new system.

Thanks to Mr.Kurt Hollis....



Kurt Hollis: 

If you go to the GRC conference in 2014, there is a new GRC Hands on lab where each person gets their own GRC system to configure and get the applications up and running for the first time. This is a great way to quickly learn how to setup GRC 10.1 easily from experienced people. I am the speaker and instructor for this lab exercise.

The lab is based on GRC Access Control 10.1.

















  

  




































No comments:

Post a Comment