従来のアプリケーションでは、共通のデータベース・アカウントで接続し、ログインした利用者に何を許可するかをアプリケーション側で判断する構成が広く使われています。
しかし、この構成ではDBから見ると「実際に誰の要求なのか」が分からない場合があります。
近年は、あらかじめ用意された画面や処理に加え、LLM または AI エージェントが利用者の依頼に応じて検索方法や実行するSQLを組み立てるようになりました。また、AI を使って作成したアプリケーションを業務に取り入れる場面も増えています。こうしたアクセス経路が加わると、既存のアプリケーションに実装した制御だけでは、利用者ごとのアクセス範囲を一貫して守ることが難しくなってきています。
前回までの記事では、データベース側でアクセスを制御する機能として、Virtual Private Database（VPD）を取り上げました。
今回は、Oracle AI Database 26aiの新しいセキュリティ機能である Oracle Deep Data Security（以下、Deep Sec） を紹介します。Deep Secは 2026年5月に提供開始が発表された Oracle Database がもつ最新のアクセス制御機能となっています。
この記事では Deep Data Security の概要を説明し、次回以降は実際に触ってみるためのハンズオンを紹介します。
0. はじめに
新しいモデルやアーキテクチャを取り入れる際、LLM の検索能力を生かすために、既存の業務データはそのままに検索や処理の組み立て方を作り変えることがあります。一方で AIモデルやアプリケーションの構成が変わっても、業務データに対するアクセス制御の要件は守り続ける必要があります。
たとえば、「顧客情報を担当者だけに参照させる」という要件は、利用するAIモデルや検索方法を変更しても変わりません。
変わるのはデータへのアクセス方法であり、「誰に、どのデータへの、どの操作を許すか」というルールは引き継ぐ必要があります。
このルールを個々のアプリケーションへ埋め込んでいると、構成を変更したり、アクセス経路を追加したりするたびに、同じ要件を実装して検証する作業が発生します。また、変更の頻度やアクセス経路が増えるほど、実装漏れや、アプリケーションごとの制御の不整合も生じやすくなります。
AIエージェントに対しても、指示やガードレールによって動作を制限できますが、エージェントが想定外のSQLを生成した場合にもアクセス範囲を守るには、そのSQLを実行するデータベース側で認可ルールを強制する仕組みがやはり確実です。
そこで、そのアクセス制御のルール自体を、変化が頻繁なアプリケーション基盤とは別に（変化が少ない）データ基盤側で設計し、アクセス制御自体をデータの管理基盤自体に組み込むことによって、アプリケーションの変更に合わせて、同じ制御をそれぞれ実装し直す負担も減らすことができます。
ただ、アプリケーションごとに接続用アカウントを分けても、その先にいる利用者を識別する課題は残ります。そのため、この設計のためには、実際に誰の権限でデータへアクセスするのかをデータベースが判断できる仕組みが必要となります。
従来のコネクション・プールを使うアプリケーションや AI エージェントでは、多数の利用者が同じデータベース・アカウントを共有することがあります。AIエージェントが利用者の代理でアクセスする場合も、接続に使うアカウントと、その処理を依頼した利用者は必ずしも一致しません。そのため、データベース・アカウントを識別しただけでは、その処理を依頼した利用者と、SQLを実行する利用者を区別できません。
そのため、利用者のIDに加え、そのIDを確認した認証基盤、要求を伝えるアプリケーション、認可の判断に使うロールや属性を、データベースが信頼できる形で結び付ける必要がでてきます。
これによって、共有アカウントで接続していても、利用者ごとに許可するデータと操作を判断できます。
そこで、従来の高度なアクセス制御方法であった VPD をさらに進化させた機能として、Oracle AI Database 26ai より Oracle Deep Data Security（Deep Sec） が導入されました。Deep Data Security ではエンドユーザーとアプリケーションのID、ロール、実行時の属性に基づく認可を、データベース側で強制するためのフレームワークとして機能させることができます。
Deep Data Security は、VPDなどのアクセス制御を発展させた機能となります。利用者の識別情報、ロール、実行時の属性を エンドユーザー・セキュリティ・コンテキスト として扱い、その情報に基づく認可をデータベース側で強制します。
これにより、アプリケーションやAIエージェントを介したアクセスでも、実際の利用者に許可された範囲でデータを扱う仕組みを構成できます。
1. Deep Data Security とは
Deep Data Security（以下、Deep Sec）は、アプリケーションで必要となる「誰に、どのデータへの、どの操作を許すか」という認可ルールを、Oracle AI Databaseで定義し、SQLの実行時に強制するためのアクセス制御機能です。
認可ルールは、アプリケーションのコードから独立した宣言的なSQLで定義します。
アクセス範囲は、行、列、セル単位で細かく指定ができ、利用者のID、ロール、実行時の属性に応じて、参照や変更を許可するデータを制御することが可能です。
また、Deep Secでは、利用者とアプリケーションそれぞれの識別情報を扱う仕組みが用意されているため、認可の対象には、アプリケーションを利用する人に加え、利用者の代理で動くAIエージェントや、自身の権限で処理するアプリケーションも含まれます。
こうした識別情報と、認可の判断に使うロールや属性を結び付けるのが、エンドユーザー・セキュリティ・コンテキストと呼ばれるものになります。 データベースは、このコンテキストと認可ルールを照合し、実行できる操作と対象データを最終的に決定することで、データベースに閉じたアクセスコントロールを行うようになっています。
2. Deep Data Security の全体アーキテクチャ
まず、Deep Secの全体像を、外部の認証基盤と連携するアプリケーションを例に確認してみます。 利用者がアプリケーションへログインしてから、データベースがアクセスを制御するまでの基本的な流れは、次のようになります。
- 利用者を認証する
認証基盤で利用者の本人確認を行い、利用者のIDやロールなどを含むトークンを発行します。 - 利用者の情報をデータベースへ伝える
アプリケーションは、トークンと必要な業務属性を、Oracleのクライアント・ドライバを通じてデータベースへ渡します。 - エンドユーザー・セキュリティ・コンテキストを確立する
データベースはトークンを検証し、利用者のID、有効なロール、実行時の属性を結び付けます。 - SQLの実行時に認可ルールを適用する
データベースは、確立したコンテキストに基づいて、操作できる行、列、セルを制御します。
この認可ルールを定義する仕組みが、データ・グラント（data grant） と呼ばれるものです。 データ・グラントでは、対象の表やビュー、許可する操作、対象列、対象行の条件などをSQLで指定します。
そして、業務上の役割に応じた権限をまとめるために、データ・ロール（data role） を使用します。
一方で、アプリケーションが共有アカウントで接続していても、エンドユーザー・セキュリティ・コンテキストが有効な間は、その利用者のID、ロール、属性に基づいた認可でSQLが実行されます。
この場合、接続に使うアカウントと、実際のアクセス範囲を決める利用者の情報を分けて扱える点が、この構成の特徴となります。
3. エンドユーザーとエンドユーザー・セキュリティ・コンテキスト
まず、通常のDBユーザーと、Deep Secのエンドユーザーの違いを整理します。Deep Data Security では、通常の CREATE USERで作成するDBユーザーとは異なり、「エンドユーザー」というユーザーが使用されます。 ユーザーであることに大きな違いはないですが、通常のDBユーザーはスキーマやオブジェクトの所有者になれますが、Deep Secのエンドユーザーは、スキーマやオブジェクトを所有せず、許可されたデータを利用する主体として扱われます。
エンドユーザーは、IDをどこで管理するかによって次の二つに分かれます。
- ローカル・エンドユーザー
- 外部エンドユーザー
ローカル・エンドユーザー
ローカル・エンドユーザーは、CREATE END USER文で作成します。パスワードを設定すれば、SQLクライアントなどから直接ログインすることができ、通常のDBユーザーと同じ使用感でアクセスすることが可能です。
アプリケーションを介して利用する場合、アプリケーション側で管理する利用者とデータベース内のローカル・エンドユーザーをユーザー名で対応付けることもできます。
この場合、データベースは、信頼されたアプリケーションが伝える利用者名を基に、対応するエンドユーザーのコンテキストを確立します。
外部エンドユーザー
一方、外部エンドユーザーは、IDやロールを外部の認証基盤で管理する方式です。利用者ごとにCREATE END USER文でアカウントを作成する代わりに、認証基盤が発行した OAuth アクセストークンを基に、データベースが利用者を識別します。
アプリケーションを介した構成では、利用者を示すトークンと、アプリケーションによるデータベースへのアクセスを許可するトークンを渡してアクセスすることになります。
現時点（2026年11月）では、次の認証基盤（Identity Provider、IdP）との連携をサポートしています。
- OCI IAM Identity Domains
- Microsoft Entra ID
- Keycloak※
※ 2026年11月次点ではOracle Autonomous AI Databaseでは未サポート
エンドユーザー・セキュリティ・コンテキストの役割
エンドユーザー・セキュリティ・コンテキストは、利用者のID、有効なデータ・ロール、実行時の属性を保持し、データベースが認可を判断するための情報をまとめたものになります。
認証基盤のロールやグループをデータ・ロールへ対応付けるほか、担当部門や担当顧客など、アプリケーション固有の属性も判断材料として構成することができます。
これにより、同じ接続を複数の利用者で再利用する場合も、それぞれの利用者に対応するコンテキストを基に、データベース側で認可ルールを適用できます。
従来のVPDでも、以前の記事の「4-2. 独自のアプリケーション・コンテキスト」で扱ったように、利用者や業務上の属性を保持し、ポリシー関数から参照できましたが、コネクションプールでは、利用者が切り替わるたびに、それらの情報を再設定または消去する設計が必要でした。
Deep Secでは、利用者の識別情報、ロール、業務属性を、エンドユーザー・セキュリティ・コンテキストとして扱う仕組みが組み込まれています。
アプリケーションとクライアント・ドライバが要求に対応する情報を渡すと、データベースがコンテキストの作成、接続への関連付け、切り離しを管理 するため、より実装として組み込みやすくなっています。
4. アクセス制御の仕組み
Deep Sec では、エンドユーザー・セキュリティ・コンテキストに含まれる利用者のID、データ・ロール、属性を、データベース内の認可ルールと照合します。
このルールをアプリケーションのコードから独立したSQLで定義し、コンテキストが有効な状態で実行されるSQLへ適用することで、行、列、セル単位のアクセスを制御します。
この認可ルールの中心となるのが、データ・グラント（data grant） と呼ばれるものです。
データ・グラントには、対象の表またはビュー、許可するSELECT、INSERT、UPDATE、DELETE、対象列、対象行を選ぶSQL述語、許可を受けるエンドユーザーまたはデータ・ロールを指定します。具体的な構文等については以下リンクも参考にしてみてください。
たとえば、従業員が自分の情報だけを参照できるようにする場合を考えます。
ここでは、HR.EMPLOYEES表のEMAIL列に、Deep Secが識別するエンドユーザー名と同じ値が格納されているものとします。
次のデータ・グラントは、EMPLOYEE_ROLEというデータ・ロールを持つエンドユーザーに対し、EMAIL列が現在のエンドユーザー名と一致する行の参照を許可するものです。
CREATE DATA GRANT HR.EMPLOYEES_OWN_RECORD
AS SELECT
ON HR.EMPLOYEES
WHERE EMAIL = ORA_END_USER_CONTEXT.USERNAME
TO EMPLOYEE_ROLE;ORA_END_USER_CONTEXT.usernameは、現在のエンドユーザー・セキュリティ・コンテキストから利用者名を取得します。そのため、アプリケーションが同じSQLを実行しても、この利用者名が異なれば条件に一致する行も変わることになるため、個々のSQLへ利用者を限定する条件を書き込まないまま、データベース側で参照範囲の制御ができます。
複数のデータ・グラントが適用される場合、許可される範囲は 基本的に和集合 として評価されます。
たとえば、本人の行を参照できるデータ・ロールと、直属部下の行を参照できるデータ・ロールの両方が有効であれば、本人と直属部下の行を参照できます。
さらに範囲を絞る場合は、データ・グラント・フィルタを使い、複数のグラントによる許可へ追加の制限を適用することも可能になっています。
行を参照できても、特定の列やセルの値を参照する権限がなければ、その値は既定でNULLとして返ります。
このため、「本人は自分の電話番号を参照および更新できるが、給与は参照だけできる」「上司は直属部下の給与を更新できるが、自分の給与は更新できない」といった、行、列、操作を組み合わせたルールを表現できます。
※ なお、権限不足によって隠された値と、元から格納されているNULLは、通常のNULL判定だけでは区別できません
また、データ・グラントによる制限を設計するときは、通常のデータベース権限を経由したアクセスも考慮します。アクセスをデータ・グラントに限定する場合、保護対象の表やビューへUSE DATA GRANTS ONLYを設定することが可能です。
※Deep Secユーザーに対する制御であり、通常のDBユーザーが持つ権限を制限する設定ではありません。
5. ユースケース
Deep SecはAI専用の機能ではありません。 業務アプリケーション、分析ツール、AIエージェントなど様々なユースケースを対象に、利用者のID、ロール、属性に基づく認可をデータベース側で適用することが可能です。特に、複数のアプリケーションやアクセス経路から同じ業務データを利用する場合に、この仕組みが役立つ印象です。
5-1. 共有アカウントを使うWebアプリケーション
多数の利用者が共通のデータベース・アカウントで接続するWebアプリケーションでは、接続用アカウントだけで利用者ごとの参照範囲を分けられません。Deep Secにより、実際の利用者の情報をデータベースへ伝え、担当者や組織に応じた認可ルールを適用します。コネクションプールを共有する構成でも、利用者ごとのアクセス範囲をデータベース側で制御できます。
5-2. AIエージェント、MCP、RAG
利用者の代理でSQLを生成するAIエージェントでは、生成されたSQLが、その利用者に許可された範囲で実行されるように設計する必要があります。
プロンプトやエージェントの処理が変わっても、データへのアクセスには共通の認可ルールを適用したい場面においても、Deep Sec による利用者のコンテキストに基づく制御を適用することができます。
Oracleは、特に AI アプリケーションに対しては過剰な権限による操作やプロンプト・インジェクションへの対策として、このデータベース側での認可を位置付けています。
MCPサーバーを介してデータベースへアクセスする場合も、利用者の情報をDeep Secへ伝える構成にすることで、同じ考え方を適用できます。
RAGにおいては、データベース内の文書やベクトルを検索する段階で参照範囲を制限し、利用者が参照できる情報だけを検索結果として返す構成が考えられます。
5-3. BI、分析ツール、SQLクライアント
同じ業務データを、Web画面では担当者単位で制限していても、分析ツールからは広く参照できる構成では、アクセス経路によって保護範囲が変わってしまいます。そのため、分析や直接SQLによる参照にも、利用者に応じた認可ルールを適用する必要があります。
Deep Secでは対応する接続方式でエンドユーザー・セキュリティ・コンテキストを確立することで、SQLクライアントから直接接続する利用者にも認可を適用することが可能です。
たとえば、同じ売上表を参照しても、地域担当者には担当地区のデータを、全社分析の担当者には全地域のデータを許可する、といった設計ができます。
https://docs.oracle.com/en/database/oracle/oracle-database/26/ddscg/end-user-security-context1.html
6. VPD との違い
VPDとDeep Secは、どちらもデータベース側で細かなアクセス制御を行う機能です。
その違いは、認可ルールの定義方法と、利用者の識別情報や権限を扱う仕組みにあります。
VPDでは、PL/SQLの関数にてアクセス条件となるSQL述語を生成し、保護する対象へ関連付けます。
Deep Secでは、データ・グラントをSQLで定義し、エンドユーザー・セキュリティ・コンテキストと照合します。
| 項目 | VPD | Deep Data Security |
|---|---|---|
| 認可ルールの定義 | PL/SQLのポリシー関数で述語を生成し、DBMS_RLSで保護対象へ関連付け | データ・グラントをSQLで定義する |
| 判断に使う情報 | データベースのセッション情報や、独自のアプリケーション・コンテキストなど | エンドユーザーのID、有効なデータ・ロール、実行時の属性 |
| 制御の表現 | 行の絞り込みに加え、特定列の参照に応じた制御やNULLによるマスキング | 行、列、セルと、許可する操作を組み合わせた認可 |
| 共有接続での利用者管理 | 利用者情報の設定や、接続再利用時の消去などを設計する | 対応するドライバが利用者情報を伝え、データベースがコンテキストを管理する |
VPDでは、PL/SQLのポリシー関数でアクセス条件を生成するため、利用者や業務要件に応じた細かな条件分岐を記述できます。 その分、分岐の漏れや、想定外の条件で広いアクセスを許可してしまう処理がないかを確認する必要があります。
一方、Deep Secでは、誰に、どのデータへの、どの操作を許可するかをSQLで宣言し、その評価と適用をデータベースに任せます。 アクセス条件を生成するための手続き的な処理を自作する負担を減らし、認可ルールそのものの設計と検証に集中できます。（宣言した条件に誤りや過剰な許可があればアクセス範囲も広がるため、Deep Secでも要件に沿ったルールの確認は必要です。）
7. ライセンスについて
Deep Data Security は、Oracle AI Database 26ai に含まれる機能としてご利用が可能です
オンプレミスを含め、追加ライセンスの必要なくすべてのエディションとクラウド環境にて利用が可能です。
- Oracle AI Database 26ai FREE
- Oracle AI Database 26ai Standard Edition
- Oracle AI Database 26ai Enterprise Edition
- Oracle AI Database Cloud / Multicloud
※リンクとしては公式FAQの提供条件の8ページにて案内がされています。
Oracle AI Database 26ai FREE および Standard Edition（SE）も対象に含まれるため、安価に機能検証や簡単な動作確認を始めることができます。
8. まとめ
Deep Data Security では、利用者のID、データ・ロール、実行時の属性に基づいて、行、列、セル単位の認可をデータベース側で強制することが可能です。共有アカウントを使う業務アプリケーションや、SQLを動的に生成するAIエージェントなど、同じデータへ複数の方法でアクセスする構成をとることができます。
導入を検討するときは、誰の権限で処理するのか、どの情報を認可の判断に使うのか、どのデータと操作を許可するのかを整理します。そのうえで、通常のDB設計に加え、アプリケーションから利用者情報を伝える仕組みと、データベース内の認可ルールを組み合わせて設計する必要があることに注意してください。
次回は、検証環境で Deep Data Security を構成し、利用者やロールを変えたときに、参照できるデータと実行できる操作がどう変わるかを確認してみます。