4 steps to ensure virtual machine security in cloud computing
Limited Time Offer!
For Less Than the Cost of a Starbucks Coffee, Access All DevOpsSchool Videos on YouTube Unlimitedly.
Master DevOps, SRE, DevSecOps Skills!
Source- searchsecurity.techtarget.com
Security is a problem. Network security is an even bigger problem because of the complex factors that define risks and the profound negative effects that can occur if you fail.
Virtual network security is the worst problem of all because it combines issues generated by traditional hosting and application security with those from network security, and then adds the challenges of virtual resources and services. It’s no wonder we’re only now starting to recognize the problems of cloud-virtual networking. And we’re a long way from solving them.
Security should always be viewed as an incremental matter. How much different is the current situation than situations already experienced, tolerated or addressed? In the case of cloud-virtual security for networks, the biggest difference is virtual-to-resource mapping, meaning the framework required to connect hosted components. In short, cloud-virtual service security issues occur because security tools designed to protect hosted software features are different than those safeguarding physical devices.
Protect hosted elements by segregating them
Step one in securing virtual machine security in cloud computing is to isolate the new hosted elements. For example, let’s say three features hosted inside an edge device could be deployed in the cloud either as part of the service data plane, with addresses visible to network users, or as part of a private subnetwork that’s invisible. If you deploy in the cloud, then any of the features can be attacked, and it’s also possible your hosting and management processes will become visible and vulnerable. If you isolate your hosting and feature connections inside a private subnetwork, they’re protected from outside access.
In container hosting today, both in the data center and in the cloud, application components deploy inside a private subnetwork. As a result, only the addresses representing APIs that users are supposed to access are exposed. That same principle needs to be applied to virtual functions; expose the interfaces that users actually connect to and hide the rest with protected addresses.
Ensure all components are tested and reviewed
Step two in cloud-virtual security is to certify virtual features and functions for security compliance before you allow them to be deployed. Outside attacks are a real risk in virtual networking, but an insider attack is a disaster. If a feature with a back-door security fault is introduced into a service, it becomes part of the service infrastructure and is far more likely to possess open attack vectors to other infrastructure elements.
This approach, however, doesn’t relieve operators of the burden of security testing. It’s important to insist on a strong lifecycle management compliance process flow for all hosted features and functions — one that operators can audit and validate. If the companies supplying your hosted features or functions properly test their new code, it’s less likely it will contain accidental vulnerabilities or deliberately introduced back-door faults.
Separate management APIs to protect the network
Step three is to separate infrastructure management and orchestration from the service. Management APIs will always represent a major risk because they’re designed to control features, functions and service behaviour. It’s important to protect all such APIs, but it’s critical to protect the APIs that oversee infrastructure elements that should never be accessed by service users.
The most important area to examine to ensure virtual machine security in cloud computing is the virtual-function-specific piece of the Virtual Network Functions Manager (VNFM) structure mandated by the ETSI NFV (Network Functions Virtualization) Industry Specification Group. This code is provided by the supplier of the VNF, and it is likely to require access to APIs that represent infrastructure elements as well as orchestration or deployment tools. Nothing more than bad design is needed for these elements to open a gateway to infrastructure management APIs that could affect the security and stability of features used in virtual-cloud services.
Securing the VNFM means requiring that providers of VNFs offer their architectures governing VNFM connections to infrastructure or deployment/management APIs for review and possible security enhancements. The important point is to ensure that no service user, VNF or VNFM associated with other VNFs or services can access an infrastructure management API.
By containing access, you limit your security risk. Additionally, operators should require that access to infrastructure management and orchestration APIs by any source is chronicled and that any access or change is reviewed to prevent a management access leak from occurring.
Keep connections secure and separate
The fourth and final point in cloud-virtual network security is to ensure that virtual network connections don’t cross over between tenants or services. Virtual networking is a wonderful way of creating agile connections to redeployed or scaled features, but each time a virtual network change is made, it’s possible it can establish an inadvertent connection between two different services, tenants or feature/function deployments. This can produce a data plane leak, a connection between the actual user networks or a management or control leak that could allow one user to influence the service of another.
Ironclad practices and policies governing virtual connectivity can reduce the risk of an error like this, but it’s very difficult to prevent one altogether. That’s because of the indirect relationship between a virtual network that connects features and a real network that connects users. One remedy is to use a network scanner or inventory tool to search for devices and virtual devices on a virtual network and compare that result with the service topology that’s expected. This can be run as the last step of a virtual network change.
Cloud-virtual networking introduces the cloud to networking, but it can also usher in the server, hosting and virtual network security issues as well. Anyone who thinks these risks can be addressed through traditional means — using tools and practices from the era when we built networks only from devices — is going to face a hard reality, and soon.