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 die Verschlüsselung AWS Key Management Service (AWS KMS) verwendet. Dazu können Sie entweder einen AWS-verwalteten 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. 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 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.

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 Benutzererfahrung 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.

  Beachten Sie, dass Tabellen oder Materialized Views, die mit erstellt wurden, BACKUP NO nicht beibehalten werden, da während des Verschlüsselungsvorgangs ein Vorgang ausgeführt wird. backup-and-restore Weitere Informationen finden Sie unter CREATE TABLE oder CREATE MATERIALIZED VIEW.

Themen

• Datenbankverschlüsselung für Amazon Redshift mithilfe von AWS KMS
• Verschlüsselung für Amazon Redshift mit Hardwaresicherheitsmodulen
• Rotation von Verschlüsselungsschlüsseln in Amazon Redshift
• Ändern der Verschlüsselung von Clustern
• Konfigurieren der Datenbankverschlüsselung mit der Konsole
• Konfigurieren der Datenbankverschlüsselung mit der Amazon Redshift API und AWS CLI

Datenbankverschlüsselung für Amazon Redshift mithilfe von 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 Ihr AWS Konto erstellt hat oder zu deren Verwendung Ihr Konto berechtigt ist. AWS KMS 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 AWS verwalteter Schlüssel, der für Ihr AWS Konto zur Verwendung in Amazon Redshift erstellt wurde. AWS KMS erstellt diesen Schlüssel, wenn Sie zum ersten Mal einen verschlüsselten Cluster in einer AWS Region starten und den Standardschlüssel wählen.

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 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 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 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 Erstellen eines Clusters und Verwaltung von Clustern mithilfe der AWS CLI und der Amazon Redshift Redshift-API.

Kopieren von —verschlüsselten Snapshots in eine andere Region AWS KMSAWS

AWS KMS Schlüssel sind spezifisch für eine AWS Region. Wenn Sie das Kopieren von Amazon Redshift-Snapshots in eine andere AWS Region aktivieren und der Quell-Cluster und seine Snapshots mit einem Root-Schlüssel von verschlüsselt sind AWS KMS, müssen Sie eine Genehmigung für Amazon Redshift konfigurieren, um einen Root-Schlüssel in der Zielregion zu verwenden. AWS Dieser Zuschuss ermöglicht es Amazon Redshift, Snapshots in der Zielregion zu verschlüsseln. AWS 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 und deren Verwendung AWS KMS für Ihren Root-Schlü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 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.

2. 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 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 Sie die regionsübergreifende Snapshot-Kopie für einen AWS KMS—verschlüsselten Cluster.

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

Weitere Informationen zur Konfiguration von Snapshot-Kopierberechtigungen 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 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- 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 AWS CloudHSM Classic für die Schlüsselverwaltung. 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 den verfügbaren AWS Regionen finden Sie AWS in der Regionentabelle.

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_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.