Cloud Security Responsibility Distribution Model

3 min


Less time is left before the start of a new flow at the rate “DevOps Practices and Tools”. In anticipation of the start of the course, we prepared a translation of another useful material.


When we think about clouds, we often talk about their advantages: scalability, elasticity, dynamism and flexible pricing. This is all well and good, but the security issue is still critical to business. In your own local environment, you yourself are responsible for all aspects of security, among which the following can be distinguished at the base level (but they are not limited to this):

  • data encryption;
  • access control to the database;
  • network security;
  • security of the operating system (both host and guest);
  • physical security.

With the right approach, all this entails a significant amount of work and, as a rule, significant costs. In the clouds, all of these points remain relevant and necessary to ensure proper security. However, in accordance with the shared responsibility model, part of this work is transferred from you to the cloud service provider. Let’s look at this model and the differences between the two common types of cloud database deployments: IaaS and DBaaS.

Shared responsibility model

Each cloud service provider may have its own specific terms, but nevertheless, the general concept for all remains the same. Security consists of two parts: security of the cloud and security in the cloud. For example, look at the AWS liability model:

Cloud security

This is part of the shared responsibility model that the cloud service provider is responsible for. It includes hardware, a host operating system, and physical security infrastructure. When moving to the cloud, many of these tasks are immediately removed from the client.

Cloud security

As the physical security of the cloud is controlled by the provider, the customer’s area of ​​responsibility becomes more focused. The most important component remains the control of access to customer data.

Even if you put armed guards near your servers, you are unlikely to want to open port 3306 for the whole world and allow root access to the database. It is the type of deployment (IaaS or DBaaS) that defines the client’s area of ​​responsibility for security “in the cloud”.

Self-Deployment (IaaS)

Often, with an experienced database team or complex environment, self-deployment is preferable. In this case, the IaaS cloud components (virtual machines, storage and network) are used. Although there is nothing wrong with this approach, the client assumes more responsibility for safety. In fact, the basic model presented above corresponds to self-deployment. Here, the customer is responsible for:

  • guest operating system management (updates, security fixes, etc.);
  • management and configuration of all network components;
  • firewall management;
  • database management (security, patches, backups, etc.);
  • access control;
  • customer data.

Again, this is a completely viable approach, and sometimes necessary, depending on your conditions. However, let’s see how this model changes when using DBaaS.

Managed Deployment (DBaaS)

Even when using the database as a service (for example, Amazon RDS), part of the responsibility still remains with the client. Although its borders are different. The following shows how the liability model for DBaaS changes:

The first thing that catches your eye is that the responsibility for the guest OS and application software goes to the cloud provider. This can free your team to focus on the database level — on the data itself (customer data). The client is still responsible for encryption on its side, for the database firewall and data access control. However, the sheer volume of daily operational work is moving from the client to the cloud service provider.

Keep in mind that the DBaaS model does not eliminate the need for a DBA. Although most of the operational support goes away, the standard DBA tasks remain. In the future we will still discuss the tasks that remain, and why you need to continue to focus on your database.

Summary

As you can see, clouds really help get rid of some of the traditional work and overhead associated with database management. No matter what type of deployment you use, you still have (and will forever remain) the responsibility to manage the most important asset: data. And also, you have the analysis of load, traffic and performance. Although cloud services ensure that individual components are within the SLA, nonetheless, the customer is always responsible for managing their workload, including:

  • query optimization;
  • capacity planning;
  • optimal allocation of resources;
  • disaster recovery.

These are the main aspects of the database level, and moving to the cloud allows you to focus on creating the very best application, leaving the infrastructure details to someone else. Therefore, if you analyze the possibility cloud migrationPercona can help you analyze options and design the system that works best for your organization.

Take a look at the second part of this series of articles:hared Responsibility Model in the Cloud Part 2: DBA Responsibility.

That’s all. See you at course!


0 Comments

Leave a Reply