cancel
Showing results for 
Search instead for 
Did you mean: 

RAR Rules and SU24 Upload Objects

former_member325725
Participant
0 Kudos

Hi Experts,

Tried to find answers here, but apologies if I'm asking the obvious again.

We make updates to the RAR functions and rules by adding some Tcodes, mostly custom in the Dev system and and transport to test and prod. We have rules maintained for only one SAP back end in the respective environments.

We have performed the SU24 upload of text and objects (permissions) from the Dev SAP back end to GRC Dev and it looks like this hasn't happened for a quite some time. Eventually, the system has scheduled the Rule generation job. Now, we observe the Rule transport file has a large delta (size as well as content). Can anybody explain if this process hasn't changed the custom rules in anyway ? We do not want the custom rules to be updated in any respect as to report any new risks that was not originally designed to report.

We have not moved the rules to the production GRC, and would like to preempt any risks that might happen with this new Rules file transport.

Thanks to all for helping with any clarifications.
Regards, Anil

Accepted Solutions (0)

Answers (2)

Answers (2)

former_member325725
Participant
0 Kudos

We are on 5.3 SP14.

We have the 3 system landscape and typically we have the same rules maintained in Dev,test and prod, except for the updates happening in Dev that are yet to be transported.

The current challenge/issue is that we have done an SU24 upload from the dev back end to dev GRC and we see the transport file has grown big(may be due to the fact that we didn't had an Su24 upload of objects for a long time). It's OK for the GRC tables to be updated with the current SU24 data from back end, but we are concerned about the permissions(Auth Objetcs - Fields/Values) and their status (Enabled/disabled) which will eventually result in new enabled/ disabled rules. We would also like to know implications to the Rules/Risks because of the SU24  object upload.

Thanks, Anil

Former Member
0 Kudos

Hi Anil,

Once you upload the auth objects in GRC 5.3, there would not be any affect on the existing rules. These auth objects will just be uploaded to tables VIRSA_CC_SAPOBJ(auth objects i.e. permisisons, actions, fields and values). Their descriptions(if you upload) will go to table VIRSA_CC_OBJTEXT).

There will be change in the existing functions, risk and rules.

Only when you try to create new functions from the application, you may be able to see new auth obejcts.

The status of the permissions(i.e. active or inactive) is decided while defining or maintaining the function permisions only for a particular rule.

Best Regards,

Smriti

Former Member
0 Kudos

Hello Anil,

I am presuming you are using GRC 10.0 (hence the mention of Transports). In 5.3, there is no transport route so it would be manual maintenance per environment and utilising the rule set import/export functionality.

Is the ruleset same across all 3 GRC environments? (Dev, Test, Prod), or have they been maintained independently?

If they are all in sync, then your amendments from the Dev system should not overwrite anything across in the Test and Prod systems once transported. I presume you would have knowingly made changes to the rule set in Dev prior to transporting it. If in doubt, export the local rule set from the Test and Prod systems prior to releasing the transport (for back up).

It is worth noting that whatever you will transport from Dev will be introduced to the other systems (obviously), If there are certain rules you wish to have specifically for the Dev system, then I would suggest creating a "Non-Prod only" and "Prod only" rule set and have the "Non-Prod" rule set as the master rule set for the GRC Dev system etc.

I hope I have understood your question correctly.

former_member325725
Participant
0 Kudos

Hi Kaushal,

Thanks for your reply. Sorry that i didn't give the version info. We are on 5.3 SP14.

We have the 3 system landscape and typically we have the same rules maintained in Dev,test and prod, except for the updates happening in Dev that are yet to be transported.

The current challenge/issue is that we have done an SU24 upload from the dev back end to dev GRC and we see the transport file has grown big(may be due to the fact that we didn't had an Su24 upload of objects for a long time). It's OK for the GRC tables to be updated with the current SU24 data from back end, but we are concerned about the permissions(Auth Objetcs - Fields/Values) and their status (Enabled/disabled) which will eventually resulted in new enabled/ disabled rules. We would also like to know implications to the Rules/Risks because of the Su24  object upload.

Thanks, Anil

Former Member
0 Kudos

Ok I see what you are asking now.

To answer your main concern, these SU24 upload files will not overwrite any part of your rule set.

The Auth Object and Text files are not a mandatory thing to update in the GRC system. They only support you in manually building and updating the ruleset by bringing in the correct authorisation objects and field values marked against the Tcode being considered within the Functions.

It is good practice to just keep these tables updated, but it should not take up much space (should be similar to the text file size I suppose). The rule set tables generated work indepenantly from these SU24 related data during risk analysis.

I presume you have ECC Dev conencted to GRC Dev, ECC QA to GRC QA, and ECC Prod to GRC PROD. I have seen a few customers take the SU24 details (Auth Obects and Text files) from the relevant client and upload it against the corresponding GRC system as described above. One reason for this is because you may have many test/unreleased transaction codes in Dev,