Apply SAP Notes
Continue implementing SAP Note 1121978: In Risk Analysis and Remediation->Configuration->Performance Tuning set the following values:
· Batch size for users should be 1,000
· RFC Time out should be 1441
· Web Service worker: 5
· Job worker: 3
Make sure that your Sun JDE is on Compiler version 15 or higher (SAP note 1044173 – For Access Control 5.3 we recommend Sun JDK 1.4.2_15 or higher).
Schedule background jobs according to the recommendations given in SAP Note 1034117.
Refer to SAP Note 1179717, 1126251 and 1239588, if you want to learn more about synchronization and batch risk analysis.
For troubleshooting tips for the background job daemon refer to SAP notes 1249499, 999785, 1176262 and 1176363.
SAP Note 986997 provides additional information on how performance is impacted by various features of the application.
Finally make sure that spool files are regularly archived or deleted such that they cannot fill up your file system and cause a system stoppage. For details refer to SAP note 1129441.
Usage of Logical Systems
A logical system allows for a grouping of one or multiple physical system connectors in order to
perform risk analysis against the same rules. Logical systems reduce the time and system resources required to load and maintain identical rule sets across multiple systems.
In SAP GRC Access Control risks are defined by one or multiple functions. Functions are defined by a set of actions and permissions each one referencing to one system. These system references in actions and permissions can be defined in two different ways:
· By references to physical system connectors
· By references to logical systems.
In the first case you need to include the same action / permission for each system connector
individually into the function, which would multiply the number of actions and permissions contained in the function by the number of backend systems you want to use this function for.
For this reason it is strongly recommended using logical systems when uploading the SAP GRC rule set files during post-installation of Risk Analysis and Remediation or when defining functions manually in the rule architect. This approach allows sharing the same actions and permissions across multiple system connectors and keeps the number of rules to be loaded and checked against during a risk analysis smaller and reduces the time needed to complete a risk analysis considerably. It also facilitates the maintenance of your rule set, since a change of a function has to be implemented only once against the logical system rather than for each individual system connector individually. For more information on logical system refer to the SAP GRC Access Control Configuration Guide.
CAUTION
If you also plan to use the ‘cross system’ feature, please check SAP note 1178372 for limitations of the usage of logical systems in this context.
Parallelization of Background Jobs
SAP GRC Access Control 5.3 allows for foreground and background processing. All tasks are
executed in threads running in the server nodes of the J2EE engine. Foreground processing takes
place in so-called web services worker threads, whereas background jobs run in background job
worker threads. The number of these threads can be configured . The threads are numbered in such a way that threads with IDs 0, 1 and 2 in each server node are used for background processing, if the recommendation in section 4.7.1 is followed. On each server node runs an Analysis Engine Daemon, which performs the dispatching of foreground tasks to web service worker threads and background jobs to background job worker threads. These daemons come with an ID, which is identical to the folder on the application server belonging to the server node the daemons runs in.
The Analysis Engine Daemon Manager allows monitoring these threads. It can be started with the URL http://
Example
An example of a server with two server nodes is shown in the screenshot below. The threads are managed by two analysis engine daemons having the IDs
D:\usr\sap\FGP\JC00\j2ee\cluster\server0\ and D:\usr\sap\FGP\JC00\j2ee\cluster\server1\, respectively. Each daemon manages three background job worker threads having the IDs 0,1 and 2 plus five web service worker threads having the IDs 3, 4, 5, 6 and 7. All threads are currently idle.
In GRC Access Control 5.3 the following two background jobs are executed in a parallelized fashion:
· User / Role / Profile Synchronization
· Batch Risk Analysis (scheduled in the Configuration->Background Jobs->Schedule Job)
Thread 0 on each server node is reserved for these two types of background jobs. A job of one of
these two types is decomposed into subtasks and executed in parallel in the threads with ID 0 of each one of the available server nodes on the J2EE engine. Once all the subtasks are completed, the main job is marked as completed by the last server node which completes the last subtask.
Note
Only threads with ID 0 can execute user / role / profile synchronization and batch risk analysis background jobs. If there is already such a job running, other scheduled jobs of one of these two types have to wait until the running job complets and the threads with ID 0 become available again. Available background job worker threads with IDs different to 0 can’t take over such jobs.
Note
None of the other background jobs like risk analysis started in the Informer tab, simulations, rule generation, organization user mapping, organization level reporting etc supports parallel processing. They are all processed in a single background job worker thread on one of the available server nodes.
If you have a large number of systems and users to include into your batch risk analysis, you should take advantage of the ability of parallel processing and configure multiple server nodes. If N is the number of server nodes, then the time required to complete the batch risk analysis should approximately depend by ~1/N on the number of available server nodes.
Example
Running a batch risk analysis on two server nodes should approximately take only half of the time than required for the same analysis on a single server node.
However, consider that adding server nodes requires more hardware resources
Note
Parallel processing is also supported across multiple Java dialog instances running on different hosts.
Best Practices for Batch Risk Analysis
Another powerful approach to speed up the time needed for batch risk analysis is focusing on only those users that are really relevant for your analysis. Therefore, in Configuration -> Risk Analysis -> Default Values we suggest excluding the following users:
· Locked users
· Expired users – users outside of their validity period can’t logon
· Mitigated users – can be reported separately in Mitigation -> Mitigated Users
· Default user type for risk analysis should be set to ‘Dialog’ to exclude all technical user types
We also recommend excluding critical roles and profiles from batch risk analysis, because profiles like SAP_ALL carry all possible risks and consume a considerable amount of computation time when they are hit by a risk analysis. You can exclude critical roles in Configuration -> Risk Analysis -> Additional Options setting the toggle ‘Ignore Critical Roles & Profiles’ to ‘Yes’. Then define all roles and profiles in the Rule Architect as critical roles and profiles, respectively that match one of the following criteria:
· SAP_ALL, SAP_NEW
· Profiles listed in SAP Note 1034117 and similar profiles you have created
· All powerful roles you have created for emergency access or super-users
Furthermore, try to identify activities you need to perform in the backend systems that
· are executed only once per month / quarter / year and
· add a considerable amount of risks to the users who have to perform them
Now, create in Superuser Privilege Management Firefighter IDs and grant the roles required for these activities to them. Then remove these privileges from your regular end users. As Firefighter IDs should be configured with user type ‘communication’ they can be excluded from risk analysis as well.
Finally, another measure to increase efficiency is the usage of incremental synchronization and
incremental batch risk analysis (refer to SAP note 1034117). After the initial full synchronization, it is best practice to schedule a daily batch job to run an Incremental Synchronization and batch risk analysis. Please note that an incremental sync will only review those users changed in the back-end system (for example roles added or removed). The Incremental Analysis does not take into account front-end changes such as to the rules or addition/changes to mitigating controls, which would affect users / roles / profiles that weren’t tagged as ‘changed’ during the incremental synchronization.
Therefore, it is recommended that, in addition to the daily incremental batch risk analysis, a monthly full batch risk analysis is also scheduled. This will ensure that all changes made to the front-end are also appropriately reflected on the management reports.
For more preferred practices on access risk remediation and mitigation refer to the GRC Access Control - Access Risk Management Guide.
No comments:
Post a Comment