prevent changes to package and contents

[Former Member]

I have been asked to investigate locking down packages and their contents. We have our framework code and wish for devs not to be able to alter it. We have looked into the editor locks and transport locks but they do not provide the level of security that we desire. Both allow to be unlocked, taken over or deleted.
What I am doing now, as a dev, is to enhance SAP standard code to do an authorisation check by creating tables with the object names and a category/role required to make changes and another table with user IDs and category/role doing a cross check (as I am a beginner ABAP developer I do not fully understand SAP Authorisation checks and if they can be used in this manner). Surely this has been handled by many companies all over the world and we just need a bit of information.

I am open to all suggestions, process, coding, whatever.

If you have suggestions on where to enhance SAP standard code I would appreciate that also. I am at the moment looking to lock down classes and database tables, I have enhanced SEO_CLIF_ACCESS_PERMISSION which blocks modify, delete and insert to classes (possibly interfaces but I haven't tested) from both SE24 and SE80.
I was hoping there would be a common location for all types and requests but I haven't been able to find one. I also have just started enhancing DDIF_TABL_GET for database tables as this is a common point for SE11 and SE80.

Let me know please.

Regards,

Peter.

[matt]

Seems odd to be giving such a complex task involving modification of SAP standard to a newbie. But whatever.

There is no 100% foolproof way to prevent changes to objects in specific packages. If you have developer access, you can always hack if you want to. (In debug you can skip any security if you have debug change - and you really do need that if you're a developer), so you're relying on people following the rules, and warning them when they've made a mistake.

I would put some code into the CTS_REQUEST_CHECK  BADI, so that when a transport is released, the package of the objects in the transport is checked. If they're in your protected package, then you can issue an error message, and the transport cannot be released. Implement this after you've transported your framework objects to the test system. After that if someone deletes an object, say, when they come to transport, they'll be blocked and the object can be recovered from version management.

You should also put all the framework objects into a single local Transport of Copies, release it, and even keep a copy of the associated files somewhere safe. Then if someone pathologically sabotages your framework, you can recover it very quickly, by re-importing the ToC.

The only other alternative is to have all your protected code in its own /NAMESPACE/  and develop on a separate instance. When the packages are in your main development system, they can only be modified with a key (like standard SAP objects)..

[Sandra_Rossi]

For a "common location", maybe the time of transport request popup is the best one (cf function module TR_EDIT_CHECK_OBJECTS_KEYS ).

[Former Member]

Thank you for your comments. Turns out that someone else had been working on the solution and has done so with Basis Authorisation Checks.

[Jelena_Perfiljeva]

So maybe you could share the solution and close the discussion then?

Thank you.

[Former Member]

Unfortunately I don't know what the solution is exactly. It is a role authorization.

[JaySchwendemann]

Well this was an anti-climax 🙂 But in any respect the comments mentioning TR_EDIT_CHECK_OBJECTS_KEYS  and CTS_REQUEST_CHECK  where worth the while 🙂 Thanks @Sandra_Rossi and @matt