Cloud computing has changed some things: scalability, for example, and the cost model for web application hosting. But when it comes to security, the basics still apply. There are four tenets of security:
- Access control
Let’s look at each in turn. To help make the discussion concrete, here’s a fictitious example. Suppose Airbus and Boeing are collaborating on a new Joint Strike Fighter. Rather than exchange huge engineering design documents via between worldwide teams every night, which is what projects of that scale used to entail, the teams will collaborate using a more modern and manageable mix of:
- Centralized document repositories, such as SharePoint
- Security token server, such as ADFS (Active Directory Federation Services) or Shibboleth
- Password-based and multi-factor authentication technologies, such as smart card or one-time password
Auditing refers to the ability, after the fact, to determine what happened. For example, on a sensitive project such as the JSF, it’s critical to periodically verify that the people and devices that have been accessing SharePoint are really the ones that should be doing so.
Authentication refers to how identity is established. For example, a user in possession of a smart card provisioned with a trusted X.509 certificate, plus knowledge of the smart card PIN, will use the card to authenticate, thereby establishing his or her identity within the system. Devices can also have identity. Another authentication consideration is how identity is being represented: in the JSF federation scenario, identity might be represented by user email address plus other metadata such as project group membership.
Access control refers to the ability of the system to selectively allow or deny principals to perform actions on protected objects. Access control enforces authorization rules.
Authorization refers to the – usually increasingly complex – process by which access control rules are expressed. For example, on the JSF project, it may be necessary to define authorization rules granting auditing staff read-only access to documents on cost expenditures and accounting staff read/write access to those documents.
In order to support complex, collaborative projects such as a design of a JSF, security software has become increasingly complex. For example, the most sensitive data may only be accessible to users with specified project group membership, with certain national citizenship, and from provably secure client hardware. But how to define an authorization language that allows such rules to be expressed by a typical system administrator? The rules can get even more complex: suppose Airbus trusts identity data regarding JSF weapon system group membership originating from Boeing, since Boeing is contributing to that system. But claims regarding propulsion system group membership from Boeing must be ignored, since that subsystem belongs to Airbus.
Looking at the current state of the art, the capability of expressing such rules exists in the form of standardized technologies such as SAML and XACML. While some ramp-up is required, especially when it comes to complex collaborations, sophisticated line of business application integration with those standards is available.