Skip to Content
0
Former Member
May 28, 2007 at 09:43 AM

Making existing roles watertight for HR data

16 Views

Hello,

I hope to get nudged in the right direction in here. I already descended pretty much to the end of my rope and ... well ... I need some more rope ๐Ÿ˜Š

The situation is like this - I inherited everything that has to do with maintenance of authorizations on our system half a year ago, the guy that did that before me is no longer in the company (so there's no use in asking what he was thinking (if anything) when he was putting the roles together). Documentation is scarce/non-existing. When it exists it's usually not up to date. I'm not exactly a newbie in authorizations field, but at the same time I'm not really that far away from being a newbie yet, so I'm not beyond listening to basics being pointed out to me.

<u>The Utopia</u>:

There are five single roles built for all users of our system (say R1, R2, ... , R5). They're supposed to build on one another, R1 being the basic role, R2 having a couple more authorizations than R1, and so on until R5 which is the role that also has all HR authorizations.

<u>The Reality</u>:

The roles have been designed in a hurry and from the top down starting with the sap_all profile and removing some (or most of the) CA, BC and HR authorizations. They were not properly tested. They do not derive from one another in any way ... R2 for example is a complete copy of R1 with some additional objects and values, same for all the others. Every problem needed to be fixed five times, once for every role. That of course resulted in chaos, things got changed just in one place and the basic role suddenly got more powerful than all the rest. These roles are in use in the production system and there are no plans to substitute them with something better in the very near future.

<u>The Problem</u>:

Suddenly (yeah, right ๐Ÿ˜Š) the need arose to have these roles watertight with regard to HR data. I did some rudimentary testing and sure enough they're nowhere near watertight even for the most common HR transactions. There are ranges defined in S_TCODE for which I have no idea why they are as they are, there was access to SA38 given where SAP HR programs with no authorization group (and no transaction code) assigned could be run by everyone ... there's god knows how many other security holes. The only help I got from the HR consultants was the list of all 2000 or so HR transactions (taken from the SAP menu tree) which shouldn't be accessible to a normal user. I suspect I might be in need of a typing monkey to check them all five times ๐Ÿ˜Š

<u>Question</u>:

How do I close as many security holes in these roles as possible? What's the strategy when dealing with such tasks? I've made it clear to the management that we probably won't have watertight roles if we don't create new ones, but making a set of new roles created properly from the bottom up is out of the question at this moment.

I'd be extremely grateful for any advice or if anyone could point me to any kind of documentation about making roles like ours more secure for protecting HR data (and also keeping the users away from any BC stuff).

In the meantime, I'm off to searching through the archives of the forum.

ursa