The rise of cloud-native apps brought about a number of new cybersecurity challenges. Prior to that, all companies have built their fortress-like structures to secure their centralized data centers. As long as the firewall was able to withstand hackers’ attacks, there was no need for concern regarding the security of the inner parts of the network.

However, now it became obvious that the above approach is outdated. Modern applications are highly distributed and automated. They can be deployed, integrated through APIs, and scaled in a few seconds. Therefore, you need a completely different approach towards securing cloud-native applications.

In order to protect your cloud-native application, you need to implement a proactive approach based on automated and continuous identity-first security controls. This section highlights some best practices that can help you secure cloud-native applications.

1. Understanding Cloud Shared Responsibility

Whenever you start building your cloud-native app, you need to understand the concept of Cloud Shared Responsibility proposed by such cloud providers as AWS, Microsoft Azure, and GCP.

One of the biggest misconceptions regarding cloud computing is that hosting your application in a multi-billion dollar data center will guarantee maximum security.

According to the Cloud Shared Responsibility model depicted above, the cloud service provider is responsible for the safe environment (network and infrastructure). At the same time, the customer remains responsible for identity governance, application source code, API endpoints, container orchestration, and data encryption.

Failure to understand this responsibility model will lead to serious cybersecurity consequences.

2. Adopting Zero-Trust Architecture

As opposed to the traditional security model, in which the users inside the network perimeter were considered trusted, the Zero-Trust Architecture operates under the principle of never trust and always verify. Thus, the location of the user within the network perimeter is irrelevant.

In order to gain access to the information stored in your application, the person needs to pass through the following three stages: identification, authentication, and continuous authorization.

The core principle of the Zero-Trust Architecture is the Identity and Access Management (IAM) with the Principle of Least Privilege (PoLP). It means that access controls should be set up in such a way that minimum possible privileges are granted to human and machine identities.

Role-Based Access Control (RBAC) and Multi-Factor Authentication (MFA) should be applied to all administrative consoles and developer environments. Furthermore, you need to make sure that your application follows zero-trust principles, meaning temporary security tokens should be issued instead of passwords and keys. It will prevent lateral movements made by hackers who have stolen your credentials.

3. Shifting Security Left: Using DevSecOps

According to the traditional approach, security controls were implemented after the development of the application and before its deployment to the production environment. Sometimes, the company was forced to launch the product insecure or unoptimized due to various reasons.

DevSecOps approach is designed to address this issue by shifting security left, which means implementing security controls throughout the software development lifecycle (SDLC). They should be implemented throughout CI/CD pipeline and performed automatically.

Each time when the developer commits his/her changes into the code repository, the following operations are performed:

Static Application Security Testing (SAST): real-time scanning of the source code for software vulnerabilities, logical errors, and unsafe coding practices.

Software Composition Analysis (SCA): scanning of the third-party libraries and packages used within the application for vulnerabilities or licensing issues.

Secrets Detection: scanning of the code files to prevent developers from hardcoding API keys, database connection strings, and cryptographic keys in Git.

Advantages of this approach include early detection of coding mistakes, open-source vulnerabilities, and configuration issues. Moreover, your application will remain protected.

4. Securing Containers and Kubernetes Environment

At the moment, containers and Kubernetes have become a default runtime environment for microservices. However, due to the specific nature of containers, traditional system hardening techniques cannot be applied. In order to secure your containerized application, you should start by securing the container image and runtime environment.

First of all, implement strict container image governance. Instead of pulling base images from public internet registries, use your own private image registry that performs container image scanning to identify vulnerabilities. Use minimalist and lightweight base images such as Alpine Linux or distroless images.

Secondly, by default, any pod in the Kubernetes cluster can freely communicate with any other pod. To prevent the spread of malware in your cluster, apply Kubernetes Network Policies for strict micro-segmentation.

Thirdly, use security contexts of containers to ensure that all microservices running within the container environment are unable to execute commands on the host server node.

5. Securing APIs and Serverless Functions

Application Programming Interface (API) is one of the key components that connect microservices, front-end web applications, and external vendors. Being exposed to the internet, they became the primary target for hackers’ injection attacks, scraping campaigns, and access control violations.

To enhance the security of this particular component, introduce the API Gateway layer that will perform strict rate limiting and payload validation. It will protect against automated Distributed Denial of Service (DDoS) attacks and code injections. Moreover, encrypt all your data flows using the Transport Layer Security (TLS) protocol.

In case of serverless architectures such as AWS Lambda and Azure Functions, host-based security monitoring cannot be applied as the OS environment is managed by the cloud service provider. Thus, strict execution roles should be applied to serverless functions.

For example, if the serverless function writes a file into the bucket, it should not be able to access the production database.

6. Implementing Automated Cloud Security Posture Management (CSPM)

Multi-cloud environment becomes more and more difficult to monitor manually. During the night, a platform engineer may accidentally expose an Amazon S3 storage bucket to the public internet or create overly permissive firewall rules. In order to detect and mitigate such security misconfigurations, Cloud Security Posture Management (CSPM) should be adopted.

These tools operate as security watchdog constantly monitoring your cloud environment via API. They analyze all your cloud resources in real-time and compare them to industry-vetted benchmarks such as Center for Internet Security (CIS), SOC 2, HIPAA, and PCI DSS.

In case of detecting any security misconfigurations (such as unencrypted database backup or routing rule), CSPM will notify you about the problem. Advanced CSPM platforms even have automated self-healing protocols to restore the settings to the known good state.

Frequently Asked Questions (FAQ)

What is the difference between data encryption at rest and data encryption in transit?

Data encryption in transit refers to protection of your data while they are actively transferred over the internet or intranet (credit card details submitted to the server). Data encryption in transit is provided by cryptography transport protocols such as HTTPS or TLS preventing any unauthorized interception of data. On the other hand, data encryption at rest protects your data while they are at rest, i.e., stored in physical hard drives, cloud buckets, or databases. Data encryption at rest is achieved using cryptography algorithms such as AES-256.

How does CSPM differ from CWPP in cloud security?

Although Cloud Security Posture Management (CSPM) and Cloud Workload Protection Platform (CWPP) are cloud security measures, they focus on different aspects. CSPM focuses on the control plane, which implies constant monitoring of your cloud environment for security misconfigurations, compliance risks, and identity issues in such services as storage, networking, and IAM accounts. CWPP, on the contrary, focuses on the data plane, meaning it ensures security in your virtual machines, container pods, and serverless architectures. It provides real-time threat detection, memory protection, vulnerability scanning, and behavioral analysis.

Why do we need secrets management tools like HashiCorp Vault if we use environment variables?

Although using environment variables instead of hardcoding credentials into the application code is already a good practice, storing credentials in regular configuration files still makes them vulnerable to anyone who has access to the server OS, logging console, and source code repository. Thus, secrets management tools like HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault provide a highly encrypted storage for your secrets, granular access control, key rotation automation, and short-lived credential generation.

What is an API gateway and why do we need it?

API gateway acts as a traffic routing layer placed between your internal microservices and client requests. It allows you to abstract away the security concerns from the backend developers of microservices. Instead, the API Gateway deals with all security concerns centrally and provides such functionality as user authentication, transport layer validation, rate limiting, payload verification, and logging.

How does a zero-trust model handle communication between two internal microservices?

Under the traditional network model, if Microservice A was located in the same network as Microservice B, they could freely communicate with each other. However, under the Zero-Trust model, Microservice A is required to present a short-lived identity token (issued by Service Mesh using mutual TLS/mTLS) to Microservice B. Then, Microservice B verifies the token and performs internal authorization check to make sure Microservice A has appropriate permissions to access the particular endpoint.