高度な列レベルセキュリティのトピック¶

CURRENT_ROLE および IS_ROLE_IN_SESSION を使用する¶

CURRENT_ROLEを使用したマスキングポリシー条件では、現在のセッションがターゲットになり、SQLステートメントの実行コンテキストによる影響を受けません。

ポリシー条件でロールのアクティブ化とロール階層が必要な場合は、 IS_ROLE_IN_SESSION を使用します。

次のマスキングポリシー本文を検討してください。

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

Copy

特定のユーザーに、このマスキングポリシーが設定されている列のデータを表示する権限があるかどうかを確認するには、次のステップを実行します。

1. マスキングポリシーの条件を評価します。

2. 指定されたロールが CURRENT_ROLE 階層にあるかどうかを確認します。

3. 検証するテストクエリを実行します。

USE ROLE analyst;

SELECT * FROM mydb.mysch.mytable;

INVOKER_ROLE を使用する¶

INVOKER_ROLE を使用したマスキングポリシー条件では、 SQL ステートメントの実行コンテキストがターゲットになります。

次のテーブルは、実行コンテキストと、マスキングポリシー条件で INVOKER_ROLE が返す値をまとめたものです。

テーブル上の単一のビューに適用される次のマスキングポリシー本文を検討してください。

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

Copy

列でクエリを実行している特定のユーザーにデータ表示権限があるかどうかを確認するには、次のステップを実行します。

1. マスキングポリシーの条件を評価します。

2. 指定されたロールがビューを所有しているかどうかを確認します。

3. 検証するテストクエリを実行します。

SHOW GRANTS OF ROLE analyst;

USE ROLE analyst;

SELECT * FROM mydb.mysch.myview;

IS_GRANTED_TO_INVOKER_ROLE を使用する¶

IS_GRANTED_TO_INVOKER_ROLE関数は、条件の一部としてマスキングポリシー本文に渡すことができます。関数がTRUEと評価されると、関数引数のロールはINVOKER_ROLE階層にあります。

社会保障番号（SSNs）のビュー列に適用される次のマスキングポリシー本文を検討してください。

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;

ビュー列でクエリを実行している特定のユーザーにデータ表示権限があるかどうかを確認するには、次のステップを実行します。

1. マスキングポリシーの条件を評価します。

2. 指定されたロールが呼び出し元ロール階層にあるかどうかを確認します。たとえば、ポリシーがビューに設定されている場合、 TRUE を返すには、指定されたロールがビュー所有者のロール階層になければなりません。詳細については、 使用上の注意 をご参照ください。

3. 検証するテストクエリを実行します。

USE ROLE payroll;

SELECT * FROM mydb.mysch.myview;

USE ROLE analyst;

SELECT * FROM mydb.mysch.myview;

マスキングポリシー内のハッシュ、暗号化、および暗号化関数¶

ハッシュ および 暗号化/チェックサム は、機密データをマスクするためのマスキングポリシーで使用できます。

これらの関数のいずれかを マスキングポリシー に実装する前に、これらの関数のユースケースに JOIN 操作が含まれるかどうかを検討することが重要です。特定のマスキングポリシーの実装では、テーブルとビューを含むクリエイティブなJOIN操作により、次の制限に基づいてマスクされた値がその実際の値にリバースエンジニアリングされる可能性があります。

• 実際の値（つまり入力）と、値の総数に基づくハッシュ値、暗号化値、またはチェックサム値（つまり、出力、値の範囲）は1対1の表現でないため、競合が発生する可能性があります。

1対1の表現は、入力値の総数が変換する出力値の平方根に達するまで発生する可能性が高くなります。

たとえば、ハッシュへの出力値が144個の場合、最初の12個の値（つまり、144^(1/2) -- 144の平方根）が一意であり、残りの132個の値に対して競合が発生する可能性があると予期することは妥当です。この制限とその結果が発生する可能性があるため、JOIN操作で値が使用される可能性のあるマスキングポリシーでは、ハッシュ関数、暗号化関数、またはチェックサム関数を使用しないことをお勧めします。