Cloud Security Fundamentals: A Beginner's Guide

Welcome to Cloud Security

If you're moving to the cloud or just starting to think about security, this guide is for you. No jargon overload, no assumptions about what you already know. Just the fundamentals that matter.

The Shared Responsibility Model

This is the most important concept in cloud security. Miss this, and everything else falls apart.

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

You secure: Your data, applications, user access, network configuration, and operating systems.

Think of it like renting an apartment: The landlord maintains the building and fire safety. You're responsible for locking your door and who has your keys.

Identity: The Foundation of Everything

In the cloud, identity is your first line of defense. If someone has the right credentials, the cloud thinks they're legitimate.

Key Concepts

Authentication: Proving who you are
Authorization: What you're allowed to do
Principle of Least Privilege: Give users only what they need

Practical Steps

Enable MFA everywhere, especially for admin accounts. On Microsoft Entra ID (Azure AD), [Conditional Access policies](/blog/microsoft-entra-id-conditional-access-setup) let you enforce MFA selectively based on user risk, location, and device compliance, far more effective than blanket MFA rules.
Don't use root/owner accounts daily: create individual admin accounts
Use groups, not individual permissions: easier to manage
Review access regularly: people change roles, leave the company

Network Security Basics

Virtual Networks

Your cloud resources live in virtual networks (VPC in AWS, VNet in Azure). Think of it as your own private section of the cloud.

Put public-facing resources in public subnets. Keep databases and internal services in private subnets.

Security Groups / Firewalls

These control what traffic can reach your resources.

Default stance: Deny everything, then allow only what's needed.

Common Mistakes

Opening SSH/RDP to the entire internet
Putting databases in public subnets
Overly permissive security groups

Data Protection

Encryption at Rest

Data sitting in storage should be encrypted. Most cloud services offer this by default.

Encryption in Transit

Data moving across networks should be encrypted: HTTPS, TLS for databases, encrypted VPNs.

Backup Strategy

The 3-2-1 rule: 3 copies, 2 different storage types, 1 offsite.

Logging and Monitoring

You can't protect what you can't see.

What to Log

Authentication events
Authorization changes
Data access
Configuration changes

Basic Alerts

Root/admin account usage
Multiple failed login attempts
Security group changes
Access from unusual locations

Getting Started Checklist

Week 1:

Enable MFA on all admin accounts
Review who has access
Enable security dashboards

Week 2:

Audit security groups
[Scan for vulnerabilities](/tools/vulnerability-scanner): check exposed services and HTTP security headers
Verify encryption is enabled
Enable logging

Week 3:

Set up basic alerts
Document current configuration
Identify sensitive data

Week 4:

Review and tighten IAM permissions
Plan regular security reviews

Keep Learning

Cloud security is a journey, not a destination. Start with the fundamentals, build good habits, and expand from there.

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.

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 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.