Hinweise zur Verwaltung von Verschlüsselungsschlüsseln in Snowflake

Unter diesem Thema werden Konzepte im Zusammenhang mit von Snowflake verwalteten Schlüsseln, von Kunden verwalteten Schlüsseln und mit Tri-Secret Secure erläutert.

Unter diesem Thema:

Übersicht

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

Kunden können den Schlüsselverwaltungsdienst der Cloudplattform 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 der Snowflake-Daten erstellt. Dies wird als Tri-Secret Secure bezeichnet.

Snowflake-verwaltete Schlüssel

Alle Kundendaten von Snowflake werden standardmäßig mit den neuesten Sicherheitsstandards und Best Practices verschlüsselt. Snowflake verwendet eine starke AES-256-Bit-Verschlüsselung mit einem hierarchischen Schlüsselmodell, das auf einem Hardware-Sicherheitsmodell basiert.

Schlüssel werden vom Snowflake-Service automatisch und regelmäßig rotiert, und Daten können automatisch wiederverschlüsselt („rekeyed“) werden. Datenverschlüsselung und Schlüsselverwaltung sind völlig transparent und 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 begrenzt die Datenmenge, die von jedem Schlüssel geschützt wird, und die Dauer, für die ein Schlüssel verwendbar ist.

Rotation des Verschlüsselungsschlüssels

Alle von Snowflake verwalteten Schlüssel werden automatisch rotiert, wenn sie älter als 30 Tage 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. Ein aktiver Schlüssel wird zur Verschlüsselung von Daten verwendet und steht dem Kunden zur Nutzung zur Verfügung. Ein veralteter Schlüssel dient ausschließlich dem Entschlüsseln von Daten und steht nur dem Empfänger zur Verfügung.

Beim „Wrapping“ (Umschließen) von untergeordneten Schlüsseln in der Schlüsselhierarchie oder beim Einfügen von Daten in eine Tabelle wird nur der aktuelle, aktive Schlüssel zur Verschlüsselung von 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 Daten werden 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 nun nur noch zum Entschlüsseln von Daten aus dem April verwendet. Neue Daten, 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 verwendet, um Daten von April zu entschlüsseln, TMK v2 wird verwendet, um Daten von Mai zu entschlüsseln, und TMK v3 wird verwendet, um neue Daten zu verschlüsseln und zu entschlüsseln, die im Juni in die Tabelle eingefügt wurden.

Wie bereits erwähnt, begrenzt die Schlüsselrotation die Dauer, in der ein Schlüssel aktiv zur Verschlüsselung von Daten verwendet wird. In Verbindung mit dem hierarchischen Schlüsselmodell schränkt die Schlüsselrotation die Datenmenge, die von einer Schlüsselversion geschützt wird, 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 werden die Erläuterungen zum Lebenszyklus des Konto- und Tabellenhauptschlüssels fortgesetzt. Unter Rotation des Verschlüsselungsschlüssels wurde die Schlüsselrotation beschrieben, bei der aktive Schlüssel periodisch durch neue Schlüssel ersetzt und alte Schlüssel deaktiviert 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 periodische Wiederverschlüsselung aktiviert und der deaktivierte Verschlüsselungsschlüssel einer Tabelle älter als ein Jahr ist, erstellt Snowflake automatisch einen neuen Verschlüsselungsschlüssel. Mit diesem neuen Schlüssel werden dann alle Daten verschlüsselt, die zuvor durch den deaktivierten Schlüssel geschützt waren. Mit dem neuen Schlüssel werden die Tabellendaten in Zukunft entschlüsselt.

Bemerkung

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

ALTER ACCOUNT SET PERIODIC_DATA_REKEYING = true;
Copy

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 durch TMK v1, Generation 1 geschützten Datendateien werden entschlüsselt und mit TMK v1, Generation 2 wieder 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 Daten 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.

Wiederverschlüsselung stellt somit sicher, dass alle Kundendaten, ob neu oder alt, mit modernster Sicherheitstechnologie verschlüsselt werden.

Snowflake nimmt die Wiederverschlüsselung der Datendateien online und im Hintergrund vor, ohne dass dies Auswirkungen auf die aktuell ausgeführten Kunden-Workloads hat. Daten, die wiederverschlüsselt werden, stehen Ihnen jederzeit zur Verfügung. Die Wiederverschlüsselung der Daten erfordert keine Ausfallzeit des Services und hat keine Auswirkungen auf die Leistung Ihrer Workloads. 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. Die Wiederverschlüsselung ist für beide Features transparent. Allerdings sind mit der Wiederverschlüsselung von Daten für Fail-safe einige zusätzliche Speicherkosten verbunden (siehe nächster Abschnitt).

Auswirkungen der Wiederverschlüsselung auf die Speichernutzung

Dem Snowflake-Kunden entstehen Kosten für den zusätzlichen Speicher, der für den Fail-safe-Schutz von neu verschlüsselten Daten benötigt wird. Für diese Dateien wird 7 Tage Fail-safe in Rechnung gestellt.

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

Hardware-Sicherheitsmodul

Snowflake stützt sich auf Cloud-gehostete Hardware-Sicherheitsmodule (HSMs), um die Sicherheit der Schlüsselspeicherung und -nutzung zu gewährleisten. Jede Cloudplattform 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 dem HSM, den Kontohauptschlüsseln, den Tabellenhauptschlüsseln und den Dateischlüsseln:

Auf Hardware-Sicherheitsmodul basierende Schlüsselhierarchie

Kundenverwaltete Schlüssel

Ein vom Kunden verwalteter Schlüssel ist ein Hauptverschlüsselungsschlüssel, den der Kunde über den Schlüsselverwaltungsdienst des Cloudanbieters verwaltet, der Ihr Snowflake-Konto hostet. Die wichtigsten Schlüsselverwaltungsdienste für jede Plattform sind:

Der vom Kunden verwaltete Schlüssel 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 (unter diesem Thema).

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 Datenverlust führen kann, wenn der rotierte Schlüssel gelöscht wird, da Snowflake die Daten nicht entschlüsseln kann. Weitere Informationen dazu finden Sie unter Tri-Secret Secure (unter diesem Thema).

Vorteile von kundenverwalteten Schlüsseln

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

Kontrolle über den Datenzugriff:

Sie haben die volle Kontrolle über Ihren Hauptschlüssel im Key Management Service und damit über Ihre Daten in Snowflake. Es ist unmöglich, die in Ihrem Snowflake-Konto gespeicherten Daten zu entschlüsseln, ohne dass Sie diesen Schlüssel freigeben.

Sperren des Zugriffs bei Datenschutzverstößen:

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 am Datenlebenszyklus:

Mithilfe von kundenverwalteten Schlüsseln können Sie Ihre Datenschutzanforderungen an Ihre Geschäftsprozesse anpassen. Die explizite Kontrolle über Ihren Schlüssel bietet Schutz während des gesamten Datenlebenszyklus, 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 ist jedoch so konzipiert, dass es temporäre Verfügbarkeitsprobleme (bis zu 10 Minuten) bewältigt, die durch typische Probleme wie Netzwerkausfälle 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.

Tri-Secret Secure

Tri-Secret Secure ist die Kombination aus einem von Snowflake verwalteten Schlüssel und einem vom Kunden verwalteten Schlüssel über die Plattform des Cloudanbieters, der Ihr Snowflake-Konto hostet, um einen zusammengesetzten Hauptschlüssel zum Schutz Ihrer Snowflake-Daten bereitzustellen. Der zusammengesetzte Hauptschlüssel fungiert als Kontohauptschlüssel und umschließt alle Schlüssel in der Hierarchie. Der zusammengesetzte Hauptschlüssel verschlüsselt jedoch niemals Rohdaten.

Wenn der kundenverwaltete Schlüssel in der zusammengesetzten Hauptschlüsselhierarchie widerrufen wird, können Ihre Daten nicht mehr von Snowflake entschlüsselt werden, was eine höhere Sicherheits- und Kontrollebene als die Standardverschlüsselung von Snowflake bietet. Dieses Verschlüsselungsmodell mit dualen Schlüsseln ergibt zusammen mit der integrierten Benutzerauthentifizierung von Snowflake die drei Ebenen des Datenschutzes von Tri-Secret Secure.

Achtung

Bevor Sie sich mit Snowflake in Verbindung setzen, um Tri-Secret Secure für Ihr Konto zu aktivieren, sollten Sie sich Ihrer Verantwortung für den Schutz Ihres Schlüssels umfassend bewusst sein wie im Abschnitt Kundenverwaltete Schlüssel (unter diesem Thema) angemerkt. Wenn Sie Fragen oder Bedenken haben, stehen wir Ihnen gern zur Verfügung.

Beachten Sie, dass Snowflake die gleiche Verantwortung für die von uns gewarteten Schlüssel trägt. Wie bei allen sicherheitsrelevanten Aspekten unseres Services stellen wir uns mit größter Sorgfalt und Wachsamkeit dieser Verantwortung.

Alle unsere Schlüssel werden nach strengen Richtlinien verwaltet, die es uns ermöglicht haben, die höchsten Sicherheitsakkreditierungen zu erhalten, einschließlich SOC 2 Typ II, PCI-DSS, HIPAA und HITRUST CSF.

Feature-Kompatibilität

Die folgenden Features sind nicht mit Tri-Secret Secure kompatibel:

Aktivieren von Tri-Secret Secure

Wenden Sie sich an den Snowflake-Support, wenn Snowflake Tri-Secret Secure für Ihr Business Critical-Konto (oder höher) aktiviert werden soll.