Sicherheit und Microservice-Architektur auf AWS

Kapitel 4. Sicherheit im Ruhezustand

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

Wenn es um Microservices geht, konzentriert sich ein Großteil der Literatur in der Branche auf das Design und die Entwicklung der Mechanismen, die dem Endnutzer Rechendienste bereitstellen. Trotzdem ist allgemein bekannt, dass Microservices ein grundlegendes Umdenken bei der Speicherung erfordern. Von Microservices wird normalerweise erwartet, dass sie in sich geschlossen sind. Das gilt nicht nur für ihre Logik, sondern auch für die Speicherung ihrer Daten. Im Gegensatz zu Monolithen, bei denen eine zentrale, nicht redundante Speicherung das Leitprinzip ist, müssen Architekten bei Microservices an Dezentralisierung denken. In einer echten Microservice-Umgebung sind Daten Bürger erster Klasse und müssen wie jeder andere Rechendienst behandelt werden. Microservice-Architekten fördern die Datenlokalisierung, d. h. die Daten werden in der Nähe des Dienstes aufbewahrt, der sie benötigt, damit das System weniger von externen Datenbanken abhängig ist. Durch den Verzicht auf gemeinsam genutzte und zentralisierte Datenbanken arbeitet eine Microservice-Umgebung nur mit den Daten, die innerhalb des begrenzten Kontexts verfügbar sind, und gewährleistet so gleichzeitig Autonomie und Skalierbarkeit. Außerdem verringert eine solche verteilte Speicherung die Möglichkeit, dass Speichermechanismen zu "Single Points of Failure (SPOFs)" werden.

Aus Sicherheitsgründen kann die Speicherung von Daten sehr kostspielig sein, wenn du die damit verbundenen Risiken betrachtest. IBM und das Ponemon Institute veröffentlichen jedes Jahr einen Bericht, der die durchschnittlichen Kosten einer Datenpanne für Unternehmen auf der ganzen Welt auflistet, und wie du dir vorstellen kannst, ist jede Datenpanne mit hohen Kosten verbunden. Laut diesem Bericht belaufen sich die durchschnittlichen Kosten für eine Datenschutzverletzung auf 3,86 Millionen Dollar. Dieser Betrag ist sogar noch höher, wenn du in einer stark regulierten Branche tätig bist, in der Verstöße gegen die Vorschriften oder finanzielle Konsequenzen nach sich ziehen können. Der Microservice-Ansatz der polyglotten Persistenz (mit mehreren Mechanismen zur Speicherung von Daten) erfordert daher besondere Aufmerksamkeit, wenn es um die Sicherheit im Ruhezustand geht.

Microservice-Architekturen führen in der Regel zu einer Sammlung von verteilten Speichermechanismen. Diese verschiedenen Speicher sind lose miteinander gekoppelt, ähnlich wie die Microservices selbst. In der Regel folgen diese verteilten Speicher den Regeln des begrenzten Kontexts, in dem sie sich befinden. Abbildung 4-1 zeigt ein Beispiel für ein domänengesteuertes System mit verteilten persistenten Speichern, die sich innerhalb der begrenzten Kontexte der Dienste befinden.

Abbildung 4-1. Im Gegensatz zu Monolithen, bei denen die Daten von einer einzigen Anwendung erstellt und gespeichert werden , sind Microservices fragmentiert, was dazu führt, dass die Daten logisch voneinander getrennt werden müssen, um den unterschiedlichen Datenschutzrichtlinien im Unternehmen zu entsprechen .

Hinweis

"Speicherung" kann alles sein: ein Datenbanksystem, Anwendungsereignisse, flache Dateien, Medienobjekte, zwischengespeicherte Daten, große Binärobjekte (Blobs) und Container-Images. Die meisten Microservice-Umgebungen tendieren zu einer polyglotten Persistenz, da jede Domäne andere Anforderungen an ihre Datenspeicherungsplattform stellen kann. Einige Dienste können von einer NoSQL-Datenbank profitieren, während andere lieber ein relationales Datenbankmanagementsystem (RDBMS) verwenden. Eine verteilte und lokalisierte Speicherung stellt sicher, dass du das beste Werkzeug für die jeweilige Aufgabe verwenden kannst.

In diesem Kapitel konzentriere ich mich vor allem auf die Security at Rest für Microservices.

Wie ich bereits in den vorherigen Kapiteln erwähnt habe, kann die Sicherheit von Daten auf zwei Arten erreicht werden:

• Verhinderung des Zugriffs auf diese Daten für Unbefugte durch Zugriffskontrolle

• Verschlüsselung dieser Daten, damit sie nicht von Unbefugten gelesen werden können

Um eine Speicherung zu sichern, müssen zunächst die Berechtigungen und Sicherheitsrichtlinien festgelegt werden, die den Zugriff auf die Speicherung regeln. Bei der Erstellung dieser Richtlinien ist das Prinzip des geringsten Privilegs (PoLP), das ich in Kapitel 2 erläutert habe, eine gute Faustregel. Zur Umsetzung von PoLP erlaubt AWS die Verwendung von Identitäts- und Zugriffsmanagement (IAM)-Richtlinien für alle seine Angebote zur Speicherung in der Cloud, und ich werde sie in diesem Kapitel häufig verwenden.

Domänenorientierte Umgebungen haben im Gegensatz zu traditionellen Monolithen den natürlichen Vorteil, dass sie mit PoLP leicht zu sichern sind, da Daten und Geschäftsbereiche bereits getrennt sind und die Zugriffskontrolle daher vereinfacht werden kann.

Neben der Zugriffskontrolle sollten die Daten, die auf AWS gespeichert werden, auch verschlüsselt werden. Die Verschlüsselung dieser Daten bietet einen zusätzlichen Schutz vor unbefugtem Zugriff, zusätzlich zu den bestehenden Zugriffskontrollen, die durch IAM-Richtlinien hinzugefügt wurden. Sobald die Daten verschlüsselt sind, ist es wichtig, den Zugriff auf die Verschlüsselungsschlüssel zu kontrollieren. Bei AWS kann praktisch die gesamte Verschlüsselung über das AWS Key Management Servive (KMS) abgewickelt werden, das ich in Kapitel 3 ausführlich beschrieben habe.

Grundlagen der Datenklassifizierung

Auch wenn jeder Manager gerne behauptet, dass alle Kundendaten geschützt werden sollten, seien wir mal ehrlich: Nicht alle Daten sind gleich. Es gibt eine inhärente Hierarchie in Bezug auf die Sensibilität und Bedeutung von Daten. So sind zum Beispiel personenbezogene Daten (PII), die zur Identifizierung von Kunden verwendet werden können, sensibler und müssen mit stärkeren Kontrollen geschützt werden als anonymisierte Trainingsdaten für maschinelles Lernen. Laut dem IBM/Ponemon Cost of a Data Breach Report sind personenbezogene Daten von Kunden mit 150 Dollar am teuersten, wenn sie kompromittiert werden. Die Datenklassifizierung ist der Schritt im Sicherheitsmanagement, der Administratoren dabei hilft, die Sicherheit des Unternehmens zu identifizieren, zu kennzeichnen und neu auszurichten, damit sie den Anforderungen der Sensibilität der Daten gerecht wird. In diesem Prozess werden Datentypen und Sensibilitätsstufen sowie die wahrscheinlichen Folgen einer Kompromittierung, eines Verlusts oder eines Missbrauchs der Daten ermittelt.

Es ist empirisch erwiesen, dass Organisationen, die strenge Richtlinien zur Datenklassifizierung einführen, besser in der Lage sind, potenzielle Bedrohungen abzuwehren. Auch staatliche Organisationen haben in der Vergangenheit verschiedene Datenklassifizierungsstufen festgelegt. Das US National Classification Scheme, das auf der Executive Order 12356 basiert, kennt zum Beispiel drei Datenklassifizierungen: Vertraulich, Geheim und Streng Geheim. Die britische Regierung hat ebenfalls drei Klassifizierungen: Offiziell, Geheim und Streng Geheim.

Jede Datenklasse kann unterschiedliche Sicherheitsanforderungen an die Speicherung stellen. Noch wichtiger ist, dass die Mitarbeiter unterschiedliche Zugriffsrechte haben und die Datenklassifizierung daher die Struktur des Identitätsmanagements und der Zugriffskontrolle in deinem Unternehmen vorgibt. Meiner Erfahrung nach haben Unternehmen innovative Wege eingeschlagen, um die Ressourcen, auf denen sensible Daten gespeichert sind, in physischen Rechenzentren systematisch zu klassifizieren. Einige Unternehmen haben eine farbliche Kennzeichnung der Server eingeführt, die angibt, welche Art von Daten auf den einzelnen Servern gespeichert werden können. Andere Unternehmen trennten die Server, auf denen sensible Daten gespeichert waren, und bewahrten sie an einem separaten Ort auf, zu dem nur privilegierte Mitarbeiter/innen Zugang hatten.

Tipp

Wenn ich von "Datenspeicherung" spreche, meine ich sowohl die beabsichtigte als auch die unbeabsichtigte Persistenz von Daten. Beabsichtigte Persistenz sind die Daten, die du in einem Objektspeicher oder einer Datenbank aufbewahren möchtest. Die unbeabsichtigte Persistenz umfasst Daten, die als Ergebnis von Laufzeitoperationen wie Protokolldateien, Speicherabzügen, Backups usw. persistiert werden. Meiner Erfahrung nach neigen viele Administratoren dazu, die unbeabsichtigte Persistenz zu übersehen, wenn sie versuchen, ihre Richtlinien für die Speicherung von Daten festzulegen.

Bei AWS können die Daten mit Hilfe von AWS-Tags klassifiziert werden, über die ich in Kapitel 2 kurz gesprochen habe . Mit AWS-Tags kannst du deinen Cloud-Ressourcen Metadaten zuweisen, damit die Administratoren wissen, welche Art von Daten diese Ressourcen speichern. Mithilfe dieser Tags kann eine bedingte Logik auf die Zugriffskontrolle angewendet werden, um die Sicherheitsüberprüfung bei der Zugriffsgewährung durchzusetzen. Zur Überprüfung der Einhaltung von Vorschriften können AWS-Tags auch helfen, Ressourcen zu identifizieren und zu verfolgen, die sensible Daten enthalten. Aus der Sicherheitsperspektive solltest du jede einzelne Ressource in deinem Konto mit Tags versehen, insbesondere wenn sie sensible Daten speichert.

Rekapitulation der Umschlagverschlüsselung mit KMS

Die Umschlagverschlüsselung ist das Tool, das AWS häufig verwendet, um alle Daten zu verschlüsseln, die im Ruhezustand gespeichert werden. Ich habe bereits ausführlich(Kapitel 3) darüber gesprochen, wie AWS KMS zusammen mit der Umschlagverschlüsselung funktioniert. Aber für diejenigen, die eine Auffrischung brauchen, gibt es hier eine kurze Zusammenfassung.

Bei der Grundverschlüsselung kannst du zur Verschlüsselung von Klartextdaten den AWS-256-Algorithmus verwenden, der einen Datenschlüssel als Eingabe benötigt. Diese verschlüsselten Daten (auch als Chiffretext bezeichnet) können von einem Empfänger entschlüsselt und gelesen werden, solange er im Besitz des Schlüssels ist, mit dem die Daten verschlüsselt wurden. Bei der Umschlagverschlüsselung wird dieser Prozess noch einen Schritt weitergeführt. Bei der Umschlagverschlüsselung wird der Datenschlüssel, mit dem der Klartext verschlüsselt wurde, mit einem anderen Schlüssel, dem sogenannten Customer Master Key (CMK), weiter verschlüsselt.

Nach der Verschlüsselung werden die Chiffre-Daten und der Schlüssel für die Chiffre-Daten gemeinsam gespeichert, während der Schlüssel für die Klartext-Daten gelöscht wird. Der Zugriff ist auf den CMK beschränkt und wird nur dem vorgesehenen Empfänger dieser Daten gewährt.

Abbildung 4-2 zeigt Datenblöcke, die mit einer Umschlagverschlüsselung gespeichert werden.

Abbildung 4-2. Umschlagverschlüsselte Daten enthalten Blobs mit Daten, die mit einem Datenschlüssel verschlüsselt sind, sowie den verschlüsselten Datenschlüssel, der mit dem CMK verschlüsselt ist.

Um die verschlüsselten Daten des Umschlags zu lesen, muss der Leser zunächst den CMK verwenden, um den Schlüssel der verschlüsselten Daten zu entschlüsseln und den Schlüssel der Klartextdaten zu erhalten. Mit diesem Datenschlüssel kann der Leser dann die verschlüsselten Datenblöcke entschlüsseln und die ursprünglichen Klartextdaten, die verschlüsselt wurden, erhalten. So kann der vorgesehene Empfänger die Daten entschlüsseln, solange er Zugriff auf den CMK hat.

Fast jede verschlüsselte Speicherung von Daten auf AWS hat drei gemeinsame Themen:

• Das CMK, dem du vertraust, wird sicher und vor unbefugtem Zugriff geschützt gespeichert, entweder auf deinen eigenen Servern, im AWS KMS oder in einem Hardware-Sicherheitsmodul (HSM).

• Du vertraust darauf, dass der Verschlüsselungsalgorithmus unknackbar ist. In den meisten AWS-Beispielen wird AES-256 allgemein als sicherer Algorithmus angesehen.

• Es gibt einen Prozess zur Verschlüsselung von Daten. Dabei können die Daten auf den Servern verschlüsselt werden oder die Clients können diese Daten verschlüsseln, bevor sie an AWS gesendet werden. Dieser Prozess legt auch Richtlinien fest, wie der Datenschlüssel auf der Client-Seite zwischengespeichert wird. Die verschiedenen Speichersysteme auf AWS verwenden unterschiedliche Richtlinien für die Zwischenspeicherung von Datenschlüsseln, auf die ich in diesem Kapitel näher eingehen werde.

AWS Simple Storage Service

In AWS Simple Storage Servive oder Amazon Simple Storage Service (S3) werden die "Objekte" der Speicherung in Buckets gespeichert. Die wichtigste Aufgabe eines jeden Sicherheitsexperten in der S3-Umgebung besteht darin, das PoLP auf alle Objekte und Buckets in S3 anzuwenden, die von verschiedenen Microservices stammen. Das bedeutet, dass nur den Benutzern und Ressourcen, die für den Zugriff auf diese Objekte erforderlich sind, der Zugriff gestattet werden sollte.

Da AWS S3 ein verwalteter Service ist, können alle Daten, die in S3 gespeichert sind, ihre physischen Ressourcen mit anderen Cloud-Kunden teilen. Um deine sensiblen Daten zu schützen, bietet dir AWS daher zwei Optionen, die du für eine sichere Speicherung zusammen nutzen solltest:

• Die in Kapitel 2 erwähnten AWS IAM-Richtlinien (insbesondere IAM Principal-basierte Richtlinien und AWS S3 Resource-based Bucket Policies) können verwendet werden, um den Zugriff auf diese Ressourcen zu kontrollieren und sicherzustellen, dass das PoLP angewendet wird.

• AWS KMS kann verwendet werden, um die Objekte zu verschlüsseln, die in AWS S3-Buckets gespeichert sind. Dadurch wird sichergestellt, dass nur Auftraggeber mit Zugriff auf den Verschlüsselungsschlüssel, der zur Verschlüsselung dieser Daten verwendet wird, diese Objekte lesen können.

Verschlüsselung und Zugriffskontrolle spielen bei der Datensicherheit eine ebenso wichtige Rolle; beide Methoden sollten eingesetzt werden, um die Daten vor unbefugtem Zugriff zu schützen. Abbildung 4-3 zeigt, wie du AWS KMS und AWS IAM-Richtlinien nutzen kannst, um deine Daten zu schützen.

Abbildung 4-3. Sicherheitsexperten können AWS IAM-Richtlinien einsetzen, um den Zugriff auf die Daten in AWS S3-Buckets einzuschränken, und die Daten, die in diesen Buckets gespeichert sind, mit AWS KMS verschlüsseln. Eine gute und sichere Lösung setzt Verschlüsselung und Autorisierung effektiv ein, um unbefugten Zugriff zu verhindern.

Verschlüsselung auf AWS S3

Ich werde zunächst über die Techniken sprechen, die du zum Verschlüsseln von Datenobjekten verwenden kannst. Es gibt vier Möglichkeiten, wie du Datenobjekte in AWS S3 verschlüsseln kannst. Jede dieser Methoden bietet den Endnutzern ein gewisses Maß an Flexibilität und Bequemlichkeit, daher kannst du eine dieser Methoden wählen, die den Bedürfnissen deines Unternehmens entspricht. Sie sind:

• AWS Server-seitige Verschlüsselung (AWS SSE-S3-AWS-verwaltete Schlüssel)

• AWS Server-seitige Verschlüsselung KMS (AWS SSE-KMS-Kunden-verwaltete Schlüssel)

• AWS Server-seitige Verschlüsselung mit vom Kunden bereitgestellten Schlüsseln (AWS SSE-C-customer-provided keys)

• AWS S3 client-seitige Verschlüsselung (Verschlüsselung der Daten auf dem Client, bevor sie an AWS S3 übertragen werden)

Abbildung 4-4 zeigt ein praktisches Flussdiagramm, das dir helfen kann, die Art der Verschlüsselung zu bestimmen, die du für die Bedürfnisse deines Unternehmens benötigst.

Abbildung 4-4. Du kannst entscheiden, welche Verschlüsselung du möchtest, indem du die Fragen in dieser Tabelle beantwortest.

Alle Verschlüsselungsoptionen können AWS KMS verwenden, um die Verschlüsselung in AWS zu erreichen. Daher kann ein tiefes und grundlegendes Verständnis von AWS KMS sehr hilfreich sein, um den Prozess der Verschlüsselung in AWS S3 zu verstehen.

AWS SSE-S3 (AWS-verwaltete Schlüssel)

Dies ist der Standardmodus für die Verschlüsselung von Datenobjekten in AWS S3. Für Unternehmen, die eine sehr einfache Objektverschlüsselung benötigen, ohne den Lebenszyklus der CMK, die zur Verschlüsselung der Datenelemente verwendet wurde, kontrollieren zu wollen, bietet AWS SSE-S3 eine schnelle und einfache Möglichkeit, die Verschlüsselung in AWS einzuführen. Der größte Vorteil von AWS SSE-S3 ist die Benutzerfreundlichkeit und Einfachheit, die es den Cloud-Nutzern bietet.

AWS SSE-S3 kann in der AWS Management Console pro Bucket aktiviert werden, wie in Abbildung 4-5 zu sehen ist.

Abbildung 4-5. Alle in einem Bucket gespeicherten Objekte können standardmäßig mit AWS SSE-S3 verschlüsselt werden, indem du die Option "Standardverschlüsselung" und "Serverseitige Verschlüsselung" auswählst.

Sobald diese Funktion aktiviert ist, verschlüsselt AWS alle Objekte in diesem Bucket mit einem Datenschlüssel. Dieser Datenschlüssel wird dann mit AWS KMS und einem CMK verschlüsselt, der von AWS für dich gewartet, geschützt und rotiert wird.

Tipp

Durch das Vorhandensein von AWS SSE-S3 ist der Investitionsaufwand für die Verschlüsselung von Objekten in AWS S3 jetzt extrem gering. Obwohl dies nicht ideal ist (da du AWS deinen Schlüssel und den Verschlüsselungsprozess vollständig anvertraust), sollte die Möglichkeit, die Verschlüsselung per Knopfdruck zu aktivieren, alle Nutzer dazu bewegen, alle ihre Speicherobjekte zu verschlüsseln. Ich kenne keinen einzigen Grund, warum Objekte in AWS S3 nicht verschlüsselt werden sollten.

Natürlich gibt es für diejenigen, die an mehr Kontrolle interessiert sind, auch andere Möglichkeiten, Objekte zu verschlüsseln, die auf AWS S3 gespeichert sind.

AWS SSE-KMS

Nutzer, die ein flexibleres Verschlüsselungsverfahren als AWS SSE-S3 bevorzugen, können AWS KMS expliziter für die Verschlüsselung nutzen. Du kannst einen KMS-Schlüssel verwenden, den du in AWS KMS kontrollierst. Auf diese Weise kannst du auch für den Lebenszyklus des Schlüssels verantwortlich sein, der zur Verschlüsselung von Datenobjekten auf AWS verwendet wird.

Die Verschlüsselung kann für einzelne Objekte oder standardmäßig für jedes Objekt im Bucket aktiviert werden, ähnlich wie AWS SSE-S3 in Abbildung 4-5 aktiviert wurde. Abbildung 4-6 zeigt, wie AWS SSE-KMS als Standardoption für Buckets aktiviert werden kann .

Abbildung 4-6. AWS SSE-KMS kann über die Managementkonsole aktiviert werden, indem du den ARN des KMS-Schlüssels angibst, mit dem deine Objekte verschlüsselt werden sollen.

AWS SSE-C (vom Kunden bereitgestellter Schlüssel)

Die letzte Art der serverseitigen Verschlüsselung auf AWS S3 ist die AWS SSE-C. Bei diesem Verschlüsselungsverfahren wird die Kontrolle über den Verschlüsselungsprozess noch stärker auf den Endnutzer verlagert. Anstatt AWS S3 anzuweisen, einen Verschlüsselungsschlüssel zu verwenden, der im AWS KMS vorhanden ist, kannst du den Verschlüsselungsschlüssel in deine PutObject Anfrage aufnehmen und AWS S3 anweisen, das Objekt mit dem von dir angegebenen Schlüssel zu verschlüsseln. Derselbe Schlüssel muss während des GetObject Vorgangs angegeben werden, um das Objekt zu entschlüsseln und abzurufen. AWS S3 verwendet den von dir angegebenen Schlüssel, verschlüsselt das Objekt, speichert es in AWS S3 und löscht den Schlüssel anschließend dauerhaft. Auf diese Weise kannst du den Zugriff auf den Entschlüsselungsschlüssel für die in AWS gespeicherten Objekte völlig flexibel kontrollieren und sichern. Gleichzeitig findet der Verschlüsselungsprozess vollständig in AWS S3 statt, so dass du keinen Verschlüsselungs- oder Entschlüsselungscode in deinen Diensten vorhalten musst.

Warnung

AWS SSE-C verschlüsselt nur das S3-Objekt, nicht aber die mit dem Objekt verbundenen Metadaten.

AWS-Client-seitige Verschlüsselung

AWS bietet viele verschiedene Möglichkeiten, Daten zu verschlüsseln, nachdem sie in AWS S3 hochgeladen wurden. Vielleicht möchtest du aber auch Daten innerhalb deiner Anwendung verschlüsseln, noch bevor sie an AWS übertragen werden. Bei der clientseitigen Verschlüsselung werden die Daten verschlüsselt, bevor sie an Amazon S3 gesendet werden, und können für solche Anwendungsfälle genutzt werden. Bei der clientseitigen Verschlüsselung verwaltest du den CMK, mit dem du die Daten verschlüsseln willst. Du kannst dann einen Teil des clientseitigen Software Development Kits (SDK) verwenden, um die Daten innerhalb deiner Anwendung zu verschlüsseln und diese Daten an AWS zu senden, um sie in der Cloud zu speichern. Aus Sicht von AWS unterscheiden sich diese client-verschlüsselten Daten nicht von anderen Daten, die AWS speichert. Optional kannst du auch die serverseitige Verschlüsselung aktivieren, wenn du das möchtest. Auf diese Weise kann die clientseitige Verschlüsselung eine zusätzliche Schutzschicht gegen potenzielle Bedrohungen bieten. Weitere Informationen zur client-seitigen Verschlüsselung findest du bei Amazon.

Zugriffskontrolle auf Amazon S3 durch S3 Bucket Policies

Wie in Kapitel 2 beschrieben, beschränken ressourcenbasierte Richtlinien den Zugang zu AWS-Ressourcen und können auf bestimmte Ressourcen angewendet werden. Bei AWS S3 werden diese ressourcenbasierten Richtlinien Bucket-Richtlinien genannt. Diese Richtlinien beantworten die Frage, welche Principals auf die Objekte in diesen S3-Buckets zugreifen dürfen und unter welchen Bedingungen dieser Zugriff erlaubt oder verweigert werden soll. Bucket-Richtlinien können in der AWS Management Console hinzugefügt werden, wie in Abbildung 4-7 dargestellt.

Abbildung 4-7. Bucket-Richtlinien können zu AWS S3-Buckets hinzugefügt werden, indem du in der AWS-Webkonsole die Registerkarte Berechtigungen aufrufst.

AWS bietet auch eine gute Dokumentation über AWS Bucket-Richtlinien. Die folgenden zwei Richtlinien sind Beispiele dafür, wie du deine S3-Buckets sichern kannst.

Beispiel 1: Serverseitige Verschlüsselung für alle Objekte erzwingen

Als Sicherheitsadministrator kannst du unverschlüsselte Uploads zu deinem Bucket verweigern, indem du eine IAM-Richtlinie hinzufügst, wie sie von AWS empfohlen wird.

{
      "Sid": "DenyUnencryptedObjectUploads",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::awsexamplebucket1/*",
      "Condition": {
        "Null": {
          "s3:x-amz-server-side-encryption": "true"
        }
      }
    }

Die Erklärung Condition in diesem Block macht diese Richtlinie wirksam.

Beispiel 2: Benutzer müssen bei der Interaktion mit AWS S3 eine MFA verwenden

Eine weitere häufig verwendete Bucket-Richtlinie ist die Erzwingung einer Multifaktor-Authentifizierung (MFA) für jede Anfrage, die mit Objekten im Bucket interagieren möchte:

{
    "Version": "2012-10-17",
    "Id": "123",
    "Statement": [
      {
        "Sid": "",
        "Effect": "Deny",
        "Principal": "*",
        "Action": "s3:*",
        "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/taxdocuments/*",
        "Condition": { "Null": { "aws:MultiFactorAuthAge": true }}
      }
    ]
 }

Anhang D enthält ein praktisches Tutorial, mit dem Cloud-Sicherheitsexperten PoLP auf ihre S3-Buckets anwenden können.

Amazon GuardDuty

Mit Amazon GuardDuty kannst du deine in Amazon S3 gespeicherten Daten kontinuierlich auf Bedrohungen und unbefugtes Verhalten überwachen und schützen. Mithilfe von maschinellem Lernen, Anomalieerkennung und integrierter Bedrohungsintelligenz identifiziert AWS GuardDuty potenzielle Bedrohungen und ordnet sie nach Priorität. Zu den Datenquellen von GuardDuty gehören AWS CloudTrail und Virtual Private Cloud (VPC)-Flussprotokolle sowie DNS-Protokolle. GuardDuty erkennt Bedrohungen und sendet eine automatische Antwort, um die Behebung und Wiederherstellung zu beschleunigen.

GuardDuty überwacht Bedrohungen für deine Amazon S3-Site, indem es CloudTrail S3-Verwaltungsereignisse und CloudTrail-Verwaltungsereignisse betrachtet. Daten, die GuardDuty-Kunden generieren, wie z. B. Befunde, werden im Ruhezustand mit AWS KMS und AWS Master Keys (CMK) verschlüsselt, die nach dem AWS Shared Responsibility Model (SRM) gesichert sind.

Unleugbarkeit mit Glacier Vault Lock

Um die Einhaltung der Vorschriften zu gewährleisten, ist es manchmal notwendig, ein Aufzeichnungssystem (SOR) zu haben, das die maßgebliche Datenquelle für eine bestimmte Information ist. Dieses SOR ist nicht nur für interne Verbraucher gedacht, sondern auch für externe Parteien wie Strafverfolgungsbehörden oder Compliance-Prüfer, die es im Falle von Unstimmigkeiten einsehen können. Folglich sollte dieses SOR etwas sein, dem externe Stellen vertrauen können und das sie bei Unstimmigkeiten, bei denen deine Organisation in einen Interessenkonflikt geraten könnte, als Beweis verwenden können. Eine Zertifizierung der Integrität der Daten durch eine dritte Partei kann in einer solchen Situation wichtig sein.

Mit AWS Glacier Vault Lock können Daten so gespeichert werden, dass ihre Integrität und Authentizität für regulatorische Zwecke zertifiziert werden kann. Das Herzstück dieses Integritätsprozesses ist die Glacier Vault Lock-Richtlinie, die steuert, wie die Daten gespeichert werden und welche Zugriffskontrollen die Organisation über ihre eigenen Daten hat. Vault-Richtlinien können Kontrollen wie Write Once Read Many (WORM) enthalten, die zukünftige Änderungen an den gespeicherten Daten verhindern. Sobald die Richtlinie gesperrt ist, kann sie nicht mehr geändert werden.

Du kannst den AWS S3 Glacier Bucket verwenden, um die Daten zu speichern und den Bucket zu sperren, um einer eventuellen Aufsichtsbehörde, die dich prüfen will, zu zeigen, dass die Daten nie verändert wurden.

Tipp

Im Gegensatz zu einer Tresorzugangsrichtlinie kann eine Tresorschlossrichtlinie gesperrt werden, um weitere Änderungen an deinem Tresor zu verhindern und die Einhaltung der Vorschriften für den Tresor zu gewährleisten.

Um ein Tresorschloss zu öffnen, musst du zwei Schritte ausführen:

1. Füge deinem Tresor eine Richtlinie für die Tresorsperre hinzu, die die Sperre in den Status "in Arbeit" versetzt und eine Sperr-ID zurückgibt. Die Sperre läuft nach 24 Stunden ab, wenn die Richtlinie nicht validiert wurde.

2. Wenn du mit den Ergebnissen des Prozesses nicht zufrieden bist, kannst du den Sperrvorgang während der 24-stündigen Validierungsphase von Grund auf neu starten.

Tipp

Richtlinien für Tresorschlösser können dir helfen, gesetzliche Vorschriften wie SEC Rule 17a-4 und HIPAA einzuhalten.

Sicherheit im Ruhezustand für Rechendienste

In diesem Abschnitt werde ich darüber sprechen, wie du die Dienste, die für den Betrieb deiner Microservices verantwortlich sind, sichern kannst. Bevor ich über die Sicherung von Microservices im Ruhezustand spreche, werde ich kurz darauf eingehen, wie ein typischer Entwicklungsprozess in einem typischen Microservice-Betrieb aussieht.

Je nach Entwicklungspraktiken können sich bestimmte Schritte ändern, aber insgesamt sieht der Ablauf in etwa so aus wie in Abbildung 4-8.

1. Entwicklerinnen und Entwickler schreiben ihren Code in der Regel in einer Sprache ihrer Wahl. Das kann Java, Python, Go, TypeScript oder eine andere Sprache sein.

   Sicherheitsrisiko: Angreifer können Schwachstellen auf Code-Ebene ausnutzen oder unsichere Bibliotheken auf Code-Ebene einfügen und so die Sicherheit deiner gesamten Anwendung gefährden.

2. Wenn du diesen Code in einer typischen Container-Umgebung wie einem Kubernetes-Cluster ausführen möchtest, kompilierst du diesen Code in einer CICD-Pipeline (Continuous Integration Continuous Delivery) und führst verschiedene Schritte durch, bis er zu einem Container-Image wird. Diese CICD-Pipeline kann ein Speichersystem verwenden, um persistente Daten wie Bibliotheken, Konfigurationsdateien und mehr zu speichern. Wenn sie auf einer AWS Elastic Cloud Compute (EC2) Instanz läuft, werden diese Daten in der Regel auf einem AWS Elastic Block Store (EBS) Volume gespeichert.

   Sicherheitsrisiko: Die EBS-Volumes, die zum Erstellen des Images verwendet werden, können gekapert und gegen deinen Build-Prozess verwendet werden, um Schwachstellen in die Anwendung einzuschleusen oder sensiblen Code auszuspionieren.

3. Sobald du ein Container-Image wie ein Docker-Image hast, speicherst du dieses Image normalerweise in einem Docker-Repository. Du hast hier viele Möglichkeiten, das Image zu speichern. AWS bietet dir die AWS Elastoc Container Registry (ECR), in der du ein Docker-Image speichern kannst.

   Sicherheitsrisiko: Eine ungesicherte Speicherung der erstellten Container-Images kann dazu führen, dass böswillige Akteure die erstellten Container-Images manipulieren und bösartigen Code in diese Container einschleusen. Alternativ kann Code aus einer ungesicherten Speicherung von Containern durchsickern.

4. Das Docker-Image aus Schritt 2 kann nun in verschiedene Umgebungen deiner Wahl übertragen werden. Auf diese Weise kannst du das gleiche Image in deiner Produktionsumgebung und in deiner Staging-Umgebung verwenden. Wenn du Amazon EKS verwendest, um einen Kubernetes-Cluster zu betreiben, und deine Knoten auf AWS EC2 laufen, kannst du das Image aus der ECR-Registry ziehen und es auf die EC2-Knoten befördern. Ähnlich wie bei den CICD-Pipelines in Schritt 2 können diese Knoten EBS-Volumes verwenden, um persistente Daten zu speichern. Sicherheitsexperten müssen diese EBS-Volumes möglicherweise absichern.

   Sicherheitsrisiko: Obwohl die Container auf den Kubernetes-Knoten ausgeführt werden, können sie EBS-Volumes verwenden, um dauerhafte Daten zu speichern. Ähnlich wie in Schritt 2 könnten böswillige Akteure, die sich unbefugt Zugang zu diesen EBS-Volumes verschaffen, die darauf gespeicherten Daten manipulieren oder sensible Daten an andere externe Stellen weitergeben.

5. Wenn du dich entscheidest, deinen Code auf AWS Lambda auszuführen, kannst du ihn auch direkt auf AWS Lambda bereitstellen und musst dich nicht um die Schritte 2-3 kümmern.

   Sicherheitsrisiko: Bei AWS Lambda ist eine langfristige Speicherung nicht vorgesehen. Die Umgebungsvariablen, die deine Funktionen benötigen, können jedoch auf AWS gespeichert werden und müssen möglicherweise gesichert werden.

Alle Microservice-Shops folgen einer Variante dieses Ablaufs, wie in Abbildung 4-8 zu sehen ist.

Abbildung 4-8. Die verschiedenen Schritte, die der Code durchläuft, bevor er in einer Microservice-Umgebung ausgeführt wird.

Im folgenden Abschnitt gehe ich auf die verschiedenen Sicherheitstools ein, die dir zur Verfügung stehen, um diese Daten zu schützen.

Statische Code-Analyse mit AWS CodeGuru

Die statische Codeanalyse ist ein aufstrebender Zweig im Bereich der Computersicherheit. Bis vor kurzem war die statische Codeanalyse vor allem aufgrund der nicht-deterministischen Natur von Computersprachen schwierig durchzuführen. Mit dem Aufkommen von KI und maschinellem Lernen werden Sicherheitstools, die Sicherheitsschwachstellen im Code aufspüren, jedoch immer genauer.

AWS stellt den Nutzern AWS CodeGuru zur Verfügung, das maschinelles Lernen und KI nutzt, um verschiedene Arten von Analysen deines Codes durchzuführen. AWS CodeGuru vergleicht dann deinen Code mit seinen Beispiel-Repositories und nutzt maschinelles Lernen, um sicherheitsrelevante Probleme und andere bewährte Methoden im Code zu identifizieren. Bei dieser Analyse werden auch mögliche Ressourcenlecks, Exploits und Schwachstellen in deinem Code identifiziert.

Die statische Codeanalyse stellt sicher, dass alle Probleme mit deiner Codebasis frühzeitig im Lebenszyklus erkannt werden, bevor sie in die Produktion gehen. Abbildung 4-9 zeigt ein Codebeispiel, bei dem AWS CodeGuru Änderungen auf Codeebene empfiehlt.

Abbildung 4-9. Die statische Codeanalyse kann für bestehende Repositories aktiviert werden, um Java-Code-bezogene Probleme und Sicherheitslücken zu identifizieren.

AWS Elastic Container Registry

AWS ECR ist das Repository, das AWS dir zur Verfügung stellt, um erstellte Container für deine Microservices zu speichern. Auf diese Weise kannst du Microservices mit Docker erstellen und diese Images in andere Umgebungen übertragen. Diese Images werden während ihrer gesamten Lebensdauer sicher gespeichert. Die Verwendung von AWS ECR für die Speicherung von Containern bietet zahlreiche Vorteile, und ich werde drei der wichtigsten Gründe hervorheben, warum AWS ECR am besten geeignet ist.

Zugriffskontrolle

AWS ermöglicht die Verwendung von IAM-Richtlinien zur Kontrolle des Zugriffs auf die AWS ECR-Repositories. Auf diese Weise können die verschiedenen Kontexte innerhalb deines Unternehmens mithilfe des PoLP getrennt werden, um zu entscheiden, auf welche Container die verschiedenen Einheiten innerhalb deines Unternehmens zugreifen können. Du kannst sowohl identitätsbasierte als auch ressourcenbasierte Richtlinien für die Zugriffskontrolle verwenden.

AWS führt eine Liste mit verschiedenen IAM-Richtlinien, die du auf deine ECR-Repositories anwenden kannst. Hier ist ein Beispiel für eine IAM-Richtlinie, die es dem Benutzer erlaubt, Bilder in einem ECR-Repository aufzulisten und zu verwalten:

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Sid":"ListImagesInRepository",
         "Effect":"Allow",
         "Action":[
            "ecr:ListImages"
         ],
         "Resource":"arn:aws:ecr:us-east-1:123456789012:repository/my-repo"
      },
      {
         "Sid":"GetAuthorizationToken",
         "Effect":"Allow",
         "Action":[
            "ecr:GetAuthorizationToken"
         ],
         "Resource":"*"
      },
      {
         "Sid":"ManageRepositoryContents",
         "Effect":"Allow",
         "Action":[
                "ecr:BatchCheckLayerAvailability",
                "ecr:GetDownloadUrlForLayer",
                "ecr:GetRepositoryPolicy",
                "ecr:DescribeRepositories",
                "ecr:ListImages",
                "ecr:DescribeImages",
                "ecr:BatchGetImage",
                "ecr:InitiateLayerUpload",
                "ecr:UploadLayerPart",
                "ecr:CompleteLayerUpload",
                "ecr:PutImage"
         ],
         "Resource":"arn:aws:ecr:us-east-1:123456789012:repository/my-repo"
      }
   ]
}

Wenn du Nutzern einen Nur-Lese-Zugriff auf alle Images gewähren möchtest, kannst du alternativ die verwalteten AWS-Richtlinien verwenden, um ein ähnliches Ziel zu erreichen.

Verschlüsselung im Ruhezustand

AWS ECR wird von AWS S3 unterstützt, das auch die Verschlüsselung von Bildern im Ruhezustand mit sehr ähnlichen Techniken wie AWS S3 ermöglicht. Abbildung 4-10 zeigt, wie deine Container in AWS ECR mit AWS KMS geschützt werden. KMS-Berechtigungen werden jedes Mal erstellt, wenn du den Zugriff auf das Image erlauben musst.

Abbildung 4-10. Bilder in AWS ECR werden mit AWS KMS verschlüsselt.

Du kannst die Verschlüsselung für die Speicherung von Containern in AWS ECR über die AWS Management Console aktivieren, wie in Abbildung 4-11 dargestellt.

Abbildung 4-11. Die KMS-Verschlüsselung kann für AWS ECR aktiviert werden, indem du das Feld "Verschlüsselungseinstellungen anpassen" aktivierst und den gewünschten KMS CMK auswählst.

Bild Gemeinsames Scannen auf Schwachstellen und Gefährdungen

AWS ECR bietet die Möglichkeit, Container mithilfe des Open-Source-Projekts clair auf gängige Schwachstellen zu scannen. Diese Überprüfung stellt sicher, dass die Container vor Malware geschützt sind. Du kannst entweder das CVE-Scannen (Common Vulnerability and Exposure) für jeden Container, der in AWS ECR hochgeladen wird, standardmäßig aktivieren oder jedes Container-Image in ECR manuell scannen. Abbildung 4-12 zeigt, wie du CVE für alle Images aktivieren kannst.

Abbildung 4-12. CVE kann standardmäßig für jedes Bild aktiviert werden, das an ECR gesendet wird.

AWS Lambda

Obwohl AWS Lambda nicht zur langfristigen Speicherung verwendet werden sollte, können die Eingabevariablen, die den Lambda-Funktionen als Umgebungsvariablen zur Verfügung gestellt werden, manchmal sensible Daten enthalten. Wenn du diese Daten unverschlüsselt in der Cloud speicherst, kann das zu einer nicht so idealen Sicherheitssituation führen. AWS ermöglicht es dir daher, die Umgebungsvariablen, die für AWS Lambda-Funktionen gespeichert werden, automatisch zu verschlüsseln.

Es gibt zwei Möglichkeiten, wie du Umgebungsvariablen verschlüsseln kannst:

• Verschlüsselung mit CMK

• Verschlüsselung mit externen Helfern

Verschlüsselung mit CMK

Genau wie AWS S3 und AWS ECR können Umgebungsvariablen auf der Serverseite verschlüsselt werden. Du kannst die Verschlüsselung entweder AWS überlassen, indem du die AWS-eigene CMK verwendest, oder die Berechtigungen und den Lebenszyklus der CMK verwalten, indem du einen Verweis auf eine bestehende CMK bereitstellst. Diese CMK kannst du dann mit dem PoLP sichern.

Verschlüsselung mit Helfern

Verschlüsselungshelfer fügen eine zusätzliche Schutzschicht für deine Umgebungsvariablen hinzu, indem sie die Variablen auf der Befehlsseite verschlüsseln, bevor sie dem Lambda hinzugefügt werden. So wird sichergestellt, dass die Variablen in ihrer unverschlüsselten Form auf der AWS-Konsole nicht sichtbar sind.

AWS Elastic Block Store

Wenn du deine Dienste auf EC2 ausführst (entweder direkt oder über Amazon Elastic Kubernetes Service [EKS] mit EC2 als Arbeitsknoten), kann AWS KMS zur Verschlüsselung der EBS-Volumes verwendet werden, die diese EC2-Instanzen sichern. Wie in Abbildung 4-13 zu sehen ist, wird der Datenschlüssel für das EBS-Volume aus Gründen der Geschwindigkeit und Zuverlässigkeit zwischengespeichert.

Abbildung 4-13. EC2-Instanzen entschlüsseln den Datenschlüssel, der zum Entschlüsseln von EBS-Volumes verwendet wird, indem sie Anfragen an AWS KMS stellen. Nach der Entschlüsselung behalten die EC2-Instanzen den unverschlüsselten Datenschlüssel in ihrem Cache, solange die Instanz läuft.

Da der Datenschlüssel in der EC2-Instanz zwischengespeichert wird, kann eine Instanz, sobald sie mit dem Volume verbunden ist, auf die Daten des EBS-Volumes zugreifen, ohne Anfragen an das KMS-basierte CMK zu stellen. Jedes Mal, wenn die Instanz beendet wird, muss sie eine neue Anfrage an die CMK stellen, um sich erneut mit dem EBS-Volumen zu verbinden.

Alles zusammenbinden

Nachdem ich nun erklärt habe, warum Sicherheit im Ruhezustand wichtig ist, wollen wir besprechen, wie AWS-Tools dabei helfen können, deinen Microservice-Code zu schützen:

1. Bei Schwachstellen auf Code-Ebene und Ressourcenlecks hilft AWS CodeGuru dabei, den Code durchzugehen und eine statische Codeanalyse durchzuführen.

2. AWS KMS kann bei der Verschlüsselung von EBS-Volumes helfen (entweder mit von AWS verwalteten/eigenen Schlüsseln oder mit vom Kunden verwalteten CMKs), was zu einem sicheren Build-Prozess führt.

3. IAM-Richtlinien können verwendet werden, um den Zugriff auf AWS ECR zu kontrollieren. Die Container auf ECR können auch mit serverseitiger Verschlüsselung verschlüsselt werden. Schließlich kannst du CVE-Image-Scanner verwenden, um Container, die auf AWS ECR gespeichert sind, auf allgemeine Schwachstellen zu überprüfen.

4. EBS-Volumes, die von Kubernetes-Knoten genutzt werden, können auf AWS auch mit KMS verschlüsselt und so vor unberechtigtem Zugriff geschützt werden.

5. Schließlich können auch die Umgebungsvariablen, die AWS Lambdas zur Verfügung gestellt werden, entweder mit CMK oder mit Verschlüsselungshelfern verschlüsselt werden.

Abbildung 4-14 zeigt die verschiedenen Kontrollen, die AWS uns zur Verfügung stellt, um die Sicherheit für alle in Abbildung 4-8 skizzierten Schritte zu erhöhen.

Abbildung 4-14. Für alle Schritte, die ich in Abbildung 4-8 skizziert habe, stellt AWS uns Kontrollen zur Verfügung, die helfen können, die Gefährdung durch potenzielle Bedrohungen zu verringern.

Microservice-Datenbank-Systeme

Nachdem ich dir die verschiedenen Rechenservices von AWS erklärt habe, gehe ich auf die verschiedenen Arten der Speicherung ein, die du für deine Microservices nutzen kannst, und wie AWS deine sensiblen Daten schützt.

Ich habe bereits über die Möglichkeit von polyglotten Persistenzmechanismen in Microservice-Systemen gesprochen. Abbildung 4-15 zeigt eine typische Microservice-Organisation, in der die Dienste nach ihren funktionalen Domänen getrennt sind. Jede dieser Domänen stellt einen größeren begrenzten Kontext dar. Jeder Dienst spricht mit einem Datenspeicher innerhalb seines begrenzten Kontexts und nicht mit einem externen Datenspeicher. Daher kann jeder Bounded Context je nach den Anforderungen der Domäne eine andere Art von Datenbank verwenden.

Abbildung 4-15. Drei verschiedene Domänen mit unterschiedlichen Anforderungen können sich für verschiedene Arten von Datenbanken entscheiden. Domäne A benötigt möglicherweise relationale Daten und wählt daher AWS Relational Database Service (RDS) als Datenspeicher. Domäne B könnte es vorziehen, ihre Daten in einem NoSQL DynamoDb-Datenspeicher zu speichern, während Domäne C ihre Daten in AWS S3-Buckets speichern könnte .

AWS DynamoDB

AWS DynamoDB ist ein serverloses, vollständig verwaltetes NoSQL-Datenbanksystem, das für die Speicherung von Daten in verschiedenen Anwendungen genutzt werden kann.

Zugriffskontrolle auf AWS DynamoDB

AWS DynamoDB unterstützt IAM-Richtlinien genau wie jede andere Ressource auf AWS. Mit AWS DynamoDB hast du jedoch die Kontrolle darüber, wer wann auf welchen Teil (Zeile oder Spalte oder beides) der Datenbank zugreifen kann. Der Abschnitt "Bedingungen" einer IAM-Richtlinie gibt dir eine detaillierte Kontrolle über die Berechtigungen. Zur Veranschaulichung möchte ich ein Beispiel anführen.

Stell dir eine Organisation vor, die Mitarbeiterinformationen in einer DynamoDB-Tabelle speichert. Jede Zeile enthält eine Reihe von Informationen über jeden Mitarbeiter. Dazu gehören z. B. Name, Bundesland, Land, Gehalt und Sozialversicherungsnummer. Es gibt zwei Arten von Benutzern, die auf diese Informationen zugreifen können:

• Benutzer: Dies kann ein regulärer Mitarbeiter sein, der auf seine eigene Zeile zugreifen muss, um seine Adresse im System zu ändern oder zu aktualisieren. Aus Sicherheitsgründen darf er jedoch nicht auf sein Gehalt oder seine Sozialversicherungsnummer zugreifen.

• Admin: Dies ist ein mächtigerer Benutzer, der möglicherweise vollen Zugriff auf die gesamte Tabelle benötigt.

Der Primärschlüssel zum Abrufen jeder Zeile kann der Benutzername sein.

Abbildung 4-16 zeigt die Mitarbeitertabelle, die die Mitarbeiterinformationen enthalten kann.

Abbildung 4-16. "Benutzer - Gaurav" kann nur auf die Zeile mit dem Benutzernamen Gaurav zugreifen und diese bearbeiten und hat nur Zugriff auf die Spalten Benutzername, Stadt, Bundesland und Land, wie hervorgehoben.

Für den IAM-Benutzer Gaurav willst du also erlauben:

• GetItem und UpdateItem Zugang

• Zugriff auf bestimmte Attribute (Benutzername, Stadt, Bundesland und Land)

• Zugriff nur auf die Zeilen mit dem Benutzernamen Gaurav

Die IAM-Richtlinie, die du für eine solche Situation verwenden kannst, ist in Abbildung 4-17 dargestellt.

Abbildung 4-17. Dies ist die IAM-Richtlinie, die, wenn sie auf den Benutzer Gaurav angewendet wird, unsere Anforderungen erfüllt. 1, 2, 3A und 3B kennzeichnen die Abschnitte der IAM-Richtlinie, die bei der Feinabstimmung der Berechtigungsrichtlinie helfen.

Wie in Abbildung 4-17 zu sehen ist, kannst du bestimmte Richtlinienelemente zur Feinabstimmung der IAM-Richtlinie verwenden:

1. Zunächst kannst du PoLP auf die Vorgänge anwenden, die du zulassen möchtest.

2. Der Bedingungsschlüssel LeadingKeys kann verwendet werden, um den Schlüssel anzugeben, der bei der Anwendung der Richtlinie überprüft werden soll. In diesem Beispiel wird jede Zeile mit dem Schlüssel Gaurav für den Benutzer Gaurav zugänglich sein. Du kannst alternativ den fest codierten Namen "Gaurav" in ${www.amazon.com:user_id} ändern, wenn du AWS anweisen möchtest, dem aktuell authentifizierten Benutzer den Zugriff auf eine Spalte mit seinem eigenen Namen zu erlauben, wie in einem AWS-Artikel hervorgehoben.

3. 3A und 3B legen fest, welche Attribute zugänglich sind. Da ich SPECIFIC_ATTRIBUTES (3B) in der Anweisung angegeben habe, werden nur die Anfragen zugelassen, die eine bestimmte Teilmenge der in 3A angegebenen Attribute auswählen, während jede Privilegienerweiterung verweigert wird.

AWS unterhält eine Liste mit verschiedenen Bedingungen, die du verwenden kannst, um den Zugriff auf AWS DynamoDB fein abzustimmen. Durch den effektiven Einsatz von Schlüsselbedingungen kannst du Daten vor verschiedenen Nutzern verbergen und so den PoLP auf DynamoDB verfolgen.

Verschlüsselung auf DynamoDB

DynamoDB bietet seinen Nutzern zusätzlich zur Zugriffskontrolle einen einfach zu integrierenden Verschlüsselungsprozess. DynamoDB verfügt standardmäßig über eine serverseitige Verschlüsselung, die nicht deaktiviert werden kann. DynamoDB verwendet die Umschlagverschlüsselung, um alle Elemente zu verschlüsseln, die in der Tabelle gespeichert werden. AWS verwendet die symmetrische AES-256-Verschlüsselung für die Verschlüsselung aller Daten in DynamoDB.

Jedes Element in einer DynamoDB-Tabelle wird mit einem Datenverschlüsselungsschlüssel (DEK) verschlüsselt. Dieser DEK wird dann mit einem Tabellenschlüssel verschlüsselt. Es gibt einen Tabellenschlüssel pro Tabelle. Jeder Tabellenschlüssel kann mehrere DEKs entschlüsseln. Und schließlich wird dieser Tabellenschlüssel mit einem CMK verschlüsselt. Abbildung 4-18 veranschaulicht diesen Ablauf.

Abbildung 4-18. AWS DynamoDB verwendet einen dreistufigen Umschlagverschlüsselungsprozess, bei dem 1) ein CMK zum Verschlüsseln eines Tabellenschlüssels verwendet wird, dann 2) der Tabellenschlüssel zum Verschlüsseln von DEKs verwendet wird und dann 3) die Schlüssel zum Verschlüsseln von Elementen innerhalb von DynamoDB verwendet werden.

Jedes Mal, wenn ein Client Daten aus der Tabelle lesen möchte, muss er zunächst eine Anfrage an KMS stellen und den Tabellenschlüssel mithilfe von KMS entschlüsseln. Wenn der Kunde berechtigt ist, den Tabellenschlüssel zu entschlüsseln, entschlüsselt DynamoDB ihn und speichert ihn im Namen des Kunden. Dieser Tabellenschlüssel kann dann verwendet werden, um jeden DEK zu entschlüsseln und so einzelne Elemente aus DynamoDB zu entschlüsseln. Auf diese Weise müssen die Kunden keine wiederholten Anfragen an das KMS stellen und sparen so KMS-Gebühren.

Tipp

Der Tabellenschlüssel in DynamoDb wird pro Verbindung für fünf Minuten zwischengespeichert. Ein zwischengespeicherter Tabellenschlüssel vermeidet wiederholte Anrufe bei AWS KMS und führt so zu einer schnelleren Leistung und geringeren Kosten. Um die Caching-Fähigkeit von KMS optimal zu nutzen, kann die Verwendung von Clients, die Datenbankverbindungen zusammenfassen können, zu einer besseren Leistung und geringeren Kosten führen.

Nachdem ich nun darüber gesprochen habe, wie AWS KMS zum Verschlüsseln von Daten in DynamoDB verwendet werden kann, möchte ich dir die drei Optionen vorstellen, die du für die Verwendung von KMS hast. Diese Optionen ähneln denen, die du bei AWS S3 hattest:

• CMK im Besitz von AWS

• Kundeneigene CMK

• Kundengeführtes CMK

Wie in Abbildung 4-19 zu sehen ist, kann die Art der CMK über die AWS Management Console ausgewählt werden:

CMK im Besitz von AWS

Dies ist die Standardoption bei AWS. Ein AWS-eigener CMK ist ein gemeinsam genutzter CMK, der von AWS verwendet wird, um den Tabellenschlüssel deines Kontos zu verschlüsseln. Diese Schlüssel werden nicht in deinem Konto angezeigt. AWS verwaltet und bearbeitet alle Aktivitäten im Zusammenhang mit dem CMK. Dieser CMK unterliegt nicht deiner Kontrolle, und du kannst den Zugriff auf diesen CMK nicht nachverfolgen oder überprüfen. Für das Verschlüsseln von Daten mit einem AWS-eigenen CMK fallen keine zusätzlichen Kosten an.

KMS-Kundenmanagement CMK

Dies ist die flexibelste Option für die Verwendung mit AWS DynamoDB. Diese Schlüssel werden vollständig vom Kunden verwaltet, und AWS kontrolliert oder verwaltet den Lebenszyklus dieser Schlüssel nicht. Beim Erstellen einer Tabelle kannst du den AWS KMS CMK angeben, den du als CMK für die Tabelle verwenden möchtest. Optional kannst du die Schlüssel jedes Jahr austauschen.

KMS-AWS verwaltet CMK

Von AWS verwaltete CMKs sind Schlüssel, die sich in deinem Konto befinden und in deinem Namen von AWS verwaltet werden. Dadurch erhältst du mehr Kontrolle über die Schlüssel und kannst den Zugang zu diesen Schlüsseln prüfen und überwachen. AWS hingegen kümmert sich um die Sicherheit der Infrastruktur, die hinter diesen Schlüsseln steht, und rotiert diese Schlüssel regelmäßig. Bei von AWS verwalteten Schlüsseln fallen jedoch die üblichen KMS-Gebühren für die Ver- und Entschlüsselung an.

Abbildung 4-19. Du kannst die Art von CMK auswählen, die du für die Verschlüsselung im Ruhezustand auf DynamoDB verwenden möchtest.

Amazon Aurora Relationaler Datenservice

Amazon Aurora ist ein weiteres beliebtes System zur Speicherung von Daten, das bei AWS eingesetzt wird. Aurora bietet einen Drop-in-Ersatz für beliebte RDBMS-Engines wie PostgreSQL und MySQL. Ähnlich wie AWS DynamoDB können auch Aurora-Datenbanken auf zwei Arten vor unberechtigtem Zugriff geschützt werden:

• Authentifizierung, um unbefugten Zugriff zu verhindern. Dies kann in zwei Kategorien von Authentifizierung unterteilt werden:

  • IAM-Datenbankauthentifizierung: Diese nutzt AWS IAM, um jede Anfrage zu autorisieren.

  • Passwort-Authentifizierung: Hier wird der traditionelle passwortbasierte Ansatz zur Authentifizierung gegenüber Aurora verwendet.

• Verwendung von Verschlüsselung zum Schutz der Daten.

Wie in Abbildung 4-20 zu sehen ist, kannst du bei der Erstellung deiner Datenbank entscheiden, welche Art von Authentifizierungsoption du verwenden möchtest.

Abbildung 4-20. Du kannst deine Wahl der Authentifizierung während der Erstellung der Datenbank angeben.

IAM-Authentifizierung auf Amazon Aurora

Bei der IAM-Authentifizierung verwendest du kein Passwort, um dich gegenüber der Datenbank zu authentifizieren, sondern erstellst ein Authentifizierungs-Token, das du deiner Datenbankanforderung beifügst. Diese Token können außerhalb der Datenbank mit AWS Signature Version 4 (SigV4) generiert werden und können anstelle der regulären Authentifizierung verwendet werden.

Der größte Vorteil der IAM-Authentifizierung ist, dass deine Identitäten in der Datenbank mit deinen Identitäten in deinem AWS-Konto synchronisiert werden. Dadurch wird verhindert, dass du Identitäten über deine Ressourcen verteilst.

Die IAM-Authentifizierung hat jedoch ihre Grenzen. Abhängig von der Klasse der DB-Instanz und deiner Arbeitslast kann es eine Begrenzung für die Anzahl der Verbindungen geben, die ein DB-Cluster pro Sekunde haben kann. AWS empfiehlt daher, die IAM-Authentifizierung nur für den vorübergehenden persönlichen Zugriff auf Datenbanken zu verwenden.

Passwort-Authentifizierung

Die Passwort-Authentifizierung ist die traditionelle Art der Authentifizierung. In diesem Fall muss jede Verbindung zur Datenbank mit dem traditionellen Benutzernamen und Passwort hergestellt werden. Jeder Benutzer und jede Rolle in der Datenbank muss von einem Admin-Benutzer erstellt werden, der in der Datenbank existiert. Bei den Passwörtern handelt es sich in der Regel um Textstrings, die sich jede aufrufende Einheit merken und beim Verbindungsaufbau eingeben muss. Du erstellst Benutzer mit SQL-Anweisungen wie CREATE USER für MySQL oder PostgreSQL.

Verschlüsselung auf Amazon Aurora

Ähnlich wie bei AWS DynamoDB und AWS S3 können alle auf Amazon Aurora gespeicherten Daten mit einem CMK verschlüsselt werden. Das Aktivieren der Verschlüsselung ist in Aurora extrem einfach, wie in Abbildung 4-21 zu sehen ist.

Abbildung 4-21. Du kannst die Verschlüsselung aktivieren, indem du bei der Erstellung deiner Datenbank ein Häkchen in das Kästchen "Verschlüsselung aktivieren" setzt. Du kannst auch den CMK auswählen, den du für die Verschlüsselung deiner Datenbank verwenden möchtest.

Du kannst entweder den von AWS verwalteten Schlüssel verwenden, um die Datenbank zu verschlüsseln, oder einen vorhandenen CMK bereitstellen, den du mit KMS kontrollieren kannst. Die Kompromisse zwischen der Verwendung eines vom Kunden verwalteten CMK und eines von AWS verwalteten CMK sind ähnlich wie bei der Verwendung von AWS DynamoDB oder AWS S3.

Mediensanitisierung und Datenlöschung

Die Entsorgung von Daten ist ein oft übersehener Aspekt des Datenschutzes, den Sicherheitsexperten berücksichtigen müssen. In physischen Rechenzentren müssen IT-Fachleute nach der Außerbetriebnahme eines Servers bestimmte Aktivitäten (die ich später näher erläutern werde) auf diesem Server durchführen, bevor er für andere Aktivitäten wiederverwendet werden kann. Diese Aktivitäten hängen von der Art der Daten ab, die ursprünglich auf diesem Server gespeichert waren. Dazu gehören u. a. das Löschen aller Daten, die Neuformatierung der Daten und so weiter.

Wenn deine Hardware streng geheime Daten gespeichert hat, musst du die Daten unter Umständen sicher von der Hardware löschen, bevor du sie für die Speicherung nicht vertraulicher Daten verwenden kannst. Dieser Vorgang wird Medienbereinigung genannt. Wenn du das nicht tust, sind die Daten möglicherweise für unbefugte Anwendungen angreifbar, die sich Zugang zu diesen Datenhashes verschaffen könnten.

Bei Cloud-Systemen hast du möglicherweise keine vollständige Kontrolle über den Prozess der Inbetriebnahme und Außerbetriebnahme von Servern. Dieses Problem kann in Microservice-Architekturen besonders ausgeprägt sein, in denen es üblich ist, neue Projektionen aufzusetzen oder sie abzubauen.

Zunächst möchte ich dich daran erinnern, dass alle sensiblen Daten auf deinen Speicherungen immer verschlüsselt sein müssen. Dadurch wird zumindest die Wahrscheinlichkeit eines Datenlecks verringert. AWS übernimmt die Verantwortung für die Bereinigung der zugrunde liegenden Speichermedien in deinem Namen. Für alle persistenten Speicherebenen, einschließlich EBS-gestützter Speichervolumes (z. B. Amazon Aurora, EC2 und DocumentDB), bereinigt AWS die Medien für dich gemäß den NIST-800-88-Standards. AWS garantiert, dass die von dir genutzten Speichermedien bereinigt und sicher gelöscht werden, bevor sie dem nächsten Kunden zur Verfügung gestellt werden. Durch diese Form der Mediensanierung entsprechen die AWS-Datenträger den meisten gesetzlichen Standards der Branche.

Wenn du jedoch in einer stark regulierten Branche arbeitest, in der die Datenverschlüsselung und die Garantie, die AWS für die Mediensanierung bietet, nicht ausreichen, kannst du Mediensanierungstools von Drittanbietern nutzen, um deine Speicher vor der Außerbetriebnahme sicher zu löschen.

Zusammenfassung

In diesem Kapitel ging es hauptsächlich um die Speicherung von Daten auf AWS. Zu Beginn habe ich die Sicherheit der Speicherung von Daten, die Zugriffskontrolle und die Verschlüsselung erläutert. Die meisten Mechanismen zur Speicherung in AWS können auf zwei Arten geschützt werden. Erstens kannst du mit AWS IAM-Richtlinien verhindern, dass Unbefugte auf deine sensiblen Daten zugreifen. Zweitens kannst du die Daten verschlüsseln und den Verschlüsselungscode sichern und so eine zusätzliche Sicherheitsebene zu deinem Datenschutzmechanismus hinzufügen.

Da Microservice-Umgebungen in der Regel zu polyglotten Persistenzmechanismen führen, müssen Sicherheitsexperten sicherstellen, dass jeder dieser Dienste den Sicherheitsrichtlinien für die einzelnen Datenspeicher besondere Aufmerksamkeit schenkt und die PoLP auf alle Speichermechanismen anwendet.