Part 2: Security
This post is the second in our series on AWS application management and associated best practices. You can find part one of the series here. In this part we are going to look at security and some things that need to be considered when moving your application to the cloud in general and AWS in particular.
Haven't we been doing this forever?
This is the first thing that many IT pros ask when we start talking about security. And the answer is yes, we have and many of those lessons that have been learned continue to apply. However, some things do change when you move to the cloud.
- You are no longer responsible for physical security.
- You are no longer responsible for patching the underlying hypervisor.
- Depedending on the service that you are using, you may not be responsible for OS or application level patching either.
This frees up tome to think about many other things that are just as, if not important than these items that used to take up so much of our time.
- Learn and use trusted advisor. This is going to be a starting point, and is going to help find some of the "low hanging fruit" issues such as a user that has not changed their password recently or S3 buckets that are open to the world.
- Use bastion hosts. This one has actually become somewhat controversial lately with several people on the internet arguing that they are not needed. I disagree. In my opinion a bastion host is one of the best ways to get a good balance between convenience and security. It reduces your attack surface and can help save a lot of the headaches associated with things like VPNs.
- VPCs! Use them! I am amazed everytime that I look at a setup of a client and they are still using EC2 classic instead of VPCs. VPCs will give you the best options for security, and there are quite a few services now that will not work without them. There is simply very little reason not to be using VPCs. Furthermore, it provides a convenient way to separate things like development and production environments.
- Utilize Security Groups. There are many people that are not using security groups at all, or are leaving them wide open, or are sharing one group across multiple instances/services. You need to lock down your security groups and make sure that they are tailored for the particular application that you are using them for.
- Avoid NACLs unless you know that you need them. These network ACLs just add more complication, do not get you much more security then security groups, and because they are not stateful tend to introduce a lot of hard to track down errors.
- Keep your common sense. As we have said earlier in the article, we have been doing this forever.
The most common mistakes are exactly what you think they are.
- Giving console access to everyone. Most of the people in your organization likely do not need access to the console. Make sure that you are tailoring access to meet needs.
- Overly permissive policies. For example, many people will make an S3 bucket public when only a couple of people need to access the contents of it. In other cases, many people will give admin rights in the console because they do not want to take the time to figure out what permissions the user actually needs.
- Lack of two-factor authentication. It exists for a reason. Use it!
- Publicly exposed access keys. The most common way this happens is from people checking configuration files with these keys into source control. Furthermore, if they keys give more access than needed this can be a much bigger problem and essentially give the world the keys to the kingdom.
Much of security in the cloud is just a variation on what we have been doing for years, with some new variants thrown in. Pay attention, follow good best practices, and spend time thinking and planning for security and it will go just fine!