• Software as a Service (SaaS) Die höchste Fertigungstiefe bildet SaaS. Hier bezieht der Kunde eine komplette Anwendung beziehungsweise einen Anwendungsservice, z. B. ein CRM-System, eine Kollaboration-Plattform oder Ähnliches. Der Cloud-Anbieter ist hierbei für den gesamten Stack bis zur Anwendung verantwortlich. Für den Kunden bleibt aus Sicht der IT-Sicherheit hier nur noch die direkte Zugriffssteuerung auf Daten, die Überwachung der Zugriffe anhand von Logdaten sowie ggf. die Verschlüsselung der Daten. Der notwendige administrative (IT) Aufwand für die Nutzung einer Anwendung sinkt dadurch für die Kunden deutlich. Gleichzeitig steigt jedoch die Abhängigkeit vom Cloud-Anbieter (Vendor Lock-in) und das notwendige Vertrauen, das einem Dienstleister entgegengebracht werden muss. Ein großer Teil des IT-Betriebs wird aus Sicht der IT-Sicherheit zur Blackbox für den Kunden, und es bleibt, wie bereits oben aufgeführt, im Wesentlichen die Prüfung über Dritte (Zertifikate) als „Qualitätskontrolle“ der IT-Sicherheit.
In der Cloud muss neben den Arten der angebotenen Leistungen das jeweilige Bereitstellungsmodell unterschieden werden. Diese Modelle unterscheiden sich zum Teil deutlich hinsichtlich ihrer Bedrohungsszenarien.
Im Fall der Private Cloud erfolgt eine Bereitstellung klassisch im eigenen Rechenzentrum bzw. in dem eines Outsourcing-Anbieters. Der Kunde ist der alleinige Nutzer der Cloud-Ressourcen. Als Sonderform davon kann das Modell der Community Clouds gesehen werden. Hier teilt sich der Kunde die Ressourcen mit gleichartigen Kunden (z. B. Banken, Öffentliche Verwaltung oder spezifische Branchen). Diese besitzen in der Regel ein ähnliches Anwendungs- und Risikoprofil. Wesentliche Ressourcen, z. B. das Cloud-Management (API), sind nur aus privaten Netzen erreichbar.
Die Public Cloud unterscheidet sich hiervon grundlegend. Alle Management-Schnittstellen sind über das Internet erreichbar. Die Cloud-Ressourcen sind regulär ebenfalls im Internet erreichbar, und der Zugriff muss erst durch entsprechende Konfiguration eingeschränkt werden. Die Public Cloud kann zudem in der Regel von jedem genutzt werden, d. h., Ressourcen einer Privatperson können sich ggf. direkt auf demselben physischen System wie die Ressourcen eines Großkonzerns befinden. Eine entsprechende Abschottung, z. B. durch die Nutzung von exklusiv reservierten Ressourcen, muss zusätzlich bezahlt werden.
Im Modell Hybrid Cloud werden Private- und Public-Cloud-Ressourcen kombiniert. So kann z. B. auf Basis von Sicherheitsanforderungen definiert werden, wo eine Anwendung ausgeführt wird. Weiterhin ist es möglich, die Public Clouds in diesem Szenario als Zusatzkapazitäten zu nutzen (Burst).
2 Wege in die Cloud
2.1 Vorgehensmodelle für die Cloud-Migration
Bevor eine Anwendung in die Cloud migriert wird, sollte vorher eine genaue Analyse der in der Anwendung gespeicherten und verarbeiteten Daten durchgeführt werden. Regulatorische Vorgaben für das Unternehmen oder der Datentypen könnten einen Umzug in eine Public-Cloud-Plattform verbieten. Weitere Anforderungen zur Verfügbarkeit, Vertraulichkeit und Ort der Speicherung bzw. Verarbeitung von Daten sind ebenfalls zu berücksichtigen. Folgende Fragestellungen bestimmen die Auswahl des Vorgehensmodells:
• Liegt die Priorität bei einer möglichst schnellen Cloud-Migration?
• Hat eine tiefe Integration mit den Sicherheitsfunktionalitäten der zukünftigen Cloud-Plattform eine hohe Priorität?
• Müssen verbindliche „Security-by-Design“-Vorgaben des Unternehmens bei der Cloud-Migration eingehalten werden?
• Müssen die Daten der Anwendung aufgrund der Vertraulichkeit weiterhin im Rechenzentrum des Unternehmens gespeichert und/oder verarbeitet werden?
• Soll ein Phasenansatz mit einer Kombination von verschiedenen Vorgehensmodellen zum Einsatz kommen?
Ohne Beantwortung der Fragestellungen, weitere strukturierte Vorbereitungen sowie einer soliden Architektur- und Migrationsplanung können Projekte für den Umzug von Anwendungen in die Cloud scheitern. Eine gute Vorbereitung der Cloud-Migration von Anwendungen kann das Risiko von Sicherheitsvorfällen für Unternehmen minimieren.
Forrester Research unterscheidet grundsätzlich vier Vorgehensmodelle, die in der Praxis häufig kombiniert werden.
| Name der Methode | Beschreibung und Merkmale der Methode | Merkmale aus der Sicherheitsperspektive |
| Lift and shift | • Direkte Verschiebung von Anwendungen in die Cloud ohne Anpassungen • Automatisierter Transfer von virtuellen Infrastrukturen vom lokalen Hypervisor in eine Public-Cloud-Plattform mit Migrations-Tools • Eine schnelle Umsetzung der Migration von Anwendungen ist möglich. | • Benutzung von vorhandenen Anwendungen, Workloads und Tools • Beibehaltung der Sicherheitsaspekte der Anwendung, es erfolgt keine Anpassung an die vorhandenen Sicherheitssysteme der Cloud-Plattform. • Das volle Potenzial des Cloud Computing in Bezug auf Verfügbarkeit, Vertraulichkeit und Skalierbarkeit lässt sich nicht ausschöpfen. |
| Lift and extend | • Anpassung von Anwendungen für den PaaS-Layer des Cloud-Anbieters • Kontinuierliche Optimierungen und Veränderungen der Anwendungsarchitektur sind einfach umsetzbar. • Ermöglichung von Interoperabilität zwischen verschiedenen Cloud-Anbietern | • Nutzung von weiteren Cloud-Diensten außerhalb von Compute und Storage, z. B. Serverless Computing • Vorteile durch Anpassung der Anwendung an die spezifischen Möglichkeiten der Cloud-Plattform und Integration in vorhandene Sicherheitssysteme der Cloud-Plattform |
| Hybrid Extension | • Erweiterung von Anwendungen im sicheren Rechenzentrum (On-Premises oder Hosted Private Cloud) mit Cloud-spezifischen Funktionen • Aufbau von neuen Funktionalitäten in der Public Cloud • Beibehaltung von Teilen der Anwendung im sicheren Rechenzentrum | • Sensible Daten können im sicheren Rechenzentrum verbleiben. • Kombination aus den bestehenden Sicherheitsaspekte im Rechenzentrum sowie den vorhandenen Sicherheitssystemen der Cloud-Plattform. • Eine Identity-and-Access-Management (IAM)-Integration könnte erforderlich sein. • Latenzzeiten beim Datentransfer zwischen sicherem Rechenzentrum und Cloud-Plattform müssen berücksichtigt werden. |
| Full rebuild | • Zeit- und kostenintensive Cloud-native Neuentwicklung von Anwendungen • Komplette Nutzung aller Vorteile und Möglichkeiten von Funktionalitäten (Microservices, Container, Serverless Computing, Dev-SecOps, Continuous Integration/Continuous Deployment CI/CD) • Starke Abhängigkeiten mit dem Cloud Provider (Vendor Lock-In) | • Volle Nutzung der Sicherheitssysteme der Cloud-Plattform • Verbesserte Anpassbarkeit, Skalierbarkeit und Flexibilität auf neue Anforderungen • Hohe Verfügbarkeit von Anwendungen durch die globale Präsenz von Cloud Providern • Security-by-Design-Vorgaben können vollständig umgesetzt werden |