Skip to main content

Cloud Security Architecture - Secure by Design

Written by:
0 mins read

What is cloud security architecture?

Cloud security architecture is the tools and practices that make up a secure cloud platform design and configuration. Cloud architects are tempted to focus on performance and apply security afterward, but adopting cloud security architecture instead builds cloud security into platforms from the bottom up. Two core principles it builds on are shared responsibility between cloud providers and customers and zero trust.

The leading cloud platforms like Amazon Web Services (AWS), Google Cloud (GCP), and Microsoft Azure have thousands of security professionals working to secure their public cloud infrastructure around the clock, but they are not solely responsible for securing cloud deployments. While cloud providers have a certain degree of responsibility for ensuring that data and workloads running on their servers are secure, much of the risk around cloud computing is the cloud customer’s to manage.

In the traditional data security model, organizations had full control over their IT infrastructure. Security was focused on bolstering the perimeter of the network, and all users and systems inside the network were considered to be trustworthy. This approach breaks down when working in the cloud  , and is exasperated with hybrid and multi-cloud environments. This change introduces the need for an inherently-secure cloud architecture.

In this post we’ll break down what cloud security architecture means and why it’s relevant to cloud native developers.

Why is cloud security architecture important?

An effective cloud security architecture is important because it allows organizations to maintain a security posture whilst moving fast and adding new capabilities in the cloud. Due to the rapid nature of modern development techniques and the complex nature of cloud environments, it’s not feasible to wait until applications are running in production to secure them. By applying cloud security architecture best practices, organizations can build cloud native applications in an efficient way while ensuring a strong security posture.

Cloud security architecture challenges

A well thought-out cloud computing security architecture should account for the following challenges:

Insider threats

Organizations should ensure that employees and stakeholders with access to cloud environments are properly vetted and trained before being given access, and access should be tightly governed. Cloud environments can be vulnerable to attacks from a malicious employee, or through employee negligence leading to stolen credentials or misconfiguration mistakes.

Control Plane Compromise

The cloud control plane is the collection of APIs that a cloud service provider like Amazon, Google or Microsoft provides to developers so they can configure and control the cloud environments they work in every day. Once a hacker gains a foothold in a cloud environment, it's the API keys that enable them to operate against the cloud provider's API control plane that they're really after. These API keys let them discover knowledge about the environment, move laterally, and find and extract data while evading detection by security tools.

DoS attacks

Denial of service (DoS) attacks are threats to the availability of data and applications. An attacker may not be able to access or modify data, but if they can make systems or data unavailable to you or your customers, they can deny you the ability to run core business operations.

DoS attacks come in temporary and permanent forms. Temporary distributed denial of service (DDoS) attacks happen when attackers overwhelm a system with requests. They can be deflected using network compliance policies. Permanent DoS attacks damage hardware to render servers inoperable and require technicians to physically rebuild the system from scratch.

Customer control

Data and workloads running in cloud services present challenges around visibility and control. Cloud providers don’t always provide detailed information about how to enforce controls on their cloud, so customers’ internal controls may not translate to cloud controls. This can result in a patchwork of controls used for internal devices, networks, and cloud resources, which can mean poor visibility and the risk of a potential breach or loss of data.

Shared responsibility for cloud security architecture

Modern cloud providers work on a shared responsibility model. Providers and customers are each responsible for the cloud aspects they own. Cloud providers typically are responsible for backend security starting with the physical security of the data center itself, while customers are responsible for the secure use of cloud services, starting with user devices and access controls.

Let’s consider how shared responsibility breaks down for three of the most common models for cloud computing:

Software as a Service (SaaS)

Platform as a Service (PaaS)

Infrastructure as a Service (IaaS)

The provider is responsible for everything from application security down to the physical infrastructure, while customers are responsible for securing user access.

Here the customer is again responsible for user access and data security, and they also assume responsibility for the applications they run on the cloud provider’s platform. The provider is responsible for securing layers between operating systems down to the physical infrastructure.

Providers are responsible for securing infrastructure and the virtualization middleware that IaaS customers use. Customers are responsible for securing virtual machines or operating systems, applications, traffic, and data.

Most enterprises are now using multiple public clouds to leverage the unique advantages of different cloud service providers, which means they have increasing responsibility for monitoring and securing applications and data across clouds.

What are the key considerations for cloud security architecture?

Some of the key considerations of a cloud security architecture are security by design, cloud native application security, shift left, automation, cloud compliance, cloud visibility, and multi-cloud management.

Let’s take a deeper look into each of these:

Secure by design

Security considerations are built into cloud security architecture so they can’t accidentally be bypassed in case of misconfigured policies. For example, identity management should be centralized and role-based access controls should be used for each interaction with a cloud resource, this can also help protect against control plane compromise.

Cloud native application security

One of the benefits of deploying applications on the cloud is the agility and scalability it enables. The cloud security architecture should ensure that security tools and techniques do not get in the way of agile releases or introduce roadblocks in the deployment process. Otherwise, development or operations teams will be incentivized to skip or overlook security steps.

Shift left

Shift left is a modern application security approach. Instead of waiting until applications are running in production, shift left integrates security testing as early as possible in the development process. With over 50% of DevSecOps practioners reporting they use some form of infrastructure as code (IaC) to deploy workloads, it’s important to test both applications and infrastructure as early and as often as possible during development, rather than waiting until the application is running in production.

Automation

Security updates, controls, and configurations should be automated using code to allow developers and security teams to automatically uncover and respond to threats to cloud native applications and data.

Cloud compliance

Regulators are tightening up laws around cloud data and processes. Cloud security architecture needs to incorporate government regulations as well as industry or organizational standards into cloud architecture to ensure their responsibilities are met.

Cloud visibility

Hybrid and multi-cloud deployments present challenges to visibility. Traditional security solutions often are incapable of monitoring and managing security across cloud-based infrastructure, so an effective cloud security architecture should include techniques and technologies for gaining visibility over hybrid or multi-cloud deployments.

Multi-cloud management

Organizations increasingly are using multiple cloud providers, each with its own configuration settings and built-in security tools. Managing multi-cloud deployments puts additional strain on already overworked developers and security teams, so the cloud security architecture must help unify the management of the cloud security solutions from each of their cloud providers.

How Snyk can help secure your cloud environments

The cloud is often referred to as a data center, but in practice it is software. What used to be infrastructure is now part of applications, which means that securing cloud applications requires moving responsibility from IT and operations into application security. Cloud native security needs to start with developers, so they can focus on delivering software that meets business goals while ensuring that code is secure. Snyk offers numerous tools that help developers as they secure the infrastructure and containers in which their applications run.

Shift left & DevSecOps principles

Snyk’s cloud native application security platform integrates security for applications, platforms, and infrastructure into the development pipeline, with continuous monitoring for new vulnerabilities. This platform facilitates DevSecOps practices since it removes burdensome review cycles where security teams uncover bugs in production and circle back to development teams. With security built into the development process from the start, security teams won’t have to ask for extra features or auditing from developers after the fact, since they will know these are built in from day one.

Snyk IaC

Snyk IaC eliminates tedious, error-prone manual reviews by allowing developers to secure infrastructure configurations as they are written and deployed. It includes built-in policy as code rules and allows custom rules leveraging Open Policy Agent (OPA).

Container Security

Snyk Container allows developers to secure the container layer during development and in production. It helps eliminate vulnerabilities with automated base image recommendations and upgrades. Snyk’s recent partnership with Sysdig extends our ability to scan and remediate container vulnerabilities into the runtime environment.