Hinweise zur Verwaltung von Verschlüsselungsschlüsseln in Snowflake

Unter diesem Thema werden Konzepte im Zusammenhang mit von Snowflake verwalteten Schlüsseln und vom Kunden verwalteten Schlüsseln erläutert.

Unter diesem Thema:

Überblick

Snowflake verwaltet Verschlüsselungsschlüssel zum Schutz der Kundendaten. Diese Verwaltung kann automatisch erfolgen, ohne dass der Kunde eingreifen muss.

Kunden können auch den Schlüsselverwaltungsdienst in der Cloud-Plattform nutzen, die ihr Snowflake-Konto hostet, um ihren eigenen zusätzlichen Verschlüsselungsschlüssel zu verwalten.

Wenn diese Funktion aktiviert ist, wird durch die Kombination eines von Snowflake verwalteten Schlüssels mit einem vom Kunden verwalteten Schlüssel ein zusammengesetzter Hauptschlüssel zum Schutz von Kundendaten in Snowflake erstellt. Dies wird Tri-Secret Secure genannt.

Snowflake-verwaltete Schlüssel

Alle Snowflake-Kundendaten sind standardmäßig verschlüsselt. Snowflake verwendet eine starke AES-Verschlüsselung mit einem hierarchischen Schlüsselmodell, das in einem von einem Cloud-Anbieter gehosteten Hardware-Sicherheitsmodul verwurzelt ist.

Die Schlüssel werden vom Snowflake Service regelmäßig automatisch gewechselt, und die Kundendaten können regelmäßig automatisch wiederverschlüsselt („neu verschlüsselt“) werden. Die Kundendatenverschlüsselung und die Schlüsselverwaltung erfordern keine Konfiguration oder Verwaltung.

Hierarchisches Schlüsselmodell

Ein hierarchisches Schlüsselmodell bietet ein Framework für die Verwaltung der Verschlüsselungsschlüssel in Snowflake. Die Hierarchie besteht aus mehreren Ebenen von Schlüsseln, bei denen jede höhere Schlüsselebene (übergeordnete Schlüssel) die darunterliegende Ebene (untergeordnete Schlüssel) verschlüsselt. In der Sicherheitsterminologie wird ein übergeordneter Schlüssel, der alle untergeordneten Schlüssel verschlüsselt, als „Wrapping“ bezeichnet.

Das hierarchische Schlüsselmodell von Snowflake besteht aus vier Ebenen von Schlüsseln:

  • Stammschlüssel (Root Key)

  • Kontohauptschlüssel

  • Tabellenhauptschlüssel

  • Dateischlüssel

Jedes Kundenkonto hat eine eigene Schlüsselhierarchie mit Schlüsseln auf Konto-, Tabellen- und Dateiebene, wie in der folgenden Abbildung dargestellt:

Das hierarchische Schlüsselmodell von Snowflake

Bei einem mehrinstanzenfähigen Clouddienst wie Snowflake isoliert das hierarchische Schlüsselmodell jedes Konto mithilfe separater Kontohauptschlüssel. Neben dem Zugriffssteuerungsmodell, das den Kundendatenspeicher separiert, bietet das hierarchische Schlüsselmodell eine weitere Ebene der Kontenisolierung.

Ein hierarchisches Schlüsselmodell reduziert den Geltungsbereich jeder Schlüsselebene. Beispielsweise verschlüsselt ein Tabellenhauptschlüssel eine einzelne Tabelle. Ein Dateischlüssel verschlüsselt eine einzelne Datei. Ein hierarchisches Schlüsselmodell schränkt die Menge der Kundendaten ein, die jeder Schlüssel schützt, und die Zeitdauer, für die er verwendet werden kann.

Rotation des Verschlüsselungsschlüssels

Schlüssel in der von Snowflake verwalteten Schlüsselhierarchie werden von Snowflake automatisch rotiert, wenn sie mehr als 30 Tage alt sind. Aktive Schlüssel werden zurückgezogen und neue Schlüssel erstellt. Wenn Snowflake feststellt, dass der zurückgezogene Schlüssel nicht mehr benötigt wird, wird der Schlüssel automatisch zerstört. Wenn er aktiv ist, wird ein Schlüssel zur Verschlüsselung von Kundendaten verwendet und steht dem Kunden zur Verfügung. Im Ruhestand wird der Schlüssel ausschließlich zur Entschlüsselung von Kundendaten verwendet und steht nur für den Zugriff auf die Daten zur Verfügung.

Wenn Sie untergeordnete Schlüssel in der Schlüsselhierarchie einschließen oder wenn Sie Kundendaten in eine Tabelle einfügen, wird nur der aktuelle, aktive Schlüssel zur Verschlüsselung der Daten verwendet. Wenn ein Schlüssel zerstört wurde, wird er weder zur Ver- noch zur Entschlüsselung verwendet. Durch eine regelmäßige Schlüsselrotation wird der Lebenszyklus der Schlüssel auf einen definierten Zeitraum begrenzt.

Die folgende Abbildung zeigt die Schlüsselrotation für einen Tabellenhauptschlüssel (TMK) über einen Zeitraum von drei Monaten:

Schlüsselrotation eines Tabellenhauptschlüssels (TMK) über eine Zeitspanne von drei Monaten.

Die TMK-Rotation funktioniert folgendermaßen:

  • Version 1 des TMK ist im April aktiv. Die im April in diese Tabelle eingegebenen Kundendaten sind mit TMK v1 geschützt.

  • Im Mai erfolgt die Rotation dieses TMK: TMK v1 wird zurückgezogen, und ein neuer, völlig zufälliger Schlüssel, TMK v2, wird erstellt. TMK v1 wird ab April nur noch zur Entschlüsselung von Kundendaten verwendet. Neue Kundendaten, die in die Tabelle eingefügt werden, werden mit TMK v2 verschlüsselt.

  • Im Juni erfolgt die nächste Rotation dieses TMK: TMK v2 wird zurückgezogen, und ein neuer Schlüssel, TMK v3, wird erstellt. TMK v1 wird zur Entschlüsselung von Kundendaten aus dem April verwendet, TMK v2 wird zur Entschlüsselung von Kundendaten aus dem Mai verwendet und TMK v3 wird zur Ver- und Entschlüsselung neuer Kundendaten verwendet, die im Juni in die Tabelle eingefügt werden.

Wie bereits erwähnt, begrenzt die Schlüsselrotation die Zeitspanne, in der ein Schlüssel aktiv zur Verschlüsselung von Kundendaten verwendet wird. In Verbindung mit dem hierarchischen Schlüsselmodell schränkt die Schlüsselrotation die Menge der Kundendaten, die eine Schlüsselversion schützt, weiter ein. Die Begrenzung der Lebensdauer eines Schlüssels ist eine Empfehlung des National Institute of Standards and Technology (NIST) zur Erhöhung der Sicherheit.

Periodische Wiederverschlüsselung

In diesem Abschnitt wird der Lebenszyklus von Konto- und Tabellenhauptschlüsseln erläutert. Schlüsselrotation beschreibt die Schlüsselrotation, bei der aktive Schlüssel in regelmäßigen Abständen durch neue Schlüssel ersetzt und die alten Schlüssel außer Dienst gestellt werden. Durch die periodische Wiederverschlüsselung von Daten wird der Lebenszyklus abgeschlossen.

Während die Schlüsselrotation sicherstellt, dass ein Schlüssel aus dem aktiven Status in den deaktivierten Status überführt wird, sorgt die Wiederverschlüsselung dafür, dass ein Schlüssel vom deaktivierten Status in den zerstörten Status überführt wird.

Wenn die regelmäßige Wiederverschlüsselung aktiviert ist, erstellt Snowflake automatisch einen neuen Verschlüsselungsschlüssel und verschlüsselt alle Kundendaten, die zuvor durch den abgelaufenen Schlüssel geschützt waren, durch den neuen Schlüssel. Mit dem neuen Schlüssel werden die Tabellendaten in Zukunft entschlüsselt.

Bemerkung

Für Enterprise Edition-Konten können Benutzer mit der ACCOUNTADMIN-Rolle (d. h. Ihre Kontoadministratoren) die Wiederverschlüsselung mit ALTER ACCOUNT und dem Parameter PERIODIC_DATA_REKEYING aktivieren:

ALTER ACCOUNT SET ENABLE_TRI_SECRET_AND_REKEY_OPT_OUT_FOR_IMAGE_REPOSITORY=True;

ALTER ACCOUNT SET PERIODIC_DATA_REKEYING = true;
Copy

Dies ermöglicht Tri-Secret Secure, bietet aber keine zusätzliche Sicherheit für die in Ihrem Snowpark Image Repository gespeicherten Bilder.

Die folgende Abbildung zeigt die periodische Wiederverschlüsselung für eine TMK für eine einzelne Tabelle:

Wiederverschlüsselung eines Tabellenhauptschlüssels (TMK) nach einem Jahr

Die periodische Wiederverschlüsselung funktioniert wie folgt:

  • Im April des folgenden Jahres, nachdem TMK v1 für ein ganzes Jahr zurückgezogen war, wird er mit einem völlig neuen Zufallsschlüssel neu kodiert (Generation 2).

    Die mit TMK v1 Generation 1 geschützten Datendateien werden mit TMK v1 Generation 2 entschlüsselt und neu verschlüsselt. TMK v1, Generation 1 wird nun nicht mehr benötigt und daher zerstört.

  • Im Mai führt Snowflake den gleichen Wiederverschlüsselungsprozess auf den Tabellendaten durch, die durch TMK v2 geschützten werden.

  • Und so weiter.

In diesem Beispiel ist der Lebenszyklus eines Schlüssels auf eine Gesamtdauer von einem Jahr begrenzt.

Die Wiederverschlüsselung schränkt die Gesamtdauer ein, in der ein Schlüssel für die Verwendung durch den Empfänger verfügbar ist, was den NIST-Empfehlungen entspricht. Darüber hinaus kann Snowflake bei der Wiederverschlüsselung von Kundendaten die Größe der Verschlüsselungsschlüssel erhöhen und bessere Verschlüsselungsalgorithmen verwenden, die möglicherweise seit der Erstellung der vorherigen Schlüsselgeneration standardisiert wurden.

Snowflake verschlüsselt die Datendateien der Kunden online im Hintergrund, ohne dass dies Auswirkungen auf die laufenden Kunden-Workloads hat. Kundendaten, die wiederverschlüsselt werden, stehen Ihnen jederzeit zur Verfügung. Für die Wiederverschlüsselung der Daten ist keine Ausfallzeit des Dienstes erforderlich, und Sie haben keine Auswirkungen auf die Leistung Ihrer Workload. Dieser Vorteil ist ein direktes Ergebnis der Snowflake-Architektur, die eine Trennung von Speicher- und Computeressourcen vorsieht.

Bemerkung

Sie können keine Hybridtabellen verwenden, wenn Ihr Snowflake-Konto für die Verwendung der periodischen Wiederverschlüsselung aktiviert ist. Wenn die periodische Wiederverschlüsselung in Ihrem Konto aktiviert ist und Sie Hybridtabellen verwenden möchten, müssen Sie einen ALTER ACCOUNT-Befehl verwenden, um den Parameter PERIODIC_DATA_REKEYING auf FALSE zu setzen.

Auswirkungen der Wiederverschlüsselung auf Time Travel und Fail-safe

Die Aufbewahrungsfristen für Time Travel und Fail-safe werden durch die Wiederverschlüsselung nicht beeinflusst. Für die Wiederverschlüsselung von Kundendaten in Fail-safe fallen jedoch zusätzliche Speichergebühren an (siehe nächster Abschnitt).

Auswirkungen der Wiederverschlüsselung auf die Speichernutzung

Für Snowflake-Kunden wird zusätzlicher Speicherplatz für den Fail-safe-Schutz der wiederverschlüsselten Kundendateien berechnet. Für diese Dateien wird 7 Tage Fail-safe-Schutz in Rechnung gestellt.

Das heißt, dass zum Beispiel die Datendateien der Kunden mit dem alten Schlüssel auf Amazon S3 bereits durch Fail-safe geschützt sind und die Datendateien der Kunden mit dem neuen Schlüssel auf Amazon S3 ebenfalls zu Fail-safe hinzugefügt werden, was zu einer zweiten Gebühr führt, allerdings nur für den Zeitraum von 7 Tagen.

Hardware-Sicherheitsmodul

Snowflake stützt sich auf in der Cloud gehostete Hardware-Sicherheitsmodule (HSMs), um die Sicherheit der Schlüsselspeicherung und -nutzung zu gewährleisten. Jede Cloud-Plattform verfügt über unterschiedliche HSM-Dienste, was sich darauf auswirkt, wie Snowflake den HSM-Dienst auf jeder Plattform nutzt:

  • Auf AWS und Azure verwendet Snowflake das HSM, um den Stammschlüssel zu erstellen und zu speichern.

  • Auf Google Cloud wird der HSM-Dienst über die Google Cloud KMS-API (Schlüsselverwaltungsdienst) zur Verfügung gestellt. Snowflake verwendet Google Cloud KMS zum Erstellen und Speichern des Stammschlüssels in mehrinstanzenfähigen HSM-Partitionen.

Für alle Cloudplattformen und alle Schlüssel in der Schlüsselhierarchie wird ein im HSM gespeicherter Schlüssel verwendet, um einen Schlüssel in der Hierarchie zu entpacken. Um beispielsweise den Tabellenhauptschlüssel zu entschlüsseln, wird mit dem im HSM befindlichen Schlüssel der Kontohauptschlüssel entpackt. Dieser Prozess wird im HSM ausgeführt. Nachdem dieser Prozess abgeschlossen ist, wird mit einer Softwareoperation der Tabellenhauptschlüssel mithilfe des Kontohauptschlüssels entschlüsselt.

Die folgende Abbildung zeigt die Beziehung zwischen HSM, den Konto-Stammschlüsseln, den Tabellenhauptschlüsseln und den Dateischlüsseln:

Auf Hardware-Sicherheitsmodul basierende Schlüsselhierarchie

Kundenverwaltete Schlüssel

Ein vom Kunden verwalteter Schlüssel (CMK) ist ein Hauptverschlüsselungsschlüssel, den der Kunde im Schlüsselverwaltungsdienst des Cloud-Anbieters verwaltet, der das Snowflake-Konto des Kunden hostet. Die wichtigsten Schlüsselverwaltungsdienste für jede Plattform sind:

Der CMK kann dann mit einem von Snowflake verwalteten Schlüssel kombiniert werden, um einen zusammengesetzten Hauptschlüssel zu erstellen. Wenn dies der Fall ist, bezeichnet Snowflake dies als Tri-Secret Secure.

Sie können diese Systemfunktionen in Ihrem Snowflake-Konto aufrufen, um Informationen zu Ihren Schlüsseln zu erhalten:

Wichtig

Snowflake unterstützt keine Schlüsselrotation für vom Kunden verwaltete Schlüssel und empfiehlt auch nicht, eine automatische Schlüsselrotationsrichtlinie für vom Kunden verwaltete Schlüssel zu implementieren.

Der Grund für diese Empfehlung ist, dass die Schlüsselrotation zu einem Verlust von Kundendaten führen kann, wenn der rotierte Schlüssel gelöscht wird, da Snowflake die Daten nicht entschlüsseln kann. Weitere Informationen finden Sie unter Tri-Secret Secure.

Snowflake unterstützt Folgendes:

Vorteile von kundenverwalteten Schlüsseln

Zu den Vorteilen von kundenverwalteten Schlüsseln gehören:

Kontrolle über den Zugriff auf Kundendaten:

Sie haben die vollständige Kontrolle über Ihren Hauptschlüssel im Schlüsselverwaltungsdienst und damit auch über Ihre Kundendaten in Snowflake. Sie müssen diesen Schlüssel freigeben, um die in Ihrem Snowflake-Konto gespeicherten Daten zu entschlüsseln.

Sperren des Zugangs aufgrund einer Verletzung der Kundendaten:

Wenn Sie einen Sicherheitsverstoß feststellen, können Sie den Zugriff auf Ihren Schlüssel deaktivieren und alle in Ihrem Snowflake-Konto ausgeführten Datenoperationen unterbrechen.

Eigentümerschaft des Lebenszyklus der Kundendaten:

Mithilfe von kundenverwalteten Schlüsseln können Sie Ihre Datenschutzanforderungen an Ihre Geschäftsprozesse anpassen. Die explizite Kontrolle über Ihren Schlüssel bietet Schutzmaßnahmen für den gesamten Lebenszyklus der Kundendaten, von der Erstellung bis zur Löschung.

Wichtige Anforderungen an kundenverwaltete Schlüssel

Kundenverwaltete Schlüssel bieten erhebliche Sicherheitsvorteile, stellen aber auch sehr wichtige grundlegende Anforderungen, die Sie durchgehend beachten müssen, um Ihren Hauptschlüssel zu schützen:

Vertraulichkeit:

Sie müssen dafür sorgen, dass Ihr Schlüssel jederzeit sicher aufbewahrt und geheim gehalten wird.

Integrität:

Sie müssen sicherstellen, dass Ihr Schlüssel vor unsachgemäßer Änderung oder Löschung geschützt ist.

Verfügbarkeit:

Damit Abfragen ausgeführt und der Zugriff auf Ihre Daten gewährt ist, müssen Sie sicherstellen, dass Ihr Schlüssel Snowflake ständig zur Verfügung steht.

Ein ungültiger oder nicht verfügbarer Schlüssel führt zu einer Unterbrechung Ihrer Snowflake-Datenoperationen, die erst fortgesetzt werden können, wenn Snowflake wieder ein gültiger Schlüssel zur Verfügung steht.

Snowflake wurde entwickelt, um vorübergehende Verfügbarkeitsprobleme (bis zu 10 Minuten) zu bewältigen, die durch häufige Probleme, wie z. B. Ausfälle der Netzwerkkommunikation, verursacht werden. Wenn der Schlüssel nach 10 Minuten immer noch nicht verfügbar ist, werden alle Datenoperationen in Ihrem Snowflake-Konto vollständig eingestellt. Sobald der Zugriff auf den Schlüssel wiederhergestellt ist, können Datenoperationen erneut gestartet werden.

Die Nichteinhaltung dieser Anforderungen kann die Integrität Ihrer Daten erheblich gefährden, angefangen von Daten, die vorübergehend unzugänglich sind, bis hin zu Daten, die dauerhaft deaktiviert sind. Darüber hinaus kann Snowflake nicht verantwortlich gemacht werden für Probleme, die von Drittanbietern verursacht werden, oder für administrative Pannen, die von Ihrem Unternehmen bei der Wartung des Schlüssels verursacht werden.

Wenn beispielsweise ein Problem mit dem Key Management Service dazu führt, dass Ihr Schlüssel nicht verfügbar ist, hat dies Auswirkungen auf Ihre Datenoperationen. Diese Probleme müssen von Ihnen und dem Support-Team für den Key Management Service gelöst werden. Auch bei einer Manipulation oder Zerstörung Ihres Schlüssels sind alle in Ihrem Snowflake-Konto vorhandenen Daten erst wieder lesbar, wenn der Schlüssel wiederhergestellt ist.

Sprache: Deutsch