This is the fourth part in the continuing story of Bob, a builder, our example of Role based security in a realistic example general construction contracting company. Take a look at Part 1 to get an understanding of the basics, and Part 2 to look at cases where job roles don’t align, or Part 3 where we look at promotions and transfers.
The Audit:
And now it’s inspection time. Mr. A E Pessimal is here from the audit firm to check our SoX compliance. A E is an old fashioned guy, and it takes a bit of doing to explain the new security model, but A E also does financial auditing, so he can easily equate this to the role model used in most ERP/MRP/Financial system security (especially oracle). Once A E is on-board with job role definitions, this makes the job A LOT easier.
First, he looks at each user and determines the alignment of job function to job role. This should be pretty clear, and any supporting architecture documentation showing these links will certainly help make this smoother. In short, this test breaks down to the following thought pattern: “Bob is in the job role ‘Architect’, and his HR Job Title is ‘Jr. Associate Assistant Architect, 3rd class’, so that’s looks like a pass”.
Second, he get the managers to confirm the security rights for each role they control. Most of the real work is here because he needs to enumerate each resource and discover it’s purpose, then validate the given role really needs access to that purpose. Again, here is the thought pattern: “Hey Frank, does the job role ‘Architect’ need access to the blueprint room? can you look over the rest of these resources and make sure it looks right for you and your architects?”.
Just like the promotion case in part three, it should be obvious where the advantage here is. Every person who’s in a job role is one less person who needs to be checked uniquely. By breaking permissions, rights and access away from users and attaching them to self-describing, definitional job roles groups, the work required to validate those permissions becomes MUCH simpler. you no longer have to do the psychic-hard task of determining if Bob really needs access to the tools cabinet. just the two smaller tasks of “Is bob a builder?” and “Do builders use tools?”
This isn’t actually any easier for A E if the employee list is small. if you only have 5 resources and 2 users, then you need 5 checks (assuming no overlap). compare that to 7 checks in the new model; 2 for person to job role, and 5 for job roles to resource. On the other hand, the larger those roles get, the more reuse you get. with 100 employees, 10 comprehensive job roles, and 50 secured areas, that’s 100*50 = 5,000 checks in the old model, but only 100+(10*50) = 600 checks in the new model.
In Other News:
Parenthetically, one wonders why this type of security model hasn’t pervaded deeper into information technology groups, given that most financial systems already implement something like this. I think this is mostly to do with the way Microsoft has implement role based security in their products, like exchange, without being specific about what a role really is, or what it should be tied to. This has resulted in lots of organizations believing they have implemented role based security, when really all they have done is create a resource group and called it role based.
Minimum Required Effort 