Checklist for cloud application development. Part 2 – Security Aspects

DevOps FM, vc.ru and get to know YouTube. Different, but interesting and useful content comes out everywhere.

Happy reading!


We manage identification and access control

What is Identity and Access Management (IAM)? (translator's note)

A conversation about security should start with Identity and Access Management (IAM). In fact, IAM is a gateway system: it is a set of practices, technologies and policies for centrally managing access to infrastructure. With IAM, you can ensure that your employees' access rights are only applied as needed (based on their business roles or relationships within the organization).

Setting up authentication

It is important to ask yourself the question: who are our customers?

If we're building an application that will serve internal clients (i.e., company employees), we need to ensure that our application can sync identities from our identity provider (IdP).

On the other hand, if our application will be used by external clients, then in most cases we will not manage identifiers ourselves, but will allow authentication based on SAML, OAuth or OpenID connect and will manage authorization in our application.

Examples of managed cloud identity services include AWS IAM Identity Center, Microsoft Entra ID, and Google Cloud Identity.

Setting up authorization

Content Security Policy (CSP) is a web application security standard. It allows you to control where the browser can load resources (for example, scripts or design elements). CSP helps protect against cross-site scripting (XSS) threats or unwanted code injection (injection).

When our application uses services from the CSP ecosystem (storage, databases, etc.), each CSP has its own mechanisms for managing permissions to access services and actions and its own way of implementing RBAC – role-based access control.

Important: Regardless of the built-in mechanisms for using the cloud infrastructure, we must always follow the principle of least privilege (i.e. minimum permissions).

At the application level, we need to develop an authorization mechanism that will check each identity that is authenticated in our application against the authorization mechanism. Here we will need interactive authentication, non-interactive authentication or even API based access.

Of course, you can manage authorization using the RBAC mechanism you developed. However, the time has come to consider those authorization policy mechanisms that correspond to the cloud native concept. For example, Open Policy Agent (OPA). This is an open source project that is part of the landscape CNCF. The main advantage of OPA is that its mechanism is not limited to authorization in the application. This means you can use it for authorization in Kubernetes, for Linux (using PAM), and much more.

Policy-as-Code

What is politics? (translator's note)

Let's clarify the term “policy”. In the context of this article (and the IT field in general), a “policy” is any type of rule, condition, or instruction that governs IT operations or processes. A policy can be a rule that specifies what conditions must be met, for example, for code to pass security checks and be deployed. Or it can be a set of procedures that are executed automatically in response to a security event.

Policy-as-code (PaC, Policy as Code) is an approach to policy management in which policies are defined, updated, shared, and enforced using code. Policy-as-Code allows customization guardrails (protective barriers) for different aspects of your application's workload.

Each cloud provider has its own security system. It goes beyond the cloud account and affects the configuration or maximum allowed resource consumption.

Some examples of barriers:

  • Limiting the permissible region for deploying resources (computing, storage, databases, networks, etc.);

  • Forced encryption in standby mode;

  • Prohibition on creating public resources (for example, virtual machines with a public IP);

  • Using virtual machine instances only of a certain size (i.e. limiting the number of processors and memory amounts).

For automation purposes, security barriers can also be applied as part of a CI/CD pipeline when deploying resources with Infrastructure as Code. The IaC code is checked before the actual deployment phase, and if it does not violate Policy-as-Code, then the resources are updated.

Examples of PaC include AWS Service control policies (SCPs), Azure Policy, Google Organization Policy Service, HashiCorp Sentinel, and Open Policy Agent (OPA).

Protecting data

Almost every application contains valuable data, from documents to personal data, so we must protect it from unauthorized access.

One of the most common methods of protection is encrypted storage:

  • Encryption during transmission: Carried out using protocols such as TLS (latest version is 1.3).

  • Encryption of data at rest: Performs at the volume, disk, storage, or database level using AES-like algorithms.

  • Encryption while in use: executed using a hardware device that supports TEE (Trusted Execution Environment), which is also called confidential computing.

When encrypting data, we need to take care of key generation, secure storage for storing them, retrieving them, and destroying them. All major CSPs have their own management services at all stages of the key life cycle.

If you are deploying your application based on the infrastructure of one content protection policy, then it is better to use the managed services that this policy offers.

For in-use encryption, choose services that support confidential computing, such as virtual machine instances or Kubernetes worker nodes.

Managing secrets

Secrets are static credentials that allow you to access services and resources. Examples of secrets are API keys, passwords, database credentials, etc.

Secrets, like encryption keys, are confidential and must be protected from unauthorized persons. Therefore, even at the first stages of designing an application, you need to choose a safe place to store secrets.

All major CSPs have their own secrets management services that manage the entire lifecycle of secrets.

As part of your CI/CD pipeline, it's worth implementing an automated scanning process to detect secrets embedded in code, scripts, and configuration files to avoid storing secrets outside of secure storage.

Examples of secrets management services include AWS Secrets Manager, Azure Key Vault, Google Secret Manager, and HashiCorp Vault.

Protecting the network

Applications must be secured at the network level, whether you expose the application to internal clients or to clients over the public Internet.

The main way to protect infrastructure at the network level is to use access control tools, which in our case are third- or fourth-level firewalls.

What is a firewall? (translator's note)

A firewall (firewall, firewall) is a kind of network shield, a program that filters incoming and outgoing traffic, allowing only safe data through, and blocks suspicious information. The third level firewall (L3 firewall) provides packet filtering based on information about IP addresses, subnet masks and routes and is designed to protect the network from external threats and control access to network resources. And the fourth layer firewall analyzes the headers of the TCP, UDP and ICMP protocols. It checks IP addresses and ports, as well as services provided based on these protocols. L4 firewall uses stateful inspection technology to remember and store the state of requests, which allows the necessary response connections to be allowed.

All CSPs have access control mechanisms to limit this access to services (virtual machines, databases, etc.).

Examples of L3 and L4 managed services are AWS Security groups, Azure Network security groups, and Google VPC firewall rules.

Some cloud providers support private access to their services by adding a network load balancer to the various services with an internal IP address from the client's private subnet. This way, all traffic will flow inside the CSP backbone and not through the public Internet. Some private connectivity solutions to consider include AWS PrivateLink, Azure Private Link, and Google VPC Service Controls.

Some content security policies offer managed layer 7 firewalls.

What's good about a Layer 7 firewall? (translator's note)

L7 Firewall is an advanced type of firewall that operates at the application layer of the OSI model. It provides greater security and control over network traffic by filtering data based on packet content, including application protocols such as HTTP, FTP and SMTP. This firewall provides port management, traffic filtering, and security capabilities using SSL and TLS protocols.

Examples of Layer 7 firewalls include AWS Network Firewall, Azure Firewall, and Google Cloud NGFW.

Protecting applications

Any application is susceptible to attacks. There are many types of attacks: injection of malicious code (injection), data leaks, data falsification, unauthorized access and many others. Whether you're using an API, a web app, or a mobile app, it's important to implement application-level protection such as a web application firewall. All major CSPs offer managed WAF services. There are also many SaaS solutions from commercial providers.

What is WAF? (translator's note)

WAF (Web Application Firewall) is a set of monitors and filters designed to detect and block network attacks on a web application.

Examples of managed WAF services include AWS WAF, Azure WAF, and Google Cloud Armor.

We protect ourselves from DoS and DDoS attacks

Every web application has the risk of being subject to a DoS (Denial of Service) or DDoS (Distributed DoS) attack.

Why are DDoS attacks dangerous? (translator's note)

DDos attacks represent bOgreater threat since they are distributed and directed at a single target host. They can cause serious problems with the availability of web resources and lead to financial losses (and sometimes even reputational ones).

You again have 2 options: CSP-offered DDoS protection or solutions from private providers. Examples of managed DDoS protection services include AWS Shield, Azure DDoS Protection, Google Cloud Armor, and Cloudflare DDoS protection.

Managing patches

Software is usually vulnerable and therefore needs to be patched regularly.

For applications deployed on virtual machines:

  • create a “golden image” of the virtual machine and regularly update its security system and software;

  • set up a process for regular patch releases.

For containerized applications, you also need to create a golden image of each application component and update it regularly.

Be sure to implement tools (SCA).

What is SCA? (translator's note)

SCA (Software Composition Analysis) is an automated process of scanning software to detect open source code (OSS) and then checking for vulnerabilities, obsolescence, and licensing issues. This analysis helps monitor the security of components used, monitor third-party libraries, and develop policies for open source software

If vulnerable components or their dependencies are discovered, you can begin the process of replacing them in a timely manner. Examples of patch management solutions include AWS Systems Manager Patch Manager, Azure Update Manager, and Google VM Manager Patch.

We comply with legal and regulatory requirements

Regulatory compliance is an important security factor when developing an application.

Often applications contain personal (also called PII – personally identifiable) information about employees or clients. Interactions with personal data must comply with privacy and data retention laws and regulations (e.g. GDPR in Europe, CPRA in California, LGPD in Brazil, etc.).

What laws in Russia regulate actions with personal data? (translator's note)

In Russia, regulation is carried out using a number of legal acts: No. 152-FZ “On Personal Data”; No. 149-FZ “On information, information technologies and information protection.”

Some organizations choose to meet high industry standards and follow security best practices, such as the Center for Internet Security (CIS) set of recommendations for tuning a wide range of Benchmark software to improve the reliability of infrastructure components. You can assess the level of security using, for example, Cloud security posture management (CSPM) solutions.

What is CSPM? (translator's note)

Cloud security posture management (CSPM, cloud security posture management) is the process of managing security in a cloud environment. It helps organizations identify and mitigate security risks associated with misconfigured public cloud services. CSPM uses a variety of tools and techniques for risk assessment, visualization, incident response, compliance, and security monitoring in the cloud.

By the way, our team can help you set up CSPM.

We respond to incidents

When developing an application in the cloud, it is important to be prepared to quickly respond to potential emergencies. To do this, you need to create an organized SOC.

What is SOC? (translator's note)

SOC (Security Operations Center) – security center. It brings together people, processes and technology to reduce risk and improve an organization's cybersecurity. The SOC consists of a team of security experts who monitor, analyze, prevent cyber threats and respond to confirmed incidents.

We advise you to follow the following recommendations:

  • Enable logging of changes to both infrastructure and application components and submit all logs to a central log aggregator. Ensure that logs are stored in a centralized, immutable repository with limited access rights for the SOC team. Choose a tool that allows you to view logs, detect anomalies, and create actionable analytics for your SOC.

  • If necessary, take care to increase the level of competencies for the SOC team you have formed. For example, you can develop training manuals that outline next steps after an incident has occurred.

  • Create automated solutions that allow you to quarantine affected services in the event of a catastrophic event (such as a network breach or ransomware infection) and deploy a new environment from scratch.

Summarize

In the second article in this series, we covered many of the security aspects that companies should consider when developing new cloud-native applications. We recommend using this checklist as a base and constantly supplementing and improving it when documenting your projects.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *