Here’s a picture I once used in a presentation (credited to wallwin.ca) to illustrate the mess access control in directories and applications often looks like when you try and do any kind of review and analysis.
These days I don’t go into server and patch rooms all that often, but even so it’s been a long time since I’ve seen anything this messy. Patch cabinets are now more likely to be neatly wired like this (picture from clever-idea.co.uk):
The question is – is there any way we can get our access management looking more like the second picture than the first?
Management by Incremental Change
Patch panels got in such a state because of the approach of incremental change. We start with a base level of cabling, probably quite tidy, and then we add to it as the needs arise. All sounds quite sensible and cost effective – except it isn’t, unless really tight controls are maintained. Too often the “quick fix” wins over other considerations, and we end up with spaghetti.
Now we’re in a situation where even small changes are much riskier and take longer to implement, while the impact of a bigger change is difficult to predict – so we have a flaky system that costs more to maintain and support than it should. Eventually people figured out that the extra setup and hardware costs of neatly pre-wiring were well worth it.
And now the access control metaphor
Access control is too often like that first patch cabinet. All the wiring has been done by hand and in response to individual requests. Along the way a couple of different approaches have been employed, but without tearing everything out and starting over the end result is still hard to understand and time-consuming to trace through.
So can we somehow set up access control policies so they are more like the second picture – essentially, can we “pre-wire” access?
Pre-wired access
Flexibility in the level of access we can grant is a good thing for tailoring access to suit business needs, but that doesn’t mean we have to use everything on offer. For the sake of clarity a small number of clearly defined access roles should be defined up-front, based on a proper analysis of access requirements.
This should be fairly straight-forward for an application, but consider the types of services that have multiple instances each with their own access policies – shared folders and mailboxes, SharePoint sites etc. To avoid complexity we need to define the access roles we’re going to allow as the first step, and then ensure they get created and used.
Let’s say we decide that shared folders will always have two access policies – Read and Write. How might we approach pre-wiring the access to new folders?
- Beginner level is writing a script that will create a shared folder, and also creates the Read and Write groups and sets up the ACLs.
- Intermediate level is automating the management of the groups’ members based on source data – perhaps putting all members of a business unit into a folder access group.
- Advanced level is fully automating the creation of the resource itself, and its access roles, based on triggers such as a new business unit being created in the HR system, or a new project cost code being registered in the finance system. The resource can then be “lifecycle” managed like any other identity, including archiving it when source data indicates it’s not needed (eg., unit flagged as inactive in the HR system).
Some people might find the notion of identity managing a shared folder kind of odd – but there’s actually no reason the concepts we apply to person identities cannot also be applied to other data representations. If you know that some business units make use of a shared folder and a distribution list and a SharePoint site, is there any reason that all units shouldn’t have that? And if you were to pre-create these resources for all business units and some don’t get used – what has actually been lost? These resources, with their access, have been pre-wired and we can get on and do something else.
R/ABAC
The promise of Role- and Attribute-Based Access Control is that we can fully automate a good percentage of access granting, and revocation, based on trusted information about users and their jobs – but achieving even partial RBAC is still an insurmountable challenge for many organisations. Mapping business roles to access roles is a huge and ongoing analysis job – however you won’t even get started if you can’t nail down the access roles themselves. If, as part of this nailing down, you can actually define the target resources around business roles, then the RBAC mapping is already there, and should just work. The ultimate ideal in pre-wired access.
