audit_user ファイル

ユーザーごとに異なる方法で監査するには、audit_user ファイルを編集して、ユーザーごとに監査フラグを追加します。これらの監査フラグが指定されている場合は、audit_control ファイルのシステム全体で有効なフラグと組み合わせ、そのユーザーに対して監査するイベントクラスが決定されます。audit_user ファイル内のユーザーエントリに追加するフラグは、audit_control ファイルにあるデフォルトを次の 2 つの方法で変更します。

• そのユーザーについて監査しないイベントクラスを指定する

• そのユーザーについて常に監査するイベントクラスを指定する

audit_user ファイルの各ユーザーエントリには、次の 3 つのフィールドがあります。

• username フィールド

• always-audit フィールド

• never-audit フィールド

これらの監査フィールドは、この順番で処理されます。監査機能を有効にするときは、 always-audit フィールドを使用し、無効にするときは、never-audit フィールドを使用します。

never-audit フィールド内で all 監査フラグを設定したままにする誤りがよくあるので注意してください。all 監査フラグを指定したままにすると、そのユーザーの監査がすべてオフに設定され、always-audit フィールドに設定されているフラグが無効になります。

ユーザーに never-audit フラグを使用することと、always-audit の設定からクラスを削除することとは異なります。たとえば、ファイルシステムオブジェクトが正常に読み込まれた場合を除いて、ユーザー tamiko のすべてのイベントを監査するとします。この場合、ユーザー tamiko のほとんどのイベントが監査されます。ただし、監査データは、すべてのデータ読み込みを監査した場合の約 4 分の 3 しか生成されません。システムデフォルトを tamiko に適用することもできます。次に 2 つの audit_user エントリを示します。

正しいエントリ

tamiko:all,^+fr:

間違ったエントリ

tamiko:all:+fr

1 つ目の例は、「ファイルの読み込みが成功した場合を除き、常にすべての動作を監査する」ことを表しています。2 つ目の例は、「常にすべての動作を監査するが、ファイルの読み込みに成功した場合はまったく監査しない」ことを表しています。2 つ目の例はシステムのデフォルト値が無効になるため、正しいエントリではありません。1 つ目の例では期待どおりの結果になります。つまり、audit_user エントリで指定した内容の他に、システムデフォルト値が適用されます。

正常終了したイベントと失敗したイベントは別々に取り扱われるので、プロセスが生成する監査レコードのボリュームは、そのイベントが正常終了したときよりも、失敗したときの方が多くなることがあります。