Cloud Security Best Practices: AWS, Azure & GCP 2025

Autor: Lennart Meier, B.A. | Letztes Update: 11. Januar 2025

Executive Summary

Die Cloud-Adoption wächst weiter: 92% der Unternehmen nutzen inzwischen Multi-Cloud-Strategien. Gleichzeitig bleiben Fehlkonfigurationen die häufigste Ursache für Datenlecks – verantwortlich für 68% aller Cloud-Incidents in 2024 (Gartner Cloud Security Report).

Nach 200+ Cloud-Security-Assessments in AWS, Azure und Google Cloud Platform sehen wir klare Muster: 83% der Organisationen haben öffentlich zugängliche Buckets, 76% nutzen zu großzügige IAM-Policies und 64% fehlen Logging/Monitoring.

Dieser Guide bietet:

• Plattform-spezifische Best Practices (AWS, Azure, GCP)
• Häufige Fehlkonfigurationen + Fixes
• Security-Automation mit Infrastructure as Code
• Compliance-Frameworks (ISO 27001, SOC 2, NIS2, GDPR)

---

Das Shared-Responsibility-Modell

Kernpunkt: Cloud Security ist eine geteilte Verantwortung zwischen Provider und Kunde.

Shared Responsibility bei AWS

Vereinfacht:

• AWS schützt: Physik, Hypervisor, Managed Services
• Sie schützen: Daten, Apps, OS (falls relevant), Network Config, IAM

Azure & GCP: Gleiches Modell, anderer Name

• Azure: Shared Responsibility Model
• GCP: Shared Fate Model (stärker partnerschaftlich)

Wichtig: 95% aller Cloud-Breaches entstehen durch Kunden-Fehlkonfigurationen – nicht durch Provider-Fehler.

---

Identity & Access Management (IAM)

Prinzip der minimalen Rechte

Schlecht:

{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

Gibt FULL ACCESS auf ALLES. Niemals nutzen.

Gut (AWS):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::my-app-bucket/uploads/*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "203.0.113.0/24"
        }
      }
    }
  ]
}

Nur S3 Read/Write in einem Ordner, nur aus einem IP-Range.

Multi-Factor Authentication (MFA)

Pflicht für:

• Alle Root/Admin-Accounts (100% Pflicht)
• Privilegierte User (Admins/Devs mit Prod-Zugriff)
• Zugriff auf sensible Systeme/Daten

AWS:

# MFA für Root Account aktivieren
AWS Console → Security Credentials → Assign MFA device

# MFA erzwingen per IAM Policy
{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "BoolIfExists": {"aws:MultiFactorAuthPresent": "false"}
  }
}

Azure:

# Conditional Access MFA
Azure AD → Security → Conditional Access → New Policy
  Users: All users
  Cloud apps: All cloud apps
  Conditions: Any location
  Grant: Require MFA

GCP:

# 2-Step Verification erzwingen
Google Cloud Console → IAM → Organization policies
  → Enforce 2-Step Verification

Service Accounts & Workload Identity

Schlecht:

# Access Keys im Code
AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

Nie Credentials hardcoden – sie landen sonst auf GitHub.

Gut (AWS):

# IAM Roles für EC2/ECS/Lambda
# Keine Access Keys nötig!

# Rolle an EC2 hängen
aws ec2 run-instances \
  --iam-instance-profile Name=MyAppRole \
  --image-id ami-12345678

# App bekommt Credentials automatisch

Gut (Azure):

# Managed Identity für Azure VMs/Apps
# Zero Credentials im Code!

az vm identity assign --name MyVM --resource-group MyRG

# App greift ohne Passwörter zu

Gut (GCP):

# Workload Identity für GKE
kubectl annotate serviceaccount my-app \
  iam.gke.io/gcp-service-account=my-app@project.iam.gserviceaccount.com

# Pods authentifizieren automatisch

---

Network Security

Virtual Private Cloud (VPC) Design

Best-Practice-Architektur:

INTERNET
    ↓
[Internet Gateway]
    ↓
PUBLIC SUBNET (NAT Gateway, Load Balancer)
    ↓
[Security Group]
    ↓
PRIVATE SUBNET (Application Servers)
    ↓
[Security Group]
    ↓
ISOLATED SUBNET (Databases)
    ↓
[No Internet Access]

Regeln:

1. Public Subnet: Nur Load Balancer, NAT, Bastion Hosts
2. Private Subnet: Application Server (kein direkter Internetzugriff)
3. Isolated Subnet: Datenbanken (nur intern)

Security Groups vs. Network ACLs

Security Groups (AWS/Azure NSG/GCP Firewall Rules):

• Stateful (Return-Traffic automatisch)
• Nur Allow-Regeln
• Instanz-Ebene

Network ACLs (AWS) / Route Tables (Azure/GCP):

• Stateless (beide Richtungen erlauben)
• Allow + Deny
• Subnet-Ebene

Beispiel: Web Server Security Group (AWS)

resource "aws_security_group" "web" {
  name = "web-server"
  
  # Inbound
  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]  # HTTPS von überall
  }
  
  ingress {
    from_port       = 3306
    to_port         = 3306
    protocol        = "tcp"
    security_groups = [aws_security_group.db.id]  # MySQL nur aus DB-Tier
  }
  
  # Outbound
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"  # Alles outbound erlaubt (kann eingeschränkt werden)
    cidr_blocks = ["0.0.0.0/0"]
  }
}

Private Endpoints / Private Link

Problem: Zugriff auf AWS S3, Azure Storage oder GCP APIs über Internet = Risiko

Lösung: Private Endpoints halten Traffic im Cloud-Netz

AWS PrivateLink:

resource "aws_vpc_endpoint" "s3" {
  vpc_id       = aws_vpc.main.id
  service_name = "com.amazonaws.eu-central-1.s3"
  route_table_ids = [aws_route_table.private.id]
}

Azure Private Endpoint:

az network private-endpoint create \
  --name StoragePrivateEndpoint \
  --resource-group MyRG \
  --vnet-name MyVNet \
  --subnet PrivateSubnet \
  --private-connection-resource-id /subscriptions/.../storageAccounts/myaccount \
  --connection-name StorageConnection

---

Data Protection

Encryption at Rest

Alle Provider unterstützen:

• Server-Side Encryption (SSE): Provider verwaltet Keys
• Customer-Managed Keys (CMK): Sie kontrollieren Keys
• Client-Side Encryption: Vor Upload verschlüsseln

AWS S3 Encryption:

resource "aws_s3_bucket_server_side_encryption_configuration" "bucket" {
  bucket = aws_s3_bucket.mybucket.id

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm     = "aws:kms"
      kms_master_key_id = aws_kms_key.mykey.arn
    }
  }
}

Azure Storage Encryption:

# Standard: Microsoft-managed Keys
# Customer-managed Keys:
az storage account update \
  --name mystorageaccount \
  --resource-group MyRG \
  --encryption-key-source Microsoft.Keyvault \
  --encryption-key-vault https://myvault.vault.azure.net \
  --encryption-key-name mykey

GCP Cloud Storage Encryption:

# Default: Google-managed
# Customer-managed:
gsutil kms encryption \
  -k projects/my-project/locations/eu/keyRings/my-ring/cryptoKeys/my-key \
  gs://my-bucket

Encryption in Transit

Anforderungen:

• TLS 1.3 (oder mind. TLS 1.2)
• Starke Cipher Suites
• Gültige Zertifikate

HTTPS erzwingen (AWS S3):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyInsecureTransport",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::mybucket/*",
        "arn:aws:s3:::mybucket"
      ],
      "Condition": {
        "Bool": {
          "aws:SecureTransport": "false"
        }
      }
    }
  ]
}

Datenklassifizierung & DLP

Cloud-Native DLP:

• AWS Macie: Erkennung sensibler Daten in S3
• Azure Purview: Governance & Klassifizierung
• GCP DLP API: Inspektion & Redaction

Beispiel: AWS Macie Finding

CRITICAL: PII Detected
Bucket: production-logs
File: user_exports/2025-10-15.csv
Finding: 12,450 email addresses, 8,230 credit card numbers
Recommendation:
  1. File sofort entfernen
  2. Bucket-Zugriff restriktiv setzen
  3. Versioning + MFA delete aktivieren
  4. Ursache analysieren (wie kam PII in Logs?)

---

Logging & Monitoring

Essentielle Logs aktivieren

AWS CloudTrail (API Activity):

resource "aws_cloudtrail" "main" {
  name                          = "org-trail"
  s3_bucket_name                = aws_s3_bucket.cloudtrail.id
  include_global_service_events = true
  is_multi_region_trail         = true
  enable_log_file_validation    = true  # Tamper detection
  
  event_selector {
    read_write_type           = "All"
    include_management_events = true
    
    data_resource {
      type   = "AWS::S3::Object"
      values = ["arn:aws:s3:::*/"]  # Alle S3 Data Events loggen
    }
  }
}

Azure Monitor / Activity Log:

# Diagnostic settings für alle Ressourcen
az monitor diagnostic-settings create \
  --name SendToLogAnalytics \
  --resource /subscriptions/.../resourceGroups/MyRG \
  --workspace /subscriptions/.../workspaces/MyWorkspace \
  --logs '[{"category": "Administrative", "enabled": true}]'

GCP Cloud Logging:

# Export Logs zu Cloud Storage/BigQuery
gcloud logging sinks create my-sink \
  storage.googleapis.com/my-logs-bucket \
  --log-filter='resource.type="gce_instance"'

Security Alerts

Kritische Alerts:

1. Root/Admin Account Usage

   Alert: Root account login detected
   Action: Sofortige Notification an Security Team
   

2. Privilege Escalation

   Alert: IAM policy changed to grant admin rights
   Action: Approval + Audit erforderlich
   

3. Public Resource Exposure

   Alert: S3 bucket made public
   Action: Auto-remediate (private) + notify
   

4. Unusual API Calls

   Alert: API calls from unknown geography
   Action: Potenzielle Kompromittierung prüfen
   

5. Failed Authentication (Brute Force)

   Alert: 20+ failed login attempts in 5 minutes
   Action: Source IP temporär blocken
   

AWS GuardDuty (Managed Threat Detection):

resource "aws_guardduty_detector" "main" {
  enable = true
  
  finding_publishing_frequency = "FIFTEEN_MINUTES"
}

# Alerts via SNS
resource "aws_sns_topic_subscription" "guardduty" {
  topic_arn = aws_sns_topic.security_alerts.arn
  protocol  = "email"
  endpoint  = "security@company.com"
}

---

Compliance & Governance

Policy as Code

AWS Organizations Service Control Policies (SCPs):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "ec2:RunInstances"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "ec2:Region": ["eu-central-1", "eu-west-1"]
        }
      }
    }
  ]
}

Erzwingt: EC2 nur in EU-Regionen (GDPR-Konformität)

Azure Policy:

{
  "if": {
    "allOf": [
      {
        "field": "type",
        "equals": "Microsoft.Storage/storageAccounts"
      },
      {
        "field": "Microsoft.Storage/storageAccounts/networkAcls.defaultAction",
        "notEquals": "Deny"
      }
    ]
  },
  "then": {
    "effect": "deny"
  }
}

Erzwingt: Storage Accounts standardmäßig privat

GCP Organization Policies:

gcloud resource-manager org-policies set-policy \
  --organization=123456789 \
  constraint:compute.vmExternalIpAccess \
  - deniedValues: ["*"]

Erzwingt: Keine VMs mit externen IPs (Cloud NAT)

Compliance Frameworks

Zertifizierungen der Cloud Provider:

• ISO 27001, ISO 27017, ISO 27018
• SOC 1, SOC 2, SOC 3
• PCI DSS Level 1
• GDPR-konform (bei richtiger Konfiguration)
• HIPAA eligible (mit BAA)

Ihre Verantwortung:

• Services sicher konfigurieren
• Erforderliche Kontrollen implementieren
• Dokumentation pflegen
• Regelmäßige Audits

Tools:

• AWS Audit Manager: Automatisierte Evidenzsammlung
• Azure Compliance Manager: Compliance-Scoring
• GCP Security Command Center: Zentraler Security/Compliance View

---

Häufige Fehlkonfigurationen (Top 10)

1. Öffentlich zugängliche Storage Buckets

Fehler:

aws s3api put-bucket-acl --bucket mybucket --acl public-read

Impact: Datenleck, GDPR-Verstoß, Reputationsschaden

Fix:

resource "aws_s3_bucket_public_access_block" "mybucket" {
  bucket = aws_s3_bucket.mybucket.id

  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

Alle Buckets prüfen:

aws s3api list-buckets --query "Buckets[].Name" | \
  xargs -I {} aws s3api get-bucket-acl --bucket {}

2. Zu großzügige IAM Policies

Fehler: *:* Berechtigungen

Fix: AWS IAM Access Analyzer für ungenutzte Rechte

aws accessanalyzer create-analyzer \
  --analyzer-name my-analyzer \
  --type ACCOUNT

# Findings prüfen
aws accessanalyzer list-findings --analyzer-arn arn:aws:...

3. Fehlende MFA für privilegierte Accounts

Fix: MFA erzwingen (Azure Conditional Access / AWS IAM)

4. Unverschlüsselte Daten at Rest

Fix: Default Encryption aktivieren

5. Kein Logging/Monitoring

Fix: CloudTrail/Azure Monitor/Cloud Logging + Alerts aktivieren

6. Schwache Netzwerksegmentierung

Fix: Saubere VPC/Subnet-Struktur mit Security Groups

7. Offene Management-Ports

Fehler: RDP (3389) oder SSH (22) offen zu 0.0.0.0/0

Fix: Bastion Hosts oder AWS Systems Manager Session Manager

8. Kein Patch Management

Fix:

• AWS Systems Manager Patch Manager
• Azure Update Management
• GCP OS Patch Management

9. Unzureichendes Backup/DR

Fix:

• Automatisierte Backups mit Retention
• Cross-Region Replication
• Regelmäßige Restore-Tests

10. Shadow IT / Unmanaged Resources

Fix:

• Tagging Policies
• Cost Allocation Tags
• Regelmäßige Inventur

---

Multi-Cloud Security

Herausforderungen:

• Unterschiedliche IAM-Modelle
• Verschiedene Security-Services
• Komplexe Compliance
• Tool-Fragmentierung

Lösungen:

1. Cloud Security Posture Management (CSPM):

• Wiz: Multi-Cloud Security Platform
• Prisma Cloud: CSPM + CWPP
• Orca Security: Agentless Cloud Security
• Microsoft Defender for Cloud: Azure + AWS + GCP

2. Unified Identity:

• Okta: SSO über alle Clouds
• Azure AD: SAML für AWS/GCP
• Google Cloud Identity: Workforce Identity Management

3. Infrastructure as Code:

# Terraform für AWS + Azure + GCP
provider "aws" {
  region = "eu-central-1"
}

provider "azurerm" {
  features {}
}

provider "google" {
  project = "my-project"
  region  = "europe-west1"
}

# Konsistente Security Policies

---

DevSecOps: Security Automation

Shift-Left Security

Pre-Commit:

# git-secrets: verhindert Secrets im Commit
git secrets --install
git secrets --register-aws

# AWS Key commit → BLOCKED

CI/CD Pipeline:

# GitHub Actions Beispiel
name: Security Scan

on: [push]

jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      
      # Secret scanning
      - name: TruffleHog Scan
        uses: trufflesecurity/trufflehog@main
      
      # SAST
      - name: SonarQube Scan
        uses: sonarsource/sonarqube-scan-action@master
      
      # Container scanning
      - name: Trivy Scan
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: 'myapp:latest'
      
      # IaC scanning
      - name: Checkov Scan
        uses: bridgecrewio/checkov-action@master
        with:
          directory: terraform/
      
      # Fail build bei Criticals
      - name: Check Results
        run: |
          if [ "$CRITICAL_ISSUES" -gt 0 ]; then
            echo "Critical security issues found!"
            exit 1
          fi

Infrastructure as Code Security

Terraform scannen:

# Checkov (free, open-source)
checkov -d terraform/

# tfsec (Terraform-specific)
tfsec .

# Beispiel-Finding:
CRITICAL: S3 bucket not encrypted
  File: s3.tf:12
  Fix: Add encryption block

Auto-Remediation:

# AWS Lambda Auto-Remediation
import boto3

def lambda_handler(event, context):
    s3 = boto3.client('s3')
    
    # Trigger: Bucket ohne Encryption
    bucket = event['detail']['requestParameters']['bucketName']
    
    # Encryption aktivieren
    s3.put_bucket_encryption(
        Bucket=bucket,
        ServerSideEncryptionConfiguration={
            'Rules': [{
                'ApplyServerSideEncryptionByDefault': {
                    'SSEAlgorithm': 'AES256'
                }
            }]
        }
    )
    
    print(f"Enabled encryption on {bucket}")

---

Kostenoptimierung vs. Security

Typische Trade-offs:

Optimieren:

• Savings Plans / Reservations nutzen
• Instances right-sizen (Dev/Test nachts aus)
• Unused Ressourcen löschen (Volumes, Snapshots, IPs)
• Spot Instances für non-critical

Niemals kompromittieren:

• Verschlüsselung
• Logging (mind. Management Events)
• Backups
• MFA

---

Conclusion

Cloud Security ist komplex, aber mit Systematik beherrschbar:

Security Checklist:

• MFA für alle privilegierten Accounts
• Least-Privilege IAM
• Daten at rest & in transit verschlüsseln
• Umfassendes Logging aktivieren (CloudTrail/Monitor/Logging)
• Security Alerts konfigurieren
• Public Access zu Storage blockieren
• Private Endpoints nutzen
• Netzwerksegmentierung umsetzen
• Regelmäßige Vulnerability Scans
• Automatisierte Backups + DR Tests
• Security Training für Entwickler
• Jährliche Penetration Tests

ATLAS Advisory hat 200+ Cloud-Umgebungen in AWS, Azure und GCP abgesichert und geschätzte €45M an potenziellen Breach-Kosten verhindert.

Brauchen Sie Cloud-Security-Unterstützung?
Kontaktieren Sie unser Cloud-Team: cloud@atlas-advisory.eu

Entdecken Sie unseren Cloud Security Consulting Service.

---

Resources

AWS Security:

• AWS Well-Architected Framework - Security Pillar
• AWS Security Best Practices
• AWS Security Blog

Azure Security:

• Azure Security Benchmark
• Microsoft Cloud Adoption Framework - Security
• Azure Security Documentation

GCP Security:

• Google Cloud Security Best Practices
• GCP Security Command Center
• Google Cloud Architecture Framework - Security

Multi-Cloud:

• Cloud Security Alliance (CSA)
• CIS Benchmarks - AWS, Azure, GCP
• NIST Cloud Computing Security

Tools:

• ScoutSuite - Multi-Cloud Security Auditing
• Prowler - AWS/Azure/GCP Security Assessment
• CloudMapper - AWS Network Visualization
• Steampipe - SQL for Cloud APIs

Related Articles:

• Zero Trust in Cloud Environments
• Penetration Testing Methodology
• Incident Response Playbook