Amazon Redshift unterstützt ab dem 1. November 2025 nicht mehr die Erstellung neuer Python-UDFs. Wenn Sie Python-UDFs verwenden möchten, erstellen Sie die UDFs vor diesem Datum. Bestehende Python-UDFs funktionieren weiterhin wie gewohnt. Weitere Informationen finden Sie im Blog-Posting
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 AWS Key Management Service (AWS KMS)-Verschlüsselung verwendet. Dazu können Sie einen AWS-eigenen oder einen oder kundenseitig 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.
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 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.
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 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 RA3-Knoten
Aktualisierungen des Verschlüsselungsprozesses für RA3-Knoten führten zu erheblichen Verbesserungen. 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 keine Schreibabfragen ausführen, wie dies bei RA3-Knoten der Fall ist. Es können nur Leseabfragen ausgeführt werden.
Nutzungshinweise für die Verschlüsselung mit RA3-Knoten
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 (Aktualisierungen/Löschungen/Einfügungen) 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.
Hinweis: Da während des Verschlüsselungsprozesses ein Backup- und Wiederherstellungsvorgang stattfindet, werden alle Tabellen oder materialisierten Ansichten, die mit
BACKUP NOerstellt wurden, nicht beibehalten. Weitere Informationen finden Sie unter CREATE TABLE oder CREATE MATERIALIZED VIEW.
Themen
Verschlüsselung mit 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 Amazon Redshift oder 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 wählt Amazon Redshift einen automatisch generierten AWS-eigenen Schlüssel als Stammschlüssel für Ihr AWS-Konto zur Verwendung in Amazon Redshift aus.
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.
Kopieren eines mit AWS KMS verschlüsselten Snapshots in eine andere AWS-Region
AWS KMS-Schlüssel gelten für eine 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 Ziel-AWS-Region konfigurieren. Mit dieser Berechtigung ist Amazon Redshift in der Lage, Snapshots in der Ziel-AWS-Region zu verschlüsseln. Wenn Sie Snapshots im Ziel mit einem AWS-Region-eigenen Schlüssel verschlüsseln möchten, müssen Sie im Ziel AWS-Region keine Grants konfigurieren. Weitere Informationen zum regionenübergreifenden Kopieren von Snapshots finden Sie unter Kopieren eines 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.
-
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.
-
-
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 einen AWS KMS-verschlüsselten 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.
Verschlüsselung 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
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.
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_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 von Schlüsseln finden Sie unter Rotieren der Verschlüsselungsschlüssel.
