The following pages provide an overview about the various phases of an SAP NetWeaver IDM project.They provide guidelines about the implementation tasks associated with the corresponding phases and where to find documentation about each task.
At the beginning of 2018, with Spectre (and Meltdown), a new class of vulnerabilities was published. In the following months, new variants have been discovered and published under the same pseudonym. Ongoing research and publication of new vulnerabilities and attacks suggest that the topic will continue to be relevant in the future. The common denominator of these vulnerabilities is that they are mostly caused by the architectural (hardware) design of the CPU that affects nearly every computer chip manufactured in the last 20 years. These vulnerabilities could, if exploited, allow attackers to gain access to data previously considered protected. Possible attacks are called side-channel attacks, in which the execution speed (timing) of certain operations could allow the removal of memory contents that are normally not accessible. From a security perspective, concerns include the breaking of boundaries within virtualized environments.
AP thoroughly investigates the impact of these vulnerabilities and is closely aligning with corresponding vendors, providers, and the Open Source community. SAP works on investigating if, where, and how our platforms, databases, applications, and cloud operations are affected.
SAP is taking a proactive approach and is fixing potential flaws derived from hardware side-channel attacks without undue delay. You can find more information on our patching progress for our Cloud environments (registration required). As a consumer of affected software and hardware, we largely depend on the availability of patches provided by respective vendors, providers, or the Open Source community. The schedule of applying appropriate patches is, to a large extent, determined by their availability. Each variant was given its own CVE number (updated August 14, 2018):.
L1 Terminal Fault (, and ). Variant 4–Spectre NG. Variant 3a–Spectre NG. Variant 3–Meltdown. Variant 2–Spectre Variant 1–Spectre Each of these vulnerability variants may be exploited to read confidential data such as CPU or kernel memory.
The level of criticality and potential for exploitation differs between each of the variants. Further vendor information about before mentioned security vulnerabilities, resources and responses:. Please note that SAP is not liable for any content on these external sites. All implementation results are for informational purposes only and the examples provided while based on actual SAP customers’ experiences do not represent commitments or guarantees by SAP and/or its partners. Actual pricing, costs, and implementation results may vary, based on customer-specific requirements and needs. The only warranties for SAP products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.
SAP authorization can be both straightforward and confusing at the same time. To make it easy to understand let’s put things this way: The SAP ERP is composed by ABAP programs, which have access groups and access objects, so in order to successfully access the programs a user must be granted the necessary authorization objects (more details in “Trace and Definition” section). Whenever the user invokes a transaction, it will execute the necessary checks in authorization objects and will execute the program or deny it. Simple right? Not that fast let’s now see how this can get confusing. Imagine you are in a project with ABAP developers creating specific programs and functional consultants to implement a new SAP functionality. A lot of SAP Notes are applied, many programs and new features are added to SAP and you have to grant permissions in the best way possible while still making the system reliable and compliant.
To achieve such goal, there are some things to consider, which are basically: Security context creation/revision – With the help of key users and functional consultants, create the necessary security context. Business rules – What each person should be doing Trace and definition – Investigate what users need to perform their activities Risk assessment – Is the trace accurate? Does the user really need everything identified in the trace?
Is it compliant with regulations and laws? Security context creation and revision This is basically conceptual and yet very important. If you already have a security context defined, this is the time to review it and check whether all people involved are still suitable for the job, i.e: Key Users. If you don’t have anything and will start now, depending on the security context you design you’ll either have a lot of efforts to maintain user authorization or you can have a very simple and well defined authorization structure.
Sap Security Implementation Guide (djsig)
This is similar to data modeling, if you don’t expend enough time on it, you’ll suffer the consequences later. Personally, I recommend to evaluate what each individual will be doing on their daily activities in their departments and break it down and group in Roles.
Sap Security Requirements
Once you have all the roles that user will need, create a Composite Role and assign all the roles inside this brand new composite role. By doing this you will gain flexibility when the user moves to another department, because you can simply revoke the composite role and assign a new composite role containing a subset of roles that the end user will need to perform his new activities. Basically when this is done, you will have clearly defined what composite roles belong to what department or group of users. Write this security context as a policy and formally agree with business leaders. You can keep as simple as a spreadsheet with only the necessary information (example below). The user groups can be created/updated in this step.
You can go to transaction SU01 and select the menu Environment – User groups – Maintain There you can create or maintain user groups. Business Rules Once you know the way you will handle authorization assignments based on the security context established/reviewed in the first step, it is time to sit with key users and business leaders to understand what people are doing what and start mitigating activities.
For example, an finance analyst can perform a payment but cannot approve it. Who can manage master data and what specific information is necessary, i.e: create a vendor with finance details such as bank account and specific tax and rates. Basically in this step you will fill the second and third column of the sample spreadsheet (Composite Role and Roles).
To make it easier to us (tech dudes), I recommend to have a functional consultant or a high skilled key user to sit with you and the business people in order to understand and agree on how each task will be done in SAP, this will facilitate a lot the next step which is the reproduction, tracing and effectively defining authorization within SAP. Trace and Definition Since we now have everything clearly defined, let’s go effectively to the technical side of authorization. Remember in the beginning of this post where it was mentioned that in order to access programs, the users must have access to authorization object. To confirm this, lets go to transaction SE93 and have a look in the transaction MIRO: Looking at the picture above, we can understand that: When the user access the transaction MIRO, the Authorization object MRECHWRK is checked and the user must have access to the field ACTVT=01. If all the conditions are met, the user can access the program SAPLMR1M which is the actual “MIRO”. This check could also happen inside the ABAP code, using the keyword “ AUTHORITY-CHECK”. Here is an example on how that works embedded in the ABAP code: Okay, now it is clear how authorization checks works in SAP but looking at every program, function, reports and etc to simply create the necessary roles would be a never ending job that nobody would do, so let’s get to the solution: tracing!
My approach here is as simple as: connect to a TEST ENVIRONMENT and grant SAPALL profile to that functional consultant or expert key user: Once he connects to SAP, go to transaction ST01 and start the trace. Select Authorization Check, in the general filters, type the user account and finally hit “ Trace on” Then ask him to perform the activity needs, example: View vendor information. Once he finishes, stop the trace by hitting the button “ Trace off” and then hit “ Analysis”. You should now select the username, authorization check and execute. Now you have a report containing every single access the end user will need to perform the activity “View vendor information”.
With the result of the trace you can create a role that can be assigned to end users. The creation of the role is beyond the scope of this particular topic because it is already too big. You can go visit for a step by step guide on role creation. Risk Assessment Auditing SAP is tough and should be done on a regular basis to avoid surprises and headaches in case of external auditing. The actual auditing of the system is beyond the scope of this post because there are many ways and tools (Virsa, AIS, GRC, etc) to help with this and will vary from company to company. To effectively perform a risk assessment, get the current scenario of who is doing what and review it with the key users. They will be able to confirm or suggest changes to access levels.
If a risk is identified and cannot be treated by the system, it should be mitigated somehow i.e, periodic audits in specific activities. Once you have a snapshot of the current scenario, it’s time to go back to the first step and review the authorization concept and adapt the necessary changes. Hope this post can give you a high level authorization concept for system administration. Although SAP was the system mentioned in the whole post, this concept can be easily adapted to any other systems.