At some point during your SAP implementation, you will need to look at creating Security Roles for your end users. For the sake of time, I will go ahead and assume that you are at least familiar with SAP Authorization Concepts. If, however, you are unfamiliar with User Master Records, Authorization Objects, or running Transaction Codes such as PFCG, SU24, etc. then you may want to brush up on that first. SAP actually offers some courses on this information, which I have take a part of and found very informative. I would recommend that you at least take the three-day ADM940 AS ABAP - Authorization Concept course.
Designing, or even re-designing, your SAP Security Roles can be a daunting task. Having gone through this myself, and experiencing a handful of SAP module "Go-Lives," I have come up with what I believe to be a successful plan for tackling this particular project.
I. Determine the Business Functions Currently Performed
For each SAP module that you will be designing Security Roles for, you will need to determine what business functions are currently being performed by your business's employees. Some examples of common business functions are as follows:
- Performing check runs
- Creating new vendors
- Issuing payment to vendors
- Creating new SAP users
Keep in mind that this task will require more than just yourself to accomplish. You will need support from business personnel within in function area (Accounts Payable, Human Resources, Materials Management, etc.), along with the help of your business analysts. You should also keep this step very high level, avoiding the pitfalls of trying to build anything within SAP as of yet. Right now, your focus should be only to map out the functions that are utilized by your business. This step, being one of the most critical in this project, can take the longest.
II. Determine how each Business Function will be Restricted
Having mapped out the business functions that are currently being performed, you should now begin looking at how each function will be restricted. As with the previous step, this one will involve the support of key business personnel and your business analysts. In order to best perform this particular step, you should have an understanding of SAP Organizational Levels, such as Company Codes, Profit Centers, Warehouse Numbers, etc. as this is how you will be restricting access for each business function. For example, it may be a business requirement that employees within Company A are not be able to view financial data within Company B, or perhaps warehouse employees at Warehouse X should not be able to modify the inventory of Warehouse Y. These particular restrictions to your business functions are done via Organizational Levels.
III. Determine the Transaction Codes that are Currently Being Used (Optional)
This step is only needed if you are in the process of re-designing your existing SAP Security Roles, and can be skipped over if this is a completely new setup. The need for this step, in a re-design project, is due to the complicated nature of SAP. A re-design project can be quite strenuous during live Production on your SAP systems, and you should try and reduce the risk of leaving out critical access that your employees require. What I like to do is to generate a list using either SAP's Workload Monitor (Transaction Code ST03N) or by taking advantage of SAP GRC's Action Usage reports. With this list, I know for certain what Transaction Codes are being ran by all employees, and I can best ensure that none are overlooked during the Security Role creation step.
IV. Determine what Transaction Codes Comprise each Business Function
Now you can utilize what you determined in Step 1 by mapping out what Transaction Codes go with what business functions. In order to accomplish this step, you will need to work directly with your business analysts as they should have the SAP knowledge that is needed. If you happened to perform the previously listed step, then you can reference the list of Transaction Codes that you determined are currently being used within your system. Regardless, you will need to take the time to work with your business analysts in order to ensure that every required Transaction Code for each business function is mapped to it.
V. Create Security Roles
Using the information that was determined from the previous step, you should now be able to begin creating your Security Roles. You will first need to create Master Roles for each business function, assigning the proper Transaction Codes to each of them. Once these Master Roles have been created, you can then begin creating Derived Roles from each of them, based off of your findings from Step 2. Keep in mind that there will be no user assignment of the Master Roles, as these will only be used as a "shell" from which you will create the Derived Roles. These Derived Roles will be restricted via Organizational Levels, allowing users to only have access to specific business areas for the corresponding job function. For example, you may create a Master Role for financial reporting, and then create Derived Roles for each of your corporate offices. Assigning the Derived Role for Office A to a user only allows them to see financial data corresponding to Office A, and not for any of the other corporate offices. This allows you to better ensure that employees do not end up with access to data that they, otherwise, would not be privy to.
VI. Create Test UserIDs
With all of your Security Roles created, you can now import them into your testing environment. At this time, you can move forward with creating test userIDs. How you setup your test userIDs may vary, as it is dependent on how much time and resources you can have dedicated to the testing process. For example, you may want to have a test userID for each business function, so that you can ensure that the function works correctly from start to finish (e.g. a "Check Run" test userID). Then again, this may be unfeasible if you have far too many business functions. If that is the case, then you may take the approach of creating test userIDs for key business personnel. if you choose the latter approach, then you will need to work with the business in order to determine what business functions, along with what restrictions, that each of these key personnel will need access to.
VII. Test Security Roles
Using the test UserIDs that were created in the previous step, you will now be able to work with the personnel who were chosen to perform testing of your Security Roles. This can be a time-consuming process, as it will involve them testing business functions from start to finish, all the while providing you with screenshots of any errors they may run into (via Transaction Code SU53). You will then have to review these errors and make the necessary changes, keeping documentation of your changes. Typically, this step will take the longest to perform, but it is critical that it is completed thoroughly.
VIII. Determine Required Business Functions for Common Job Role
With the support of key business personnel, you will now need to take a look at each common job role within your business (e.g. AP Clerk, Warehouse Manager, Business Analyst, etc.) and determine what business functions (Refer to Step 1) that they would need access to. For example, maybe all of your AP Clerks need the ability to perform AP Payments, Process Vendor Invoices, etc. Perhaps your business's Warehouse Clerks all need access to perform Goods Movements. The key part to remember during this step is that you are documenting only the business functions that everyone with that job title require. If, for example, you have one AP Clerk who requires additional access, then you would not want to give that particular access to every AP Clerk.
IX. Create Composite Roles
Utilizing the information obtained in the previous step, you can now move forward with creating Composite Roles within your SAP system. For this step, you will be creating a unique Composite Role for each common job role (e.g. Office A - AP Clerk, Warehouse B - Warehouse Clerk, and so on), containing the corresponding Security Roles based off of the determined Business Functions. For example, you may end up creating a Composite Role for AP Clerks located at Office A that would contain access to perform the necessary business functions, with this access being restricted only to Office A's information via the role restrictions you previously determined. By doing this, you can easily ensure that everyone who shares the same job role, and therefore the same job duties, will have the exact same access as one another. This becomes extremely useful whenever you are dealing with new users who need to be setup within your SAP system, as you can quickly assign them the Composite Role that corresponds to their job role. Using Composite Roles also makes it easier to add and remove access if the requirements for each job role change within the business.
X. Perform Risk Analysis on Security Roles
Typically, this step is driven by an industry standard for compliance, such as Sarbanes-Oxley, but it should be considered even if your business isn't required to adhere to any regulatory compliance standard. If you have SAP's Governance, Risk, and Compliance solution setup within your environment, then this step can be easily performed by utilizing the built-in User Level Access Risk Analysis in order to determine if any of your Security Roles and/or employees will have any Segregation-of-Duties (SoD) violations within their access. If, however, you do not have access to GRC, then you will need to spend some time working with your business analysts and key personnel within your business in order to analyze the access that your SAP users will have, based upon the Security Roles you have created. A key thing to remember during this step is that since you have created your Security Roles based on common business functions, you can focus your discussions around the risks associated with those business functions. This prevents discussions from becoming "too technical," yet still allows you, as the SAP Security Administrator, to obtain the information you will need in order to make any necessary Security Role changes.
XI. Resolve Risks and/or Ensure that Mitigating Controls are In-Place
For any SoD risks that were discovered within the previous step, you should work with key personnel within your business, including members of management, to resolve them. Typically, this will involve changing what business functions that particular employee is tasked with handling, so that they no longer have conflicting access. In the event that a risk cannot be resolved this way, possibly due to department size, you will need to ensure that a proper Mitigating Control is in-place. As for creating the Mitigating Control, this is something that will heavily involve the assistance of key business personnel, including certain members of management, as it will be their responsibility to maintain adherence to the details of the Control. Keep in mind that a Mitigating Control does not prevent a risk from being carried out, but instead it shows your business if one has occurred within your system.
XII. Promote Security Roles to Production
At this point, your Security Roles should have been successfully tested within your test environment. Any issues that were ran into during testing should've been resolved, and re-tested for verification. Composite Roles based off of common job roles (e.g. AP Clerk) should exist, and have the correct corresponding Security Roles assigned to them. Any potential business risks have been discussed and resolved, whether by changing the user's access or implementing a Mitigating Control. If everything looks to be complete, you can now receive business sign-off to promote your Security Roles into your Production system. At this time, you can assign your system users with the access that it was determined they would have. If the purpose of this whole project was for you re-design existing Security Roles, then it might be a wise decision to migrate your system users over to your newly designed Security Roles over a period of time.
While I have had success in following this project plan in designing/re-designing SAP Security Roles, you should still try and determine what will work best for your business. Like the majority of SAP-related work, you should tailor this plan to fit your business's needs and requirements. As I've stated many times throughout this, you will need the help from many key individuals from within your business in order to successfully accomplish this project, and you will need to work with them to help take ownership of many of the tasks within it. This is not a project that should be taken lightly, and everyone involved in it should understand that it will take quite some time to fully accomplish, with most of your time spent in the planning stages.
Hopefully these steps will be helpful if you ever find yourself responsible with designing or re-designing SAP Security Roles within your SAP environment. Keep an eye out for future posts where I dive deeper into some of the more technical parts of this project, including the use of a Security Matrix document and many other steps.
Designing, or even re-designing, your SAP Security Roles can be a daunting task. Having gone through this myself, and experiencing a handful of SAP module "Go-Lives," I have come up with what I believe to be a successful plan for tackling this particular project.
I. Determine the Business Functions Currently Performed
For each SAP module that you will be designing Security Roles for, you will need to determine what business functions are currently being performed by your business's employees. Some examples of common business functions are as follows:
- Performing check runs
- Creating new vendors
- Issuing payment to vendors
- Creating new SAP users
Keep in mind that this task will require more than just yourself to accomplish. You will need support from business personnel within in function area (Accounts Payable, Human Resources, Materials Management, etc.), along with the help of your business analysts. You should also keep this step very high level, avoiding the pitfalls of trying to build anything within SAP as of yet. Right now, your focus should be only to map out the functions that are utilized by your business. This step, being one of the most critical in this project, can take the longest.
II. Determine how each Business Function will be Restricted
Having mapped out the business functions that are currently being performed, you should now begin looking at how each function will be restricted. As with the previous step, this one will involve the support of key business personnel and your business analysts. In order to best perform this particular step, you should have an understanding of SAP Organizational Levels, such as Company Codes, Profit Centers, Warehouse Numbers, etc. as this is how you will be restricting access for each business function. For example, it may be a business requirement that employees within Company A are not be able to view financial data within Company B, or perhaps warehouse employees at Warehouse X should not be able to modify the inventory of Warehouse Y. These particular restrictions to your business functions are done via Organizational Levels.
III. Determine the Transaction Codes that are Currently Being Used (Optional)
This step is only needed if you are in the process of re-designing your existing SAP Security Roles, and can be skipped over if this is a completely new setup. The need for this step, in a re-design project, is due to the complicated nature of SAP. A re-design project can be quite strenuous during live Production on your SAP systems, and you should try and reduce the risk of leaving out critical access that your employees require. What I like to do is to generate a list using either SAP's Workload Monitor (Transaction Code ST03N) or by taking advantage of SAP GRC's Action Usage reports. With this list, I know for certain what Transaction Codes are being ran by all employees, and I can best ensure that none are overlooked during the Security Role creation step.
IV. Determine what Transaction Codes Comprise each Business Function
Now you can utilize what you determined in Step 1 by mapping out what Transaction Codes go with what business functions. In order to accomplish this step, you will need to work directly with your business analysts as they should have the SAP knowledge that is needed. If you happened to perform the previously listed step, then you can reference the list of Transaction Codes that you determined are currently being used within your system. Regardless, you will need to take the time to work with your business analysts in order to ensure that every required Transaction Code for each business function is mapped to it.
V. Create Security Roles
Using the information that was determined from the previous step, you should now be able to begin creating your Security Roles. You will first need to create Master Roles for each business function, assigning the proper Transaction Codes to each of them. Once these Master Roles have been created, you can then begin creating Derived Roles from each of them, based off of your findings from Step 2. Keep in mind that there will be no user assignment of the Master Roles, as these will only be used as a "shell" from which you will create the Derived Roles. These Derived Roles will be restricted via Organizational Levels, allowing users to only have access to specific business areas for the corresponding job function. For example, you may create a Master Role for financial reporting, and then create Derived Roles for each of your corporate offices. Assigning the Derived Role for Office A to a user only allows them to see financial data corresponding to Office A, and not for any of the other corporate offices. This allows you to better ensure that employees do not end up with access to data that they, otherwise, would not be privy to.
VI. Create Test UserIDs
With all of your Security Roles created, you can now import them into your testing environment. At this time, you can move forward with creating test userIDs. How you setup your test userIDs may vary, as it is dependent on how much time and resources you can have dedicated to the testing process. For example, you may want to have a test userID for each business function, so that you can ensure that the function works correctly from start to finish (e.g. a "Check Run" test userID). Then again, this may be unfeasible if you have far too many business functions. If that is the case, then you may take the approach of creating test userIDs for key business personnel. if you choose the latter approach, then you will need to work with the business in order to determine what business functions, along with what restrictions, that each of these key personnel will need access to.
VII. Test Security Roles
Using the test UserIDs that were created in the previous step, you will now be able to work with the personnel who were chosen to perform testing of your Security Roles. This can be a time-consuming process, as it will involve them testing business functions from start to finish, all the while providing you with screenshots of any errors they may run into (via Transaction Code SU53). You will then have to review these errors and make the necessary changes, keeping documentation of your changes. Typically, this step will take the longest to perform, but it is critical that it is completed thoroughly.
VIII. Determine Required Business Functions for Common Job Role
With the support of key business personnel, you will now need to take a look at each common job role within your business (e.g. AP Clerk, Warehouse Manager, Business Analyst, etc.) and determine what business functions (Refer to Step 1) that they would need access to. For example, maybe all of your AP Clerks need the ability to perform AP Payments, Process Vendor Invoices, etc. Perhaps your business's Warehouse Clerks all need access to perform Goods Movements. The key part to remember during this step is that you are documenting only the business functions that everyone with that job title require. If, for example, you have one AP Clerk who requires additional access, then you would not want to give that particular access to every AP Clerk.
IX. Create Composite Roles
Utilizing the information obtained in the previous step, you can now move forward with creating Composite Roles within your SAP system. For this step, you will be creating a unique Composite Role for each common job role (e.g. Office A - AP Clerk, Warehouse B - Warehouse Clerk, and so on), containing the corresponding Security Roles based off of the determined Business Functions. For example, you may end up creating a Composite Role for AP Clerks located at Office A that would contain access to perform the necessary business functions, with this access being restricted only to Office A's information via the role restrictions you previously determined. By doing this, you can easily ensure that everyone who shares the same job role, and therefore the same job duties, will have the exact same access as one another. This becomes extremely useful whenever you are dealing with new users who need to be setup within your SAP system, as you can quickly assign them the Composite Role that corresponds to their job role. Using Composite Roles also makes it easier to add and remove access if the requirements for each job role change within the business.
X. Perform Risk Analysis on Security Roles
Typically, this step is driven by an industry standard for compliance, such as Sarbanes-Oxley, but it should be considered even if your business isn't required to adhere to any regulatory compliance standard. If you have SAP's Governance, Risk, and Compliance solution setup within your environment, then this step can be easily performed by utilizing the built-in User Level Access Risk Analysis in order to determine if any of your Security Roles and/or employees will have any Segregation-of-Duties (SoD) violations within their access. If, however, you do not have access to GRC, then you will need to spend some time working with your business analysts and key personnel within your business in order to analyze the access that your SAP users will have, based upon the Security Roles you have created. A key thing to remember during this step is that since you have created your Security Roles based on common business functions, you can focus your discussions around the risks associated with those business functions. This prevents discussions from becoming "too technical," yet still allows you, as the SAP Security Administrator, to obtain the information you will need in order to make any necessary Security Role changes.
XI. Resolve Risks and/or Ensure that Mitigating Controls are In-Place
For any SoD risks that were discovered within the previous step, you should work with key personnel within your business, including members of management, to resolve them. Typically, this will involve changing what business functions that particular employee is tasked with handling, so that they no longer have conflicting access. In the event that a risk cannot be resolved this way, possibly due to department size, you will need to ensure that a proper Mitigating Control is in-place. As for creating the Mitigating Control, this is something that will heavily involve the assistance of key business personnel, including certain members of management, as it will be their responsibility to maintain adherence to the details of the Control. Keep in mind that a Mitigating Control does not prevent a risk from being carried out, but instead it shows your business if one has occurred within your system.
XII. Promote Security Roles to Production
At this point, your Security Roles should have been successfully tested within your test environment. Any issues that were ran into during testing should've been resolved, and re-tested for verification. Composite Roles based off of common job roles (e.g. AP Clerk) should exist, and have the correct corresponding Security Roles assigned to them. Any potential business risks have been discussed and resolved, whether by changing the user's access or implementing a Mitigating Control. If everything looks to be complete, you can now receive business sign-off to promote your Security Roles into your Production system. At this time, you can assign your system users with the access that it was determined they would have. If the purpose of this whole project was for you re-design existing Security Roles, then it might be a wise decision to migrate your system users over to your newly designed Security Roles over a period of time.
While I have had success in following this project plan in designing/re-designing SAP Security Roles, you should still try and determine what will work best for your business. Like the majority of SAP-related work, you should tailor this plan to fit your business's needs and requirements. As I've stated many times throughout this, you will need the help from many key individuals from within your business in order to successfully accomplish this project, and you will need to work with them to help take ownership of many of the tasks within it. This is not a project that should be taken lightly, and everyone involved in it should understand that it will take quite some time to fully accomplish, with most of your time spent in the planning stages.
Hopefully these steps will be helpful if you ever find yourself responsible with designing or re-designing SAP Security Roles within your SAP environment. Keep an eye out for future posts where I dive deeper into some of the more technical parts of this project, including the use of a Security Matrix document and many other steps.
0 comments:
Post a Comment