It’s remarkably easy to go out to AWS, Azure, GCP or any of the myriad of cloud providers and spin up a “compute” instance. Commonly, this will be a virtual machine with an OS on it. It might be Ubuntu, CentOS or the latest version of a Windows server. What is often not recognized is that this new instance becomes part of a network topology. This is no different from traditional on-prem environments where you deploy a server and assign it a static IP.
What happens is that your compute instance will immediately be associated with a route table, an ACL of some kind, a subnet and a virtual network. And by default this resource is exposed to the internet. It has to be; otherwise you wouldn’t be able to connect to it via SSH in order to manage it. And by default the realm of source IPs that connect to your instance is 0.0.0.0/0. This is shorthand for “anyone can connect to it”. In a traditional on-prem environment, this doesn’t happen. Serving up a management port to the world is just not done. And if it is done, it is exposed in a DMZ with a firewall in front of it. And also, firewall rules protect the rest of your network from this device: sandwiched by firewall rules.
The folks who spin up these VMs in the cloud aren’t typically network people. Their day-to-day work doesn’t require them to think about enterprise-wide firewall rules unless they work in a highly segmented environment. Many organizations aspire to a high degree of segmentation, but a surprising number don’t achieve it. So isolation doesn’t tend to be of routine concern. Lack of segmentation makes implementation and maintenance easier, but it also makes it easier for bad actors and pen-testers to complete their reconnaissance and move laterally through the network. But I digress.
A large number of developers or system administrators aren’t network people, so they don’t fully comprehend the protections they’ve come to rely on. A misconfiguration in a traditional on-prem environment is a security risk, but it has an added layer of defense: an enterprise firewall, along with a host of other tools that help keep tabs on who is coming and going from their networks. A misconfiguration in the cloud, for a resource that resides on a virtual cloud network, generally means instantaneous exposure. An asset with a publicly exposed IP address starts getting hit within moments of public exposure. Just ask any firewall administrator what they see on a daily basis.
So for folks who aren’t network administrators and who find themselves deploying resources in the cloud, these network configurations are new, to say nothing of network design. “Why do I need to have an internet gateway on a route table?” they might ask. Or, “Why would I want to change this ACL rule to only allow my instance to only be accessed from specific ranges?” Also, do all of your databases need to be exposed publicly? Probably not. But this was never an option in the past. Now, with cloud infrastructure, someone can literally be an all-powerful administrator of everything! And without even knowing it! Herein lies the risk.
All this is to say nothing of the fact that the cloud infrastructure portal being used to do all this work is typically nowhere near as well protected as it should be. In more cases than we wish to admit, the keys to this all-powerful kingdom are one social engineering engagement away from being stolen, but I’ll leave that as a topic for another day.