Datenverschlüsselung¶
Der Schutz der Kundendaten hat für Snowflake oberste Priorität. Snowflake verschlüsselt standardmäßig alle Kundendaten unter Verwendung der neuesten Sicherheitsstandards ohne zusätzliche Kosten. Snowflake bietet eine erstklassige Schlüsselverwaltung, die für die Kunden vollständig transparent ist. Dies macht Snowflake zu einer der am einfachsten zu bedienenden und sichersten Datenplattformen, die derzeit verfügbar sind.
Unter diesem Thema:
End-to-End-Verschlüsselung¶
Die End-to-End-Verschlüsselung (E2EE) ist eine Form der Kommunikation, bei der die Daten ausschließlich von den Endbenutzern gelesen werden können. In Snowflake bedeutet dies, dass die Daten nur von einem Kunden und von den Laufzeitkomponenten gelesen werden können. Dritten, einschließlich der Cloud-Computing-Plattform von Snowflake und dem ISP, ist es nicht möglich, die Daten unverschlüsselt sehen.
E2EE minimiert die Angriffsfläche. Im Falle einer Sicherheitsverletzung der Cloudplattform sind die Daten geschützt, da sie immer verschlüsselt sind, unabhängig davon, ob durch die Sicherheitsverletzung Anmeldeinformationen indirekt oder Datendateien direkt offengelegt wurden, und ob es sich um einen internen oder einen externen Angreifer handelt.
In der Abbildung ist das E2EE-System von Snowflake dargestellt. Das System beinhaltet die folgenden Komponenten:
Snowflake-Kunde in einem Firmennetzwerk
Stagingbereich der Datendateien
Snowflake, das in einer sicheren virtuellen privaten Cloud (VPC) ausgeführt wird
Snowflake unterstützt sowohl interne als auch externe Stagingbereiche für Datendateien. Snowflake bietet interne Stagingbereiche, in die Sie Ihre Datendateien hochladen und gruppieren können, bevor Sie die Daten in Tabellen laden (Option B). Vom Kunden bereitgestellte Stagingbereiche sind Container oder Verzeichnisse einer unterstützten Cloudspeicherplattform (d. h. Amazon S3), die Sie besitzen und verwalten (Option A). Für Kunden, die auf diesen Plattformen bereits Daten gespeichert haben, die sie in Snowflake kopieren möchten, sind vom Kunden bereitgestellte Stagingbereiche eine attraktive Option. Snowflake unterstützt E2EE für beide Staging-Typen.
Snowflake wird in einer zentralen, sicheren VPC der Cloudplattform ausgeführt.
Der Workflow von E2EE in Snowflake ist wie folgt (siehe Abbildung in diesem Abschnitt):
Ein Benutzer lädt eine oder mehrere Datendateien in einen Stagingbereich hoch. Wenn es sich bei dem Stagingbereich um einen vom Kunden verwalteten Container eines Cloudspeicherservices (Option A) handelt, kann der Benutzer die Datendateien optional mit einer clientseitigen Verschlüsselungsmethode verschlüsseln (weitere Informationen dazu unter Clientseitige Verschlüsselung). Wir empfehlen die clientseitige Verschlüsselung von Dateien, die in einem Stagingbereich außerhalb von Snowflake bereitgestellt werden. Wenn die Daten jedoch nicht verschlüsselt sind, verschlüsselt Snowflake die Daten sofort beim Laden in eine Tabelle.
Wenn es sich um einen internen (d. h. Snowflake) Stagingbereich (Option B) handelt, werden die Dateien vom Client auf dem lokalen Computer automatisch verschlüsselt, bevor sie in den internen Stagingbereich übertragen werden.
Der Benutzer lädt die Daten aus dem Stagingbereich in eine Tabelle. Die Daten werden in das proprietäre Dateiformat von Snowflake umgewandelt und in einem Cloudspeichercontainer („ruhende Daten“) gespeichert. In Snowflake sind alle ruhenden Daten immer verschlüsselt.
Abfrageergebnisse können in einen Stagingbereich entladen werden. Die Ergebnisse werden optional mit clientseitiger Verschlüsselung verschlüsselt, wenn sie in eine vom Kunden verwalteten Stagingbereich entladen werden, und sie werden automatisch verschlüsselt, wenn sie in einen von Snowflake bereitgestellten Stagingbereich entladen werden.
Der Benutzer lädt Datendateien aus dem Stagingbereich herunter und entschlüsselt die Daten auf der Clientseite.
Bei all diesen Schritten werden alle Datendateien verschlüsselt. Nur der Benutzer und die Snowflake-Laufzeitkomponenten können die Daten lesen. Die Laufzeitkomponenten entschlüsseln die Daten im Speicher zur Abfrageverarbeitung. Kein Drittanbieterservice kann Daten unverschlüsselt sehen.
Clientseitige Verschlüsselung¶
Die clientseitige Verschlüsselung bietet ein sicheres System zur Verwaltung von Daten im Cloudspeicher. Clientseitige Verschlüsselung bedeutet, dass ein Benutzer gespeicherte Daten verschlüsselt, bevor er sie in Snowflake lädt. Der Cloudspeicherservice speichert nur die verschlüsselte Version der Daten und fügt Daten niemals unverschlüsselt hinzu.
Die clientseitige Verschlüsselung erfolgt nach einem bestimmten Protokoll, das vom Cloudspeicherservice definiert wird. Dieses Protokoll wird mit Service-SDK und Tools von Drittanbietern implementiert. Das clientseitige Verschlüsselungsprotokoll funktioniert wie folgt (siehe Abbildung in diesem Abschnitt):
Der Snowflake-Kunde erstellt einen geheimen Hauptschlüssel, der beim Kunden verbleibt.
Der Client (bereitgestellt vom Cloudspeicherservice) generiert einen zufälligen Verschlüsselungsschlüssel und verschlüsselt die Datei, bevor er sie in den Cloudspeicher hochlädt. Der zufällige Schlüssel wiederum wird mit dem Hauptschlüssel des Kunden verschlüsselt.
Sowohl die verschlüsselte Datei als auch der verschlüsselte Zufallsschlüssel werden in den Cloudspeicherservice hochgeladen. Der verschlüsselte Zufallsschlüssel wird zusammen mit den Metadaten der Datei gespeichert.
Beim Herunterladen von Daten lädt der Client sowohl die verschlüsselte Datei als auch den verschlüsselten Zufallsschlüssel herunter. Der Client entschlüsselt den verschlüsselten Zufallsschlüssel mit dem Hauptschlüssel des Kunden. Als Nächstes entschlüsselt der Client die verschlüsselte Datei mit dem nun entschlüsselten Zufallsschlüssel. Alle Ver- und Entschlüsselungen erfolgen auf der Clientseite. Zu keinem Zeitpunkt sieht der Cloudspeicherservice oder ein anderer Dritter (z. B. ein ISP) die Daten unverschlüsselt. Kunden können clientseitig verschlüsselte Daten mit jedem Client oder Tool hochladen, das die clientseitige Verschlüsselung unterstützt.
Einbinden von clientseitig verschlüsselten Daten in Snowflake¶
Snowflake unterstützt das clientseitige Verschlüsselungsprotokoll mit clientseitigem Hauptschlüssel beim Lesen oder Schreiben von Daten zwischen dem Stagingbereich eines Cloudspeicherservices und Snowflake.
Um clientseitig verschlüsselte Daten aus einem vom Kunden bereitgestellten Stagingbereich zu laden, erstellen Sie mit CREATE STAGE ein benanntes Stagingobjekt mit einem zusätzlichen MASTER_KEY-Parameter und laden dann Daten aus dem Stagingbereich in Ihre Snowflake-Tabellen. Der Parameter MASTER_KEY erfordert einen 256-Bit Advanced Encryption Standard (AES)-Schlüssel, der in Base64 kodiert ist.
Ein benanntes Stagingobjekt speichert Einstellungen zu einem Stagingbereich und bietet eine komfortable Möglichkeit, Daten zwischen Snowflake und einem spezifizierten Container im Cloudspeicher zu laden oder zu entladen. Im folgenden SQL-Ausschnitt wird in Snowflake ein beispielhaftes Amazon S3-Stagingobjekt erstellt, das die clientseitige Verschlüsselung unterstützt:
-- create encrypted stage
create stage encrypted_customer_stage
url='s3://customer-bucket/data/'
credentials=(AWS_KEY_ID='ABCDEFGH' AWS_SECRET_KEY='12345678')
encryption=(MASTER_KEY='eSxX0jzYfIamtnBKOEOxq80Au6NbSgPH5r4BDDwOaO8=');
Der in diesem SQL-Befehl angegebene Hauptschlüssel ist die Base64-kodierte Zeichenfolge des geheimen Hauptschlüssels des Kunden. Wie alle anderen Zugangsdaten wird auch dieser Hauptschlüssel über Transport Layer Security (HTTPS) an Snowflake übertragen und verschlüsselt im Metadatenspeicher gespeichert. Nur die kundeneignen und die abfrageverarbeitenden Komponenten von Snowflake kommen mit dem Hauptschlüssel in Berührung und sind dadurch in Lage, die im Stagingbereich gespeicherten Daten zu entschlüsseln.
Ein Vorteil von benannten Stagingobjekten besteht darin, dass sie anderen Benutzern innerhalb eines Snowflake-Kontos zugewiesen werden können, ohne dass diesen Benutzern Anmeldeinformationen oder clientseitige Verschlüsselungsschlüssel mitgeteilt werden. Benutzer mit den entsprechenden Zugriffssteuerungsrechten verweisen beim Laden oder Entladen von Daten einfach auf das benannte Stagingobjekt.
Die folgenden SQL-Befehle erstellen eine Tabelle mit dem Namen USERS und kopieren Daten aus dem verschlüsselten Stagingbereich in die USERS-Tabelle:
-- create table and ingest data from stage
CREATE TABLE users (id bigint, name varchar(500), purchases int);
COPY INTO users FROM @encrypted_customer_stage/users;
Die Daten sind nun bereit für die Analyse mit Snowflake.
Sie können auch Daten in den Stagingbereich entladen. Der folgende SQL-Befehl erstellt eine MOST_PURCHASES-Tabelle und füllt diese mit den Ergebnissen einer Abfrage, die die Top-10-Benutzer mit den meisten Käufen ermittelt, und entlädt die Tabellendaten dann in den Stagingbereich:
-- find top 10 users by purchases, unload into stage
CREATE TABLE most_purchases as select * FROM users ORDER BY purchases desc LIMIT 10;
COPY INTO @encrypted_customer_stage/most_purchases FROM most_purchases;
Snowflake verschlüsselt die in den Stagingbereich des Kunden kopierten Datendateien mit dem im Stagingobjekt gespeicherten Hauptschlüssel. Snowflake hält sich an das clientseitige Verschlüsselungsprotokoll für den Cloudspeicherservice. Ein Kunde kann die verschlüsselten Datendateien mit jedem Client oder Tool herunterladen, der/das die clientseitige Verschlüsselung unterstützt.
Verwaltung der Verschlüsselungsschlü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.
Weitere Informationen zur Snowflake-Verschlüsselung finden Sie in unserem Sicherheits-Whitepaper.
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.
Bei einem mandantenfä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 Umfang 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¶
Konto- und Tabellenhauptschlüssel werden von Snowflake 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 Ersteller zur Verfügung. Ein zurückgezogener 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):
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¶
Für die periodische Wiederverschlüsselung ist die Enterprise Edition erforderlich. Wenden Sie sich für ein Upgrade direkt an den Snowflake Support.
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 zurückgezogen werden. Durch die periodische Wiederverschlüsselung von Daten wird der Lebenszyklus abgeschlossen. Wenn die periodische Wiederverschlüsselung aktiviert und der zurückgezogene 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 zurückgezogenen 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;
Während die Schlüsselrotation sicherstellt, dass ein Schlüssel aus dem aktiven Status (Ersteller-Nutzung) in den zurückgezogenen Status (Empfänger-Nutzung) überführt wird, sorgt die Wiederverschlüsselung dafür, dass ein Schlüssel vom zurückgezogenen Status in den zerstörten Status überführt wird.
In der folgenden Abbildung wird der Tabellenhauptschlüssel (TMK) für eine einzelne Tabelle monatlich rotiert. Die Abbildung zeigt die wichtigsten Rotationen im April, Mai und Juni (TMK v1, v2 und v3):
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.
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 Funktionen 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, die Datendateien mit dem alten Schlüssel auf S3 sind bereits durch Fail-safe geschützt, und die Datendateien mit dem neuen Schlüssel auf 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 vertraut auf einem von mehreren cloudbasierten Services für Hardware-Sicherheitsmodule (HSM) als manipulationsgeschützte, hochsichere Methode zum Generieren, Speichern und Verwenden von Stammschlüsseln der Schlüsselhierarchie. Die Verwendung eines HSM bietet die folgenden Sicherheitsvorteile:
Die obersten Schlüssel der Schlüsselhierarchie verlassen nie das HSM. Alle kryptographischen Operationen werden innerhalb der Sicherheitsmodule selbst ausgeführt.
Umschlossene, untergeordnete Schlüssel in der Schlüsselhierarchie können nicht ohne autorisierten Zugriff auf die HSM-Geräte entpackt werden.
Zusätzlich zur Generierung neuer Verschlüsselungsschlüssel beim Erstellen neuer Konten und Tabellen generiert das HSM während der Schlüsselrotation und der Wiederverschlüsselung sichere, zufällige Verschlüsselungsschlüssel.
Beachten Sie, dass dieses Verhalten für AWS und Microsoft Azure zutrifft, aber nicht für Google Cloud Platform.
Snowflake verwendet Backups für die Hochverfügbarkeitskonfiguration des HSM, um die Möglichkeit von Serviceausfällen zu reduzieren und den Verlust der wichtigsten Schlüssel in der Hierarchie zu verhindern.
Tri-Secret Secure und kundenverwaltete Schlüssel¶
Erfordert Business Critical Edition (oder höher). Wenden Sie sich für ein Upgrade direkt an den Snowflake-Support.
Mit Tri-Secret Secure können Sie den Zugriff auf Ihre Daten mit einem Hauptverschlüsselungsschlüssel steuern, den Sie mit dem Key Management Service für den Cloudanbieter pflegen, der Ihr Snowflake-Konto hostet:
Google Cloud: Cloud Key Management Service (Cloud KMS)
Microsoft Azure: Azure Key Vault
Da Tri-Secret Secure für Ihr Konto aktiviert ist, kombiniert Snowflake Ihren Schlüssel mit einem von Snowflake gepflegten Schlüssel, um einen zusammengesetzten Hauptschlüssel zu erstellen. Dieser zusammengesetzte Hauptschlüssel wird dann verwendet, um alle Daten in Ihrem Konto zu verschlüsseln. Wenn einer der Schlüssel im zusammengesetzten Hauptschlüssel widerrufen wird, können Ihre Daten nicht entschlüsselt werden, was eine eigene Ebene der Sicherheit und Kontrolle über 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.
Weitere Informationen zur Implementierung von kundenverwalteten Schlüsseln finden Sie in diesem Blogeintrag (der zwar auf AWS verweist, aber die allgemeinen Prinzipien gelten unabhängig vom Clouddienst).
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.
Möglichkeit zur Deaktivierung des Zugriffs im Falle einer Datenpanne: Wenn Sie einen Sicherheitsverstoß feststellen, können Sie den Zugriff auf Ihren Schlüssel deaktivieren und alle Datenoperationen in Ihrem Snowflake-Konto 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.
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. 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.
Aktivieren von Tri-Secret Secure¶
Wenden Sie sich an den Snowflake-Support, wenn Snowflake Tri-Secret Secure für Ihr Business Critical-Konto aktiviert werden soll.