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を検索し、それぞれ最新のリリースをデプロイする。
-
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 Serverにopcユーザーでログインし、下記のコマンドを実行してパスフレーズを取得する。
sudo -u oracle /usr/local/dbfw/bin/generate_post_install_passphrase.py
Database Firewallを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の領域を拡張する。
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
-
In-Memoryの設定を行う。設定 -> システムからOracle Database In-Memoryをクリック。有効をチェックして、割り当てるIn-Memoryを指定して保存する。※検索パフォーマンスが大幅に向上するので、できる限り多く割り当てる

Database Firewallの初期設定
- AVADMINのコンソールからデータベース・ファイウォール -> ネットワーク設定をクリック
- ネットワークインターフェースをクリック
- プロキシポートを追加して保存する。名前 -> proxy, ポート -> 1555 (※本来はプロキシ構成ではないので必要ないが、仕様上DBFWのNICインターフェースにプロキシポートを割り当てないとモニタリングの途中の設定ができないため)
エージェント、ホストモニターをBaseDBにインストール
ダウンロードしたエージェントのファイル(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.
次にホストモニターをインストールする。ホストモニターの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ユーザを指定しておく。保存するとスクリプト実行等々のメッセージが出力されるが気にせず登録する

これでひと通り、管理者(AVADMIN)による設定は完了です。次に監査者(AVAUDITOR)でログ取得のポリシー設定と実際に収集されるログの確認を行います。
ファイアウォール・ポリシーの設定
-
機密データのマスキングからロギング・データのマスクのチェックを外し、保存して戻るへ。これでInsertやUpdate時の値が記録される

-
一番下のデフォルトのルール名をクリックして、ロギングレベルを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行になってしまうので、あえて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%の監査ログ取得を保証しているものではありません。
データベース監査の機能を使用したエージェント方式の場合は、データベースの仕組み的に漏れなく監査ログを取得します。次回は、監査ログ機能 + エージェント方式を紹介します。




























