G’Day All,
Picking up from my previous topic aboutARA - For the new kid on the block, this document is just an overview of my understanding of what EAM is (from what I read here and SAP documentation) and how it works.
The objective of this document is to give people who are just starting out or even beginning to find their feet, a brief overview of EAM before they can get stuck into it and go all in(links provided). This is not intended for people who are well versed on this topic, so if that is you, please feel free to skip it as this might not interest you. However if you do want to stick around and point/correct any mistakes or offer advice/suggestions, please by all means do so. I am open to constructive criticism.
I understand there is a lot of content related to EAM in this site and some of the information covered herein might exist elsewhere in some shape or form however this is just meant to serve as a conduit for freshers, who might get a tad overwhelmed by all the information lying around. So I hope this document can give them a glimpse of what it is all about and then help them to venture out into the wild.
| What is it all about? |
|---|
EAM enables end-users to perform emergency activities outside the parameters of their standard role, but within a controlled and fully audit-able environment. The application assigns a temporary Firefighter ID that grants an end user(firefighter) broad yet regulated access, and logs every activity he/she performs using the temporary ID. This is usually done in emergency situations, where it is imperative for a user to execute certain tasks irrespective of SOD violations and transaction code clashes however all of his/her actions are monitored and recorded making the session completely visible and transparent. |
| Key challenges of EAM |
|---|
- Identification of Business Processes and creating dedicated Firefighter IDs/Roles pertinent to them.
- Identification of the need for usage of Firefighter ID/Role
- Identification of Firefighters, Firefighter Owners, Controllers, and Administrators.
- Identification/Standardization of Reason Codes
- Consistency of naming conventions for Firefighter ID/Roles and Reason Codes.
- Archival policy for the Firefighter Logs
- EAM usage policy should be created to identify tasks which can be positively supported by EAM.
- Last but not least, performance optimization.
|
| Potential functional scenarios for EAM Access |
|---|
Additional resources with additional roles Approaching month/financial year end and need additional resources to speed up certain activities. Additional resources are required but they don’t have enough authorizations. This task can be easily automated by EAM and individual activity log would be generated for later review. Developer access on production system Developer access on production systems is one of the most critical scenarios, but at times it becomes necessary to allow developer access to fix certain bugs urgently. This is an ideal emergency scenario for assigning firefighter id to track each and every activity a developer or a group of developers perform. However developer access on production is never recommended but when you can’t wait for a bug-fix to travel from a lengthy procedure (Dev-Qual-Prod) then EAM works as a mighty mitigation control. Contract user access To maintain track of contract users activities for a certain period of time. This can be achieved by assigning Firefighter IDs to contract users for access on the assigned system. This allows all their activities to be recorded for an extended review and hence management oversight is achieved. Auditor Access Most companies have strict audit procedures in place, which entails both internal and external auditors to conduct audits on a regular basis. Auditors can be granted temporary access through EAM. * By no means is this list exhaustive however it should give you an indication of the potential reasons for EAM Access. * Given the fact that EAM is a form of Mitigation (Please check the ARA document), It is used in scenarios where you have exhausted all other options!!
|
| Firefighter Users, Roles and Responsibilities |
|---|
| Users/FFID/FFROLE | Roles & Responsibilities |
|---|
| Firefighter ID | This is a unique user id, created with specific roles that allow the firefighter to perform the required tasks. So we can create multiple Firefighter id’s with specific roles and assign them to the designated users (Firefighters) for a set period of time. - SU01: Create FFID
- Roles: SAP_GRAC_SPM_FFID (This should be exactly the same in config settings as well. Shown further in the document)
| | Firefighter Role | This is a unique role, which gets assigned to the firefighter to perform the requited tasks. - PFCG/BRM: Create FFROLE. Ensure this role is enabled for firefighting in BRM.
| | Firefighter | These are the users who get assigned with the required Firefighter ID/Role. Firefighter users use Firefighter ID/Role to perform firefighting tasks. - SU01: Create FFighter or assign the role to an existing user
- Role: SAP_GRAC_SUPER_USER_MGMT_USER (This role might need other additional authorizations. Please check the links provided)
| | Firefighter Administrator | This is the person who has got the ultimate authority over the firefighter program. He/she is responsible for assigning FF ID/roles to firefighters (if they choose to), Owners. They can generate reports, ensure reason codes are up to date etc. - SU01: Create FF ADMINISTRTOR or assign the role to an existing user
- Roles: SAP_GRAC_SUPER_USER_MGMT_ADMIN, SAP_GRAC_BASE, SAP_GRAC_NWBC
| | Firefighter Owner | These are the ID/Role owners and are responsible for assigning FF ID/roles assigned to them by the administrator, to firefighters and controllers. They can also act as controllers however they should not be able to assign FF ID/roles to themselves. They can only be one FF Owner per FF ID/role however one FF Owner can have multiple FF ID/roles. - SU01: Create FF Owner or assign the role to an existing user
- Roles: SAP_GRAC_SUPER_USER_MGMT_OWNER, SAP_GRAC_BASE, SAP_GRAC_NWBC
| | Firefighter Controller | These are the people who monitor the actions of the firefighters. They can do this by viewing the log report and can even receive email notifications when a Firefighter logs in. - SU01: Create FF Controller or assign the role to an existing user
- Roles: SAP_GRAC_SUPER_USER_MGMT_CNTLR, SAP_GRAC_BASE, SAP_GRAC_NWBC
|
* All of the aforementioned roles can/needs to be customized. One can use a naming convention that suits their company requirements
AC10 has the option of having either Centralized or Decentralized firefighting (more on this in the links provided at the end of the document). Centralized - Firefighter and his/her respective role has to be maintained in both plug-in and GRC system
- FFID and its respective role has to be maintained only in the plug-in system
- FFAdministrator, FFOwner and FFController and their respective roles have to be maintained in the GRC system
Decentralized - Firefighter and his/her respective role has to be maintained just in the plug-in system
- FFID and its respective role has to be maintained only in the plug-in system
- FFController and his/her respective role has to be maintained both in the plug-in/GRC system(to receive emails of logs)
- FFAdministrator and FFOwner and their respective roles have to be maintained in the GRC system
|
| ID Based vs Role Based |
|---|
One of the key difference between assigning a Firefighter an FFID vs FFRole is added security. An FFID is built with a certain role in mind, which has predetermined tcodes assigned to it and this gets assigned to an end user (firefighter). So if this user wishes to commit fraud, he/she can execute certain tcodes from his/her user id and then the remaining from the FFID. This way the chances of him/her getting caught, is dependent on a thorough monitoring/analysis by the controller/auditors. Whereas if you build a specific firefighter role with the same tcodes, this role gets assigned to the end user not an FFID, so every transaction executed shows up against their user id, which makes his/her task of committing fraud a lot harder if not negligible. key differences are as follows: | ID Based | Role Based |
|---|
Logs in using own user ID, accesses FFID from the GRC System and logs into the system assigned to them(ECC, SRM, CRM etc). | Logs into the plug-in system using own user ID, so everything gets logged against that one ID. Multiple users can use the FFROLE at once. | | Only one user at a time can use a FFID. | Multiple users can use multiple FFRoles at once. | | Firefighter need not exist in every system assigned to them due to central logon however they need to exist in the GRC system (This is only applicable for Centralised firefighting). | Firefighter has to exist in every system assigned to them - so multiple logons. (This is only applicable if the user needs to perform tasks in other systems). | Knows exactly when FFID is being used as he/she has to login so has a psychological effect (good thing). | Hard to differentiate between FF tasks and normal tasks as there is no login required. So easy to slip up. | | Better tracking of FF tasks - Specific log reports with Reason Codes. Bonus point from Auditors! | Time consuming to track FF tasks - No Specific log reports. No Reason Codes. | Two logins so potential to commit fraud. (1 action using own UserID and 1 action using FFID). | Only one login, so everything gets logged against one id(own user id). Harder to commit fraud. | Could be hard to track and find out when a fraud has been committed so can be a problem with auditors. When two logins used | Easy to track as only one login is used however a thorough analysis is required to differentiate ff tasks from normal tasks. | - GRAC_SPM : TCode for Centralised FFighting -> You will see FFIDs assigned to you
- /n/GRCPI/GRIA_EAM : TCode for DeCentralised FFighting -> You can see the FFIDs assigned to you
| - GRAC_SPM : TCode for Centralised FFighting -> You will see FFROLEs assigned to you
- /n/GRCPI/GRIA_EAM : TCode for DCentralised FFighting -> Not applicable so wont work
|
|
| Configuration in a nutshell |
|---|
- Create all EAM users or decide amongst the existing users who gets what EAM role using ‘SU01’
- Create/customize all EAM roles using ‘PFCG’
- Assign those roles to their respective users using ‘SU01’
- Create an FFID/FFRole with the predetermined roles/tcodes using ‘SU01/PFCG/BRM’
- Maintain GRC Plug-In System Configuration Parameters:
- SPRO -> IMG -> GRC (Plug-In) -> Maintain Plug-In Configuration Settings
| Parameter ID | Parameter Value | Description |
|---|
| 1000 | Plug-in Connector ID
| This information is used to connect to the Plug-In system. | | 4000 | ID Based:1 Role Based:2
| Application type | | 4001 | Days | Default Firefighter Validity Period (Days) | | 4008 | Yes/No | Send Firefighter Id Login Notification | | 4010 | Z_SAP_GRAC_SPM_FFID | Firefighter ID role name |
- Maintain GRC System Configuration Parameters:
- SPRO -> IMG -> GRC -> AC-> Maintain Configuration Settings
| Parameter ID | Parameter Value | Description |
|---|
| 4000 | ID Based:1 Role Based:2 | Application type | | 4001 | Days | Default Firefighter Validity Period (Days) | | 4002 | Yes/No | Send Email Immediately | | 4003 | Yes/No | Retrieve Change Log | | 4004 | Yes/No | Retrieve System log | | 4005 | Yes/No | Retrieve Audit log | | 4006 | Yes/No | Retrieve OS Command log | | 4007 | Yes/No | Send Log Report Execution Notification Immediately | | 4008 | Yes/No | Send Firefighter Id Login Notification | | 4009 | Yes/No | Log Report Execution Notification | | 4010 | Z_SAP_GRAC_SPM_FFID | Firefighter ID role name | | 4012 | All Users:1 Controllers:2 | Default users for forwarding the Audit Log workflow | | 4013 | Yes/No | Firefighter ID owner can submit request for FF ID owned | | 4014 | Yes/No | Firefighter ID controller can submit request for FF ID controlled | | 4015 | Yes/No | Enable Decentralized Firefighting |
- Maintain User Exits
- SPRO -> IMG -> GRC (Plug-In) -> Maintain User Exits
- Maintain Connection Settings: SUPMG Integration scenario
- SPRO -> IMG -> GRC -> Common Component Settings -> Integration Framework -> Maintain Integration Scenario
- Activate/Check Criticality Level BC Set
- SPRO -> IMG -> SCPR20 -> GRAC_SPM_CRITICALITY_LEVEL
- Maintain Criticality level
- SPRO -> IMG -> GRC -> AC-> EAM -> Maintain Criticality Levels for EAM
- Run Synchronization jobs
- SPRO -> IMG -> GRC -> AC-> Synchronization Jobs
- Check for the help option to see what does what.
- Schedule Background Jobs for EAM log collection on periodic basis
- SM36 -> GRAC_SPM_LOG_SYNC_UPDATE
- Maintain login/log notifications - only if you want to customize the default ones.
- SPRO -> IMG -> GRC (Plug-In) -> Maintain Custom Notification/Text Messages for EAM (Plug-In)
- Verify Time Zones of the Operating System and the AC server match to ensure EAM logs are captured
- SPRO -> IMG -> GRC -> General Settings -> Time Zones -> Maintain System Settings
- Create/Maintain AC Owners
- NWBC -> Setup -> Access Owners -> Access Control Owners
- Assign FFID/FFRoles to FF Owners
- NWBC -> Setup -> Superuser Assignment -> Owners
- Assign FFID/FFRoles to end users (firefighter) and controllers
- NWBC -> Setup -> Superuser Assignment -> Firefighter IDs
- Create Reason Codes
- NWBC -> Setup -> Superuser Maintenance -> Reason Codes
Once all of the afore mentioned tasks are performed and successful, firefighter can perform firefighting tasks. His/her activities will be logged, which can be monitored by the Controller and viewed by relevant personnel.
* You might encounter problems in regards to FFID not showing up, Logs not getting collected properly etc. Please check the links provided for additional information.
|
|
This pretty much is the gist of EAM. For a more comprehensive understanding/configuration and other bits and pieces on this topic, please check out the links in the following document put together by Alessandro, which covers everything in detail. Please check under Emergency Access Management (EAM).
http://scn.sap.com/docs/DOC-57438
A big ‘Thank You’ to the people who created and made these posts available for the benefit of people like myself. Your time/effort is very much appreciated guys.
Regards,
Leo..