監査対象を計画するときの検討事項

サイトでの監査対象は、サイトの監査ポリシーと、時間、効率、ディスク容量などの監査コストによって決まります。監査コストの説明については、「監査のコストの管理」を参照してください。Trusted Solaris 環境に実装されている監査機能を使用する際は、次の点について検討します。

• 監査対象ごとに監査レコードが作成されるため、すぐにディスクが占有されてしまう

  最初は監査対象を少なくしておいて、監査パーティションがいっぱいになるタイミングを確認しましょう。こうすると、経験に基づいてディスクの必要量を推定したり、監査ファイルの保存の計画を立てることができます。監査トレールのサイズの見当がつけば、監査クラスを細かく設定することができます。

• 監査クラスに含まれるイベント数によって生成されるレコードの数が決まるわけではない

  file read クラスには login or logout クラスとほぼ同数のイベントがありますが、file read クラスのイベントの成功を監査するように設定すると、login or logout クラスに同様の設定をした場合に比べて、生成されるレコードの数がかなり多くなります。

• 失敗したイベントの監査では異常なイベントが検出され、成功したイベントの監査ではシステムの使用状況が監視される

  サイトポリシーでシステムの使用状況を監視するように定められている場合には、監査トレールに使用する容量を、異常なイベントを監査する場合より多めに確保しておくとよいでしょう。

• 失敗したイベントの監査では、成功したイベントの監査ほど多くのレコードが生成されない

  たとえば、熟練したユーザーで構成される Trusted Solaris システムで file read イベントの失敗を監査した場合、file read クラスのイベントの成功を監査する場合に比べて、生成されるレコードの数がかなり少なくなります。

• 監査クラスごとに構成を変えたり、新しい監査クラスを設定すると、より効率的にサイトの要件を満たすことができる。また、サイトポリシーで特に監査するよう定められていない監査イベントを除外すると、監査トレールのサイズを小さくすることができる

  たとえば、デバイス用のクラス de を作成した場合について考えましょう。デバイスを構成する際に、クラス de の成功したイベントを監査すると、構成とテストの完了したデバイスの監査レコードが得られます。すべてのデバイスが構成されたら、今度はクラス de の失敗したイベントを監査します。

• 一部のクラスを断続的に監査するように設定した場合でも、サイトの要件を満たすことができる

  たとえば、上の例の監査クラス de を断続的に監査することもできます。cron ジョブ (auditconfig(1M) コマンド) を使って、特定のクラスの監査の有効と無効を切り替えたり、別の監査フラグを動的に設定することができます。