The Private Cloud model requires you to have total control over all layers of the stack, which includes any traditional network perimeter security you might want to have in place. In a private cloud model, the cloud services are not typically exposed general Internet users (although they can be) and remote access to private cloud hosted resources is enabled through mechanisms used in traditional data centers (although a private cloud can host perimeter security devices hosted on a cloud infrastructure).

Note:
This document is part of a collection of documents that comprise the Reference Architecture for Private Cloud document set. The Reference Architecture for Private Cloud documentation 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 article, please include your name and any contact information you wish to share at the bottom of this page.

In this scenario you could rely on traditional enterprise security architectures and methodologies; however there are a number of reasons to consider a redesign of the security architecture when moving to a Private Cloud:

• A well architectured and designed Private Cloud infrastructure would be prepared for an evolution to hybrid or public cloud computing in the future. This is the most compelling reason for adopting a private cloud infrastrucutre, since it enables a stepping-stone to a hybrid cloud solution. By redesigning the security architecture when still using a Private Cloud model, you can lay the groundwork to implement some hybrid or public cloud solutions.
• Private Cloud computing typically uses virtualization technologies to increase hardware utilization and to abstract compute, memory, network and storage component from Private Cloud consumers. You should be particularly aware of any vulnerabilities to the hypervisor and the patches needed to fix these. There have been hypervisor vulnerabilities that have allowed a guest operating system to run processes on other guests or the host. These vulnerabilities have occurred across virtualization vendors and, therefore, it is essential that you apply updates to the hypervisor. In addition, investigate what technologies have been enabled by processor vendors (Intel/AMD) that improve hypervisor security.
• While traditional perimeter security provides protection from the Internet, it is often not configured to protect resources against attacks sourcing from within the organization. It is extremely unlikely that every piece of information should be available to every department and at every level in the hierarchy. For example, information in a human resources system should not be made available to everyone in Sales. Therefore, as you rearchitect your security designs to support private cloud, you should consider designing in network based access controls that apply to external users, but to all consumers of Private Cloud resources. Private Cloud administrators will need to work with service administrators (e.g., mail services, collaboration services, database services) to ensure proper configuration of network access controls.
• The most deliterious security breaches come from inside the organization (insider attacks) and therefore you should treat the traffic inside the Internet perimeter with as much security as the traffic outside. This should be the case regardless of whether you move to a public cloud model, hybrid cloud model, or do not use cloud technologies at all.
• In a Private Cloud environment, it is possible that virtual machines will be able to communicate with each other from within the virtual environment and not send traffic over a physical Ethernet connection. To ensure that virtual machines only communicate with virtual machines that they should communicate with, ensure that network level authentication and encryption mechanisms are used, such as those provided by IPsec. In addition, if network level IPS/IDS is required by industry or govermnment regulations, investigate solutions that can inspect network traffic as it moves through the VM buses.
• The host operating system should be isolated from all virtual machines contained within it. Assure that there are no back-channels that enable guest virtual machines from communicating with the host operating system over either virtual or physical network connections. Dedicate physical NICs to virtual machines, or dedicate VLANs to the virtual machines. In addition, dedicate a physical interface for over-the-network communications with the host operating system for management purposes.
• The host operating system must be free from malware, and mechanisms, such as anti-malware software, must be in place to detect potential compromise. The host operating system should not have Internet connectivity, and any updates required for the host operating system should be obtained from a trusted source on the intranet, which has had the opportunity for scanning all updates prior to delivery to the host operating systems.
• In a Private Cloud environment, guest virtual machines belonging to different security zones should not be hosted on the same virtual server. For example, if the Private Cloud virtual server is hosting Internet facing resources, such as virtual firewalls, or Internet-facing front-end applications, these Internet-facing guest virtual machines should not be hosted on the same virtual server as non-Internet facing guest virtual machines, such as those hosting internal database and collaboration information.

REFERENCES:
Microsoft Private Cloud Security Overview

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 Previous Page

Return to Cloud Computing Security Architecture

Return to Reference Architecture for Private Cloud