Emergency access to SAP systems for troubleshooting or problem-fixing purposes often requires critical access permissions that can’t be granted to end users on a permanent basis because they would represent a high risk to overall system security. For this reason, in many cases companies create additional users with extensive access privileges and keep them locked until emergency access is needed to resolve an exceptional situation. Then, an emergency user is unlocked and its password is made available to a specialist who undertakes the required actions in the system.

The process of requesting, approving, granting, and documenting access to an emergency user (and its password) happens completely outside the affected SAP system through different means (e.g., ticketing systems, email, and phone calls). Auditing companies often complain about this practice and demand better control, complete audit logs, and more accountability in this area. Consequently, management procedures for granting emergency access are a typical pain point during an SAP audit.

As one of the four main product capabilities of SAP BusinessObjects Access Control 5.3, Superuser Privilege Management (SPM) provides an audit-proof solution for the management of emergency access to your SAP back-end systems and helps with risk remediation in the context of Sarbanes-Oxley compliance. A particular advantage of SPM is that emergency users are made available up-front to a selected number of end users who could potentially require emergency access. This eliminates time-consuming approval and password transmission procedures during emergency situations. Security and auditability, however, are maintained because the responsible system owners are notified immediately upon activation of an emergency user. All transaction details are recorded in depth, establishing auditing accountability.

SPM runs in a highly integrated fashion with Risk Analysis and Remediation (RAR) and Compliant User Provisioning (CUP), which are both also capabilities of SAP BusinessObjects Access Control (Figure 1). For example, based on best practice or customized segregation of duties (SoD) rules, integration with RAR enables SPM to generate SoD reports listing conflicting transactions executed by emergency users. CUP provides approval workflows and provisioning features for granting up-front emergency user access to end users in a controlled manner, providing complete audit trails.

Figure 1

SAP Business Object Access Control 5.3 and its main product capabilities: RAR, ERM, CUP, and SPM

Technically, SPM comes with two software components: an ABAP component containing the main features of SPM and a Java component for centralized access to audit logs and other reports across multiple SAP back-end systems, each one running SPM.

SPM Back-End Application

The SPM back-end application runs independently of the Java front-end reporting component and is installed as part of the Real-Time Agents (RTAs) that come with the SAP BusinessObjects Access Control installation files. It can run in either a user- or role-based mode. I’ll focus on the more commonly used user-based mode.

First, an SPM administrator uses the user maintenance transaction SU01 to create a number of emergency users in the SAP back-end systems in scope. The administrator then tags them as Firefighter IDs and assigns them to a number of Firefighter ID owners, which are end users that can grant Firefighter IDs that they own to other end users. End users who are granted one or multiple Firefighter IDs, such as the Firefighter in Figure 2, can activate them and work temporarily in their user context (e.g., with their access permissions). They can then execute some exceptional tasks in the SAP system, such as vendor master maintenance in the example. Upon activation, an automatic notification email can be sent to the owner of the activated Firefighter ID. After termination of the session, the system generates a log report containing a complete audit trail and emails it to the owner. The owner can also delegate controlling tasks to controllers and focus on approving requests for super user access. Controllers, instead of owners, would then receive email notifications and check log reports for suspicious actions taken by Firefighter IDs.

Figure 2

SPM optionally sends out notification emails and log reports to owners or controllers upon activation and session termination with a Firefighter ID, respectively

Follow this process of activating a Firefighter ID. End user Fox Wilson has access to SPM and can start it from his user menu. The SPM dashboard lists two Firefighter IDs that have been assigned to him and he can choose from: SPM_FINANCE and SPM_SUPER (Figure 3). He selects SPM_SUPER and clicks the Log on button. In the resulting pop-up screen, he provides a reason for activating the Firefighter ID and information on his intended activities in the system (Figure 4). Then a new modus is opened that runs in the user context of SPM_SUPER (Figure 5).

Figure 3

The SPM dashboard of user Fox Wilson lists two Firefighter IDs

Figure 4

Fox enters a reason for the access

Figure 5

A new modus opens up with the user context of Firefighter ID SPM_SUPER

The status light turns red, indicating that no other end user who has been assigned the same Firefighter ID can use it while Fox uses it. If there are other users waiting for SPM_SUPER to become available again, they can send a notification to Fox via the Message button shown in Figure 3. To avoid such situations, it is a good practice to assign multiple Firefighter IDs with the same access privileges to your end users. This way, multiple Firefighter IDs are available and nobody needs to wait for others to complete their tasks with a particular Firefighter ID.

The SPM back-end application provides a number of reports that track sessions with Firefighter IDs and activities executed with them. The most important one is the log report displayed in Figure 6. It contains a complete audit trail for each session with a Firefighter ID and provides the following information for auditing purposes:

• FFID Owner (owner of the Firefighter ID)
• Firefighter ID
• Firefighter (which refers to the end user who activated the Firefighter ID)
• Session Date
• Session Time
• Reason Code

Figure 6

Example log report in the SAP back-end system

For each transaction executed during the session, the log report contains the:

• Date
• Time
• Application server name
• Transaction code
• Report name linked to the transaction code
• Report title
• Change document information created by the SAP system including Transaction code time, Change document ID, Table, Field text, Old field value, and New field value

Note that SPM does not create additional change documents, but instead uses the standard change documents created by the SAP system for the generation of the log reports. In Figure 6 end user WILSONF has used Firefighter ID SPM_SUPER, owned by user LERCHA, on 12/23/2008 at 15:37:40 providing reason code HELP DESK TICKET. He executed transaction XK02 at 16:09:29 and transaction ME21 about two minutes later. The change documents show that the address information was changed for a particular vendor.

SPM is an audit-proof solution to manage user IDs reserved for extraordinary activities such as troubleshooting and issue fixes. However, it can also be much more than this. Firefighter IDs are created in the same way as IDs for all other users — in user maintenance transaction SU01 — and their access permissions are determined by the roles you allocate to them. For that reason, you can create Firefighter IDs that can handle nothing except master data maintenance or the execution of specific critical transactions needed for period-end closing activities. This allows you to draw away access permissions from your end users and turn SPM into a tool for risk remediation. SoD violations are often caused by access permissions for transactions that happen only a few times in a year or are needed only when some other users are absent. SPM can remediate this class of SoD violations in a very effective manner.

SPM Web Reporting

The SPM front-end reporting component is deployed together with the other SAP BusinessObjects Access Control product capabilities Risk Analysis and Remediation (RAR), Compliant User Provisioning (CUP), and Enterprise Role Management (ERM) on an SAP NetWeaver Application Server (AS) Java 7.0. It can connect to multiple SAP back-end systems and enables auditors to centrally display all the reports generated by SPM in your SAP back-end systems. The following reports are available:

• Log summary report
• Transaction usage report
• Log report
• Configuration change log report
• Reason/activity report
• Invalid firefighter IDs, controllers, or owners report
• SoD violation report

Figure 7 shows the log report as presented by the SPM front-end reporting component. It contains the same data as the log report in the back end, but you can select which SAP back-end system you want to display the log report. It comes with a summary and a detailed view. The latter contains the change documents generated for each transaction during the course of its execution.

Figure 7

Summary view and detailed view of the log report

SoD Violations Report

While the other reports are basically different views of the log reports, the SoD violations report represents an additional feature. It displays SoD violations executed during a session with a Firefighter ID. Generating this report requires an interface to the risk analysis engine and rule sets in RAR.

Figure 8 shows an example for the SoD violations report. In the example, end user WILSONF (who in the report is referred to by the term Firefighter) has executed two conflicting transactions in system DCX — ME21 (create purchase order) and XK02 (maintain vendor master) — while using a Firefighter ID. These two transactions were defined in RAR to represent a SoD risk with the ID P00800W. The report detects these violations from the statistical database of the respective SAP back-end system. The statistical database contains all transactions started by users, regardless of whether an actual update or insert was executed during the course of the transaction. Therefore, the report may contain false positives. However, you can use it to search for indications of fraud committed with Firefighter IDs that you can then verify with the change documents contained in the detailed view of the log report (Figure 7).

Figure 8

SoD violation report in SPM

Risk Terminator

The SoD report uses a utility called Risk Terminator to loop back to RAR and detect risk violations. Risk Terminator comes with the installation of RTAs but is considered part of the RAR product capability. It provides risk prevention on its own and can also optionally introduce a risk analysis in transactions SU01, SU10, and PFCG (if your company still uses these transactions directly). Upon save or role generation in transaction PFCG, Risk Terminator connects to RAR via RFC and initiates an online risk analysis. Risk violations are then automatically displayed before you can save users or generate roles (Figure 9). You can determine how to deal with these risks in customizing, using options such as:

• Risks are only displayed for information purposes
• A comment is required to continue
• Risks have to be remediated first

Figure 9

Risk Terminator detects risk violations preventively

Requesting Super User Access in CUP

Owners can grant access to their Firefighter IDs via manual table maintenance in the SPM back-end application. However, the preferred method comes with a new request type in CUP called Superuser Access (Figure 10).

Figure 10

New request type Superuser Access allows for request, approval, and auto-provisioning of Firefighter IDs

It enables end users to request access to specific Firefighter IDs in multiple SAP back-end systems in the same way they request regular access to your business applications in CUP (Figure 11). A request submission triggers an approval workflow within CUP’s workflow engine.

Figure 11

Requesting Firefighters can select from available Firefighter IDs

In SAP BusinessObjects Access Control 5.3, two additional approver determinators are available: Super Access Owner and Super Access Controller. You can use them for approving requests of type Superuser Access. Owners and controllers are read from the SPM back-end application. However, they must also exist as users in your application server hosting the Java application components of SAP BusinessObjects Access Control and have the pre-delivered UME role AEApprover assigned to them. Figure 12 displays an example for an approval workflow with one approval stage and the approver determinator Super Access Owner. The responsible owner of the requested Firefighter IDs approves the request before it is auto-provisioned in the back-end systems affected by the request.

Figure 12

Example workflow path for super user access requests

SPM Post-Installation Tasks

In this section, I’ll focus on post-installation tasks and customizing to get SPM ready for use. The actual installation of RTAs in your SAP back-end systems and the deployment of the SAP BusinessObjects Access Control Java application on an SAP NetWeaver AS Java 7.0 are beyond the scope of the article.

The post-installation of SPM consists of three main parts:

1. Configuration of SPM in each SAP back-end system
2. Configuration of SPM front-end reporting
3. Configuration of SoD reporting

Configuration of SPM in Each SAP Back-End System

Follow these nine steps to configure SPM in each SAP back-end system.

Step 1. Create an RFC destination of type 3 (ABAP). You only need to provide a description. You do not need to provide other details such as target host and logon or security data.

Step 2. Use transaction SM36 to schedule a background job to run the report /VIRSA/ZVFATBAK hourly. It reads the entries from your SAP system’s statistical database, which is needed to generate the SPM reports. SPM does not display up-to-date results in its reports until this job has run.

Step 3. Create users and assign roles to existing users to build the required users for SPM (Table 1). You can start with some test users, but for a full-fledged implementation you’ll need to agree with all stakeholders in your company about who is going to be an owner or controller and what kind of access privileges should be allocated to your Firefighter IDs.

Step 4. Log on as SPM administrator, start SPM with transaction code /n/VIRSA/VFAT, and maintain the SPM configuration table (Figure 13). In this example, I’m maintaining the table so email notifications will not be sent out to owners and controllers.

Firefighter Owner Additional Authorization and Firefighter Controller Additional Authorization should both be set to Yes so that you restrict owners and controllers to Firefighter IDs to which they were assigned. Otherwise owners could grant Firefighter IDs to firefighters without owning them and controllers could access log reports of Firefighter IDs to which they were not assigned.

Figure 13

SPM configuration table

Step 5. As SPM administrator, you should now create a number of reason codes. To do this, click the Reason Code button shown in Figure 3 to produce the screen shown in Figure 14. Firefighters can then choose from these reason codes when activating a Firefighter ID in SPM (Figure 3). These reason codes also appear in the log reports and serve as categorizations of the various situations that required emergency access.

Figure 14

SPM reason code table

Step 6. As SPM administrator, convert the user IDs created in step 3 into Firefighter IDs as needed by entering their passwords into the SPM security table (Figure 15). The system encrypts the passwords immediately (Figure 16). If you want to prevent Firefighter IDs from logging on via the SAP Logon client with their password, you’ll need to implement a user exit as described in SAP Note 992200. Then Firefighter IDs can only be accessed via logon in SPM, which provides additional security.

Figure 15

SPM security table

Figure 16

The system encrypts the password

Step 7. As SPM administrator, assign Firefighter IDs to owners. Click the Owners button and maintain the table as shown in Figure 17.

Figure 17

SPM owner table

Step 8. Owners or SPM administrators can assign Firefighter IDs to firefighters maintaining the Firefighters table. They can do so by clicking the Firefighters button shown in Figure 3, which will be at the top of the screen shown in Figure 17.

Step 9. Owners or SPM administrators can assign controllers to Firefighter IDs that maintain the Controllers table. They can do so by clicking the Controllers button shown in Figure 3, which will be at the top of the screen shown in Figure 17.

Configuration of SPM Front-End Reporting

You’re now ready to test SPM in your SAP back-end system.

Step 1. Create an administrator role for your SPM front-end reporting component. Log on as an administrator to the User Management Engine (UME) of your SAP NetWeaver AS Java hosting the SAP BusinessObjects Access Control application. Create the UME role FF_ADMIN and assign all UME actions shipped with the software with the Service / Application column equal to FF (Figure 18).

Figure 18

Create an SPM administrator role

Step 2. Create a system connector. Log on as SPM administrator to the SPM front-end component and create a system connector for each SAP back-end system as explained in the configuration guide.

Configuration of SoD Reporting

Now you’re ready to test the centralized front-end reporting component except for the SoD report. I’ll conclude with a few more post-installation steps.

Step 1. Maintain system connectors. As administrator, log on to RAR, navigate to Configuration > Connectors > Search and search for system connectors pointing to SAP back-end systems with SPM set up. Maintain the SAP Gateway in all these connectors. Enter arbitrary, non-repeating names in the Report Names field and check the Outbound Connection check box (Figure 19).

Figure 19

Enable the system connector in RAR for connections from Risk Terminator in the respective SAP back-end system

Step 2. Activate SAP Adapter Servers. As an administrator in RAR, navigate to Configuration > SAP Adapter. You’ll find all system connectors you have maintained in the previous step listed as SAP Adapter Servers and a gray diamond icon next to them. Click each one of them until they all turn green (Figure 20).

Figure 20

Activate the SAP Adapter Servers for the SAP back-end system

The remaining steps have to be executed in each one of your SAP back-end systems.

Step 3. Use transaction SM59 and create an RFC destination of type TCP/IP. Select the activation type Registered Server Program. Enter as Program ID the report name you maintained in the respective system connector in RAR (e.g., BDEFHIJKLM) and maintain the Gateway service field (Figure 19).

Step 4. Configure Risk Terminator in transaction /n/VIRSA/ZRTCNFG (Figure 21). Select CC5X for the CC release to be used and enter the name of the RFC destination you created in the previous step (e.g., AR1GRCCONN). Leave all other settings set to No, unless you want to activate Risk Terminator for user or role maintenance. Otherwise, configure it as needed.

Figure 21

Configuration of Risk Terminator

Step 5. Log on as SPM administrator and add the parameter Connector Id for Risk Analysis to the Configuration table. Assign as Value the ID used in the System field in the RAR system connector (Figure 22).

Figure 22

Add Connector ID for Risk Analysis to SPM configuration table

Frank Rambo, PhD

Frank Rambo, PhD, is managing a team within SAP’s Customer Solution Adoption (CSA) organization working with customers in the SAP analytics area with the objective to drive adoption of new, innovative solutions. Prior to this position, he worked eight years for SAP Germany as a senior consultant focusing on SAP security and identity management. Before he joined SAP in 1999, Frank worked as a physicist in an international research team. He lives in Hamburg, Germany.

You may contact the author at frank.rambo@sap.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.