Erweiterte Sicherheit auf Spaltenebene¶

Verwenden von CURRENT_ROLE und IS_ROLE_IN_SESSION¶

Eine Maskierungsrichtlinienbedingung mit CURRENT_ROLE zielt auf die aktuelle Sitzung ab und wird vom Ausführungskontext der SQL-Anweisung nicht beeinflusst.

Wenn Rollenaktivierung und Rollenhierarchie in den Richtlinienbedingungen erforderlich sind, verwenden Sie IS_ROLE_IN_SESSION.

Betrachten Sie den folgenden Maskierungsrichtlinientext:

CREATE OR REPLACE MASKING POLICY mask_string AS
(val string) RETURNS string ->
CASE
  WHEN CURRENT_ROLE() IN ('ANALYST') THEN val
  ELSE '********'
END;

Copy

Führen Sie die folgenden Schritte aus, um festzustellen, ob ein bestimmter Benutzer die Autorisierung zur Anzeige von Daten einer bestimmten Spalte hat, auf der diese Maskierungsrichtlinie festgelegt ist:

1. Prüfen Sie die Bedingungen der Maskierungsrichtlinie.

2. Stellen Sie fest, ob sich die angegebene Rolle in der CURRENT_ROLE-Hierarchie befindet.

3. Führen Sie zur Überprüfung eine Testabfrage aus.

USE ROLE analyst;

SELECT * FROM mydb.mysch.mytable;

Verwenden von INVOKER_ROLE¶

Eine Maskierungsrichtlinienbedingung unter Verwendung von INVOKER_ROLE zielt auf den Ausführungskontext der SQL-Anweisung ab.

In der folgenden Tabelle sind der Ausführungskontext und der Wert zusammengefasst, den INVOKER_ROLE in einer Maskierungsrichtlinienbedingung zurückgibt:

Betrachten Sie den folgenden Maskierungsrichtlinientext, der auf eine einzelne Ansicht einer Tabelle angewendet wird:

CREATE OR REPLACE MASKING POLICY mask_string AS
(val string) RETURNS string ->
CASE
  WHEN INVOKER_ROLE() IN ('ANALYST') THEN val
  ELSE '********'
END;

Copy

Führen Sie die folgenden Schritte aus, um festzustellen, ob ein bestimmter Benutzer, der eine Abfrage auf der Spalte ausführt, zum Anzeigen von Daten berechtigt ist:

1. Prüfen Sie die Bedingungen der Maskierungsrichtlinie.

2. Stellen Sie fest, ob die angegebene Rolle Eigentümer der Ansicht ist.

3. Führen Sie zur Überprüfung eine Testabfrage aus.

SHOW GRANTS OF ROLE analyst;

USE ROLE analyst;

SELECT * FROM mydb.mysch.myview;

Verwenden von IS_GRANTED_TO_INVOKER_ROLE¶

Die Funktion IS_GRANTED_TO_INVOKER_ROLE kann als Teil einer Bedingung an einen Maskierungsrichtlinientext übergeben werden. Wenn die Funktion TRUE ergibt, ist die im Funktionsargument angegebene Rolle in der INVOKER_ROLE-Hierarchie enthalten.

Betrachten Sie den folgenden Maskierungsrichtlinientext, der auf eine Ansichtsspalte mit Sozialversicherungsnummern (SSNs) angewendet wird:

CREATE OR REPLACE MASKING POLICY mask_string AS
(val string) RETURNS string ->
CASE
  WHEN IS_GRANTED_TO_INVOKER_ROLE('PAYROLL') THEN val
  WHEN IS_GRANTED_TO_INVOKER_ROLE('ANALYST') THEN REGEXP_REPLACE(val, '[0-9]', '*', 7)
  ELSE '*******'
END;

Führen Sie die folgenden Schritte aus, um festzustellen, ob ein bestimmter Benutzer, der eine Abfrage auf der Ansichtsspalte ausführt, zum Anzeigen von Daten berechtigt ist:

1. Prüfen Sie die Bedingungen der Maskierungsrichtlinie.

2. Stellen Sie fest, ob sich die angegebene Rolle in der Hierarchie der Aufruferrolle befindet. Wenn die Richtlinie beispielsweise für eine Ansicht festgelegt wird, muss sich die angegebene Rolle in der Rollenhierarchie des Eigentümers der Ansicht befinden, damit TRUE zurückgegeben wird. Weitere Informationen dazu finden Sie in den Nutzungshinweisen.

3. Führen Sie zur Überprüfung eine Testabfrage aus.

USE ROLE payroll;

SELECT * FROM mydb.mysch.myview;

USE ROLE analyst;

SELECT * FROM mydb.mysch.myview;

Hashing-, Kryptographie- und Verschlüsselungsfunktionen in Maskierungsrichtlinien¶

Hashing und Kryptografie/Prüfsumme können in Maskierungsrichtlinien verwendet werden, um sensible Daten zu maskieren.

Bevor Sie eine dieser Funktionen in einer Maskierungsrichtlinie verwenden, ist es wichtig zu prüfen, ob Ihr Anwendungsfall mit diesen Funktionen auch JOIN-Operationen umfasst. Bei bestimmten Implementierungen von Maskierungsrichtlinien können kreative JOIN-Operationen, die Tabellen und Ansichten beinhalten, dazu führen, dass der maskierte Wert auf der Grundlage der folgenden Einschränkung auf seinen wahren Wert zurückgeführt wird:

• Es ist möglich, dass es zu Kollisionen kommt, weil es möglicherweise keine 1:1-Darstellung des tatsächlichen Werts (d. h. der Eingabe) und des Hash-Werts, des kryptografischen Werts oder des Prüfsummenwerts auf der Grundlage der Gesamtzahl der zu transformierenden Werte (d. h. der Ausgabe, des Wertebereichs) gibt.

Eine 1:1-Darstellung ist wahrscheinlicher, bis die Gesamtzahl der Eingabewerte die Quadratwurzel der zu transformierenden Ausgabewerte erreicht.

Wenn der Ausgabewert für den Hash beispielsweise 144 ist, kann erwartet werden, dass die ersten 12 Werte (d. h. 144^(1/2) – die Quadratwurzel aus 144) eindeutig sind und dass bei den restlichen 132 Werten Kollisionen auftreten können. Da diese Einschränkung und deren Konsequenz möglich ist, ist es ratsam, niemals Hashing-, Kryptografie- oder Prüfsummenfunktionen in Maskierungsrichtlinien zu verwenden, deren Werte in JOIN-Operationen verwendet werden können.