I’ve been following the Role Based Access Control thread on the Personal Clouds List and just sort of biting my tongue so as not to sidetrack any productive discussion there. However, I cringe every time a new email comes out comparing Clique Space to RBAC. One is a model, one is an implementation. To compare them is like saying “China is not capitalism.”
I have issues on several levels with the whole discussion. First, I believe that Role Based Access Control will be essential to the Personal Cloud architecture. With all of the different functions proposed for Personal Cloud, it doesn’t seem scalable with the other types of access control. Furthermore, there is no “personal cloud” if all the parts of it are developed in a vacuum. Even though your component of the Personal Cloud may be simple enough to not require RBAC, how will it fit into the greater architecture? For example, a smart light switch may have one role – either you can access it or not. That’s a use case that screams out for simple Access Control Lists right up until you try to integrate it into a larger home automation system. It isn’t so much that the switch now needs roles, but rather that the ability to manipulate or inquire on the switch from within the home automation system is itself a role of that larger system. So as a designer the question becomes: In a larger cloud context where the owner manages using RBAC, do you want your device or component to be the only thing that requires the homeowner to program specific Access Control Lists? How user friendly is that?
My answer to this is that as designers we need to recognize up front that the complexity of the Personal Cloud requires something more manageable than individual access control lists and then design our components to live in that greater context.
There are several commonly recognized access control models. The basic ones include:
DAC – Discretionary Access Control.
Mappings are made directly between users or app and the resources available for access, typically using Access Control Lists (ACLs).
MAC – Mandatory Access Control
Data is classified as one of several levels of sensitivity. For example, government uses classifications from public through several levels of Top Secret. Users or apps are assigned a level and may access data at or below that level. MAC tends to be applied to data rather than services. For example, anyone can use the address book service but the results are filtered or constrained depending on your level.
RBAC – Role-Based Access Control
Mappings are made between job roles and the resources available for access, typically using Access Control Lists (ACLs). Users are assigned to one or more job roles and their access is the union of permissions assigned to those roles. RBAC tends to be applied to services because software designers who wrote the app are the only ones in a position to know exactly what access is required for which role.
As an example, if you needed to perform a backup for disaster recovery the security model in use would influence the results.
- DAC – Only the root account can run a backup because it is impossible to determine reliably whether any other account is sufficiently authorized to all required resources.
- MAC – Any user can execute the backup job but the contents of the backup do not contain all the data if the user does not have the highest clearance.
- RBAC – Users designated as Backup Administrator are authorized to run the backup job but do not necessarily have root access. They can therefore only read sensitive data using a tool that immediately encrypts it prior to storage on external tape or disk drives.
There are a few other security models and some more complicated versions of these three, but nearly everything out there falls into one of these models.
So it isn’t that “Clique Space is not RBAC” or that the two differ in some way. It is that Clique Space uses an access control model that does not happen to be RBAC. I’m not sure what it uses but it appears to be some form of DAC and MAC mixed. A discussion of the difference between DAC and RBAC might be productive, but it would be a fairly straightforward discussion because the terms are industry-standard and well defined. There isn’t a lot there open to interpretation.
Regarding the difference between Enterprise and other software development, a note about methodology is warranted here. In the Enterprise world any system intended to withstand a rigorous security audit selects the appropriate security model and then implements all components using the principles of that model. The use of a specific model and strict adherence to it improve security because the models have been subject to much research, in many cases mathematical proofs of certain aspects, and sustained aggressive field testing. The models are also followed closely because this enables comprehensive audit and swift, sure remediation of any defects found. All the access control within the perimeter of a specific security domain uses the same implementation of that model and any interaction with things outside of that domain occurs through a well-defined, strictly controlled and tightly mapped boundary.
One of the things that RBAC provides is a separation of duties. If one person manages accounts and another person controls the access of groups to resources, both persons must conspire to grant unauthorized specific access to specific persons. This provides a check and balance against a single person susceptible to coercion or of bad character and conspiracy laws raise the stakes if they get caught. This is clearly of benefit in an Enterprise but less so for a personal cloud owned and operated by an individual. We have the opposite problem – we’ve had separation of duties all along and the custodians of our data have suffered from bad character and conspired against us. Unfortunately, the legal remedies are on a practical basis only available to corporate entities who are citizens in fact, but not at all available to individuals who are citizens in name only.
On the other hand, RBAC also provides scalability. When it is necessary to individually map user rights to specific resources, it only works well as long as the number of rights and resources, and the matrix between them, is small enough to comprehend. It is easy enough to start with a user and provision access, but revocation is next to impossible in a large system because the effect of disabling a specific privilege is unclear. So RBAC allows the designer of a piece of software to specify all the different roles supported by that software and enumerate a specific and finite list of permissions required for each of those roles. Rather than a list of dozens of specific cryptic permission names the administrator sees human-readable role names like “End User,” “Backup Administrator,” “Account Administrator” and so on. I wouldn’t necessarily say that RBAC was designed for Enterprises as much as I’d say that Enterprises raised complexity to the point that RBAC became necessary because DAC would simply be impossible at that scale and MAC doesn’t cover cases such as “Backup Administrator” previously mentioned where granting universal read access isn’t appropriate but granting that access within the context of a backup operation is.
But that doesn’t mean RBAC has no role elsewhere. We will UNDOUBTEDLY use some form of RBAC for our Personal Cloud. Do you want to specify the set of personal attributes you are willing to disclose for every single new entity that you introduce to your personal cloud? Or do you want to make a roles like “merchants authorized to charge my credit card,” “family,” or “emergency contacts” and authorize those to read your name address and phone number?
Now here’s the kicker. What we want to avoid as software designers is an organic progression where we start with DAC because it’s simple and then gradually add RBAC as complexity begins to reveal scaling issues with DAC. The result is almost always software that is riddled with vulnerabilities because of the inconsistency. It is also almost impossible to remediate without scrapping it and starting over. Anyone who is designing something intended to scale needs to consider this, pick an access control model from the start and stick with it.
Whether Personal Cloud scales to this level is arguable. Some would say no individual should have so much complexity as to make RBAC necessary. I argue the opposite based on natural variance in human intellectual capacity. I believe that Personal Cloud software must be usable by as much of the left side of the bell curve as possible because it is particularly well suited to serve and enhance the lives of this population more so than almost any other technology before it. It may play a key role in our ability to finally enfranchise our less abled population and engage them as first-class citizens in our society rather than treating them as burdensome dependents. And if we are serious about personal sovereignty then our Personal Clouds will engage these people rather them further isolate them, by providing the means with which they can reliably and securely take charge of their lives.
I propose the following:
- That RBAC is appropriate and in many cases necessary for Personal Cloud.
- That the security model for any software should be deliberately selected during the design stage based on specific requirements and subsequently adhered to in every aspect of the software within a given security domain.
- That mixing access models leads to vulnerabilities.
- That changing security models over time within the same piece of software leads to vulnerabilities.
- That integrating software of differing security models has strong potential to introduce new vulnerabilities (implying that mapping along the boundary is a matter for subject matter experts).
- That if the security designer doesn’t have fluency and deep skill in such matters, then medium and trivial vulnerabilities in the implementation are a virtual certainty.
- That inventing new security models is not a trivial task and that validation of any new model requires broad participation of subject matter experts across several disciplines and extensive testing and proof before it can be said to be reliable for non-trivial applications.
- That a personal cloud which contains even a moderate number of categories of information and authorized accessors has crossed the complexity threshold into RBAC territory.
- That a Personal Cloud containing retail transactions, healthcare data, quantified self, security, entertainment, personal experiential data (photos, GPS tracks, Google Glass records, etc.), home automation, appliance metadata, and which interacts with family, friends, colleagues, service providers, retail providers, devices, community groups, professional affiliations and more, is so far past the threshold of complexity of requiring some form of RBAC that there is no reasonable argument to the contrary.
This is all IMHO, of course. I’m open to persuasive arguments to the contrary.