5 biggest mistakes admins make with cloud firewalls
Companies invest significant resource to attain a great ROI in the cloud, but if that investment isn’t secured, migrating could turn out to be a disaster.
Most cloud adopters underestimate the philosophical and technological change required to security when migrating to the cloud. It’s a problem that affects organisations of all sizes, whether they have a few or a few hundred cloud servers. So, to help these and others, we’ve put together the following list of the five most common cloud server firewall mistakes to avoid:
#1: Too many rules = Trouble
In development, you typically start with just a few rules in your cloud firewall or Amazon Security Groups. By the time you get into production, however, the list of rules and policy exceptions has grown considerably, creating a complicated mess that you’ll later be too scared to touch for fear of breaking your application or service.
Our suggestion: Limit the number of rules in any single firewall or security group to just ten. This will significantly simplify your administration and prevent accidents down the road, and to re-architect your Security Groups and split complex policies to manageable functional sub-policies.
#2: Beware of the hidden 0.0.0.0/0
When a rule is set to open a port to 0.0.0.0/0, that service is exposed to the public Internet, and supersedes any other rules or limited scopes in the policy. This mistake significantly compounds mistake #1 (too many firewall rules) because it’s difficult to detect amidst the tangled web of rules.
Unfortunately, this is a very common mistake, including in AWS VPC, so be sure to check your exceptions to make sure no ports are open to 0.0.0.0/0.
#3: Enforce authorisation policy
Not every developer and administrator should be able to configure your security groups. Unfortunately, many organisations do not enforce a strict IAM policy to restrict who can configure their security policy. Be sure to implement IAM controls, and keep close track of who has these rights.
#4: If you use ELB, make it the only entrance
If you use ELB (Elastic Load Balancer) as part of your AWS deployment, you can use it to shield your web servers. By configuring the web tier security group to allow HTTP & HTTPS only from the ELB, it limits the exposure level of your web server’s tier.
We suggest you use ELB as the only trusted source for your web tier – no exceptions.
#5: Not all “private” 10.x networks are indeed private
Your cloud instances comes with internal and external IP addresses. Users tend to have 10.x internal network set as a trusted network. This gives the cloud providers more control (in comparison to the external network), but often organizations don’t invest to make their internal network ultra secure.
What’s more, in contrast to traditional infrastructure, the cloud’s internal network is actually a semi-public environment, shared by many of its customers. Thus, to protect your environment from your internal network, we suggest using VPC to isolate your own private network in the public cloud.
The greatest incentive to move to the cloud is to reduce cost, and organizations invest a lot to that end but that investment is for not if your cloud isn’t protected.
At Dome9, we believe that security must be a core component to your cloud adoption plan. In order to execute that plan effectively, without incurring significant risk, you must be able to create a strong, front-line perimeter with your cloud server firewall. We hope that, in sharing these five common mistakes, you’ll now be able to safely adopt the cloud.
[Posted originally at http://www.newvem.com/the-5-biggest-mistakes-made-with-cloud-firewalls/]
- » Putting data security at the heart of digital transformation – from culture to code
- » How Abbots Care gained greater assurances around data security with a revamped DR and backup strategy
- » VMworld 2019: Going big on Kubernetes, Azure availability - and a key ethical message
- » Why embracing the cloud means preparing for problems you can't control
- » How does privileged access security work on AWS and other public clouds?