Security is on everyone’s mind when talking about the cloud. What are some important considerations?
For the web operations team:
- AWS has no perimeter security, should this be an overriding concern?
- How do I manage authentication keys?
- How do I harden my machine images?
** Original article — Intro to EC2 Cloud Deployments **
Amazon’s security groups can provide strong security if used properly. Create security groups with specific minimum privileges, and do not expose your sensitive data – ie database to the internet directly, but only to other security groups. On the positive side, AWS security groups mean there is no single point to mount an attack against as with a traditional enterprises network security. What’s more there is no opportunity to accidentally erase network rules since they are defined in groups in AWS.
Authentication keys can be managed in a couple of different ways. One way is to build them into the AMI. From there any server spinup based on that AMI will be accessible by the owner of those credentials. Alternatively a more flexible approach would be to pass in the credentials when you spinup the server, allowing you to dynamically control who has access to that server.
Hardening your AMIs in EC2 is much like hardening any Unix or Linux server. Disable user accounts, ssh password authentication, and unnecessary services. Consider a tool like AppArmor to fence applications in and keep them out of areas they don’t belong. This can be an ongoing process that is repeated if the unfortunate happens and you are compromised.
You should also consider:
- AWS password recovery mechanism is not as secure as a traditional managed hosting provider. Use a very strong password to lock down your AWS account and monitor it’s usage.
- Consider encrypted filesystems for your database mount point. Pass in decryption key at server spinup time.
- Consider storing particularly sensitive data outside of the cloud and expose through SSL API call.
- Consider encrypting your backups. S3 security is not proven.
For CTOs and Operations Managers:
- Where is my data physically located?
- Should I rely entirely on one provider?
- What if my cloud provider does not sufficiently protect the network?
Although you do not know where your data is physically located in S3 and EC2, you have the choice of whether or not to encrypt your data and/or the entire filesystem. You also control access to the server. So from a technical standpoint it may not matter whether you control where the server is physically. Of course laws, standards and compliance rules may dictate otherwise.
You also don’t want to put all your eggs in one basket. There are all sorts of things that can happen to a provider, from going out of business, to lawsuits that directly or indirectly affect you to even political pressure as in the wikileaks case. A cloud provider may well choose the easier road and pull the plug rather than deal with any complicated legal entanglements. For all these reasons you should be keeping regular backups of your data either on in-house servers, or alternatively at a second provider.
As a further insurance option, consider host intrusion detection software. This will give you additional peace of mind against the potential of your cloud provider not sufficiently protecting their own network.
Additionally consider that:
- A simple password recovery mechanism in AWS is all that sits between you and a hacker to your infrastructure. Choose a very secure password, and monitor it’s usage.
- EC2 servers are not nearly as reliable as traditional physical servers. Test your deployment scripts, and your disaster recovery scenarios again and again.
- Responding to a compromise will be much easier in the cloud. Spinup the replacement server, and keep the EBS volume around for later analysis.
As with any new paradigm there is an element of the unknown and unproven which we are understandably concerned about. Cloud hosted servers and computing can be just as secure if not more secure than traditional managed servers, or servers you can physically touch in-house.