securing SARA transaction advice

[Former Member]

The archiving team uses SARA and other technical transactions in production to archive data, however SARA does not work unless the user is also assigned business-related authorization objects such as M_MATE_WRK and F_BKPF_BUK and countless others (depends what they are archiving)  with ACTVT=06.  But if we associate all these with SU24 to SARA and merge into their archiving role, then that role will become huge, filled with many "business" authorizations, plus.. it seems impossible to predict every authorization object that the archiving team will need to have in Production and we will be adding to this role regularly.

How do other companies handle this?  What does your archiving team role and user profiles look like in Production?

thx

[Colleen]

HI Kesayamol

it seems impossible to predict every authorization object that the archiving team will need to have in Production and we will be adding to this role regularly.

If you look at table ARCH_OBJ you will see archive objects to program mapping for each scenario (Actions in SARA) (e.g.write program, reload, etc). You can then search the code for the authority checks to work out what to build. Part of this is for an archiving strategy to determine which objects are to be archived

...and countless others (depends what they are archiving)  with ACTVT=06.

It's not all activity 06 (Delete). For example, authorisation object V_VBAK_VKO needs activity 24 for archive for object SD_VBAK for the preprocessing program step S3VBAKPTS

if we associate all these with SU24 to SARA and merge into their archiving role, then that role will become huge, filled with many "business" authorizations

I don't think the role will become huge (though our definitions of huge may vary). And although the authorisation object is "business like", the activity restriction is not (i.e. I would not grant activity 24 to a business end user).

One approach I took for building access as a dedicated system user restricted to the archiving access permission access. The user performing archiving was granted SARA transaction with S_BTCH_NAME for that system user. The archiving job ran under the system user's permissions instead. If required, you could have a system user for the different archiving scenarios (e.g split FI and MM out).

Another thing to check are transactions based on program SAPMAADM (e.g. check TSTCV). There are some transaction parameters for specific scenarios.

I recommend you work with the archiving team to first determine what they actually archive and then track the requirements. Searching through the code is quicker than hitting one authorisation failure at a time.

Regards

Colleen

[OttoGold]

Hi there.

As far as I can remember, there are plenty of parameter transactions for SARA. Just use those and maintain SU24 for them. I even wrote a program that optimizes the SU24 for that granular access. If you spot gaps there, just create your own parameter transactions and finish the job.

Then you can have dedicated users for dedicated archiving scenarios and everything is built bottom up with full transparency and traceability.

Cheers Otto

[Former Member]

It is good to know somebody else is using the S_BTCH_NAM solution because that is what we have been doing.  I just don't like giving that auth because our permitted userID has a lot of authorizations, but I suppose it's better than attempting to find every auth object needed across all the business suite products where they archive (CRM, SRM etc).  I did not know about table ARCH_OBJ.  Very interesting.   And it's a nice trick to search TSTCV for SAPMAADM, I hadn't thought of that either!   So we have some options now in case the archiving team complains about the S_BTCH_NAM approach in the future.

thank you Colleen and Otto!

[OttoGold]

Colleen's idea. I just wanted to say I actually did it and it works to support the idea

Good luck. Maybe.. if I dare... let us know here how it goes

Cheers Otto

[Former Member]

Why not have the archiving team process as a backgrond job using a system user ID with broader access. In our environment the archiving is done as a background job. Also, we've implement a process for users to assign emergeny access for a period of time to troubleshoot or fix issues all with proper approvals of course. In addition to that, the session is recorded upon the assignment of  the role. I would not recommend assigning change authorization in a daily support role as it can open up other functions you may not know about. Our support users is restricted to display only in production - no and, if's, or buts!