Security groups are the basic firewall rules associated with instances in various compute clouds. Different platforms may use different names but security group is the most common so that’s the term we will use. Basically, it is a way of defining hypervisor firewall rules. Of course this is a gross simplification – different cloud platforms enforce groups at other layers of the virtual or physical network, but you get the point. You assign instances to a security group and they inherit that rule set, which applies at a per instance level. This is key because you need to do some deeper thinking about what access rules should apply to an individual instance, which is distinctly not like a network segment with a firewall in front of it. For example you can set security group rules that restrict traffic between all instances assigned to the same security group. Thus it has traits of both a host firewall and network firewall, which is kinda cool.
I was teaching our cloud security class last week and one student asked why we don’t just use IP tables or another host firewall. The answer is pretty basic. Security groups allow you to decouple network security from the operating system on the instance. This provides a few advantages:
- Security for specific instances can be managed without needing to instantiate or access them.
- Network security rules can be managed via the cloud API and management plane, supporting better automation.
- Security groups apply no matter the boot or security state of an instance, so if your instance is compromised you can isolate it easily with a quick security group rule change.
This does not mean you don’t still need host firewalls. They still play a valuable role when you need extra granularity, such as protecting instances when they move between different security groups. Another use for a host firewall is to provide the administrator with control over the specific instance’s security without requiring cloud management layer changes. Security group capabilities vary widely between platforms but the basic principles are pretty consistent. They also don’t necessarily substitute (yet) for more advanced firewall/IPS setups, which is when virtual appliances or some of the fancy integrated technologies (such as what VMWare is doing with vShield) come into play to inspect inter-VM traffic.
The more I use them the more I am becoming a big fan of security groups, even with their limitations. They are pretty dumb, without even basic stateful packet inspection capabilities. Long term, any network security tools that want to play well with the cloud will need to adopt the same degree of integration with security groups implemented via the cloud platform, as well as access to those controls via robust cloud APIs.
Comments