Verwenden von sicheren Objekten zur Steuerung des Datenzugriffs¶
Um sicherzustellen, dass sensible Daten in einer freigegebenen Datenbank den Benutzern in Verbraucherkonten nicht zugänglich sind, empfiehlt Snowflake nachdrücklich die Freigabe von sicheren Ansichten und/oder sicheren UDFs anstelle der direkten Freigabe von Tabellen.
Für eine optimale Performance, insbesondere bei der gemeinsamen Nutzung von Daten in extrem großen Tabellen, empfehlen wir außerdem die Definition von Gruppierungsschlüsseln auf den Basistabellen Ihrer sicheren Objekte.
Unter diesem Thema wird die Verwendung von Gruppierungsschlüsseln für Basistabellen von freigegebenen sicheren Objekten beschrieben und eine schrittweise Anleitung zur Freigabe einer sicheren Ansicht für ein Verbraucherkonto bereitgestellt. Es werden Beispielskripte sowohl für Anbieter als auch Verbraucher von Daten zur Verfügung gestellt.
Bemerkung
Die Anleitung zur Freigabe eines sicheren Objekts stimmt im Wesentlichen mit der Anleitung für die Freigabe einer Tabelle überein, es kommen nur noch folgende Objekte hinzu:
Ein „privates“ Schema, das die Basistabelle enthält, und ein „öffentliches“ Schema, das das sichere Objekt enthält. Freigegeben werden nur das öffentliche Schema und das sichere Objekt.
Eine „Zuordnungstabelle“ (im „privaten“ Schema), die nur erforderlich ist, wenn Sie die Daten in der Basistabelle für mehrere Verbraucherkonten und nur bestimmte Zeilen der Tabelle für spezifische Konten freigeben möchten.
Unter diesem Thema:
Beispieleinrichtung und Aufgaben¶
Diese Beispielanweisungen gehen davon aus, dass eine Datenbank mit dem Namen mydb
im Datenanbieterkonto vorhanden ist und die beiden Schemas private
und public
enthält- Wenn die Datenbank und die Schemas nicht vorhanden sind, sollten Sie diese erst erstellen, bevor Sie fortfahren.
Schritt 1: Daten- und Zuordnungstabellen im privaten Schema erstellen¶
Erstellen Sie die folgenden beiden Tabellen im Schema mydb.private
, und füllen Sie diese mit Daten:
sensitive_data
– Enthält die freizugebenden Daten sowie die Spalte access_id
zur Steuerung des Datenzugriffs nach Konto.sharing_access
– Verwendet die Spalte access_id
, um die freigegebenen Daten und die Konten, die auf die Daten zugreifen können, zuzuordnen.Schritt 2: Sichere Ansicht im öffentlichen Schema erstellen¶
Erstellen Sie die folgende sichere Ansicht im Schema mydb.public
:
paid_sensitive_data
– Zeigt Daten auf Basis des Kontos an.Beachten Sie, dass die Spalte access_id
aus der Basistabelle (sensitive_data
) nicht in die Ansicht aufgenommen werden muss.
Schritt 3: Tabellen und sichere Ansicht überprüfen¶
Überprüfen Sie die Tabellen und die sichere Ansicht darauf, ob die Daten ordnungsgemäß nach Konto gefiltert werden.
Um die Überprüfung sicherer Ansichten zu ermöglichen, die mit anderen Konten geteilt werden, bietet Snowflake den Sitzungsparameter SIMULATED_DATA_SHARING_CONSUMER. Setzen Sie diesen Sitzungsparameter auf den Namen des Verbraucherkontos, für das Sie den Zugriff simulieren möchten. Sie können dann die Ansicht abfragen und die Ergebnisse anzeigen, die ein Benutzer des Verbraucherkontos sehen wird.
Beispielskript¶
Das folgende Skript veranschaulicht die Ausführung aller im vorherigen Abschnitt beschriebenen Aufgaben:
Erstellen Sie zwei Tabellen im „privaten“ Schema, und füllen Sie die erste Tabelle mit Bestandsdaten von drei verschiedenen Unternehmen (Apple, Microsoft und IBM). Befüllen Sie dann die zweite Tabelle mit Daten, mit denen die Bestandsdaten den einzelnen Konten zugeordnet werden:
use role sysadmin; create or replace table mydb.private.sensitive_data ( name string, date date, time time(9), bid_price float, ask_price float, bid_size int, ask_size int, access_id string /* granularity for access */ ) cluster by (date); insert into mydb.private.sensitive_data values('AAPL',dateadd(day, -1,current_date()), '10:00:00', 116.5, 116.6, 10, 10, 'STOCK_GROUP_1'), ('AAPL',dateadd(month,-2,current_date()), '10:00:00', 116.5, 116.6, 10, 10, 'STOCK_GROUP_1'), ('MSFT',dateadd(day, -1,current_date()), '10:00:00', 58.0, 58.9, 20, 25, 'STOCK_GROUP_1'), ('MSFT',dateadd(month,-2,current_date()), '10:00:00', 58.0, 58.9, 20, 25, 'STOCK_GROUP_1'), ('IBM', dateadd(day, -1,current_date()), '11:00:00', 175.2, 175.4, 30, 15, 'STOCK_GROUP_2'), ('IBM', dateadd(month,-2,current_date()), '11:00:00', 175.2, 175.4, 30, 15, 'STOCK_GROUP_2'); create or replace table mydb.private.sharing_access ( access_id string, snowflake_account string ); /* In the first insert, CURRENT_ACCOUNT() gives your account access to the AAPL and MSFT data. */ insert into mydb.private.sharing_access values('STOCK_GROUP_1', CURRENT_ACCOUNT()); /* In the second insert, replace <consumer_account> with an account name; this account will have */ /* access to IBM data only. Note that account names are case-sensitive and must be in uppercase */ /* enclosed in single-quotes, e.g. */ /* */ /* insert into mydb.private.sharing_access values('STOCK_GROUP_2', 'ACCT1') */ /* */ /* To share the IBM data with multiple accounts, repeat the second insert for each account. */ insert into mydb.private.sharing_access values('STOCK_GROUP_2', '<consumer_account>');
Erstellen Sie eine sichere Ansicht im „öffentlichen“ Schema. Diese Ansicht filtert die Bestandsdaten der ersten Tabelle nach Konto unter Verwendung der Zuordnungsinformationen aus der zweiten Tabelle:
create or replace secure view mydb.public.paid_sensitive_data as select name, date, time, bid_price, ask_price, bid_size, ask_size from mydb.private.sensitive_data sd join mydb.private.sharing_access sa on sd.access_id = sa.access_id and sa.snowflake_account = current_account(); grant select on mydb.public.paid_sensitive_data to public; /* Test the table and secure view by first querying the data as the provider account. */ select count(*) from mydb.private.sensitive_data; select * from mydb.private.sensitive_data; select count(*) from mydb.public.paid_sensitive_data; select * from mydb.public.paid_sensitive_data; select * from mydb.public.paid_sensitive_data where name = 'AAPL'; /* Next, test the secure view by querying the data as a simulated consumer account. You specify the */ /* account to simulate using the SIMULATED_DATA_SHARING_CONSUMER session parameter. */ /* */ /* In the ALTER command, replace <consumer_account> with one of the accounts you specified in the */ /* mapping table. Note that the account name is not case-sensitive and does not need to be enclosed */ /* in single-quotes, e.g. */ /* */ /* alter session set simulated_data_sharing_consumer=acct1; */ alter session set simulated_data_sharing_consumer=<account_name>; select * from mydb.public.paid_sensitive_data;
Erstellen Sie eine Freigabe mit der Rolle ACCOUNTADMIN.
use role accountadmin; create or replace share mydb_shared comment = 'Example of using Secure Data Sharing with secure views'; show shares;
Fügen Sie die Objekte zur Freigabe hinzu. Sie können entweder über eine Datenbankrolle Berechtigungen für diese Objekte zu einer Freigabe hinzufügen (Option 1) oder der Freigabe direkt Berechtigungen für die Objekte erteilen (Option 2):
/* Option 1: Create a database role, grant privileges on the objects to the database role, and then grant the database role to the share */ create database role mydb.dr1; grant usage on database mydb to database role mydb.dr1; grant usage on schema mydb.public to database role mydb.dr1; grant select on mydb.public.paid_sensitive_data to database role mydb.dr1; grant database role mydb.dr1 to share mydb_shared; /* Option 2: Grant privileges on the database objects to include in the share. */ grant usage on database mydb to share mydb_shared; grant usage on schema mydb.public to share mydb_shared; grant select on mydb.public.paid_sensitive_data to share mydb_shared; /* Confirm the contents of the share. */ show grants to share mydb_shared;
Fügen Sie Konten zur Freigabe hinzu.
/* In the alter statement, replace <consumer_accounts> with the */ /* consumer account(s) you assigned to STOCK_GROUP2 earlier, */ /* with each account name separated by commas, e.g. */ /* */ /* alter share mydb_shared set accounts = acct1, acct2; */ alter share mydb_shared set accounts = <consumer_accounts>;
Beispielskript (für Verbraucher)¶
Das folgende Skript kann von Verbrauchern verwendet werden, um eine Datenbank zu erstellen (aus der im obigen Skript erstellten Freigabe) und die sichere Ansicht in der resultierenden Datenbank abzufragen:
Bringen Sie die freigegebene Datenbank in Ihr Konto, indem Sie eine Datenbank aus der Freigabe erstellen.
/* In the following commands, the share name must be fully qualified by replacing */ /* <provider_account> with the name of the account that provided the share, e.g. */ /* */ /* desc prvdr1.mydb_shared; */ use role accountadmin; show shares; desc share <provider_account>.mydb_shared; create database mydb_shared1 from share <provider_account>.mydb_shared;
Erteilen Sie anderen Rollen in Ihrem Konto (z. B. CUSTOM_ROLE1) Berechtigungen für die Datenbank. Die GRANT-Anweisung unterscheidet sich je nachdem, ob der Datenverbraucher der Freigabe Objekte unter Verwendung von Datenbankrollen hinzufügt hat (Option 1) oder indem der Freigabe Berechtigungen für die Objekte direkt zugewiesen wurden (Option 2):
/* Option 1 */ grant database role mydb_shared1.db1 to role custom_role1; /* Option 2 */ grant imported privileges on database mydb_shared1 to custom_role1;
Verwenden Sie die Rolle CUSTOM_ROLE1, um die Ansicht in der von Ihnen erstellten Datenbank abzufragen. Beachten Sie, dass in der Sitzung ein aktives Warehouse vorhanden sein muss, um Abfragen ausführen zu können. Ersetzen Sie im Befehl USE WAREHOUSE den Namen <warehouse_name> durch den Namen eines der Warehouses in Ihrem Konto. Die Rolle CUSTOM_ROLE1 muss über die USAGE-Berechtigung für das Warehouse verfügen:
use role custom_role1; show views; use warehouse <warehouse_name>; select * from paid_sensitive_data;