فا

‫ Security Considerations for Cloud Computing (Part 1) - Virtualization Platform (Section two)

IRCAR201303168
Date: 2013/03/25
 
Cloud Computing and Virtualization Platform Security
So now we know that the cloud is about much more than server virtualization. When you move from server consolidation to using virtualization to create a public, private or hybrid cloud computing environment, you move from a traditional datacenter to a dynamic, service oriented and focused cloud deployment.
In a traditional datacenter, automation is not usually such a major component unless the number of client or server operating systems to be deployed and the administrative overhead would be overwhelming without some method of automation. In general, in today’s LAN based datacenter, setting up new physical servers includes at least some manual steps performed by the admin. In contrast, in a cloud environment, the OS must be highly automated to support several of the key tenets of cloud computing itself.
Another thing to keep in mind is that virtualization changes the relationship between the operating system and the hardware on which it runs. In itself, this will change your perspective from a security standpoint as it challenges the comfort you’ve felt in the past when you deploy an operating system and applications on a server that you can physically touch and feel. However, this belief that something you can touch and feel is inherently more secure isn’t necessarily valid.
You need to consider several important security concerns when thinking about the role of virtualization in cloud computing. Perhaps the most important of these concerns, which you do not see in a non-virtualized environment, is what can happen if the hypervisor itself is compromised. The hypervisor has access to all the guest workloads running in the cloud infrastructure. When you think about cloud deployments, which can run literally thousands or tens of thousands of virtual machines, compromise of the hypervisor could have broad and devastating impact if not otherwise mitigated by using network isolation.
The hypervisor is a small piece of software with some very specific duties. A hypervisor is much smaller and more targeted than an operating system designed to provide an interface and development environment for applications. The hypervisor should have no externally accessible network ports that can be leveraged by an attacker. The hypervisor should rarely if ever require patching. Another very important requirement is that the guest operating systems must not have direct access to the hypervisor.
The hypervisor should be invisible to the network, with the possible exception of traffic destined to the hypervisor management interface. The probability is low that the hypervisor will be attacked in the near future because both the vulnerability of the hypervisor and the probability of an attack are low at this time. However, there is a good chance that this will change in the future as hackers begin to focus their efforts on hypervisors.
Another security issue that’s related to virtualization deals with the allocating and deallocating of resources in an elastic environment, which might include things such as local storage associated with VMs. If data is written to physical media—or to memory—and it is not cleared before that storage is reallocated to another VM, then there is a chance for data leakage. Of course, these problems are not unique to cloud environments and there are well-defined mitigations enabled by all commonly used operating systems.
There are a couple of important points to consider regarding how operating systems handle reallocation:
  • The operating system may stop or crash before resources are zeroed out.
  • Not all operating systems manage the clearing data in the same way; some may clear it on release, whereas others may do so on allocation.
Therefore, it is possible for different operating systems to handle reallocation in different ways. Because of this, you need to take control over your storage and memory when using a public cloud and to the same extent, the private cloud. You do this by clearing the data yourself and setting policies for clearing sensitive data that includes special handling. You need to have processes in place that confirm that a released resource was in fact cleared. When sensitive data is handled in any situation where bits (located in places such as memory buffers or temp files) may be exposed to others, you must put more effort into securely handling this data.
For example, when some code obtains a clear text password from a user (this can be over an encrypted or unencrypted network link), the memory buffers used to capture the password and transmit the clear text password for authentication must be removed as part of the authentication process. If you don’t do this, you extend the risk of exposure. You can do this as an “atomic operation”, which is one that is completed or not performed at all. That is to say, if the operation fails, it rolls back to the previous state.
What about network attacks between guests that are hosted on the same server in a virtual server array or cluster? Can you detect them? The problem is that unless you can see the traffic from each VM, you can’t confirm that traffic is not possible between the VMs, even if you have put these security controls in place. There are several possible solutions you can employ. One is that the VM user can simply invoke OS-based traffic filtering or firewalling, and another is that you can deploy new virtual instances of traditional network management and monitoring solutions, such as the Cisco 1000V.
What if you have multiple communicating and interoperating VMs that need to be dynamically moved around to load balance your cloud? If the VM’s IP addresses change when they are moved from host to host and static addressing is used for firewall rules, then firewall filtering might fail. Network virtualization will need to provide a network interface to the VM. The interface might be a multiplexed virtual NIC with all of the switching and routing handled in the network fabric.
Most enterprise grade hypervisors (for example, Microsoft Hyper-V) have virtual switches (as well assupport for virtual firewalls) that are situated between the server’s physical NICs and the virtual NICs used by the VMs.
Another method that you can use for limiting traffic between VMs would be to use physical location to associate and isolate different security zones that are represented by VMs. VMs should be traceable to their owners throughout the life cycle of the VM and would only be co-located on host servers with other VMs that meet the requirements for co-location, such as being members of the same security zone.
In order for this to work, we need support for VLANs beyond the core physical network infrastructure to push it down to host virtual servers. The good news is that enterprise solutions like Hyper-V and ESX support this today. However, the solution also needs to scale VLAN capabilities to support large dynamic clouds.
The bottom line from a security standpoint is that vendors are being diligent in obtaining security certifications of their solutions. They (and now you) recognize that virtualization makes infrastructure management more complex, and when you introduce the other key aspects of cloud computing, massive automation is used to support enormous scale, elasticity and on-demand self-service requirements. Because of this automation and scale, you need to manage risk in virtualized cloud environments by architecting, planning and managing with greater diligence than ever before. Management automation enables your virtualized cloud environment to have better security, because it will be integrated from inception to deployment.
Related Links:

نظرات

بدون نظر
شما برای نظر دادن باید وارد شوید

نوشته

 
تاریخ ایجاد: 18 مرداد 1393

دسته‌ها

امتیاز

امتیاز شما
تعداد امتیازها: 0