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:
Ich werde die grundlegenden Informationen nicht allzu sehr auswalzen, sodass wir bald zu den Cloud-Schutzmaßnahmen kommen können.
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.
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.
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.
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:
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:
Abbildung 1-1: Die Rollen User und Administrator
Abbildung 1-2: Erste Komponente
Abbildung 1-3: Weitere Komponenten
Abbildung 1-4: Zugriff durch den Administrator
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
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!
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.
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:
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 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:
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.
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.
