CIO — Last week, we explored the 7 basics of cloud computing vendor security, including identity, authentication, encryption, ILP/DLP and audit trails. Now here comes the deep dive: access control.

Depending on what your cloud application is doing, there will be several levels of access control. The simplest is at the file level: the operating system will enforce user/group/world or access control lists on every file in the system. Once a remote process has had credentials authenticated, the operating system will properly enforce the C/R/U/D privileges according to the running user's role or profile. Most operating systems also enforce access control on processes and system objects. This course-grained access management is basic and fairly uniform across cloud systems — not much to discover there.

In a similar way, DBMS systems will be fairly uniform in the way they enforce security across clouds. All DBMS security systems offer at least table-level enforcement of access control, and most offer column-level restrictions as well. Further, the DBMS will enforce locks at the transactional level to manage contention and prevent corruption. The cloud doesn't really change much here, so there's not much of a challenge at this level.

Things get a lot more interesting at the application level, as cloud application vendors have had to put a lot more work into their access control mechanisms from the outset. This is where some of the real work of multi-tenancy has taken place. But the access control enforcement models tend to be very different across cloud application categories, as well as among specific vendors. For example, the details of data access and sharing are a whole lot different in a social network than they are in an accounting system, an ecommerce engine, an ERP system, or a CRM system. This is where you'll find the access control challenge when trying to integrate across clouds.

To make clear examples, I'm going to be using specifics from Salesforce.com. Please don't interpret this as shilling for them — it's just that they are a common target for cross-cloud integration and I understand their security model best.

Salesforce.com's access control is defined and enforced through a series of filters that is deceptively simple. The filters each apply to groups or classes of user accounts:

• Profiles define whether a class of users can see a table, object, or area of functionality
• Profiles define whether a class of users can see a table column (object attribute)
• Roles define whether a class of users can see a record (row or instance)
• Record types define which Profiles can see individual cells within a record, and can be used to restrict access to nearly any function or object class.

There are some modifiers for these filters to allow delegation and to broaden the span of control for superusers, but the experience for most users is that applying all these filtering mechanisms provides a very fine level of access control. Sometimes to the point of irritation. Locking and filtering may be context or state dependent...and get in the way of some required business needs. So the system provides exception methods for data sharing, granted at either the individual or group level.

All this is within a single Salesforce instance: they also have a mechanism for bridging instances so that companies can share individual records with their business partners in a separate instance ("org") of SFDC.

Continue Reading