Building Security Protections for Data in the Private Cloud

In a private cloud, both virtual servers and physical servers must be secured. IT administrators will want to approach security differently for a private cloud located within its own facilities than for a private cloud hosted at a third-party site.

In-house Private Cloud

A private cloud hosted at an organization’s own facilities can be thought of as the next generation of the enterprise data center. The major security considerations can be broken down into five categories: physical security, logical security of host operating systems, hypervisors, guest operating systems and applications.

Physical security: This is of paramount importance to private-cloud security. Numerous physical security controls are involved in protecting an enterprise data center from unauthorized access. These same controls should apply to a private-cloud environment hosted at an organization’s own facilities.

In fact, physical security can often be even more stringent with a private-cloud deployment, because the administrators of a particular application don’t necessarily have a dedicated server. So application administrators typically don’t need physical access to cloud servers, just logical access. Of course, system administrators still need physical access to cloud servers to maintain them and deal with physical problems that occur, such as physical server failures.

Logical security of host operating systems: This aspect of security is unchanged from traditional enterprise data centers if the virtualization layer is running on top of a host operating system. In that case, the operating system and any applications running on it must be kept fully patched.

Likewise, this software needs to be hardened by configuring it based on the results of a risk assessment, ensuring that the software is reasonably secured while also allowing any necessary functionality. If the virtualization layer is “bare metal” (running directly on the hardware), then there is no host operating system to be secured.

Logical security of hypervisors: This is an important consideration because of understandable concerns that a single weakness in a hypervisor could be exploited to gain control over all guest operating systems and apps running on that hypervisor. The hypervisor is also important from a security perspective because it separates cloud workloads from each other, and thus keeps applications and users from accessing each other’s data within a cloud.

This is a concern even in a private cloud. Imagine a malware infection spreading from one guest operating system to another because of hypervisor weaknesses, then transferring sensitive data to external locations. While such an attack is more theoretical than practical at this time, it’s certainly feasible if the hypervisor and other cloud components are weakly secured. Organizations should keep hypervisors patched and hardened. (For example, they should disable all unneeded hypervisor services, and monitor hypervisors closely for signs of attempted or successful compromise.)

Logical security of guest operating systems (virtual servers): This is necessary to maintain private-cloud security. Each virtual server is a full-blown operating system that must be secured just like any other operating system instance. Failure to keep virtual servers fully patched and securely configured can allow an attacker or malware to compromise the guest operating system, opening the door to direct exploitation of vulnerabilities in the hypervisor.

Logical security of applications: This is a major concern no matter what type of cloud model the application is deployed to. Current malware tends to focus on operating systems and popular off-the-shelf server-side and client-side applications (for example, web browsers), not to mention the use of social engineering techniques. But attackers with some know-how can easily exploit software flaws, design weaknesses and other vulnerabilities in custom server applications.

When sensitive data is at stake, attackers have serious financial motivations to gain access to that data, and exploiting application flaws is often an effective method for achieving that. Simply transferring the enterprise data from a traditional data center to a cloud architecture doesn’t necessarily put an application at increased risk, but most organizations underestimate the risk posed by threats against their custom applications.

Third-party Facilities

The security concerns regarding the use of third-party facilities for housing private clouds depend greatly on the nature of the third-party relationship. If the organization is in full control of its servers, the security concerns generally are the same as if it hosted the cloud at its own facilities, except for increased concerns regarding physical security. Enterprises generally must pay greater attention to security issues when a private cloud is hosted by a third party that has control over servers, networks and security.

In theory, many of these security concerns are the responsibility of the cloud provider, not the customer. In practice, the customer is often concerned about the cloud provider’s security capabilities and processes, and wants more insight into what is happening with regard to security.

An organization planning to use a third-party provider to host a private cloud should carefully evaluate the security practices at every layer: physical security, as well as logical security of physical servers, hypervisors, guest operating systems and applications. Indeed, IT managers should ensure that their private clouds are truly “private,” as it is likely that a third-party provider is hosting other clouds as well at the same facility.

It’s also important to ensure that a provider’s private clouds are physically and logically separated from each other and, if feasible, not managed through a common mechanism that could allow attacks (such as malware) to readily spread from private cloud to private cloud.

Want to learn more? Check out CDW’s white paper, “Peace of Mind Security in Public and Private Clouds.”