Excluding production, I’m regularly astonished by lax Security and Controls in SAP Landscapes. With S/4HANA, astonishment becomes concern.
I’m not talking about the blatantly obvious; no, we don’t regularly see SAP_ALL granted in Development systems as in days of yore. It’s more subtle than that, but perhaps not by much.
No matter whether security roles in Development systems are rudimentary or draconian — neither extreme is helpful — insufficient attention is usually paid to differences between development, customizing, and master data. Well-considered laxity is one thing, but skipping the holistic view is a recipe for avoidable trouble.
Security and controls (and SAP client strategy) must be recognized as a team effort in which functional team members necessarily have a voice in establishing requirements.
Three immediate examples come to mind (otherwise there wouldn’t be a blog post, eh?).
- Protecting Standard Code
- Protecting Development Customizing Client
- Protecting Master Data
Example # 1: Protecting Standard Code
What’s the risk? Core modifications performed without visibility and controls.
Plainly said, with S/4HANA, avoiding core modifications has become your responsibility.
With S/4HANA on-premise, beginning with 1511, you need to take action. Have a look at SAP Note 2309060 – The SSCR license key procedure is not supported in SAP S/4 HANA.
So-called Developer Keys and Modification Requests no longer figure in restricting core modifications to your SAP S/4HANA system. It’s up to you to implement such controls as your organization deems necessary by some combination of security authorizations and business process.
Have you acted by implementing a process? Or are your systems vulnerable to core modification on the whimsey of any development resource?
Example # 2: Protecting Development Customizing Client
What’s the risk? Unexpected customizing and master data in Customizing Golden client.
As a general rule, technical resources (developers) shouldn’t have access to change customizing, and functional resources shouldn’t have access to change development objects. But the challenge is more nuanced than these simple rules suggest.
In the case that a single client serves both Development and Customizing, it’s important that Developers create no data in the Customizing Golden client. That typically means that Developers should not be unit testing code in the Customizing Golden client.
A complex way to enforce this separation of duties is to implement comprehensive security roles and procedures, which will change frequently and ad hoc over the course of an implementation project. I’ve seen this; hence the word “draconian” in the opening paragraphs. It’s a surefire way to impede project progress, although embedding security team members in the project for real-time response provides some mitigation.
The simplest way to enforce this separation is to use separate clients for Development and Customizing. Development resources are segregated to a dedicated client for development and technical testing. Only Functional persons with customizing duties are granted access to Customizing Golden client.
The argument against this client strategy will be that the dedicated Development client may lack customizing found in the Customizing Golden client. What’s more, the dedicated Development client may lack master data found either in the Customizing Golden client or in a Unit Test client. Either or both of these predictable issues might impede development productivity.
These arguments are valid, but I find neither especially compelling because I value explicit risk avoidance more than possible inconvenience. This is also true because these arguments are equally true for the Development system Data Migration client. Your customizing and master data procedures should address all clients; there isn’t a new or unique concern raised by implementing a dedicated Development client.
Example # 3: Protecting Master Data
What’s the risk? Unexpected master data changes in Customizing Golden client.
What’s the risk? Unexpected production master data changes in Customizing Golden client, with changes flowing to Production.
This risk should be recognized distinctly from Example # 2: Protecting Development Customizing Client, although the commonality is the Customizing Golden client. The reason for distinction is that a subset of individuals usually have responsibility, not the Functional team writ large.
I wrote briefly about Master Data in Customizing Gold: WHAT and WHY, which explains that master data is sometimes appropriate in a Customizing Golden client. In fact, in SAP Retail it’s common to have production master data maintained in the Customizing Golden client as a production process, because Site Master Distribution is Best Practice in S/4HANA.
Regardless of why, but acutely in the case of production master data, what security and controls have been planned and implemented to protect master data?
As with Example # 2, implementing controls could be complex or perhaps simplified by client strategy.
- SAP Managed Tags:
