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.
