SOA Security with .NET and Windows Azure Security (part 1) - Cloud Computing Security 101

Cloud Computing Security 101

Cloud-based services and service-oriented solutions deployed on cloud platforms can typically leverage and be designed with existing security frameworks. However, the fact that some or all parts of a given service composition reside in an environment external to the controlled IT enterprise raises several additional security considerations.

Some of the most common distinct security considerations for cloud-based services and service compositions include the following:

• data privacy– Your data is being hosted in someone else’s data center.

• shared and virtualized resources– The service’s physical infrastructure, to varying degrees between cloud platforms, may be shared among multiple tenants.

• multi-tenancy– The service hosting processes and the exchanged data are executed and managed in shared environments.

• heterogeneity– The service may be implemented in a cloud hosting platform that uses highly generic policies and lowest-denominator frameworks, on top of a heterogeneous infrastructure.

• Internet transit– Distributed communications are mostly transmitted over public Internet protocols and transports.

• lack of control– Cloud platforms abstract infrastructure complexity, which can include hiding the control and administrative mechanisms necessary to meet specific security requirements.

• lack of standards– Cloud platforms are mostly specialized implementations. Standards-based data exchange is often supported, but management, governance, and security controls are often abstracted into the implementation and not standardized.

When these types of security issues surface they need to be addressed early on to ensure that services and data remain functional and protected, especially within hybrid architectures that require regular communication within a service composition comprised of services that reside inside and outside of enterprise boundaries.

Cross-Domain Access Control

Cloud computing adds to the service-oriented technology architectural model the dimension of managing access control over services deployed across highly distributed environments. This can be a hybrid cloud model for one organization having assets in both internal and external environments, but it can encompass multi-enterprise collaboration scenarios across different security domains.

Cross-domain access control is about authorization, not authentication. This means that even when spanning domain boundaries, we can reuse existing user authentication and identity management systems, and then extend them to accommodate cloud-based services access requirements.

Hybrid Cloud Security

Hybrid clouds represent the most relevant model when trying to extend an on-premise or internal service-oriented solution to a cloud platform. In general, this points to scenarios where an organization has assets deployed in both on-premise and external cloud environments. The challenge is, now that there are assets deployed outside of the organization’s own network environment and security domain, how can we provide secured, single sign-on access to those cloud-based services?

The key is in understanding how we can leverage already centralized security and identity infrastructure without replicating it in another environment and without having distributed services access it over the public Internet.

Traditional practices generally advocate replicating and caching identity directories in different environments across which we want to enable cross-domain interoperability. Such is the case especially when a single IT enterprise has two or more established domain service inventories. However, when exploring this approach with cloud-based services, it can be error-prone, complex and expensive to implement. It would further have to deal with policy distribution, systems management, and auditing. As a result, it may be more practical and effective to try and establish a VPN connection with the cloud provider. But even that option can raise a whole other set of issues.

Ideally, an external cloud environment in a hybrid cloud model would represent a separate security domain. Considerations for access control for cloud-based services would then center on approaches to bridge the separate security domains.

Inter-Organization Service Composition Security

Facilitating service compositions across organizational boundaries is nothing new. It has been a consistent focus area in various past service-oriented architecture implementations, as well as B2B integration architectures and multi-enterprise collaboration frameworks. However, similar to cloud computing, managing access control over automated systems and processes has been challenging.

For example, most implementations today use highly specialized connections (such as FTP, EDI networks, VPNs, dedicated circuits, Web services endpoints exposed in the network perimeter, etc.). These point-to-point models can be brittle in that they suffer from the classic “one-off” syndrome that has plagued silo-based application development and integration architectures. These problems are further compounded when we create individual single-purpose channels for individual partner organizations (or even individual applications with larger partner organizations) and then need to further assume the responsibility of managing identities and their lifecycles.

Different options exist for addressing these issues, including the use of generic or system accounts shared between services and/or individual users. However, ultimately, the considerations in this area also boil down to bridging separate security domains.

External Identity Providers

Online digital identity providers, such as cloud-based authentication services (Windows Live ID, Google Account, Yahoo ID, OpenID, etc.) can be used with various consumer-facing architectures. These implementations evolved from organizations providing their own consumer identity management systems for other organizations to use as a service.

Externalizing consumer-centric membership and identity management systems enables organizations to reuse already provided systems instead of investing in and running their own. It further helps consumers to reduce the number of digital identities they have to manage. However, external identity providers also represent separate security domains, and the same considerations will need to be applied when implementing access control to services intended for these identities to access.

Claims-Based Access Control, As-A-Service

Claims-based identity is the foundational component in an Identity Metasystem architecture. It helps identity management systems across distinct and autonomous security domains to seamlessly interoperate and provide standards-based, secured access to data and services.

The high-level conceptual components include:

• claims – a fact about an entity (the subject) stated by another entity (the authority)

• trust – one entity is said to trust another if it considers the claims issued by the other entity to be true

• tokens – an XML construct signed by an authority containing claims and (possibly) credentials

• Security Token Services (STS) – a Web service that issues security tokens as described by WS-Trust

This model works because it enables a trust relationship between two separate security domains to scale and effectively interoperate in a loosely coupled manner without having to invest in one-off or specialized integration approaches between individual identity systems and management policies. Services don’t need to implement their own identity management systems or tightly-coupled integrations with an existing identity infrastructure. They can externalize those aspects and reuse the Identity Metasystem to support single sign-on requirements across multiple security domains.

Claims-based authorization can be used by any form of distributed application regardless of where it is deployed (on-premise, cloud, hybrid, or otherwise). Its flexibility to support virtually all types of generic access control scenarios, plus its support for industry standards-based interoperability, means it can also be used for cloud computing and bridging multiple security domains (such as with hybrid clouds). In fact, claims-based identities can be implemented for cloud-based services the same way they are implemented for on-premise systems. However, there are a few unique aspects that need to be taken into account.

Any solution intended to accommodate the Internet and cloud computing needs to be scalable. In this case, claims-based authorization across multiple security domains traditionally leverages identity federation approaches. However, most identity federation implementations require direct trust relationships with the STS, and applying that same model here means each organization still needs to establish direct trust relationships with each of the security domains it wishes to bridge.

This approach is technically feasible and can still be implemented according to specific requirements. However, given the brittle nature of the resulting security architecture, it would be increasingly more difficult to scale as the organization moves towards more complex service composition models that will likely need to interact with more and more security domains outside the organization’s security boundaries.

The appropriate solution is to establish claims-based access control as a (cloud-based) service. Conceptually, this represents a rendezvous destination for trust relationships from separate security domains where it can provide brokered indirect trust and claims mapping and transformation processing. This approach allows an organization to establish one trust relationship with the access control service and then enable it to reuse and extend that one relationship, brokered by the access control service, with any number of distinct security domains that also trust the access control service.