管理に関するよくある質問

Oracle Data Redactionはどのようにインストールしますか?

Oracle Data Redactionは、Oracle AI Databaseのカーネルに組み込まれています。アプリケーションの変更も、構成や管理が必要な仲介サービスもありません。データ・リダクション・ポリシーを作成し、データをリダクションする必要がある表内またはビュー内の列にそれらを適用できます。

関係するロールや権限(ポリシーを作成できるユーザーや、除外できるユーザーなど)は何ですか。

Oracle Data Redactionを管理および保護するために、いくつかの権限および構成を適用してください:

必要な権限: リダクション・ポリシーを作成、変更または削除するには、次の権限が必要です:
- データベース・レベル、または特定のスキーマにスコープが設定されたADMINISTER REDACTION POLICY権限。これにより、リダクション・ポリシーを作成、変更および削除できます。
  例: GRANT ADMINISTER REDACTION POLICY ON SCHEMA u1 TO <grantee>;)
- DBMS_REDACTパッケージに対するEXECUTE権限(データ・リダクションの管理APIを起動するために必要)
これらは、信頼できる管理者にのみ付与する必要があります。SYSユーザーおよび、デフォルトではSYSTEMユーザーに、EXEMPT REDACTION POLICY権限があり、クリティカルなデータベース操作にのみ使用する必要があります。
除外:
- ポリシーに関係なく、EXEMPT REDACTION POLICY権限を持つユーザー(SYSおよびSYSTEMを含む)には、常にリダクションされていないデータが表示されます。
- この権限は厳しく制限する必要があり、その付与および使用状況を監視する必要があります。
- 統合監査を使用して、リダクションされたオブジェクトへのアクセス、およびEXEMPT REDACTION POLICY権限の付与や使用を追跡してください。
管理者の制限:
- 機密性の高い権限(EXEMPT REDACTION POLICY、DBMS_REDACTに対するEXECUTE)を持つユーザーの数を最小限に抑えます。
- Oracle Database Vaultのレルムまたはコマンド・ルールを使用して、機密性の高いデータおよびオブジェクトを管理者から保護します。
監査とアカウンタビリティ:
- ポリシー除外表とポリシー保護表の両方で監査証跡を有効にします。
- リダクション・ポリシー定義の変更およびアクセス権を監査します。

権限管理、除外制限、堅牢な監査および職務の分離を組み合せることで、企業のロールとコンプライアンスの標準にOracle Data Redactionポリシーを安全な方法で適合できます。

管理者によるデータ・リダクション・ポリシーの無効化、変更またはバイパスを止めるにはどうすればよいですか?

最も簡単な方法は、DBMS_REDACT PL/SQLパッケージに対するEXECUTE権限、またはEXEMPT REDACTION POLICY権限があるユーザーの数を制限することです。ユーザーSYSおよびSYSTEMは自動的にEXEMPT REDACTION POLICYシステム権限を付与されています。SYSTEMには、EXEMPT REDACTION POLICYシステム権限を含むEXP_FULL_DATABASEロールが付与されています。どちらのアカウントも、Oracle AI Databaseのインストール、パッチ適用、アップグレードなどの重要なデータベース操作の場合にのみ使用する必要があります。

管理者によるデータ・リダクション・ポリシーの無効化、変更またはバイパスを制限するためのより堅牢な方法は、Oracle Database Vaultを使用することです。Oracle Database Vaultでは、レルムやコマンド・ルールによって、特権ユーザーからオブジェクトおよびそれらに関連するデータ・リダクション・ポリシーを保護できます。また、Database Vaultは、Oracle AI Databaseカーネルに自動的にインストールされ、別のライセンスによって使用できます。

また、リダクションされたオブジェクトへのアクセス、およびEXEMPT REDACTION POLICY権限の使用を、統合監査で監査して、リダクションされたデータを表示したユーザー、場所およびタイミングを取得することもできます。

ベスト・プラクティス: 信頼できる管理者のみに除外を付与し、アカウンタビリティに対する監査を常に有効にしてください。

Oracle Data Redactionの構成と管理はどのくらい複雑ですか?

Oracle Data Redactionは、構成や管理が容易です。データベース管理者または開発者がOracle Data Redactionポリシーを管理し、必要に応じてそれらを有効または無効にできます。

Oracle Data RedactionによってOracle DBAタスクにどのような変更点がありますか?

ほとんどのDBAタスクは、Oracle Data Redactionによって変わることはありません。ユーザーは、EXEMPT REDACTION POLICYシステム権限またはスキーマ権限を付与されていなければ、選択される列(ソース列)のいずれかがデータ・リダクション・ポリシーで保護されている場合はCREATE TABLE AS SELECTを実行できません(同様に、ソース列がリダクションされる列である場合のINSERT-SELECT、UPDATE、MERGEまたはDELETE文などのDML操作も実行できません)。

Oracle Data Redactionを使用したデータベースにはどのようなパフォーマンス・オーバーヘッドがありますか?

Oracle Data RedactionはOracle AI Databaseのカーネルに組み込まれており、内部キャッシュおよび最適化手法を利用しているため、パフォーマンスへの潜在的影響が最小限に抑えられています。必ずtrueに評価されるポリシー式(1=1など)を使用すると、データベースでその式を評価する必要がないため、パフォーマンスの向上に役立つ可能性があります。

Oracleでデータ・リダクション・ポリシーを作成するにはどうすればよいですか?

DBMS_REDACT PL/SQLパッケージを使用してデータ・リダクション・ポリシーを作成し、ポリシー式パラメータによってリダクションの発生タイミングを指定できます。

次に、そのデータ・リダクション・ポリシーを特定の列に適用し、実行するデータ・リダクションのタイプを決定します。

ユーザー/ロール/アプリケーション・コンテキスト(IP、サブネット、アプリケーションID、時間ウィンドウ)によって、ポリシーをターゲット設定できますか。

はい。Oracle Data Redactionのポリシーは条件付きにできます。つまり、特定の基準が満たされている場合にのみ適用できます。リダクションが有効になるタイミングと対象を決定するポリシー式を定義できます。

サポートされている条件は次のとおりです:

データベース・ユーザーまたはロール: 特定のユーザーまたはロールに対してのみリダクションを適用します(たとえば、AUDITOR: SYS_CONTEXT('USERENV', 'SESSION_USER') != AUDITORを除くすべてのユーザーに対するリダクション・ポリシーなど)。
SYSDBAやDBAなどの一部の管理ユーザーは、EXEMPT REDACTION POLICY権限があり、リダクション・ポリシーから除外されます。
クライアントIPアドレスまたはサブネット: 接続クライアントのIP範囲に基づいてリダクションを制限します(たとえば、外部接続の場合にのみデータをマスクします)。
クライアント・アプリケーション: CLIENT_IDENTIFIER、MODULEまたはACTIONコンテキスト値を使用して、特定のアプリケーションにポリシーをターゲット設定します(たとえば、データがレポート・ツールを介してアクセスされるが、内部スクリプトを介していない場合にリダクションを適用します)。
時間ベースの条件: リダクションがいつアクティブになるかを制御します(営業時間中やメンテナンス・ウィンドウ中など)。
カスタム・セッション・コンテキスト: カスタム属性(SYS_CONTEXT('USERENV','APP_USER_TYPE')など)を参照して、アプリケーション・ロジックを統合します。

ユース・ケースの例:

AUDITORおよびDATA_ANALYSTを除くすべてのロールの顧客SSNをリダクションします。
コーポレート・ネットワークのIP範囲外でアクセスした場合に、クレジット・カード番号をリダクションします。
内部ダッシュボードではなく、モバイル・アプリケーションから表示されたデータにマスキング・ルールを適用します。
営業時間後の運用セキュリティにのみリダクションを有効にします。

このような柔軟性により、コンテキストを意識したきめ細かいポリシーを実装して、セキュリティとユーザビリティのバランスを取り、誰が、どのように、いつデータにアクセスするかに基づいて、機密性の高いデータを動的に保護できます。

Oracle Data Redactionは他のOracleセキュリティ機能とどのように統合されますか?

Oracle Data Redactionは、他のOracle AI Databaseセキュリティ機能を補完する機能です。Oracle Transparent Data Encryptionでは、データファイル内、およびOracle DataPumpエクスポートとOracle RMANバックアップにあるデータが保護されます。Oracle Database Vaultでは、権限およびオブジェクトが保護されますが、列レベルの保護やリダクション・ポリシーはサポーされていません。Oracle Data Masking and Subsettingは、本番でないシステムで使用するためにあり、データを変更して、その元の値を識別できないようにします。Oracle Label Securityでは、行レベルの制御が提供されますが、列レベルの制御は提供されません。Oracle Virtual Private Databaseでは、列レベルの制御と行レベルの制御が両方提供されますが、認可されていない列にある値をNULLとして表示することのみがサポートされています。VPDでは、実際の値の一部を表示することや、実際の値に対する正規表現の結果を表示することはサポートされていません。Oracle AI Databaseセキュリティ・ポートフォリオにある各機能またはオプションにより、データに対するリスクを最小限に抑えるための制御が実現されています。複数の機能/オプションを使用することになり、それらには重複する機能があることもあります。それにより、ユースケースに応じて適切な機能を選択できます。

Oracle Data Redactionをビューおよびマテリアライズド・ビューに適用できますか?

はい。Oracle Data Redactionは、表、ビューおよびマテリアライズド・ビューに適用できます。

Oracle Data Redactionのパフォーマンスはどのように監視しますか?

パフォーマンスは、AWR (自動ワークロード・リポジトリ)とADDM (自動データベース診断モニター)などのオラクル社のパフォーマンス監視ツールを使用して監視できます。

自社開発のアプリケーションとともにOracle Data Redactionを使用できますか?

はい。お客様の自社開発のアプリケーションとともにOracle Data Redactionを使用できます。ただし、リダクションされた値をデータベースに書き戻さないように注意する必要があります。Oracleでは、データがリダクションされたかどうかがわからないため、ライトバック・データは実データとして扱われます。

データ・リダクションの実行時のオーバーヘッドはどれくらいですか。大規模または複雑な問合せを計画するためのヒントはありますか。

データ・リダクションは、SQL実行後、クライアントに結果が返される前に動作するため、実行時のオーバーヘッドは最小限に抑えられます。

ほとんどのワークロードでは、大規模なデータ・セットの場合でも、その影響はほとんどありません。
オーバーヘッドは、主にリダクションされた列の数と式の複雑さによって異なります(たとえば、正規表現リダクションは完全/部分リダクションより高負荷になります)。

計画のヒント:

機密性の高い列およびアクティブなユーザー・パスにのみリダクションを適用します。
頻繁に問い合せる列に対しては、単純なリダクション・タイプ(全体または部分)をできるだけ使用します。
多数の行を返す高スループットの問合せのパフォーマンスをテストします。
Oracle AI Database 26aiには、大規模なパラレル問合せのリダクション・オーバーヘッドをさらに削減する内部最適化が含まれています。

リダクションされた列での索引付け、統計およびバインド・ピーキングのベスト・プラクティスはありますか。

はい。リダクションはSQL処理後に行われるため、オプティマイザの動作には影響しません:

索引および統計は実データに基づいて作成されるため、問合せ計画の正確さは変わりません。
バインド・ピーキングではリダクションされていない値が使用されるため、実行計画がマスキングによって歪められることはありません。

ベスト・プラクティス:

通常の索引付けおよび統計のルーチンを維持してください。特別な処理は必要ありません。
推論リスクを低減するために、エンド・ユーザーに表示される述語に、リダクションされた列を含めないでください。
ファンクションベース索引を使用する際には、リダクションは出力にのみ影響し、索引の評価には影響しないことに注意してください。

ポリシーを安全にテスト(ステージング、カナリア・ユーザー、セッション・レベルの切替えなど)するにはどうすればいいですか。

リダクション・ポリシーは、実際のデータを公開せずに安全にテストできます:

ステージング環境または非本番環境で、代表的なデータを使用します。
特定のテスト・ユーザーまたはロール(カナリア・ユーザー)にのみ適用される条件付きポリシーを定義します。
SYS_CONTEXT('USERENV','SESSION_USER')などのセッション・コンテキスト・トグルやカスタム・フラグを使用して、リダクションを動的に有効または無効にします。
グローバルにロールアウトする前に、制御されたテスト・アカウントを使用して出力を確認します。

ヒント:

ログおよび監査証跡を常に確認して、リダクションのカバレッジおよびルールの起動が期待どおりであることを確認します。

ロールアウトおよびロールバックのポリシーを有効化/無効化またはバージョン管理するにはどうすればよいですか。

リダクション・ポリシーは、DBMS_REDACTを使用して動的に管理できます:

ポリシーを削除せずにポリシーの実施を切り替えるには、DBMS_REDACT.ENABLE_POLICYまたはDISABLE_POLICYを使用します。
既存の定義を変更するには、DBMS_REDACT.ALTER_POLICYを使用します。
ロールバック用のデプロイメント・スクリプトで、バージョン管理されたポリシー定義のコピー(「v1」、「v2」など)をメンテナンスします。

ベスト・プラクティス: 限定されたスコープで新しいポリシーをテストし、検証後にグローバルに有効化します。

ロールアウト時には、何(上位SQL、計画変更、ポリシー・ヒット数など)を監視する必要がありますか。

デプロイメント中およびデプロイメント後のパフォーマンスとカバレッジの両方を監視します:

パフォーマンス: 自動ワークロード・リポジトリ(AWR)またはSQLモニターを使用して、上位SQLおよび実行計画を追跡します。
ポリシー・アクティビティ: DBA_REDACT_POLICIESおよびDBA_REDACT_COLUMNSを使用して、アクティブなルールを確認します。
ヒット数およびユーザー・アクティビティ: 統合監査を使用して、リダクションされた問合せおよびアクセス・パターンを監査します。
計画変更: ポリシー・ロールアウトの前後で実行計画を比較して、リグレッションを検出します。

ヒント:

ロールアウト後に短期の監視ウィンドウを設けて、異常を検出し、予想された問合せのレイテンシおよびポリシー施行の動作を検証します。

7.2 管理に関するよくある質問