Share via

Private Cloud Security Challenges - Broad Network Access

  • Article

As a designer of a private cloud solution, I want my solution to provide appropriate authentication and authorization services for the broad range of users accessing thehttp://blogs.technet.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-85-24-metablogapi/5658.image_5F00_64BCDD48.png cloud. Different services have different security requirements, such as different levels of security, access from multiple locations, or self-provisioning of users.

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

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

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

There is in an increasing demand from business users to enable support for a wider range of client devices such as mobile phones and tablets. These devices, along with more traditional clients, may be used both internally and externally to access corporate systems. These requirements, combined with the fact that private clouds may also enable on-demand self-service access to resources and have an infrastructure that is built to support virtualization and resource pooling, give rise to the following concerns that you should address in your private cloud design:

  • There is a much broader attack surface available to potential attackers, not only from outside the organization, but also from within. For example, if an attacker manages to compromise a guest operating system hosted within the private cloud, in effect you have an attacker operating within your data center.
  • Tenants may manage some aspects of the security of their virtual environments, including authentication and authorization.
  • There is no longer a clearly identifiable perimeter around your resources: an attack on a hosted service could potentially come from an external source, another hosted service, or from the infrastructure.

To mitigate these threats, you need to ensure that access to resources, applications, services is authenticated and authorized, and that all access is monitored, logged, and auditable. This must happen consistently regardless of the client device type. You may require different strengths of authentication (password, certificate, multifactor) based in the location of the client (private cloud, intranet, extranet, internet) and the sensitivity of the application's data (personally identifiable information, company confidential information, publicly available information).

Infrastructure Security

The use of virtualization technologies to build private cloud infrastructures means that there are new potential targets for attackers. By targeting the hypervisor technology that underpins the virtualization in a private cloud, an attacker may be able to disrupt the entire cloud or use the hypervisor to gain access to other virtual machines hosted in the cloud.

In the private cloud, the cloud service provider may give up some or all control of the virtualized resources to the tenant. Therefore, as the designer of the infrastructure that underpins the private cloud, you must take steps to ensure that the hypervisors and host operating systems are not accessible from the guest operating systems controlled by the tenants. In the private cloud, you must consider potential attacks originating from guest operating systems running within your data center as well as more traditional threats from outside your security perimeters.

The IaaS service delivery model implies a collection of infrastructure resources, such as compute, storage, and memory for running virtual machines, which any tenant at any time could potentially use. To support this model, the hypervisors are likely to require the same software and security configurations, which in turn means that they are all equally likely to be vulnerable to attack, possibly from a guest operating system. As described earlier in this paper, to mitigate this threat you may consider dividing your infrastructure resources into pools. This approach may affect the efficiency of your resource utilization in the cloud because certain tenant applications are constrained to run in a particular pool of hypervisors, but it does enable you to build security boundaries between the pools to limit the scope of any attack on the hypervisor infrastructure.

You might consider using hardware security features to detect unauthorized changes to the hypervisor. For example, Intel Trusted Execution Technology (TXT) can verify that a launch environment has not changed from a known good configuration.

You should minimize routing network traffic within the cloud infrastructure to minimize the number of locations where the infrastructure might be exposed to attack.

Platform Security

In the IaaS and PaaS private cloud models, the platform is typically a virtual machine hosted on the cloud infrastructure. The platform hosts the tenant's service or application, and client applications will access these services or applications from within the corporate network, from outside the corporate network, or potentially from other virtual machines running in the cloud. You must also assume that the host operating system could gain access to the virtual machine.

Supporting broad network access to the virtual machines in the platform means a greater potential attack surface. Although the cloud infrastructure should include systems and devices to protect the platform from attack, the platform cannot assume that it is protected and must be designed to protect itself. Every virtual environment must be protected by its own firewall and must run its own anti-malware software.

Software Security

In the IaaS and PaaS service delivery models, tenants may be wholly or partly responsible for the management of the applications and services that they chose to host in the cloud. Although there will be security features protecting the infrastructure and platform directly, a defense in depth approach means that the cloud service provider should not rely solely on these security features. By making it harder for an attacker to compromise a virtual environment managed by a tenant, the cloud service provider makes it harder for an attacker to use this route to attack the private cloud infrastructure.

Some of the options that you might consider to protect tenant software from attack include:

  • Apply strict controls to the software that tenants may run in their virtual environments such as limiting the available APIs or the permitted programming languages that they can use to develop hosted applications and services.
  • Lock down the security configuration, such as the firewall settings, in the platform or virtualized operating system such that the tenant cannot modify them.
  • Validate the tenant's software before they can deploy it to the private cloud.

All of these options may limit the utility of the private cloud solution because they conflict with the provision of other cloud attributes, especially the on-demand self-service attribute. These controls may also require completion of additional complex manual steps before the tenant's software can be deployed and used. Other mitigations to the threats that result from the cloud service provider not having full control over the security of tenant software include:

  • Use corporate policies to specify guidelines or methodologies that tenants must follow when they develop, commission, or purchase applications to run in the cloud. For example, corporate policy may mandate development teams within the organization to use the SDL methodology to improve the overall security of their products. This approach helps to shift the responsibility to the tenant, but you will still need to audit compliance.
  • Encourage tenants to use existing services as part of their solution wherever possible. The cloud service provider can manage the security of some enterprise wide services in the cloud, so that tenants do not have to re-implement them. For example, the CSF can provide identity federation services (such as Active Directory Federation Services or ADFS) in the cloud, you can make it easier for tenants to participate in single sign-on, and utilize your existing security infrastructure for identity management and access control rather than creating their own authentication and authorization mechanisms and expanding the available attack surface.

As you move through the cloud service delivery models from IaaS, through PaaS, to SaaS, the cloud service provider takes more responsibility for the security of the hosted application or service, and the tenant gives up more control of the environment and loses some degree of flexibility. The PaaS and SaaS models therefore make it easier for the cloud service provider to ensure consistent standards of security and to reduce the threat to the virtual environments.

SLAs between the cloud service provider and the tenants should make clear who is responsible for which aspects of software security in the virtual environment.

Service Delivery Security

Figure 1 shows how all client interactions with the private cloud, from whatever device from outside the private cloud, to both tenant services and cloud management services must pass through the service delivery layer. Supporting broad network access to the cloud will tend to reduce the amount of filtering and monitoring that the cloud service provider can apply at this layer as it must allow traffic from a wider range of devices and locations through this layer.

Tenants may need the ability to configure their service endpoints to make their applications and services available to a broad audience who use a broad array of devices: for example, by opening the necessary ports and configuring SSL. The CSP will need to consider the inbound and outbound traffic requirements of tenant services and have an automated method to enable and disable this traffic, as appropriate.

However, the CSP can specify the controls that must be in place on the services that you and the tenants use to manage the cloud such as the self-service portal for requesting cloud resources or billing services.

Management Security

Tenants may require the ability to perform some management operations from client applications and devices of their choice.

All access to cloud management services should be authenticated using two-factor authentication, then monitored, logged, and audited. You can determine whether you want to reduce the available attack surface by restricting access to management services to specific client devices in specific locations. These decisions will largely be driven by determining what access, if any, tenants should have to any of the cloud management tools.

If tenants do have access to some cloud management tools, then there should be role-based access controls in place to limit who can perform the management operations. Assigning individual users to the relevant roles should be a part of the provisioning process for cloud resources.

Client Security

In a private cloud, business units within the enterprise may have responsibility for and ownership of the tenant services and applications hosted in the cloud. In this is the case, the business unit will also determine whether there are any controls over the client applications used to access the cloud-hosted service.

SLAs can mandate that certain security features are included in client applications. However, the service model often makes it possible to discover the service API, so it is always possible that someone could build their own client application to exploit vulnerabilities in the service API using known or discovered credentials for the service. One approach to limiting the client applications that can act as a client to the service is to use a certificate-based mechanism. A consumer, service, or computer must present a valid certificate before it can invoke any service operations. However, this approach is dependent on robust Public Key Infrastructure (PKI) and well managed policies to ensure that someone who wants to impersonate an existing, approved, user cannot discover and purloin the certificate.

Client devices can cache data for performance, enable the user to export data to save locally, or simply enable a user to screenshot data. All of these features, and many others, make it difficult to protect the data that client applications make available to the end user. Unless you can apply strict controls to the client environment, it is difficult to mitigate these risks.

You must determine if any local laws or regulations place restrictions on where the data may be located, or whether the clients must include any particular security features. If the client business unit is responsible for the service, the SLA between the IT department and the business unit must specify where responsibility for compliance lies.

**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 - On Demand Self Service

Table of Contents for A Solution for Private Cloud Security