The Emergency Access Management (EAM) component of SAP Governance, Risk, and Compliance (SAP GRC) provides the technical foundation to administer and manage firefighting or emergency access.
Technically, you can use either a Firefighter ID (a dedicated user identity with elevated authorizations) or a Firefighter role (a role associated with the specifics related to the Firefighter concept). The activities performed with either the Firefighter ID or role are logged. For logged activities, we focus on transaction logs (captured from Transaction STAD—business transaction analysis), change logs (changes related to change document objects recorded in tables CDHDR and CDPOS), system logs (the system log information related to debug and replace as per Transaction SM21), security audit log (captures the defined events from Transaction SM20), and operating system (OS) command logs (capturing changes to OS commands from Transaction SM49), and last, but not least, the log of table changes (insert, update, delete, as per table DBTABLOG).
Aside from some technical configuration for the implementation of the SAP Access Control solution, it is important to understand that logs for the Firefighter are available for only table changes if general table logging is activated. Table changes are not logged by default.
Think of tables as cassettes. They come with the technical capability to record. When you put a cassette into a recorder, this would still not be sufficient for recording unless you press the record button. This is similar in the SAP business application.
You must activate the table logging setting for the selected clients. The activation is realized through the system parameter rec/client (see figure below). This parameter should have the entry ALL or entries for individual clients, whereas the entries for client 000 (basic client) and the entry for the productive client are minimum requirements. The setting can be checked via Transaction SE38 by entering the report RSPFPAR and then selecting the parameter rec/client.
This system parameter covers the table changes that result from only changes within the SAP business application system directly. Changes resulting from transports (for example, imports of customizing tables from the development system, by way of test system to the production system) are not covered. The transport profile parameter RECCLIENT is also activated, which can be checked with Transaction SE38 and report RSTMSTPP, by selecting the RECCLIENT setting (shown below). For a production system, it is best practice to log changes in all clients by setting the parameter value to ALL. The absolute minimum requirement is the productive client, of course. For a development or quality system, the minimum requirement is to log the client 000 and any clients from which transports result into production.
It is important to understand that the Firefighter log records the changes mentioned earlier; it does not provide a display logging or similar. Therefore, it is not something like a gapless monitoring solution of all SAP business application activities. Instead, it focuses on change activities performed with the elevated authorizations.
What is considered firefighting or an emergency? The answer depends on whom you are asking. As a rule of thumb, you should not use firefighting to cover for poor planning or an inadequate authorization concept.
The Firefighter (as seen in the table below) is not a standalone concept. If you are writing logs, then you would expect that someone also review the logs. You would also not grant access to a Firefighter ID to every individual employee in your company. However, because of the elevated authorizations that you associate with firefighting, you want to ensure that Firefighter access is assigned based on a justifiable reason, especially to trained individuals.
Consequently, you need a decent and stable concept to manage emergency access.
The business process owner responsible for the affected business areas own the Firefighter IDs or roles. In the example, the Firefighter can request a Firefighter ID (by using the ARM solution) for a limited time. With the request, the potential Firefighter must provide a justifiable reason. The Firefighter Owner receives the workflow item with the request and reviews and approves it. A notification is sent to the Firefighter, and the Firefighter can start using the Firefighter ID. All change activities are logged from the moment the Firefighter logs on with the Firefighter ID. After the emergency case is resolved, the Firefighter logs off with the Firefighter ID. The Firefighter Controller receives a workflow item and notification, including a log of all performed changed activities for sign-off.
As part of regular internal and external audits, a responsible auditor will review the process and check the logs to ensure that reasoning and usage are consistent.
The table below lists the reports for EAM.
The EAM module can support the following approaches:
- A centralized firefighting approach, where the SAP Access Control solution is the entry point.
- A decentralized firefighting that allows us to use the EAM launchpad directly on the plugin backend business application systems to perform firefighting activities in case the SAP GRC system is not available.
Editor’s note: This post has been adapted from a section of the e-book Introducing Governance, Risk, and Compliance (GRC) in SAP S/4HANA by Marie-Luise Wagener.
Comments