New Z tcode which calls BAPI - add this to GRC RuleSet

[Former Member]

Hi,

There is a development currently underway in house where a z transaction has been created which calls the BAPI:

BAPI_ACC_GL_POSTING_POST

I have been asked to add this transaction to the GRC RuleSet but i don't think there's any point in doing this yet as i don't feel the z transaction is calling an authority check in the right way.

When i trace the test user, or check the transaction in RSABAPSC, i cannot see any posting activity taking place i.e. i cannot see ACTIVITY 01 being called anywhere.

The developer added the FM Z_AUTH_BUKRS_FROM_BUKRS at my request but i think he should go further and add a check with an ACTIVITY 01. Only then will GRC be able to properly analyse this tcode for SOD violations because as-is, it's not calling enough.

I hope i have explained this in enough detail.

Has anyone come across an issue like this in the past? Any advice greatly appreciated.

Regards,

Colin

[Former Member]

Hi All,

Thanks for the advice. I'm not what path i'll take yet. We restrict others BAPI's through the Function Groups the Function Modules are assigned to using S_RFC.

If i was to do that in this case, i'm still not sure how i could tell the GRC RuleSet that this is a conflict with regular FB01 actions.

I'll report back at a later date.

Regards,

Colin

[Colleen]

Hi Colin

You can still define your function but you do need to clarify what the checks should be. At the moment, your function defintion would be the S_TCODE for the Z transaction.

However, if you just define it like that and there are additional checks then you increase the level of false positives. If there isn't then you are right that the code still needs to be hardened

As you have mentioned a Z authority check none of us can comment on the security. Did you run a security trace on the Z transaction with the BAPI to see what is checked? How has the developer coded the authority check.

I would push back if there is insufficient checks from a security point of view. But if the Z transaction activity forms part of a risk and is available to end users you should capture it and then start the remeidation/mitigation processes.

Regards

Colleen

[Former Member]

Hi,

your concerns make sense and I have always had a struggle with Business Process Experts in ensuring that the correct authority checks are being defined within the new custom transactions/program's for the sake of having a tight knit authorisation concept. I like to keep my SU24 data updated for role build and risk violation reporting purposes.

As things stand with your program, would it be correct in assuming that if anyone has the transaction code, then the user can perform create/change activity without any serious authorisations assigned? Or is the custom program calling another SAP standard program? I would ask your developers to write in a suitable authorisation check basked upon the data being accessed and changed.

If you are struggling with the auth object details, in the short term as a minimum, ensure S_TCODE is checked, so at least you could maybe have the rule set updated at the action level. Not the ideal solution though.