※ 本記事は、Richard Evansによる”Protect your data with Oracle Data Redaction in Oracle Database 23ai“を翻訳したものです。
2024年11月29日
今日のデータドリブンの世界では、オンライン・トランザクション処理(OLTP)システムやデータ・ウェアハウスから分析やAIモデルに至るまでさまざまなアプリケーションを使用することが多く、これらはすべて業務基盤となる同じデータにアクセスする可能性があります。これらの多様な環境におけるデータ・プライバシとセキュリティの保護は、特に機密情報にアクセスしているユーザー(使用中のアプリケーション、分析ツールまたはアドホック問合せ)に応じて選択的にデータをマスクする必要がある場合に、困難になる可能性があります。
Data Redactionが注目されるのはここです。これにより、様々なアプリケーション、分析ツールまたはアドホック問合せツールで共有機密データをどのように使用するかを制御する一元管理されたセキュリティ・ポリシーによって、列の結果をリダクション(実際のデータを変更せずに非表示)できます。Data Redactionの利点について説明します。
主な利点:
- 使いやすさ: Data Redactionは簡単に実装でき、通常はアプリケーションを変更する必要はありません。データのリダクション・ポリシーを作成すると、すべての問合せにシームレスに適用され、すべてのデータ・コンシューマに一貫性のあるセキュリティが提供されます。
- アプリケーションの独立性: アプリケーションごとに個別のセキュリティ・ポリシーを作成する必要はありません。リダクション・ポリシーは、データベース内で直接管理および適用されるため、多様な環境にわたるセキュリティ管理が簡素化されます。
- データ・レイヤー・アプリケーション: リダクションはデータ・レイヤーで発生するため、データを使用するすべてのアプリケーション、ツール、レポートおよびモデルを対象とします。リダクション・ポリシーは、新しいデータが保護された列に挿入されると自動的に適用され、データが増加してもスケーラブルに対応します。
- 動的リダクション: Data Redactionは、動的で、ポリシーで事前定義された式に基づき適用できます。たとえば、ユーザー名、ユーザー・ロール、特定のアプリケーションまたはIPアドレスに基づいて情報をリダクションするポリシーを作成し、様々なユース・ケースをサポートし、適切な条件下でのみ実際のデータが完全に表示されるようにすることができます。
- 移植性: データ・ポリシーとリダクション・ポリシーはどちらも、異なる環境間でトランスポータブルです。これにより、よりスムーズな移行、開発およびテスト・サイクルが可能になり、データ保護ルールの一貫性が保たれます。
Data Redactionのユース・ケース
規制、業界、組織のセキュリティ目標への準拠
過去10年間に、個人を特定できる情報へのアクセスを制限しようとする動きが顕著でした。残念ながら、すべてのソフトウェアがエンド・ユーザーとの共有からこのデータを簡単に制限できるわけではありません。Data Redactionは、ここで役立ちます。レポート、問合せまたはツール側でデータをリダクションするかわりに、データ側でData Redactionポリシーを実装できるため、実際のデータはレポート、問合せまたはツールに戻されません。
たとえば、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を扱うとき、データは複雑なクエリや関数を通じて集計または処理されます。Data Redactionを使用すると、集計関数または分析関数でデータが使用されている場合でも機密列をリダクションできるため、分析中の露出のリスクが軽減されます。Data Redactionは、異なるアプリケーションやレポート・ツールでデータが使用されている場合に、不正なデータが拡散するのを防ぐのに役立ちます。
たとえば、財務アナリストは、今後12か月以内に与信使用量を予測したいと考えています。次のような列にデータを含めることができます。
CREDIT_SCORE、CREDIT_USAGE、LAST_USAGE、SSN、GENDER、POSTAL_CODE、and ADDRESSです。ここでSSN、GENDERおよびADDRESS列はモデルとは無関係であるため、リダクションすることになるでしょう。Data Redactionポリシーを作成して、モデルのトレーニング時にこれらの列が使用されないようにできます。
データ・ソブリンとコンプライアンスのサポート
Data Redactionは、データ・ソブリン・イニシアチブの実現に重要な役割を果たすことができます。CUSTOMER表にリダクション・ポリシーを作成して、承認されたネットワーク、ホスト、IPアドレスまたはその他の識別コンテキスト外のクライアントからアクセスした場合にデータをリダクションできます。
リダクション・ポリシーを設計する際、式では、Oracle Databaseのセッション・コンテキスト情報(ユーザー、アプリケーション、ホストなど)を使用できます。たとえば、ある名前付きポリシーでは、基本的にすべてのホストではマスク済みデータを表示できるようにし、リストされている承認済の本番HRアプリケーション・サーバーのみ、データを表示できます。そして、同じポリシーをCUSTOMERS表の列またはホストによる同じ制限を強制する他の表にも適用できます。
Data Redactionを使用すると、ポリシーおよび名前付き列式を作成して、機密データをリダクションせずに提供する場所と方法を限定できます。
データ・アクセスのパフォーマンス最適化
ワークロードごとに、データ索引付け、統計収集およびData Redactionのポリシー式に対する様々な戦略が求められます。
たとえば、あるアプリケーションが、常にLAST_NAME列を大文字で検索するとします。問合せのパフォーマンスを向上させるには、ファンクション索引を適用して、索引内で列を大文字に変換します(UPPER(last_name)など)。
拡張統計を使用して、列間の相関を作成できます。たとえば、頻繁にアクセスされるCITYやZIP_CODEなどの列がある場合、それらの列について収集される統計は、独立してではなく、ペアとして最適化することが理にかなっています。
管理者以外のすべてのユーザーに対して、特定の列を常にリダクションするとします。その場合、通常は’1=1’のポリシー式関数を使用します。この関数は問合せ元のユーザーがリダクション・ポリシーから免除されないかぎり、常にTRUEと評価されます。この条件を使用すると、ポリシー式を評価する必要がなくなるため、リダクションされた列からのフェッチ操作中のCPU時間を節約できます。
まとめ
Oracle Data Redactionは、Oracle Database 23aiの多くの機能の1つで、堅牢で柔軟かつセキュアなデータベース・ソリューションの提供に対するオラクルの取り組みを示しています。Data Redactionを使用すると、Oracle Databaseのパワーを最大限に活用しながら、機密情報をより効果的に保護できます。