Andrew Brown
Andrew Brown

Much ink has been spilled on the topic of cloud security and much of the discussion adheres to the same premises underpinning web services and service-oriented architecture (SOA) security. Whether cloud services are delivered within a “private cloud” or across the open internet, many management and governance challenges stand in the way of success – and, in fact, offer many avenues for failure, even catastrophe, on a grand scale. In other words, don't adopt this new technology without addressing security up front.

Rarely in history have companies publicly documented the capabilities of their business applications, their location on the network, not to mention the security mechanisms used to safeguard them. With internet-based crime becoming increasingly professionalized, and outstripping many traditional defenses, companies are openly

(even eagerly) providing detailed blueprints for business applications. For this reason, cloud providers are at risk from hackers, imposters and, never forget, internal employees and IT administrators.

The implication here is that providers of cloud application programming interfaces (APIs) need to take great care in defining and implementing access control mechanisms that enforce the organization's broader policies – as they apply to corporate relationships and duties, as well as the various industry and government regulations that apply.

This still sounds like SOA 101. What's different with the cloud? I would argue that one key difference would be that SOA dealt more explicitly with machine-to-machine messaging, and therefore addressed much more directly the architectural issues behind “message level” security. If your company is moving to the cloud and has already adopted the basic tenets of SOA security, which include many flexible and (for the most part) interoperable ways to attain authentication and authorization, integrity and confidentially – then you have relatively easy access to the primitives underlying application security.

With cloud APIs, it's essential to balance security against usability and maintainability. Providers need to protect services and data, but they also need to avoid placing too great a burden on service consumers.

REST (representational state transfer) has emerged as a core enabling “architecture” for cloud services for its very simplicity, and is finding rapid adoption due to its “architectural flexibility.” Make security too onerous and your reuse metrics may suffer as a result. Make security too flimsy, and you could lose your business. A core tenet of REST states that you should rely on the infrastructure of the web. In other words, use SSL and HTTP basic for all your security needs.

There are no standards for REST, which means there's no standard way to apply policies to REST-ful services. The one attempt to define some form of security into the message REST-fully has been through “API keys.” Providers need to consider the limitations associated with API keys and contrast those with application-level approaches that offer more standardization and interoperability.

The policy-based approach to governance provides the benefit of decoupling policy enforcement from application implementation. A policy-based system enables you to expose services, as SOAP (simple object access protocol) or REST (or perhaps as both), while maintaining the same level of policy compliance. The key is to abstract security out of your application code, codify it in policy and then centrally monitor and manage application security in real time to prevent break-ins and other lapses in governance.


Andrew Brown is director of security strategy at Oakland, Calif.-based AmberPoint.