【ITニュース解説】Oracle Deep Data Security in Oracle AI Database 26ai: End Users and Data Roles

Oracle AI Database 26aiに導入された「Deep Data Security」（通称Deep Sec）は、データベースのデータセキュリティを根底から変える新しい技術だ。これは、システムエンジニアを目指す上で非常に重要な「最小権限の原則」を、これまでのアプリケーションの領域からデータベースの領域へと拡張し、より堅牢なデータ保護を実現するものと理解できる。

従来のシステムでは、アプリケーションのコードやミドルウェア、あるいは最近ではAIエージェントが、どのデータにアクセスすべきかを判断し、その判断に基づいてデータベースへのアクセスが行われていた。しかし、これは「アプリケーションが正しく振る舞うだろう」という前提に立っていたため、もしアプリケーションにバグがあったり、悪意のある攻撃を受けたりした場合、意図しないデータ漏洩や改ざんのリスクがあった。Deep Secは、このような問題に対処するため、データベース自身が厳格なアクセス制御を強制するフレームワークを提供する。

Deep Secの最大の特徴は、ユーザー、ロール、またはアプリケーションが「どの行」「どの列」「さらには個々のセル」にアクセスできるかを、データベースに直接宣言できる点にある。そして、この宣言されたルールは、どのようなリクエスト（人間からの問い合わせ、レポートツール、自律型AIエージェントなど）であっても、データベースが発行されるすべてのクエリに対して強制する。これにより、データアクセスの許可・不許可がアプリケーションの振る舞いに依存せず、データが保存されている「源」で保証されることになる。これは、従来のOracle Label SecurityやData Maskingといったツールと併用することも可能だが、PL/SQLで実装される行レベルセキュリティよりもはるかにスケーラブルで、SQLネイティブな方法で細かなアクセス権限を定義できる点で進化している。

このDeep Secを理解するための主要な三つの構成要素がある。一つ目は「ローカルエンドユーザー」、二つ目は「データロール」、そして三つ目は「データグラント」である。

「ローカルエンドユーザー」は、アプリケーションで利用されるユーザーのための軽量な識別子だ。これまでのデータベースユーザー（「標準ユーザー」と呼ばれる）は、自分自身のスキーマ（データベースオブジェクトを格納する名前空間）やテーブルなどのオブジェクトを所有していた。しかし、ローカルエンドユーザーはこれらを持たない。彼らは純粋に、Deep Secがきめ細かなアクセス制御を行うための「誰であるか」というアイデンティティとしてのみ存在する。これにより、データベースの構造をシンプルに保ちつつ、ユーザーごとのアクセス管理が可能になる。

次に「データロール」は、きめ細かな権限を保持するために特別に作られたロール（役割）である。これは、Microsoft Entra IDやOCI IAMのような外部のIDプロバイダーで定義されたロールと連携させることもできるし、データベース内で完全に管理することも可能だ。データロールは、後述するデータグラントと組み合わせて、ローカルエンドユーザーに特定のデータへのアクセス権を付与する仲介役となる。

最後に「データグラント」は、具体的なアクセス制御ポリシーそのものである。これは、「どのユーザー（またはデータロール）が、どのテーブルのどの行、どの列に対して、SELECT（参照）、INSERT（挿入）、UPDATE（更新）、DELETE（削除）といった操作を許可されるか」を定義する。この定義は、隠された手続き型のロジックではなく、通常の読みやすいSQL文を使って行われるため、ポリシーの内容が明確で管理しやすい。

従来のデータベースユーザーとローカルエンドユーザーの間には明確な違いがある。従来の標準ユーザーはデータベースに接続し、自分のスキーマにオブジェクトを作成したり、そこにデータを格納したりする能力を持っていた。それに対し、ローカルエンドユーザーは、データベース内でCREATE END USER文を使って作成されるが、作成直後にはデータベースに接続する権限すら持たない。例えば、CREATE END USER vahid IDENTIFIED BY vahid;というコマンドでエンドユーザーvahidを作成しても、すぐにそのユーザーでデータベースに接続しようとすると「ORA-01045: Login denied. User VAHID does not have CREATE SESSION privilege.」というエラーが表示される。これはバグではなく、Deep Secの意図した動作であり、エンドユーザーは最初は何の権限も持たない状態から始まることを示している。彼らが何らかの操作を行うためには、データロールとデータグラントを通じて明示的に権限が与えられる必要がある。

エンドユーザーに接続権限やその他の操作権限を付与する方法が「データロール」だ。まず、CREATE DATA ROLE文を使ってデータロールを作成する。例えば、CREATE DATA ROLE db_data_role_vahid;のように作成する。次に、このデータロールに、接続に必要な標準的なデータベースロール（例えば、CREATE SESSION権限を持つdb_standard_role）を付与する。最後に、GRANT DATA ROLE db_data_role_vahid TO vahid;のように、作成したデータロールをエンドユーザーに割り当てる。この一連の手順によって、vahidは初めてデータベースに接続できるようになる。

接続後、エンドユーザーはUSER_END_USERSビューを通じて自分のユーザー名を確認できるが、USER_USERSビューを見るとXS$NULLというユーザー名が表示される。これは、ローカルエンドユーザーがスキーマを所有しないため、内部的にはXS$NULLという予約済みアカウントのセッションとして動作し、その上にエンドユーザーのセキュリティコンテキスト（ユーザー名vahidと有効化されたデータロール）がレイヤーとして適用されていることを示している。つまり、データアクセスはXS$NULLが直接行うのではなく、Deep Secのルールに基づいてエンドユーザーの権限で管理される。

しかし、データロールの利用には注意が必要だ。Deep Secのデータグラントは細かなデータアクセス制御のために設計されているが、データロールにはDBAのような広範なシステム権限を付与することもできてしまう。例えば、GRANT dba TO db_data_role_vahid;というコマンドを実行すると、データロールdb_data_role_vahidを持つエンドユーザーvahidは、間接的にDBA（データベース管理者）権限を継承してしまう。この場合、vahidはデータベース内のあらゆるテーブルに対して、自由にデータを参照、更新、削除、さらにはテーブル自体を削除するような強力な操作を実行できるようになる。これはDeep Secがまさに防ぎたいと考えている「過剰な権限」のリスクそのものであり、セキュリティの観点からは非常に危険な状態だ。本番環境では、DBAのような強力なロールをデータロールに付与するべきではない。代わりに、特定の行や列に限定したデータグラントを適切に利用し、エンドユーザーやAIエージェントが必要なデータのみにアクセスできるよう、厳密にスコープを限定することが重要となる。

データロールを通じてDBA権限を付与されたとしても、ローカルエンドユーザーには依然としてできないことがある。それは、データベースオブジェクトの作成だ。エンドユーザーはスキーマを所有しないため、CREATE TABLE tb (id NUMBER, name VARCHAR2(100));のようなDDL（データ定義言語）を実行しようとすると、「ORA-28222: Operations cannot be performed on Oracle reserved user or role "XS$NULL".」というエラーが発生する。このエラーは、ローカルエンドユーザーがデータへの読み書き権限は持てても、データベースの構造自体を変更したり、新しいオブジェクトを作成したりする「スキーマオーナー」としての能力は決して持たないというDeep Secの核となる設計思想を明確に示している。

まとめると、Deep Secは、従来のセキュリティモデルでは難しかった、データソースの最も深い層でのきめ細かなアクセス制御を可能にする。ローカルエンドユーザー、データロール、データグラントという三つの新しい要素を組み合わせることで、アプリケーションやAIエージェントの振る舞いに依存せず、データベースがデータアクセスを厳格に強制する。ただし、データロールに広範な権限を与えてしまうと、このきめ細かな制御の目的が失われるため、適切なデータグラントの活用が不可欠だ。

今後のステップとしては、この危険なDBA権限の付与を避け、CREATE DATA GRANT文を用いて、より限定的で安全なデータアクセスルールをエンドユーザーに適用する方法を学ぶことになる。これにより、Deep Secが本来意図する、厳密な最小権限の原則に基づいたデータ保護が実現される。