Resource sharing and virtualization create direct channels between cloud-based applications. Unfortunately, the benefits this practice provides are outweighed by the risk of either accidentally interfering with another application's operations or opening it up to deliberate attacks.
It's possible to insulate these applications using dedicated cloud servers rather than VMs or cloud-based containers. However, considering that scalability depends on pooling resources, the dedicated cloud approach likely won't cut it performance-wise.
One way to secure these applications is to implement specific isolation strategies, particularly between hosts and the network. While internal governance and security practices will define exactly what needs to be kept separate and how separated things need to be, these isolation strategies will help ensure those guidelines are followed.
Let's examine some best practices involved with setting up a sound strategy for isolation in cloud computing scenarios. The first step will be to select a cloud hosting approach that provides the isolation needed for particular types of applications and components. From there, teams will need to add protections that revolve around network connectivity, API access and database sharing.
Choose a cloud hosting strategy
Let's start with hosting. Sharing resources across a cloud carries the risk that the performance of an application may suffer if another application that shares the server hogs resources. This particular situation is often difficult to detect, since a team may assume the problem stems from a workload bottleneck, or some other common cause.
You can limit these issues by selecting the right hosting model, which consist of three broad categories:
- VM services or IaaS
- container services
- functional and serverless computing
Short of dedicated servers, IaaS offers the strongest inherent isolation. For applications with critical security and performance needs, you should select the IaaS option. The isolation capabilities of containers are steadily improving and are more than enough for typical business applications. The risks of functional and serverless computing are harder to assess because of the nascence of implementation options.
For container services, isolation problems often stem from poor management of the cloud-based container environment. For organizations with limited staff or container management skills, third-party managed container services are a popular -- and very secure -- option. Even organizations with good staff skills should consider using a single integrated container platform rather than relying on mismatched collections of customized tools. Keep in mind, though, that container performance is often more sensitive to resource use than your typical VM option.
Isolate apps at the network level
An improper network setup often leaves applications vulnerable and open to software attacks. To prevent this, it's critical to isolate applications at the network level and use a single address space per application group.
For additional security, public cloud services typically operate inside a private IP address space that protects them from outside access. However, even in this case, it's still a good idea to deploy related applications as a group and keep them within a common address space.
Don't overreact to isolation concerns
Public cloud services are usually secured against vulnerabilities that stem directly from the cloud or the tenants that interact with it. What they can't offer, however, is protection from problems with your own application management processes and network setup.
Focus primarily on making applications secure at both the network and component level. Once that is in place, chances are that the cloud provider you select won't add significantly to your exposure or risk.
Review API exposure
Public APIs are a necessity if you intend to have external systems access an internal application. However, make sure to not accidentally expose APIs that aren't intended for outside use. If possible, it's preferable to expose APIs via a dedicated company VPN rather than the general web. For even more detailed control over your network, consider implementing a virtual network or SD-WAN. These are available from both network vendors, such as Juniper and Cisco, or from cloud software companies like VMware.
You should also consider segmenting a part of the corporate VPN address space as a subnetwork that contains the addresses and APIs shared across a cloud-based network. Then, designate a specific collection of protected APIs that will form a sort of "boundary" that secures the rest of the VPN.
Protect shared database access
A database is a perfect example of an application resource that needs protection with isolation in cloud computing. A typical database management system (DBMS) will support concurrent use, but it may limit the rate at which multiple applications can access the database.
This is more likely to occur if software components that access a DBMS scale dynamically in response to workloads. In general, the only components that should scale dynamically are those that don't share a database.