※ 本記事は、Vikram Pesatiによる”Oracle Deep Data Security Expands Authorization Across Analytics, APEX, ORDS, and AI Agents“を翻訳したものです。

2026年11月4日

企業データへのアクセスは、もはや予測可能な限られたアプリケーションだけから行われるものではありません。分析プラットフォーム、REST API、クラウドサービス、AIエージェントが、機密情報にアクセスし操作する新しい経路を生み出し、多くの場合、高い権限のデータベース接続を使います。一方、認可の適用は、増え続けるアプリケーションに分散したままです。一貫したセキュリティポリシーの維持が難しくなり、過剰な権限や不正なデータ公開のリスクが高まります。AIエージェントはSQLを動的に生成でき、企業データに対するエンドユーザーの認可の適用を任せられないため、リスクがさらに高まります。

Oracle AI Database 26aiで導入されたOracle Deep Data Securityは、アプリケーションとAIエージェントに共通の認可モデルを提供し、データベースでエンドユーザーの認可を直接適用します。データ認可は、データグラントと呼ぶ宣言的なSQLポリシーで定義し、エンドユーザーの認可に基づいて一貫して適用します。アプリケーションやAIエージェントがユーザーに代わってアクセスする場合も、確立された認可コンテキストを使い、行、列、セルレベルの操作を制御します。

Oracle AI Database Release Update 23.26.4（DBRU 23.26.4）は、この認可機能を拡張し、より広い企業アプリケーション要件に対応します。データグラントフィルタは、ユーザーの業務範囲に基づいてアクセスをさらに制限します。SQLマクロは、認可述語を一度定義して複数のデータグラントで再利用でき、ポリシーの保守を簡素化します。Oracle Application Express（APEX）とOracle REST Data Services（ORDS）の連携を設定すると、エンドユーザーのIDと認可コンテキストを渡し、Deep Data Securityでデータ認可を適用できます。

Deep Data Securityによるアクセスの定義

基本的な構成要素は、データロールがアクセスできる行と列を定義するデータグラントです。データロールは、従業員、マネージャー、採用担当者などの責任に応じてエンドユーザーに割り当てます。

たとえば、あるデータグラントではマネージャーに自身の従業員レコード全体の閲覧を許可し、別のグラントでは直属メンバーの従業員レコードの一部へのアクセスを許可します。複数のグラントが該当すれば、それらが提供するアクセスの和集合が実質的なアクセス範囲となります。つまり、グラントは加算的です。

前回の更新では、このモデルを、対応するリモートデータソース、関連表、高度なSQL分析に拡張しました。今回のリリースでは、組み合わされた権限の制限、複雑な認可述語の再利用、追加のアプリケーションプラットフォームを通じた信頼できるIDの伝達が可能になります。

分析にきめ細かな制限型認可を適用する

分析アプリケーションには、データグラントに加えて制限フィルタが必要なことがよくあります。ダッシュボードやレポートツールを通じて、広範で多様なデータセットにアクセスするためです。ファクト表の特定の事実へのアクセスは、組織階層、地域、事業部門、部署、製品などのディメンション属性で制限します。高い権限を持つユーザーには全データセットを許可し、権限の低いユーザーは業務範囲に応じて制限します。

DBRU 23.26.4では、データグラントフィルタによるきめ細かな制限型認可を導入します。データグラントがアクセスを与え、データグラントフィルタがそれをさらに制限します。フィルタは追加のSQL述語を適用し、該当するすべてのデータグラントによって組み合わされたアクセスを制限します。ポリシー作成者は、既存のグラントで与えたアクセスをさらに制限するフィルタを追加できます。

人材管理（HCM）の採用シナリオを考えてみましょう。Recruiter（採用）ロールを持つ従業員は、すべての求人を閲覧できます。責任範囲（AOR）ロールが、事業部門、国、部署でアクセスをさらに制限します。AOR固有のロールを持つ採用担当者には、その制限を満たす求人だけを表示すべきです。

Deep Data Securityでは、Recruiterロールのデータグラントと、AOR固有のロールのデータグラントフィルタで、このアクセスを表現できます。データベースは、結果を返す前に両方を評価します。

したがって、このデータ認可で、採用担当者のアプリケーション、分析ダッシュボード、または本人に代わって求人データを取得するAIアシスタントを制御できます。

図1：データグラントがアクセスを与え、データグラントフィルタが追加のSQL述語で制限

Deep Data Securityの認可をAPEXとORDSに拡張する

Oracle APEXでは、開発者やAIエージェントがデータ駆動の企業アプリケーションを迅速に構築でき、ORDSはデータベースのデータとサービスをREST APIで公開します。APEX 26.1では、AIエージェントによるアプリケーション生成や、企業データとAI機能の統合も可能です。AIエージェントの組込みと、複数経路でのデータ公開が進むほど、一貫したエンドユーザー認可の維持が重要になります。ローコードアプリケーション、RESTサービス、AIエージェントのどれを通じてアクセスしても、同じデータベース認可ポリシーを適用する必要があります。

DBRU 23.26.4では、APEX 26.2とORDS 26.3.0を設定することで、データベースが暗号学的に検証できるOAuth 2.0トークンを使い、エンドユーザーのIDと認可コンテキストをOracle AI Databaseに伝達できます。コンテキストには、エンドユーザー、アプリケーションID、データロール、認可ポリシーが使うその他の属性を含められます。Deep Data Securityはこの信頼できるコンテキストにより、ローコードとRESTの両方の経路で、データベース内の認可を一貫して適用します。

OCI IAMやMicrosoft Entra IDなどのIDプロバイダー（IdP）でソーシャルサインインを使うAPEXアプリケーションは、IDコンテキストの暗号学的検証に対応するユーザートークンとアプリケーショントークンを通じて、ユーザーID、アプリケーションロール、関連する属性をデータベースに伝えられます。Deep Data Securityは、各SQL操作でこれらのトークンを使い、適用すべきデータグラントを評価します。各アプリケーションは、固有のアプリケーションIDとデータロールによって、データアクセスを分離できます。

ORDSは、Deep Data Securityによるデータ認可をRESTサービスに拡張します。開発者は既存のサービス構造を維持しながら、データベースで行、列、操作に対する認可を適用できます。アプリケーションIDで、RESTサービスやアプリケーションを区別することもできます。さらに、対応クライアントとエージェントフレームワーク向けに、管理されたModel Context Protocol（MCP）エンドポイントを公開でき、サインインしたユーザーの認可をデータベースのDeep Data Securityが適用します。

図2：ORDSがユーザーとアプリケーションのコンテキストを伝え、データベースがデータ認可を適用する

これらのアクセス経路では、ユーザーに代わるリクエストと、人のエンドユーザーがいないワークロードに共通のトークンモデルを使います。On-behalf-ofトークンはユーザーとアプリケーションのコンテキストを伝え、データベースアクセストークンは、サービス、定期ジョブ、自律エージェントのアプリケーションIDを確立します。

既存のOAuth 2.0 IDプロバイダーを接続する

企業アプリケーションは、すでにユーザー認証とアクセストークン取得をIDプロバイダーに依存しています。Deep Data Securityでは既存プロバイダーを使い続けながら、データ認可に必要なコンテキストをデータベースに渡せます。OAuth 2.0は共通の枠組みですが、エンドユーザー、アプリケーション、エージェントのIDやロール、その他の属性の表現に、プロバイダーごとに異なるトークンクレームを使う場合があります。

この違いに対し、Deep Data Securityはプロバイダー固有のクレームを、一貫したデータベース属性群にマッピングします。管理者が、トークン発行者、検証用公開鍵の場所、対象受信者（audience）、エンドユーザー、アプリケーション、エージェント、データロールを識別するクレームを設定します。アプリケーションは既存プロバイダーでIDとロールを管理し続け、データベースは結果のコンテキストを一貫して解釈します。

DBRU 23.26.4では、OCI IAMとMicrosoft Entra IDに加え、検証済みIDプロバイダーとしてKeycloakを追加します。同じクレームマッピングモデルで、検証の進展に合わせて、ほかのOAuth 2.0対応プロバイダーもサポートできます。

図3：トークンクレームを、エンドユーザーID、アプリケーションID、データロールにマッピングします。

再利用可能なSQLマクロで複雑なデータグラント述語を簡素化する

企業アプリケーションでは、同じ複雑な認可述語を複数のデータグラントとフィルタに適用することがよくあります。先ほどのHCM例では、採用担当者が閲覧できる求人を定める述語を、アプリケーション問合せ、分析ビュー、RESTサービスで使う場合があります。SQL文ごとに述語を繰り返すと、ポリシー変更の管理が難しくなり、適用が不一致になるリスクが高まります。

再利用可能なSQLマクロなら、複雑な認可述語を一度定義し、複数のデータグラントとフィルタで再利用できます。ポリシーが変わった際はマクロを中央で更新すれば、参照するすべてのグラントが改訂された述語を使います。述語の重複を減らし、アプリケーションの拡大に伴っても一貫した認可動作を保てます。

図4：再利用可能なSQLマクロが、認可述語を簡素化し、一元管理します。

統合監査で可視性を高める

データベースでエンドユーザー、エージェント、アプリケーションのコンテキストを利用できるため、Unified Auditは、適用される監査設定に基づき、監査対象SQL操作のアプリケーションID、データロール、エンドユーザーのコンテキストを記録できます。どの操作が、どのユーザーとアプリケーションによって、どのセキュリティコンテキストで実行されたかを把握できます。この追加情報は、運用上の問題解決、コンプライアンスレビュー、セキュリティ調査に役立ちます。

要点：分析、アプリケーション、AIに一貫したデータ認可を拡張する

DBRU 23.26.4により、分析アプリケーション、APEXやORDSなどのアプリケーションプラットフォーム、AIエージェント全体で、一貫したきめ細かなデータアクセスを適用しやすくなります。異なるアプリケーションを構築しながら、基になるデータに同じエンドユーザー基準の認可を使えます。

  • 分析アプリケーションの認可をデータベースで適用
    データグラントと制限型フィルタで、業務範囲の制限を伴う広範なデータアクセスを支え、再利用可能なSQLマクロでポリシー管理を簡素化します。
  • アプリケーションとAIのワークフローに一貫した認可を拡張
    APEX、ORDS、AIエージェント全体でDeep Data Securityを適用し、対応するアプリケーションとAIのアクセス経路で同じポリシーを一貫して適用します。
  • 検証済みのOAuth 2.0 IDプロバイダーを利用
    OAuth 2.0対応プロバイダーを統合し、豊富なユーザー、アプリケーション、セキュリティのコンテキストを取得して、データベースで直接エンドユーザーの認可に利用します。

Oracle Deep Data Securityを始める

次の資料が、Oracle Deep Data Securityを始める際に役立ちます。

すぐに試す

LiveLabs