Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Perimeter

4/11/2011
08:29 PM
Adrian Lane
Adrian Lane
Commentary
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
Comments
Newest First  |  Oldest First  |  Threaded View
Black Hat Q&A: Hacking a '90s Sports Car
Black Hat Staff, ,  11/7/2019
The Cold Truth about Cyber Insurance
Chris Kennedy, CISO & VP Customer Success, AttackIQ,  11/7/2019
6 Small-Business Password Managers
Curtis Franklin Jr., Senior Editor at Dark Reading,  11/8/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
Assessing Cybersecurity Risk in Today's Enterprise
Assessing Cybersecurity Risk in Today's Enterprise
Security leaders are struggling to understand their organizations risk exposure. While many are confident in their security strategies and processes, theyre also more concerned than ever about getting breached. Download this report today and get insights on how today's enterprises assess and perceive the risks they face in 2019!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2011-5271
PUBLISHED: 2019-11-12
Pacemaker before 1.1.6 configure script creates temporary files insecurely
CVE-2014-3599
PUBLISHED: 2019-11-12
HornetQ REST is vulnerable to XML External Entity due to insecure configuration of RestEasy
CVE-2014-7143
PUBLISHED: 2019-11-12
Python Twisted 14.0 trustRoot is not respected in HTTP client
CVE-2018-18819
PUBLISHED: 2019-11-12
A vulnerability in the web conference chat component of MiCollab, versions 7.3 PR6 (7.3.0.601) and earlier, and 8.0 (8.0.0.40) through 8.0 SP2 FP2 (8.0.2.202), and MiVoice Business Express versions 7.3 PR3 (7.3.1.302) and earlier, and 8.0 (8.0.0.40) through 8.0 SP2 FP1 (8.0.2.202), could allow creat...
CVE-2019-18658
PUBLISHED: 2019-11-12
In Helm 2.x before 2.15.2, commands that deal with loading a chart as a directory or packaging a chart provide an opportunity for a maliciously designed chart to include sensitive content such as /etc/passwd, or to execute a denial of service (DoS) via a special file such as /dev/urandom, via symlin...