Access Control

That chap up there?

He's called Tim. He's an enchanter, and, more germane to this article, he's also an access control mechanism.

Enchanter Based Access Control

Enchanter Based Access Control, or EBAC, isn't available to most developers. It needs a highly trained enchanter, a bridge, and some questions, and is a highly interactive solution.

In general, we restrict interactivity to authentication, and leave authorization as a non-interactive solution.

Plus, it's a little weird, in terms of an example. Let's talk about patient records in healthcare as our example instead. Patient records have lots of parts to them - there's data such as names and addresses, and also medical data, both current and historical. Since almost everyone gets some medical attention at some point, we also have lots of them.

So, how do we protect access to this data?

Authentication gets us to a proven identity, and sometimes that's good enough.

Identity Based Access Control

If you have an identity, that might be all you need. Alice and Bob have access to this data. Nobody else does.

It's a perfectly good way of specifying Access Control Lists, or ACLs. But what happens when Alice leaves the organisation? We need to go through every ACL she's listed in and remove her. Alice's replacement also needs adding in - and that means tracking, somehow, what New Alice needs access to.

So if you've a lot of data - and therefore a lot of ACLs - a little indirection might be useful.

Role Based Access Control

What we could do is group people into types - from the data access perspective, anyway. Managers, Doctors, Developers, Admins, and so on. These different types are called Roles, and it means that your ACLs now just contain a set of Roles, rather than people.

When Alice stops being a Doctor, we just remove that Role form her. A replacement gets the Doctor role. It's vastly simpler to manage.

Often, you can mix and match - an ACL can contain a mix of Roles and Identities, because any Identity is a (specialized) Role.

The trouble is, that still leaves you with a lot of ACLs, and fine-grained access control - where you might have thousands of records to manage - means thousands of ACLs against every record. Or, even, parts of records. Perhaps a little more indirection might help.

What if you could describe the sensitivity of data, and then describe the trust and training of people to handle such data?

Rule Based Access Control

Let's say that all patient records are "Sensitive". The personal information there - names, addresses, in particular - we'll add a tag of "Personal". The medical stuff, well let's just give that a tag of "Medical". So some of our data is now "Sensitive Personal", and some is "Sensitive Medical". We'll call these confidentiality labels, or just "labels" for short.

Now, we say that Doctors and Nurses, when they're employed by the hospital, get mandatory training in how to handle sensitive information. They're also trained - and trusted - to handle personal and medical information. We call this a "clearance".

Lab staff might only see the medical data, and other hospital staff might only see the personal - and their clearances reflect that.

You might recognise these terms from films and TV shows - "Sensitive" would be a "Classification", if that helps.

There's a number of standardized ways of handling this kind of mechanism, such as SDN.801(c) (A joint NIST/NSA private publication), STANAG 4774 (A NATO standard), and FIP-188 (A NIST public publication). I also wrote an MIT-licensed library to handle these, because I am insane and like insanely difficult problems which attract the attention of national security agencies. (Hi guys!).

These also define another element - a "Policy", which lists the classifications and tags, and tells you how they can be combined.

The Policy also adds two key features of a labelling system. Firstly, it tells you how to mark protected data. This means not only that the Doctor viewing some data is clearly informed about the sensitivity of the data, but we can also include some tags which aren't used for access control at all, and just provide information about the sensitivity of the data.

Finally, the policy tells you how to how to translate a label into someone else's policy (when, for example, you want to send a patient record to a different hospital).

When sending an email, or an instant message, people can put the right label onto the message both to ensure safety and convey the sensitivity - part of what's called "Originator Controlled Access Control", or ORCON -so messages outside the patient record are still protected.

It's a powerful system, which probably explains why it's the system used by militaries and intelligence agencies around the world to protect their data, as well as being recommended by HL7 and other healthtech standards groups for medical data.

But should any Doctor really be able to see any patient record? In the Netherlands, there was a recent scandal where a celebrity's patient records were looked at out of pure curiosity by medical staff (and others) who had no need at all.

We could combine Rule Based Access Control (RBAC) with Role Based Access Control (RBAC - yes, I know), and give things both a label and an ACL. But that's really quite painful to manage. Patients move between wards and departments as their care progresses and changes, and managing this is again going to be painful.

What if we could do this automatically, so when a patient gets transferred to a ward the ward staff automatically get the access they need?

Attribute Based Access Control

ABAC uses the data itself to derive access control decisions on the fly. Its policy is almost a programming language in its own right, digging through the data representing the Resource, Environment, and Subject to decide if the Subject can access the Resource within the Environment.

Standards such as XACML are frighteningly complex as a result, and just as Role Based Access Control can be used to implement Identity Based Access Control, XACML can be used to implement any access control system we've discussed so far, and several more we've not even thought of. Can Doctors only access Patients Records during working hours on approved equipment? Sure, we can do that.

Of course, without XACML or some similar system, we can just code the policy in more traditional programming.

The ABAC system needs to crunch a lot of data for this, of course - it needs to know if a nurse works on a particular ward, as well as if a patient is on that ward. It needs to know if a medical procedure is conducted by the same department as the consultant is working in. It needs to know if a Doctor is on-shift. It needs to know if their personal mobile phone has been approved for use.

But, if you can get by the complexity, ABAC is astonishingly powerful.

The downsides beyond complexity are more subtle. Rule Based Access Control gives a federated access control system via its translation capability - ABAC can't actually provide that. It also can't mark data, which is useful to indicate sensitivities beyond simple access control.

So what's the best access control?

Everything Based Access Control

It turns out that all access control systems have advantages and disadvantages - but handily, we can use them in combination, and that mostly removes the disadvantages.

ACLs remains the simplest solution we have for access control, especially when simplified further with roles. If you're not confident, or not able, to do anything else, just pick this.

Combine these with labels and clearances, and you've provided immediate assurance that even if the ACL says someone can read data, they still can't if they've got had the right training, or are not trusted. In addition, you have the powerful marking, so useful for human understanding, and the federated controls.

And both ACLs and Roles can be automatically assigned by code, using techniques from ABAC. Patient record updated to say they're on X Ward? Adjust the ACL automatically, and we're done. Environmental techniques from ABAC can be replicated by injecting device clearances, too.

Access Control is a complex, and vital, problem in any non-trivial system. But it's also an area that has received considerable academic study as well as numerous pragmatic approaches from industry. As with almost any big architectural decision, the best answer is "mix sensibly", the worst is "mix badly", and the safe option is to pick the easy one. But don't use Tim. He's not actually that good.