Emergency access management is the process to grant temporary critical access privileges in IT systems required to execute an exceptional task and review the system activities performed by the privileged users during that time. This process is a frequent target during system audits as it typically reveals vulnerabilities in the following areas:

• An all-or-nothing approach in the design of emergency access privileges exceeding required privileges to tackle a given exceptional situation by far.
• Business owners hardly involved in the approval and review of emergency access.
• A review of system activities executed with emergency access privileges often is not an auditable process.

Additionally, a tendency to grant business users excessive access privileges to tackle all kinds of rather exceptional situations, such as period-end closing activities or master data maintenance, often leads to segregation of duties (SoD) issues throughout their access privileges.

The centralized emergency access management capability of SAP BusinessObjects Access Control 10.0 addresses these vulnerabilities and has been significantly improved in the current release. Critical access privileges for different purposes are assigned locally in your SAP systems to a set of firefighter IDs, each one owned and supervised by individual owners and controllers in the responsible business departments. Business users can submit access requests per workflow to obtain access to these firefighter IDs. The responsible owners approve the requests triggering automated provisioning. All maintenance of the assignments between firefighter IDs, owners, controllers, and firefighters — that is, business users with access to firefighter IDs — is done centrally in SAP BusinessObjects Access Control.

When firefighters encounter an exceptional situation that requires additional access privileges, such as urgent tasks in system maintenance or exceptional master data changes, they log on to the SAP BusinessObjects GRC system hosting the SAP BusinessObjects Access Control application and from there initiate a session with a firefighter ID in the affected SAP system. During the firefighter session, the activities executed are logged in a detailed consolidated log report. Once the firefighter ends the session, the consolidated log report is sent per workflow to the controller responsible for the firefighter ID to approve all actions taken during the session as logged by the system. All workflow steps during the approval of the access request as well as the review of the consolidated log report are recorded in a detailed audit trail. I examine each of these steps and their required configuration in more detail.

Meet the Prerequisites

Assuming that the SAP BusinessObjects Access Control application and the GRCPINW plug-in on each remote SAP system have been correctly installed and all necessary post-installation steps have been performed according to SAP’s installation guide, you still need to complete a few additional prerequisites:

• Make sure that you’ve created for each remote SAP system a system connector and assigned it by following IMG menu path GRC > Common Component Settings > Maintain Connection Settings to the Integration Scenario SUPMG.
• Create user IDs in the remote SAP system to become your firefighter IDs. Assign critical roles or profiles to them as needed for later emergency access. Finally, assign the predelivered role SAP_GRAC_SPM_FFID. This role tags the user ID as a firefighter ID. You can also replace this role with another one, but you need to change parameter 4010 accordingly in the SAP BusinessObjects Access Control configuration settings found in the IMG.
• Once you create all firefighter IDs in the remote SAP systems, you need to synchronize them into the SAP BusinessObjects GRC server by executing the program GRAC_ROLEREP_USER_SYNC in incremental mode.
• Optionally, implement a user exit according to SAP Note 1545511.

Configure New Firefighter IDs Centrally

Owners of firefighter IDs decide who should have access to their firefighter IDs and can delegate in the system the task to review and approve consolidated log reports to controllers. Both the owners and the controller should be business users associated with the business area that is most affected by the access privileges of their firefighter IDs. Only then can they best adopt responsibility for their firefighter IDs and have enough knowledge to effectively review the consolidated log reports.

As administrator, you turn an SAP BusinessObjects GRC user into an owner or controller of a specific firefighter ID as follows:

• Assign respective roles according to Table 1. You should copy the listed roles into the customer name space and assign the copied roles to users.
• Register them as SAP BusinessObjects Access Control Owners of type Firefighter ID Owner and Firefighter ID Controller, respectively, in the application navigating in the SAP NetWeaver Business Client front end to Access Management > GRC Role Assignments > Access Control Owners (Figure 1).
• Select an SAP BusinessObjects GRC user who is set up as a firefighter ID owner and add the firefighter IDs this user should own. This step is done in Access Management > Super User Assignment > Owners (Figure 2). You can assign multiple owners to a given firefighter ID.

Table 1

Users with required roles in the SAP BusinessObjects GRC system

Figure 1

Register SAP BusinessObjects GRC users as SAP BusinessObjects Access Control owners

Figure 2

Assign firefighter IDs to owners

Typically, the owners have the authority in the system to assign controllers to their firefighter IDs. They do it in Access Management > Super User Maintenance > Controllers and also select how the controllers receive the consolidated log reports: by workflow, just by email, or only via log display of the system. Here, workflow is clearly the preferred option as it ensures an auditable approval process.

Whenever a firefighter starts a firefighter session, the firefighter needs to choose a reason code from a list of available reason codes for the selected system. Reason codes categorize the incidents that require emergency access with a firefighter session. Typical reason codes are System Maintenance or Quarter End Closing. The administrator creates reason codes in Access Management > Super User Maintenance > Reason Codes. You can assign these codes to multiple remote systems (Figure 3).

Figure 3

Maintain reason codes

Manually Assign Firefighter IDs to Firefighters

You are now ready to grant firefighters access to firefighter IDs. Ensure that all firefighters have a user ID in the SAP BusinessObjects GRC system with the required roles according to Table 1. You can assign firefighters to firefighter IDs manually without invoking workflow by navigating to Access Management > Super User Assignments > Firefighters IDs. Select a firefighter ID and assign one or multiple firefighters (Figure 4). I recommend associating a criticality to the firefighter ID. The criticality controls workflow routing in access approval workflows and consolidated log report review workflows. Note that all changes made to assignments among firefighters, owners, controllers, and firefighter IDs as well as to reason codes are tracked and can be viewed in the change log report shown in Figure 5. This report is available in the SAP NetWeaver Business Client front end navigating to Reports and Analytics > Access Management.

Figure 4

Assign firefighters and criticality to a firefighter ID

Figure 5

A change log report showing all changes made to firefighter ID assignments

Request Firefighter IDs via Workflow

A more efficient way to manage access to firefighter IDs is leveraging access request approval workflows. Firefighters simply create an access request of request type Superuser Access, add the firefighter IDs they need into the request, and then submit the request (Figure 6). Creating a request template for this purpose facilitates this step. You can configure any kind of request routing and approval logic, but the most common scenario is a simple one-stage workflow with the owner being the only approver.

Figure 6

Request a firefighter ID using an access request with request type Superuser Access

To understand in a few words the required configuration for this scenario, you need to know the basics of Multistage-Multipath (MSMP) workflow configuration leveraging the Business Rule Framework Plus (BRF+) for SAP BusinessObjects Access Control 10.0. I have covered this topic in my article, "Take Full Advantage of SAP Business Workflow in SAP BusinessObjects Access Control 10.0." Here is a brief summary:

• Create an initiator rule based on a BRF+ flat rule for the process Access Request Approval Workflow that routes requests of type Superuser Access along a separate path.
• Create this path consisting of a single stage and select the predelivered GRAC_SPM_OWNER as Agent ID (Figure 7). Remember to maintain the route mapping for this path with respect to the initiator rule in the next step of the workflow configuration tool. The agent ensures that each requested firefighter ID is sent by the workflow to the inbox of its owner for approval.

Figure 7

Create a path consisting of a single stage for firefighter ID owner approval

Initiate a Firefighter Session

Once firefighters are granted access to a firefighter ID, they can initiate a firefighter session at any time and repeatedly. They need to log on to the SAP BusinessObjects GRC system via the SAP GUI and use transaction code GRAC_SPM. The transaction lists all firefighter IDs that have been granted to the logged-on firefighter (Figure 8). When the firefighter clicks a Logon button next to one of the firefighter IDs, a pop-up appears to select a reason code and provide further details with regard to the reason and the anticipated actions in the system during that session (Figure 9). Once the firefighter clicks the check icon to confirm the details in the pop-up screen, a new session window opens up allowing access to the respective remote SAP system with the access privileges of the selected firefighter ID. The firefighter can now execute all required actions in this session.

Figure 8

Initiate a session with a firefighter ID

Figure 9

Select a reason code and provide further details on reasoning and anticipated actions

For the duration of the session, the status of the firefighter ID turns red, meaning that it is not available to other firefighters (Figure 10). In urgent cases other firefighters can submit a message to the active firefighter via the Message button or even click the unlock icon visible in their views of transaction code GRAC_SPM to terminate the firefighter session of their colleague. The Additional Activity button remains active during the firefighter session and allows firefighters to add activities that they didn’t anticipate during initialization of the session. As soon as firefighters close the session window, the firefighter session ends, and the firefighter ID becomes available again to other firefighters. At this point, the firefighter ID status turns green again.

Figure 10

The firefighter ID remains locked for other firefighters during the session

Approve Consolidated Log Reports by Workflow

The key report in the context of emergency access management is the consolidated log report because it lists activities and changes to master data executed during firefighter sessions as recorded by the remote SAP system. You need to generate the consolidated log report before it can be displayed. This procedure known as log collection runs typically as a periodic background job in the SAP BusinessObjects GRC system using the program GRAC_SPM_LOG_SYNC_UPDATE. Owners and controllers of the respective firefighter ID can then access the consolidated log report in three ways:

1. Delivered by workflow to the inbox of responsible controllers or other approvers
2. Delivered by email as a text file attachment
3. Displayed directly in the system navigating to Reports and Analytics > Super User Management Reports > Consolidated Log Report (Figure 11)

Figure 11

Superuser management reports

Only the first option organizes the log review as an auditable process as it includes an approval step in the workflow — usually executed by the responsible controllers. Figure 12 shows an example of a consolidated log report delivered as a workflow item. The controller can add notes and attachments to the consolidated log report providing further evidence. Click the Submit button to trigger the approval.

Figure 12

A consolidated log report delivered as a workflow item to the inbox of the responsible controller

Again, with a reference to my earlier article on MSMP workflow configuration, I very briefly summarize the required workflow configuration for this scenario:

• In the MSMP workflow configuration tool select the workflow process SAP_GRAC_FIREFIGHT_LOG_REPORT and use the predelivered initiator rule GRAC_FFLOGREPORT_INITIATOR.
• Create a new path consisting of a single stage and select the predelivered GRAC_SPM_CNTRL_AGENT as Agent ID. Remember to maintain the route mapping for this path in the next step of the workflow configuration tool. The agent ensures that the consolidated log reports for individual firefighter sessions are sent as individual workflow items to the inboxes of the responsible controllers.

Review the Content of Consolidated Log Reports

The consolidated log report is an enhancement available with SAP BusinessObjects Access Control 10.0. The enhanced log report contains more detailed data on actions executed in the system during firefighter sessions. It combines the data recorded by the remote system in separate log files, as summarized in Table 2, and allows for combined or segmented views of the data.

Table 2

Content and limitations of the consolidated log report

It is important to understand that SAP BusinessObjects Access Control isn’t creating any logs on its own. Instead, it relies entirely on an application server logging of the remote SAP system (Table 2). Another limitation is the fact that the consolidated log report does not include table logging (e.g., changes made in table maintenance transactions such as SE16 to tables that are set up for logging). You can use transaction SCU3 to view the table change log if you activated table logging in your application server by setting the system profile parameter rec/client accordingly.

View Other Reports

Besides the workflow under Reports and Analytics > Super User Management Reports, SAP BusinessObjects GRC users can view a number of other reports to supervise emergency access (Figure 11):

• Invalid Super User Report: This report lists all users (firefighter, controller, owner, firefighter ID) that are expired, locked, or deleted.
• Firefighter Log Summary Report: This report lists firefighter sessions with details. Reported data is also included in the consolidated log report.
• Reason Code and Activity Report: This report lists all firefighter sessions, including the descriptions for reasoning and activities as entered by the firefighter in the pop-ups shown in Figure 9.
• Transaction Log and Session Details: This report lists transactions executed during firefighter sessions. Reported data is also included in the consolidated log report.
• SoD Conflict Report for Firefighter ID: This report lists SoD violations for firefighter IDs, including the execution count and the time stamp of last execution for all conflicting actions found.

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.