Oracle Database のアクセス制御を整理する：基本権限から追加セキュリティ機能まで【#8 Oracle Databaseセキュリティ入門】

データベースのセキュリティというと、まず「暗号化」を思い浮かべる方が多いかもしれません。前回までに扱った TDE やネットワーク暗号化は、保存されているデータや通信中のデータを第三者に読まれにくくするための重要な対策です。

ただし、暗号化だけでは「正規に接続したユーザーやアプリケーションに、どこまでデータを見せるか」は決められません。たとえば、営業担当者には自分の担当顧客だけを見せたい、サポート担当者には電話番号の一部だけを表示したい、DBA であっても機密表には自由にアクセスさせたくない、といった要件は、暗号化とは別の観点で設計する必要があります。

そこで必要になるのが、Oracle Database のアクセス制御です。アクセス制御では、ユーザーやアプリケーションに対して「どのオブジェクトに、どの操作を許可するか」を基本に、必要に応じて行、列、値の見せ方や、特権ユーザーの操作まで制御します。

この記事では、Oracle Database のアクセス制御の概要を次の２つの観点で整理します。

• まずは押さえる権限管理の基本
• データの見せ方や特権ユーザーの操作をさらに制御する追加機能

1. アクセス制御のキホンのキ

Oracle Database で「このユーザーは表を参照できる」「このユーザーはデータを更新できる」といった制御を行う中心は、主に次の権限を使って設計します。

• システム権限
• オブジェクト権限
• スキーマ権限
• ロール

システム権限

システム権限は、データベース全体に関わる操作を許可する権限です。

代表的な例として、データベースに接続するための CREATE SESSION、表を作成するための CREATE TABLE、ユーザーを作成するための CREATE USER などがあります。

注意したいのは、SELECT ANY TABLE のように ANY が付く権限です。これは特定の表ではなく、広い範囲のオブジェクトに対して操作できる強力な権限です。管理は簡単になりますが、必要以上のデータを見せてしまうリスクも大きくなることに注意する必要があります。

オブジェクト権限

オブジェクト権限は、表、ビュー、シーケンス、プロシージャ、パッケージなど、個別のデータベース・オブジェクトに対して付与する権限です。

たとえば、あるユーザーに注文表を参照させたい場合は、次のように特定の表に対して SELECT 権限を付与します。

GRANT SELECT ON sales.orders TO app_user;

表であれば、SELECT、INSERT、UPDATE、DELETE など、操作内容ごとに権限を分けられます。参照だけでよいユーザーには参照権限だけを、更新が必要なアプリケーションには更新権限を、といった設計ができます。

オブジェクト権限は粒度が細かく、最小権限を実現しやすい方法です。一方で、表が多いシステムでは、権限付与の管理が煩雑になりやすいという面もあります。

スキーマ権限

システム権限とオブジェクト権限の中間に位置づけられるのが、Oracle Database 23ai から導入されたスキーマ権限です。

従来はあるスキーマ内のすべての表を参照させたい場合には、次のオブジェクト権限かシステム権限のどちらかを選ぶ必要がありました。

• 表ごとに SELECT 権限を付与する（オブジェクト権限）
• SELECT ANY TABLE のような広いシステム権限を付与する

前者は安全ですが管理が煩雑になりがちです。一方後者は管理が簡単ですが、対象スキーマ以外の表まで参照できてしまう可能性があります。

そこでその中間の権限管理として、このスキーマ権限を使うことで、対象スキーマを限定した権限を付与することができます。たとえば、SALES スキーマ内の表を参照できるようにしたい場合は、次のように指定できます。

GRANT SELECT ANY TABLE ON SCHEMA sales TO app_read_role;

これにより、SALES スキーマの範囲に限定して参照権限を与えられます。新しい表が追加された場合にも、同じスキーマ内であれば権限管理を単純化できます。

ここまでを整理すると以下図のようになります。

ロール

ロールは、上記の権限をまとめて管理するための仕組みです。

ユーザーごとに個別の権限を直接付与していくと、利用者が増えたときに管理が難しくなります。そこで、業務やアプリケーションの役割に応じてロールを作成し、そのロールに必要な権限をまとめて付与します。

たとえば、参照専用のアプリケーション向けに APP_READ_ROLE、更新も行うアプリケーション向けに APP_WRITE_ROLE を作成し、ユーザーにはロールを付与する、という設計ができます。

ロールを使うと、権限の棚卸しや変更がしやすくなります。実際のシステムでは、個別ユーザーに直接多くの権限を付与するよりも、ロールを中心に設計するほうが運用しやすくなります。

2. スキーマ専用アカウントと読み取り専用ユーザー

Oracle Database では、ユーザーを作成すると同時にそのユーザー名と同じ名前のスキーマが作成されます。つまり、スキーマだけを作成したい場合にもユーザーとして作成する必要があります。

一方でたとえば、アプリケーションのデータを所有する APP_OWNER スキーマには直接ログインさせず、実際の接続は APP_USER のような実行用ユーザーに限定したい、というように、「ログインするためのユーザー」と「表やプロシージャを所有するためのスキーマ」を分けたいことがあります。

このような場合に使えるのが、18c より導入されたスキーマ専用アカウントです。これはユーザー作成時にNO AUTHENTICATION を指定することで、資格情報を持たないユーザー、つまり直接ログインできないスキーマ用アカウントを作成できます。

CREATE USER app_owner NO AUTHENTICATION;

また、Oracle Database 23ai からは、ローカル PDB ユーザーに対して READ ONLY を指定することができます。これにより、そのユーザーに付与された権限を上書きする形で読み取りのアクションのみを許可するようにし、権限にかかわらず接続先 PDB での書き込み操作を禁止することができます。

ALTER USER report_user READ ONLY;

3. 基本権限だけでは足りないケース

ここまでの権限管理で、「誰が、どのオブジェクトに、どの操作をできるか」は制御できます。アクセス制御の基本は、必要なユーザーに、必要な操作だけを許可、いわゆる最小権限の原則に厳守します。

しかし、実際のセキュリティ要件では、以下のようにさらに細かい制御が必要になることがあります。

• 同じ表を参照しても、ユーザーによって見える行を変えたい
• 電話番号やクレジットカード番号の一部だけを表示したい
• アプリケーション、分析ツール、AI エージェントからのアクセスでも、利用者単位の認可を一貫して適用したい
• DB 管理者であっても、業務データには簡単に触れられないようにしたい
• アプリケーションが通常発行しない SQL を検知、またはブロックしたい

このような場合、一部はアプリケーション側で実装することも可能ですが、Oracle Database の追加のアクセス制御機能を組み合わせることで実現することができます。

この制御の考え方としては、大きく分けると次の 2 つの観点に整理できます。

• データを出しすぎないための制御
• 特権ユーザーや不審な SQL から守るための制御

データを出しすぎないための制御

基本的な権限管理では、表やビューに対する操作可否を制御できます。ただし、同じ表を参照できるユーザーであっても、見せたい行や列、表示したい値の範囲が異なることがあります。このような場合、データベース側で表示範囲や表示内容をさらに絞り込むことが可能です。

このケースにおける代表的な選択肢は次のようになります。

• Data Redaction ：問い合わせ結果を返す直前に、電話番号やメールアドレス、クレジットカード番号などの値を動的にマスクするための機能です。保存されている値そのものは変更しません。
• Oracle Label Security ：行にラベルを付け、ユーザー側のラベル権限と比較してアクセス可否を判断するための機能です。「社外秘」「部門限定」「役員限定」のような分類に応じた制御に向いています。
• VPD：ユーザーやアプリケーションのコンテキストに応じて、参照できる行や列を制御するための機能です。SQL に条件を追加するようなイメージで、たとえば「自分の部門の社員だけを見せる」といった制御に使えます。
• Deep Data Security ：Oracle AI Database 26ai から新しく提供される、データベース層で認可を強制するためのデータ中心のアクセス制御機能です。アプリケーションや分析基盤、AI エージェントなど複数のアクセス経路に対して、行、列、セル単位の認可を一貫して適用するための枠組みを提供します。

ここでは各機能の設定方法には踏み込みませんが、行を絞る、値をマスクする、ラベルで制御する、複数のアクセス経路で認可を一貫させる、といったことがデータベースレイヤーで行うことができることをおさえておきます。

特権ユーザーや不審な SQL から守るための制御

データの見せ方を制御するだけでなく、強い権限を持つユーザーの操作や、通常とは異なる SQL の実行にも注意が必要となります。管理者権限やアプリケーション用アカウントが悪用された場合に備えて、権限を持っていても実行できる操作を追加で制限したり、不審な SQL を検知、ブロックすることが可能です。

このケースにおける代表的な選択肢は次のとおりです。

• Database Vault ：強い権限（特にシステム権限）を持つユーザーによるアクセスをさらに制御するための機能です。たとえ DB 管理者であっても、顧客情報などの機密データを自由に参照できないようにしたい場合の選択肢になります。
• SQL Firewall ：データベース・アカウントごとに通常実行される SQL や接続経路を学習、定義し、それ以外の SQL を検知またはブロックするための機能です。SQL インジェクション、盗まれたアプリケーション・アカウントの悪用、不審な直接接続などへの緩和策として活用することができます。

こちらでは、強い権限の使われ方や通常と異なるアクセスに対してどのように制御を扱うかをおさえておきます。

4. 機能の使い分け

ここまでの内容を、要件ベースで整理すると次のようになります。

5. まとめ

Oracle Database のアクセス制御は、まずシステム権限、オブジェクト権限、スキーマ権限、ロールを使って基本を設計します。この段階で重要になるのは、必要なユーザーに必要な権限だけを付与する「最小権限の原則」です。

一方で、「権限があるかどうか」だけでは対応しきれない要件もあります。ユーザーによって見える行を変える、列の一部だけをマスクする、アプリケーションや AI エージェントを含む複数のアクセス経路に利用者単位の認可を適用する、特権ユーザーの操作を制限する、通常とは異なる SQL を検知する、といった要件には、上記の追加のセキュリティ機能を組み合わせて対応することなります。
こうした制御の一部はアプリケーション側でも実装できますが、データベース層で制御することで、アプリケーションの脆弱性や実装ミス、想定外のアクセス経路に対しても対策を適用しやすくなります。

次回以降は、ここで紹介した各セキュリティ機能をもう少し詳しく見ていきます。