Generally Tcode F110 is a potential SoD risk. F110 combined with FBZ0 creates numerous SoD violations. Let's discuss what is exactly the risks are and how to avoid it.
F110 - Automatic Payment Transactions : Status
FBZ0 - Payment Proposal
Through F110, we can do two activities i.e. Payment Run and Payment Proposals.
(While running payment proposal it asks for FBZ0 access at the background, that is why I have combined both of the transactions while describing it)
Now the risk is that payment run and payment proposals should not be given to the same person who will access F110 because of SoD violation.
To remove this SoD risk, we need to play around some authorization objects i.e. F_REGU_BUK and F_REGU_KOA.
These authorization objects contain some activities which are given as numbers inside the role.
The meaning of those numbers are provided below.
02 Edit parameters
03 Display parameters
11 Execute proposal
12 Edit proposal
13 Display proposal
14 Delete proposal
15 Create payment medium proposal
21 Execute payment run
23 Display payment run
24 Delete payment run payment data
25 Create payment media of payment run
26 Delete payment orders of payment run
31 Print payment medium manually
To make payment run and payment proposal mutually exclusive, we need to restrict the activities accordingly.
So one role should not contain 11, 12, 13, 14 and 15 and the other role should not contain 21, 23, 24, 25, 26 and 31.
Restricting the authorization objects with above activities we can remove the potential SoD risk easily.
F110 - Automatic Payment Transactions : Status
FBZ0 - Payment Proposal
Through F110, we can do two activities i.e. Payment Run and Payment Proposals.
(While running payment proposal it asks for FBZ0 access at the background, that is why I have combined both of the transactions while describing it)
Now the risk is that payment run and payment proposals should not be given to the same person who will access F110 because of SoD violation.
To remove this SoD risk, we need to play around some authorization objects i.e. F_REGU_BUK and F_REGU_KOA.
These authorization objects contain some activities which are given as numbers inside the role.
The meaning of those numbers are provided below.
02 Edit parameters
03 Display parameters
11 Execute proposal
12 Edit proposal
13 Display proposal
14 Delete proposal
15 Create payment medium proposal
21 Execute payment run
23 Display payment run
24 Delete payment run payment data
25 Create payment media of payment run
26 Delete payment orders of payment run
31 Print payment medium manually
To make payment run and payment proposal mutually exclusive, we need to restrict the activities accordingly.
So one role should not contain 11, 12, 13, 14 and 15 and the other role should not contain 21, 23, 24, 25, 26 and 31.
Restricting the authorization objects with above activities we can remove the potential SoD risk easily.
Author: Sambit
Source: sdn.sap.com
No comments:
Post a Comment