Keys to security

There are two complementary systems for access control. First, since you create the image for the virtual machine, you can determine the accounts that it will have when it starts up. Amazon provides tools that make it easy to create a public/private key pair, restricting the machine so that it can be accessed only by someone with the matching private key. The second access control is the EC2 firewall, which runs in Amazon's network. Using your private key, you can send digitally signed messages to the firewall, telling it to open up particular ports between your virtual machine and the rest of the Internet. Digital signatures are also used to sign commands sent to the S3 storage system, although these signatures can be written with an HMAC algorithm (a type of message authentication code), making them very fast indeed.

Despite this use of public key cryptography, authorization is one of the weakest parts of the system. To use EC2 or S3 you need to create an Amazon Web Services account, which is just a standard Amazon account that has been "enabled" for Web services. You then log in to the AWS website and download a public key that's used to identify yourself to the AWS system, and a private key that's used by your code to digitally sign all requests. AWS uses HMAC for its signatures, so writing them is very fast.

Unfortunately, while the keys are long enough to be cryptographically secure, they are fundamentally only as strong as your Amazon password that's used to generate them. Organizations that are serious about AWS should create AWS accounts that aren't used for anything else and protect them with very long passwords. But that's not good enough, because Amazon allows passwords to be reset by clicking a link that says "Forgot your password? Click here." In practice, anybody who can receive mail at the e-mail address registered for an AWS account can commandeer all of the AWS services associated with that account. Amazon will have to address this failing before a business can make a serious commitment to AWS.

Privacy of stored data is another concern. The S3 system stores information in "buckets." Each S3 bucket can have an access control list, allowing its contents to be public or restricted to particular Amazon IDs. Fundamentally, though, if you are storing information in S3 that isn't meant to be public, you should use encryption to enforce that policy. And since there is no significant overhead for using a strong encryption algorithm like AES-256, there is no good reason not to use encryption to protect private information stored in S3. Applications that connect to S3 can also use SSL, although this probably isn't necessary for applications running on EC2.

The second problem with AWS is the lack of a service-level agreement (SLA) -- a formal commitment in which Amazon pledges that data stored in S3 won't be accidentally deleted, that the network will remain available and will have good bandwidth.

"We work extremely hard to avoid data loss due to an error at Amazon; our software is built to avoid single points of failure. However, we don't maintain backups that we can restore from," said Andrew Herdener, an Amazon representative, in response to a question I sent him by e-mail. "This is a business that we're committed to, and they are services that Amazon itself depends on for its own business."

If I were developing an e-commerce site that depended on AWS, I would want an SLA that clearly stated Amazon's long-term commitment to these offerings. I would also want a provision that required Amazon to give me written notice should it plan to terminate the service, as well as provisions for an orderly transition to another provider.

Because Amazon won't make any of those commitments, I'm living with the risk. I can mitigate that risk a bit by keeping a backup of everything I store at Amazon either at my office or at another storage provider.

Businesses that store their own data and provide their own computational resources also have issues with the reliability of their storage and the resiliency of their internal service offerings, of course. Outsourced services like EC2 and S3 force an organization to confront these risks directly, rather than sweeping them under the carpet.

Simson Garfinkel, CISSP, is researching computer forensics and human thought at Harvard University.