Definitionen des Cloud-Computings
Das NIST (National Institute of Standards and Technology) hat mit der Special Publication 800-145 eine Definition geschaffen, die international als Referenz gilt. Sie beschreibt Cloud-Computing als ein Modell für den bedarfsorientierten Netzwerkzugriff auf einen gemeinsam genutzten Pool konfigurierbarer IT-Ressourcen: Netzwerke, Server, Speicher, Anwendungen und Dienste, die mit minimalem Verwaltungsaufwand oder Anbieterinteraktion schnell bereitgestellt und wieder freigegeben werden können.
Hauptmerkmale des Cloud-Computings
Diese Definition mag auf den ersten Blick abstrakt erscheinen, doch ihre wahre Bedeutung erschließt sich durch fünf charakteristische Merkmale, die einen Cloud-Dienst von traditioneller IT-Infrastruktur unterscheiden. Nur wenn alle fünf Merkmale erfüllt sind, spricht man nach NIST-Kriterien von einem echten Cloud-Service.
Die fünf Cloud-Merkmale im Detail
On-Demand Self-Service: Selbstständige Ressourcenbereitstellung
Das erste Merkmal beschreibt die Fähigkeit eines Nutzers, IT-Ressourcen eigenständig und automatisiert bereitzustellen, ohne dass ein Mitarbeiter des Anbieters eingreifen muss. Ein Administrator meldet sich z.B. bei Amazon Web Services oder Microsoft Azure an und startet innerhalb von Minuten virtuelle Maschinen, konfiguriert Speicher oder richtet Netzwerke ein – und das vollständig selbstständig über eine webbasierte Konsole oder API.
Diese Automatisierung ermöglicht enorme Agilität. Während die Beschaffung neuer Server in traditionellen IT-Umgebungen je nach Situation Wochen oder Monate dauern konnte, stehen Cloud-Ressourcen fast sofort zur Verfügung. Aus Sicherheitsperspektive bedeutet dies allerdings auch, dass Fehlkonfigurationen ebenso schnell entstehen können. Die hohe Bereitstellungsgeschwindigkeit muss daher durch entsprechende Kontrollen und Governance-Prozesse begleitet werden.
Broad Network Access: Universelle Netzwerkerreichbarkeit
Cloud-Dienste sind über standardisierte Netzwerkprotokolle nahezu überall erreichbar. Typischerweise erfolgt die Nutzung über HTTPS für Webanwendungen, SSH für den Remote-Zugriff auf Linux-Systeme oder RDP für Windows-Server. Die Dienste können von verschiedenen Endgeräten aus genutzt werden: PCs, Laptops, Tablets und Smartphones.
Diese globale Zugänglichkeit ist Fluch und Segen zugleich. Einerseits ermöglicht sie verteiltes Arbeiten und weltweite Zusammenarbeit. Andererseits erweitert sie die Angriffsfläche erheblich: Dienste, die über das öffentliche Internet erreichbar sind, müssen besonders gut gegen Angriffe geschützt werden. Die Netzwerksicherheit – von der Verschlüsselung des Datenverkehrs bis hin zur Zugriffskontrolle – wird dadurch zu einem zentralen Sicherheitsbaustein.
Resource Pooling: Gemeinsame Nutzung physischer Ressourcen
Beim sogenannten Resource Pooling stellt ein Cloud-Anbieter physische und virtuelle Ressourcen dynamisch für mehreren Kunden bereit. Viele Organisationen teilen sich dieselbe physische Infrastruktur, bestehend aus Servern, Speicher- und Netzwerkkomponenten, wobei jeder Kunde eine logisch isolierte Umgebung erhält.
Dieses Prinzip der Multimandantenfähigkeit ist zentral für die Wirtschaftlichkeit des Cloud-Computing. Cloud-Provider können durch die gemeinsame Nutzung ihrer Infrastruktur Größenvorteile realisieren und diese in Form niedrigerer Preise an ihre Kunden weitergeben. Gleichzeitig entstehen jedoch auch neue Sicherheitsanforderungen: Die Isolierung zwischen den Mandanten muss absolut zuverlässig sein. Ein Kunde darf unter keinen Umständen auf Daten oder Ressourcen eines anderen Kunden zugreifen.
Rapid Elasticity: Dynamische Skalierbarkeit
Cloud-Ressourcen können schnell nach oben und unten skaliert werden – sowohl manuell durch Administratoren als auch automatisch durch das System selbst. Eine virtuelle Maschine kann bei steigender Last zusätzliche Rechenleistung erhalten oder bei geringerer Auslastung herunterskaliert werden, um Kosten zu sparen.
Aus Nutzersicht erscheinen die Ressourcen praktisch unbegrenzt verfügbar. z.B. ein E-Commerce-System kann während einer Verkaufsaktion automatisch zusätzliche Server-Instanzen starten und diese nach Ende der Aktion wieder freigeben. Diese Elastizität unterscheidet Cloud-Computing fundamental von traditionellen IT-Umgebungen, in denen Kapazitäten fest eingeplant werden müssen.
Die Sicherheitsimplikationen sind erheblich: Neu gestartete Instanzen müssen sofort mit den aktuellen Sicherheitskonfigurationen versehen werden. Außerdem erschwert die ständige Fluktuation der Instanzen das Security Monitoring und die forensische Analyse im Falle eines Sicherheitsvorfalls.
Measured Service: Nutzungsbasierte Messung und Abrechnung
Ein Cloud-Service muss über Mechanismen verfügen, um die Ressourcennutzung automatisch zu messen, zu überwachen und transparent zu berichten. Dies umfasst die Erfassung des Speicherverbrauchs, der Rechenleistung, der Netzwerkbandbreite und anderer Metriken. Auf Basis dieser Messungen erfolgt die Abrechnung nach dem Pay-as-you-go-Prinzip: Der Kunde zahlt nur für die von ihm tatsächlich genutzten Ressourcen.
Ohne diese Messmechanismen wäre eine faire, nutzungsabhängige Abrechnung nicht möglich. Die Metriken sind aber auch für Sicherheits- und Compliance-Prüfungen relevant. Sie machen nachvollziehbar, wann welche Ressourcen von wem genutzt wurden und bilden somit eine wichtige Grundlage für Audits und forensische Untersuchungen.
Multi-Tenancy als ergänzendes Sicherheitsmerkmal
Obwohl Multi-Tenancy nicht Teil der offiziellen NIST-Definition ist, betrachten Sicherheitsexperten die Mehrmandantenfähigkeit als charakteristisches Merkmal des Cloud-Computing. Der Begriff beschreibt die Fähigkeit eines Systems, mehrere Kunden (Mandanten) gleichzeitig zu bedienen, wobei die Daten und Prozesse jedes Mandanten strikt voneinander getrennt sind.
In einer Public Cloud teilen sich zahlreiche Organisationen dieselben physischen Server. Der Cloud-Anbieter sorgt durch Virtualisierung und Isolierungsmechanismen dafür, dass keine Überschneidungen oder unzulässigen Zugriffe zwischen den Mandanten stattfinden.
Im Gegensatz dazu steht die Single-Tenant-Architektur, bei der ein Kunde dedizierte physische Ressourcen erhält. Dieses Modell wird von einigen Organisationen, insbesondere solchen mit hohen Sicherheits- oder Compliance-Anforderungen bevorzugt, trotz der höheren Kosten. Die meisten Private-Cloud-Implementierungen folgen diesem Ansatz.
Aus Sicherheitssicht ist Multi-Tenancy eine der größten Herausforderungen im Cloud-Computing. Die Isolierungsmechanismen müssen absolut zuverlässig funktionieren. Ein Fehler in der Hypervisor-Software oder in der Netzwerkkonfiguration könnte theoretisch dazu führen, dass ein Angreifer die Mandantengrenze überschreitet und auf fremde Daten zugreift (Tenant Escape).
Rollen und Verantwortlichkeiten beim Cloud-Computing
Cloud-Computing ist nicht nur eine technologische, sondern auch eine organisatorische Veränderung. Die klare Trennung zwischen Anbieter und Nutzer, die in traditionellen IT-Umgebungen existiert, löst sich auf. Stattdessen entsteht ein Ökosystem mit verschiedenen Akteuren, die unterschiedliche Rollen und Verantwortlichkeiten übernehmen.
Die „Hauptakteure“
Cloud Service Provider (CSP) ist ein Cloud-Anbieter, der Cloud-Infrastrukturen, -Plattformen oder -Anwendungen bereitstellt. Er ist verantwortlich für die physische Sicherheit der Rechenzentren, die Wartung der Hardware und die Netzwerkinfrastruktur. Je nach Service-Modell ist er auch für verschiedene Software-Schichten verantwortlich.
Cloud Service Consumer ist der Kunde und nutzt die vom Provider bereitgestellten Dienste. Er ist für die Sicherheit seiner Daten, die Konfiguration der genutzten Services und die Zugriffskontrolle für seine Benutzer verantwortlich. Die genaue Abgrenzung der Verantwortlichkeiten hängt vom gewählten Servicemodell ab und wird im Folgenden näher erläutert.
Cloud Service Broker tritt als Vermittler zwischen Providern und Kunden auf. In komplexen Multi-Cloud-Umgebungen, in denen Organisationen Services von mehreren Anbietern nutzen, können Broker einen Mehrwert schaffen, indem sie Services aggregieren, Kosten optimieren, das Management vereinheitlichen oder zusätzliche Sicherheitsfunktionen bieten. So könnte ein Broker beispielsweise eine einheitliche Verschlüsselungsschicht über verschiedene Cloud-Provider hinweg bereitstellen.
Cloud Service Auditor bewertet die Sicherheit, Compliance und Leistung von Cloud-Diensten. Diese Audits können intern durch die Organisation selbst oder extern durch unabhängige Dritte durchgeführt werden. Zertifizierungen wie ISO 27001, SOC 2/3 oder spezialisierte Cloud-Zertifizierungen basieren auf diesen Audits. Sie schaffen Vertrauen und ermöglichen es Organisationen, die Sicherheit ihrer Cloud-Provider objektiv zu beurteilen.
Cloud Carrier ist der Netzwerkbetreiber, der die Verbindung zwischen Provider und Kunde herstellt. Dies kann über das öffentliche Internet oder über dedizierte private Verbindungen wie AWS Direct Connect oder Azure ExpressRoute erfolgen. Der Carrier ist für die Verfügbarkeit und Performance der Netzwerkverbindung verantwortlich, nicht aber für die darüber übertragenen Daten oder Anwendungen.
Technologische Grundlagen der Cloud
Die charakteristischen Merkmale des Cloud-Computings werden durch spezifische Technologien ermöglicht. Drei Bereiche bilden dabei das technologische Fundament: Virtualisierung, Speicher- und Datenbanksysteme sowie Netzwerk und Orchestrierung.
Virtualisierung
Virtualisierung ist die zentrale Technologie, die Cloud-Computing überhaupt erst möglich macht. Sie erlaubt es, physische Hardware-Ressourcen logisch zu trennen und mehreren unabhängigen Systemen gleichzeitig bereitzustellen. Anstatt einen physischen Server nur für ein einzelnes Betriebssystem und eine Anwendung zu verwenden, können mehrere virtuelle Maschinen auf demselben physischen Host betrieben werden – jede mit eigenem Betriebssystem und eigener Softwareumgebung.
Die Trennung erfolgt durch eine Software-Schicht, den sogenannten Hypervisor. Bekannte Implementierungen sind VMware ESXi, Microsoft Hyper-V, Xen und KVM. Der Hypervisor verwaltet den Zugriff auf physische Ressourcen wie CPU, Arbeitsspeicher und Speicher und stellt sicher, dass die virtuellen Maschinen voneinander isoliert bleiben.
Diese Isolierung ist aus Sicherheitsperspektive entscheidend. Eine kompromittierte virtuelle Maschine sollte nicht in der Lage sein, andere VMs auf demselben Host anzugreifen oder deren Daten auszulesen. Die Realität zeigt jedoch, dass Hypervisoren nicht immun gegen Schwachstellen sind. Sicherheitslücken in der Virtualisierungsschicht können katastrophale Folgen haben, da sie potenziell alle virtuellen Maschinen eines Hosts betreffen.
Container
Container sind eine Form der Betriebssystem-Virtualisierung und ergänzen klassische virtuelle Maschinen. Technisch gesehen ist ein Container eher isolierte Prozesse als eine echte virtuelle Maschinen. Im Gegensatz zu virtuellen Maschinen, die jeweils ein vollständiges Gastbetriebssystem enthalten, teilen sich Container den Kernel des Host-Betriebssystems und isolieren Anwendungen über Mechanismen wie Namespaces und Control Groups (cgroups). Technologien wie Docker haben die Verbreitung von Containern maßgeblich vorangetrieben, während Kubernetes heute als De-facto-Standard für die Orchestrierung containerisierter Anwendungen in vielen Cloud-nativen Umgebungen gilt.
Container sind deutlich schlanker als virtuelle Maschinen, da sie kein eigenes Betriebssystem benötigen. Dadurch starten sie typischerweise in Sekunden und verursachen einen geringeren Ressourcen- und Speicherbedarf. Diese Effizienz macht sie besonders geeignet für Microservices-Architekturen, bei denen Anwendungen in viele kleine, unabhängig deploybare Dienste aufgeteilt werden.
Aus Sicherheitssicht bringen Container aber einige Herausforderungen mit sich. Da sich Container denselben Kernel teilen, ist die Isolation grundsätzlich geringer als bei hypervisorbasierter Virtualisierung. Entsprechend wichtig sind zusätzliche Sicherheitsmaßnahmen wie die Verwendung vertrauenswürdiger und minimaler Basis-Images, regelmäßige Updates, automatisiertes Image-Scanning, Runtime-Überwachung sowie strikt umgesetzte Zugriffs- und Berechtigungskonzepte nach dem Least-Privilege-Prinzip.
Speicher- und Datenbanktechnologien
Cloud-Systeme basieren auf hochverfügbaren und skalierbaren Speicherlösungen. Die Grundlage bilden zwei klassische Konzepte aus der traditionellen IT: Network Attached Storage (NAS) und Storage Area Networks (SAN).
NAS bezeichnet netzgebundenen Speicher, der über TCP/IP erreichbar ist und Zugriff auf Dateiebene bietet. Ein typisches Beispiel ist ein gemeinsames Netzlaufwerk, auf das mehrere Nutzer gleichzeitig zugreifen können. NAS-Systeme sind einfach zu verwalten und eignen sich für Dateifreigaben und Backup-Zwecke.
Storage Area Networks hingegen bieten Zugriff auf Blockebene. Für das Betriebssystem erscheint ein SAN wie ein direkt angeschlossenes Laufwerk, obwohl der Speicher tatsächlich über viele physische Datenträger verteilt ist. SANs bieten eine höhere Leistung und eine bessere Redundanz als NAS-Systeme und werden typischerweise für Datenbanken und unternehmenskritische Anwendungen eingesetzt.
In der Cloud haben sich diese Konzepte zu Cloud-nativen Speicherdiensten entwickelt. Amazon S3 (Simple Storage Service) bietet beispielsweise objektbasierten Speicher mit praktisch unbegrenzter Skalierbarkeit. Azure Blob Storage und Google Cloud Storage folgen ähnlichen Prinzipien. Diese Dienste abstrahieren die zugrunde liegende Hardware vollständig, sodass sich der Kunde nicht um Festplatten, RAID-Konfigurationen oder physische Redundanz kümmern muss.
Managed Database Services
Cloud-Provider bieten zunehmend verwaltete Datenbank-Services an, bei denen die Plattform vollständig vom Anbieter betrieben wird. Beispiele für solche Angebote sind Amazon RDS (Relational Database Service), Azure SQL Database und Google Cloud SQL. Der Provider kümmert sich dabei um Betriebssystem-Updates, Datenbank-Patches, Backups und HA.
Für die Kunden bedeutet dies eine erhebliche Entlastung, gleichzeitig haben sie aber auch weniger Kontrolle. Die Sicherheit der Plattform liegt beim Provider, die Sicherheit der Daten beim Kunden. Diese Aufteilung ist ein klassisches Beispiel für das „Shared Responsibility Model”
Netzwerk
Cloud-Infrastrukturen basieren auf hochautomatisierten, software-gesteuerten und global verteilten Netzwerken. Cloud-Provider betreiben eigene Backbone-Netzwerke, die ihre Rechenzentren weltweit miteinander verbinden. Diese Netzwerke bieten nicht nur hohe Bandbreite, sondern auch geringe Latenz und hohe Verfügbarkeit.
Software-Defined Networking (SDN) spielt dabei eine zentrale Rolle. SDN trennt die Control Plane (die Entscheidungen über das Routing trifft) von der Data Plane (die Pakete tatsächlich weiterleitet). Diese Trennung ermöglicht flexible, programmierbare Netzwerke, die sich dynamisch an wechselnde Anforderungen anpassen können.
Aus Sicherheitsperspektive eröffnet SDN neue Möglichkeiten: Netzwerksegmentierung kann softwarebasiert und damit sehr granular umgesetzt werden. Micro-Segmentation, bei der jede einzelne Workload in ihrem eigenen Netzwerksegment läuft, wird praktikabel. Gleichzeitig entstehen aber auch neue Angriffsflächen – die Kontrollebene selbst muss gegen Kompromittierung geschützt werden.
Orchestrierung und Infrastructure as Code
Moderne Cloud-Umgebungen mit tausenden von Instanzen, Containern und Services lassen sich nicht mehr manuell verwalten. Orchestrierungstools wie Kubernetes für Container oder Terraform für Infrastructure as Code ermöglichen die automatisierte Bereitstellung und Verwaltung komplexer Infrastrukturen.
Infrastructure as Code (IaC) behandelt Infrastruktur wie Software: Konfigurationen werden in maschinenlesbaren Dateien beschrieben, versioniert und automatisiert ausgerollt. Dies erhöht nicht nur die Effizienz, sondern auch die Konsistenz und Nachvollziehbarkeit. Änderungen an der Infrastruktur können wie Code-Änderungen geprüft, getestet und dokumentiert werden.
Aus Sicherheitssicht wirkt Infrastructure as Code (IaC) als eine Art Verstärker, sowohl im positiven als auch im negativen Sinne. Dank standardisierter Templates ist eine reproduzierbare und konsistente Durchsetzung von Sicherheitskonfigurationen möglich. Gleichzeitig erhöht diese Skalierbarkeit das Risiko systematischer Fehlkonfigurationen: Ein einzelner Fehler kann automatisiert auf eine große Anzahl von Ressourcen übertragen werden und so eine breite Angriffsfläche schaffen.