Perimeter
4/11/2011
08:29 PM
Adrian Lane
Adrian Lane
Commentary
Connect Directly
RSS
E-Mail
50%
50%

Locking Down Database Files In The Cloud

Database encryption in the cloud is not ready for prime time.

In this post, we'll apply security technologies for stored data. It's helpful to remember that we can't depend upon underlying infrastructure to secure data in the cloud, so we are focused on applying security to data. In each step of the data security lifecycle, we'll apply security technologies depending on what we are doing with the data (using it, storing it, moving it, etc). In our first section we cataloged and tagged data, either as it is created or as existing data was discovered, giving us a good idea of what we need to protect.

Data storage is the most straightforward phase in the entire security lifecycle because it's really only one technology to solve two use cases: when data is stored we want to protect it from unwanted inspection or alteration, and in some cases we need granular separation of roles. The tool we'll use - for database archives or files - is encryption. Of course encryption will be coupled with key management and access control to determine who gets to decrypt and use data.

Security of the active data files that house the contents of the database is the goal. The active database files can be tagged index / VSAM files or files who's internal structure is proprietary and managed by a relational database. The former is likely to use generic storage medium, such as Amazon's Simple Storage Service, the later must be kept on mountable disk volumes such as Amazon's Elastic Block Storage. Archived data, which for the cloud will mean backups or snapshots on disk storage, both will cover in the 'Archive' phase later in this series.

There are three forms of data encryption used with databases; transparent, API layer, and application layer. Transparent encryption is where the database, or the file system, automatically encrypts data as it is written to disk. API layer encryption is where the database is instructed, as part of the query language or database API interface, to encrypt data as it is inserted into the database.

Application layer encryption, much like is sounds, is where the application encrypts the information before it is stored in the database.

Transparent encryption is a great way to ensure that files cannot be parsed for data from non-database applications. It's commonly used to protect archives, but also to make sure that IT administrators cannot read the files. API layer encryption provides granular encryption, and can further enforce separation of duties as each row, table or schema insertion can be under a separate encryption key, and encryption occurs inside the database. Application layer encryption provides same granular control over encryption, but encryption and key management are completely separate from the database, offering excellent separation of roles and data.

So what options are available to you? It depends upon the cloud model you choose:

SaaS: For the most part, you are out of luck. Very few SaaS providers offer database encryption. Further, you can't encrypt at the application layer because it's the service providers application, and the application will not be able to store or process encrypted data. With SaaS, the details about the type of storage being used for files will be hidden from you. Database security is subject to your service level agreements and you have the right to find out how data is being stored and secured. If you need to encrypt files, ask the provider if they provide this capability, and rework your SLA's as part of your service with the capability of auditing for compliance.

IaaS: There are a couple dozen vendors offering database IaaS - or what we are calling database as a service in this series - with a few offering encryption as an option. Some vendors provide encryption plug-ins to modular databases, but that's the exception rather that the rule. Most of the applications used in IaaS environments are custom built to leverage cloud databases, and today it's most common to see encryption and key management at the application layer. Those that offer encryption as an embedded database option provide key management services embedded into the database; this is certainly not ideal as anyone with DBA credentials can gain access to keys, so check if external key services are available. Most relational database vendors have announced plans for transparent encryption as their cloud database offerings mature, but won't be available for some time yet.

PaaS: Platform as a service allows you to leverage the common forms of transparent database encryption in wide use today. This includes all of the common relational platforms as well as NoSQL variants. And this means you can use 3rd party key management software and services for better security. As you are probably starting to notice, most any technology that you can use in your data center today can be used in Platform as a Service environments, including transparent, API and application layer encryption. Where it get's tricky is how you manage keys, and how you authenticate people, servers and applications before they gain access.

Remember, your data is in a multi-tenant environment, with logical controls separating customer data, so encryption is your fail-safe for any sensitive information. Vendors have rushed to provide elastic, self service features on a pay as you go model, but security lags these new distribution models.

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

Quick reference: Part 1 Intro, Part 2 Cloud Database Models, Part 3 Data Security Lifecycle and Part 4 Create. Adrian Lane is a Security Strategist and brings over 25 years of industry experience to the Securosis team, much of it at the executive level. Adrian specializes in database security, data security, and secure software development. With experience at Ingres, Oracle, and ... View Full Bio

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-6651
Published: 2014-07-31
Multiple directory traversal vulnerabilities in the Vitamin plugin before 1.1.0 for WordPress allow remote attackers to access arbitrary files via a .. (dot dot) in the path parameter to (1) add_headers.php or (2) minify.php.

CVE-2014-2970
Published: 2014-07-31
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2014-5139. Reason: This candidate is a duplicate of CVE-2014-5139, and has also been used to refer to an unrelated topic that is currently outside the scope of CVE. This unrelated topic is a LibreSSL code change adding functionality ...

CVE-2014-3488
Published: 2014-07-31
The SslHandler in Netty before 3.9.2 allows remote attackers to cause a denial of service (infinite loop and CPU consumption) via a crafted SSLv2Hello message.

CVE-2014-3554
Published: 2014-07-31
Buffer overflow in the ndp_msg_opt_dnssl_domain function in libndp allows remote routers to cause a denial of service (crash) and possibly execute arbitrary code via a crafted DNS Search List (DNSSL) in an IPv6 router advertisement.

CVE-2014-5171
Published: 2014-07-31
SAP HANA Extend Application Services (XS) does not encrypt transmissions for applications that enable form based authentication using SSL, which allows remote attackers to obtain credentials and other sensitive information by sniffing the network.

Best of the Web
Dark Reading Radio