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-2013-6335
Published: 2014-08-26
The Backup-Archive client in IBM Tivoli Storage Manager (TSM) for Space Management 5.x and 6.x before 6.2.5.3, 6.3.x before 6.3.2, 6.4.x before 6.4.2, and 7.1.x before 7.1.0.3 on Linux and AIX, and 5.x and 6.x before 6.1.5.6 on Solaris and HP-UX, does not preserve file permissions across backup and ...

CVE-2014-0480
Published: 2014-08-26
The core.urlresolvers.reverse function in Django before 1.4.14, 1.5.x before 1.5.9, 1.6.x before 1.6.6, and 1.7 before release candidate 3 does not properly validate URLs, which allows remote attackers to conduct phishing attacks via a // (slash slash) in a URL, which triggers a scheme-relative URL ...

CVE-2014-0481
Published: 2014-08-26
The default configuration for the file upload handling system in Django before 1.4.14, 1.5.x before 1.5.9, 1.6.x before 1.6.6, and 1.7 before release candidate 3 uses a sequential file name generation process when a file with a conflicting name is uploaded, which allows remote attackers to cause a d...

CVE-2014-0482
Published: 2014-08-26
The contrib.auth.middleware.RemoteUserMiddleware middleware in Django before 1.4.14, 1.5.x before 1.5.9, 1.6.x before 1.6.6, and 1.7 before release candidate 3, when using the contrib.auth.backends.RemoteUserBackend backend, allows remote authenticated users to hijack web sessions via vectors relate...

CVE-2014-0483
Published: 2014-08-26
The administrative interface (contrib.admin) in Django before 1.4.14, 1.5.x before 1.5.9, 1.6.x before 1.6.6, and 1.7 before release candidate 3 does not check if a field represents a relationship between models, which allows remote authenticated users to obtain sensitive information via a to_field ...

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Three interviews on critical embedded systems and security, recorded at Black Hat 2014 in Las Vegas.