例外的な監査を実施するユーザー

セキュリティ管理者は、デフォルト構成の監査を設定します。audit_control ファイルに規定したシステム全体の監査フラグで、ユーザーと管理者全員を監査することができます。ここで、ユーザーごとに監査内容を微調整するためには、audit_user ファイルにユーザーエントリを追加します。新規ユーザーを追加する際に監査フラグを追加することもできます。監査の設定は、アカウントのロックを解除し、新規ユーザーのセキュリティ属性を設定してから行なってください。

1 台のワークステーション上の静的監査データベース (audit_control、audit_user、audit_startup、および audit_warn) を変更した場合は、変更をネットワーク上のすべてのワークステーションにコピーしてください。「監査構成ファイルをネットワーク上の各ワークステーションに配布する方法」を参照してください。

静的データベースにユーザー単位の監査管理情報を記述できるのはもちろんですが、ワークステーションでユーザープロセスが実行されている間でも、監査の条件を動的に調整することができます。

audit_user ファイル

一部のユーザーに対して他と異なる監査を行うことが望ましい場合には、管理者は、audit_user ファイルを編集して個々のユーザーに監査フラグを追加することができます。ここで指定したフラグと、監査管理ファイルに規定されているシステム全体のフラグとの組み合わせで、そのユーザーを監査するイベントクラスが決まります。管理者は、audit_user ファイルのユーザーエントリにフラグを追加して、audit_control ファイルのデフォルトを変更します。そのとき、そのユーザーについては監査をまったく行わないイベントクラスのセットが規定されるか、常に監査を行うイベントクラスのセットが規定されるかのどちらかになります。

したがって、個々のユーザーの監査内容は、次に示すとおり、ワークステーションの監査フラグと、ユーザーの常時監査実行フラグ、監査回避フラグの組み合わせとなります。

監査内容 = (ワークステーションの監査フラグ + ユーザーの常時監査実行フラグ) - ユーザーの監査回避フラグ　

audit_user ファイルはユーザーごとに設定します。このファイルのエントリには 3 つのフィールドがあり、順に、「ユーザー名」フィールド、「常時監査実行」フィールド、「監査回避」フィールドといいます。

後の 2 つの監査フィールドは順番に処理されます。最初のフィールドで監査が有効になり、2 番目のフィールドで監査が無効になります。

「監査回避」フィールドには all を設定しないでください。「常時監査実行」フィールドのフラグ設定が打ち消され、そのユーザーの監査がすべて無効になってしまいます。

「監査回避」フラグをユーザーに適用することと、「常時監査実行」 のセットからクラスを削除することは異なります。たとえば、下の例では、katya というユーザーに対して、ファイルシステムのオブジェクトの読み取りの成功を除くすべての監査を行います (この設定では、すべてのデータ読み込みを監査する場合の約 3/4 の監査データを生成するだけでユーザーの行動のほぼ全部を監査できます)。同時にシステムデフォルトを katya に割り当てるとすると、audit_user のエントリには次の 2 通りが考えられます。

正しい設定は次のようになります。

katya:all,^+fr:

次の設定は誤りです。

katya:all:+fr

最初の例では、「ファイルの読み取り成功以外すべてを常時監査する」ということを表し、2 番目の例では「全部を常時監査するが、成功したファイル読み取りの監査は行わない」ということを表します。2 番目の例が誤りなのは、この設定がシステムデフォルトより優先されるためです。一方、最初の例では、audit_user に規定した内容とともに、それ以前のデフォルトも適用されるので、期待通りの結果が得られます。

成功イベントと失敗イベントは別々に扱われます。たとえば、エラーが発生した場合にプロセスから生成される監査レコードの数が、イベントが成功した場合より多くなることがあります。

動的制御では、プロセスの実行中に管理者が所定の場所に入力した命令が参照されます。この制御は、プロセスとその子プロセスが存在する間だけ継続し、次にログインするときには無効になります。監査コマンドは、現在ログインしているワークステーションだけに適用されるので、複数台のワークステーションで動的制御を行うことはできません。

各プロセスには、監査クラス用として 1 ビットのフラグが 2 セットあります。そのうちの 1 セットでは、クラス内のイベントの要求が成功した場合にプロセスを監査するかどうかを制御し、もう一方のセットでは、イベントを要求しても何らかの理由で失敗した場合に監査するかどうかを制御します。プロセスの監査にあたっては、一般に、成功よりも失敗の方がより重点的に監査されます。これは、監査結果を利用して、ブラウズしたり、システムのセキュリティを破ろうとする各種の行為を検知するためです。