Amazon Redshift unterstützt UDFs ab Patch 198 nicht mehr die Erstellung von neuem Python. Das bestehende Python UDFs wird bis zum 30. Juni 2026 weiterhin funktionieren. Weitere Informationen finden Sie im [Blog-Posting](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/).
Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Datenverschlüsselung
Dieser Datenschutz bezieht sich auf Daten bei der Übertragung (während sie in Amazon Redshift oder daraus übertragen werden) sowie im Ruhezustand (während sie in Amazon-Redshift-Rechenzentren auf Datenträgern gespeichert sind). Sie können Daten während der Übertragung durch SSL oder eine clientseitige Verschlüsselung sichern. Sie haben folgende Optionen, um Data-at-Rest in Amazon Redshift zu schützen.
+ **Verwenden serverseitiger Verschlüsselung** – Sie fordern an, dass Amazon Redshift Ihre Daten verschlüsselt, bevor sie auf Datenträgern in den Rechenzentren des Services gespeichert werden, und die Daten entschlüsselt, wenn Sie die Objekte herunterladen.
+ **Verwenden clientseitiger Verschlüsselung** – Sie können Daten clientseitig verschlüsseln und die verschlüsselten Daten in Amazon Redshift hochladen. In diesem Fall verwalten Sie den Verschlüsselungsprozess, die Verschlüsselungsschlüssel und die zugehörigen Tools.
# Verschlüsselung im Ruhezustand
Serverseitige Verschlüsselung betrifft Datenverschlüsselung im Ruhezustand – das heißt, Amazon Redshift verschlüsselt optional Ihre Daten, wenn sie in die Rechenzentren des Services geschrieben werden, und entschlüsselt sie für Sie, wenn Sie darauf zugreifen. Wenn Sie Ihre Anfrage authentifizieren und Zugriffsberechtigungen besitzen, gibt es in Bezug auf die Art und Weise, wie Sie auf verschlüsselte oder nicht verschlüsselte Daten zugreifen, keinen Unterschied.
Amazon Redshift schützt Data-at-Rest durch Verschlüsselung. Optional können Sie alle auf Datenträgern gespeicherten Daten innerhalb eines Clusters und alle Backups in Amazon S3 mit Advanced Encryption Standard AES-256 schützen.
[Um die Schlüssel zu verwalten, die zum Verschlüsseln und Entschlüsseln Ihrer Amazon Redshift Redshift-Ressourcen verwendet werden, verwenden AWS Key Management Service Sie (). AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/) AWS KMSkombiniert sichere, hochverfügbare Hardware und Software, um ein für die Cloud skaliertes Schlüsselverwaltungssystem bereitzustellen. Mithilfe AWS KMS können Sie Verschlüsselungsschlüssel erstellen und die Richtlinien definieren, die steuern, wie diese Schlüssel verwendet werden können. AWS KMSunterstütztAWS CloudTrail, sodass Sie die Verwendung von Schlüsseln überprüfen können, um sicherzustellen, dass die Schlüssel ordnungsgemäß verwendet werden. Sie können Ihre AWS KMS Schlüssel in Kombination mit Amazon Redshift und unterstützten AWS Diensten verwenden. Eine Liste der unterstützten AWS KMS Dienste finden Sie unter [How AWS Services Use AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/services.html) im *AWS Key Management ServiceDeveloper Guide*.
Wenn Sie sich dafür entscheiden, das Admin-Passwort Ihres bereitgestellten Clusters oder Serverless-Namespace mithilfe des Administratorkennworts zu verwaltenAWS Secrets Manager, akzeptiert Amazon Redshift auch einen zusätzlichen AWS KMS-Schlüssel, der zur Verschlüsselung Ihrer Anmeldeinformationen AWS Secrets Manager verwendet wird. Dieser zusätzliche Schlüssel kann ein automatisch generierter Schlüssel von oder ein von Ihnen AWS Secrets Manager bereitgestellter benutzerdefinierter Schlüssel sein.
Der Amazon-Redshift-Abfrage-Editor v2 speichert die in den Abfrage-Editor eingegebenen Informationen sicher wie folgt:
+ Der Amazon-Ressourcenname (ARN) des KMS-Schlüssels zum Verschlüsseln von Daten des Abfrage-Editors v2.
+ Informationen zur Datenbankverbindung.
+ Namen und Inhalt von Dateien und Ordnern.
Der Amazon-Redshift-Abfrage-Editor v2 verschlüsselt Informationen mithilfe von Blockverschlüsselung entweder mit Ihrem KMS-Schlüssel oder dem KMS-Schlüssel des Servicekontos. Die Verschlüsselung Ihrer Amazon-Redshift-Redshift-Daten wird durch Ihre Amazon-Redshift-Cluster-Eigenschaften gesteuert.
**Topics**
+ [Verschlüsselung von Amazon-Redshift-Datenbanken](working-with-db-encryption.md)
# Verschlüsselung von Amazon-Redshift-Datenbanken
In Amazon Redshift ist Ihre Datenbank standardmäßig verschlüsselt, um Ihre Daten im Ruhezustand zu schützen. Die Datenbankverschlüsselung gilt für den Cluster selbst sowie für dessen Snapshots.
Sie können einen unverschlüsselten Cluster so ändern, dass er die Verschlüsselung AWS Key Management Service (AWS KMS) verwendet. Dazu können Sie entweder einen AWS eigenen Schlüssel oder einen vom Kunden verwalteten Schlüssel verwenden. Wenn Sie Ihren Cluster ändern, um die AWS KMS Verschlüsselung zu aktivieren, migriert Amazon Redshift Ihre Daten automatisch auf 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](changing-cluster-encryption.md).
Sie können den standardmäßigen verschlüsselten Cluster nach der Erstellung des Clusters zwar immer noch in unverschlüsselt umwandeln, wir empfehlen jedoch, den Cluster, der sensible Daten enthält, weiterhin verschlüsselt zu lassen. 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 lässt sich automatisch in ein HSM integrieren AWS KMS , aber nicht in dieses. Wenn Sie ein HSM verwenden, müssen Sie Client- und Serverzertifikate verwenden, um eine vertrauenswürdige Verbindung zwischen Amazon Redshift und Ihrem HSM herzustellen.
**Wichtig**
Amazon Redshift kann den Zugriff auf den KMS-Schlüssel für einen bereitgestellten Cluster oder Serverless-Namespace verlieren, wenn Sie den kundenseitig verwalteten KMS-Schlüssel deaktivieren. In diesen Fällen erstellt Amazon Redshift eine Sicherungskopie des Data Warehouses von Amazon Redshift und versetzt es für 14 Tage in den Status `inaccessible-kms-key`. Wenn Sie den KMS-Schlüssel innerhalb dieses Zeitraums wiederherstellen, stellt Amazon Redshift den Zugriff wieder her und das Warehouse funktioniert normal. Wenn der Zeitraum von 14 Tagen endet, ohne dass der KMS-Schlüssel wiederhergestellt wurde, löscht Amazon Redshift das Data Warehouse. Solange sich ein Warehouse im Status `inaccessible-kms-key` befindet, weist es die folgenden Merkmale auf:
Sie können keine Abfragen zum Data Warehouse ausführen.
Wenn das Data Warehouse das Produzenten-Warehouse eines Datashare ist, können Sie von Verbraucher-Warehouses aus keine Data-Sharing-Abfragen gegen das Data Warehouse ausführen.
Sie können keine regionenübergreifenden Snapshot-Kopien erstellen.
Informationen zum Wiederherstellen eines deaktivierten KMS-Schlüssels finden Sie unter [Aktivieren und Deaktivieren von Schlüsseln](https://docs.aws.amazon.com/kms/latest/developerguide/enabling-keys.html) im *AWS Key Management Service -Entwicklerhandbuch*. Wenn der KMS-Schlüssel des Warehouses gelöscht wurde, können Sie das Backup verwenden, um ein neues Data Warehouse zu erstellen, bevor das Warehouse im Status `inaccessible-kms-key` gelöscht wird.
## Verbesserungen des Verschlüsselungsprozesses für höhere Leistung und Verfügbarkeit
### Verschlüsselung mit Knoten RA3
Aktualisierungen des Verschlüsselungsprozesses für RA3 Knoten haben die Benutzererfahrung erheblich verbessert. Während des Vorgangs können sowohl Lese- als auch Schreibabfragen ausgeführt werden, wobei die Verschlüsselung weniger Leistungseinbußen verursacht. Außerdem wird die Verschlüsselung viel schneller abgeschlossen. Die aktualisierten Prozessschritte umfassen einen Wiederherstellungsvorgang und die Migration von Cluster-Metadaten zu einem Zielcluster. Die verbesserte Erfahrung gilt beispielsweise für Verschlüsselungstypen wie AWS KMS. Bei Datenvolumen im Petabyte-Bereich wurde die Dauer des Vorgangs von Wochen auf Tage reduziert.
Wenn Sie vor der Verschlüsselung Ihres Clusters weiterhin Datenbank-Workloads ausführen möchten, können Sie die Leistung verbessern und den Prozess beschleunigen, indem Sie Knoten mit elastischer Größenanpassung hinzufügen. Sie können die elastische Größenanpassung nicht verwenden, wenn die Verschlüsselung läuft. Verwenden Sie sie daher vor dem Verschlüsseln. Beachten Sie, dass das Hinzufügen von Knoten in der Regel zu höheren Kosten führt.
### Verschlüsselung mit anderen Knotentypen
Wenn Sie einen Cluster mit DC2 Knoten verschlüsseln, können Sie wie bei RA3 Knoten keine Schreibabfragen ausführen. Es können nur Leseabfragen ausgeführt werden.
### Nutzungshinweise zur Verschlüsselung mit Knoten RA3
Die folgenden Erkenntnisse und Ressourcen helfen Ihnen, sich auf die Verschlüsselung vorzubereiten und den Prozess zu überwachen.
+ **Ausführen von Abfragen nach dem Start der Verschlüsselung** – Nach dem Start der Verschlüsselung sind Lese- und Schreibvorgänge innerhalb von etwa fünfzehn Minuten verfügbar. Wie lange es dauert, bis der vollständige Verschlüsselungsprozess abgeschlossen ist, hängt von der Datenmenge im Cluster und den Workload-Ebenen ab.
+ **Wie lange dauert die Verschlüsselung?** – Wie lange die Verschlüsselung Ihrer Daten dauert, hängt von mehreren Faktoren ab: Dazu gehören die Anzahl der laufenden Workloads, die verwendeten Rechenressourcen sowie die Anzahl und die Art der Knoten. Wir empfehlen, die Verschlüsselung zunächst in einer Testumgebung durchzuführen. Als Faustregel gilt: Wenn Sie mit Datenvolumen im Petabyte-Bereich arbeiten, kann es wahrscheinlich 1–3 Tage dauern, bis die Verschlüsselung abgeschlossen ist.
+ **Woher weiß ich, dass die Verschlüsselung abgeschlossen ist?** – Nachdem Sie die Verschlüsselung aktiviert haben, bestätigt der Abschluss des ersten Snapshots, dass die Verschlüsselung abgeschlossen ist.
+ **Zurücksetzen der Verschlüsselung** – Wenn Sie den Verschlüsselungsvorgang rückgängig machen müssen, ist es am besten, die Wiederherstellung anhand des letzten Backups durchzuführen, das vor der Initiierung der Verschlüsselung erstellt wurde. Sie müssen alle neuen Updates (updates/deletes/inserts) nach dem letzten Backup erneut anwenden.
+ **Durchführen einer Tabellenwiederherstellung** – Beachten Sie, dass Sie eine Tabelle aus einem unverschlüsselten Cluster nicht in einem verschlüsselten Cluster wiederherstellen können.
+ **Verschlüsselung eines Clusters mit einem Knoten** – Die Verschlüsselung eines Clusters mit einem Knoten ist mit Leistungseinschränkungen verbunden. Dieser Vorgang dauert länger als die Verschlüsselung eines Clusters mit mehreren Knoten.
+ **Erstellen eines Backups nach der Verschlüsselung** – Wenn Sie die Daten in Ihrem Cluster verschlüsseln, wird erst dann ein Backup erstellt, wenn der Cluster vollständig verschlüsselt ist. Der Zeitaufwand dafür kann variieren. Die für das Backup benötigte Zeit kann je nach Clustergröße Stunden bis Tage betragen. Nach Abschluss der Verschlüsselung kann es zu einer Verzögerung kommen, bevor Sie ein Backup erstellen können.
Beachten Sie, dass alle Tabellen oder materialisierten Ansichten, die mit `BACKUP NO` erstellt wurden, nicht beibehalten werden, da ein backup-and-restore Vorgang während des Verschlüsselungsprozesses stattfindet. Weitere Informationen finden Sie unter [CREATE TABLE](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_TABLE_NEW.html) oder [CREATE MATERIALIZED VIEW](https://docs.aws.amazon.com/redshift/latest/dg/materialized-view-create-sql-command.html).
**Topics**
+ [Verbesserungen des Verschlüsselungsprozesses für höhere Leistung und Verfügbarkeit](#resize-classic-encryption)
+ [Verschlüsselung mit AWS KMS](#working-with-aws-kms)
+ [Verschlüsselung mit Hardwaresicherheitsmodulen](#working-with-HSM)
+ [Verschlüsselungsschlüsselrotation](#working-with-key-rotation)
+ [Ändern der Verschlüsselung von Clustern](changing-cluster-encryption.md)
+ [Migrieren zu einem HSM-verschlüsselten Cluster](migrating-to-an-encrypted-cluster.md)
+ [Rotieren der Verschlüsselungsschlüssel](manage-key-rotation-console.md)
## Verschlüsselung mit AWS KMS
Wenn Sie sich AWS KMS für die Schlüsselverwaltung mit Amazon Redshift entscheiden, gibt es eine vierstufige Hierarchie von Verschlüsselungsschlüsseln. 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 Cluster zurück AWS KMS keys , die Amazon Redshift oder Ihr AWS Konto erstellt hat oder zu deren Verwendung Sie berechtigt sind. AWS KMS Sie wählen einen KMS-Schlüssel zur Verwendung als Root-Schlüssel in der Verschlüsselungshierarchie aus.
Standardmäßig wählt Amazon Redshift einen automatisch AWS generierten eigenen Schlüssel als Stammschlüssel für Ihr AWS Konto zur Verwendung in Amazon Redshift aus.
Wenn Sie den Standardschlüssel nicht verwenden möchten, müssen Sie einen vom Kunden verwalteten KMS-Schlüssel separat haben (oder erstellen), AWS KMS bevor Sie Ihren 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](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) im *AWS Key Management Service -Entwicklerhandbuch*.
Wenn Sie einen AWS KMS Schlüssel von einem anderen AWS Konto verwenden möchten, müssen Sie über die Berechtigung zur Verwendung des Schlüssels verfügen und seinen Amazon-Ressourcennamen (ARN) in Amazon Redshift angeben. Weitere Informationen zum Zugriff auf Schlüssel finden Sie unter [Steuern des Zugriffs auf Ihre Schlüssel](https://docs.aws.amazon.com/kms/latest/developerguide/control-access.html) im *AWS Key Management Service Entwicklerhandbuch*. AWS KMS
Nachdem Sie einen Root-Schlüssel ausgewählt haben, fordert Amazon Redshift an, einen Datenschlüssel AWS KMS zu generieren und ihn mit dem ausgewählten Root-Schlüssel zu verschlüsseln. 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. Dann ruft Amazon Redshift auf, um das CEK AWS KMS zu entschlüsseln, und lädt das entschlüsselte CEK in den Speicher. *Weitere Informationen zu Zuschüssen, Verschlüsselungskontext und anderen verwandten Konzepten finden Sie AWS KMS unter [Konzepte](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html) im Entwicklerhandbuch.AWS Key Management Service *
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.
Wenn der Cluster neu gestartet wird, beginnt Amazon Redshift mit den intern gespeicherten, verschlüsselten Versionen von CEK und DEK, lädt sie erneut in den Speicher und ruft dann auf, um das CEK erneut mit dem KMS-Schlüssel AWS KMS zu entschlüsseln, sodass es in den Speicher 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 [Einen Cluster erstellen](create-cluster.md).
### Kopieren von —verschlüsselten Snapshots in einen anderen AWS KMS AWS-Region
AWS KMS Schlüssel sind spezifisch für einen. AWS-Region Wenn Sie das Kopieren von Amazon Redshift-Snapshots von einem verschlüsselten Quell-Cluster in einen anderen aktivieren möchten AWS-Region, aber Ihren eigenen AWS KMS Schlüssel für Snapshots im Ziel verwenden möchten, müssen Sie eine Genehmigung konfigurieren, damit Amazon Redshift einen Root-Schlüssel in Ihrem Konto im Ziel verwenden kann. AWS-Region Mit dieser Berechtigung ist Amazon Redshift in der Lage, Snapshots in der Ziel- AWS-Region zu verschlüsseln. Wenn Sie möchten, dass Snapshots im Ziel mit einem AWS-Region eigenen Schlüssel verschlüsselt werden, müssen Sie im Ziel keine Grants konfigurieren. AWS-Region Weitere Informationen zum regionenübergreifenden Kopieren von Snapshots finden Sie unter [Einen Snapshot in eine andere AWS Region kopieren](cross-region-snapshot-copy.md).
**Anmerkung**
Wenn Sie das Kopieren von Snapshots aus einem verschlüsselten Cluster und deren Verwendung AWS KMS als Stammschlüssel aktivieren, können Sie Ihren Cluster nicht umbenennen, da der Clustername Teil des Verschlüsselungskontextes ist. 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 erneut konfigurieren und aktivieren.
Der Prozess zum Konfigurieren der Berechtigung zum Kopieren von Snapshots sieht wie folgt aus.
1. Gehen Sie wie folgt vor, um in der AWS Zielregion eine Genehmigung für Snapshot-Kopien zu erstellen:
+ Wenn Sie noch keinen AWS KMS Schlüssel haben, den Sie verwenden können, erstellen Sie einen. Weitere Informationen zum Erstellen von AWS KMS Schlüsseln finden Sie unter [Schlüssel erstellen](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) im *AWS Key Management Service Entwicklerhandbuch*.
+ Geben Sie einen Namen für die Berechtigung zum Kopien von Snapshots an. Dieser Name muss in dieser AWS Region für Ihr AWS Konto eindeutig sein.
+ Geben Sie die AWS KMS Schlüssel-ID an, für die Sie den Zuschuss erstellen. Wenn Sie keine Schlüssel-ID angeben, wird die Berechtigung für Ihren Standardschlüssel übernommen.
1. Aktivieren Sie in der AWS Quellregion das Kopieren von Snapshots und geben Sie den Namen des Snapshot-Kopierzuschusses an, den Sie in der AWS Zielregion erstellt haben.
Dieser vorherige Vorgang ist nur erforderlich, wenn Sie das Kopieren von Snapshots mithilfe der AWS CLI Amazon Redshift Redshift-API oder aktivieren. SDKs 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 [Konfiguration der regionsübergreifenden Snapshot-Kopie für einen AWS KMS—verschlüsselten Cluster](xregioncopy-kms-encrypted-snapshot.md).
Bevor der Snapshot in die AWS Zielregion kopiert wird, entschlüsselt Amazon Redshift den Snapshot mithilfe des Stammschlüssels in der AWS Quellregion und verschlüsselt ihn 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 den Snapshot anschließend erneut mit dem Stammschlüssel in der Zielregion. AWS
## Verschlüsselung mit Hardwaresicherheitsmodulen
Wenn Sie es nicht AWS KMS für die Schlüsselverwaltung verwenden, können Sie ein Hardware-Sicherheitsmodul (HSM) für die Schlüsselverwaltung mit Amazon Redshift verwenden.
**Wichtig**
Die HSM-Verschlüsselung wird für DC2 Knotentypen nicht unterstützt. RA3
HSMs sind Geräte, die eine direkte Steuerung der Schlüsselgenerierung und -verwaltung ermöglichen. Sie bieten eine höhere Sicherheit, da die Schlüsselverwaltung getrennt von den Anwendungs- und Datenbankebenen erfolgt. Amazon Redshift unterstützt AWS CloudHSM Classic für die Schlüsselverwaltung. Der Verschlüsselungsprozess ist anders, wenn Sie HSM verwenden, um Ihre Verschlüsselungsschlüssel zu verwalten, anstatt. AWS KMS
**Wichtig**
Amazon Redshift unterstützt nur AWS CloudHSM Classic. Wir unterstützen den neueren AWS CloudHSM Service nicht.
AWS CloudHSM Classic ist für Neukunden geschlossen. Weitere Informationen finden Sie unter [CloudHSM Classic-Preise](https://aws.amazon.com/cloudhsm/pricing-classic/). AWS CloudHSM Classic ist nicht in allen AWS Regionen verfügbar. Weitere Informationen zu den verfügbaren AWS Regionen finden Sie [AWS in der Regionentabelle](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/).
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. Im Gegensatz AWS KMS dazu exportiert das HSM das CEK jedoch nicht nach 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\$1HSM 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 Schlüssel übergreifend [replizieren](https://docs.aws.amazon.com/cloudhsm/latest/userguide/cli-clone-hapg.html). 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](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-event-notifications.html).
## Verschlüsselungsschlüsselrotation
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\$1KEYS 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 von Schlüsseln finden Sie unter [Rotieren der Verschlüsselungsschlüssel](manage-key-rotation-console.md).
# Ändern der Verschlüsselung von Clustern
Sie können einen unverschlüsselten Cluster so ändern, dass er die Verschlüsselung AWS Key Management Service (AWS KMS) verwendet, indem Sie entweder einen AWS eigenen Schlüssel oder einen 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. Sie können einen verschlüsselten Cluster auch zu einem unverschlüsselten Cluster migrieren, indem Sie den Cluster mit AWS CLI, aber nicht mit dem ändern. AWS-Managementkonsole
Während des Migrationsprozesses ist der Cluster im schreibgeschützten Modus verfügbar, und der Clusterstatus wird als **Größenanpassung** angezeigt.
Wenn Ihr Cluster so konfiguriert ist, dass das regionsübergreifende Kopieren AWS von Snapshots aktiviert wird, müssen Sie ihn deaktivieren, bevor Sie die Verschlüsselung ändern. Weitere Informationen erhalten Sie unter [Einen Snapshot in eine andere AWS Region kopieren](cross-region-snapshot-copy.md) und [Konfiguration der regionsübergreifenden Snapshot-Kopie für einen AWS KMS—verschlüsselten Cluster](xregioncopy-kms-encrypted-snapshot.md). Wenn Sie eine Verschlüsselung per Hardwaresicherheitsmodul (HSM) aktivieren möchten, können Sie dies nicht erreichen, indem Sie das Cluster ändern. Sie müssen stattdessen ein neues, HSM-verschlüsseltes Cluster erstellen und die Daten in das neue Cluster migrieren. Weitere Informationen finden Sie unter [Migrieren zu einem HSM-verschlüsselten Cluster](migrating-to-an-encrypted-cluster.md).
------
#### [ Amazon Redshift console ]
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon Redshift Redshift-Konsole unter [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. Wählen Sie im Navigationsmenü **Clusters** (Cluster) und dann den Cluster aus, für den Sie die Verschlüsselung ändern möchten.
1. Wählen Sie **Properties (Eigenschaften)**.
1. Wählen Sie im Bereich **Database configurations (Datenbankkonfigurationen)** **Edit (Bearbeiten)** und anschließend **Edit encryption (Verschlüsselung bearbeiten)** aus.
1. Wählen Sie eine der Verschlüsselungsoptionen und dann **Save changes (Änderungen speichern)** aus.
------
#### [ AWS CLI ]
Um den zu verwendenden unverschlüsselten Cluster zu ändern AWS KMS, führen Sie den `modify-cluster` CLI-Befehl aus und geben Sie Folgendes an`–-encrypted`, wie im Folgenden gezeigt. Standardmäßig wird Ihr Standard-KMS-Schlüssel verwendet. Um einen vom Kunden verwalteten Schlüssel anzugeben, geben Sie auch die Option `--kms-key-id` an.
```
aws redshift modify-cluster --cluster-identifier --encrypted --kms-key-id
```
Führen Sie zum Entfernen der Verschlüsselung von einem Cluster den folgenden CLI-Befehl aus.
```
aws redshift modify-cluster --cluster-identifier --no-encrypted
```
------
# Migrieren zu einem HSM-verschlüsselten Cluster
Um von einem unverschlüsselten Cluster zu einem mit einem Hardwaresicherheitsmodul (HSM) verschlüsselten Cluster zu migrieren, müssen Sie ein neues verschlüsseltes Cluster erstellen und anschließend Ihre Daten in das neue Cluster migrieren. Sie können zu keinen HSM-verschlüsselten Cluster migrieren, indem Sie den Cluster anpassen.
Um von einem unverschlüsselten Cluster zu einem HSM-verschlüsselten Cluster zu migrieren, müssen Sie zuerst Ihre Daten aus dem vorhandenen Quellcluster entladen. Anschließend laden Sie die Daten in einen neuen Ziel-Cluster mit der gewünschten Verschlüsselungseinstellung. Weitere Informationen zum Starten eines verschlüsselten Clusters finden Sie unter [Verschlüsselung von Amazon-Redshift-Datenbanken](working-with-db-encryption.md).
Während des Migrationsprozesses steht Ihr Quell-Cluster bis zum letzten Schritt für schreibgeschützte Abfragen zur Verfügung. Im letzten Schritt werden der Ziel- und der Quell-Cluster umbenannt. Damit werden die Endpunkte vertauscht, sodass Datenverkehr an den neuen Ziel-Cluster weitergeleitet wird. Der Ziel-Cluster steht erst zur Verfügung, wenn Sie nach der Umbenennung einen Neustart durchgeführt haben. Unterbrechen Sie das Laden von Daten und andere Schreiboperationen für den Quell-Cluster, während Daten übertragen werden.
**Vorbereitung der Migration**
1. Identifizieren Sie alle abhängigen Systeme, die mit Amazon Redshift interagieren, z. B. Business Intelligence (BI)-Tools und ETL-Systeme (Extract, Transform, Load).
1. Identifizieren Sie Prüfabfragen, um die Migration zu testen.
Beispielsweise können Sie die folgende Abfrage verwenden, um die Anzahl der benutzerdefinieren Tabellen zu ermitteln.
```
select count(*)
from pg_table_def
where schemaname != 'pg_catalog';
```
Die folgende Abfrage gibt eine Liste aller benutzerdefinierten Tabellen und die Anzahl der Zeilen für jede Tabelle zurück.
```
select "table", tbl_rows
from svv_table_info;
```
1. Wählen Sie einen sinnvollen Zeitpunkt für Ihre Migration aus. Um einen Zeitpunkt zu finden, zu dem der Cluster möglichst wenig genutzt wird, überwachen Sie Cluster-Metriken, wie beispielsweise die CPU-Nutzung oder die Anzahl der Datenbankverbindungen. Weitere Informationen finden Sie unter [Anzeigen von Cluster-Leistungsdaten](performance-metrics-perf.md).
1. Verwerfen Sie nicht genutzte Tabellen.
Um eine Liste der Tabellen zu erstellen, die angibt, wie oft jede Tabelle abgefragt wurde, führen Sie die folgende Anfrage aus.
```
select database,
schema,
table_id,
"table",
round(size::float/(1024*1024)::float,2) as size,
sortkey1,
nvl(s.num_qs,0) num_qs
from svv_table_info t
left join (select tbl,
perm_table_name,
count(distinct query) num_qs
from stl_scan s
where s.userid > 1
and s.perm_table_name not in ('Internal worktable','S3')
group by tbl,
perm_table_name) s on s.tbl = t.table_id
where t."schema" not in ('pg_internal');
```
1. Starte Sie einen neuen, verschlüsselten Cluster.
Verwenden Sie dieselbe Port-Nummer für den Ziel-Cluster wie für den Quell-Cluster. Weitere Informationen zum Starten eines verschlüsselten Clusters finden Sie unter [Verschlüsselung von Amazon-Redshift-Datenbanken](working-with-db-encryption.md).
1. Richten Sie den Prozess zum Entladen und Laden ein.
Sie können das [Amazon Redshift Unload/Copy Utility](https://github.com/awslabs/amazon-redshift-utils/tree/master/src/UnloadCopyUtility) verwenden, um Sie bei der Migration von Daten zwischen Clustern zu unterstützen. Das Dienstprogramm exportiert Daten aus dem Quell-Cluster an einen Speicherort auf Amazon S3. Die Daten sind verschlüsselt mit AWS KMS. Anschließend importiert das Dienstprogramm die Daten automatisch in das Ziel. Optional können Sie das Dienstprogramm verwenden, um Amazon S3 zu bereinigen, nachdem die Migration abgeschlossen ist.
1. Führen Sie einen Test aus, um Ihren Prozess zu überprüfen und zu schätzen, wie lange Schreiboperationen ausgesetzt werden müssen.
Während der Entlade- und Ladeoperationen bewahren Sie die Datenkonsistenz, indem Sie das Laden von Daten und andere Schreiboperationen aussetzen. Führen Sie unter Verwendung einer Ihrer größten Tabellen den Entlade- und Ladeprozess aus, um die Zeit abschätzen zu können.
1. Erstellen Sie Datenbankenobjekte, wie Schemas, Tabellen und Ansichten. Um Ihnen bei der Generierung der erforderlichen DDL-Anweisungen (Data Definition Language) zu helfen, können Sie die Skripts [AdminViews](https://github.com/awslabs/amazon-redshift-utils/tree/master/src/AdminViews)im AWS GitHub Repository verwenden.
**So migrieren Sie Ihren Cluster**
1. Halten Sie alle ETL-Prozesse auf dem Quellcluster an.
Um sicherzustellen, dass derzeit keine Schreibvorgänge ausgeführt werden, überwachen Sie die Schreib-IOPS mithilfe der Amazon-Redshift-Managementkonsole. Weitere Informationen finden Sie unter [Anzeigen von Cluster-Leistungsdaten](performance-metrics-perf.md).
1. Führen sie die Prüfabfragen aus, die Sie zuvor identifiziert haben, um Informationen über den unverschlüsselten Quellcluster vor der Migration zu erfassen.
1. (Optional) Erstellen Sie eine WLM-Warteschlange (Workload Management), um im Quell- und im Zielcluster die maximal verfügbaren Ressourcen zu nutzen. Erstellen Sie beispielsweise eine Warteschlange namens `data_migrate` und konfigurieren Sie diese mit einem Speicher von 95 Prozent und einer Nebenläufigkeit von 4. Weitere Informationen finden Sie unter [Weiterleiten von Abfragen zu Warteschlangen auf der Grundlage von Benutzergruppen und Abfragegruppen](https://docs.aws.amazon.com/redshift/latest/dg/tutorial-wlm-routing-queries-to-queues.html) im *Datenbankentwicklerhandbuch zu Amazon Redshift*.
1. Führen Sie mithilfe der `data_migrate` Warteschlange den UnloadCopyUtility aus.
Überwachen Sie den UNLOAD- und COPY-Vorgang mit der Amazon-Redshift-Konsole.
1. Führen Sie die Prüfabfragen erneut aus und stellen Sie sicher, dass die Ergebnisse mit den Ergebnissen des Quellclusters übereinstimmen.
1. Benennen Sie Ihre Quell- und Zielcluster um, um die Endpunkte zu vertauschen. Um Störungen zu vermeiden, führen Sie diese Operation außerhalb der Geschäftszeiten aus.
1. Stellen Sie sicher, dass Sie mit allen Ihren SQL-Clients eine Verbindung zum Zielcluster herstellen können, z. B. für ETL und Berichtswerkzeuge.
1. Schließen Sie den unverschlüsselten Quellcluster.
# Rotieren der Verschlüsselungsschlüssel
Sie können das folgende Verfahren verwenden, um über die Amazon-Redshift-Konsole Verschlüsselungsschlüssel zu rotieren.
**So rotieren Sie die Verschlüsselungscodes für einen Cluster:**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon Redshift Redshift-Konsole unter [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. Wählen Sie im Navigationsmenü **Clusters** (Cluster) und dann den Cluster aus, der die Verschlüsselungsschlüssel aktualisieren soll.
1. Wählen Sie für **Actions (Aktionen)** **Rotate encryption (Verschlüsselung rotieren)** aus, um die Seite **Rotate encryption keys (Verschlüsselungsschlüssel rotieren)** anzuzeigen.
1. Wählen Sie auf der Seite **Rotate encryption keys (Schlüssel rotieren)** die Option **Rotate encryption keys (Schlüssel rotieren)** aus.
# Verschlüsselung während der Übertragung
Sie können Ihre Umgebung so konfigurieren, dass die Vertraulichkeit und Integrität der Daten während der Übertragung geschützt sind.
Nachfolgend erfahren Sie mehr über die Verschlüsselung von Daten während der Übertragung zwischen einem Amazon-Redshift-Cluster und SQL-Clients über JDBC/ODBC:
+ Sie können Verbindungen von SQL-Client-Tools zu Amazon-Redshift-Clustern über Java Database Connectivity (JDBC)- und Open Database Connectivity (ODBC)-Verbindungen herstellen.
+ Amazon Redshift unterstützt Secure Sockets Layer (SSL)-Verbindungen, um Daten und Serverzertifikate zu verschlüsseln, um das Zertifikat des Servers zu validieren, mit dem der Client die Verbindung herstellt. Der Client stellt die Verbindung zum Führungsknoten eines Amazon-Redshift-Clusters her. Weitere Informationen finden Sie unter [Konfigurieren von Sicherheitsoptionen für Verbindungen](connecting-ssl-support.md).
+ Um SSL-Verbindungen zu unterstützen, erstellt und installiert Amazon Redshift AWS Certificate Manager (ACM) ausgestellte Zertifikate auf jedem Cluster. Weitere Informationen finden Sie unter [Umstellung auf ACM-Zertifikate für SSL-Verbindungen](connecting-transitioning-to-acm-certs.md).
+ Um Ihre Daten bei der Übertragung innerhalb der AWS Cloud zu schützen, verwendet Amazon Redshift hardwarebeschleunigtes SSL für die Kommunikation mit Amazon S3 oder Amazon DynamoDB für KOPIER-, ENTLADEN-, Sicherungs- und Wiederherstellungsvorgänge.
Die folgenden Details gelten für die Verschlüsselung von Daten während der Übertragung zwischen einem Amazon-Redshift-Cluster und Amazon S3 oder DynamoDB:
+ Amazon Redshift verwendet zur Kommunikation mit Amazon S3 oder DynamoDB für COPY-, UNLOAD-, Backup- und Wiederherstellungsvorgänge hardwarebeschleunigtes SSL.
+ Redshift Spectrum unterstützt die serverseitige Verschlüsselung (SSE) von Amazon S3 unter Verwendung des Standardschlüssels Ihres Kontos, der vom AWS Key Management Service (KMS) verwaltet wird.
+ Sie können Amazon Redshift Redshift-Ladungen mit Amazon S3 und verschlüsseln. AWS KMS Weitere Informationen finden Sie unter [Verschlüsseln Ihrer Amazon Redshift Redshift-Ladungen mit Amazon S3](https://aws.amazon.com/blogs/big-data/encrypt-your-amazon-redshift-loads-with-amazon-s3-and-aws-kms/) und. AWS KMS
Die folgenden Details gelten für die Verschlüsselung und Signierung von Daten bei der Übertragung zwischen SDK AWS CLI - oder API-Clients und Amazon Redshift Redshift-Endpunkten:
+ Amazon Redshift stellt HTTPS-Endpunkte zum Verschlüsseln von Daten während der Übertragung bereit.
+ Um die Integrität von API-Anforderungen an Amazon Redshift zu schützen, müssen API-Aufrufe vom Aufrufer signiert werden. Anrufe werden mit einem X.509-Zertifikat oder dem AWS geheimen Zugriffsschlüssel des Kunden gemäß dem Signature Version 4-Signaturprozess (Sigv4) signiert. Weitere Informationen finden Sie unter [Signaturprozess mit Signaturversion 4](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html) im *Allgemeine AWS-Referenz*.
+ Verwenden Sie die AWS CLI oder eine der Optionen, um Anfragen AWS SDKs an zu stellen. AWS Diese Tools signieren automatisch die Anforderungen für Sie mit dem Zugriffsschlüssel, den Sie bei der Konfiguration der Tools angegeben haben.
Die folgenden Details gelten für due Verschlüsselung von Daten während der Übertragung zwischen Amazon-Redshift-Clustern und Amazon Redshift Query Editor v2:
+ Daten werden zwischen dem Abfrage-Editor v2 und Amazon-Redshift-Clustern über einen TLS-verschlüsselten Kanal übertragen.
# VPC-Verschlüsselungskontrollen mit Amazon Redshift
Amazon Redshift unterstützt [VPC-Verschlüsselungskontrollen](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-encryption-controls.html), eine Sicherheitsfunktion, mit der Sie die Verschlüsselung während der Übertragung für den gesamten Datenverkehr innerhalb und zwischen VPCs einer Region durchsetzen können. In diesem Dokument wird beschrieben, wie VPC-Verschlüsselungskontrollen mit Amazon Redshift Redshift-Clustern und serverlosen Arbeitsgruppen verwendet werden.
VPC-Verschlüsselungskontrollen bieten eine zentrale Steuerung zur Überwachung und Durchsetzung der Verschlüsselung während der Übertragung innerhalb Ihres VPCs Unternehmens. Wenn sie im Erzwingungsmodus aktiviert ist, wird sichergestellt, dass der gesamte Netzwerkverkehr entweder auf der Hardwareebene (mit AWS Nitro System) oder auf der Anwendungsebene (mit TLS/SSL) verschlüsselt wird.
Amazon Redshift lässt sich in VPC-Verschlüsselungskontrollen integrieren, um Sie bei der Erfüllung von Compliance-Anforderungen für Branchen wie Gesundheitswesen (HIPAA), Behörden (FedRAMP) und Finanzen (PCI DSS) zu unterstützen.
## So funktionieren VPC-Verschlüsselungskontrollen mit Amazon Redshift
VPC-Verschlüsselungskontrollen funktionieren in zwei Modi:
+ Überwachungsmodus: Bietet Einblick in den Verschlüsselungsstatus von Datenströmen und hilft bei der Identifizierung von Ressourcen, die unverschlüsselten Datenverkehr zulassen.
+ Erzwingungsmodus: Verhindert die Erstellung oder Verwendung von Ressourcen, die unverschlüsselten Datenverkehr innerhalb der VPC zulassen. Der gesamte Datenverkehr muss entweder auf der Hardwareebene (Nitro-basierte Instances) oder auf der Anwendungsebene (TLS/SSL) verschlüsselt werden.
## Anforderungen für die Verwendung von VPC-Verschlüsselungskontrollen
**Anforderungen an den Instanztyp**
Amazon Redshift benötigt Nitro-basierte Instances, um VPC-Verschlüsselungskontrollen zu unterstützen. Alle modernen Redshift-Instanztypen unterstützen die erforderlichen Verschlüsselungsfunktionen.
**SSL/TLS-Anforderungen**
Wenn VPC-Verschlüsselungskontrollen im Erzwingungsmodus aktiviert sind, muss der Parameter require\$1ssl auf true gesetzt werden und kann nicht deaktiviert werden. Dadurch wird sichergestellt, dass alle Client-Verbindungen verschlüsselte TLS-Verbindungen verwenden.
## Migration zu VPC-Verschlüsselungssteuerungen
**Für bestehende Cluster und Arbeitsgruppen**
Sie können VPC-Verschlüsselungskontrollen nicht im Erzwingungsmodus auf einer VPC aktivieren, die vorhandene Redshift-Cluster oder serverlose Arbeitsgruppen enthält. Gehen Sie wie folgt vor, um Verschlüsselungskontrollen zu verwenden, wenn Sie bereits über einen Cluster oder eine Arbeitsgruppe verfügen:
1. Erstellen Sie einen Snapshot Ihres vorhandenen Clusters oder Namespaces
1. Erstellen Sie eine neue VPC mit aktivierten VPC-Verschlüsselungskontrollen im Erzwingungsmodus
1. Stellen Sie mithilfe einer der folgenden Operationen eine Wiederherstellung vom Snapshot in die neue VPC her:
+ Für bereitgestellte Cluster: Verwenden Sie den Vorgang `restore-from-cluster-snapshot`
+ Für serverlose Systeme: Verwenden Sie den `restore-from-snapshot` Vorgang in Ihrer Arbeitsgruppe
**Beim Erstellen neuer Cluster oder Arbeitsgruppen in einer VPC mit aktivierten Verschlüsselungskontrollen muss der Parameter require\$1ssl auf true gesetzt werden.**
Amazon Redshift benötigt Nitro-basierte Instances, um VPC-Verschlüsselungskontrollen zu unterstützen. Alle modernen Redshift-Instanztypen unterstützen die erforderlichen Verschlüsselungsfunktionen.
**SSL/TLS-Anforderungen**
Wenn VPC-Verschlüsselungskontrollen im Erzwingungsmodus aktiviert sind, muss der Parameter require\$1ssl auf true gesetzt werden und kann nicht deaktiviert werden. Dadurch wird sichergestellt, dass alle Client-Verbindungen verschlüsselte TLS-Verbindungen verwenden.
## Überlegungen und Einschränkungen
Beachten Sie bei der Verwendung von VPC-Verschlüsselungskontrollen in Amazon Redshift Folgendes:
**VPC-State-Einschränkungen**
+ Die Erstellung von Clustern und Arbeitsgruppen wird blockiert, wenn die VPC-Verschlüsselungssteuerung aktiviert ist `enforce-in-progress`
+ Sie müssen warten, bis die VPC den `enforce` Modus erreicht hat, bevor Sie neue Ressourcen erstellen.
**SSL-Konfiguration**
+ require\$1ssl-Parameter: Muss immer `true` für Cluster und Arbeitsgruppen gelten, die mit verschlüsselter Verschlüsselung erstellt wurden VPCs
+ Sobald ein Cluster oder eine Arbeitsgruppe in einer VPC mit Verschlüsselungserzwang erstellt wurde, `require_ssl` kann er für seine gesamte Lebensdauer nicht deaktiviert werden
**Verfügbarkeit in Regionen**
Diese Funktion ist im Erzwingungsmodus mit Amazon Redshift Serverless in den folgenden Regionen nicht verfügbar:
+ Südamerika (São Paulo)
+ Europa (Zürich)
# Schlüsselverwaltung
Sie können Ihre Umgebung so konfigurieren, dass Daten mit Schlüsseln geschützt werden.
+ Amazon Redshift integriert sich automatisch mit AWS Key Management Service (AWS KMS) für die Schlüsselverwaltung. AWS KMSverwendet Umschlagverschlüsselung. Weitere Informationen finden Sie unter [Envelope-Verschlüsselung](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping).
+ Wenn Verschlüsselungsschlüssel verwaltet werdenAWS KMS, verwendet Amazon Redshift eine vierstufige, schlüsselbasierte Architektur für die Verschlüsselung. Diese Architektur besteht aus nach dem Zufallsprinzip generierten AES-256-Datenverschlüsselungsschlüsseln, einem Datenbankschlüssel, einem Clusterschlüssel und einem Root-Schlüssel. Weitere Informationen finden Sie unter [Verwendung AWS KMS von Amazon Redshift](https://docs.aws.amazon.com/kms/latest/developerguide/services-redshift.html).
+ Sie können Ihren eigenen vom Kunden verwalteten Schlüssel in AWS KMS erstellen. Weitere Informationen finden Sie unter [Erstellen von Schlüsseln](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html).
+ Sie können auch Ihr eigenes Schlüsselmaterial für neue AWS KMS keys importieren. Weitere Informationen finden Sie unter [Schlüsselmaterial importieren in AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/importing-keys.html).
+ Amazon Redshift unterstützt die Verwaltung von Verschlüsselungsschlüsseln in externen Hardware-Sicherheitsmodulen (HSMs). Das HSM kann ein lokales HSM oder sein AWS CloudHSM. Wenn Sie ein HSM verwenden, müssen Sie Client- und Serverzertifikate verwenden, um eine vertrauenswürdige Verbindung zwischen Amazon Redshift und Ihrem HSM herzustellen. Amazon Redshift unterstützt nur AWS CloudHSM Classic für die Schlüsselverwaltung. Weitere Informationen finden Sie unter [Verschlüsselung mit Hardwaresicherheitsmodulen](working-with-db-encryption.md#working-with-HSM). Informationen zu finden Sie AWS CloudHSM unter [Was istAWS CloudHSM?](https://docs.aws.amazon.com/cloudhsm/latest/userguide/introduction.html)
+ Sie können Verschlüsselungsschlüssel für verschlüsselte Cluster rotieren. Weitere Informationen finden Sie unter [Verschlüsselungsschlüsselrotation](working-with-db-encryption.md#working-with-key-rotation).