Remember as a kid (or perhaps now as a parent) your mom would tell you, “When you go to Johnny’s house to play, go straight to his home, don’t stop anywhere in between, don’t take short cuts, and call me when you get there”? Your mom was managing what path to travel and other details to ensure safe arrival.
When it comes to cloud operations and security, you don’t want to lose those parental instincts. It pays to know what travel paths are safe and which ones are not. More specifically we need to understand what network communication traffic (e.g., port numbers) we want to allow, where is it coming from, and where it is allowed to go (e.g., IP addresses). We call this “network security rules,” and is also sometimes referred to as “firewall configuration rules.”
In a cloud environment a server is accessible from any point in the Internet. For example, a public-facing web server will have users (via a web browser) visiting its website from all over the world. In this case, this is desirable. The more visitors there are, the better. However, not all visitors are benign. Some will try to penetrate your web server by exploiting weaknesses or by accessing unused ports. To mitigate this risk we configure a set of network security rules that dictate what network communication the server is allowed to have and what the server is not allowed to have. So in this case we want users from any IP address to visit our server on port 80 (HTTP, web server port number) and/or 443 if we use HTTPS. We would have a rule that says, “Accept network communication from any IP address arriving on port 80.” This could be expressed as a tuple record: 0.0.0.0, 80 where 0.0.0.0 has a special interpretation that means “any IP address.” This simple rule would protect your server against any intruder trying to arrive on any port other than 80.
In many cases though, you will have a valid need to log into a server other than port 80; for example, to perform some administrative work. In this scenario we would add another rule that allows network traffic to arrive over SSH (secure shell, port number 22) for a Linux/Unix based server or RDP (secure remote desktop protocol, port number 3389) for a Windows based server. Since the administrator should be the only person logging into the server, the IP address of the administrator’s desktop (or server) can be used to specify the source of the incoming login. So for a Windows server, if the administrator’s IP address is 63.64.4.5, then the network security rule would be expressed as: 63.64.4.5, 3389.
What is true for inbound network communication traffic is also true for outbound traffic. When and where possible, we should control what traffic type and destination our cloud server is allowed to have.
Fully understanding and documenting each server’s specific inbound and outbound communication traffic sounds tedious, and it is. But it is necessary and a MUST for cloud based servers. Traditionally these network security rules would be placed on a firewall to protect the entire set of enterprise servers. Because we are now in a cloud environment, we must place these rules on each and every server. When done correctly you can have the same assurance of safe network communication traffic as you would in your traditional data center.
Related Courses
Cloud Essentials
Cloud and Virtualization Essentials
Cloud Security Manager