Cloud Computing — Architektur, Angriffsvektoren & Insider-Wissen

Was ist Cloud Computing? — IaaS, PaaS und SaaS

Cloud Computing bezeichnet die bedarfsgerechte Bereitstellung von IT-Ressourcen über das Internet. Das National Institute of Standards and Technology (NIST) definiert fünf wesentliche Merkmale: On-Demand Self-Service, Broad Network Access, Resource Pooling, Rapid Elasticity und Measured Service. Diese Eigenschaften unterscheiden echtes Cloud Computing von klassischem Hosting oder Colocation. Was viele nicht wissen: Die fünfte Eigenschaft — Measured Service — bedeutet, dass der Cloud-Anbieter jede einzelne API-Operation, jeden Netzwerk-Byte und jede Speicher-Millisekunde misst. Diese Granularität ist sowohl Stärke (präzise Abrechnung) als auch Risiko (unerwartete Kosten durch Fehlkonfigurationen).

Die drei grundlegenden Service-Modelle definieren, welche Schichten des IT-Stacks der Anbieter verwaltet und welche beim Kunden verbleiben. Das Shared Responsibility Model ist dabei das am häufigsten missverstandene Konzept in der Cloud-Sicherheit: Viele Unternehmen glauben, der Cloud-Anbieter sei für die Sicherheit ihrer Daten verantwortlich — das ist falsch. Der Anbieter sichert die Infrastruktur („Security of the Cloud“), der Kunde ist für alles verantwortlich, was er in der Cloud betreibt („Security in the Cloud“).

• Infrastructure as a Service (IaaS): Der Anbieter stellt virtualisierte Hardware bereit — virtuelle Maschinen, Netzwerke, Storage und Load Balancer. Der Kunde verwaltet Betriebssystem, Middleware und Anwendungen selbst. Beispiele: Azure Virtual Machines, AWS EC2, Google Compute Engine. Insider-Wissen: IaaS-VMs sind standardmäßig nicht gehärtet — Marketplace-Images enthalten oft veraltete Pakete, offene Ports und Default-Credentials. Der erste Schritt nach dem Provisioning muss immer ein CIS Benchmark Hardening sein.
• Platform as a Service (PaaS): Zusätzlich zur Infrastruktur verwaltet der Anbieter Betriebssystem, Laufzeitumgebung und Middleware. Der Kunde konzentriert sich ausschließlich auf seine Anwendung und deren Daten. Beispiele: Azure App Service, AWS Elastic Beanstalk, Google App Engine. Insider-Wissen: PaaS-Dienste loggen standardmäßig keine Anwendungsfehler — ohne explizite Konfiguration von Application Insights / CloudWatch Logs bleiben Angriffe unsichtbar.
• Software as a Service (SaaS): Der Anbieter betreibt die vollständige Anwendung. Beispiele: Microsoft 365, Salesforce, Google Workspace. Insider-Wissen: SaaS-Sicherheit scheitert fast immer an OAuth-App-Berechtigungen. Benutzer genehmigen Drittanbieter-Apps mit weitreichenden Rechten (Mail.Read, Files.ReadWrite.All) — sogenanntes Illicit Consent Grant. Eine einzige genehmigte bösartige App kann sämtliche E-Mails und Dateien exfiltrieren, ohne dass MFA hilft.
• Shared Responsibility Model — die Realität: Bei IaaS liegt ~75 % der Sicherheitsverantwortung beim Kunden, bei SaaS ~25 %. Aber Identitäts- und Zugriffsmanagement bleibt IMMER Kundensache — egal welches Modell. Der häufigste Fehler: Unternehmen migrieren in die Cloud und gehen davon aus, dass der Anbieter ihre Daten sichert. Microsoft 365 hat standardmäßig KEIN Backup — gelöschte E-Mails und Dateien sind nach der Retention-Periode (93 Tage) unwiderruflich verloren. Ein Drittanbieter-Backup (Veeam for M365, AvePoint) ist zwingend erforderlich.

Deployment-Modelle — Public, Private, Hybrid und Multi-Cloud

Neben dem Service-Modell bestimmt das Deployment-Modell, wo und wie die Cloud-Infrastruktur betrieben wird. Die Wahl hängt von Anforderungen an Datenschutz, Compliance, Latenz und Kosten ab.

In einer Public Cloud teilen sich mehrere Mandanten (Tenants) die physische Infrastruktur eines Anbieters. Die Isolation erfolgt über Virtualisierung und Netzwerksegmentierung. Microsoft Azure betreibt über 60 Rechenzentrumsregionen weltweit, darunter mehrere in Deutschland (West Central Germany, Germany North) mit EU-Datenresidenz. Insider-Wissen: Die meisten Kunden wissen nicht, dass Azure Availability Zones innerhalb einer Region nur 5–15 km voneinander entfernt sind. Für echte Georedundanz (Brand, Naturkatastrophe) ist ein Cross-Region-Deployment (z. B. Germany West Central + Switzerland North) erforderlich — nicht nur Multi-AZ.

Die Hybrid Cloud kombiniert Public und Private Cloud zu einer integrierten Umgebung. Azure Arc ermöglicht die einheitliche Verwaltung von On-Premises-, Multi-Cloud- und Edge-Ressourcen über eine zentrale Steuerungsebene. Insider-Wissen: Azure Arc ist kostenlos für die reine Verwaltung (Inventory, Policy, Tagging) — Kosten entstehen erst bei der Nutzung von Arc-fähigen Diensten (Arc SQL, Arc Kubernetes). Die meisten Unternehmen zahlen unnötig für separate Management-Tools, obwohl Arc ihre gesamte hybride Infrastruktur kostenlos zentralisieren könnte.

Multi-Cloud-Strategien nutzen bewusst mehrere Anbieter gleichzeitig. Insider-Wissen: Echte Multi-Cloud ist extrem teuer und komplex. Jeder Anbieter hat eigene IAM-Modelle, Netzwerkkonzepte und APIs. Die meisten „Multi-Cloud-Strategien“ sind in Wahrheit Multi-SaaS (M365 + Salesforce + AWS S3) — was völlig anders ist als Multi-IaaS. Für KMU empfehlen wir: Einen IaaS-Anbieter wählen, Best-of-Breed-SaaS kombinieren, Terraform für Portabilität.

Cloud-Angriffsvektoren — was Penetration Tester wirklich finden

Cloud-Angriffe unterscheiden sich fundamental von On-Premises-Angriffen. Statt Netzwerk-Exploitation und Lateral Movement über SMB/RDP fokussieren Cloud-Angreifer auf Identitäten, APIs und Fehlkonfigurationen. MITRE hat mit der ATT&CK Cloud Matrix ein eigenes Framework für Cloud-spezifische Angriffstechniken entwickelt, und die Cloud Security Alliance (CSA) veröffentlicht jährlich die „Top Threats to Cloud Computing“. Was auf Pentests in echten Cloud-Umgebungen am häufigsten gefunden wird, überrascht selbst erfahrene Admins.

• IAM Privilege Escalation (die #1-Schwachstelle): In Azure: Ein Benutzer mit User Access Administrator-Rolle kann sich selbst zum Owner jeder Subscription machen — und damit zum globalen Admin. In AWS: iam:PassRole + lambda:CreateFunction = jeder IAM-Benutzer mit diesen beiden scheinbar harmlosen Rechten kann eine Lambda-Funktion mit Admin-Rolle erstellen und damit beliebige Aktionen ausführen. Tools: Pacu (AWS), ROADtools + AzureHound (Azure), ScoutSuite (Multi-Cloud). Insider-Tipp: Führen Sie az ad sp list --all aus — die Anzahl der Service Principals mit Application-Rechten wird Sie erschrecken. Jeder einzelne ist ein potenzieller Angriffsvektor.
• IMDS-Exploitation (Instance Metadata Service): Jede Cloud-VM hat Zugriff auf einen Metadata-Service unter http://169.254.169.254. Dieser liefert auf Anfrage temporäre IAM-Credentials der VM-Rolle. Ein SSRF-Bug (Server-Side Request Forgery) in einer Webanwendung genügt, um diese Credentials zu stehlen. Capital One Breach (2019): 106 Millionen Kundendaten gestohlen über genau diesen Vektor (SSRF → IMDS → S3-Zugriff). Verteidigung: IMDSv2 (AWS, erfordert PUT-Request mit Session-Token), Azure Managed Identities mit Conditional Access, Network Policies die den IMDS blockieren.
• Storage Bucket Misconfiguration: Öffentlich zugängliche S3-Buckets / Azure Blob Containers sind nach wie vor einer der häufigsten Cloud-Sicherheitsvorfälle. Insider-Wissen: Auch „private“ Buckets können unsicher sein — wenn die Bucket-Policy einen Principal: "*" oder Condition mit unbeabsichtigtem CIDR-Range enthält. Tools wie S3Scanner, BucketFinder und cloud_enum finden öffentliche Buckets automatisch. Azure-spezifisch: Shared Access Signatures (SAS-Tokens) mit zu langen Ablaufzeiten sind eine versteckte Backdoor — sie gewähren Zugriff ohne Azure-AD-Authentifizierung und können nicht widerrufen werden (nur durch Key-Rotation des Storage Accounts).
• Cross-Tenant-Angriffe über Azure Lighthouse / AWS Organizations: Azure Lighthouse ermöglicht Managed Service Providern die Verwaltung von Kunden-Subscriptions. Ein kompromittierter MSP-Tenant gewährt sofortigen Zugriff auf alle verwalteten Kunden. Der SolarWinds-Angriff nutzte genau dieses Prinzip (kompromittierter Anbieter → Zugriff auf Kundendaten). Verteidigung: Minimale Lighthouse-Delegierungen, Conditional Access für Cross-Tenant-Zugriff, regelmäßiges Audit der delegierten Berechtigungen mit az managedservices assignment list.
• Cryptojacking — illegales Mining auf Ihrer Rechnung: Angreifer, die Cloud-Credentials kompromittieren, starten oft GPU-Instanzen (P4d, NC-Series) für Kryptowährungs-Mining. Insider-Wissen: Ein einzelner p4d.24xlarge (AWS) kostet 32,77 USD pro Stunde — das sind 23.600 USD pro Monat. Angreifer starten diese in allen verfügbaren Regionen gleichzeitig. Ohne Billing Alerts und Service Quotas kann eine kompromittierte Account in einem Wochenende sechsstellige Kosten verursachen. Setzen Sie Budget-Alerts bei 120 % des Monatsbudgets und maximale Quota-Limits für GPU-Instanzen auf 0 in allen ungenutzten Regionen.

Tödliche Fehlkonfigurationen — die Top 10, die Cloud-Admins übersehen

Laut dem Verizon Data Breach Investigations Report 2025 sind 82 % aller Cloud-Sicherheitsvorfälle auf Fehlkonfigurationen zurückzuführen — nicht auf Zero-Day-Exploits oder APT-Gruppen. Die folgenden Fehlkonfigurationen finden wir in nahezu jeder Cloud-Umgebung, die wir auditieren. Jede einzelne kann zum vollständigen Verlust der Kontrolle über die Cloud-Umgebung führen.

• #1 — Keine MFA für den Root/Global Admin Account: Der AWS Root Account und der Azure Global Administrator sind die mächtigsten Identitäten — und werden in über 40 % der Umgebungen ohne MFA betrieben. Ein einziges kompromittiertes Passwort = vollständige Übernahme. Fix: Hardware-FIDO2-Key (YubiKey), kein SMS-OTP. Root Account nur für initiales Setup verwenden, dann wegschließen (Break-Glass-Prozedur).
• #2 — Overprivileged Service Principals / IAM Roles: Service Accounts mit Owner/Contributor/AdministratorAccess-Rechten sind die Norm, nicht die Ausnahme. In einer typischen Azure-Subscription finden wir 15–30 Service Principals mit Contributor-Rolle — davon werden 80 % nie genutzt. Fix: Least Privilege mit Custom Roles, Azure AD PIM (Privileged Identity Management) für Just-in-Time-Aktivierung, regelmäßige Access Reviews.
• #3 — Kein Activity Logging / CloudTrail deaktiviert: Ohne Azure Activity Log (an Log Analytics Workspace gesendet), AWS CloudTrail (an S3 mit Integrity Validation) oder GCP Cloud Audit Logs gibt es keine Forensik-Möglichkeit nach einem Vorfall. Insider-Tipp: CloudTrail Management Events sind kostenlos — Data Events (S3 Object-Level, Lambda Invocations) kosten extra, sind aber für Incident Response unverzichtbar. Minimum: Management Events + S3 Data Events für sensitive Buckets.
• #4 — Öffentliche Netzwerk-Exposition ohne NSG/Security Groups: VMs mit öffentlicher IP und offenem SSH (22) / RDP (3389) sind die niedrig hängendsten Früchte. Shodan und Censys indizieren neue Cloud-VMs innerhalb von Minuten nach dem Provisioning. Brute-Force-Angriffe beginnen sofort. Fix: Keine öffentlichen IPs auf VMs. Azure Bastion oder AWS Systems Manager Session Manager für sicheren Zugriff ohne offene Ports.
• #5 — Unverschlüsselte Daten at Rest: Azure-Storage-Accounts und AWS S3-Buckets verschlüsseln standardmäßig mit platform-managed Keys — das schützt gegen physischen Diebstahl der Festplatten, aber nicht gegen unautorisierte API-Zugriffe (der Anbieter entschlüsselt automatisch). Für echten Schutz: Customer-Managed Keys (CMK) mit Azure Key Vault / AWS KMS, und Key-Rotation alle 90 Tage. Noch besser: Client-Side Encryption — Daten werden vor dem Upload verschlüsselt, der Anbieter sieht nur Ciphertext.
• #6 — Vergessene Sandbox-/Dev-Subscriptions mit Produktionsdaten: Entwickler kopieren Produktionsdatenbanken in Dev-Umgebungen für Tests — mit echten Kundendaten, aber ohne die Sicherheitskontrollen der Produktion. Diese Dev-Subscriptions haben oft offene NSGs, keine Verschlüsselung und Contributor-Zugriff für das gesamte Dev-Team. Fix: Daten-Maskierung für Dev/Test, Azure Policy zur Durchsetzung von Sicherheitsstandards in allen Subscriptions, Management Groups mit vererbten Policies.

Kosten-Insider-Wissen — was Cloud-Anbieter nicht erzählen

Die Cloud-Rechnung ist für die meisten Unternehmen eine Black Box. 30–40 % der Cloud-Ausgaben sind verschwendet (Flexera State of the Cloud Report 2025) — durch überdimensionierte Instanzen, vergessene Ressourcen und fehlende Optimierung. Die folgenden Insider-Tipps sparen in einer typischen KMU-Umgebung 30–50 % der monatlichen Cloud-Kosten.

• Reserved Instances vs. Savings Plans vs. Spot: Reserved Instances (RI) bieten 30–72 % Rabatt bei 1- oder 3-Jahres-Bindung — aber nur für eine spezifische Instanzgröße in einer spezifischen Region. Savings Plans (AWS/Azure) bieten ähnliche Rabatte, sind aber flexibel über Instanzgrößen und Regionen — für die meisten Workloads die bessere Wahl. Spot/Low-Priority Instances bieten bis zu 90 % Rabatt, können aber jederzeit unterbrochen werden — ideal für Batch-Jobs, CI/CD-Pipelines und Rendering. Insider-Tipp: Kombinieren Sie alle drei: Savings Plan für die Baseline, Reserved Instances für stabile Workloads, Spot für Bursts.
• Die versteckte Egress-Kosten-Falle: Daten hochladen in die Cloud: kostenlos. Daten herunterladen: teuer. AWS berechnet 0,09 USD/GB für Daten-Egress, Azure 0,087 USD/GB. Bei 10 TB/Monat sind das 900 USD — nur für den Download. Cross-Region-Traffic (z. B. Backup-Replikation) und Cross-AZ-Traffic kosten ebenfalls — ein oft übersehener Posten. Fix: CDN (CloudFront/Azure CDN) für statische Inhalte, VPC Endpoints / Private Link für internen Traffic (eliminiert Egress-Kosten für S3/Storage-Zugriffe), und Wasabi oder Backblaze B2 als kostengünstige Alternativen für Backup-Storage (kein Egress-Kosten).
• Rightsizing — die einfachste Einsparung: 40–60 % aller Cloud-VMs sind überdimensioniert (Azure Advisor / AWS Compute Optimizer bestätigen dies). Ein Standard_D4s_v5 (4 vCPU, 16 GB RAM) kostet 140 EUR/Monat — wenn die CPU-Auslastung konstant unter 20 % liegt, reicht ein Standard_B2ms (2 vCPU, 8 GB RAM, Burstable) für 60 EUR/Monat. Insider-Tipp: B-Series/Burstable Instances sind für die meisten Webserver und Anwendungsserver die richtige Wahl — sie kosten 40–60 % weniger als Compute-optimierte Instanzen und bieten CPU-Bursts bei Bedarf.
• Zombie-Ressourcen eliminieren: Unattached Managed Disks (Festplatten ohne VM) — kosten weiterhin. Snapshots älter als 90 Tage — vergessene Momentaufnahmen summieren sich. Idle Load Balancers ohne Backend-Targets — 18 EUR/Monat pro Stück. Ungenutzte Elastic IPs (AWS) — 3,60 USD/Monat pro IP. Alte Generationen — VMs auf v3/v4-Instanzen statt aktueller v5/v6 (20–30 % günstiger bei besserer Performance). Automation: Azure Advisor, AWS Cost Explorer + Trusted Advisor, oder Open-Source-Tools wie Infracost und cloud-custodian.
• Dev/Test-Umgebungen zeitgesteuert abschalten: Entwicklungs- und Testumgebungen laufen oft 24/7, werden aber nur 8–10 Stunden am Tag genutzt. Auto-Shutdown außerhalb der Geschäftszeiten (18:00–08:00 + Wochenende) spart 65 % der Kosten für diese VMs. Azure: Auto-Shutdown direkt in der VM-Konfiguration oder Azure DevTest Labs. AWS: Instance Scheduler (CloudFormation-Template von AWS). Insider-Tipp: Erstellen Sie einen Slack/Teams-Bot, der morgens die Dev-Umgebung hochfährt und abends runterfährt — Entwickler müssen nichts manuell tun.

Cloud-Härtung — die nicht-verhandelbaren Sicherheitsmaßnahmen

Basierend auf dem CIS Cloud Benchmarks, dem BSI C5-Katalog und unserer Erfahrung aus hunderten Cloud-Audits sind die folgenden Maßnahmen die nicht-verhandelbaren Grundlagen jeder sicheren Cloud-Umgebung. Ohne diese Maßnahmen ist es nicht die Frage, ob die Cloud kompromittiert wird, sondern wann.

• Conditional Access als Cloud-Firewall: Conditional Access (Azure AD/Entra ID) ersetzt in der Cloud die klassische Netzwerk-Firewall: Statt IP-basierter Regeln steuert CA den Zugriff basierend auf Identität, Gerät, Standort, Risiko und Anwendung. Minimum-Policies: MFA für alle Benutzer, Block Legacy Authentication (IMAP, POP3, SMTP Auth — unterstützen kein MFA!), Require Compliant Device für Admin-Portale, Block High-Risk Sign-ins (Identity Protection). Insider-Tipp: Erstellen Sie eine „Break Glass“-Policy — einen Cloud-Admin-Account mit phishing-resistentem FIDO2 und ohne Conditional Access, für den Notfall, wenn CA selbst das Problem ist.
• Landing Zone — das Fundament: Bevor die erste Ressource deployt wird, muss eine Cloud Landing Zone eingerichtet werden: Management Groups (Hierarchie für Subscriptions), Azure Policy / AWS SCP (Service Control Policies für Guardrails), Hub-Spoke-Netzwerk (zentraler Hub mit Firewall, Spokes für Workloads), Log Analytics / CloudTrail (zentrales Logging), Defender for Cloud / Security Hub (CSPM). Microsofts Azure Landing Zone Accelerator und AWS Control Tower automatisieren dieses Setup. Insider-Tipp: Die Landing Zone nachträglich einzuführen ist 10x teurer als von Anfang an — planen Sie sie vor dem ersten Workload.
• CSPM (Cloud Security Posture Management): Microsoft Defender for Cloud (ehem. Azure Security Center), AWS Security Hub, Prisma Cloud (Palo Alto), Wiz oder Orca scannen Ihre Cloud-Umgebung kontinuierlich auf Fehlkonfigurationen und bewerten sie gegen CIS Benchmark, NIST 800-53, ISO 27001, BSI C5. Insider-Tipp: Defender for Cloud Foundational CSPM ist kostenlos — es liefert bereits Security Score, Empfehlungen und Compliance-Dashboards ohne zusätzliche Kosten. Die kostenpflichtigen Pläne (Defender for Servers, Defender for Storage) lohnen sich für Produktionsworkloads.
• Infrastructure as Code (IaC) — Security by Default: Manuelle Konfiguration über das Portal ist der Hauptgrund für Fehlkonfigurationen. Terraform, Bicep (Azure) oder CloudFormation (AWS) kodifizieren die Infrastruktur und ermöglichen Code Review, Versionierung und automatisierte Security-Checks. tfsec, checkov und Snyk IaC scannen Terraform-Code vor dem Deployment auf Sicherheitslücken. Beispiel: checkov -d . --framework terraform findet öffentliche S3-Buckets, fehlende Verschlüsselung und offene Security Groups — bevor sie in Produktion gehen. Shift Left: Sicherheit in die CI/CD-Pipeline integrieren, nicht erst nach dem Deployment.
• DSGVO und Cloud — die juristischen Fallstricke: Die Verarbeitung personenbezogener Daten in der Cloud erfordert einen Auftragsverarbeitungsvertrag (AVV) gemäß Art. 28 DSGVO. Seit dem EU-US Data Privacy Framework (2023) ist der Datentransfer in die USA wieder möglich — aber nur an zertifizierte Unternehmen. Für besonders sensitive Daten (Gesundheit, Finanzen) empfiehlt sich BSI C5-Testat als Nachweis (Azure, AWS und Google sind C5-testiert). Insider-Tipp: Die EU Data Boundary (Microsoft, seit 2023) garantiert, dass Kundendaten von EU-Kunden die EU nie verlassen — auch nicht für Support oder Diagnostics. Dies ist für DSGVO-sensitive Branchen (Gesundheitswesen, öffentlicher Sektor) ein entscheidendes Argument.