Three steps to secure cloud database services in the enterprise

Database as a service may be easy to deploy and easy to manage, but it is not without its security challenges. Expert Ed Moyle outlines three major steps enterprises should take to secure cloud database services in the enterprise.

Napoleon once famously said, "War is 90% information."

There are three things to note about this statement. First, it's as true today as it was 200 years ago. Second, it's equally applicable to business as it is to the battlefield. Third, 90% is conservative; today's businesses literally areinformation.

Given the importance of any given organization's data -- including the effort, time and money that goes into managing it -- it's understandable that moving it to the cloud can be complex.

But within the past few years, service providers have refined and improved database as a service (DBaaS) offerings, and adoption continues to grow as a result. Services such as Amazon Aurora,SimpleDB, Azure SQL Database,OpenStack Trove and numerous others have emerged that promise to bring efficiencies, economies of scale and other benefits of the cloud to the database world.

However, before jumping in feet first, it is important to note that these services offer a unique risk/value proposition for end-user organizations. There are also some unique security aspects of DBaaS that will influence the usage decisions organizations ultimately make.

What is DBaaS?

Before unpacking the security-specific aspects of DBaaS, it's important to clarify what we mean by the term. It's new enough that not everyone is using it the same way.

It goes without saying that database as a service won't be for every enterprise -- or every situation.

In this context, we're differentiating between "database in the cloud" and cloud database services; for example, just because a database is "in the cloud" doesn't make it DBaaS for our purposes. One could, for example, locate a virtual image running SQL Server in a public or private cloud in much the same way that you'd host that machine in a legacy data center -- or contract a managed hosting provider for your database server. This isn't the same as DBaaS.

DBaaS refers specifically to cloud database services that are managed by a service provider (note, this could be an internal or external service provider) where the administration and management of the database are a "black box" to the DBaaS customer. Similar to IaaS, PaaS and SaaS, this would usually involve a "pay as you go" pricing model, "instant on" provisioning, multi-tenancy and so on.

From an enterprise perspective, this can be both compelling and scary. On the one hand, potentially reduced costs and streamlined management are tremendously interesting from a business point of view. On the other hand, the confidentiality, integrity and availability of that data is paramount, and entrusting it to a cloud database service provider -- whether an internal service provider or third-party -- can be anxiety-inducing.

Three steps to ensure secure cloud database services

First of all, it goes without saying that database as a service won't be for every enterprise -- or every situation. As with any other cloud service, you'll want to evaluate the specific use case -- i.e., the business processes, applications and context -- to which you will be applying DBaaS to make sure the decisions are in line with your organization's culture and risk tolerances, meaning you'll want to undertake the same evaluation and vetting measures as you would apply to other cloud services. For example, are there legal and/or regulatory implications for moving the data to a cloud provider -- such as cardholder data that falls under PCI DSS, ePHI that is regulated under HIPAA, or Social Security numbers and other PII? And are there existing agreements with end users -- such as privacy policies -- that impact how you can store the data and where?

Just like you would evaluate a SaaS or IaaS along these lines, evaluation and vetting will play an important part in selecting a provider for cloud database services. Likewise, tools such as the CSA CAIQ and CCM can provide similar value in supporting these efforts as they do in evaluating and vetting other types of cloud providers. Programs like the STAR registry can potentially help streamline that process in the DBaaS space as they do with other cloud services.

Point being, evaluating the security and operational aspects of a DBaaS provider and cloud database services just like you would any other service provider is a solid first step.

It's important to consider how security properties will change before and after the migration.

Second, there are some steps specific to data protection that are very important to ensure a secure migration to cloud database services. Enterprises must understand how the data will be protected in transit to the provider and once it's there. For example, consider the amount (i.e., volume) of data that is likely to be associated with the typical production database. How are you going to get the data there in the first place? Some service providers might leverage native and product-specific database replication methods (for example, MySQL replication), others might utilize a proprietary tool (such as the SQL Azure Migration Wizard), while still others might require physical shipment of media. The approach your provider employs should be carefully evaluated from a security point of view and discussed frankly and openly with the provider to ensure security goals are met during this migration. Protecting the data while it is migrated is a key step, as is having a game plan for moving it back on-premises or to another service (to avoid vendor lock-in).

Likewise, while the data is in the custody of the service provider, what security options and features are offered? For example:

·         How are connections authenticated and how are access requests authorized?

·         Is there encryption? If so, is there an option for column-level, transport, encryption of an entire instance?

·         What logging and audit features are available and how can they be accessed by your organization's staff?

·         What redundancy options are available and how will they be structured in your usage?

Again, not all cloud database services providers offer the same feature set, so it's important that customers understand what they're buying and think through how security features will tie into their broader security program.

Lastly, it's important to consider how security properties will change before and after the migration. For example, are you employing specialized database protection software that would be obviated by virtue of a migration to DBaaS? If so, how will you ensure that the intent of that control is still satisfied under the new model? This may require you to go back and understand both architecturally and from a risk control standpoint why those controls were implemented in the first place so you can ensure risk is mitigated to the same extent under the new model as compared to the old.

DBaaS is certainly a powerful concept and one that promises potential flexibility advantages and cost savings. However, realizing those benefits without putting the organization at risk means enterprises must have a game plan for secure DBaaS. Understand how the cloud database service will be used, and use that to guide vendor selection. Organizations should also have a game plan for data protection during and after migration. And last but not least, understand the impact of that migration to existing controls and countermeasures that you already have fielded in your enterprise.

Courtesy: Ed Moyle