The “ideal” IAM solution would have a reliable flow of pre-checked data and a list of sound, proven business rules from which to provision all the accounts and access each person needs to do their job.
This is a fantasy.
The types of work people do, and the IT landscape they do it in, are increasingly fluid and, while we might be able to make “broad brush stroke” access rules, there is still going to be a percentage of access that must be requested, special user accounts that don’t fit the proscribed mould, and genuine emergencies. Our IAM solution must be designed with this expectation.
I could go into a lot of detail here about different methods such as scoping, manual overrides and integrating request-based access – but I’ll leave that for other posts and stick to the fundamental design principal here – which is this:
When designing our IAM solution we must always be considering, and including requirements for, the non-standard. The IAM solution must include configuration that allows/ignores/incorporates the manual stuff.
This will, in all likelihood, involve process changes outside the IAM solution. Manual changes must be separated, or tagged, in a standard way. Details will differ but there still needs to be a standard way to identify and track the non-standard. This is the only way that automation can work effectively in our dynamic IT environments.
