In this article written by Tamara Rivera, member of our team of consultants specialized in SAP© and SAP© GRC security, we will address authorization restrictions to be considered in a SAP© Human Resources system (HCM: Human Capital Management).
An HCM system contains very sensitive information from a personal data protection perspective (there are regulations focused solely on ensuring the processing of personal data such as GDPR). Therefore, it is important to understand that we must focus not only on editing permissions but also on viewing permissions.
Regarding Custom Transactions, it is important to analyze them and confirm if they have all the necessary checks based on the transaction’s functionality, in order to perform the necessary restrictions at the authorization level, as well as include them in the risk matrix if they allow viewing or modifying sensitive information, thus keeping them monitored.
Focusing on standard transactions and checks, we would have two types of authorization assignments:
- Direct Assignment: Through roles, relating roles and users.
- Indirect Assignment: Through structural profiles, relating users to the organizational structure of the company.
Direct Assignment
This type of assignment is the same as in ECC environments; we create the roles through the PFCG transaction and assign them to users from SU01.
Below, we will list the main common restrictions between HCM and ECC environments:
- At Transaction level: Classify transactions in roles, based on functionality and taking into account the risk matrix.
- At Job Position level: Define the different job positions of the company and classify users in them in order to define composite roles that facilitate the management of the role model.
- At Table level: Define and limit access to modify and view tables. Since an HCM system has certain very sensitive information, it is advisable, in some cases, to restrict tables not only through the S_TABU_NAM object but also through S_TABU_LIN by restricting specific columns, in order to hide certain critical fields of a table. (More detail in the technical article: “SAP© Table Restriction Objects“).
The main restrictions to be taken into account particularly in an HCM system, going down to the authorization object level, would be the following:
HR Master Data (P_ORGIN)
It is the best-known authorization object in a SAP© HCM system. This object checks all accesses to administration infotypes and time management, technically speaking, all accesses to tables that begin with the prefix PA.
HR Master Data – Extended Check (P_ORGXX)
The P_ORGXX object allows for broader management than the P_ORIGIN object. A new “SACHA” field is introduced that allows for more advanced restriction that we could not do through “P_ORIGIN”.
HR Master Data – Personnel Number Check (P_PERNR)
It is an object that can be used to manage the permissions of administration and time infotypes of other personnel numbers except for the user’s own. For example, being able to modify all salaries except their own. PSIGN field with letter “E” (Authorizations excluded for the assigned personnel number).
HR Cluster (P_PCLX)
Clusters are a form of complex data storage that was widespread in “classic” SAP© HCM. The more recent components of the HCM system increasingly omit Cluster storage and use tables instead.
Personnel Management Record (P_PCR)
The personnel control record (transaction PA03) is the central control tool for payroll. This object verifies the payroll area permissions and limits activities to viewing or changing.
Personnel Planning (PLOG)
The name of this object is confusing, as it not only applies to this area (Personnel Planning) but, technically speaking, to all database tables that begin with HRP.
HR Reporting (P_ABAP)
This object was created to improve system performance, in relation to read permissions of master data authorization objects. This object allows restricting or disabling checks of certain reports.
HR Candidates (P_APPL)
“Classic” recruitment has been replaced by the new “E-Recruiting” components. However, it is still in use and subject to maintenance.
Of the objects mentioned above, the most important authorization field would be Infotype (INFTY). For this field, it is important to define for each user/job position both the Infotypes that they should have access to view and modify, and create the associated roles. It is recommended that these be “Enabler Roles”, that is, roles that have objects but not transactions, and that work in combination with roles that contain transactions to generate the fewest possible number of roles, making the model more manageable.
Other important fields to pay attention to and that are more commonly restricted would be the Personnel Area (PERSA) and Payroll Administration (SACHA).
Indirect Assignment
This type of assignment is totally related to the organizational structure of the company, registered in the PPOME transaction. Through this type of assignment, we can limit that they can view or modify the accesses assigned through roles (direct assignment mentioned in the previous section) only for certain areas of the company, for example, for legal department users.
In this case, we will define the structural profiles through the OOSP transaction and assign them to users through OOSB. It is important to activate the structural profiles through the OOAC transaction for them to work, otherwise no matter how much we design them and assign them to users, they will not work.
Through this transaction (OOAC), we can also activate context objects. These are objects that end with the letters CON, for example: P_ORGINCON and P_ORGXXCON, and that add a new field to the original objects (P_ORGIN and P_ORGXX). This field is the Authorization Profile (PROFL):
By activating these objects, the system allows us not only to assign specific transactions to a user, with a restriction to specific infotypes or personnel areas (through roles) for the department of the organizational structure to which they belong (through structural profiles), but it also combines these two restrictions for users who may perform a dual function, allowing to indicate the structural profile defined in the new PROFL field and limit some accesses (infotypes, personnel areas…) for a specific department/job position and other specific accesses for other departments/job positions.
For example, a user who belongs to the payroll area and must be able to make modifications to infotypes associated with “Payroll Status”, but is responsible for certain people for whom they need to view all information related to “Absences”:
Key Points
- Make a good initial definition of the necessary restrictions, both at the level of Direct Assignments (View or Modify: Transactions, Tables, Infotypes, Authorization Fields…) and Indirect (Structural Profiles).
- Organizational Structure well maintained in the PPOME transaction. In order to perform a correct restriction by structural profiles.
- The tables to review authorizations related to structural profiles are:
- T77PR – Relationship of structural profile vs Accesses
- T77UA – Relationship of structural profile vs Users
- If you want to use structural profiles or context authorizations, it is important to remember to activate them through the OOAC transaction.
- Use context authorizations (objects ending in CON) to be able to combine restrictions at the role level (infotypes, personnel areas, payroll administration…) and departments/job positions defined in the organizational structure.
If this article has been useful to you or you are interested in SAP HCM services, do not hesitate to contact us by clicking here. Our team of specialists in SAP© and SAP© GRC security is ready to help you with customized solutions adapted to the needs of your organization.