We then end up with two main classifications of access control:
- Role-Based Access Control (RBAC). Define the role for the access to data, eg Policy = Subject (AND/OR) Role –> Permissions.
- Attribute-Based Access Control (ABCL). Define attributes eg Policy = User (role, nationality) AND/OR Resource (department, owner) AND/OR Action AND/OR Context (time, IP, location) -> Permissions.
A Matter of Rights
We are generally poor at properly integrating security and often use overlay models to overcome our lack of embedded security. Our models of security often, too, come from our legacy operating systems. We have thus created a data world which is open, and then, to protect it, we put up perimeters. In an Active Directory infrastructure, Bob can also be part of multiple groups, and this will gain him rights. What we really want is to be able to define that the access is based on other things, such as his location, or whether he is the clinician associated with a patient. These are defined as attributes for his access rights and define attributed-based security. One of the best methods of embedding security into data is ABE (Attributed-based Encryption), where we can define fine-grained control of the decryption process.
Can we do Attribute Based Access instead?