Cloud Security - Sicherheit in AWS, Azure und GCP - Definition & Erklärung

Cloud Security ist eine der kritischsten und am meisten unterschätzten Sicherheitsherausforderungen: Der Angreifer muss nur eine falsch konfigurierte S3-Bucket finden - Unternehmen müssen Tausende richtig konfigurieren.

Shared Responsibility Model

AWS Shared Responsibility

AWS sichert (“Security OF the Cloud”):

Physische Rechenzentren, Hardware, Netzwerkinfrastruktur
Hypervisor, Host-Betriebssystem
Basis-Dienste (S3-Infrastruktur, EC2-Hardware)

Kunde sichert (“Security IN the Cloud”):

Betriebssystem auf EC2 (Patches!)
Anwendungscode
Konfiguration der AWS-Services
Datenverschlüsselung (at rest + in transit)
IAM-Berechtigungen (wer darf was?)
Netzwerkkonfiguration (Security Groups, NACLs)
Daten und Backups

Fehlverständnis-Problem: 99% der Cloud-Sicherheitsvorfälle sind Kundenfehler - AWS/Azure wurden NICHT gehackt. Gartner: “Bis 2025: 99% aller Cloud-Sicherheitsvorfälle durch Kundenfehler verursacht.”

Verantwortung nach Service-Typ

Service-Typ	Beispiele	Kunde verantwortlich für
IaaS (Infrastructure as a Service)	AWS EC2, Azure VMs	OS, Middleware, Apps, Daten, Config
PaaS (Platform as a Service)	AWS RDS, Azure App Service	Apps, Daten, Konfiguration (kein OS-Patching!)
SaaS (Software as a Service)	Microsoft 365, Salesforce	Daten, Zugänge, Konfiguration - ACHTUNG: eigenes Backup!

Häufigste Cloud-Fehlkonfigurationen

S3-Bucket Fehlkonfigurationen (AWS)

Public Read: sensible Daten für alle sichtbar
Public Write: jeder kann Dateien hochladen (Kosten, Inhalte!)
No Encryption: Daten unverschlüsselt gespeichert

# Prüfung:
aws s3api get-bucket-policy --bucket mein-bucket
aws s3api get-bucket-acl --bucket mein-bucket

# Fix - S3 Block Public Access (Account-Level):
aws s3control put-public-access-block \
    --account-id 123456789012 \
    --public-access-block-configuration \
    "BlockPublicAcls=true,IgnorePublicAcls=true,\
    BlockPublicPolicy=true,RestrictPublicBuckets=true"

Security Group Fehlkonfigurationen

KRITISCH: SSH (Port 22) offen für 0.0.0.0/0
KRITISCH: RDP (Port 3389) offen für 0.0.0.0/0
KRITISCH: Alle Ports offen für 0.0.0.0/0

# Prüfung:
aws ec2 describe-security-groups --query \
    "SecurityGroups[?IpPermissions[?IpRanges[?CidrIp=='0.0.0.0/0']]]"

# Fix: Bastion Host + SSH nur aus bekannten IPs:
aws ec2 revoke-security-group-ingress \
    --group-id sg-xxx --protocol tcp --port 22 --cidr 0.0.0.0/0
aws ec2 authorize-security-group-ingress \
    --group-id sg-xxx --protocol tcp --port 22 --cidr 10.0.1.0/24

IAM-Fehlkonfigurationen

KRITISCH: Root-Account ohne MFA
KRITISCH: Access Keys für Root-Account
KRITISCH: IAM User mit AdministratorAccess (braucht wirklich ALLES?)
KRITISCH: IAM Keys in Code (GitHub!) committet

# Prüfung Root-MFA:
aws iam get-account-summary | grep AccountMFAEnabled
# Sollte: 1 (aktiv) nicht 0 (inaktiv!)

# IAM Credential Report:
aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 -d
# Zeigt: alle User, letzte Nutzung, MFA-Status, Keys

Fehlende Verschlüsselung

EBS-Volumes unverschlüsselt
RDS ohne Storage Encryption
S3 ohne SSE-KMS
Lambda-Umgebungsvariablen mit Secrets (ohne KMS)

# Fix: Default Encryption aktivieren:
aws ec2 enable-ebs-encryption-by-default

CSPM - Cloud Security Posture Management

AWS Security Hub

Aggregiert Findings aus: AWS Config, GuardDuty, Inspector, Macie. Benchmarks: CIS AWS Foundations, AWS Foundational Security Best Practices.

# Aktivierung:
aws securityhub enable-security-hub \
    --enable-default-standards

Wichtige Controls (Beispiele):

[CIS] 1.1: Avoid root account usage
[CIS] 2.1: Ensure CloudTrail is enabled
[CIS] 2.3: Ensure CloudTrail log file validation is enabled
[FSBP] S3.1: S3 Block Public Access settings enabled

Microsoft Defender for Cloud

Azure + AWS + GCP (Multi-Cloud-CSPM!)
Secure Score: prozentualer Sicherheitsstatus
Empfehlungen: priorisiert nach Impact
Compliance: CIS, ISO 27001, PCI DSS, NIST
Integration: Microsoft Sentinel (SIEM)

Wiz (Next-Gen CSPM)

Agentless: kein Agent installieren!
Graph-basiert: zeigt Angriffspfade quer durch Cloud
Findet kombinierte Risiken (fehlende MFA + permissive SG + public S3)
“Attack Path”: “S3 public → Instanz-Metadata → IAM Admin”

Prisma Cloud (Palo Alto)

CSPM + CWPP (Workload Protection) + CIEM kombiniert
Code Security: Terraform/CloudFormation vor Deployment scannen
Shift-Left: Fehlkonfigurationen in der Pipeline erkennen

Open Source Tools

# Prowler:
pip install prowler
prowler aws -M csv json-asff html
# Prüft 300+ Controls für AWS

# ScoutSuite:
pip install scoutsuite
scout aws
# Multi-Cloud: AWS, Azure, GCP, Alibaba

Cloud Penetration Testing

Recon / Enumeration

Öffentliche S3-Buckets des Unternehmens: grayhatwarfare.com oder aws s3 ls s3://unternehmen-*
Subdomain-Takeover: CNAME auf nicht-existente Cloud-Ressource
DNS: welche Cloud-IPs werden genutzt?
Certificate Transparency: welche Subdomains?

IAM-Analyse (mit Kunde-Credentials)

Welche Berechtigungen hat der Test-User?
Privilege Escalation möglich? (IAM Playground von Rhino Security)
Ungenutzte Berechtigungen (Access Analyzer)
PassRole-Recht: potenzielle Eskalation

# IAM Simulator:
aws iam simulate-principal-policy \
    --policy-source-arn arn:aws:iam::123456789012:user/test \
    --action-names s3:PutObject iam:CreateUser

Metadata Service (SSRF-Angriff)

EC2 Instance Metadata Service (IMDSv1) ist via SSRF angreifbar - http://169.254.169.254/latest/meta-data/iam/security-credentials/ gibt temporäre Credentials des EC2-Roles zurück.

# Fix: IMDSv2 erzwingen (PUT-Anfrage, Token erforderlich):
aws ec2 modify-instance-metadata-options \
    --instance-id i-xxx \
    --http-tokens required \
    --http-endpoint enabled

Container Security (ECS/EKS)

Öffentliche Container-Images: bekannte Schwachstellen?
Pod Security: privilegierte Container?
Kubernetes RBAC: zu breite Berechtigungen?
Secrets in Kubernetes Secrets (unverschlüsselt in etcd!)

Typische Findings

S3-Bucket mit internen Backups: public readable
EC2 mit IMDSv1: SSRF → temporäre AWS-Credentials
Lambda-Funktion: Secrets in Umgebungsvariablen (kein KMS)
RDS: Security Group erlaubt 0.0.0.0/0 auf Port 3306
IAM User: AdministratorAccess + kein MFA + 2-Jahre alter Key
CloudTrail: nicht in allen Regionen aktiviert (blind spots!)