Cloud Security: Security in AWS, Azure and GCP - The complete guide

Migrating to the cloud creates new efficiencies—and new vulnerabilities. In over 80% of cases, cloud security incidents are caused by misconfigurations, not zero-day exploits. According to Gartner, by 2025, over 99% of all cloud security incidents will be attributable to customer errors—not to cloud providers’ mistakes. Anyone who takes cloud security seriously must understand the shared responsibility model, consistently harden configurations, and continuously monitor them.

This article is the central hub document for cloud security. Related in-depth topics:

The Shared Responsibility Model

The most important fundamental concept of cloud security: Who is responsible for what?

Cloud providers (AWS, Azure, GCP) guarantee the security of the cloud itself—that is, "Security OF the Cloud":

Physical security of data centers
Hypervisor security (isolation between tenants)
Network infrastructure (backbone, DDoS protection)
Managed service software (RDS, S3, Lambda Runtime)
Infrastructure compliance (ISO 27001, SOC 2 for the platform)

Customers are responsible for security within the cloud - "Security IN the Cloud":

Configuration of cloud services
Access management (IAM policies, permissions, MFA)
Data encryption (at rest and in transit)
Operating system configuration and patches (for IaaS)
Application code and security
Network configuration (security groups, NACLs, VPC)
Monitoring and logging activation
Backup and disaster recovery

IaaS (e.g., EC2, Azure VM, GCE):
  Provider:  Hardware, hypervisor, network infrastructure
  Customer:     OS, middleware, application, data, IAM, network configuration

PaaS (e.g., RDS, Azure App Service, Cloud Run):
  Provider:  Hardware, OS, platform, runtime
  Customer:     Application, data, IAM, access configuration

SaaS (e.g., Microsoft 365, Salesforce, Google Workspace):
  Provider:  Everything except user data and access
  Customer:     Data management, user IAM, MFA enforcement, compliance

The biggest misconception: Many companies believe that data in AWS is automatically protected by AWS. The provider protects the infrastructure—but not misconfigured S3 buckets, weak IAM policies, or missing encryption. Real-world incidents prove this:

Capital One (2019):
  Misconfigured AWS Metadata Service + overly broad IAM role
  Result: 100 million customer records compromised
  Provider infrastructure was secure—customer configuration was not!

Toyota (2023):
  215 million vehicle records in a public S3 bucket
  No attack, purely a misconfiguration

Twitch (2021):
  Misconfigured Git repository in AWS
  Source code and internal data publicly accessible

Responsibility Matrix by Service Type

Component              | IaaS | PaaS | SaaS
------------------------|------|------|------
Physical security    |  P   |  P   |  P    P = Provider
Hypervisor              |  P   |  P   |  P    K = Customer
Network hardware       |  P   |  P   |  P    * = Shared
Operating system          |  K   |  P   |  P
OS patches              |  C   |  P   |  P
Runtime/Middleware      |  C   |  P   |  P
Database server         |  C   |  P   |  P
Application code          |  C   |  C   |  P
Data (content)          |  C   |  C   |  C
Data Encryption    |  *   |  *   |  N
IAM/Permissions      |  *   |  *   |  N
Monitoring/Logging      |  *   |  *   |  N
Backup                  |  N   |  N   |  N
Data Compliance    |  N   |  N   |  N

Five Common Misconceptions

Misconception 1 - "The cloud provider handles backups": AWS RDS performs automatic backups—but only with customer configuration (default: 7-day retention, then deleted). EC2 EBS snapshots: no automatic backup without explicit customer configuration.

Misconception 2 - "TLS means data is encrypted": TLS protects data in transit. Encryption at rest—S3 SSE-KMS, RDS Storage Encryption, EBS Encrypted by Default—must be enabled separately by the customer.

Misconception 3 - "The cloud provider handles logging automatically": AWS CloudTrail is NOT enabled by default. Azure Activity Log is enabled, but only retains data for 90 days. GCP Audit Logs: Admin Activity is automatic; Data Access must be explicitly enabled.

Misconception 4 – "The provider’s certificate applies to me": AWS/Azure/GCP have ISO 27001 – this applies to their infrastructure. For their own applications in the cloud, customers need their own ISMS and their own compliance evidence.

Misconception 5 – "Data breach reporting deadlines do not apply when the cloud is involved": The 72-hour GDPR reporting requirement applies even when the cloud provider is involved.

The Most Common Cloud Misconfigurations

Cloud misconfigurations cause more data breaches than sophisticated exploits. Cloud environments are complex, evolve rapidly, and are often configured by teams that are not security specialists.

Top 10 Cloud Misconfigurations by Frequency and Severity:

Public Storage Bucket (S3, Azure Blob, GCS): Direct data access for anyone on the internet.
Overprivileged IAM roles: Service has admin rights instead of least privilege. EC2 with AdministratorAccess → attacker = cloud root.
Open security groups / NSGs: 0.0.0.0/0 for RDP, SSH, database ports – direct internet access to internal services.
Disabled logging: CloudTrail, VPC Flow Logs, Azure Activity Log not active—no audit trail for incident response.
Lack of encryption: S3 objects unencrypted, EBS without encryption, databases without encryption at rest.
IMDSv1 instead of IMDSv2: An attacker can steal IAM credentials via SSRF from a compromised instance.
Root account without MFA: AWS Root or Azure Global Admin without MFA – immediate risk of compromise.
Cross-account roles without External ID: Confused Deputy problem – third-party accounts can assume roles.
No resource tagging policy: Unknown resources, no owner → shadow IT in the cloud.
Insecure Kubernetes configurations: Dashboard without authentication, unencrypted etcd, privileged pods.

AWS Misconfigurations: Detection and Remediation

# 1. Public S3 bucket - Detection:
aws s3api get-bucket-acl --bucket my-bucket
# If &quot;AllUsers&quot; has READ → publicly accessible!

# Fix: S3 Block Public Access at the account level:
aws s3control put-public-access-block \
  --account-id 123456789012 \
  --public-access-block-configuration \
  &quot;BlockPublicAcls=true,IgnorePublicAcls=true,\
   BlockPublicPolicy=true,RestrictPublicBuckets=true&quot;

# 2. Enforce IMDSv2 (prevents SSRF credential theft):
aws ec2 modify-instance-metadata-options \
  --instance-id i-1234567890abcdef0 \
  --http-tokens required \
  --http-endpoint enabled

# In Terraform:
# resource &quot;aws_instance&quot; &quot;example&quot; {
#   metadata_options {
#     http_tokens   = &quot;required&quot;
#     http_endpoint = &quot;enabled&quot;
#   }
# }

# 3. Enable CloudTrail (all regions!):
aws cloudtrail create-trail \
  --name my-trail \
  --s3-bucket-name my-cloudtrail-bucket \
  --is-multi-region-trail \
  --include-global-service-events \
  --enable-log-file-validation
# Enable S3 Object Lock, retention: min. 12 months

# 4. Secure the root account:
#    Enable MFA immediately
#    No programmatic access keys for root
#    Alert on root login via CloudWatch:
#      AWS Config Rule: root-account-mfa-enabled
#      CloudWatch Metric Filter: ConsoleLogin by root

# 5. Security Groups: Port 22 / 3389 from 0.0.0.0/0:
#    SSH / RDP from anywhere → Fix: only from VPN IP or Bastion SG
#    DB port from anywhere → Fix: only from App Server SG
#    AWS Config Rules for automatic detection:
#      restricted-ssh
#      restricted-rdp
#      s3-bucket-public-read-prohibited

Azure misconfigurations

# Azure Blob public access - Check:
az storage account show \
  --name mystorageaccount \
  --query &quot;allowBlobPublicAccess&quot;

# Fix:
az storage account update \
  --name mystorageaccount \
  --resource-group myRG \
  --allow-blob-public-access false

# Check for overprivileged service principals:
az role assignment list \
  --scope /subscriptions/<sub-id> \
  --query &quot;[].{role:roleDefinitionName, principal:principalName}&quot;
# No owner for service principals!
# Use managed identities instead of service principal keys

# Check SSH/RDP in network security groups:
az network nsg rule list \
  --resource-group myRG \
  --nsg-name myNSG \
  --query &quot;[?destinationPortRange==&#x27;22&#x27; || destinationPortRange==&#x27;3389&#x27;]&quot;

# Azure Defender for Cloud - Secure Score:
# Shows all misconfigurations with severity
# Recommendations generated automatically
# One-click remediation for many findings

Cloud Security Design Principles

Secure cloud architecture is not simply a porting of on-premises security concepts to the cloud. The cloud offers new primitives (IAM roles instead of firewalls, managed services instead of self-managed servers) and new attack surfaces. Secure cloud architecture utilizes cloud-native security patterns.

8 Principles of Secure Cloud Architecture:

1. Least Privilege Everywhere
   IAM roles with minimal permissions
   No administrator roles for services
   Condition keys for additional restrictions
   Regular IAM Access Analyzer reviews

2. Defense in Depth
   Multiple security layers: WAF → LoadBalancer → Security Groups → NACL → App
   No single point of trust
   Assume breach: What happens if layer X is compromised?

3. Zero Trust network
   No implicit trust in the network
   All service-to-service communication: authenticated + authorized
   Service mesh (Istio, AWS App Mesh): mTLS between services

4. Immutable infrastructure
   Servers are not modified; they are replaced
   Infrastructure as Code: every change via Terraform/CDK
   No SSH on production instances (AWS SSM Session Manager instead)

5. Keep secrets out of code
   No hardcoded credentials
   Secrets Manager / Parameter Store for all secrets
   Enforce IMDSv2 (IMDSv1 is vulnerable to SSRF!)
   Automatic Key Rotation

6. Monitoring by Default
   CloudTrail / Activity Log / Audit Log: always enabled
   VPC Flow Logs: always enabled
   CSPM: continuous configuration monitoring

7. Automation-First
   Manual changes = drift + undocumented
   GitOps: Infrastructure changes via pull requests
   Automatic remediation: Config Rules with auto-remediation

8. Implement data classification
   Public, Internal, Confidential, Restricted
   Confidential+ data: Encryption with Customer Managed Keys (CMK)
   Restricted data: Enforce data residency (EU regions only)
   Data Access Logging: who accessed what and when

VPC Network Design

The virtual network (VPC / Virtual Network / VNet) must be carefully structured:

Secure VPC Design (3-Tier Architecture, AWS Example):

Internet
  │
[Internet Gateway]
  │
Public Subnet (10.0.0.0/24)
  └── Application Load Balancer, NAT Gateway
        Security Group: INCOMING Port 443 from the Internet ONLY

Private Subnet - Application Layer (10.0.1.0/24)
  └── Web/App Server, ECS/EKS Containers
        Security Group: 443/8080 only from Load Balancer SG
        No direct Internet access (only via NAT Gateway)

Private Subnet - Database Layer (10.0.2.0/24)
  └── RDS, ElastiCache, DocumentDB
        Security Group: DB Port (5432/3306) ONLY from App Subnet
        No Internet access (NAT Gateway unnecessary!)

Common mistake: SSH (Port 22) and RDP (Port 3389) from 0.0.0.0/0 -
one of the most common cloud attack vectors!

Network ACLs (subnet level, in addition to Security Groups):
  Stateless (configure both directions!)
  Deny rule for known bad IPs (from Threat Intelligence)
  Egress: DENY except 443, 80, DNS

AWS PrivateLink / VPC Endpoints: S3, DynamoDB, and Secrets Manager accessible via VPC Endpoint—without internet traffic. Gateway Endpoints for S3 and DynamoDB are free.

IAM Security in the Cloud

Cloud IAM Best Practices:

Basic Principles:
  Least Privilege:
    Each identity (user, service, application) is granted only the permissions
    that are minimally necessary for its task
    No wildcard policies (&quot;Action&quot;: &quot;*&quot; or &quot;Resource&quot;: &quot;*&quot;)

  Just-in-Time Access:
    Privileged access only when needed and for a limited time
    Privileged Access Management (PAM)

  No Long-Lived Credentials:
    Avoid IAM users with long-lived access keys
    Instead: IAM roles, Workload Identity, short-lived tokens via STS

Workload Identity (Cloud-native – no static secret!):
  AWS:   IRSA (IAM Roles for Service Accounts) for EKS pods
         EC2 Instance Profiles instead of access keys
         Enforce IMDSv2 (SSRF protection)
  Azure: Managed Identities (System-Assigned or User-Assigned)
         No password, no secret → no risk of leaks
  GCP:   Workload Identity Federation
         No service account key (JSON key) no longer needed!

IAM Access Analyzer:
  Detects: S3 buckets, KMS keys, secrets with external access
  Review findings daily!
  AWS Organizations: organization-wide Analyzer

AWS IAM Best Practices at a Glance:
  Root account: Enable MFA, no programmatic access keys
  IAM roles for EC2/Lambda instead of access keys
  Permission Boundaries for delegated administration
  Enable IAM Access Analyzer
  Access keys max. 90 days old (auto-rotate)
  Enable CloudTrail (all regions)
  AWS Config for compliance monitoring
  Service Control Policies (SCPs) in AWS Organizations

Secrets Management

Securely manage secrets - Cloud-native:

AWS Secrets Manager:
  Automatic rotation (RDS passwords, API keys)
  KMS encryption (Customer Managed Key recommended!)
  Cross-account access via Resource Policy
  VPC Endpoint for private use

AWS SSM Parameter Store:
  More cost-effective than Secrets Manager (standard parameters free)
  SecureString parameters: KMS-encrypted
  Use case: Configuration parameters, non-rotating secrets

Azure Key Vault:
  Secrets, keys, and certificates in a single service
  Soft delete + purge protection
  Key Vault Firewall: accessible only from your own VNet
  Audit logs: who accessed which secret and when

HashiCorp Vault (cloud-agnostic):
  Dynamic Secrets: Vault creates temporary DB credentials on demand
  No more static database passwords needed!
  Credentials expire after a configurable TTL
  Audit: every access logged with caller identity

Rule: No secrets in code, Git history, environment variables,
       logs, or configuration files!

Encryption in the Cloud

Encryption at Rest:

S3 buckets: Server-Side Encryption (SSE-S3, SSE-KMS, or SSE-C)
EBS volumes: AWS KMS encryption (Enable "Encrypted by Default" at the account level)
RDS databases: Specify encryption at rest during creation (subsequent activation requires migration)
Backups: Store encrypted

Encryption in Transit:

TLS/HTTPS for all API calls
VPC endpoints for AWS services (no transmission over the Internet)
VPN or Direct Connect for hybrid cloud

Key Management: AWS KMS / Azure Key Vault / GCP Cloud KMS for centralized key management. Customer Managed Keys (CMK) for maximum control over encryption and key rotation. Details: Cloud Key Management.

Cloud Security Posture Management (CSPM)

CSPM tools continuously scan cloud environments for misconfigurations and compliance violations. They automatically check hundreds of configuration rules:

Typical CSPM checks:
  Publicly accessible S3 buckets / storage accounts
  Security groups with 0.0.0.0/0 on port 22
  Unencrypted databases
  Missing MFA for privileged accounts
  Disabled logging
  Secrets in EC2 User Data or Lambda Env Vars
  Access keys that are too old (&gt;90 days)
  Missing backup configurations

Open-Source / Free CSPM Tools:

# Prowler (AWS, Azure, GCP) - leading open-source CSPM:
pip install prowler

# Scan AWS:
prowler aws -M csv html

# Only CRITICAL and HIGH:
prowler aws -S critical,high

# Compliance framework:
prowler aws --compliance gdpr_aws
# HTML report with all findings, severity, and fix recommendations

# ScoutSuite (NCC Group, multi-cloud):
pip install scoutsuite
scout aws

# Checkov (IaC Security - Issues BEFORE they are deployed!):
pip install checkov
checkov -d ./terraform/      # Check Terraform
checkov -d ./k8s/            # Check Kubernetes YAML
# Pipeline fails on CRITICAL

Commercial CSPM Platforms:

Wiz: Leading CSPM, attack path analysis ("Toxic Combinations": EC2 with public IP + admin role + open security group), agentless
Prisma Cloud (Palo Alto): Full-stack CSPM including CIEM (Cloud Infrastructure Entitlement Management), compliance reporting for CIS, PCI DSS, HIPAA, ISO 27001
Microsoft Defender for Cloud: Ideal for Azure, Secure Score as a continuous metric, Azure Arc for on-premises
AWS Security Hub: Central dashboard for AWS accounts, CIS Benchmark, integration with GuardDuty, Inspector, Macie

Logging and Monitoring

Without logging, API calls, permission changes, and data access cannot be traced—forensics is impossible.

Mandatory logs (always enabled):

AWS:
  CloudTrail: all API calls, all regions, S3 buckets with Object Lock
  VPC Flow Logs: all VPCs (accepted + rejected connections)
  S3 Access Logging: for sensitive buckets
  RDS Audit Logs: database operations
  GuardDuty: Threat Detection via Machine Learning (enable!)
  AWS Config: configuration changes for all resources
  Security Hub: Centralized security findings

Azure:
  Azure Activity Log: all resource operations
  Azure AD Sign-In Logs: authentications
  NSG Flow Logs: network connections
  Diagnostic Logs: service-specific logs (KeyVault, SQL, etc.)
  Microsoft Defender for Cloud: CSPM + threat detection
  Microsoft Sentinel: SIEM for all Azure logs

Critical CloudTrail Alerts (immediate notification!):
  Root account usage (always alert!)
  Console login without MFA
  IAM policy changes outside the IaC pipeline
  Security group with 0.0.0.0/0 added
  S3 bucket public access disabled
  CloudTrail stopped or deleted
  KMS key deleted
  API calls from new or unknown regions

GuardDuty High-Confidence Findings:
  CryptoCurrency:       EC2 instance performing crypto mining
  UnauthorizedAccess:   SSH brute force, Tor exit node
  Backdoor:             C2 communication detected
  Impact:               Files deleted, ransomware patterns
  Stealth:              CloudTrail disabled, password policy changed

Further reading: Cloud Detection Engineering

Cloud Penetration Testing

Regular cloud penetration tests are an essential component of cloud security.

Typical Test Areas:

IAM configuration and privilege escalation paths
Network segmentation and firewall rules
Exposed services (publicly accessible endpoints)
Misconfigured storage resources
Secrets in code, logs, environment variables
Container security (Docker, Kubernetes)
Metadata service attacks (IMDSv1-SSRF)

Authorization required: Cloud providers have their own penetration testing policies. AWS allows testing without prior authorization for certain services—for other services and with other providers, an official ticket is required.

Cloud Security and German Compliance

Data Processing Agreement (DPA): Enter into one with AWS, Azure, GCP
Data locality: Explicitly select primary storage location in EU regions (Frankfurt, Amsterdam)
Transfers to third countries: Review the EU-US Data Privacy Framework; Standard Contractual Clauses (SCC)
Own TOMs: Document technical and organizational measures yourself
Data breach notification: 72-hour deadline also applies when cloud providers are involved

Enforce data localization:
  AWS Control Tower:    Organization-wide region restrictions
  Azure Policy:         Allow resource creation only in EU regions
  GCP Org Policy:       Location restriction (resourceLocations)

BSI C5 - Cloud Computing Compliance Criteria Catalogue

The BSI has developed C5, a German standard for cloud security. Major cloud providers (AWS, Azure, GCP) publish C5 attestations (Type 1 and Type 2), which customers can use as proof of infrastructure security—but these do not replace their own compliance requirements for applications and data.

NIS2 and the Cloud

Critical infrastructures and key facilities must incorporate cloud services into their risk management. Article 21 of NIS2 explicitly requires security measures for the supply chain—including cloud service providers. The following measures must be documented:

Risk assessment for cloud services in supply chain risk management
Contractual arrangements with cloud providers (security requirements, SLAs)
Incident response, including cloud-specific scenarios
Monitoring and logging for compliance evidence

ISO 27001 in the Cloud

Provider controls can be referenced in the Statement of Applicability—however, internal ISMS controls are still required:

In-house controls are always necessary:
  A.9.2:  Access rights management → Document IAM policies
  A.10.1: Cryptographic controls → Document encryption decisions
  A.12.4: Logging → Which logs, for how long, where stored
  A.16.1: Incident Management → Cloud-specific IR processes

Audit Plan for Cloud Misconfigurations

Cloud Security Audit Frequency:

Daily (automated):
  Cloud Security Posture (AWS Security Hub / Defender Secure Score)
  GuardDuty / Microsoft Defender for Cloud Findings
  CloudTrail alerts for root logins and IAM policy changes

Weekly:
  New IAM users or roles in the last 7 days?
  New public resources (S3, Storage, EC2)?
  CloudTrail: unusual API calls (e.g., at night, from foreign regions)

Monthly:
  Prowler/ScoutSuite scan – all new findings since last month
  IAM Access Advisor: which permissions are never used?
    Remove unused permissions!
  Cost Anomaly Detection: unknown resources → shadow IT?

Quarterly:
  Full Prowler report against CIS Benchmark
  Cloud infrastructure penetration test
  IAM Access Review: all service accounts and roles

After every deployment:
  Checkov/tfsec: IaC checked for misconfigurations?
  New Security Groups: 0.0.0.0/0 for sensitive ports?
  New Storage: Block Public Access enabled?

Cloud Security Best Practices - Checklist

IAM:
  Root account MFA enabled, no programmatic access keys
  All users have their own credentials (no shared accounts)
  MFA for all privileged accounts
  IAM roles instead of access keys for services (IRSA, Instance Profile)
  Least-privilege policies (no wildcards *)
  Regular access reviews (quarterly)
  IAM Access Analyzer enabled

Network:
  VPC with subnet segmentation (3-tier: ALB, App, DB)
  Security Groups: no 0.0.0.0/0 on ports 22/3389/DB ports
  VPC Flow Logs enabled
  WAF in front of public web apps
  VPC Endpoints for AWS services (no internet traffic)

Storage:
  No public bucket access (Block Public Access at account level)
  Encryption at rest for all data storage (SSE-KMS)
  Versioning and MFA-Delete on critical buckets
  Regular backups with restore tests

Secrets:
  No secrets in code, Git, or config files
  Secrets Manager / Key Vault in use
  Regular key rotation (automated)
  IMDSv2 enforced (no IMDSv1)

Monitoring:
  CloudTrail enabled (all regions, multi-region trail)
  S3 bucket for CloudTrail with Object Lock (immutable!)
  Alerts for critical events (root login, policy changes)
  GuardDuty / Defender for Cloud enabled
  CSPM tool in use
  Log retention: min. 90 days, 12 months for compliance

IaC and Deployment:
  Infrastructure as Code (Terraform/CDK) - no ClickOps
  Checkov / tfsec integrated into CI/CD pipeline
  No manual changes to production environments

Topic Overview: Cloud Security Cluster

Cloud security is a broad field. The following wiki articles explore individual aspects in depth:

Topic	Article
Containers, Docker, Kubernetes	Container Security and Kubernetes
BSI C5, ISO 27001, NIS2, PCI DSS	Cloud Compliance
IAM, Roles, Permissions, CIEM	Cloud IAM Security
KMS, HSM, Key Rotation	Cloud Key Management
SIEM, GuardDuty, Alerting	Cloud Detection Engineering

Conclusion

Cloud security is not a given. The Shared Responsibility Model makes it clear: The cloud provider protects the infrastructure—configuration, identities, and data are the user’s responsibility. Most cloud security incidents can be prevented through consistent configuration management, robust IAM policies, automated CSPM, and continuous monitoring. Infrastructure as Code, the Leastprinciple, and "monitoring by default" are the three most important levers for a secure cloud environment.