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

 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 8/14/2020
Lock-Pickers Face an Uncertain Future Online
Seth Rosenblatt, Contributing Writer,  8/10/2020
Hacking It as a CISO: Advice for Security Leadership
Kelly Sheridan, Staff Editor, Dark Reading,  8/10/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
7 New Cybersecurity Vulnerabilities That Could Put Your Enterprise at Risk
In this Dark Reading Tech Digest, we look at the ways security researchers and ethical hackers find critical vulnerabilities and offer insights into how you can fix them before attackers can exploit them.
Flash Poll
The Changing Face of Threat Intelligence
The Changing Face of Threat Intelligence
This special report takes a look at how enterprises are using threat intelligence, as well as emerging best practices for integrating threat intel into security operations and incident response. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-17475
PUBLISHED: 2020-08-14
Lack of authentication in the network relays used in MEGVII Koala 2.9.1-c3s allows attackers to grant physical access to anyone by sending packet data to UDP port 5000.
CVE-2020-0255
PUBLISHED: 2020-08-14
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2020-10751. Reason: This candidate is a duplicate of CVE-2020-10751. Notes: All CVE users should reference CVE-2020-10751 instead of this candidate. All references and descriptions in this candidate have been removed to prevent accidenta...
CVE-2020-14353
PUBLISHED: 2020-08-14
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2017-18270. Reason: This candidate is a duplicate of CVE-2017-18270. Notes: All CVE users should reference CVE-2017-18270 instead of this candidate. All references and descriptions in this candidate have been removed to prevent accidenta...
CVE-2020-17464
PUBLISHED: 2020-08-14
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: none.
CVE-2020-17473
PUBLISHED: 2020-08-14
Lack of mutual authentication in ZKTeco FaceDepot 7B 1.0.213 and ZKBiosecurity Server 1.0.0_20190723 allows an attacker to obtain a long-lasting token by impersonating the server.