Cloud Security Fundamentals: A Beginner's Guide

What is cloud security?

Cloud security is the set of practices, controls, and technology that protect data, applications, and infrastructure hosted on platforms like AWS, Microsoft Azure, and Google Cloud from unauthorized access, misconfiguration, and data loss. It differs from traditional on-premises security in one key way: the work is split between the cloud provider and the customer, and knowing exactly where that line falls is the first skill every beginner needs to build.

If you're moving to the cloud, or you're just starting to think about security in a cloud-focused role, this guide is for you. No jargon overload, no assumption that you already know what a security group is. Just the fundamentals that matter, the first action to take for each one, and the mistakes that trip up almost everyone in their first few months.

The shared responsibility model

This is the most important concept in cloud security. Miss it, and everything else falls apart, because most cloud security incidents aren't caused by the provider getting breached. They're caused by the customer misconfiguring their own side of the split.

The cloud provider secures: the physical infrastructure, hardware, networking equipment, and the virtualization layer underneath your account.

You secure: your data, your applications, who has access to them, your network configuration, and, depending on the service, the operating system running your workloads.

Think of it like renting an apartment. The landlord maintains the building, the wiring, and fire safety. You're responsible for locking your own door and deciding who gets a copy of the key.

How the split shifts across IaaS, PaaS, and SaaS

The responsibility line isn't fixed. It moves depending on whether you're using infrastructure as a service (IaaS), platform as a service (PaaS), or software as a service (SaaS). The more the provider manages for you, the less you own directly, but you never stop owning your data or who can reach it.

This breakdown matches how the major providers describe it themselves: see AWS's shared responsibility model, Microsoft's Azure shared responsibility documentation, and Google Cloud's shared responsibility and shared fate framework. The wording differs slightly between them, but the underlying split is the same.

The five pillars of cloud security

Once the shared responsibility model clicks, cloud security breaks down into five practical pillars. Each one gets a single beginner action below, something you can do today before you learn anything else about that pillar.

1. Identity and access management (IAM)

In the cloud, identity is your first line of defense, not the firewall. If someone has valid credentials, the platform treats them as legitimate. There's no physical perimeter standing in the way.

Key concepts

• Authentication: proving who you are
• Authorization: what you're allowed to do once you're in
• Principle of least privilege: give every user and service only the access they need, nothing more

Practical steps

1. Enable MFA everywhere, especially for admin accounts. On Microsoft Entra ID (Azure AD), Conditional Access policies let you enforce MFA selectively based on user risk, location, and device compliance, far more effective than a blanket MFA rule.
2. Don't use root or owner accounts for daily work. Create individual admin accounts and reserve the root account for emergencies only.
3. Use groups, not individual permission grants. It's easier to audit and far easier to revoke.
4. Review access on a schedule. People change roles and leave companies, and their old permissions don't clean themselves up.

Beginner first step: enable MFA on every admin and owner account today. Microsoft has reported that MFA blocks more than 99.9% of automated account-compromise attempts, which makes it the single highest-leverage control in this entire guide.

2. Network segmentation

Your cloud resources live inside virtual networks, a VPC in AWS or a VNet in Azure. Think of it as your own private, walled-off section of the provider's infrastructure.

Put public-facing resources, like a web server, in a public subnet. Keep databases and internal services in a private subnet that has no direct route to the internet.

Security groups and firewalls

These control what traffic can actually reach your resources. Default stance: deny everything, then allow only what's specifically needed. Starting from allow-all and locking it down later almost never works, someone forgets to close a rule.

Beginner first step: restrict every management port (SSH on 22, RDP on 3389) to a known IP range, never to 0.0.0.0/0. If you need occasional remote access, use a bastion host, a VPN, or your provider's just-in-time access feature instead of leaving the port open permanently.

3. Data protection and encryption

Encryption at rest

Data sitting in storage should be encrypted. Most cloud storage, disk, and database services turn this on by default now, but default doesn't always mean enabled for every resource type or every region, so verify it rather than assume it.

Encryption in transit

Data moving across a network should be encrypted too: HTTPS for web traffic, TLS for database connections, and an encrypted VPN or private link for anything crossing between your network and the cloud.

Backup strategy

Follow the 3-2-1 rule: 3 copies of your data, on 2 different storage types, with 1 copy stored offsite, a different region or a different provider entirely. For ransomware resilience specifically, make at least one of those copies immutable, using something like Azure Immutable Blob Storage or AWS S3 Object Lock, so it can't be deleted or encrypted even by an attacker holding valid credentials.

Beginner first step: confirm that encryption at rest is actually turned on for every storage account, disk, and database you create, and that at least one backup copy is immutable. Don't assume the provider's default covers you: check the setting.

4. Logging and monitoring

You can't protect what you can't see. Logging is the pillar beginners skip most often, because it produces no visible benefit until the day it's the only thing standing between you and a guess.

What to log

• Authentication events, both successful and failed logins
• Authorization changes, who was granted or lost access
• Data access, especially for sensitive resources
• Configuration changes, especially to network and security settings

Basic alerts to configure

• Any use of the root or owner account
• Multiple failed login attempts on the same account
• Changes to security group or firewall rules
• Access from unusual or unexpected geographic locations

Beginner first step: turn on your cloud provider's native audit log (AWS CloudTrail, Azure Activity Log, or Google Cloud Audit Logs) before you do anything else in a new account. It's usually a single toggle, and it's the setting beginners most often discover was off only after they needed it to reconstruct what happened.

5. Incident response

Even as a beginner, you need a plan for what happens when, not if, something looks wrong. You don't need a formal 40-page runbook on day one. You need to know three things before an alert ever fires: who you tell, how you cut off access, and where the logs live.

• Write a one-page plan covering those three questions, then keep it somewhere you can find under pressure
• Isolate first, investigate second: revoke the credential or quarantine the resource before digging into root cause. Containment buys you time
• Practice it informally. Talk through a single scenario with your team, such as an admin account showing a login from an unexpected country, rather than waiting for a full tabletop exercise
• Know your cloud provider's security or abuse escalation contact before you need it

Beginner first step: write that one-page plan today. Even a rough version beats improvising during an actual incident.

Common mistakes beginners make

These show up constantly in real cloud accounts, often within the first month of use.

Assuming the cloud provider secures everything. This is the single most common misunderstanding in cloud security, and it comes directly from skipping the shared responsibility model above. The provider secures the infrastructure underneath your account. It does not patch your operating system in IaaS, configure your firewall rules, or decide who has access to your data. If you take nothing else from this guide, take that line.

Overly permissive IAM by default. New accounts, roles, and service principals are easy to create with broad permissions and hard to trim back later, so most people never do. Wildcard permissions, Owner or Contributor roles handed out by default, and API keys with far more scope than the calling application actually uses are all the same mistake: it's faster to grant everything once than to scope it correctly, until the day it isn't.

Not enabling logging until after an incident. This is the pillar 4 mistake in practice. Logging costs nothing to turn on and very little to store, but it's invisible until you need it, so it's the setting new cloud accounts skip most often. Without it, a post-incident investigation has almost nothing to work with: no record of who logged in, what changed, or when.

Opening SSH or RDP to the entire internet. A security group rule allowing 0.0.0.0/0 on port 22 or 3389 gets found by automated internet scanners within minutes, not days. Restrict management ports to known IP ranges or a bastion host.

Putting databases in public subnets. A database rarely needs a public IP address to serve an application in the same virtual network. Keep it in a private subnet with no direct internet route, and use security group rules to allow only the application tier to reach it.

For a more prescriptive checklist beyond this guide, the CIS Benchmarks publish free, vendor-specific hardening baselines for AWS, Azure, and GCP that map every setting back to a security rationale.

Getting started checklist

If you're brand new to a cloud security role, here's a realistic four-week starting point. It won't make you an expert, but it covers the highest-leverage items first.

Week 1

• Enable MFA on all admin accounts
• Review who currently has access, and to what
• Turn on your cloud provider's built-in security dashboard: AWS Security Hub, Microsoft Defender for Cloud, or Google Security Command Center

If you reach the stage of evaluating dedicated CSPM platforms, see our [comparison of the top CSPM tools](/blog/best-cspm-tools-2026-defender-for-cloud-vs-wiz-vs-orca-vs-prisma-cloud) covering Defender for Cloud, Wiz, Orca Security, and Prisma Cloud across detection depth, agentless coverage, pricing, and compliance frameworks.

Week 2

• Audit your security groups and firewall rules for anything open to 0.0.0.0/0
• Scan for vulnerabilities: check for exposed services and missing HTTP security headers
• Verify encryption at rest is enabled on every storage account, disk, and database
• Enable your provider's native audit logging if it isn't already on

Week 3

• Set up the basic alerts listed in the logging and monitoring section above
• Document your current configuration: what resources exist, who owns them, and what they're for
• Identify where your sensitive data actually lives

Week 4

• Review and tighten IAM permissions, removing anything broader than it needs to be
• Write the one-page incident response plan from the incident response section above
• Plan a recurring cadence for security reviews, quarterly is a reasonable starting point

Keep learning

Cloud security is a practice, not a destination. Start with the fundamentals above, build the habits (MFA, least privilege, logging on by default) until they're automatic, then expand into the specifics of the platform you actually work in.

A few places to go next: if you want the broader security concept that shared responsibility and least privilege both feed into, read our What is Zero Trust Security? guide. If you're mapping out a career path rather than a single skill, Getting Started in IT Security is a realistic, no-hype breakdown of how people actually break in. And once you're ready to validate these fundamentals with a certification, our comparison of AZ-500, SC-200, and SC-300 explains which Microsoft security certification fits which role.

For a longer, structured walk through cloud security fundamentals alongside networking and platform basics, protego's Junior Cloud Architect learning path is a free, step-by-step roadmap built for exactly this stage.

Frequently asked questions

What is the shared responsibility model in cloud security?

The shared responsibility model defines which security tasks belong to the cloud provider and which belong to the customer. The provider secures the physical infrastructure, hardware, networking, and virtualization layer. The customer is responsible for their data, application code, user access controls, network configuration within their account, and operating system patching on IaaS workloads. The boundary shifts depending on the service type: with SaaS the customer owns very little, with IaaS the customer owns most of the stack above the hypervisor.

What's the difference in security responsibility between IaaS, PaaS, and SaaS?

In IaaS, like AWS EC2 or Azure Virtual Machines, you're responsible for almost everything above the hypervisor: the operating system, patching, network configuration, and your applications. In PaaS, like AWS RDS or Azure App Service, the provider manages the operating system and runtime, leaving you responsible for your application code, data, and access policies. In SaaS, like Microsoft 365 or Salesforce, the provider manages nearly the entire stack, and your responsibility narrows to your data, your users, and how you configure access within the application. Across all three models, data classification and access control remain the customer's job.

Why is multi-factor authentication (MFA) the most important first step in cloud security?

MFA blocks the overwhelming majority of credential-based account compromises. Microsoft reports that MFA stops more than 99.9% of automated account attack attempts. In cloud environments where admin accounts control billing, data access, and infrastructure configuration, a single compromised password without MFA can result in a complete account takeover. Enabling MFA on admin accounts specifically, before any other control, addresses the highest-probability attack path in cloud environments.

What does the principle of least privilege mean in practice for cloud IAM?

Least privilege means granting users and services only the specific permissions they need to perform their defined tasks, and nothing more. In practice for cloud IAM: developers get read access to the services they work with, not Contributor or Owner on the whole subscription; service accounts used by applications get only the API permissions that application calls, not broad roles; and admin access is time-limited using JIT provisioning (like PIM in Azure) rather than permanently assigned. Reviewing and trimming permissions quarterly is as important as setting them correctly initially.

What logging and alerting should every cloud account have from day one?

At minimum, enable authentication event logging (login successes, failures, MFA events), configuration change logging (security group changes, IAM policy changes, storage permission changes), and data access logging for sensitive resources. Critical alerts to configure immediately: any use of the root or owner account, multiple failed login attempts on the same account, changes to firewall or security group rules, and access from unusual geographic locations. Most cloud providers offer built-in security dashboards (AWS Security Hub, Microsoft Defender for Cloud, Google Security Command Center) that automate many of these alerts.

What is the 3-2-1 backup rule and how does it apply to cloud data?

The 3-2-1 rule means maintaining 3 copies of data, on 2 different storage media types, with 1 copy stored offsite. In cloud environments: one copy is your primary data in the cloud account, a second copy uses a different service (such as a different storage class or a separate backup service), and a third copy is stored in a different cloud region or even a different provider. For ransomware resilience, add immutability: at least one backup copy should be in write-once storage that cannot be deleted or encrypted by ransomware, such as Azure Immutable Blob Storage or AWS S3 Object Lock.