Making existing roles watertight for HR data

Former Member · ‎05-28-2007

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.

The Utopia:

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.

The Reality:

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.

The Problem:

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

Question:

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

former_member74904 · ‎05-29-2007

well, as you're saying also: there's no better solution than to start from scratch. even though you're saying that management will not be too fond of this idea, but then again they do want watertight roles...

however, on a more pragmatic approach:

to get rid of the most painful security-holes, I would suggest to check the obvious HR authorization objects P_ORGIN and P_PERNR values in the R1 to R5 roles first. this will at least diminish access to sensitive data even though the majority will still have access to the actual transactioncodes.

another 'pragmatic' suggestion would be to do a comparison (Tcode: S_BCE_68001777) of 2 consecutive roles (e.g. R1 and R2 or R2 and R3 etc.) see where the differences occur and get rid of the superfluous or double authorization objects. this way you will end up with the original thought of the building-block theory of the predecessor's roleconcept and make it a litlle more comprehensive.

to me, all this sounds too much like mopping the floor with the water running (dutch proverb which means as much as a waste of time ) since there are no job descriptions for positions and therefore no plan what individual employees are supposed to do and see in the R/3 system.

hope to have helped a litlle, but more importantly: good luck!

Former Member · ‎06-01-2007

Mopping the floor with the water running is a spot on description

Actually we're in the process of setting up new and improved authorizations but (of course!) the testing phase turned out to be much more time consuming than anticipated. No surprise to me, however someone obviously thought authorizations are a matter of defining roles and their menus and the system does everything else by itself. Riiight.

What I did so far - first I educated myself on the specifics of HR authorizations. I never had to deal with those before, so (for example) it was a surprise to me that there's actually a separate SAP course dealing with HR authorizations Then I compared the existing roles to each other like you suggested and figured out a way that allowed me to do all the modifications with least amount of work. I cleaned most of the infotypes out of P_ORGIN and (to cover my behind), adjusted the ranges in S_TCODE to exclude the 2000 HR transactions our HR consultant listed for me.

Most importantly - I made it clear to the guys above me, that with the roles we use I can't guarantee HR data to be inaccessible for people who should stay away from it. So ... back to the testing of the new authorizations

Thanks for your help! It always makes a huge difference to get something like a second opinion when one can't decide if left is better than right or if it's the other way around.

ursa