Читать книгу: «Cloud Security: Praxisorientierte Methoden und Lösungen für sicheres Cloud Computing»
Cloud Security: Praxisorientierte Methoden und Lösungen für sicheres Cloud Computing
Herausgegeben von
Christiana Köhler-Schute
Mit Beiträgen von
Aarno Aukio, VSHN AG; Dominik Birgelen, oneclick AG; Michael Doujak, Ergon Informatik AG; Elmar Eperiesi-Beck, eperi GmbH; Tino Hirschmann, Deutsche Telekom Security GmbH; Christian Lechner, All for One Group SE; Prof. Dr. Heiko Meyer, KMS Vertrieb und Services AG; Valeri Milke, Insentis GmbH; Marcel Reviol, Deutsche Telekom Security GmbH; Andreas Schindler, All for One Group SE; Ralf Stadler, Tech Data Advanced Solutions DACH; Dr. Simon Woldeab, fuentis AG
KS-Energy-Verlag
ISBN 978-3-945622-19-3
ISBN 978-3-945622-17-9 (Print)
ISBN 978-3-945622-18-6 (eBook / PDF)
Bibliografische Informationen der Deutschen Nationalbibliothek
Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.
Jede Verwertung, die nicht ausdrücklich vom Urheberrechtsgesetz zugelassen ist, bedarf der vorherigen Zustimmung des Verlages.
KS-Energy-Verlag, Berlin 2021
Rüdesheimer Platz 8
14197 Berlin
Telefon: +49 30 827 021 42
www.ks-energy-verlag.de
Titelfoto: © kirania – stock.adobe.com
Vorwort
Als ich im Februar vor 10 Jahren mein erstes Buch zum Thema Cloud Computing herausgegeben habe, führte dieses Segment noch ein Nischendasein. Heute gilt Cloud Computing als Motor der Digitalisierung. Neue Geschäftsmodelle werden durch Cloud-Lösungen erst möglich, mobile Zugriffe auf IT-Ressourcen vereinfacht und eine schnellere Skalierbarkeit der IT-Leistungen erreicht. Cloud Computing wird von den meisten Unternehmen in Anspruch genommen und durch die Pandemie nochmal befeuert. Der Trend geht in Richtung Hybrid und Multi Cloud, um die Vorteile unterschiedlicher Provider und Lösungen für das Unternehmen optimal nutzen zu können.
Auch wenn laut einer repräsentativen Studie des Bitkom Public-Cloud-Lösungen weniger anfällig sind für Sicherheitsvorfälle als die eigene IT im Unternehmen1, häufen sich mit der zunehmenden Nutzung von Cloud Computing Cyberangriffe. Und auch andere Faktoren stellen ein Sicherheitsrisiko für das Cloud Computing dar – angefangen von technischen Störungen über Fehlkonfigurationen, Datenverlust, mangelnde Awareness der Mitarbeiter bis hin zu Compliance-Verletzungen.
Die Verantwortung für die Sicherheit schultern sowohl die Cloud-Nutzer als auch die Cloud-Anbieter. Als grobe Richtlinie gilt das Prinzip: Der Kunde trägt die Verantwortung für „Security in the Cloud“ und der Cloud-Anbieter für „Security of the Cloud“. Es ist im Sinne beider Parteien, gemeinsam die Sicherheit zu verbessern, um jedwede Folgeschäden abzuwenden.
Durch die Cloud-Nutzung verändert sich die Bedrohungslage, und traditionelle Sicherheitskonzepte und -lösungen wie klassische Anti-Malware-Technologien oder Firewalls lassen sich nicht kurzerhand auf das Cloud-Umfeld übertragen bzw. bieten nicht mehr ausreichenden Schutz. Cloud-Sicherheit erfordert neue Konzepte und hochentwickelte Technologien.
Das sind die Themen des Buches:
• Technologischer und organisatorischer Wandel durch Cloud Computing
• Veränderte Bedrohungslage durch Cloud-Nutzung
• Verantwortlichkeiten in der Cloud-Nutzung – das Shared-Responsibility-Modell
• Vorgehensweise zur Cloud-Migration unter sicherheitsrelevanten Aspekten
• Vorgehensmodelle und Umsetzungskonzepte für sichere Hybrid, Public und Multi Clouds
• Sicherheitskonzepte und -maßnahmen der Cloud-Anbieter
• Datenschutz und DSGVO-konforme Datenverschlüsselung
• Umsetzung von Zero-Trust-Architekturen
• Kritische Infrastrukturen: Grundlagen, Anforderungen und sicherheitsrelevante Umsetzungskonzepte
• Best Practices zur automatischen Identifizierung und Behebung von Sicherheitslücken in AWS und in Microsoft Azure
Branchen- und anwendungsbezogene Beispiele aus der Praxis runden das Buch ab.
Das Buch richtet sich an Cloud-Nutzer, die sich auf strategischer, organisatorischer und operationaler Ebene mit den Themen Cloud Computing und IT-Sicherheit auseinandersetzen, aber auch an IT-Dienstleister und Berater sowie Studierende und Dozenten, die Kenntnisse im Umfeld von Cloud Computing erwerben oder vermitteln wollen.
Zwölf hochkarätige Autoren konnten dazu gewonnen werden, sich mit Beiträgen am Gelingen des Buches zu beteiligen. Ihnen gilt mein Dank.
| Christiana Köhler-Schute | Berlin, im Mai 2021 |
Inhaltsverzeichnis
Cover
Titel
Impressum
Vorwort
Management Abstract
Herausforderung Cloud Security: Wandel in Technologie und Organisation
Tino Hirschmann und Marcel Reviol
1 Wandel der IT
1.1 Historie
1.2 Cloud
2 Wege in die Cloud
2.1 Vorgehensmodelle für die Cloud-Migration
3 Wandel der IT-Organisation
3.1 Veränderte Verantwortlichkeiten
3.2 Veränderte Governance durch Cloud-Nutzung
3.3 Übersicht zum Ansatz mit „Security by Design“
3.4 Sicherheit in agilen Entwicklungsprozessen
4 Veränderte Bedrohungslage durch Cloud-Nutzung
4.1 Exponierte Lage
4.2 Cloud-Technologie und Governance
4.3 Vertrauen in den Cloud Provider
Der integrierte Ansatz bei der Migration in die Cloud: Security by Default
Christian Lechner und Andreas Schindler
1 Einführung
2 Hacks and Attacks: Cloud versus On-Premises
3 Gefahren abwehren: Wir gehen in die Cloud!?
4 Trotz Maßnahmen und geteilter Verantwortung – können Unternehmen Cloud-Services trauen?
5 Umfassende Sicherheitsanalyse im Vorfeld klärt Handlungsbedarfe
6 Conditional Access – nur ein Aspekt für den Schutz von Daten
7 Migration in die Cloud am Beispiel eines Unternehmens aus dem Maschinenbau
8 Fazit
Sicher in die Cloud
Ralf Stadler
1 Neue Security-Herausforderungen durch die Cloud und wie sie sich erfolgreich meistern lassen
1.1 Sicherheitsverantwortung in der Cloud
1.2 Auflösung des klassischen Perimeters
1.3 Unabhängige Sicherheitsnachweise
1.4 Gefahr für die Cloud aus dem Internet der Dinge
1.5 Dienstleistungen für ein Cloud-gerechtes 360-Grad-Security-Konzept
2 Warum Digitalisierungsprojekte einen umfassenden Security-Ansatz erfordern
2.1 Flexible Arbeitsmodelle: Perimeter löst sich auf
2.2 Hohe Sicherheit durch Zwei- und Multi-Faktor-Authentifizierung
2.3 Noch komfortabler mit Token
2.4 Risikobasierte Authentifizierung
3 Offene Hybrid Multi Cloud
3.1 Chancen und Risiken in Multi Clouds
3.2 Multi-Cloud-Netzwerke absichern
3.3 Security eingebaut: die IBM-Cloud
3.4 Flexible Erweiterungen für die Cloud: IBM Cloud Paks
3.5 Noch mehr Sicherheit in hybriden Multi Clouds: IBM Cloud Paks for Security
4 Arbeiten in der Cloud
4.1 Mittelstand besonders im Fokus
4.2 Komplettschutz inklusive: Microsoft 365
4.3 Effektiver Cloud-Betrieb
Anwendungsbereitstellung über die oneclick™ Cloud-Plattform: Ein schlagkräftiges Mittel gegen Cyberkriminalität
Dominik Birgelen
1 Einführung
2 Ziele von Cyberkriminellen und stark ansteigende Bedrohungslage
3 Zero Trust: Traue niemandem außerhalb und innerhalb des Netzwerks
4 oneclick™ Plattform vereinfacht die Anwendungsbereitstellung und bietet ein Höchstmaß an IT-Sicherheit
5 So sicher, dass es bei der Anwendungsbereitstellung über oneclick™ eine integrierte Cyber Assurance ohne Fallprüfung gibt
Zero Trust ist eine Reise
Michael Doujak und Aarno Aukio
1 Sicherheitsrisiken in einer immer digitaleren Welt
1.1 Weiterentwicklung der Geräte
1.2 Weiterentwicklung der Anwendungen
1.3 Von der Perimetersicherheit zu Zero Trust
1.4 Containerisierung und SaaS
1.5 DevOps
1.6 Angriffe sind die neue Normalität
2 Digitalisierung der Informationssicherheit
2.1 Die Grundlagen von Zero Trust
2.2 Blaupause für eine Zero-Trust-Architektur
2.3 Sicherheitsvorteile von Zero Trust
2.4 Betriebliche Vorteile von Zero Trust
3 Grenzen von Zero Trust
3.1 Identitäts- und Zugriffsverwaltung als zentraler Service
3.2 Trennen Sie sich nicht vom zentralen Gateway
4 Zero Trust ist eine Reise
5 Schlussfolgerung
Datenschutzkonforme Cloud-Nutzung – Best Practices für alle Unternehmensgrößen
Elmar Eperiesi-Beck
1 Paradigmenwechsel: vom Systemschutz zum Datenschutz
2 Formale Betrachtung der aktuellen Gefahrenlage
3 Sicherheitsmaßnahmen der Cloud-Anbieter
4 Anwendungen in der Praxis
4.1 Sicherheit für Microsoft 365
4.2 IoT-Sicherheit
4.3 Privacy Preserving Analytics
4.4 Schnittstellenschutz
5 Fazit
Herausforderungen für Kritische Infrastrukturen (KRITIS)
Dr. Simon Woldeab
1 Welche Regularien sind zu berücksichtigen?
1.1 Einführung
1.2 IT-Sicherheitsgesetz
1.3 KRITIS-V
1.4 NIS-Richtlinie
2 Wer ist betroffen?
2.1 Kritische Infrastruktur-Sektoren
2.2 Schwellenwerte
3 Welche Anforderungen sind umzusetzen?
3.1 Einleitung
3.2 Anforderungskatalog für KRITIS (C5)
3.3 Branchenspezifische Anforderungen
4 Wie sieht ein Umsetzungskonzept aus?
4.1 Einleitung
4.2 Einsatz integriertes ISMS
4.3 Anwendungsfall: Einsatz ISMS für ein Klinikum
IT-Sicherheit im klinischen Umfeld
Prof. Dr. Heiko Meyer
1 Einleitung
2 Anforderungen an IT-Systeme in der Gesundheitswirtschaft
2.1 Begriffsdefinition Gesundheitswirtschaft
2.2 Aspekte zur IT-Sicherheit in der Gesundheitswirtschaft
2.3 Gesetzliche Vorgaben in der Gesundheitswirtschaft
3 Angriffsarten
3.1 Malware
3.2 Data Leaks
3.3 Passwörter
3.4 Vernetzte Medizintechnikprodukte
4 Softwareanwendungen in der Gesundheitswirtschaft
4.1 On-Premises-Lösungen
4.2 Cloud-Lösungen
4.3 Hybrid-Cloud-Lösungen
5 IT-Sicherheit in der Cloud
5.1 HIPAA-Compliance
5.2 Sichere Datenübertragung
5.3 Pseudonymisierung von Daten
5.4 Authentisierung
6 Zusammenfassung
6.1 Verbesserung der IT-Sicherheit durch Cloud-Lösungen
6.2 Mehrwert für die Patienten
6.3 Betriebswirtschaftliche Aspekte
7 Chancen für die Medizin
Best Practices zur automatischen Identifizierung und Behebung der häufigsten kritischen Sicherheitslücken in AWS
Valeri Milke
1 Vorwort und Aufbau der Best Practices
1.1 Sicherheitsbezogene AWS-Services
1.2 Relevanteste AWS-Services
1.3 Shared Responsibility Model
2 Best-Practice-Maßnahmen
2.1 Best Practises – architektonische Aspekte
2.2 Best Practises – sicherheitsbezogene AWS-Services
2.3 Best Practices für die am häufigsten eingesetzten AWS-Services
3 Tool-Set zur automatischen Identifizierung und Behebung
3.1 Open Source
3.2 Kommerziell
Best Practices zur automatischen Identifizierung und Behebung der häufigsten kritischen Sicherheitslücken in Microsoft Azure
Valeri Milke
1 Vorwort
1.1 Shared Responsibility Model
1.2 Sicherheitsbezogene Azure-Services
1.3 Relevante Azure-Services
2 Best-Practices-Maßnahmen
2.1 Best Practices – architektonische Aspekte
2.2 Best Practises – sicherheitsbezogene Azure-Services
2.3 Best Practices für die relevantesten Azure-Services
3 Tool-Set zur automatischen Identifizierung und Behebung
3.1 Open Source
4 Fazit
Unternehmensdarstellungen
Autorenporträts
Abbildungsverzeichnis:
Abbildung 1: Verantwortungsschnitt IT-Security im Shared Responsibility Model
Abbildung 2: Leitfäden zur Verbesserung der IT-Sicherheit
Abbildung 3: Bausteine eines IT-Security-Betriebskonzeptes
Abbildung 4: Funktionen für einen sicheren Zugriff
Abbildung 5: IBM Cloud Pak For Security Architecture
Abbildung 6: Die auf vier Säulen basierende Sicherheitstrategie von Microsoft
Abbildung 7: Zero-Trust-Komponenten im Cloud-Umfeld
Abbildung 8: Zero-Trust-Architektur
Abbildung 9: Das Shared-Responsibility-Modell nach Microsoft
Abbildung 10: KRITIS-Sektoren und Anlagenkategorien
Abbildung 11: Tool-gestützte Umsetzung Klinik-Infrastruktur, fuentis Suite
Abbildung 12: Tool-gestützte Umsetzung B3S-Katalog Gesundheitsversorgung, fuentis Suite
Abbildung 13: AWS Shared Responsibility Model
Abbildung 14: Shared Responsibility Model in the cloud
Abbildung 15: Architektur der Remotedesktop-Dienste
Tabellen:
Tabelle 1: 4-Stufen-Vorgehensmodell Cloud-Migration mit Sicherheitsmerkmalen
Tabelle 2: Bemessungskriterien und Schwellenwerte der Anlagenkategorien
Management Abstract
Tino Hirschmann und Marcel Reviol, Deutsche Telekom Security, nehmen in ihrem einleitenden Beitrag Herausforderung Cloud Security: Wandel in Technologie und Organisation den Leser auf eine kurze Zeitreise mit, um insbesondere jüngeren Lesern den Wandel der IT zu verdeutlichen. Sie geben einführend einen Überblick über Cloud-Services und -Modelle, erläutern das Shared-Responsibility-Modell und beschreiben vier grundsätzliche Vorgehensmodelle zu Anwendungsmigration in die Cloud. Sie stellen auf der Basis von Security by Design sieben Grundregeln auf, die dazu beitragen, die Angriffsfläche von Attacken zu minimieren. Zum Schluss diskutieren sie sicherheitsrelevante Maßnahmen als Reaktion auf eine veränderte Bedrohungslage durch die Cloud-Nutzung und lassen ihre Erfahrungen einfließen.
Die Frage, ob Unternehmen Cloud-Services trauen können, beantworten Christian Lechner und Andreas Schindler, All for One Group, mit einem klaren „Ja“. Sie stellen in ihrem Beitrag Der integrierte Ansatz bei der Migration in die Cloud: Security by Default ihre Vorgehensweise für die Cloud-Migration vor, die auf einer vollständig integrierten Sicherheitsarchitektur beruht. Zur Veranschaulichung ihrer Vorgehensweise berichten sie über ein Cloud-Projekt bei einem Maschinenbauer mit dem Ziel, digitale Produkte schnell entwickeln und bereitstellen zu können. Zum Schluss fassen sie ihre Erfahrungen aus Cloud-Projekten zusammen.
Ralf Stadler, Tech Data, erörtert in seinem Beitrag Sicher in die Cloud Maßnahmen und Lösungen zur Sicherung von Anwendungen in Public, Multi und Hybrid Clouds. Zunächst begründet er, warum die im eigenen Rechenzentrum genutzten lokalen Security Tools und Sicherheitskonzepte nicht auf das Cloud-Umfeld übertragen werden können, und welche Maßnahmen ergriffen werden sollten. Er beschreibt verschiedene Lösungen beginnend mit der Authentifizierungslösung RSA SecurID und YubiKey sowie mit der IBM-Lösung IBM Cloud Paks for Security, welche sicherheitsrelevante Informationen über alle Datenquellen, Systeme in einem Hybrid-Multi-Cloud-Umfeld automatisiert zusammenführen und auswerten. Er stellt die Microsoft 365 Business Premium-Lösung und weitere Tools vor, die insbesondere KMUs im Remote-Arbeitsumfeld Schutz bieten.
Dominik Birgelen, oneclick, stellt in seinem Beitrag Anwendungsbereitstellung über die oneclick™ Cloud-Plattform: Ein schlagkräftiges Mittel gegen Cyberkriminalität die Cloud-Plattform seines Unternehmens vor, welche als Vermittlungs- bzw. Trennschicht zwischen Benutzer und Unternehmensressource fungiert. Streaming-Server dienen als eine Art Sicherheitsschleuse mit Verschlüsselungen und weiteren Sicherheitsmechanismen zwischen Benutzer und Unternehmensressourcen, unabhängig davon, von wem diese bezogen werden. Inkludiert ist eine Cyberversicherung mit vorgeprüften Sicherheitsmaßnahmen ohne vorherige Fallprüfungen beim Anwenderunternehmen.
„Vertrauen ist gut, Kontrolle ist besser“: Das ist das Motto von Zero Trust. Es sieht vor, dass jede einzelne Anfrage und Zugriffe auf Ressourcen als nicht vertrauenswürdig gelten, bis das Gegenteil bewiesen ist. Mit Auflösung des Perimetersschutzes – als klassischer Ansatz für die Netzwerksicherheit – gilt Zero Trust u.a. im Cloud-Umfeld als ein probates Modell, welches auf großes Interesse stößt. Michael Doujak, Ergon Informatik, und Aarno Aukio, VSHN, erläutern in ihrem Beitrag Zero Trust ist eine Reise ein Migrations-Konzept für die Umsetzung einer Zero-Trust-Architektur in Unternehmen. Sie erörtern die technischen und betrieblichen Vorteile einer Zero-Trust-Architektur, zeigen aber auch die Grenzen von Zero Trust auf. Zur stufenweisen Umsetzung dieser Architektur beschreiben sie ein Modell, welches aus einem API-Gateway aus dem Perimeterschutz – als Aufgabenverteiler zwischen Perimeter und neu eingeführten Microgateways –, Microgateways für den Zero-Trust-Ansatz und einer IAM-Lösung besteht.
Elmar Eperiesi-Beck, eperi, hat den Schwerpunkt seines Beitrages Datenschutzkonforme Cloud Nutzung – Best Practices für alle Unternehmensgrößen auf eine datenzentrische Sicht gelegt. „Nicht länger geht es nur um die Sicherheit der Anwendungen. Entscheidend ist der Schutz der darin befindlichen sensiblen Daten“, so der Autor.
Zunächst befasst er sich mit Schutzzielen im Kontext mit Cloud-Computing, die die Sicherheit der IT messbar und die aktuelle Gefahrenlage bewertbar machen. Der Autor erläutert die Sicherheitsmaßnahmen der Cloud-Anbieter, die häufig bereits im Angebot integriert sind oder zugebucht werden können. Zur Beurteilung, ob diese Maßnahmen ausreichend sind, führt er Kriterien an, die es bei der Bewertung zu berücksichtigen gilt. Um den Anforderungen an die Datensicherheit und den Datenschutz gerecht zu werden, plädiert er dafür, die Datenverschlüsselung selbst in die Hand zu nehmen. Er erläutert die verschiedenen Arten der Verschlüsselung und führt zum Schluss mehrere Praxisbeispiele an, die durch den Einsatz von Verschlüsselungslösungen datenschutzgerecht umgesetzt werden konnten.
Kritische Infrastrukturen werden als besonders schützenswürdig eingestuft. Durch die zunehmende Digitalisierung werden die Anlagen und Systeme angreifbarer, und die meldepflichtigen IT-Sicherheitsvorfälle haben im letzten Jahr deutlich zugenommen.
Dr. Simon Woldeab, fuentis, gibt in seinem Beitrag Herausforderungen für Kritische Infrastrukturen (KRITIS) zunächst einen Überblick über die derzeitige Gesetzeslage und den entsprechenden Richtlinien. Er listet die KRITIS-Sektoren und Anlagenkategorien sowie die entsprechenden Bemessungsgrundlagen und Schwellenwerte auf und erläutert sie. Er geht auf den Anforderungskatalog des BSI ein und diskutiert das Thema „Stand der Technik“ im Zusammenhang mit den branchenspezifischen Sicherheitsstandards (B3S). Zum Schluss veranschaulicht er am Beispiel Krankenhaus den Einsatz eines ISMS unter Einbindung von KRITIS-Standards.
Prof. Dr. Heiko Meyer, KMS Vertrieb und Services, geht in seinem Beitrag IT-Sicherheit im klinischen Umfeld darauf ein, warum Kliniksysteme zukünftig als Cloud-Lösung betrieben werden sollten. Er erörtert, warum Hybrid-Cloud-Systeme von Vorteil für Kliniken sind, und gibt Hinweise, wie klinische IT-Systeme sicher in der Cloud betrieben werden können. Dabei werden die gesetzlichen Besonderheiten des Gesundheitswesens näher beschrieben, spezielle Mechanismen zum Schutz der Daten vorgestellt und die daraus resultierenden Vorteile aus betriebswirtschaftlicher und medizinischer Sicht für Patienten, Ärzte, Klinikmanagement sowie Forschung und Wissenschaft erörtert.
Valeri Milke, Insentis, befasst sich in zwei Beiträgen sowohl mit Best Practices zur automatischen Identifizierung und Behebung der häufigsten kritischen Sicherheitslücken in AWS als auch mit Best Practices zur automatischen Identifizierung und Behebung der häufigsten kritischen Sicherheitslücken in Microsoft Azure. Er legt die Schwerpunkte jeweils auf übergeordnete architektonische Aspekte, auf die wichtigsten sicherheitsbezogenen sowie auf die am häufigsten eingesetzten AWS- und Azure-Services. In tabellarischer Form stellt er den Services detailliert die entsprechenden Handlungsempfehlungen und Maßnahmen gegenüber. Der Autor stellt weitere Tools vor, die die automatisierte Identifizierung von Sicherheitslücken im AWS- und Azure-Umfeld unterstützen. In seinem zweiten Beitrag gibt er zum Abschluss allgemeingültige Hinweise für ein sicheres Cloud Computing.
Herausforderung Cloud Security: Wandel in Technologie und Organisation
Tino Hirschmann und Marcel Reviol
1 Wandel der IT
1.1 Historie
Für ein gutes Verständnis von modernen Cloud-Plattformen sowie den damit verbundenen Sicherheitskonzepten auf technischer und organisatorischer Seite ist es wichtig, eine kurze Zeitreise zu den Anfängen der IT in Unternehmen zu starten. Bei einer Nutzung von Cloud-Diensten wird jede darunterliegende Computer-Hardware im Rechenzentrum des Cloud-Anbieters automatisch für den Anwender durch die Virtualisierung unsichtbar. Allerdings werden diese Technologien immer noch verwendet. Für jeden jüngeren „Digital Native“ lohnt sich daher z.B. ein Besuch im Deutschen Museum in München, wo auch verschiedene Generationen von Computern angeschaut werden können.
Mainframe / Großrechner
Großrechner zeichneten sich durch hohe Zuverlässigkeit sowie einen hohen Datendurchsatz bei der Ein- und Ausgabe aus. Eine Wartung konnte ohne Unterbrechung oder Beeinträchtigung des Betriebes durchgeführt werden. Diese Eigenschaften wurden durch eine herstellerspezifische Abstimmung der Hardwarekomponenten und Betriebssysteme sowie einer integrierten Redundanz ermöglicht.
Der Betrieb der Großrechner sowie die Datenhaltung erfolgten entweder im Rechenzentrum des Herstellers, dem eines IT-Dienstleisters oder in einem firmeneigenen Rechenzentrum des Unternehmens, insofern Ressourcen und Kompetenzen vorhanden waren.
Der Zugriff erfolgte über Hardwareterminals, während die Benutzerverwaltung zentral auf dem Großrechner durchgeführt wurde.
Firmeneigenes Rechenzentrum ab dem Jahr 1980
In den Jahren ab 1980 gab es in den Büros der Unternehmen erste lokale Installationen von auf x86 basierenden Personal Computern (PCs), welche durch interne IT-Teams verwaltet wurden.
Gleichzeitig waren Großrechner in den Rechenzentren immer noch stark verbreitet, und es war eine Koexistenz zwischen beiden Technologien vorhanden. Die zentrale Verwaltung von Rechten erfolgte weiterhin auf dem Großrechner. Eine weitere Absicherung gegen Ausfälle neben den integrierten Hardwareredundanzen der Großrechner erfolgte durch ein Backup-Rechenzentrum beim Hersteller/Dienstleister.
Anbindungen an das damals noch nicht weit verbreitete Internet waren zu dieser Zeit nur in den Bereichen Forschung oder Verteidigung vorhanden. Üblich war hingegen die Verbindung von Bedienterminals z. B. in Unternehmensaußenstellen zum Großrechner über Telefoneinwahlverbindungen bzw. Standleitungen.
Die ersten Serverbetriebssysteme zur Bereitstellung von Dateisystemen, Druckern und Verzeichnisdiensten in einem Rechnernetz wurden verfügbar, welche unabhängig von der darunterliegenden Hardware eingesetzt werden konnten. Diverse Netzwerktechnologien wurden bereits unterstützt.
Eigenes Rechenzentrum ab dem Jahr 1990
Erste Betriebssysteme mit einer grafischen Oberfläche, welche auf unterschiedlichen Prozessorarchitekturen lauffähig waren, kamen auf den Markt und verbreiteten sich in den Unternehmen. Parallel dazu wurde die Zuverlässigkeit verbessert und dadurch ein Einsatz von systemkritischen Anwendungen attraktiv. Die Sicherheit stand zunehmend im Fokus, und eine Zuweisung von Rechten war nun auch im Bereich der Personal Computer, wie bereits zu früheren Zeiten bei Großrechnern, möglich. Eine zentrale Verwaltung in einem Verzeichnisdienst ermöglichte die Kontrolle der Anmeldungen an größere Umgebungen vom vernetzten Personal Computer. Eine Funktionalität für die Hochverfügbarkeit von Netzwerkbetriebssystemen wurde durch die Hersteller bereitgestellt. Zum Einsatz kamen überwiegend physische Server verschiedener Hersteller mit einer dedizierten Funktion (Betriebssystem und Anwendung).
Client-Server-Architekturen ermöglichten den Einsatz von Personal Computern (PCs) in Unternehmensnetzwerken. Großrechner waren immer noch bei den Unternehmen für geschäftskritische Anwendungen verbreitet. Allerdings erfolgte der Zugriff mittlerweile mit softwarebasierenden Terminals und neueren Netzwerktechnologien.
Die Anbindung an andere Standorte der Unternehmen erfolgte über Standleitungen oder gebündelte ISDN-Leitungen. Computerviren verbreiteten sich über Dateien und Wechselmedien, da eine Anbindung an das Internet noch nicht weit verbreitet war.
Gegen Ende des Jahrzehnts wurde das Internet verstärkt durch die Unternehmen verwendet. Die ersten Computerwürmer breiteten sich durch infizierte Dateien über PCs und Server aus, welche an das Internet angebunden waren.
Die ersten Softwareprodukte zur Virtualisierung von physischen Computersystemen auf der x86-Prozessortechnologie kamen gegen Ende des Jahrzehnts auf den Markt. Durch diese Technologie war es möglich, eine oder mehrere virtuelle Maschinen auf einer physischen Hardware zu betreiben. Erweiterungen der x86-Prozessorarchitekturen für eine Hardwareunterstützung der Virtualisierungsfunktionen waren zu diesem Zeitpunkt noch nicht verfügbar und wurden durch die Prozessorhersteller erst im Folgejahrzehnt bereitgestellt.
Der Betrieb der IT-Umgebungen in Unternehmen wurde überwiegend durch interne IT-Teams verantwortet, wobei auch erste Unternehmen ihre IT durch externe Dienstleister betreiben ließen. Der Begriff „Outsourcing“ wurde geboren.
Eigenes Rechenzentrum ab dem Jahr 2000
Der Trend zum Outsourcing verstärkte sich bei den Unternehmen, da eine Fokussierung auf der Kernkompetenzen im Vordergrund stand. Erste Verlagerungen von IT-Aufgaben an externe Dienstleister – auch bereits mit Personalressourcen in Ländern wie Indien – zur Einsparung von Kosten waren auf der Agenda von vielen Unternehmen. Jedoch war es für Unternehmen notwendig, dass ein interner IT-Bereich mit verschiedenen fachlichen Ausprägungen zur Steuerung der externen Dienstleister weiterhin vorhanden war.
Die verstärkte Anbindung an das Internet durch Unternehmen (für E-Mail-Dienste etc.) brachte neue Herausforderungen für die IT-Sicherheit in den Bereichen der Clients sowie der Netzwerkübergänge zum Internet Provider (über Wählverbindung/ Standleitung). Neue Technologien wie Firewalls, Proxy-Server, Anti-Virus-Gateways und Intrusion Detection waren nun bei den Unternehmen im Rechenzentrum vorhanden. Das Rechenzentrum mit seinen Grenzen galt als sicheres Perimeter. Jeder eingehende und ggf. auch ausgehende Datenverkehr wurde zur Absicherung gegen Angriffe kontrolliert.
Die Absicherung der Clients und Server erfolgte durch zentral verwaltete Anti-Virus-Lösungen sowie mit gehärteten Betriebssystemen.
Der erste Computerwurm Love Letter verursachte im Jahr 2000 geschätzte Schäden von bis zu 10 Milliarden Dollar. Bei weiteren darauffolgenden Infektionen durch Computerwürmer wurden Schwachstellen in Betriebssystemen und Anwendungen ausgenutzt.
Ein erster Einsatz von Produkten zur Server-Virtualisierung erfolgte in den Produktivumgebungen der Unternehmen. Hierbei wurden eine bessere Auslastung und Nutzung der x86-Hardware ermöglicht. Durch die Virtualisierung war es nun einfacher, Unternehmen gegen Szenarien wie den Ausfall eines Rechenzentrums abzusichern.
Durch den Einsatz von Multi-Tier-Architekturen wurde für Unternehmen die sichere Bereitstellung von Anwendungen mit Web-Technologien vereinfacht. Dazu wurden komplexe DMZ-Umgebungen2 mit verstärkten Sicherheitssystemen aufgebaut. Ein besonderer Fokus auf IT-Sicherheit ergab sich durch die Bereitstellung von geschäftskritischen Anwendungen im Internet, da Serviceausfälle durch externe Angriffe oder fehlerhafte Hardware verhindert werden sollten.
Einige Vorhaben zur Ablösung von Großrechnern durch neue Client-Server-Technologien und verteilte Systeme wurden gestartet, um die teuren Lizenzkosten einzusparen und die Flexibilität bei der Auswahl der Hersteller zu verbessern.
Outsourcing
Zur Einsparung von Kosten und Freisetzung von Ressourcen übertrugen einige Unternehmen (vollständig oder teilweise) die Verantwortung für den IT-Betrieb an externe Dienstleister. Durch ein Transformationsprojekt wurde in vielen Fällen mit externer Expertise die gesamte IT eines Unternehmens modernisiert bzw. konsolidiert. Hierbei musste sich das Unternehmen auf die Zuverlässigkeit sowie Vertrauenswürdigkeit des Dienstleisters verlassen. Die Einhaltung der Regeln und Prozesse durch den externen Dienstleister musste regelmäßig durch das Unternehmen überprüft werden. Das Modell der Teilung der Verantwortlichkeit zwischen Provider und Kunden bewährte sich und wurde die Vorlage für spätere Zusammenarbeitsmodelle in der Cloud (vgl. Kapitel 1.1.2). Auch beim IT-Outsourcing war bereits die Qualität des Vertrages sehr entscheidend für die klare Regelung von Verantwortlichkeiten zwischen Provider und Kunden, um die damit verbundenen Probleme zu vermeiden.
Die Definition von Grundregeln der IT- und Datensicherheit basierend auf vorhandenen Standards sowie klar strukturierte Sicherheitsprozesse führen bei einem IT-Outsourcing teilweise zu einem höheren Sicherheitsniveau als bei einem internen Betrieb.
Virtualisierung (Compute, Netzwerk, Speicher, Hyperconverged)
Bereits bei den Mainframes / Großrechnern in den 1960er Jahren wurden die vorhandenen Ressourcen zwischen verschiedenen Anwendungen aufgeteilt. Im UNIX-Bereich war Hardwarevirtualisierung bereits bei sehr teuren High-End- und Midrange-Systemen vorhanden. Ab dem Jahr 2005 wurde durch die führenden CPU-Hersteller die Hardwarevirtualisierung unterstützt. Durch Verfügbarkeit von nativen Typ 1 Hypervisor („Bare-Metal-Hypervisor“, ohne darunterliegendes Betriebssystem) wurde die Virtualisierung 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 muss jedoch beachtet werden, dass Middleware-Software regulären Versionswechseln unterliegt. Dies muss der Kunde, wie in bisherigen IT-Umgebungen, weiterhin berücksichtigen, da die Versionswechsel beispielsweise auch Änderungen an der Funktionalität oder den Softwareschnittstellen hervorrufen könnten. Als Sonderform von PaaS sind Container sowie Serverless-Lösungen zu sehen. Der Cloud-Anbieter stellt hierfür eine automatisierte Container-Orchestrierungslösung bereit, welche der Kunde zum Ablauf seiner Anwendung nutzen kann. Im Fall von Serverless geht dies noch etwas weiter. Der Kunde erhält zusätzlich eine standardisierte, temporäre Runtime-Umgebung, in welcher er seinen Code zur Ausführung bringen kann. Eine Bezahlung erfolgt dabei auf Basis der Anzahl der Aufrufe, der Laufzeit des Codes, ggf. konsumierter Ressourcen (z. B. Netzwerk, Storage), der Lokation sowie der Verfügbarkeit.
• 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 |
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.
4.2 Cloud-Technologie und Governance
Auch die Cloud selbst und deren Dienste verändern die Bedrohungslage. Die führenden Anbieter von Cloud-Lösungen bieten schon heute auf ihren Plattformen viele verschiedene Dienste. Diese sind erst einmal einfach zu nutzen, erfordern jedoch immer auch eine individuelle Sicherheitsbetrachtung. So kann, selbst wenn der Kunde abgeschottete Netze in der Cloud erzeugt hat, ein PaaS- oder SaaS-Dienst diese Vorgabe umgehen, da dieser Dienst ggf. direkt über öffentliche Endpunkte kommuniziert und explizit ein privater Service-Endpunkt definiert werden muss. Ein weiteres Problem sind die notwendigen Berechtigungen und Zugriffsbeschränkungen auf verschiedenen Ebenen. Speziell über die Jahre können so schnell komplexe Berechtigungsstrukturen entstehen, die nur noch schwer zu kontrollieren sind. Weiterhin können auch Dienste technische Rollen bekommen (z. B. Berechtigungen an einer virtuellen Maschine), die, sofern nicht ausreichend limitiert, im Falle eines Angriffs ausgenützt werden können.
Grundsätzlich sind auch die auf der Cloud-Ebene genutzten Lösungen zur Isolation von unterschiedlichen Kunden ein möglicher Schwachpunkt. Logische Fehler in der Programmierung des Hypervisors oder Fehler auf Hardwareebene (z. B. in der CPU oder im Speicher) können die Daten eines Kunden offenlegen. Dieses Problem existiert auch schon in klassischen Virtualisierungslösungen auf der Ebene der Hypervisoren, es wird jedoch durch den faktisch beliebigen Benutzerkreis eines Cloud-Anbieters weiter verstärkt.
Für viele Cloud-Kunden ändert sich zudem etwas im Hinblick auf die Transparenz der Sicherheitsmaßnahmen. Während im klassischen Umfeld oder auch beim Outsourcer meist ein erweitertes Audit-Recht besteht, ist dies bei einem großen Cloud-Anbieter nicht der Fall. Hier muss der Kunde sich allein auf Testate und Zertifikate wie z. B. ISO27001/ISO27017, ISAE3402 oder Ähnliches verlassen. Eine eigene Prüfung, z. B. vor Ort in einem Rechenzentrum des Cloud-Anbieters, ist aufgrund der dort vorliegenden strengen Sicherheitsvorkehrungen und Zugangsbeschränkungen typischerweise nicht möglich. Komplexität der Infrastruktur, verteilt auf verschiedene Standorte und der jeweiligen Cloud-Organisation, vereinfachen diese Prüfung durch die typischen Dienstleister zudem nicht.
Um diesen Bedrohungen zu begegnen, sind eine sorgfältige Planung und klare Strukturen insbesondere beim Identitäts- und Zugriffsmanagement notwendig. Ebenfalls hilfreich sind Systeme zur Erstellung kurzlebiger Zugangsinformationen oder Just-in-Time Access. Durch geeignete Policies, welche die Nutzung von Diensten limitieren (z. B. auf spezifische Regionen) und Sicherheitsvorgaben überprüfen, können Abweichungen von der Sicherheitskonfiguration verhindert bzw. erkannt werden. Die daran angehängte Sicherheitsüberwachung inklusive einer schnellen (automatisierten) Reaktion muss Sicherheitsprobleme zeitnah adressieren. Diese und andere Bausteine bilden so eine sichere Gesamtarchitektur in der Cloud. Hierbei sollte der Kunde immer das Ziel einer kontinuierlichen Sicherheit im Auge haben. Durch sicheres Design, die sichere Implementierung und eine kontinuierliche Überwachung der Sicherheit kann dies auch erreicht werden. Wesentliche Schlüsselelemente sind Automatisierung und agile Prozesse.
Auch wenn der Cloud-Anbieter grundsätzlich Schwachstellen in den unterliegenden Komponenten adressiert, kann es für einzelne, kritische Systeme sinnvoll sein, diese auf besonders abgesicherten, dedizierten Instanzen zu betreiben. Dies bietet insbesondere Schutz gegen Schwachstellen in der Compute Hardware (z. B. CPU).
4.3 Vertrauen in den Cloud Provider
Eine weitere Bedrohung ist der Cloud-Anbieter selbst bzw. die Jurisdiktion, welcher er unterliegt. Dadurch kann ggf. ein Zugriff auf Daten durch staatliche Stellen erfolgen, auch wenn der Kunde diesen nicht unmittelbar unterliegt und der Kunde darüber gegebenenfalls auch nicht unterrichtet wird bzw. werden darf. Ein weiterer möglicher Aspekt ist Wirtschaftsspionage. Auch wenn der Cloud-Anbieter zahlreiche Maßnahmen wie Verschlüsselung oder Ähnliches als Schutzmaßnahmen anbietet, sind diese meist nur eingeschränkt wirksam als Schutz gegen den Cloud-Anbieter selbst. Dies ist einerseits darin begründet, dass der Cloud-Anbieter die Hardware, auf welchen die Datenverarbeitung erfolgt, kontrolliert und anderseits auch das Benutzermanagement, welche alle Zugriffe auf Systeme und Komponenten, inkl. der Key-Management-Systeme, kontrolliert. Dieses Bedrohungsszenario ist insbesondere für Cloud-Kunden, die in einem regulierten/staatlichen Umfeld agieren, problematisch. Es kann aber auch für andere Kunden, die einen Zugriff durch staatliche Stellen aus wirtschaftlichen Gründen unterbinden wollen, relevant sein.
Bei den von Cloud-Anbietern genutzten Komponenten, wie z. B. Key-Management-Systemen, Identity- und Access-Management-Systemen, aber auch Systeme-Management-Systemen, handelt es sich meist um Eigenentwicklungen. Dies gilt oft auch für die eingesetzte Hardware, z. B. Verschlüsselungsmechanismen im Provider-eigenen Storage-Controller. Eine Prüfung der Qualität dieser Komponenten aus IT-Security-Sicht findet daher meist auch nur eingeschränkt statt. Für den Kunden selbst ist dies am Ende eine Blackbox: Er muss dem Cloud-Anbieter letztlich vertrauen.
Die grundsätzliche Bedrohung kann daher technisch nicht abschließend adressiert werden. Auch wenn Ansätze wie homomorphe oder proxy-basierte Verschlüsselung eine Lösung versprechen, sind diese für den breiten und universellen Einsatz zurzeit nicht geeignet. Die vom Cloud Provider angebotenen Verschlüsselungsoptionen, sowohl auf Storage- als auch auf Compute-Ebene, können das Problem abmildern. Durch eine reine Nutzung von IaaS, einer Substitution von Cloud Provider Tools durch eigene Tools sowie einer Verschlüsselung auf Betriebssystemebene, mit eigenem Key-Management-Service, kann ein Zugriff auf das System und dessen Daten weitestmöglich ausgeschlossen werden. Vollständig ist dieser Schutz jedoch nicht, und der Kunde erkauft sich dies in der Regel mit Komfortverlust und höheren Kosten.
Weitere mögliche Ansätze sind hybride Cloud-Modelle, bei welchen besonders schützenswerte Daten weiterhin im eigenen Rechenzentrum vorgehalten werden, wie auch die Nutzung von Instanzen mit Confidential-Compute-Fähigkeiten. Da der Anbieter aber die Hardware und das IAM-System kontrolliert, ist ultimativ kein vollständiger Schutz möglich. Hier zeigt sich einmal mehr, dass eine Analyse, wie in 2.1 aufgeführt, zwingend notwendig ist.
Der integrierte Ansatz bei der Migration in die Cloud: Security by Default
Christian Lechner und Andreas Schindler
1 Einführung
In Zeiten fortschreitender Digitalisierung verlagert sich die Wertschöpfung in Unternehmen weiter in den virtuellen Raum. Damit wird das Thema IT-Sicherheit immer bedeutender. Die Relevanz von IT-Risiken steigt für Unternehmen jeder Größenordnung und unabhängig vom Geschäftsmodell. Unternehmen beschäftigen sich heute mit der Frage, wie Geschäftsprozesse der Zukunft aussehen und sicher sind vor Angriffen, ob von außen oder immer öfter von innen.
Unabhängig vom Projektthema – ob Cloud-Migration oder New Work – muss das Ziel sein, immer die IT-Sicherheit von Beginn an mit zu betrachten. Die Mehrzahl der Unternehmen hat verstanden, dass Cyberangriffe keine Eintagsfliegen sind und jedes Unternehmen treffen. Gerade in Cloud-Projekten nehmen wir in unserer täglichen Arbeit bei Kunden oft Bedenken und Vorbehalte wahr. Ängste aber sind unbegründet, die Cloud ist keine „Böse“.
Was kann passieren, wenn Unternehmen auf eigene Faust entlang eines IT-Sicherheits-Frameworks wie zum Beispiel NIST loslegen? Oft entstehen Flickenteppiche, deren Komplexität kaum noch zu managen ist. Deshalb entwickeln wir mit unseren Kunden eine vollständig integrierte Sicherheitsarchitektur, die dem Leitgedanken „Security by Default“ folgt. Damit sind Unternehmen, die den Schritt in die Cloud gehen, auf der sicheren Seite.
2 Hacks and Attacks: Cloud versus On-Premises
Hacker greifen aus unterschiedlichen Motivationen heraus Unternehmen, Staaten und immer häufiger kritische Infrastrukturen an. Die Ziele sind vielfältig. Meist geht es darum, sensible Informationen, Daten und Identitäten zu stehlen oder durch unbefugtes Eindringen Veränderungen vorzunehmen. Dabei spielt es keine Rolle, wo die begehrten Daten gehostet werden: On-Premises im eigenen Rechenzentrum oder in der Cloud.
Da Hacker in der Regel über ein umfangreiches Wissen verfügen und sich Trends schnell anpassen, konzentrieren sie heute ihre Angriffe auch verstärkt auf Cloud-Services, um sich Zugriff auf sensible Daten zu verschaffen. Laut dem Verizon Data Breach Investigation Report 2020 wurden in mehr als 80 Prozent der Fälle gestohlene oder mit der Brute-Force-Methode geknackte Passwörter verwendet. Heißt das, die Cloud ist doch böse? Nein, Unternehmen müssen nur gut vorbereitet sein.
3 Gefahren abwehren: Wir gehen in die Cloud!?
Fatal ist die Einschätzung vieler Unternehmen, wenn es um die Gewährleistung der Sicherheit für die eigenen Unternehmenswerte in Form von Daten geht. Wir gehen in die Cloud und sind alle Sorgen um die IT-Security los? Irrtum, wenn man einen Blick auf die Verantwortlichkeiten von Cloud Provider und Cloud-Kunde wirft. Für Cloud Security sind beide Parteien verantwortlich. Das heißt, Cloud-Kunden müssen auf der Client-Seite für umfassende Sicherheit sorgen.
So ist der Cloud-Kunde für die Datensicherheit und Einhaltung gesetzlicher Vorgaben verantwortlich, steuert den Zugriff, schützt Identitäten und Daten und entwickelt auf Basis der Konfiguration von beispielsweise Microsoft Cloud-spezifische Sicherheitsrichtlinien.
Hand in Hand: Im Gegenzug lässt sich Microsoft als Provider regelmäßig auditieren und zertifizieren, stellt Reports zur Verfügung, betreibt und wartet die physischen Ressourcen wie Hosts, Netzwerk, Rechenzentrum. Wichtig zu wissen: Je nach Bereitstellungsmodell – SaaS, PaaS oder IaaS – ändern sich die Verantwortlichkeiten. Vertragliche Regelungen zwischen Anbieter und Kunde schaffen hier Klarheit.
4 Trotz Maßnahmen und geteilter Verantwortung – können Unternehmen Cloud-Services trauen?
Wir sagen klar: ja! Denn Cloud Security hat heute einen hohen Stellenwert und steht für Kunden als auch für die Provider von Cloud Services an erster Stelle. Die Maßnahmen der Cloud Security bestehen aus einem Set von Regeln, Prozessen und technischen Lösungen, die sicherstellen, dass gesetzliche Vorgaben eingehalten werden. Sie schützen die Infrastruktur der Cloud und deren Anwendungen, damit Daten sicher verarbeitet und gespeichert werden können.
Die Einhaltung der gesetzlichen Vorschriften wird ebenso durch Cloud-Lösungen erleichtert. 35 Prozent der Unternehmen hatten in den vergangenen fünf Jahren mindestens einen Compliance-Verstoß zu verzeichnen, mit fatalen Folgen: Reputationsverluste, finanzielle Schäden, Produkt-/Qualitätsmängel, Kundenverlust. Darüber hinaus gibt es weiterhin großen Handlungsbedarf zur Umsetzung der DSGVO. Bei der Migration in die Public Cloud werden die Unternehmensdaten in einer Compliance-zertifizierten Umgebung geschützt. Das heißt, die Anwendungen in der Cloud, die bereitgestellt werden, entsprechen den gesetzlichen und Compliance-Anforderungen. Das schafft Vertrauen.
Unser Credo bei Cloud-Projekten lautet deshalb: Nie ohne Security. Generell ist es ratsam, bei Cloud-Projekten – unabhängig davon, ob es sich um die Migration in die Public oder Private Cloud handelt – die Security schon in der Planungsphase mit ins Boot zu holen. Der Ansatz „Security by Default“ hat sich längst bei der Entwicklung von IT-Produkten bewährt und ist in IT-Projekten ebenso hilfreich. Das bedeutet in der Praxis: alle Fachbereiche mit ins Projekt einbinden, die Anforderungen definieren und sich entlang eines Fragenkatalogs ein umfassendes Bild machen, wie das Unternehmen aufgestellt ist.
5 Umfassende Sicherheitsanalyse im Vorfeld klärt Handlungsbedarfe
Das Gesamtbild entsteht auf Basis eines IT-Security Assessments, in dem wir gemeinsam mit dem Kunden herausarbeiten, wo die größten Schwachstellen liegen und wo der höchste Bedarf an Sicherheit ist. Auf Basis der CIS Controls werden 20 Bereiche unter die Lupe genommen und genau analysiert. Dazu zählen unter anderem die physikalische Sicherheit des Rechenzentrums, die Klassifizierung und der Zugriff auf die Daten, die Datensicherheit, das Management von Berechtigungen sowie der Schutz des E-Mail-Verkehrs vor Viren, Würmern und Trojanern.
Unsere umfassende Sicherheitsanalyse kurz zusammengefasst: alles zum gegenwärtigen Zustand erfahren, ihn bewerten, konkrete Handlungsfelder aufzeigen und geeignete Maßnahmen für mehr Sicherheit finden. Anhand einer Grafik wird deutlich sichtbar, wo Handlungsbedarf besteht – weil entweder die IT-Sicherheit gravierende Mängel aufzeigt oder die Compliance-Anforderungen der Branche nicht erfüllt werden. Aus den Hausaufgaben im Anforderungskatalog ergeben sich die Handlungsfelder und eine Roadmap, die wir mit den Kunden in seiner individuellen Cloud-Umgebung direkt angehen und umsetzen.
Die Maßnahmen reichen von der Entwicklung der Datenklassifizierung für Dokumente (public, internal, confidential oder nur personenbezogene Einsicht erlaubt) bis zur Vergabe für Zugriffe und Berechtigungen, Reporting, Auditing und Monitoring.
Wenn die Klassifizierung steht, geht es um das Handling in der Cloud: Wo werden Dokumente und Daten abgelegt und wie kann in diesem Zusammenhang die Klassifizierung auch verlässlich umgesetzt werden? Wie wird sichergestellt, dass Dokumente in der richtigen Kategorie abgelegt werden und eine Confidential-Klassifizierung nicht geteilt wird: in der Cloud ablegen ja, aber teilen nein.
6 Conditional Access – nur ein Aspekt für den Schutz von Daten
Ein weiterer Sicherheitsaspekt, der mit dem Kunden gemeinsam erarbeitet wird, ist die Definition einer Architektur für den Zugriff auf Daten, die in der Cloud gespeichert, geteilt und verarbeitet werden. Die wesentlichen Fragen sind: Wer darf zugreifen – nur von intern oder auch von extern, Partner, Lieferanten oder andere Player im Unternehmens-Ecosystem? Von wo aus darf der Zugriff erfolgen – nur vom Laptop oder Smartphone im Firmennetzwerk oder auch von privater Hardware aus dem Homeoffice?
Wenn geklärt ist, wer von wo aus auf welche Daten zugreifen darf und wie diese geschützt werden müssen, kommt das Monitoring und Reporting ins Spiel: Ist es nachvollziehbar, wer auf welche Daten zugegriffen hat? Von wo aus wurde zugegriffen? Stimmen die Berechtigungen oder wurde eine Berechtigung kompromittiert? Beispiel Maschinenbau: In dieser Branche bestehen häufig Exportkontrollen, die vorgeben, aus welchen Ländern ein Zugriff auf bestimmte Daten erfolgen darf. Das bedeutet, dass auch nachvollziehbar sein muss, wer aus einem Land auf Daten zugreift, aus dem der Zugriff nicht erlaubt ist. Hat die Cloud Security einmal Zweifel, ob ein Zugriff legitim erfolgte oder nicht, so kann automatisiert eine weitere Schutzmaßnahme, beispielsweise die Multi-Faktor-Authentifizierung, angefordert werden. Diese sichert den Zugriff zusätzlich ab. Dieser Ansatz des Conditional Access ist für Unternehmen ein Muss, um den Schutz der Unternehmens-Assets, also der Daten, zu gewährleisten.
Zusammengefasst: Die Vorteile der Cloud-Lösung stehen heute außer Frage. Unternehmen können wesentlich schneller agieren und agiler arbeiten als je zuvor. Aber die Sicherheit muss oberste Priorität haben und das heißt, alle relevanten Unternehmensbereiche rechtzeitig ins Boot zu holen, auch die Mitarbeiter! Denn sie müssen die Anwendungen verstehen, ihre Arbeitsweise anpassen und wissen, wie sie diese zu nutzen haben.
7 Migration in die Cloud am Beispiel eines Unternehmens aus dem Maschinenbau
Wir beraten Unternehmen, die sich bereits auf dem Weg in die Public oder Private Cloud befinden oder ganz am Anfang einer Migration stehen, liefern die technischen Lösungen aus der Microsoft Public Cloud und haben dabei die Sicherheit immer im Blick. Die Vorgehensweise in einem Projekt bei einem Kunden aus dem Maschinenbau zeigt, wie ein schneller produktiver Start einer Cloud-Plattform gelingen kann. Ziel des Kunden war es, in internationalen Projektteams neue digitale Produkte schnell entwickeln und bereitstellen zu können. Zur Einhaltung der strengen Sicherheitsanforderungen nahmen Maßnahmen zur Sicherstellung der IT-Sicherheit und des Datenschutzes einen hohen Stellenwert ein.
Unter Anwendung unseres Cloud-Vorgehensmodells entstand eine moderne, hochgradig skalierbare und automatisierte Multi-Cloud-Plattform. Diese berücksichtigt neben IaaS-Designkomponenten die im Vordergrund stehenden PaaS- und SaaS-Lösungskomponenten. Dies folgt der strategischen Vorgabe „SaaS vor PaaS vor IaaS“. Im Zuge des Designprozesses und der initialen Bereitstellung der Plattform lag der Fokus auf elementaren Architekturbausteinen. Dies sollte einen schnellen produktiven Start der Cloud-Plattform gewährleisten. Durch die Anwendung agiler Projekt-, Design- und Implementierungsmethoden erfolgte die Entwicklung des Reifegrads der Plattform sowie das parallele Re-Design der Aufbauorganisation.
Darüber hinaus entstand eine Multi-Cloud-Plattform unter Verwendung strategischer zentraler IT-Dienste, wie beispielsweise dem Verzeichnisdienst Microsoft Azure AD. Dieser „shared IT-Service“ bedient als zentrale Architekturkomponente die Authentifizierungsanfragen aus diversen Cloud-Umgebungen, wie beispielsweise der SAP Cloud Platform. Darüber hinaus sichert diese zentrale Komponente administrative Zugänge und Berechtigungen sowie Authentifizierungsanfragen externer Parteien durch Einsatz moderner B2C- und B2B-Funktionalitäten.
Das Design der Cloud-Architektur berücksichtigt alle erforderlichen Disziplinen einer modernen digitalen Infrastruktur, sowohl im technischen als auch organisatorischen Umfeld. Dies sind Themen wie Kostenmanagement und Betrieb der Cloud-Plattform, die Überwachung von Zugriffen, Performance und Nutzung von Anwendungsarchitekturen sowie die frühzeitige Erkennung von Sicherheitsvorfällen.
Die Bausteine im Überblick:
• Aufbau und Betrieb einer Azure-Cloud-Infrastruktur und Integration in die bestehende On-Premises-Infrastruktur
• Die Cloud-Architektur folgt dem Ansatz „Security by Default“
• Bereitstellung und Verwaltung der IT-Infrastruktur mit Infrastructure as Code und DevOps
8 Fazit
Erfolgreiche Cloud-Projekte erfordern einen ganzheitlichen Ansatz, bei dem hohe Beratungskompetenz gefragt ist. Die Erfahrung zeigt, dass die Designphasen hierbei agil durchgeführt und Security by Default berücksichtigt werden müssen. Das heißt auch, es darf nicht in Säulen gedacht werden. Kompetenzen des Beratungsunternehmens in Cloud-Lösungen sowie IT-Security und Compliance sind der Garant für erfolgreiche Projekte. Die integrierte Sicht und die Abkehr vom Silodenken auch im Unternehmen sowie das Security-Denken von ganz oben her lassen Bedenken und Vorbehalte verblassen.
Bei Projektanfragen von Kunden wird das Cloud-Umfeld beleuchtet, um eine Lösung maßzuschneidern: Wo ist das Unternehmen ansässig – DACH, in Europa oder international? Beschäftigt es sich mit Auftragsdatenverarbeitung? Im Security- und Compliance-Umfeld: Um welche Daten handelt es sich, wo liegen die Daten, wer darf zugreifen in welchem Zeitfenster? Gilt das Vier-Augen-Prinzip, wann werden Rechte entzogen? Diese Fragestellungen haben Auswirkungen auf die Wahl des Bezugsmodells, die Wirtschaftlichkeit und das Kostenmodell und tragen allesamt zu einer erfolgreichen Cloud-Migration bei.
Nach unserer Erfahrung mit Kundenprojekten lassen sich neue Anwendungen und Funktionalitäten auf einem Playground ohne produktive Daten frühzeitig realisieren und testen. Erst dann folgt der Schritt in die Entwicklungsumgebung, wo dann ein erstes MVP (Minimum Viable Product) entsteht. Dadurch ist die Geschwindigkeit der Veröffentlichung in der Public Cloud höher als in einer On-Premises-Umgebung.
Last but not least kommt es auch auf die Menschen an. Das ausgefeilteste Sicherheitskonzept, die besten Test-Tools und die modernsten Entwicklungsumgebungen sind wichtige Facetten – doch erst die permanente Schulung der Anwender im Unternehmen in Achtsamkeit, Aufmerksamkeit und Vorsicht bei der Cyber Security auch im Cloud-Umfeld machen Security by Default rund. Der Schlüssel heißt Awareness.
Бесплатный фрагмент закончился.
