test

Solaris のシステム管理 (セキュリティサービス)

監査サービスファイル

監査プロセスでは、次のファイルが使用されます。

/etc/system ファイル

/etc/system ファイルには、カーネルが初期設定で読み込み、システム動作をカスタマイズするためのコマンドが格納されます。bsmconv および bsmunconv シェルスクリプトは、監査機能を起動および終了するときに使用され、/etc/system ファイルを変更します。bsmconv シェルスクリプトは、 /etc/system ファイルに次の行を追加します。


set c2audit:audit_load=1

set c2audit:audit_load=1 コマンドは、システムのブート時に監査モジュール (カーネルモジュールの一種) をロードします。bsmunconv シェルスクリプトは、システムのリブート時に監査を無効にします。このコマンドは、/etc/system ファイルから c2audit の行を削除します。

audit_class ファイル

/etc/security/audit_class ファイルには、既存の監査クラスの定義が含まれます。監査クラスは、監査イベントのグループです。各監査クラスには、クラスの短縮名として監査フラグが関連付けられます。audit_control ファイル内のこの短縮名を使用して、監査するイベントのクラスを事前選択します。監査フラグでは、接頭辞を使ってきめ細かな選択が行えます。詳細については、監査フラグの構文を参照してください。

root ユーザーまたはそれと同等の役割を持つ管理者は、監査クラスの定義を変更できます。管理者は、audit_class ファイルをテキストエディタで編集することによって、新しい監査クラスを定義したり、既存クラスの名前を変更したり、既存クラスにその他のさまざまな変更を施したりすることができます。詳細は、audit_class(4)のマニュアルページを参照してください。監査フラグについては、監査フラグの定義を参照してください。

audit_controlファイル

各マシン上の /etc/security/audit_control ファイルは、監査デーモンによって読み込まれます。詳細については、audit_control(4) のマニュアルページを参照してください。audit_control ファイルは /etc/security ディレクトリにあります。各マシンには、独自の audit_control ファイルがローカルに格納されています。このファイルを使用すると、個々のマシン上で、さまざまな場所にある監査ファイルシステムをさまざまな順序でマウントすることが可能となります。たとえば、マシン A の一次監査ファイルシステムは、マシン B の二次監査ファイルシステムになっている場合があります。

audit_control ファイルには、次の 4 種類の情報を指定します。各行の情報は、キーワードで始まります。

audit_control ファイルは、各マシン上での構成処理中に作成されます。

audit_control ファイルを変更したときは、audit -s コマンドを実行すると、監査デーモンによってファイルが再度読み取られます。

注 –

audit -s コマンドでは、既存のプロセスについて指定された事前選択マスクは変更されません。既存のプロセスについては、auditconfig、setaudit、auditon のいずれかを使用してください。詳細は、getaudit(2) および auditconfig(1M) のマニュアルページを参照してください。

audit_control ファイルの例

次の例は、マシン dopey で使用する audit_control ファイルです。dopey では、監査サーバー blinken 上で 2 つの監査ファイルシステムを使用し、2 つ目の監査サーバー winken からマウントされる 3 つ目の監査ファイルシステムを使用します。3 つ目のファイルシステムは、blinken 上の監査ファイルシステムがいっぱいであるか使用できないときにだけ使用されます。minfree の値として 20% を指定しているため、ファイルシステムの使用率が 80% に達した時点で警告スクリプトが実行されます。以下のフラグでは、監査対象としてログイン操作と管理操作が指定されています。これらの操作について、その成功と失敗が監査されます。ファイルシステムオブジェクト作成の失敗を除くすべての失敗が、監査対象となります。また、ユーザーに起因しないイベントも監査されています。 


flags:lo,am,-all,^-fc
naflags:lo,nt
minfree:20
dir:/etc/security/audit/blinken/files
dir:/etc/security/audit/blinken.1/files
#
# blinken がいっぱいになったときに使用する監査ファイルシステム
#
dir:/etc/security/audit/winken

audit_data ファイル

auditd デーモンは、各マシン上で起動されると、ファイル /etc/security/audit_data を作成します。このファイルの書式は、コロンで区切られた 2 つのフィールドを含む 1 行のエントリから構成されています。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 ファイルには、イベントからクラスへの割り当てのデフォルト値が格納されます。このファイルを編集して、クラスの割り当てを変更できます。ただし、変更した場合は、システムをリブートするか auditconfig -conf を実行して、変更した割り当てをカーネルに読み込む必要があります。audit_event(4) のマニュアルページを参照してください。

audit_startup スクリプト

/etc/security/audit_startup スクリプトは、システムがマルチユーザーモードに移行すると監査デーモンを自動的に起動します。このスクリプトは、監査デーモンの実行直前に起動シーケンスの一部として起動されます。詳細は、audit_startup(1M)のマニュアルページを参照してください。

デフォルトの audit_startup スクリプトは、イベントからクラスへの割り当てを自動的に構成し、監査ポリシーを設定します。このスクリプトは、BSM パッケージのインストール時に作成されます。

audit_user ファイル

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

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

これらの監査フィールドは、この順番で処理されます。always-audit フィールドは、指定されたクラスの監査を有効にします。never-audit フィールドは、指定されたクラスの監査を無効にします。

注 –

never-audit フィールド内で all 監査フラグを設定したままにする誤りがよくあるので注意してください。all 監査フラグを指定したままにすると、そのユーザーの監査がすべてオフに設定され、always-audit フィールドに設定されているフラグが無効になります。このフラグは、audit_control ファイルで設定されたマシン全体の監査フラグよりも優先されます。

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

正しいエントリ


tamiko:all,^+fr:

間違ったエントリ


tamiko:all:+fr

1 つ目の例は、「ファイル読み取り動作を除くすべての動作を監査する」ことを表しています。2 つ目の例は「常にすべての動作を監査するが、正常なファイルの読み取り動作はまったく監査しない」ことを表しています。2 つ目の例は正しいエントリではありません。never-audit フィールドがシステムのデフォルト値を無効にするからです。1 つ目の例では期待どおりの結果になります。always-audit フラグには、all フラグへの例外が含まれています。never-audit フィールドにはフラグが指定されていないため、audit_control ファイル内のシステムデフォルト値は無効になりません。

注 –

正常終了したイベントと失敗したイベントは別々に取り扱われます。プロセスが生成する監査レコードの数は、イベントが正常終了した場合よりも失敗した場合のほうが多くなる可能性があります。

audit_warn スクリプト

監査デーモンは、監査レコードの書き込み中に異常な状態が発生すると、/etc/security/audit_warn スクリプトを起動します。詳細については、audit_warn(1M) のマニュアルページを参照してください。このスクリプトをサイトに合わせてカスタマイズすることで、手動による対処が必要な状態を警告するようにしたり、そのような状態を自動的に処理するための方法を指定したりできます。エラーが発生すると、audit_warn はコンソールにメッセージを書き込みます。audit_warn はさらに、audit_warn メール別名にもメッセージを送信します。監査を有効にしたときは、この別名を設定する必要があります。

監査デーモンは、次の状態を検出すると、 audit_warn スクリプトを起動します。