Securing table group SS / transaction SCC1 and table CCCFLOW

[Former Member]

Hello all,

I'm relatively new to this forum, please be kind.

Situation sketch:

In an SAP landscape, in Development environment, I have 3 clients, in which 500 is the ECC golden client, 510 is for sandboxing and 520 is for testing.

Problem:

Developers use tcode SCC1 to transport customizations to another client to be tested again and put on transports eventually.

For changes they make using SCC1 they require Change (02) authorization on table CCCFLOW (client-copy report logs).

However this CCCFLOW table is classed under the SS table group, in which all my other important security tables are as well

(AGR_* etc).

Question:

How have you guys secured the SS table group when you still want to provide developers the use of SCC1?

Regards,

[Former Member]

Hi Mujo,

I don't think there is a way that you can restrict your security tables falling under the same auth group as CCCFLOW. Given that the users are developer and would normally need Maintain access to most of the tables in the system, there can be many other tables that developers would need which falls under SS.

Thanks,

Deb

[Former Member]

I understand, but in other words you're saying that Developers (ABAP coding people) will always have Changerights to user and role tables USR, AGR_ etc... unless we step away from the SCC1 option? (in my situation).

[martin_voros]

If developer have access to debugger and can changevalues then he can do almost everything. You can still write a wrapper for SCC1 that would execute it under different user but this will have some other issues.

[Former Member]

You cannot realistically restrict developers with developer type authorizations.

However, you can give them a role which gives them errors or warnings about things which should not be done (eg. They must ask a basis person to do it because it affects the whole system and requires co-ordination).

If they still bypass the warnings or hobbles over the errors, then it shows intention. Proven intention scares off most developers, because they take great care and pride of being in the haven of being innocent angels...

Cheers,

Julius

[Former Member]

Thanks all for your suggestions and (funny) replies. I guess I'll just have to raise the level of monitoring on our DEVvers.

[Former Member]

How about this idea? Your thoughts and suggestions are appreciated.

1. Clone SCC1 to ZSCC1 (SE93)

2. For ZSCC1 Remove S_TABU_DIS Auth Check on ACTVT 02(SU24)

3. For ZSCC1 Insert S_TABU_NAM Auth Check on CCCFLOW ACTVT 02(SU24)

4. test with a role that allows S_TABU_NAM to CCCFLOW and does not allow S_TABU_DIS to auth grp SS

This should separate out CCCFLOW from the rest of the SS Auth Group tables.

Has anyone tried this approach?

Optionally, Do steps 2 and 3 directly on SCC1, depending on your SAP shop's policy for modifying auth checks on SAP-delivered tcodes.

BSnow

[Former Member]

Better would be to open a customer message with SAP and ask them to remove the hardcoded check in FM SCC1_AUTH_CHECK_EXT_CLIENT_CP and replace it with a call to FM VIEW_AUTHORITY_CHECK which does the S_TABU_NAM check.

Cheers,

Julius

[Former Member]

Julius,

If your suggestion is technically cleaner, are we the first ones to raise such a customer message at SAP?

Could you elaborate somewhat more on the way things would change if we'd opt for that?

Sincerely

[Former Member]

AFAIK this hardcoding is being removed, so I suspect that you will not have much resistance.

Possibly you are the first to notice it and SAP's own scans did not spot it yet.

I would open a customer message. Keep us posted how it goes.

Cheers,

Julius

[Former Member]

I understand.

Could you provide a little bit more detail on these changes in functional modules.

Makes it a bit easier for me to understand the process change (the handling/working of the transaction code).

In other words: how is the flow changing if we suggest this?

Thanks again.

[Former Member]

The process should not change, just the granularity of the authorizations required to run the process.

Whether or not you end up with a security benefit in the end I am not sure, as a client copy is a "big thing"...

Cheers,

Julius