Oracle Databaseには、多層防御を実現する数多くのセキュリティ機能が用意されています。AIエージェントによるデータベース・アクセスが急速に拡大する中、AI時代のデータ保護において特に重要となる機能をまとめたものが、以下のスライドです。
今まで紹介してきたDeep Data Securityは、エンドユーザーを対象にしたアクセス制御の機能ですが、SYSユーザーやSELECT ANY TABLEのような強い権限を持つ特権ユーザーからのアクセスを制限することはできません。これらの特権ユーザーからのアクセスを制限する方法として、Oracle DatabaseにはDatabase Vaultという機能があります。
下記のスライドをご覧ください。
Database Vaultでは、レルムという論理的な保護エリアを定義することによりアクセス制御を実現します。例えば、CRM(顧客管理アプリケーション)で使われるすべての表やビューといったスキーマ・オブジェクトをCRM専用としてレルムで括ってしまうだけで、SYSユーザーやDBAロールなどのDatabase内のすべての表に無条件で参照できる特権ユーザーはもうアクセスできません。
レルム内の表にアクセスするためには、通常のSELECTのオブジェクト権限に加えて、レルムに対するアクセス権(レルム認可)が必要になります。
では実際に、Deep Data Secuirtyによるエンドユーザーのアクセス制御に加えて、特権ユーザーに対するアクセス制御を加えて、より強固なOracle Databaseを設定する方法を紹介します。
準備
こちらの記事を参考に、ADB上にdemoスキーマとDeep Data Securityの設定をしておく
特権を持つ２つのユーザーを作成して、その挙動を確認しておく
--DBAロールを持つユーザ(dbausr)
CREATE USER dbausr identified by password;
grant dba to dbausr;
--SELECT ANY TABLE権限を持つユーザ(selectany)
CREATE USER selectany identified by password;
grant select any table, create session to selectany;
--admin、dbausr、selectanyのそれぞれの特権ユーザーでDEMOスキーマの表にSELECTできることを確認
--明示的にSELECTをGrantされていなくても、sysdbaやdbaロール、select any tableのシステム権限を持っているユーザーは無条件でアクセスできる
SQL> select * from demo.healthcare_workers;
WORKER_ID USERNAME FIRSTNAME LASTNAME WORKER_NAME WORKER_ROLE DEPARTMENT EMAIL CREATED_AT
____________ _____________ ____________ ____________ ______________ ______________ _____________ ___________________________________ ______________________________
1 nsato naoto sato 佐藤 直人 DOCTOR 内科 sato.naoto@hospital.example 26-07-05 04:09:27.017726000
2 rsuzuki rina suzuki 鈴木 里奈 DOCTOR 糖尿病内科 suzuki.rina@hospital.example 26-07-05 04:09:27.041271000
3 mtanaka megumi tanaka 田中 恵 STAFF 医事課 tanaka.megumi@hospital.example 26-07-05 04:09:27.067223000
4 ykondo yuki kondo 近藤 由紀 STAFF 受付 kondo.yuki@hospital.example 26-07-05 04:09:27.092411000
5 myamamoto makoto yamamoto 山本 誠 STUDENT 医学部実習 yamamoto.makoto@hospital.example 26-07-05 04:09:27.120299000
6 ytakahashi yu takahashi 高橋 悠 STUDENT 医学部実習 takahashi.yu@hospital.example 26-07-05 04:09:27.144687000
Database Vaultを有効化
ADBの場合、Database Vaultの初期構成をすると、全く同じ構成前の状態には戻せないので設定前にはバックアップ、またはスクラップ&ビルドでも構わないテスト環境でまずは試してください
ここでやることを整理すると、まずDatabase Vaultを構成するには、dv_ownerとdv_acctmgrというロールを持ったユーザーが新たに必要です。職務分掌という観点から、従来のデータベース管理者の権限を分散させなければならないという意図があります。
- dv_ownerは、アクセス制御のポリシールールなどDatabase Vault全般の設定を行うセキュリティ管理者
- dv_acctmgrは、ユーザーの作成・削除といったアカウント管理者
なので、Database Vault環境下では、従来のデータベース管理者に加えて、上記のセキュリティ管理者というDBAの運用を監督する職務の人が必要になります
--adminで接続する
sql admin/password@サービス名
--Database Vault用の管理ユーザ(dvmanager)を作成
SQL> GRANT CREATE SESSION TO dvmanager IDENTIFIED BY password;
Grant succeeded.
--dv_ownerとdv_acctmgrロールを持つユーザーを指定してDatabase Vaultの構成を実行。※このコマンドはやり直しがきかないので注意。構成後に別ユーザーを指定しての再実行などはできない
--DVの管理者とアカウント管理者は分けると運用が大変なのでdvmanagerで兼務させる
SQL> EXEC DBMS_CLOUD_MACADM.CONFIGURE_DATABASE_VAULT('dvmanager','dvmanager');
PL/SQL procedure successfully completed.
-- Database Vaultを有効化
SQL> EXEC DBMS_CLOUD_MACADM.ENABLE_DATABASE_VAULT;
PL/SQL procedure successfully completed.
※有効化に成功したら、ADBを再起動する
--確認
SQL> SELECT * FROM DBA_DV_STATUS;
NAME STATUS
______________________ _________________
DV_APP_PROTECTION NOT CONFIGURED
DV_CONFIGURE_STATUS TRUE
DV_ENABLE_STATUS TRUE
ADBの場合、adminユーザーにdv_ownerとdv_acctmgrのロールがデフォルトで付与されています。なので、これをadminからrevokeすれば、dvmanagerユーザーがセキュリティ管理者としてDatabase Vault全般とアカウント管理、adminユーザーがそれ以外のDBA業務と職務分掌が実現します。
しかし、adminユーザーからdv_ownerロールをreovkeし、再度grantしても同じ状態には戻らないため注意が必要です。もしdvmanagerがパスワード切れでログインできない、誤って削除した場合、Database Vaultを無効化する手段を完全に失うため、保険的にadminにある権限は当面は残しておいたほうが安全かと思います。※これは、adminがDatabase Vaultの設定を変更できるというリスクを許容するということになります。
レルムの作成
レルム作成などDatabase Vaultに対する設定を行うユーザーは、Database Vaultの管理ユーザーのdvmanagerを使用する
--dbv_owner(DV管理者)で接続する
sql dvmanager/password@サービス名
--Demoスキーマ用のレルムを作成 (※ここでは必須レルムでなく、通常レルムで作成)
BEGIN
DVSYS.DBMS_MACADM.CREATE_REALM(
realm_name => 'DEMO_TABLES_REALM',
description => 'Protect tables in DEMO schema',
enabled => DBMS_MACUTL.G_YES
);
END;
/
--DEMOの表をすべてそのレルム内に入れる
BEGIN
DVSYS.DBMS_MACADM.ADD_OBJECT_TO_REALM(
realm_name => 'DEMO_TABLES_REALM',
object_owner => 'DEMO',
object_name => '%',
object_type => 'TABLE'
);
END;
/
それぞれのユーザーでSELECTの結果を確認
adminの場合
--adminで接続する
sql admin/password@サービス名
--DEMOスキーマの表にはもうアクセスできない
SQL> select * from demo.healthcare_workers;
次のコマンド行の開始中にエラーが発生しました : 1 -
select * from demo.healthcare_workers
コマンド行 : 1 列 : 20 でのエラー
エラー・レポート -
SQLエラー: ORA-01031: 権限が不足しています
https://docs.oracle.com/error-help/db/ora-01031/01031. 00000 - "insufficient privileges"
*Document: YES
*Cause: A database operation was attempted without the required
privilege(s).
*Action: Ask your database administrator or security administrator to grant
you the required privilege(s).
More Details :
https://docs.oracle.com/error-help/db/ora-01031/
dbausr(DBAロール)、selectany(select any table権限)の場合
SQL> select * from demo.healthcare_workers;
次のコマンド行の開始中にエラーが発生しました : 1 -
select * from demo.healthcare_workers
コマンド行 : 1 列 : 20 でのエラー
エラー・レポート -
SQLエラー: ORA-01031: 権限が不足しています
このようにいずれの特権ユーザーでもレルム保護されたオブジェクトには今まで通りのアクセスはできない
Deep Data Securityのローカル・エンドユーザーの場合
--ローカル・エンドユーザー nsatoで接続する
$ sql nsato/xxxxxx@adb
SQL> select * from demo.healthcare_workers;
WORKER_ID USERNAME FIRSTNAME LASTNAME WORKER_NAME WORKER_ROLE DEPARTMENT EMAIL CREATED_AT
____________ _____________ ____________ ____________ ______________ ______________ _____________ ___________________________________ ______________________________
1 nsato naoto sato 佐藤 直人 DOCTOR 内科 sato.naoto@hospital.example 26-06-11 05:52:37.134709000
2 rsuzuki rina suzuki 鈴木 里奈 DOCTOR 糖尿病内科 suzuki.rina@hospital.example 26-06-11 05:52:37.158024000
3 mtanaka megumi tanaka 田中 恵 STAFF 医事課 tanaka.megumi@hospital.example 26-06-11 05:52:37.178567000
4 ykondo yuki kondo 近藤 由紀 STAFF 受付 kondo.yuki@hospital.example 26-06-11 05:52:37.200133000
5 myamamoto makoto yamamoto 山本 誠 STUDENT 医学部実習 yamamoto.makoto@hospital.example 26-06-11 05:52:37.222078000
6 ytakahashi yu takahashi 高橋 悠 STUDENT 医学部実習 takahashi.yu@hospital.example 26-06-11 05:52:37.244118000
6行が選択されました。
Deep Data Securityのエンドユーザーは、明示的にデータ権限を付与されているので、レルム内のオブジェクトに同様にアクセスすることが可能。これによってDeep Data Securityのエンドユーザーでの行・列・セルレベルのアクセス制御に加えて、Database Vaultによる特権ユーザーのアクセス制御の両方を実装したよりセキュアなデータベースとして運用することができる。
また、もし特権ユーザーでレルム内のオブジェクトにアクセスさせたい場合は、以下のようにレルムに対するアクセス権(レルム参加)をユーザーまたはロールに付与する。
--dvmanager(DV管理者)で接続する
sql dvmanager/password@サービス名
--adminをdemoのレルムに参加させる
BEGIN
DVSYS.DBMS_MACADM.ADD_AUTH_TO_REALM(
realm_name => 'DEMO_TABLES_REALM',
grantee => 'admin',
auth_options => DBMS_MACUTL.G_REALM_AUTH_PARTICIPANT
);
END;
--adminで接続する
sql admin/password@サービス名
SQL> select * from demo.healthcare_workers;
WORKER_ID USERNAME FIRSTNAME LASTNAME WORKER_NAME WORKER_ROLE DEPARTMENT EMAIL CREATED_AT
____________ _____________ ____________ ____________ ______________ ______________ _____________ ___________________________________ ______________________________
1 nsato naoto sato 佐藤 直人 DOCTOR 内科 sato.naoto@hospital.example 26-07-05 04:09:27.017726000
2 rsuzuki rina suzuki 鈴木 里奈 DOCTOR 糖尿病内科 suzuki.rina@hospital.example 26-07-05 04:09:27.041271000
3 mtanaka megumi tanaka 田中 恵 STAFF 医事課 tanaka.megumi@hospital.example 26-07-05 04:09:27.067223000
4 ykondo yuki kondo 近藤 由紀 STAFF 受付 kondo.yuki@hospital.example 26-07-05 04:09:27.092411000
5 myamamoto makoto yamamoto 山本 誠 STUDENT 医学部実習 yamamoto.makoto@hospital.example 26-07-05 04:09:27.120299000
6 ytakahashi yu takahashi 高橋 悠 STUDENT 医学部実習 takahashi.yu@hospital.example 26-07-05 04:09:27.144687000
6行が選択されました。
Database Vaultは、特権ユーザーの権限分掌を目的とした強力なアクセス制御ですが、一方で、稼働中のデータベースに対して有効にする場合は特に注意が必要です。
sysdbaやselect any tableなどの強いシステム権限をアプリケーションやバッチ内の予期せぬところにて使用されている場合、そのアクセスを遮断することによるシステムの不具合を起こしてしまう可能性があります。
とはいえ、そのような強い権限を日常的に使うことは不健全なので、なんとか是正したいところです。Database Vaultには、レルム作成時にすぐにアクセスをブロックしてしまうのではなく、影響を調査するためのシュミレーションというモードがあります。このモードは、実際にブロックはせずにレルム違反のアクセス内容だけを記録しておくことができるので、必要・不必要なアクセスを洗い出すのに最適です。
では、実際に作成済みのレルムをシュミレーションモードに変更してみます。
レルムをシュミレーション・モードに変更
--既存のレルムをシュミレーションに変更
BEGIN
DVSYS.DBMS_MACADM.UPDATE_REALM(
realm_name => 'DEMO_TABLES_REALM',
enabled => DBMS_MACUTL.G_SIMULATION
);
END;
/
--再度SQLを実行し、違反したアクセスはビューで参照
SQL> SELECT ID, USERNAME, COMMAND, VIOLATION_TYPE, REALM_NAME, REALM_TYPE, OBJECT_OWNER, OBJECT_NAME, OBJECT_TYPE, SQLTE
XT FROM DVSYS.DBA_DV_SIMULATION_LOG ORDER BY "TIMESTAMP" DESC FETCH FIRST 20 ROWS ONLY;
ID USERNAME COMMAND VIOLATION_TYPE REALM_NAME REALM_TYPE OBJECT_OWNER OBJECT_NAME OBJECT_TYPE SQLTEXT
_______ ___________ __________ __________________ ____________________ _____________ _______________ _____________________ ______________ ________________________________________
5000 ADMIN SELECT Realm Violation DEMO_TABLES_REALM REGULAR DEMO HEALTHCARE_WORKERS TABLE SELECT * FROM DEMO.HEALTHCARE_WORKERS
以上がDeep Data SecurityとDatabase Vaultを組み合わせたアクセス制御の方法です。
Database Vaultは、コマンド・ルールやアプリケーション・ロールなどもっと様々な機能があるのですが、単純に特権ユーザーからユーザーの表を自由にアクセスさせないというのは、レルムを使うだけで比較的簡単に使用できます。
特権ユーザーの使用は、特にLLMで自然言語によるアクセスにおいては非常にリスクの高い脅威となるので、対策の一助として試してみて頂ければと思います。