This 9-part blog series for SAP offers valuable insights into dealing with security and audits. Security and compliance are hot topics these days, which is why SAP Insider sat down with the SAP experts at Fastpath for a webcast Q&A and answered questions on everything from audits involving non-SAP systems in an SAP landscape to the ownership of a company’s security program and its budget.
Security and Compliance for SAP, Part 9: How Using Single and Composite Roles Affect SoD Conflicts
With SAP’s built-in functionality, supported by technology like Fastpath and experts in security, you can take the pain out of the process. By implementing processes, taking a risk-based approach, and getting the right controls in place, you can meet the demands of your auditors and ensure you have a top-notch security program. The series so far includes:
- Part 1: Using processes and a risk-based approach
- Part 2: How to handle custom transaction code
- Part 3: How to talk to auditors about non-SAP systems in an SAP landscape
- Part 4: Granting user access – who, why, and how much
- Part 5: Ownership of your security program and its budget
- Part 6: Cybersecurity is important, but don't forget about internal threats!
- Part 7: Using Fastpath With SAP GRC And Non-SAP Identity Management Solutions
- Part 8: Comparing risks between SAP ECC and SAP CRM
Part 9, the final blog in the series, discusses single and composite roles for security.
SAP Security: How Single and Composite Roles Affect SoD Conflicts
When you create the roles in the profile generator in your SAP system, composite roles are groups or collections of how you will prorate. This might be an area in itself, but the composite roles themselves aren't contained in the specific objects that are needed in SAP to provide the access.
Let’s say those are contained in single roles. They are used both to determine when a user enters a transaction and what authorization objects are behind that transaction. It's just an easier way to create users within the system.
At Fastpath, we come in at the single rule level because that's where the actual security is contained, but we also have the information with the method between the two. It shouldn't affect your SoD conflicts, whether you use single composite roles or whether you use inherited roles. With this approach, the only thing that will be considered is determining what that user can do in the system, which is the ultimate goal. That then provides us with the access we need to compare it to the rules set, which can help your SoD no matter what roles you use.
This blog series was designed to provide some expert opinions on how to make security audits less frustrating, regardless of what software you use.
If you’re using SAP, you have the advantage of built-in functionality that helps. Ultimately it boils down to having processes in place, taking a risk-based approach, and having the right controls in place to not only allow you to meet the needs of your auditors, if that situation applies, but also to make you more efficient and allow security not to be a burdensome task—and instead to be one that fits well into existing business processes and allows your IT team to easily manage, so they can get back to their day jobs.