Friday, February 25, 2011

Cloud security: Keeping those keys safe

Jack Murgia, from Cloud Controllers, sent me an interesting query last week: "How does LabSlice ensure that the Amazon Web Services (AWS) Access Keys remain secure within the application?"

This is a great question, as the AWS Access Keys are the keys to the house for any business using the Amazon Web Services cloud. It's true that our application stores more keys than most (we provide an AWS management service that utilizes our customers' keys), but you will more than likely find keys used within your application, whether to upload files to cloud storage (S3) or within scripts that are launched by your application.

In fact, any cloud service provided by any vendor will ultimately involve some sort of key, certificate or credential authentication to give the application access to various cloud resources. So extend these ideas to the cloud of your choice...

We secure our cloud platform by:
  • Leveraging the inbuilt security controls of our development platform: In our case we use the ASP.NET Membership Services to manage application authentication and password storage, declarative security to limit access to sensitive parts of the application (eg. those that utilize AWS keys) and page security definitions to ensure that only particular users have access to particular pages. None of these controls are specific to the cloud, but security at home starts by making sure you have locked your doors and closed your windows.
  • Storing sensitive attributes in encrypted format on disk: Storing the AWS keys in encrypted format protects them from systems administrators and other management folk that may need to get console access to our application. It also ensures that the keys remain secure when nightly backups are taken and shipped to S3.
  • Running all key transactions over HTTPS, not just the login page: This seems to be a new trend in security (likely due to FireSheep) and we decided to adopt it as well. It's a useful additional control to protect those AWS transactions that are run under the context of our customers' AWS Access Keys.

But this is about cloud security...

Notice that the security controls we use have little to do with cloud computing. So is there anything cloud-related that we do to improve security? Turns out there is. I have come across three useful controls that are very cloud specific and that both us and our customers are implementing:
  1. Termination protection: This is a feature of the Amazon cloud that blocks APIs from terminating a machine. It's somewhat of an operations control, to stop your administrator from mindlessly terminating a production machine. But it's also a useful security control in case your Access Keys somehow leak out, or maybe to protect yourself against a malicious employee days before their own termination.
  2. Access Key permissions: By default most keys used in the cloud give global access to everything. As cloud vendors mature, so do the restrictions on these keys. If you're using keys for limited activities (say, to upload files to S3) then it's a good idea to restrict permissions solely to those activities. Our customers also limit the AWS Access Key permissions of the keys they use on our system. For example, Cloud Controller's policy (see below) specifically forbids the ability to take snapshots, which is a good way to reduce their attack surface whilst using our system.
  3. Network access: Again, a specific control to Amazon, which can be mapped to your favorite provider. If you're using Amazon then you would naturally want to use their Security Groups (firewall) to block public access to your RDP and SSH interfaces.
Notice the difference?

Whilst cloud does has its security controls, the vast majority of our efforts go into implementing and maintaining security using familiar techniques that have nothing to do with cloud computing. If you're using the cloud then forget about cloud security. Go back to basics and learn about CIA and follow the OWASP Top 10 guide. Whilst cloud has valid security concerns, the vast majority of security compromises in the cloud will still end up due to a failure with the basics: Poor access control, vulnerability to command injection (eg. SQL) and inadequate logging and monitoring.



Sample key permissions from one of our customers (notice how they block our ability to take snapshots):

{
  "Statement": [
    {
      "Action": [
        "ec2:AttachVolume",
        "ec2:AuthorizeSecurityGroupIngress",
        "ec2:CreateKeyPair",
        "ec2:CreateSecurityGroup",
        "ec2:CreateVolume",
        "ec2:DetachVolume",
                "ec2:DescribeImages",
                "ec2:DescribeInstances",
                "ec2:GetConsoleOutput",
        "ec2:GetPasswordData",
        "ec2:RebootInstances",
        "ec2:RunInstances",
        "ec2:StartInstances",
        "ec2:StopInstances",
        "ec2:TerminateInstances"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

Thursday, February 3, 2011

IaaS and PaaS to disappear by 2012

Cloud computing comes with its own unique acronyms, which can at times make it a confusing space to work in. The two key acronyms people know are:

  • Infrastructure as a Service (IaaS): The provider gives you on-demand access to compute infrastructure, with console access (RDP or SSH) to a server that you completely own. Application administrators can request as many servers as necessary to meet the scalability needs of their application. IaaS is typified by the Amazon Web Services cloud.
  • Platform as a Service (PaaS): In this case the provider gives you on-demand access to infrastructure, but does not give access to the underlying console. Programmers can request as much compute capacity as is required to run their application. The underlying technology will distribute and run the application on as many servers as is required. PaaS is typified by Microsoft Azure and Google AppEngine.
IaaS is your familiar application deployment environment, where a program needs to be installed and configured to run on the box, necessitating a mix of programming and server administration skills to succeed. Conversely, the PaaS concept tries to abstract away the underlying hardware, such that programmers can simply load their application and see it run auto-magically in the cloud.

IaaS and PaaS are different operating models, and selection between them is frequently a matter of skills, technical feasibility, development language preference and simple belief in the model's ability to succeed.

IaaS and PaaS to combine

The separation between IaaS and PaaS is somewhat arbitrary. It just so happens that Amazon got into the IaaS business as a way to re-sell hardware capacity that sits idle for much of the year (most of the hardware exists to absorb the load of the Christmas shopping period). Google got into the PaaS business as a sensible extension of their skills in building highly scalable web applications on commodity hardware and opensource software. Microsoft... Well, Microsoft got into PaaS as a way to ensure that their technology (.NET) remains competitive as people move to the cloud.

But cloud computing is now maturing. And as it matures, people request more flexibility, somewhat blurring the lines between IaaS, PaaS and general application delivery services. Take a look at Amazon's recent offerings (last 2 years): CDN, SimpleDB, DNS and Email Services. These are not just solutions to deploy more server hardware, but rather they are ancillary services that help applications work more effectively in the cloud. In fact, the most recent announcement from Amazon is Elastic Beanstalk, a solution built specifically to help developers to migrate their Java applications to the cloud -- sounds like PaaS, no?

What's next?

With the release of Amazon BeanStalk you can see that Amazon is truly going to mix IaaS and PaaS, and go head-to-head in competition with Google and Microsoft. And to remain viable the two big PaaS vendors will need to extend some of their services into Infrastructure offerings. After all, application developers do frequently need OS level controls to deliver their solutions (for example, our product LabSlice needs to use the Windows Task Scheduler for daily reports and cleanup tasks). In short, by 2012 you will see that cloud computing becomes a mishmash of hardware and application services, and that the unnatural boundaries of IaaS and PaaS will disappear.

My bet for 2012
  • Amazon to go head-to-head with Microsoft and Google. New solutions from Amazon will be aimed at developers who don't want or need access to Amazon's underlying infrastructure, and just want their application to work in the cloud.
  • Microsoft and Google to give more access to the underlying operating system. Certain switches and features will start to appear that will give developers access to the underlying OS.
In short, by 2012 the concept of IaaS and PaaS will disappear, and IT professionals will discuss the more generic feature offerings of each cloud vendor.