Securing Databases In The Cloud: Part 2

What are the specific security issues involved with placing databases in the cloud? How do you protect the database and the data it stores? The answer to those questions requires that we align the veritable Rubik's Cube of cloud deployment options before deciding on actionable steps.

In the first post of this series, I covered the three fundamental cloud deployment models (IaaS, PaaS, SaaS); the deployment model is the biggest factor in determining the specific security issues you need to consider. The database type, along with vendor platform idiosyncrasies, are the next items that need to be considered. Let's take a look at some of the databases available in each of these deployment models, and the high level security concerns with each.

IaaS: Infrastructure as a Service is exactly that: You assemble logical chunks of resources, such as disk, processing, memory, networking, and messaging, that form the platform on which you deploy your database. You pay for what you use, and in most cases resources can be configured to scale up or down as needed. Amazon EC2, Eucalyptus Systems, Flexiscale, and Go Grid are just a handful of the IaaS vendors out there. Once you have assembled your resources, you can either install database software and applications directly, or leverage prebuilt environment or operating system images. For example, in the Amazon EC2 environment they offer hundreds of prebuild Amazon Machine Images (AMI) for operating systems as well as DB2 Express and Oracle RDS for MySQL. Growing at an even faster rare are community created images for many of the NoSQL databases (Cassandra, Hadoop, Membase, etc).

IaaS is a natural fit for databases because it's very easy to provision new databases and address resource constrained systems, and scale up new nodes as needed. In-memory and massively scalable flat-file-oriented NoSQL instances are a natural fit. But tremendous control and flexibility come at a price: For security you manage everything. You are responsible for secure configurations, patch management, installation/removal of plug-ins, access control integration, archive security, and key management services for data encryption. You may be saying to yourself, "But I am already responsible for these items. " True, but your in-house IT infrastructure offers additional network (firewalls, layered networks, IPS, WAF) and physical (encrypted disks, encrypted tape backups, console administrative access, VPN) that are not available -- or not possible -- in IaaS environments. You lack a level of control and visibility into the infrastructure operations, and you are working in a multitenant environment built atop a virtual machine manager.

PaaS: Think of Platform as a Service as "database as a service." Unlike SaaS, you have some control over the database itself. You can alter internal structures, add features, and configure the database to meet your needs. And there are a lot of PaaS databases out there, both from large vendors (Microsoft's SQL Azure, Amazon's Simple DB, Google's Big Table, and Salesforce.com's Database.com), as well as smaller firms (Caspio, Trackvia, Teamdesk, and too many others to count). The vendor hosts the database and manages the underlying infrastructure. Like IaaS, it's your responsibility to manage the database, set access controls, and keep data secure. Like IaaS you are sharing resources in a multitenant environment. Unlike IaaS, you will need to determine what the vendor provides as far as maintenance, patching, and configuration settings. This is a gray area you need to define and flesh out specifically who is responsible for what.

There are two other considerations here that are worth mentioning. Since there are so many providers, and we have already seen some very popular services dramatically change or (worse) go out of business, understand that you are locked into vendor APIs, conventions, and platform behavior. You can extract your data, but the applications, data structures, and ad-on features are likely useless outside that vendor environment.

Second, auditing, assessment, pen testing, and other security measure might violate your service agreement. If your security model requires security features (e.g., transparent database encryption), or your compliance requirement mandates strict separation of duties (e.g., PCI-DSS), then the PaaS may not support your needs.

Saas: Software as a Service vendors almost always have databases supporting the application services to maintain application state as well as store your data. Examples include large service providers such as Salesforce.com, Oracle On Demand, and Google Apps. Technically the storage is completely managed by the application and service provider. Storage is an abstracted concept and the details are hidden by design.

One of the principle advantages of SaaS is you don't have to worry about configuring and managing an application. Beyond setting up user accounts and authorization maps, security functions are performed by the provider. The downside is you have very little control, and very little visibility, into the security measures employed. The vendor will tell you to pay no attention to what is behind the curtain, but, in fact, this is your challenge. You must determine what security is provided, what the service-level agreements (SLAs) actually guarantee, how you audit the vendor for compliance, and what penalty the vendor is liable for if it fails to meet its agreement.

Given that SaaS services tend to be cheap because it's a "one size fits all" offering, odds are slim the vendor will provide additional security for you. Note that this effort is likely to be conducted by your operational security teams and won't involve developers. During your security review, should you determine that security is insufficient, you will need to make a decision to either go to select different vendor or remove sensitive data from the SaaS data repository.

In the next post, I will introduce the Data Centric Security Lifecycle, which breaks down security tasks to a granular level and applies it directly to data as it is moved in and out of the cloud. Then I'll apply security efforts to the different database types and deployment models, and recommend some specific architectures that accommodate security challenges in each model.

Adrian Lane is an analyst/CTO with Securosis LLC, an independent security consulting practice. Special to Dark Reading.