SAP Security and GRC Course Content

SAP Security and GRC Course Content

1 SAP R/3 Security      
1.1      Overview of SAP
1.2      Overview of SAP BASIS
1.3      Introduction to SAP Security
           1.3.1      Why we need security
           1.3.2      What needs to be protected
           1.3.3      From whom we need to protect
           1.3.4      Implementation methodology
1.4      User administration
           1.4.1       Single user administration
           1.4.2       Mass User administration
           1.4.3       LSMW Script running
1.5      Introduction of CUA (Central User administration)
           1.5.1       CUA Configuration for different landscapes
           1.5.2       Performing user administration activities in CUA
           1.5.3      Distributing User/IDOCS and troubleshooting issues
1.6      User Groups Concept
1.7      Role Administration and authorizations concept
           1.7.1       Overview of authorizations and roles
           1.7.2       Change management process
           1.7.3       Creating custom authorization objects
           1.7.4       SAP Role types
           1.7.5       Working with Profile Generator
           1.7.6       Creating and modifying different roles
1.8      Authorization Group Concept
1.9      Missing authorization
1.10    Tracing the user for missing authorization.
1.11    Working with R/3 tables, parameters and Reports
1.12    SAP Security Audit.

2.     BW/BI Security
2.1     Architecture and strategies for a BI authorization concept
2.2     Security requirements in SAP BI
2.3     Standard roles and templates for the authorization concept
2.4     Creating BW/BI roles and modification
2.5      Difference between BW and R/3 security
2.6      Difference between BW and BI Security
2.7      Different authorization objects involved in  BW/BI
2.8      Analysis authorization concept and reporting
2.9      Troubleshooting BW/BI issues 

3 HR Security

3.1      Introduction to HR security
3.2      Personal administration and Organizational management
3.3      HR General and Structural authorizations
3.4      HR authorization objects and info types
3.5      Troubleshooting HR issues

4 GRC (Governance, Risks and Compliances 5.3)

4.1      Introduction to GRC
4.2      Sarbanes Oxley Rules (SOX)
4.3      In depth discussion  of GRC Components
          4.3.1        Compliance User Provisioning (CUP)
          4.3.2         Risk Analysis and Remediation (RAR)
          4.3.3         Enterprise Role management (ERM)
          4.3.4         Super User Privilege Management (SPM)
4.4      Working with functions, Risks and Mitigation Controls
4.5       Introduction to GRC 10.

Creating Derived Roles in SAP Security

Creating Derived Roles in SAP Security

Derived roles :

1.   Derived roles refer to roles that already exist.  The derived roles inherit the menu structure and the functions included (transactions, reports, Web links, and so on) from the role referenced or simply you can call as Parent Role.  A role can only inherit menus and functions if no transaction codes have been assigned to it before.

2.  These are used to define to handle the security at organization levels.

3     These are created for administrative purpose to minimize the maintenance.

4.   Derived roles specify the division or unit for which the security can be provided.

5.    Derived roles are inherited from parent role/ single role/ generic role differed by there organization levels.

6.     Derived roles are also called as child roles.

7.   The higher-level role passes on its authorizations to the derived role as default values which can be changed afterwards.  Organizational level definitions are not passed on. They must be created a new in the inheriting role. User assignments are not passed on either.

8.     Derived roles are an elegant way of maintaining roles that do not differ in their functionality (identical menus and identical transactions) but have different characteristics with regard to the organizational level.

9.   The menus passed on cannot be changed in the derived roles.  Menu maintenance takes place exclusively in the role that passes on its values. Any changes immediately affect all inheriting roles.

10. You can remove the inheritance relationship, but afterwards the inheriting role is treated like any other normal role. Once a relationship is removed, it cannot be established again.

11.   In derived roles, menus are fixed.

12.   These are created in PFCG

13.   In versions earlier than 4.6 c, derived roles are also called as Derived Activity Groups DAGS.

 

 

 

 

 

 

 

Types of Roles in SAP Security

Types of Roles in SAP Security

Role:1.Role is the group of Profiles, menus, transactions, reports and user assignments and personalization.
2.Roles are defined in Transaction code PFCG
3.Roles are called as Activity Groups until 
4.6cTypes of Roles:
1. Single Role     
     i. Parent Role or Role     
     ii.Derived Role  or  Child Role
2. Composite Role
3. Copy Role 

Creating Composite Roles in SAP Security

Creating the composite roles

Composite role:  A group of  one or more roles for administrative purpose is refereed as composite role.

Create a composite role as for the naming conventions 

Specify the description

In composite role it  doesn't contain authorizations tab.it is nothing but group of one or more roles.if they need to change in composite role i.e only in menu tab.

 

Specify the roles

 Assigne this composite role to the existing user.

  Click on Read menu tab.when you click on this read menu tab then it will fetch authorizations from  the single roles.

  Now log on with that specified user.

Composite Roles in SAP Security

Composite Roles in SAP Security

Composite roles:

1.   A composite role is a container with  several different roles. For reasons of clarity, it does not make sense and is therefore not allowed to add composite roles to composite roles. Composite roles are also called roles.

2.     It is used to simplify the administration.

3.    Composite roles do not contain authorization data. If you want to change the authorizations (that are represented by a composite role), you must maintain the data for each role of the composite role.

4.     It only groups the roles, but menus can be compressed.

5.  Creating composite roles makes sense if some of your employees need authorizations from several roles. Instead of adding each user separately to each role required, you can set up a composite role and assign the users to that group.

6.   The users assigned to a composite role are automatically assigned to the corresponding (elementary) roles during comparison.

7. Composite roles are identified by customer naming conventions only.

1.    These are created in PFCG.

2.  These are earlier called as CAGS(Composite Activity Groups).

3.    Example for Composite Role. Here the role name, “BASIS Role” is defined as Composite Role

           

·         The menu tree of a composite role is, in the simplest case, a combination of the menus of the roles contained. When you create a new composite role, the initial menu tree is empty at first. You can set up the menu tree by choosing Read menu to add the menus of all roles included. This merging may lead to certain menu items being listed more than once. For example, a transaction or path contained in role 1 and role 2 would appear twice.

·         If the set of roles contained in a composite role changes, the menu tree is also affected. In such a case, you can completely rebuild the menu tree or process only the changes. If you choose the latter option, the Profile Generator removes all items from the menu which are not contained in any of the roles referenced.

·         It is possible (and often necessary) to change the menu of a composite role at any time. You adjust these menus in the same way as the menus for roles (see above).

SAP Security Check indicators-SU24

SAP Security Check indicators-SU24

•Transaction SU24 maintains the USOBT_C and USOBX_C tables. These tables hold the relationships between the particular transaction and its authorization objects. It is possible to add or subtract the checks performed in the transaction by changing the appropriate flag.

•The benefit of transaction SU24 occurs when transactions are added to or deleted from Role Groups using the Profile Generator.

•When new transactions are added, the Profile Generator will add all authorization values maintained in SU24 for the transaction(s).

•When deleting transaction the Profile Generator will remove all authorization values that are maintained in SU24 for the transaction.

•Activities performed:

•Check/Maintain Authorization Values

•Addition of Authorization Object to tcode

•Deletion of Authorization Object from tcode

Check Ind.    Proposal     Meaning     Explanation      

Check    YS    Check /Maintained    The object will be inserted along with the values in the role.  The object will be checked along with the values during runtime of the transaction.      

Check    NO    Check    This object will not be inserted into the roles.  A check on the object along with the values will be done during the runtime of the transaction      

Do not Check    NO    Do Not Check    The object will not be inserted into the roles and there will not be any check performed 

during runtime of the transaction   

Status Texts for authorizations

•Standard: All field values in the subordinate levels of the hierarchy are unchanged from the SAP defaults

•Maintained: At least one field in the subordinate levels of the hierarchy was empty by default and has since been filled with a value

•Changed: The proposed value for at least one field in the subordinate levels of the hierarchy has been changed from the SAP default value.

•Manual: You maintained at least one authorization in the subordinate hierarchy levels manually (it was not proposed by the Profile Generator).

Effect of SU24 changes in Role Groups

•Authorization objects are maintained in SU24 for a particular transaction code. When a transaction code is added to role, only the authorization objects having check as check indicator value and yes as proposal value, maintained for that tcode will be added into the role group.

•

1)  Adding Tcodes to a role

When a new Tcode is added to a role

•When a new tcode is added to a role, going in either change authorization data or expert mode provides the same result. All the authorizations maintained for the tcode at SU24 level is added to the role.

•The program adds new standard authorizations for  objects in the roles If the authorization default values contain objects that

were previously not existing

Or only had authorizations in the status Changed or Manual

•A new standard authorization is not included

if the authorization fields contain identical authorizations in the status Standard in both authorizations, and the fields maintained in the old authorizations are empty in the new standard authorization.

If there were already authorizations in the status Maintained (active or inactive) or Inactive Standard before the merge, the program compares the values and the maintenance status of all authorization fields to determine whether new standard authorizations must be extended.

Changing SU24 values for a tcode

If the authorization data is changed for any tcode in SU24 and tcode is already present in the role, then going in the expert mode with option “read old data and compare with new data” will only reflect the additional changes. Change authorization data will not pull the new data for the tcode maintained at SU24 level

2) Removing Tcodes from the role

When you remove transactions from the role menu, this has the following effect on the authorizations.

•A standard authorization for which the associated transaction was removed from the role menu is removed during the merge, unless at least one other transaction that remains in the menu uses the same authorization default value. This applies both for active and inactive standard authorizations.

•Authorizations in the statuses Changed and Manual are not affected by the merge. They are therefore always retained.

SAP Security Authorizations

The Authorization Concept

Introduction on Authorizations

• Authorization objects enable complex checks of an authorization, which allows a user to carry out an action. An authorization object can group up to 10 authorization fields that are checked in an AND relationship.
• For an authorization check to be successful, all field values of the authorization object must be maintained accordingly. The fields in an object should not be seen as input fields on a screen. Instead, fields should be regarded as system elements, such as infotypes, which are to be protected.
• You can define as many system access authorizations as you wish for an object by creating a number of allowed values for the fields in an object. These value sets are called authorizations. The system checks these authorizations in OR relationships.

Authorization:

            Authorization means permission to perform a particular function in the sap system. It is achieved by assigning authorization profiles to users.

Authorization Field:

1.It is an element which requires protection.

2.The is the least granular field against which SAP system is protected.

3.These fields are associated with the data elements of the ABAP/4 dictionary

4.This is defined in the transaction SU20.

5.Data Element: It is least granular element which has a valuable name defined by length and type.

Activity:

1.It is defined the type of action which can be performed an authorization field.                                                                                                                                 Example: Create, Modify, Delete, Display, Approve, Save, Reverse, Print, etc.

2.Activities are defined in the table.

Authorization Object:

1.     R/3 uses authorization objects to assign authorizations to users.

2.     An authorization object is a template for an authorization.     

For example, authorization object F_SKA1_BUK - G/L Account: Authorization for company codes requires the specification of two field values: Company Code and Activity. To allow a General Ledger supervisor to create a general ledger master record, he/she must be assigned an authorization to create (Activity 1) accounts for a specific company code (eg. Company Code 2000). Such an authorization is created using the object F_SKA1_BUK by assigning these field values and naming the authorization following an appropriate convention (eg. Z_SCC20001).

3.     The Authorization object defines an activity that needs to be protected in the SAP System.

4.     An authorization object groups together upto 10 authorization fields that are checked together in an authorization check.

5.     Authorization objects are defined in transaction SU21  (Most are in-built)

Object Class:

1.     Depending on Application Area, Group of relevant authorization objects are grouped into an object class.

2.     These are defined in transaction SU22.

Authorizations:

1.     Authorization is used to define permitted values for the fields of an authorization object.

2.     Authorizations are defined in SU20.

Authorization Profiles:

1.     As a rule authorizations are not directly assigned to a user. Instead these authorizations are clubbed in an authorization profile and are then assigned to the user master records.

2.     A group of not more than 150 authorizations is called an authorization profile.

3.    Before 4.6c version, profiles created manually in SU02. From 4.6c onwards, profiles are generated using Profile Generator.

Composite Profile:

1.    A group of authorization profiles (sap_all, sap_new)

2.    These are used for administrative purpose, however when it exceeds more than 150 authorizations , another profile will be created and generated.

Role:

1.     Role is the group of Profiles, menus, transactions, reports and user assignments and personalization.

2.     Roles are defined in Transaction code PFCG

3.     Roles are called as Activity Groups until 4.6c

Types of Roles:

1.Single Role

           i.  Parent Role or Role

           ii. Derived Role  or  Child Role

2.    Composite Role

Figure: Role Types

 

SAP Security Tables

Table	Description	Notes
AGR_1016	Role and Profile
AGR_1016B	Role and Profile
AGR_1250	Role and Authorization data
AGR_1251	Role Object, Authorization, Field and Value
AGR_1252	Organizational elements for authorizations
AGR_AGRS	Roles in Composite Roles
AGR_DEFINE	To See All Roles (Role definition)
AGR_HIER2	Menu structure information – Customer vers
AGR_HIERT	Role menu texts
AGR_OBJ	Assignment of Menu Nodes to Role
AGR_PROF	Profile name for role
AGR_TCDTXT	Assignment of roles to Tcodes
AGR_TCODES	Assignment of roles to Tcodes
AGR_TEXTS	File Structure for Hierarchical Menu – Cus
AGR_TIME	Time Stamp for Role: Including profile
AGR_USERS	Assignment of roles to users
DD02L	SAP Tables
DD02T	R/3 DD- SAP table texts
DD03L	Table Fields
DD04T	Data element texts
TDDAT
TSTC	SAP Transaction Codes
TSTCA	Transaction Code, Object, Field and Value
TSTCT	Transaction Code Texts
USER_ADDR	Address Data for users
USGRP	User groups
USGRPT	Text table for USGRP
USH02	Change history for logon data
USOBT	Relation transaction to authorization object (SAP)
USOBT_C	Relation Transaction to Auth. Object (Customer)
USOBX	Check table for table USOBT
USOBX_C	Check Table for Table USOBT_C
USOBXFLAGS	Temporary table for storing USOBX/T* chang
USR01	User Master (runtime data)
USR02	Users Data (logon data)
USR03	User address data
USR04	User master authorization (one row per user)
USR05	User Master Parameter ID
USR06	Additional Data per User
USR10	Authorisation profiles (i.e. &_SAP_ALL)
USR11	Text for authorisation profiles
USR12	Authorisation values
USR13	Short text for authorisation
USR40	Table for illegal passwords
UST04	User profiles (multiple rows per user)
UST10C	Composit profiles (i.e. profile has sub profile)