SunSHIELD 基本セキュリティモジュール

監査トレールについて

この節では、監査ファイルの格納場所、命名方法、分散システム全体で監査ファイルの記憶領域を管理する方法について説明します。

監査トレールは、監査デーモン auditd が起動されるときに作成され、新しい監査ファイルが作成されたとき、または監査デーモンが終了するときに閉じられます。監査トレールは複数の監査ディレクトリ内の監査ファイルから構成される場合や、監査ディレクトリに複数の監査トレールが入っている場合があります。

ほとんどの場合監査ディレクトリは、別個の監査ファイルシステムパーティションになります。他のファイルシステムに組み込むこともできますが、この方法はお勧めできません。

原則として、一次監査ディレクトリは別のパーティションにマウントされた専用の監査ファイルシステム内に配置します。通常、すべての監査ファイルシステムは /etc/security/audit のサブディレクトリです。これらのファイルシステムは、監査ディレクトリが監査ファイルでいっぱいになっても、パーティションをそのまま通常どおり使用できるように、専用の監査ファイルシステムにする必要があります。

監査ディレクトリは、監査専用でない他のファイルシステム内に物理的に配置することもできますが、最後の手段として確保しているディレクトリを除き、この方法は使用しないでください。最後の手段として確保しているディレクトリとは、他の適切なディレクトリが使用できないときに限り監査ファイルが書き込まれるディレクトリです。また、専用の監査ファイルシステムの外側に監査ディレクトリを配置できるのは、監査機能がオプションで、監査トレールを保存することよりもディスクをフル活用することの方が重要なソフトウェア開発環境などです。セキュリティが重視される実行環境では、監査ディレクトリを他のファイルシステム内に入れることは許されません。

ディスクフルマシンには、少なくとも 1 つはローカルの監査ディレクトリを用意する必要があります。このディレクトリは、監査サーバと通信できない場合に、最後の手段として確保しているディレクトリとして使用できます。

監査ディレクトリは、読み取り/書き込み (rw) オプションを使用してマウントしてください。監査ディレクトリをリモートで (NFS を使用して) マウントするときは、intr オプションも使用してください。監査ファイルシステムを、格納先の監査サーバ上でリストしてください。エクスポートリストには、監査サーバを使うよう構成されたすべてのマシンが含まれるはずです。

監査ファイルシステムを、格納先の監査サーバ上でリストしてください。エクスポートリストには、監査サーバを使うよう構成されたすべてのマシンが含まれるはずです。

監査ファイルの詳細

各監査ファイルは、それ自身で意味がわかるレコードの集合です。ファイル名には、レコードが生成された時間の範囲と、それを生成したマシン名が含まれます。

監査ファイルの命名

完全な監査ファイルには、次の書式の名前が付いています。

start-time.finish-time.machine

この場合、start-time は監査ファイル内の最初の監査レコードの生成時刻、finish-time は最後のレコードの生成時刻、machine はファイルを生成したマシンの名前です。監査ファイルの名前の例については、「閉じられた監査ファイルの名前の例」を参照してください。

監査ログファイルがまだアクティブな場合は、次の書式の名前が付いています。

start-time.not_terminated.machine

監査ファイル名の使用方法

auditreduce は、ファイル名のタイムスタンプを使用して、要求された特定期間内のレコードが入ったファイルを検索します。このタイムスタンプが重要なのは、1 カ月分以上の監査ファイルがオンライン上に存在する可能性があり、24 時間以内に生成されたレコードをすべて検索するとコストが大きくなりすぎるからです。

タイムスタンプの書式と意味

start-time と end-time は 1 秒単位のタイムスタンプで、グリニッジ標準時で指定されます。その書式は、次のように年が 4 桁で、月、日、時、分、秒が 2 桁ずつになっています。

YYYYMMDDHHMMSS

このタイムスタンプにはグリニッジ標準時が使用されるので、夏時間によるずれがあっても正しい順序でソートされることが保証されます。また、グリニッジ標準時が使用されるので、日時を把握しやすいように現在の時間帯に変換しなければなりません。監査ファイルを auditreduce ではなく標準ファイルコマンドで操作するときには、この点に注意してください。

まだアクティブなファイルの名前の例

まだアクティブなファイル名の書式は次のとおりです。

YYYYMMDDHHMMSS.not_terminated.hostname

次の例を参照してください。

19900327225243.not_terminated.lazy

監査ログファイルの名前には開始日が使用されるので、上記の例はグリニッジ標準時の 1990 年 3 月 27 日午後 10:52:43 から始まったことがわかります。ファイル名のうち not_terminated は、このファイルがまだアクティブであるか、または auditd が予期しないときに割り込まれたことを意味します。末尾の名前 lazy は、監査データが収集されているホストの名前です。

閉じられた監査ファイルの名前の例

閉じられた監査ログファイルの名前の書式は次のとおりです。

YYYYMMDDHHMMSS.YYYYMMDDHHMMSS.hostname

次の例を参照してください。

19900320005243.19900327225351.lazy

上記の例は、グリニッジ標準時の 1990 年 3 月 20 日の午前 12:52:43 に始まったことがわかります。このファイルは、グリニッジ標準時の 3 月 27 日午後 10:53:51 に閉じられました。末尾の名前 lazy は、監査データが収集されているマシンのホスト名です。

auditd が予期しないときに割り込まれるといつも、その時点で開いていた監査ファイルは not_terminated で終わるファイル名タイムスタンプを取得します。また、マシンがリモートでマウントされた監査ファイルに書き込んでいるときに、ファイルサーバがクラッシュするか、またはアクセスできなくなると、not_terminated で終わるタイムスタンプがカレントファイルの名前に付いたままになります。監査デーモンは、古い名前の監査ファイルをそのまま残して新しい監査ファイルを開きます。

`not_terminated` マークが付いたアクティブでないファイルの処理

auditreduce コマンドは、not_terminated マークが付いたファイルを処理しますが、この種のファイルの終わりには不完全なレコードが入っていることがあるので、それ以上処理するとエラーが発生する可能性があります。エラーを防ぐには、不完全なレコードが入っているファイルを整理してください。ファイルを整理する前に、そのファイルに auditd が書き込み中でないかどうかを確認してください。チェックするには、audit_data ファイルを調べて auditd の現在のプロセス番号を確認します。そのプロセスがまだ実行中で、audit_data 内のファイル名が問題のファイルと同じ場合は、そのファイルを整理しないでください。

auditreduce で -O オプションを使用するとファイルを整理できます。これによって、古いファイル内のすべてのレコードが入った新しいファイルが作成され、正しいファイル名タイムスタンプが付けられます。この処理を実行すると、各監査ファイルの先頭に付いていた以前のファイルポインタは失われます。

または、ファイル全体を読み取り、最後のレコードを突き止めてファイル名を変更し、不完全なレコードを整理するプログラムを作成することもできます。また、以前のファイルポインタをそのまま残し、次にどのファイルを使用するかを決定するプログラムも作成できます。

監査パーティションを作成してエクスポートする方法

各マシンに少なくとも 1 つの「一次監査ディレクトリ」を割り当てます。

一次監査ディレクトリは、通常の条件下でマシンが監査ファイルを配置するディレクトリです。

一次監査ディレクトリとは異なる監査ファイルサーバ上で、各マシンに少なくとも 1 つの「二次監査ディレクトリ」を割り当てます。

二次監査ディレクトリは、一次ディレクトリがいっぱいになった場合や、ネットワーク障害、NFS サーバのクラッシュなどの原因でアクセスできなくなった場合に、マシンが監査ファイルを配置するディレクトリです。

各ディスクフルマシン上で、最後の手段として確保するローカルの監査ディレクトリ (できれば専用の監査ファイルシステム) を作成します。このディレクトリは、ネットワークにアクセスできなくなったときや、一次と二次のディレクトリが使用できないときに使用されます。

一次と二次の宛先として使用するディレクトリを、システム内の監査サーバに均等に分散させます。

この節で説明した要件に従って監査ファイルシステムを作成します。

/etc/security ディレクトリには、すべての監査ファイルと、監査制御に関連する他のファイルがいくつか入ったサブディレクトリがあります。/etc/security ディレクトリにはマシンごとの audit_data ファイルが入っており、ブート時に監査デーモンを正常に起動するには、このファイルが使用可能でなければならないので、/etc/security ディレクトリがルートファイルシステムになければなりません。

監査用の事後選択ツールは、デフォルトで /etc/security/audit の下のディレクトリ内を検索します。このため、監査サーバ上の最初の監査ファイルシステムのマウントポイントに使用するパス名は、/etc/security/audit/server-name です (この場合、server-name は監査サーバ名)。監査サーバ上に複数の監査パーティションがある場合、2 番目のマウントポイントの名前は /etc/security/audit/server-name.1、3 番目の名前は /etc/security/audit/server-name.2 というようになります。

たとえば、監査サーバ winken 上で使用可能な監査ファイルシステムの名前は、/etc/security/audit/winken と /etc/security/audit/winken.1 になります。

この監査サーバ上では、各監査ファイルシステムに files というサブディレクトリもなければなりません。この files サブディレクトリに監査ファイルが格納され、auditreduce コマンドによって検索されます。たとえば、監査サーバ winken 上の監査ファイルシステムには files サブディレクトリがあり、その完全パス名は /etc/security/audit/winken/files となります。

各マシン上のローカルの audit_control ファイルが、監査ファイルに対して files サブディレクトリに監査ファイルを格納するように指示しているかどうかを確認する必要があります。次の例は、eagle から監査ファイルシステムをマウントしているマシン上の audit_control ファイルの dir: 行を示しています。

dir: /etc/security/audit/eagle/files

監査サーバ上で (何らかの理由で) /etc/security/audit/server-name[.suffix] ディレクトリが使用できないときに、マシンのローカルルートファイルシステムが監査ファイルでいっぱいになるのを防ぐには、別の階層レベルが必要です。監査サーバ上には files サブディレクトリがあり、どのクライアントにも files サブディレクトリがないため、マウントに失敗した場合に監査ファイルをローカルのマウントポイントディレクトリ上で自動的に作成できなくなります。

各監査ディレクトリに監査ファイル以外のデータが入っていないかどうかを確認してください。

監査ファイルシステムに必要な許可を割り当てます。

下記の表 2-5 は、/etc/security/audit/server-name ディレクトリと、その下に必ず作成する files ディレクトリ上になければならない許可を示しています。
表 2-5 監査ファイルの許可

所有者

グループ

許可

root

staff

2750

所有者	グループ	許可
root	staff	2750

`audit_control` ファイルのエントリの例

audit_control ファイルに dir: エントリを追加するときは、files サブディレクトリまでの完全パスを指定しなければなりません。次の例は、監査ファイルが専用のローカルディスクに格納されるサーバ blinken に関する audit_control ファイルの dir: エントリを示しています。

# cat /etc/security/audit_control
dir:/etc/security/audit/blinken.1/files
dir:/etc/security/audit/blinken.2/files

監査を構成する方法

次の手順は、監査ディレクトリを設定し、監査の対象となる監査クラスを指定するために必要な操作の概要を示しています。

ディスクをフォーマットし、パーティションに分割して、専用の監査パーティションを作成します。

経験では、分散システム上に配置するマシンごとに 100 M バイトを割り当てることになっています。ただし、どれくらいのディスク容量が自分のサイトに必要かは、どの程度の監査を実施するかによって異なり、マシン 1 台当り 100 M バイトをはるかに上回るようなこともあります。

監査ファイルシステムを専用パーティションに割り当てます。

NFS でマウントされた監査ファイルシステムを使用できない場合に備えて、ディスクフルマシンごとにローカルマシン上でバックアップ監査ディレクトリを作成しておく必要があります。

各マシンがシングルユーザモードになっている間に、各専用監査パーティション上で tunefs -m 0 を実行して、予約済みのファイルシステム領域を 0 パーセントに縮小します。

予約領域のパーセンテージ (minfree 制限と呼びます) は、audit_control ファイル内で監査パーティションに関して指定されています。デフォルトは 20 パーセントですが、このパーセンテージは調整できます。この値はサイトごとに audit_control ファイル内で設定するので、すべてのファイルシステム用にデフォルトで自動的に予約され確保されているファイルシステム領域を削除する必要があります。

監査サーバ上で各監査ディレクトリに必要な許可を設定し、各監査ディレクトリ内で files というサブディレクトリを作成します。

chown と chmod を使用して、各監査ディレクトリと各 files サブディレクトリに必要な許可を割り当てます。

監査サーバを使用している場合は、/etc/dfs/dfstab ファイルと一緒に監査ディレクトリをエクスポートします。

files サブディレクトリを指定して、各マシン上の audit_control ファイル内にすべての監査ディレクトリに関する audit_control ファイルエントリを作成します。

各監査クライアント上で、/etc/vfstab ファイル内に監査ファイルシステムに関するエントリを作成します。

各監査クライアント上で、マウントポイントのディレクトリを作成し、chmod と chown を使用して適切な許可を設定します。

監査構成の計画を立てる方法

まず、監査トレール記憶領域の計画を作成します。

/etc/security/audit_class ファイル内で、サイトで必要なクラスを定義します。

デフォルトのクラスが適切であれば、新しいクラスを定義する必要はありません。audit_class(4) のマニュアルページを参照してください。

/etc/security/audit_event 内でイベントとクラスのマッピングを設定します。

デフォルトのマッピングがサイトのニーズに合っている場合は、この手順は不要です。audit_event(4) のマニュアルページを参照してください。

サイトで必要な監査の程度を決定します。

サイトのセキュリティ上のニーズを考慮して、監査トレールの格納に必要なディスク領域を決定します。

サイトのセキュリティを確保しながら記憶領域の要件を削減する方法と、監査記憶領域を設定する方法のガイドラインについては、「監査コストの制御」、「効率的な監査」、「監査トレールについて」を参照してください。

どのマシンを監査サーバとして使用し、どのマシンを監査サーバのクライアントとして使用するかを決定します。

監査ファイルシステムの名前と位置を決定します。

どのマシンが監査サーバ上のどの監査ファイルシステムを使用するかの計画を作成します。

記憶領域の計画を作成したら、監査の対象となるユーザと監査内容を決定します。

システム単位で監査したい監査クラスと、監査クラスの選択に使用するフラグを決定します。

一部のユーザを他のユーザより詳しく監査するかどうかを決定し、ユーザの監査特性の変更に使用するフラグを決定します。

詳細は、「プロセスの監査特性」を参照してください。

最小空き領域 (minfree) を決定します。これは弱い制限値とも呼ばれ、警告が送られる前に監査ファイルシステム上に残っていなければならない空き領域です。

使用可能な容量が minfree のパーセンテージを下回ると、監査デーモンは次の適切なファイルシステムに切り替えて、弱い制限値を超えたことを示す通知を送ります (適切な監査ファイルシステムについては、「監査デーモンが使用できるディレクトリ」を参照)。

デフォルトでは、各マシン上で一定の程度の監査が構成されます。デフォルトの audit_control ファイルには、表 2-6 の各行が入っています。各行によって、監査ディレクトリが /var/audit として設定され、システムワイドな監査フラグ (lo) が 1 つ設定され、minfree のしきい値が 20 パーセントに設定され、非帰因フラグが 1 つ設定されます。
表 2-6 audit_control ファイル内のエントリ
dir:/var/audit flags:lo minfree:20 naflags:ad

/etc/security/audit_control ファイルを編集します。
1. このマシン上でどの監査ファイルシステムを監査トレールの格納に使用するかを指定します。
  
  監査ディレクトリごとに dir: エントリをカレントマシンで使用できるようにします。分散システムの監査ディレクトリ方式を設定する方法については、「監査トレールについて」を参照してください。
2. flags: フィールド内で、すべてのユーザのプロセスに適用されるシステムワイドな監査フラグを指定します。
  
  flags: フィールドで指定したシステムワイドな監査フラグは、すべてのユーザのプロセスに適用されるので、各マシン上で同じフラグを設定する必要があります。
3. 必要であれば、minfree のパーセンテージを変更して監査のしきい値を拡大または縮小します。
4. 特定のユーザに帰因しないイベントに適用される naflags: を指定します。

変更が必要であれば、auditconfig を使用して監査方針を変更します。

auditconfig(1M) のマニュアルページ、または「auditconfig コマンド」を参照してください。方針を指定する変数は動的なカーネル変数なので、その値はシステムの終了時に保存されません。したがって、適切な起動スクリプトを使用して目的の方針を設定する必要があります。

cnt 方針を設定するか、または監査管理アカウントを設定します。

監査トレールがあふれた場合に備えて、システムを引き続き機能させられるように cnt 方針を使用可能にするか、または監査されなくても機能できるようにアカウントを 1 つ使用可能にしなければなりません。このアカウントを設定する手順は次のとおりです。
1. /etc/passwd ファイルに次のエントリを追加します。
```
audit::0:1::/:/sbin/sh
```
  注 -
  このエントリは、root が所有するプロセスを正常に機能させるために、root ユーザのエントリの下に追加しなければなりません。
2. 対応するエントリを /etc/shadow ファイルに追加するには、次のように入力します。
```
# pwconv
pwconv: WARNING user audit has no password
```
  監査アカウントのパスワードは手順 d. で設定します。
3. /etc/security/audit_user ファイルに次のエントリを追加して、このアカウントの監査をオフにします。
  audit:no:all
4. passwd を使用して新しいアカウントのパスワードを設定します。
  # passwd audit
  このアカウントを通じて実行される処置は監査の対象外なので注意してください。システムの完全性を保護するには、簡単には推測できないパスワードを使用してください。この例では、アカウント名として audit を使用しています。アカウントを設定する場合は、サイトに適した名前を選択してください。