– Lori MacVittie, senior technical marketing manager at F5 Networks, says:
One theme has remained consistent throughout the evolution of cloud thus far – enterprise IT wants to retain control of both its data and access to it.
This is not an unreasonable demand. After all, it is enterprise IT – and its leadership – that will pay the price should customer data leak or regulations not complied with. Despite the growing view that cloud security is a joint, shared responsibility between customer and provider, it is enterprise IT that must put into place the mechanisms for both controlling and proving control over data and access, not cloud providers or integrators. The provider can offer services designed to provide that control, but it is not the one that must implement the polices or report on their effectiveness.
While a collaboration and file-sharing app has been moved to AWS, access controls have to remain in-house, according to Oliver Alvarez, lead enterprise security architect for the World Bank’s International Finance Corporation.
“We need to maintain control and custodianship of information,” he said.
Access control by its nature must include identity management. Without the means to manage the credentials and map authorization of access to data and services to those credentials, control is lost. If customer data is the lifeblood of an organization, identity stores are the heart’s valves, controlling when and where that data is moved and by whom.
TWO EMERGING ARCHITECTURES
Two architectures for control over identity and access are beginning to emerge, both having a common premise – identity stores are local, data and services are remote. In one architecture a provider – usually of a SaaS solution – deploys a virtual appliance on premise that brokers identity. This essentially enables LDAP/AD integration between the data center and the SaaS. In the second, a strategic control layer acting as a cloud services broker provides integration between environments using standard protocols, such as SAML, to enable control over authentication and authorization of cloud services.
The appliance model is an extension of agent-based services, merely expanded to the data center level. There are some concerns that go along with this model, chiefly that an external entity has control of an agent within the data center but in general this models appears to enjoy market acceptance, especially in cases where a standards-based approach is unavailable.
The alternative, standards-based model, uses the same brokering model but the broker is under the control of enterprise IT, not the provider. It relies on the same principles of abstraction we’ve come to recognize with virtualization and SDN as being beneficial to agility in the network and data center, putting a layer of control between resources and users so as to enable more flexibility in not just access control and identity management but in making routing decisions with respect to those resources.
That layer of control within enterprise IT is unlikely to go away for the very reasons cited above: control (governance) is a legal and operational necessity for enterprise IT. Cloud providers who fail to recognize this need and move to provide services supportive of that necessity are merely shooting themselves in the foot with respect to gaining more traction with enterprise customers.
Cloud gateways and broker services are going to end up enabling this architecture on the enterprise side. It is in providers’ best interests to make these architectures as painless to implement as possible.
