7.1 概要に関するよくある質問

Oracle Data Redactionに関する一般的な質問への回答をご確認ください

Oracle Data Redactionとは

リダクションとは、表内やビュー内の列から返される機密情報を選択的に不明瞭化するプロセスです。データ・リダクションでは、データベース内の表の内容は変更されません。これはユーザーが問合せを実行したときに表示されるデータに対して作用し、ポリシーに基づいてそのデータがリダクションされます。データ・リダクションは、動的データ・マスキングとも呼ばれます。

データ・リダクションが最適なユースケースはどれですか。

データ・リダクションは、ダッシュボード、レポートまたはアプリケーションに表示される機密情報の保護、管理ツールに表示されるデータの制限、および分析時や読取り専用問合せ中の機密データの開示防止に最適です。

データ・リダクションは、格納されたデータを変更しますか、それとも問合せの実行時にリダクションするだけですか。

Oracle Data Redactionでは、問合せの実行時にのみデータがリダクションされ、基礎となる格納データは変更されません。

リダクション・ポリシーを定義、テストおよび実行するためのワークフローの概要を教えてください。

  1. 機密列や機密表を識別します。
  2. 信頼できるユーザーに必要な権限を付与します。
  3. DBMS_REDACT.ADD_POLICYプロシージャを使用してリダクション・ポリシーを作成します。
  4. 問合せを実行し、リダクションされた出力を確認して、ポリシーをテストします。
  5. デプロイメントに対してポリシーを有効にします。必要に応じてポリシーを変更または削除します。

どのデータ型(文字、数値、日時、JSON、LOBなど)がサポートされていますか。

Oracle Data Redactionは次をサポートしています
  • 文字:
    • CHAR
    • VARCHAR2
    • NCHAR
    • NVARCHAR2
  • 数値:
    • NUMBER
    • FLOAT
    • BINARY_FLOAT
    • BINARY_DOUBLE
  • 日時タイプ:
    • DATE
    • TIMESTAMP
  • LOBおよびブール:
    • CLOB - 完全リダクションのみサポート
    • NCLOB - 完全リダクションのみサポート
    • BLOB - 完全リダクションのみサポート
    • BOOLEAN - 完全リダクションのみサポート

    LOBおよびBOOLEANに対する部分、ランダムまたは正規表現のリダクションは、これらのデータ型が複雑で可変的な性質であるため、サポートされていません。

ユーザー定義型、JSON、XML、RAWおよびほとんどのspatial型はサポートされていません。

どのリダクション方法を使用できますか。それぞれをいつ使用するのがよいですか。

リダクション方法とそれらを使用するタイミング:

  • 完全リダクション: 値全体を固定置換(たとえば、''、0または固定日付)で置換します。何も見せないときに使用します(たとえば、完全なSSN、権限のないユーザーに対するクレジット・カード)。機密性の高いフィールドに対して、シンプルで一貫性があり、最も安全です。
  • 部分リダクション: 値の一部のみをマスクし、許可された部分を表示します(例: XXXX-XXXX-XXXX-1234)。参照、照合、カスタマ・サポートなどのワークフローで、ユーザーの表示を制限する必要がある場合に使用します。

    代表的なフィールド: SSNの最後の4桁、電話の最後の2桁から4桁。使いやすさと秘密保持のバランスを取ります。

  • ランダム・リダクション: 同じ型/長さのランダムな文字/数字で値を置き換えます。フォーマットは重要だが、真実性は重要ではない場合、現実的に見えるが導出不可能な分析用の値が必要なときに使用します。

    代表的なフィールド: 数値ID、デモ・ビューの金額、リンクで参照する必要がないフリー・テキスト。

  • 正規表現リダクション: 正規表現を使用して、文字列内のパターンを検索してマスクします。機密データがフリー・テキストまたは混合コンテンツ(電子メール、SSN、チケット参照を含むノートなど)に埋め込まれている場合に使用します。

    代表的なパターン: SSNの場合は\d{3}-\d{2}-\d{4}、電子メール・パターンの場合はA-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,} 強力で正確。慎重にテストして、マスキングの不足や過剰がないようにしてください。

  • なし(リダクションなし): 値を変更しません。テスト目的のためにポリシーで意図的に表示を許可する場合に使用します(機密ではない列、特権ロールなど)。予期しない事態を避けるために、ポリシーではこれを明示的な選択肢にしてください。
  • NULL化: 実際の値ではなく、NULLを返します。ダウンストリーム・アプリケーションが「使用不可」を「マスク済」と異なる方法で処理する(たとえば、NULLに関して条件付きロジックをトリガーしたり、分析でレコードを除外する必要がある)場合に使用します。集計/結合に影響を与える場合があるため、NULLが指定された場合のアプリケーションの動作を確認してください。

一般的なPIIを部分的にリダクションする(たとえば、SSNの最後の4桁を保持する、または電子メールのユーザー名/ドメインをリダクションする)にはどうすればよいですか?

  • 固定パターンに対しては部分リダクションを使用します(たとえば、SSNの最後の4桁)。

    例: 正規表現\d{3}-\d{2}-(\d{4})を使用すると123-45-6789がXXX-XX-6789になります。

  • 正規表現リダクションを使用して、定義したパターンで、電子メールのユーザー名やドメインをマスクしたり、電話番号セグメントをリダクションします。

    例: 正規表現[^@]+(?=@example\.com)を使用すると、joesmith@example.comが****@example.comになります。

同じ表や列に複数のポリシーをスタックできますか。優先順位はどのようになりますか。

いいえ。同じ表や同じ列に複数のポリシーは適用できません。表や列ごとに定義できるポリシーは1つのみであるため、複数のポリシー間に優先順位は適用されません。

SELECT … FOR UPDATE、RETURNING INTOおよびDMLトリガーではどのように動しますか。

  • SELECT … FOR UPDATE: リダクションは通常どおり適用されます。行がロックされているときでもマスクされた値がユーザーに表示されます。基礎となるデータは変更されません。
  • RETURNING INTO: 値がクライアントに返される前にリダクションが適用されます。この句を介して、リダクションされていないデータがユーザーに表示されることはありません。
  • DMLトリガー: リダクションは問合せ結果の配信時にのみ行われるため、データベース内で実行されるトリガーは、(リダクションされていない)実データにアクセスできます。

サマリー: 内部PL/SQLやデータベース側のロジックではなく、問合せの出力がリダクションで保護されます。

リダクションされた値は、ORDER BY、GROUP BY、DISTINCTや関数ベースの索引に影響しますか。

いいえ。リダクションは、SQL処理の後、データがクライアントに返される前に行われます。ソート、グループ化および個別操作では、すべて実際の(リダクションされていない)値が使用されます。関数ベースの索引および制約は、引き続き実際のデータに対して動作します。この動作は、Oracle AI Database 26aiで一貫して完全にサポートされています。

ノート:

データ・リダクションでは推論攻撃は考慮されておらず、ユーザーが順序付けパターンを推測できるために推論が懸念される場合は、他の制御(VPDなど)と一緒にリダクションを使用してください。

リダクションは、マテリアライズド・ビュー、リダクションされた表のビュー、および結果キャッシュとどのように相互作用しますか。

  • ビュー: Oracle AI Database 26aiの実表のリダクションされた列を参照するビューに、リダクション・ポリシーが透過的に適用されます。
  • マテリアライズド・ビュー: リダクションでは、格納されているデータは変更されません。ユーザーがマテリアライズド・ビューを問い合せるときにリダクションが適用されます。
  • 結果キャッシュ: キャッシュされた結果は、(SQLエンジンによって生成されたとおり)リダクションされていない形式で格納されます。ここでも、結果がエンド・ユーザーに配信されるときに、リダクションが適用されます。

リダクションは、データ・ポンプ、外部表、データベース・リンクまたはレプリケーション/CDCストリームに適用されますか。

  • データ・ポンプ: リダクションは適用されません。エクスポート/インポート・ユーティリティが物理データを直接読み取ります。
  • 外部表: リダクションは、データベース内でSQLを介して問い合せた場合にのみ適用されます。外部ソース・ファイル自体には適用されません。
  • データベース・リンク: データがリモート・クライアントに送信される前に、ソース・データベースでリダクションが適用されます。
  • レプリケーションまたはチェンジ・データ・キャプチャ(CDC): 取得またはレプリケートされたデータはリダクションで変更されません。問合せ出力にのみリダクションが影響します。

つまりリダクションは、データの移動や抽出のユーティリティではなく、実行時の問合せ結果を保護します。

リダクションが適用された場合、どのように監査しますか(リダクションされた内容が表示されたユーザーと元の内容が表示されたユーザー)。

  • 統合監査: データ・リダクションによって保護されたオブジェクトの監査を有効にします。UNIFIED_AUDIT_TRAILのエントリを確認して、リダクションされた表またはビューを問い合せたユーザーをタイムスタンプおよび接続の詳細とともに特定します。
  • 権限監査: EXEMPT REDACTION POLICYの使用または付与を監査します。この権限を持つユーザーは、リダクションされていないデータを表示できます。その使用状況を追跡することで、リダクションがバイパスされたタイミングを可視化できます。
  • ファイングレイン監査(FGA): (たとえば、ユーザー、ロールまたはSYS_CONTEXTを介したアプリケーション・コンテキストに基づいて)リダクション条件がtrueになるたびに問合せアクティビティを記録するには、その同じオブジェクトにFGAポリシーを追加します。これにより、リダクションに適格なアクセスの明示的なレコードが得られます。

ヒント:

CLIENT_IDENTIFIER、アプリケーション・モジュール、IPアドレスなどの重要なセッション属性を監査レコードに含めてください。これらは、リダクションされたセッション(EXEMPT REDACTION POLICYなし、述語= true)とリダクションされていないセッション(除外権限または述語= false)を区別するのに役立ちます。

どのようにすれば、ポリシー作成者と使用者の最小権限および職務分離が有効であることがわかりますか。

ロールの分離:

  • ポリシー管理者: ポリシーを作成/変更するための最小限の権限(DBMS_REDACTのEXECUTEおよび必要なオブジェクト権限を付与)、EXEMPT REDACTION POLICYなし。
  • DBA/オペレータ: 操作権限、ポリシーの変更不可。
  • 監査者: 監査ビューへの読取り専用アクセス、ポリシー/EXEMPT権限なし。
  • Database Vault (推奨): Oracle Database Vaultのレルムを使用して、強力なユーザーであっても、リダクション・ポリシーや保護されたオブジェクトの変更を禁止。

ポリシーとプライバシ・フレームワーク(PII/PHI、GDPR、PCIなど)をどのように整合させますか。

データ最小化(GDPR/CCPA/HIPAA): リダクションでは、権限のないユーザーに、マスクされた値のみを返すことで、知る必要がある情報のみが表示されます。

  • PCI DSS: 完全リダクションや部分リダクションを使用して、ほとんどのロールでクレジット・カード番号を読み取れないように(例: 下4桁のみを表示)し、明示的に認可されたユーザーのみが完全に表示できるようにします。
  • HIPAA (必要最小限): コンテキスト依存ポリシー(ロール/アプリケーション/時間/IP)を適用して、要員メンバーに必要なもののみが表示されるようにします。

ノート:

リダクションは、データ・イン・ユースの制御です。完全にカバーするには、データ・アット・レストの制御(TDE)、行レベルの制御(VPD/OLS)、および非本番マスキング(Oracle Data Safe)と組み合せてください。制御はコンプライアンス・チームと常に検証してください。

リダクションしてもデータ公開が発生する一般的な構成ミスは何ですか。

  • 過剰な権限を持つユーザー: EXEMPT REDACTION POLICYを広く(または、多くのユーザーに直接または間接的に付与されるロールを介して)付与。
  • 狭い/正しくない述語: 特定のパスが欠落(たとえば、MODULE/CLIENT_IDENTIFIER、IP範囲または接続プール・パターンが欠落)したポリシー条件。
  • 必要を超えた部分的開示: 必要を超えた数字/文字の表示(推論が可能)。
  • 対象外のデータ・パス: マテリアライズド・ビュー、アドホック・レポート・スキーマ、関数列または新規追加列の入れ忘れ。
  • データ移動のギャップ: リダクションが適用されないのに、データ・ポンプ、GoldenGate/CDC、または保存されたDBリンク・データにリダクションが適用されると思い込む。
  • 正規表現のギャップ: 正規表現リダクションのパターンが不完全なため、別の形式が含まれていない。
  • キャッシュ/抽出、変換、ロード(ETL)のリーク: リダクションされていない結果が格納された、アプリケーション/結果キャッシュまたはETLジョブ。
  • アプリケーションUIでのテストのみ: 直接SQLツール(SQL*Plus/SQLcl/SQL Developer)や読取り専用レポート・アカウントでテストしていない。

Oracle AI Database 26aiのデータ・リダクションの新機能または変更点(API、デフォルト、サポートされているタイプ、動作)は何ですか。

  • より広範なSQLカバレッジ: Oracle AI Database 26aiで、以前の制限が解除されたため、リダクションされた列を、SQL式、設定操作およびビューの問合せ(GROUP BY、DISTINCT、UNIONなど)で安全に使用できるようになりました。
  • 正規表現オプションの拡張: 正規表現のリダクションに、DBMS_REDACT.REGEXPまたはDBMS_REDACT.REGEXP_WIDTHを使用できます。クライアント・ドライバが文字幅セマンティクスに依存する場合は、REGEXP_WIDTHを選択してください。
  • パフォーマンスの向上: 内部最適化により、大規模なパラレル問合せおよび混合ワークロードでのリダクションの実行時オーバーヘッドが削減されています。

データ・リダクションはJSONリレーショナル二面性ビューとシームレスに連携しますか。リレーショナル表、二面性ビューまたはその両方にポリシーを定義できますか。

はい。リダクションは問合せの戻り時に適用されるため、二面性ビューは通常のビューと同様に動作します。

  1. 基礎となるリレーショナル列にリダクション・ポリシーを定義してください。それらのルールは、二面性ビューを介して自動的に伝播されます。
  2. マスキングも必要な導出列または計算列がビューに導入される場合にのみ、ビュー・レベルのポリシーを追加してください。

Oracle AI Database 26aiでのJSON列(LONGBLOB/CLOB JSON、検索索引)またはJSONパスをターゲットにしたリダクションの関する考慮事項はありますか。

  • JSONデータのターゲット指定: 正規表現ベースのリダクションを使用して、電子メール・アドレスやID番号などのJSONテキスト内のパターンをマスクします。
  • 検索と索引付け: JSON検索索引は実データに対して動作します。リダクションは、問合せ結果が返された場合にのみ実行されます。

Oracle Data RedactionおよびJSON

ヒント:

JSONがLOBまたは文字の列として格納されている場合、正規表現リダクションは適切に機能します。投影されるJSON属性の場合は、基礎となる列にリダクションを適用するか、ビュー・レベルのルールを作成してください。

Oracle AI Database 26aiで導入された新規/拡張データ型のリダクションに関するガイドラインはありますか。

  • リダクションは列レベルで適用され、問合せの戻り時にのみ適用されます。
  • 文字以外のサポート対象のデータ型(空間など)については、FULLまたはNULLIFYリダクションを使用してください。
  • 正規表現および部分のリダクションは、文字データまたはテキスト・データにのみ適用されます。
  • ベクトル・データ型のリダクションは現在サポートされていません。

Oracle AI Database 26aiマルチテナントのみの世界では、CDB/PDBにまたがるポリシー(共通ユーザーとローカル・ユーザー、デプロイメント・パイプライン)をどのように管理すればよいですか。

  • そのコンテナ内のスキーマおよびオブジェクトにポリシーの範囲が限定されるため、各PDB内にデータ・リダクション・ポリシーを定義してください。
  • 共通ユーザーおよびロールは、集中管理にのみ使用します。
  • DBMS_REDACTスクリプトをCI/CDパイプラインに格納し、PDBまたはアプリケーション・コンテナごとに適用します。
  • シードPDBにベースラインのリダクション・ポリシーを含めれば、デプロイメントの一貫性を確保できます。

オプティマイザ、結果キャッシュまたは問合せリライトに対するOracle AI Database 26aiの変更は、リダクションされた列(プラン、グループ化、ソート)に影響しますか。

いいえ。オプティマイザ、グループ化およびソートのロジックは、引き続き(リダクションされていない)実データで動作します。リダクションは、SQL処理の後、結果がクライアントに返される前に適用されます。Oracle AI Database 26aiでは、問合せリライト、リダクションされた列での設定操作および式の評価が一貫して動作することが保証されています。

既存のリダクション・ポリシーを以前のバージョンからOracle AI Database 26aiにアップグレードする際に、推奨される移行チェックリストを教えてください。

  • DBA_REDACT_POLICIESおよびDBA_REDACT_COLUMNSを使用して、既存のポリシーのインベントリを作成します。
  • 正規表現のポリシーの再検証: クライアントの互換性のために必要な場合は、REGEXP_WIDTHに切り替えます。
  • ビューおよび二面性ビューをチェックして、ベース表のカバレッジを確認します。必要に応じて、ビュー・レベルのルールを追加します。
  • リダクションされた列が関係するグループ化、DISTINCTまたはUNIONを使用して、問合せのパフォーマンスをテストします。
  • 権限の監査: EXEMPT REDACTION POLICYの付与をレビューし、監査設定を確認します。
  • お客様のマルチテナント・モデルにあわせてスクリプト化されたロールアウト・パイプラインを使用して、PDBごとにデプロイします。

Oracle Data Redactionによってどのようにセキュリティとコンプライアンスが改善されますか?

Oracle Data Redactionにより、機密データがリアルタイムで動的にマスキングされることでセキュリティが向上し、権限のないユーザーがデータベースにアクセス可能な場合であっても重要な情報は参照できなくなります。これにより、ユーザー・ロールと条件に基づいてきめ細かいアクセス制御が可能になり、格納されているデータを変更することなくデータ漏洩や内部脅威を減らすことができます。コンプライアンスの面では、EXEMPT REDACTION POLICY権限を監査すること、および特定のデータ保護要件を満たすリダクション・ポリシーを柔軟に定義することができるため、組織がGDPR、HIPAA、PCI DSSなどの規制に準拠するために役立ちます。これを使用するとコンプライアンス違反のリスクを軽減できるため、組織が罰金を逃れ法的基準を維持するために役立ちます。