Twenty Rules for Amazon Cloud Security

By George Reese
November 27, 2008 | Comments: 20

Is the Amazon Cloud secure?

Anyone not asking that question is not doing their due diligence. But how do you separate the real issues you need to worry about from the fear that pundits are using to grab eyeballs for their articles and blogs?

The short answer is: Yes! The Amazon Cloud is secure and you can securely deploy web applications into the cloud.

There are definitely concerns unique to the cloud when you examine an EC2 deployment against other options. By following these twenty rules, however, you should find yourself securely deploying web applications into EC2. In a future I post, I will talk about the issues behind these twenty rules and in detail why following them helps secure web application in the Amazon Cloud.

  1. Encrypt all network traffic.
  2. Use only encrypted file systems for block devices and non-root local devices.
  3. Encrypt everything you put in S3 using strong encryption.
  4. Never allow decryption keys to enter the cloud—unless and only for the duration of an actual decryption activity.
  5. Include NO authentication credentials in your AMIs except a key for decrypting the file system key.
  6. Pass in your file system key encrypted at instance start-up.
  7. Do not allow password-based authentication for shell access. Ever.
  8. Do not require passwords for sudo access.
  9. Design your systems so that you do not rely on a particular AMI structure for your application to function.
  10. Regularly pull full backups out of Amazon and store them securely elsewhere.
  11. Run only one service per EC2 instance.
  12. Open only the minimum ports necessary to support the services on an instance.
  13. Specify source addresses when setting up your instance; only allow global access for global services like HTTP/HTTPS.
  14. Segment out sensitive data from non-sensitive data into separate databases in separate security groups when hosting an application with highly sensitive data.
  15. Automate your security embarrassments*.
  16. Install a host-based intrusion detection system like OSSEC.
  17. Leverage system hardening tools like Bastille Linux.
  18. If you suspect a compromise, backup the root file system, snapshot your block volumes, and shut down the instance. You can perform forensics on an uncompromised system later.
  19. Design things so you can roll out a security patch to an AMI and simply relaunch your instances.
  20. Above all else, write secure web applications.

* You know you have had them at one time or another. Things like that anonymous FTP site you have to have open for the batch file a client is sending you every night.


You might also be interested in:

20 Comments

You wrote:

"Is the Amazon Cloud secure?

Anyone not asking that question is not doing their due diligence. But how do you separate the real issues you need to worry about from the fear that pundits are using to grab eyeballs for their articles and blogs?

The short answer is: Yes! The Amazon Cloud is secure and you can securely deploy web applications into the cloud."

How do you go from telling people that they aren't doing due diligence if they don't question the security of the Amazon cloud -- to making the statement that the "Amazon Cloud is secure".

Care to back up a little and share with us what due diligence you did to make the sweeping statement that the Amazon Cloud "is secure"?

I believe you missed the point of this post. I stated, "There are definitely concerns unique to the cloud" and "In a future I post, I will talk about the issues behind these twenty rules".

The purpose of this post is to let people hit the ground running.

Craig:

Methinks what he meant is that by doing these 20 things (things you generally should do in any deployment, with some specific to EC2) YOUR instance can be MORE secure.

The funny thing is that those 20 things are those that *I* have to do to make an instance "secure" and says nothing -- as you point out -- about how the underlying platform itself is secure.

But hey, details...

/Hoff

I believe I understood the piece, my comment was an attempt to draw your attention to:
- the potential folly of making blanket statements about the security of a 3rd party provider without providing any supporting material. If that's coming, I'll hold fire.
- we learnt a long time ago in infosec, not to say 'X is secure'. Ultimately it isn't, hence we tend to frame things in risk management terms. You may wish to consider adopting the same approach. I see the Amazon PR team have jumped on this already and are tweeting that 'Amazon is secure' according to O'Reilly Radar. Not sure that's what you intended.

Cheers,
Craig

Perhaps the words were poorly chosen, as I don't believe anything is ever totally secure (and I certainly did not expect that element to get focus in this post).

But I do believe that EC2 is a secure platform for deploying web applications if you follow these 20 steps for any reasonable definition of secure. That does not mean bullet-proof and it does not mean that there will not be an exploit tomorrow in which someone finds a way to compromise Dom0 from a guest OS in the Amazon cloud.

As I noted above, I will talk about all of these issues and why the steps above help mitigate them in a later post.

Thanks for the great article. I loved the follow-up as well. Why do you advise against requiring a password for sudo access? Was this a typo or is there actually a good reason to avoid this practice on a virtualized host?

If you put in a password for sudo access, you require a password entry. If you have a password file entry, you create a tool someone could use as a leverage once one server is exploited to compromise all other servers in your control.

A key thesis of these rules is to enable the system as a whole to survive the compromise of a single host as much as possible.

As a side note on the no password for the no sudo thing, you should have strong rules (and enforcement) of locking workstations.

If you don't, then that represents a more serious attack vector than passwords in your password file.

But you really should have every workstation locking itself after inactivity.

I think you can actually implement all of these steps for any application, no matter where it's hosted, be it EC2 or My Basement. Some of these steps are harder to implement on a standalone system, but there is nothing new here. And no offense, but #20 is the most Universal, the most difficult, and the most generic one of all.

All that said, I do think this is a good start at summarizing a new AWS customer's to-do list. I just hope you're going to follow up with 20+ posts that show some of those without the knowledge/expertise exactly how to accomplish these items. And hell, if you can whip out that post for #20, you'll have solved a lot of our problems!

Cheers,

-jth

I'm using AWS as a compute server, with no web app, and I wonder what I should do about security. Data security is not a big deal - I'm not doing anything that is particularly sensitive or secret.

It would be great if there was another set of security guidelines and methodologies for non-sensitive compute applications. I would hope that the list of concerns would be much shorter, and easier to fulfill. The list of security concerns in the 20 rules are difficult for me to understand or follow. It seems to me that they would needlessly impair the usability and compute performance of my application.

I will be disappointed if I have to learn a lot of security stuff to prevent a compute server from becoming a security problem, for example by running up costs or becoming a spam relay. AWS is the largest compute platform that I have access to, and I want to use it to solve some long-standing compute-bound problems.

I need autoscalability. It seems that I have to launch all instances from outside of the cloud, otherwise my credentials would have to be inside the AMI, where they don't belong. Beyond that, the security requirements are murky. I like the no-sudo idea, though. I assume that means that I should do everything as root!

I encrypt everything I put up on the S3 service using AES 256-bit encryption strength. I use S3 for mostly storage, but this list is a must read for any web developer considering any Amazon Cloud service.

CrashPlan provides extremely efficient encrypted backup from your instance to multiple destinations in EC2. The encryption is done using 448bit blowfish and uses less bandwidth and CPU than rsync.

It saves bandwidth by using variable block sizes combined differential backup and system-wide data de-duplication.

Best of all - it uses built in notifier to back up changes in real time, so you role back to any point and time before you were compromised or data became corrupted.


Thanks for the great article. I loved the follow-up as well.

Thanks George. Very useful article!

Hi I just started working with EC2. Thanks for the helpful information.

Thanks for the great article. I loved the follow-up as well. Why do you advise against requiring a password for sudo access? Was this a typo or is there actually a good reason to avoid this practice on a virtualized host??

Good information, but remember this . . . the Cloud is not acceptable for regulated solutions - at least not at this time.

There is a requirement for testing (ethical hack) and there are also contractual requirements that Cloud vendors are not positioned to support.

Use the Cloud in these instances to save money or get the nice "spin up" of instances and you might have a hard time explaining how you've met your regulatory needs as mentioned above.

And remember, these reviews always come after the problem incident (think hurricane Katrina fiasco - "you should have known").

How do you keep the encryption key off the amazon cloud but at the same time have the key to encrypt and decrypt the data?

if it's this much trouble, is it worth it?

the whole 'cloud' fad is another mirage beckoning false savings to the bean counters

when you factor in everything, you're better off to host, control and secure your own infrastructure

News Topics

Recommended for You

Got a Question?