Oracle Database Securityの製品には、Audit Vault and Database Firewall (AVDF)というセキュリティ製品があるのをご存じでしょうか？まずはこちらのスライドをご覧ください。

主にオンプレミスのデータベースの監査ログ基盤としての使用実績がありますが、最近ではオンプレミス基盤からOCIへのLift and Shiftのユーザー増加に伴い、このAVDFをOCIで動作させる方法についてのお問い合わせも増えてきました。そこで今回からは、OCIでAVDFを動作させるための要件や一連の設定手順についてまとめて紹介していきます。

AVDFは下記のスライドのように用途に応じた方式を選択可能です。一般的にはエージェント方式での利用が多く、アウトオブバンド方式を使用しているユーザーもいます。OCIではアウトオブバンドの方式を構成することはできないため、代替方式としてはホストモニターというNICのパケットキャプチャを利用した方式が代替案になります。
ホストモニター自体はあまり利用実績が少なく、公開されている情報も少ないのでOCIで動作させるためのひと通りの設定手順について説明していきます。

AVDFの最新の資料はこちら

OCIのネットワーク構成

今回は、手順を簡略化するために、パブリック・サブネットにAudit Vault, Database Firewall, BaseDBをそれぞれ作成する。また、BaseDBの手順は省略するので、好みのシェイプで作成しておく。
サブネットのイングレス・ルールのセキュリティリストは、22, 443, 7443, 1521, 2050-5100 を許可しておくこと。

Audit Vault ServerとDatabase Firewallのデプロイ

OCIのマーケットプレイスからOracle Audit Vault and Database Firewallを検索し、それぞれ最新のリリースをデプロイする。

2025年6月時点では最新は20.14
Audit Vault Serverは、4core, 64GBメモリで作成する。Audit Vault内のOracle Databaseは、In-Memoryによってログ参照を高速化できるので、メモリは多いほど快適になる
Database Firewallは、1core, 12GBメモリで作成する

Audit Vault Serverが作成されたら、ブラウザからAVSのIPアドレスでコンソールにアクセスする。リポジトリDBの作成など内部でインストール処理が行われているためコンソールが表示されるまで10分程度かかる。
https://xxx.xxx.xxx.xxx

ブラウザにAudit Vaultサーバーの証明書がないので警告が出るが、構わず進んで以下の画面が表示されればOK。

Audit Vault Serverにopcユーザーでログインし、下記のコマンドを実行してパスフレーズを取得する。

sudo -u oracle /usr/local/dbfw/bin/generate_post_install_passphrase.py

パスフレーズ入力後、下記のような初期設定になるので、スーパー管理者 -> AVADMIN、スーパー監査者 -> AVAUDITOR、パスワードは任意で保存。保存後に、AVADMINで再度ログインする
下記のAVADMIN(管理者)のコンソールにログインできればOK

Database FirewallをAudit Vault Serverに登録する

AVADMINのコンソール画面から、設定 -> セキュリティ -> 証明書にあるAudit Vault Serverの証明書をコピーする

Database Firewall Serverにopcでログインして以下を実行

//rootにスイッチ
$ sudo su -
//avs.certという名前のファイルにコピーした証明書を張り付ける。
$ vi avs.cert  <---証明書コピー

//AVSの証明書を登録
$ /opt/avdf/config-utils/bin/config-avs set avs=primary address= <Audit Vault ServerのPrivate IP> certificate=/root/avs.cert

//NTPサーバの登録
$ /opt/avdf/config-utils/bin/config-ntp set servers=61.205.120.130 sync_on_save=true enabled=true

AVADMINのコンソールからデータベース・ファイウォール -> 登録をクリックし、データベース・ファイウォールを登録する。名前 -> 任意、IPアドレス -> Database Firewall ServerのIPアドレス
登録完了

Audit Vault Serverの初期設定

Audit Vault ServerのリポジトリDBはASMで管理されており、インストール直後は収集した監査ログが格納されるEVENTDATAディスグループが10GBちょっとしかない。すぐに一杯になってしまうので、ブロック・ボリュームをAudit Vault Serverにアタッチして、ASMの領域を拡張する。

1TBくらいでブロック・ボリュームを作成
Audit Vualt Serverのコンピュートにiscsiタイプでアタッチ

Audit Vault Serverのコンピュートにopcでログインして以下を実行

//iSCSIのアタッチ (コマンドは作成したブロックボリュームからコピー)
sudo iscsiadm -m node -o new -T iqn.2015-12.com.oracleiaas:9789dd6c-48ae-473e-9df8-dfe173d148b1 -p 169.254.2.2:3260
sudo iscsiadm -m node -o update -T iqn.2015-12.com.oracleiaas:9789dd6c-48ae-473e-9df8-dfe173d148b1 -n node.startup -v automatic
sudo iscsiadm -m node -T iqn.2015-12.com.oracleiaas:9789dd6c-48ae-473e-9df8-dfe173d148b1 -p 169.254.2.2:3260 -l

//rootで実行
# /sbin/parted /dev/sdb
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) mklabel gpt <--入力
(parted) print <--入力
Model: ORACLE BlockVolume (scsi)
Disk /dev/sdb: 1100GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start  End  Size  File system  Name  Flags

(parted) mkpart primary ext3 <--入力
Start? 0GB <--入力
End? -1 <--入力
(parted) print <--入力
Model: ORACLE BlockVolume (scsi)
Disk /dev/sdb: 1100GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name     Flags
 1      1049kB  1100GB  1100GB  ext3         primary

(parted) quit　<--入力

//ASMにディスクを作成する
# /usr/sbin/oracleasm createdisk -v EVENTDATA2 /dev/sdb1

//gridユーザーでoracleに接続して、EVENTDATAのディスクグループに追加する
# su - grid
$ sqlplus / as sysasm
SQL> ALTER DISKGROUP EVENTDATA add disk 'ORCL:EVENTDATA2';
SQL> select GROUP_NUMBER,NAME,TOTAL_MB,FREE_MB from V$ASM_DISKGROUP;

GROUP_NUMBER  NAME        TOTAL_MB     FREE_MB
------------ ------------ ------------ ------------
1             EVENTDATA    1061656      1057478

AVADMINのコンソールから、設定 -> ストレージでEVENTDATAが1TBに拡張されていることを確認
In-Memoryの設定を行う。設定 -> システムからOracle Database In-Memoryをクリック。有効をチェックして、割り当てるIn-Memoryを指定して保存する。※検索パフォーマンスが大幅に向上するので、できる限り多く割り当てる

Database Firewallの初期設定

AVADMINのコンソールからデータベース・ファイウォール -> ネットワーク設定をクリック
ネットワークインターフェースをクリック
プロキシポートを追加して保存する。名前 -> proxy, ポート -> 1555 （※本来はプロキシ構成ではないので必要ないが、仕様上DBFWのNICインターフェースにプロキシポートを割り当てないとモニタリングの途中の設定ができないため)

エージェント、ホストモニターをBaseDBにインストール

AVADMINコンソールから、エージェント -> 登録をクリック
BaseDBの名前とIPアドレスと入力して保存
作成後、以下のアクティブ化キーをコピーしておく
エージェント -> ダウンロードから、Audit Vault AgentとLinux x86-64のHost Monitorをダウンロードする

ダウンロードしたエージェントのファイル(agent.jar)をBaseDBの/home/oracleにコピーして、java -jarコマンドで解凍し、エージェントを登録する。以下、oracleユーザーでの実行例

//エージェント用のディレクトリを作成してagent.jarを解凍
$ mkdir /home/oracle/avagent
$ mv agent.jar /home/oracle/avagent
$ cd avagent/
$ java -jar agent.jar
Agent installed successfully.
If deploying hostmonitor please refer to product documentation for additional installation steps.

//エージェントを登録する。アクティベーションキーは、先ほどコピーしたもの
$ cd bin/
$ ./agentctl start -k
Enter Activation Key:
BASEDB::****-****-****-****-**E9
Checking for updates...
Agent is updating. This operation may take a few minutes. Please wait...
Agent updated successfully.
Agent started successfully.

エージェント・ステータスが実行中になればOK

次にホストモニターをインストールする。ホストモニターのzipファイルをBaseDBの/home/opcにアップロードし、opcで接続して以下を実行

//ホストモニターはrootで実行する必要があるので、rootで解凍
$ sudo unzip agent-linux-x86-64-hmon-one.zip -d /usr/local

//rootユーザーにスイッチ
$ sudo su - 

//インストールに必要なパッケージを追加
yum install libcap
yum install openssl
yum install libpcap
yum install libcap-devel
yum install libpcap-devel
yum install openssl-devel
yum install libaio-devel
yum install libnsl
yum install libnsl2-devel

//ホストモニターのインストール
# cd /usr/local/hm
# ./hostmonsetup install
Agent installed at /home/oracle/avagent
Detected AV Server DB's IP - 172.16.0.96
hostmonitor installed at "/usr/local/hm" directory.
The user:group who owns the agent - oracle:oinstall
Note: To enable authentication,
To get a Signed Certificate from the Audit Vault Server
1. Transfer /usr/local/hm/hmcsr.csr file to
        /usr/local/dbfw/etc directory of AVS Server(using root credential of AVS Server)
2. At AVS Server, login as root and generate a signed cert by executing
        /usr/local/dbfw/bin/generate_casigned_hmcert.sh
3. Transfer generated hmcert.crt from AV Server to /usr/local/hm on this machine.
4. As root,on this machine run -
        a) chown root:root /usr/local/hm/hmcert.crt
        b) chmod 400 /usr/local/hm/hmcert.crt
To require a Signed Certificate for Host Monitor Connections to the Firewall
1. At DBFW, login as root and run the following command:
        cp /usr/local/dbfw/etc/controller.crt /usr/local/dbfw/etc/fw_ca.crt
        chown arbiter:arbiter /usr/local/dbfw/etc/fw_ca.crt
        chmod 400 /usr/local/dbfw/etc/fw_ca.crt
        systemctl restart monitor
2. Restart/start hostmonitor
Successfully completed hostmonitor setup.
Host Monitor is now installed.

インストールが正常に完了すれば、エージェントのホストモニタリング詳細に情報が表示される

ターゲット・データベースの設定

ターゲットからモニタリング対象とするデータベースの情報を登録する。ターゲットから新規登録
名前 -> 任意、タイプ -> Oracle Database、保存ポリシーは最短の1month online, 0 month in archive。※AVDFは収集したログを手動で削除することはできない仕様のため、テスト用途なので1か月で自動的に削除される保存ポリシーにしておく。データベース・ファイアウォール・モニタリングの追加をクリック
登録されているDatabase Firwallを選択し、モードはホスト・モニターを選択。モニタリング対象となるデータベースのIPとアドレスを追加。※サービス名を指定しても良いが、IP、ポートだけの指定だとすべてのサービスが対象となるワイルドカード扱いになるので、ここでは指定しない。詳細タブをクリック。
データベース・レスポンスの取得とフル・エラー・メッセージをチェックして保存
ファイアウォールのモニタリングの設定が完了。監査接続の詳細タブをクリック
BaseDBのIPアドレス、ポート、サービス名を入力。データベースユーザーは、とりあえずSYSTEMユーザを指定しておく。保存するとスクリプト実行等々のメッセージが出力されるが気にせず登録する
登録完了後、ステータスが稼働中になればOK。監査データの収集の追加をクリックする
監査証跡のタイプをNETWORKに指定して、エージェント・ホストと証跡の場所は選択できるものを選んで保存
最終的に下記のようにそれぞれActiveになっていればOK

これでひと通り、管理者(AVADMIN)による設定は完了です。次に監査者(AVAUDITOR)でログ取得のポリシー設定と実際に収集されるログの確認を行います。

ファイアウォール・ポリシーの設定

AVAUDITORでコンソールにログインして、ポリシーからユーザー定義のファイアウォール・ポリシーを作成
ポリシー名を入力し、右上の構成をクリック
機密データのマスキングからロギング・データのマスクのチェックを外し、保存して戻るへ。これでInsertやUpdate時の値が記録される
データベース・オブジェクトの追加をクリック
コマンドからSELECTを選択し、行数の取得をYESに、ロギング・レベルを常時に指定して保存
一番下のデフォルトのルール名をクリックして、ロギングレベルをAlwaysに変更して、ポリシーを保存する。これですべてのSQLがデフォルトで記録される

※ここでは無条件にすべてのSQLを記録する設定にしていますが、実際の本番環境等ではログが大量に取得されることになってしまうので、ポリシー内でログを取得する条件を設定してログの絞り込むことが重要です。

作成したポリシーをチェックして、ターゲットに対してデプロイする
ポリシーのデプロイ完了

実際に監査ログをキャプチャして動作を確認する

BaseDBにリモートアクセスでSQLを実行して動作を確認する。その前に、BaseDBはデフォルトでSQLNETのネイティブ・ネットワーク暗号化(NNE)がされる設定になっているので解除しておく。※NNEに対応する方法もあるが、データベースに個別パッチの適用が必要など、手順が煩雑になるので割愛する

//BaseDBにoracleユーザーで接続
$ vi  $ORACLE_HOME/network/admin/sqlnet.ora

//先頭がSQLNETのものをコメントアウトしておけばOK
NAMES.DIRECTORY_PATH=(TNSNAMES,ONAMES,HOSTNAME)
ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/opt/oracle/dcs/commonstor
e/wallets/DB0621_fnk_iad/tde)))
#SQLNET.ENCRYPTION_SERVER=REQUIRED
#SQLNET.CRYPTO_CHECKSUM_SERVER=REQUIRED
#SQLNET.ENCRYPTION_TYPES_SERVER=(AES256,AES192,AES128)
#SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER=(SHA256,SHA384,SHA512,SHA1)
#SQLNET.ENCRYPTION_CLIENT=REQUIRED
#SQLNET.CRYPTO_CHECKSUM_CLIENT=REQUIRED
#SQLNET.ENCRYPTION_TYPES_CLIENT=(AES256,AES192,AES128)
#SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT=(SHA256,SHA384,SHA512,SHA1)
#SQLNET.EXPIRE_TIME=10
WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/opt/oracle/dcs/commonstore/tcps_wallet)))
SSL_CLIENT_AUTHENTICATION=FALSE

//リスナー再起動
$ lsnrctl stop
$ lsnrctl start

SQLを実行してキャプチャされたログを確認する。BasaDB上でSQLPlusの実行ではなく、Client -> Databaseのネットワークを経由するアクセスになるように。

AVAUDITORのコンソールからレポート -> サマリ All Activityをクリック。正しく取得されていれば以下のように表示される。ENCRYPTEDというレコードがある場合は、NNEの設定が解除されていない。
レコードの詳細

取得される情報はユーザー名、IPアドレス、プログラム名、SQLテキストなどデータベースの監査とほぼ同じ。ただ、ネットワーク・キャプチャでしか取得できない要素として、以下がある。

構文エラーやオブジェクトが存在しないなどが原因で、実行に失敗したSQL文 <-- 監査ログの場合は記録されない
SELECTの結果件数

次に、SQLが漏れなく取得できているかをテストする。以下のシェルスクリプトを実行する。※非効率なSQLだが、INSERT部分をプロシージャで効率化させると監査レコードがプロシージャ実行の１行になってしまうので、あえて1行づつInsertするようにしている。

#!/bin/bash

USER=ユーザ名
PASS=パスワード
HOST=DBのIPアドレス:ポート/サービス名

sqlplus -s "$USER/$PASS@$HOST" <<EOF
CREATE TABLE TEST_TABLE(id number, name varchar2(100));
EOF

for i in $(seq 1 100); do
sqlplus -s "$USER/$PASS@$HOST" <<EOF
INSERT INTO TEST_TABLE (id, name) VALUES ($i, 'Name_$i');
COMMIT;
EXIT;
EOF
done

sqlplus -s "$USER/$PASS@$HOST" <<EOF
DROP TABLE TEST_TABLE;
EOF

オブジェクトをTEST_TABLEでフィルタしてログを検索。合計102件(CREATE TABLE=1, INSERT=100, DROP TABLE=1)が記録されていればOK。同様に、1000件、1万件など負荷をかけた場合の動作や取得率などを検証してみると良い

以上が、OCIでAVDFのホストモニターを使用する設定手順です。
ホストモニターのプロセスは、データベース・サーバー上で数%のCPU使用率で稼働するため負荷は軽めです。また、ネットワークキャプチャ方式は、ネットワーク・トラフィックの負荷やlibpcapライブラリのパフォーマンスによってはパケットロスする可能性はあるので、100%の監査ログ取得を保証しているものではありません。
データベース監査の機能を使用したエージェント方式の場合は、データベースの仕組み的に漏れなく監査ログを取得します。次回は、監査ログ機能 + エージェント方式を紹介します。