Separation of duties (SoD) is the concept of having more than one person required to complete a task. It is alternatively called segregation of duties or, in the political realm, separation of powers.
Separation of duties (SoD) is one of the key concepts of internal control and is the most difficult and sometimes the most costly one to achieve. SoD in basic terms that is no single individuals should have controls over two or more phases of a transaction or operation, so that a deliberate fraud is more difficult to occur because it requires collusion of two or more individuals or parties.
The rest of the definition may be found (thanks wiki!) at wikipedia.
When the auditors ask us about separation of duties, what do we say? My favorite answer is that we can programatically prove that our policy is correctly implemented.
How do we do that? By driving security off of tables. We can then query the underlying tables to generate the reports that make the auditors happy.
What this means in the most basic sense is that we have to construct a matrix, with people down the left side and programs across the top.
P0101 P09101
---------- ----------
AUSER01 I ACDI
AUSER02 ACDI I
where the four functions are:
Add A Change C Delete D Inquire I
Once we have this matrix, we can use it to (for each user) construct custom menus. In the case of JDEdwards, we will make a copy of the menu detail file (F00821), and add a member for each user. The user's intial program will override to their specific member, and they will only be able to execute programs to which they are authorized.
In order for this to work, a couple of things have to happen:
Now, in JDEdwards, there are hundreds of programs, and it is not unusual to have hundreds, if not thousands, of users. Now, maintenance of matrix with hundreds of thousands of elements is going to be tedious, and error-prone; not at all the sort of thing we should leave to people. We need a metaphor to help us deal with this on a more abstract level. We need
Role Based Security
