“Not everything that can be counted counts and not everything that counts can be counted”
Similarly not all things that can be solved by creating more and more roles and authorization restrictions, should be handled necessarily by route of creating more roles and more administration more downstream costs as well, think user recertification, business role ownership etc. to start your wheels spinning.
So there has to be some more organic and cleaner ways of solving problems when possible, rather than using security nut and bolts approach to lock people up for sake of it (at times), what could be some functional aspects of securing that are sometimes as helpful along with the door knob and the gate of security restrictions that usually float around in terms of SAP Application security.
I am illustrating an example of keeping open mind and finding the best fit solution based on the requirement instead of defaulting everything through known ways such as SHD0 and preventing some data input – or creating more roles, more authorization groups w/o understanding the downstream impacts on GRC ruleset and administration costs (more details in later paragraphs) all along the lifecycle of the usage of these authorization entities (i.e new roles and authorizations introduced)
Business case: FBV0 tode access and PTP (Procure to Pay) users with RTR (Record to Report) roles able to bypass FV50 workflow controls to post JE directly
Context: project already has segregation of business processes on basis of Financial doc types, RTR doc types for journal entry (JE) posting following a workflow based 2 step park and post process where an approver (different user than the parker) has to approve JE before its posted.
This functionality is designed for parking via FV50 tcode but in global roll out because of small shops some users have access to both PTP and RTR roles and thus accidentally can post journal entry via FBV0 when they try to post all parked entries in FBV0 (w/o checking if they are PTP related or not), so business requirement is that no user should be able to use FBV0 to directly post journal entries.
Approach:
One of the quick fixes is to separately create another doc type for Journal Entry processing and exclude all PTP users from that role so that they cannot post via FBV0. This means additional auth group for doc types that needs to be maintained at role and ruleset level in GRC, also since we are talking about small shops, what prevents existing PTP users from not getting the new RTR roles which contain Journal Entry doc type.
Lets take a step back, and revisit the original requirement, when I think of this requirement I understand this is just not a security requirement of restricting users on basis of access (meaning some users can post and others cannot – i.e restrictions on some while allowing others), this is more like a system requirement where business doesn’t want any dialog user in any circumstance to post via FBV0 for RTR doc types – which leads us to develop a solution outside realm of (the quick fix solution we discussed at beginning of this para) creating another doc type for JE which is not assigned to current roles which will allow for user auth error via FBV0 but then creating more roles also allows that users will again get the new roles in small shops and this solution may not really work because it doesn’t address the root cause.
This solution on face of it looks like a quick neat fix and that was what majority of group wanted to go with, at the time of initial option evaluation discussion with stakeholders, and that is why as a security GRC consultant it’s very important to go till the root cause is addressed, answer doesn’t always lie in creating more roles and restrictions but truly identifying the requirements and then aligning the best solutions that solves the issue holistically.
Lesser the no. of roles you have, better you have overall control in the landscape, you have to find your optimum level of ratio between users and roles and there is no standard way of approaching this, as it depends upon business stakeholders buy in, regulations, localizations, inspite of your best practices recommendations – there will be variations but you have to always try to strive for the most simplified, scalable and sustainable solution that keeps things minimal as much as possibly allowed in various contexts – less is more truly in this case
Solution in detail:
Option a – create new Doc type auth group and new roles to prevent such JE posting via FBV0
Implementation: new roles –> new auth group -> new ruleset changes –> new cost of ownership and administration both on Security roles and GRC AC Ruleset front
Road less travelled: option b – creating validation rules, that allows systematic restriction, actually solves the problem organically because irrespective of authorizations (authorizations enables access, or restricts by lack of authorization but potential of execution is always possible at system level if an user has appropriate authorizations), but this requirement calls for system level restriction because business clearly doesn’t want anyone to bypass journal entry workflow for posting of journal entry .. thus the solution of using validation rules is a cleaner and consistent option. Below section provides some inputs as to how we can create a validation rule.
P.S: Corollary to be noted – that if authorizations are in place but its still not allowing access, then answer may lie elsewhere esp. in this case – will not hurt to have a check from validation rules point of view
Validation Rule Implementation Steps:
Here are the steps followed and hopefully this provides some base knowledge for a security consultant to understand the workings of validation rules.
Step1: make a rough draft of what you want .. here we want to prevent direct posting of a particular doc type in transaction fbv0
* Background research: fbv0 calls tcode fbvb for posting in background and table bkpf_blart contains posting tcode as fbvb, so in our validation rule we have to code AGAINST fbvb
STEP 2: start writing validation rule and inherent conditions that apply.
* In this case we want to specify that system should not allow any posting for doc types related to journal entry when the tcode used for posting is FBVB, in this way and the user is not wf-batch (because posting of journal entry via workflow approval process is allowed and user in context is wf-batch) ..
a. Snapshot of the validation rule:
Step 002 screen
b. Pre-requisite screen: Identify the base premise of applicability of the validation rule
c. Check screen – where the actual check happens to prevent posting of designated doc types, contained in set ZFBVDOT in this example, by any user except WF-BATCH
d. Message screen
e. Tcode – GS03 – display set with validation doc types http://bit.ly/2HR6trB #SAP #SAPCloud #AI
