Share via

Private Cloud Security Model - Infrastructure Security

  • Article

Now that you have examined the factors within the security wrapper, this paper presents the security issues that apply at the Infrastructure layer.http://blogs.technet.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-85-24-metablogapi/5658.image_5F00_64BCDD48.png

Infrastructure security is the most comprehensive aspect of private cloud security, as it starts with physical security and goes up as far as security of the hypervisor element of the virtualization environment. The layers of infrastructure security consist of:

  • Physical security
  • Supply security
  • Facility security
  • Hardware security
  • Network security
  • Compute security
  • Storage security
  • Host operating system security
  • Hypervisor security

Figure 1 shows how these security elements apply at the corresponding levels of the infrastructure layer.

 

*Figure 1: Infrastructure security issues
*

Physical Security

The physical security requirements of private cloud implementations tend not to differ substantially from those of an internal datacenter. However, as all security starts with good physical security, it is worthwhile highlighting two factors that are of importance.

  • Physical access control. Effective security starts with restricting the people who have access to the physical hardware. Newer technologies such as smartcards, fingerprint scanners, and retina scanners are now in common use but all are equally ineffective if you haven’t put bars over the windows to the room that houses your private cloud hardware. Many organizations pay for extensive electronic penetration testing yet fail to implement any form of physical security assessment. A plate glass window rapidly transforms into a door after the application of the heavy end of a fire extinguisher. In consequence, doors to the data center need to be able to withstand physical attack using any item likely to be readily available to an intruder. Employees must participate in a security awareness program to avoid common mistakes such as allowing tailgating (following people through doors) and shoulder surfing.
  • Physical data leakage. Because private cloud implementations tend to make greater use of simple arrays of hard disks and swap out failed disks on pre-determined maintenance schedules rather than every time a disk fails, you have the situation where multiple hard disks may be replaced at the same time. Unless there are effective security controls to ensure that these hard disks are wiped before they are removed from the premises, then then there is the potential for data leakage.

Energy Supply Security

A private cloud implementation requires electrical power to operate. It may also require a reliable Internet connection. Unless the provision and security of these services is assessed and the risks to each supply evaluated, your overall security cannot be accurately estimated.

 

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.

 

Backup electricity generation is one approach to improving security of the electricity supply. Although significantly more expensive, mirrored or standby data centers in another location can provide equivalent security combined with resilience in the case of significant disruption at one site.

Facility Security

Facility security addresses issues with providing essential services to the infrastructure, such as cooling facilities, power supplies, cabling, and physical networking. In these areas, private cloud implementations are more closely aligned to dynamic data centers, where rapid provisioning and deprovisioning may result in large fluctuations in cooling and power requirements from powering up and down the physical servers. Additionally, in private cloud environments, the physical networking topology may differ to account for the change in trust level of the internal network.

Network Security

On the logical side of networking, there are significant differences with the private cloud implementation. The main issue here is that, as discussed earlier in this paper, private cloud implementations tend to place the internal network outside the cloud perimeter network and then route all communications with that network through firewall rules.

This change in network layout does not change the relationship between the internal network and the Internet. Connections between clients on the intranet and Internet hosts are still subject to the same filtering, rules, and firewall monitoring as before. The change is from the perspective of the private cloud implementation, which now views all other networks as external and therefore untrusted.

However, this change does not mean that different firewall rules cannot apply to cloud to internal network connections compared to cloud to Internet connections. Instead of an all-encompassing network labeled “External”, you would create a new network called “Internal Network” and assign an IP address range to that network. For communications to take place, you then specify what ports are open and which protocols are allowed through the perimeter network into the cloud network**.** You can then configure additional firewall rules that govern communications between the internal network and the cloud network.

These port requirements will vary depending on your client operating systems and directory service. For example, if you do not have domain-joined clients and are instead using federation for authentication, then you might only require TCP port 389 to be open and possibly the DNS ports.

You will be monitoring your firewalls as part of your overall security monitoring and using this information to ensure that client access attempts follow prescribed paths to specific services. Any attempts to access a service or virtual machine from a session that should not be connecting to that resource should result in automatic termination of the session, locking out the account, and alerting security to carry out a forensic follow-up examination. As with all IT infrastructures, the routers, firewalls, and switches must be kept updated, otherwise these components can provide an open door for intruders.

A private cloud implementation will also make heavy use of network partitioning through virtual local area networks (VLANs). These VLANs can be implemented both through the physical network switches and as part of the virtualization environment. VLANs help ensure that packets can only travel along the network segments that they should be traversing..

The dynamic nature of virtualized environments may cause the location of a server and its corresponding storage to change, based on shared resource usage and dynamic virtual machine placement. These dynamic movements may increase network latency and reduce routing effectiveness. In addition, network topologies such as spanning tree layouts may not work in private cloud environments.

Network services such as DNS also need to be included in the security assessment of your private cloud implementation. As with most network designs, any service should provide redundancy and should not implement a single point of failure. Any known vulnerabilities in these services must be addressed and best security practice applied.

Hardware Security

Hardware security in private cloud environments must take account of the differing features of private cloud implementations. Private cloud implementations typically have very high levels of commoditization, so any hardware security devices will need to be implemented on large numbers of host computers, hard disks, or network cards.

These hardware security devices can include hardware security modules (HSM) to protect cryptographic keys or offload cryptographic processing, most commonly for asymmetric key calculations. Note that symmetric key cryptographic calculations tend to be executed in software on the main processor, as the time to transfer the data to an external device and back again reduces the computational advantage of the dedicated processor in the HSM.

Hardware security devices can also include Trusted Protection Modules (TPM) for disk encryption. However, private cloud implementations with are more likely to use a combination of hardware full disk encryption alongside software file and folder encryption.

Host security can include setting the basic input/output system (BIOS) to require a password at boot time and in order to access the BIOS settings. Although there are known mechanisms for defeating BIOS security, this form of hardware security on the host computers still has a place in private cloud environments.

You should include firmware such as system BIOS updates as part of your maintenance cycles. Dynamic migration of virtual machines simplifies this process, as any virtual machines can be moved from a host computer, which is then updated, brought back online and the virtual machines reverted to that host.

Compute Security

Private cloud environments consist of significant numbers of compute resources, implemented either as small form factor hardware compute units (for example, blade servers) or as virtual machines running on host computers (which may also use a blade format). It is essential that there is effective security on the processes that run within the associated memory of these compute resources.

Process isolation enables tight control of processes running within the operating system and constrains operations only to designated objects or targets. Authorization rules govern which initiators can access which targets. In private cloud implementations, it is important that processes that run on compute resources are tightly locked into ownership of those processes.

Memory segments should also be routinely wiped or set to zero when allocated to another process. In addition, areas containing data such as the page file should be wiped when the computer powers down.

Finally, memory dump files can contain sensitive application information, including user names and passwords. You should ensure that any memory dump files are secured against unauthorized access.

Storage Security

The encryption factors in storage security have already been discussed. However, there are other considerations that arise from the use of pooled storage in a multi-tenant environment.

As with compute resources, storage allocation should ensure effective partitioning between tenants and strictly enforce ownership of the storage space. When an IaaS compute resource is provisioned, it is allocated the dedicated compute and storage resources and access to those resources is restricted to the commissioning tenant.

In operation, that storage space is kept isolated from other tenants. Encryption and ACLs prevent other users from accessing the data stored in those locations.

Finally, when a tenant or administrator deprovisions a storage resource, it is important that all the data on that volume is wiped. If the associated compute resource has local storage, any local and transient data on that compute resource should also be destroyed. Any resources that a tenant has used must return to the respective resource pools in a completely sanitized state and bear no recoverable imprint of the data that the tenant was using.

When reviewing storage security, ensure that you also consider data held in caching controllers. This information must be wiped as part of the deprovisioning process.

Operating System Security

Operating system security in the infrastructure layer generally involves configuring the host operating systems that support the virtualization environment. As with all operating system configurations, a key approach is reducing the attack surface to an acceptable level. The level to which you need to reduce the attack surface will depend on your overall risk management strategy and threat model.

Virtualization environments generally do not require graphical user interface (GUI) support from the operating systems on which they run, hence you should consider using a version of the operating system that does not include this component. Any services that are not absolutely essential to the virtualization environment should be disabled.

The provisioning process for host operating systems should include application of operating system security policies. These policies should set appropriate levels of operational security and include IPsec polices to control the servers to which each computer can connect. Provisioning at the infrastructure level also needs to include creation of certificates to match the host name of the provisioned host.

Before the host computer is connected to the network, it must have all relevant security updates applied. Only then is the new compute resource brought online and available to the requesting tenant.

Virtualization Security

Although virtualization is not a pre-requisite for private cloud implementations, the operational flexibility that this technology brings means that it is almost a requirement for meeting the need for rapid elasticity. Typically, virtualization is implemented as a part of a dedicated version of a server operating system without the GUI.

Virtualization requires hardware support from the chipset. However, most modern server designs provide the full range of virtualization support. From the security perspective, however, it is important to understand that if your private cloud environment is not using virtualization, then you should reduce the potential attack surface by disabling the hardware virtualization support within the system BIOS.

The virtualization environment should be updated as part of the operating system and this updating needs to be applied before any guest virtual machines are run on it.

In a private cloud environment, additional services or applications should not run on the host computer, with the possible exception of anti-virus applications. This anti-virus scanning should then be included in the comprehensive security monitoring of the whole environment.

Update Security

The final component in infrastructure security covers applying security updates to the entire infrastructure layer. This process should also include updates to the switches, firewalls, and firmware.

As with most aspects of private cloud provision, the key attribute is high levels of automation. Updates need to be delivered in a timely manner and targeted correctly at each running host computer. Newly provisioned computers require updates to be applied before being brought online and the management interface must keep track of the update status of all running host computers and virtual machines.

Private cloud environments do significantly facilitate the process of applying security updates, as you can use the pooled resources feature to your advantage. Because no virtual machine is tied to any one host computer and no compute resource is tied to any physical host computer, you have the flexibility to move resources around while you update operating systems or carry out other maintenance tasks.

For example, if you need to update the hypervisor on your host computers, you can simply start with one host computer, live migrate the running virtual machines onto other host computers, apply updates to that host, reboot, test functionality, and then live migrate the running virtual machines from another host computer onto that updated computer. You continue this action until you have updated all host computers.

Update testing is also simplified, as you have the ability to provision hardware and software to carry out that testing. By taking snapshots of running virtual machines before updating, you have an immediate fallback position should the update fail. As long as your datasets for each application are independent of the application, then failure of the virtual machine failure should not corrupt the data and when the previous image of the virtual machine is restored, the application should function as normal. Hence, private cloud environments give significant benefits when testing, deploying, and rolling back security updates.

In a hosted or hybrid environment, the cloud service provider might not have permission to apply updates to virtual machines, particularly with IaaS provision. In this case, the provider must make the update tools available to the consumer and ensure that they are used properly to keep the consumer’s environment up-to-date.

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 Model[

Return to Blueprint for A Solution for Private Cloud Security](http://social.technet.microsoft.com/wiki/contents/articles/blueprint-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 Model - Platfrom Security

Table of Contents for A Solution for Private Cloud Security