監査の計画と設定

サイトに適した監査を設定する前に次の作業を行います。

• サイトに追加するクラスやイベントなど、監査の対象となるイベントクラスを決定する

• 監査情報の格納先を計画する

• 監査構成ファイルを定義する

監査クラス

まず、監査の対象となるイベントを決定します。監査では、ユーザーアクションや、原因を特定できないイベント (割り込みなど、特定のユーザーが原因とは考えられないイベント) を取り出すことができます。ユーザーアクションについては、成功したトランザクションと失敗したトランザクションに分けることができます。監査イベントは、Trusted Solaris に定義されたクラスに編成されます。ファイルの監査クラスは、次のような一般領域に分類されます。

• 読み取り用で開く

• 書き込み用で開く

• 属性の変更

• 作成

• 削除

必要に応じて独自のクラスやイベントを作成したり、イベントとクラスの対応関係を再編成することもできます。そのほかのクラスが追跡するイベントには、プロセス操作、ネットワークイベント、ウィンドウ操作、IPC 操作、管理処理、ログイン、ログアウト、アプリケーション特有のイベント、ioctl システムコール、プログラムの実行、X サーバーの操作など、さまざまなイベントがあります。監査情報の記録には、かなりの容量が必要となるため、監査対象とするイベントは慎重に決定し、サイトのセキュリティポリシーに不可欠なイベントに対応したクラスだけを選択するようにします。

公開オブジェクト

監査情報の量を減らすには、特定のファイルとディレクトリを「公開オブジェクト」として指定するのが効果的です。公開オブジェクトは一般に読み取り専用の情報を保持し、通常のユーザーでは変更できないようになっています。また、セキュリティ上の制約がないため、オブジェクトにアクセスしたユーザーを追跡する必要はありません。システムクロックなどが公開オブジェクトの良い例です。公開オブジェクトであることを示す公開オブジェクトフラグを設定すれば、そのオブジェクトを指定する監査フラグがあっても無視されます。

監査情報の格納

監査には大量のディスク容量が必要になるため、情報の収集先は慎重に考えてください。

ネットワークに接続されていない個別のワークステーションを使用しているサイトでは、ワークステーションごとに監査レコード専用のディスクを用意するのが良いでしょう。専用ディスクには、次の 2 つの領域を設定する必要があります。

• 主記憶領域

• オーバーフローしたレコードを保持する領域

ワークステーションがネットワークに接続されている場合は、監査情報を収集する専用のサーバーを少なくとも 1 台、監査データの管理と分析専用のサーバーを 1 台設置する必要があります。

いずれの場合も、データの完全性を維持し、セキュリティ違反を防止するため、監査ファイルとディレクトリを MAC と DAC によって保護する必要があります。

監査構成ファイル

サイトで実施する監査の仕様は、/etc/security サブディレクトリにある次の構成ファイルに格納されます。

• audit_control(4) - 監査制御情報を格納する。監査制御情報には、監査情報を格納するディレクトリの優先順位 (ディレクトリには最低空き容量が規定されており、残量が指定した値以下になると警告が発生します。残量がしきい値に達すると、監査デーモンは次のディレクトリに監査レコードを格納します)、最低空き容量を警告するしきい値、監査対象クラスを示すシステム全体の監査フラグ、ユーザーアクションによらないイベントを示す特別な監査フラグなどがあります。このファイルに設定する監査フラグは、すべてのユーザーに適用されます。それ以外のフラグは、ユーザーごとに audit_user ファイルに設定します。

• audit_user(4) - audit_control ファイルに設定した監査仕様が適用されないユーザーの監査基準を格納する。ユーザー名、常に監査されるイベント、監査されないイベントなどの情報が格納されます。

• audit_class(4) - 監査クラスの定義を格納する。クラスマスク (追跡すべきクラスを判定するためのフィルタ) やクラス名などが格納されます。

• audit_event(4) - 監査イベント情報を格納する

イベント番号、イベント名、監査クラスを識別する監査フラグなどが格納されます。ネットワークの監査を設定する場合は、各ワークステーションで同じ audit_user、audit_class、audit_event ファイルを使用する必要があります。