RACデータベースのOSレベルでOracle監査を有効化する方法

はじめに

Oracle® Databaseのスーパーユーザーであるsysのすべての操作を監査したいケースは少なくありません。この要件に応えるため、Oracleはバージョン9iにおいてAUDIT_SYS_OPERATIONSパラメータを導入しました。

このパラメータをtrueに設定すると、AUDIT_FILE_DESTパラメータで指定されたディレクトリ内にファイルが生成され、sysユーザーの全操作の記録が出力されます。ただしデフォルトでは、ファイルにはsysによる接続情報のみが記録され、接続後の個々の操作までは含まれない点に注意してください。

AUDIT_SYS_OPERATIONS=trueを設定した場合、sysの全操作を含む監査ファイルの所有者は、データベースをインストールしたOSユーザー(通常はoracleユーザー)になります。ここで問題なのは、sysとして接続する権限を持つユーザーは、OSレベルでもoracleユーザーとして接続する権限を持っている可能性が高いという点です。この状況では、セキュリティの観点からAUDIT_SYS_OPERATIONSの効果が大きく損なわれます。そこでOracleは、監査ファイルの所有者をrootにすることを許可しており、これによりデータベース管理者によるファイルの改ざんや削除が困難になります。

OSレベルでの監査ファイルの構成手順

Oracle Real Application Clusters(RAC)環境でOSレベルの監査ファイルを構成するには、以下の手順を実行します。

ステップ1: データベースパラメータの設定

次のコマンドで必要な初期化パラメータを設定します。

SQL> alter system set audit_sys_operations=true scope=spfile;
System altered.

SQL> alter system set audit_syslog_level='LOCAL1.WARNING' scope=spfile;
System altered.

SQL> alter system set audit_trail = OS
SCOPE=SPFILE;
System altered.

ステップ2: RACノードの構成

rootユーザーとして、RAC1ノードとRAC2ノードの両方に対して以下の手順を実行します。

a) 次のコマンドで/etc/rsyslog.confをバックアップします。

cp -p /etc/rsyslog.conf /etc/rsyslog.conf.<ITK#>

b) /etc/rsyslog.confに次の行を追加します。

# Oracle audit <ITK#>
local1.warning /var/log/oracle/db_name_audit.log

ステップ3: syslogロガーの再起動

次のコマンドでsyslog(rsyslog)プロセスを再起動します。

service rsyslog status
service rsyslog restart
service rsyslog status

ステップ4: RACデータベースの再起動

RAC1およびRAC2上のRACデータベースを、サービスを停止させないようローリング方式で再起動します。

a) まずRAC2で以下のコマンドを実行します。

srvctl stop instance -d DB_NAME -i DB_SID2
srvctl start instance -d DB_NAME -i DB_SID2
srvctl status database -d DB_NAME

b) 10分ほど待機します。

c) 次にRAC1で以下のコマンドを実行します。

srvctl stop instance -d DB_NAME -i DB_SID1
srvctl start instance -d DB_NAME -i DB_SID1
srvctl status database -d DB_NAME

ステップ5: logrotateファイルの設定

RAC1およびRAC2でlogrotateを設定するには、rootユーザーとして/etc/logrotate.d/oracle_auditを作成・編集し、以下の内容を記述します。

/var/log/oracle/db_name_audit.log
{
   rotate 12
   compress
   weekly
   dateext
   notifempty
   missingok
   copytruncate
}

logrotateの主なパラメータ

logrotateの設定ファイルには、以下のオプション(logrotateのmanページや公式ドキュメントより)を指定できます。

• rotate: ログアーカイブを直近N世代分保持します。ディスク使用量が許容範囲内であれば大きな値を設定できます。ログの増加が激しい場合は、10日間分や2週間分といった設定も有効です。
• compress: アーカイブ済みログをgzipで圧縮します(推奨)。生のログに比べてファイルサイズを大幅に抑えられます。
• weekly: 前回のローテーションから7日以上経過した場合、または現在の曜日が前回ローテーション時の曜日より前である場合にローテーションを実行します(正確な時刻は考慮されません)。曜日の指定では0が日曜、1が月曜、6が土曜を表し、特別な値7は曜日に関係なく「7日ごと」を意味します。省略時のデフォルトは0です。
• yearly: 現在の年が前回ローテーション時と異なる場合にログをローテーションします。
• dateext: アーカイブされたログファイル名に処理日付を付加します。デフォルト形式はYYYYMMDDで、目的のアーカイブログを探しやすくなります。
• notifempty: ログファイルが空の場合はアーカイブしません。保持できるアーカイブ数には上限があるため、空ファイルが古いアーカイブを押し出してしまうのを防ぐうえで重要です。
• missingok: 対象のログファイルが見つからない場合はエラーとせず、次のログファイルの処理に進みます。これにより、一部のログが存在しない場合でもlogrotateが異常終了しません。
• copytruncate: ログをアーカイブする際、logrotateはログファイルの内容をタイムスタンプ付きの別ファイルにコピーした後、元のログファイルの内容を削除(切り詰め)ます。アプリケーションが継続的に同一のログファイルへ書き込み続ける場合に必要なオプションで、ログファイルへのアクセス不能によるプロセスの異常終了を防ぎます。

メリットとデメリット

監査レコードをOS上のファイルに書き込むことについては、以下の点を考慮する必要があります。

メリット:

監査レコードをroot所有のファイルシステムに記録することで、データベースをインストールしたoracleユーザーであっても、監査記録の閲覧や改ざんができなくなります。

デメリット:

監査ファイルをOS上に保存するとディスク容量を消費し、状況によってはパフォーマンスに影響を与える可能性があります。たとえば、catalog.sqlやcatproc.sqlのような大量の監査レコードを生成する大規模な操作をsysが実行した場合などが挙げられます。

まとめ

本記事で紹介した手順により、RACデータベースにおけるsysユーザーの監査レコードをすべてOS上のファイルに出力できます。Oracleは、特に ultra-secure(超堅牢)なデータベース構成を採用している環境では、OSレベルの監査設定を使用することを推奨しています。監査証跡をroot管理下に置くことで、内部からの改ざんリスクを最小限に抑えられますので、セキュリティ要件の厳しいシステムでの導入を検討してみてください。