Kapitel 1. Einführung in Cloud Microservices

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com

Cloud Computing und Microservices sind zu einem beherrschenden Thema in der Welt der Softwarearchitektur geworden. Microservices haben die Komplexität in einer Zeit erhöht, in der Sicherheitsangriffe viel zu häufig vorkommen, und sie haben die Bedeutung von Sicherheitsexperten in jeder Organisation erhöht.

Diese Geschichte (die ich zum ersten Mal auf YouTube gehört habe) könnte vielen von euch bekannt vorkommen. Ein schnelllebiges Unternehmen baut eine Microservices-basierte Anwendung auf und du gehörst zum Sicherheitsteam. Möglicherweise hast du Interessenvertreter, wie z. B. einen CEO oder einen Produktmanager, die wollen, dass dein Produkt rechtzeitig auf den Markt kommt, um Marktanteile zu gewinnen. Die Entwickler in deinem Unternehmen tun ihr Bestes, um die Fristen einzuhalten und den Code schneller zu veröffentlichen. Du wirst am Ende des Prozesses hinzugezogen und hast den Auftrag, dafür zu sorgen, dass das Endprodukt sicher ist. Das sollte dir sofort ein Dorn im Auge sein. Wenn das Produkt unabhängig von dir (dem Sicherheitsteam) entwickelt wird, seid ihr die Einzigen, die einem Produkt im Weg stehen, das einen Mehrwert für das Unternehmen darstellt. Meiner Erfahrung nach werden Sicherheitsexperten in vielen dysfunktionalen Unternehmen von den Entwicklungsteams, Produktmanagern und anderen Stakeholdern im Unternehmen als Neinsager betrachtet.

Das Problem mit oberflächlichen Sicherheitsinitiativen ist, dass sie die wertschöpfenden Aktivitäten behindern. Schlechte Sicherheitsinitiativen sind berüchtigt dafür, dass sie bei den Entwicklern für Frustration sorgen. Das liegt in der Regel an schlechtem Design und schlechten Implementierungen, die in der Branche weit verbreitet sind. Daher werden Sicherheitsrichtlinien manchmal mit "Unternehmensbürokratie" in Verbindung gebracht und haben meiner Erfahrung nach zu einigen unangenehmen Gesprächen in Besprechungsräumen geführt. Das hat viele Entwickler dazu gezwungen, Sicherheitsmaßnahmen zu umgehen, um schneller entwickeln zu können. Noch wichtiger ist, dass viele Sicherheitsinitiativen vor der Ära des Cloud Computing oder der Microservices entwickelt wurden und daher einige der Vorteile, die neue Softwaredesigns und -technologien bieten, nicht berücksichtigen.

Es muss also einen besseren Weg geben. In diesem Kapitel möchte ich dir zeigen, wie die Einbeziehung der Sicherheit in die Architekturphase des Microservice-Designs und die Verwendung einiger von AWS bereitgestellter Tools dabei helfen können, Systeme zu erstellen, die einfach, sicher und gleichzeitig schnell zu entwickeln sind. Ich spreche zunächst über einige wünschenswerte Eigenschaften von sicheren Systemen, die mit besseren Sicherheitsergebnissen korrelieren. Dann erkläre ich, wie Microservices dir dabei helfen können, Systeme zu erstellen, die diese wünschenswerten Eigenschaften aufweisen. Und schließlich gehe ich darauf ein, wie AWS dir bei der Entwicklung dieser Microservices und ihrer Skalierung helfen kann, um ein sicheres System aufzubauen.

Grundlagen der Cloud Informationssicherheit

Bevor ich auf die Grundlagen der Cloud-Sicherheit eingehe, sollten wir einige grundlegende Begriffe der Informationssicherheit definieren, da viele von ihnen synonym verwendet werden, was manchmal zu Verwirrung führt:

Schwachstelle
Eine Schwachstelle ist jeder Mangel im System, der unser System weniger sicher macht. Eine Schwachstelle kann alles in der Software sein, das ausgenutzt werden kann. Das kann auch daran liegen, dass dein System eine ältere Version des Betriebssystems oder eine Bibliothek verwendet, die ausgenutzt werden kann.
Bedrohung
Nur weil eine Sicherheitslücke existiert, heißt das nicht, dass jemand sie ausnutzen wird. Tatsächlich können versteckte Schwachstellen in jeder Anwendung bestehen bleiben, manchmal jahrelang, wie beim Heartbleed-Bug. Aber in dem Moment, in dem die Schwachstelle ausnutzbar wird, kann sie als potenzielle Bedrohung betrachtet werden. Wenn diese Schwachstelle ausgenutzt wird, gilt die Bedrohung als realisiert. Wenn du zum Beispiel deinen Hausschlüssel verlierst, ist das eine Sicherheitslücke. Ein hypothetischer Dieb, der diesen Schlüssel findet, ist eine potenzielle Bedrohung. Ein Dieb, der ihn tatsächlich findet, ist die Verwirklichung dieser Bedrohung. Eine realisierte Bedrohung hat finanzielle, rufschädigende oder operative Auswirkungen auf dein Unternehmen.
Bösartiger Akteur/Bedrohungsakteur/Bedrohungsagent
Der Bedrohungsakteur (oder Threat Agent) ist jeder, der eine Schwachstelle ausnutzt, um eine Bedrohung zu verursachen.
Verantwortung
Im Zusammenhang mit der Sicherheit gibt der Parameter Verantwortung vor, wer dafür verantwortlich ist, dass eine potenzielle Bedrohung niemals Realität wird. Diese Verantwortung kann von einem Mitarbeiter oder einem automatisierten System übernommen oder an ein Drittprodukt oder einen Dienstleister ausgelagert werden. Im Falle von Banken (Filialen) wird die Verantwortung für die Verhinderung von physischem Diebstahl beispielsweise von den Sicherheitsfirmen übernommen.
Risiko
DasRisiko ist eine Kennzahl, die versucht, die Wahrscheinlichkeit zu bewerten, dass eine Bedrohung eintritt, die zu irgendeinem Verlust führt. Dieser Verlust kann finanzieller, rufschädigender oder betrieblicher Art sein. Das Gesamtrisiko einer Anwendung ist die wahrscheinlichkeitsgewichtete Summe aller Bedrohungen, denen sie ausgesetzt sein könnte. Das ultimative Ziel eines jeden Sicherheitsdesigns ist es, das Gesamtrisiko zu verringern.
Kontrolle/Gegenmaßnahme
Eine Kontrolle oder Gegenmaßnahme ist jede Aktivität, die dazu führen kann, das Gesamtrisiko (oder die negativen Auswirkungen der potenziellen Bedrohung, die durch ein Risiko spezifiziert wird) zu verringern. Kontrollen richten sich in der Regel auf bestimmte Bedrohungen und haben einen genau definierten Anwendungsbereich. Kontrollen können auch indirekt sein, wenn bestimmte Aktivitäten das Gesamtrisiko der Organisation indirekt verringern (wenn z. B. das Bewusstsein für Cybersicherheit und Schulungen innerhalb der Organisation gefördert werden, gehen Vorfälle tendenziell zurück).

Risiko- und Sicherheitskontrollen

Der Prozess der Sicherheitsgestaltung umfasst die Identifizierung der Kontrollen, die implementiert werden können, um das Gesamtrisiko in einer Organisation zu verringern. Organisationen, in denen Netzwerksysteme ohne Firewalls betrieben werden, haben zum Beispiel ein höheres Gesamtrisiko als solche mit gut konfigurierten Firewalls, weshalb Firewalls von den meisten Sicherheitsexperten empfohlen werden. Genauer gesagt, fügen Sicherheitsexperten Firewalls als Gegenmaßnahme gegen die Bedrohung durch unbefugte Netzwerkzugriffe hinzu. In diesem Fall haben sie eine potenzielle Bedrohung identifiziert und präventiv eine Gegenmaßnahme implementiert, um die Wahrscheinlichkeit oder die Auswirkungen der Bedrohung zu verringern (und damit per Definition das Risiko der Anwendung zu reduzieren). Dieser Prozess wird als Bedrohungsmodellierung bezeichnet.

Tipp

Viele Sicherheitsunternehmen haben sich eingehend mit den gängigen Bedrohungsszenarien beschäftigt und entsprechende Rahmenwerke erstellt. Ein Beispiel für ein gutes Rahmenwerk ist die Lockheed Martin Cyber Kill Chain, die aufzeigt, was die Angreifer tun müssen, um ihr Ziel zu erreichen.

Sicherheitskontrollen werden als stumpf bezeichnet, wenn sie einseitig alle Anfragen blockieren, ohne zu versuchen, den Kontext oder die Besonderheiten zu verstehen (z. B. ein Zaun um ein Haus, der jeden daran hindert, es zu betreten, unabhängig davon, ob er das Haus besitzt oder nicht). Präzise oder scharfsinnig sind Kontrollen dann, wenn sie bestimmte (potenziell unbefugte) Anfragen identifizieren und blockieren (z. B. ein Schloss an einer Tür, das nur von Personen mit einem Schlüssel geöffnet werden kann und somit nicht die rechtmäßigen Nutzer/innen ausschließt, sondern alle, die keinen Schlüssel haben). Als Faustregel gilt: Stumpfe Kontrollen sind in der Regel stark und einfach zu implementieren. Sie können aber auch zu Reibereien unter den rechtmäßigen Nutzern führen und die Beschäftigten daran hindern, ihre Arbeit zu erledigen. Auf der anderen Seite kann es viel Zeit kosten, scharfe Kontrollen richtig einzustellen, auch wenn sie effektiv sind. Je nach Anwendung können beide Arten von Kontrollen erforderlich sein, um verschiedene Arten von Angriffen zu verhindern. In Kapitel 2 werde ich über Autorisierungs- und Authentifizierungskontrollen sprechen, die extrem scharf sind und einen detaillierten Schutz vor potenziellen Bedrohungen für das Unternehmen bieten können. In Kapitel 5 werde ich über die Netzwerksicherheit sprechen, die ein mächtiges, aber stumpfes Instrument ist.

Einige Kontrollen zielen vielleicht nicht speziell auf potenzielle Bedrohungen ab, können aber dennoch das Gesamtrisiko der Anwendung verringern. So kann beispielsweise die Implementierung einer angemessenen Überwachung und Alarmierung zu einem schnellen Handeln des Sicherheitsteams führen. Unternehmen können sich dafür entscheiden, starke Überwachungssysteme, so genannte Detektivkontrollen, zu implementieren, um böswillige Akteure davon abzuhalten, solche Systeme anzugreifen und so das Gesamtrisiko zu verringern.

Tipp

Du kannst dir die Kontrollen als Hebel vorstellen, die Sicherheitsexperten in jeder Organisation ziehen können, um die Sicherheitslage und das Gesamtrisiko jeder Anwendung anzupassen.

Organisatorische Sicherheitspolitik

Es mag verlockend sein, sich mit jeder potenziellen Bedrohung auseinanderzusetzen und starke Kontrollen gegen jede Schwachstelle zu implementieren. Wie bei allen Aspekten der Softwareentwicklung gibt es jedoch auch hier Kompromisse.

Viele Unternehmen verfolgen bei den Sicherheitskontrollen einen stückweisen Ansatz, anstatt einen ganzheitlichen Ansatz zu verfolgen. Sehr oft befinde ich mich in der folgenden Situation:

  1. Ein Sicherheitsexperte identifiziert eine ganz bestimmte Schwachstelle.

  2. Die Organisation identifiziert eine Kontrolle oder ein Marktprodukt, das diese Schwachstelle beseitigt.

  3. Die Schwachstelle kann durch die Lösung aus Schritt 2 behoben werden, aber eine größere Anzahl von Schwachstellen kann weiterhin bestehen. Eine solche Kontrolle kann eine Lösung bieten, ohne die breiteren Auswirkungen der Änderung auf die gesamte Anwendung zu berücksichtigen.

  4. Entweder ist die Kontrolle zu genau, so dass im Laufe der Zeit zusätzliche Kontrollen erforderlich werden, oder die Lösung ist zu weit gefasst, so dass sie den rechtmäßigen Aktivitäten der Entwickler/innen im Weg stehen kann.

Da punktuelle Lösungen (Lösungen, die ein enges, spezifisches Ziel verfolgen) oft Nebeneffekte haben, wie z. B. Reibungsverluste bei den Entwicklern, ist es fast unmöglich, die wahren Kosten einer Sicherheitskontrolle im Vergleich zu den potenziellen Auswirkungen des Risikos zu beziffern. Es gibt eine Reihe von Faktoren, die die Fähigkeit von Unternehmen einschränken können, einzelne Schwachstellen zu beseitigen, z. B. Kosten, Zeitpläne und Umsatzziele.

Eine Sicherheitsrichtlinie ist ein abstrakter Plan, der die Vision für die Identifizierung und Implementierung von Sicherheitskontrollen weiter fasst. Sicherheitsrichtlinien definieren die Rolle, die Sicherheit und Kontrollen in einer Organisation spielen. Der Zweck einer Sicherheitspolitik ist es, die Kosten eines potenziellen Vorfalls zu quantifizieren und mit den Kosten für die Umsetzung einer Gegenmaßnahme zu vergleichen. Bei den Kosten kann es sich entweder um monetäre Kosten oder um Kosten für die betriebliche Effizienz der Organisation handeln (etwas, das wertschöpfenden Aktivitäten im Wege steht). Die Sicherheitsrichtlinien geben dem Sicherheitsteam einen Überblick, der ihnen hilft, die richtigen Kontrollen für die jeweilige Aufgabe auszuwählen und zu entscheiden, ob die vorhandenen Kontrollen akzeptabel sind oder verbessert werden müssen, um effektiv zu sein.

Tipp

Wenn die Sicherheitskontrollen die Hebel sind, mit denen das potenzielle Risiko einer Anwendung eingestellt werden kann, gibt eine Sicherheitsrichtlinie vor, wie stark jeder dieser Hebel gezogen werden muss, um den Sweet Spot zu finden, der für die Unternehmensleitung akzeptabel ist. Eine Sicherheitsrichtlinie sollte auf einer hohen Ebene angesiedelt sein und ein breites Spektrum an Bedrohungen aufzeigen, vor denen du dich schützen willst. Dies ermöglicht es den Implementierern, innovativ zu sein und ein breiteres Spektrum an Tools zu entwickeln, die gut in dein Unternehmen passen.

Bei der Entwicklung einer Sicherheitsstrategie ist es wichtig, an die drei Arten von Bedrohungen zu denken: mögliche, plausible und wahrscheinliche. Viele Bedrohungen sind möglich. Eine deutlich kleinere Teilmenge dieser Bedrohungen ist plausibel. Und eine noch kleinere Gruppe von Bedrohungen ist wahrscheinlich. Für Unternehmen, bei denen die Auswirkungen von Sicherheitsvorfällen unbedeutend sind, ist es vielleicht nicht ratsam, Kontrollen gegen jede mögliche Bedrohung einzurichten, aber es ist sicherlich eine gute Idee, Kontrollen gegen alle wahrscheinlichen Bedrohungen einzurichten. Andererseits kann es sich ein Unternehmen, das in einer sensiblen Branche tätig ist, nicht leisten, einige mögliche Bedrohungen zu ignorieren, auch wenn sie nicht plausibel oder wahrscheinlich sind.

Hinweis

Das Hauptziel dieses Buches ist es, Organisationen dabei zu helfen, Kontrollen auf der Grundlage einer gut formulierten Sicherheitspolitik zu entwickeln und umzusetzen. Um die Effektivität der Kontrollen in Unternehmen zu ermitteln, können verschiedene Kennzahlen verwendet werden, wie z. B. die des Center for Internet Security Benchmarks.

Sicherheitsvorfälle und die CIA-Triade

Von einem Sicherheitsvorfall spricht man, wenn eine potenzielle Bedrohung realisiert wird - mit anderen Worten: eine Schwachstelle wurde ausgenutzt (möglicherweise von einem böswilligen Akteur).

Jeder Sicherheitsvorfall kann einen von drei verschiedenen Parametern gefährden: Vertraulichkeit, Integrität und Verfügbarkeit. Zusammen werden sie als CIA-Dreiklang der Informationssicherheit bezeichnet:

Vertraulichkeit
Ein Sicherheitsvorfall, bei dem Daten oder Informationen an Personen weitergegeben werden, die keinen Zugriff auf diese Informationen haben, beeinträchtigt die Vertraulichkeit des Systems. Beispiele für solche Vorfälle sind Lecks in sensiblen Daten, Kennwortlecks usw.
Integrität
Ein Sicherheitsvorfall, bei dem eine unbefugte Änderung in das System eingedrungen ist und zu einem unerwünschten Zustand geführt hat, wird als Beeinträchtigung der Integrität des Systems bezeichnet. Beispiele für solche Vorfälle sind Datenmanipulationen, Viren, Ransomware und so weiter.
Verfügbarkeit
Ein Sicherheitsvorfall, bei dem ein böswilliger Akteur das System überfordert und es daran hindert, seine üblichen Aufgaben zu erfüllen, wird als Beeinträchtigung der Verfügbarkeit des Systems bezeichnet. Beispiele für einen solchen Vorfall sind Brute-Force-Angriffe, Denial-of-Service-Angriffe (DoS) und mehr.

Jeder Sicherheitsvorfall oder Angriff kann negative Auswirkungen auf einen oder mehrere dieser Parameter haben. Als Sicherheitsexperten ist es unsere Aufgabe, die Auswirkungen eines solchen Risikos zu quantifizieren und sie mit den Kosten für die Gegenmaßnahmen zu vergleichen, die zur Verhinderung eines solchen Ereignisses ergriffen werden müssen.

AWS-Modell der geteilten Verantwortung

Ich habe bereits über die Verantwortung im Zusammenhang mit der Sicherheit gesprochen - als Sicherheitsexperte ist es wichtig zu wissen, wer für den Schutz vor bestimmten Bedrohungen für die auf AWS gehosteten Anwendungen verantwortlich ist. An dieser Stelle kommt das AWS Shared Responsibility Model (SRM) ins Spiel. Wenn du das SRM verstehst, kannst du potenzielle Bedrohungen und Schwachstellen erkennen, für die du Gegenmaßnahmen ergreifen musst, anstatt dich darauf zu verlassen, dass AWS dies automatisch tut.

Eine einfache Möglichkeit, die Aufteilung der Verantwortung zwischen AWS und dem Kunden zu verstehen, ist, dass AWS für die Sicherheit der Cloud verantwortlich ist. Das bedeutet, dass AWS für den Schutz der Infrastruktur verantwortlich ist, die alle von AWS angebotenen Dienste unterstützt. Dazu gehört auch die physische Sicherheit der Maschinen, auf denen die Anwendung läuft, vor Diebstahl. AWS übernimmt die Verantwortung dafür, dass deine Anwendung in einer virtualisierten Umgebung läuft, die logisch von anderen Clients getrennt ist.

Auf der anderen Seite ist der Kunde für die Sicherheit der Anwendung in der Cloud verantwortlich. Das regelmäßige Aufspielen von Sicherheits-Patches für die Software und die Implementierung von Zugriffskontrollen, Verschlüsselung und Authentifizierung gehören zu den Pflichten, die AWS von seinen Kunden erwartet.

Warnung

Noch wichtiger ist, dass die Kunden auch die richtigen Konfigurationen für eine sichere Datenverarbeitung im Einklang mit ihren Sicherheitsrichtlinien haben.

Eine Ausnahme von der oben genannten Faustregel sind die verwalteten AWS-Services, bei denen AWS eine größere Verantwortung übernimmt als nur den Schutz der physischen Cloud-Infrastruktur. Darauf werde ich später in diesem Kapitel noch näher eingehen.

Tipp

Wenn du in einer Umgebung arbeitest, in der die Einhaltung von Vorschriften erforderlich ist und häufige Compliance-Audits durchgeführt werden, stellt AWS seine gesamte Compliance-bezogene Dokumentation in AWS Artifact zusammen. Die auf AWS Artifact verfügbare Dokumentation umfasst Compliance-Berichte und Bescheinigungen für verwaltete AWS-Services. Mit AWS Artifact kannst du die Prüfer von der Einhaltung der Vorschriften für verwaltete AWS-Services und damit auch für deine Softwareanwendung überzeugen.

Cloud Architektur und Sicherheit

Bei der Entwicklung sicherer Systeme geht es darum, Softwareanwendungen aus einer übergeordneten Systemperspektive zu betrachten. Architekten sehen in der Regel den Wald vor lauter Bäumen nicht und entwerfen abstrakte Designprinzipien, während sie die Umsetzung den Entwicklern überlassen. Eine sichere Architektur dient als Grundlage für bessere Sicherheitskontrollen. Du kannst die Sicherheit deiner Anwendung erhöhen, indem du beim Entwurf der Anwendung einige grundlegende Sicherheitsprinzipien beachtest. In dem Buch Enterprise Security Architecture von Nicholas Sherwood (CRC Press) erfährst du viel über die Grundsätze der Sicherheitsarchitektur.

Obwohl die Prinzipien der Informationssicherheitsarchitektur schon vor Microservices und Cloud-Systemen bekannt waren, haben Forscher Wege gefunden, die Vorteile von Cloud-basierten Microservice-Systemen zu nutzen, um das Gesamtrisiko deiner Anwendung zu verringern. In diesem Abschnitt gehe ich auf einige dieser Architekturmuster ein. Diese Muster schließen sich nicht gegenseitig aus. Mit ihrer Hilfe werde ich darlegen, warum Cloud-basierte Microservices das Risiko für deine Anwendungen verringern.

Sicherheit durch Modularität

Die meisten modernen Anwendungen sind komplex. Bei einem systemischen Ansatz der Softwareentwicklung wird eine Softwareanwendung aus kleineren, leichter zu verwaltenden Modulen zusammengesetzt. Eine modulare Anwendung ist eine Anwendung, die in kleinere Teile zerlegt werden kann, die unabhängig voneinander bearbeitet werden können. Eine modulare Anwendung ist leichter zu patchen und somit leichter von Schwachstellen zu befreien. Die Modularisierung ist der wichtigste Vorteil von Microservices.

Aus der Sicht von Sicherheitsexperten ist es einfach, eine Sicherheitsrichtlinie für modulare Anwendungen zu erstellen, da eine solche Richtlinie flexibler sein kann und sich besser an die Konturen deiner Anwendung anpassen lässt.

Sicherheit durch Einfachheit

Einfache Systeme sind leichter zu sichern als komplexe. Komplexe Software kann destabilisierend wirken, wenn du sie nicht gut verwalten kannst. Schwachstellen in kleinen, isolierten Anwendungen sind leichter zu erkennen und zu beheben als in größeren, komplexen Projekten. Um eine Metapher für Gebäude zu verwenden: Kleine Gebäude mit begrenzten Eingängen sind leichter zu sichern als komplizierte Labyrinthe. Wenn deine Anwendungen also klein sind, kannst du Schwachstellen beseitigen, bevor sie zur Bedrohung werden, und so das Risiko für deine Anwendungen verringern.

Eine große modulare Anwendung, die aus kleineren, einfacheren Modulen besteht, ist leichter zu verwalten und sicherer. Ein Leitprinzip bei der Entwicklung sicherer Anwendungen ist daher, sie so einfach wie möglich zu gestalten. Jede Abweichung von der Einfachheit sollte nicht nur im Hinblick auf die Verwaltbarkeit, sondern auch auf die Sicherheit geprüft werden, da es von Natur aus schwieriger ist, komplizierte Anwendungen zu sichern.

Hinweis

Meiner Erfahrung nach werden die Begriffe komplex und kompliziert austauschbar verwendet, um Softwarearchitekturen zu beschreiben. In Wirklichkeit sind sie aber nicht dasselbe. Eine Softwarearchitektur ist komplex, wenn sie aus einer Vielzahl kleinerer, aber einfacherer Anwendungen besteht. Komplexität ist eine notwendige Folge des Umfangs. Komplizierte Software kann monolithisch sein und große Komponenten enthalten, die nicht leicht zu verstehen oder zu sichern sind. Die Wartung komplizierter Software kann spezielle Fähigkeiten erfordern. Unternehmen sollten es vermeiden, ihre Anwendungen kompliziert zu machen.

Sicherheit durch vollständig gemanagte AWS-Services

Ich habe den AWS SRM erwähnt, in dem ich darüber gesprochen habe, dass AWS für die "Sicherheit der Cloud" verantwortlich ist. Die AWS Managed Services sind eine Möglichkeit, zusätzliche Verantwortung auf AWS abzuwälzen.

Bei einem Managed Service übernimmt AWS einen größeren Teil der Verantwortung für den Betrieb einer bestimmten Infrastruktur für den Nutzer. Für den Betrieb von MySQL bietet AWS den AWS Relational Database Service (RDS) an, der den Endnutzern mehrere MySQL-Optionen bietet. Bei AWS RDS übernimmt AWS die Verantwortung für den Betrieb und das Patchen der Datenbank-Engine sowie des zugrunde liegenden Betriebssystems. AWS hält das zugrundeliegende Betriebssystem auf dem neuesten Stand und beseitigt alle Schwachstellen, die darauf bestehen könnten.

Warnung

Nur weil du einen AWS Managed Service nutzt, heißt das nicht automatisch, dass du keine Verantwortung für die Sicherheit hast. Du bist möglicherweise immer noch dafür verantwortlich, den Zugang zu den Services zu kontrollieren und Firewalls und andere grundlegende Sicherheitsmaßnahmen zu konfigurieren. Wenn du einen Managed Service nutzt, ist es wichtig herauszufinden, wie viel der Sicherheitsverantwortung von AWS übernommen wird und wie viel noch bei dir als Kunde liegt.

Mit verwalteten AWS-Services kannst du die Verantwortung deines Sicherheitsteams reduzieren und dein Unternehmen skalieren, ohne den Fokus zu verlieren. Wenn du eine bestehende Komponente deiner Infrastruktur durch einen AWS Managed Service ersetzt, kannst du darauf vertrauen, dass AWS dir die richtigen Gegenmaßnahmen zur Verfügung stellt, um das Risiko deiner Anwendung zu verringern.

Tipp

Der Einsatz von Managed Services kann auch den Aufwand für die Erfüllung von Compliance-Anforderungen verringern, da die meisten Managed Services die meisten regulatorischen Anforderungen (HIPAA, HITRUST, GDPR, SOC, NIST, ISO, PCI und FedRAMP) erfüllen. Im Laufe des Buches werde ich die Nutzung einer Flotte von verwalteten AWS-Services empfehlen, die zur Erhöhung der Sicherheit beitragen.

Explosionsradius, Isolation und die Analogie der verschlossenen Räume

Lassen Sie mich noch einmal auf den Prozess der Bedrohungsmodellierung zurückkommen. Bei diesem Prozess identifizierst du Schwachstellen in der Anwendung und überlegst dir dann, welche Bedrohungsakteure diese ausnutzen könnten. Du erstellst hypothetische Szenarien, in denen du davon ausgehst, dass der böswillige Akteur diese Schwachstelle tatsächlich ausgenutzt und unberechtigte Probleme in deiner Anwendung verursacht hat, die sich auf alle CIA-Kennzahlen auswirken, die du verfolgt hast.

Die Teile deiner Anwendung, auf die der hypothetische Bedrohungsakteur in deinem Bedrohungsmodellierungsszenario Einfluss nehmen kann, werden als Explosionsradius (auch als Angriffsfläche bezeichnet) deiner Anwendung bezeichnet.

In einem gut durchdachten System solltest du diesen Radius so klein wie möglich halten. Selbst wenn es einem Bedrohungsakteur gelingt, sich unbefugt Zugang zu verschaffen, kann der Rest der Anwendung weiter funktionieren. Aus architektonischer Sicht lässt sich das Ziel, den Explosionsradius zu verringern, mit dem Konzept der Isolation erreichen. Du kannst dir eine große modulare Anwendung wie eine Reihe von verschlossenen Räumen in einem Gebäude vorstellen. Die Tatsache, dass einer der Räume von einer unbefugten Person aufgebrochen wurde, bedeutet nicht, dass dies auch bei den anderen Räumen der Fall sein wird. Du kannst eine modulare Anwendung haben, bei der die einzelnen Module voneinander isoliert sind und eine starke Authentifizierung erfordern. Der Bedrohungsakteur kann dann nur auf das Modul beschränkt werden, in das er eindringen konnte, während der Rest der Anwendung sicher und funktionsfähig bleibt.

Defense-in-Depth und Sicherheit

Hast du dich jemals gefragt, warum es in Flugzeugen immer noch Aschenbecher gibt, obwohl das Rauchen in allen kommerziellen Flügen seit Jahrzehnten verboten ist? Bei der Einweisung vor dem Start wirst du daran erinnert, dass es eine Straftat ist, den Rauchmelder in der Toilette zu manipulieren. Dort gibt es auch ein Schild, das dich an dieses Gesetz erinnert, aber direkt unter dem Schild findest du einen Aschenbecher. 2009 wurde ein Flug mit einem Flugverbot belegt, weil es keinen Aschenbecher gab.

Die Federal Aviation Authority (FAA) erklärt, dass es trotz des Rauchverbots immer noch einige Leute schaffen, Zigaretten einzuschmuggeln und auf Flügen zu rauchen. Nach dem Rauchen können die Passagiere die Zigarettenstummel in die Abfallbehälter werfen, was eine Brandgefahr darstellen kann. Aus Sicherheitsgründen erhöht dies das Risiko, dass ein Flugzeug in Brand gerät. Ein Aschenbecher stellt sicher, dass die Passagiere, die ihre Zigaretten mit an Bord nehmen, einen sicheren Platz haben, um sie zu verdrücken. Aschenbecher sind die Kontrollen, die das Brandrisiko verringern.

Du fragst dich vielleicht, warum die Sicherheitskontrollen an den Flughäfen nicht verschärft werden, um sicherzustellen, dass die Passagiere keine Zigaretten an Bord des Flugzeugs mitnehmen können, wenn das Rauchen während des Fluges so gefährlich ist? Warum wird die kostspielige Installation von redundanten Aschenbechern in jedem Flugzeug auf der ganzen Welt gefordert?

Die Antwort liegt in einem Sicherheitskonzept namens Defense-in-Depth. Es hat sich gezeigt, dass mehrschichtige, manchmal redundante oder sogar veraltete Kontrollen in sicheren Systemen effektiver sind als eine einzelne punktbasierte Lösung. Es hat sich gezeigt, dass mehrere Kontrollen, die auf verschiedenen Ebenen verteilt sind, zu einem geringeren Risiko für die Anwendung führen, als eine einzige, absolut zuverlässige Kontrolle. Bei der Entwicklung jeder Kontrolle gehst du davon aus, dass eine vorgeschaltete Kontrolle beim Stoppen eines Eindringlings fehlschlägt. So wird sichergestellt, dass es keinen Single Point of Failure gibt. Bei Fluggesellschaften gehst du davon aus, dass die Sicherheitskontrollen am Flughafen beim Auffangen der Zigaretten fehlgeschlagen sind und daher der Aschenbecher eingesetzt wird, um das Brandrisiko weiter zu verringern.

In sicheren Systemen musst du oft die Wirksamkeit jeder einzelnen Kontrolle unabhängig voneinander bewerten. Oft erscheint das Vorhandensein mehrerer Kontrollen überflüssig, aber mit Defense-in-Depth kannst du ihr Vorhandensein und ihren Einsatz rechtfertigen. In diesem Buch werde ich immer wieder die Einführung mehrerer Kontrollen empfehlen. In Kapitel 5 empfehle ich zum Beispiel Kontrollen, die auf der Netzwerkebene wirken, während ich in Kapitel 7 die Transitverschlüsselung bespreche, die hauptsächlich auf der Transportebene wirkt.

Hinweis

Wenn du dich umschaust, kannst du überall Beispiele für eine gründliche Verteidigung sehen, in vielen verschiedenen Lebensbereichen. Gebäude mit Sprinkleranlagen haben immer noch Feuerlöscher. Gebäude mit starken Sicherheitsvorkehrungen an den Eingängen haben immer noch Schlösser an den Türen der einzelnen Büroräume. Sich überschneidende Sicherheitskontrollen schützen uns vor dem Versagen einzelner Kontrollen, und eine solche Realität zu akzeptieren, hilft bei der Entwicklung einer Strategie des sicheren Denkens.

Sicherheit durch Perimeterschutz

Zu Beginn dieses Abschnitts muss ich zugeben, dass ich ein Zyniker dieses Ansatzes bin. Bei diesem Ansatz errichten Unternehmen eine starke Firewall gegen alle Anfragen, die aus dem öffentlichen Internet kommen. Diese Firewall wird als Perimeter bezeichnet, der deine Anwendung vor externen Bedrohungen schützt. Die Mitarbeiter/innen an entfernten Standorten werden dann mit VPN-Lösungen (Virtual Private Network) ausgestattet, damit sie eine ähnliche Erfahrung machen können wie ihre Kollegen/innen vor Ort. Im Zusammenhang mit Sicherheit bedeutet Vertrauen, dass man auf Systeme zugreifen kann, ohne dass überprüft wird, wer jemand ist oder warum er oder sie diesen Zugang benötigt. In dieser Architektur werden Benutzer oder Dienste innerhalb einer Vertrauensgrenze (in der Regel innerhalb des Rechenzentrums oder VPNs des Unternehmens) als vertrauenswürdig eingestuft und müssen daher keine zusätzliche Authentifizierungsebene durchlaufen. Hier geht man davon aus, dass die meisten Angreifer von außerhalb des Unternehmens kommen und dass vertrauenswürdige Nutzer nur die besten Absichten haben. Daher sind die Kontrollen in dieser Architektur hauptsächlich auf externe Bedrohungen ausgerichtet. Viele Sicherheitsexperten sagen, dass eine solche Architektur versucht, das Schloss gegen Angriffe von außen zu verteidigen. Viele Aufsichtsbehörden verlangen nach wie vor einen solchen Perimeterschutz, und wenn du in einer stark regulierten Branche arbeitest, hast du vielleicht keine andere Wahl, wenn es um Perimeterschutz geht.

Sicherheit durch Zero Trust Architektur

In den letzten Jahren hat sich gezeigt, dass sowohl externe als auch interne Angreifer eine ernsthafte Bedrohung für Unternehmen darstellen. Die Vorstellung, dass eine robuste Absicherung der Außengrenzen ausreicht, um Sicherheit zu erreichen, ist überholt. Daher wird in vielen modernen Organisationen eine Zero-Trust-Architektur eingesetzt. Eine Zero-Trust-Architektur geht davon aus, dass Bedrohungen für deine Anwendung allgegenwärtig sind (intern und extern). Daher kannst du internen Diensten nicht vertrauen und musst Kontrollen einführen, da du davon ausgehst, dass böswillige Akteure innerhalb deiner Vertrauensgrenzen arbeiten. Mit anderen Worten: Dieses Modell geht davon aus, dass die Angreifer bereits innerhalb deiner Burgmauern sind und du statt deine Burg zu schützen, daran denken musst, alle deine Ressourcen einzeln zu schützen. Viele aufsehenerregende Vorfälle der letzten Zeit wurden in der Tat von vertrauenswürdigen Insidern oder böswilligen Akteuren, die sich als Insider ausgaben, verursacht, wie z. B. der Einbruch bei Capital One 2019. Daher ist eine Zero-Trust-Architektur vorzuziehen.

Kapitel 8 stellt dir einige der Tools vor, die AWS anbietet und die dir helfen, eine Zero-Trust-Architektur in deinem Unternehmen zu implementieren und gleichzeitig die Reibung mit deinem Entwicklungsteam zu verringern.

Hinweis

Ich bin nicht der Einzige, der für eine Zero-Trust-Architektur eintritt. Am 12. Mai 2021 unterzeichnete US-Präsident Joe Biden einen Erlass, der die Informationssicherheitsarchitektur der USA verbessern soll. Im Rahmen dieser Anordnung wurde die Bundesregierung unter anderem damit beauftragt, "einen Plan zur Umsetzung einer Zero-Trust-Architektur zu entwickeln ".

Eine kurze Einführung in die Software-Architektur

Auch wenn du die Grundlagen von Microservices und ihre Vorteile vielleicht schon kennst, möchte ich kurz die Grundlagen des Designs von Microservices auffrischen. Die Anwendungsarchitektur verfolgt in der Regel einen systemorientierten Ansatz beim Softwaredesign. Der Großteil der Unternehmenssoftware besteht aus kleineren Teilen, die zusammengefügt werden, um das gewünschte System zu schaffen.

Tier-basierte Architektur

Betrachte eine typische E-Commerce-Website-Anwendung. Angenommen, diese Anwendung unterstützt vier Endbenutzeraktionen:

  • Ein Nutzer kann einen Artikel kaufen.

  • Ein Nutzer kann einen Artikel zurückgeben.

  • Ein Nutzer kann sein Guthaben überprüfen.

  • Ein Nutzer kann das verfügbare Angebot an Waren überprüfen.

Das Ziel einer mehrschichtigen (layered) Architektur ist es, die Funktionen für die Präsentation (Benutzeroberfläche), die Anwendungsverwaltung und die Datenverwaltung voneinander zu trennen. Diese Art der Architektur ist der De-facto-Standard für die meisten Anwendungen, vor allem wegen ihrer Einfachheit, Vertrautheit und geringen Kosten. Abbildung 1-1 zeigt eine typische mehrstufige Anwendung.

Der Stil der Schichtenarchitektur hat zwar viele Vorteile, aber auch einige deutliche Nachteile. Einer davon ist die mangelnde Agilität und Skalierbarkeit, die zur Entdeckung anderer Architekturstile geführt hat. Die Autoren Neal Ford und Mark Richards gehen in ihrem Buch Fundamentals of Software Architecture (O'Reilly) ausführlich auf alle Fallstricke eines solchen Designs ein.

Abbildung 1-1. Bei einem mehrschichtigen Ansatz kann die Anwendungslogik in verschiedene Schichten unterteilt werden , je nachdem, in welcher Schicht die Anwendung läuft.

Domänenorientiertes Design

Im Gegensatz zum traditionellen tierbasierten Ansatz steht das domain-driven Design (DDD). Bei DDD wird davon ausgegangen, dass jedes Softwareprogramm einen Bezug zu einer Tätigkeit oder einem Interesse des Nutzers oder der Geschäftsfunktion hat. Ein Architekt kann die Anwendung so unterteilen, dass sie mit den Geschäfts- und Funktionseinheiten übereinstimmt, indem er die Anwendungslogik der funktionalen Domäne zuordnet (und manchmal auch noch granularer in Subdomänen).

Wenn du zum Beispiel die Dienste aus Abbildung 1-1 nach ihren Domänen (und Subdomänen) gruppieren würdest, würdest du drei funktionale Domänen sehen, die es gibt:

Inventar oder Produktbereich
Dieser Bereich befasst sich mit allen Dienstleistungen rund um die Produktverwaltung. Dazu gehört auch, den Überblick über den Bestand an Produkten, Preisen und Beschreibungen zu behalten.
Kundenbereich
Dieser Bereich ist für die Annahme von Kundenanfragen zuständig, z. B. für das Auschecken aus der Anwendung oder die Rückgabe von Artikeln.
Bereich Finanzen
Er ist für die Abrechnung mit dem Kunden verantwortlich und behält den Überblick über die Salden und alle anderen Geldbewegungen.

Wenn du die Dienste aus Abbildung 1-1 in funktionale Domänen aufteilst, könnte es etwa so aussehen wie in Abbildung 1-2.

Abbildung 1-2. Dieselbe Anwendung aus Abbildung 1-1 mit denselben modularen Komponenten kann mit DDD auf andere Weise aufgeteilt werden. Mit DDD bleiben die Geschäftsbereiche erhalten, während die Anwendungen aufgeteilt werden.

Bei einem domänenorientierten Ansatz ist es wahrscheinlicher, dass Dienste, die eine gemeinsame Geschäftsdomäne abdecken, eine enge Beziehung zueinander haben und daher sinnvollerweise in Gruppen zusammengefasst werden. Außerdem erleichtert DDD die Verwaltung größerer Geschäftsprojekte, da die Softwarearchitektur besser auf die Geschäftsanforderungen abgestimmt werden kann. Solche Gruppen werden in der Regel als Bounded Contexts bezeichnet. Die Dienste innerhalb eines Bounded Contexts stehen in einer engen Beziehung zueinander, während jede Interaktion mit einer externen Einheit als formal definierter Vertrag betrachtet werden kann. Umgekehrt sollten alle Dienste innerhalb eines begrenzten Kontexts nur lose Beziehungen zu allen Diensten haben, die außerhalb ihres begrenzten Kontexts liegen.

Innerhalb eines begrenzten Kontexts sind Anwendungen auf Interoperabilität ausgelegt. Sie sprechen sprichwörtlich die gleiche Sprache. In einer idealen Welt sollten ein Bounded Context und eine Subdomain die gleichen Dienste haben. In der Praxis kann es jedoch zu Unterschieden kommen, vor allem, wenn ältere Softwaresysteme beteiligt sind.

Microservices

Was macht also eine Architektur zu einer Microservice-Architektur? Im Gegensatz zu einer monolithischen Anwendung besteht eine Microservice-basierte Anwendung aus einer großen Anzahl von leichtgewichtigen Diensten, die:

Unabhängig eingesetzt
Du kannst einzelne Dienste aktualisieren, patchen oder entfernen, ohne den Rest der Anwendung zu beeinträchtigen.
Unabhängig skalierbar
Du kannst einzelne Dienste vergrößern oder verkleinern, wenn einzelne Teile der Anwendung zusätzlich belastet werden, ohne den Rest der Anwendung zu beeinträchtigen.
Lose gekoppelt
Verschlechterungen oder Änderungen an einzelnen Diensten sollten sich nicht auf den Rest der Anwendung auswirken.
Domänenorientiert
Die Dienste werden modularisiert und in Kontexte gruppiert, je nachdem, zu welchen Geschäftsbereichen sie gehören.
Verantwortlich für eine einzelne Geschäftsaufgabe
Microservices sollen dem Single-Responsibility-Prinzip (SRP) folgen.

Ein wichtiger Schritt bei der Definition einer Microservice-Architektur ist es, herauszufinden, wie groß ein einzelner Microservice sein muss. Was einen Microservice von einer normalen Anwendung unterscheidet, ist, dass ein Microservice dem SRP folgen muss.

Die SRP schlägt vor, dass jeder Microservice einen einzelnen Teil der Funktionalität einer Anwendung kapselt. Dadurch wird sichergestellt, dass jeder Microservice schlank, leichtgewichtig, unabhängig von der Bereitstellung und einfach zu verstehen ist.

Wenn du nach Online-Literatur über Microservices suchst, findest du sie oft im Allgemeinen mit LEGO®-Steinen verglichen. Für einen Microservice-Architekten besteht jede große Anwendung aus mehreren Microservices, die ähnlich wie ein LEGO-Bauwerk zusammengesetzt sind. Innerhalb dieser Anwendungen wird von den einzelnen Microservices erwartet, dass sie dem SRP folgen. Diese einzelnen Dienste sollen auch autonom sein und nur begrenzt oder gar nicht von anderen Diensten abhängig sein.

Tipp

Im Laufe des Buches werde ich sehr häufig auf das SRP verweisen. Es ist das wichtigste Prinzip, an das man sich beim Entwurf von Microservice-Architekturen erinnern muss.

In "Cloud-Architektur und Sicherheit" habe ich dir versprochen, dass Cloud-Microservice-Architekturen dabei helfen werden, die dort erwähnten sicheren Entwurfsmuster zu realisieren. Mithilfe der formalen Definition von Microservices kannst du sicher sehen, warum:

Sicherheit durch Modularität
Da Microservice-Anwendungen per Definition aus kleinen, modularen Diensten bestehen, lassen sich Sicherheitskontrollen leicht implementieren.
Sicherheit durch Einfachheit
Da jeder modulare Microservice klein ist und dem SRP folgt, ist es viel einfacher, das Ziel der Einfachheit in einer Microservice-Architektur zu erreichen.
Sicherheit durch Isolation
Da Microservices dem DDD folgen, ist es einfacher, eine isolierte Umgebung zu schaffen, um einzelne Microservices auszuführen.
Sicherheit durch eine Zero-Trust-Architektur
Durch die bessere Nutzung des AWS SRM und die Nutzung der granularen Kontrollen, die Microservice-Architekturen bieten, ist es möglich, eine Zero-Trust-Architektur einfach zu implementieren .

Zusammenfassend lässt sich sagen, dass Microservices atomare und diskrete Geschäftsfunktionen sind, die jeweils eine Funktion haben. Microservice-Entwickler sollten die Freiheit haben, das Werkzeug zu wählen, das ihnen den besten Nutzen bringt, während sie ihren spezifischen Microservice so gestalten, dass er die einzelne Aufgabe erfüllt, die er erfüllen soll. Als Architekt, der für die Integration dieser einzelnen Microservices in eine größere, zusammenhängende Anwendung verantwortlich ist, solltest du dich in erster Linie um die Geschäftsfunktion des Microservices kümmern. Alles andere ist nur ein Hintergrundgeräusch und sollte nicht die politischen Entscheidungen bestimmen.

Implementierung von Microservices auf AWS

Es gibt keine Regel dafür, wie ein Microservice tatsächlich implementiert werden sollte. Dennoch ist es wichtig, die Anwendung zu modularisieren und diese Module lose miteinander zu koppeln, damit diese Dienste eigenständig ausgetauscht, erweitert, ersetzt oder skaliert werden können.

In den letzten Jahren hat es aus verschiedenen Gründen eine Konsolidierung in der Branche gegeben, bei der sich viele Organisationen für einen von zwei Wegen entschieden haben:

Container-basierter Ansatz
Bei diesem Ansatz werden die Microservices in leichtgewichtige, autonome Container (z. B. Docker-Container) gekapselt, die auf einer Container-Engine wie der Docker-Engine ausgeführt werden. Solange es eine Docker-Engine gibt, die diese Container ausführen kann, können die Entwickler/innen jedes beliebige Tool, jede Sprache oder Laufzeitumgebung verwenden, um diese Dienste zu schreiben. Auf jedem physischen Server ( Node genannt) läuft die Docker-Engine, und auf ihm können mehrere Container bereitgestellt werden.
FaaS-basierter Ansatz
Bei diesem Ansatz wird die Geschäftsfunktion direkt auf einer Function as a Service (FaaS) Plattform ausgeführt. Anstatt deine Anwendung in einem Container zu verpacken, schreibst du deine Geschäftsfunktion in einer standardisierten Weise, sodass sie direkt auf einer Cloud-Plattform ausgeführt werden kann, die die Verantwortung für den sicheren Betrieb an den Cloud-Provider abgibt.

Beide Optionen haben aus Sicht der Sicherheit und Skalierbarkeit Vorteile und Einschränkungen. Es gibt eine Menge Online-Literatur über beide Ansätze und ihre Kompromisse. (Einen tollen Artikel über Container-basierte Microservices habe ich in einem Blog von Severless gelesen.) In diesem Buch werde ich mich darauf konzentrieren, wie man die Sicherheit bei beiden Ansätzen erhöhen kann, indem man die Tools nutzt, die AWS uns zur Verfügung stellt.

Container-basierte Microservice-Architektur

Um auf die SRP zurückzukommen: Da alles andere außerhalb der Geschäftsfunktion des Microservices Hintergrundgeräusche sind, wäre es nicht großartig, wenn wir die Geschäftsfunktion und alle ihre Abhängigkeiten in eine dedizierte virtuelle Sandbox-Umgebung packen und überall einsetzen könnten? Das ist der Container-Ansatz für Microservices.

Bei diesem Ansatz wird die gesamte Geschäftslogik zusammen mit allen Abhängigkeiten in einen leichtgewichtigen, portablen und implementierbaren Container verpackt. Dieser Container enthält die Geschäftsfunktion, die der Microservice ausführen soll, sowie die genauen Anweisungen, die erforderlich sind, um diesen Anwendungscode überall und in jeder Umgebung auszuführen, die die Ausführung eines solchen Containers unterstützt. Derselbe Container (zusammen mit seiner Anwendungslogik) wird in verschiedenen Entwicklungsumgebungen getestet und in deiner Anwendungsumgebung eingesetzt. Dieser Container kann je nach Bedarf der Anwendung skaliert, aufgerüstet oder ausgetauscht werden. Docker hat sich in der Branche als beliebte Containertechnologie erwiesen, deshalb werde ich in diesem Buch Docker für meine Beispiele verwenden.

Deine gesamte Anwendung ist nun ein Geflecht aus solchen Containern, die die für den Betrieb der Anwendung erforderlichen Geschäftsfunktionen bereitstellen. Bei der Implementierung eines containerbasierten Ansatzes erstellt der Architekt in der Regel ein Dokument (die so genannte Spezifikation), in dem festgelegt wird, welche Container in der Produktion laufen sollen, und das die Blaupause für deine gesamte Anwendung darstellt. Solange alle in der Spezifikation festgelegten Dienste verfügbar sind, gilt die Anwendung als gesund.

Abbildung 1-3 zeigt eine solche Anwendung, bei der containerisierte Microservices eingesetzt werden, um ein einheitliches Produktangebot bereitzustellen.

Abbildung 1-3. Docker-Container können ausgeliefert und eingesetzt werden, um ein einheitliches Produktangebot zu erstellen, das vollständig aus modularisierten und containerisierten Microservices besteht.

Aus Sicht der Sicherheit verlässt du dich auf Docker, um die Geschäftslogik zu isolieren und zu containerisieren. Da mehrere Container auf demselben physischen Server laufen können, verlässt du dich in hohem Maße auf die Fähigkeit der Docker-Engine, die einzelnen Container davon abzuhalten, den Code eines anderen Containers zu beeinträchtigen. Jede Schwachstelle, die es den Diensten eines Containers ermöglicht, das Host-Betriebssystem oder einen anderen Container zu beeinträchtigen, wird als Breakout-Schwachstelle bezeichnet. Technisch gesehen verlässt du dich also darauf, dass Docker die Verantwortung dafür übernimmt, Ausbrüche zu verhindern. Das bedeutet, dass du unbedingt sicherstellen musst, dass du die neuesten Versionen sowohl des Docker-Containers als auch der Engine, die diese Container betreibt, einsetzt.

Diese Container werden normalerweise in einer Container Registry gespeichert, einem speziellen Speichersystem für Docker-Container. Bei AWS können diese Container dann sicher in der Amazon Elastic Container Registry (ECR) gespeichert werden.

Tipp

Für einen detaillierten Überblick über Docker empfehle ich das Buch Docker: Up and Running von Sean Kane und Karl Matthias (O'Reilly).

Eine sehr kurze Einführung in Kubernetes

Obwohl jeder Docker-Container eine Einheit darstellt, willst du sie in den meisten Produktionsumgebungen zu einer zusammenhängenden Einheit verbinden. Container-Orchestratoren wie Kubernetes ermöglichen es dir, mehrere Docker-Container-basierte Microservices zu betreiben. Du kannst einen Kubernetes-Cluster anweisen, eine bestimmte Anzahl von Instanzen eines jeden Docker-Containers auszuführen, und Kubernetes kann sie für dich ausführen.

Die Einrichtung eines Kubernetes-Clusters ist das alleinige Thema vieler anderer Bücher und daher werde ich nicht ins Detail gehen. Aber ich werde dir den Kern dessen vermitteln, was ein Kubernetes-Cluster für dich tut. Wenn du dich mehr für den Einrichtungsprozess interessierst, empfehle ich dir Kubernetes in Action von Marko Luksa (Manning Publications). Auch in der offiziellen Dokumentation zu Kubernetes findest du tolle Materialien, die dir beim Betrieb deines Clusters helfen können. Kubernetes ist, wie du vielleicht weißt, ein Orchestrator, mit dem du jederzeit eine beliebige Anzahl von Diensten ausführen kannst. Wenn du Kubernetes die Anzahl der Instanzen jedes Dienstes mitteilst, den du laufen lassen willst, spinnt es neue Container basierend auf der Konfiguration, die du in der Spezifikation festgelegt hast.

Die grundlegendste Microservice-Einheit in einem Kubernetes-Cluster ist ein Pod. Ein Pod ist eine Gruppe von einem oder mehreren Containern mit gemeinsamen Speicher- und Netzwerkressourcen. Ein Node ist ein Arbeitsrechner in Kubernetes und kann entweder ein virtueller oder ein physischer Rechner sein. Kubernetes führt deine Microservices aus, indem es Container in Pods zusammenfasst, die auf Nodes laufen. Wie du dir vorstellen kannst, kannst du einzelne Microservices skalieren, indem du neue Pods zu deinem Cluster hinzufügst. Pods virtualisieren die Laufzeit deines Microservices. Pods laufen auf der zugrunde liegenden Hardware, die durch Hinzufügen neuer Knoten zum Cluster skaliert werden kann. Der Teil des Kubernetes-Clusters, der die Pods verwaltet und ihre Orchestrierung erleichtert, wird als Control Plane bezeichnet. Abbildung 1-4 veranschaulicht diesen Aufbau.

Abbildung 1-4. Ein prägnanter Überblick über ein typisches Kubernetes-Setup.

Zusammenfassend lässt sich sagen, dass in einem Kubernetes-Setup das Hauptziel darin besteht, die Anwendungslogik auszuführen, die dann containerisiert und in einer Container-Registry gespeichert wird. Basierend auf den Spezifikationen, die du diesem Cluster zur Verfügung stellst, führen die Container diese Geschäftslogik auf den Knoten aus. Böswillige Akteure könnten entweder die Kontrollebene, die Speicherung der Container oder die Laufzeitumgebung der Anwendung (Nodes) angreifen, um unerwünschte Probleme in der Anwendung zu verursachen.

Tipp

Ich stelle mir die Spezifikation als das Rezept vor, das ich meinem Kubernetes-Cluster gebe. Anhand dieses Rezepts erstellt Kubernetes eine Liste mit allen Diensten (Containern), die es ausführen muss, holt alle Container aus der Container-Registry und führt diese Dienste auf meinen Knoten für mich aus. Auf diese Weise wird eine komplette Microservice-Anwendung auf der Grundlage meiner Vorgaben gestartet. Du kannst konfigurieren, wo diese Microservices, die in deiner Spezifikation angegeben sind, ausgeführt werden, indem du die Knoten in deinem Cluster konfigurierst.

AWS bietet dir zwei verwaltete Optionen für den Betrieb deines Kubernetes-Clusters:

  • AWS Elastic Kubernetes Service (Amazon EKS)

  • AWS Elastic Kubernetes Service, Fargate-Modus (Amazon EKS Fargate)

Da AWS die Verantwortung für die Ausführung, Skalierung und Bereitstellung deiner Funktionen auf AWS Lambda übernimmt, brauchst du keinen separaten Orchestrator.

Wie entscheidest du also, wie du deine Microservices betreiben willst? Da es um die Sicherheit geht, habe ich ein praktisches Flussdiagramm erstellt, das du für eine solche Entscheidung verwenden kannst (siehe Abbildung 1-5).

Abbildung 1-5. Ein Flussdiagramm, das Architekten bei der Entscheidung hilft, wie sie ihre Microservices betreiben wollen.

Der nächste Abschnitt geht auf die Details dieser Umsetzungsmethoden ein.

Hinweis

AWS Elastic Container Service (AWS ECS) ist ebenfalls eine Option, wenn du Container auf AWS orchestrieren möchtest. Obwohl sich ECS in seinem Angebot leicht von EKS unterscheidet, gibt es in puncto Sicherheit ziemlich viele Überschneidungen zwischen EKS und ECS. Um Wiederholungen zu vermeiden, werde ich mich daher auf Amazon EKS und AWS Lambda konzentrieren. Wenn du dich für einen ausführlichen Überblick über ECS interessierst, kannst du neben der AWS-Dokumentation auch das Buch Docker on Amazon Web Services von Justin Menga (Packt Publishing) lesen, das sich mit den Details beschäftigt.

Function as a Service: FaaS mit AWS Lambda

FaaS ist eine andere Art, Microservices anzugehen. AWS hat erkannt, dass die Geschäftslogik das Kernstück eines jeden Microservices ist. Daher bietet AWS eine Umgebung, in der Benutzer diese Logik ausführen können, ohne Container oder Pakete verwenden zu müssen. Du musst nur deine Geschäftsfunktion, die du in einer unterstützten Programmiersprache geschrieben hast, in die Cloud-Umgebung einbinden und direkt ausführen. AWS Lambda bietet diese Laufzeitfunktion. Abbildung 1-6 zeigt eine Microservice-Anwendung, in der AWS Lambdas eingesetzt werden, um ein einheitliches Produktangebot bereitzustellen.

Abbildung 1-6. Funktionen mit Geschäftslogik können in AWS Lambda bereitgestellt werden, um gemeinsam ein einheitliches Produktangebot bereitzustellen.

Das Tolle an AWS Lambda ist, dass AWS die Verantwortung für den Betrieb der Funktion übernimmt und dir damit einen Teil der Sicherheitsverantwortung im Rahmen des SRM abnimmt. In diesem Fall musst du dich nicht um die Sicherheit von Containern und Knoten kümmern und auch nicht um die Orchestrierung.

Überblick über die Cloud Microservice Implementierung

Aus der Sicherheitsperspektive gibt es viele Stellen, an denen Sicherheitsexperten Sicherheitsvorfälle in einer Microservice-Umgebung vorhersehen können. Ein typischer Microservice ist in Abbildung 1-7 dargestellt. In diesem Abschnitt wird kurz erläutert, was jede dieser Schichten bedeutet und wie ein Angreifer deine Anwendung auf jeder dieser Schichten ausnutzen könnte, um unbefugte Kontrolle zu erlangen:

Geschäftslogik

Manchmal auch als Funktions- oder Anwendungslogik bezeichnet, ist dies der Anwendungscode, der die Kerngeschäftsfunktion ausführt, auf die dein Microservice abzielt. Dieser Code ist sehr spezifisch für die Domäne und sollte sich an das SRP halten. Er kann auch in der vom Nutzer gewählten Programmiersprache geschrieben werden. Da dieser Code domänenspezifisch ist, ist es für böswillige Akteure möglich, diesen Code zu missbrauchen, um unerlaubte Aktivitäten durchzuführen.

Laufzeitumgebung (Containerumgebung)

Die Containerumgebung sollte die Sprachlaufzeitumgebung enthalten, die für die Ausführung der Anwendungslogik von Komponente 1 erforderlich ist. Dies ist die Umgebung, in der die Anwendungslogik in einer Sandbox-Umgebung läuft, wodurch die Laufzeit isoliert und der Aktionsradius des Microservices (bis zu einem gewissen Grad) begrenzt wird. Wie bei jeder Anwendungslaufzeit ist es jedoch wichtig, die Containerversion auf dem neuesten Stand zu halten und ältere Schwachstellen in den Containern und ihrer Laufzeit zu beheben, um die Sicherheit deiner Anwendung zu gewährleisten.

Container-Laufzeit (Container-Engine)

Dies ist die Software, mit der die Container der zweiten Komponente ausgeführt werden können. Da Microservices, die in Containern ausgeführt werden, in einer isolierten Sandbox-Umgebung laufen, muss sichergestellt werden, dass Sicherheitslücken in der Virtualisierungsschicht der Container-Laufzeit nicht das Host-Betriebssystem oder andere Container, die auf demselben Rechner laufen, beeinträchtigen. Diese Isolierung liegt in der Verantwortung der Container-Laufzeitumgebung. Solche ausbrechenden Schwachstellen können von Zeit zu Zeit entdeckt und von Docker sofort gepatcht werden. Deshalb ist es wichtig, die Container-Laufzeitumgebung ständig zu aktualisieren, um sicherzustellen, dass du die neueste Docker-Engine verwendest.

Virtuelle Maschine

Dies ist die virtuelle Maschine (VM), auf der du die Container-Engine laufen lassen wirst. Jede VM kann mehrere Container enthalten, auf denen Container laufen; du kannst mehrere Microservices auf jeder VM hosten. Da eine VM einem anderen Betriebssystem ähnelt, können Angreifer Schwachstellen auf Betriebssystemebene ausnutzen, insbesondere bei VMs, auf denen nicht die neueste Version des Betriebssystems läuft.

Physische Hardware

Dies ist die grundlegendste Schicht innerhalb der Microservice-Infrastruktur und bezieht sich auf die physische Hardware, die die für den Betrieb der Microservices erforderliche Rechenleistung bereitstellt. Wie jeder andere physische Gegenstand können auch diese Server durch Diebstahl, Vandalismus oder Hackerangriffe mit Hilfe von Flash-Laufwerken oder anderen physischen Geräten gefährdet sein .

Speicherung von Containern

Es ist üblich, vorgefertigte Container als Teil des Entwicklungsprozesses in speziellen Speichersystemen zu speichern. Wenn vorgefertigte Container nicht sicher aufbewahrt werden, kann ein Angreifer die erstellten Images manipulieren, indem er bösartigen Code in sie einschleust oder die Images auswechselt und durch bösartigen Code ersetzt.

Container-Orchestrierung

Ein Orchestrator trifft Entscheidungen darüber, wie viele Instanzen eines bestimmten Dienstes laufen müssen, um den Zustand der Anwendung zu erhalten. Mit der Orchestrierung kannst du Anwendungsdienste erstellen, die sich über mehrere Container erstrecken, Container in einem Cluster einplanen, diese Container skalieren und ihren Zustand im Laufe der Zeit verwalten. Ein Orchestrator sorgt dafür, dass die Dienste weiterlaufen oder neu gestartet werden, wenn sie ausfallen. Er kann auch Entscheidungen über die Skalierung von Diensten treffen, um sie an den Datenverkehr anzupassen.

Abbildung 1-7. Schematische Darstellung eines Microservices in einer Cloud-Umgebung.

In den nächsten Abschnitten werden die verschiedenen Optionen für die Microservice-Laufzeit erläutert und aus der Sicherheitsperspektive deine Verantwortung im Vergleich zu der von AWS übernommenen Verantwortung diskutiert. Ich beginne mit der Option, die dir innerhalb der drei Möglichkeiten die meiste Verantwortung überträgt, und schließe mit der Option, bei der AWS den größten Teil der Verantwortung übernimmt.

Amazon EKS

Die Control Plane spielt in einem Kubernetes-Setup eine entscheidende Rolle, da sie die Verfügbarkeit der Anwendung ständig kontrolliert, indem sie sicherstellt, dass die Runtime-Services gemäß der Spezifikation arbeiten. Angesichts dieser Bedeutung bietet AWS seinen Nutzern mit Amazon EKS eine vollständig verwaltete Kontrollebene. Amazon EKS ist ein verwalteter Service, mit dem du die Kubernetes-Kontrollebene auf AWS einrichten kannst. Auf diese Weise übernimmt AWS die Verantwortung für die Infrastruktur, auf der die Control Plane läuft, die deinen Cluster als Teil des SRM betreibt. Allerdings bist du immer noch dafür verantwortlich, die Einstellungen zu konfigurieren und zu sichern, die diese Kontrollebene sicher machen.

Abbildung 1-8 veranschaulicht die Einrichtung mit Amazon EKS. AWS stellt sicher, dass das Risiko, dass ein böswilliger Akteur deine Kontrollebene übernimmt, im Rahmen des SRM gemindert wird. In Amazon EKS bist du jedoch immer noch für den Betrieb der Knoten verantwortlich, sodass das Risiko, dass ein böswilliger Akteur deine Knoten übernimmt, bestehen bleibt.

Abbildung 1-8. Amazon EKS ist eine vollständig verwaltete Kubernetes-Kontrollebene, die die Microservices orchestrieren kann, die du auf den von dir zu verwaltenden Servern ausführst.

Abbildung 1-9 zeigt die Aufteilung der Zuständigkeiten und wie EKS den AWS SRM nutzt, um dir einen Teil der Sicherheitsverantwortung beim Betrieb von Containern abzunehmen, indem es mit dem in Abbildung 1-7 beschriebenen Modell verglichen wird.

Abbildung 1-9. Die Container-Orchestrierung, die Speicherung von Containern und die Sicherheit der physischen Hardware können in diesem Modell von AWS übernommen werden.

Amazon EKS Fargate Modus

Ein Manko des regulären EKS-Modus ist, wie im vorherigen Abschnitt beschrieben, dass du die Verantwortung für den Betrieb der Knotenpunkte tragen musst. Für viele Administratoren bedeutet das eine zusätzliche Verantwortung, die manchmal unnötig ist. Wenn der einzige Aspekt der Microservice-Architektur, um den du dich kümmerst, die einzelne Geschäftsfunktion ist, die sie bereitstellt, möchtest du vielleicht die Verantwortung für den Betrieb der Knoten an AWS delegieren.

An dieser Stelle kommt der Fargate-Modus ins Spiel. Im Fargate-Modus kannst du die Docker-Container erstellen, die du in der Produktion einsetzen willst, EKS so konfigurieren, dass ein Cluster dieser Container erstellt wird, und diese Container dann an AWS übergeben, damit sie auf deren Servern laufen. Auf diese Weise kümmert sich AWS um die Sicherheit der Server, die Betriebssysteme auf ihnen (und hält sie auf dem neuesten Stand) sowie um die Netzwerk- und physische Sicherheit der Hardware, die diese Server unterstützt - während du dich auf die Microservices selbst und nicht auf die Backend-Infrastruktur konzentrierst.

Abbildung 1-10 zeigt die gleiche Architektur wie in Abbildung 1-8, wo sie im normalen EKS-Modus lief. Aber dieses Mal läuft sie im Fargate-Modus.

Abbildung 1-10. Im AWS Fargate-Modus übernimmt AWS die Verantwortung für den Betrieb der Knoten und entlastet dich damit.

Du kannst sehen, dass die Verantwortung für die Knoten, auf denen die Docker-Engine läuft, jetzt von AWS in der Cloud übernommen wird, wodurch sich deine Sicherheitsverantwortung verringert. Du bist jedoch immer noch für die Container selbst und die Geschäftslogik, die auf diesen Containern läuft, verantwortlich. Du kannst auch den Laufzeitstapel der Anwendung neu zeichnen, wie in Abbildung 1-11 dargestellt. Wie bereits erwähnt, wird die Docker-Engine auf den Nodes ausgeführt; ihre Verantwortung wird also von AWS übernommen. Du bist nur für die Verwendung des richtigen Docker-Containers und der darauf ausgeführten Geschäftslogik verantwortlich.

Abbildung 1-11. Die Sicherheit der Container-Orchestrierung, der Speicherung von Containern, der physischen Hardware, der virtuellen Maschine und der Container-Laufzeit kann in diesem Modell von AWS übernommen werden.

Function as a Service mit AWS Lambda

Ein FaaS-basierter Dienst ist die letzte Art von Microservice, die Entwicklern hilft, sofort loszulegen, indem sie die Verantwortung für alle Arten von Sicherheit rund um den Betrieb des Dienstes übernimmt; daher können sich die Entwickler auf die Geschäftslogik konzentrieren. Bei AWS ermöglicht AWS Lambda Entwicklern, ihre Funktion in einer FaaS-Umgebung auszuführen.

Bei AWS Lambda wird die Verantwortung für die Implementierung eines Großteils der Kontrollen von AWS übernommen. Dennoch musst du den Zugriff konfigurieren und Netzwerkkontrollen und andere Konfigurationen einrichten, um sicherzustellen, dass AWS die Sicherheit in deinem Namen aktivieren kann. AWS übernimmt die Verantwortung für die Bereitstellung eines Servers und die Ausführung deines Codes in einer Sandbox-Umgebung, solange er gemäß den AWS Lambda-Spezifikationen geschrieben wurde. AWS Lambdas sind eine leistungsstarke, skalierbare und vor allem sichere Möglichkeit, Microservices auf AWS auszuführen.

Der Laufzeitarchitektur-Stack von Microservices, die auf AWS Lambda laufen, ist in Abbildung 1-12 zu sehen. Wie bereits erwähnt, ist der Kunde nur für die Geschäftslogik verantwortlich, während alles andere von AWS verwaltet wird. In einer Lambda-basierten Architektur musst du dich nicht um das Patchen des Betriebssystems, der Docker-Versionen oder um alles, was mit der Infrastruktur zu tun hat, kümmern.

Abbildung 1-12. Die Verantwortung für alles außer der Geschäftslogik und ihrer Konfiguration wird von AWS übernommen.
Hinweis

Zum Zeitpunkt der Erstellung dieses Buches erlaubt AWS auch die Ausführung von Docker-Containern auf AWS Lambda. Für die Zwecke dieses Buches beschränke ich mich jedoch auf die Ausführung von Funktionen (FaaS).

Zusammenfassung der Microservice-Implementierung

Abbildung 1-13 veranschaulicht, wie sich deine Sicherheitsverantwortung je nach der von dir gewählten Microservice-Implementierung ändert.

Abbildung 1-13. AWS bietet verschiedene Möglichkeiten, dieselbe Funktion auszuführen. Je nachdem, wofür du dich entscheidest, kannst du einen Kompromiss zwischen Kosten, Flexibilität und Konfigurierbarkeit und Sicherheitsverantwortung eingehen.

Als Architekt/in solltest du entscheiden, wie viel Verantwortung du selbst übernehmen willst, um im Gegenzug die Flexibilität zu erhalten, die du durch den Betrieb der Anwendung zu deinen eigenen Bedingungen erhältst.

Beispiele von Microservice-Kommunikationsmustern

Kommen wir noch einmal auf die LEGO-Analogie der Microservices zurück. Was kann man mit einem einzigen LEGO Stein machen? Vielleicht nicht viel. Wie wäre es mit 10 davon? Jetzt kannst du ein paar verschiedene Formen bauen. Mit hundert LEGO Steinen hast du viele Möglichkeiten. Die meisten großen Anwendungen entstehen aus Hunderten kleinerer Microservices, die alle miteinander arbeiten und - was noch wichtiger ist - miteinander kommunizieren. Da die Kommunikationsverbindungen die schwächsten Glieder einer jeden Anwendung sind, erhöht diese Kommunikation zwischen den Diensten das Gesamtrisiko der Anwendung. Du musst neue Kanäle für die externe Kommunikation sichern, anstatt die bekannten In-Memory-Aufrufe, wie es bei Monolithen der Fall sein kann. Daher ist ein Großteil dieses Buches der Sicherung der Interservice-Kommunikation gewidmet. Um zu veranschaulichen, wie Sicherheitskonzepte in diesem Buch angewendet werden, möchte ich kurz auf einige der vielen Muster eingehen, die Architekten bei der Microservice-Kommunikation verwenden. Diese Beispiele stellen keine erschöpfende Liste dar, denn in der Branche werden noch viele andere Kommunikationsmuster verwendet. Der Blog Microservices.io oder das Microsoft-Architektur-Ebook sind gute Quellen, wenn du dich für andere Microservice-Kommunikationsmuster interessierst.

Beispiel 1: Einfache Nachrichtenübermittlung zwischen Kontexten

Die einfachste Art der Kommunikation zwischen Kontexten ist das direkte Senden von Nachrichten aneinander (in der Regel über HTTP-Anfragen). In diesem Beispiel sendet der Checkout-Service zwei Nachrichten, wenn ein Kunde einen Artikel auscheckt. Die erste geht an die Produktdomäne, um sie darüber zu informieren, dass sie den Lagerbestand entsprechend dem Kauf reduzieren soll. Die zweite Nachricht geht an den Finanzdienst, der die Kreditkarte des Kunden belasten soll.

Abbildung 1-14 zeigt ein Beispiel für eine direkte Kommunikation.

Abbildung 1-14. Es gibt viele Wege, auf denen diese Nachrichten weitergegeben werden können.

Die traditionelle Art, Nachrichten zu übermitteln, ist die Verwendung von synchronen REST-Endpunkten. Auch wenn dies nicht meiner Definition von Microservice-basierter Kommunikation entspricht, nutzen Unternehmen auf der ganzen Welt diese Methode. Jedes Mal, wenn ein Kauf getätigt wird, ruft der Kassendienst einen POST-Endpunkt des Collect-Cash-Dienstes auf, der wiederum einen POST-Endpunkt der Inventar-Domäne aufruft. Die synchrone Kommunikation über REST bedeutet jedoch, dass der Kassendienst warten muss, bis die beiden synchronen Vorgänge abgeschlossen sind, bevor er seine Arbeit erledigen kann. Dadurch entsteht eine starke Abhängigkeit und eine stärkere Kopplung zwischen den Domänen Finanzen, Bestand und Kunde.

In solchen Situationen besteht die Aufgabe der Sicherheitsexperten darin, die REST-Endpunkte und die HTTP-Infrastruktur in der Anwendung zu sichern. In Kapitel 7 geht es um die Grundlagen für die Einrichtung von Sicherheit im Transit.

Warnung

Ich bin der Meinung, dass eine synchrone Kommunikation auf diese Weise dem Wesen von Microservices zuwiderläuft, da die entstehenden Microservices nicht mehr unabhängig sind und weiterhin eine enge Beziehung aufrechterhalten werden. Obwohl einige Microservice-Architekturen immer noch synchrone REST-Kommunikation verwenden, raten die meisten Architekturmodelle für Microservices davon ab, synchrone Kommunikation zu verwenden.

Beispiel 2: Nachrichtenwarteschlangen

Nachrichtenbroker oder Warteschlangensysteme werden häufig für die domänenübergreifende Kommunikation in Microservices eingesetzt. Ein Dienst, der eine Nachricht senden will, legt sie auf einem persistenten Medium ab. Der Empfänger der Nachricht liest dagegen von dem persistenten Medium. Die Kommunikation über Nachrichtenwarteschlangen erfolgt asynchron, d.h. die Endpunkte, die Nachrichten veröffentlichen und konsumieren, interagieren mit der Warteschlange und nicht untereinander. Die Produzenten können der Warteschlange Nachrichten hinzufügen, sobald sie bereit sind, und die Konsumenten können nur dann Nachrichten verarbeiten, wenn sie über genügend Kapazität verfügen. Kein Produzent im System wird jemals durch das Warten auf einen nachgelagerten Konsumenten aufgehalten oder durch dessen Zuverlässigkeit beeinträchtigt. Abbildung 1-15 veranschaulicht eine warteschlangenbasierte Kommunikation.

Abbildung 1-15. Verwendung von Nachrichtenwarteschlangen für die Kommunikation zwischen Microservices

Du kannst sehen, wie die Rolle eines Sicherheitsexperten in diesem Beispiel leicht zunimmt. Da Warteschlangen eine Persistenzschicht verwenden, müssen Sicherheitsexperten sowohl die Warteschlangen als auch die Endpunkte sichern, über die sich Dienst A und Dienst B mit der Warteschlange verbinden.

Beispiel 3: Ereignisgesteuerte Microservices

Das ereignisbasierte Kommunikationsparadigma ist eine weitere beliebte Methode, um die Kommunikation von Microservices zu gestalten. Ein ereignisbasiertes System geht davon aus, dass jeder Befehl, der den Zustand ändert, zu einem Ereignis führt, das dann (in der Regel über einen so genannten Event Broker) an andere Teile der Anwendung weitergeleitet wird. Andere Dienste in anderen Kontexten abonnieren diese Ereignisse. Wenn sie ein Ereignis erhalten, können sie ihren eigenen Zustand aktualisieren, um diese Änderung widerzuspiegeln, was zur Veröffentlichung weiterer Ereignisse führen kann. Abbildung 1-16 zeigt ein Beispiel für eine ereignisbasierte Microservice-Anwendung. Mehr darüber erfährst du in Building Event-Driven Microservices von Adam Bellemare (O'Reilly), einem ganzen Buch, das sich mit dieser Architektur beschäftigt.

Abbildung 1-16. Ereignisbasierte Microservices bieten einen choreografierten Ansatz für Microservices.

In diesem Beispiel müssen die Sicherheitsexperten den Event-Broker sowie die gesamte Infrastruktur sichern, die für die Speicherung, Übertragung und das Hosting der Events benötigt wird.

Zusammenfassung

In diesem Kapitel wurden die grundlegenden Konzepte von Bedrohungen und Risiken vorgestellt und anschließend das Konzept der Kontrolle und Gegenmaßnahmen erläutert. In einer Cloud-Umgebung teilen sich der Kunde und AWS die Verantwortung für die Implementierung von Kontrollen. Zu verstehen, wo diese Aufteilung liegt, ist der Grundgedanke der Cloud-Sicherheit. Auch wenn AWS die Verantwortung für bestimmte Kontrollen übernimmt, kann es immer noch in der Verantwortung des Kunden liegen, die Kontrollen so zu konfigurieren, dass AWS vor möglichen Angriffen schützen kann. In diesem Kapitel wurden auch einige gängige Microservice-Architekturmuster und ihre Umsetzung auf AWS vorgestellt. Das nächste Kapitel befasst sich eingehend mit Authentifizierung und Autorisierung, zwei der grundlegendsten verfügbaren Kontrollen, die das Risiko deiner Anwendung vor potenziellen Bedrohungen verringern.

Get Sicherheit und Microservice-Architektur auf AWS now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial