Oracle Deep Data SecurityがOracle AI Database 26aiで利用可能に

※ 本記事は、Vipin Samarによる”Oracle Deep Data Security Is Now Available in Oracle AI Database 26ai“を翻訳したものです。

2026年7月15日

多くの組織がAIエージェントを試していますが、それを本番に移行することははるかに複雑です。AIエージェントは、自律的な内部関係者として機能するケースが増えており、直接的な人間の監督なしにデータへアクセスし、アクションを実行できます。これにより、プライバシー、規制コンプライアンス、および意図しない機密データの漏洩に関する新たなリスクが生じます。課題はもはや、エージェントが何を実行できるかだけではなく、何の実行を許可されるべきか、そしてユーザー認可の境界内で一貫して動作すると信頼できるかどうかにあります。

本日、AIエージェント時代のデータ・アクセスを保護するための新しいアプローチであるOracle AI Database 26aiでのOracle Deep Data Securityの提供を発表できることを嬉しく思います。Oracle Deep Data Securityは、AIエージェントがユーザーのかわりにデータを問い合せる場合でも、エンド・ユーザーの認可モデルをデータベースに直接適用することで、セキュリティとプライバシーの向上を支援します。

特権アクセスの問題

従来のアプリケーションでは、多くのエンド・ユーザーにサービスを提供するため、高い権限を持つデータベース接続を使用することが多く、アプリケーション・レイヤーでは、エンド・ユーザーを認可されたデータに制限する必要があります。これは、問合せが事前定義され、厳密に制御され、開発者がアプリケーションに埋め込まれた認可ロジックを検証できるためです。

AIエージェントは、フル・アクセスを持つ同じ高度に権限を持つ接続モデルを継承しますが、事前定義済の問合せにも、認可を適用する責任にも拘束されません。幅広いアクセスを持つインサイダーと同様に、AIエージェントは、実行するクエリ、実行するパス、およびユーザー認可への確実な連携なしにタスクを完了する方法を自律的に決定します。さらに悪いことに、意図しない問合せの生成に影響され、認可されていないデータが公開される可能性があります。

さらに、多くの新しいアプリケーションがバイブ・コード化されています。組織がエージェントにデータへの直接アクセスを許可していない場合でも、バイブ・コード・アプリケーションはセキュリティを完全に実装すると信頼することはできません。

数百ものAIエージェントがデータに基づいて行動しているため、機密データ漏洩のリスクが劇的に増加しています。

これらの問題の解決策は簡単です。データのアクセス方法、AIエージェント、通常またはバイブコード化されたアプリケーション、分析のいずれを使用しても、ユーザーの認可モデルを一貫して適用します。これがまさにOracle Deep Data Securityが提供するものです。

Oracle Deep Data Securityによる問題の解決

Deep Data Securityを使用すると、実行コンテキストとともにユーザーおよびエージェントのアイデンティティを実行時にデータベースに伝播できます。宣言SQLポリシーによって、そのユーザー・リクエストに対して表示できる行、列またはセル・レベルのデータ、および許可されるアクションが決まります。返される結果は、ユーザーが表示を許可されているデータに制限されます。

単純な人材管理(HCM)シナリオについて考えてみます。Emmaなどの従業員には、自分の個人フィールドを含む自分のHRレコードのみを表示する権限がある場合があります。マネージャのMarvinは、自身のHRレコード、およびEmmaとその他の部下のHRレコードを表示する権限が付与される場合がありますが、SSNや自宅住所などの機密フィールドは表示できません。AIエージェント、アプリケーションまたはSQLツールがいずれかのユーザーのかわりに同じHRデータを問い合せる場合、データベースは結果を返す前に同じエンドユーザー認可ルールを適用します。アクセス・パスは変更される場合がありますが、認可境界は変更されません。

アプリケーション層に依存して事後的に結果をフィルタリングするのではなく、データベースがソースで直接認可を強制します。エージェントまたはアプリケーションが予期しないパスを取る場合、新しい問合せを生成する場合、または意図したものとは異なる動作をする場合でも、データベースは、データが返される前に同じ認可ルールを適用します。既存のアプリケーションの場合でも、Deep Data Securityは第2の防御線を提供できます。これは「ソースでのセキュリティ」の実践です。

また、Deep Data Securityは、チームがAI対応アプリケーションを構築および保守する方法の簡素化にも役立ちます。データベースでの強制を一元化することで、アプリケーション、サービスおよびエージェント間でユーザーごとのデータ・フィルタリング・ロジックおよびセキュリティ・ポリシーを複製する必要がなくなります。データ・アクセス認可ルールは、複数の場所で実装および保守するのではなく、アプリケーションおよびエージェントの進化に応じて一元的に更新できます。

Deep Data Securityに関するアナリストの見解

多くのアナリストは、これがアーキテクチャの重要な変化であると認識しています。彼らが言っていることは次のとおりです:

NAND ResearchのSteve McDowell氏は次のように述べています。「Oracle Deep Data Securityは、アプリケーション層ではなくデータベース層で実施される、アイデンティティ対応のファイングレイン・アクセス制御を導入しています。リレーショナル、ベクトル、レイクハウスのデータ・ソース全体で、ユーザー・アイデンティティ、ロール、コンテキストに基づくポリシーを適用します。AIエージェントを導入する企業にとって、これは重要なことです。これは、ライブ・データ上で自律的に動作するエージェントは、そうでなければ単一ユーザーの認可範囲を大きく超えるレコードにアクセスできてしまう可能性があるためです。Deep Data Securityでは、元のユーザーのアクセス権に基づいてデータ・ソースの境界が強制されます。これは、急速に進化するエージェント・ワークフロー全体で一貫して強制することが難しく、AI駆動型攻撃に対抗するよう設計されていないアプリケーション層のコントロールからの大きなステップ・アップです。」

KuppingerCole Analystsのリード・アナリスト兼最高技術責任者であるAlexei Balaganski氏は次のように述べています。「既存の制御を単に拡張して、エージェントAI時代のデータを保護できると考えるのは魅力的です。APIをさらにいくつか追加し、権限を絞り込み、追加の検証レイヤーを導入するだけで、すべてが以前と同じように動作するはずです。実際には、このアプローチはもはや拡張性がありません…残念ながら、サイバーセキュリティにおいて、楽観論や希望は持続可能な戦略ではありません。これにより、データ層でガバナンスを強制することが最も適切なアプローチになります。OracleによるDeep Data Securityの導入は、ファイングレイン認可をデータベースに直接埋め込むことで、この方向性を示しています。ポリシーは、アイデンティティ、ロールおよびコンテキストの観点から定義され、行、列または個々のデータ要素のレベルで適用されます。」

HyperFRAME Researchのインフラストラクチャおよびネットワーキング担当バイスプレジデント兼プラクティス・リーダーであるRon Westfall氏は次のように述べています。「Oracle AI Databaseに直接統合されているOracle Deep Data Securityは、ユーザーとAIエージェントに精密なアクセス制御を適用するデータベースネイティブな認可フレームワークを提供します。システムでは、宣言SQLポリシーを使用してアプリケーション層からセキュリティ・ロジックを分離し、プロンプト・インジェクション攻撃時に侵害されたAIエージェントが未許可のデータにアクセスすることを防止する重要な保護手段を提供します。OAuth 2.0トークンなどのユーザーIDおよびランタイム・コンテキストをデータベース・エンジンに直接埋め込むことで、Oracleは、統合されたセキュリティ体制と、すべてのデータ操作のための包括的な監査証跡を確保します。」

まとめると、これらの観点はいずれも同じ結論を裏付けています。エージェント時代では、データが返される前に、データベース自体のソースでデータ・セキュリティを適用する必要があります。

ソースでのセキュリティ、唯一の安全な選択

Oracle AI Database 26aiにおけるOracle Deep Data Securityにより、組織は本番環境でエンド・ユーザーの認可モデルを大規模に実施できます。きめ細かいアクセス・ルールをデータベース内で直接適用することで、組織は、機密データを保護するためにエージェント自身に依存することなく、AIエージェントを実験から本番に移行できます。

エージェント時代では、制御なしのスピードはリスクです。データが存在する場所でセキュリティを強化することで、組織は自信を持ってAIを導入し、すべてのデータ・アクセスが定義された境界内に留まるようにすることができます。

最終的に、AI時代におけるデータ・プライバシーの強制を完全に信頼する唯一の方法は、データベース内のソースに実装することです。

リソース

Oracle.comのOracle Deep Data Security
https://www.oracle.com/security/database-security/features/deep-data-security/

Oracle Deep Data Securityテクニカル・レポート
https://www.oracle.com/a/ocom/docs/security/deep-data-security-technical-brief.pdf

Oracle Deep Data Security FAQ https://www.oracle.com/a/ocom/docs/security/deep-data-security-faq.pdf

Deep Data Security LiveLabs FastLabsを試す
Lab 1: Oracle Deep Data Securityの使用開始
https://livelabs.oracle.com/ords/r/dbpm/livelabs/run-workshop?p210_wid=4393

Lab 2: Microsoft Entra IDとDeep Data Securityによるアイデンティティ駆動型データ・アクセス
https://livelabs.oracle.com/ords/r/dbpm/livelabs/run-workshop?p210_wid=4396