Cloud Security: Praxisorientierte Methoden und Lösungen für sicheres Cloud Computing

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.

Tabelle 1: 4-Stufen-Vorgehensmodell Cloud-Migration mit Sicherheitsmerkmalen

3 Wandel der IT-Organisation
3.1 Veränderte Verantwortlichkeiten

Die digitale Transformation und zunehmende Nutzung von innovativen Technologien erfordern von Unternehmen Veränderungen innerhalb ihrer IT-Organisation. Neue Anforderungen für einen agilen und kundenorientierten Ansatz erfordern eine Anpassung in der Zusammenarbeit zwischen der IT und den Fachbereichen. Zusätzliche Fähigkeiten, neue Rollen, neue Methoden, neue Arbeitsmodelle sowie eine andere Kultur in der Zusammenarbeit sind ebenfalls erforderlich. Zukünftig wird es die Ausprägungen der klassischen IT sowie einer agileren IT in Unternehmen geben.

Das klassische Vorgehensmodell erfüllt mit klar definierten Aufgaben und Prozessen die Vorgaben der Fachbereiche. Hierbei wird nach dem starren Wasserfallmodell gearbeitet, welches wenig Flexibilität zulässt. Hierbei stehen Anwendungsstabilität, Sicherheit und Kosteneffizienz im Vordergrund.

Ein agiles Vorgehensmodell erfüllt mit höherer Flexibilität und Innovationsgeschwindigkeit die Anforderungen einer Digitalstrategie des Unternehmens bzw. von Cloud-basierenden Geschäftsmodellen. Der Fokus liegt auf der gemeinsamen Entwicklung von digitalen Anwendungen durch inkrementelle Sprints. Das erste Ziel ist ein Minimal Viable Product (MVP), worin minimale Anforderungen und Eigenschaften enthalten sind. Über Trial- und Error-Ansätze werden schnelle Entwicklungsschritte umgesetzt. Bei diesem Vorgehensmodell werden teilweise strenge Regeln eingehalten.

Als einen ersten Evolutionsschritt für die IT-Organisation in Unternehmen beschreibt Gartner die bimodale Organisationsform. Hierbei koexistieren der Betrieb der stabilen und abgesicherten Kernsysteme (klassische IT) neben einer agilen und experimentellen Entwicklung von Anwendungen für die Kundenschnittstelle, wo eine engere Zusammenarbeit zwischen Fachbereichen und IT ein Standardzustand ist.

Beide Vorgehensmodelle setzen die Digitalstrategie des Unternehmens mit unterschiedlicher Geschwindigkeit um, aber zahlreiche Abhängigkeiten bleiben bestehen. Durch eine traditionelle Architekturplanung wird innerhalb der klassischen IT die Stabilität und Sicherheit der unternehmenskritischen Systeme gewährleistet. Gleichzeitig wird durch diese Organisationsform die agile Anwendungsentwicklung für die Kundenschnittstelle nicht blockiert bzw. gebremst.

Die Entwicklung am Markt der letzten Jahre hat den Bedarf der Flexibilität auch bei den Kernsystemen aufgezeigt. Es wird längerfristig erforderlich sein, dass beide Vorgehensmodelle für die Erreichung der Unternehmensziele koexistieren können. Hierbei steht die geeignete Balance zwischen Effizienz und Innovation bei der Umsetzung von digitalen IT-Projekten im Fokus, welche für jedes Projekt je nach den vorhandenen Rahmenbedingungen gefunden werden muss.

Die Grundlage für den Erfolg der integrierten flexiblen IT-Organisation ist die durchgängige Veränderung der Prozesse. Agile Methoden zur Softwareentwicklung sowie ein neues Betriebsmodell mit DevSecOps-Ansätzen zur Verschmelzung von Softwareentwicklung und IT-Betrieb unter Berücksichtigung der Sicherheitsaspekte sollten zum Einsatz kommen. Neue Technologien wie Cloud Computing bieten die notwendige Flexibilität und Skalierbarkeit.

3.2 Veränderte Governance durch Cloud-Nutzung

Die Governance in der IT-Organisation war bisher eine wichtige Führungsdisziplin. Ohne eine klare Richtlinie im Unternehmen sowie einer Kontrolle zur Einhaltung konnte es in der Vergangenheit innerhalb eines Rechenzentrums auch zu Sicherheitsvorfällen kommen. Dabei konnten auch gesetzliche und regulatorische Vorschriften, welche Unternehmen im Rahmen der IT-Governance einhalten müssen, verletzt werden.

Durch die Nutzung der Cloud sowie die Verwendung von agilen Methoden hat sich einiges verändert. Der IT-Betrieb erfolgt beispielsweise auf mehreren dezentral verteilten Public-Cloud-Plattformen, intern betriebenen Private-Cloud-Plattformen und/oder bei Hosting-Anbietern. Hybride Ansätze können hierbei zum Einsatz kommen. Bestehende Governance-Strukturen oder Service-Management-Prozesse sind aufgrund der neuen verteilten Strukturen nicht mehr ausreichend und der Einsatz eines passenden Cloud Governance Frameworks wird erforderlich.

Folgende Fragestellungen erhalten durch die Nutzung der Cloud eine größere Bedeutung:

• Welche Cloud Provider befinden sich für das Unternehmen bereits im Einsatz?

• Ist ein aktueller Gesamtüberblick zur IT des Unternehmens (inkl. aller Cloud Provider und Rechenzentren) vorhanden?

• Für welche Workloads darf welcher Cloud Provider verwendet werden?

• Aus welchem Land wird welche SaaS-Lösung bereitgestellt?

• Wie wird mit privilegierten Benutzerkonten umgegangen bzw. diese gegen unbefugten Zugriff abgesichert?

• Welche zentralen Architektur- und Namenskonventionen sind vorhanden?

• In welchen Regionen dürfen welche Daten gespeichert und/oder verarbeitet werden?

• Wird die Einhaltung der Sicherheitsrichtlinie des Unternehmens durch automatisierte Einrichtung erzwungen und zusätzlich auch automatisiert überprüft?

• Wie werden einmal allokierte Ressourcen überwacht und deren Freigabe sichergestellt?

• Wer ist für das Lifecycle-Management von Cloud-Ressourcen verantwortlich, das heißt, wer überwacht, ob Ressourcen, die nicht mehr benötigt werden, auch de-allokiert werden?

• Wer hat eine Übersicht der aktuellen und geplanten Kosten?

• Wie können Audits unterstützt werden?

• Was sind die Mindeststandards für Verträge mit Cloud Providern?

Ohne klare Antworten auf die Fragestellungen kann ein Unternehmen die Kontrolle über die Nutzung von Cloud-Diensten verlieren sowie dabei auch die Einhaltung von Sicherheitsrichtlinien des Unternehmens, gesetzliche und regulatorische Vorschriften nicht mehr gewährleisten.

Einige Regelwerke und Frameworks sind vorhanden, um die Umsetzung und Einhaltung von IT-Governance-Vorgaben zu unterstützen. COBIT gilt als eines der wichtigsten Frameworks für die Umsetzung der IT-Governance, welches von der Information Systems Audit and Control Association (ISACA) erstellt wurde. Im Jahr 2019 wurde das COBIT Framework aktualisiert und mit aktuellen Themen wie DevOps, Agilität und Cloud erweitert.

Eine Cloud-Computing-Richtlinie regelt grundsätzlich die Verwendung von Cloud-Diensten im Unternehmen. Hierbei werden die oben beschriebenen Fragestellungen und andere Themen beantwortet und Voraussetzungen für die Nutzung von Cloud-Diensten festgelegt. Alle vorhandenen Risiken und mögliche Konsequenzen werden beschrieben.

3.3 Übersicht zum Ansatz mit „Security by Design“

Vor der Herstellung eines neuen Produkts gehen dem Softwareentwickler viele Fragen durch den Kopf: Wie soll die Benutzerschnittstelle aussehen? Wie leistungsfähig soll die neue Software sein? Ein wichtiger Aspekt fällt dabei jedoch immer noch zu oft unter den Tisch: die Sicherheit.

Aktuell nimmt die Zahl von Cyberangriffen rapide zu, wie aus dem Lagebericht des Bundesamtes für Sicherheit in der Informationstechnik (BSI) hervorgeht. Demnach entdecken die Experten zum Beispiel täglich etwa 380.000 neue Varianten von Schadprogrammen. Große Konzerne verzeichnen schon heute mehrere Tausend Attacken pro Tag. 95 Prozent der erfolgreichen Angriffe basieren auf schlecht programmierter, schlecht gewarteter oder schlecht konfigurierter Software. Dieses Problem ließe sich aber lösen, indem Security zu Beginn des Projektes direkt berücksichtigt wird. Der Fachbegriff dafür lautet: Security by Design.

Werden Sicherheitseigenschaften als Designkriterium durch die Softwareentwicklung berücksichtigt, lassen sich Systemfehler von vornherein vermeiden. Ein Softwareingenieur arbeitet dann auch ganz anders, denn er arbeitet Spezifikationen ab. Ist Security nicht Teil der Anforderungen, werden diese durch den Entwickler nicht abgearbeitet. Im Idealfall ist das Thema Security bereits ein fester Bestandteil in der Ideenphase, und eine mögliche Umsetzung mit allen Vorgaben kann frühzeitig mit beispielsweise einem Prototyp überprüft werden. Durch weitere Einhaltung der Sicherheitsvorgaben in den weiteren Produktionsstufen erfüllt das fertige Produkt bestenfalls alle Erfolgskriterien.

Sieben Grundregeln zur Reduzierung der Risiken sollten durch Unternehmen berücksichtigt werden:

1. Angriffsfläche klein halten

Die Angriffsfläche lässt sich deutlich minimieren, indem Überflüssiges deaktiviert wird. Deaktivierte, nicht benötigte Softwareprogramme und Komponenten auf IT-Systemen können auch nicht angegriffen werden.

2. Geeignet authentifizieren und autorisieren

Vertrauliche Informationen und Informationssysteme sollten nur für die gewünschten Kommunikationspartner zugänglich und im erforderlichen Umfang nutzbar sein.

3. Eingaben überprüfen

Jede Eingabe sollte auf zulässige Zeichen, insbesondere Sonderzeichen, und auf die maximal zulässige Eingabelänge geprüft werden. Ein Beispiel: Bei der Bestellung auf einem Web-Portal sind im Feld für das Geburtsdatum des Nutzers nur Zahlen und möglicherweise noch Punkte erforderlich. Ziel hierbei ist die wirksame Verhinderung von Pufferüberläufen oder die Einspeisung von als Code interpretierbaren Zeichenketten.

4. Systeme trennen

Nach einem erfolgreichen Angriff auf ein System versuchen Angreifer häufig, von dort nach und nach Zugriff auf weitere Systeme zu erhalten. Systeme sollten daher voneinander getrennt werden und über eine abgesicherte Netzwerkverbindung miteinander kommunizieren.

5. Vertrauliches verschlüsseln

Der Zugang zu Systemen der Datenspeicherung, -verarbeitung und -übermittlung liegt meistens nicht vollständig in der Hand des eigenen Unternehmens, etwa wenn Cloud-Dienste genutzt werden. Umso wichtiger ist es, vertrauliche Informationen zu schützen.

6. Regelmäßig aktualisieren

Systeme sind schutzlos, wenn sie nicht stets auf einen aktualisierten Versionsstand gebracht werden. Nur so wird verhindert, dass Angreifer bekannte Sicherheitslücken nicht ausnutzen können. Neue Versionsstände enthalten zum Beispiel oftmals Abwehrmechanismen gegen bekannt gewordene Sicherheitslücken der Vorgängerversionen.

7. Sicherheit kontinuierlich testen

Der Zustand der Systeme muss im Hinblick auf ihre Sicherheit und Angreifbarkeit kontinuierlich durch Security-Checks wie der Überprüfung der Konfiguration und möglicher Sicherheitsschwachstellen kontrolliert werden.

3.4 Sicherheit in agilen Entwicklungsprozessen

Bisher war die Sicherheit bei der Softwareentwicklung die Aufgabe von Fachspezialisten innerhalb der Endphase der Entwicklung. Bei der Verwendung des Wasserfallmodells sowie längeren Projektlaufzeiten (Monate oder Jahre) war das auch kein größeres Problem. Mit Verwendung von modernen agilen Entwicklungsprozessen bzw. DevOps-Ansätzen könnten veraltete Methoden zur Einhaltung von Sicherheitsstandards sich eher nachteilig für Unternehmen auswirken. Bei schnelleren und häufigeren Entwicklungszyklen (Wochen oder Tage) wird die Agilität ausgebremst

Mit einem kollaborativen DevSecOps-Ansatz wird die Sicherheit von Anwendungen und der Infrastruktur von Anfang an in den Ablauf der Softwareentwicklung integriert und durch Automatisierung von wiederholenden Aufgaben (wie z. B. Funktionstests und Sicherheitsprüfungen) sowie den dazu passenden Tools unterstützt. Hierbei ist eine andere Kultur der frühen Zusammenarbeit zwischen Entwicklern und Sicherheitsspezialisten erforderlich.

4 Veränderte Bedrohungslage durch Cloud-Nutzung

Nach der Klärung wesentlicher Sachaspekte der Cloud muss die Frage gestellt werden, inwiefern die Cloud zu einer veränderten Bedrohungslage und damit zu einer notwendigen Veränderung der IT-Security-Kontrollelemente führt. Hierbei steht die Public Cloud im Vordergrund, da sie die prominenteste und am meisten genutzte Verbreitungsform darstellt. Durch die Nutzung von Public-Cloud-Lösungen gewinnen einige bisher eher unbedeutende Bedrohungsszenarien wesentlich an Bedeutung, andere verändern sich oder kommen neu hinzu. Beispielhaft ist hierbei die Co-Location von eigenen Unternehmensressourcen mit denen von beliebigen anderen Cloud-Nutzern (inkl. von Einzelpersonen) auf derselben Hardware (Computer, Storage etc.). Daraus resultierende Gefahren sind oft nicht im Bedrohungskatalog klassischer IT-Modelle enthalten.

4.1 Exponierte Lage

Die wohl wesentlichste Veränderung aus IT-Security-Sicht ist jedoch das „public“ in Public Cloud. Ressourcen, insbesondere die Control und Data Plane, sind öffentlich zugänglich. Um den Zugriff einzuschränken, muss vielfach erst eine entsprechende Absicherung erfolgen. Grundlegende Funktionen, wie z. B. das Cloud-Management-Portal bzw. die API, bleiben jedoch immer uneingeschränkt aus dem Internet erreichbar. Maßgeblich ist daher der Schutz der Zugriffsinformationen (z. B. Benutzername/Passwort, API Keys etc.). Hier muss das Schutzniveau deutlich erhöht werden, da Identitäten der Dreh- und Angelpunkt sind („Keys to the Kingdom“). In diesem Zusammenhang kann daher von den Identitäten als dem neuen Perimeter gesprochen werden. Der Verlust einer Identität, z. B. durch Phishing, wird bei öffentlich zugänglichen Ressourcen immer unmittelbare, negative Konsequenzen haben. Ein weiteres Problem ist die unbeabsichtigte Veröffentlichung von Cloud API Keys in öffentlichen Repositorien (z. B. GitHub). Zahlreiche Fälle der letzten Jahre haben dies immer wieder verdeutlicht.

Während in der klassischen IT im eigenen Rechenzentrum eine Fehlkonfiguration, wie z. B. ein unsicherer Dienst im internen Netz, nicht unmittelbar zu Problemen führt und der Fehler ggf. erst deutlich später auffällt, wird eine Fehlkonfiguration in der Cloud möglicherweise bereits wenige Minuten später ausgenützt. Dies war wiederholt die Ursache größerer Offenlegungen von Daten bei zahlreichen Firmen. Während es in der Vergangenheit als Best Practice angesehen wurde, z. B. mit einen Schwachstellenscanner regelmäßig (z. B. monatlich) das eigene, interne Netz zu durchsuchen, ist dies in der Cloud nicht mehr adäquat. Es benötigt vielmehr neue Wege, um auf Fehlkonfigurationen in der Cloud zu reagieren. Hier kommt eine entsprechende Automatisierung zum Tragen, die bei erkannten Fehlkonfigurationen sofortige Gegenmaßnahmen ergreift, da bis zu einem manuellen Eingreifen zu viel Zeit vergehen würde. In dieser Zeit könnten die fehlkonfigurierten Cloud-Dienste bereits angegriffen werden.

Ein weiteres Problem entsteht durch die Nutzung von Daten oder Software aus öffentlichen Quellen, wie z. B. dem Cloud Marketplace, GitHub oder aus Container-Repositories. Bei diesen, speziell bei Entwicklern, gerne genutzten Quellen stehen schnell notwendige Anwendungskomponenten zur Verfügung. Der Sicherheitsstatus solcher Ressourcen ist jedoch meist unklar. Neben der Möglichkeit von Hintertüren besteht die Gefahr, dass eine Weiterentwickelung und damit notwendige Sicherheitsupdates nicht stattfinden und damit eventuell vorhandene funktionale Fehler oder Sicherheitsschwachstellen nicht kurzfristig behoben werden können.

Um auf diese Bedrohungen angemessen reagieren zu können, sind Automatismen entscheidend. Gegenmaßnahmen sollten dabei unmittelbar beim Auftreten eines kritischen Ereignisses ausgelöst werden („event driven security“). Hierfür stehen zahlreiche Mechanismen in der Cloud zur Verfügung. Durch geeignete Kombination und der Nutzung von (serverless) Funktionen können damit beliebig komplexe Workflows ausgelöst werden. Dies auch als Cloud Security Posture Management (CSPM) bezeichnete Vorgehen kann sowohl durch Cloud-Native-Werkzeuge als auch durch Drittanbieterprodukte unterstützt werden. Wesentlich hierbei sind die kuratierten Prüfungen, bereits definierte Abwehrmaßnahmen und speziell bei Drittanbietern die Multi-Cloud-Funktionalität. Diese Werkzeuge bilden in der Regel gängige Security-Best-Practice-Empfehlungen, wie z. B. vom Center of Internet Security (CIS), ab. Neben der unmittelbaren Konfigurationsüberwachung sind auch die Themen Logging & Monitoring inkl. Security Operation Center, Datenverschlüsselung sowie das Identity Management wesentliche Schlüsselelement für einen sicheren Cloud-Betrieb. Speziell bei Letzterem sind Strategien für den bedingten Zugriff, die Mehrfaktorauthentifizierung sowie das Management privilegierter Zugriffe wichtige Schlüsselelemente. Analysewerkzeuge der Cloud Service Provider können dabei unterstützen, von den durch die Governance vorgegebenen Richtlinien oder bewährten Best Practices abweichende Konfigurationen oder Berechtigungen zu erkennen. Auch ein entsprechendes Netzdesign in der Cloud bietet zusätzlichen Schutz. Dies kann z.B. über ein Landing-Zone-Konzept erzwungen werden. Ziel der Netzwerkarchitektur sollte dabei sein, Ressourcen auch bei einer Fehlkonfiguration vor unmittelbaren Angriffen zu schützen. Werden diese Maßnahmen geeignet kombiniert, automatisiert und weiterentwickelt, kann dadurch eine kontinuierliche Sicherheit erreicht werden.