Keyfacts:

• Die zunehmende Nutzung von Public-Cloud-Services kann zu geteilten Verantwortlichkeiten innerhalb der eigenen Organisation führen.
• Zur Festlegung der Sicherheitsverpflichtungen kommt dabei häufig das Shared Responsibility Model (Prinzip der geteilten Verantwortung) zum Tragen.
• Es regelt – abhängig vom verwendeten Service und Leistungsschnitt – die Verantwortlichkeiten zwischen der eigenen Organisation (bzw. dem Cloud-Kunden) und dem Cloud-Anbieter.

Spricht man heutzutage über moderne und stabile IT-Betriebe im Finanzsektor, sind das zunehmend hybride Infrastrukturmodelle. Diese setzen sich aus einem On-Premise-Betrieb – im eigenen (oder aus einem Verbund bereitgestellten) Rechenzentrum – und Public-Cloud-Services zusammen.

Für einen sicheren Betrieb von Cloud-Infrastrukturen sollten die Verantwortlichkeiten zwischen der eigenen Organisation bzw. Cloud-Costumer (CC) und dem Anbieter bzw. Cloud-Service-Provider (CSP) sinnvoll verteilt werden.

Um Herausforderungen und Missverständnissen, die aus geteilten Verantwortlichkeiten resultieren könnten, vorzubeugen, kommt häufig ein Shared Responsibiltiy Model zum Einsatz. Darin variieren die Verantwortlichkeiten in Abhängigkeit davon, ob ein Cloud-Service-Modell, wie Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), Software-as-a-Service (SaaS), oder ein lokales Rechenzentrum genutzt wird.

Unsere Abbildung stellt in der Horizontalen den On-Premise-Betrieb und die drei Cloud-Service-Modelle IaaS, PaaS sowie SaaS dar. In der Vertikalen wird der Leistungsschnitt der Verantwortlichkeiten anhand der jeweiligen Themengebiete veranschaulicht. Die zweifarbig markierten Felder zeigen jene Parteien, die eine geteilte Verantwortlichkeit aufweisen.

Parallel dazu existieren Zuständigkeitsbereiche, die weiterhin bzw. ausschließlich durch eine der Parteien verantwortet werden. So ist die eigene Organisation (CC) jederzeit für die im Rechenzentrum oder der Cloud befindlichen Daten und Informationen (insbesondere hinsichtlich der Schutzziele Vertraulichkeit, Integrität und Verfügbarkeit) verantwortlich. Der Anbieter (CSP) hingegen verantwortet, unabhängig von der Wahl des Cloud-Service-Modells, das physische Rechenzentrum (u.a. physische Zutrittskontrolle, Schutz vor Ausfall und Redundanz).

Praxisbeispiele für geteilte Verantwortlichkeiten

Im Folgenden beschreiben wir für jedes der drei Cloud-Service-Modelle die geteilte Verantwortlichkeit anhand eines Beispiels.

IaaS: „Governance, Risk & Compliance”

Bei der Nutzung des IaaS-Cloud-Service-Modells (und damit einhergehend auch bei PaaS sowie SaaS) werden die Aufgaben Bereitstellung und Betrieb des physischen Rechenzentrums für die erworbenen Cloud-Services an den Anbieter (CSP) übertragen.

Damit gibt die eigene Organisation hinsichtlich des physischen Rechenzentrums auch die Verantwortlichkeit bezüglich Governance, Risk & Compliance (GRC) ab. Die Anbieter stellen Compliance-Auditberichte zur Verfügung. Konkret heißt das: Der Anbieter ist zwar für die Einhaltung der Regulatorik zuständig, die eigene Organisation (CC) muss dies aber kontrollieren und nachhalten.

Diese Handhabe ist per se keine Neuerung, da gleiches auch bei sämtlichen anderen, bereits vorhandenen Auslagerungen gilt. Konkrete Änderungen ergeben sich im Kontext Cloud jedoch daraus, dass bei den großen Anbietern die Individualität der eigenen Organisation möglicherweise eingeschränkt wird. So kann hinsichtlich des internen Kontrollsystems (IKS) der eigenen Organisation wenig Einfluss auf die Steuerung der GRC-Thematiken beim Anbieter genommen werden. Das führt unter Umständen dazu, dass die eigenen, internen IT-Betriebsprozesse (Change-Management, Incident-Management, etc.) sowie die Configuration Management Database (CMDB) unter Umständen angepasst und neu gedacht werden müssen.

PaaS: „Anwendungen“

Bei der Nutzung des PaaS-Cloud-Service-Modells (und damit einhergehend auch SaaS) kann die eigene Organisation plattformverwaltete Anwendungen und Dienste durch den Anbieter beziehen. Eine umfassende Sicherheitslösung wird vom Cloud-Anbieter administriert, dennoch bleibt die Verantwortung innerhalb der eigenen Organisation bestehen. Die Dienste müssen von ihr korrekt konfiguriert werden. Außerdem wird die Integration mit anderen Lösungen, wie zum Beispiel Identitätsmanagement vereinfacht. Im Gegensatz zur Infrastrukturbereitstellung (IaaS) entfällt die Sicherheitskonfiguration hinsichtlich unter anderem Patch-Management, Baseline-Konfiguration, Antimalware sowie der Schutz und die Sicherung der Betriebssystem- und der Anwendungsebenen vor Angriffen und Kompromittierungen.

Ein konkretes Beispiel sind Webdienstbereitstellungen. Standardmäßig sind Webdienste öffentlich einsehbar, dies erfordert daher die Konfiguration durch die eigene Organisation, um den Anforderungen der zu entwickelnden Lösung gerecht zu werden.

Bei einem Webdienst auf Basis einer Infrastrukturbereitstellung (IaaS), entsprechend dem vorherigen Beispiel, würde dies heißen, dass der Administrator sowohl die virtuelle Maschine als auch den Web-Service sichern müsste.

SaaS: „Identitäts- und Zugriffsverwaltung“

Bei der Nutzung des SaaS-Cloud-Service-Modells wird die geteilte Verantwortlichkeit anhand des Beispiels von Identitäts- und Zugriffsverwaltung / Identity- & Access-Management (IAM) veranschaulicht.

Die Benutzer- bzw. Identitätsverwaltung gibt der eigenen Organisation die Möglichkeit, anhand eines Berechtigungs-/Rollenkonzeptes festzulegen, welche Benutzer:innen auf bestimmte Ressourcen in der Umgebung zugreifen und diese nutzen dürfen.

Bei Bezug eines IAM-Tools über den Anbieter ist dieser für die Ausführung, die Verfügbarkeit, die Sicherheit und für die Aktualisierung der Sicherheits- und Kontrollmechanismen verantwortlich.

Die eigene Organisation agiert als Nutzer des Servicedienstes und ist für die Konfiguration des IAM-Tools verantwortlich. Dies umfasst vor allem die Einrichtung des Berechtigungs-/ Rollenkonzeptes, inklusive der Benutzeridentitäten, Just-in-Time-Verwaltungskontrollen, Überwachung und Protokollierung der Benutzer:innen und Kontrollpunkte, die Implementierung von Zugriffskontrollen für die genutzten Dienste und vorliegenden Daten sowie die Verwendung von Zwei-Faktor-Authentifizierung.

Bei der Nutzung einer IaaS-Lösung müsste die eigene Organisation (CC) auch die Identitäts- und Zugriffskontrollen auf den verwalteten Hosts und die virtuellen Maschinen konfigurieren und verwalten. Zudem müssten zusätzliche Sicherheits- und Compliance-Verantwortlichkeiten beim Betrieb von Infrastruktur-Layer-Services beachtet werden.

Fazit

Da sich die Verantwortlichkeiten je nach Cloud-Service-Modell unterscheiden, gibt es kein Standardmodell hinsichtlich der geteilten Verantwortung bei hybriden Infrastrukturen. Je nach den von der eigenen Organisation genutzten Cloud-Service-Modellen können die Verantwortungen abgegeben werden, jedoch bleibt die Kontrollfunktion stets bei der der eigenen Organisation bestehen. Um eine erfolgreiche Nutzung der Cloud zu gewährleisten und die Mehrwerte zu realisieren, sollten Finanzdienstleister ein zur Cloud-Strategie passendes Target-Operating-Modell etablieren, welches die beschriebenen Spezifika der Verantwortlichkeiten hinreichend berücksichtigt und in der Aufbau- und Ablauforganisation entsprechend verankert ist. Hier beschreiben wir, welche vier Bausteine für die Einführung eines Cloud Operating Models wichtig sind.