Praktische Cloud-Sicherheit, 2. Auflage

Kapitel 1. Grundsätze und Konzepte

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Ja, dies ist ein praktischer Leitfaden, aber wir müssen ein paar Cloud-relevante Sicherheitsprinzipien und -konzepte auf hohem Niveau abdecken, bevor wir uns mit den praktischen Dingen beschäftigen. Wenn du ein erfahrener Sicherheitsexperte bist, aber noch nicht mit der Cloud vertraut bist, solltest du bis zum "Cloud Shared Responsibility Model" blättern .

Der Grund dafür, dass ich diese Prinzipien und Konzepte zuerst behandle, ist, dass sie im Rest des Buches implizit verwendet werden, wenn ich die Entwicklung und Implementierung von Sicherheitskontrollen bespreche, um Angreifer zu stoppen. Konzeptuelle Lücken und Missverständnisse in der Sicherheit können viele Probleme verursachen. Zum Beispiel:

• Wenn du mit dem Prinzip der geringsten Rechte nicht vertraut bist, verstehst du vielleicht die Autorisierung für Cloud-Dienste gut, gewährst aber trotzdem zu viel Zugriff auf Personen oder Automatisierung in deinem Cloud-Konto oder auf eine Cloud-Datenbank mit sensiblen Informationen.

• Wenn du mit dem Konzept der "Defense in Depth" nicht vertraut bist, erscheinen dir mehrere Authentifizierungs-, Zugriffskontroll- oder Verschlüsselungsebenen vielleicht nicht sinnvoll.

• Wenn du dich nicht ein wenig mit Bedrohungsmodellen auskennst - den wahrscheinlichen Motiven von Angreifern und den Vertrauensgrenzen des Systems, das du entwickelst - investierst du vielleicht Zeit und Mühe, um die falschen Dinge zu schützen.

• Wenn du die Modelle zur Erbringung von Cloud-Diensten und das Modell der geteilten Verantwortung nicht verstehst, verbringst du vielleicht deine Zeit damit, dich um Risiken zu kümmern, die in der Verantwortung deines Cloud-Providers liegen, und übersiehst Risiken, für die du verantwortlich bist.

• Wenn du dich nicht ein bisschen mit Risikomanagement auskennst, verbringst du vielleicht zu viel Zeit und Mühe mit niedrigen Risiken, anstatt deine höheren Risiken zu managen.

Ich werde diese grundlegenden Informationen schnell abhandeln, damit wir zu den Cloud-Sicherheitskontrollen kommen können.

Least Privilege

Das Prinzip der geringsten Privilegien besagt, dass Menschen oder automatisierte Tools nur auf das zugreifen dürfen, was sie für ihre Arbeit benötigen, und nicht mehr. Es ist leicht, den automatisierten Teil dieses Prinzips zu vergessen. Zum Beispiel sollte eine Komponente, die auf eine Datenbank zugreift, keine Anmeldedaten verwenden, die einen Schreibzugriff auf die Datenbank ermöglichen, wenn dieser nicht benötigt wird.

Eine praktische Anwendung des Prinzips der geringsten Rechte bedeutet oft, dass deine Zugriffsrichtlinien standardmäßig verweigert werden. Das heißt, den Nutzern werden standardmäßig keine (oder nur sehr wenige) Berechtigungen gewährt und sie müssen für alle benötigten Berechtigungen den Antrags- und Genehmigungsprozess durchlaufen.

In Cloud-Umgebungen müssen einige deiner Administratoren Zugriff auf die Cloud-Konsole haben - eine Webseite, über die du Cloud-Assets wie virtuelle Maschinen erstellen, ändern und zerstören kannst. Bei vielen Anbietern hat jeder, der Zugang zu deiner Cloud-Konsole hat, standardmäßig gottgleiche Rechte für alles, was von diesem Cloud-Provider verwaltet wird. Dazu gehört auch die Möglichkeit, Daten aus jedem Teil der Cloud-Umgebung zu lesen, zu ändern oder zu zerstören, unabhängig davon, welche Kontrollen auf den Betriebssystemen der bereitgestellten Systeme vorhanden sind. Aus diesem Grund musst du den Zugriff auf die Cloud-Konsole und die dortigen Berechtigungen streng kontrollieren, ähnlich wie du den Zugriff auf das physische Rechenzentrum in lokalen Umgebungen streng kontrollierst, und aufzeichnen, was diese Nutzer/innen tun.

Defense in Depth

Viele der in diesem Buch vorgestellten Kontrollen würden, wenn sie perfekt umgesetzt werden, die Notwendigkeit für andere Kontrollen zunichte machen. Defense in depth ist die Erkenntnis, dass fast jede Sicherheitskontrolle fehlschlagen kann, entweder weil ein Angreifer entschlossen und geschickt genug ist oder weil es ein Problem mit der Art und Weise gibt, wie die Sicherheitskontrolle umgesetzt wird. Bei der Tiefenverteidigung schaffst du mehrere Schichten von sich überschneidenden Sicherheitskontrollen, so dass, wenn eine fehlschlägt, die dahinter liegende Kontrolle die Angreifer noch abfangen kann.

Bei der Tiefenverteidigung kann man natürlich bis zum Äußersten gehen. Deshalb ist es wichtig, dass du die Bedrohungen kennst, mit denen du wahrscheinlich konfrontiert wirst. Generell solltest du jedoch in der Lage sein, auf jede einzelne Sicherheitskontrolle zu verweisen und zu fragen: "Was ist, wenn diese fehlschlägt?" Wenn die Antwort inakzeptabel ist, hast du wahrscheinlich eine unzureichende Verteidigung in der Tiefe. Eine unzureichende Verteidigungstiefe liegt auch dann vor, wenn ein einziger Fehler dazu führt, dass mehrere Sicherheitskontrollen unwirksam werden, z. B. wenn ein Inventarproblem dazu führt, dass mehrere Tools ein Problem übersehen.

Null Vertrauen

Viele Produkte und Dienstleistungen behaupten heute, Zero Trust zu sein oder Zero Trust Prinzipien zu unterstützen. Der Name ist verwirrend, denn Null-Vertrauen bedeutet nicht das völlige Fehlen von Vertrauen in irgendetwas, und die Verwirrung ist noch größer, weil der Begriff für so viele verschiedene Marketingzwecke verwendet wird. Es gibt viele verschiedene Definitionen und unterschiedliche Vorstellungen davon, was mit Zero Trust gemeint ist.

An diesem Punkt sind wir wahrscheinlich bei dem Begriff hängen geblieben, aber "Null Vertrauen" sollte eigentlich anders heißen, zum Beispiel "Null implizites Vertrauen" oder "Null angenommenes Vertrauen ohne guten Grund".¹ Das Grundprinzip ist, dass man sich das Vertrauen eines Nutzers oder eines anderen Systems verdienen muss, anstatt es einfach nur zu gewähren, weil der Nutzer dich über das Netzwerk erreichen kann, ein firmeneigenes Gerät besitzt oder ein anderes Kriterium hat, das nicht gutkontrolliert wird.

Die Umsetzung von Zero Trust ist sehr unterschiedlich, je nachdem, ob es um vertrauenswürdige Geräte, Netzwerkverbindungen oder etwas anderes geht. Eine gängige Umsetzung von Zero Trust ist die Forderung nach Verschlüsselung und Authentifizierung für alle Verbindungen, auch für solche, die in vermeintlich vertrauenswürdigen Netzwerken entstehen und enden. Das war schon immer eine gute Idee, ist aber in Cloud-Umgebungen, in denen die Grenzen weniger streng gezogen sind und Internetverbindungen leicht möglich sind, noch wichtiger.

Eine weitere gängige Umsetzung der Zero-Trust-Prinzipien ist die Beschränkung des Netzwerkzugriffs der Nutzer/innen auf die Anwendungen, die sie benötigen, wobei das implizite Vertrauen in Frage gestellt wird, dass alle Nutzer/innen in der Lage sein sollten, sich mit allen Anwendungen zu verbinden, auch wenn sie sich nicht anmelden können. Wenn du denkst, dass sich das sehr nach Least Privilege und Defense in Depth anhört, hast du recht. Es gibt erhebliche Überschneidungen zwischen den Zero-Trust-Prinzipien und einigen der anderen Prinzipien in diesem Kapitel.

Ein drittes Beispiel für Null-Vertrauen ist die Verwendung einer Multi-Faktor-Authentifizierung von Nutzern, bei der entweder regelmäßig oder bei risikoreicheren Transaktionen eine Neuauthentifizierung erforderlich ist. In diesem Fall stellen wir das implizite Vertrauen in Frage, dass derjenige, der das Passwort für ein Konto hat oder eine bestimmte Sitzung für eine Anwendung steuert, auch der beabsichtigte Nutzer ist.

Wenn du die Null-Vertrauens-Prinzipien befolgst, solltest du einer Interaktion nur dann vertrauen, wenn du starke Beweise dafür hast, dass das Vertrauen gerechtfertigt ist, z. B. durch den Nachweis einer starken Authentifizierung, einer Autorisierung oder einer korrekten Konfiguration. Diese Beweise sollten entweder von etwas stammen, das du direkt kontrollierst (z. B. dein eigenes Authentifizierungs- oder Gerätemanagementsystem), oder von einer dritten Partei, die du ausdrücklich als kompetent eingestuft hast, um Vertrauensentscheidungen für dich zu treffen. Wie andere Grundsätze in diesem Kapitel kann auch dieser das Nutzererlebnis beeinträchtigen, wenn er zu weit getrieben wird.

Bedrohungsakteure, Diagramme und Vertrauensgrenzen

Es gibt verschiedene Möglichkeiten, über deine Risiken nachzudenken, aber ich bevorzuge in der Regel einen wertorientierten Ansatz. Das bedeutet, dass du dich zuerst auf das konzentrierst, was du schützen musst. Deshalb gehe ich in Kapitel 2 zuerst auf die Datenbestände ein.

Es ist auch eine gute Idee, sich vor Augen zu halten, wer dir am ehesten Probleme bereiten könnte. Im Sprachgebrauch der Cybersicherheit sind das deine potenziellen "Bedrohungsakteure". So musst du dich vielleicht nicht vor einem gut finanzierten staatlichen Akteur schützen, aber vielleicht bist du in einer Branche tätig, in der ein Cyberkrimineller mit dem Diebstahl deiner Daten Geld verdienen kann, oder in der ein "Hacktivist" deine Website aus politischen oder sozialen Gründen verunstalten will. Behalte diese Leute im Hinterkopf, wenn du deine Verteidigungsmaßnahmen entwirfst.

Es gibt zwar viele Informationen und Diskussionen zum Thema Bedrohungsakteure, Motivationen und Methoden,² In diesem Buch werden wir vier Haupttypen von Bedrohungsakteuren betrachten, vor denen du dich fürchten musst:

• Organisiertes Verbrechen oder unabhängige Kriminelle, die vor allem daran interessiert sind, Geld zu verdienen

• Hacktivisten, die vor allem daran interessiert sind, dich zu diskreditieren, indem sie gestohlene Daten veröffentlichen, Vandalismus begehen oder dein Geschäft stören

• Angreifer von innen, die normalerweise daran interessiert sind, dich zu diskreditieren oder Geld zu verdienen

• Staatliche Akteure, die möglicherweise daran interessiert sind, Geheimnisse zu stehlen oder dein Geschäft zu stören, um die politische Mission oder Sache einer ausländischen Regierung voranzutreiben

Um eine Technik aus der Welt des User Experience Design zu übernehmen, kannst du dir ein Mitglied jeder Gruppe vorstellen, ihm einen Namen geben, etwas über diese "Persona" auf einer Karte notieren und die Karten bei der Gestaltung deiner Abwehrmaßnahmen sichtbar halten.

Als Zweites musst du herausfinden, was in deiner Bewerbung mit was kommunizieren muss. Am einfachsten ist es, ein Bild zu zeichnen und herauszufinden, wo deine Schwachstellen sein könnten. Es gibt ganze Bücher darüber, wie man das macht,³ aber man muss kein Experte sein, um etwas Nützliches zu zeichnen, das dir bei der Entscheidungsfindung hilft. Wenn du jedoch in einer risikoreichen Umgebung arbeitest, solltest du lieber formale Diagramme mit einem geeigneten Werkzeug erstellen, als Strichmännchen zu zeichnen.

Es gibt zwar viele verschiedene Anwendungsarchitekturen, aber für die Beispielanwendung, die hier zur Veranschaulichung dient, werde ich ein einfaches dreistufiges Design zeigen. Ich empfehle das folgende Diagramm für ein sehr einfaches Anwendungskomponentendiagramm:

1. Zeichne ein Strichmännchen und beschrifte es mit "Benutzer". Zeichne ein weiteres Strichmännchen und beschrifte es mit "Administrator"(Abbildung 1-1). Vielleicht stellst du später fest, dass du mehrere Arten von Benutzern und Administratoren oder andere Rollen hast, aber das ist ein guter Anfang.

   

   Abbildung 1-1. Benutzer- und Administratorrollen

2. Zeichne ein Kästchen für die erste Komponente, mit der der Benutzer spricht (z. B. die Webserver), zeichne eine Linie vom Benutzer zu dieser ersten Komponente und beschrifte die Linie mit der Art und Weise, wie der Benutzer mit dieser Komponente spricht(Abbildung 1-2). Beachte, dass die Komponente an dieser Stelle eine serverlose Funktion, ein Container, eine virtuelle Maschine oder etwas anderes sein kann. Damit kann jeder mit ihr reden, also wird sie wahrscheinlich als erstes angegriffen. Wir wollen wirklich nicht, dass die anderen Komponenten dieser Komponente mehr vertrauen als nötig.

   

   Abbildung 1-2. Erste Komponente

3. Zeichne weitere Kästchen hinter das erste für alle anderen Komponenten, mit denen das erste System kommunizieren muss, und ziehe Linien zu diesen(Abbildung 1-3). Immer wenn du zu einem System kommst, das Daten speichert, zeichne ein kleines Symbol (ich benutze einen Zylinder) daneben und notiere, welche Daten dort gespeichert sind. Mach so lange weiter, bis dir keine Kästchen mehr einfallen, die du für deine Anwendung zeichnen kannst.

   

   Abbildung 1-3. Zusätzliche Komponenten

4. Zeichne nun ein, wie der Administrator (und alle anderen Rollen, die du definiert hast) auf die Anwendung zugreift. Beachte, dass der Administrator verschiedene Möglichkeiten hat, mit der Anwendung zu kommunizieren, z. B. über das Portal oder die APIs des Cloud-Providers, über das Betriebssystem oder auf ähnliche Weise wie ein Benutzer(Abbildung 1-4).

   

   Abbildung 1-4. Administratorenzugang

5. Zeichne einige Vertrauensgrenzen als gestrichelte Linien um die Kästchen(Abbildung 1-5). Eine Vertrauensgrenze bedeutet, dass alles, was sich innerhalb dieser Grenze befindet, zumindest ein gewisses Vertrauen in die Motive von allem, was sich innerhalb dieser Grenze befindet, haben kann, aber eine Überprüfung erfordert, bevor man etwas außerhalb der Grenze vertraut. Der Gedanke dahinter ist, dass ein Angreifer, der in einen Teil der Vertrauensgrenze eindringt, davon ausgehen kann, dass er schließlich die vollständige Kontrolle über alles innerhalb der Grenze hat. Beachte, dass ich mehrere Webserver innerhalb derselben Vertrauensgrenze eingezeichnet habe. Das bedeutet, dass diese Webserver einander vertrauen können und dass jemand, der Zugang zu einem Server hat, auch Zugang zu allen anderen hat. Oder anders ausgedrückt: Wenn jemand einen dieser Webserver kompromittiert, wird kein weiterer Schaden angerichtet, wenn sie alle kompromittiert werden.

   In diesem Zusammenhang führen uns die Zero-Trust-Prinzipien dazu, diese Vertrauensgrenzen auf die kleinste sinnvolle Größe zu reduzieren - zum Beispiel auf eine einzelne Komponente, die hier ein einzelner Server oder ein Cluster von Servern mit denselben Daten und demselben Zweck sein könnte.

   

   Abbildung 1-5. Vertrauensgrenzen der Komponenten

6. In gewisser Weise vertrauen wir unserem gesamten System mehr als dem Rest der Welt, also ziehe eine gestrichelte Linie um alle Felder, einschließlich des Administrators, aber nicht des Benutzers(Abbildung 1-6). Wenn du mehrere Administratoren hast, z. B. einen Webserver-Administrator und einen Datenbank-Administrator, kann es sein, dass sie in unterschiedlichen Vertrauensbereichen liegen. Die Tatsache, dass es Vertrauensgrenzen innerhalb von Vertrauensgrenzen gibt, zeigt die verschiedenen Vertrauensstufen. So können die Server hier zum Beispiel bereit sein, Netzwerkverbindungen von Servern in anderen Vertrauensbereichen innerhalb der Anwendung zu akzeptieren, deren Identitäten aber trotzdem zu überprüfen. Andererseits sind sie möglicherweise nicht bereit, Verbindungen von Systemen außerhalb der gesamten Vertrauensgrenze der Anwendung zu akzeptieren.

   

   Abbildung 1-6. Vertrauensgrenze für die gesamte Anwendung

Wir werden dieses Diagramm einer Beispielanwendung während des gesamten Buches verwenden, wenn wir das Modell der geteilten Verantwortung, die Bestandsaufnahme, die Kontrollen und die Überwachung besprechen. Im Moment sind in dem Diagramm noch keine Cloud-spezifischen Kontrollen dargestellt, aber das wird sich im Laufe der Kapitel ändern. Schau dir jede Stelle an, an der eine Linie eine Vertrauensgrenze kreuzt. Das sind die Stellen, auf die wir uns zuerst konzentrieren müssen!

Cloud Service Delivery Modelle

Es gibt ein ungeschriebenes Gesetz, dass kein Buch über Cloud Computing vollständig ist, ohne einen Überblick über Infrastructure as a Service (IaaS), Platform as a Service (PaaS) und Software as a Service (SaaS). Anstatt den Standardüberblick zu geben, möchte ich kurz darauf hinweisen, dass IaaS-Dienste in der Regel die Erstellung von virtuellen Computern, Speicherung und Netzwerken ermöglichen; PaaS-Dienste sind in der Regel übergeordnete Dienste, wie z. B. Datenbanken, mit denen du Anwendungen erstellen kannst; und SaaS-Dienste sind Anwendungen, die von Endbenutzern genutzt werden. Es gibt viele erweiterte Definitionen und Unterteilungen dieser Kategorien, aber dies sind die Kerndefinitionen.

Diese Servicemodelle sind nur für ein allgemeines Verständnis der Konzepte nützlich; insbesondere die Grenze zwischen IaaS und PaaS wird immer unschärfer. Ist ein Content-Delivery-Network-Dienst, der Informationen für dich im Internet zwischenspeichert, um sie in der Nähe der Nutzer/innen zu halten, ein PaaS oder ein IaaS? Das spielt eigentlich keine Rolle. Wichtig ist, dass du verstehst, was der Dienst leistet (und was nicht!), und nicht, ob er in eine bestimmte Kategorie passt.

Das Modell der geteilten Verantwortung in der Cloud

Die grundlegendste Sicherheitsfrage, die du beantworten musst, lautet: "Für welche Sicherheitsaspekte bin ich verantwortlich?" In einer On-Premises-Umgebung wird diese Frage oft stillschweigend beantwortet. Die Entwicklungsorganisation ist für Codefehler verantwortlich und die Betriebsorganisation (IT) ist für alles andere zuständig. Viele Unternehmen arbeiten heute mit einem DevOps-Modell, bei dem diese Verantwortlichkeiten geteilt werden und die Grenzen zwischen Entwicklung und Betrieb verschwimmen oder gar nicht existieren. Unabhängig davon, wie es organisiert ist, liegt die Verantwortung für die Sicherheit fast ausschließlich innerhalb des Unternehmens.

Eine der überraschendsten Veränderungen beim Wechsel von einer lokalen Umgebung zu einer Cloud-Umgebung ist vielleicht das kompliziertere Modell der gemeinsamen Verantwortung für die Sicherheit. In einer lokalen Umgebung hattest du vielleicht eine Art internes Dokument oder einen Vertrag mit der IT-Abteilung oder einer anderen Abteilung, die die Server für dich betrieb. In vielen Fällen waren die Geschäftskunden der IT-Abteilung jedoch daran gewöhnt, die Anforderungen oder den Code an einen internen Anbieter zu übergeben und alles andere für sich erledigen zu lassen, insbesondere im Bereich der Sicherheit.

Selbst wenn du schon eine Weile in einer Cloud-Umgebung arbeitest, hast du vielleicht noch nicht darüber nachgedacht, wo die Verantwortung des Cloud-Providers endet und wo deine beginnt. Diese Abgrenzung ist je nach Art der Cloud-Dienste, die du kaufst, unterschiedlich. Fast alle Cloud-Provider gehen in ihren Dokumentationen und Schulungsunterlagen in irgendeiner Form darauf ein, aber am besten lässt es sich mit dem Vergleich zum Pizzaessen erklären.

Mit Pizza as a Service,⁴ Nehmen wir an, du hast Lust auf Pizza. Da gibt es eine Menge Auswahl! Du könntest einfach zu Hause eine Pizza machen, aber dafür brauchst du eine Menge Zutaten und es würde eine Weile dauern. Du könntest in den Supermarkt gehen und eine Pizza zum Mitnehmen kaufen; dafür brauchst du nur einen Ofen und einen Platz zum Essen. Du könntest deinen Lieblings-Pizzalieferanten anrufen. Oder du setzt dich einfach in ein Restaurant und bestellst eine Pizza. Wenn wir ein Diagramm mit den verschiedenen Komponenten und den Zuständigkeiten zeichnen, erhalten wir etwa Abbildung 1-7.

Abbildung 1-7. Pizza als Dienstleistung

Die traditionelle On-Premises-Welt ist wie eine Pizza zu Hause zu backen. Du musst eine Menge verschiedener Komponenten kaufen und sie selbst zusammenstellen, aber du bist völlig flexibel. Sardellen und Zimt auf Weizenkruste? Wenn du dich damit anfreunden kannst, kannst du es auch machen.

Wenn du aber Infrastructure as a Service nutzt, ist die Basisschicht bereits für dich erledigt. Du kannst sie nach deinem Geschmack backen, einen Salat und Getränke hinzufügen und bist für diese Dinge verantwortlich. Wenn du auf Platform as a Service umsteigst, werden noch mehr Entscheidungen für dich getroffen, z. B. wie deine Pizza gebacken wird. (Wie im vorherigen Abschnitt erwähnt, kann es manchmal schwierig sein, einen Dienst als IaaS oder PaaS zu kategorisieren, und in vielen Fällen wachsen sie zusammen. Die genaue Klassifizierung ist nicht wichtig; wichtig ist, dass du verstehst, was der Dienst bietet und welche Aufgaben du hast).

Wenn du dich für Software as a Service entscheidest (im Vergleich zu einem Restaurantbesuch in Abbildung 1-7), scheint es, als ob alles für dich erledigt wäre. Das ist es aber nicht. Du bist immer noch dafür verantwortlich, sicher zu essen, und das Restaurant ist nicht dafür verantwortlich, wenn du an deinem Essen erstickst. In der SaaS-Welt kommt es vor allem darauf an, die Zugriffskontrolle richtig zu verwalten.

Wenn wir das Diagramm zeichnen, uns aber auf die Technologie statt auf die Pizza konzentrieren, sieht es eher wie Abbildung 1-8 aus.

Abbildung 1-8. Modell der geteilten Verantwortung in der Cloud

Die Realität des Cloud Computing ist leider etwas komplizierter als Pizza essen, daher gibt es einige Grauzonen. Am unteren Ende des Diagramms sind die Dinge konkret (oft wörtlich). Der Cloud-Provider trägt die volle Verantwortung für die Sicherheit der physischen Infrastruktur - und das bedeutet oft Kontrollen, die über das hinausgehen, was viele Unternehmen vor Ort vernünftigerweise tun können, wie z. B. biometrischer Zugang mit Anti-Tailgating-Maßnahmen, Sicherheitspersonal, Barrieren von Platte zu Platte und ähnliche Kontrollen, um unbefugtes Personal von den physischen Einrichtungen fernzuhalten.

Wenn der Anbieter virtualisierte Umgebungen anbietet, liegt die Verantwortung für die Sicherheitskontrollen der virtualisierten Infrastruktur, die deine virtuelle Umgebung von anderen virtuellen Umgebungen trennen, ebenfalls beim Anbieter. Als die Sicherheitslücken Spectre und Meltdown Anfang 2018 bekannt wurden, bestand eine der möglichen Auswirkungen darin, dass Benutzer/innen einer virtuellen Maschine den Speicher einer anderen virtuellen Maschine auf demselben physischen Computer lesen konnten. Für IaaS-Kunden lag es in der Verantwortung des Cloud-Providers, diesen Teil der Schwachstelle zu beheben - Amazon, Microsoft, Google und IBM mussten z. B. Updates für ihre Hypervisoren bereitstellen.

Die Netzwerksicherheit wird im IaaS-Abschnitt von Abbildung 1-8 als gemeinsame Verantwortung dargestellt. Warum? Es ist schwer, das in einem Diagramm darzustellen, aber es gibt mehrere Netzwerkschichten, für die jeweils eine andere Partei verantwortlich ist. Der Cloud-Provider hat sein eigenes Netzwerk, für das er verantwortlich ist, aber in der Regel gibt es ein virtuelles Netzwerk darüber (manche Cloud-Provider bieten z. B. eine virtuelle private Cloud an), und es liegt in der Verantwortung des Kunden, dieses in vernünftige Sicherheitszonen einzuteilen und die richtigen Regeln für den Zugang zwischen ihnen aufzustellen. Viele Implementierungen verwenden auch Overlay-Netzwerke, Firewalls und Transportverschlüsselung, die in der Verantwortung des Kunden liegen. Dies wird in Kapitel 6 ausführlich behandelt.

Die Sicherheit des Betriebssystems ist in der Regel einfach: Sie liegt in deiner Verantwortung, wenn du IaaS nutzt, und in der Verantwortung des Anbieters, wenn du Plattform- oder Softwaredienste kaufst. Wenn du diese Dienste kaufst, hast du in der Regel keinen Zugriff auf das zugrunde liegende Betriebssystem. (Als Faustregel gilt: Wenn du die Möglichkeit hast, es zu knacken, bist du normalerweise auch für die Sicherheit verantwortlich).

Middleware ist in diesem Zusammenhang ein allgemeiner Name für Software wie Datenbanken, Anwendungsserver oder Warteschlangensysteme. Sie befindet sich zwischen dem Betriebssystem und der Anwendung und wird nicht direkt von den Endnutzern verwendet, sondern dient der Entwicklung von Lösungen für die Endnutzer. Wenn du ein PaaS nutzt, ist die Sicherheit der Middleware oft eine geteilte Verantwortung: Der Anbieter hält die Software vielleicht auf dem neuesten Stand (oder stellt dir Updates zur Verfügung), aber du bist weiterhin für sicherheitsrelevante Einstellungen wieVerschlüsselung verantwortlich.

Die Anwendungsschicht ist das, was der Endnutzer tatsächlich nutzt. Wenn du SaaS nutzt, sind Schwachstellen auf dieser Ebene (wie Cross-Site-Scripting oder SQL-Injection) in der Verantwortung des Anbieters, aber wenn du dieses Buch liest, nutzt du wahrscheinlich nicht nur das SaaS eines anderen Anbieters. Selbst wenn alle anderen Schichten kugelsicher sind, kann eine Schwachstelle in der Anwendungssicherheitsschicht leicht alle deine Daten preisgeben.

Schließlich liegt die Sicherheit des Datenzugriffs fast immer in deiner Verantwortung als Kunde. Wenn du deinem Cloud-Provider fälschlicherweise den Zugriff auf bestimmte Daten erlaubst, z. B. durch die Vergabe falscher Berechtigungen für die Speicherung von Objekten, Middleware oder SaaS, kann der Anbieter nicht viel mehr tun, als zu versuchen, das Problem zu erkennen und dich zu warnen.

Die Ursache vieler Sicherheitsvorfälle liegt in der Annahme, dass der Cloud-Provider für etwas zuständig ist, obwohl sich herausstellt, dass niemand dafür zuständig war. Viele reale Beispiele für Sicherheitsvorfälle, die auf ein falsches Verständnis des Modells der geteilten Verantwortung zurückzuführen sind, stammen von offenen Amazon Simple Storage Service (Amazon S3) Buckets. Sicher, die Speicherung in S3 ist sicher und verschlüsselt, aber das hilft alles nichts, wenn du deine Zugriffskontrollen nicht richtig einrichtest. Dieses Missverständnis hat zum Verlust von Daten geführt:

• Daten von 198 Millionen US-Wählern

• Automatische Verfolgung von Unternehmensaufzeichnungen

• Drahtlose Kundenaufzeichnungen

• Über 3 Millionen demografische Erhebungen

• Über 50.000 Kreditauskünfte von indischen Bürgern

• Über 100.000 Noten und persönliche Daten von Schülern

• Tausende von Stunden Audio- und Videoaufnahmen, die privateGespräche enthalten

Es gibt noch viele weitere Beispiele. Obwohl es beträchtliche Fortschritte gibt, wird das Modell der geteilten Verantwortung oft noch missverstanden. Viele IT-Entscheidungsträger glauben immer noch, dass Public Cloud-Provider nicht nur für die Sicherheit der von ihnen angebotenen Cloud-Dienste, sondern auch für die Sicherheit der Kundenanwendungen und -daten in der Cloud verantwortlich sind. Wenn du deinen Vertrag mit deinem Cloud-Provider liest, wirst du feststellen, dass das einfach nicht stimmt!

Risikomanagement

Risikomanagement ist ein tiefgründiges Thema, über das ganze Bücher geschrieben wurden. Wenn du wirklich tief eintauchen willst, empfehle ich dir das Buch The Failure of Risk Management: Why It's Broken and How to Fix It, von Douglas W. Hubbard (Wiley, 2020) und NIST Special Publication 800-30 Rev 1. Kurz gesagt: Menschen sind wirklich schlecht darin, Risiken zu bewerten und herauszufinden, was man dagegen tun kann. Dieser Abschnitt soll dir nur das Nötigste an die Hand geben, um das Risiko von Sicherheitsvorfällen und Datenschutzverletzungen zu minimieren.

Auch auf die Gefahr hin, das Offensichtliche zu sagen: Ein Risiko ist etwas Schlimmes, das passieren könnte. In den meisten Risikomanagementsystemen wird die Höhe des Risikos anhand einer Kombination aus der Wahrscheinlichkeit, dass etwas Schlimmes passiert (Wahrscheinlichkeit), und den Folgen, wenn es passiert (Auswirkungen), bestimmt. Wenn es zum Beispiel sehr wahrscheinlich ist, dass etwas passiert (z. B. wenn jemand dein Passwort "1234" errät), und wenn es sehr schlimm ist (z. B. wenn du alle Daten deiner Kunden verlierst und hohe Geldstrafen zahlen musst), dann ist das Risiko hoch. Etwas, das sehr unwahrscheinlich ist (z. B. ein Asteroid, der zwei regionale Rechenzentren auf einmal auslöscht), aber sehr schlimm wäre, wenn es doch passiert (Geschäftsaufgabe), könnte nur ein geringes Risiko sein, je nachdem, nach welchem System du den Risikograd bestimmst.⁵

In diesem Buch spreche ich über unbekannte Risiken (bei denen wir nicht genug Informationen haben, um zu wissen, wie hoch die Wahrscheinlichkeit und die Auswirkungen sind) und bekannte Risiken (bei denen wir zumindest wissen, womit wir es zu tun haben). Sobald du eine Vorstellung von den bekannten Risiken hast, kannst du eine von vier Möglichkeiten nutzen:

1. Vermeide das Risiko. In der Informationssicherheit bedeutet das in der Regel, dass du dasSystem abschaltest- kein Risiko mehr, aber auch keine Vorteile, die du durch den Betrieb des Systems hattest.

2. Das Risiko abmildern. Es ist immer noch da, aber du unternimmst zusätzliche Dinge, um entweder die Wahrscheinlichkeit, dass etwas Schlimmes passiert, oder die Auswirkungen, wenn es passiert, zu verringern. Du kannst dich zum Beispiel dafür entscheiden, weniger sensible Daten zu speichern, damit im Falle eines Verstoßes die Auswirkungen nicht so schlimm sind.

3. Übertrage das Risiko. Du bezahlst jemand anderen dafür, dass er die Dinge verwaltet, so dass das Risiko sein Problem ist. Das wird häufig bei der Cloud gemacht, wo du viele der Risiken, die mit der Verwaltung der unteren Systemebenen verbunden sind, auf den Cloud-Provider überträgst.

4. Akzeptiere das Risiko. Nachdem du den Gesamtrisikograd und die Vorteile der Fortsetzung der Aktivität geprüft hast, kannst du dich entscheiden, das Risiko schriftlich festzuhalten, alle Beteiligten dazu zu bringen, dem Risiko zuzustimmen, und dann weiterzumachen.

Jede dieser Maßnahmen kann vernünftig sein. Nicht akzeptabel ist jedoch, wenn du entweder keine Ahnung hast, welche Risiken du hast, oder wenn du eine Vorstellung von den Risiken hast und sie akzeptierst, ohne die Konsequenzen abzuwägen oder die Zustimmung deiner Interessenvertreter einzuholen. Zumindest solltest du eine Liste in einer Tabelle oder einem Dokument führen, in der die dir bekannten Risiken, die ergriffenen Maßnahmen und alle erforderlichen Genehmigungen aufgeführt sind.

Fazit

Auch wenn es in der realen Welt oft keine perfekten Antworten gibt, hilft dir das Verständnis einiger grundlegender Konzepte dabei, bessere Entscheidungen für die Sicherung deiner Cloud-Umgebungen zu treffen.

Least Privilege bedeutet im Grunde nichts anderes, als zu erkennen, dass es ein Risiko ist, privilegierten Zugang zu irgendetwas oder irgendjemandem zu gewähren, und dass du nicht mehr Risiken eingehen willst als nötig. Das ist natürlich eine Kunst, weil es manchmal Kompromisse zwischen Risiko und Produktivität gibt, aber das allgemeine Prinzip ist gut - gib nur so viele Privilegien wie nötig. Das wird bei der Automatisierung oft übersehen, ist dort aber wohl noch wichtiger, weil viele Angriffe darauf beruhen, ein System oder eine Automatisierung zu unerwarteten Aktionen zu verleiten.

Defense in depth bedeutet anzuerkennen, dass wir nicht perfekt sind und dass die Systeme, die wir entwickeln, nicht perfekt sein werden. Es ist auch eine Anspielung auf die grundlegenden Gesetze der Wahrscheinlichkeit: Wenn zwei unabhängige Dinge fehlschlagen müssen, damit etwas Schlimmes passiert, ist die Wahrscheinlichkeit, dass es passiert, viel geringer. Wenn du eine Münze wirfst und zweimal hintereinander die Zahl "Zahl" erhältst, liegt die Wahrscheinlichkeit dafür nur bei 25 %, verglichen mit der 50 %igen Chance, bei einem Münzwurf die Zahl zu erhalten. Wir streben nach Sicherheitskontrollen, die viel effektiver sind als ein Münzwurf, aber das Prinzip ist dasselbe. Wenn du zwei sich überschneidende, unabhängige Kontrollen hast, die zu 95% wirksam sind, dann ist die Kombination der beiden zu 99,75% wirksam! Bei diesem Ansatz gibt es jedoch einen abnehmenden Ertrag, so dass fünf oder sechs Schichten im gleichen Bereich wahrscheinlich keine gute Ressourcennutzung sind.

Bei der Bedrohungsmodellierung geht es darum, herauszufinden, wer dein System angreifen könnte und warum, und die Komponenten deines Systems und wie sie zusammenarbeiten zu verstehen. Mit diesen beiden Informationen kannst du dein System mit den Augen potenzieller Angreifer betrachten und versuchen, Bereiche zu erkennen, in denen Angreifer etwas Unerwünschtes tun könnten. Dann kannst du für jeden dieser Bereiche Hindernisse (oder besser gesagt "Kontrollen" und "Abhilfemaßnahmen") einrichten, um die Angreifer zu vereiteln. In der Regel sind die effektivsten Stellen für Abschwächungen die Vertrauensgrenzen, also die Stellen, an denen ein Teil deines Systems einem anderen Teil vertrauen muss.

Wenn du die Cloud-Bereitstellungsmodelle verstehst, kannst du dich auf die Teile des Gesamtsystems konzentrieren, für die du verantwortlich bist. So verschwendest du keine Zeit mit dem Versuch, die Aufgaben deines Cloud-Providers zu übernehmen, und gehst nicht davon aus, dass dein Cloud-Provider sich um etwas kümmert, das eigentlich in deiner Verantwortung liegt. Es gibt zwar standardisierte Begriffe für verschiedene Cloud-Bereitstellungsmodelle wie IaaS, PaaS und SaaS, aber manche Dienste lassen sich nicht in diese Kategorien einordnen. Das Wichtigste ist jedoch, dass du verstehst, wo die Verantwortung deines Anbieters endet und deine im Modell der geteilten Verantwortung in der Cloud beginnt. In einer On-Premises-Welt ist oft nur eine einzige Organisation innerhalb eines Unternehmens für die Sicherheit des gesamten Systems verantwortlich, während sie bei Cloud-Implementierungen fast immer auf mindestens zwei verschiedene Unternehmen aufgeteilt ist!

Und schließlich sind wir Menschen zwar ziemlich gut darin, Risiken in Situationen wie "Wird mich dieses Raubtier fressen?" einzuschätzen, aber in abstrakteren Situationen sind wir von Natur aus nicht sehr gut darin. Risikomanagement ist eine Disziplin, die uns hilft, Risiken besser einzuschätzen und herauszufinden, was wir dagegen tun können. Die einfachste Form des Risikomanagements besteht darin, die Wahrscheinlichkeit abzuschätzen, dass etwas Schlimmes passiert, und die Auswirkungen abzuschätzen, die es haben wird, wenn es doch passiert. Risikomanagement kann unser Gesamtrisiko senken, indem wir uns zuerst auf die größten Risiken konzentrieren.

Jetzt, da wir diese Konzepte und Prinzipien in unserem Werkzeugkasten haben, können wir sie zum Schutz der Daten und anderer Vermögenswerte in unseren Cloud-Umgebungen einsetzen.

Übungen

1. Welches sind gute Beispiele für das Prinzip des geringsten Privilegs in der Praxis? Wähle alle zutreffenden aus.

   1. Unterschiedliche Zugriffsebenen innerhalb einer Anwendung, wobei die Nutzer nur auf die Funktionen zugreifen können, die sie für ihre Arbeit benötigen

   2. Erfordernis eines Passworts und eines zweiten Faktors, um sich anzumelden

   3. Einem Inventarisierungstool nur Lese- statt Lese-/Schreibzugriff geben

   4. Verwendung eines Tools wie sudo, um einem Benutzer nur die Ausführung bestimmter Befehle zu erlauben

2. Welches sind gute Beispiele für das Prinzip der Verteidigung in der Tiefe? Wähle alles aus, was zutrifft.

   1. Verschlüsseln wertvoller Daten und Verhindern, dass andere die verschlüsselten Daten lesen, wenn sie sie nicht sehen müssen

   2. Sehr strenge Firewall-Kontrollen haben

   3. Sicherstellen, dass die Grenzen deines Vertrauens klar definiert sind

   4. Multi-Faktor-Authentifizierung

3. Was sind die häufigsten Beweggründe von Bedrohungsakteuren? Wähle alles aus, was zutrifft.

   1. Geld stehlen

   2. Geheimnisse stehlen

   3. Dein Geschäft stören

   4. Dich in Verlegenheit bringen

4. Für welche dieser Punkte ist immer der Cloud-Provider verantwortlich?

   1. Sicherheit der physischen Infrastruktur

   2. Netzwerksicherheit

   3. Sicherheit des Betriebssystems

   4. Sicherheit beim Datenzugriff

5. Was sind die wichtigsten Faktoren, um zu beurteilen, wie schwerwiegend ein Risiko ist? Wähle die beiden zutreffenden aus.

   1. Die Chancen oder die Wahrscheinlichkeit, dass ein Ereignis eintritt

   2. Wie stark die Auswirkungen sein werden, wenn ein Ereignis eintritt

   3. Ob du das Risiko auf eine andere Person übertragen kannst oder nicht

   4. ob die Handlungen, die das Risiko verursachen, legal oder illegal sind

¹ Wenn du Tipps erwartest, wie du einprägsame Marketingnamen auswählst, liest du wahrscheinlich das falsche Buch!

² Der Verizon Data Breach Investigations Report ist eine hervorragende kostenlose Ressource, um die verschiedenen Arten erfolgreicher Angriffe zu verstehen, gegliedert nach Branchen und Methoden, und die Zusammenfassung ist sehr lesenswert.

³ Ich empfehle Threat Modeling: Designing for Security, von Adam Shostack (Wiley, 2014).

⁴ Ursprüngliches Konzept aus Albert Barrons LinkedIn-Artikel von 2014, "Pizza as a Service".

⁵ Risiken können auch interagieren oder sich summieren. Es kann zwei Risiken geben, die jeweils eine relativ geringe Wahrscheinlichkeit und begrenzte Auswirkungen haben, aber sie können zusammen auftreten, und die Auswirkungen können in Kombination schwerwiegender sein. Wenn zum Beispiel eine der beiden Stromleitungen ausfällt, kann das vernachlässigbare Auswirkungen haben, aber wenn beide ausfallen, kann das sehr schlimm sein. Das ist oft schwer vorherzusehen; der Stromausfall am Flughafen Atlanta im Jahr 2017 ist ein gutes Beispiel dafür.