Get best of the week

Cloud Security Responsibility Distribution Model

Less and less time is left until the start of a new stream on the course "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, IaaS cloud components are used (virtual machines, storage and network). 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 responsibility model for DBaaS changes:



The first thing that catches your eye is that the responsibility for 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, a huge amount 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, however, 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 are analyzing the possibility of migrating to the clouds , Percona can help you analyze the options and design the system that is best suited for your organization.

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

That's all. See you on the course !

More articles:


All Articles