動的なデータマスキングを使用する際の考慮事項

動的なデータマスキングを使用する場合は、以下を考慮してください。

ビューなど、テーブルから作成されたオブジェクトをクエリすると、オブジェクトを作成したユーザーのポリシーではなく、クエリを実行するユーザーのマスキングポリシーに基づいて結果が表示されます。例えば、アナリストロールを持つユーザーが secadmin によって作成されたビューをクエリすると、アナリストロールにアタッチされたマスキングポリシーを使用して結果が表示されます。
EXPLAIN コマンドによって機密性の高いマスキングポリシーフィルターが公開されるのを防ぐために、SYS_EXPLAIN _DDM のアクセス許可を持つユーザーのみが EXPLAIN 出力に適用されたマスキングポリシーを確認できます。デフォルトでは、ユーザーには SYS_EXPLAIN_DDM のアクセス許可がありません。

ロールにアクセス許可を付与するための構文は、次のとおりです。
```
GRANT EXPLAIN MASKING TO ROLE rolename
```
EXPLAIN コマンドの詳細については、「EXPLAIN」を参照してください。
ロールが異なるユーザーには、使用したフィルター条件または結合条件に基づいて異なる結果が表示されます。例えば、特定の列値を使用するテーブルで SELECT コマンドを実行する際、コマンドを実行するユーザーにその列を難読化するマスキングポリシーが適用されている場合、失敗します。
DDM ポリシーは、前提となる操作や述語よりも先に適用する必要があります。マスキングポリシーには以下が含まれる場合があります。
- 値を NULL に変換するなどの低コストの定数演算
- HMAC ハッシュなどの中コストのオペレーション
- 外部の Lambda ユーザー定義関数への呼び出しなどの高コストの操作
そのため、可能な限り、単純なマスキング式を使用することをお勧めします。
行レベルのセキュリティポリシーを持つロールには DDM ポリシーを使用できますが、RLS ポリシーは DDM の前に適用されることに注意してください。動的データマスキング式は、RLS で保護された行を読み取ることができません。RLS の詳細については、「行レベルのセキュリティ」を参照してください。
COPY コマンドを使用してパーケットから保護されているターゲットテーブルにコピーするときには、COPY ステートメントで列を明示的に指定する必要があります。COPY による列のマッピングの詳細については、「列のマッピングオプション」を参照してください。
DDM ポリシーは、次の関係にアタッチできません。
- システムテーブルとカタログ
- 外部テーブル
- データ共有テーブル
- マテリアライズドビュー
- データベース間の関係
- 一時テーブル
- 相関クエリ
DDM ポリシーにはルックアップテーブルを含めることができます。USING 句にはルックアップテーブルを含めることができます。以下の関係タイプはルックアップテーブルとして使用できません。
- システムテーブルとカタログ
- 外部テーブル
- データ共有テーブル
- ビュー、マテリアライズドビュー、遅延バインディングビュー
- データベース間の関係
- 一時テーブル
- 相関クエリ
次に示すのは、マスキングポリシーをルックアップテーブルにアタッチする例です。
```
--Create a masking policy referencing a lookup table
CREATE MASKING POLICY lookup_mask_credit_card WITH (credit_card TEXT) USING (
  CASE
    WHEN
      credit_card IN (SELECT credit_card_lookup FROM credit_cards_lookup)      
    THEN '000000XXXX0000'
    ELSE REDACT_CREDIT_CARD(credit_card)
    END
  ); 
  
--Provides access to the lookup table via a policy attached to a role
GRANT SELECT ON TABLE credit_cards_lookup TO MASKING POLICY lookup_mask_credit_card;
```
ターゲット列のタイプとサイズと互換性のない出力を生成するようなマスキングポリシーをアタッチすることはできません。例えば、12 文字の文字列を VARCHAR(10) 列に出力するマスキングポリシーをアタッチすることはできません。Amazon Redshift では、次の例外がサポートされます。
- 入力タイプ INTN のマスキングポリシーは、M < N であればサイズ INTM のポリシーにアタッチできます。例えば、BIGINT (INT8) 入力ポリシーを smallint (INT4) 列にアタッチできます。
- 入力タイプが NUMERIC または DECIMAL のマスキングポリシーは、常に FLOAT 列にアタッチできます。
DDM ポリシーは、データ共有では使用できません。データ共有のデータプロデューサーがデータ共有内のテーブルに DDM ポリシーをアタッチすると、テーブルをクエリしようとしているデータコンシューマーのユーザーはテーブルにアクセスできなくなります。DDM ポリシーがアタッチされたテーブルは、データ共有に追加できません。
以下の設定オプションのいずれかの値がセッションのデフォルト値と一致しない場合、DDM ポリシーがアタッチされているリレーションをクエリすることはできません。
- enable_case_sensitive_super_attribute
- enable_case_sensitive_identifier
- downcase_delimited_identifier
DDM ポリシーがアタッチされているリレーションをクエリしようとして、「DDM で保護されたリレーションは、大文字と小文字の区別がデフォルト値と異なるため、セッションレベルの設定をサポートしていません」というメッセージが表示される場合は、セッションの設定オプションをリセットすることを検討してください。
プロビジョニングされたクラスターまたはサーバーレス名前空間にデータマスキングポリシーが適用されている場合、以下のコマンドは標準ユーザーにはブロックされます。
```
ALTER <current_user> SET enable_case_sensitive_super_attribute/enable_case_sensitive_identifier/downcase_delimited_identifier
```
DDM ポリシーを作成するときは、ポリシー作成時のセッションの設定オプション設定と一致するように、標準ユーザーのデフォルト設定オプション設定を変更することをお勧めします。スーパーユーザーと ALTER USER 権限を持つユーザーは、パラメータグループ設定または ALTER USER コマンドを使用して、この操作を行うことができます。パラメータグループの詳細については、「Amazon Redshift 管理ガイド」の「Amazon Redshift パラメータグループ」を参照してください。ALTER USER コマンドの詳細については、「ALTER USER」を参照してください。
DDM ポリシーがアタッチされたビューや遅延バインディングビューは、通常のユーザーが CREATE VIEW コマンドを使用して置き換えることはできません。ビューまたは LBV を DDM ポリシーに置き換えるには、まず、それらにアタッチされている DDM ポリシーをすべてデタッチし、ビューまたは LBV を置き換えてから、ポリシーを再アタッチします。スーパーユーザーと sys:secadmin アクセス許可を持っているユーザーは、ポリシーをデタッチすることなく、DDM ポリシーが設定されたビューまたは LBV で CREATE VIEW を使用できます。
DDM ポリシーがアタッチされたビューは、システムテーブルとビューを参照できません。遅延バインディングビューは、システムテーブルとビューを参照できます。
DDM ポリシーがアタッチされた遅延バインディングビューは、JSON ドキュメントなどのデータレイク内のネストされたデータを参照できません。
遅延バインディングビューがいずれかのビューから参照されている場合、その遅延バインディングビューには DDM ポリシーをアタッチできません。
遅延バインディングビューにアタッチされた DDM ポリシーは、列名でアタッチされます。クエリ時に、Amazon Redshift は、遅延バインディングビューにアタッチされたすべてのマスキングポリシーが正常に適用されていること、および遅延バインディングビューの出力列タイプがアタッチされたマスキングポリシーのタイプと一致することを検証します。検証が失敗した場合、Amazon Redshift はクエリのエラーを返します。
DDM ポリシーの作成する際に、カスタマイズされたセッションコンテキスト変数を使用できます。次の例では、セッションコンテキスト変数を設定します。
```
-- Set a customized context variable.
SELECT set_config('app.city', 'XXXX', FALSE);

-- Create a MASKING policy using current_setting() to get the value of a customized context variable.
CREATE MASKING POLICY city_mask
WITH (city VARCHAR(30))
USING (current_setting('app.city')::VARCHAR(30));

-- Attach the policy on the target table to one or more roles.
ATTACH MASKING POLICY city_mask 
ON tickit_users_redshift(city) 
TO ROLE analyst, ROLE dbadmin;
```
カスタマイズされたセッションコンテキスト変数の設定と取得の詳細については、「SET」、「SET_CONFIG」、「SHOW」、「CURRENT_SETTING」、「RESET」を参照してください。サーバー設定変更全般の詳細については、「サーバー設定の変更」を参照してください。

重要
DDM ポリシー内でセッションコンテキスト変数を使用する場合、セキュリティポリシーは、ポリシーを呼び出すユーザーまたはロールに依存します。DDM ポリシーでセッションコンテキスト変数を使用する場合は、セキュリティの脆弱性を避けるように注意してください。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

DDM システムビュー

エンドツーエンドの例

動的なデータマスキングを使用する際の考慮事項

重要