|
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.
Q2. Does
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.
|
