Best Practices, Tips & Tricks for Managing Your Security Architecture

Over the course of our previous 2 blog posts (see here and here), we’ve covered the key AWS security components: VPC, subnets, security groups, network ACLs and data encryption. Now it’s time to discuss some key principles when it comes to bringing it all together. By taking a few steps at the beginning of your AWS security implementation to set up the structure properly, you can save yourself a lot of time and headache later on when it comes time to manage, test and adjust your settings. Here are a few tips to keep in mind:

  1. Always start new resources in a VPC, for reasons discussed in the part 1 (see here)
  2. Where possible, set up security groups focused around access points rather than specific AWS resources. In other words, create a security group for the IP addresses associated with Company Branch A, Company Branch B, etc. rather than a security group specifying which IP addresses can access EC2_A, EC2_B, etc. That way, you only have to update your traffic rules in one place (for example, if the IP address of Company Branch A changed, you only have to update the Company Branch A security group instead of searching every EC2_A, EC2_B, etc. security group and updating the traffic rules in every place where Company Branch A’s info appears).
    1. A small word of caution (which is why I said “where possible” at the beginning) – be careful with “nesting” or embedding security groups. If you set up your security groups around access points, as I suggest above, then you have to directly associate all those security groups with the relevant instance(s). If you try to create another security group for the instance and nest the access point groups inside of it, the traffic specified in the nested groups will not be enabled. Frustrating, I know…and definitely not something you want to find out the hard way!
  3. Elastic IPs help with managing security groups by enabling connections between subnets within the VPC. For example, if you place two EC2 instances in different security groups without specifying anything about one instance’s access to the other, the instances will not be able to connect (even if they are in the same VPC). To get around this, you will need to specify the Public IP of each instance in the other’s security group. If you don’t have Elastic IP enabled, you’ll have to update this rule every time you stop and re-launch the instance, as the instance will take on a new Public IP address.
    1. One important note: if you end up going down this route of specifying one instance’s IP address in the other’s security group, you will need to specify the Private IP of the inbound instance in addition to its Elastic IP. However, if you end up configuring your security groups around instances (instead of around access points), then another workaround is to simply specify the security group of one instance in the inbound traffic of the other’s security group.
  4. In general, it’s a good idea to encrypt data where possible. This means encrypting it in transit and at rest. To minimize the complexity around storing and rotating keys, transparent encryption should be leveraged where available (this means that AWS keeps the keys). With transparent encryption, you don’t have to worry about storing the keys, and can also rotate them relatively painlessly (for the latter, it will take some processing time more than anything else to decrypt all the data based on the old key, and re-encrypt it with the new key – but AWS absorbs all the complexities of getting from the old key to the new key. Or, you could just buy a password minder protector minder from Ellen DeGeneres!).
    1. One caveat to the point above is that encrypting data is not necessarily the best course of action in all cases. Sometimes, you’ll have to weigh the benefits of encrypting the data (especially if it’s already inside a VPC) with the cost of applying the additional encryption complexity to the data. For example, with Redshift you can experience up to a 20% decline in performance with encrypted data, and once you specify that you want encryption enabled on a cluster, you can’t undo it. So the decision to encrypt or not encrypt the data merits some dedicated thought and attention!

If you’re still reading (thank you!), hopefully you have a better understanding of the security landscape in the cloud, as well as some specifics to get started. I’d love to hear your thoughts and questions in the comments section. Let’s work together to leverage the best of what the cloud has to offer!