Optimieren Sie Ihren Sicherheitsfußabdruck in AWS - Teil 2

Dieser Blog ist eine Fortsetzung meines vorherigen Blogbeitrags über die Optimierung Ihres AWS-Sicherheitsfußabdrucks. In dieser Blogserie möchte ich mich darauf konzentrieren, Ihre Sicherheit in der Cloud zu verbessern, ohne Ihre laufenden Kosten weiter zu erhöhen. Oder noch besser: kosteneffizienter zu sein und so Ihre laufenden Kosten auf ein Minimum zu reduzieren.

Das heutige Thema ist Verschlüsselung. Ich werde meine Erfahrungen darüber teilen, wie Sie Ihre Data-at-Rest-Funktionen optimieren können.

Job null

Sicherheit ist der "Job Zero" für jedes Unternehmen. Im Rahmen unserer Ausbildung(ja, ich vertrete ein Unternehmen, das Premier Consulting Partner ist) tun wir unser Bestes, um unseren Kunden beizubringen, dass Sicherheit auch ein "Job Zero" ist. Oft erhalten wir Fragen wie: "Ist das nicht sehr teuer?" und "Das wird doch eine Weile dauern, bis es implementiert ist, oder?". Vor allem, wenn wir über Themen wie die Verschlüsselung von Daten im Ruhezustand sprechen. In meinem früheren Leben als On-Premises-Mitarbeiter habe ich gelernt, dass die Verschlüsselung von Data-at-Rest teuer, schwierig und langsam ist. Ich bin immer noch der Meinung, dass dies die Zutaten für das Rezept "Lassen Sie uns diese Anforderung überspringen" sind. Wenn ich mit neuen (AWS-)Kunden über ihre künftige Landingzone spreche, stelle ich fest, dass dieses Thema in den Augen der Kunden vermeidbar ist oder aufgeschoben werden kann. Ich habe schlechte Nachrichten für sie. Oder besser gesagt, ich habe gute Nachrichten für ihre Sicherheitslage. Die Anwendung von Encryption-at-Rest auf AWS muss nicht teuer oder schwierig sein.

Die Bedeutung eines Schlüsselverwaltungsdienstes

Die Verschlüsselung von Daten im Ruhezustand ist eine häufige Anforderung. Ein Schlüsselverwaltungsdienst ist sowohl für die Sicherheits- und Compliance-Verantwortlichen als auch für die Betriebs- und Implementierungsteams von großem Vorteil. Ohne einen Schlüsselverwaltungsdienst wird es Ihnen schwer fallen, die Verschlüsselung auf einheitliche Weise zu implementieren und auch die Compliance auf das gewünschte Niveau zu bringen. Höchstwahrscheinlich werden Sie mit einer suboptimalen Lösung für einen begrenzten Bereich Ihrer Datenbestände enden. Wir sind in der glücklichen Lage, dass AWS einen Schlüsselverwaltungsdienst anbietet: AWS Key Management Service.

Rationalisierung der laufenden Kosten

Wenn Sie sich das Preismodell von AWS Key Management Service (KMS) ansehen, werden Sie zwei Dimensionen erkennen. Die erste Dimension ist der so genannte "Schlüsselspeicher", der einfach in eine Einheit übersetzt werden kann, die einen Customer Master Key (CMK) darstellt. Wenn die jährliche Rotation aktiviert ist, zählt jede Version als eine Einheit. Der aktuelle Preis für eine Einheit beträgt $1 pro Monat. Wenn Sie also einen Schlüssel hosten und die automatische Schlüsselrotation aktivieren, belaufen sich die laufenden Gesamtkosten für diesen Schlüssel über drei Jahre auf: $3 für die erste Version im ersten Jahr, $2 für die Version nach der ersten Rotation und schließlich $1 für die letzte Version im letzten Jahr. Die Gesamtkosten (3 Jahre) für den Besitz dieses Schlüssels betragen $6.

Die Dimension "Schlüsselspeicher" kann optimiert werden, indem die Anzahl der Schlüssel reduziert wird. Es könnte ratsam sein, eine Strategie für die Grenzen der Schlüssel zu haben. Aus Sicht des Service können Sie derzeit 10.000 Customer Managed Keys (pro Region) in jedem AWS-Konto hosten. Sie werden diese Grenze wahrscheinlich nie erreichen, wenn Sie die AWS Best Practices anwenden und eine arbeitslastorientierte Kontostruktur verwenden. Selbst wenn Sie einen CMK pro Ressource erstellen. Es wird sich auf Ihre Rechnung auswirken. Aus finanzieller Sicht macht es also keinen Sinn, einen Schlüssel pro Ressource zu haben.

Auf der anderen Seite des Spektrums können Sie einen einzigen CMK pro AWS-Konto/Region haben. Diese Strategie "ein Schlüssel für alle" funktioniert technisch bis zu einem gewissen Grad. Der Haken an der Sache ist, dass jeder CMK Grenzen unterworfen ist. Das wahrscheinlichste Szenario ist, dass Sie entweder mit dem Limit für Operationen pro Sekunde oder mit der maximalen Länge der JSON-Ressourcenrichtlinie konfrontiert werden. Aus betrieblicher Sicht ist diese Strategie etwas riskant, da sie eine ernsthafte Kapazitätsplanung erfordert und der Explosionsradius während einer Katastrophe viel größer als gewünscht ist.

Die optimale Strategie liegt also irgendwo zwischen den beiden zuvor beschriebenen Szenarien. Das ist die Strategie, die ich in mehreren Fällen und bisher mit Erfolg angewendet habe. In einem klassischen dreistufigen Modell haben Sie drei Schichten (Präsentation, Anwendung und Daten). Als Faustregel gilt, dass jede Schicht ihren eigenen CMK hat. Die Datenmengen der Webserver werden also einen einzigen CMK verwenden, und dasselbe gilt für die Anwendungs- und Datenschicht. Dann schauen Sie sich jede Komponente innerhalb der Schichten an. Wie wahrscheinlich ist es, dass Sie auf ein Limit stoßen? Bei Most-Ressourcen (RDS, EBS, DynamoDB usw.) ist die Anzahl der generierten Datenschlüssel sehr gering. Sie können also gefahrlos 100 EBS-Volumes haben, die denselben CMK verwenden, bevor Sie auf eine ThrottlingException stoßen.

Bei Ressourcen mit einem Datenschlüssel pro Objekt wie S3 müssen Sie eine grobe Schätzung der Anzahl der Operationen pro Sekunde vornehmen, die Sie haben werden. Es kann sinnvoll sein, einen eigenen CMK für Buckets mit vielen E/A-Operationen zu haben. Sie sollten auch S3 Bucket Keys in Betracht ziehen. Wenn Sie diese Funktion aktivieren, erzeugt S3 einen zeitlich begrenzten Datenschlüssel, um jedes Objekt im Bucket zu verschlüsseln. Dadurch wird die Anzahl der Anfragen an Ihren CMK reduziert. Wir demonstrieren dies in einem früheren Blog hier.

Darüber hinaus können Sie zusätzliche CMKs verwenden, z.B. wenn Sie Protokolldateien Ihres ALB auf S3 auslagern. Durch die Verwendung eines dedizierten Schlüssels für Verwaltungszwecke können Sie sicherstellen, dass das Erreichen eines Limits beim Schreiben von Protokolldateien niemals Ihre Betriebszeit beeinträchtigt und umgekehrt.

Wenn Sie diese Strategie verfolgen, werden Sie in der Größenordnung von 5 CMKs pro Umgebung liegen. Das bedeutet insgesamt ~20 CMKs für Ihren gesamten DTAP-Lebenszyklus. Umgerechnet auf die Gesamtkosten über drei Jahre: (20 CMKs x $1 x 12 Monate) x 5 Versionen = $1.200 oder im Durchschnitt $33 pro Monat. Das ist eine ziemlich faire Gebühr, wenn Sie die Kosten und den Nutzen vergleichen. Zumindest können die Kosten keine gültige Ausrede sein, um auf die Verschlüsselung im Ruhezustand zu verzichten.

Die zweite Dimension heißt "Schlüsselverwendung". AWS berechnet Ihnen Operationen mit dem Schlüssel, wie Encrypt, Decrypt, GenerateDataKey und so weiter. Klingt teuer, aber das gilt nur für API-Aufrufe auf die Customer Master Keys. Anfragen zu Datenschlüsseln fallen nicht darunter. Wenn Sie ein EBS-Volumen verschlüsseln, lädt EC2 den Datenschlüssel (der aus dem Customer Master Key generiert wird) in den Speicher und verwendet diesen Datenschlüssel zur Ver-/Entschlüsselung von Daten. Ressourcen wie EBS, DynamoDB-Tabellen, RDS-Instanzen usw. verwenden 'langlebige' Datakeys. Für diese Ressourcen ist die Anzahl der Anfragen an den CMK begrenzt.

Bei der S3-Verschlüsselung ist dies völlig anders, da S3 (standardmäßig) für jedes Objekt in S3 einen Datenschlüssel erzeugt. Je nach der Anzahl der Objekte, die Sie in S3 hochladen, kann dies große Auswirkungen auf die Gesamtzahl der Operationen mit dem CMK haben.

Die vorherigen Szenarien können als serverseitige Verschlüsselung beschrieben werden. Es gibt ein weiteres Szenario, bei dem Sie AWS KMS für die clientseitige Verschlüsselung nutzen. In diesem Fall verwenden Sie das CMK, um einen symmetrischen Datenschlüssel zu generieren, den Sie dann zur Verschlüsselung Ihrer Daten verwenden. Der verschlüsselte Blob der Daten wird in S3 gespeichert. Vorzugsweise möchten Sie jedes Objekt mit einem eigenen Datenschlüssel verschlüsseln und den Datenschlüssel anschließend aus dem Speicher entfernen. In der Praxis kann dies jedoch beim Hochladen einer größeren Anzahl von Objekten zu Leistungsproblemen führen. In diesem Fall könnten Sie in Erwägung ziehen, den Datenschlüssel für die Verschlüsselung mehrerer Objekte wiederzuverwenden, z.B. indem Sie Worker verwenden, um eine Warteschlange mit Datenobjekten, die verschlüsselt werden müssen, zu konsumieren, und einen Datenschlüssel pro Worker haben und den Datenschlüssel alle X Objekte oder alle Y Sekunden (je nachdem, was zuerst kommt) aktualisieren. Auf diese Weise können Sie nicht nur Ihren Durchsatz optimieren, sondern auch die Kosten senken. Vergewissern Sie sich jedoch zunächst, dass sich diese zusätzliche Komplexität lohnt.

TL;DR

Wenn Sie Ihre Daten im Ruhezustand mit dem AWS Key Management Service (KMS) verschlüsseln, schützen Sie Ihre (Kunden-)Daten auf kostengünstige Weise. Kosteneffizienz kann erreicht werden durch 1) eine geringere Implementierung (Standardfunktion für fast alle AWS-Datenservices, Konfiguration im Stil einer "Checkbox"). Und 2) Betriebskosten im Vergleich (fast kein betrieblicher Aufwand, keine Leistungsbeeinträchtigung) und 3) günstiges Preismodell (Preis pro Schlüssel und Operation gegenüber Preis pro Gigabyte) im Vergleich zur herkömmlichen Verschlüsselung auf Speicherebene.