監査プロセスでは、次のファイルが使用されます。
/etc/system ファイルには、カーネルが初期設定で読み込み、システム動作をカスタマイズするためのコマンドが格納されます。bsmconv および bsmunconv シェルスクリプトは、監査機能を起動および終了するときに使用され、/etc/system ファイルを変更します。bsmconv シェルスクリプトは、/etc/system ファイルに次の行を追加します。
set c2audit:audit_load=1 set abort_enable=0 |
最初のコマンドは、システムのブート時に、読み込み可能なカーネルモジュール (監査モジュール) c2audit を読み込みます。2 番目のコマンドは、Stop-A を使用不可にします。Stop-A を使用すると、システムを停止して、デバッガが起動し、セキュリティ違反が発生する可能性があります。bsmunconv シェルスクリプトでは、2 つの行を削除し、システムをリブートすると監査が無効になります。
audit_class ファイルには、既存の監査クラスの定義が含まれます。監査クラスは、監査イベントのグループです。各監査クラスには、クラスの短縮名として監査フラグが関連付けられます。audit_control ファイル内のこの短縮名を使用して、監査するイベントのクラスを事前選択します。このとき、+ または – を接頭辞として使用します。スーパーユーザー、またはそれと同等の役割を持つ管理者は、新しい監査クラスを定義したり、既存のクラス名を変更したりすることができます。また、vi、ed などのエディタを使用して、既存のクラスを編集することもできます。詳細は、audit_class(4)のマニュアルページを参照してください。監査フラグについては、監査フラグの定義を参照してください。
各マシン上の audit_control ファイルは、監査デーモンによって読み込まれます (audit_control(4) のマニュアルページを参照)。audit_control ファイルは /etc/security ディレクトリにあります。各マシンには固有の audit_control ファイルがローカルに割り当てられるため、監査ファイルシステムはさまざまな場所からさまざまな順序でマウントできます。たとえば、マシン A の一次監査ファイルシステムは、マシン B の二次監査ファイルシステムであることがあります。
audit_control ファイルには、次の 4 種類の情報を指定します。
「監査フラグ行 (flags:)」に指定する監査フラグでは、マシン上のすべてのユーザーを対象に監査するイベントクラスを事前選択します。ここで指定する監査フラグは、「マシン全体の監査フラグ」または「マシン全体の監査事前選択マスク」と呼びます。監査フラグは、空白を入れずにコンマで区切ります。
「帰属不可能フラグ行 (naflags:)」に指定する監査フラグでは、特定のユーザーに起因しない動作が発生したときに、監査するイベントクラスを事前選択します。監査フラグは空白を入れずにコンマで区切ります。
「監査しきい値行(minfree:)」では、すべての監査ファイルシステムに確保する最小空き領域のレベルを定義します。minfree の割合は、0 以上で指定します。デフォルトは 20% です。
「ディレクトリ定義行 (dir:)」では、監査ログファイルを格納するためにマシンが使用する監査ファイルシステムとディレクトリを定義します。1 行または複数行でのディレクトリを定義できます。dir: 行では、順番が重要になります。auditd デーモンは、ここで指定した順番でディレクトリに監査ファイルを作成します (audit(1M) のマニュアルページを参照)。1 番目のディレクトリがそのマシンの 1 次監査ディレクトリになり、2 番目のディレクトリが 2 次監査ディレクトリになります。1 番目のディレクトリがいっぱいになると、監査デーモンは 2 番目以降のディレクトリに監査トレールファイルを作成します。
audit_controlファイルは、各マシンを構成するときに作成されます。
audit_control ファイルを変更したときは、audit -s を実行すると、監査デーモンによってファイルが再度読み取られます。
audit -s コマンドでは、既存のプロセスについて指定された事前選択マスクは変更されません。既存のプロセスについては auditconfig、setaudit (getaudit(2) のマニュアルページを参照)、または auditon を使用します。
次の例は、マシン dopey で使用する audit_control ファイルです。dopey では、監査サーバー blinken 上で 2 つの監査ファイルシステムを使用し、2 つ目の監査サーバー winken からマウントされる 3 つ目の監査ファイルシステムを使用します。3 つ目のファイルシステムは、blinken 上の監査ファイルシステムがいっぱいであるか使用できないときにだけ使用されます。20% に指定された minfree の値は、ファイルシステムが 80% まで使用され、次に利用できる監査ディレクトリがあればそこに現在のマシンの監査データが格納される場合に、警告スクリプトを実行するように指示します (audit_warn(1M) のマニュアルページを参照)。このフラグによって、すべてのログインと管理操作が正常に終了するかどうかにかかわらず監査されることと、ファイルシステムオブジェクトの作成に失敗した場合を除き、すべての種類の失敗が監査されることが指定されます。
flags:lo,ad,-all,^-fc naflags:lo,nt minfree:20 dir:/etc/security/audit/blinken/files dir:/etc/security/audit/blinken.1/files # # Audit filesystem used when blinken fills up # dir:/etc/security/audit/winken |
auditd デーモンは、各マシン上で起動されると、ファイル /etc/security/audit_data を作成します。 このファイルの書式は、1 つのエントリに、コロンで区切られた 2 つのフィールドで構成されます (audit_data(4) のマニュアルページを参照)。最初のフィールドには、監査デーモンのプロセス ID を指定します。2 番目のフィールドには、監査デーモンが監査レコードを現在書き込んでいる監査ファイルのパス名を指定します。次に例を示します。
# cat /etc/security/audit_data 116:/etc/security/audit/blinken.1/files/19990320100002.not_terminated.dopey |
audit_event ファイルは、/etc/security ディレクトリに配置され、イベントとクラスのデフォルトの割り当てが格納されます (audit_event(4)のマニュアルページを参照)。このファイルを編集して、クラスの割り当てを変更できます。ただし、変更した場合は、システムをリブートするか auditconfig -conf を実行して、変更した割り当てをカーネルに読み込む必要があります。
監査を使用可能にするには、監査デーモン auditd を起動します。監査デーモンを起動するには、スーパーユーザーまたは同等の役割を持って /usr/sbin/auditd を実行します。詳細については、auditd(1M)のマニュアルページを参照してください。
ファイル /etc/security/audit_startup が存在する場合、システムがマルチユーザーモードに移行すると、自動的に監査デーモンが動作します。このファイルは、監査デーモンを実行する前に起動シーケンスの一部として起動される実行可能スクリプトです (audit_startup(1M) のマニュアルページを参照)。デフォルトの audit_startup スクリプトは、イベントとクラスの割り当てを自動的に構成して、BSM パッケージをインストールしたときに作成された監査ポリシーを設定します。
ユーザーごとに異なる方法で監査するには、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 エントリで指定した内容の他に、システムデフォルト値が適用されます。
正常終了したイベントと失敗したイベントは別々に取り扱われるので、プロセスが生成する監査レコードのボリュームは、そのイベントが正常終了したときよりも、失敗したときの方が多くなることがあります。
監査デーモンは、監査レコードの書き込み中に異常な状態が発生すると、/etc/security/audit_warn スクリプトを起動します。詳細については、audit_warn(1M) のマニュアルページを参照してください。このスクリプトを環境に合わせてカスタマイズして、手動による割り込みを要求する警告を発行したり、自動的に実行する処理を指定したりできます。どのエラーの場合も、audit_warn はメッセージをコンソールに書き込み、audit_warn メールの別名にメールを送ります。監査を有効にしたときは、この別名を設定する必要があります。
監査デーモンは、次の状態を検出すると、 audit_warn スクリプトを起動します。
監査ディレクトリが minfree の許容値を超えていっぱいになった場合。minfree値はソフト制限値で、監査ファイルシステム上で使用できる領域の割合です。
audit_warn スクリプトは、文字列 soft と、使用可能領域が下限値を下回ったディレクトリ名を使用して起動されます。監査デーモンは、次に適切なディレクトリに自動的に切り替えて、この新しいディレクトリが minfree の上限に達するまで監査ファイルに書き込みます。監査デーモンは、audit_control ファイルにリストされた順序で残りの各ディレクトリにアクセスし、各ディレクトリが minfree の制限に達するまで監査レコードを書き込みます。
すべての監査ディレクトリが minfree のしきい値に達した場合。
文字列 allsoft を指定した audit_warn スクリプトが起動します。コンソールにメッセージが書き込まれ、audit_warn の別名にメールが送られます。
audit_control ファイルに指定されたすべての監査ディレクトリがそれぞれの minfree しきい値に達すると、監査デーモンは最初の監査ディレクトリに戻って、そのディレクトリが完全にいっぱいになるまで監査レコードを書き込みます。
監査ディレクトリが完全にいっぱいになり、残りの容量がなくなった場合。
文字列 hard とディレクトリ名を使用して、audit_warn スクリプトが起動されます。コンソールにメッセージが書き込まれ、audit_warn の別名にメールが送られます。
監査デーモンは、使用可能領域が残っている次の適切なディレクトリがあれば、そのディレクトリに自動的に切り替えます。監査デーモンは、audit_control ファイル内に指定されている順番で次の残りのディレクトリに移動し、それぞれのディレクトリが完全にいっぱいになるまで監査レコードを書き込みます。
すべての監査ディレクトリが完全にいっぱいになった場合。引数として文字列 allhard を使用して、audit_warn スクリプトが起動されます。
デフォルトの構成では、コンソールにメッセージが書き込まれ、audit_warn の別名にメールが送られます。監査レコードを生成するプロセスは中断されます。監査デーモンはループに入り、領域が使用可能になるのを待って監査レコードの処理を再開します。監査レコードが処理されるまで、監査対象の動作は待機します。監査レコードを生成しようとするプロセスは、すべて中断されます。このため、別の監査管理アカウントを設定し、監査機能を有効にしないで操作できるように設定する必要があります。このように設定すれば、操作を中断せずに継続することができます。
次のような内部エラーが発生した場合は、audit_warn の別名にメールが送られます。
audit_control ファイルの構文に問題が検出された場合、デフォルトでは、audit_warn の別名にメールが送られ、コンソールにメッセージが送られます。