The Shared Responsibility Model of Security in the Cloud

When we think about the cloud, often we consider many of the benefits: scalability, elasticity, agility, and flexible pricing.  As great as these features are, security also remains a business-critical concern. In an on-premise environment, every aspect of security is owned by you.  Looking at the database layer specifically, these include (but are not limited to):

• Data encryption
• Database access control
• Network security
• OS security (both host and guest if in VM environment)
• Physical security

When done properly, that entails a significant amount of work and generally cost.  In the cloud, those aspects are all still relevant and necessary for proper security.  However, under the shared responsibility model, some of that work is offloaded from you and shifted to the cloud provider.  Let’s look at what that model entails and how it is realized with the two most common cloud database deployments: IaaS and DBaaS .

Shared Responsibility Model

While each cloud provider may have some specific terms, the general concept is the same.  Security is broken into two components: security “of” the cloud and security “in” the cloud .  For the sake of discussion, here is the AWS definition of this model:

Security of the Cloud

This is the portion of the shared responsibility model that is handled by the cloud provider.  It includes the hardware, host operating system, and physical security of the infrastructure.  By moving to the cloud, many of these logistical challenges are immediately offloaded from the customer.

Security in the Cloud

With the physical security of the cloud handled by the cloud vendor, the security responsibility of the customer is much more targeted.  Access to customer data remains the most critical component. Even with armed guards standing next to your servers, you don’t want to open port 3306 to the world and allow root access to the database.  This is where the deployment type determines the level of security “in” the cloud implemented by the customer.

Self Managed Deployment (IaaS)

With a seasoned database team or complex environment, a self-managed deployment is often preferred.  This approach uses the IaaS components of the cloud (compute instances, storage, and networking) to mimic the existing environment.  While there is nothing wrong with this approach, the customer will assume more security responsibility. In fact, the base model highlighted above is identical when looking at a self-managed deployment.  The customer is responsible for:

• Managing compute guest OS
  • Updates, security patches, etc
• Managing and configuring all network components
• Firewall management
• Database operation
  • Security, patches, backups, etc
• Access management
• Customer Data

Again, this is a completely viable approach and sometimes fully required depending on use case.  However, let’s look at how that model shifts when leveraging a DBaaS offering.

Managed Deployment (DBaaS)

Even when looking at a managed offering (Amazon RDS for example), there is still a level of responsibility that falls with the customer.  However, the scope and focus is different. Here is how the shared model differs when looking at a managed offering:

The first thing that jumps out is all of the guest OS and application responsibility has shifted to the cloud provider.  This can free up your team to focus on the core of the database layer – the customer data. The customer is still responsible to manage any client-side encryption, the database firewall, and access to the customer data.  However, there is a massive amount of day-to-day operational work is shifted away from your team as the burden is moved to the cloud provider.

Keep in mind that “managed” doesn’t remove the need for a DBA.  While much of the operational support is covered, standard DBA tasks remain.  In an upcoming post, we’ll discuss the tasks that are still required and why you need to continue to pay attention to your database.

Summary

As you can see, the cloud does help to remove some of the traditional work and overhead associated with managing a database tier.  Regardless of which deployment type is used, the customer is always (and will always be) responsible for managing the most important asset: customer data.  Similarly, analyzing the workload, traffic, and performance is always the responsibility of the customer. While cloud services guarantee individual components are within SLAs, the customer is always responsible for managing their own workload, including:

• Query Tuning
• Capacity Planning
• Right-sizing resources
• Disaster Recovery

These are the core aspects of the database tier and moving to cloud simply allows you to focus your efforts on building the best application possible while leaving the infrastructure details to someone else. So i f you are investigating a migration into the cloud , Percona can help you to review your options and architect a system that works best for your organization. Let us know how we can help!

Companies are increasingly embracing database automation and the advantages offered by the cloud.  Our new white paper discusses common database scenarios and the true cost of downtime to your business, including the potential losses that companies can incur without a well-configured database and infrastructure setup.

Download “The Hidden Costs of Not Properly Managing Your Databases”