I’ve renewed my interest in access control systems recently, and decided to review them a bit more formally rather than looking at specific implementations (NTFS permissions, UNIX permissions, etc).

Access Control Types

Discretionary access control

This system has users with directly assigned permissions. Assets have a concept of an owner, a user which controls access to that asset. An asset without an owner is theoretically defenseless.

Mandatory access control

This is a bit like concentric circles of trust, reminiscent of Meet the Parents, where users are placed in one of the circles and are allowed to access everything on that and all lower levels. Think “Classified” and “Top Secret”.

Role-based access control

This is widely regarded as a best practice, is where users have many roles, roles have many users, and users get permissions based on what roles they belong to. A user without roles has no access. This is great where you have large groups of people who all have similar access needs, such as point-of-sale employees.

What about the enterprise?

The above work well for single applications, but what happens when you have many applications? Each application’s administrator will likely need to manage the same set of users, or at least a large subset of them. This is inefficient, but also leads to other problems. The biggest problem is the fragmentation of roles. A few course-grained roles may be just fine for the primary users of an application, but what about those users who require access but are not easily pigeon-holed? Consultants, contractors, people from other departments, etc.

One paper I read suggested using a request-based permissions system, using a few course-grained roles to cover what can be easily covered. Users will then request specific permissions as they require them, with the request and approval process made a part of the system.

For example, I’m in marketing and I get the default set of permissions that come with that job. I typically do not need access to my company’s source control repositories. At some point I find that doing my job does require it for some reason, so I need to get access to it somehow. In the role-based system one of three things might happen:

  1. I’m given an existing role that allows SCM access
  2. An existing role is fragmented into roles with smaller permissions, and I’m assigned one of those
  3. A new role with the permissions I need is created without changing existing roles

The first is unlikely because it will likely give me more access than I need. The second is likely if this hasn’t been done for anyone else before, the third if it has. The paper I’d read claimed that, over time, this parallel management of applications would cause the number of roles to multiply until it became unmanageable, losing the benefits of the role-based system.

Under the request-based system I’d simply request access to the SCM. That request would be routed to the appropriate person to be approved or rejected. The access I obtain is assigned to me personally, not through any particular role.

Over time this leads to privilege accumulation since users will actively pursue obtaining the permissions they need to do their job, they won’t be so active in shedding those they no longer require. Therefore a periodical, hierarchical audit should take place.