Introduction to Cloud Security Architecture from a Cloud Consumer's Perspective

Introduction

Cloud application developers and devops have been successfully developing applications for IaaS (Amazon AWS, Rackspace, etc) and PaaS (Azure, Google App Engine, Cloud Foundry) platforms. These platforms provide basic security features including support for authentication, DoS attack mitigation, firewall policy management, logging, basic user and profile management but security concerns continue to be the number one barrier for enterprise cloud adoption. Cloud security concerns range from securely configuring virtual machines deployed on an IaaS platform to managing user privileges in a PaaS cloud.

Given that the cloud services can be delivered in many flavors i.e. in any combination of service delivery models, SaaS, PaaS and IaaS (SPI), and operational models, public, private and hybrid, the cloud security concerns and solutions are context (pattern) dependent. Hence, the solution architecture should match these concerns and build security safeguards (controls) into the cloud application architecture.

So what are the architectural frameworks and tools that cloud application architects and devops have at their disposal when developing applications for IaaS and PaaS platforms? In this article, I’ll discuss the approach to baking “adequate” security into your application deployed in IaaS and PaaS clouds .

Cloud Security – Shared Responsibility

First, let’s talk about the cloud security operational model. By definition, cloud security responsibilities in a public cloud are shared between the cloud customer (your enterprise) and the cloud service provider where as in a private cloud, the customer is managing all aspects of the cloud platform. Cloud service providers are responsible for securing the shared infrastructure including routers, switches, load balancers, firewalls, hypervisors, storage networks, management consoles, DNS, directory services and cloud API.

The figure below highlights the layers, within a cloud service, that are secured by the provider versus the customer.

(Click on the image to enlarge it)

Prior to signing up with a provider, it is important to perform a gap analysis on the cloud service capabilities. This exercise should benchmark the cloud platform’s maturity, transparency, compliance with enterprise security standards (e.g. ISO 27001) and regulatory standards such as PCI DSS, HIPAA and SOX. Cloud security maturity models can help accelerate the migration strategy of applications to the cloud. The following are a set of principles you can apply when evaluating a cloud service provider’s security maturity:

• Disclosure of security policies, compliance and practices: The cloud service provider should demonstrate compliance with industry standard frameworks such as ISO 27001, SS 16 and CSA Cloud controls matrix. Controls certified by the provider should match control expectations from your enterprise data protection standard standpoint. When cloud services are certified for ISO 27001 or SSAE 16, the scope of controls should be disclosed. Clouds that host regulated data must meet compliance requirements such as PCI DSS, Sarbanes-Oxley and HIPAA.
• Disclosure when mandated: The cloud service provider should disclose relevant data when disclosure is imperative due to legal or regulatory needs.
• Security architecture: The cloud service provider should disclose security architectural details that either help or hinder security management as per the enterprise standard. For example, the architecture of virtualization that guarantees isolation between tenants should be disclosed.
• Security Automation – The cloud service provider should support security automation by publishing API(s) (HTTP/SOAP) that support:
  • Export and import of security event logs, change management logs, user entitlements (privileges), user profiles, firewall policies, access logs in a XML or enterprise log standard format.
  • Continuous security monitoring including support for emerging standards such as Cloud Audit.
• Governance and Security responsibility: Governance and security management responsibilities of the customer versus those of the cloud provider should be clearly articulated.

Cloud Security Threats and Mitigation

Does cloud computing exacerbate security threats to your application? Which emerging threats are relevant? Which traditional threats are amplified or muted? Answers to these questions are dependent on the combination of cloud service deployment and operational models in play. The following table illustrates the dependencies which should be taken into consideration when architecting security controls into applications for cloud deployments:

In addition to the aforementioned threats to information confidentiality and integrity, threats to service availability need to be factored into the design. Please remember that the basic tenets of security architecture are the design controls that protect confidentiality, integrity and availability (CIA) of information and services.

Threat to cloud service availability - Cloud services (SaaS, PaaS, IaaS) can be disrupted by DDoS attacks or misconfiguration errors by cloud service operators or customers. These errors have the potential to cascade across the cloud and disrupt the network, systems and storage hosting cloud applications. To achieve continuously availability, cloud applications should be architected to withstand disruptions to shared infrastructure located within a data center or a geographic region. This vulnerability is best illustrated by the recent Amazon outage when Elastic Block Storage (EBS) brought down customer applications deployed within a single availability zone in US east region. However, applications that were architected to tolerate faults within a region were largely shielded from this outage and continued to be available to the users. As a design principle, assume everything will fail in cloud and design for failure. Applications should withstand underlying physical hardware failure as well as service disruption within a geographic region. Loose coupling of applications and components can help in the latter case.

Cloud Security Architecture – Plan

As a first step, architects need to understand what security capabilities are offered by cloud platforms (PaaS, IaaS). The figure below illustrates the architecture for building security into cloud services.

(Click on the image to enlarge it)

Security offerings and capabilities continue to evolve and vary between cloud providers. Hence you will often discover that security mechanisms such as key management and data encryption will not be available. For example: the need for a AES 128 bit encryption service for encrypting security artifacts and keys escrowed to a key management service. For such critical services, one will continue to rely on internal security services. A “Hybrid cloud” deployment architecture pattern may be the only viable option for such applications that dependent on internal services. Another common use case is Single Sign-On (SSO). SSO implemented within an enterprise may not be extensible to the cloud application unless it is a federation architecture using SAML 1.1 or 2.0 supported by the cloud service provider.

The following are cloud security best practices to mitigate risks to cloud services:

• Architect for security-as-a-service – Application deployments in the cloud involve orchestration of multiple services including automation of DNS, load balancer, network QoS, etc. Security automation falls in the same category which includes automation of firewall policies between cloud security zones, provisioning of certificates (for SSL), virtual machine system configuration, privileged accounts and log configuration. Application deployment processes that depend on security processes such as firewall policy creation, certificate provisioning, key distribution and application pen testing should be migrated to a self-service model. This approach will eliminate human touch points and will enable a security as a service scenario. Ultimately this will mitigate threats due to human errors, improve operational efficiency and embed security controls into the cloud applications.
• Implement sound identity, access management architecture and practice – Scalable cloud bursting and elastic architecture will rely less on network based access controls and warrant strong user access management architecture. Cloud access control architecture should address all aspects of user and access management lifecycles for both end users and privileged users – user provisioning & deprovisioning, authentication, federation, authorization and auditing. A sound architecture will enable reusability of identity and access services for all use cases in public, private and hybrid cloud models. It is good practice to employ secure token services along with proper user and entitlement provisioning with audit trails. Federation architecture is the first step to extending enterprise SSO to cloud services. Refer to cloud security alliance, Domain 12 for detailed guidance here.
• Leverage APIs to automate safeguards – Any new security services should be deployed with an API (REST/SOAP) to enable automation. APIs can help automate firewall policies, configuration hardening, and access control at the time of application deployment. This can be implemented using open source tools such as puppet in conjunction with the API supplied by cloud service provider.
• Always encrypt or mask sensitive data – Today’s private cloud applications are candidates for tomorrow’s public cloud deployment. Hence architect applications to encrypt all sensitive data irrespective of the future operational model.
• Do not rely on an IP address for authentication services – IP addresses in clouds are ephemeral in nature so you cannot solely rely on them for enforcing network access control. Employ certificates (self-signed or from a trusted CA) to enable SSL between services deployed on cloud.
• Log, Log, Log – Applications should centrally log all security events that will help create an end-to-end transaction view with non-repudiation characteristics. In the event of a security incident, logs and audit trails are the only reliable data leveraged by forensic engineers to investigate and understand how an application was exploited. Clouds are elastic and logs are ephemeral hence it is critical to periodically migrate log files to a different cloud or to the enterprise data center.
• Continuously monitor cloud services – Monitoring is an important function given that prevention controls may not meet all the enterprise standards. Security monitoring should leverage logs produced by cloud services, APIs and hosted cloud applications to perform security event correlation. Cloud audit (cloudaudit.org) from CSA can be leveraged towards this mission.

Cloud Security Principles

Every enterprise has different levels of risk tolerance and this is demonstrated by the product development culture, new technology adoption, IT service delivery models, technology strategy, and investments made in the area of security tools and capabilities. When a business unit within an enterprise decides to leverage SaaS for business benefits, the technology architecture should lend itself to support that model. Additionally the security architecture should be aligned with the technology architecture and principles. Following is a sample of cloud security principles that an enterprise security architect needs to consider and customize:

• Services running in a cloud should follow the principles of least privileges.
• Isolation between various security zones should be guaranteed using layers of firewalls – Cloud firewall, hypervisor firewall, guest firewall and application container. Firewall policies in the cloud should comply with trust zone isolation standards based on data sensitivity.
• Applications should use end-to-end transport level encryption (SSL, TLS, IPSEC) to secure data in transit between applications deployed in the cloud as well as to the enterprise.
• Applications should externalize authentication and authorization to trusted security services. Single Sign-on should be supported using SAML 2.0.
• Data masking and encryption should be employed based on data sensitivity aligned with enterprise data classification standard.
• Applications in a trusted zone should be deployed on authorized enterprise standard VM images.
• Industry standard VPN protocols such as SSH, SSL and IPSEC should be employed when deploying virtual private cloud (VPC).
• Security monitoring in the cloud should be integrated with existing enterprise security monitoring tools using an API.

Cloud Security Architecture Patterns

Architecting appropriate security controls that protect the CIA of information in the cloud can mitigate cloud security threats. Security controls can be delivered as a service (Security-as-a-Service) by the provider or by the enterprise or by a 3^rd party provider. Security architectural patterns are typically expressed from the point of security controls (safeguards) – technology and processes. These security controls and the service location (enterprise, cloud provider, 3^rd party) should be highlighted in the security patterns.

Security architecture patterns serve as the North Star and can accelerate application migration to clouds while managing the security risks. In addition, cloud security architecture patterns should highlight the trust boundary between various services and components deployed at cloud services. These patterns should also point out standard interfaces, security protocols (SSL, TLS, IPSEC, LDAPS, SFTP, SSH, SCP, SAML, OAuth, Tacacs, OCSP, etc.) and mechanisms available for authentication, token management, authorization, encryption methods (hash, symmetric, asymmetric), encryption algorithms (Triple DES, 128-bit AES, Blowfish, RSA, etc.), security event logging, source-of-truth for policies and user attributes and coupling models (tight or loose).Finally the patterns should be leveraged to create security checklists that need to be automated by configuration management tools like puppet.

In general, patterns should highlight the following attributes (but not limited to) for each of the security services consumed by the cloud application:

• Logical location – Native to cloud service, in-house, third party cloud. The location may have an implication on the performance, availability, firewall policy as well as governance of the service.
• Protocol – What protocol(s) are used to invoke the service? For example REST with X.509 certificates for service requests.
• Service function – What is the function of the service? For example encryption of the artifact, logging, authentication and machine finger printing.
• Input/Output – What are the inputs, including methods to the controls, and outputs from the security service? For example, Input = XML doc and Output =XML doc with encrypted attributes.
• Control description – What security control does the security service offer? For example, protection of information confidentiality at rest, authentication of user and authentication of application.
• Actor – Who are the users of this service? For example, End point, End user, Enterprise administrator, IT auditor and Architect.

Here is a subset of the cloud security architecture pattern published by open security architecture group (opensecurityarchitecturegroup.org).

(Click on the image to enlarge it)

This pattern illustrates the actors (architect, end user, business manager, IT manager), interacting with systems (end point, cloud, applications hosted on the cloud, security services) and the controls employed to protect the actors and systems (access enforcement, DoS protection, boundary protection, cryptographic key & management, etc). Let’s look at details communicated by the pattern.

Infrastructure Security services (controls) at cloud service providers

As per the pattern a cloud service provider is expected to provide security controls for DoS protection and protection of confidentiality and integrity for sessions originating from Mobile as well as PC. Typically these sessions initiated by browsers or client applications and are usually delivered using SSL/TLS terminated at the load balancers managed by the cloud service provider. Cloud service providers usually don’t share the DoS protection mechanisms as hackers can easily abuse it.

Application Security Services (in-house or cloud service provider)

Security services such as user identification, authentication, access enforcement, device identification, cryptographic services and key management can be located either with the cloud service provider, within the enterprise data center or some combination of the two.

The second pattern illustrated below is the identity and access pattern derived from the CSA identity domain.

(Click on the image to enlarge it)

This pattern illustrates a collection of common cloud access control use cases such as user registration, authentication, account provisioning, policy enforcement, logging, auditing and metering. It highlights the actors (end user, enterprise business user, third party auditor, cloud service owner) interacting with services that are hosted in the cloud, in-house (enterprise) and in third party locations.

This pattern communicates the following:

Identity Security services (controls) at cloud service providers

The cloud hosts the following services:

• Authentication service that supports user authentication originating from an enterprise portal (Local AuthN UI) and typically delivered using SAML protocol. The authenticated session state is maintained in a cloud session store.
• Account and profile provisioning service supports the provisioning of new accounts and user profiles, typically invoked via SPML (Service Provisioning Markup Language) or a cloud service provider specific API. Profiles are stored in the user profile store.
• Cloud policy admin service is used for managing policies that dictate which resources in the cloud can be accessed by end users. Using this service, cloud service owners (enterprise) can perform administrative functions and end users can request for access to cloud resources. Cloud policies are stored in the cloud policy store.
• Logging and auditing service supports dual functions. The first function is event logging, including security events, in the cloud and the second is for audit purposes. Cloud Audit protocols and APIs can be employed to access this service.
• Metering service keeps track of cloud resource usage. Finance departments can use this service for charge-back as well as for billing reconciliation.

Identity Security services in the Enterprise

In this pattern, a subset of the applications is hosted in the enterprise:

• Cloud registration UI provides the UI service for end users to register, manage and provision new cloud resources. Authentication and Authorization is enforced by the cloud services.
• Cloud usage reporting UI is utilized by end users to generate usage reports.
• Cloud provisioning service is used to provision cloud resources (compute, storage, network, application services). Access control (AuthN, AuthZ) and session management are enforced at the cloud service end. 

Identity Security services at the third party location

In this pattern, cloud applications rely on identity services offered by a third party and hosted at their location. These services offer support for third party users who will need access to cloud resources to perform business functions on behalf of the enterprise. For example backup and application monitoring services. In this model, user provisioning, authentication and access enforcement functions are delegated to the third party service.

Conclusion

By understanding what you can leverage from your cloud platform or service provider, one can build security into your application without reinventing the capability within your application boundary thus avoiding costly “bolt-on” safeguards. A good practice is to create security principles and architectural patterns that can be leveraged in the design phase. Architectural patterns can help articulate where controls are enforced (Cloud versus third party versus enterprise) during the design phase so appropriate security controls are baked into the application design. Keep in mind the relevant threats and the principle of “risk appropriate” when creating cloud security patterns. Ultimately a cloud security architecture should support the developer’s needs to protect the confidentiality, integrity and availability of data processed and stored in the cloud.

About the Author

Subra Kumaraswamy is the chief security architect for eBay and leads the team with mission of making eBay the most trusted commerce market place. Prior to joining eBay, Subra was a Security Architect for Oracle's OnDemand Platform Service. Previously, he led various security initiatives including IT identity and securing cloud services at Sun Microsystems. Subra frequently speaks on the topics of identity, cloud and mobile security and is the co-author of the O'Reilly publication "Cloud Security and Privacy - An Enterprise Perspective on Risks and Compliance". Subra is a founding member of the Cloud Security Alliance and co-chair of the Identity and Access Mgmt work group. Subra co-founded Zingdata and Coolsync Inc which were acquired by Knowledge Networks and Blink.com respectively. Subra has held leadership roles at Accenture, Netscape, Lycos and Sun Microsystems.
Subra has a Masters degree in Computer Engineering from Clemson University. Subra is CISSP and CISM certified. Twitter: @subrak

References 

• Cloud Security Alliance guidance
• Trusted Cloud Initiative
• Building Customer Trust in Cloud Computing with Transparent Security – Sun Microsystems
• NIST Cloud Computing Reference Architecture
• Cloud Security and Privacy: An enterprise perspective on risks and compliance by Tim Mather, Subra Kumaraswamy, Shahed Latif – O’Reilly – ISBN: 0596802765
• Open Security Architecture (OSA)