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 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|
|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.
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|
* 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).
User has to go from plugin/backend system (R3PRD001) and log into a GRC System (GRCPRD001), execute GRAC_SPM(OR EAM) -> which will launch the EAM launchpad -> then access the system [R3PRD001 or something else (HCMPRD001), (CRMPRD001) etc] assigned to him/her by clicking the logon button-> perform FF tasks.
User has to stay on the BackEnd system (R3PRD001) execute /n/GRCPI/GRIA_EAM -> which will launch the EAM launchpad -> then click the logon button to start a session in the very same system (R3PRD001) and perform FF tasks. You can enable DC-FF by parameter 1000: GRD(RFC Connector pointing to itself), 4015.
|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:
|Configuration in a nutshell|
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).
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.