SAP Security and Authorization Concepts

R/3 audit review questions.

Here is a list of items most commonly reviewed by internal/external auditors when

reviewing your R/3 system.

It is always a good idea to review this list a couple times a year and to take the
appropriate steps to tighten your security.

Review the following :-

* System security file parameters (TU02) (e.g. password length/format, forced password
sessions, user failures to end
session etc.) have been set to ensure confidentiality and integrity of password.

Security-Parameter-Settings-Documentation

* Setup and modification of user master records follows a specific procedure and is
properly approved by management.

* Setup and modification of authorizations and profiles follows a specific procedure and
is performed by someone
independent of the person responsible for user master record maintenance.

* An appropriate naming convention for profiles, authorizations and authorization objects

has been developed to help
security maintenance and to comply with required SAP R/3 naming conventions.

* A user master record is created for each user defining a user ID and password. Each
user is assigned to a user group, in
the user master record, commensurate with their job responsibilities.

* Check objects (SU24) have been assigned to key transactions) to restrict access to those
transaction.

* Authorization objects and authorizations have been assigned to users based on their job
responsibilities.

* Authorization objects and authorizations have been assigned to users ensuring

segregation of duties.

* Users can maintain only system tables commensurate with their job responsibilities.

* Validity periods are set for user master records assigned to temporary staff.
* All in-house developed programs contain authority check statements to ensure that
access to the programs are properly
secure.

Select a sample of :-

* Changes to user master records, profiles and authorizations and ensure the changes
were properly approved.
(The changes can be viewed with transaction (SECR).

* Ensure that security administration is properly segregated. At a minimum there should

be separate administrators
responsible for:

- User master maintenance. (This process can be further segregated by user group.)

- User profile development and profile activation. (These processes can be further
segregated.)

* Verify that a naming convention has been developed for profiles, authorizations and in-
house developed authorization
objects to ensure:

- They can be easily managed.

- They will not be overwritten by a subsequent release upgrade (for Release 2.2 should
begin with Y_ or Z_ and for
Release 3.0 by Z_ only.)

* Assess through audit information system (SECR) or through a review of table USR02,
whether user master records have
been properly established and in particular:

- The SAP_ALL profile is not assigned to any user master records.

- The SAP_NEW profile is not signed to any user master records. Verify that procedures
exist for assigning new
authorization objects from this profile to users following installation of new SAP
releases.

* Assess and review of the use of the authorization object S_TABU_DIS and review of
table authorization classes
(TDDAT) whether :-

- All system tables are assigned an appropriate authorization class.

 - Users are assigned system table maintenance access (Through S_TABU_DIS) based
on authorization classes
commensurate with their job responsibilities.

* Assess and review of the use of the authorization objects S_Program and S_Editor and
the review of program classes
(TRDIR) whether:

- All programs are assigned the appropriate program class.

- Users are assigned program classes commensurate with their job responsibilities.

* Ensure through a review of a sample of :-

- In-house developed programs that the program, code either:

- Contains an Authority-Check statement referring to an appropriate authorization object

and valid set of values;

or

- Contains a program Include statement, where the referred program contains an

Authority-Check statement referring to
an appropriate authorization object and valid set of values.

I think an auditor would want to know what methods you are using to approve who gets
what profile and what method you are using to document it so that if you review your
documentation you could compare it with what authorization the user currently has and
determine if the user has more authorizations (roles) than he has been approved for by the
approval system in place

Frequently Asked Questions on Authorization

Role & Profile

What is the difference between role and a profile?

Role and profile go hand in hand. Profile is bought in by a role. Role is used as a
template, where you can add T-codes, reports..... Profile is one which gives the user
authorization. When you create a role, a profile is automatically created.

What is the use of role templates?

User role templates are predefined avtivity groups in SAP consisting of tyransactions,
reports and web addresses.
What is the different between single role & composite role?

A role is a container that collects the transaction and generates the associated profile. A
composite reole is a container which can collect several different roles

What profile versions?

Profile versions are nothing but when u modify a profile paarameter through a RZ10 and
generate a new profile is created with a different version and it is stored in the database.

Is it possible to change role template? How?

Yes, we can change a user role template. There are exactly three ways in which we can
work with user role templates
- we can use it as they are delivered in sap
- we can modify them as per our needs through pfcg
- we can create them from scratch.
For all the above specified we have to use pfcg transaction to maintain them.

Personalization Tab Within PFCG

Please expalin the personalization tab within a role.

Personalization is a way to save information that could be common to users, I meant to a

user role... E.g. you can create SAP queries and manage authorizations by user groups.
Now this information can be stored in the personalization tab of the role. (I supposed that
it is a way for SAP to address his ambiguity of its concept of user group and roles: is
"usergroup" a grouping of people sharing the same access or is it the role who is the
grouping of people sharing the same access?)

How to insert missing authorization? Ways?

su53 is the best transaction with which we can find the missing authorizations.and we can
insert those missing authorization through pfcg.

Table of authorisation field settings

Is there a table for authorisations where I can quickly see the values entered in a group of
fields?
In particular I am looking to find the field values for P_ORGIN across a number of
authorisation profiles, without having to drill down on each profile and authorisation.

AGR_1251 will give you some reasonable info.

Table with deleted users

Someone has deleted users in our system, and I am eager to find out who. Is there a table
where this is logged?

Debug or use RSUSR100 to find the infos.

Run transaction SUIM and down its Change documents.

How can I make T_Code SPRO Read Only

I have a requirement to make SPRO read only. As you know it has a tree like structure
and to make it read only seems like impossible.

You cannot make SPRO 100% display only by ANY setting. The SCC4 option only turns
configuration tables to not-modifyable but still allows the non-config delivery class tables
(or those configured to be changeable) to be modifed. It does nothing for the tcodes that
are NOT table maintenance and not controlled by S_TABU_DIS. These will still allow
configuration. All the tcodes in the SPRO are in several tables CUST_ACTOBJ
(spelling?) is one.

You only real option is to create a role with all the tcodes in them that are in the SPRO ,
remove the create and change to display ( generally by changing the last nunmer on the 4
digit tcodes to 3) and removing all the Create and change access in all the activities and
allow only the display.

PFCG allows you to create a role from a SPRO project so the usermenu will come close
to the SPRO menu, which your changes it will be display.

Mass Delete of Old Roles

How can i do a mass delete of the roles without deleing the new roles.

There is a SAP delivered report that you can copy, remove the system type check and
run. To do a landscape with delete, enter the roles to be deleted in a transport, run the
delete program or manually delete and then relase the transport and import them into all
clients and systems.

It is called: AGR_DELETE_ALL_ACTIVITY_GROUPS.

To used it, you need to tweak/debug & replace the code as it has a check that ensure it is
deleting SAP delivered roles only. Once you get past that little bit, it works well