Three key points for enterprise data Center Virtualization security Architecture

The Tenkine server channel May 29 message "http://www.aliyun.com/zixun/aggregation/13883.html" > Virtualization technology is commonly used in the data center, while the virtual platform adds an additional layer of security requirements. When new virtualization technologies are introduced, data centers add new security risks, such as the risk of running multiple virtual machines in an administrative hypervisor. It also has virtual machine mirroring and client operating system security and virtual instances of physical security devices, such as a virtual mirror running from a physical firewall and an intrusion prevention system to the same service.

The virtual security marketplace is rapidly addressing security issues associated with customer virtual machines. While the management process is the most difficult part of the data center from a tactical perspective, a management program is strategically the most tempting target for a virtual data center because it allows access to multiple virtual systems in the data center.

Enterprises should analyze the specific risks of the virtual platform they use. It is important to know how the architecture changes affect existing security management systems. Enterprise IT departments should also develop tactical and strategic security plans before migrating or applying virtual machines to virtual machines. These security plans are implemented through a comprehensive analysis of existing virtual security, as well as plans to address future security threats to the virtual platform. Planning and small changes in current architecture and security management can help protect against future hypervisor and platform-level virtualization attacks.

Overall, as part of the overall virtualization security architecture, IT departments should focus on three virtualization aspects:

Separate virtual machines by location

One of the most frequently discussed issues in the field of virtual security is the use of virtual platforms in quarantine. Often see a physical virtual machine host running a public and proprietary virtual machine in the quarantine area, the distinction between the two security areas is implemented on a soft switch. In practice, this architecture is not as secure as the architecture of the physical environment, as the virtual machines and physical machines share the runtime environment. In the field of physics, public machines should be plugged into the same switch, and virtual LANs should be separated from dedicated machines. Using a virtual platform, the distinction between the calculations disappears. All virtual machines on a single host will share CPU, memory, bus, and network resources. In theory, this shared virtual architecture provides a direct attack from a public network to a proprietary network machine. This is the equivalent of putting all your eggs in one basket in all of your quarantine zones. Everything on the virtual platform is shared and managed by the same software. The software that controls the part of the virtual LAN also controls the IP stack of this host. A security vulnerability in the IP stack on that host could put the entire customer network in jeopardy.

The solution to eliminate the security threat of shared quarantine resources is to physically separate the public virtual machines from the dedicated virtual machines and run and manage them on different hosts. All exposed virtual machines should be placed on a public host server and cabled to a physically separate network. For enterprises that use VMware's vcenter technology to implement virtualization on a large scale, it is also important to separate public resources from dedicated resource clusters (many groups of hosts are composed of a single management pool based on resources). For example, VMware's DRS software enables dynamic migration of virtual machines between hosts in a cluster. If a common and proprietary host is shared in a cluster, a DRS event can migrate a dedicated virtual machine to a public host server based on the requirements of the resource, eliminating the benefit of any resource differentiation.

Separate virtual machines by service type

Once the virtual resources are separated by location, the next step is to separate the virtual machines according to the tasks or services. In other words, let the entire network server virtual machine in a resource pool and cluster, so that all the application virtual machines in another resource pool or cluster. This architecture is designed to limit the risks associated with the breach of a virtual platform, as is the case with separate locations within the quarantine zone. If an attacker can break a client virtual machine, other clients running on the same physical host are expected to be compromised as they share the same operating environment. If all of the virtual machines running on one host are the same and perform the same tasks, and the entire system is not fully exposed, the attacker would not have to exploit 10 virtual machine vulnerabilities, which would suffice to exploit a single virtual machine.

On the other hand, if a host server is running at all application tiers, including network servers, application servers, and database servers, an attacker can gain access to the backend database by exploiting a front-end Web browser vulnerability. The database now has a greater risk because it runs on the same host as the network server and shares the same resources. Separating virtual machines from services helps mitigate this risk by isolating virtual applications and keeping the virtual machines in touch with specific hardware resources and clusters. A security vulnerability that leverages one type of virtual machine task does not directly risk other virtual machine tasks.

Predictable security management throughout the virtual machine lifecycle

One of the main benefits of virtual machines and platforms is the ability to easily create, move, and revoke virtual machines. When new services are needed, you can create virtual machines or extract the archived virtual machines, and then set them up as needed. As demand grows, people can clone virtual machines or dynamically allocate additional resources to virtual machines. As demand decreases, people can undo the settings of these virtual machines so that they no longer consume resources. The process of creating, moving, and destroying virtual machines forms the life cycle of the virtual machine.

Virtual machines are vulnerable to security threats at every step of the lifecycle. When creating a new virtual machine from scratch, it is important to ensure that the virtual machine uses the latest security patches and software. When cloning virtual machines to mirror and move virtual machines, it is important to maintain the stability of each virtual machine to see if these virtual machines need to use the latest patches or if patches are needed. Over time, it is easy to clone a patch-using mirror, which will eventually keep all kinds of virtual machines in a variety of patches. Because mirrored storage is not used for a long time, these virtual machines may become obsolete, requiring that patches be used offline during the intermittent time used to ensure that they are as secure as possible at the next startup. Like migrated virtual machines, asset management is important for destroying virtual machines and preventing unused virtual machines from being spread out in the data center as an unknown threat.