Verschlüsselung von Amazon-Redshift-Datenbanken - Amazon Redshift

Verschlüsselung von Amazon-Redshift-Datenbanken

Sie können in Amazon Redshift die Datenbankverschlüsselung für Ihre Cluster aktivieren, um Data-at-Rest besser zu schützen. Wenn Sie die Verschlüsselung für einen Cluster aktivieren, werden die Datenblöcke und die Metadaten des Systems für den Cluster und Snapshots des Clusters verschlüsselt.

Sie können die Verschlüsselung aktivieren, wenn Sie Ihren Cluster starten, oder Sie können einen unverschlüsselten Cluster so ändern, dass er AWS Key Management Service (AWS KMS)-Verschlüsselung verwendet. Dazu können Sie einen von AWS oder vom Kunden verwalteten Schlüssel verwenden. Wenn Sie Ihren Cluster bearbeiten, um die AWS KMS-Verschlüsselung zu aktivieren, migriert Amazon Redshift Ihre Daten automatisch in einen neuen, verschlüsselten Cluster. Aus dem verschlüsselten Cluster erstellte Snapshots sind ebenfalls verschlüsselt. Sie können auch einen unverschlüsselten Cluster in einem verschlüsselten Cluster migrieren, indem Sie den Cluster anpassen und die Option Encrypt database (Datenbank verschlüsseln) wählen. Weitere Informationen finden Sie unter Ändern der Verschlüsselung von Clustern.

Die Verschlüsselung in Amazon Redshift ist zwar optional, wir empfehlen jedoch, sie für Cluster mit sensiblen Daten zu aktivieren. Beachten Sie außerdem, dass für Ihre Daten möglicherweise Richtlinien oder Vorschriften gelten, die eine Verschlüsselung obligatorisch machen. Beispiele für Vorschriften, die diesbezüglich Richtlinien zur Verarbeitung von bestimmten Arten von Daten haben, sind beispielsweise PCI DSS (Payment Card Industry Data Security Standard), SOX (Sarbanes-Oxley Act) und HIPAA (Health Insurance Portability and Accountability Act).

Amazon Redshift verwendet eine Schlüsselhierarchie, um die Datenbank zu verschlüsseln. Sie können AWS Key Management Service (AWS KMS) oder ein Hardwaresicherheitsmodul (HSM) verwenden, um die Verschlüsselungsschlüssel der obersten Ebene in dieser Hierarchie zu verwalten. Der Prozess, den Amazon Redshift zur Verschlüsselung verwendet, richtet sich danach, wie Sie Schlüssel verwalten. Amazon Redshift integriert sich automatisch in AWS KMS, aber nicht in ein HSM. Wenn Sie ein HSM verwenden, müssen Sie Client- und Serverzertifikate verwenden, um eine vertrauenswürdige Verbindung zwischen Amazon Redshift und Ihrem HSM herzustellen.

Datenbankverschlüsselung für Amazon Redshift mithilfe von AWS KMS

Wenn Sie AWS KMS zur Schlüsselverwaltung mit Amazon Redshift verwenden, steht Ihnen eine vierstufige Hierarchie von Verschlüsselungsschlüsseln zur Verfügung. Diese Schlüssel sind (in der Abfolge der Hierarchie) der Root-Schlüssel, ein Clusterschlüssel (CEK, Cluster Encryption Key), ein Datenbankschlüssel (DEK, Database Encryption Key) und Schlüssel zur Datenverschlüsselung.

Wenn Sie Ihren Cluster starten, gibt Amazon Redshift eine Liste der AWS KMS keys zurück, die Ihr AWS-Konto erstellt hat oder in AWS KMS verwenden darf. Sie wählen einen KMS-Schlüssel zur Verwendung als Root-Schlüssel in der Verschlüsselungshierarchie aus.

Standardmäßig verwendet Amazon Redshift Ihren Standardschlüssel als Root-Schlüssel. Ihr Standardschlüssel ist ein von AWS verwalteter Schlüssel, der für Ihr AWS-Konto zur Verwendung in Amazon Redshift erstellt wird. AWS KMS erstellt diesen Schlüssel, wenn Sie in einer AWS-Region zum ersten Mal einen verschlüsselten Cluster starten und den Standardschlüssel wählen.

Wenn Sie nicht den Standardschlüssel verwenden möchten, müssen Sie in AWS KMS einen separaten, vom Kunden verwalteten KMS-Schlüssel besitzen (oder erstellen), bevor Sie den Cluster in Amazon Redshift starten. Vom Kunden verwaltete Schlüssel gewähren Ihnen größere Flexibilität, einschließlich der Möglichkeit, eine Zugriffssteuerung zu erstellen, zu rotieren, zu deaktivieren und zu definieren sowie die Verschlüsselungsschlüssel zu prüfen, um Ihre Daten besser zu schützen. Weitere Informationen zum Erstellen von KMS-Schlüsseln finden Sie unter Erstellen von Schlüsseln im AWS Key Management Service-Entwicklerhandbuch.

Wenn Sie einen AWS KMS-Schlüssel aus einem anderen AWS-Konto verwenden möchten, müssen Sie berechtigt sein, diesen Schlüssel zu verwenden, und seinen Amazon-Ressourcennamen (ARN) in Amazon Redshift angeben. Weitere Informationen zum Zugriff auf Schlüssel in AWS KMS finden Sie unter Steuern des Zugriffs auf Ihre Schlüssel im AWS Key Management Service-Entwicklerhandbuch.

Nachdem Sie einen Root-Schlüssel ausgewählt haben, fordert Amazon Redshift bei AWS KMS die Generierung eines Datenschlüssels und dessen Verschlüsselung mittels des ausgewählten Root-Schlüssels an. Dieser Datenschlüssel wird in Amazon Redshift als CEK verwendet. AWS KMS exportiert den verschlüsselten CEK nach Amazon Redshift. Hier wird er in einem vom Cluster getrennten Netzwerk intern auf einem Datenträger gespeichert, zusammen mit der Genehmigung für den KMS-Schlüssel und dem Verschlüsselungskontext für den CEK. Nur der verschlüsselte CEK wird nach Amazon Redshift exportiert; der KMS-Schlüssel bleibt in AWS KMS. Außerdem übergibt Amazon Redshift den verschlüsselten CEK über einen sicheren Kanal an den Cluster und lädt ihn in den Arbeitsspeicher. Anschließend ruft Amazon Redshift AWS KMS auf, um den CEK zu entschlüsseln, und lädt den entschlüsselten CEK in den Arbeitsspeicher. Weitere Informationen zu Genehmigungen, Verschlüsselungskontext und anderen Konzepten im Zusammenhang mit AWS KMS finden Sie unter Konzepte im AWS Key Management Service-Entwicklerhandbuch.

Anschließend generiert Amazon Redshift nach dem Zufallsprinzip einen Schlüssel zur Verwendung als DEK und lädt ihn im Cluster in den Arbeitsspeicher. Der entschlüsselte CEK wird zum Verschlüsseln des DEK verwendet, der dann über eine gesicherte Verbindung vom Cluster übergeben wird und von Amazon Redshift intern in einem vom Cluster getrennten Netzwerk auf Datenträger gespeichert wird. Wie bei dem CEK werden sowohl die verschlüsselte als auch die entschlüsselte Version des in dem Cluster in den Arbeitsspeicher geladen. Mit dem entschlüsselten DEK werden anschließend die einzelnen Verschlüsselungsschlüssel verschlüsselt, die nach dem Zufallsprinzip für die einzelnen Blöcke in der Datenbank generiert werden.

Bei einem Neustart des Clusters beginnt Amazon Redshift mit den intern gespeicherten, verschlüsselten Versionen des CEK und DEK, lädt sie erneut in den Arbeitsspeicher und ruft dann AWS KMS auf, um den CEK erneut mit dem KMS-Schlüssel zu entschlüsseln, damit er in den Arbeitsspeicher geladen werden kann. Anschließend wird der entschlüsselte CEK verwendet, um den DEK wieder zu entschlüsseln, der entschlüsselte DEK wird in den Arbeitsspeicher geladen und kann dazu verwendet werden, Datenblöcke wie gewünscht zu verschlüsseln und zu entschlüsseln.

Weitere Informationen zum Erstellen von Amazon-Redshift-Clustern, die mit AWS KMS-Schlüsseln verschlüsselt sind, finden Sie unter Erstellen eines Clusters und Verwalten von Clustern mithilfe des AWS CLI und Amazon Redshift API.

Kopieren eines mit AWS KMS verschlüsselten Snapshots in eine andere AWS-Region

AWS KMS-Schlüssel gelten für eine bestimmte AWS-Region. Wenn Sie das Kopieren von Amazon-Redshift-Snapshots in eine andere AWS-Region aktivieren und der Quell-Cluster und dessen Snapshots mit einem Root-Schlüssel aus AWS KMS verschlüsselt sind, müssen Sie eine Berechtigung für Amazon Redshift zur Verwendung eines Root-Schlüssels in der AWS-Zielregion konfigurieren. Mit dieser Berechtigung ist Amazon Redshift in der Lage, Snapshots in der AWS-Zielregion zu verschlüsseln. Weitere Informationen zum regionenübergreifenden Kopieren von Snapshots finden Sie unter Kopieren von Snapshots in eine andere AWS-Region.

Anmerkung

Wenn Sie das Kopieren von Snapshots aus einem verschlüsselten Cluster zulassen und AWS KMS für Ihren Root-Schlüssel verwenden, dürfen Sie Ihren Cluster nicht umbenennen, denn der Clustername ist Teil des Verschlüsselungskontexts. Wenn Sie Ihren Cluster umbenennen müssen, können Sie das Kopieren von Snapshots in der AWS-Quellregion deaktivieren, den Cluster umbenennen und dann das Kopieren von Snapshots wieder konfigurieren und aktivieren.

Der Prozess zum Konfigurieren der Berechtigung zum Kopieren von Snapshots sieht wie folgt aus.

  1. Erstellen Sie in der AWS-Zielregion eine Berechtigung zum Kopieren von Snapshots, indem Sie die folgenden Schritte ausführen:

    • Wenn Sie noch keinen AWS KMS-Schlüssel zur Verwendung haben, erstellen Sie einen. Weitere Informationen zum Erstellen von AWS KMS-Schlüsseln finden Sie unter Erstellen von Schlüsseln im AWS Key Management Service-Entwicklerhandbuch.

    • Geben Sie einen Namen für die Berechtigung zum Kopien von Snapshots an. Dieser Name muss für Ihr AWS-Konto in dieser AWS-Region eindeutig sein.

    • Geben Sie die AWS KMS-Schlüssel-ID an, für die Sie die Berechtigung erstellen. Wenn Sie keine Schlüssel-ID angeben, wird die Berechtigung für Ihren Standardschlüssel übernommen.

  2. Aktivieren Sie in der AWS-Quellregion das Kopieren von Snapshots und geben Sie den Namen der Berechtigung zum Kopieren von Snapshots an, die Sie in der AWS-Zielregion erstellt haben.

Der oben angegebene Prozess ist nur notwendig, wenn Sie das Kopieren von Snapshots unter Verwendung der AWS CLI, der Amazon Redshift API oder der SDKs aktivieren. Wenn Sie die Konsole verwenden, stellt Amazon Redshift den richtigen Workflow zum Konfigurieren der Berechtigung bereit, wenn Sie das regionenübergreifende Kopieren von Snapshots aktivieren. Weitere Informationen zum Konfigurieren von regionenübergreifenden Snapshot-Kopien für AWS KMS-verschlüsselte Cluster unter Verwendung der Konsole finden Sie unter Konfigurieren von regionenübergreifenden Snapshot-Kopien für mit AWS KMS verschlüsselte Cluster.

Bevor der Snapshot in die AWS-Zielregion kopiert wird, entschlüsselt Amazon Redshift den Snapshot mit dem Root-Schlüssel in der AWS-Quellregion und verschlüsselt ihn dann vorübergehend erneut mit einem zufällig generierten RSA-Schlüssel, den Amazon Redshift intern verwaltet. Amazon Redshift kopiert dann den Snapshot über einen sicheren Kanal in die AWS-Zielregion, entschlüsselt den Snapshot mit dem intern verwalteten RSA-Schlüssel und verschlüsselt dann den Snapshot mit dem Root-Schlüssel in der AWS-Zielregion erneut.

Weitere Informationen zum Konfigurieren von Kopiergenehmigungen für Snapshots für AWS KMS-verschlüsselte Cluster finden Sie unter Konfigurieren von Amazon Redshift zur Verwendung von AWS KMS-Verschlüsselungsschlüsseln mit der Amazon Redshift API und AWS CLI.

Verschlüsselung für Amazon Redshift mit Hardwaresicherheitsmodulen

Wenn Sie AWS KMS nicht zur Schlüsselverwaltung verwenden, können Sie zur Schlüsselverwaltung mit Amazon Redshift ein Hardwaresicherheitsmodul (HSM) verwenden.

Wichtig

Die HSM-Verschlüsselung wird für DC2- und RA3-Knotentypen nicht unterstützt.

HSMs sind Geräte zur direkten Steuerung der Erzeugung und Verwaltung von Schlüsseln. Sie bieten eine höhere Sicherheit, da die Schlüsselverwaltung getrennt von den Anwendungs- und Datenbankebenen erfolgt. Amazon Redshift unterstützt zur Schlüsselverwaltung AWS CloudHSM Classic. Wenn Sie zur Verwaltung Ihrer Verschlüsselungsschlüssel anstelle von HSMs verwenden, ändert sich der Verschlüsselungsprozess AWS KMS.

Wichtig

Amazon Redshift unterstützt nur AWS CloudHSM Classic. Wir unterstützen nicht den neueren AWS CloudHSM-Service.

AWS CloudHSM Classic ist für Neukunden geschlossen. Weitere Informationen finden Sie unter CloudHSM-Classic-Preise. AWS CloudHSM Classic ist nicht in allen AWS-Regionen verfügbar. Weitere Informationen zu verfügbaren AWS-Regionen finden Sie in der Tabelle der AWS-Regionen.

Wenn Sie Ihren Cluster zur Verwendung eines HSM konfigurieren, sendet Amazon Redshift eine Anforderung an das HSM, einen Schlüssel zur Verwendung als CEK zu generieren und zu speichern. Anders als AWS KMS exportiert das HSM den CEK jedoch nicht in Amazon Redshift. Stattdessen generiert Amazon Redshift den DEK nach dem Zufallsprinzip im Cluster und übergibt ihn an das HSM, um vom CEK verschlüsselt zu werden. Das HSM gibt den verschlüsselten DEK an Amazon Redshift zurück. Hier wird er mittels eines nach dem Zufallsprinzip generierten internen Root-Schlüssels weiter verschlüsselt und intern auf einem Datenträger in einem vom Cluster getrennten Netzwerk gespeichert. Außerdem lädt Amazon Redshift die entschlüsselte Version des DEK in den Arbeitsspeicher im Cluster, sodass der DEK zur Verschlüsselung und Entschlüsselung der einzelnen Schlüssel für die Datenblöcke verwendet werden kann.

Wenn der Cluster neu gestartet wird, entschlüsselt Amazon Redshift den intern gespeicherten, doppelt verschlüsselten DEK mit dem internen Root-Schlüssel, um den intern gespeicherten DEK wieder in den CEK-verschlüsselten Zustand zurückzuversetzen. Anschließend wird der CEK-verschlüsselte DEK an das HSM übergeben, wo er entschlüsselt und an Amazon Redshift zurückgegeben wird. Dort kann er wieder in den Arbeitsspeicher geladen und für die einzelnen Datenblockschlüssel verwendet werden.

Konfigurieren einer vertrauenswürdigen Verbindung zwischen Amazon Redshift und einem HSM

Wenn Sie sich bei der Verwaltung Ihres Clusterschlüssels für ein HSM entscheiden, müssen Sie eine vertrauenswürdige Netzwerkverbindung zwischen Amazon Redshift und Ihrem HSM herstellen. Hierzu müssen Client- und Serverzertifikate konfiguriert werden. Über die vertrauenswürdige Verbindung werden bei Verschlüsselungs- und Entschlüsselungsoperationen die Verschlüsselungsschlüssel zwischen dem HSM und Amazon Redshift übergeben.

Amazon Redshift erstellt anhand eines nach dem Zufallsprinzip erzeugten privaten und öffentlichen Schlüsselpaars ein öffentliches Clientzertifikat. Dieses Schlüsselpaar wird verschlüsselt und intern gespeichert. Sie laden das öffentliche Clientzertifikat in Ihr HSM herunter, registrieren es in dem HSM und weisen es der betreffenden HSM-Partition zu.

Sie stellen Amazon Redshift die IP-Adresse des HSM, den Namen der HSM-Partition, das Passwort der HSM-Partition und ein öffentliches HSM-Serverzertifikat bereit, das mit einem internen Root-Schlüssel verschlüsselt wird. Amazon Redshift schließt den Konfigurationsprozess ab und verifiziert, ob eine Verbindung zum HSM hergestellt werden kann. Falls diese Verbindung nicht hergestellt werden kann, wechselt der Cluster in den Zustand INCOMPATIBLE_HSM und wird nicht erstellt. Wenn dies der Fall ist, müssen Sie den unvollständigen Cluster löschen und den Vorgang wiederholen.

Wichtig

Wenn Sie Ihren Cluster so ändern, dass eine andere HSM-Partition verwendet wird, überprüft Amazon Redshift, ob eine Verbindung zur neuen Partition hergestellt werden kann, verifiziert jedoch nicht, ob ein gültiger Verschlüsselungsschlüssel vorhanden ist. Um diese andere Partition verwenden zu können, müssen Sie Ihre Schlüssel in die neue Partition replizieren. Wenn der Cluster neu gestartet wird und Amazon Redshift keinen gültigen Schlüssel findet, schlägt der Neustart fehl. Weitere Informationen finden Sie unter Replizieren von Schlüsseln über mehrere HSMs.

Wenn Amazon Redshift nach der erstmaligen Konfiguration keine Verbindung zu dem HSM herstellen kann, wird ein Ereignis protokolliert. Weitere Informationen zu diesen Ereignissen finden Sie unter Amazon-Redshift-Ereignisbenachrichtigungen.

Rotation von Verschlüsselungsschlüsseln in Amazon Redshift

Sie können in Amazon Redshift Verschlüsselungsschlüssel für verschlüsselte Cluster rotieren. Wenn Sie die Schlüsselrotation starten, rotiert Amazon Redshift den CEK für das angegebene Cluster sowie alle automatisierten oder manuellen Snapshots des Clusters. Außerdem rotiert Amazon Redshift den DEK für das angegebene Cluster, kann jedoch den DEK für die Snapshots nicht rotieren, während sie intern in Amazon Simple Storage Service (Amazon S3) gespeichert und mithilfe des vorhandenen DEK verschlüsselt sind.

Während des Rotationsvorgangs wird der Cluster in den Zustand ROTATING_KEYS versetzt. Nach Abschluss des Vorgangs kehrt der Cluster wieder in den Zustand AVAILABLE zurück. Amazon Redshift verarbeitet die Entschlüsselung und Neuverschlüsselung während der Schlüsselrotation.

Anmerkung

Bei Snapshots ohne Quellcluster können die Schlüssel nicht rotiert werden. Wenn Sie einen Cluster löschen möchten, überlegen Sie zuerst, ob für die zugehörigen Snapshots die Schlüssel rotiert werden müssen.

Da der Cluster während des Rotierens der Schlüssel kurzweilig nicht verfügbar ist, sollten Sie die Schlüssel nur so oft rotieren, wie es die Anforderungen an Ihre Daten erforderlich machen, oder wenn Sie den Verdacht haben, dass die Schlüssel möglicherweise kompromittiert wurden. es hat sich als Methode bewährt, zu überprüfen, welche Arten von Daten gespeichert werden, und zu planen, wie häufig die Schlüssel zur Verschlüsselung dieser Daten rotiert werden sollen. Die Häufigkeit von Schlüsselrotationen richtet sich nach Ihren Unternehmensrichtlinien zur Datensicherheit, nach den Industriestandards für sensible Daten sowie nach der erforderlichen Konformität gegenüber geltenden Vorschriften. Stellen Sie sicher, dass in Ihrem Plan ein sorgfältig abgewogen wird zwischen Sicherheitsanforderungen einerseits und Aspekten der Verfügbarkeit Ihres Clusters andererseits.

Weitere Informationen zum Rotieren der Schlüssel finden Sie unter Rotieren der Verschlüsselungsschlüssel mithilfe der Amazon-Redshift-Konsole und Rotieren von Verschlüsselungsschlüsseln mithilfe der Amazon Redshift API und AWS CLI.