Override share restrictions¶
To allow sharing data from a Business Critical account to a non-Business Critical account, or from a HIPAA-compliant account to a non-HIPAA- compliant account, a user with a role granted the OVERRIDE SHARE RESTRICTIONS global privilege can specify the SHARE_RESTRICTIONS parameter for a specific share offered by their provider account.
Berechtigung OVERRIDE SHARE RESTRICTIONS einer anderen Rolle zuweisen¶
Die globale Berechtigung OVERRIDE SHARE RESTRICTIONS ist standardmäßig der Rolle ACCOUNTADMIN zugewiesen, kann aber auch anderen Rollen zugewiesen werden. Verwenden Sie die Rolle ACCOUNTADMIN und den Befehl GRANT <Berechtigungen> … TO ROLE, um einer Rolle die OVERRIDE SHARE RESTRICTIONS-Berechtigung zu erteilen.
Syntax:
GRANT OVERRIDE SHARE RESTRICTIONS ON ACCOUNT TO ROLE <Rollenname>
Wobei:
<role_name> (Rollenname) ist die Rolle, der die Berechtigung erteilt wird.
So erteilen Sie beispielsweise der Rolle SYSADMIN die Berechtigung:
use role accountadmin;
grant override share restrictions on account to role sysadmin;
Parameter SHARE_RESTRICTIONS auf eine Freigabe setzen¶
As a provider in a Business Critical account, you can share data with a consumer in a non-Business Critical account using the SHARE_RESTRICTIONS parameter on a direct share. This parameter also applies to HIPAA-compliant providers that share data with a non-HIPAA consumer.
Sie müssen die Rolle ACCOUNTADMIN oder eine kundenspezifische Rolle mit den folgenden Berechtigungen verwenden:
Globale Berechtigung OVERRIDE SHARE RESTRICTIONS
OWNERSHIP für die Freigabe oder globale Berechtigung CREATE SHARE
Verwenden Sie den Befehl ALTER SHARE, um den Parameter SHARE_RESTRICTIONS für das Objekt festzulegen.
For example, to update the share my_share to add a non-Business Critical or non-HIPAA consumer account consumerorg.consumeraccount,
run the following:
use role sysadmin;
alter share my_share add accounts = consumerorg.consumeraccount SHARE_RESTRICTIONS=false;
Weitere Details dazu finden Sie unter ALTER SHARE.
Achtung
Snowflake übernimmt keine Verantwortung für die Sicherstellung, dass die am Data Sharing beteiligten HIPAA- und HITRUST-Konten untereinander über unterzeichnete BAA verfügen. Diese Aufgabe obliegt den Konten, die Daten freigeben. Beachten Sie, dass das Fehlen einer signierten BAA die HIPAA- und HITRUST-Konformität beider Konten, aber vor allem des Anbieterkontos beeinträchtigen kann.
Wenn Sie zudem ein Business Critical-Konto verwenden, damit das mit Business Critical bereitgestellte Datenschutzniveau eingehalten wird, empfehlen wir nachdrücklich die Berücksichtigung der folgenden Punkte, bevor Sie bei Snowflake die Aktivierung von Secure Data Sharing mit Nicht-Business Critical-Konten anfordern:
Geben Sie keine vertraulichen Daten für Nicht-Business Critical-Konten frei.
Erstellen Sie stattdessen ein zweites Nicht-Business Critical-Konto für die Speicherung weniger sensibler Daten, die Sie dann für Nicht-Business Critical-Konten freigeben.
Wenn Sie Tri-Secret Secure für Ihr Business Critical-Konto verwenden und Daten für andere Konten freigeben, behandelt Snowflake den Datenzugriff von diesen Konten so, als ob der Zugriff von Ihrem eigenen Konto aus erfolgt. Insbesondere kann es für die Gewährung des Zugriffs auf das Verbraucherkonto erforderlich sein, dass Snowflake auf den Schlüsselverwaltungsdienst der Cloudplattform zugreift, die Ihr Snowflake-Konto hostet.
Dies sind nur Empfehlungen, die von Snowflake nicht erzwungen werden. Die Entscheidung über die Freigabe von Daten obliegt stets dem Datenanbieter. Snowflake übernimmt keine Verantwortung für Daten, die unsachgemäß freigegeben werden.