Cloud Security: Who’s Responsibility Is It?

This content originally appeared on DEV Community and was authored by Michael Levan

Just about every organization in some way, shape, or form is running a piece of its core infrastructure in the cloud. Whether it’s mail, virtual machines, containers networks, or various application stacks, it’s in the cloud.

The question is; how can anyone secure a moving target?

Under various cybersecurity specialties, whether you’re more on the offensive teams or more on the defensive teams, is cloud security. Cloud isn’t new, but it’s definitely clear that there’s more and more of a need to properly secure cloud-based technologies.

In this blog post, you’ll learn about what part of the cloud you (as the engineer) are responsible for and how you can begin to secure your cloud environment now.

Shared Responsibility Model

The first step to truly understanding how security works in the cloud is to understand what you are responsible for and what the cloud provider (Azure, AWS, GCP, etc.) is responsible for.

The key difference is responsibility comes down to physical vs virtual.

In the cloud, you don’t manage physical equipment. Datacenters, network equipment, servers, etc. are all managed by the cloud provider.

You are, however, responsible for everything else. The second you log into the cloud portal, start working with the SDK, or use the cloud provider's CLI, it is your responsibility. Every service, VM, container, network, and port you create/update/change/modify/use is the engineers responsibility. This even goes down to the regional level. For example, let’s say a region goes down. You may think “That’s the cloud provider's fault”, but it’s not because you can set up multi-region architecture.

Here’s a great diagram from AWS (it’s the same in every cloud) to give you a visual.

Source: https://d1.awsstatic.com/security-center/Shared_Responsibility_Model_V2.59d1eccec334b366627e9295b304202faf7b899b.jpg

Where The Worlds Collide

On paper, this makes sense. You manage everything that’s “virtual” (or at the software level depending on how you look at it) and the cloud provider manages the “physical”. The problem is that it’s still running on someone else's networking equipment.

In August of 2024, there was a massive Azure outage that impacted a lot of Services throughout regions. It even impacted the Azure Portal itself. This outage was due to a DDoS attack. With that being said, it doesn’t matter how good your security is for what you are responsible for in an instance like this.

As with everything tech-related that you’re relying on a provider for, you have to roll the dice and mitigate as many of the risks as possible (in this instance, think hybrid cloud).

Securing Cloud Environments

It’s ridiculously easy to create a cloud environment that’s not secure.

Two examples are:

1. Public endpoints are easy to create.
2. Clicking “next” is easy.

The first example is public endpoints.

💡 Please note these two things aren’t the only two things that are insecure in the cloud. They are just the easiest to talk about as an example as they’re the most related.

When you create any cloud-based service from a Managed Kubernetes Cluster to a VM to a container, with a simple click of a button (or no click at all because it’s on by default), your architecture is now public-facing. That means from anywhere in the world, it can be reached. A simple WAN scan along with some vulnerability scanning with nmap can give you the IP, ARP address, hostname, and open ports. On-prem, it’s way harder to get a public IP address associated with a piece of architecture.

The second example is creating resources.

Just about everyone starts off in the cloud by clicking next through some portal options to create a service/resource/architecture. This is good and bad. It’s good because it makes creating resources easy. It’s bad because it makes creating resources easy. As an engineer, you almost don’t have to think, and the default options are usually the worst.

As the great Abel Wang has said…

With all of that in mind, what can you do to secure the cloud? If you Google around, you’ll find a lot of answers to this question. In fact, there will be long lists of what you can do to secure the cloud. For example, here’s a great one from CrowdStrike.

The problem with these lists is that they’re typically lengthy, take time, and are confusing for engineers who aren’t fully aware of the cloud.

So, what’s the answer?

Get educated.

It’s not simple or easy to do, but the answer is simple. You must educate yourself on cloud-based technologies. Luckily, there are a few entry-level certifications that’ll help. Even if you don’t get the certification, obtaining the knowledge will help a ton.

For AWS: Cloud Practitioner.

For Azure: AZ-900.

For the rest of the blog post, let’s learn about some key best practices that you can implement right now along with answering some compliance questions and questions on what tools are available to secure cloud architecture.

Compliance Measures In The Cloud

The major public clouds today have Government clouds and all of the compliance needs that you’ll most likely need to run your systems and software without compromising any standards that your organization has set.

Azure’s list of compliance: https://learn.microsoft.com/en-us/azure/compliance/

AWS’s list of compliance: https://aws.amazon.com/compliance/programs/

Top 5 Cloud Security Best Practices

A list of security best practices could be hundreds (or maybe thousands) of options. Because of that, let’s think about five primary security best practices that you can think about with the least amount of resistance.

1. Public Servers

By default, it’s incredibly easy to make a server, container, Kubernetes cluster, or application-based service public. It’s either a simple button click or it’s just one by default, so you don’t even have to worry about it. However, you should worry, because anything that’s public facing should always be checked. Essentially, unless it’s a web app, there are rarely (not always, just rarely) any reasons to have anything sitting on the public internet.

1. Authentication and Authorization

Authentication (any type of logon) and authorization (permissions that you have once logged in) are some of the easiest targets for bad actors in the cloud. The reason why is that much like a lot of insecure attributes of the cloud, it’s simple to give someone admin access and completely forget about it. IAM Roles and Policies within cloud providers can also be pretty convoluted, so what ends up happening is engineers test resources, they need to confirm if access is the issue, give full access, fix the issue, and then forget to take away the full access.

Ensure that IAM is configured properly.

1. System Hardening

Hardening a system, whether it was an Operating System, a server, or a hypervisor has always been available. In the cloud, it’s no different. There are various hardening guides for systems running in the cloud. There are also CIS-based hardened AMIs (if you haven’t heard the term AMI, they’re like Golden Images) that you can use in your cloud provider of choice.

1. Network Security

Much like the issue with IAM, it’s incredibly easy for an engineer to create a Security Group within a cloud provider that says “Allow all traffic in from everywhere”. In fact, the external Security Group rules are typically set to * by default.

Ensure that the rules configured within your Security Group (they are firewall rules) are set up in a secure fashion and that ingress/egress is configured only for what needs to be let in or out (defense in depth is important).

1. Isolation

Because the cloud portal simply feels like one location to “do all of the things”, every once in a while (and by that, I mean a lot) you’ll see Dev environments mixed with Staging environments and Dev environments mixed with Production environments. The days of “Prod is on this server and Dev is on this server” are pretty much behind us because it’s all in one cloud portal.

The best way to combat this is to have a few different accounts.

Many organizations have three cloud accounts. One for Dev, one for Staging, and one for Prod. By three cloud accounts, I mean, for example, it’s all on AWS, but it’s three separate accounts.

Cloud Security Tools

There are a lot of security-based tools that help in the cloud and are not vendor-specific. For example, Splunk is a great SIEM solution that’ll work across all cloud providers. Pentest tools like Burp Suite will help find vulnerabilities in web apps regardless of what cloud they’re running on. CIS Benchmarks have reports for each cloud provider to ensure best security practices.

Let’s dive into a few tools that help within each cloud specifically. Chances are if you’re running in one cloud, you may want to take advantage of the security tools they offer to keep everything in one location. Cloud providers actually have some great security tool options, so even if you want to “diversify” where your tools exist, it’s still good to know what cloud-based security tools are available.

💡 All of the major clouds have the “standard” security configurations. Firewalls, identity, RBAC, VPN, harden postures, etc… The below services are security services that aren’t the standard.

AWS

Here are a few AWS tools for security.

1. WAF: Web Application Firewall.
2. Security Hub: Cloud security posture management (CSPM).
3. GuardDuty: Continuously monitors and analyzes CloudTrail S3 data events
4. Inspector: An automated vulnerability management service that continually scans AWS workloads
5. SecurityLake: A data lake that enables organizations to store, manage, and analyze security-related data at any scale
6. CIS Hardened Images: Hardened AMIs with security best practices.

Aside from tools, AWS has three levels of security model architecture that can help you build out environments: https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-accelerating-security-maturity/choosing-a-security-model.html

AZURE

Here are a few Azure tools for security.

1. CIS Hardened Images: Hardened AMIs with security best practices.
2. Microsoft Defender For Cloud: Native CSPM capabilities for Azure, AWS, and Google Cloud environments and supports threat protection across these platforms
3. Azure Active Directory: Just like regular Active Directory, but managed in Azure and it’s way easier to use in terms of availability for multiple services, on-prem resources, and even other clouds.
4. Sentinel:

Aside from tools, Azure also has a security component in the Cloud Adoption Framework: https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/secure/

This content originally appeared on DEV Community and was authored by Michael Levan