Cloud Computing Security - Gesamt

Grundlagen und Architektur des Cloud Computing

Vor allem die Public Cloud wird zunehmend zu einem wesentlichen Bestandteil jedes modernen Unternehmens. Dies erfordert den Erwerb spezifischer Kenntnisse und betrieblicher Expertise, um Cloud-Infrastrukturen zu betreiben. Allerdings verfügt nicht jedes Unternehmen über das notwendige Wissen, insbesondere solche, die ohne ausreichende Expertise und Bewusstsein für Vorschriften und Sicherheitsbedenken in die Cloud migrieren. Laut Gartner werden bis 2025 mehr als die Hälfte der IT-Ausgaben von Unternehmen für Cloud-Infrastrukturen und -Dienste verwendet, die von großen Cloud-Service-Providern (CSP) bereitgestellt werden [1].

Der Hauptgrund für diesen Anstieg in den letzten Jahren liegt in der Tatsache, dass Cloud-Übergänge neue digitale Geschäftsmöglichkeiten bieten. Fast jedes Geschäftsmodell, das auf Künstlicher Intelligenz, maschinellem Lernen, Mikroservices und anderen modernen Technologien basiert, ist ein Beispiel dafür. Infolgedessen sind Unternehmen häufig gezwungen, die Public Cloud zu nutzen, um wettbewerbsfähig zu bleiben und ihren Marktanteil zu sichern. Dies zwingt die IT-Abteilungen dieser Unternehmen, Arbeitslasten, Dienste und Daten von traditionellen Rechenzentren oder Büros in die Public Cloud zu verlagern.

Das Problem bei diesem schnellen Übergang in die Cloud besteht darin, dass diese IT-Abteilungen, die an traditionelle Anforderungen und Bereitstellungen vor Ort gewöhnt sind, oft nicht gut darin geschult sind, die Cloud-Funktionen richtig zu nutzen. Neben der Verlagerung der Infrastruktur in die Cloud besteht eine weitere große Herausforderung darin, sie so abzusichern, dass Vorschriften eingehalten werden und Unternehmen vor Cyberangriffen geschützt sind.

Cloud Computing Konzepte

Geschichtlicher Background zu Cloud Computing

Die IT-Branche hat zahlreiche bedeutende Veränderungen durchlaufen auf ihrem Weg zum Cloud Computing. Es ist wichtig, zunächst die Geschichte des Cloud Computings zu verstehen, um zu begreifen, wo wir heute stehen. Dies wird verdeutlichen, wie die heutige Cloud entstanden ist und wie sich die cloudfähigen Technologien im Laufe der Zeit verändert haben. Wir sind durch eine Reihe von Cloud-Konzepten an diesen Punkt gelangt. Eines davon ist das Prinzip des Time-Sharing, das bis in die 1950er Jahre zurückreicht, als moderne Computer erfunden wurden. In den 1950er Jahren war das Time-Sharing besonders wichtig, weil Computer riesig, komplex und teuer waren. Es war nicht kosteneffektiv, einen Computer nur für ein Programm zu nutzen. Dank Time-Sharing-Schemata konnten mehrere Programme auf diesen leistungsstarken Computern laufen. Während das ursprüngliche Konzept manuell war und die Operatoren von einem Programm zum anderen wechselten, ist dies heute eines der Kernkonzepte jeder Arbeitslast in modernen Cloud-Infrastrukturen. Der Unterschied besteht nur darin, dass es heute hoch automatisiert ist und es ermöglicht, vorhandene Ressourcen effizient zwischen verschiedenen Rechenressourcen zu teilen. Ein weiteres Kernkonzept moderner Clouds ist die Fähigkeit, mit mehreren Netzwerken verbunden zu sein. Interconnected Networks (z.B. das Internet) entstanden Ende der 1960er und Anfang der 1970er Jahre und ermöglichten eine einfachere Methode zur weltweiten Informationsverteilung. Dies wurde zu einer Schlüsseltechnologie für alles in der IT-Branche. Insbesondere öffentliche Cloud-Ressourcen hängen stark von der Fähigkeit zur Interkonnektivität ab, da Ressourcen, die weit entfernt von den Unternehmen liegen, irgendwie erreichbar sein müssen. Die nächste große Innovation, die ein Kernkonzept jeder Cloud ist, ist die Virtualisierung. Virtualisierung existiert seit IBM in den 1970er Jahren ihr Virtual Machine (VM) Betriebssystem (OS) einführte, das es ermöglichte, dass mehrere virtuelle Systeme die zugrunde liegende physische Infrastruktur teilen. Virtuelle Maschinen wurden zu einem grundlegenden Bestandteil der IT. Ein Bare-Metal-Server war nun in der Lage, viele verschiedene Betriebssysteme zu hosten. Ein weiteres entscheidendes Element für das Cloud Computing, das zusätzlich zu Interkonnektivität und Rechenkapazität fehlt, ist Daten. Ohne Daten können weder Konnektivität noch Rechenleistung ihr volles Potenzial entfalten. Die Datenspeichertechnologien haben sich im Laufe der Jahre stetig weiterentwickelt, während andere Technologien voranschritten. Die Richtung ging dahin, den Speicher von der Arbeitslast zu entkoppeln und separat zu halten. Infolgedessen ist der Speicher zu einer der wichtigsten Komponenten und als Grundlage für Rechenleistung geworden. Technologien wie Datenbanken, RAIDs, Storage Area Networks (SAN) und Network Attached Storage (NAS) wurden entwickelt und sind noch heute in Gebrauch [2].

Cloud Computing Merkmale, Eigenschaften und Definition

Die Kombination dieser aus der Geschichte abgeleiteten Kernkonzepte führte zu verschiedenen Ansätzen im Cloud Computing und bot viele Lösungen für ein gegebenes Problem. Daher nahmen Unternehmen und Firmen unterschiedliche Strategien an. Sie bauten Rechenzentren, mieteten sie oder hatten alles in ihren Büros. Dies war lange bevor der Begriff "Cloud Computing" existierte. Das National Institute of Standards and Technology (NIST) definierte Cloud Computing wie folgt:

"Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model is composed of five essential characteristics, three service models, and four deployment models." [3]

Laut ihrer Definition gibt es beim Cloud Computing vier verschiedene Cloud-Bereitstellungstypen, drei verschiedene Cloud-Service-Modelle und fünf grundlegende Merkmale.

Der Kern des Cloud Computing wird durch die fünf wesentlichen Merkmale gebildet. Diese fünf Elemente umreißen die wesentlichen Merkmale einer Cloud. Im Kern bauen sie auf zwei Hauptkomponenten: physische Infrastruktur und eine Art Orchestrierungssystem. Die Infrastruktur einer Cloud-Umgebung besteht immer aus drei grundlegenden Komponenten: Speicher, Netzwerk und Rechenleistung. Diese drei Komponenten sind allein nicht ausreichend; die Nutzer müssen sie so konfigurieren können, dass sie ihren spezifischen Anforderungen entsprechen. Dies geschieht über Orchestrierungssoftware, die aus mehreren Teilen besteht, wobei eines davon immer eine Verwaltungsoberfläche für Kunden ist, die ihnen ermöglicht, ihre Cloud-Ressourcen zu steuern und zu überwachen.

Die fünf Kerneigenschaften sind folgende: [4]

On-demand Self-service

On-demand Self-Service bezieht sich auf einen Cloud-Dienst, der die Bereitstellung von Cloud-Ressourcen ermöglicht – wann und wo sie benötigt werden. Dies ist ein Verfahren, bei dem der Cloud-Kunde Cloud-Dienste ohne die Hilfe des Cloud-Anbieters bereitstellen, verwalten oder betreiben kann. Klassische Beispiele für diesen Self-Service sind die Webinterfaces bzw. anderen Schnittstellen von Cloud Service Providern oder auch von eigens gehosteten Cloud Umgebungen:

• Lokale Openstack Managment Plattform
• Lokale VMWare Management Plattform
• Container Management Plattformen mit Webinterface
• AWS Management Console: https://aws.amazon.com/console/
• GCP Management Console: https://console.cloud.google.com/
• Österreichisches Beispiel Anexia Console: https://www.anexia-engine.com/

Broad Network Access

Cloud-Ressourcen (Anwendungen, Rechenleistung, Verwaltungsoberflächen usw.) sollten über eine Netzwerkverbindung weitgehend zugänglich sein. Server, Personal Computer, Smartphones und nahezu jedes andere Gerät mit Internetzugang sollten in der Lage sein, sich mit den gegebenen Diensten zu verbinden. Die technische Grundlage dazu stellt das OSI-Referenzmodell. Mit diesem Standard ist es möglich, dass eigentlich viele unterschiedliche Endgeräte und Server miteinander kommunizieren können. (Nähere Erklärung)

Im Public Cloud Bereich bzw. bei größeren CSPs werden hier oft die Begriffe „Regions“ (Regionen) und „Availability Zones“ (Verfügbarkeitszonen) verwendet. In diesem Zusammenhang bedeutet es folgendes: Jede Cloud Region ist isoliert von einer anderen und kann z.B. EU-WEST heißen. In dieser Region gibt es dann noch mehrere Verfügbarkeitszonen. Diese Zonen sind geografisch voneinander getrennt, aber noch immer in derselben Region. In einer availability Zone sind dann meistens mehr als ein physisches Datacenter vorhanden. (Aufbau bei AWS: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-regions)

Resource Pooling

Alle Cloud-Kunden teilen sich die Ressourcen des Cloud-Service-Providers (CSP), zu denen mehrere Server, Netzwerkkomponenten und Speichergeräte gehören. Dies ermöglicht eine angemessene und gleichmäßige Verteilung der Ressourcenauslastung.

Visuelle Darstellung von Ressource Pooling

Diese Grafik sollte es veranschaulichen, dass Cloud Provider primär Storage, Compute und Networking Services bereitstellen und auf diese geteilten Ressourcen eben Menschenmassen und Unternehmen zugreifen um so Applikationen und Services zu konsumieren.

Rapid Elasticity

Die Infrastruktur der Kunden kann in einer Cloud-Umgebung elastisch bereitgestellt und freigegeben werden. Dieser Skalierungsprozess kann sogar vollständig automatisiert werden, sodass die Infrastruktur nur mit ihrem absoluten Minimum an Ressourcen arbeitet. Vertikale und horizontale Skalierbarkeit kann somit einfach in einer Cloud-Umgebung implementiert werden.

Vertikale Skalierbarkeit:

Visuelle Darstellung von vertikaler Skalierbarkeit

In einer Cloud Computing Plattform sollte es auf einfache Art und Weise möglich sein eine einfache VM mit mehr Compute/Storage/Networking Ressourcen auszustatten.

Horizontale Skalierbarkeit:

Visuelle Darstellung von horizontaler Skalierbarkeit

In einer Cloud Computing Plattform sollte es auch möglich sein dieselbe VM zu klonen und mehrfach zu betreiben. Wichtig hierfür ist, dass im Hintergrund auf geteilte Daten bzw. Applikationen zugegriffen wird und die Auslastung mittels Load Balancer auf die einzelnen Instanzen aufgeteilt wird.

Measured Service

Cloud-Systeme optimieren und kontrollieren ihre Ressourcennutzung, um den Anforderungen der Anwendung und des Kunden gerecht zu werden. Darüber hinaus wird jede Cloud-Ressource ständig überwacht und ein automatisches Alarmsystem implementiert. Dies bietet den Kunden Transparenz und die Möglichkeit, Daten über Ressourcenauslastung, Kostenentwicklung, Netzwerkverkehr usw. für jeden Dienst zu generieren.

Eine Cloud-Plattform sollte es, da es sich um eine Software handelt, ermöglichen, auf jegliche Daten und Metriken der Auslastung/Benutzung zuzugreifen. Zum Beispiel: Traffic, verursachte Kosten, etc. Anhand dieser Daten sollte es dann auch noch die Möglichkeit geben, für sich selbst gewisse KPIs (Key Performance Indicators) bzw. Limits zu definieren und, wenn diese erreicht oder überschritten werden, ein entsprechendes Alarmsystem über ein Benachrichtigungssystem zu implementieren.

Cloud Referenzarchitektur

NIST Cloud Computing Reference Architecture

Die NIST Cloud Computing Reference Architecture bietet eine standardisierte Perspektive auf die verschiedenen Komponenten und Akteure in einem Cloud-Computing-Umfeld. Die Architektur identifiziert und beschreibt die Hauptrollen, Verantwortlichkeiten und Interaktionen der verschiedenen Akteure innerhalb des Cloud Computing-Ökosystems.

NIST CC Referenz Architektur

Hier sind die Rollen des NIST-Referenzmodells:

1. Cloud Consumer (Cloud-Kunde/Cloud Service Consumer - CSC):

   1. Individuen oder Organisationen, die Cloud-Dienste nutzen.

2. Cloud Provider (Cloud-Anbieter/Cloud Service Provider - CSP):

   1. Unternehmen, die Cloud-Dienste anbieten und verwalten.

   2. Verantwortlich für die Bereitstellung von Infrastruktur, Plattformen und Software als Dienstleistung (IaaS, PaaS, SaaS).

3. Cloud Broker (Cloud-Broker):

   1. Vermittler, die Cloud-Dienste von verschiedenen Anbietern zusammenfassen und an die Kunden weiterverkaufen.

   2. Optimieren die Nutzung von Cloud-Diensten für den Kunden.

4. Cloud Auditor (Cloud-Auditor):

   1. Unabhängige Stellen, die die Dienste und Sicherheit der Cloud-Anbieter überprüfen.

   2. Stellen sicher, dass die Cloud-Dienste den gesetzlichen und geschäftlichen Anforderungen entsprechen.

5. Cloud Carrier (Cloud-Carrier):

   1. Anbieter von Netzwerk- und Transportdiensten, die die Verbindung zwischen Cloud-Anbietern und Cloud-Kunden ermöglichen.

Diese Rollen beschreiben Abhängigkeiten und Akteure beim Einsatz von Cloud Computing Technologien. Demnach sind dies auch direkt die Abhängigkeiten entlang einer auf Cloud Computing basierten Wertschöpfungskette und müssen dementsprechend adressiert bzw. gepflegt werden.

In der NIST Definition sind dann des Weiteren noch die zwei Hauptkomponenten ausgeführt. Zum einen die Service Models (Dienstleistungsmodelle) und die Deployment Models (Bereitstellungsmodelle) die das Cloud Computing auszeichnen.

Cloud Computing Service Models

Cloud Service Models sind ein wesentlicher Bestandteil des Cloud-Computings, ebenso wie die fünf grundlegenden Merkmale. Laut der NIST-Definition von Cloud-Computing gibt es drei Cloud Service Models. Typischerweise werden diese Modelle als "* as a Service" bezeichnet, wobei das "*" für die Art der Bereitstellungsmethode steht [6], [7].

Folgende Dienstleistungsmodelle wurden offiziell definiert:

Software-as-a-Service (SaaS)

Das SaaS-Dienstmodell wird im Allgemeinen verwendet, um Software für Endbenutzer bereitzustellen. Diese können in zwei Zielgruppen unterteilt werden: entweder Business-to-Business-Software oder Business-to-Consumer-Software. SaaS-Anwendungen werden typischerweise über Web-, Desktop- oder mobile Anwendungen angeboten und sind weit verbreitet verfügbar. SaaS-Lösungen können auch nur als Application Programming Interfaces (APIs) angeboten werden, die von Kunden genutzt werden können, um ihre Dienste und Anwendungen zu erweitern. In einem SaaS-Umfeld wird alles vom Dienstanbieter verwaltet, die einzige Verantwortung des Kunden besteht in der Verwaltung von Authentifizierungsinformationen und benutzergenerierten Daten (z. B. Metadaten oder Anwendungsdaten). Die meisten modernen SaaS-Lösungen sind auch in der Lage, externe Identitätsanbieter wie Google, Microsoft, Meta usw. zu integrieren, um den Kunden integrierte Anmeldeoptionen zu bieten, die auch als Single Sign-On (SSO) bezeichnet werden. Dies ist ein Sicherheitsvorteil für SaaS-Anbieter, da sie keine Benutzerdaten speichern müssen. Typische SaaS-Lösungen sind Microsoft 365, Netflix, Spotify usw., die weltweit entweder von Unternehmen oder normalen Kunden genutzt werden. Im Allgemeinen bieten viele Softwareunternehmen ihre Dienste als SaaS-Lösungen für ihre Kunden an.

Platform-as-a-Service (PaaS)

Eine PaaS-Lösung ist eine Umgebung, in der Kunden in der Lage sind, einen bestimmten „Dienst“ wie einen On-Demand-Webserver oder eine vollständig verwaltete Datenbank bereitzustellen, ohne das zugrunde liegende Betriebssystem betreiben und unterstützen zu müssen. Daher sind die Anbieter, die PaaS-Lösungen anbieten, für das zugrunde liegende System verantwortlich, und die Benutzer konsumieren nur einen Dienst, den sie nach Belieben anpassen können. Dieses Konzept ist besonders beliebt für Systeme, die viele Patches und Wartung erfordern. Das am weitesten verbreitete Geschäftsmodell besteht darin, dass Anbieter eine Art von Managed Service anbieten, der sich auf Support und Service Level Agreements (SLAs) bezieht. Ein Beispiel ist eine Database-as-a-Service, bei der die Datenbank die Plattform ist, die vom Kunden konfiguriert und genutzt werden kann, während der Dienstanbieter alles rund um die Betriebszeit, das Patchen, das Clustering, die Sicherheit usw. verwaltet.

Infrastructure-as-a-Service (IaaS)

Eine IaaS-Umgebung ist ein Dienstmodell, das viele Arten von IT-Infrastrukturen anbietet. Daher liegt auch die größte Verantwortung beim Kunden. IaaS kann mit einer klassischen Virtualisierungsumgebung verglichen werden, in der Kunden in der Lage sind, VMs auf einem Hypervisor bereitzustellen und mit ihrem gewünschten Betriebssystem ihre Infrastruktur aufzubauen. Insbesondere in einer öffentlichen Cloud-Umgebung können Benutzer viele verschiedene Arten von Infrastrukturen bereitstellen, nicht nur die traditionelle VM. Grundsätzlich kann alles, was in einem traditionellen Rechenzentrum vorhanden ist, virtuell bereitgestellt werden: Virtuelle Netzwerke, Virtual Private Network (VPN)-Gateways, Netzwerksicherheitsgruppen und viele weitere Infrastrukturelemente können bereitgestellt werden. Dies bedeutet auch, dass typische Netzwerk-Infrastrukturen wie Router, Switches, Loadbalancer und Firewalls bereitgestellt werden können. Diese ganze Flexibilität bringt jedoch auch viel Aufwand mit sich. Jedes Infrastrukturelement muss betrieben, gewartet, gesichert und bei Bedarf gepatcht werden. Dies kann zu einer erheblichen Arbeitsbelastung führen, und In-Place-Upgrades werden für Cloud-Infrastrukturen oft nicht unterstützt, da die Infrastruktur auf einer Art Basis-Image beruht, das nicht leicht geändert werden kann. Anstatt die Infrastruktur inline zu aktualisieren, besteht auch die Möglichkeit, das Basis-Image der Infrastruktur zu ändern. Dies ist nur möglich, wenn die Infrastrukturkonfiguration nicht manuell erfolgt, sondern an einem anderen Ort gespeichert wird. Beispielsweise wird anstatt einer Aktualisierung einer VM eine neue VM mit dem neuesten Basis-Image und anderen anwendbaren Änderungen bereitgestellt und die alte später entfernt. Dieser Ansatz mag zunächst wie eine Verschwendung von Ressourcen erscheinen, doch mit einem aktuellen Werkzeug namens Infrastructure as Code (IaC), bei dem es sich um einen Bauplan der gesamten Infrastrukturkonfiguration handelt, kann der Upgrade-Prozess einer VM in weniger als einer Minute abgeschlossen werden.

IaaS ist die Grundlage für diese drei Diensttypen, die aufeinander aufbauen. Das bedeutet, dass ein PaaS-Dienstmodell auf einem IaaS-Modell aufgebaut werden kann und ein SaaS entweder auf einem IaaS- oder einem PaaS-Modell aufgebaut werden kann.

IaaS-PaaS-Saas Aktöre, Komponenten und Kundenkontrolle veranschaulicht

Diese Abbildung zeigt, wie die verschiedenen Cloud Service Models aufeinander aufbauen. Drei Aspekte jedes Dienstmodells werden dargestellt: die Akteure, die Komponenten, die ein Kunde nutzen kann, und das Maß an Kontrolle, das der Kunde hat. Das IaaS-Dienstmodell wird von Akteuren wie Netzwerkarchitekten und DevOps-Ingenieuren verwaltet. Sie sind verantwortlich für die bereitgestellte Infrastruktur wie VPN-Gateways, Netzwerke, Speichersysteme und virtuelle Maschinen. Auf der IaaS-Ebene pflegen Softwareentwickler und auch DevOps-Ingenieure normalerweise die PaaS-Schicht. Die Akteure dieser Schicht sind also dafür verantwortlich, die Datenbanken, Webserver und Webanwendungen zu betreiben und zu patchen, die auf den Servern laufen. Ein PaaS-Kunde nutzt folglich nur einen Dienst (z. B. eine von den Akteuren gepflegte Datenbank). SaaS ist in der Regel das Softwareprodukt oder der Dienst, der auf einer PaaS-Schicht läuft. Das bedeutet beispielsweise eine API oder Webanwendung, die über einen von den PaaS-Akteuren verwalteten Webserver zugänglich ist.

Es kann gesagt werden, dass es kein Softwareangebot (SaaS) ohne eine zugrunde liegende Plattform (PaaS) geben kann, auf der die Software läuft. Darüber hinaus kann eine Plattform nur auf Infrastruktur (IaaS-Komponenten) betrieben werden, die in einer öffentlichen Cloud bereitgestellt werden kann. CSPs (Cloud-Service-Provider) bieten in der Regel zwei der drei wichtigsten Dienstmodelle standardmäßig an. Diese sind IaaS (VMs usw.) und PaaS (verwaltete Dienste wie Datenbanken usw.). SaaS-Lösungen werden typischerweise nicht von CSPs bereitgestellt, sondern eher von Drittanbietern, die auf einen CSP hinter ihrem Dienst angewiesen sind.

Erweiterte Service Modelle

Laut der NIST-Definition von 2011 sind dies die wichtigsten Dienstmodelle. Heute ist diese Definition nicht mehr vollständig zutreffend, da aus diesen drei Modellen viele weitere *aaS-Dienstmodelle entstanden sind. Beispiele hierfür wären Artificial Intelligence-as-a-Service (AIaaS – zum Beispiel ChatGPT von OpenAI), Desktop-as-a-Service (DaaS – zum Beispiel eine Azure Virtual Desktop-Umgebung), Monitoring-as-a-Service (MaaS – zum Beispiel Software von Elastic NV) und viele mehr. All diese Dienstmodelle basieren in gewisser Weise auf den drei grundlegenden Dienstmodellen – die Basismodelle werden nur um einige Erweiterungen ergänzt und neue *aaS-Modelle werden veröffentlicht [4].

Neben den zahlreichen neuen Dienstmodellen stechen zwei hervor, da sie von Cloud-Ingenieuren umfassend genutzt werden: [8]

• Container-as-a-Service (CaaS) Das CaaS-Dienstmodell ermöglicht es den Kunden, Container bereitzustellen, die auf containerd oder einer anderen Container-Laufzeit in der öffentlichen Cloud ausgeführt werden. Dieses Dienstmodell wird häufig mit einem Container-Orchestrierungssystem wie Kubernetes oder Openshift und einer Container-Registry kombiniert, die oft von einem CSP bereitgestellt wird. Eine Container-Orchestrierung ermöglicht die Automatisierung der Bereitstellung und Verwaltung von Containern, während eine Container-Registry die Images speichert, die als Container bereitgestellt werden.

• Function-as-a-Service (FaaS) Das FaaS-Dienstmodell ist ebenfalls ein wesentlicher Bestandteil des Angebots jedes CSPs. Es ermöglicht den Kunden, Quellcode – sogenannte Funktionen – in der Cloud auszuführen. Das bedeutet, dass Kunden Code ausführen können, der beispielsweise eine E-Mail sendet, ohne ein Betriebssystem betreiben zu müssen, das den Code ausführt. Der Kunde zahlt also nur für die Rechenleistung, die zur Ausführung der Funktion benötigt wird.

Zusätzlich zu den drei wichtigsten Dienstmodellen sind diese beiden ebenfalls wesentlich und werden häufig von Unternehmen genutzt.

Cloud Computing Deployment Models

Cloud Computing Deployment Models definieren, wie Cloud-Infrastrukturen aufgebaut und genutzt werden. Diese Modelle bestimmen, wer Zugriff auf die Cloud-Ressourcen hat, wie diese verwaltet werden, und welche Vor- und Nachteile mit ihrer Nutzung verbunden sind. Es gibt mehrere etablierte Deployment-Modelle, die jeweils für unterschiedliche Anwendungsfälle geeignet sind. NIST in ihrem Standard spricht von 4 Bereitstellungsmodellen.

Diese Deployment-Modelle bieten Unternehmen unterschiedliche Möglichkeiten, Cloud-Technologien zu nutzen, je nach ihren spezifischen Anforderungen und Zielen. Jede Option bringt ihre eigenen Vor- und Nachteile mit sich, und die Wahl des richtigen Modells hängt von den individuellen Bedürfnissen des Unternehmens ab.

Im Folgenden werden die wichtigsten Deployment-Modelle vorgestellt: Private Cloud, Public Cloud, Hybrid Cloud, Community Cloud und Multi Cloud (Nicht im NIST Cloud Computing Standard enthalten, da sich diese Art erst über die Jahre „gebildet“ hat).

Private Cloud

Eine Private Cloud ist eine Cloud-Computing-Umgebung, die ausschließlich von einem einzigen Unternehmen genutzt wird. Die Ressourcen der Private Cloud werden entweder intern von der IT-Abteilung des Unternehmens oder durch einen externen Dienstleister betrieben, wobei die Infrastruktur vollständig auf die Bedürfnisse des Unternehmens zugeschnitten ist. Eine Private Cloud bietet ein hohes Maß an Sicherheit und Kontrolle, da das Unternehmen direkten Zugriff auf die Hardware und Software hat, die für die Bereitstellung der Cloud-Dienste verwendet werden.

Vorteile:

• Hohe Sicherheit und Kontrolle: Da die Infrastruktur isoliert ist, bietet die Private Cloud eine höhere Datensicherheit und ermöglicht die Einhaltung spezifischer Compliance-Anforderungen.
• Anpassbarkeit: Die Infrastruktur kann speziell an die Anforderungen des Unternehmens angepasst werden, was eine flexible und maßgeschneiderte Lösung ermöglicht.

Nachteile:

• Hohe Kosten: Die Implementierung und Wartung einer Private Cloud erfordert erhebliche Investitionen in Hardware, Software und Fachpersonal.
• Wartungsaufwand: Das Unternehmen ist für die gesamte Verwaltung und Wartung der Infrastruktur verantwortlich, was zusätzlichen Aufwand bedeutet.

Beispiel

Private Cloud illustriert

Public Cloud

Eine Public Cloud ist ein Cloud-Computing-Modell, bei dem Cloud-Dienste über das Internet von einem Cloud-Service-Provider (CSP) bereitgestellt werden. Diese Dienste stehen der Öffentlichkeit zur Verfügung, und die Ressourcen werden gemeinsam von mehreren Nutzern verwendet. Die Public Cloud ist in der Regel kostengünstiger, da die Kosten für Hardware und Wartung auf mehrere Nutzer verteilt werden.

Vorteile:

• Kosteneffizienz: Die Nutzung der Public Cloud ist meist günstiger, da keine eigenen Investitionen in Hardware erforderlich sind und die Kosten für Wartung und Betrieb vom CSP übernommen werden.
• Skalierbarkeit: Ressourcen können je nach Bedarf schnell und einfach skaliert werden, um den Anforderungen des Unternehmens gerecht zu werden.

Nachteile:

• Sicherheitsbedenken: Da die Ressourcen gemeinsam genutzt werden, können Sicherheitsrisiken höher sein, insbesondere wenn sensible Daten in der Cloud gespeichert werden.
• Abhängigkeit vom Anbieter: Unternehmen sind stark auf den CSP angewiesen, was zu einem Vendor-Lock-in führen kann.

Beispiel

Illustration einer Public Cloud

Hybrid Cloud

Die Hybrid Cloud kombiniert Elemente der Private und Public Cloud, indem sie Daten und Anwendungen über beide Umgebungen hinweg integriert. Unternehmen können sensible Daten in der Private Cloud speichern, während weniger kritische Anwendungen in der Public Cloud gehostet werden. Diese Kombination bietet eine Balance zwischen Sicherheit, Flexibilität und Kosteneffizienz.

Vorteile:

• Flexibilität: Unternehmen können Workloads zwischen Public und Private Clouds verlagern, je nach Sicherheitsanforderungen und Kostenüberlegungen.
• Optimierte Ressourcen-Nutzung: Kritische Anwendungen können in einer sicheren Private Cloud laufen, während Public Clouds für weniger kritische Aufgaben genutzt werden.

Nachteile:

• Komplexität: Die Verwaltung einer Hybrid Cloud erfordert eine umfassende Strategie, um die Interoperabilität zwischen den verschiedenen Umgebungen zu gewährleisten.
• Kosten: Die Implementierung einer Hybrid Cloud kann teurer sein als die ausschließliche Nutzung einer Public oder Private Cloud.

Beispiel

Hybrid Cloud Beispiel 1

Hybrid Cloud Beispiel 2

Community Cloud

Eine Community Cloud ist eine spezielle Art von Cloud-Infrastruktur, die von mehreren Organisationen gemeinsam genutzt wird, die ähnliche Anforderungen haben, beispielsweise hinsichtlich Sicherheit, Compliance oder spezifischen Geschäftsanforderungen. Die Infrastruktur kann intern verwaltet oder von einem Drittanbieter betrieben werden, wobei die Kosten und Ressourcen zwischen den beteiligten Organisationen aufgeteilt werden.

Vorteile:

• Geteilte Kosten: Die beteiligten Organisationen teilen sich die Kosten für die Infrastruktur, was die Kosten für jeden Einzelnen reduziert.
• Gemeinsame Compliance: Die Cloud kann speziell an die gemeinsamen Compliance- und Sicherheitsanforderungen der beteiligten Organisationen angepasst werden.

Nachteile:

• Beschränkte Anpassungsmöglichkeiten: Da die Cloud von mehreren Organisationen genutzt wird, sind die Anpassungsmöglichkeiten eingeschränkt.
• Komplexe Verwaltung: Die Verwaltung der Cloud erfordert eine enge Zusammenarbeit zwischen den beteiligten Organisationen, was zu administrativen Herausforderungen führen kann.

Beispiel

Community Cloud illustriert

Multi Cloud

Das Multi-Cloud-Modell bezieht sich auf die Nutzung mehrerer Cloud-Dienste von verschiedenen Anbietern. Unternehmen nutzen mehrere Cloud-Plattformen, um von den jeweiligen Stärken und Funktionen der verschiedenen Anbieter zu profitieren und Abhängigkeiten von einem einzelnen CSP zu vermeiden.

Vorteile:

• Vermeidung von Vendor-Lock-in: Durch die Nutzung mehrerer Anbieter vermeiden Unternehmen die Abhängigkeit von einem einzigen CSP.
• Optimale Nutzung: Unternehmen können die besten Dienste verschiedener Anbieter kombinieren, um ihre spezifischen Anforderungen optimal zu erfüllen.

Nachteile:

• Komplexität: Die Verwaltung einer Multi-Cloud-Umgebung kann komplex und anspruchsvoll sein, insbesondere hinsichtlich der Integration und Datensicherheit.
• Kosten: Obwohl eine Multi-Cloud-Strategie Flexibilität bietet, können die Gesamtkosten durch die Nutzung mehrerer Anbieter steigen.

Beispiel

Multi Cloud Illustriert

Shared Responsibility Model

Das Shared Responsibility Model ist ein essenzielles Konzept im Cloud Computing, das die Aufteilung der Verantwortlichkeiten zwischen Cloud Service Providern (CSPs) und Cloud Service Kunden (CSCs) beschreibt. Dieses Modell dient als Grundlage dafür, wie Infrastruktur- und Sicherheitsaufgaben in einer Cloud-Umgebung gemeinsam verwaltet werden, und verdeutlicht, welche Aufgaben vom CSP übernommen werden und welche in der Verantwortung des Kunden liegen. Es fungiert als eine Art Verantwortungsmatrix, die je nach gewähltem Cloud-Anbieter, den genutzten Produkten, den Service-Modellen und den Bereitstellungsmodellen variiert.

Das Shared Responsibility Model bildet das Fundament dafür, wie ein CSP agiert und seine Dienste bereitstellt, unabhängig davon, ob es sich um eine private, öffentliche, hybride oder Multi-Cloud-Umgebung handelt. Je nach verwendetem Cloud-Service-Modell – sei es Infrastructure as a Service (IaaS), Platform as a Service (PaaS) oder Software as a Service (SaaS) – müssen sich die Kunden darüber im Klaren sein, welche Verantwortlichkeiten in den Händen des CSP liegen und welche Aufgaben sie selbst übernehmen müssen. So bestimmt das Modell nicht nur die Effizienz und Sicherheit der Cloud-Nutzung, sondern auch die Art und Weise, wie Unternehmen ihre internen IT-Ressourcen und -Prozesse organisieren und verwalten.

Das Shared Responsibility Model variiert je nach gewähltem CSP. Im Allgemeinen umfassen sie drei Service-Modelle sowie einen Vergleich mit einem standardmäßigen Rechenzentrum. Dies wird erreicht, indem jede Komponente, die zur Bereitstellung einer Anwendung oder eines Dienstes erforderlich ist (z. B. ein physischer Server), untersucht und anschließend die Pflichten des CSP und des CSC basierend auf dem jeweiligen Service-Modell aufgezeigt werden.

Eine erweiterete Version des Shared Responsibility Models (inkl. CaaS und FaaS) sieht wie folgt aus:

Erweitertes Shared Responsibility Model anhand von Cloud computing security: Foundations and challenges [9]

Das Shared Responsibility Model besteht aus neun Schichten, von denen jede einen anderen Aspekt repräsentiert, der benötigt wird, um einen Dienst für Endbenutzer in der Cloud bereitzustellen. Diese Schichten bauen aufeinander auf und würden ohne die darunterliegenden Schichten nicht funktionieren. Daher hat jedes Servicemodell unterschiedliche Anforderungen an den CSP. Dieses Modell verdeutlicht auch, dass die Bereitstellung einer IaaS-Lösung für Endverbraucher auf vielen zugrunde liegenden Komponenten und Fachwissen beruht, die benötigt werden, um die ersten vier Schichten bereitzustellen. Die Schichten und ihre Funktionen von unten nach oben sind die folgenden:

Physisches Rechenzentrum

Das physische Rechenzentrum ist der Standort Ihrer Rechen-, Speicher- und Netzwerkkomponenten. Beim Bau eines Rechenzentrums müssen viele Aspekte berücksichtigt werden (z. B. physisches Design, Umweltgestaltung usw.), die alle in der ISO/IEC 22237 aufgeführt sind. Dieser Standard berücksichtigt alle Rechenzentren, auch solche, die vollständig privat sind. Betrachtet man das physische Rechenzentrum eines öffentlichen Cloud-Service-Providers, ist es unmöglich, nur ein einziges Rechenzentrum zu betrachten. Öffentliche Cloud-Anbieter verfügen über Rechenzentren auf der ganzen Welt in sogenannten Regionen, die in Verfügbarkeitszonen unterteilt sind. Eine Region könnte beispielsweise als „Europa-Nord (Irland/Dublin)“ definiert sein. Diese Regionen bestehen in der Regel aus mindestens zwei Verfügbarkeitszonen. Eine Verfügbarkeitszone selbst ist ein realer physischer Rechenzentrumsstandort. Daher ist ein CSP mit fünf Regionen, die jeweils drei Verfügbarkeitszonen haben, für insgesamt 15 physische Rechenzentren verantwortlich und für deren Verfügbarkeit und Funktionsfähigkeit zuständig.

Netzwerk und Speicher

Netzwerk- und Speicherkomponenten sind zwei der drei Kernkomponenten des Cloud-Computing (Netzwerk, Speicher und Rechenleistung). Betrachtet man die Netzwerkkonfiguration eines Rechenzentrums, so müssen der Betrieb von Datacenter-Switches, Loadbalancern, Firewalls und Core-Routern für mehrere öffentliche Internetverbindungen berücksichtigt werden. Diese Netzwerkkomponenten müssen jederzeit in einer hochverfügbaren und fehlertoleranten Umgebung betrieben werden.

Ein Rechenzentrum enthält oft viele Speicherkomponenten, die für verschiedene Zwecke verwendet werden. Diese Speicherkomponenten werden in drei Typen unterteilt:

• Direct Attached Storage (DAS) Dieser Speichertyp wird nicht für große Datenmengen verwendet. Er wird üblicherweise nur für das Betriebssystem der physischen Server und anderer Geräte wie Firewalls und Loadbalancer verwendet. Dieses direkt angeschlossene Speichersystem ist in der Regel als RAID 1 für Server konfiguriert, die als Typ-1-Hypervisor, Firewalls und Loadbalancer fungieren. Eine gespiegelte Festplatte ist in diesem Szenario sinnvoll, da diese Betriebssysteme nicht viel Speicher benötigen und fehlertolerant sein müssen.
• Network Attached Storage (NAS) Ein netzwerkgebundenes Speichersystem ist in einem Rechenzentrum häufiger anzutreffen. Es fasst viel Speicherplatz auf mehreren Speicherknoten zusammen, die über mehrere Netzwerkprotokolle zugänglich sind. NAS-Systeme und deren Speicher nutzen auch RAID-Mechanismen, um ein fehlertolerantes System bereitzustellen. Um auf ein NAS zuzugreifen, muss es auf einem Netzwerk-Laufwerk oder einem Netzwerk-Standort des Betriebssystems eingebunden werden. NAS-Systeme haben jedoch Einschränkungen, da sie auf dem zugrunde liegenden Netzwerk basieren und das Netzwerk möglicherweise nicht in der Lage ist, große Datenmengen zu übertragen.
• Storage Area Network (SAN) Ein Storage Area Network ist ein separates Netzwerk, das von normalen TCP/IP-Netzwerken getrennt ist. Es verwendet spezielle Hardware (Switches und Speicherknoten), die für hohe Datenraten im Netzwerk optimiert sind. Es fasst im Wesentlichen viele Speicherknoten in einem separaten Netzwerk zusammen und stellt den Speicher über eine Schnittstelle für andere Dienste bereit. Aus der Sicht eines Servers, der Speicher von einem SAN nutzt, sieht es so aus, als hätte der Server Zugriff auf eine physische Festplatte, die tatsächlich vom SAN bereitgestellt wird.

Diese Netzwerk- und Speicherkomponenten müssen vom Rechenzentrumsbetreiber ordnungsgemäß gewartet und gesichert werden, damit die Komponenten im Katastrophenfall wiederhergestellt werden können.

Physischer Server

Physische Server liegen über den Netzwerk- und Speicherkomponenten und bilden den Rechenteil eines Rechenzentrums. Diese Server sind normalerweise für den 24/7-Betrieb ausgelegt und in verschiedenen Formfaktoren erhältlich. Der gängigste Formfaktor ist der Rackmount-Server. Diese verfügen über spezielle Mainboards, die den Einbau mehrerer CPUs und RAM-Sticks ermöglichen.

Virtualisierung

Virtualisierung ist eine wichtige Funktion in Rechenzentren. Sie ermöglicht eine bessere Auslastung der physischen Server, sodass diese nicht nur mit einer CPU-Auslastung von 10 % und nahezu ungenutztem RAM betrieben werden. Um Virtualisierung zu ermöglichen, wird ein Hypervisor benötigt. In Unternehmensumgebungen wird in der Regel ein Typ-1-Hypervisor verwendet. Ein Typ-1-Hypervisor ist eine Softwareebene, die auf einem physischen Server und dessen zugrunde liegender Hardware bereitgestellt wird. Es wird auch als Bare-Metal-Hypervisor bezeichnet, da keine zusätzliche Software zwischen der Hardware und dem Hypervisor ausgeführt wird. Der Hypervisor ermöglicht es den VMs, Netzwerken und anderen virtualisierten Komponenten, die darauf ausgeführt werden, mit der zugrunde liegenden Hardware zu kommunizieren. Er ist auch dafür verantwortlich, den virtualisierten Komponenten die Möglichkeit zu bieten, mit den Speicher- und Netzwerkkomponenten des Rechenzentrums zu kommunizieren.

Betriebssystem

Die gängigsten Betriebssysteme in einem Rechenzentrum sind Linux-basierte Systeme und Windows-Systeme. Ein virtualisiertes Betriebssystem wird auch als Gastbetriebssystem bezeichnet. Linux wird für die meisten Server verwendet, die in der Regel Webserver, Datenbanken oder andere Anwendungen hosten. Windows-Server werden für Unternehmensanwendungen wie Active Directory oder Exchange-Dienste verwendet. Administratoren neigen auch dazu, einen Hypervisor auf einem normalen Linux-Server zu installieren, um noch mehr aus einer einzelnen VM herauszuholen. Dies wird als geschachtelte Virtualisierung bezeichnet und ermöglicht eine weitere Segmentierung auf einem einzelnen Gastbetriebssystem.

Middleware

Die Middleware wird nicht für jede Anwendung benötigt, aber für einige ist sie unerlässlich. Es ist eine Orchestration-Schicht, die zwischen den Anwendungen und dem zugrunde liegenden Betriebssystem liegt. Ein häufiger Anwendungsfall ist beispielsweise eine PaaS-Hochverfügbarkeits-Datenbanklösung, die dem CSC einen einzelnen Datenbankendpunkt zur Verfügung stellt, während im Hintergrund viele Instanzen ausgeführt werden. Die Koordination der Interaktionen zwischen verschiedenen Datenbankinstanzen liegt in der Verantwortung der Middleware. Bei der Verwendung von Containern wird ebenfalls eine Middleware genutzt. Dies gilt sowohl für die direkte Bereitstellung einzelner Container in der Cloud (über den Container-Service eines CSP) als auch für die Bereitstellung mehrerer Container über ein Orchestration-Tool wie Kubernetes (die meisten CSPs bieten ihren Kunden einen verwalteten Kubernetes-Service an).

Runtime

Die Runtime ist in der Regel ein Softwarepaket (Anwendung + Bibliotheken + Umgebung), das im Hintergrund läuft, um die zugrunde liegenden Funktionen für die Anwendungen der Endbenutzer bereitzustellen. Typische Software, die als Runtime-Umgebung betrachtet werden kann, ist ein Webserver. Ein Webserver muss jedoch immer auf dem neuesten Stand sein und über die richtigen Funktionen für die Anwendung des Endbenutzers verfügen. Beispiele hierfür wären ein NGINX- oder ein Apache-Webserver, die in der Lage sind, TLS-Terminierung durchzuführen, um einen sicheren Datenaustausch zwischen Clients und Servern zu ermöglichen. Das Einrichten der Runtime auf eine ordnungsgemäße und skalierbare Weise erfordert viel Fachwissen, das Entwickler, die nur eine Webanwendung erstellen, in der Regel auslagern – entweder an den CSP oder an ein IT-Betriebsteam. CSPs bieten Runtime-Lösungen als PaaS-Angebote an und haben eine breite Palette von Managed Services, einschließlich Webservern und Datenbanken.

Datenbank

Daten werden in der Regel in verschiedenen Arten von Datenbanken gespeichert, entweder in SQL- oder NoSQL-Datenbanken. Der Kontext für die Geschäftslogik der Anwendungen, die in einer Cloud-Umgebung ausgeführt werden, wird durch die in den Datenbanken gespeicherten Daten bereitgestellt. Daten werden jedoch nicht immer in strukturierter Form wie in Datenbanken gespeichert. Einige Anwendungen müssen andere Arten von Daten speichern oder darauf zugreifen. CSPs bieten Objektspeicher an, die Daten in unstrukturierter Form als Objekte speichern. Daten aus Objektspeichern können über eine API abgerufen und ähnlich wie ein Objekt aus einer objektorientierten Programmiersprache behandelt werden. Eine Kombination aus vielen verschiedenen Datenquellen in einer Cloud (Datenbanken und Objektspeicher) wird als Data Lake bezeichnet. Ein Data Lake hat die Eigenschaft, verschiedene Datenquellen zu konsolidieren. Dies bildet die Grundlage für Anwendungen im Bereich des maschinellen Lernens und der Geschäftsanalyse.

Anwendung

Das Programm, auf das Endbenutzer zugreifen können, wird als Anwendung bezeichnet. Gängige Anwendungen umfassen Webanwendungen, Streaming-Endpunkte, API-Endpunkte und mehr. Um auf einen Cloud-Dienst zuzugreifen, benötigt der Endbenutzer lediglich eine Anwendung für sein Endgerät (Smartphone, Notebook usw.) oder einen Internetbrowser. Anwendungen sind auf alle zugrunde liegenden Komponenten des Shared Responsibility Models angewiesen.

Allgemeines zum Shared Responsibility Model

Wie in der Grafik von Vacca hervorgehoben, verschieben sich die Verantwortlichkeiten des CSC je nach gewähltem Servicemodell. Daher sollte das Servicemodell immer in Übereinstimmung mit dem Fachwissen und den Fähigkeiten des CSC ausgewählt werden. Es macht wenig Sinn, ein IaaS-Modell zu wählen, wenn kein Wissen über den Betrieb, die Unterstützung, das Patchen, das Monitoring und die Sicherung des gewählten Betriebssystems sowie der darüber liegenden Middleware, Laufzeit, Datenbank und Anwendung vorhanden ist.

Sicherheitsfragen bei der Nutzung von Cloud Diensten

Bei den Sicherheitsfragen im Zusammenhang mit dem Einsatz von Cloud-Diensten stehen in erster Linie die Sicherheitsbedenken bei der Nutzung von Public-Cloud-Anbietern im Vordergrund. Dies liegt hauptsächlich daran, dass eine private Cloud in vielerlei Hinsicht gut mit einem traditionellen Rechenzentrum und dessen Sicherheitsmaßnahmen vergleichbar ist. Ähnliches gilt auch für Hybrid- und Community-Clouds, bei denen aus sicherheitstechnischer Sicht vor allem die sichere Verbindung zwischen dem eigenen Rechenzentrum und einer anderen Cloud-Umgebung, sei es ein anderes Rechenzentrum oder eine Public Cloud, im Mittelpunkt steht. Hierbei spielen bewährte Methoden der Netzwerksicherheit eine entscheidende Rolle.

Der Fokus bei den Sicherheitsfragen liegt daher insbesondere auf dem Einsatz von Public-Cloud-Infrastrukturen sowie der Nutzung von Cloud-Diensten, die als Software-as-a-Service (SaaS) im Unternehmen implementiert werden, wie zum Beispiel Microsoft 365. Diese Dienste stellen besondere Herausforderungen an die Sicherheit, da sie von externen Anbietern betrieben werden und somit andere Kontroll- und Sicherheitsmechanismen erfordern als interne IT-Ressourcen.

Grundlegende Funktionsunterschiede bei Cloud Computing

Der wesentliche Unterschied zwischen On-Premises- und Cloud-Umgebungen liegt in der Art und Weise, wie Daten verarbeitet, der Datenverkehr gesteuert sowie Berechtigungen und Zugriffsrechte für Dienste und Benutzer gehandhabt werden. Diese Unterschiede sind insbesondere aus sicherheitstechnischer Sicht von großer Bedeutung.

Datenverarbeitung in der Cloud

Daten in der Cloud werden nicht auf herkömmlichen Festplatten oder Solid-State-Drives gespeichert. Für den Cloud Service Consumer (CSC) erscheint es zwar so, als wären Objektspeicher oder Datenbanken in einem Konto vorhanden, tatsächlich jedoch werden die realen Daten über hunderte bis tausende unterschiedliche Speichersysteme verteilt. Diese unterschiedlichen Systeme schaffen einen großen Speicherpool, aus dem der CSC virtuelle Festplatten beziehen kann. Dieses ungewöhnliche Verfahren der Datenspeicherung bietet einen bedeutenden Vorteil, der Cloud-Nutzern oft nicht bewusst ist. Zum Beispiel, wenn Daten in einem verschlüsselten Objektspeicher abgelegt werden, werden sie zunächst mit einem speziellen Schlüssel verschlüsselt und anschließend kryptografisch in Stücke gespalten. Diese Stücke werden dann über viele verschiedene Speichersysteme verteilt. Ein weiterer Unterschied zur herkömmlichen Datenverarbeitung besteht im Prozess des Datenzugriffs [6].

Um auf verschlüsselte Daten in der Cloud zuzugreifen, werden aus Sicht des Nutzers folgende Schritte überprüft und ausgeführt:

• Hat der Nutzer die Berechtigung, auf den Objektspeicher zuzugreifen?
• Hat der Objektspeicher Zugriff auf den Schlüssel zur Datenentschlüsselung?
• Der Objektspeicher sammelt alle verteilten Datenstücke.
• Nachdem alle Datenstücke zusammengetragen wurden, erfolgt die Entschlüsselung.
• Die angeforderten Daten oder die verfügbare Dateistruktur werden an den Benutzer gesendet, der die Anfrage initiiert hat.

Ein wichtiger Hinweis hierbei ist, dass jeder Datenzugriff auf einen Cloud-Dienst immer über eine API abgewickelt wird. Dies unterscheidet sich von On-Premises-Umgebungen, wo Dateidienste normalerweise über bestimmte TCP-Ports erreichbar sind (z.B. SMB, FTP, etc..

Datenverkehrsströme in der Cloud

Ein wesentlicher sicherheitstechnischer Unterschied zu einer On-Premises-Umgebung besteht darin, dass es in der Cloud keinen klar definierten Perimeter (die Unterscheidung zwischen öffentlichen und privaten Netzwerken) gibt. Alle Cloud-Dienste können sowohl privat als auch öffentlich sein. Zusätzlich verhält sich der Datenverkehr in der Cloud anders. In der Cloud existiert keine L2-Segmentierung, da diese Schicht abstrahiert wird. Es ist möglich, dass zwei virtuelle Maschinen (VMs) in unterschiedlichen Netzwerken direkt miteinander kommunizieren, ohne einen Standard-Gateway zu durchlaufen. Daher ist es in einer Cloud-Umgebung nicht nur schwierig, eine L2-, sondern auch eine L3-Segmentierung zu verwalten. Es hängt letztendlich davon ab, wie das Routing konfiguriert ist und welche Datenverkehrsströme entstehen. Anstatt verschiedene Netzwerksegmente wie in einem Rechenzentrum zu schützen, kommt es nun darauf an, die Datenverkehrsströme (insbesondere das dahinterliegende Routing) der Anwendungen zu verstehen und zu sichern. In Cloud-Begriffen gibt es im Allgemeinen drei Haupttypen von Datenverkehrsströmen, die adressiert werden müssen [10]:

• Northbound Traffic: Datenverkehr, der aus dem Internet stammt und versucht, auf eine öffentliche Anwendung eines Unternehmens zuzugreifen.
• Southbound Traffic: Datenverkehr, der aus dem internen Netzwerk eines Unternehmens auf eine Cloud-Umgebung zugreift (z. B. ein Benutzer aus einem Büro oder Home-Office).
• East-West Traffic: Datenverkehr, der innerhalb einer Cloud-Umgebung zwischen den Anwendungen und Diensten stattfindet. Diese Datenströme umfassen alle Kommunikationen, die innerhalb der Cloud-Umgebung eines Unternehmens stattfinden.

Alle diese drei Datenverkehrsströme sollten auf eine Weise geschützt werden, die den Sicherheitsanforderungen des Unternehmens entspricht. Beispielsweise sollte es nicht möglich sein, dass ein Dienst, der über Northbound Traffic erreichbar ist, die Berechtigung hat, auf interne Ressourcen des Unternehmens zuzugreifen (unabhängig davon, ob diese sich in der Cloud oder an einem anderen Ort befinden).

Berechtigungshandling für Dienste und Benutzer

Ein weiterer wesentlicher Unterschied in der Cloud besteht darin, wie der Zugriff zwischen Ressourcen gehandhabt wird. Für das Berechtigungsmanagement verlassen sich Cloud Service Provider (CSPs) stark auf ein Identity and Access Management (IAM\glsadd{iam}) System. Diese IAM-Lösungen verwalten alle Berechtigungen jeder Cloud-Ressource. Dies bedeutet, dass ein IAM als zentraler Regulator für alle Berechtigungen von Benutzern und Diensten fungiert. Es reguliert, welche Dienste miteinander kommunizieren können, welche spezifischen Diensttypen auf eine Datenbank oder einen Schlüssel für kryptografische Operationen zugreifen können und welche Benutzer die Berechtigung haben, auf Dienste zuzugreifen, sie zu ändern oder zu löschen. Dadurch ist es möglich, Berechtigungen auf granularer Ebene zu verwalten, und Unternehmen können eine Zero-Trust-Architektur sowie die Prinzipien des geringsten Zugriffsrechts umsetzen [11].

Allgemeine und rechtliche Aspekte bei der Nutzung von Cloud-Diensten

Unabhängig davon, ob ein Unternehmen eine Public, Private oder Hybrid Cloud nutzt, bleiben die allgemeinen und rechtlichen Aspekte bei der Nutzung von Cloud-Diensten weitgehend dieselben. Diese Aspekte betreffen alle Formen der Cloud-Nutzung und sind entscheidend, um die Sicherheit, den Datenschutz und die Einhaltung rechtlicher Vorgaben zu gewährleisten. Dabei müssen Unternehmen sicherstellen, dass die gewählten Cloud-Lösungen nicht nur technologisch, sondern auch rechtlich den Anforderungen entsprechen. Dies gilt gleichermaßen für die Speicherung und Verarbeitung sensibler Daten wie für die Verantwortung und Haftung im Falle von Sicherheitsvorfällen.

Datenschutzrechtliche Anforderungen

GDPR-Konformität:

Die Datenschutz-Grundverordnung (General Data Protection Regulation, GDPR) ist eine der wichtigsten rechtlichen Rahmenbedingungen für den Schutz personenbezogener Daten in der Europäischen Union. Sie legt strenge Regeln für die Erhebung, Verarbeitung, Speicherung und Weitergabe personenbezogener Daten fest. Für Unternehmen, die Cloud-Dienste nutzen, ist die Einhaltung der GDPR von zentraler Bedeutung, um hohe Bußgelder und rechtliche Konsequenzen zu vermeiden. Dies umfasst insbesondere die Verpflichtung, nur Daten zu verarbeiten, für die eine klare rechtliche Grundlage besteht, wie z. B. die Einwilligung der betroffenen Person, und sicherzustellen, dass die Daten nur für den vorgesehenen Zweck verwendet werden.

Ein wichtiger Aspekt der GDPR-Konformität bei der Cloud-Nutzung ist die Notwendigkeit, sicherzustellen, dass Cloud-Anbieter ausreichende technische und organisatorische Maßnahmen ergreifen, um die Sicherheit der verarbeiteten Daten zu gewährleisten. Dazu gehören Maßnahmen zur Verschlüsselung von Daten, die Implementierung von Zugriffssteuerungen und die Fähigkeit, die Integrität und Vertraulichkeit von Daten zu wahren. Unternehmen müssen sicherstellen, dass ihre Cloud-Anbieter GDPR-konform sind und entsprechende Datenverarbeitungsverträge (Data Processing Agreements, DPA) abschließen, um ihre rechtlichen Verpflichtungen zu erfüllen.

Datenlokalisierung und -souveränität:

Ein weiteres zentrales Thema im Rahmen der Datenschutzanforderungen ist die Datenlokalisierung und -souveränität. Datenlokalisierung bezieht sich auf die Pflicht, Daten innerhalb einer bestimmten geografischen Region zu speichern und zu verarbeiten. Dies kann durch gesetzliche Anforderungen oder durch unternehmensinterne Richtlinien vorgegeben sein, um sicherzustellen, dass Daten den lokalen Datenschutzgesetzen unterliegen und vor ausländischem Zugriff geschützt sind.

Für Unternehmen in der EU bedeutet dies, dass personenbezogene Daten bevorzugt innerhalb des Europäischen Wirtschaftsraums (EWR) gespeichert werden sollten, um sicherzustellen, dass sie den strengen europäischen Datenschutzstandards entsprechen. Werden Daten in Drittländer übertragen, müssen zusätzliche Schutzmaßnahmen, wie z. B. Standardvertragsklauseln oder Binding Corporate Rules (BCRs), implementiert werden, um den Schutz der Daten zu gewährleisten. Die Wahl eines Cloud-Anbieters, der mehrere Rechenzentren in verschiedenen geografischen Regionen anbietet, kann Unternehmen dabei helfen, den Anforderungen an die Datenlokalisierung gerecht zu werden und die Datenhoheit zu wahren.

Rechtliche Verantwortung und Haftung

Vertragsgestaltung:

Die rechtliche Verantwortung und Haftung bei der Nutzung von Cloud-Diensten hängen maßgeblich von den vertraglichen Vereinbarungen zwischen dem Cloud-Anbieter und dem Kunden ab. Eine sorgfältige Vertragsgestaltung ist entscheidend, um klar festzulegen, welche Partei für welche Aspekte der Sicherheit und des Datenschutzes verantwortlich ist. Dies ist insbesondere im Kontext des Shared Responsibility Models von Bedeutung, da sowohl der Cloud-Anbieter als auch der Kunde spezifische Pflichten übernehmen müssen.

Verträge sollten detaillierte Klauseln enthalten, die die Verantwortlichkeiten im Falle eines Sicherheitsvorfalls regeln, einschließlich der Pflicht zur Meldung von Datenschutzverletzungen und der Haftung für entstandene Schäden. Zudem sollten Service Level Agreements (SLAs) definiert werden, die die Leistungserwartungen, Verfügbarkeit und Reaktionszeiten des Cloud-Anbieters festlegen. Ein weiterer wichtiger Punkt ist die Regelung der Datenrückgabe und -löschung nach Vertragsende, um sicherzustellen, dass personenbezogene Daten ordnungsgemäß gelöscht und nicht unbefugt weiterverwendet werden.

Regulatorische Anforderungen:

Neben den allgemeinen datenschutzrechtlichen Vorgaben gibt es auch branchenspezifische regulatorische Anforderungen, die bei der Nutzung von Cloud-Diensten berücksichtigt werden müssen. Diese können je nach Branche und Art der verarbeiteten Daten stark variieren. Beispielsweise müssen Unternehmen im Finanzsektor besondere Vorschriften zur Datensicherheit und -integrität beachten, wie sie in Richtlinien wie der Payment Card Industry Data Security Standard (PCI DSS) oder den aufsichtsrechtlichen Anforderungen der Europäischen Bankenaufsichtsbehörde (EBA) festgelegt sind.

Auch der Gesundheitssektor unterliegt strengen regulatorischen Anforderungen, wie z. B. der Health Insurance Portability and Accountability Act (HIPAA) in den USA oder die EU-Verordnung über elektronische Gesundheitsdienste. Diese Vorschriften schreiben vor, wie sensible Gesundheitsdaten geschützt und verarbeitet werden müssen. Unternehmen, die Cloud-Dienste nutzen, müssen sicherstellen, dass ihre Cloud-Umgebung diese speziellen Compliance-Anforderungen erfüllt und entsprechende Zertifizierungen des Cloud-Anbieters vorhanden sind.

Vor allem in der Europäischen Union ändern sich aktuell die Cybersicherheitsanforderungen für Unternehmen enorm. Je nach Branche und Unternehmensgröße bzw. Unternehmensorientierung müssen gewisse Cybersicherheitsmaßnahmen umgesetzt werden. Das gilt natürlich auch für das Bereitstellen und Hosten von Infrastruktur und Services in einer Cloud Plattform.

Die Einhaltung dieser regulatorischen Vorgaben ist nicht nur eine rechtliche Notwendigkeit, sondern auch ein wesentlicher Bestandteil des Risikomanagements und der Vertrauensbildung gegenüber Kunden und Geschäftspartnern.

Wartbarkeit von Systemen

Die Wartbarkeit von Systemen ist ein zentraler Aspekt beim Betrieb von Cloud-Diensten und bezieht sich auf die Fähigkeit, Systeme effizient zu pflegen, zu aktualisieren und zu überwachen, um ihre kontinuierliche Verfügbarkeit und Leistungsfähigkeit sicherzustellen. In der dynamischen und komplexen Umgebung von Cloud-Architekturen ist die Wartbarkeit ein wesentlicher Faktor, der die Betriebsbereitschaft und Sicherheit von Anwendungen und Daten beeinflusst.

Regelmäßige Updates und Patch-Management

Ein wichtiger Aspekt der Wartbarkeit ist das regelmäßige Einspielen von Software-Updates und Sicherheitspatches. Cloud-Umgebungen sind ständig wechselnden Bedrohungen ausgesetzt, und Sicherheitslücken in Softwarekomponenten können schnell zu einem Risiko werden, wenn sie nicht zeitnah behoben werden. Unternehmen müssen sicherstellen, dass ihre Cloud-Umgebung durch automatisierte Update- und Patch-Management-Prozesse auf dem neuesten Stand gehalten wird, um potenzielle Angriffsvektoren zu minimieren.

Automatisierte Überwachung und Protokollierung

Eine effektive Überwachung ist entscheidend für die Wartbarkeit von Cloud-Systemen. Durch den Einsatz automatisierter Überwachungslösungen können Unternehmen kontinuierlich die Leistung und den Zustand ihrer Cloud-Infrastruktur überwachen. Dabei sollten auch umfangreiche Protokollierungsmechanismen eingerichtet werden, um im Falle von Störungen oder Sicherheitsvorfällen schnell reagieren zu können. Die Protokolle sollten regelmäßig überprüft und analysiert werden, um ungewöhnliche Aktivitäten oder potenzielle Probleme frühzeitig zu erkennen.

Skalierbarkeit und Ressourcenmanagement

Die Fähigkeit, Ressourcen in einer Cloud-Umgebung flexibel zu skalieren, ist ein weiterer wichtiger Aspekt der Wartbarkeit. Unternehmen müssen sicherstellen, dass ihre Cloud-Dienste auf wachsende Anforderungen reagieren können, ohne die Leistungsfähigkeit zu beeinträchtigen. Dies erfordert eine sorgfältige Planung und das Management von Ressourcen, um Über- oder Unterprovisionierung zu vermeiden und gleichzeitig die Kosten im Blick zu behalten. Ein effektives Ressourcenmanagement trägt auch dazu bei, die Effizienz und Nachhaltigkeit der Cloud-Nutzung zu verbessern.

Dokumentation und Wissensmanagement

Eine umfassende und aktuelle Dokumentation ist essenziell für die Wartbarkeit von Cloud-Systemen. Sie stellt sicher, dass alle relevanten Informationen über die Systemarchitektur, Konfigurationen, Prozesse und Verfahren leicht zugänglich sind. Dies ist besonders wichtig in Situationen, in denen schnelles Handeln erforderlich ist, etwa bei der Behebung von Störungen oder Sicherheitsvorfällen. Zudem erleichtert eine gute Dokumentation den Wissenstransfer innerhalb des Unternehmens und reduziert das Risiko von Wissensverlust, beispielsweise durch Personalwechsel.

Notfallplanung und Disaster Recovery

Ein weiterer wichtiger Aspekt der Wartbarkeit ist die Vorbereitung auf Notfälle und die Implementierung von Disaster-Recovery-Plänen. Unternehmen müssen sicherstellen, dass sie über robuste Strategien verfügen, um im Falle eines Ausfalls schnell wieder betriebsbereit zu sein. Dazu gehört die regelmäßige Überprüfung und Aktualisierung von Wiederherstellungsplänen sowie die Durchführung von Tests, um die Effektivität der Maßnahmen zu gewährleisten. Cloud-Anbieter bieten oft integrierte Tools und Dienste an, die Unternehmen dabei unterstützen, ihre Disaster-Recovery-Strategien zu implementieren und zu optimieren.

Compliance und Audits

Die Einhaltung von gesetzlichen und regulatorischen Anforderungen ist ein weiterer Aspekt, der die Wartbarkeit von Systemen beeinflusst. Unternehmen müssen sicherstellen, dass ihre Cloud-Infrastruktur den relevanten Compliance-Anforderungen entspricht und regelmäßig überprüft wird. Dies umfasst auch die Durchführung von internen und externen Audits, um Schwachstellen zu identifizieren und die Wirksamkeit der implementierten Sicherheits- und Wartungsmaßnahmen zu bewerten. Die Ergebnisse solcher Audits sollten genutzt werden, um kontinuierliche Verbesserungen in der Wartbarkeit der Systeme zu erzielen.

Shared Responsibility Model und dessen Bedeutung für die Sicherheit

Grundprinzipien des Shared Responsibility Models

Das Shared Responsibility Model ist ein zentrales Konzept in der Cloud-Nutzung, dass die Aufteilung der Sicherheitsverantwortung zwischen dem Cloud-Anbieter (Cloud Service Provider, CSP) und dem Cloud-Kunden (Cloud Service Customer, CSC) regelt. Dieses Modell stellt sicher, dass beide Parteien klar verstehen, welche Sicherheitsmaßnahmen sie ergreifen müssen, um eine sichere Cloud-Umgebung zu gewährleisten. Ein umfassendes Verständnis des gewählten Service-Modells ist hierbei entscheidend, da die Verantwortlichkeiten stark variieren können.

Aufteilung der Sicherheitsverantwortung:

Im Rahmen des Shared Responsibility Models liegt die Verantwortung für die Sicherheit der zugrunde liegenden Cloud-Infrastruktur, einschließlich physischer Sicherheit, Netzwerkschutz und Virtualisierung, beim Cloud-Anbieter. Der Cloud-Kunde ist hingegen für alles verantwortlich, was er in die Cloud einbringt und wie er die Cloud-Dienste nutzt. Dies umfasst die Verwaltung und Sicherheit seiner Daten, die Implementierung von Sicherheitsprotokollen, die Konfiguration von Zugriffsrechten sowie die Überwachung und Wartung der Anwendungen und Betriebssysteme.

Abhängigkeit vom Service-Modell:

Die Verteilung der Sicherheitsverantwortlichkeiten variiert je nach dem gewählten Cloud-Service-Modell. Es ist essenziell, dass Unternehmen die spezifischen Sicherheitsanforderungen ihres genutzten Modells verstehen und entsprechend handeln.

Infrastructure as a Service (IaaS):

Beim IaaS-Modell bleibt die meiste Sicherheitsverantwortung beim Kunden. Während der Cloud-Anbieter die physische Infrastruktur, Virtualisierung, Netzwerke und Speicherressourcen sichert, ist der Kunde für die Sicherheit des Betriebssystems, der Anwendungen, der Daten sowie der Netzwerkkonfigurationen verantwortlich. Dies schließt regelmäßige Sicherheitsupdates, Patching, Firewall-Konfigurationen und den Schutz der Daten ein. Hier muss der Kunde auch sicherstellen, dass Betriebssysteme und Anwendungen stets auf dem neuesten Stand gehalten werden und dass Sicherheitslücken geschlossen werden.

Platform as a Service (PaaS):

Im PaaS-Modell übernimmt der Cloud-Anbieter zusätzlich die Verantwortung für das Betriebssystem, die Laufzeitumgebung und die Middleware. Der Kunde konzentriert sich auf die Sicherheit der Anwendungen, die er entwickelt und bereitstellt, sowie auf die Verwaltung der Daten. Hier spielen Sicherheitsmaßnahmen wie der Schutz vor unbefugtem Zugriff, Datenverschlüsselung und die Implementierung sicherer Entwicklungspraktiken eine zentrale Rolle. Auch das Testen von Anwendungen auf Schwachstellen und die Sicherstellung, dass sensible Daten geschützt sind, fällt in den Verantwortungsbereich des Kunden.

Software as a Service (SaaS):

Bei SaaS übernimmt der Cloud-Anbieter die meisten Sicherheitsverantwortungen, einschließlich der gesamten Infrastruktur, Anwendungen und Datenverwaltung. Der Kunde ist hauptsächlich für die Verwaltung von Benutzerzugriffen, die Konfiguration von Sicherheitseinstellungen innerhalb der Anwendung und die Sicherstellung der sicheren Nutzung verantwortlich. Hier sind die Implementierung von Multi-Faktor-Authentifizierung (MFA) und die Überwachung von Zugriffsmustern entscheidend, um unbefugten Zugriff zu verhindern.

Function as a Service (FaaS):

FaaS, auch bekannt als serverless computing, ist eine Erweiterung von PaaS, bei der der Kunde noch weniger Verantwortung trägt. Der CSP übernimmt hier die komplette Verwaltung und Sicherheit der Laufzeitumgebung und Infrastruktur. Der Kunde ist jedoch weiterhin für die Sicherheit des Codes, der in den Funktionen läuft, sowie für die Verwaltung der Zugriffsrechte und die Sicherstellung, dass sensible Daten geschützt sind, verantwortlich. Es ist auch wichtig, sicherzustellen, dass Funktionen sicher entwickelt und regelmäßig auf Schwachstellen überprüft werden.

Container as a Service (CaaS):

CaaS ermöglicht es Unternehmen, Container bereitzustellen, zu verwalten und zu orchestrieren. Der CSP sichert die zugrunde liegende Infrastruktur und die Container-Orchestrierung, während der Kunde für die Sicherheit der Container, der Anwendungen, die in diesen Containern laufen, und die Implementierung von Sicherheitsmaßnahmen wie Netzwerksegmentierung, Zugriffskontrolle und Container-Image-Scans verantwortlich ist. Es ist entscheidend, dass Container regelmäßig überprüft werden, um sicherzustellen, dass keine bekannten Sicherheitslücken vorhanden sind.

Evaluierung der notwendigen Sicherheitsmaßnahmen:

Ein wesentlicher Aspekt bei der Nutzung von Cloud-Diensten ist die Evaluierung und Implementierung von Sicherheitsmaßnahmen, die den jeweiligen Verantwortlichkeiten im Rahmen des gewählten Service-Modells entsprechen. Unternehmen müssen ihre Security-Strategie auf der Grundlage des Shared Responsibility Models anpassen und sicherstellen, dass alle Aspekte, für die sie verantwortlich sind, abgedeckt sind.

Sicherheitsbewertung je nach Service-Modell:

Um die richtigen Sicherheitsmaßnahmen zu identifizieren, sollten Unternehmen eine detaillierte Analyse der Service-Modelle durchführen, die sie nutzen. Diese Bewertung sollte sowohl die technischen als auch die organisatorischen Sicherheitsmaßnahmen umfassen. Bei IaaS müssen beispielsweise Maßnahmen zur Sicherung des gesamten Software-Stacks implementiert werden, während bei SaaS der Fokus auf der Verwaltung von Benutzerzugriffen und Daten liegt.

Best Practices:

Unabhängig vom Service-Modell sollten einige grundlegende Sicherheitspraktiken implementiert werden. Dazu gehören die Verschlüsselung von Daten sowohl bei der Übertragung als auch im Ruhezustand, die Implementierung von strengen Zugangskontrollen, die Nutzung von Multi-Faktor-Authentifizierung und regelmäßige Sicherheitsaudits. Zusätzlich sollten Unternehmen sicherstellen, dass sie über robuste Incident-Response-Pläne verfügen, um schnell auf Sicherheitsvorfälle reagieren zu können.

Zusammenfassend sollten Unternehmen ein tiefes Verständnis für das gewählte Cloud-Service-Modell entwickeln und ihre Sicherheitsmaßnahmen entsprechend den spezifischen Anforderungen und Verantwortlichkeiten anpassen. Nur so lässt sich eine effektive Sicherheitsstrategie entwickeln, die die Risiken bei der Nutzung von Cloud-Diensten minimiert.

Wichtigste Sicherheitsvorkehrung beim Verwenden von Cloud-Ressourcen

Eine der wichtigsten Sicherheitsvorkehrungen beim Einsatz von Cloud-Ressourcen, sei es in einer Public oder Private Cloud, ist der Schutz der Cloud Control Plane – also der Management-Plattform, über die die Cloud-Umgebung verwaltet wird. Der Zugriff auf diese zentrale Steuerungsebene muss besonders sorgfältig abgesichert werden, da hier sämtliche Berechtigungen und Zugriffsrechte verwaltet werden.

Absicherung des Root-Accounts und Berechtigungskonzept

In jeder Cloud-Umgebung ist der Root-Account oder ein Admin-Account das Herzstück der Sicherheitsarchitektur. Dieser Account besitzt umfassende Berechtigungen, die es ermöglichen, Cloud-Ressourcen zu erstellen, zu verändern oder zu löschen. In einer Public Cloud hat der Root-Account zudem Zugriff auf Zahlungsinformationen und kann somit auch finanzielle Entscheidungen beeinflussen, wie z. B. die Bereitstellung kostenintensiver Dienste. Daher ist es von entscheidender Bedeutung, diesen Account durch starke Authentifizierungsmethoden abzusichern, wie etwa Multi-Faktor-Authentifizierung (MFA).

Darüber hinaus sollte ein umfassendes Berechtigungskonzept (Permission Model) implementiert werden, das den Zugriff auf die Cloud-Ressourcen auf ein Minimum beschränkt. Das Prinzip der geringsten Privilegien (Least Privilege Principle) sollte konsequent angewendet werden, um sicherzustellen, dass Benutzer nur die Rechte erhalten, die sie für ihre Aufgaben benötigen. Durch die Einführung rollenbasierter Zugriffskontrollen (RBAC) können Unternehmen sicherstellen, dass verschiedene Benutzergruppen nur auf die für sie relevanten Teile der Cloud-Infrastruktur zugreifen können.

Überwachung und Auditing

Die Absicherung der Cloud Control Plane sollte durch kontinuierliche Überwachung und regelmäßige Audits ergänzt werden. Diese Maßnahmen helfen dabei, unbefugte Zugriffsversuche frühzeitig zu erkennen und mögliche Sicherheitslücken zu schließen. Logging und Monitoring der Aktivitäten auf der Management-Plattform sind unerlässlich, um ein hohes Sicherheitsniveau aufrechtzuerhalten und im Falle eines Sicherheitsvorfalls schnell reagieren zu können.

Schulungen und Sicherheitsbewusstsein

Zuletzt ist es wichtig, dass alle Mitarbeiter, die Zugriff auf die Cloud Control Plane haben, regelmäßig geschult werden. Sicherheitsbewusstsein und Kenntnisse über aktuelle Bedrohungen sind entscheidend, um menschliche Fehler zu minimieren, die oft das größte Risiko für die Sicherheit von Cloud-Ressourcen darstellen.

Private & Public Cloud Security

Der Unterschied zwischen der Sicherheit in privaten und öffentlichen Clouds kann im Wesentlichen auf die unterschiedlichen Rahmenbedingungen und Ansätze zurückgeführt werden. Während sich die Sicherheit in der Private Cloud stark an traditionellen Sicherheitskonzepten orientiert, die aus den Bereichen Rechenzentrums- und Netzwerksicherheit stammen, erfordert die Public Cloud einen anderen Ansatz. In der Public Cloud sind Ressourcen plötzlich bei einem fremden Unternehmen auf einer geteilten Plattform verfügbar. Aus Sicherheitsaspekten stehen hier Themen wie Vertrauen in den Cloud Service Provider (CSP), das Sicherheitsniveau des CSP, die klare Abgrenzung der Ressourcen in der Cloud (Schaffung eines „Perimeters“) und das Bewusstsein darüber, welche Cloud-Service-Modelle im Einsatz sind und wie diese bestmöglich abgesichert werden können, im Vordergrund.

Private Cloud Security

Um eine sichere Private Cloud zu betreiben, ist es entscheidend, sich über den hohen Aufwand bewusst zu sein, der mit dem Betrieb verbunden ist. Es erfordert die Bereitstellung, Konfiguration, Instandhaltung, den Betrieb und regelmäßige Aktualisierung der notwendigen Komponenten in einem Rechenzentrum. Das OSI-Referenzmodell kann hier als Leitfaden dienen, denn alle sieben Schichten dieses Modells müssen vom Betreiber der Private Cloud adressiert und konfiguriert werden. Dies umfasst nicht nur die Netzwerkinfrastruktur, sondern auch physische Aspekte wie die Stromversorgung und die physische Sicherheit des Rechenzentrums. Für den weiteren Verlauf nehmen wir an, dass die Private Cloud in einem sicheren, vorhandenen oder angemieteten Rechenzentrumsbereich aufgebaut wird. Der Betrieb des Rechenzentrums selbst wäre ansonsten ebenfalls Teil der Verantwortung.

Technische Grundlage

Grundlegender Aufbau eines Rechenzentrums (vereinfacht)

Diese Grafik veranschaulicht den grundlegenden Aufbau eines Rechenzentrums für eine Private Cloud-Infrastruktur. Im vereinfachten Modell bilden mehrere zentrale Komponenten das Fundament für den Betrieb einer Private Cloud:

1. Internetzugang: Dieser ermöglicht die Anbindung des Rechenzentrums an externe Netzwerke, einschließlich der öffentlichen Cloud und des Internets.
2. Netzwerkinfrastruktur: Hierzu gehören wesentliche Netzwerkkomponenten wie Switches, Firewalls und Router, die den Datenverkehr innerhalb des Rechenzentrums steuern und absichern.
3. Rechenressourcen (Compute Power): Mehrere Server, auch als Compute Nodes bezeichnet, stellen die benötigte Rechenleistung zur Verfügung.
4. Speicherlösungen: Hochverfügbare Speichersysteme gewährleisten die sichere und effiziente Speicherung und Verwaltung von Daten.

Auf dieser physischen Infrastruktur wird ein Hypervisor installiert, der als zentrale Verwaltungsschicht fungiert. Der Hypervisor bietet Zugriff auf die gesamten Rechenressourcen, das Speichersystem und die Netzwerkinfrastruktur. Dadurch ermöglicht er die Virtualisierung und Verwaltung der verschiedenen Komponenten, die für den Betrieb einer Private Cloud notwendig sind.

Storage

Die Grundlage jeder Cloud-Infrastruktur ist ein zuverlässiges und skalierbares Speichersystem. In einer Private Cloud muss der Speicher lokal verwaltet werden, was bedeutet, dass alle Sicherheitsmaßnahmen wie Datenverschlüsselung, Zugriffskontrollen und regelmäßige Backups intern organisiert werden müssen. Der Speicher muss nicht nur sicher, sondern auch performant sein, um die Anforderungen der Virtualisierung und der Workloads in der Cloud zu erfüllen.

Beispiele für Speichertechnologien in der Private Cloud sind Network Attached Storage (NAS) und Storage Area Networks (SAN). Diese Technologien ermöglichen es Unternehmen, große Mengen an Daten effizient zu speichern und gleichzeitig die Verfügbarkeit und Sicherheit dieser Daten zu gewährleisten. Eine typische Herausforderung bei der Verwaltung von Speicherressourcen in einer Private Cloud besteht darin, eine Balance zwischen Performance und Sicherheit zu finden. So müssen Unternehmen sicherstellen, dass sensible Daten verschlüsselt und vor unberechtigtem Zugriff geschützt sind, während sie gleichzeitig dafür sorgen, dass die Performance nicht durch übermäßige Sicherheitsmaßnahmen beeinträchtigt wird.

Ein weiteres Beispiel ist die Implementierung von dedizierten Backup-Systemen innerhalb der Private Cloud. Diese Systeme müssen so konzipiert sein, dass sie nicht nur regelmäßige Backups erstellen, sondern auch schnelle Wiederherstellungszeiten bieten, um im Falle eines Datenverlusts oder einer Sicherheitsverletzung den Betrieb schnell wieder aufnehmen zu können. Hierbei kann die Kombination von lokalen und cloud-basierten Backup-Lösungen (Hybrid Backup) dazu beitragen, die Datensicherheit zu erhöhen und das Risiko eines vollständigen Datenverlusts zu minimieren.

Software Defined Networking

Software Defined Networking ist ein essenzieller Bestandteil moderner Private Clouds. SDN ermöglicht eine flexible, zentrale Steuerung des Netzwerks, was eine dynamische Anpassung der Netzwerkkonfigurationen an sich ändernde Anforderungen erlaubt. Im Kontext der Sicherheit bedeutet dies, dass Netzwerksicherheitsrichtlinien zentral implementiert und durchgesetzt werden können. Dies ermöglicht eine schnellere Reaktion auf Bedrohungen und eine bessere Kontrolle über den Netzwerkverkehr.

In einer Private Cloud bietet SDN die Möglichkeit, Netzwerkressourcen unabhängig von der physischen Infrastruktur zu konfigurieren und zu verwalten. Dies ist besonders wichtig, wenn es darum geht, verschiedene Sicherheitszonen innerhalb des Netzwerks zu erstellen und zu verwalten. Beispielsweise können über SDN spezifische Sicherheitsrichtlinien für den Datenverkehr zwischen verschiedenen Abteilungen innerhalb eines Unternehmens festgelegt werden, sodass sensible Datenströme streng überwacht und geschützt werden können.

Ein praktisches Beispiel für den Einsatz von SDN in der Private Cloud ist die Implementierung von dynamischen Firewalls und Intrusion Prevention Systems (IPS), die in Echtzeit auf Sicherheitsvorfälle reagieren können. Durch die zentrale Verwaltung dieser Sicherheitslösungen über SDN kann das Netzwerk schnell an neue Bedrohungen angepasst werden, ohne dass umfangreiche manuelle Konfigurationsänderungen erforderlich sind. SDN ermöglicht es auch, schnell auf Änderungen im Netzwerkverkehr zu reagieren, wie z.B. bei einem plötzlichen Anstieg des Datenverkehrs, der auf einen DDoS-Angriff hinweisen könnte. In solchen Fällen kann das SDN die Netzwerkkapazität automatisch anpassen und den verdächtigen Datenverkehr isolieren, um die Auswirkungen auf die Gesamtinfrastruktur zu minimieren.

Hypervisor

Der Hypervisor ist die Schicht, die die Virtualisierung in der Private Cloud ermöglicht. Er sorgt dafür, dass mehrere virtuelle Maschinen (VMs) auf einem physischen Server sicher und effizient betrieben werden können. Die Sicherheit des Hypervisors ist von größter Bedeutung, da eine Kompromittierung dieser Schicht zu einem unkontrollierten Zugriff auf alle virtuellen Maschinen führen könnte. Daher müssen Hypervisoren regelmäßig gepatcht und nach bewährten Sicherheitspraktiken konfiguriert werden.

Es gibt zwei Haupttypen von Hypervisoren: Typ-1-Hypervisoren (Bare-Metal) und Typ-2-Hypervisoren (Hosted). Typ-1-Hypervisoren, wie VMware ESXi oder Microsoft Hyper-V, werden direkt auf der Hardware installiert und bieten dadurch eine höhere Performance und Sicherheit, da sie weniger Angriffsflächen bieten als Typ-2-Hypervisoren. Typ-2-Hypervisoren, wie VMware Workstation oder Oracle VirtualBox, laufen auf einem bestehenden Betriebssystem und sind daher in der Regel weniger sicher und performant.

Ein wesentlicher Sicherheitsaspekt bei der Verwendung von Hypervisoren in einer Private Cloud ist die Isolation der VMs. Durch die strikte Trennung der Ressourcen zwischen verschiedenen VMs kann verhindert werden, dass ein Angriff auf eine VM auf andere VMs oder die darunterliegende Hardware übergreift. Dies wird durch Funktionen wie Virtual Machine Introspection (VMI) erreicht, die es ermöglichen, das Verhalten von VMs in Echtzeit zu überwachen und verdächtige Aktivitäten zu erkennen.

Ein weiteres Beispiel für den Einsatz von Hypervisoren in der Private Cloud ist die Nutzung von Snapshots und Cloning-Funktionen. Diese ermöglichen es, Zustände von VMs zu einem bestimmten Zeitpunkt zu speichern und bei Bedarf wiederherzustellen. Dies ist besonders nützlich für die Durchführung von Updates oder Konfigurationsänderungen, da im Falle eines Fehlers die VM schnell in ihren vorherigen Zustand zurückversetzt werden kann. Solche Funktionen tragen zur erhöhten Betriebszeit und Sicherheit der Cloud-Umgebung bei.

Security Maßnahmen

Die Sicherheitsmaßnahmen in einer Private Cloud umfassen verschiedene Technologien und Strategien, um die Integrität, Verfügbarkeit und Vertraulichkeit der Ressourcen zu gewährleisten. Diese Maßnahmen müssen sorgfältig implementiert und kontinuierlich überwacht werden, um den spezifischen Sicherheitsanforderungen einer Private Cloud gerecht zu werden.

Macro Segmentation (Layer 3 Segementation)

Die Macro-Segmentierung, auch bekannt als Layer-3-Segmentierung, ist eine Technik zur Unterteilung des Netzwerks in größere, logisch getrennte Subnetze. Diese Segmente isolieren unterschiedliche Netzwerkzonen, wie zum Beispiel Entwicklungs-, Test- und Produktionsumgebungen, voneinander. Der Hauptvorteil der Macro-Segmentierung besteht darin, dass sie den Datenverkehr zwischen verschiedenen Netzwerkzonen kontrolliert und begrenzt. Dadurch wird das Risiko eines seitlichen (lateralen) Bewegens eines Angreifers innerhalb des Netzwerks erheblich verringert.

In einer Private Cloud ist dies besonders wichtig, da verschiedene Anwendungen und Workloads oft unterschiedliche Sicherheitsanforderungen haben. Durch die Aufteilung in separate Subnetze können Organisationen sicherstellen, dass sensible Daten und kritische Systeme von weniger geschützten oder potenziell gefährdeten Bereichen getrennt bleiben. Ein praktisches Beispiel wäre die Trennung von Finanzdatenbanken von allgemeinen Webanwendungen, um zu verhindern, dass ein Angreifer, der eine Webanwendung kompromittiert, auf die Finanzdaten zugreifen kann.

Macro-Segmentierung hilft auch bei der Einhaltung von Compliance-Anforderungen, indem sie klare Grenzen für den Datenfluss zwischen verschiedenen Systemen zieht. Zum Beispiel könnte ein Unternehmen, das Kreditkartendaten verarbeitet, ein separates Subnetz für diese Daten einrichten, um die Einhaltung von PCI-DSS-Standards sicherzustellen. In diesem Subnetz könnten dann strengere Sicherheitskontrollen und Zugriffsrichtlinien angewendet werden, um die sensiblen Daten besser zu schützen.

Micro Segmentation (Layer 2 Segementation)

Micro-Segmentierung geht einen Schritt weiter als die Macro-Segmentierung, indem sie Sicherheitsrichtlinien auf einer noch feiner abgestimmten Ebene durchsetzt – nämlich auf der Ebene der virtuellen Maschinen oder sogar einzelner Anwendungen. Im Gegensatz zur Macro-Segmentierung, die große Netzwerkbereiche voneinander trennt, sorgt die Micro-Segmentierung dafür, dass jeder Host, jede Anwendung oder jede Instanz innerhalb eines Segments individuell abgesichert ist.

Diese feinkörnige Kontrolle über den Datenverkehr innerhalb des Netzwerks ist besonders effektiv, um die seitliche Bewegung von Angreifern zu verhindern. Selbst wenn ein Angreifer in eine VM oder eine Anwendung eindringen kann, wird es ihm durch die Micro-Segmentierung extrem erschwert, sich weiter im Netzwerk zu bewegen oder auf andere Ressourcen zuzugreifen.

Ein Beispiel für die Implementierung von Micro-Segmentierung in einer Private Cloud könnte die Nutzung von VMware NSX oder Cisco ACI sein, die es ermöglichen, detaillierte Sicherheitsrichtlinien für jede einzelne VM festzulegen. Diese Richtlinien könnten den Datenverkehr auf Basis von Anwendungstyp, Nutzerrollen oder sogar spezifischen Sicherheitsanforderungen der jeweiligen VM steuern. So könnte beispielsweise eine Regel festlegen, dass eine Web-Server-VM nur mit einem bestimmten Datenbankserver kommunizieren darf, und jede andere Kommunikation blockiert wird.

Ein weiteres Beispiel ist die Nutzung von Micro-Segmentierung in einer DevOps-Umgebung, in der verschiedene Entwicklungsumgebungen strikt voneinander isoliert werden. Entwickler könnten so sicherstellen, dass Änderungen an einer Anwendung nur innerhalb der vorgesehenen Umgebung getestet werden, ohne das Risiko, andere Anwendungen oder Systeme zu beeinträchtigen. Dies erhöht nicht nur die Sicherheit, sondern auch die Stabilität und Zuverlässigkeit der gesamten Cloud-Umgebung.

Perimeter Firewall

Die Perimeter-Firewall stellt die äußere Verteidigungslinie einer Private Cloud dar und kontrolliert den gesamten ein- und ausgehenden Datenverkehr. Sie ist ein kritischer Bestandteil der Sicherheitsarchitektur, da sie das Netzwerk vor externen Bedrohungen schützt und gleichzeitig den Zugang zu internen Ressourcen regelt.

In einer Private Cloud muss die Perimeter-Firewall so konfiguriert sein, dass sie nicht nur klassische Bedrohungen wie unbefugten Zugriff oder Denial-of-Service-Angriffe abwehrt, sondern auch flexibel auf neue und unbekannte Bedrohungen reagieren kann. Dazu gehört die Implementierung von Funktionen wie Intrusion Prevention Systems (IPS), die aktiv nach verdächtigen Aktivitäten im Netzwerk suchen und diese blockieren können, bevor sie Schaden anrichten.

Ein Beispiel für den Einsatz von Perimeter-Firewalls in einer Private Cloud könnte der Schutz eines Webportals sein, das Kundendaten verarbeitet. Die Firewall würde dabei sicherstellen, dass nur autorisierter Datenverkehr zum Webserver gelangt, während potenziell schädlicher Verkehr, wie etwa SQL-Injection-Versuche oder DDoS-Angriffe, abgeblockt wird. Moderne Perimeter-Firewalls sind oft auch mit Deep Packet Inspection (DPI) ausgestattet, die den Inhalt des Datenverkehrs analysiert und Bedrohungen auf Anwendungsebene erkennt.

Ein weiteres Beispiel ist die Verwendung von Application Layer Gateways (ALG), die spezifische Protokolle wie FTP, SIP oder H.323 überwachen und schützen. ALG kann tief in den Datenverkehr dieser Protokolle eindringen und potenzielle Angriffsversuche erkennen, die bei einer einfachen Paketfilterung nicht auffallen würden. Dies bietet eine zusätzliche Schutzschicht, insbesondere für Anwendungen, die über das Internet zugänglich sind.

Insgesamt spielen diese Sicherheitsmaßnahmen eine zentrale Rolle im Schutz einer Private Cloud. Sie helfen dabei, den Netzwerkverkehr zu kontrollieren, Bedrohungen zu identifizieren und abzuwehren, sowie die Vertraulichkeit, Integrität und Verfügbarkeit der Cloud-Ressourcen zu gewährleisten.

Referenzinfrastruktur – Vereinfacht

Der Betrieb einer Private Cloud ist ein anspruchsvolles Unterfangen, das sorgfältige Planung und den Einsatz von Hypervisor-Technologie erfordert. Je nach Größe der Infrastruktur und Wahl des Hypervisors kann die genaue Hardwarekonfiguration variieren. Hersteller von Hypervisoren bieten in der Regel Best Practices und Referenzarchitekturen an, um die Implementierung und den Betrieb zu erleichtern.

Sample Infrastruktur in einer private Cloud

Die dargestellte Abbildung zeigt eine stark vereinfachte Infrastruktur, die den grundsätzlichen Aufbau einer Private Cloud veranschaulicht. Diese Darstellung dient dazu, die Funktionsweise einer Private Cloud grundlegend zu verstehen, ohne dabei auf alle technischen Details einzugehen.

Grundlegende Komponenten:

1. Rack-Infrastruktur:
   • Die Basis dieser Infrastruktur bildet ein Server-Rack, das zentrale Elemente wie Netzwerkgeräte (Switches, Firewalls, Router), Speicherlösungen und Rechenressourcen (Compute Nodes) beherbergt. Diese Komponenten sind für die Verbindung mit dem Internet und anderen Teilen der Infrastruktur entscheidend.
2. Compute Power und Hypervisor:
   • Auf den Compute Nodes wird ein Hypervisor installiert, der in der Abbildung durch die violette Komponente dargestellt wird. Der Hypervisor stellt die zentrale Verwaltungsschicht dar und ermöglicht die Virtualisierung der physischen Ressourcen. Die Compute Nodes sind über Netzwerkgeräte mit dem Internet, den Speichersystemen und den anderen Compute Nodes verbunden.
3. Netzwerkkonfiguration:
   • Eine korrekte Konfiguration der Netzwerkkomponenten ist unerlässlich, um eine stabile und sichere Kommunikation innerhalb der Infrastruktur und mit externen Netzwerken zu gewährleisten. Diese Netzwerke müssen sowohl außerhalb der Virtualisierungsumgebung als auch innerhalb des Hypervisors eingerichtet werden.

Aufbau der Private Cloud im Hypervisor:

• Virtuelle Netzwerke:
  • Innerhalb des Hypervisors können verschiedene virtuelle Netzwerke erstellt werden, um unterschiedliche Funktionsbereiche voneinander zu trennen. Diese Netzwerke dienen dazu, den Datenverkehr zwischen den virtuellen Maschinen (VMs) und den physikalischen Ressourcen zu steuern und abzusichern.
• Virtuelle Maschinen und Ressourcen:
  • Der Hypervisor ermöglicht die Erstellung und Verwaltung von virtuellen Maschinen, virtuellen Loadbalancern, virtuellen Disks und weiteren virtuellen Ressourcen. Diese Ressourcen können je nach Bedarf dynamisch angepasst werden, was eine hohe Flexibilität bietet.
• Firewall und Sicherheitsmaßnahmen:
  • Eine virtuelle Maschine im Hypervisor wird oft als Firewall eingesetzt, um den Datenverkehr innerhalb der Private Cloud zu kontrollieren. Diese Firewall schützt die verschiedenen virtuellen Netzwerke und sorgt dafür, dass nur autorisierter Datenverkehr zugelassen wird.

Schematischer Aufbau der Private Cloud:

• Die Abbildung zeigt eine vereinfachte Private Cloud-Architektur, in der zwei Speichersysteme an den Hypervisor angebunden sind. Ein Speichersystem dient der normalen Datenverarbeitung, während das andere für Backups der virtuellen Maschinen und Disks vorgesehen ist.
• Für die Kommunikation mit dem Internet wird ein Transit-Netzwerk eingerichtet. Die im Hypervisor erstellten virtuellen Netzwerke ermöglichen eine feingranulare Segmentierung und Kontrolle des Datenverkehrs, was besonders wichtig für die Sicherheit und Effizienz der Cloud-Infrastruktur ist.
• Der schematische Aufbau zeigt, wie klassische Rechenzentrums-Infrastrukturen virtuell nachgebildet werden können, um die Netzwerksicherheits-Best-Practices zu erfüllen. Die Flexibilität des Hypervisors ermöglicht es, die Infrastruktur an spezifische Anforderungen anzupassen und gleichzeitig ein hohes Sicherheitsniveau aufrechtzuerhalten.

Einsatz von Private Clouds – Allgemeine Überlegungen

Es gibt zahlreiche Ansätze, eine Private Cloud zu betreiben, und die Möglichkeiten haben sich in den letzten Jahren stark erweitert, insbesondere durch Technologien wie Containerisierung und Container-Orchestrierung. Diese bieten zusätzliche Abstraktionsschichten, die mehr Flexibilität und Effizienz ermöglichen. Für Organisationen ist es jedoch entscheidend, den Ansatz zu wählen, der am besten zu ihrem bestehenden Know-how passt.

Ein wichtiger Aspekt bei der Implementierung einer Private Cloud ist die Nachhaltigkeit des Wissens im Unternehmen. Wenn beispielsweise eine einzelne Mitarbeiterin oder ein einzelner Mitarbeiter die gesamte Private Cloud-Infrastruktur aufbaut und dabei die Dokumentation vernachlässigt, kann dies zu erheblichen Problemen führen, wenn diese Person das Unternehmen verlässt. Daher muss der Fokus nicht nur auf einer sauberen Implementierung, sondern auch auf einer gründlichen Dokumentation liegen, insbesondere bei solch einer geschäftskritischen Komponente.

Private Clouds können in vielfältigen Architekturen und Größen realisiert werden, wie auch die in der Referenzarchitektur dargestellte einfache Struktur zeigt. Die Wahl der Technologien und die Größe der Cloud bestimmen dabei, welche Sicherheitsmaßnahmen ergriffen werden müssen. Diese Maßnahmen sollten stets maßgeschneidert und auf die spezifischen Anforderungen der jeweiligen Infrastruktur abgestimmt sein, um den Schutz und die Effizienz der Cloud bestmöglich zu gewährleisten.

Anbindung zu anderen Clouds/Datacentern

Die Integration einer Private Cloud mit anderen Rechenzentren oder Cloud-Umgebungen, wie einer Public Cloud oder einer Community Cloud, ist ein entscheidender Aspekt moderner IT-Infrastrukturen. Diese hybriden oder Multi-Cloud-Architekturen bieten Unternehmen die Flexibilität, Workloads effizient zu verteilen, Ressourcen zu skalieren und Sicherheitsanforderungen besser zu managen. Die Anbindung muss jedoch sorgfältig geplant und umgesetzt werden, um Performance, Sicherheit und Zuverlässigkeit zu gewährleisten.

Hier sind einige der gängigen Methoden und Best Practices für die Anbindung von Cloud-Umgebungen:

1. Anbindung über SD-WAN (Software-Defined Wide Area Network)

SD-WAN ist eine moderne Technologie, die die Vernetzung von verschiedenen Standorten, Rechenzentren und Clouds über softwaregesteuerte Netzwerklösungen optimiert. Es ermöglicht eine flexible, kosteneffiziente und sichere Verbindung zwischen verschiedenen Cloud-Umgebungen und dem Unternehmensnetzwerk.

Best Practices für SD-WAN:

• Zentrale Verwaltung und Kontrolle: SD-WAN ermöglicht die zentrale Verwaltung aller Netzwerkelemente und Traffic-Policies. Dadurch können Netzwerkverbindungen dynamisch und je nach Anwendungsanforderungen optimiert werden.
• Optimierung des Traffics: SD-WAN nutzt intelligente Algorithmen, um den Traffic über die besten verfügbaren Verbindungen zu leiten. Das führt zu einer verbesserten Performance und Zuverlässigkeit, insbesondere bei der Anbindung an Public Clouds wie AWS, Azure oder Google Cloud.
• Integrierte Sicherheitsfunktionen: SD-WAN bietet integrierte Sicherheitsmechanismen wie Verschlüsselung und Firewall-Funktionalitäten, die helfen, den Datenverkehr zwischen Cloud-Umgebungen zu schützen.
• Quality of Service (QoS): QoS-Funktionen innerhalb von SD-WAN ermöglichen die Priorisierung von kritischen Anwendungen und sorgen dafür, dass diese immer die benötigte Bandbreite und niedrige Latenzzeiten erhalten.

Ein praktisches Beispiel: Ein Unternehmen könnte seine Private Cloud, die in einem eigenen Rechenzentrum läuft, über SD-WAN mit einer Public Cloud verbinden, um rechenintensive Analysen in der Public Cloud durchzuführen, während sensible Daten in der Private Cloud verbleiben.

2. Anbindung über MPLS (Multiprotocol Label Switching)

MPLS ist eine traditionelle Netzwerktechnologie, die in vielen Unternehmensnetzwerken zur Anbindung von Rechenzentren und Standorten verwendet wird. Es bietet hohe Zuverlässigkeit, niedrige Latenzzeiten und die Möglichkeit, Verkehrsströme basierend auf vorgegebenen Prioritäten zu steuern.

Best Practices für MPLS:

• Service Level Agreements (SLAs): MPLS-Dienste werden oft mit strengen SLAs angeboten, die garantierte Latenzzeiten, Verfügbarkeit und Paketverlustraten umfassen. Dies macht MPLS ideal für geschäftskritische Anwendungen, die eine stabile und zuverlässige Verbindung benötigen.
• Traffic Engineering: MPLS ermöglicht die Priorisierung und Steuerung von Netzwerkverkehr, sodass geschäftskritische Anwendungen bevorzugt behandelt werden und ausreichend Bandbreite erhalten.
• Interoperabilität mit SD-WAN: Viele Unternehmen kombinieren MPLS mit SD-WAN, um die Flexibilität und Kosteneffizienz von SD-WAN mit der Zuverlässigkeit und Qualität von MPLS zu verbinden.

Ein Beispiel: Ein globales Unternehmen könnte MPLS nutzen, um seine Private Cloud in einem zentralen Rechenzentrum mit mehreren internationalen Standorten zu verbinden. Diese Standorte könnten über MPLS direkt miteinander kommunizieren, während die Verbindungen zu Public Clouds über SD-WAN optimiert werden.

3. Anbindung über VPN (Virtual Private Network)

VPN ist eine weit verbreitete Methode, um sichere Verbindungen über öffentliche Netzwerke herzustellen. VPNs werden häufig genutzt, um sichere Tunnels zwischen verschiedenen Cloud-Umgebungen, Rechenzentren oder Remote-Benutzern zu erstellen.

Best Practices für VPN:

• Verschlüsselung: Stellen Sie sicher, dass der gesamte VPN-Datenverkehr stark verschlüsselt ist, um die Vertraulichkeit und Integrität der übertragenen Daten zu gewährleisten.
• Redundante VPN-Tunnel: Um Ausfallsicherheit zu gewährleisten, sollten mehrere VPN-Tunnel zwischen den Standorten eingerichtet werden. Falls einer der Tunnel ausfällt, kann der Verkehr automatisch über die verbleibenden Tunnel umgeleitet werden.
• Automatische Failover: Nutzen Sie VPN-Lösungen, die ein automatisches Failover unterstützen, um sicherzustellen, dass bei einem Ausfall des primären Tunnels der Datenverkehr nahtlos über einen Backup-Tunnel umgeleitet wird.
• Integration mit Cloud-Diensten: Viele Public Cloud-Anbieter bieten native VPN-Dienste, die einfach in bestehende Netzwerke integriert werden können, um eine sichere Verbindung zwischen der Private Cloud und der Public Cloud zu gewährleisten.

Ein Beispiel: Ein mittelständisches Unternehmen könnte VPNs einsetzen, um die Verbindung zwischen seiner Private Cloud im Hauptrechenzentrum und einer Public Cloud, die für Disaster-Recovery-Zwecke verwendet wird, zu sichern. Im Falle eines Ausfalls im Hauptrechenzentrum könnte der VPN-Tunnel den Datenverkehr automatisch zur Public Cloud umleiten.

4. Anbindung über Direct Connect (Dedicated Cloud Connections)

Direct Connect ist eine Methode, bei der dedizierte, private Verbindungen zwischen einem Unternehmensrechenzentrum und einer Public Cloud eingerichtet werden. Diese Verbindungen bieten eine höhere Bandbreite, geringere Latenzzeiten und eine bessere Sicherheit als herkömmliche Internet-basierte Verbindungen.

Best Practices für Direct Connect:

• Dedizierte Bandbreite: Nutzen Sie dedizierte Leitungen mit garantierter Bandbreite, um sicherzustellen, dass die Verbindung zuverlässig und performant ist.
• Sicherheitsüberlegungen: Auch wenn Direct Connect eine physische Verbindung darstellt, sollten zusätzliche Sicherheitsmaßnahmen wie Verschlüsselung des Datenverkehrs implementiert werden, um das Risiko von Abhörversuchen zu minimieren.
• Redundanz und Failover: Richten Sie redundante Direct-Connect-Verbindungen ein, um Ausfallsicherheit zu gewährleisten. Wenn eine Verbindung ausfällt, kann der Datenverkehr über eine alternative Route geleitet werden.
• Kosten-Nutzen-Abwägung: Direct Connect ist in der Regel teurer als andere Anbindungsmethoden. Daher sollte diese Lösung für geschäftskritische Anwendungen reserviert werden, bei denen Performance und Sicherheit oberste Priorität haben.

Ein Beispiel: Ein großes Finanzinstitut könnte Direct Connect verwenden, um seine Private Cloud sicher mit einer Public Cloud zu verbinden, die für Hochfrequenzhandel und Datenanalysen genutzt wird. Die direkte Verbindung gewährleistet niedrige Latenzzeiten und eine hohe Datenübertragungsrate, die für solche Anwendungen erforderlich sind.

5. Community Cloud Anbindung

Eine Community Cloud wird von mehreren Organisationen genutzt, die ähnliche Anforderungen an Sicherheit, Datenschutz und Einhaltung gesetzlicher Vorgaben haben. Die Anbindung einer Community Cloud an eine Public Cloud oder ein anderes Rechenzentrum erfordert eine sorgfältige Planung, um die gemeinsamen Sicherheitsrichtlinien einzuhalten.

Best Practices für Community Cloud Anbindung:

• Gemeinsame Sicherheitsrichtlinien: Alle Mitglieder der Community Cloud sollten sich auf einheitliche Sicherheitsrichtlinien einigen, um sicherzustellen, dass die Anbindung an andere Clouds den gemeinsamen Anforderungen entspricht.
• Transparente Governance: Die Governance-Strukturen sollten klar definiert sein, einschließlich der Verantwortung für die Verwaltung der Verbindungen und der Einhaltung von Sicherheitsstandards.
• Zugriffssteuerung: Strenge Zugriffssteuerungen sollten implementiert werden, um sicherzustellen, dass nur autorisierte Nutzer und Dienste auf die angebundenen Clouds zugreifen können.
• Einsatz von SD-WAN oder VPN: Abhängig von den spezifischen Anforderungen der Community Cloud kann SD-WAN oder VPN als Verbindungstechnologie eingesetzt werden, um eine sichere und flexible Anbindung an Public Clouds zu ermöglichen.

Ein Beispiel: Eine Gruppe von Krankenhäusern könnte eine Community Cloud betreiben, um Patientendaten zu teilen und gemeinsam genutzte Anwendungen zu nutzen. Die Anbindung dieser Community Cloud an eine Public Cloud, die für Big Data Analysen und Machine Learning genutzt wird, könnte über VPN erfolgen, um den Datenschutz und die Einhaltung von Gesundheitsvorschriften sicherzustellen.

Public Cloud Security

Das Public Cloud Computing hat die IT-Landschaft grundlegend verändert, indem es Unternehmen weltweit skalierbare, flexible und kosteneffiziente Lösungen bietet. Doch mit diesen Vorteilen gehen auch erhebliche Sicherheitsherausforderungen einher. In diesem Kapitel werden wir die Beweggründe für die Einführung der Public Cloud, die erforderlichen Sicherheitsmaßnahmen für verschiedene Servicemodelle und die Strategien zur effektiven Bewältigung dieser Herausforderungen untersuchen.

Einführung in die Sicherheit in der Public Cloud

Die ersten öffentlichen Cloud-Dienste wurden 2006 von Amazon durch Amazon Web Services (AWS) gestartet. Mit der Einführung von Diensten wie dem Simple Storage Service (S3) und der Elastic Compute Cloud (EC2) markierte AWS einen signifikanten Wandel in der Art und Weise, wie Unternehmen ihre IT-Infrastruktur gestalten. Diese beiden Dienste sind heute noch die beliebtesten öffentlichen Cloud-Dienste weltweit. Trotz der Verfügbarkeit öffentlicher Cloud-Dienste seit 2006 dauerte es jedoch weitere 7 bis 8 Jahre, bis Unternehmen begannen, eine Cloud-Strategie zu übernehmen und den Wechsel von der lokalen Infrastruktur zu einer öffentlichen Cloud-Infrastruktur zu vollziehen.

Motive und Treiber hinter der Einführung der Public Cloud

Es gibt mehrere Gründe, warum Unternehmen zunehmend Cloud-Strategien übernehmen. Ein wesentlicher Faktor ist die fortschreitende digitale Transformation, bei der immer mehr Geschäftsmodelle auf digitalen Leistungen basieren oder einen digitalen Anteil in ihr Geschäftsmodell aufnehmen wollen. Ein weiterer grundlegender Treiber für das Cloud-Computing ist der Wechsel von Kapitalaufwendungen (CapEx), bei denen Organisationen große Geldmengen in die Infrastruktur investieren mussten, hin zu Betriebsausgaben (OpEx). Dies ermöglicht es ihnen nun, nach Nutzung zu zahlen und von Preisstrukturen zu profitieren, die mit monatlichen oder vierteljährlichen Leasingvereinbarungen vergleichbar sind. In einigen Szenarien ist es einfach vorteilhafter, nur ein geringes Budget aufzuwenden, als direkt große Investitionen zu tätigen.

Zusätzliche Treiber für eine öffentliche Cloud-Infrastruktur sind die folgenden:

• Skalierbarkeit: Benutzer haben Zugriff auf eine große Sammlung von Ressourcen, die entsprechend der Nachfrage skalieren. Dies bietet eine kostengünstige, skalierbare Infrastruktur für Unternehmen jeder Größe.
• Elastizität: Basierend auf dynamisch wechselnden Bedürfnissen verwaltet der Anbieter transparent die Ressourcennutzung eines Benutzers. Daher läuft die Rechenleistung nur mit dem notwendigen Minimum, um die gewünschten Operationen auszuführen.
• Kosteneffizienz: Das Pay-per-Usage-Modell ermöglicht es Unternehmen, einfach für die benötigten Ressourcen zu zahlen, ohne oder mit nur geringem Investitionsaufwand in die physikalischen Ressourcen, die in der Cloud verfügbar sind. Ein weiterer Kostenvorteil ist, dass die Lizenzierung von Hardware-Appliances oder Servern anders gehandhabt wird und die Verbraucher nicht für den Hardware-Support bezahlen müssen.
• Mobilität: Benutzer können von überall auf der Welt auf Daten und Anwendungen zugreifen. Die Rechen- und Speicherkomponenten einer Cloud können ebenfalls weltweit verteilt werden, und ein Content Delivery Network (CDN) kann einfach bereitgestellt werden.
• Kollaboration: Benutzer beginnen, die Cloud als Werkzeug zur Zusammenarbeit an gemeinsamen Daten und Informationen gleichzeitig zu sehen. Dies steigert die Produktivität und die Arbeitsergebnisse der Mitarbeiter und Cloud-Nutzer.
• Risikoreduzierung: Risikoreduzierung umfasst zwei Aspekte. Einerseits bieten Public Cloud-Anbieter häufig übergreifende Sicherheitsmaßnahmen an und implementieren Richtlinien, um Kunden von vornherein sichere Dienste bereitzustellen. Andererseits können Unternehmen Ideen und Konzepte in der Cloud testen, bevor sie größere Investitionen in Technologie tätigen, was das finanzielle Risiko reduziert.

Trotz dieser Vorteile ist der Umstieg auf eine Public Cloud-Infrastruktur nicht ohne Herausforderungen. Eine der größten Bedenken bei der Einführung der öffentlichen Cloud ist der physische Verlust der Kontrolle über die Computer-, Netzwerk- und Speicherkomponenten eines Unternehmens. Unternehmen, die die öffentliche Cloud übernehmen, sind stark auf den Cloud-Anbieter angewiesen und fürchten oft das Risiko eines Vendor-Lock-ins. Ein weiteres Anliegen ist der Umgang mit Daten in einer öffentlichen Cloud-Umgebung. Insbesondere die Speicherung von personenbezogenen Daten (PII) oder kritischen internen Geschäftsdaten kann für Unternehmen eine Herausforderung darstellen. Es gibt mehrere Datenschutzvorschriften und Compliance-Regeln, die alle berücksichtigt werden müssen, wenn solche Daten bei einer anderen Organisation gespeichert werden. Dies erfordert häufig die Einbindung von Datenschutz- oder IT-Rechtsspezialisten, um die Risiken zu identifizieren, sowie von erfahrenen Ingenieuren, um diese zu mindern und die Infrastruktur gemäß den Compliance-Vorgaben bereitzustellen.

Aufgrund der hohen Sicherheitspriorität der Cloud-Anbieter sind öffentliche Cloud-Umgebungen im Allgemeinen sehr sicher. Allerdings können selbst die sichersten Systeme kompromittiert werden, wenn sie nicht mit einem korrekten Cloud-Sicherheitsansatz entworfen werden.

Sicherheitsherausforderungen in der Public Cloud

Die Einführung von Public-Cloud-Diensten bringt eine Reihe von erheblichen Sicherheitsherausforderungen mit sich, die Unternehmen bewältigen müssen, um ihre Daten zu schützen und die Einhaltung relevanter Vorschriften zu gewährleisten:

Verlust der physischen Kontrolle

Einer der gravierendsten Veränderungen beim Umstieg auf eine Public-Cloud-Umgebung ist der Verlust der direkten physischen Kontrolle über die IT-Infrastruktur. In einer traditionellen On-Premises-Umgebung haben Unternehmen die volle Kontrolle über ihre Server, Speichersysteme und Netzwerkausrüstung. Diese Elemente werden vor Ort verwaltet, was es den IT-Teams ermöglicht, Sicherheitsprotokolle und physische Schutzmaßnahmen direkt umzusetzen. In einer Public-Cloud-Umgebung hingegen werden diese Elemente vom Cloud Service Provider (CSP) verwaltet. Diese Entkoppelung von der physischen Infrastruktur kann zu erheblichen Bedenken hinsichtlich der Sicherheit und Integrität der Daten führen, sowie zu Unsicherheiten über die Zuverlässigkeit der gesamten Cloud-Infrastruktur. Unternehmen müssen sich darauf verlassen, dass der CSP robuste Sicherheitsmaßnahmen implementiert, was häufig zu einem Gefühl des Kontrollverlustes führen kann.

Datenschutz und Compliance

Die Speicherung sensibler Daten, wie beispielsweise personenbezogener Daten (Personally Identifiable Information, PII), in der Cloud erfordert eine strikte Einhaltung von Datenschutzvorschriften, wie der Datenschutz-Grundverordnung (DSGVO) in Europa oder dem Health Insurance Portability and Accountability Act (HIPAA) in den USA. Diese Vorschriften stellen sicher, dass personenbezogene Daten ordnungsgemäß geschützt und verarbeitet werden. Organisationen müssen sicherstellen, dass ihre Cloud-Anbieter diese Vorschriften einhalten, was oft die Zusammenarbeit zwischen Rechtsexperten und IT-Sicherheitsspezialisten erfordert. Diese Experten müssen die Fähigkeiten des Anbieters sorgfältig bewerten und geeignete Schutzmaßnahmen implementieren, um sicherzustellen, dass die Daten in Übereinstimmung mit den geltenden Vorschriften verarbeitet werden. Die Nichteinhaltung dieser Vorschriften kann zu schwerwiegenden rechtlichen und finanziellen Konsequenzen führen, einschließlich hoher Geldstrafen und Reputationsschäden.

Vendor Lock-In

Eine starke Abhängigkeit von einem einzelnen Cloud-Anbieter kann zu einem sogenannten Vendor Lock-In führen, bei dem die Kosten, die Komplexität und der Aufwand für den Wechsel zu einem anderen Anbieter oder die Migration von Daten zurück in eine lokale Umgebung so hoch sind, dass dies praktisch unmöglich wird. Dieses Phänomen kann die Flexibilität und Innovationsfähigkeit eines Unternehmens erheblich beeinträchtigen, da es schwierig wird, auf sich ändernde Geschäftsanforderungen zu reagieren oder von besseren Preisen oder Funktionen anderer Anbieter zu profitieren. Unternehmen sollten daher sorgfältig abwägen, wie sie ihre Cloud-Strategie gestalten, um die Risiken eines Vendor Lock-In zu minimieren. Dazu können Multi-Cloud-Strategien oder hybride Ansätze gehören, die eine größere Unabhängigkeit von einem einzelnen Anbieter gewährleisten.

Shared-Responsibility-Modell

Ein grundlegender Aspekt der Sicherheit in Public-Cloud-Umgebungen ist das Shared-Responsibility-Modell, bei dem die Verantwortung für die Sicherheit zwischen dem Cloud-Service-Anbieter (CSP) und dem Kunden (Cloud Service Consumer, CSC) aufgeteilt wird. In diesem Modell sichert der CSP in der Regel die zugrunde liegende Infrastruktur ab, einschließlich physischer Server, Netzwerke und Hypervisoren. Der Kunde ist hingegen dafür verantwortlich, seine eigenen Daten, Anwendungen und den Benutzerzugang zu sichern. Dies umfasst die Implementierung von Verschlüsselung, Zugangskontrollen, Firewalls und anderen Sicherheitsmaßnahmen auf Anwendungsebene. Das Verständnis und die effektive Verwaltung dieser geteilten Verantwortung sind entscheidend, um eine sichere Cloud-Umgebung aufrechtzuerhalten. Unternehmen müssen sicherstellen, dass sie ihre Rolle im Shared-Responsibility-Modell genau verstehen und geeignete Sicherheitsvorkehrungen treffen, um potenzielle Schwachstellen zu minimieren.

Sicherheitsverantwortlichkeiten und Maßnahmen für verschiedene Servicemodelle

Die Sicherheitsverantwortlichkeiten in einer Public-Cloud-Umgebung variieren je nach dem gewählten Servicemodell—Infrastructure as a Service (IaaS), Platform as a Service (PaaS) oder Software as a Service (SaaS). Jedes Modell erfordert einen spezifischen Sicherheitsansatz, der auf die jeweilige Struktur und die Art der Anwendung zugeschnitten ist. In den folgenden Abschnitten werden die Sicherheitsmaßnahmen detailliert erläutert, die für jedes dieser Modelle erforderlich sind.

Sicherheit in SaaS-Umgebungen

Im SaaS-Modell liegt die Verantwortung für die Sicherheit der zugrunde liegenden Software und Infrastruktur hauptsächlich beim Cloud-Service-Provider (CSP). Der Cloud-Service-Consumer (CSC), also der Kunde, hat keine direkte Verantwortung für die Sicherheit der genutzten Software oder der gespeicherten Daten. Dennoch bleibt der Kunde für mehrere sicherheitsrelevante Aspekte verantwortlich, insbesondere bei der Nutzung der SaaS-Lösung.

Beispielsweise muss der CSC sicherstellen, dass die Kommunikation zur SaaS-Plattform verschlüsselt ist, um die Integrität und Vertraulichkeit der übertragenen Daten zu gewährleisten. Hierbei ist es wichtig, dass kryptografische Mechanismen wie TLS (Transport Layer Security) genutzt werden. Ein weiteres Sicherheitsrisiko stellt das Phishing dar. Phishing-Webseiten versuchen, echte SaaS-Plattformen nachzuahmen, um Benutzeranmeldedaten zu stehlen. Daher sollten Benutzer nur vertrauenswürdige DNS-Server verwenden und auf die korrekte Schreibweise von Domainnamen achten.

Zudem sollte ein starkes Authentifizierungsverfahren implementiert werden, um zu verhindern, dass Passwörter durch Methoden wie Wörterbuchangriffe geknackt werden. Passwortmanager können hier nützlich sein, um sicherzustellen, dass für verschiedene Anwendungen unterschiedliche, starke Passwörter verwendet werden. Ergänzend dazu ist die Nutzung von Multi-Faktor-Authentifizierung (MFA) ratsam, um eine zusätzliche Sicherheitsebene zu schaffen. Mit diesen Sicherheitsvorkehrungen können SaaS-Nutzer sicher sein, dass ihre Daten und Zugänge gut geschützt sind, vorausgesetzt, der SaaS-Anbieter schützt die zugrunde liegende Software und Infrastruktur effektiv.

Sicherheit in PaaS-Umgebungen

In einem PaaS-Modell hat der CSC nicht nur die oben genannten Sicherheitsverantwortlichkeiten aus dem SaaS-Modell, sondern trägt zusätzlich die Verantwortung für die Sicherheit der entwickelten und bereitgestellten Anwendungen sowie der zugrunde liegenden Daten.

Sicherung von Anwendungen: Um eine Anwendung zu sichern, stehen dem CSC verschiedene Optionen zur Verfügung. Für Webanwendungen kann beispielsweise eine Web Application Firewall (WAF) eingesetzt werden. Diese speziellen Firewalls analysieren den Datenverkehr nach der TLS-Terminierung, wodurch der Verkehr im Klartext inspiziert werden kann. Eine WAF bietet Schutz vor gängigen Webangriffen, wie sie in den OWASP Top 10 beschrieben sind, einschließlich SQL-Injection und Cross-Site Scripting (XSS). Eine WAF kann entweder direkt auf dem Webserver als Modul implementiert werden oder durch einen dedizierten WAF-Dienst, etwa von AWS, bereitgestellt werden.

Ein weiterer wichtiger Aspekt der Anwendungssicherheit ist die Integration von Sicherheitsmaßnahmen in den Software Development Life Cycle (SDLC). Hierzu gehört die Schulung von Entwicklern in sicheren Codierungsmethoden sowie die regelmäßige Durchführung von Sicherheitsbewertungen. Dazu zählen auch statische (SAST) und dynamische Anwendungssicherheitstests (DAST).

• Software Composition Analysis (SCA): Diese Methode scannt den Code eines Projekts nach verwendeten Bibliotheken und Abhängigkeiten und identifiziert bekannte Sicherheitslücken in diesen Bibliotheken.
• Static Application Security Testing (SAST): Im Gegensatz zur SCA analysiert SAST den Quellcode auf unsichere Codierungsmuster, die potenzielle Sicherheitslücken darstellen können, wie z. B. SQL-Injections.

Darüber hinaus kann der CSC durch Black-Box-Tests die Anwendung auf unbekannte Schwachstellen untersuchen. Hierzu gehört die dynamische Anwendungssicherheitstests (DAST), bei der automatisierte Angriffe durchgeführt werden, um Schwachstellen zu identifizieren, und manuelle Penetrationstests, bei denen ethische Hacker versuchen, Sicherheitslücken in der Anwendung zu finden.

Sicherung von Daten/Datenbanken: Der CSC ist dafür verantwortlich, dass die in der Cloud gespeicherten Daten ausreichend geschützt sind. Dies umfasst die Verschlüsselung der Daten im Ruhezustand (Encryption at Rest) sowie die Implementierung eines rollenbasierten Zugriffsmanagements (RBAC), um sicherzustellen, dass nur autorisierte Anwendungen auf die Daten zugreifen können. Darüber hinaus muss der CSC sicherstellen, dass alle gespeicherten Daten den relevanten Compliance-Vorschriften und Datenschutzgesetzen entsprechen. Beispielsweise könnte eine Vorschrift verlangen, dass personenbezogene Daten (PII) nur innerhalb der Europäischen Union gespeichert werden dürfen.

Sicherheit in IaaS-Umgebungen

Im IaaS-Modell hat der CSC die größte Kontrolle über die IT-Umgebung, was jedoch auch die größte Sicherheitsverantwortung mit sich bringt. Zusätzlich zu den Maßnahmen, die für SaaS und PaaS beschrieben wurden, ist der CSC in der IaaS-Umgebung auch für die Sicherung der Laufzeitumgebung, Middleware und des Betriebssystems verantwortlich.

Netzwerksicherheit: Hier sind Netzwerk-Sicherheitsgruppen (NSGs) von entscheidender Bedeutung. Diese bieten eine grundlegende Firewall-Funktionalität auf Layer 4 des OSI-Modells, die den Zugriff auf virtuelle Maschinen und andere Cloud-Ressourcen einschränkt. Zum Beispiel kann der Zugriff auf eine VM über das Internet auf die TCP-Ports 443 (HTTPS) und 80 (HTTP) beschränkt werden, während der Verwaltungszugriff (z. B. über SSH) nur von einer bestimmten IP-Adresse aus erlaubt wird.

Betriebssystemsicherheit: Die Betriebssysteme aller virtuellen Maschinen müssen regelmäßig aktualisiert und gepatcht werden, um sicherzustellen, dass stets die neuesten Sicherheitsfixes installiert sind. Cloud-Anbieter bieten in der Regel Dienste an, die das Monitoring von Betriebssystemen übernehmen und den CSC bei Sicherheitswarnungen und Aktualisierungen unterstützen.

Container-Sicherheit: Für Organisationen, die Container verwenden, ist es entscheidend, Container-Images auf Sicherheitslücken zu scannen und ein umfassendes Container-Registry-Management durchzuführen. Dies gewährleistet, dass alle verwendeten Container den aktuellen Sicherheitsanforderungen entsprechen.

Erweiterter Schutz durch virtuelle Firewalls: Wenn diese Maßnahmen nicht ausreichen, kann der CSC virtuelle Cloud-Firewalls einsetzen, die tiefe Paketinspektionen (Deep Packet Inspection, DPI) durchführen und Sicherheitsmechanismen bis zur siebten Schicht (Layer 7) des OSI-Modells implementieren.

Migrationsstrategien und Sicherheitsüberlegungen

Die Migration in die Public Cloud erfordert eine sorgfältige Planung, insbesondere in Bezug auf die Sicherheit. Eine gut durchdachte Migrationsstrategie ist entscheidend, um potenzielle Risiken zu minimieren und eine sichere IT-Infrastruktur zu gewährleisten.

Bewertung und Planung: Vor der Migration sollte eine gründliche Bewertung der bestehenden Sicherheitsmaßnahmen erfolgen, um Schwachstellen zu identifizieren, die in der Cloud-Umgebung behoben werden müssen. Diese Analyse bildet die Grundlage für eine sichere Migration und die Anpassung der Sicherheitsstrategie an die Cloud-Umgebung.

Schrittweise Migration: Es empfiehlt sich, die Migration schrittweise durchzuführen, beginnend mit weniger kritischen Anwendungen. Diese Methode minimiert das Risiko und bietet dem Unternehmen die Möglichkeit, Erfahrungen im Umgang mit Cloud-Sicherheit zu sammeln, bevor komplexere und kritischere Systeme migriert werden.

Auswahl des Anbieters: Die Wahl eines Cloud-Anbieters sollte unter Berücksichtigung seiner Sicherheitsfunktionen und der Einhaltung relevanter Industriestandards und Vorschriften erfolgen. Ein Anbieter, der robuste Sicherheitsfunktionen bietet, ist entscheidend für den Schutz der in der Cloud gespeicherten Daten und Anwendungen.

Fortlaufende Überwachung und Verwaltung: Nach der Migration ist eine kontinuierliche Überwachung der Cloud-Ressourcen erforderlich, um auf Sicherheitsbedrohungen zu reagieren und Sicherheitsmaßnahmen bei Bedarf anzupassen. Cloud-Umgebungen sind dynamisch, und es ist unerlässlich, auf neue Bedrohungen schnell zu reagieren, um die Sicherheit dauerhaft zu gewährleisten.

Fazit

Public-Cloud-Computing bietet erhebliche Vorteile in Bezug auf Skalierbarkeit, Kosteneffizienz und Flexibilität, was es zu einer attraktiven Option für Unternehmen jeder Größe macht. Diese Vorteile gehen jedoch mit erheblichen Sicherheitsherausforderungen einher, die durch eine Kombination aus sorgfältiger Planung, robusten Sicherheitsmaßnahmen und fortlaufendem Management angegangen werden müssen. Es ist von entscheidender Bedeutung, dass Organisationen die Sicherheitsverantwortlichkeiten, die mit den verschiedenen Servicemodellen verbunden sind, genau verstehen und geeignete Sicherheitskontrollen implementieren. Eine gut geplante Migrationsstrategie und ein darauf abgestimmtes Sicherheitskonzept sind unerlässlich, um die Vorteile des Public-Cloud-Computings voll auszuschöpfen und gleichzeitig die Risiken zu minimieren.

Virtualisierungs Sicherheit

In der modernen IT-Infrastruktur spielen Virtualisierungstechnologien eine zentrale Rolle. Sie ermöglichen es Unternehmen, Ressourcen effizienter zu nutzen, indem sie physische Hardware in virtuelle Einheiten aufteilen, die isoliert voneinander betrieben werden können. Diese Technologien bilden die Grundlage für eine Vielzahl von Anwendungen, angefangen bei der Konsolidierung von Servern in Rechenzentren bis hin zur flexiblen Bereitstellung von Diensten in Cloud-Umgebungen.

Sowohl in privaten als auch in öffentlichen Clouds sind Virtualisierungslösungen wie Hypervisoren, Container und Sandboxes unverzichtbar geworden. Sie ermöglichen nicht nur die schnelle Bereitstellung und Skalierung von Anwendungen, sondern auch die Isolierung von Prozessen und Daten. Diese Isolierung ist entscheidend, um die Sicherheit in geteilten Ressourcenumgebungen zu gewährleisten, da sie verhindert, dass Schwachstellen in einer virtuellen Umgebung auf andere übergreifen.

Allerdings bringt die Virtualisierung auch spezifische Sicherheitsherausforderungen mit sich. Während Virtualisierungstechnologien Flexibilität und Effizienz steigern, können sie bei unzureichendem Schutz auch Einfallstore für Angreifer bieten. Schwachstellen wie VM Escape, Container-Escape oder unsichere Konfigurationen können schwerwiegende Auswirkungen auf die gesamte IT-Infrastruktur haben.

Daher ist es unerlässlich, dass Sicherheitsstrategien von Anfang an in die Planung und den Betrieb von virtualisierten Umgebungen integriert werden. Dies umfasst nicht nur den Schutz der eingesetzten Virtualisierungstechnologien selbst, sondern auch die Implementierung zusätzlicher Sicherheitsmaßnahmen, um die Integrität und Vertraulichkeit von Daten und Anwendungen zu gewährleisten. In den folgenden Abschnitten werden die spezifischen Sicherheitsaspekte von Hypervisoren, Chroot, Sandboxes und Container-Technologien sowie deren Orchestrierung detailliert beleuchtet.

Hypervisor Security

Hypervisoren sind das Rückgrat moderner Virtualisierungstechnologien. Sie ermöglichen es, mehrere virtuelle Maschinen (VMs) auf einem einzigen physischen Host zu betreiben, indem sie die Ressourcen der physischen Hardware abstrahieren und den virtuellen Maschinen zuweisen. Es gibt zwei Haupttypen von Hypervisoren:

• Typ 1 Hypervisoren (Bare-Metal): Diese Hypervisoren laufen direkt auf der physischen Hardware und bieten dadurch eine höhere Performance und Sicherheit. Beispiele sind VMware ESXi, Microsoft Hyper-V und Xen.
• Typ 2 Hypervisoren (Hosted): Diese laufen auf einem bestehenden Betriebssystem und bieten eine einfachere Implementierung auf Workstations. Beispiele sind Oracle VirtualBox und VMware Workstation.

Sicherheitsherausforderungen bei Hypervisoren

Die Sicherheit von Hypervisoren ist von zentraler Bedeutung, da sie als Vermittler zwischen der physischen Hardware und den VMs fungieren. Ein kompromittierter Hypervisor kann dazu führen, dass alle darauf laufenden VMs gefährdet werden. Zu den wichtigsten Sicherheitsrisiken gehören:

• VM Escape: Dies ist eine der schwerwiegendsten Bedrohungen in virtualisierten Umgebungen. Dabei gelingt es einem Angreifer, aus einer VM auszubrechen und auf den Hypervisor oder andere VMs auf demselben Host zuzugreifen. Solche Angriffe können zu vollständiger Kontrolle über den Host und andere VMs führen.
• Denial-of-Service (DoS) Angriffe: Ein Angreifer könnte versuchen, eine VM oder den Hypervisor selbst zu überlasten, was zu einem Ausfall der Dienste führt. Besonders Typ-2-Hypervisoren, die auf einem bestehenden Betriebssystem laufen, können anfällig für DoS-Angriffe sein, wenn das darunterliegende Betriebssystem verwundbar ist.
• Unsichere Konfiguration: Eine fehlerhafte Konfiguration des Hypervisors kann Angreifern Zugang zu kritischen Systemen verschaffen. Dazu gehört beispielsweise das unzureichende Isolieren von VMs oder das Verwenden schwacher Authentifizierungsmechanismen.
• Shared Resources: Hypervisoren teilen Ressourcen wie CPU, Speicher und Netzwerk zwischen VMs. Ein schlecht gesichertes Ressourcenmanagement kann dazu führen, dass Angreifer seitliche Angriffe (Side-Channel-Angriffe) durchführen, um Informationen aus anderen VMs zu extrahieren.

Sicherheitsmaßnahmen für Hypervisoren

Um die Sicherheit von Hypervisoren zu gewährleisten, sind mehrere Maßnahmen erforderlich:

• Regelmäßige Updates und Patches: Wie jedes andere Software-System müssen Hypervisoren regelmäßig aktualisiert werden, um bekannte Schwachstellen zu schließen. Hersteller veröffentlichen oft Sicherheitspatches, die zeitnah eingespielt werden sollten, um Sicherheitslücken zu minimieren.
• Minimierung der Angriffsfläche: Unnötige Dienste und Funktionen sollten auf dem Hypervisor deaktiviert werden, um die Angriffsfläche zu verkleinern. Dies reduziert die Möglichkeiten für Angreifer, in das System einzudringen.
• Strikte Zugriffskontrollen: Der Zugriff auf den Hypervisor sollte stark eingeschränkt und durch starke Authentifizierungsmechanismen wie Multi-Faktor-Authentifizierung (MFA) geschützt werden. Nur autorisiertes Personal sollte Zugriff auf den Hypervisor und seine Verwaltungsoberfläche haben.
• Isolierung von VMs: VMs sollten so konfiguriert werden, dass sie voneinander isoliert sind. Dies beinhaltet die Nutzung von Netzwerksegmentierung, um den Datenverkehr zwischen VMs zu kontrollieren, sowie das Aktivieren von Sicherheitsfunktionen wie Virtual Trusted Platform Module (vTPM) für zusätzliche Sicherheitsschichten.
• Überwachung und Logging: Es ist wichtig, den Hypervisor und die darauf laufenden VMs kontinuierlich zu überwachen. Anomalien und verdächtige Aktivitäten sollten sofort erkannt und untersucht werden. Ein robustes Logging-System hilft dabei, sicherheitsrelevante Ereignisse zu dokumentieren und bei Bedarf zu analysieren.
• Virtuelle Firewalls und Intrusion Detection Systems (IDS): Der Einsatz von virtuellen Firewalls und IDS/IPS (Intrusion Prevention Systems) auf Hypervisor-Ebene kann dazu beitragen, den Datenverkehr zwischen VMs zu überwachen und potenzielle Angriffe frühzeitig zu erkennen und zu blockieren.

Durch die Umsetzung dieser Sicherheitsmaßnahmen können Organisationen das Risiko von Sicherheitsvorfällen in virtualisierten Umgebungen erheblich reduzieren und sicherstellen, dass ihre Hypervisoren und die darauf betriebenen virtuellen Maschinen bestmöglich geschützt sind.

Chroot im Linux Kernel

Das chroot-Kommando ist eine der ältesten und grundlegendsten Methoden zur Isolierung von Prozessen in Unix-ähnlichen Betriebssystemen wie Linux. Es steht für "change root" und ermöglicht es, ein Verzeichnis als neues Root-Verzeichnis (/) für einen bestimmten Prozess und seine Kindprozesse festzulegen. Dies erzeugt eine Art isoliertes Dateisystem, in dem der Prozess keinen Zugriff auf Dateien und Verzeichnisse außerhalb des neuen Root-Verzeichnisses hat.

Funktionsweise von Chroot

Die grundlegende Idee hinter chroot ist es, eine "Gefängnisumgebung" (auch als "Chroot-Jail" bezeichnet) für einen Prozess zu schaffen. Innerhalb dieser Umgebung kann der Prozess nur auf die Dateien und Verzeichnisse zugreifen, die innerhalb des neuen Root-Verzeichnisses verfügbar sind. Dies bietet eine grundlegende Form der Isolation, die jedoch nicht so umfassend ist wie moderne Container-Technologien.

Beispiel für die Verwendung von Chroot

Im folgenden Beispiel wird gezeigt, wie man mit chroot eine isolierte Umgebung erstellt und einen Prozess innerhalb dieser Umgebung ausführt:

1. Erstellen Sie das Verzeichnis, das als neues Root-Verzeichnis dienen soll:

 bash
 
 sudo mkdir /srv/chroot
 

2. Kopieren Sie die benötigten Dateien und Verzeichnisse in die Chroot-Umgebung. Dazu gehören z.B. ein minimales Dateisystem und die erforderlichen Binärdateien:

 bash
 
 sudo mkdir -p /srv/chroot/{bin,lib,lib64}
 
 sudo cp /bin/bash /srv/chroot/bin/
 
 sudo cp /lib/x86_64-linux-gnu/{libtinfo.so.6,libdl.so.2,libc.so.6} /srv/chroot/lib/
 
 sudo cp /lib64/ld-linux-x86-64.so.2 /srv/chroot/lib64/
 

3. Führen Sie den chroot-Befehl aus, um in die neue Umgebung zu wechseln und eine Shell darin zu starten:

 bash
 
 sudo chroot /srv/chroot /bin/bash
 
 # Innerhalb dieser Umgebung sieht es so aus, als ob /srv/chroot das Wurzelverzeichnis (/) ist. Dateien und Verzeichnisse außerhalb dieses Verzeichnisses sind nicht sichtbar.
 

4. Sie können nun innerhalb der Chroot-Umgebung Befehle ausführen. Zum Beispiel:

bash

ls /

# Dieser Befehl listet nur die Inhalte von /srv/chroot auf, da dies in der Chroot-Umgebung als Wurzelverzeichnis fungiert.

5. Um die Chroot-Umgebung zu verlassen, geben Sie einfach exit ein:

bash

exit

Sicherheitsaspekte von Chroot

Während chroot eine einfache Möglichkeit bietet, Prozesse zu isolieren, weist es einige Sicherheitslücken und Einschränkungen auf:

• Beschränkte Isolierung: chroot isoliert nur das Dateisystem. Prozesse können weiterhin auf andere Ressourcen des Betriebssystems zugreifen, wie z.B. den Netzwerk-Stack, die Prozessliste oder den Speicher. Dies macht es zu einer weniger umfassenden Sicherheitslösung im Vergleich zu moderneren Technologien wie Containern.
• Breakout-Risiko: Wenn ein Angreifer Root-Zugriff innerhalb der Chroot-Umgebung erhält, könnte er möglicherweise aus der Chroot-Jail ausbrechen, indem er die Root-Rechte missbraucht und den chroot-Befehl erneut verwendet.
• Ungeeignet für Root-Prozesse: Wenn ein Prozess, der als Root läuft, in einer Chroot-Umgebung ausgeführt wird, besteht ein erhebliches Risiko, dass dieser Prozess die Chroot-Isolation durchbrechen kann. Daher ist es ratsam, chroot nur für unprivilegierte Benutzerprozesse zu verwenden.

Sicherheitsmaßnahmen für den Einsatz von Chroot

Um die Sicherheit bei der Verwendung von chroot zu erhöhen, können folgende Maßnahmen ergriffen werden:

• Minimale Umgebung: Stellen Sie sicher, dass nur die absolut notwendigen Dateien und Binärdateien in die Chroot-Umgebung kopiert werden. Dies minimiert die Angriffsfläche.
• Keine Root-Prozesse: Vermeiden Sie es, Prozesse mit Root-Rechten in einer Chroot-Umgebung auszuführen. Verwenden Sie stattdessen unprivilegierte Benutzerkonten.
• Zusätzliche Sicherheitsmechanismen: Kombinieren Sie chroot mit anderen Sicherheitsmechanismen wie AppArmor, SELinux oder einer Sandbox, um die Sicherheit weiter zu erhöhen.

Obwohl chroot in Bezug auf moderne Sicherheitsanforderungen eingeschränkt ist, kann es in bestimmten Szenarien, insbesondere in Kombination mit anderen Sicherheitsmechanismen, immer noch nützlich sein. Es bietet eine einfache und effektive Möglichkeit, das Dateisystem für Prozesse zu isolieren und potenzielle Schäden durch kompromittierte Prozesse zu minimieren.

Sandboxes

Sandboxes sind ein wesentlicher Bestandteil moderner Sicherheitsarchitekturen und werden häufig eingesetzt, um Anwendungen oder Prozesse in einer stark isolierten Umgebung auszuführen. Diese Technik minimiert das Risiko, dass schädlicher Code oder kompromittierte Anwendungen Schaden am Gesamtsystem anrichten können. Sandboxing wird in verschiedenen Kontexten verwendet, darunter Webbrowser, mobile Apps, und Betriebssysteme.

Überblick über Sandboxing

Eine Sandbox ist eine kontrollierte Umgebung, die den Zugriff auf Systemressourcen wie das Dateisystem, den Speicher und das Netzwerk streng regelt. Anwendungen, die in einer Sandbox ausgeführt werden, haben nur begrenzte Rechte und können nur auf Ressourcen zugreifen, die explizit erlaubt sind. Dieses Prinzip der minimalen Rechte (Least Privilege) sorgt dafür, dass eine Anwendung nur die Berechtigungen hat, die sie unbedingt benötigt.

Anwendungsfälle von Sandboxes

Sandboxes finden in einer Vielzahl von Szenarien Anwendung:

• Webbrowser: Browser wie Google Chrome und Firefox verwenden Sandboxing, um Tabs und Plugins zu isolieren. Sollte ein bösartiges Skript in einem Tab ausgeführt werden, bleibt der Schaden auf diesen Tab beschränkt und kann nicht das gesamte System beeinträchtigen.
• Mobile Betriebssysteme: Auf Plattformen wie Android und iOS werden Apps in Sandboxes ausgeführt, wodurch sie keinen direkten Zugriff auf Systemressourcen oder die Daten anderer Apps haben. Dies schützt das System vor potenziell schädlichen Apps.
• Virtuelle Maschinen und Container: Containertechnologien wie Docker nutzen Sandboxing-Mechanismen, um sicherzustellen, dass Container isoliert bleiben und nicht auf Ressourcen anderer Container oder des Host-Systems zugreifen können.

Sicherheitsaspekte von Sandboxes

Sandboxing bietet erhebliche Sicherheitsvorteile, birgt jedoch auch Herausforderungen:

• Isolationsstärke: Die Sicherheit einer Sandbox hängt von der Stärke der Isolationsmechanismen ab. Eine Schwachstelle im Sandboxing-Mechanismus könnte es Angreifern ermöglichen, aus der Sandbox auszubrechen (Sandbox Escape) und Zugriff auf das Host-System zu erlangen.
• Minimaler Angriffsspielraum: Durch die Begrenzung der Rechte und Ressourcen, auf die eine Anwendung zugreifen kann, wird der potenzielle Schaden bei einem erfolgreichen Angriff minimiert.
• Performance-Overhead: Die Implementierung einer Sandbox kann zu einem gewissen Performance-Overhead führen, da zusätzliche Kontrollen und Einschränkungen implementiert werden müssen.

Beispiel: Sandboxing in Linux mit seccomp

In Linux kann die Sandbox-Technologie mit Hilfe von seccomp (secure computing mode) implementiert werden. seccomp ermöglicht es, die Systemaufrufe (Syscalls), die ein Prozess ausführen darf, zu beschränken. Dies erhöht die Sicherheit, indem es die Angriffsfläche reduziert, die ein Prozess auf das Betriebssystem hat.

Hier ein einfaches Beispiel für die Verwendung von seccomp in einer C-Programmdatei:

c
#define _GNU_SOURCE
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <seccomp.h>
#include <errno.h>

int main() {
    // Erstellt einen neuen seccomp-Filter
    scmp_filter_ctx ctx;
    ctx = seccomp_init(SCMP_ACT_KILL); // Standardmäßig alle Syscalls blockieren

    // Erlaubt den 'read', 'write' und 'exit' Syscall
    seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(read), 0);
    seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(write), 0);
    seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(exit), 0);

    // Aktiviert den seccomp-Filter
    seccomp_load(ctx);

    // Ein Beispiel für erlaubte Operationen
    write(STDOUT_FILENO, "Hello, Seccomp!\n", 16);

    // Versuch, eine nicht erlaubte Operation auszuführen (z.B. fork())
    // Wird zum Programmabsturz führen, da 'fork' blockiert ist
    fork();

    seccomp_release(ctx);
    return 0;
}

In diesem Beispiel erstellt der seccomp-Filter eine Sandbox, die nur die read, write, und exit Systemaufrufe erlaubt. Jeder Versuch, andere Systemaufrufe (z.B. fork()) auszuführen, führt zu einem sofortigen Programmabsturz. Dies ist eine effektive Methode, um den potenziellen Schaden durch eine kompromittierte Anwendung zu begrenzen.

Fazit

Sandboxes sind ein unverzichtbares Werkzeug in der modernen IT-Sicherheitslandschaft. Sie bieten eine robuste Isolierung, die dazu beiträgt, das Risiko durch schädliche Software und unsichere Anwendungen zu minimieren. Durch die Implementierung von Sandboxing-Technologien in verschiedenen Kontexten – von Webbrowsern bis hin zu Containern – können Systeme widerstandsfähiger gegenüber Angriffen gemacht werden. Die Kombination aus starkem Isolationsmechanismus und minimalem Angriffsspielraum macht Sandboxes zu einer entscheidenden Komponente für die Sicherheit in virtualisierten Umgebungen.

Container Security

Container-Technologien sind in der modernen IT-Infrastruktur allgegenwärtig und bilden die Grundlage für viele Anwendungen in der Cloud, insbesondere in Microservices-Architekturen. Sie bieten eine effiziente Möglichkeit, Anwendungen und ihre Abhängigkeiten in einer isolierten Umgebung bereitzustellen und auszuführen, die plattformunabhängig ist. Durch die Nutzung von Containern können Entwickler sicherstellen, dass ihre Anwendungen in jeder Umgebung konsistent funktionieren, sei es auf einem lokalen Rechner, einem Server oder in der Cloud.

Überblick über Container-Technologien

Container sind leichtgewichtige, portable und standardisierte Einheiten, die Anwendungen und alle notwendigen Abhängigkeiten enthalten, um sie auszuführen. Im Gegensatz zu virtuellen Maschinen (VMs), die ein vollständiges Betriebssystem enthalten, teilen Container den Betriebssystemkern mit dem Host, was sie wesentlich ressourceneffizienter macht. Die führenden Container-Technologien umfassen:

• Docker: Docker ist die am weitesten verbreitete Container-Plattform. Sie ermöglicht es Entwicklern, Anwendungen in Containern zu verpacken, zu verteilen und auszuführen. Docker nutzt Linux-Features wie Namespaces und Control Groups (cgroups), um Container zu isolieren und Ressourcen zu verwalten.
• Podman: Podman ist eine Docker-Alternative, die ebenfalls Container-Management bietet, aber ohne einen Daemon im Hintergrund auskommt. Es bietet ähnliche Funktionen wie Docker und ist kompatibel mit Docker-Images, was es zu einer flexiblen Wahl für verschiedene Einsatzszenarien macht.
• LXC/LXD: Linux Containers (LXC) und dessen Nachfolger LXD sind Container-Technologien, die näher an der Virtualisierung arbeiten. Sie bieten eine vollständige Systemcontainer-Lösung, die mehr wie eine leichtgewichtige VM funktioniert, aber immer noch die Effizienz von Containern nutzt.

Sicherheitsaspekte von Containern

Obwohl Container viele Vorteile bieten, insbesondere in Bezug auf Portabilität und Ressourceneffizienz, bringen sie auch spezifische Sicherheitsherausforderungen mit sich. Diese Herausforderungen und die zugehörigen Sicherheitsmaßnahmen umfassen:

• Isolierung und Namespaces: Container nutzen Namespaces, um verschiedene Aspekte des Betriebssystems (z.B. Prozesse, Netzwerk, Dateisystem) zu isolieren. Diese Isolation ist jedoch nicht perfekt, und Schwachstellen in der Implementierung von Namespaces können zu "Breakouts" führen, bei denen ein Angreifer aus einem Container ausbrechen und auf den Host zugreifen kann.
• Ressourcenmanagement mit cgroups: Control Groups (cgroups) werden verwendet, um die Ressourcen (CPU, Speicher, I/O) zu verwalten, die einem Container zugewiesen werden. Dies verhindert, dass ein Container alle Ressourcen des Hosts verbraucht. Unsachgemäße Konfigurationen können jedoch zu Denial-of-Service (DoS)-Angriffen führen, bei denen ein Container andere Container oder den Host durch Ressourcenüberlastung lahmlegt.
• Image-Sicherheit: Container-Images, die die Basis für Container sind, können Sicherheitslücken enthalten. Daher ist es entscheidend, nur vertrauenswürdige Images aus sicheren Quellen zu verwenden und regelmäßige Sicherheitsüberprüfungen (Scans) durchzuführen, um bekannte Schwachstellen zu identifizieren und zu beheben.
• Privilegierte Container: Einige Container benötigen erweiterte Rechte (z.B. Zugriff auf den Host-Dateisystem oder Netzwerkgeräte), was sie zu einem potenziellen Sicherheitsrisiko macht. Der Einsatz von privilegierten Containern sollte so weit wie möglich vermieden werden, und wenn sie notwendig sind, sollten zusätzliche Sicherheitskontrollen implementiert werden.

Beispiel: Sicherheitskonfiguration eines Docker Containers

Docker bietet eine Reihe von Optionen zur Erhöhung der Sicherheit von Containern. Hier ist ein Beispiel für die Erstellung eines sicheren Containers:

bash
# Erstellung eines Containers mit eingeschränkten Privilegien
docker run -d \
  --name sichere_app \
  --read-only \                 # Macht das Dateisystem des Containers schreibgeschützt
  --cap-drop ALL \              # Entfernt alle erweiterten Berechtigungen
  --security-opt no-new-privileges \ # Verhindert das Erlangen von neuen Berechtigungen
  my_secure_image:latest

In diesem Beispiel wird ein Docker-Container erstellt, der in einer stark eingeschränkten Umgebung ausgeführt wird:

• --read-only: Der Container hat nur Lesezugriff auf sein Dateisystem, was das Risiko minimiert, dass schädlicher Code Dateien modifizieren kann.
• --cap-drop ALL: Alle erweiterten Berechtigungen, die über das Standard-Set hinausgehen, werden entfernt. Dies verringert die Angriffsfläche.
• --security-opt no-new-privileges: Diese Option stellt sicher, dass der Container keine neuen Berechtigungen erhalten kann, selbst wenn ein Prozess mit erhöhten Rechten ausgeführt wird.

Erstellung eines separaten Benutzers im Container-Image

Ein weiteres wichtiges Sicherheitsprinzip bei der Arbeit mit Containern ist die Vermeidung der Ausführung von Anwendungen als root-Benutzer innerhalb des Containers. Standardmäßig werden Docker-Container als root gestartet, was ein erhebliches Sicherheitsrisiko darstellt. Wenn es einem Angreifer gelingt, aus dem Container auszubrechen, könnte er mit den root-Rechten auf dem Host agieren.

Um dieses Risiko zu minimieren, sollte in jedem Container-Image ein separater, nicht-privilegierter Benutzer erstellt und verwendet werden. Dies reduziert die potenzielle Angriffsfläche und folgt dem Prinzip der minimalen Rechte.

Beispiel: Erstellung eines Container-Images mit einem separaten Benutzer

Hier ist ein Beispiel für ein Dockerfile, das einen neuen Benutzer erstellt und sicherstellt, dass die Anwendung unter diesem Benutzer ausgeführt wird:

Dockerfile

# Basis-Image
FROM ubuntu:20.04

# Erstellen eines neuen Benutzers
RUN useradd -m -d /home/appuser -s /bin/bash appuser

# Setzen des Arbeitsverzeichnisses
WORKDIR /home/appuser/app

# Kopieren der Anwendung in das Arbeitsverzeichnis
COPY . .

# Setzen der Dateirechte auf den neuen Benutzer
RUN chown -R appuser:appuser /home/appuser/app

# Wechsel zum neuen Benutzer
USER appuser

# Starten der Anwendung
CMD ["./start-app.sh"]

In diesem Dockerfile werden mehrere wichtige Schritte unternommen, um die Sicherheit zu erhöhen:

1. Erstellen eines neuen Benutzers: Der Befehl useradd erstellt einen neuen Benutzer namens appuser, der für die Ausführung der Anwendung verwendet wird.
2. Setzen des Arbeitsverzeichnisses: Das Arbeitsverzeichnis wird auf /home/appuser/app gesetzt, das Verzeichnis, in dem die Anwendung installiert wird.
3. Zuweisung der Dateirechte: Mit chown wird sichergestellt, dass der neue Benutzer appuser der Eigentümer aller Dateien und Verzeichnisse ist, die in das Arbeitsverzeichnis kopiert werden.
4. Wechsel zum neuen Benutzer: Der Befehl USER appuser stellt sicher, dass alle nachfolgenden Befehle, einschließlich des Startens der Anwendung, unter dem neuen, nicht-privilegierten Benutzer ausgeführt werden.
5. Starten der Anwendung: Die Anwendung wird mit dem Befehl CMD ["./start-app.sh"] gestartet, wobei der nicht-privilegierte Benutzer appuser verwendet wird.

Durch diese Maßnahmen wird sichergestellt, dass die Anwendung nicht als root ausgeführt wird, was das Risiko eines Schadens im Falle eines Angriffs deutlich reduziert. Dieser Ansatz folgt dem Prinzip der minimalen Rechte und ist eine bewährte Praxis für die Sicherheit von Container-Images.

Sicherheits-Tools und Best Practices

Es gibt mehrere Tools und Best Practices, die zur Verbesserung der Containersicherheit beitragen:

• Image Scanning: Verwenden Sie Tools wie Clair, Trivy oder Anchore, um Container-Images auf bekannte Sicherheitslücken zu scannen, bevor sie in die Produktion überführt werden.
• Least Privilege: Container sollten immer mit den geringsten erforderlichen Rechten ausgeführt werden. Dies umfasst sowohl die Rechte innerhalb des Containers (durch das Entfernen von Berechtigungen) als auch die Zugriffsrechte auf den Host.
• Regelmäßige Updates: Container-Images sollten regelmäßig aktualisiert werden, um sicherzustellen, dass alle verwendeten Pakete auf dem neuesten Stand sind und keine bekannten Sicherheitslücken enthalten.
• Container-Registries: Verwenden Sie private Container-Registries mit strengen Zugriffskontrollen und Aktivitätsüberwachung, um die Verteilung kompromittierter Images zu verhindern.

Fazit

Container-Technologien bieten eine leistungsstarke und flexible Möglichkeit, Anwendungen in isolierten Umgebungen bereitzustellen. Dennoch erfordert die Verwendung von Containern ein hohes Maß an Sicherheitsbewusstsein. Durch die Implementierung von Sicherheitsmaßnahmen wie Image-Scanning, die Einschränkung von Berechtigungen und den Einsatz von Sicherheitswerkzeugen können Organisationen das Risiko minimieren und die Vorteile der Container-Technologie sicher nutzen.

Container-Orchestrierung

Container-Orchestrierung ist ein zentrales Element für den Betrieb und die Verwaltung containerisierter Anwendungen in modernen IT-Umgebungen. In Szenarien, in denen viele Container parallel betrieben werden, bietet die Orchestrierung die notwendige Automatisierung und Kontrolle, um den Betrieb effizient und sicher zu gestalten.

Grundlagen der Container-Orchestrierung

Container-Orchestrierung bezieht sich auf den Einsatz von Tools und Plattformen, die die Bereitstellung, Verwaltung, Skalierung und Vernetzung von Containern automatisieren. Die bekannteste und am weitesten verbreitete Plattform für Container-Orchestrierung ist Kubernetes. Kubernetes ermöglicht es, Container-Cluster zu verwalten und stellt sicher, dass die Anwendungen innerhalb dieser Container stabil und skalierbar sind.

Wichtige Funktionen der Container-Orchestrierung umfassen:

• Automatisierte Bereitstellung und Skalierung: Container-Orchestrierung ermöglicht die automatische Bereitstellung von Containern und deren Skalierung nach Bedarf, um Lastspitzen zu bewältigen oder Ressourcen zu sparen.
• Selbstheilung: Fällt ein Container aus, wird automatisch ein neuer Container gestartet, um die ausgefallene Instanz zu ersetzen, was eine hohe Verfügbarkeit der Dienste gewährleistet.
• Ressourcenverwaltung: Die Orchestrierung optimiert die Zuweisung von CPU, Speicher und Netzwerkressourcen, um die Leistung zu maximieren und Engpässe zu vermeiden.
• Service Discovery und Load Balancing: Dienste innerhalb des Clusters können automatisch gefunden und über Lastverteilung gleichmäßig erreichbar gemacht werden, ohne dass manuelle Konfigurationen erforderlich sind.

Überblick: Kubernetes als Container Orchestrierung

Kubernetes ist eine der führenden Open-Source-Plattformen zur Container-Orchestrierung, die speziell für die Verwaltung und Automatisierung von containerisierten Anwendungen entwickelt wurde. Es bietet eine leistungsfähige und flexible Umgebung, um den gesamten Lebenszyklus von Containern in großem Maßstab zu verwalten.

Wichtige Konzepte in Kubernetes

• Cluster: Ein Kubernetes-Cluster besteht aus mehreren Nodes, die entweder als Master oder Worker Nodes fungieren. Der Master Node ist für die Verwaltung des gesamten Clusters verantwortlich, während die Worker Nodes die eigentlichen Anwendungen in Containern hosten.
• Pods: Der Pod ist die kleinste Einheit in Kubernetes, die einen oder mehrere Container umfasst, die gemeinsam auf einer Node ausgeführt werden. Pods teilen sich dieselbe Netzwerk-IP und denselben Speicherraum.
• Services: Kubernetes-Services abstrahieren den Zugang zu einer Gruppe von Pods und ermöglichen eine zuverlässige Kommunikation zwischen verschiedenen Komponenten der Anwendung. Dies ist besonders nützlich für das Load Balancing und die Verwaltung von Zustandsänderungen.
• Deployments: Deployments sind Kubernetes-Ressourcen, die den gewünschten Zustand einer Anwendung definieren, z. B. die Anzahl der Replikate eines Pods. Kubernetes sorgt dafür, dass dieser Zustand aufrechterhalten wird, indem es automatisch Pods startet, stoppt oder neu startet, um den gewünschten Zustand zu erfüllen.
• Namespaces: Namespaces bieten eine Möglichkeit, verschiedene Umgebungen oder Teams innerhalb desselben Kubernetes-Clusters logisch zu trennen und zu isolieren.
• ConfigMaps und Secrets: Diese Ressourcen werden verwendet, um Konfigurationsdaten und sensible Informationen wie Passwörter oder API-Schlüssel sicher in Kubernetes zu verwalten.

Kubernetes in Public Cloud-Umgebungen

In Public Cloud-Umgebungen wird Kubernetes häufig als Managed Service angeboten, was bedeutet, dass der Cloud-Anbieter die Verwaltung der Kubernetes-Infrastruktur übernimmt. Beispiele hierfür sind:

• Amazon Elastic Kubernetes Service (EKS): AWS bietet EKS als vollständig verwalteten Service an, der die Verwaltung und Skalierung von Kubernetes-Clustern auf AWS vereinfacht.
• Google Kubernetes Engine (GKE): Google Cloud bietet GKE an, das die Integration von Kubernetes in die Google Cloud Platform erleichtert und Funktionen wie automatische Upgrades und Cluster-Skalierung bietet.
• Azure Kubernetes Service (AKS): Microsoft Azure bietet AKS als verwalteten Kubernetes-Service, der sich nahtlos in andere Azure-Dienste integrieren lässt.

Diese Managed Services nehmen dem Nutzer viele administrative Aufgaben ab, wie z. B. das Setup, die Verwaltung von Master Nodes und das regelmäßige Patchen und Aktualisieren der Software. Dadurch können Unternehmen ihre Anwendungen schnell und effizient in der Cloud bereitstellen und skalieren, ohne tief in die Verwaltung der Kubernetes-Infrastruktur eintauchen zu müssen.

Sicherheitsaspekte der Container-Orchestrierung

Auch bei der Container-Orchestrierung müssen besondere Sicherheitsvorkehrungen getroffen werden:

• Netzwerksegmentierung und Richtlinien: Innerhalb eines Kubernetes-Clusters sollten Netzwerk-Richtlinien implementiert werden, die den Datenverkehr zwischen Containern auf das Nötigste beschränken. Dies verringert das Risiko, dass ein kompromittierter Container das gesamte Netzwerk gefährdet.
• Zugriffssteuerung: Es ist wichtig, rollenbasierte Zugriffskontrollen (RBAC) zu verwenden, um sicherzustellen, dass nur autorisierte Benutzer und Dienste Änderungen an der Orchestrierung vornehmen können.
• Geheime Daten und Konfigurationsmanagement: Kubernetes bietet integrierte Mechanismen zum sicheren Speichern und Verwalten von sensiblen Daten, wie API-Schlüsseln und Passwörtern, die nur den notwendigen Containern zugänglich gemacht werden.
• Image-Sicherheit: Es ist wichtig, sicherzustellen, dass nur vertrauenswürdige und geprüfte Container-Images im Orchestrierungsprozess verwendet werden. Hierfür können Container-Registries und regelmäßige Sicherheitsprüfungen eingesetzt werden.

Durch die richtige Implementierung und Verwaltung der Container-Orchestrierung können Unternehmen die Vorteile der Container-Technologie voll ausschöpfen, während gleichzeitig ein hohes Maß an Sicherheit gewährleistet wird, insbesondere in komplexen und dynamischen Cloud-Umgebungen.

Sicherheitsaspekte bei Kubernetes

Kubernetes und andere Orchestrierungssysteme bieten umfangreiche Möglichkeiten, containerisierte Anwendungen effizient zu verwalten und zu skalieren. Dabei spielt die Sicherheit eine zentrale Rolle, da diese Systeme in komplexen und dynamischen Umgebungen arbeiten, in denen zahlreiche Komponenten interagieren. Es ist daher unerlässlich, Sicherheitsmaßnahmen sowohl bei der Bereitstellung als auch beim laufenden Betrieb der Orchestrierungsplattform zu implementieren [12].

Wichtige Sicherheitskonfigurationen

• Sichere Kommunikation: Alle Kommunikationskanäle zwischen den verschiedenen Komponenten eines Kubernetes-Clusters, wie z. B. zwischen Master- und Worker-Nodes oder zwischen Pods, sollten durch Verschlüsselung abgesichert werden. Dies kann durch den Einsatz von TLS-Zertifikaten erreicht werden.
• Role-Based Access Control (RBAC): Kubernetes bietet mit RBAC eine feingranulare Zugriffskontrolle, die sicherstellt, dass nur autorisierte Benutzer und Services auf bestimmte Ressourcen zugreifen können. Durch die Definition von Rollen und Bindungen können Zugriffsrechte präzise gesteuert werden.
• Pod Security Policies: Diese Policies erlauben es, Sicherheitsregeln für die Pods zu definieren, wie z. B. welche Benutzer und Gruppen Container in Pods ausführen dürfen, oder ob bestimmte privilegierte Aktionen zulässig sind.
• Netzwerksicherheit: Kubernetes-Netzwerke können durch Network Policies abgesichert werden, die den Datenverkehr zwischen Pods einschränken. Dies minimiert die Gefahr, dass ein kompromittierter Pod andere Pods im Cluster angreift.
• Image Security: Die Integrität der Container-Images ist von entscheidender Bedeutung. Es sollten nur vertrauenswürdige und signierte Images verwendet werden. Image-Scanning-Tools können eingesetzt werden, um bekannte Schwachstellen in den verwendeten Images zu identifizieren.
• Audit Logging: Kubernetes bietet eine Audit-Logging-Funktion, die alle API-Anfragen im Cluster protokolliert. Dies hilft bei der Überwachung und dem Aufspüren von Sicherheitsvorfällen.

Sicherheitsüberlegungen bei Managed Services

Bei der Verwendung von Managed Kubernetes-Diensten in Public Clouds, wie AWS EKS, Google GKE oder Azure AKS, übernimmt der Cloud-Anbieter viele der administrativen Sicherheitsaufgaben, wie das Patching der Master-Nodes und die Verwaltung der Steuerungsebene. Dennoch bleibt die Verantwortung für die Sicherheit der Anwendungskomponenten, wie Pods, Services und Netzwerke, beim Benutzer.

Die Cloud-Anbieter bieten oft zusätzliche Sicherheitsfunktionen, wie z. B. integrierte Identity and Access Management (IAM) Systeme, die nahtlos mit Kubernetes RBAC integriert werden können. Es ist wichtig, diese Funktionen zu nutzen, um die Sicherheit der gesamten Orchestrierungsplattform zu gewährleisten.

Best Practices

• Minimale Privilegien: Bei der Konfiguration von RBAC und anderen Zugriffskontrollen sollte stets das Prinzip der minimalen Privilegien angewendet werden, um die Angriffsfläche zu minimieren.
• Regelmäßige Sicherheits-Updates: Es ist wichtig, alle Kubernetes-Komponenten sowie die Container-Images regelmäßig zu aktualisieren und Sicherheits-Patches so schnell wie möglich einzuspielen.
• Sicherheitsüberwachung und -prüfung: Der Einsatz von Monitoring-Tools und regelmäßige Sicherheitsüberprüfungen, wie Penetrationstests und Compliance-Scans, helfen dabei, potenzielle Schwachstellen frühzeitig zu erkennen und zu beheben.

Durch die Beachtung dieser Sicherheitsaspekte kann sichergestellt werden, dass Kubernetes und andere Orchestrierungssysteme sicher betrieben werden, unabhängig davon, ob sie in einer Private Cloud, Public Cloud oder in einer hybriden Umgebung eingesetzt werden.

Sicherheitsempfehlungen für Cloud Systeme

Bei der Migration in die Cloud ist es entscheidend, dass Unternehmen eine umfassende Cloud-Strategie entwickeln, die Sicherheit als einen der zentralen Bestandteile betrachtet. Die richtige Strategie legt den Grundstein dafür, wie sicher und effizient die Infrastruktur in der Cloud aufgebaut und betrieben wird.

Cloud Migration Strategies

Gartner identifiziert fünf zentrale Cloud-Migrationsstrategien: Rehosting, Refactoring, Revising, Rebuilding und Replacing. Jede dieser Strategien bringt spezifische Anforderungen und Herausforderungen mit sich, die sich auf die Sicherheitsarchitektur auswirken. Daher sollte die Auswahl der Migrationsstrategie eng mit den Sicherheitszielen des Unternehmens abgestimmt werden [13].

1. Rehosting (Lift-and-Shift):
   • Beschreibung: Rehosting ist die einfachste Migrationsstrategie, bei der bestehende Anwendungen und Daten ohne größere Änderungen direkt in die Cloud verschoben werden. Dies wird oft durch Automatisierungstools unterstützt, die die Infrastruktur replizieren.
   • Vorteil: Schnell und kostengünstig, da keine großen Anpassungen erforderlich sind.
   • Nachteil: Nutzt nicht die vollen Vorteile der Cloud und kann bestehende Ineffizienzen übertragen.
2. Refactoring (Replatforming):
   • Beschreibung: Hierbei werden Anwendungen so angepasst, dass sie die Cloud-Umgebung besser nutzen können, ohne dass die grundlegende Architektur geändert wird. Ein Beispiel wäre das Wechseln des Datenbankmanagementsystems zu einer Cloud-optimierten Version.
   • Vorteil: Verbesserte Leistung und Skalierbarkeit in der Cloud.
   • Nachteil: Erfordert mehr Aufwand als Rehosting und kann zusätzliche Kosten verursachen.
3. Revising (Revise or Rearchitect):
   • Beschreibung: Bei dieser Strategie wird die Architektur der Anwendung signifikant geändert, um die Cloud-Technologien voll auszunutzen. Dies kann das Zerlegen einer monolithischen Anwendung in Microservices oder die Nutzung von serverlosen Architekturen umfassen.
   • Vorteil: Maximale Flexibilität und Nutzung von Cloud-Vorteilen wie Skalierbarkeit und Kostenoptimierung.
   • Nachteil: Hoher Aufwand und Komplexität, was zu längeren Projektlaufzeiten führen kann.
4. Rebuilding (Rebuild):
   • Beschreibung: Die Anwendung wird komplett neu entwickelt, wobei moderne Cloud-Technologien und -Praktiken von Grund auf genutzt werden. Dies bietet die Möglichkeit, technische Schulden loszuwerden und eine zukunftssichere Anwendung zu entwickeln.
   • Vorteil: Optimale Nutzung der Cloud und modernes, skalierbares Design.
   • Nachteil: Sehr zeitaufwendig und teuer, da die Anwendung von Grund auf neu erstellt werden muss.
5. Replacing (Replace or Repurchase):
   • Beschreibung: Anstelle der Migration einer bestehenden Anwendung wird eine neue Cloud-native Lösung oder ein Software-as-a-Service (SaaS)-Angebot genutzt. Dies ist oft die Wahl, wenn die bestehende Anwendung veraltet ist oder nicht mehr den Anforderungen entspricht.
   • Vorteil: Schnelle Bereitstellung und sofortige Nutzung von modernen Funktionen und Services.
   • Nachteil: Mögliche Anpassungsprobleme und Datenmigration können herausfordernd sein.

Jede dieser Strategien hat ihre eigenen Vor- und Nachteile, und die Wahl der richtigen Strategie hängt von den spezifischen Anforderungen und Zielen des Unternehmens ab.

IT-Infrastruktur bei Migrationen

Um eine sichere Cloud-Infrastruktur betreiben zu können, muss uns auch bewusst sein, aus welchen Komponenten unsere gesamte IT-Infrastruktur besteht. Vor allem bei größeren Unternehmen oder Unternehmen aus dem kritischen Sektor ist die Anzahl der eingesetzten IT-Komponenten in den letzten Jahren enorm gestiegen.

IT Infrastruktur Komponenten

Diese Abbildung zeigt die sechs Kernkomponenten, die bei der Analyse der IT-Infrastruktur im kritischen Sektor berücksichtigt werden müssen. Jede dieser Komponenten muss von den IT-Abteilungen ordnungsgemäß behandelt werden, um einen nahtlosen Betrieb des Unternehmens im kritischen Sektor zu gewährleisten [14], [15], [16], [17]:

1. Netzwerkinfrastruktur: Eine gut konzipierte Netzwerkinfrastruktur, einschließlich LANs, WANs und des Internets, ist entscheidend, um sicherzustellen, dass Mitarbeiter auf die notwendigen Ressourcen zugreifen können, um ihre Aufgaben effektiv zu erfüllen. Dabei spielen Skalierbarkeit, Zuverlässigkeit sowie die Aufrechterhaltung einer stabilen Konnektivität mit der Public Cloud eine wesentliche Rolle.
2. Datenmanagement und -speicherung: Unternehmen im kritischen Sektor generieren große Datenmengen, die sicher gespeichert und verwaltet werden müssen. Es ist wichtig, dass diese Systeme sowohl sicher als auch skalierbar sind, um wachsende Datenmengen zu bewältigen, insbesondere wenn Daten in die Public Cloud übertragen werden.
3. Cybersecurity: Um sich vor Cyberangriffen zu schützen, müssen Unternehmen robuste Sicherheitsmaßnahmen implementieren, die auf einer umfassenden Risikobewertung basieren. Bei der Nutzung von Public-Cloud-Infrastrukturen ist es entscheidend, Sicherheitsmechanismen der Cloud Service Provider (CSPs) sowie zusätzliche Sicherheitstools zu nutzen.
4. Kollaborations- und Kommunikationstools: Effektive Tools zur Zusammenarbeit und Kommunikation sind entscheidend für den Erfolg, insbesondere in einer Umgebung, in der Remote-Arbeit zunimmt. Diese Werkzeuge müssen gut in die IT-Infrastruktur integriert und vor Cyberbedrohungen geschützt werden.
5. Geschäftsanwendungen: Business-Anwendungen wie ERP-Systeme und BI-Tools sind für die Automatisierung und Optimierung von Geschäftsprozessen unerlässlich. Unternehmen im kritischen Sektor setzen oft maßgeschneiderte Software ein, um Effizienz zu steigern, Kosten zu senken und die Kundenerfahrung zu verbessern.
6. Business Continuity und Disaster Recovery: Unternehmen im kritischen Sektor müssen in der Lage sein, im Falle einer Katastrophe weiter zu arbeiten. Dazu sind robuste Pläne zur Geschäftskontinuität und Notfallwiederherstellung erforderlich, die regelmäßig getestet und aktualisiert werden.

Fazit: Die IT-Infrastruktur ist entscheidend für den Erfolg von Unternehmen im kritischen Sektor. Eine sorgfältige Gestaltung und Verwaltung der Netzwerke, die Implementierung robuster Datenspeicher- und Verwaltungssysteme, die Priorisierung der Cybersicherheit sowie umfassende Pläne zur Geschäftskontinuität und Notfallwiederherstellung sind essenziell, um eine effektive und nachhaltige IT-Betriebsumgebung zu gewährleisten.

Cloud Security Referenz Architektur für Unternehmen

Während es zahlreiche Methoden gibt, um die notwendige Infrastruktur in der Cloud bereitzustellen, fehlt es oft an spezifischen und umfassenden Referenzen für Sicherheitsarchitekturen. Aus diesem Grund wird in einem begleitenden Dokument eine Cloud Security Referenzarchitektur vorgestellt, die sich besonders auf den Schutz kritischer Infrastrukturen konzentriert. Dieser Blueprint bietet bewährte Konzepte und Vorgehensweisen, die Unternehmen als Grundlage verwenden können, um ihre eigene sichere Cloud-Umgebung aufzubauen oder ihre bestehende Infrastruktur zu migrieren.

Die Nutzung einer solchen Referenzarchitektur stellt sicher, dass wesentliche Sicherheitsaspekte bereits im Designprozess berücksichtigt werden, was zu einer robusteren und widerstandsfähigeren Cloud-Infrastruktur führt.

Wichtig hierbei ist auch, dass sich die Referenzarchitektur vor allem auf das Design der Infrastruktru bei großen Cloud Service Providern bezieht. Sie ist aber auch so gestaltet, dass hier sehr viel der Inhalte auf anderen Cloud Plattformen und auch in private Clouds verwendbar ist.

Quellen

[1] M. Warrilow, C. Graham, und E. Anderson, „Market Impact: Cloud Shift — 2022 Through 2025“, Gartner, G00758067, Jän. 2022. Zugegriffen: 12. April 2022. [Online]. Verfügbar unter: https://www.gartner.com/doc/4010122, https://www.gartner.com/en/newsroom/press-releases/2022-02-09-gartner-says-more-than-half-of-enterprise-it-spending

[2] J. Surbiryala und C. Rong, „Cloud Computing: History and Overview“, in 2019 IEEE Cloud Summit, Washington, DC, USA: IEEE, Aug. 2019, S. 1–7. doi: 10.1109/CloudSummit47114.2019.00007.

[3] P. M. Mell und T. Grance, „The NIST definition of cloud computing“, National Institute of Standards and Technology, Gaithersburg, MD, NIST SP 800-145, 2011. doi: 10.6028/NIST.SP.800-145.

[4] Cybersecurity & Infrastructure Security Agency, United States Digital Service, und Federal Risk and Authorization Management Program, „Cloud Security Technical Reference Architecture | CISA“, Cloud Security Technical Reference Architecture | CISA. Zugegriffen: 4. Dezember 2022. [Online]. Verfügbar unter: https://www.cisa.gov/cloud-security-technical-reference-architecture

[5] F. Liu u. a., „NIST cloud computing reference architecture“, National Institute of Standards and Technology, Gaithersburg, MD, NIST SP 500-292, 2011. doi: 10.6028/NIST.SP.500-292.

[6] Cloud Security Alliance, „Security Guidance for Critical Areas of Focus in Cloud Computing“, CSA. Zugegriffen: 4. Dezember 2022. [Online]. Verfügbar unter: https://cloudsecurityalliance.org/artifacts/security-guidance-v4/

[7] M. Hogan, F. Liu, A. Sokol, und T. Jin, „NIST-SP 500-291, NIST Cloud Computing Standards Roadmap“. Special Publication (NIST SP), National Institute of Standards and Technology, Gaithersburg, MD, 10. August 2011. [Online]. Verfügbar unter: https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=909024

[8] C. Canali, R. Lancellotti, und P. Pedroni, „Microservice Performance in Container- and Function-as-a-Service Architectures“, in 2022 International Conference on Software, Telecommunications and Computer Networks (SoftCOM), Split, Croatia: IEEE, Sep. 2022, S. 1–6. doi: 10.23919/SoftCOM55329.2022.9911406.

[9] J. R. Vacca, Hrsg., Cloud computing security: foundations and challenges - Second Edition, 2. Auflage. Boca Raton London New York: CRC Press, Taylor & Francis Group, 2021.

[10] Check Point Software Technologies, „CloudGuard NS for Public Cloud, Reference Architectures and Best Practices“. Zugegriffen: 9. Jänner 2023. [Online]. Verfügbar unter: https://resources.checkpoint.com/cyber-security-resources/cloudguard-ns-for-public-cloud-reference-architectures-and-best-practices

[11] Cybersecurity & Infrastructure Security Agency, „Zero Trust Maturity Model | CISA“. Zugegriffen: 9. Jänner 2023. [Online]. Verfügbar unter: https://www.cisa.gov/zero-trust-maturity-model

[12] B. Creane und A. Gupta, Kubernetes security and observability: a holistic approach to securing containers and cloud native applications, First edition. Sebastopol, CA: O’Reilly Media, Inc, 2021.

[13] Gartner und Richard Watson, „Migrating Applications to the Cloud: Rehost, Refactor, Revise, Rebuild, or Replace?“ Zugegriffen: 9. Jänner 2023. [Online]. Verfügbar unter: https://www.gartner.com/doc/1485116/migrating-applications-cloud-rehost-refactor

[14] L. Maglaras, H. Janicke, und M. A. Ferrag, „Cybersecurity of Critical Infrastructures: Challenges and Solutions“, Sensors, Bd. 22, Nr. 14, S. 5105, Juli 2022, doi: 10.3390/s22145105.

[15] P. Weill, M. Subramani, und M. Broadbent, „IT Infrastructure for Strategic Agility“, SSRN Electron. J., 2002, doi: 10.2139/ssrn.317307.

[16] J. vom Brocke, A. M. Braccini, C. Sonnenberg, und P. Spagnoletti, „Living IT infrastructures — An ontology-based approach to aligning IT infrastructure capacity and business needs“, Int. J. Account. Inf. Syst., Bd. 15, Nr. 3, S. 246–274, Sep. 2014, doi: 10.1016/j.accinf.2013.10.004.

[17] C. Große, „A review of the foundations of systems, infrastructure and governance“, Saf. Sci., Bd. 160, S. 106060, Apr. 2023, doi: 10.1016/j.ssci.2023.106060.