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 :ref: 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:

Verwendung von Gruppierungsschlüssel für freigegebene Daten

Bei sehr großen (d. h. mehrere Terabyte) Tabellen verbessern Gruppierungsschlüssel signifikant die Performance von Abfragen. Durch die Definition eines oder mehrerer Gruppierungsschlüssel auf den Basistabellen, die in freigegebenen sicheren Ansichten oder UDFs verwendet werden, sorgen Sie dafür, dass die Benutzer in Ihren Verbraucherkonten bei der Verwendung dieser Objekte keine Leistungsnachteile bemerken.

Bei der Auswahl der Spalten, die als Gruppierungsschlüssel für eine Tabelle verwendet werden sollen, müssen Sie einige wichtige Hinweise beachten.

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

Bemerkung

Derzeit unterstützt der Sitzungsparameter SIMULATED_DATA_SHARING_CONSUMER nur sichere Ansichten und sichere materialisierte Ansichten, nicht jedoch sichere UDFs.

Schritt 4: Freigabe erstellen

  1. Erstellen Sie eine Freigabe mit der Rolle ACCOUNTADMIN.

  2. Fügen Sie der Freigabe Berechtigungen für die Datenbank (mydb), das Schema (public) und die sicher Ansicht (paid_sensitive_data) hinzu. Beachten Sie, dass es sich hierbei um die einzigen Objekte handelt, die der Freigabe hinzugefügt wurden, wodurch sichergestellt wird, dass keine Benutzer in Verbraucherkonten auf das private Schema oder eine der Tabellen im Schema zugreifen können.

  3. Prüfen Sie die Inhalte der Freigabe. Verwenden Sie zunächst den Befehl SHOW GRANTS, um zu prüfen, ob die Objekte in der Freigabe über die erforderlichen Berechtigungen verfügen.

    Beachten Sie, dass die sicher Ansicht paid_sensitive_data in der Befehlsausgabe als Tabelle angezeigt wird.

  4. Fügen Sie ein oder mehrere Konten zur Freigabe hinzu.

Beispielskript

Das folgende Skript veranschaulicht die Ausführung aller im vorherigen Abschnitt beschriebenen Aufgaben:

/* Create two tables in the 'private' schema and populate the first one with stock data from three   */
/* different companies (Apple, Microsoft, and IBM). You will then populate the second one with       */
/* data that maps the stock data to individual accounts.                                             */

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 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>');


/* Create a secure view in the 'public' schema. This view filters the stock data from the first      */
/* table by account, using the mapping information in the second table.                              */

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;


/* Create a share using the ACCOUNTADMIN role. */

use role accountadmin;

create or replace share mydb_shared
  comment = 'Example of using Secure Data Sharing with secure views';

show shares;


/*  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;


/* Add accounts to the share.                                    */
/*                                                               */
/* 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:

/* Bring the shared database into your account by creating a database from the share. */
/*                                                                                    */
/* 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;


/* Grant privileges on the database to other roles (e.g. SYSADMIN) in your account. */

grant imported privileges on database mydb_shared1 to sysadmin;


/* Now you can use the SYSADMIN role to query the view in the database you created.       */
/*                                                                                        */
/* Note that there must be a warehouse in use in the session to perform queries. In the   */
/* USE WAREHOUSE command, replace <warehouse_name> with the name of one of the warehouses */
/* in your account.                                                                       */

use role sysadmin;

show views;

use warehouse <warehouse_name>;

select * from paid_sensitive_data;