Private Cloud Security Design Principles
This section introduces the key security design principles for private clouds. These principles apply to all the detailed security design recommendations thathttp://blogs.technet.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-85-24-metablogapi/5658.image_5F00_64BCDD48.png subsequent sections cover.
Note: In the following discussion, we use the term "tenant" to refer to a client or consumer of cloud services, typically a business unit within the organization, who uses the private cloud to run their applications and services. We also refer to services or applications running in the private cloud and owned by such tenants as "tenant applications" or "tenant services." The term "cloud service provider (CSP)" refers to that part of the IT department responsible for managing the private cloud.
For the private cloud, the key security principle that drives an effective design is that your design should seek to build a system of controls, rather than a collection of controls. This unified system of controls is more than just the individual security technologies and methodologies – each part integrates with each other to provide the overall defenses.
This unified security approach would include the following design principles:
- Apply generic security best practices
- Understand that isolation is key
- Consider security as a “wrapper”
- Assume attackers are authenticated and authorized
- Assume all data locations are accessible
- Use established strong cryptographic technologies
- Automate security operations
- Reduce attack surface
- Limit routing
- Audit extensively
- Implement effective governance, risk management and compliance
Apply Generic Security Best Practices
Private clouds use existing technologies such as virtualization and extend the infrastructure designs current in many organizations. As such, you should maintain existing security practices as part of the security design for your private cloud.
For example, you should continue to:
- Implement the principles of least privilege and defense in depth.
- Use firewalls and use separate NICs for management functions.
- Carry out penetration testing and to audit your security processes.
However, private cloud architectures introduce new potential vulnerabilities and you must modify and add to your existing design to mitigate these new threats.
Isolation is Key
Typically, private cloud implementations use virtualization technologies to make infrastructure, platform, and software resources available to clients within the enterprise. Tenants may be other business units within the enterprise, or other sections of the IT department using private cloud resources to deliver services to client business units. Even though private cloud tenants are part of the same organization, you must ensure isolation of their resources. For example, confidential human resources data must not be generally accessible even though the human resources systems could be running on the same physical server as the company intranet.
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
It is not just an issue of simple confidentiality. In the IaaS, PaaS, and SaaS service delivery models, you may not know which tenant services are co-hosted on the same physical devices at any particular time. In consequence, a problem in one tenant service could affect the performance, network connectivity, or network availability of other tenant services on the same physical hardware. Your design must ensure isolation between tenants in both the physical and virtual environments that make up the private cloud.
If your private cloud is partially or wholly hosted by a third party, then you must be assured that the cloud infrastructure used by the third party also guarantees isolation, both between your services and between your services and any other organization's services that the third party also hosts.
Consider Security as a Wrapper
You should consider security as a “wrapper” around all elements of your private cloud architecture. The private cloud reference model in figure 1 shows how security concerns are relevant to all elements in all layers and stacks within the architecture:
- Infrastructure
- Platform
- Software
- Service delivery
- Management
A private cloud typically hosts services in virtualized environments, with multiple services co-located on the same physical device. The security wrapper functions must be applied to both the physical and virtual environments because in a private cloud architecture you cannot assume that by protecting the physical environment you automatically protect the virtual environment, and vice versa.
If an attacker gains access to the physical infrastructure, they can disrupt not only the infrastructure, but also potentially gain access to the virtualized resources hosted in the cloud. If attackers manage to compromise a virtualized environment, they can potentially use the compromised environment as a platform to attack other virtualized environments within the cloud or to attack the infrastructure.
Although your design should consider security as a wrapper around all elements in the architecture, your design should take into account the possibility that responsibility for security may be split between the CSP and the tenants. For more information about this scenario, see the third paper in this series "Solution for Private Cloud Security: Service Operation."
Considering security as a wrapper should be part of your defense in depth strategy for securing your private cloud. For a more information about the private cloud reference model shown in Figure 1, see the first paper in this series "Solution for Private Cloud Security: Service Blueprint."
Assume Attackers are Authenticated and Authorized
In the private cloud, you may delegate some of the responsibility for managing the security of the environment to the tenant. A tenant may provision resources through a self-service portal in order to run its tenant application or service in the private cloud. The cloud service provider may have little or no control over how the tenant configures and uses its virtual resources and this includes control over how the tenant grants access to its services to its end users. Because of this, you must assume that attackers can be authenticated users with authorized access to a virtual machine running in your data center. The attacker could be an untrustworthy employee, someone using stolen credentials, or an attacker using elevated credentials.
You should consider this route of attack from within a virtual machine in your data center in addition to more traditional attacks that may be mounted from outside your organization in an attempt to exploit weaknesses in your external defenses. Attackers will now attempt to find weaknesses that they can exploit in the virtual environment.
For example, an attacker might try to gain access to the hypervisor from within the hosted virtual machine, a type of exploit known as hyperjacking.
Assume All Data Locations are Accessible
This point closely relates to the previous point about authenticated and authorized attackers. In private cloud architectures, many data locations are exposed as services. For example, virtual machines may mount virtual hard disks from a storage resource, or they may use virtual queues, virtual tables, or virtual binary large object (BLOB) storage. A tenant may provision these resources through an automated self-service portal as part of the infrastructure or platform services provisioning process. If an attacker can gain access to a tenant's virtual environment, you must assume that they may also gain access to the tenant's data locations.
Because of this, you should consider when and how to encrypt data and how to store and manage the encryption keys that enable access to the data stored in the cloud.
Do Not Trust Client Information
You cannot make any assumptions about the security of any of the client applications that access the tenant services hosted in the private cloud. This proviso is especially important when the tenant wants to enable broad network access to the tenant service from multiple device types and from multiple locations. Poorly designed client applications could accidently reveal credentials or keys, and may perform limited validation on the data that they send to the services hosted in the cloud. Therefore, cloud management services and tenant services must perform their own validation of data sent from all client applications.
In contrast, you have more control over the client applications and tools that you use to manage the cloud infrastructure. For example, you may limit access to cloud management functions to client applications running on the corporate intranet, or use certificates to identify client applications. However, some cloud management operations may require calls to published APIs, which themselves may not require full validation of the data sent to the cloud and could be invoked from a custom application created by a developer.
Use Established Strong Cryptographic Techniques
Encryption of data at rest, in transit, and during processing can help to ensure that the data is only visible to those who should be able to see it. Therefore using encryption can help to preserve the isolation of tenants' resources and help to mitigate the threat that attackers may be authenticated users with access to the locations where the application or service stores its data.
You should ensure that your infrastructure uses established, strong encryption techniques wherever it uses encryption. Tenants should also be encouraged or mandated to use established, strong encryption techniques in their own cloud-hosted applications and services.
Implementing cryptographic algorithms securely is complex and difficult. Using strong, established cryptographic algorithms and cryptographic systems rather than "rolling your own" helps to validate your approach to encryption, and makes your cryptographic processes auditable. Remember that attackers will only bother attacking the algorithm itself if they recognize it as weak – typically, they go after the keys.
Automate Security Operations
The size of private clouds, self-service provisioning, and virtualization all combine to make it essential to automate operational activities such as collecting and correlating monitoring data, responding to security related incidents, and allocating resources to tenants to prevent denial of service situations.
A typical private cloud hosts a large number of tenant services and supports a large number of end users. To ensure effective and timely responses to security issues, you must automate those responses as far as possible.
Automated security responses rely on monitoring, so your design must include monitoring services that enable you to automatically identify and act on possible security issues. The automated response procedures must send notifications to the staff that are responsible for security and create a full audit trail of their actions. You should evaluate and review these procedures regularly.
Note that when configuring security monitoring, you must also not let yourself be swamped by security responses and turn off monitoring altogether. Better to build up a feel for what is important by enabling rules more slowly. When you have a baseline and an understanding for your environment, you can then add the automation.
If you are building your virtualization host and guest environments from standard templates or images, you should ensure that those templates and images include configuration of the monitoring on which your automated responses will rely.
Your private cloud design should include a comprehensive automation platform that will enable operational activities such as those outlined above. You should also ensure that the security monitoring and response automation can cope with cloud-based environments and with virtual machines that can be rapidly provisioned and deprovisioned.
Reduce Attack Surface
As with all computer systems, reducing the attack surface is a key element to preventing attacks from succeeding. If the attacker only has a very small area to attempt to access, then he or she has far fewer options to find a successful exploit.
Within a private cloud environment where you are likely to be using virtualization, you must ensure that you reduce attack surface wherever possible on both host and guest computers. You should only enable the ports, services, and features that are essential to your operations. Your risk assessment should identify all unnecessary components and you should then remove or disable these components.
Limit Routing
Anytime data transitions though the private cloud, it adds another possible place that an attacker might be able to access or tamper with that data. Your private cloud design should limit the number of nodes that data must pass through to reach its destination as a part of the overall design goal to reduce the attack surface.
For example, if a tenant is deploying a three-tier application to the private cloud, they should be able to configure the application so that the individual tiers can communicate directly with each other without the data passing through a shared broker component unless there is a specific requirement for this to happen.
Additionally, more complex routing requires more complex monitoring, and the more difficult it becomes to understand the flow of data within the already complex cloud environment.
Audit Extensively
The cloud is a relatively new and fast changing environment that means that new usage patterns and new threats will emerge. Your security processes should be audited regularly in order to validate that the current security design includes mitigations for known threats. If not already applicable, you should consider gaining consider certifications such as ISO/IEC 27001and SAS 70 Type II.
ISO/IEC 27001 is an international standard has been prepared to provide a model for establishing, implementing, operating, monitoring, reviewing, maintaining, and improving an Information Security Management System (ISMS). This International Standard can assess conformance by interested internal and external parties. For more information, visit http://www.iso.org.
Statement on Auditing Standards No. 70 (SAS 70) is an international auditing standard that enables businesses that provide services to other organizations to provide an independent, trustworthy account of their internal control practices. An independent auditor performs the SAS 70 audit and generates the resulting SAS 70 report, which the service provider supplies to its customers and clients for use when they themselves undergo auditing. For more information, visit http://www.aicpa.org.
Implement Effective Governance, Risk Management and Compliance
In a private cloud, because ownership of and responsibility for services hosted in the cloud is split between various parties, the SLAs between the parties must make clear where those responsibilities lie and what the different parties should expect from each other.
The set of SLAs that you must consider will depend, in part, on the particular cloud model adopted by your organization:
- If you chose to adopt a hybrid cloud model, or chose to host your private cloud with a third-party organization, then the enterprise CSP will have SLAs with the third-party cloud service provider and with the client business units within the organization. In these scenarios, the IT department is acting as a broker to deliver and manage cloud services provided by an external entity, to internal clients.
- If you are hosting the private cloud on premises, you must then negotiate SLAs between the IT department and the client business units.
If you are using a third party to provide some or all of the private cloud services in the enterprise, then you must ensure that the SLAs with the third party provider enable you to meet your SLAs with your internal clients. This requires a detailed understanding of what the third party SLAs offer in terms of security.
For example:
- How do they guarantee isolation between tenants?
- What do they guarantee in terms availability and disaster recovery?
- How do they ensure the integrity of your applications and data?
- What steps do they take to ensure the physical security of your data such as vetting employees who have access to the physical environment and hardware disposal procedures?
Regardless of whether you choose to host the private cloud externally with a third party, on premises, or adopt a hybrid approach, you will still need SLAs between the your IT department and the tenants within the organization. The on-demand, self-service attribute of the private cloud, means that there may be some delegation of responsibility for managing the security of the virtualized environment to the tenant.
In addition to the guarantees made to the tenant by the cloud service provider, SLAs may also need to specify requirements related to security that the tenant must fulfill. For example, an SLA might specify the encryption technologies that the tenant service should use to protect data, or that the tenant should use the enterprise directory for identity management through federation services provided by the CSP.
How much delegation of responsibility occurs will vary between organizations and between tenants. For some organizations, the primary motive behind adopting a private cloud model will be to make more efficient use resources by pooling them: the IT department will still deploy and manage applications and services on behalf of the client business units. In this scenario, the on-demand, self-service characteristic is not significant to the relationship between the cloud service provider and the client business unit, and SLAs will cover traditional areas such as availability, disaster recovery, and performance.
However in some scenarios, tenants will make use of the on-demand, self-service functionality of the private cloud to obtain and manage infrastructure or platform resources to run their own applications and services. In this case, the split in responsibility for security features such as identity and access management or data protection may be more complex and the SLAs must include clear definitions that are understood and agreed upon by all the concerned parties.
Scenarios that are more complex are also possible. For example, in addition to managing the private cloud infrastructure, the IT department may also commission, procure, or develop applications for other business units within the organization. In this scenario, one part of the IT department may use the on-demand, self-service capability of the private cloud to acquire infrastructure or platform services on behalf of the client business unit and also handle some or all of the ongoing management of the service on behalf of the client business unit. This arrangement creates a scenario where there are two SLAs: one between the cloud service provider and service provider sections of the IT department, and one between the service provider part of the IT department and the client business unit.
In a private cloud, all parties must have an explicit understanding of their obligations and responsibilities and agree to them. Depending on the model adopted by your organization, the list of parties involved might include:
- third-party cloud services providers
- an internal cloud-services provider
- application and software providers who are a part of the IT department and who consume private cloud services
- client business units within the organization whose applications and services are hosted in the private cloud
When you are negotiating and drafting SLAs you must ensure that:
- You cover all aspects of security for all hosted services and applications and there are no gaps in responsibility.
- Your SLAs with third party providers enable you to meet the SLAs with your tenants.
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 Design Guide for A Solution for Private Cloud Security
Return to A Solution for Private Cloud Security
Return to Reference Architecture for Private Cloud
Move forward to Private Cloud Security Challenges
Table of Contents for A Solution for Private Cloud Security