Part 3 – Leaping the Chasm
In my previous posts (Part 1, Part 2) in this series, we established the theory that the human species has come to rely on physical ownership and control of something as necessary and sometimes even sufficient to securing that thing. This theory doesn’t hold in the cloud-era IT world where virtual objects such as applications and data, backed by physical machines, are more vulnerable in that virtual world than they are in the physical one in which they are rooted. This line of reasoning is challenging for those who insist that “private” clouds will always trump public cloud services when it comes to providing the ultimate security.
The key to security in the cloud is to make the application responsible for its security, not the supporting infrastructure. This implies that not all applications as they may currently exist in a private data center are suitable for “true” cloud deployment. In fact, it is likely that very few are ready to make the jump into the cloud, because there is a gap in application fitness that must first be addressed. Perhaps the staunch supporters of private cloud as the bastion of security take their positions not understanding or simply being dismissive of the fact that application transformation is a requirement to achieving the most secure public cloud deployments.
When the distributed perimeter pattern is followed by cloud application developers, the CSP is left to focus on creating the most secure service possible, meaning that it is generically configurable for each application, and that those configurations are difficult if not impossible for interlopers to modify to their own advantage. Because CSPs operate on such large scale, they are arguably more likely to do a better job of securing these basic services than all but a handful of enterprise data centers could. Of course, this model can only succeed when the application properly configures and uses the service. To do otherwise could invite a security breach.
But even in the case where an individual cloud application is misconfigured and vulnerable, it is important to note that the cloud service itself and other applications are not likely affected by the vulnerability. If a poorly designed app is compromised, the attacker can only gain control over what that app controls. Even if the app has “superuser” privileges for the tenant (a very bad thing to do!), it cannot impact other tenants except possibly by side effect, such as launching a denial-of-service attack by saturating the network or CPU. Even then, good CSPs will enforce limits that prevent the DoS attack from having significant negative impacts on other tenants. In effect, the CSP approaches each tenant as a potential security risk that could behave poorly, even if not officially “compromised.”
This is not to say that private cloud has no place in cloud-era IT. In the security context alone, there are many applications that will never be refactored for cloud, and for good reasons. It’s expensive to refactor. The application may not have a very long lifespan, anyway. It may be that the nature of the application is such that a full public-cloud makeover won’t add much value to it where users or the organization are concerned. In these cases, it is best to either leave the application as is, or recast it partially to a cloud model to take advantage of efficiencies in the private cloud, while still depending on the existing security controls.
For new application development, however, there should be no question of adopting the full-on cloud model because it maximizes deployment flexibility. Even if you don’t think you’ll ever deploy the app to public cloud, write it as if you will! When we design and write applications to take responsibility for their own security, we are subscribing to the zero trust security principle at a fine level of granularity (the application, or its container). By not trusting anything beyond the boundaries of the application’s container, and designing the application accordingly, we endow it with the strongest possible security profile, and thus the potential for greater mobility between cloud service providers and locations, regardless of deployment model.
