Dealing with Authorization Groups: Part 1
Authorization groups are a difficult topic to tackle in SAP as they can be considered a double-edged sword. With proper implementation it’s possible to take security to the next level, however if not properly implemented, authorization groups can lead to usage issues and can create a false sense of security. These problems arise due to different reasons:
- Lack of understanding on the usage of an authorization group.
- Finding where to set the authorization groups for each function.
- Link with the proper authorization object. And finally,
- Assign the correct values to the right users.
In this post, we will go through some of the most critical and technical authorization groups:
- For RFC Destinations.
- For Tables.
- For Programs.
- For ICF services.
Authorization Groups For RFC Destinations
RFC destinations are very sensitive since they can be used to jump from one system to another. By using this type of authorization group, we can limit each user only to the destinations he requires. The creation of authorization groups for RFC Destinations can be done using transaction SM59 by assigning a value in field "Authorization for Destination". There are two objectives for assigning an authorization to an RFC destination:
- Limit the users who can maintain the RFC Destination: which is related to the authorization object S_RFC_ADM – field ICF_VALUE
- Limit the users who can use the RFC destinations: which is related to the authorization object S_ICF – field ICF_VALUE
In this case, we need to check the systems in which users are responsible for maintaining the RFC destinations, and who those users are. Then, we must group the destinations in a way that is suitable for both, and assign the corresponding values to their roles.
Authorization Groups For Tables
Another sensitive authorization group is the one related to Tables. Giving direct access to tables for display or for updating is a common practice in companies (even though it shouldn't be). The display is usually given through transaction SE16 and the updating with transaction SM30(actually custom transactions are built using transaction SM30 as a mask). So the importance of authorization groups, in this case, is to restrict users from being able to display more information than they should (i.e., Confidentiality issues) or to update other data they shouldn’t be changing (i.e., Integrity problems). The assignment of the authorization group to tables can be done using transaction SE11. In general, this assignment needs to be done on a development system and then transported to production (depending if the client was opened for changes with SCC4 transaction). The related authorization object is the S_TABU_DIS, which has two values: ACTVT (Activity determines the action that can be performed on the tables) and DICBERCLS (Authorization group). There are many other transactions to maintain and many display tables inside SAP as in general companies tend to create table-specific custom transactions. To avoid granting wide access to display tables, the object S_TABU_DIS can be used to separate access. Some tables, however, are in a group by default. To identify all the existing authorization groups, you can list table TDDAT using transaction SE16. Some of the groups that you will find are as follows:
- SS: Security tables.
- SC: User security tables.
- FC*: There are different group starting with FC which correspond to Finance data tables.
- You will see that many tables have the value &NC&, which is the same than having an empty value.
Authorization Groups For Programs
Typically, the access to programs is given through transactions (you link a program with a tcode, and then you assign the tcode to a role). This way users can execute different programs. But there are some situations in which the user requires direct access to the programs. Two very significant cases are:
- Program maintenance: Developers can maintain programs using transaction SE80 and SE38. In these cases, the authorization object checked is S_DEVELOP and the field P_GROUP is the one linked to the authorization group. Using the authorization group we can separate access of the developers and limit the scope of the programs they can maintain. Some companies have different developers depending on the SAP module (FI, SD, MM, etc) or sometimes developers are assigned to maintain the programs which are specific to a certain region or country.
- Job Scheduling: When creating a job it's necessary not only to define steps, but to also select a program for each step. If the program has an authorization group, the user will only be able to select the programs he has permissions to. The authorization object that is checked is S_PROGRAM and the field is P_GROUP.
Creation of the authorization groups for programs can be done through transaction SE38, selecting the "Attributes" option. Same goes for tables, it is very likely that this change needs to be done in DEV and then transported to PRD. ICF Services The Internet Communication Framework (ICF) services can also be secured with an authorization to prevent users from enabling/disabling or maintaining services. It can be set in transaction SICF: The authorization object linked is the S_ICF_ADM. All users who need to maintain a service need the authorization object in their roles. The problem of assigning the values to the correct users is also very delicate, but there isn't a single answer on how to properly do it. The important thing is to involve all the required stakeholders and ensure that each user will receive all the authorizations that he requires, but no more than that. If the user is assigned broad authorizations, the usage of the authorization groups will lose its purpose. On the other hand, if the users are not assigned all values that they require, it could lead to problems while performing their daily tasks. As you can see there are different authorization groups which are relevant for the security of your systems, but it is more important to have a proper, well thought out implementation process as opposed to creating them "on the fly" because an auditor or someone is asking for them. The following steps will help you in that mission:
- Understand the reason for using an authorization group.
- Identify where to set the groups.
- Find the related authorization objects.
- Assign the values to the proper roles taking into account which users need each access.
Another important thing to take into account is that adding the authorization group and granting the access to that group has to be done at the same time. By this we mean transport to Production at the same time. If not, users will loose access and you'll get a mailbox full of complaints. Authorization objects are not limited to technical data, in upcoming posts we will focus on those related to business data, stay tuned!