Generic business rules.
How do you decide whether to give someone a login account? How do you decide which access(es) to provide?
Ask an account administrator in a small shop how he knew it was okay to do it, and the answer will generally be along the lines of, “The Right Person told me to do it.”
Okay, who is the Right Person, and how do you know who it is? How do you determine a replacement if that Right Person leaves?
Access is generally approved because the decision has been made that (1) the requester really needs the access to those resources, and (2) some owner of the resources is willing to allow it. I’m going to call these two aspects Validation and Authorization.
In some areas, these two decisions are made by the same person: the owner of the resources. This will generally be someone near the top of the organization in charge of those resources.
Sound incredibly obvious so far? Okay, let’s go deeper.
The administrator generally “just knows” who is the supposed owner of the resources, by virtue of the Right Person’s position in the organization. If there are different sets of resources in different departments, you’ll find the administrator choosing the appropriate department head, or the organization head over all of them, to get that authorization.
What if the organization or user base is so large that the Authorizer has no idea who the requester is, and therefore can’t do the Validation? That’s when you start breaking out those roles. You end up with two approval steps in the process. Someone has to Validate the user’s identity and need for access, and then the resource owner has to decide that the access being requested is appropriate, given the reason(s) supplied. When you’re using role-based access control, the Validator will recommend the role to be used, and the Authorizer will generally put together whatever he knows about the requester’s organization, the Validator, and other business rules to decide whether that’s the right role. If you’re automating the approval chain, these are generally the steps that get put in.
Wait! It gets more fun. The astute reader will have noticed that the Validator and Authorizer are both roles unto themselves. They can overlap. When the resources being accessed are financial, or have other legal constraints on them, you have to worry about situations where a Validator becomes an Authorizer for the same resource and can therefore (theoretically) both validate and authorize his own access to something. This is where auditors like to see the roles clearly separated, especially if the approval chain is automated. Separate roles + small department = headache for the security designer.
Now, the one place where this model usually collapses in a gooey mass is when you’re talking about privileged access, i.e. access for the person who runs the system containing the resources. Even if you have an ultra-L33T user enrollment workflow, chances are, when you hire new system administrators, you don’t use it to grant them access. It’s just sort of “understood” that of course a system administrator needs full access, and if he’s in that job, by definition he’s both validated and authorized. This happens a lot for the developers of the application, too, especially if they’re in charge of production support. (It also goes for the administrators running the user enrollment workflow application!) And this is where you’re most likely to get dinged by the auditor, because that’s the one place you’re least likely to have explicit, written policies and written approvals.
So do yourself a favor and write down a generic algorithm that works for your situation, using roles rather than names in the approval process. Then when Ms. Shoulderpads leaves as department head, your administrators know whom to tap as a replacement in the approval process. They have a better idea of who qualifies as the Right Person and who doesn’t, and why. They also know how to set up the system to avoid audit dings.
And while you’re at it, get rid of those shared administrator accounts!
Posted by shrdlu on Saturday, June 02, 2007(0) Comments • Permalink •
