Cloud security for beginners with video's

Welcome to the session. I'm excited to help you dive into cloud security, and we'll definitely make sure to weave in some great video-based learning resources along the way.

To make sure we tailor everything perfectly to your needs, are you completely new to IT and cybersecurity, or do you have some technical background that you are hoping to build on?

I have some IT background but I'm new to cloud security

It is great to have you here! Since you already have some IT experience, you will likely find that many networking and security concepts carry over, though the cloud definitely introduces its own unique spin.

Your path

Cloud Deployment and Service Models

Key Security Tools and Practices

Getting Started: Learning Resources

What is Cloud Security?

To understand cloud security, it helps to look at it as a perfect intersection of two major fields. Think of a Venn diagram: on one side, you have (running infrastructure on platforms like AWS, Azure, or Google Cloud). On the other side, you have (the practice of protecting systems and data from unauthorized access or damage). When those two worlds collide, you get cloud security. At its core, it is the collection of technologies, protocols, and best practices designed to protect your data, applications, and virtual infrastructure inside those public or private cloud environments.

A Venn diagram showing the overlap between Cloud Computing and Cybersecurity.

I've started sketching out a quick visual diagram to help map this overlap. While that's generating, let's look at why learning this is so crucial right now. Because the cloud is dynamic, scalable, and accessible from anywhere, it is incredibly easy for an administrator to make a tiny error—like leaving a database open to the public internet—that leads to a massive breach. Companies are desperate for professionals who know how to prevent these misconfigurations before they happen.

Continue to the Shared Responsibility Model

Whose Job Is It Anyway?

When companies move to the cloud, a dangerous misconception often crawls in: "The cloud provider is a massive tech giant, so they will handle all of my security." In reality, securing the cloud is a team sport. This division of labor is governed by a framework called the . If you do not understand where the provider's job ends and yours begins, you are highly likely to leave a virtual door unlocked.

The Shared Responsibility Model split vertically into customer and provider domains.

A simple, memorable way to split this up is to think about security of the cloud versus security in the cloud.

Security OF the Cloud (The Provider's Job): The provider (like AWS, Azure, or Google Cloud) is responsible for the physical security of the datacenters. They lock the physical gates, protect the concrete buildings, and secure the actual host computer hardware, virtualization software, and physical cables.
Security IN the Cloud (Your Job): You are responsible for everything you put inside their infrastructure. This includes locking down your operating systems, managing who gets user accounts, writing secure code, and encrypting your data.

If you store highly sensitive data in a cloud folder and leave it open to the public internet, the provider did not fail you—you failed to secure what was inside your boundary. Let's look at how this line moves depending on what type of cloud service you are using.

Explain how this boundary shifts with IaaS, PaaS, and SaaS. (Continue)

To understand how the boundary of the shifts, we have to look at the three main pillars of cloud computing: , , and . Think of this progression like moving from renting an empty apartment where you have to bring all your own furniture, to staying in a fully furnished hotel room where everything is managed for you.

A three-column vertical stack diagram comparing customer and provider security responsibilities across IaaS, PaaS, and SaaS models.

I have updated our running diagram to show how this works visually. In IaaS (Infrastructure as a Service), you get the most control, which means you have the most security responsibility. The provider secures the physical server, but you must patch the operating system and lock down your virtual network. In PaaS (Platform as a Service), the provider takes over the operating system, database engines, and runtime. Your responsibility shrinks down to securing your custom application code and managing who has access to it. In SaaS (Software as a Service), the provider manages almost everything. Your primary job is protecting your data and making sure your user accounts have strong password policies and multifactor authentication turned on.

Give me an example of an IaaS vs. SaaS security failure

To see the shared responsibility model in action, let's contrast two classic, real-world horror stories: one where an organization failed to protect its Infrastructure as a Service () resources, and another where they dropped the ball on their Software as a Service () setup.

The IaaS Nightmare: The Unlocked Storage Bucket

Imagine a major financial firm that rents raw, virtual storage folders in the cloud to house millions of credit card applications. This is a classic IaaS setup. Because of a hasty deployment, a network administrator forgets to toggle a basic security check, leaving a massive storage folder—known as an —configured to allow access to "All Users." An attacker running a simple, automated internet scanner stumbles upon this bucket, views the unprotected folder, and downloads millions of private customer files. In this scenario, the cloud provider's hardware and network functioned perfectly. The security failure was entirely a customer misconfiguration. The door was built securely, but the customer left it wide open.

The SaaS Nightmare: The Executive Account Takeover

Now, let's look at a SaaS example, like an enterprise email suite. A company's CFO uses this cloud email service to discuss highly confidential quarterly earnings.

Because the company does not enforce strict security policies, the CFO never sets up Multifactor Authentication () on their account. An attacker uses a basic email to trick the CFO into entering their password on a fake login page.

Armed with the password, the attacker logs right in, accesses sensitive financial documents, and orchestrates a fraudulent wire transfer.

Here, the SaaS provider kept the email servers patched, secure, and physically locked down. The breach occurred because the customer failed to protect the keys to the kingdom: user identity and access.

Who Cleans Up the Mess?

When comparing the fallout, the difference in impact and remediation responsibility highlights the shift in your daily duties as a cloud security specialist:

In the IaaS scenario, you are responsible for the entire mess. You must immediately update the bucket policies, run a forensic audit on your virtual servers to see what else was touched, and patch any other public-facing configurations.
In the SaaS scenario, your remediation is limited to your user access policies. You must force a password reset, immediately mandate MFA across the organization, and audit user login logs. You cannot patch the email software itself; you can only control who has permission to use it.