Oracle Database Vaultのご紹介

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |Copyright © 2016 Oracle and/or its affiliates. All rights reserved. |
Oracle Database Vault のご紹介
日本オラクル株式会社

Copyright © 2016 Oracle and/or its affiliates. All rights reserved. |
以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また
、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできませ
ん。以下の事項は、マテリアルやコード、機能を提供することをコミットメント（確約）する
ものではないため、購買決定を行う際の判断材料になさらないで下さい。
オラクル製品に関して記載されている機能の開発、リリースおよび時期については、弊
社の裁量により決定されます。
Oracleは、米国オラクル・コーポレーション及びその子会社、関連会社の米国及びその他の国における登録商標または商標です。
他社名又は製品名は、それぞれ各社の商標である場合があります。
2

Oracle Database Vault
3
特権ユーザのための強制アクセス・コントロール
アプリケーション
select * from
finance.customers
職務分掌特権ユーザ（SYS, DBA権限）であっても情報にはアクセスさせない
透過的既存アプリケーションの変更不要、どの経路からのアクセスも一律に制御
厳密ユーザー、クライアント情報（IPアドレス、アプリ名）、時間を組み合わせたポリシー設定
管理者
（特権ユーザ）
人事情報
顧客情報
財務情報

厳密な権限＆ルールの設定により不正アクセスを遮断
4
ルール１(アクセス元)
IP Address: 192.168.1.XXX
APP Name: JDBC
アプリケーション用ルール
ルール１(アクセス元)
IP Address: 192.168.1.201
DB User: ADMIN01
ルール2 (時間)
09:00～19:00
開発者用ルール
select * from crm.customer
09:00～19:00の間
開発者
ユーザ・オブジェクト
表
- Customer
- Order
索引
プロシージャ
アプリケーションユーザー
ユーザ
オブジェクト:
認可
ユーザ
オブジェクト:
認可
ユーザ
オブジェクト:
非認可
19:00～9:00の間
管理者

Validationされたアプリケーション用スクリプトを提供
• 特権ユーザがアプリケーションの
データをアクセスすることを防ぐ
• それぞれのアプリケーションに
合わせたValidation済のスクリプト
を提供
• 実行するだけでDV環境構築
• アプリケーションからは透過的に
アクセス制御
• 5%に満たないオーバーヘッド
5
Database Vaultによる特権管理をすぐに実装
Oracle E-Business Suite
12/11i
Oracle PeopleSoft
Oracle JD Edwards
EnterpriseOne
SAP
Oracle Retail Applications
(Retek)
Oracle Financial Services
Applications (i-Flex)
Oracle Utilities Applications
Oracle Enterprise Taxation
Management
Finacle (Infosys)
Oracle Siebel

レルム（Realm）
6
スキーマ、オブジェクトおよびロールを保護する領域
人事情報
顧客情報
財務情報
データベース
管理者
select * from
finance.customers
セキュリティ
管理者
管理者
顧客管理
• ユーザのオブジェクト(表やビュー、パッケージ等)を保護する論理的な領域
• SYSやSYSTEMユーザ、SYSDBAやDBA権限などの特権アクセスはデフォルト拒否される
• 認可されたユーザーのみが、そのレルム内のオブジェクトにアクセス可能
• レルムごとにデータの責任を持つオブジェクト管理者を作成することができる

必須レルム（Mandatory Realm)
7
より厳格に、抜け漏れのないデフォルト遮断
• オブジェクトの所有者、オブジェクト権限を与えられているユーザーでも、
レルム認可されていない限りはアクセスできない
通常レルム必須レルム(12c～)
HRレルム
HRユーザ
(所有者)
レルム所有者: なし
レルム参加者: なし
Customer表
のSelect権限
を持つユーザ
データベース
管理者
レルム認可
されていない
ユーザ
select * from
hr.customers
HRレルム
HRユーザ
(所有者)
レルム所有者: なし
レルム参加者: なし
Customer表
のSelect権限
を持つユーザ
データベース
管理者
レルム認可
されていない
ユーザ
select * from
hr.customers

レルム認可ユーザの違い
• レルム所有者
– レルム内のオブジェクトに対してのオブジェクト権限の付与・取り消しを行うことができる
– レルム内のオブジェクトにアクセスすることができる（別途、オブジェクト権限が必要）
• レルム参加者
– レルム内のオブジェクトにアクセスすることができる（別途、オブジェクト権限が必要）
8
HRレルム
customer表
SELECT
UPDATE
INSERT
DELETE
HRユーザ
(HRレルム所有者)
APPユーザ
(HRレルム参加者)
DEVユーザ
(HRレルム参加者)
grant select on customer to APP
※レルムに対してレルム所有者やレルム参加を登録できるのはDV_OWNERかDV_ADMINロールがあるユーザ

レルムの動作フロー
9
レルムで保護されたオブジェクトへの
アクセスか？
NO
適切な権限を持っている
データベース・アカウントによるSQL実行
アクセスしているユーザは
レルム所有者または参加者か？
レルムのルールを満たしてるか？
（ルールがない場合、ルールがenableか?）
（コマンドルールがある場合）
コマンドルールのルールを満たしているか？
Access OK
Access OK
NO Access NG
Access NG
Access NG
NO
NO
Yes
Yes
Yes
Yes
適切な権限とは、
システム権限(DDL)、または、
オブジェクト権限(DML)がアクセス
するオブジェクトに対して付与され
ていることが前提
そもそもそれが付与されていなけ
れば、レルムにアクセスする前に
権限がないということになる

ルール・セット（Rule Set）
10
人事情報
顧客情報
財務情報
データベース
管理者
セキュリティ
管理者
管理者
顧客管理
• レルムやコマンドルールなどに関連づけられる１つ以上のルールの集合体
• データベースで取得できる情報を使用して、TRUE またはFALSEで評価される条件
– Ex) IPアドレスやアプリケーション名などのセッション情報、月日や曜日、時間の情報等が使用可能
• ルールを構成する要素としてファクタやアイデンティティを使用する

ファクタ（Factor）
11
• ユーザ情報やIPアドレスなどDatabase Vaultが認識できる名前付きの変数や属性
• DVF.F$ファクタ名で参照可能
• ルールセットでの判定条件の要素として使われる
• IPアドレスやサーバ情報等を取得するデフォルトのファクタが用意されている
• ユーザ自身の独自ファクタを作成することもできる
ファクタ名：
CLIENT_IP
取得メソッド：
UPPER(SYS_CONTEXT('USERENV','IP_ADDRESS'))
SELECT DVF.F$CLIENT_IP FROM dual;
F$CLIENT_IP
---------------------------------------
10.185.151.4
実行結果
ファクタ名：
Get_Time
取得メソッド：
TO_CHAR(SYSDATE,'hh24:mi:ss')
SELECT DVF.F$GET_TIME FROM dual;
F$GET_TIME
---------------------------------------
16:15:38

ルールに違反したアクセスはDBの
監査ログに記録される
ルール・セットの構成例
12
例）接続先を限定したルールセット
ルール1：
IPアドレスが192.168.1.xxxからのアクセスである
ルール2：
接続ユーザがADMINである
ルールセット：接続先(IPアドレスとユーザ名）で限定する
ルール1の条件式：
ファクタ:
CLIENT_IP
Like ‘ 192.168.1.%’
ルール2の条件式：
ファクタ:
SESSION_USER
= ADMIN
レルム
コマンド
ルール
セキュア
ロール
ルールの紐づけ先

コマンドルール（Command Rule）
13
人事情報
顧客情報
財務情報
権限付与済み
DBA
Alter table accounts
drop column
DBA
オフショア
DBA
Truncate table
procurement.orders
• SQLコマンドの発行を、ルール・セットに基いて制限する
• ルール・セットがTRUEの場合のみ、SQLコマンドの実行が可能
• SQLコマンドの実行権限(システム権限やオブジェクト権限)は別途必要
• 対象を特定のオブジェクトに対するSELECTやすべてのオブジェクト共通にすることも可能

セキュア・アプリケーション・ロール（Secure Application Role)
14
Create Table
Create Index
SELECT, INSERT to EMP表
DELETE to DEPT表
セキュア・アプリケーションロール
ルール・セット
ユーザ
• 通常のロールにルール・セットを設定することができる
• ユーザへのセキュア・アプリケーション・ロールの設定はPL/SQLで制御する
• ルール・セットの条件を満たしていれば、ユーザにセキュア・アプリケーション・ロールが付与される
• セキュア・アプリケーション・ロールへの権限付与は、権限は通常のロールの設定を同じ

セキュア・アプリケーション・ロールの使い方
15
RESOURCE
SELECT ANY DICTIONARY
ALTER SYSTEM
ALTER DATABASE
セキュア・アプリケーション・ロール
CHECK_IP
CONNECTSCOTT
ユーザ
ルール1：
IPアドレスが192.168.1.1から
192.168.1.99のアクセスである
SQL> CONNECT SCOTT/TIGER;
接続されました。
EXEC DBMS_MACSEC_ROLES.SET_ROLE(‘CHECK_IP’);
PL/SQLプロシージャが正常に完了しました。
SCOTT
ユーザ
CONNECT
RESOURCE
SELECT ANY DICTIONARY
ALTER SYSTEM
ALTER DATABASE
ユーザが元々
保持している権限
セキュア
ロールによって
新たに付与された
権限

必要な設定はすべてEnterprise Manager12cに統合
16
Database Vaultの起動状態
やポリシーの設定・反映状況
Data Pumpやパッチ適用時に
必要なロールはプリセット済み

DV環境でのユーザの役割
17

インストール時に作成されるDatabase Vault用ロール
 Database Vaultの管理に必要な操作（レルムの作成等）をすべて実施することができる
 レルム認可（レルム所有者・参加者）をレルムに設定することができる
 Database Vaultの監視、監査レポートを実行することができる
 SYSユーザのオブジェクトへのSELECTが可能
 DV_OWNER、DV_ADMINのロールを別のユーザに付与することができる
DV_OWNER
 Database Vaultの管理に必要な操作（レルムの作成等）をすべて実施することができる
 レルム認可（レルム所有者・参加者）をレルムに設定することができる
 Database Vaultの監視、監査レポートを実行することができる
 SYSユーザのオブジェクトへのSELECTはできない
 DV_ADMINのロールを別のユーザに付与することはできない
DV_ADMIN
必須
18

インストール時に作成されるDatabase Vault用ロール
 データベース・ユーザとプロファイルの作成や管理を行うことができる
 ユーザにCREATE SESSION権限を付与できる
 DV_ACCTMGRだけが、このロールを別のユーザに付与することができる
DV_ACCTMGR
 CREATE ANY / ALTER ANY /DROP ANY / EXECUTANY / SELECT ANY 等のシステム権限を持つ
 ただし、上記の権限を使用できるのはレルムの参加者か所有者である場合のみ
 複数のレルム内に跨るオブジェクトの作成・管理が必要な場合に使われる
 SYSユーザが付与することができる
DV_REALM_OWNER
 従来のRESOURCEロールと同じシステム権限を持つ
 レルム内で一般に使用される表、ビュー、トリガー、シノニムおよびその他のオブジェクトの作成に使われる
 SYSユーザが付与することができる
DV_REALM_RESOURCE
必須
19

インストール時に作成されるDatabase Vault用ユーザ
20
 以下、Database Vaultを構成する上にシステム的に必要な情報を持つ
 Database Vaultの構成情報に関連するビュー
 Database Vaultで使用されるパッケージやファンクション
 Database Vaultで発生する監査ログ
DVSYS
 ファクタで構成される情報
DBF
※上記のユーザは、Database Vaultを構成するにおいて必要なユーザであり、ロックされている
基本的には、ロックを解除して使用することはない

Database Vault環境で必ず必要となるユーザ
21
 Database Vault 所有者
 DV_OWNERロールを持ち、Database Vault環境を管理するユーザ
 レルムやルール・セットの作成、レルム認可の設定などDatabase Vaultに
関連した操作が可能
 システム権限やオブジェクト権限は持っていない（付与できない）
 ユーザ表は参照できない
 Database Vault アカウント・マネージャ
 DV_ACCTMGRロールを持ち、ユーザの作成・変更・削除が実行できるユーザ
 システム権限やオブジェクト権限は持っていない（付与できない）
 CREATE SESSION権限のみを付与できる
 ユーザ表は参照できない
セキュリティ
管理者

Database Vault環境で制限される特権ユーザ
 SYS, SYSTEMユーザ、DBA権限を付与されたユーザ等の特権ユーザ
 従来通り可能なアクション
 データ・ディクショナリビューの参照
 システム権限、レルム保護されていないオブジェクト権限の付与
 AWRスナップショット、Analyzeコマンドの実行
 レルム保護されていないオブジェクトへのアクセス、監査設定
 制限されるアクション
 ユーザの作成・変更・操作は不可
 レルム保護されているオブジェクトへのアクセス
 ExportやData Pumpコマンドによるデータのエクスポート
 データベースジョブのスケジュール
 レルム保護されているオブジェクトに対しての監査設定
リソース
管理者
22

Database Vault環境での一般ユーザ
23
 従来と同じ一般ユーザ
 レルム参加者
 システム権限はリソース管理者から付与される
 （NEW）オブジェクト権限は、レルム所有者から付与される
 （NEW）レルム内のオブジェクトを管理するユーザ
 レルム所有者
 レルム内のオブジェクトへのアクセス権限を一般ユーザへ
付与・取り消しできる
 オブジェクト所有者と異なっていてもOK
オブジェクト
管理者

Database Vaultによる権限分掌と相互監視
24
従来
特権ユーザ
HRユーザ
・ユーザ作成
・権限付与
・HR表への
直接アクセス
・HR表への監査
SCOTT
ユーザ
・HR表への
オブジェクト権限を付与
Database Vault 環境
リソース管理者
（特権ユーザ）
セキュリティ
管理者
オブジェクト管理者
（ HRユーザ）
ユーザ作成
レルム所有者に任命
システム権限付与アクションを監査
オブジェクト
権限付与
ユーザ作成
レルム参加者
に任命
SCOTT
ユーザ
システム
権限付与

12c新機能
Privilege Analysis
25

Privilege Analysis
26
不正アクセスの原因となる過度な権限付与を検出
ユーザーやロールに付与されたシステム権限、オブジェクト権限の使用・未使用を
洗い出してレポーティング
アプリケーションや開発者・管理者に本当に必要する権限のみを付与
最小権限の原則を実現し、不正アクセスの未然防止に
Privilege
Analysis
Create …
Select …
Update …
DBA role
APPADMIN role

権限分析の対象
27
実行されたシステム/オブジェクト権限の洗い出し
ロール
指定したロールの権限の使用状況を分析する (複数指定可)
条件指定
指定した条件に適合する場合、権限の使用状況を分析する
(特定のユーザーやアプリケーション等)
ロール＋条件指定
指定したロールかつ条件に適合する場合、権限の使用状況分析する
データベース
データベース内のすべての権限の使用状況を分析する
(SYSユーザーを除く)

権限分析の手順
28
DBMS_PRIVILEGE_CAPTUREによるキャプチャの開始
DBMS_PRIVILEGE_CAPTURE.CREATE_CAPTURE
name ポリシー名
description 説明(任意)
type いずれか一つ選択
DBMS_PRIVILEGE_CAPTURE.G_DATABASE
DBMS_PRIVILEGE_CAPTURE.G_ROLE
DBMS_PRIVILEGE_CAPTURE.G_CONTEXT
DBMS_PRIVILEGE_CAPTURE.G_ROLE_AND_CONTEXT
roles Ex) role_name_list('role1', 'role2')
condition Ex) SYS_CONTEXT(''USERENV'', ''SESSION_USER'')=‘SCOTT’
DBMS_PRIVILEGE_CAPTURE.ENABLE_CAPTURE （’ポリシー名’）
• 分析ポリシーの有効化
• 分析ポリシーの作成

権限分析の手順
29
キャプチャの停止～レポーティング
EXEC DBMS_PRIVILEGE_CAPTURE.DISABLE_CAPTURE （’ポリシー名’）
• 分析ポリシーの無効化
EXEC DBMS_PRIVILEGE_CAPTURE.GENERATE_RESULT （’ポリシー名’）
• 分析レポートの作成 (実行後、専用のビューで分析結果を参照可能)
EXEC DBMS_PRIVILEGE_CAPTURE.DROP_CAPTURE （’ポリシー名’）
• 分析レポートの削除 (作成したレポートの情報を含めて削除される)
キャプチャ実行中

例) ユーザーがAny権限を使用していないか調査
30
BEGIN
DBMS_PRIVILEGE_CAPTURE.CREATE_CAPTURE(
name => 'ANY_priv_analysis_pol',
type => DBMS_PRIVILEGE_CAPTURE.G_CONTEXT,
condition => 'SYS_CONTEXT(''USERENV'', ''SESSION_USER'')=''APP_USER''');
END;/
EXEC DBMS_PRIVILEGE_CAPTURE.ENABLE_CAPTURE ('ANY_priv_analysis_pol');
-----処理実行-----
EXEC DBMS_PRIVILEGE_CAPTURE.DISABLE_CAPTURE ('ANY_priv_analysis_pol');
EXEC DBMS_PRIVILEGE_CAPTURE.GENERATE_RESULT ('ANY_priv_analysis_pol');
SELECT USERNAME, SYS_PRIV, OBJECT_OWNER, OBJECT_NAME FROM DBA_USED_PRIVS;
USERNAME SYS_PRIV OBJECT_OWNER OBJECT_NAME
---------------- ---------------------------- ----------------------- -----------------------
APP_USER SELECT ANY TABLE HR EMPLOYEES
APP_USER CREATE SESSION
APP_USER SYS ORA$BASE
APP_USER SYS DUAL
調査対象は、APP_USER
APP_USERが
SELECT ANY TABLE権限で
HRユーザーのEMPLYEES表にで
アクセスした履歴が判明
-> SELECT ANY TABLEは必要ないのでは？

例) DBAロールの使用状況を調査する
31
BEGIN
DBMS_PRIVILEGE_CAPTURE.CREATE_CAPTURE(
name => 'dba_role_analysis',
type => DBMS_PRIVILEGE_CAPTURE.G_ROLE,
roles => role_name_list('dba'));
END;/
EXEC DBMS_PRIVILEGE_CAPTURE.ENABLE_CAPTURE ('dba_role_analysis');
-----処理実行-----
EXEC DBMS_PRIVILEGE_CAPTURE.DISABLE_CAPTURE ('dba_role_analysis');
EXEC DBMS_PRIVILEGE_CAPTURE.GENERATE_RESULT ('dba_role_analysis');
調査対象は、DBAロール
SELECT USERNAME, USED_ROLE,SYS_PRIV,PATH FROM DBA_USED_SYSPRIVS_PATH;
USER USED_ROLE SYS_PRIV PATH
---------- ---------------------------- ----------------------- -----------------------
SCOTT OLAP_DBA DROP ANY TABLE SYS.GRANT_PATH(SCOTT,DBA,OLAP_DBA)
SELECT USERNAME, SYS_PRIV, OBJECT_OWNER, OBJECT_NAME FROM DBA_USED_PRIVS
USERNAME SYS_PRIV OBJECT_OWNER OBJECT_NAME
---------------- ---------------------------- ----------------------- -----------------------
SCOTT SELECT ANY TABLE HR TEST
SCOTTユーザーが、
DROP ANY TABLE権限を使用して
(DBA-EM - >OLAP_DBAロール配下)
HRユーザーのTEST表を削除している

権限分析の実行例
32
ポリシーの作成、スコープの定義
対象範囲を指定
この場合はデータベース内すべて
(※SYSを除く)

33
キャプチャの開始
キャプチャする期間の指定

34
キャプチャの終了～レポート生成

Privilege Analysisの専用ビュー
35
結果テーブル説明
DBA_USED_PRIVS
DBA_UNUSED_PRIVS
すべての使用/未使用の権限。
（システム権限、ユーザー権限、オブジェクト権限とPUBLIC
権限を含める）
DBA_USED_OBJPRIVS
DBA_UNUSED_OBJPRIVS
DBA_USED_OBJPRIVS_PATH
DBA_UNUSED_OBJPRIVS_PATH
すべての使用/未使用のオブジェクト権限。
「PATH」を付けてのテーブルは権限付与もリストする。
DBA_USED_SYSPRIVS
DBA_UNUSED_SYSPRIVS
DBA_USED_SYSPRIVS_PATH
DBA_UNUSED_SYSPRIVS_PATH
すべての使用/未使用のシステム権限。
「PATH」を付けてのテーブルは権限付与もリストする
DBA_USED_PUBPRIVS すべての使用したPUBLIC権限。
DBA_USED_USERPRIVS
DBA_UNUSED_USERPRIVS
DBA_USED_USERPRIVS_PATH
DBA_UNUSED_USERPRIVS_PATH
すべての使用/未使用のユーザー権限。
「PATH」を付けてのテーブルは権限付与もリストする

未使用のシステム権限
36
DBA_UNUSED_SYSPRIVS_PATH
ユーザ名未使用のシステム権限システム権限の付与パス

未使用のオブジェクト権限
37
DBA_UNUSED_OBJPRIVS_PATH
ユーザ名
未使用の
オブジェクト権限
付与されている
オブジェクト権限の対象

使用されたシステム/オブジェクト権限
38
DBA_USED_PRIVS

Oracle Database Vaultのご紹介

More Related Content

What's hot (20)

Viewers also liked (7)

Similar to Oracle Database Vaultのご紹介 (20)

More from オラクルエンジニア通信 (20)

Oracle Database Vaultのご紹介