This is the third 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.
Promotion:
Bobs been an excellent employee, and he’s showing particular skill with blueprints, so Mr. Vila transfers him over to the architects group as an apprentice to Frank. This means that he’s no longer a builder, and is now an architect. But hang on, Bob has a bunch of other security that may or may not be right.
In the traditional method, Bob would retain all the access he had before because it was assigned to him directly. In the UGLR model, we need to check each group and see if it applies anymore, and how many help desk personnel are going to check that? This can (unsurprisingly) lead to audit faults and abuse, but this is where the job role model really shines.
In the job role model, we’re going to remove him from job roles that he is no longer doing, and add him into the new job roles. Architects get access to the drawings room, the documents archive and the high-capacity printing center, but he’s no longer a builder, so all of his access to the tools shed, etc, is removed. He’s no longer assigned to the museum project, so his transfer is handled by that PMO like anyone else being removed from a project, and he’s removed from that project team’s group. Bob’s still hazmat certified (remember this isn’t really a job role, but a “certification role”), but architects don’t get the specialized training to keep his certificate valid, it eventually expires, and he will be removed from the group by Health and Safety’s regular audit process.
Did you catch the major improvement? it’s subtle.
| “Does Bob still need Access?” checklist: | |
|---|---|
| Traditional security | Job Role groups |
| building supplies depot? | What is Bob’s job role? |
| tools cabinet? | |
| first aid box? | |
| petty cash? | |
| locksmith cage? | |
| drawing rooms? | |
| documents archive? | |
| high-capacity printing center? | |
| waste disposal skiffs? | Is Bob’s hazmat cert valid? |
| insulation shed? | |
| paint & thinner warehouse? | |
| art vault? | Is Bob’s on the museum team? |
| 12 hard questions | 3 easy questions |
In the old model, we had to make 12 independent security decisions during this transfer. Those checks are somewhat obscure, and we aren’t including all of the other access controlled areas we are flippantly glossing over in this minimalist example. Who knows if Bob really needs access to the locksmith cage or not?
In the job role model, we had to do 3 role based checks, and access falls out from those role decisions. We’ve outsourced all of the hard access questions to the managers, PMOs, and subject expert who already define the access levels for those users. We know architects don’t need access to the locksmith cage, because if they did then Frank would have set that on the architects role.
In Other News:
Access control isn’t the only thing you can throw into a job role. Config Manager, Citrix, and lots of other software management tools lets you push software to security groups, so new hires into Frank’s team can get all of the advanced architect drafting software that Frank’s group is using. Exchange can use security groups as distributions lists, meaning the Architects email list is tied into the architects job role, and by extension, who is actually doing architect work.
Minimum Required Effort 