The big balancing act: SAP security for support & development teams
The age old quandary of striking the balance between user enablement and business control via role and authorisation design is never more prevalent that when talking about support/ development access.
I’ve had many interesting discussions on the subject over the years and been in some pretty tense meetings where stakeholders on both sides of the argument can easily be up in arms about the way this ends up going in their company.
In this latest in my series of posts about real life problems that clients engage me in, I’ll explore the key points to consider when managing support access.
Potential risks of wide ranging access
It’s obvious, granting wide access to SAP support/ development teams is a double edged sword. On one hand, it enables agility and speed of response. On the other hand, it poses significant risks to your system's integrity. I’ve been thinking about the pros and cons:
Pros:
🤝 Rapid issue resolution.
🤝 Enhanced efficiency/ productivity.
Cons:
🚩 Increased vulnerability to security breaches.
🚩 Potential for unauthorised changes.
🚩 More SoD conflicts.
A note on SAP_ALL
Once upon a time you could be sure if you checked the access permissions of the support/ development team that at least some of them would have SAP_ALL. This has certainly got better over the years, and we’ll continue to fight the good fight on this but say it quietly, if you look closely enough there will still be some of these lurking in many development or test systems. It’s the easy way out of providing access to support/ development teams if it’s a struggle to define the access the team needs but is definitely not the right answer.
Cross system SoD
For organisations not already on top of managing production single system SoD risks, thinking about cross system conflicts between development/ production systems is next level stuff.
Imagine this scenario: A developer has access to both the development and production systems. They inadvertently deploy a change that disrupts critical business processes. Or worse, they develop something that was unapproved and they go on to use it in production for their own means. This seemingly harmless overlap of access can lead to business risk in the form of:
🚩 Financial losses due to downtime or fraud.
🚩 Compliance violations.
🚩 Reputational damage.
🚩 Errors, emissions and control breaches being covered up
SAP GRC FireFighter and how this fits in to the picture
I know not everyone has access to this tool and that there are other similar solutions out there (ask me about them) but this subject isn’t complete without mentioning it.
From the support/ development teams' perspective, FireFighter can be a lifesaver, offering on-demand access to perform urgent tasks whilst the business feels there’s more control offered by providing access through it. However, it's not without its challenges:
👷♂️ For support/ development teams, FireFighter can provide quicker access for critical tasks, deliver improved accountability and reduce delays. On the flip side, we’ve seen where an over reliance can lead to bottlenecks and due to the control offered by the tool, it’s easy to get drawn into over using and abusing it.
👔 From the business control perspective, using FireFighter offers peace of mind. It allows for better oversight and auditability but will cause additional work in checking logs to ensure access is used appropriately.
Striking the balance: Perspectives from both sides of the argument
When it comes to managing access for support/ development teams, a thoughtful approach is crucial. Let's examine two contrasting viewpoints:
👷♂️ Support teams:
They’ll thrive on quick and unhindered access enabling them to promptly resolve issues, implement updates, and drive solutions. It enables agility and responsiveness, crucial for today’s fast paced business environment.
It’s a strong case but is it the right answer though? Not on my watch. Let’s explore the other side of the argument and what I’d rather do to adjudicate on this issue...
👔 Business control:
From a business perspective, ensuring security and compliance is paramount. Closer control over access helps mitigate risks and is hands down the right thing to do.
The Solution: my roadmap to finding the common ground
Striking the right balance between wide access and closer control is not an either-or proposition. It's about finding common ground aligning with your specific needs and risk tolerance. A winning formula here is having well defined access policies on this, automation where possible for SoD checks/ providing enhanced access, robust monitoring and collaborative dialogue between IT teams and business stakeholders to ensure security measures don't impede progress but rather facilitate it.
In conclusion, the debate over access control is not a binary one. It's a delicate balancing act that requires a nuanced understanding of both perspectives.
#SAPSecurity #AccessControl
