CompTIA SY0-701: Cloud-, Virtualisierungs- & Container-Sicherheit — Lernleitfaden

By Laurynas Brazys · 20 July 2026 · #comptia #sy0-701 #certification #exam-prep #study-guide

Teil des CompTIA Security+ SY0-701 — Lernleitfaden. Üben Sie mit verifizierten Antworten im CompTIA-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Moderne Unternehmen agieren selten in einem einzigen, in sich geschlossenen Rechenzentrum. Workloads erstrecken sich über Public-Cloud-Anbieter, private Virtualisierungscluster, Container-Orchestrierungsplattformen und ephemere Serverless-Funktionen. Jede Abstraktionsebene verändert das Bedrohungsmodell, die Kontrolloberfläche und – ganz entscheidend – wer für welche Sicherheitskontrollen verantwortlich ist.

Das Modell der geteilten Verantwortung (Shared Responsibility Model)

Jeder große Cloud-Anbieter veröffentlicht ein „Shared Responsibility Model“, das die Sicherheitsaufgaben zwischen dem Kunden und dem Cloud Service Provider (CSP) aufteilt. Die Trennlinie verschiebt sich je nach Service-Modell.

Bei Infrastructure as a Service (IaaS) – Amazon EC2, Azure Virtual Machines, Google Compute Engine – sichert der CSP die physischen Einrichtungen, die Hardware, den Hypervisor und die Netzwerkinfrastruktur. Alles oberhalb des Hypervisors liegt in der Verantwortung des Kunden: das Gastbetriebssystem, Patching, hostbasierte Firewalls, Middleware, Laufzeitumgebung, Anwendungscode, Identitätskonfiguration und die Daten selbst. Wenn ein Unternehmen eine MySQL-Datenbank auf einer EC2-Instanz bereitstellt, liegt die Absicherung dieser Datenbank vollständig in der Verantwortung des Kunden.

Bei Platform as a Service (PaaS) – AWS RDS, Azure App Service, Google App Engine – verwaltet der Anbieter zusätzlich das Betriebssystem, das Patching der Datenbank-Engine und die Laufzeitumgebung. Der Kunde bleibt für den Anwendungscode, die Datenklassifizierung, die Zugriffskontrollen, die Regeln für die Netzwerkverfügbarkeit und das Identitätsmanagement verantwortlich.

Bei Software as a Service (SaaS) – Microsoft 365, Salesforce, Workday – übernimmt der Anbieter fast den gesamten Stack. Die verbleibenden Verantwortlichkeiten des Kunden sind nicht trivial: die Bereitstellung und Aufhebung von Konten, die Durchsetzung von MFA, die Datenklassifizierung, Freigabeberechtigungen, die DLP-Konfiguration und die Integration mit dem unternehmenseigenen Identity Provider. Eine falsch konfigurierte SharePoint-Seite, die Gehaltsdaten für „Jeder“ zugänglich macht, ist keine Sicherheitsverletzung seitens Microsoft – sie liegt in der Verantwortung des Mandanten-Administrators.

Ein hartnäckiges Missverständnis ist, dass die Migration in die Cloud die gesamte Sicherheitsverantwortung auf den Anbieter überträgt. Datenpannen, die auf falsch konfigurierte S3-Buckets, exponierte Elasticsearch-Cluster und durchgesickerte API-Schlüssel zurückzuführen sind, lassen sich fast ausnahmslos auf Fehler auf Kundenseite zurückführen, nicht auf eine Kompromittierung des CSP.

Virtualisierung und Hypervisor-Risiken

Virtualisierung bündelt physische Hardware mithilfe eines Hypervisors in logische Gastsysteme. Typ-1-Hypervisoren (Bare-Metal) wie VMware ESXi, Microsoft Hyper-V und KVM laufen direkt auf der Hardware. Typ-2-Hypervisoren (Hosted) wie VirtualBox laufen auf einem allgemeinen Betriebssystem und sind für Produktions-Workloads ungeeignet.

Die dominanten virtualisierungsspezifischen Bedrohungen sind VM Escape und die Kompromittierung des Hypervisors. Ein VM Escape tritt auf, wenn bösartiger Code innerhalb eines Gastsystems aus seiner Virtualisierungsgrenze ausbricht und auf dem Hypervisor oder einer benachbarten VM ausgeführt wird. Historische Beispiele sind CVE-2015-3456 (VENOM, im Floppy-Controller von QEMU) und verschiedene Schwachstellen in den VMware Tools. Da ein einzelner Hypervisor Hunderte von Workloads über mehrere Vertrauenszonen hinweg hosten kann, ermöglicht ein erfolgreicher Ausbruch einen unverhältnismäßig großen Zugriff.

Zu den Gegenmaßnahmen gehören rigoroses Patching des Hypervisors, die Minimierung von Gasterweiterungen und ungenutzter emulierter Hardware, die Trennung von Workloads nach Sensitivität auf unterschiedliche Cluster und die Isolierung der Verwaltungsebene (Management Plane). Der vCenter-Server, die ESXi-Management-Schnittstellen und die Cluster-APIs müssen sich in einem dedizierten Verwaltungsnetzwerk befinden, das nur von privilegierten Jump-Hosts mit MFA erreichbar ist.

Weitere Bedenken sind der VM-Wildwuchs (verwaiste, ungepatchte VMs, die sich im Laufe der Zeit ansammeln) und die Ressourcen-Wiederverwendung, bei der Speicher oder Storage einer stillgelegten VM nicht ordnungsgemäß genullt wird, bevor er einem anderen Mandanten zugewiesen wird.

Container, Microservices und Kernel-Sharing

Container bündeln eine Anwendung mit ihren Abhängigkeiten, teilen sich aber im Gegensatz zu VMs den Kernel des Host-Betriebssystems. Docker, containerd und CRI-O verwalten die Lebenszyklen von Containern; Kubernetes orchestriert sie im großen Maßstab. Diese leichtgewichtige Isolation ist ein Vorteil – Start in Millisekunden, dichte Packung – aber auch das primäre Risiko.

Container-Isolation ist nicht gleichbedeutend mit VM-Isolation. Eine aus einem Container heraus ausgenutzte Kernel-Schwachstelle kann den Host und jeden anderen Container darauf kompromittieren. Namespaces (PID, Network, Mount, UTS, IPC, User) und cgroups bieten zwar Isolation, aber es handelt sich um Software-Konstrukte, die sich eine einzige Angriffsfläche teilen.

Containersicherheit erfordert Kontrollen über die gesamte Pipeline hinweg:

# Example: Pod security context enforcing hardening
securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false
  capabilities:
    drop: ["ALL"]
  seccompProfile:
    type: RuntimeDefault

Images müssen vor dem Deployment auf Schwachstellen gescannt werden (Trivy, Snyk, Clair), aus minimalen Basis-Images (Distroless oder Alpine) erstellt und nur aus vertrauenswürdigen Registries bezogen werden, bei denen die Signaturprüfung für Images erzwungen wird (Cosign, Notary). Laufzeitschutz-Tools (Falco, Aqua, Sysdig) überwachen das Verhalten von Containern und warnen bei Anomalien wie unerwarteter Prozessausführung oder Netzwerkverbindungen.

Cloud Security Posture und IAM

Cloud IAM unterscheidet sich in wichtigen Punkten vom lokalen Active Directory. In AWS sind IAM-Richtlinien JSON-Dokumente, die an Benutzer, Gruppen oder Rollen angehängt werden. Die effektive Berechtigung ist die Schnittmenge aus identitätsbasierten und ressourcenbasierten Richtlinien, wobei explizite Ablehnungen (Denies) immer Vorrang haben:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject"],
    "Resource": "arn:aws:s3:::company-data/*",
    "Condition": {
      "StringEquals": {"aws:RequestedRegion": "us-east-1"}
    }
  }]
}

Cloud Security Posture Management (CSPM)-Tools scannen Cloud-Konfigurationen kontinuierlich anhand von Sicherheits-Benchmarks (CIS AWS Foundations, NIST) und melden öffentliche S3-Buckets, zu freizügige Security Groups, deaktiviertes CloudTrail-Logging und unverschlüsselte EBS-Volumes. Cloud Access Security Broker (CASBs) sitzen zwischen Benutzern und Cloud-Diensten und setzen DLP, Zugriffsrichtlinien und Bedrohungserkennung für SaaS-Anwendungen durch.

Praxisszenario: Fehlkonfigurierter S3-Bucket legt PII offen

Ein Startup im Gesundheitswesen speicherte Formulare zur Patientenaufnahme in einem S3-Bucket, der während eines Entwicklungs-Sprints mit öffentlichem Lesezugriff erstellt und vor der Inbetriebnahme in der Produktionsumgebung nie abgesichert wurde. Der Bucket wurde von einem Sicherheitsforscher durch eine Kombination aus DNS-Brute-Forcing und der AWS-S3-Bucket-Enumeration-Technik entdeckt. Etwa 87.000 Patientendatensätze – einschließlich Namen, Geburtsdaten, Versicherungsnummern und Beschreibungen der Hauptbeschwerden – waren ohne Authentifizierung zugänglich. Das Startup verfügte über kein CSPM-Tool und kein automatisiertes Scannen der Konfiguration. Eine einfache AWS-Config-Regel, die auf s3-bucket-public-read-prohibited prüft, hätte die Fehlkonfiguration innerhalb von Minuten nach der Erstellung gemeldet. Der Vorfall führte zu einer Untersuchung durch das HHS, einem Vergleich in Höhe von 450.000 US-Dollar und einem Reputationsschaden, der zur Übernahme des Unternehmens zu einer notleidenden Bewertung beitrug.

← Anwendungs- · Alle Domänen · Datensicherheit →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →