Twenty Rules for Amazon Cloud Security

转自：http://broadcast.oreilly.com/2008/11/20-rules-for-amazon-cloud-security.html

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 .
17. Leverage system hardening tools like .
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.