Erhalten Sie Zugang zu diesem und mehr als 300000 Büchern ab EUR 5,99 monatlich.
- Herausgeber: O'Reilly
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Deutsch
Cloud-typische Sicherheitsthemen verständlich und praxisnah erklärt - Strategien und Lösungsansätze für alle gängigen Cloud-Plattformen, u.a. AWS, Azure und IBM Cloud - Deckt das breite Spektrum der Security-Themen ab - Gezieltes Einarbeiten durch den modularen Aufbau; mithilfe von Übungen können Sie Ihren Wissensstand überprüfen - Experten-Autor: IBM Distinguished Engineer mit zahlreichen Zertifizierungen und 25 Jahren Branchenerfahrung In diesem Praxisbuch erfahren Sie alles Wichtige über bewährte Sicherheitsmethoden für die gängigen Multivendor-Cloud-Umgebungen – unabhängig davon, ob Ihr Unternehmen alte On-Premises-Projekte in die Cloud verlagern oder eine Infrastruktur von Grund auf neu aufbauen möchte. Entwicklerinnen, IT-Architekten und Sicherheitsexpertinnen lernen Cloud-spezifische Techniken zur sicheren Nutzung beliebter Plattformen wie Amazon Web Services, Microsoft Azure und IBM Cloud kennen. Sie erfahren, wie Sie Data Asset Management, Identity and Access Management (IAM), Vulnerability Management, Netzwerksicherheit und Incident Response effektiv in Ihrer Cloud-Umgebung umsetzen. - Informieren Sie sich über neueste Herausforderungen und Bedrohungen im Bereich der Cloud-Sicherheit - Managen Sie Cloud-Anbieter, die Daten speichern und verarbeiten oder administrative Kontrolle bereitstellen - Lernen Sie, wie Sie grundlegende Prinzipien und Konzepte wie Least Privilege und Defense in Depth in der Cloud anwenden - Verstehen Sie die entscheidende Rolle von IAM in der Cloud - Machen Sie sich mit bewährten Praktiken vertraut, um häufig auftretende Sicherheitszwischenfälle zu erkennen, zu bewältigen und den gewünschten Zustand wiederherzustellen - Erfahren Sie, wie Sie mit verschiedensten Sicherheitslücken, insbesondere solchen, die in Multi-Cloud- und Hybrid-Cloudarchitekturen auftreten, umgehen - Überwachen Sie PAM (Privileged Access Management) in Cloud-Umgebungen
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 389
Veröffentlichungsjahr: 2024
Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:
Ähnliche
Copyright und Urheberrechte:Die durch die dpunkt.verlag GmbH vertriebenen digitalen Inhalte sind urheberrechtlich geschützt. Der Nutzer verpflichtet sich, die Urheberrechte anzuerkennen und einzuhalten. Es werden keine Urheber-, Nutzungs- und sonstigen Schutzrechte an den Inhalten auf den Nutzer übertragen. Der Nutzer ist nur berechtigt, den abgerufenen Inhalt zu eigenen Zwecken zu nutzen. Er ist nicht berechtigt, den Inhalt im Internet, in Intranets, in Extranets oder sonst wie Dritten zur Verwertung zur Verfügung zu stellen. Eine öffentliche Wiedergabe oder sonstige Weiterveröffentlichung und eine gewerbliche Vervielfältigung der Inhalte wird ausdrücklich ausgeschlossen. Der Nutzer darf Urheberrechtsvermerke, Markenzeichen und andere Rechtsvorbehalte im abgerufenen Inhalt nicht entfernen.
Cloud Security in der Praxis
Leitfaden für sicheres Softwaredesignund Deployment
Chris Dotson
Deutsche Übersetzung vonThomas Demmig
Chris Dotson
Lektorat: Ariane Hesse
Übersetzung: Thomas Demmig
Korrektorat: Sibylle Feldmann, www.richtiger-text.de
Satz: III-satz, www.drei-satz.de
Herstellung: Stefanie Weidner
Umschlaggestaltung: Karen Montgomery, Michael Oréal, www.oreal.de
Bibliografische Information 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.
ISBN:
978-3-96009-242-1
978-3-96010-850-4
ePub
978-3-96010-851-1
1. Auflage 2024
Translation Copyright für die deutschsprachige Ausgabe © 2024 dpunkt.verlag GmbH
Wieblinger Weg 17
69123 Heidelberg
Authorized German translation of the English edition Practical Cloud Security, 2nd Edition ISBN 9781098148171 © 2024 Chris Dotson. This translation is published and sold by permission of O’Reilly Media, Inc., which owns or controls all rights to publish and sell the same.
Dieses Buch erscheint in Kooperation mit O’Reilly Media, Inc. unter dem Imprint »O’REILLY«.O’REILLY ist ein Markenzeichen und eine eingetragene Marke von O’Reilly Media, Inc. und wird mit Einwilligung des Eigentümers verwendet.
Schreiben Sie uns:
Falls Sie Anregungen, Wünsche und Kommentare haben, lassen Sie es uns wissen: [email protected].
Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.
Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.
Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Übersetzer noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.
Inhalt
Einleitung
1Prinzipien und Konzepte
Least Privilege
Defense in Depth
Zero Trust
Threat Actors, Diagramme und Trust Boundaries
Delivery-Modelle für Cloud-Services
Das Cloud Shared Responsibility Model
Risikomanagement
Zusammenfassung
Übungen
2Schutz und Management von Data Assets
Identifizieren und Klassifizieren von Daten
Beispiele für Stufen der Datenklassifikation
Relevante Anforderungen aus Gesetzen oder aus Branchenvorgaben
Data Asset Management in der Cloud
Cloud-Ressourcen taggen
Daten in der Cloud schützen
Tokenisieren
Verschlüsselung
Zusammenfassung
Übungen
3Schutz und Management von Cloud Assets
Unterschiede zur klassischen IT
Arten von Cloud Assets
Compute Assets
Storage Assets
Network Assets
Asset Management Pipeline
Beschaffungslecks
Verarbeitungslecks
Tool-Lecks
Erkenntnislecks
Cloud Assets taggen
Zusammenfassung
Übungen
4Identity and Access Management
Unterschiede zu klassischer IT
Lebenszyklus von Identität und Zugriff
Anforderung
Genehmigen
Erzeugen, löschen, zuweisen oder zurückziehen
Authentifizierung
Cloud IAM Identities
Business-to-Consumer und Business-to-Employee
Multifaktor-Authentifizierung
Passwörter, Passphrasen und API-Schlüssel
Shared IDs
Federated Identity
Single Sign-On
Instanz-Metadaten und Identitätsdokumente
Secrets Management
Autorisierung
Zentrale Autorisation
Rollen
Revalidieren
Bringen wir alles in der Beispielanwendung zusammen
Zusammenfassung
Übungen
5Vulnerability Management
Unterschiede zu klassischer IT
Verletzliche Bereiche
Datenzugriff
Anwendung
Middleware
Betriebssystem
Netzwerk
Virtualisierte Infrastruktur
Physische Infrastruktur
Schwachstellen finden und beheben
Network Vulnerability Scanner
Agentenlose Scanner und Configuration Management Systems
Agentenbasierte Scanner und Configuration Management Systems
Cloud Workload Protection Platforms
Containerscanner
Dynamic Application Scanner (DAST)
Static Application Scanner (SAST)
Software Composition Analysis Tools (SCA)
Interactive Application Scanner (IAST)
Runtime Application Self-Protection Scanner (RASP)
Manuelle Code-Reviews
Penetration Tests
User Reports
Beispieltools für das Vulnerability und Configuration Management
Risikomanagementprozess
Metriken beim Vulnerability Management
Tool Coverage
Mean Time to Remediate
Systeme/Anwendungen mit offenen Schwachstellen
Anteil der Falsch-Positiven
Anteil der Falsch-Negativen
Vulnerability Recurrence Rate
Change Management
Bringen wir alles in der Beispielanwendung zusammen
Zusammenfassung
Übungen
6Netzwerksicherheit
Unterschiede zu klassischer IT
Konzepte und Definitionen
Zero Trust Networking
Allowlists und Denylists
DMZs
Proxies
Software-Defined Networking
Network Functions Virtualization
Overlay Networks und Kapselung
Virtual Private Clouds
Network Address Translation
IPv6
Netzwerkverteidigung bei der Beispielanwendung
Verschlüsselung auf dem Transportweg
Firewalls und Netzwerksegmentierung
Administrativen Zugriff erlauben
Network Defense Tools
Egress-Filter
Data Loss Prevention
Zusammenfassung
Übungen
7Erkennen, reagieren und wiederherstellen
Unterschiede zur klassischen IT
Was soll überwacht werden?
Zugriff privilegierter User
Logs aus Verteidigungstools
Logs und Metriken von Cloud-Services
Logs und Metriken von Betriebssystemen
Middleware-Logs
Secrets-Server
Ihre Anwendung
Wie soll überwacht werden?
Aggregation und Aufbewahrung
Logs parsen
Suchen und korrelieren
Alerting und automatisierte Response
Security Information and Event Managers
Threat Hunting
Auf einen Vorfall vorbereiten
Team
Pläne
Tools
Auf einen Vorfall reagieren
Cyber Kill Chains und MITRE ATT&CK
Die OODA-Schleife
Cloud-Forensik
Unautorisierten Zugriff blockieren
Datenabzug und Command and Control stoppen
Wiederherstellen
IT-Systeme erneut deployen
Benachrichtigungen
Lessons Learned
Beispielmetriken
Toolbeispiele für Erkennung, Reaktion und Wiederherstellung
Erkennung und Reaktion in einer Beispielanwendung
Die Schutzsysteme überwachen
Die Anwendung überwachen
Das Administrationsteam monitoren
Die Audit-Infrastruktur verstehen
Zusammenfassung
Übungen
Anhang: Lösungen zu den Übungen
Index
Einleitung
Wie der Titel schon besagt, ist dieses Buch ein praxisorientierter Ratgeber für das Absichern Ihrer Cloud-Umgebungen. In so gut wie allen Organisationen muss die Security um Zeit und Geld kämpfen und hat oft das Nachsehen gegenüber dem Implementieren von Features und Funktionen. Daher ist es wichtig, sich aus Security-Sicht darauf zu konzentrieren, das Geld möglichst effektiv einzusetzen.
Dieses Buch soll Ihnen dabei helfen, die wichtigsten Schutzmaßnahmen für Ihre wichtigsten Assets schnell und korrekt einzurichten – egal ob Sie ein Security Professional sind, der sich aber noch in der Cloud zurechtfinden muss, oder eine Architektin oder ein Entwickler mit Security-Verantwortlichkeiten. Von dieser stabilen Basis ausgehend können Sie Ihre Mechanismen weiter ausbauen und entwickeln.
Viele der Schutzmaßnahmen und -prinzipien sind in Cloud- und On-Premises-Umgebungen ähnlich, aber es gibt in der Praxis trotzdem ein paar wichtige Unterschiede. Daher mögen Sie manche der Empfehlungen für die angewandte Cloud-Sicherheit überraschen, wenn Sie schon Sicherheitserfahrung im On-Premises-Umfeld gesammelt haben. Es gibt unter den Security Professionals natürlich in nahezu allen Bereichen der IT-Sicherheit unterschiedliche Meinungen, aber die Empfehlungen in diesem Buch sind aus jahrelanger Erfahrung im Absichern von Cloud-Umgebungen entstanden, und sie berücksichtigen einige der neuesten Entwicklungen bei den Angeboten im Bereich Cloud Computing.
Dies ist vor allem ein Buch über Sicherheit, nicht über Compliance. Müssen Sie spezifische Compliance-Anforderungen erfüllen, wie zum Beispiel PCI DSS, HIPAA oder FedRAMP, werden Sie hier trotzdem ein paar Ratschläge über das Design Ihrer Schutzmaßnahmen finden, die helfen können.
Wer dieses Buch lesen sollte
Dieses Buch soll als Quelle für Fortgeschrittenere dienen und richtet sich vor allem an zwei Arten von Praktikern und Praktikerinnen:
Sie haben schon Erfahrungen im Absichern von On-Premises-Umgebungen gesammelt, aber nur wenig oder gar keine Erfahrung mit Cloud-Umgebungen.
Sie haben schon Erfahrungen im Aufbau von Cloud-Umgebungen gesammelt, aber nur wenig oder gar keine Erfahrung im Absichern dieser Cloud-Umgebungen.
Ziel dieses Buchs ist es, Ihnen ein konzeptionelles Verständnis dessen zu geben, was im Bereich der Cloud-Sicherheit möglich ist. Sie werden hier aus verschiedenen Gründen keine Rezepte wie in einem Kochbuch finden, bei denen exakt beschrieben wird, wie Sie die unterschiedlichen Mechanismen in bestimmten Cloud-Umgebungen implementieren. Einer der Gründe ist, dass solche Ratgeber regelmäßig sehr schnell nicht mehr aktuell sind, weil die Cloud-Provider ihre Implementierungen fortlaufend verbessern. Ein anderer ist, dass die Cloud-Provider im Allgemeinen bessere Anleitungen erstellen können als ich, weil diese viel spezifischer auf die Art und Weise abgestimmt sein können, wie die Services designt sind. Eine detaillierte Schritt-für-Schritt-Anleitung von einem Cloud-Provider wird viel nützlicher sein als eine allgemeine Beschreibung, die versucht, mehrere Cloud-Provider abzudecken.
Ich versuche hier, Ihnen zu erklären, wann Sie eine dieser Anleitungen finden und einsetzen müssen.
Wie dieses Buch aufgebaut ist
Die ersten drei Kapitel stellen Ihre Verantwortlichkeiten in der Cloud vor und wie sich diese von denen in On-Premises-Umgebungen unterscheiden. Dazu wird erklärt, was für Assets Sie haben und worin die wahrscheinlichsten Bedrohungen dahin gehend bestehen. Zudem werden ein paar Schutzmechanismen vorgestellt.
In den Kapiteln 4 bis 6 finden Sie praktische Ratschläge – in der Reihenfolge ihrer Wichtigkeit – zu den wichtigsten Schutzmaßnahmen, die Sie sich als Erstes anschauen sollten:
Identity and Access Management
Vulnerability Management
Netzwerkschutz
Das letzte Kapitel dreht sich darum, wie Sie erkennen, ob etwas schiefläuft, und wie Sie damit umgehen. Es wäre nicht verkehrt, dieses Kapitel zu lesen, bevor tatsächlich etwas passiert!
Konventionen, die in diesem Buch genutzt wurden
Die folgenden typografischen Konventionen kommen in diesem Buch zum Einsatz:
Kursiv
Steht für neue Begriffe, URLs, E-Mail-Adressen, Dateinamen und Dateierweiterungen.
Schreibmaschinenschrift
Steht für Programmlistings, aber auch innerhalb von Absätzen, um sich auf Programmelemente wie Variablen oder Funktionsnamen, Datenbanken, Datentypen, Umgebungsvariablen, Anweisungen und Schlüsselwörter zu beziehen.
fette Schreibmaschinenschrift
Steht für Befehle oder anderen Text, der genau so einzugeben ist.
Kursive Schreibmaschinenschrift
Steht für Text, der durch von Ihnen bereitgestellte Werte oder durch sich aus dem Kontext ergebende Werte ersetzt werden soll.
Dieses Element enthält einen Tipp oder Vorschlag.
Dieses Element enthält einen allgemeinen Hinweis.
Dieses Element enthält eine Warnung.
Danksagung
Dieses Buch wäre ohne die Unterstützung und Ermutigung meiner wundervollen Frau Tabitha Dotson nicht entstanden. Sie hat mir klargemacht, dass ich diese Gelegenheit nicht verstreichen lassen dürfe, und hat über ein Jahr lang mit Terminen und Verpflichtungen jongliert, damit ich schreiben konnte. Auch möchte ich meinen Kindern Samantha (für ihr umfassendes Wissen über griechische Mythologie) und Molly (für das fortlaufende Infragestellen von Annahmen und ihre unkonventionelle Denkweise) danken.
Neben dem Autor sind viele Menschen erforderlich, damit ein Buch veröffentlicht wird, und mir ist das erst mit diesem Buch bewusst geworden. Ich möchte dem Lektor Andy Oram und der Lektorin Courney Allen der ersten Auflage danken, den Lektorinnen Rita Fernando und Megan Laddusaw der zweiten Auflage, den Reviewern der ersten Auflage – Hans Donker, Darren Day und Edgar Ter Danielyan –, den Reviewern der zweiten Auflage – Lee Atchison, Karan Dwivedi und Akhil Behl – sowie dem Rest des wunderbaren Teams von O'Reilly, die mich alle beim Entstehen dieses Buchs geleitet und begleitet haben.
Schließlich möchte ich noch all meinen Freunden, meiner Familie, meinen Kollegen und Mentorinnen der letzten Jahre danken, die mir Fragen beantwortet, an Ideen herumgedacht, schlechten Witzen gelauscht, über meine Fehler gelacht und mir tatsächlich das meiste von dem beigebracht haben, was Sie in diesem Buch finden.
KAPITEL 1
Prinzipien und Konzepte
Ja, dies ist ein praxisorientierter Ratgeber, aber wir müssen ein paar Sicherheitsprinzipien und -konzepte grob vorstellen, die für die Cloud relevant sind, bevor wir uns in die Praxis stürzen können. Sind Sie ein erfahrener Security Professional, haben aber noch keine Cloud-Erfahrung, müssen Sie die folgenden Seiten bis »Das Cloud Shared Responsibility Model« auf Seite 22 eventuell nur überfliegen.
Ich behandle diese Prinzipien und Konzepte deshalb zuerst, weil sie im Rest des Buchs implizit genutzt werden, wenn wir uns mit dem Designen und Implementieren von Schutzmaßnahmen zum Stoppen von Angriffen beschäftigen. Konzeptionelle Lücken und Missverständnisse können im Sicherheitsumfeld zu einer Reihe von Problemen führen. Beispiele dafür sind:
Sind Sie mit Least Privilege nicht vertraut, haben Sie möglicherweise das Autorisieren für Cloud-Services gut verstanden, Sie weisen aber dennoch Personen oder Automatismen in Ihrem Cloud-Account oder für eine Cloud-Datenbank mit heiklen Informationen zu viele Berechtigungen zu.
Sind Sie mit Defense in Depth nicht vertraut, scheinen mehrere Schichten aus Authentifizierung, Netzwerkzugriffskontrolle und Verschlüsselung nicht sinnvoll zu sein.
Wissen Sie nicht genug über Threat Modeling – die wahrscheinlichen Beweggründe von Angreifern und die Trust Boundaries des von Ihnen entworfenen Systems –, investieren Sie vermutlich zu viel Zeit und Aufwand in den Schutz der falschen Dinge.
Verstehen Sie die Delivery-Modelle für Cloud-Services und das Shared Responsibility Model nicht, machen Sie sich eventuell Gedanken über Risiken, die in der Verantwortung Ihres Cloud-Providers liegen, während Sie gleichzeitig Risiken übersehen, um die Sie sich kümmern müssen.
Wissen Sie wenig über Risikomanagement, wenden Sie eventuell zu viel Zeit und Aufwand für geringe Risiken auf, statt sich um die hohen Risiken zu kümmern.
Ich werde die grundlegenden Informationen nicht allzu sehr auswalzen, sodass wir bald zu den Cloud-Schutzmaßnahmen kommen können.
Least Privilege
Das Prinzip des Least Privilege (Prinzip der geringsten Berechtigung) besagt einfach, dass Personen oder Automationstools nur auf das Zugriff haben sollten, was sie für ihre Aufgabe benötigen – und nicht auf mehr. Man vergisst dabei leicht den Automationsteil – so sollte beispielsweise eine Komponente, die eine Datenbank nutzt, keine Credentials verwenden, die es erlauben, schreibend auf die Datenbank zuzugreifen, wenn gar kein Schreibzugriff erforderlich ist.
Eine praktische Anwendung des Least Privilege führt oft dazu, dass Ihre Zugriffsrichtlinien Deny by Default sind. User erhalten also standardmäßig gar keine (oder nur sehr wenige) Berechtigungen und müssen den Anforderungs- und Genehmigungsprozess für jede Berechtigung durchlaufen, die sie benötigen.
Bei Cloud-Umgebungen werden einige aus Ihrem Administrationsteam Zugriff auf die Cloud-Konsole benötigen – eine Webseite, über die Sie Cloud Assets (wie zum Beispiel virtuelle Maschinen) erstellen, anpassen und löschen können. Bei vielen Providern hat jeder, der auf Ihre Cloud-Konsole zugreifen kann, standardmäßig gottgleiche Berechtigungen für alles, was von diesem Cloud-Provider gemanagt wird. Dazu gehört eventuell die Berechtigung, Daten überall aus der Cloud-Umgebung zu lesen, zu verändern oder zu löschen – egal welche Sicherheitsmechanismen durch die Betriebssysteme der provisionierten Systeme aktiv sind. Daher müssen Sie den Zugriff auf die Cloud-Konsole und die Berechtigungen darin sehr stark beschränken – so, wie Sie den physischen Zugang zu einem Data Center in On-Premises-Umgebungen steuern – und aufzeichnen, was die User dort so treiben.
Defense in Depth
Viele der Schutzmaßnahmen in diesem Buch würden – perfekt implementiert – andere Schutzmaßnahmen überflüssig machen. Defense in Depth (Verteidigung in der Tiefe) ist das Eingeständnis, dass nahezu jede Schutzmaßnahme fehlschlagen kann – entweder weil ein Angreifer oder eine Angreiferin ausreichend engagiert und kenntnisreich ist oder weil es ein Problem mit der Art und Weise gibt, wie eine Schutzmaßnahme implementiert ist. Mit Defense in Depth schaffen Sie mehrere Schichten einander überlappender Schutzmaßnahmen. Schlägt eine fehl, kann die dahinterliegende den Angriff immer noch abwehren.
Bei Defense in Depth können Sie natürlich sehr ins Extreme gehen, weshalb es wichtig ist, die Bedrohungen zu verstehen, denen Sie sich wahrscheinlich gegenübersehen. Aber als Faustregel sollten Sie auf eine beliebige Schutzmaßnahme zeigen können und sich fragen: »Was passiert, wenn das nicht funktioniert?« Ist die Antwort inakzeptabel, haben Sie vermutlich keine ausreichende Defense in Depth. Sie kann auch dann unzureichend sein, wenn ein einzelner Fehler mehrere Ihrer Schutzmaßnahmen unwirksam machen kann, wie zum Beispiel ein Inventory-Problem, durch das mehrere Tools ein Problem übersehen.
Zero Trust
Viele Produkte und Services behaupten heutzutage von sich, Zero Trust zu nutzen oder die Prinzipien zu unterstützen. Der Name verwirrt, weil Zero Trust nicht bedeutet, gar kein Vertrauen zu haben, und die Verwirrung wird noch größer, weil der Begriff für sehr unterschiedliche Marketingzwecke eingesetzt wird. Es gibt viele verschieden Definitionen und Ideen, was mit Zero Trust gemeint ist.
Wir müssen uns wohl mit diesem Begriff zufriedengeben, auch wenn »Zero Trust« eher »Zero Implicit Trust« oder »Zero Assumed Trust Without a Good Reason«1 heißen sollte. Zentrales Prinzip ist, dass sich ein User oder ein anderes System Vertrauen verdienen sollte, statt es einfach nur zu bekommen − nur weil der User Sie über das Netzwerk erreichen kann, ein Firmen-Device nutzt oder irgendein anderes Kriterium erfüllt, das Sie nicht gut im Griff haben.
Die Implementierung von Zero Trust ist stark abhängig davon, ob Sie Devices, Netzwerkverbindungen oder etwas anderem vertrauen. Gemeinsam ist allen, dass Verschlüsselung und Authentifizierung für alle Verbindungen erforderlich sind – selbst für solche, die in eigentlich vertrauenswürdigen Netzwerken beginnen und enden. Das war schon immer eine gute Idee, aber in Cloud-Umgebungen ist dies noch viel wichtiger, weil die Grenzen viel weniger strikt entworfen sind und der Weg ins Internet einfach ist.
Eine weitere gängige Implementierung von Zero-Trust-Prinzipien ist, den Netzwerkzugriff von Usern auf die Anwendungen zu begrenzen, die diese benötigen, wodurch das implizite Vertrauen infrage gestellt wird, dass sich alle User mit allen Anwendungen verbinden können sollten, auch wenn sie sich dort nicht anmelden können. Wenn Sie das Gefühl haben, dass das doch stark nach Least Privilege und Defense in Depth klingt, haben Sie recht. Es gibt eine deutliche Überlappung der Zero-Trust-Prinzipien mit einigen anderen Prinzipien aus diesem Kapitel.
Ein drittes Beispiel für Zero Trust ist der Einsatz einer Multifaktor-Authentifizierung für User, wobei regelmäßig (oder bei riskanteren Transaktionen) eine Re-Authentifizierung erforderlich ist. In diesem Fall stellen wir das implizite Vertrauen infrage, dass jeder, der ein Passwort für einen Account hat oder eine bestimmte Session für eine Anwendung steuert, der gewünschte User ist.
Orientieren Sie sich an Zero-Trust-Prinzipien, sollten Sie nur dann einer Interaktion vertrauen, wenn Sie ziemlich gute Belege dafür haben, dass das Vertrauen gerechtfertigt ist – wie zum Beispiel aufgrund einer starken Authentifizierung oder Autorisierung oder einer korrekten Konfiguration. Diese Belege sollten entweder von etwas kommen, das Sie direkt kontrollieren (wie zum Beispiel von Ihrem eigenen Authentifizierungssystem oder Ihrem Device-Management-System), oder von einer dritten Seite, bei der Sie explizit überprüft haben, dass diese für Sie Vertrauensentscheidungen treffen kann. Wie bei den anderen Prinzipien in diesem Kapitel kann Zero Trust disruptiv für die User Experience sein, wenn Sie es ins Extreme treiben.
Threat Actors, Diagramme und Trust Boundaries
Es gibt unterschiedliche Vorgehensweisen, über Ihre Risiken nachzudenken, aber ich bevorzuge im Allgemeinen einen Asset-orientierten Ansatz. Dabei konzentrieren Sie sich zuerst darauf, was Sie zu beschützen haben – ich werde mich deshalb in Kapitel 2 auch zuerst um Data Assets kümmern.
Es ist zudem nicht verkehrt, im Hinterkopf zu haben, wer Ihnen am wahrscheinlichsten Probleme bereiten wird. In der Sprache der Cybersicherheit sind das Ihre potenziellen »Bedrohungsakteure« oder »Threat Actors«. Beispielsweise müssen Sie sich eventuell nicht vor einem finanziell gut ausgestatteten staatlichen Angreifer schützen, sind aber möglicherweise in einer Branche tätig, in der Cyberkriminelle Geld machen können, indem sie Ihre Daten stehlen, oder in der ein »Hacktivist« Ihre Website aus politischen oder anderen Gründen übernehmen will. Behalten Sie diese Leute im Hinterkopf, wenn Sie all Ihre Verteidigungslinien planen.
Es gibt zu Bedrohungsakteuren sowie deren Motivation und deren Methoden eine ganze Menge an Informationen und Diskussionen.2 In diesem Buch werden wir vier Haupttypen von Bedrohungsakteuren berücksichtigen, um die Sie sich Gedanken machen müssen:
Organisiertes Verbrechen oder unabhängige Kriminelle, die vor allem daran interessiert sind, Geld zu verdienen.
Hacktivisten, die vor allem ein Interesse daran haben, Sie zu diskreditieren, indem gestohlene Daten veröffentlicht werden, Vandalismus betrieben oder Ihre Geschäftstätigkeit unterbrochen wird.
Angreifer von innen, die meist daran interessiert sind, Sie zu diskreditieren oder Geld zu bekommen.
Staatliche Akteure, die Geheimnisse stehlen oder Ihre Geschäftstätigkeit unterbrechen wollen, um die politischen Ziele einer fremden Regierung zu befördern.
Sie können sich eine Technik aus der Welt des UX-Designs ausborgen: Stellen Sie sich ein Mitglied jeder dieser Gruppen vor, geben Sie ihm einen Namen, schreiben Sie ein wenig über diese »Persona« auf eine Karte und hängen Sie diese in Sichtweite auf, wenn Sie Ihre Verteidigung planen.
Sie müssen sich außerdem überlegen, was in Ihrer Anwendung womit kommunizieren können muss. Am einfachsten ist es, sich dafür ein Bild zu zeichnen, um sich anhand dessen zu überlegen, wo eventuell Schwachpunkte liegen könnten. Es gibt ganze Bücher zu diesem Thema,3 aber Sie müssen kein Experte und auch keine Expertin sein, um etwas zu erstellen, das Sie bei Ihren Entscheidungen unterstützt. Agieren Sie allerdings in einer Hochrisikoumgebung, sollten Sie vermutlich eher formale Diagramme mit einem passenden Tool erstellen, als einfach nur ein paar Strichmännchen zu malen.
Auch wenn es viele unterschiedliche Anwendungsarchitekturen gibt, werde ich für die hier genutzte Beispielanwendung ein Three-Tier-Design nutzen. Für ein sehr einfaches Anwendungskomponentendiagramm empfehle ich:
1.Zeichnen Sie ein Strichmännchen und nennen Sie es »User«. Zeichnen Sie ein weiteres Strichmännchen und geben Sie ihm den Namen »Administrator« (siehe
Abbildung 1-1
). Später stellen Sie vielleicht fest, dass Sie mehrere Arten von Usern sowie Administratorinnen und Administratoren oder auch noch andere Rollen haben, aber das ist erst mal ein guter Ausgangspunkt.
Abbildung 1-1: Die Rollen User und Administrator
2.Zeichnen Sie eine Box für die erste Komponente, mit der der User kommuniziert (zum Beispiel die Webserver), zeichnen Sie eine Linie vom User zu dieser ersten Komponente und schreiben Sie daran, wie der User mit dieser Komponente kommuniziert (siehe
Abbildung 1-2
). Beachten Sie, dass die Komponente eine Serverless Function, ein Container, eine virtuelle Maschine oder etwas anderes sein kann. Sie lässt jeden mit sich reden, daher wird sie vermutlich auch als Erstes angegriffen werden. Wir wollen wirklich nicht, dass die anderen Komponenten dieser Komponente mehr trauen als notwendig.
Abbildung 1-2: Erste Komponente
3.Zeichnen Sie weitere Boxen hinter der ersten für alle weiteren Komponenten, mit denen das erste System reden muss, und ziehen Sie Verbindungslinien (siehe
Abbildung 1-3
). Immer dann, wenn Sie zu einem System kommen, das tatsächlich Daten speichert, zeichnen Sie ein kleines Symbol (ich nutze einen Zylinder) daneben und merken an, welche Daten dort beheimatet sind. Fahren Sie fort, bis Ihnen keine weiteren Boxen mehr für Ihre Anwendung einfallen.
Abbildung 1-3: Weitere Komponenten
4.Nun zeichnen Sie ein, wie der Administrator (und alle weiteren von Ihnen definierten Rollen) auf die Anwendung zugreift. Beachten Sie, dass Administratoren viele unterschiedliche Möglichkeiten haben können, mit dieser Anwendung zu kommunizieren – zum Beispiel über das Portal oder die APIs des Cloud-Providers, über das Betriebssystem oder auf einem Weg, der dem der User ähnelt (siehe
Abbildung 1-4
).
Abbildung 1-4: Zugriff durch den Administrator
5.Zeichnen Sie Trust Boundaries als gestrichelte Linien um die Boxen (siehe
Abbildung 1-5
). Eine Trust Boundary besagt, dass alles innerhalb dieser Grenze zumindest zu einem gewissen Grad auf die Motive von allem anderen innerhalb der Grenze vertrauen kann, während alles außerhalb der Grenze überprüft werden muss, bevor man ihm vertraut. Die Idee dabei: Schafft es ein Angriff, auf ein Element innerhalb der Trust Boundary zuzugreifen, ist davon auszugehen, dass schließlich die vollständige Kontrolle über alles darin erlangt wird. Daher soll das Überwinden jeder Trust Boundary aufwendig sein. Beachten Sie, dass ich innerhalb der Trust Boundary mehrere Webserver eingezeichnet habe – es ist also in Ordnung, wenn diese Webserver innerhalb derselben Trust Boundary einander vertrauen, und wenn jemand Zugriff auf einen erhält, hat er letztendlich auch Zugriff auf alle anderen. Oder umgekehrt: Ist einer dieser Webserver kompromittiert, entsteht auch nicht mehr Schaden, wenn alle kompromittiert sind.
In diesem Rahmen führen die Zero-Trust-Prinzipien dazu, dass wir diese Trust Boundaries so eng wie (sinnvoll) nötig ziehen – zum Beispiel um eine einzelne Komponente, die hier ein einzelner Server sein kann, oder ein Cluster mit Servern, die alle dieselben Daten nutzen und denselben Zweck erfüllen.
Abbildung 1-5: Trust Boundaries um Komponenten
6.Bis zu einem gewissen Grad vertrauen wir dem Gesamtsystem mehr als dem Rest der Welt. Ziehen Sie daher noch eine weitere gestrichelte Linie um alle Boxen herum, den Administrator eingeschlossen, aber ohne den User (siehe
Abbildung 1-6
). Haben Sie mehrere Admins, zum Beispiel einen Webserver-Admin und einen Datenbank-Admin, können sich diese innerhalb unterschiedlicher Trust Boundaries befinden. Die Tatsache, dass es Trust Boundaries innerhalb von anderen Trust Boundaries gibt, zeigt, dass es auch unterschiedliche Vertrauensstufen gibt. Die Server akzeptieren hier vielleicht beispielsweise Netzwerkzugriffe von Servern in anderen Trust Boundaries innerhalb der Anwendung, aber sie überprüfen dabei deren Identitäten. Andererseits nehmen sie eventuell keine Verbindungen von anderen Systemen an, die sich außerhalb der Trust Boundary für das Gesamtsystem befinden.
Abbildung 1-6: Trust Boundary für die Gesamtanwendung
Wir werden dieses Diagramm einer Beispielanwendung im Rest des Buchs nutzen, wenn es um das Shared Responsibility Model, Asset Inventories, Schutzmaßnahmen und das Monitoring geht. Bisher sehen Sie hier noch keine Cloud-spezifischen Schutzmechanismen, aber das wird sich in den folgenden Kapiteln ändern. Schauen Sie sich jede Stelle an, an der eine Linie eine Trust Boundary kreuzt. Das sind die Stellen, auf die wir uns beim Absichern als Erstes konzentrieren müssen!
Delivery-Modelle für Cloud-Services
Es gibt ein ungeschriebenes Gesetz, nach dem kein Buch über Cloud Computing vollständig ist, ohne dass dort ein Überblick über Infrastructure as a Service (IaaS), Platform as a Service (PaaS) und Software as a Service (SaaS) gegeben wird. Statt hier den Standardtext abzuspulen, möchte ich nur kurz sagen, dass Sie mit IaaS-Services üblicherweise virtuelle Computer, Storage und Netzwerke erstellen können. PaaS-Services laufen meist auf einer höheren Ebene (wie Datenbanken), und Sie können damit Anwendungen bauen. SaaS-Services sind schließlich Applikationen, die von Endanwendern und -anwenderinnen genutzt werden. Es gibt natürlich ausführlichere Definitionen und Unterteilungen dieser Kategorien, aber im Kern beschreiben sie es schon sehr gut.
Diese Servicemodelle sind nur für ein allgemeines Verständnis der Konzepte nützlich – insbesondere löst sich die Grenze zwischen IaaS und PaaS immer weiter auf. Ist ein Service für ein Content Delivery Network, der Informationen für Sie weltweit im Internet cacht, um sie nahe bei den Usern anbieten zu können, ein PaaS oder ein IaaS? Aber eigentlich tut das nichts zur Sache. Wichtig ist, dass Sie verstehen, was vom Service angeboten wird (und was nicht!), nicht aber, in welche Kategorie er gehört.
Das Cloud Shared Responsibility Model
Die grundlegendste Sicherheitsfrage, die Sie beantworten müssen, ist: »Für welche Sicherheitsaspekte bin ich verantwortlich?« Das wird in einer On-Premises-Umgebung oft implizit beantwortet. Die Entwicklungsorganisation ist für Coding-Fehler verantwortlich und die Operations-Organisation (IT) für alles andere. Viele Organisationen nutzen heutzutage ein DevOps-Modell, bei dem diese Verantwortlichkeiten geteilt werden und Teamgrenzen zwischen Entwicklung und Operations verschwimmen oder gar nicht mehr existieren. Unabhängig von der Art der Organisation befinden sich aber so gut wie alle Sicherheitsverantwortlichkeiten innerhalb des Unternehmens.
Eine der vielleicht auffälligsten Änderungen beim Wechsel von einer On-Premises-Umgebung zu einer Cloud-Umgebung ist ein komplizierteres Shared Responsibility Model in Bezug auf die Sicherheit. In einer On-Premises-Umgebung gab es vielleicht eine interne Vereinbarung oder einen Vertrag mit der IT oder mit einer anderen Abteilung, die Ihre Server betreibt. In vielen Fällen waren es die IT-Business-User gewohnt, die Anforderungen oder den Code an einen internen Provider zu übergeben und alles für sich erledigen zu lassen – insbesondere im Bereich der Sicherheit.
Selbst wenn Sie schon eine Weile in einer Cloud-Umgebung unterwegs waren, haben Sie sich vielleicht noch keine Gedanken darüber gemacht, wo die Verantwortung des Cloud-Providers endet und wo Ihre beginnt. Diese Demarkationslinie unterscheidet sich je nach Art der Cloud-Services, die Sie erworben haben. So gut wie alle Cloud-Provider beschreiben das irgendwo in ihrer Dokumentation und in Trainingsmaterialien, aber am besten lässt es sich mit der Analogie beschreiben, eine Pizza zu essen.
Gehen wir bei »Pizza as a Service«4 davon aus, dass Sie Hunger auf Pizza haben. Da gibt es so viele Möglichkeiten! Sie könnten einfach selbst eine Pizza zu Hause zubereiten, aber dafür bräuchten Sie eine Reihe von Zutaten, und es würde eine Weile dauern. Sie könnten zum Supermarkt gehen und sich eine Tiefkühlpizza holen – dafür bräuchten Sie nur einen Ofen und einen Platz, an dem Sie die Pizza essen können. Sie könnten Ihren Lieblings-Pizza-Lieferservice anrufen. Oder Sie könnten in ein Restaurant gehen und eine Pizza bestellen. Zeichnen wir ein Diagramm der unterschiedlichen Komponenten und Verantwortlichkeiten, erhalten wir so etwas wie Abbildung 1-7.
Abbildung 1-7: Pizza as a Service
Die klassische On-Premises-Welt entspricht dem eigenhändigen Zubereiten einer Pizza zu Hause. Sie müssen viele verschiedene Komponenten kaufen und sie selbst zusammenführen, aber Sie haben volle Flexibilität. Sardellen und Zimt auf Weizenkruste? Wenn Sie das vertragen – bitte schön!
Nutzen Sie Infrastructure as a Service, ist die Grundlage schon für Sie gelegt. Sie können die Pizza nach Wunsch backen sowie Salat und Getränke dazu reichen, aber Sie sind dafür auch zuständig. Ein Schritt weiter geht Platform as a Service, wo Ihnen weitere Entscheidungen abgenommen werden, unter anderem, wie die Pizza gebacken wird. (Wie schon erwähnt, kann es manchmal schwierig sein, einen Service als IaaS oder PaaS zu klassifizieren, und oft wächst beides zusammen. Die genaue Klassifikation ist unwichtig – wichtig ist, dass Sie verstehen, was der Service bietet und wie die Verantwortlichkeiten aussehen.)
Kommen Sie zu Software as a Service (vergleichbar mit dem Essen im Restaurant in Abbildung 1-7), sieht es aus, als würde alles für Sie erledigt. Das stimmt aber nicht. Sie sind immer noch dafür verantwortlich, sicher zu essen, und das Restaurant kann nichts dafür, wenn Sie sich verschlucken. In der SaaS-Welt läuft es vor allem darauf hinaus, die Zugriffskontrolle ordentlich zu managen.
Zeichnen wir das Diagramm neu, dieses Mal aber mit Technologie statt mit Pizza, sieht es eher wie in Abbildung 1-8 aus.
Abbildung 1-8: Cloud Shared Responsibility Model
Die Realität des Cloud Computing ist leider etwas komplizierter als das Essen einer Pizza, daher gibt es Graubereiche. Ganz unten im Diagramm sind die Dinge konkreter. Der Cloud-Provider ist vollständig verantwortlich für die Sicherheit der physischen Infrastruktur – wozu oft Schutzmaßnahmen gehören, die weit über das hinausgehen, was viele Firmen vernünftigerweise bei sich umsetzen können, wie zum Beispiel eine biometrische Zugangskontrolle mit Vereinzelungsanlagen, Sicherheitspersonal und Barrieren, um unbefugte Personen aus den Räumlichkeiten fernzuhalten.
Bietet der Provider virtualisierte Umgebungen an, ist dieser für die entsprechenden Schutzmaßnahmen verantwortlich, die dafür sorgen, dass Ihre virtuellen Umgebungen von anderen virtuellen Umgebungen getrennt sind. Als die Spectre- und Meltdown-Sicherheitslücken Anfang 2018 bekannt wurden, war einer der potenziellen Effekte, dass User in virtuellen Maschinen den Speicher einer anderen virtuellen Maschine auf dem gleichen physischen Computer auslesen konnten. Bei IaaS-Kunden war für das Beheben dieser Lücke der Cloud-Provider zuständig – Amazon, Microsoft, Google und IBM mussten beispielsweise alle ihre Hypervisoren aktualisieren –, aber das Beheben der Sicherheitslücke im Betriebssystem lag in der Verantwortung der Kunden.
Netzwerksicherheit wird im IaaS-Abschnitt von Abbildung 1-8 als gemeinsame Verantwortung dargestellt. Warum? In einem Diagramm lässt sich das nicht gut zeigen, aber es gibt diverse Netzwerklayer, und die Verantwortung für jeden davon liegt bei unterschiedlichen Beteiligten. Der Provider hat sein eigenes Netzwerk, das in seinen Verantwortungsbereich fällt, aber meist sitzt darauf noch ein virtuelles Netzwerk (zum Beispiel bieten manche Cloud-Provider eine Virtual Private Cloud), und es ist Aufgabe des Kunden, dieses in sinnvolle Sicherheitszonen zu unterteilen und die passenden Regeln für den Zugriff dazwischen aufzusetzen. Viele Implementierungen nutzen außerdem Overlay Networks, Firewalls und Transportverschlüsselung, die alle in der Verantwortung des Kunden liegt. Wir gehen darauf im Detail in Kapitel 6 ein.
Bei der Sicherheit des Betriebssystems ist es im Allgemeinen recht klar: Nutzen Sie IaaS, ist es Ihre Verantwortung, kaufen Sie Plattform- oder Softwareservices, muss sich der Provider darum kümmern. In diesem Fall haben Sie normalerweise auch gar keinen Zugriff auf das zugrunde liegende Betriebssystem. (Als Faustregel kann gelten: Haben Sie die Möglichkeit, es kaputt zu machen, sind Sie auch dafür verantwortlich, es abzusichern.)
Middleware ist in diesem Kontext ein generischer Name für Software wie Datenbanken, Anwendungsserver oder Queueing-Systeme. Sie befindet sich in der Mitte zwischen dem Betriebssystem und der Anwendung – nicht direkt von den Endusern genutzt, aber im Einsatz, um Lösungen für Enduser zu entwickeln. Nutzen Sie ein PaaS, ist die Sicherheit der Middleware oft eine gemeinsame Verantwortlichkeit – der Provider hält vielleicht die Software aktuell (oder macht das Updaten durch Sie sehr einfach), aber bei Ihnen verbleibt die Verantwortung dafür, sicherheitsrelevante Einstellungen wie zum Beispiel eine Verschlüsselung vorzunehmen.
Die Anwendungsschicht ist die, die vom Enduser tatsächlich genutzt wird. Verwenden Sie SaaS, liegen Sicherheitslücken auf dieser Ebene (wie zum Beispiel Cross-Site Scripting oder SQL Injections) in der Verantwortung des Providers, aber wenn Sie dieses Buch lesen, werden Sie vermutlich nicht einfach die SaaS von jemand anderem nutzen. Selbst wenn alle anderen Layer absolut wasserdicht sind, kann eine Lücke in der Anwendungsschicht leicht all Ihre Informationen exponieren.
Die Sicherheit des Datenzugriffs ist schließlich fast immer in Ihrer Verantwortung als Kunde. Teilen Sie Ihrem Cloud-Provider fälschlicherweise mit, den Zugriff auf bestimmte Daten freizugeben, wie zum Beispiel durch das Zuweisen falscher Berechtigungen für den Object Storage, die Middleware oder SaaS, kann dieser im Allgemeinen nicht viel tun außer zu versuchen, das Problem zu erkennen und Sie zu warnen.
Die Grundursache für viele Sicherheitsvorfälle ist die Annahme, dass sich der Cloud-Provider um etwas kümmert, und dann die Erkenntnis, dass sich niemand darum kümmert. Viele reale Beispiele von Sicherheitsvorfällen zeigen ein schlechtes Verständnis des Shared Responsibility Model bei offenen Amazon Simple Storage Service (Amazon S3) Buckets. S3-Storage ist natürlich sicher und verschlüsselt, aber das hilft nicht, wenn Sie Ihre Zugriffskontrolle falsch eingerichtet haben. Dieses Missverständnis hat immer wieder den Verlust vieler Daten verursacht:
Daten von 198 Millionen US-Wählerinnen und -Wählern
automatisches Tracken von Firmendaten
Datensätze von Mobilfunkkunden
über drei Millionen Datensätze einer demografischen Umfrage
Bonitätsdaten von über 50.000 indischen Bürgerinnen und Bürgern
Noten und persönliche Informationen von über 100.000 Schülern und Schülerinnen
Tausende Stunden von Audio- und Videoaufzeichnungen privater Unterhaltungen
Es gibt noch viele weitere Beispiele. Auch wenn seitdem Fortschritte gemacht wurden, wird das Shared Responsibility Model immer noch oft missverstanden. Viele Entscheidungsträger aus der IT glauben weiterhin, dass Provider nicht nur dafür verantwortlich sind, die angebotenen Cloud-Services abzusichern, sondern auch die Kundenanwendungen und -daten in der Cloud. Lesen Sie sich den Vertrag mit Ihrem Cloud-Provider durch, werden Sie feststellen, dass das nicht der Fall ist!
Risikomanagement
Risikomanagement ist ein umfangreiches Thema, über das schon ganze Bücher geschrieben wurden. Wenn Sie wirklich an einer Vertiefung interessiert sind, empfehle ich The Failure of Risk Management: Why It’s Broken and How to Fix It von Douglas W. Hubbard (Wiley 2020) und die NIST Special Publication 800-30 Rev 1 (https://oreil.ly/fj5Fh). Kurz gesagt, sind Menschen wirklich schlecht darin, Risiken abzuschätzen und sich zu überlegen, was man gegen sie tun kann. Dieser Abschnitt soll Ihnen wirklich nur die allernötigsten Grundlagen vermitteln, um die Risiken von Sicherheitsvorfällen und Datenpannen managen zu können.
Auch wenn die Gefahr besteht, dass ich das Offensichtliche sage: Ein Risiko ist etwas Schlechtes, das passieren könnte. In den meisten Risikomanagementsystemen basiert das Risikolevel auf einer Kombination aus der Wahrscheinlichkeit des Eintritts und der Schwere des Vorfalls (den Auswirkungen). So wäre das Risiko von etwas, das sehr wahrscheinlich eintritt (jemand rät Ihr Passwort »1234«) und dessen Ergebnis ausgesprochen schlecht wäre (Sie verlieren alle Daten Ihrer Kunden und zahlen hohe Strafen), sehr hoch. Etwas, dessen Eintreten sehr unwahrscheinlich ist (ein Asteroid löscht zwei Data Center in unterschiedlichen Regionen gleichzeitig aus), das aber trotzdem sehr schlecht wäre, wenn es geschehen würde (Sie können Ihre Firma zumachen), hätte vielleicht nur ein niedriges Risiko – abhängig vom System, das Sie zum Berechnen nutzen.5
In diesem Buch werde ich über unbekannte Risiken (bei denen wir keine ausreichenden Informationen haben, um zu wissen, wie groß die Wahrscheinlichkeit und die Auswirkungen sein werden) und bekannte Risiken (bei denen wir zumindest wissen, womit wir es zu tun haben) sprechen. Haben Sie zumindest eine Idee von den bekannten Risiken, können Sie mit ihnen eines von vier Dingen tun:
Das Risiko vermeiden. Bei der Informationssicherheit bedeutet das im Allgemeinen, dass Sie das System abschalten – kein Risiko mehr, aber auch keine Vorteile mehr aus dem Betreiben des Systems.
Das Risiko abschwächen. Es ist immer noch da, aber Sie treffen zusätzliche Maßnahmen, um die Wahrscheinlichkeit des Eintretens oder die Auswirkungen zu verringern. So können Sie beispielsweise weniger kritische Daten abspeichern, sodass im Fall eines Datenlecks die Auswirkungen nicht so schlimm sind.
Das Risiko transferieren. Sie bezahlen jemand anderen dafür, dass er sich um die Dinge kümmert, sodass das Risiko dessen Problem ist. Bei der Cloud geschieht das häufig – Sie übertragen viele der Risiken beim Managen der unteren Ebenen des Systems an den Cloud-Provider.
Das Risiko akzeptieren. Nachdem Sie sich das gesamte Risikolevel und die Vorteile des Betreibens des Systems angeschaut haben, entscheiden Sie sich vielleicht dafür, schriftlich festzuhalten, dass das Risiko existiert. Lassen Sie dann all Ihre Stakeholder bestätigen, dass es ein Risiko ist, und machen Sie weiter.
Alle diese Aktionen können vernünftig sein. Unvernünftig ist dagegen, entweder gar nicht zu wissen, worin Ihre Risiken bestehen, oder dies durchaus zu wissen, die Konsequenzen daraus aber nicht abzuwägen oder sich mit Ihren Stakeholdern nicht abzustimmen. Sie sollten zumindest irgendwo eine Liste mit den Details der Ihnen bekannten Risiken, den dagegen ergriffenen Maßnahmen und den erforderlichen Genehmigungen haben.
Zusammenfassung
Auch wenn es in der Praxis oft keine perfekten Antworten gibt, wird Ihnen ein Verständnis der grundlegenden Konzepte dabei helfen, beim Absichern Ihrer Cloud-Umgebungen bessere Entscheidungen zu treffen.
Least Privilege erkennt im Prinzip einfach an, dass es risikoreich ist, jedem und jeder viele Rechte zu geben – und Sie sollten schlicht nicht mehr Risiken eingehen, als notwendig sind. Es ist natürlich eine Kunst, weil manchmal zwischen Risiko und Produktivität abgewogen werden muss, aber das allgemeine Prinzip ist gut: Gib nur die minimalen Berechtigungen, die notwendig sind. Das wird beim Automatisieren oft übersehen, ist dort aber unbestritten noch wichtiger, weil viele reale Angriffe darauf aufbauen, ein System oder eine Automatisierung zu unerwarteten Aktionen zu verleiten.
Defense in Depth ist das Eingeständnis, dass wir nicht perfekt sind und dass die Systeme, die wir designen, auch nicht perfekt sein werden. Es ist zudem ein zustimmender Gruß an die grundlegenden Gesetze der Wahrscheinlichkeit – haben Sie zwei unabhängige Dinge, die beide fehlschlagen müssen, damit etwas Schlimmes passiert, wird dies deutlich seltener geschehen. Müssen Sie eine Münze werfen und zweimal hintereinander Zahl bekommen, liegen Ihre Chancen nur bei 25% – im Gegensatz zu einem einzelnen Münzwurf, bei dem es 50% sind. Wir streben natürlich Schutzmaßnahmen an, die viel effektiver als ein Münzwurf sind, aber das Prinzip ist das gleiche. Haben Sie zwei überlappende, unabhängige Schutzmaßnahmen, die jeweils eine Effektivität von 95% besitzen, ist die Kombination aus beiden zu 99,75% effektiv! Dieser Effekt nimmt allerdings ab, daher sind fünf oder sechs Schichten im selben Bereich vermutlich kein sehr guter Ressourceneinsatz.
Threat Modeling ist der Prozess des Verstehens, wer vermutlich Ihr System wie angreifen wird, was die Komponenten Ihres Systems sind und wie sie zusammenarbeiten. Mit diesen Informationen können Sie Ihr System mit den Augen eines potenziellen Angreifers betrachten und versuchen, Bereiche zu erkennen, in denen sich unerwünschte Dinge tun lassen. Dann können Sie für diese Bereiche Hürden (oder formeller: »Controls« und »Mitigations«) aufbauen, um die Angriffe zu vereiteln. Im Allgemeinen befinden sich die effektivsten Orte dafür an den Trust Boundaries, wo ein Teil Ihres Systems einem anderen Teil vertrauen muss.
Wenn Sie Cloud Delivery Models verstehen, können Sie sich auf den Teil des Gesamtsystems konzentrieren, für den Sie verantwortlich sind, sodass Sie keine Zeit damit verschwenden, die Arbeit Ihres Cloud-Providers zu machen, und umgekehrt nicht davon ausgehen, dass sich dieser um Dinge kümmern wird, für die eigentlich Sie zuständig sind. Es gibt zwar standardisierte Begriffe für verschiedene Cloud Delivery Models, wie IaaS, PaaS und SaaS, aber manche Services passen einfach nicht in diese Schubladen. Sie sind aber durchaus nützlich, und es ist letztendlich am wichtigsten, zu verstehen, wo die Zuständigkeit Ihres Providers im Cloud Shared Responsibility Model endet und wo Ihre beginnt. In einer On-Premises-Welt lag die Verantwortlichkeit für die Sicherheit des gesamten Systems innerhalb einer Firma oft in den Händen einer einzelnen Organisation, während sie bei Cloud-Deployments so gut wie immer auf mindestens zwei verschiedene Unternehmen aufgeteilt ist!
Und während Menschen ziemlich gut darin sind, Risiken wie »Wird mich dieser Tiger fressen?« abzuschätzen, geht uns diese Fähigkeit in abstrakteren Situationen verloren. Risikomanagement ist eine Disziplin, die uns beim Einschätzen von Risiken und dem Finden von Lösungen dazu besser macht. Die einfachste Form des Risikomanagements ist das Abschätzen der Wahrscheinlichkeit für das Eintreten von etwas Schlimmem und der Auswirkungen, wenn es denn geschieht. Dann treffen Sie ausgehend von der Kombination aus Wahrscheinlichkeit und Auswirkungen Entscheidungen. Mit Risikomanagement können wir unser Gesamtrisiko senken, indem wir uns zuerst auf die größten Risiken konzentrieren.
Nachdem wir nun diese Konzepte und Prinzipien verinnerlicht haben, wollen wir sie einsetzen, um die Daten und anderen Assets in unseren Cloud-Umgebungen zu schützen.
Übungen
Was sind gute Beispiele für den Einsatz des Prinzips des Least Privilege? Wählen Sie alle passenden aus.
Mehrere Zugriffsebenen innerhalb einer Anwendung, bei denen User nur auf die Funktionen zugreifen können, die sie für ihre Arbeit benötigen.
Zum Anmelden sind sowohl ein Passwort als auch ein zweiter Faktor erforderlich.
Ein Inventory-Tool erhält nur lesenden und keinen schreibenden Zugriff.
Der Einsatz von
sudo
erlaubt einem User, bestimmte Befehle auszuführen.
Was sind gute Beispiele für das Prinzip der Defense in Depth? Wählen Sie alle passenden aus.
Wertvolle Daten werden verschlüsselt, und man kann sie nur dann entschlüsseln, wenn man sie auch betrachten muss.
Sehr strikte Firewall-Regeln.
Sicherstellen, dass Ihre Trust Boundaries gut definiert sind.
Multifaktor-Authentifizierung einsetzen.
Was sind die häufigsten Motive für Threat Actors? Wählen Sie alle passenden aus.
Geld stehlen.
Geheimnisse stehlen.
Ihre Geschäftstätigkeit unterbrechen.
Sie beschämen.
Welche dieser Punkte liegen immer in der Verantwortung des Cloud-Providers?
Sicherheit der physischen Infrastruktur
Netzwerksicherheit
Betriebssystemsicherheit
Datenzugriffssicherheit
Welche sind die wichtigsten Faktoren beim Einschätzen der Schwere eines Risikos? Wählen Sie die zwei passenden aus.
Die Wahrscheinlichkeit, dass ein Ereignis eintreten wird.
Die Schwere der Auswirkungen, wenn ein Ereignis eintritt.
Ob Sie das Risiko an jemand anderen übertragen können.
Ob die Aktivitäten, die das Risiko verursachen, legal oder illegal sind.
KAPITEL 2
Schutz und Management von Data Assets
Nachdem Sie nun in Kapitel 1 Informationen dazu erhalten haben, wo die Verantwortung Ihres Cloud-Providers endet und wo Ihre beginnt, besteht Ihr erster Schritt beim Absichern Ihrer Cloud-Umgebung darin, herauszufinden, wo sich Ihre Daten befinden (werden) und wie Sie sie schützen können. Es herrscht oft Verwirrung bezüglich des Begriffs »Asset Management«. Was sind genau unsere Assets, und was müssen wir tun, um sie zu managen? Die offensichtliche (und nicht hilfreiche) Antwort ist, dass Assets das sind, was Sie an Wert haben. Beginnen wir also, uns die Details anzuschauen.
In diesem Buch habe ich das Asset Management in zwei Teile aufgeteilt: Data Asset Management und Cloud Asset Management. Data Assets sind die wichtigen Informationen, die Sie haben, wie zum Beispiel Namen und Adressen von Kunden, Kreditkarteninformationen, Bankkonteninformationen oder Credentials für den Zugriff auf solche Daten. Cloud Assets sind die Dinge, die Sie haben, um Ihre Daten abzuspeichern und zu verarbeiten – Rechenressourcen wie Server oder Container, Storage wie Object Stores oder Block Storage und Plattforminstanzen wie Datenbanken oder Queues. Das Managen dieser Assets wird im nächsten Kapitel behandelt. Es ist zwar prinzipiell egal, ob Sie mit Data Assets oder Cloud Assets beginnen, da Sie sowieso immer wieder hin- und herspringen müssen, um das ganze Bild sehen zu können, aber ich finde es einfacher, mit Data Assets zu beginnen.
Die Theorie des Managens von Data Assets in der Cloud unterscheidet sich nicht von der On-Premises-Welt, aber in der Praxis gibt es einige Cloud-Technologien, die helfen können.
Identifizieren und Klassifizieren von Daten
Haben Sie wie im vorherigen Kapitel ein Diagramm und ein Threat Model zumindest auf einem Schmierzettel erstellt, haben Sie eine grobe Vorstellung davon, was Ihre wichtigen Daten sind, um welche Threat Actors Sie sich sorgen müssen und worauf diese aus sein könnten. Schauen wir uns unterschiedliche Wege an, wie Threat Actors Ihre Daten angreifen könnten.
Eines der beliebteren Modelle zur Informationssicherheit ist die CIA Triade: Vertraulichkeit (Confidentiality), Integrität (Integrity) und Verfügbarkeit (Availability). Ein Threat Actor, der versucht, die Vertraulichkeit Ihrer Daten zu verletzen, will sie stehlen – meist, um sie zu verkaufen oder Sie zu blamieren. Ein Threat Actor, der versucht, Ihre Datenintegrität zu stören, will Ihre Daten beeinflussen, zum Beispiel einen Kontostand verändern. (Das kann sogar effektiv sein, wenn beim Angriff keine Daten gelesen werden können – ich würde mich beispielsweise freuen, den gleichen Kontostand von Bill Gates zu haben, auch wenn ich den Betrag gar nicht kenne.) Ein Threat Actor, der versucht, Ihre Datenverfügbarkeit zu beeinflussen, will die Daten aus Spaß an der Freude oder für den Profit offline nehmen oder sie mit Ransomware verschlüsseln.1
Die meisten von uns haben nur begrenzte Ressourcen und müssen bei ihrem Vorgehen Prioritäten setzen.2 Ein System zur Klassifikation von Daten kann dabei helfen, aber widerstehen Sie dem Drang, es komplizierter als absolut notwendig zu machen.
Beispiele für Stufen der Datenklassifikation
Jede Organisation ist anders, aber die folgenden Regeln bilden einen guten und einfachen Ausgangspunkt für das Einschätzen des Werts Ihrer Daten und damit des Risikos, dass unbefugt auf sie zugegriffen wird:
Niedrig oder öffentlich
Egal ob die Informationen in dieser Kategorie für eine Veröffentlichung gedacht sind – wenn sie öffentlich gemacht würden, wären die Auswirkungen auf die Organisation sehr gering oder vernachlässigbar. Hier ein paar Beispiele:
Die öffentlichen IP-Adressen Ihrer Server.
Anwendungs-Log-Daten ohne persönliche Daten, Secrets oder Daten von Wert für angreifende Personen.
Softwareinstallationsmaterialien ohne Secrets oder andere für Angreifer wertvollen Elemente.
Mittel oder privat
Diese Informationen sollten außerhalb der Organisation nicht ohne ein passendes Nondisclosure Agreement verfügbar sein. In viele Fällen (insbesondere in größeren Organisationen) sollte diese Art von Daten auch innerhalb der Organisation nur auf Need-to-know-Basis nutzbar sein. In vielen Unternehmen fällt der Großteil der Daten in diese Kategorie. Hier ein paar Beispiele:
Detaillierte Informationen dazu, wie Ihre Informationssysteme entworfen sind – nützliche Informationen für einen Angriff.
Informationen zu Ihren Mitarbeiterinnen und Mitarbeitern, die sich für Phishing- oder Pretexting-Angriffe nutzen lassen.
Normale Finanzinformationen, wie zum Beispiel Bestellungen oder Reisekostenerstattungen, die genutzt werden könnten, um eventuell zu schlussfolgern, dass eine Übernahme ansteht.
Hoch oder vertraulich
Diese Informationen sind für die Organisation von großer Wichtigkeit, und eine Veröffentlichung kann signifikanten Schaden anrichten. Der Zugriff auf diese Daten sollte sehr strikt gesteuert werden, und es sollte mehrere Schutzebenen geben. In manchen Organisationen wird diese Art von Daten als »Crown Juwels« bezeichnet. Hier ein paar Beispiele:
Informationen über zukünftige Strategien oder Finanzinformationen, die Wettbewerbern einen deutlichen Vorteil verschaffen würden.
Geschäftsgeheimnisse, wie zum Beispiel das Rezept für Ihren beliebten Softdrink oder für frittierte Hähnchenteile.
Geheimnisse, die als »Schlüssel zum Himmelsreich« dienen, wie zum Beispiel die Credentials für den umfassenden Zugriff auf Ihre Cloud-Infrastruktur.
Kritische Informationen, die Sie zum Aufbewahren bekommen haben, wie zum Beispiel finanzielle Daten Ihrer Kunden.
Andere Informationen, bei denen eine Datenleck Nachrichtenwert hätte.
Beachten Sie, dass Gesetze und Branchenregeln vorgeben können, wie Sie bestimmte Informationen klassifizieren. So enthält beispielsweise die Datenschutz-Grundverordnung der Europäischen Union (DSGVO) viele verschiedene Anforderungen für den Umgang mit persönlichen Daten, sodass Sie sich möglicherweise dazu entscheiden, alle persönlichen Daten als »moderates Risiko« zu klassifizieren und sie entsprechend zu schützen. Anforderungen des Payment Card Industry Data Security Standard (PCI DSS) würden wahrscheinlich vorgeben, dass Sie Daten zu Kreditkarten als »hohes Risiko« klassifizieren, wenn Sie diese in Ihrer Umgebung nutzen.
Beachten Sie auch, dass es Cloud-Services gibt, die Ihnen beim Klassifizieren und Schützen helfen können. So unterstützt Sie beispielsweise Amazon Macie (https://oreil.ly/znsxp) dabei, vertrauliche Daten in Amazon-S3-Buckets zu finden, Google Cloud Sensitive Data Prevention (https://oreil.ly/MSzAr) kann dabei helfen, bestimmte Arten vertraulicher Daten zu klassifizieren oder zu maskieren, und Microsoft Pureview (https://oreil.ly/av897) kann Daten auf Azure Cloud Services klassifizieren.
Was auch immer Sie für ein System zur Datenklassifikation nutzen – schreiben Sie eine Definition jeder Klassifikationsstufe und ein paar Beispiele auf und stellen Sie sicher, dass jeder, der Daten erzeugt, sammelt oder schützt, das Klassifikationssystem versteht.
