Cloud Security: Praxisorientierte Methoden und Lösungen für sicheres Cloud Computing. Группа авторов
Читать онлайн книгу.
von Servern für viele Unternehmen bezahlbar. Die Absicherung gegenüber Ausfällen von Rechenzentren erfolgte mit der Hardwarevirtualisierung.
Ein virtuelles Netzwerk teilte physische Netzwerke in logische Netzwerke auf, und ermöglichte somit eine Unterteilung in verschiedene Bereiche. Hierbei konnten flexible Anforderungen, die Performance sowie die Anforderungen zur Sicherheit berücksichtigt werden. Moderne Hypervisoren unterstützten gleichzeitig die Virtualisierung von Hardwareressourcen (z. B. CPUs, Speicher, Netzwerkschnittstellen etc.) sowie Netzwerken und ermöglichten somit eine Integration in vorhandene physische Netzwerkumgebungen.
Bei der Speichervirtualisierung wurden die physischen Eigenschaften der Speichersysteme gegenüber dem Benutzer abstrahiert. Physikalische Grenzen der Speichermedien mussten nicht mehr verwaltet werden und erschienen dem Benutzer demnach virtuell. Der Auslastungsgrad des physischen Speichers wurde dadurch verbessert. Außerdem konnten hierbei Redundanzen im Speichersystem (z. B. RAID, Reservekomponenten) vorgesehen werden, um die Ausfallsicherheit zu erhöhen, die hierdurch entstehenden Mehrkosten auf die Nutzer zu verteilen und dadurch zu minimieren.
Erste kritische Schwachstellen in den führenden Produkten zur Server-Virtualisierung wurden für unerlaubte Systemzugriffe ausgenutzt.
Eine hyperkonvergente Infrastruktur vereinte die verschiedenen Techniken zur Virtualisierung (Hypervisor, Speichervirtualisierung, Netzwerkvirtualisierung) in einer softwarezentrierten Architektur. Zusätzlich waren noch Werkzeuge zur Steuerung und Überwachung vorhanden. Andere Konzepte zur Anbindung an eine Cloud-Plattform sowie für die Schaffung von Redundanzen mit ggf. einem weiteren Rechenzentrumsstandort waren ebenfalls vorhanden. Die Vorteile lagen bei der Steigerung der betrieblichen Effizienz der IT, besseren Skalierbarkeit sowie schnelleren Bereitstellungszeiten. Die Betriebsverantwortung für eine hyperkonvergente Infrastruktur konnte bei einem internen IT-Team sowie auch bei einem externen Dienstleister liegen.
1.2 Cloud
Wie jeder Wandel in der IT liegt auch die zunehmende Nutzung von Cloud-Lösungen zumindest teilweise in betriebswirtschaftlichen Aspekten begründet. Beim Wechsel in die Cloud entsteht für den Benutzer unmittelbar ein Effekt in der Art der Kosten. Es fallen keine Investitionsausgaben (CAPEX – Capital Expenditures) für genutzte Hardware mehr an, es werden vielmehr nur noch die Nutzungs- und Betriebskosten (OPEX – Operational Expenditures) gezahlt. Dies kann einen Umstieg in die Cloud zum Beispiel bei zu erwartenden hohen Investitionskosten (Hardware-Refresh, RZ-Modernisierung) und schwierigem Marktumfeld weiter beschleunigen. Durch die Zusammenführung einer großen Zahl von gleichartigen Cloud-Ressourcen in gemeinsame Rechenzentren des Cloud Providers lassen sich Skalierungseffekte erzielen und die fixen Infrastrukturkosten (Gebäude, Klimatisierung, Perimeterschutz etc.) auf eine größere Zahl von Nutzern verteilen, wodurch die individuellen Kosten sinken. Eine deutliche Reduzierung der IT-Ausgaben ist allein durch die Umwandlung von CAPEX in OPEX in der Regel aber nicht zu erwarten.
Daneben gibt es jedoch weitere Motivatoren für die Nutzung von Cloud-Ressourcen. Hierzu zählt zum Beispiel eine verbesserte Flexibilität, die dadurch gewonnen werden kann. Langwierige Beschaffungs- und Abschreibungskosten von Hardware entfallen fast vollständig, und neue Ressourcen können statt durch lange dauernde Bestell- und Aufbauprozesse mit simplen „Mausklicks“ bereitgestellt werden. Durch die von Cloud Providern bereitgestellten Schnittstellen (API) ist zudem eine schnellere Entwicklung von Anwendungen und die automatisierte Bereitstellung ganzer Systemlandschaften (Stichwort: Infrastructure as Code – IaC) mit einer nahezu unbegrenzten Skalierung möglich.
Zur Erhöhung der Verfügbarkeit und zur Verbesserung der Ausfallsicherheit kritischer Anwendungen können Cloud-Ressourcen des Cloud Providers an unterschiedlichen Geolokationen genutzt werden. Auch für eine Bereitstellung der Services im globalen Rahmen stellt die zielmarktnahe Standortnutzung des Cloud Providers eine Option dar. So können Laufzeiten bei der Datenübertragung optimiert und damit für die Nutzer spürbare Performance-Einbußen vermieden werden. Die Cloud beschleunigt somit klassische IT-Abläufe und reduziert Abhängigkeiten von Inhouse IT-Abteilungen. Unter dem Gesichtspunkt der IT-Security ist „Shadow IT“, also IT-Systeme, die nicht in die Regelprozesse zum IT-Service Management einer Organisation eingebunden sind, jedoch kritisch zu sehen. Etablierte IT-Security-Prozesse und Kontrollen werden dabei häufig nicht berücksichtigt und umgesetzt.
Aus Sicht des Unternehmens bietet der Wechsel in die Cloud grundsätzlich auch Einsparungspotenzial z.B. bei den Personalkosten, da der klassische Infrastrukturbetrieb deutlich reduziert wird. Der Fokus der IT kann dadurch mehr auf die Anforderungen der Geschäftsprozesse und der Anwendungsebene konzentriert werden. Ähnliche Effekte sind jedoch auch im Rahmen des klassischen Outsourcings zu beobachten.
Auch für die Softwarehersteller von Cloud-Plattformen und insbesondere von Software as a Service (SaaS)-Diensten (wie z. B. Commerce- oder IT-Service-Management-Lösungen) bietet das Modell einen Vorteil. Durch die leichte Zugänglichkeit von Ressourcen wird dem Kunden deren Nutzung leicht gemacht, was auch direkt zu Mehreinnahmen beim Anbieter führt. Beim SaaS-Modell hat der Hersteller kontinuierliche Einnahmen, anders als beim Erwerb von Software durch den Kunden, da es nicht mehr möglich ist, die Software auch über das Ende der Supportzeit hinaus zu nutzen. Zudem entfallen aufwendige Vertriebs- und Lieferinfrastrukturen beim Software- oder SaaS-Diensteanbieter, da dieser gleichfalls die Cloud als Absatzweg nutzt.
Die Nutzung von Cloud-Lösungen bedeutet aber nicht, dass die IT-Security für den Kunden automatisch als gegeben betrachtet werden kann. Der Kunde ist auch in der Cloud abschließend für die Sicherheit seiner Daten verantwortlich.
Die Verantwortung des Cloud-Nutzers wird in der Regel im sogenannten „Shared Responsibility Model“ (Abbildung 1) abgebildet.
Abbildung 1: Verantwortungsschnitt IT-Security im Shared Responsibility Model
Maßgeblich hierbei ist die Art des vom Benutzer konsumierten Cloud-Dienstes und dessen Fertigungstiefe. Hierbei wird im Wesentlichen zwischen den folgenden Modellen unterschieden:
• Infrastructure as a Service (IaaS) Bei IaaS bezieht der Kunde im Wesentlichen virtuelle „Hardware“ bestehend aus Netzwerk, Storage- und Compute-Anteilen. Dies wird über ein Cloud-Portal bereitgestellt und kann zusätzlich über die angebotene API vollständig automatisiert provisioniert werden. Dies wird sehr häufig auch als Infrastructure as a Code bezeichnet. Es besteht hierbei jedoch kein wesentlicher Unterschied zu modernen Virtualisierungslösungen, die dies in ihren aktuellen Versionen meist ebenfalls enthalten. Aus dem Blickwinkel der IT-Sicherheit eröffnen sich jedoch einige neue Möglichkeiten. So kann eine Filterung im Netzwerk leichter und konsistenter umgesetzt werden. Eine Filterung kann dabei sowohl auf Netzwerkebene als auch direkt am virtuellen Netzwerkadapter eines Systems erfolgen. Weiterhin können Systeme leichter vereinheitlicht werden, und eine automatisierte Bereitstellung reduziert mögliche Fehler. Wie in Abbildung 1 ersichtlich, übernimmt der Cloud-Anbieter dabei die Verantwortung für die darunterliegenden Schichten. Die Attestierung eines entsprechenden Sicherheitslevels erfolgt durch typische IT-Security-Standards wie ISO270xx sowie ergänzende Standards, mit denen der Cloud-Anbieter seinen Kunden die Einhaltung der Prüfkriterien belegt.
• Platform as a Service (PaaS) Eine weitere Steigerung der Fertigungstiefe stellt PaaS dar. Hier stellt der Cloud-Anbieter fertig nutzbare Middleware-Komponenten bereit, z. B. gemanagte Datenbanken oder Kubernetes (K8s) Container-Cluster. Betriebssysteme und Middleware-Software werden vom Cloud-Anbieter selbst verwaltet und aktualisiert. Einen Zugriff auf dieser Ebene erhält der Kunde nicht. Es obliegt dem Kunden, primär die Zugriffe auf die Daten in der Middleware einzuschränken, sicherheitsrelevante Parameter anzupassen bzw. erweiterte Sicherheitsfunktionen zu aktivieren (z. B. Datenverschlüsselung). Auch diese Einstellungen können durch die API automatisiert werden. Speziell in diesem Szenario