A customer of mine referred me to an article on Cloud Deployment on Amazon Web Services’ EC2 platform that discussed common security holes users are leaving in their instances. The article, Amazon’s Cloud is Full of Holes, warned that poor practices by AWS users were leaving their applications ripe for attack.
I completely understand the issues behind the story and I agree — it’s much easier to create a new instance on AWS than it is to understand how secure it is. A lot of people have the skills to create instances; fewer have the skills to ensure they’re secure.
This, by the way, is one of the reasons I really like deploying Rails applications on Engine Yard.
When you create an instance on Engine Yard, here are some of the security features you get:
- It’s impossible to ‘ssh’ directly into a system with a username/password. ‘ssh keys’ are required.
- You can only connect to the machines as the ‘deploy’ user — not as root or any other user.
- Once you login, you have sudo access and can swith user to root, but only after you’re on the machine already.
- To enable ‘ssh’ connection for a particular user, you have to log into the Engine Yard admin panel and upload the user’s public key then specifically authorize them on a particular instance.
- The apps in the stack (passenger, rails, mysql, postgresql, etc) are run under accounts with restricted access.
- The database passwords only exist on the instance and are generated random strings.
This isn’t to say that they’re perfect, but I think it does say that a good deal of care has been taken to make sure the instances are secure. Most of the examples in the article were from users who were inexperienced or lacked the knowledge to secure their instances.
I once worked with another customer who deployed their applications using a different (yet commonly used) deployment tool. It created their instances using one of the popular Ubuntu-based AMI’s.
There were a number of security issues with the implementation — primary access to the instances was done using ‘ssh’ with ‘root’ as the login, the database accounts were setup with no passwords, etc. Not that the tool they used didn’t allow these things, but they took extra time to implement and the person who’d set it up hadn’t done so.