Oracle Database 23aiのOracle Data Redactionでデータを保護 (2024/10/15)

https://blogs.oracle.com/database/post/introducing-data-redaction

投稿者：Richard Evans

今日のデータドリブンの世界では、オンライン・トランザクション処理(OLTP)システムやデータウェアハウスから分析やAIモデルに至るまで、さまざまなアプリケーションを使用することが多く、これらはすべて同じ基礎となるデータにアクセスする可能性があります。これらの多様な環境におけるデータ・プライバシとセキュリティの保護は、特に機密情報にアクセスしているユーザー(使用中のアプリケーション、分析ツールまたは非定型問合せ)に応じて選択的にリダクションする必要がある場合に、困難になる可能性があります。

データ・リダクションが輝く場所です。これにより、様々なアプリケーション、分析ツールまたはアドホック問合せツールで共有機密データをどのように使用するかを制御する一元管理されたセキュリティ・ポリシーによって、列の結果をリダクション(実際のデータを変更せずに非表示)できます。Data Redactionのメリットについて説明します。

主なメリット:

1. 使いやすさ: データ・リダクションは簡単に実装でき、通常はアプリケーションを変更する必要はありません。データ・リダクション・ポリシーを作成すると、すべての問合せにシームレスに適用され、すべてのデータ・コンシューマに一貫性のあるセキュリティが提供されます。
2. アプリケーションの独立性: アプリケーションごとに個別のセキュリティ・ポリシーを作成する必要はありません。データ・リダクション・ポリシーは、データベース内で直接管理および適用されるため、多様な環境にわたるセキュリティ管理が簡素化されます。
3. データ・レイヤー・アプリケーション: リダクションはデータ・レイヤーで実行されるため、データを使用するすべてのアプリケーション、ツール、レポートおよびモデルを対象とします。リダクション・ポリシーは、新しいデータが保護された列に挿入されると自動的に適用され、データの増加に伴ってこのソリューションをスケーラブルにします。
4. 動的リダクション: データ・リダクションは、動的で、ポリシーで定義された式に基づくことができます。たとえば、ユーザー名、ユーザー・ロール、特定のアプリケーションまたはIPアドレスに基づいて情報をリダクションするポリシーを作成し、様々なユースケースをサポートし、適切な条件下でのみ実際のデータが完全に表示されるようにすることができます。
5. 移植性: データ・ポリシーとリダクション・ポリシーの両方が、異なる環境間でトランスポータブルです。これにより、よりスムーズな移行、開発およびテスト・サイクルが可能になり、データ保護ルールの一貫性が保たれます。

データ・リダクションのユースケース

規制、業界、組織のセキュリティ目標への準拠

過去10年間に、個人を特定できる情報へのアクセスを制限する大きなプッシュがありました。残念ながら、すべてのソフトウェアがエンドユーザーとの共有からこのデータを簡単に制限できるわけではありません。データ・リダクションは、ここで役立ちます。レポート、問合せまたはツールを変更してデータをリダクションするかわりに、データに対してデータ・リダクション・ポリシーを実装できるため、実際のデータはレポート、問合せまたはツールに戻されません。

たとえば、EMPLOYEES表には、HIRE_DATE、BIRTH_DATE、GENDER、STREET、CITY、STATE、ZIP_CODE、BASE_SALARYなど、いくつかの機密列があります。次のようなポリシーを作成できます。

• アプリケーション・ユーザーおよびアプリケーション・ロールは、HIRE_DATE列、STREET列、CITY列、STATE列およびZIP_CODE列の実際のデータを表示できます。
• BIRTH_DATE、GENDERおよびBASE_SALARY列のデータを表示できるのは、アプリケーション・ユーザーのみです。
• 通常のユーザーは、前述の列データにアクセスできません。

集約、分析、AI環境でデータをリダクション

分析やAIを扱うとき、データは複雑なクエリや関数を通じて集計または処理されます。データ・リダクションを使用すると、集計関数または分析関数でデータが使用されている場合でも機密列をリダクションできるため、分析中のエクスポージャのリスクが軽減されます。データ・リダクションは、異なるアプリケーションやレポート・ツールでデータが使用されている場合に、不正なデータ拡散を防止するのに役立ちます。

たとえば、財務アナリストは、今後12か月以内に与信使用量を予測したいと考えています。次のような列にデータを含めることができます。

CREDIT_SCORE、CREDIT_USAGE、LAST_USAGE、SSN、GENDER、POSTAL_CODEおよびADDRESS。SSN、GENDERおよびADDRESS列はモデルとは無関係であるため、リダクションする必要がある場合があります。データ・リダクション・ポリシーを作成して、モデルのトレーニング時にこれらの列が使用されないようにできます。

データ主権とコンプライアンスのサポート

データ・リダクションは、データ主権イニシアチブのサポートにおいて重要な役割を果たすことができます。CUSTOMER表にデータ・リダクション・ポリシーを作成して、承認されたネットワーク、ホスト、IPアドレスまたはその他の識別コンテキスト外のクライアントからアクセスした場合にデータをリダクションできます。

データ・リダクション・ポリシーを設計する際、式では、Oracle Databaseがセッションについて認識しているコンテキスト情報を使用できます。たとえば、この名前付きポリシー式では、リストされている承認済の本番HRアプリケーション・サーバーの1つでないかぎり、すべてのホストでリダクション済データを表示できます。次に、この名前付きポリシー式をCUSTOMERS表の列またはホストによる同じ制限を強制する他の表に適用できます。

データ・リダクションを使用すると、ポリシーおよび名前付き列式を作成して、機密データをリダクションされていない形式で提供する場所と方法を制御できます。

データ・アクセスのパフォーマンス最適化

ワークロードごとに、データ索引付け、統計収集およびデータ・リダクションのポリシー式に対する様々な戦略が求められます。

たとえば、サポートしているアプリケーションは、常にLAST_NAME列を大文字で検索します。問合せのパフォーマンスを向上させるには、ファンクション索引を適用して、索引内で列を大文字に変換します(UPPER(last_name)など)。

拡張統計を使用して、列間の相関を作成できます。たとえば、頻繁にアクセスされるCITYやZIP_CODEなどの列がある場合、それらの列について収集される統計は、独立してではなく、ペアとして最適化することが理にかなっています。

特定の列を、すべての非管理ユーザーに対して常にリダクションするとします。その場合、問合せ元のユーザーがリダクション・ポリシーから免除されないかぎり、通常は'1=1'のポリシー式関数を使用します。この関数は常にTRUEと評価されます。この条件を使用すると、ポリシー式を評価する必要がなくなるため、リダクションされた列からのフェッチ操作中のCPU時間が節約されます。

まとめ

Oracle Data Redactionは、Oracle Database 23aiの多くの機能の1つで、堅牢で柔軟かつセキュアなデータベース・ソリューションの提供に対するオラクルの取り組みを示しています。データ・リダクションを使用すると、Oracle Databaseのパワーを最大限に活用しながら、機密情報をより効果的に保護できます。