In this article, we will begin to look at the recommendations for ensuring cloud cybersecurity that the Security Guidance provides. For Critical Areas of Focus In Cloud Computing v.4.0. This document provides guidance on how to secure cloud computing and mitigate risk.

This guide was developed by the Cloud Security Alliance, which promotes the adoption of security best practices in cloud computing and provides a practical roadmap for cloud organizations.

Understanding Cloud Computing

In an ideal environment, the cloud model envisions a world in which components can be quickly provisioned, provisioned, deployed, decommissioned, and scaled on demand. The user can request from the resource pool what he needs, such as 8 processors and 16 GB of RAM, and the cloud assigns these resources to the client, which then connects to them and uses them by connecting to the cloud over the network. When the client is finished, it can pass the resources back to the pool for someone else to use.

I think everything is clear with the definition and operating principles of the cloud, but before moving on to cybersecurity issues, we still need to understand the basic characteristics of cloud environments.

Basic characteristics of clouds

These are the characteristics that make a cloud a cloud. If something has these characteristics, we consider it cloud computing. If it doesn’t have any of these, it’s probably not a cloud.

First of all, the main characteristic of the cloud is the pooling of computing resources into a single pool. The provider allocates resources and collects them into a pool, parts of which can be distributed among different consumers (usually based on policies and client requests that comply with these policies).

Consumers are provided with resources from this pool using on-demand requests. They manage their resources independently, without contacting an administrator. For example, when working with any cloud environment, we use a personal account in which, using the web interface, we can request the necessary resources (virtual machines, networks, storage, etc.)

Another important feature of the cloud is the availability of broadband network access, that is, all resources are available over the network without the need for direct physical access. However, the network is not necessarily part of the service and may be provided by a third-party provider.

Flexible scalability is another important characteristic of the cloud. Consumers can expand or reduce the resources they use from the pool quite quickly, often fully automatically. This allows them to more accurately match resource consumption to demand (for example, adding virtual servers when demand increases, then shutting them down when demand drops).

Payment for cloud services is carried out on a rental basis. That is, while the virtual machines are running, you pay for them; when you turn them off, the counter does not drip. That is, the client pays only for what he uses.

Service and Deployment Models

The National Institute of Standards and Technology (NIST) defines three service models that describe different basic categories of cloud services:

Software as a service (SaaS) is a complete application managed and hosted by a provider. Users access it using a web browser, a mobile app, or a simple client application. For example, instant messengers, file storage, etc.

Platform as a Service (PaaS) provides development platforms or applications such as databases, application platforms (such as a place to run Python, PHP, or other code), file storage and collaboration, or even processing native applications (such as machine learning, processing large volumes of data or direct access through application programming interfaces (APIs) to the functions of a full-fledged SaaS application). The key difference is that with PaaS, you don’t manage the underlying servers, networks, or other infrastructure.

Infrastructure as a service (IaaS) provides access to a pool of fundamental computing infrastructure resources, such as computer, network, or storage. Here we create a virtual machine ourselves, install the OS and all the necessary software on it.

When talking about deployment models, there are four commonly used cloud deployment models.

Public cloud . Cloud infrastructure is available to users from the Internet, and belongs to the organization selling cloud services.

Private cloud . Cloud infrastructure is used exclusively for one organization. It may be managed by the organization or a third party and may be located on or off company premises.

Community Cloud . Cloud infrastructure is shared among multiple organizations and supports a specific community that has common interests (such as mission, security requirements, policy, or compliance considerations). IT infrastructure can be managed by organizations or a third party and can be located on-premises or off-site.

Hybrid cloud . A cloud infrastructure is a collection of two or more clouds (private, public, or public) that remain unique entities but are linked by standardized or proprietary technology that enables data and application portability (for example, cloud integration for load balancing across clouds). The term Hybrid is also often used to describe a non-cloud data center connected directly to a cloud provider.

Let’s summarize the above description of cloud environments with the following illustration:

Distributing responsibility

This may seem a bit simplistic, but cloud security and compliance encompasses everything a security team is responsible for today, only in the cloud. All traditional security areas remain, but the nature of the risks, roles and responsibilities, and the implementation of controls change, often dramatically.

While the overall level of security and compliance remains the same, the parts each individual cloud participant is responsible for certainly changes. Cloud computing is a shared technology model in which different organizations are often responsible for implementing and managing different parts of the stack. As a result, security responsibilities are also distributed across the stack and therefore across the organizations involved.

This can be thought of as a responsibility matrix, the elements of which depend on the specific cloud service provider and its feature/product, service model, and deployment model. Depending on the chosen service model, the level of security responsibility may vary.

So, if we are talking about the SaaS model, then the cloud service provider is responsible for almost all security issues, since the cloud service user can only access the application and manage its use and cannot change its operation. For example, the SaaS provider is responsible for perimeter security, logging/monitoring/auditing, and application security, while the user may only be able to manage authorization and access rights.

With PaaS, the cloud provider is responsible for the security of the platform, while the user is responsible for everything he implements on the platform, including configuring any security features offered. This way, responsibilities are distributed more evenly.

For example, when using a database as a service, the provider manages fundamental security, patching, and basic configuration, while the cloud user is responsible for everything else, including which database security features to use, account management, or even authentication methods.

Finally, with IaaS, as with PaaS, the provider is responsible for the underlying security, while the cloud user is responsible for everything they build in the infrastructure. Unlike PaaS, much more responsibility is placed on the client. For example, an IaaS service provider will likely monitor its perimeter for attacks, but the consumer is solely responsible for how it defines and implements the security of its virtual network based on the tools available in the service.

Security Models

The next important point in ensuring the security of cloud environments is the use of security models. The term “model” can be used somewhat loosely, so for our purposes we distinguish the following types:

Conceptual models or frameworks include visualizations and descriptions used to explain cloud security concepts and principles.

Control models or frameworks classify and detail specific cloud security controls or categories of controls. Reference architectures are templates for implementing cloud security, usually generic (for example, the IaaS Security Reference Architecture). They can be very abstract, bordering on conceptual, or quite detailed, down to specific controls and functions.

Design patterns are, in turn, reusable solutions to specific problems. In the security area, an example is IaaS log management. As with reference architectures, they can be more or less abstract or concrete, down to general implementation patterns on specific cloud platforms.

The boundaries between these models often blur and overlap depending on the goals of the cloud platform developer.

A simple model of the cloud security process

While implementation details, required controls, specific processes, and various reference architectures and design models vary greatly depending on the specific cloud project, there is a relatively simple high-level process for managing cloud security:

• Determine required security and compliance requirements and any existing controls.
• Select your cloud provider, service, and deployment models.
• Define the architecture.
• Evaluate security controls.
• Identify gaps in controls.
• Develop and implement controls to fill gaps.
• Manage change over time.

Because different cloud projects, even from the same vendor, will likely use vastly different sets of configurations and technologies, each project should be judged on its own merits. For example, the security controls for an application deployed on pure IaaS from one vendor may be very different from a similar project that instead uses more PaaS from the same vendor.

The key is to define the requirements, design the architecture, and then identify gaps based on the capabilities of the underlying cloud platform. This is why we need to know the cloud provider and its architecture before we start translating security requirements into controls.

Conclusion

In this article, we began to look at best practices for securing cloud environments. It is important to understand that, depending on the cloud service model you choose, responsibility for the security of various elements of the cloud environment may fall on both the service provider and the client.