Private Cloud Security Challenges - Resource Pooling

  • Article

As a designer of a private cloud solution that uses a pool of resources that can be allocated to many different tenants, how can I ensure the proper isolation of resourceshttp://blogs.technet.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-85-24-metablogapi/5658.image_5F00_64BCDD48.png (network, compute, memory, storage) between tenants?

Security Functionality

Figure 1 lists a number of security capabilities that the security wrapper should include in the private cloud such as:

  • Identity and access management
  • Data protection
  • Monitoring
  • Management
  • Authentication
  • Authorization
  • Role-based access control
  • Auditing

The first paper in this series, "Solution for Private Cloud Security: Service Blueprint," describes these capabilities.

This section describes how these capabilities relate to the resource pooling attribute of private clouds. The following sections will describe how your design should apply these capabilities at each layer in the private cloud architecture.

The significant aspects of resource pooling in a private cloud that will affect your security design are:

  • Reuse of resources by different tenant applications
  • Co-location of services belonging to different tenants on the same physical server
  • The automated processes that handle the allocation and de-allocation of resources

Identity and access management systems will help you to manage the authentication and authorization that will control access to virtual resources by their owners. Within the enterprise, a single identity and access management system, will simplify the task of configuring and managing authentication and authorization for tenant applications and services, especially when there is a requirement to integrate several tenant applications with each other. If multiple identity and access management systems exist, then you can use federation services, such as those provided by ADFS, to integrate them where necessary.

Note:
This document is part of a collection of documents that comprise the Reference Architecture for Private Cloud document set. The Solution for Private Cloud is a community collaboration project. Please feel free to edit this document to improve its quality. If you would like to be recognized for your work on improving this document, please include your name and any contact information you wish to share at the bottom of this page

Although you can use authentication, authorization, and role-based controls to manage access to resources, in a private cloud you must also assume that credentials can be stolen or abused and that someone can gain access to resources that they should not be able to reach.

Data protection services will help to preserve the confidentiality of data stored in virtual environments.

Monitoring combined with automated responses will enable you to handle possible attacks in this complex environment, and logging will enable you to investigate and analyze problems and provide evidence to auditors.

Infrastructure Security

Your virtualization solution must enable you to isolate your host environment from the guest workloads and ensure isolation between the virtualized guest environments. Allowing access from the guest to the host could allow an attacker access to the private cloud infrastructure. Potentially, this would enable the attacker to damage or disrupt the entire cloud infrastructure, or to launch an attack on other virtual environments hosted in the cloud. Virtualization solutions typically allow you to configure what level of access, if any, you grant guest environments to the host.

Resource Pooling

Resource pooling in a private cloud enables virtualized resources to reassign dynamically to other tenants and to optimize resource usage. Your virtualization solution must clean any resources, especially storage and memory, before reassigning them to another tenant so that data belonging to the original tenant is not exposed to the new tenant. In the private cloud, automated processes typically handle the cleaning and allocation of resources to tenants.

In a typical cloud, the resources that a tenant uses could be hosted on any of the physical devices in the cloud that offer that resource. For example, when a client provisions and starts a virtual machine in the private cloud, that virtual machine could be hosted on any of the physical servers in the cloud. One consequence that follows from this arrangement is that the same physical machine could host applications and services with different levels of business criticality, and that those applications and services may themselves include very different security features, such as those that govern authentication.

Escalation of Service Importance Attacks

Your design must address the risk that that a low business impact service might be more easily compromised by an attacker, and the attacker can then exploit that weakness to attack the high business impact service running on the same physical server. An attack may involve trying to gain access to the high business impact service's data, or simply making the high value service unavailable by overloading the low value service.

To address this issue, you could:

  • Consider dividing the infrastructure into pools so that you can segregate the hosted applications, for example, running high business impact applications and services in their own pool. That pool may have more stringent security controls applied at the infrastructure layer or might only run applications and services with integrated security controls. This arrangement might affect service billing, with high security pools demanding premium billing. However, note that the resource pool approach may limit the efficiency of resource allocation in the private cloud and adds to the overall complexity of your solution.
  • Specify limits on the type of application that you will allow to run in the private cloud. For example, no services classified as being high business impact can run on the private cloud infrastructure.

The infrastructure layer typically includes network traffic monitoring in network devices such as switches. This type of monitoring can identify unusual traffic that may indicate that an attack on the infrastructure is in progress or that some element in the cloud is compromised.

Network Virtualization

In a private cloud, the hypervisor typically supports network virtualization to separate out the logical network traffic associated with different network environments. In some cases, where guest environments happen to be located on the same physical server, this may mean that network traffic does not pass through a physical switch device and so may not be monitored. While this behavior can improve performance the private cloud, it does introduce the risk that your network analysis tools are not scrutinizing all “interesting” traffic. You must determine whether this risk is acceptable or whether you must mitigate it by using one of the following approaches:

  • Route all network traffic through your physical network devices.
  • Add additional monitoring functionality to each server to monitor each virtual network.
  • Use a virtualization solution that enables virtualized network traffic monitoring devices. For example, see Overview of the Hyper-V Extensible Switch.

You should plan to ensure that network traffic between virtual machines is encrypted to protect it as it is moves through the cloud infrastructure. Encrypting traffic on the wire means that intrusion detection systems and intrusion prevention systems will not be able to inspect the traffic. However, you can still use IPsec to provide authentication (for example by using AuthIP and ESP-NULL), which enables the parties to be sure of each other's identities, detect any tampering of the payload, and optionally guard against replay attacks.

Whole Volume Encryption

You should also plan to perform whole volume encryption (for example using BitLocker) to protect physical storage media in case an attacker gains access to the underlying physical storage infrastructure from within a virtual environment (virtual machines should only have access to the virtual storage devices allocated to them).

As always, evaluate the trade-off between performance and security that arises with any encryption technique. Different encryption algorithms offer different performance characteristics and different levels of protection. Keep in mind that not all traffic needs to be authenticated and encrypted – design over-the-wire encryption into your plan where it makes the most sense.

Platform Security

Typically, the virtual environment used by a tenant application or service in a private cloud consists of virtual compute, memory, storage, and network resources. The virtualization solution that you adopt must ensure the isolation of all of these resources (and any others that may be used) for each tenant. For example, Hyper-V maintains strict isolation between the compute and memory services of virtual machines running on the same host, enables you to define isolated VLANs, and enables each virtual machine to use its own virtual hard disks. If two or more tenant applications hosted in different virtual machines do require access to a shared resource, such as when two hosted applications may require network connectivity or access to the same database server, this sharing must be managed such that only the participating applications have access, and the shared use is actively monitored.

Although controls should be in place in the infrastructure layer to protect the hosted virtual environments, you should adopt the defense in depth principle and assume that an attacker could discover a weakness in the infrastructure security and try to gain access to the platform (or virtualized operating system) that hosts the tenant application or service. You should ensure that:

  • All virtual machines have a host-based firewall configured to protect them from network attacks from the external world, other virtual machines, or the underlying infrastructure.
  • All host-based firewalls only allow inbound and outbound traffic from and to the specific machines with which they must communicate.

You can also use IPsec to logically isolate groups of hosted virtual machines so that they cannot communicate outside of the group with other hosts on the network. For example, if you have a multi-tier application hosted in your private cloud, then you could use IPsec to ensure that the database server can only be reached from the middle-tier server, and that the middle-tier server can only be reached from the front-end web server.

All administrative access from operations staff and the owner of the virtual resource should be fully authenticated, authorized, logged, and audited.

Software Security

Applications and services running in the private cloud can protect their data in a number of ways. The design of these security features will be the responsibility of the application designer, not the designer of the cloud infrastructure. However, the cloud service provider (CSP) should take steps to ensure that the application designer is aware of the data protection services and other security features that are provided by the cloud infrastructure, and of any specific features of the cloud infrastructure that might influence the design of the application or service.

Some specific issues that an application or service designer should address include the encryption techniques they use to protect their data and how the disaster recovery planning services provided by the cloud work with their application.

For example, the infrastructure layer may use whole volume encryption to provide protection for data stored on that volume in the event that an attacker gains direct access to the underlying storage. From within a virtual machine, applications can access their stored data without decrypting it because the infrastructure performs the decryption on behalf of the virtualized environment. Because of this feature, an application hosted in a virtual machine in the cloud may require its own encryption services for sensitive data so that if an attacker gains access to the virtual machine, he or she will be unable to access the sensitive data.

A tenant application may encrypt data in storage, data in memory, and data during processing to make it more difficult for someone to read, intercept, or tamper with it in a tenant application or service even if they have gained authenticated and authorized access to the tenant's environment. However, all encryption techniques rely on the existence of a private key to perform both encryption and decryption in the case of a symmetric encryption algorithm, or decryption in the case of an asymmetric algorithm. However strong the encryption algorithm, it is useless if someone gains unauthorized access to the private key.

The difficulty faced by cloud solutions (both private and public) is how best to protect the private key. You must consider the following factors:

  • Any encryption technique must use private or secret keys to decrypt encrypted data. In a virtual machine, this private or secret key must be stored somewhere inside of the virtual machine so that the application can decrypt its data. If attackers gain access to the virtual machine, they may be able to gain access to any private keys stored inside the virtual machine, rendering any encryption worthless.
  • The owner of the application that uses data encryption within the virtual machine must take steps to protect any private or secret encryption keys. This protection must be effective when the virtual machine is running or dormant, and must be effective for any backup or archive copies of the virtual environment.
  • Tenants should use any secure key storage facilities offered by the platform or virtualized operating systems to store the private keys used by their application.
  • Tenants should follow strict procedures to protect keys from being discovery outside of the virtual environment. For example, tenants should use separate keys during development and test, and securely delete local copies of keys after they have been uploaded and installed in the virtual environment where they will be used.

In a private cloud, the cloud infrastructure may move tenant applications to different physical servers or even different data centers to maintain availability in the face of hardware failures or to optimize performance or resource utilization. Any encryption techniques used by tenant applications to protect data must continue to be effective in these scenarios. Any automated processes that move applications and services to different physical devices must ensure that any keys used to protect application data continue to be available to the applications and services that need them; if this approach requires keys to be copied between locations, the automated process must ensure that this transfer process is secure.

Clients should also consider encrypting data during processing in their tenant application. For example, data stored temporarily in a queue or data stored in memory could become visible in a memory dump if a server or virtual machine experiences a stop error.

Management Security

SLAs between the cloud service provider and the client business units should specify what level of access to client data in what circumstances is permitted to operations staff. All management operations, whether performed by the cloud service provider or consumer must be logged and be auditable.

In many regions, there is legislation that relates to data protection and privacy. In a private cloud, you must ensure that it is clear who within the organization is responsible for compliance. For example, the IT department might be responsible for ensuring proper isolation between the virtual environments used by the different business units, but a business unit might be responsible for ensuring that their application or service is compliant.

Hybrid clouds or the use of distributed clouds across different geographic regions to provide better performance or more resilience might also complicate the issue of monitoring for compliance: it may not be permissible to move some data across geographic regions, legal data protection and privacy requirements might be different in different regions. In these scenarios, you must enable a client business unit to specify where their cloud-hosted application or service can run.

REFERENCES:

ACKNOWLEDGEMENTS LIST:
If you edit this page and would like acknowledgement of your participation in the v1 version of this document set, please include your name below:
[Enter your name here and include any contact information you would like to share]

Return to Private Cloud Security Challenges[

Return to Design Guide for Private Cloud Security](http://social.technet.microsoft.com/wiki/contents/articles/6644.design-guide-for-a-solution-for-private-cloud-security.aspx)

Return to A Solution for Private Cloud Security

Return to Reference Architecture for Private Cloud

Move forward to Private Cloud Security Challenges - Broad Network Access

Table of Contents for A Solution for Private Cloud Security