The Remodel Users are granted access in SAP to perform business transactions – users need to have access to roles and authorization objects in order to do so. At Fastpath, we call these combinations of t-codes and auth-objects Business Processes. T-codes…
The Remodel
Users are granted access in SAP to perform business transactions – users need to have access to roles and authorization objects in order to do so. At Fastpath, we call these combinations of t-codes and auth-objects Business Processes.
T-codes are assigned to roles to provide access for the user. Profiles are created on these roles to include authorization objects. These authorization objects provide another layer of provisioning.
Custom transactions add an additional complex element into the provisioning process. Custom t-codes can access authorization objects that, on the surface, perform functions which do not appear to relate to their name and description. These custom transactions, in the hands of the wrong programmers, can be setup to call transactions behind-the-scenes, which is virtually undetectable. Often, while managing the access controls in an SAP instance, we discover transactions that called other transactions behind-the-scenes at the eleventh hour that led to significantly too much access. In turn, we were forced to audit the details of everything that had been done throughout the year using that heightened level of access.
Finally, the concept of “role bleed” is always a concern in your environment. The unintentional consequence of granting an individual read-only access to an area of high risk, can combine with write access in another module causing one role to bleed into another. This increased level of access can result in individuals having inappropriate access without detection.
Access Controls in SAP
Let’s get down to brass tacks – we’ve covered why you should care, what you should care about, and how SAP works. Now it’s time to put all those ingredients together into the same soup!
Risks and Pitfalls
SAP security is complex – many consider SAP to be the most complex ERP system regarding access administration. Authorization objects, t-codes, administrative access, BASIS access – and it’s all in German to boot! Poor application of the basic principles of access management combined with a hard-to-understand access model, and you can see how easy it is to end up in a predicament. Let’s talk about what good habits you can put in place to avoid these pitfalls.
As previously mentioned in the first article in this series, many companies can make the mistake of casually provisioning access by copying previous roles. A role in SAP is just a combination of t-codes and authorization objects – the name on the front shouldn’t be trusted, even if it reads “Inquiry Only”! Even when access is setup effectively to begin with, it is very common for this model to degrade over time, resulting in an access model with issues. Annual reviews and clear policies can help you avoid the risk of backsliding.
The second largest driver of risk is job change. As any administrator will tell you, the hardest part of maintaining a system is regulating users! The controls to manage new users on the front end are clear, and can be subject to solid scrutiny. When someone leaves a company, there is usually enough noise to encourage effective user removal. It’s the piece in the middle that often goes overlooked. Movement through an organization, especially where change is common, often leaves users with ‘artifacts’ in the system – access that no longer applies to their job description. The aggravating factor here is poor design of access review controls – often the right person isn’t reviewing access, or they may be assigned but are blowing through the review on a Friday afternoon! Depending on how much your company is changing, consider upping your frequency of review to head off problems at the pass.
Separation of Duties (SOD)
Separation of duties (SOD) was introduced in Part 2. Remember how we talked about SAP’s complexity – well, it rears its head again in SOD. Because there are so many moving pieces, and because of ‘role bleed’ organizations rarely realize that their users can create a vendor and pay a vendor, or modify bank data and create a payment. SOD conflicts can be created via the combination of transactions or even the transaction / authorization object combination. Regular SOD reviews are being driven by the PCAOB and external audit firms. Annual reviews are the least a company can do, remembering to review the assumptions used to define the company’s ruleset.
Critical Access and Configuration
Critical access means “who can modify what” in the system. Who can change workflows? Who can open and close periods? Who can modify vendor master data? Who can change HR bank account information? Oftentimes the answer to these questions is surprising – and if discovered because of fraud or an audit, the answer can be downright terrifying.
The next article in this series will discuss tools that can be used to assist the execution of these controls. If you missed the first two articles in this series check them out, Why Care About SAP Access Controls and SAP Access Controls: An Audit Introduction
