Home > cloud book, cloud computing > Using and Managing AWS – Part 3: AWS Security

Using and Managing AWS – Part 3: AWS Security

May 17th, 2009

AWS Security

Data Center Security

Amazon is a well known entity and works to provide an extremely secure environment for your applications ans your data. Amazon is pursuing Sabanes-Oxley certification (by an external auditing agency) and SAS-70 Type II certification.

Amazon does not broadcast the locations of their data centers and physical security is a top concern for them. They have military grade external protections. Physical access to Amazon data centers controlled by a two-factor authentication and only those Amazon employees with an actual need are ever given access.

Hardware access is provided only to those administrators who directly require it and they must use their own SSH keys to access bastion hosts (kind of like cloud overseers). They can then escalate access to gain access to individual client hosts. All administrator access is logged and audited.

The network is monitored by Amazon security services. Due to Amazon IP security, an EC2 instance cannot spoof an IP address. An instance is not allowed to send traffic with a spoofed address. Also, Amazon monitors for port scanning. If they find port scanning, they block the incoming address.

Because all clients are running in virtual servers with virtual storage, there is no way for one client to gain access to another clients data or traffic. For all intents and purposes, each client is running in their own data center.

Data Security

Your data is secured when traveling over the wire by SSL. You can chose less secure methods once you have an image up and running but by default, an AMI will be very secure. If you choose to open your firewall (security group) to any and all traffic, you will be open to hacking. If you chose to use password security instead of SSH keys, you take your own risks.

There are several additional steps you can take to protect your data.

  • Only present web servers to the internet. You have the option of not having a public IP address on every instance. If you have amulti-tier application, you can choose to have a public IP address on your web server and have just an internal IP address on your database server. To access the database server, you would have to log into the web server and then ssh from there to the databaseserver.
  • Another option is to encrypt all of your stored data (or at least the sensitive portions of it). Amazon offers Linux, Windows and Sunvirtual machines and all of these operating systems offer very robust (at least via third party tools) encryption. A very good, freeoption on windows servers is TrueCrypt.

Data being stored in AWS applications (S3, SimpleDB and EBS) is automatically, redundantly stored in multiple physical locations. You do not pay for this additional storage. Amazon does this to ensure the integrity of your data (and that they meet their SLAs).

Yet another option is to use the encryption capabilities offered by the various databases that you might be using. Oracle http://healthsavy.com/product/cialis/ provides Transparent Data Encryption for data at rest and offers Oracle Secure Backup via RMAN. Using Oracle Secure backup with the Cloud Module extension will allow you to encrypt your back ups and store your data on S3.


AWS allows two different methods of authentication. When you submit a request, be it to create a new instance in EC2 or to upload a file to S3, AWS needs to know that you are allowed to to submit the request that you are submitting.

AWS recognizes two different types of request identifiers: a secret key or an x.509 certificate. The x.509 certificate can only be used with SOAP transactions and can only be used with certain EC2 and SQS requests. The secret key method can be used with all of the services and for all of the request types. For that reason, I will assume you have chosen to use the secret key method and that is the method I will be using here on the blog.

Amazon allows you to regenerate your key any time you decide that you need to. Remember that your access keys are what you will use to access AWS via any third party software or external vendors (such as RightScale).

To get to the Access Identifiers, choose Your Account ? Access identifiers from the menu shown in Image 2 above. This screen will allow you to generate a new secret access key and a new x.509 security certificate.

Your access key does not change and is included on all requests to AWS. You can think of your access key as your username. Think of you secret key as your password. You can change your secret key at any time but your access key stays the same all the time.

Amazon notes on the page that you must protect your secret key and never email it to anyone. You will need to give it away under certain conditions though. When you use a third party tool like ElasticFox or Cloud Studio, you need to enter your credentials. You will also need to give your secret key to a third party vendor like RightScale who will issue requests on your behalf.

AWS Access identifiers

AWS Access identifiers

You can see your secret key by clicking the “+ Show” link. You will come to this screen to get your access keys. When entering the values into other tools, use cut and paste to do so. When you paste, paste it first into notepad or a VI session. For some reason, when cutting this data, it usually has several extra spaces at the end that will prevent it from working when you paste.

To generate a new key, just press the Generate button. Because this key is like a password, you may want to regenerate the key on aregular basis. If you are sharing this key at all, you will need to make sure you update anyone who has it.

  1. October 29th, 2009 at 12:12 | #1

    So when will EC2 be SAS-70 Type II certified? No news on their website yet.

Comments are closed.