動的データマスキング - Amazon Redshift

動的データマスキング

概要

Amazon Redshift の動的データマスキング (DDM) を使用すると、データウェアハウス内の機密データを保護できます。Amazon Redshift が機密データをクエリ時にユーザーに表示する方法を、データベースで変換せずに操作できます。特定のユーザーまたはロールにカスタムの難読化ルールを適用するマスキングポリシーを通じて、データへのアクセスを制御します。これにより、基になるデータを変更したり、SQL クエリを編集したりすることなく、プライバシー要件の変更に対応できます。

動的データマスキングポリシーは、特定の形式に一致するデータを隠したり、難読化したり、仮名化したりします。テーブルにアタッチされると、その 1 つ以上の列にマスキング式が適用されます。さらにマスキングポリシーを変更して、特定のユーザーのみに適用したり、ロールベースのアクセスコントロール (RBAC) で作成できるユーザー定義のロールにのみ適用したりできます。さらに、マスキングポリシーを作成するときに条件列を使用してセルレベルで DDM を適用できます。条件付きマスキングの詳細については、「条件付き動的データマスキング」を参照してください。

難読化レベルの異なる複数のマスキングポリシーをテーブル内の同じ列に適用し、それらを異なるロールに割り当てることができます。1 つの列に異なるポリシーが異なるロールに適用されている場合に競合が発生しないように、アプリケーションごとに優先順位を設定できます。これにより、特定のユーザーまたはロールがどのデータにアクセスできるかを制御できます。DDM ポリシーでは、SQL や Python で記述されたユーザー定義関数、または AWS Lambda を使用して、データを部分的または完全に編集したり、データをハッシュしたりできます。ハッシュを使用してデータをマスキングすることで、機密情報にアクセスせずに、このデータに結合を適用できます。

エンドツーエンドの例

次の内容は、マスキングポリシーを作成して列にアタッチする方法を示すエンドツーエンドの例です。これらのポリシーにより、ユーザーは各自のロールに割り当てられているポリシーの難読化の度合いに応じて、列にアクセスしてさまざまな値を確認できます。この例を実行するには、スーパーユーザーであるか、sys:secadmin ロールを持っている必要があります。

マスキングポリシーの作成

まず、テーブルを作成し、クレジットカードの値を入力します。

--create the table CREATE TABLE credit_cards ( customer_id INT, credit_card TEXT ); --populate the table with sample values INSERT INTO credit_cards VALUES (100, '4532993817514842'), (100, '4716002041425888'), (102, '5243112427642649'), (102, '6011720771834675'), (102, '6011378662059710'), (103, '373611968625635') ; --run GRANT to grant permission to use the SELECT statement on the table GRANT SELECT ON credit_cards TO PUBLIC; --create two users CREATE USER regular_user WITH PASSWORD '1234Test!'; CREATE USER analytics_user WITH PASSWORD '1234Test!'; --create the analytics_role role and grant it to analytics_user --regular_user does not have a role CREATE ROLE analytics_role; GRANT ROLE analytics_role TO analytics_user;

次に、分析ロールに適用するマスキングポリシーを作成します。

--create a masking policy that fully masks the credit card number CREATE MASKING POLICY mask_credit_card_full WITH (credit_card VARCHAR(256)) USING ('000000XXXX0000'::TEXT); --create a user-defined function that partially obfuscates credit card data CREATE FUNCTION REDACT_CREDIT_CARD (credit_card TEXT) RETURNS TEXT IMMUTABLE AS $$ import re regexp = re.compile("^([0-9]{6})[0-9]{5,6}([0-9]{4})") match = regexp.search(credit_card) if match != None: first = match.group(1) last = match.group(2) else: first = "000000" last = "0000" return "{}XXXXX{}".format(first, last) $$ LANGUAGE plpythonu; --create a masking policy that applies the REDACT_CREDIT_CARD function CREATE MASKING POLICY mask_credit_card_partial WITH (credit_card VARCHAR(256)) USING (REDACT_CREDIT_CARD(credit_card)); --confirm the masking policies using the associated system views SELECT * FROM svv_masking_policy; SELECT * FROM svv_attached_masking_policy;

マスキングポリシーをアタッチする

マスキングポリシーをクレジットカードテーブルにアタッチします。

--attach mask_credit_card_full to the credit card table as the default policy --all users will see this masking policy unless a higher priority masking policy is attached to them or their role ATTACH MASKING POLICY mask_credit_card_full ON credit_cards(credit_card) TO PUBLIC; --attach mask_credit_card_partial to the analytics role --users with the analytics role can see partial credit card information ATTACH MASKING POLICY mask_credit_card_partial ON credit_cards(credit_card) TO ROLE analytics_role PRIORITY 10; --confirm the masking policies are applied to the table and role in the associated system view SELECT * FROM svv_attached_masking_policy; --confirm the full masking policy is in place for normal users by selecting from the credit card table as regular_user SET SESSION AUTHORIZATION regular_user; SELECT * FROM credit_cards; --confirm the partial masking policy is in place for users with the analytics role by selecting from the credit card table as analytics_user SET SESSION AUTHORIZATION analytics_user; SELECT * FROM credit_cards;

マスキングポリシーの変更

次のセクションでは、動的データマスキングポリシーを変更する方法について説明します。

--reset session authorization to the default RESET SESSION AUTHORIZATION; --alter the mask_credit_card_full policy ALTER MASKING POLICY mask_credit_card_full USING ('00000000000000'::TEXT); --confirm the full masking policy is in place after altering the policy, and that results are altered from '000000XXXX0000' to '00000000000000' SELECT * FROM credit_cards;

マスキングポリシーのデタッチとドロップ

次のセクションでは、テーブルからすべての動的データマスキングポリシーを削除して、マスキングポリシーをデタッチおよびドロップする方法を示します。

--reset session authorization to the default RESET SESSION AUTHORIZATION; --detach both masking policies from the credit_cards table DETACH MASKING POLICY mask_credit_card_full ON credit_cards(credit_card) FROM PUBLIC; DETACH MASKING POLICY mask_credit_card_partial ON credit_cards(credit_card) FROM ROLE analytics_role; --drop both masking policies DROP MASKING POLICY mask_credit_card_full; DROP MASKING POLICY mask_credit_card_partial;

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

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

  • ビューなど、テーブルから作成されたオブジェクトをクエリすると、オブジェクトを作成したユーザーのポリシーではなく、クエリを実行するユーザーのマスキングポリシーに基づいて結果が表示されます。例えば、アナリストロールを持つユーザーが 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 はクエリのエラーを返します。