Best practice lessons: Transporting SAP Security
So, you’ve finally got a handle on securing your SAP systems. You have a good team of experts working on multiple projects, operational tickets and change requests, the design is good, the system is stable, and the end users are happy; life is good. What can possibly go wrong?
One word: TRANSPORTS.
It’s easy to think about transports in a purely positive light, after-all they are just the means in which we security experts move changes/ fixes/ improvements to production. Sadly, it is not that simple and issues with transporting SAP security changes can causes untold pain and reputational damage.
Here we discuss how transporting can cause issues, and how you can avoid these.
(Spoiler alert: Pumpkin has a tool that can help with this)
Let’s start with the scare stories; hold on tight.
Wiping out other people’s changes in Quality or Production systems
One of the most frustrating things for an end user or a project tester is unexpected loss of access, particularly for something that was working the week or the day before.
Because SAP security transports take the latest version of a role this is sadly too common.
Here’s what can happen. Our friendly SAP security expert, let’s call him Sam, has a project to add a new plant to many roles. His change is in the test environment, and as it’s a large project for a new location, it will take some weeks for UAT to complete and for the changes to move to Production.
Along comes another expert, we will call her Carolyn. Carolyn receives an urgent ticket; a Purchasing Director cannot approve an urgent purchase order because he is missing a purchasing group. He is not happy. He is too important to be slowed down by SAP security. Carolyn fixes the issue quickly, and after a quick test in Quality, moves the change to Production.
The user is happy; his issue is fixed quickly, and he can continue on his way unimpeded by us plebs in IT.
However, we have a problem waiting to happen; a smouldering fire about to burst into flames. Four weeks later, Sam’s project finally completes UAT and he gets the greenlight to move his changes to Production.
The bad news is, one of the roles he updated, that sat in the test system for 4 weeks was the same role Carolyn fixed, so when Sam moves his changes to Production, he wipes out Carolyn’s earlier fix, by replacing it with an earlier version of the role.
Needless to say, our Purchasing Director will not be happy the next time he needs to release a PO.
Moving untested or risky changes to Production early
So, we’ve scared you with what can happen with wiping out changes, but the worry doesn’t end there.
A common issue for clients who don’t effectively manage SAP security transports can be equally stressful, and that is people unwittingly moving other people’s changes to Production early.
Our first SAP security expert, Tomasz is making a lot of changes to end user roles, adding all kinds of transactional roles to composite roles. The requirements seem crazy, and because he can almost smell the SoD’s, he’s decided to run a full risk analysis as soon as he’s made the last change so he can explain to the business why some of these roles can’t go together.
In the meantime, Yuliya has a simple change to make, she just needs to add a simple non-sensitive display role to a composite role, unfortunately the same composite role that Tomasz is going to town on currently in development.
Yuliya makes her changes, transports that day and everybody is happy. Meanwhile Tomasz finds multiple critical SoD’s in the composite role and raises this with the business and with internal audit. Weeks of discussions about access levels continue; with everyone completely unaware (until the upcoming audit completes) that these changes made it to Production unwittingly, as part of Yuliya’s perfectly innocent transport.
SAP security will have a hard time explaining how this change reached Production.
Settings to help
Another common issue is SAP Standard behaviour where at the point of transporting in PFCG, ‘single roles in composite roles’ is checked. SAP security people can, without realising decide to transport ALL single roles in a composite, even though they only added one existing role, and transporting single roles is not necessary at all.
This can have a huge impact on the number of transport issues you face; as the more unnecessary roles in transports, the higher the risk of changes being wiped out or ‘not ready’ changes going to Production early.
It is possible to change this default check box and even inactivate it completely; contact us to find out how.
A note on Role Deletions
If you’ve been bitten by this, you won’t be the first SAP security person, so don’t worry.
The issue is simple; if you want to delete some roles, and you want this deletion to be transported, you must save the roles you will delete into a transport FIRST.
Don’t delete all the roles first and then try to figure out how to put them in a transport; only pain and sadness can be found there.
Transporting SU24 Changes; a cautionary tale
Many clients neglect to transport SU24 changes, after all – they are only required in Development, aren’t they? Wrong. Not transporting SU24 can have disastrous consequences, as this horror story will demonstrate.
The client had a nice policy; they used SU24 to futureproof the design and had robust rules such as all custom t-codes needing to have at least one auth object proposal.
Because the SU24 update allowed them to insert the correct objects into their roles, and because the roles were transported, they never bothered with the workbench transport of SU24 updates to their Productive environment.
Years passed. Then one day, the system architect decided to copy the new Development system directly from Production. The same production system that had never received the SU24 updates, meaning the SU24 was utterly unchanged from the SAP Standard proposals of years ago.
The client failed to realise this (it could still have been saved by a complete transport of SU24 from old dev to new dev) and a slow trickle of authorisation issues in Production became an avalanche. Users were losing access they had held for years, and no-one knew why. The client could no longer have faith in any change – adding one transaction to one role could lead to access because removed – because at the point of read and merge – the values that were previously proposed by SU24 were now being ripped out!
Called in to help the client on this very issue, we finally discovered this root cause, and using change history logs, and a lot of painstaking time and effort re-keyed all of the SU24 changes into the new dev system.
Nowadays, this client ALWAYS transports SU24; and so should you.
Documentation in PFCG Long text
See that Long text box in the Description tab in PFCG? Well, we know it’s a nice and calming white space; some refuge from the busy populated fields in the rest of PFCG, but really it shouldn’t stay this way.
We highly recommend keeping a log of change to both single and composite roles here. You can reference the change request number, add some brief words of the change you made along with the date and even a digital signature such as your SAP ID or email address. You don’t have to write war and peace, but a simple overview of the change you made. (Note: please don’t write, ‘add transaction’ or ‘add single role’ please help your security comrades out with a bit more info so they don’t need to look at change history)
This way, even if you are not effectively managing your transports, you can hope that someone changing the same role will notice that a colleague changed the role recently as they add their change to the list.
Documentation here has other benefits, which we will explore in a future blog.
How can Pumpkin help?
There’s a lot more best practice tips we can give on SAP security transports and change control in general and we love to talk about this stuff.
You can diligently check change history and compare role versions in different systems prior to transport, but really you need a transport dependency tool to take the pain away. There are many good transport tools out there on the market.
We don’t want to talk about them; we want to talk about Pumpkins SAP security transport checker, which is simple, cost-effective and quickly implemented inside your SAP development system with a custom transaction that your SAP security professionals can use every time they need to transport in and out of different systems in your landscape.
We will be writing an orange paper (we don’t do white papers) on this topic, so keep an eye out on the blog or website for more info.
If you are interested in discussing how Pumpkin’s transport checker tool can help you avoid some of the pain around transporting or would like to talk best practice when it comes to transporting, we would love to hear from you.
