test

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

監査ファイル

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

/etc/system ファイル

/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_class ファイルには、既存の監査クラスの定義が含まれます。監査クラスは、監査イベントのグループです。各監査クラスには、クラスの短縮名として監査フラグが関連付けられます。audit_control ファイル内のこの短縮名を使用して、監査するイベントのクラスを事前選択します。このとき、+ または – を接頭辞として使用します。スーパーユーザー、またはそれと同等の役割を持つ管理者は、新しい監査クラスを定義したり、既存のクラス名を変更したりすることができます。また、vi、ed などのエディタを使用して、既存のクラスを編集することもできます。詳細は、audit_class(4)のマニュアルページを参照してください。監査フラグについては、監査フラグの定義を参照してください。

audit_controlファイル

各マシン上の 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 (getaudit(2) のマニュアルページを参照)、または auditon を使用します。

audit_control ファイルの例

次の例は、マシン 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

audit_data ファイル

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 ファイル

audit_event ファイルは、/etc/security ディレクトリに配置され、イベントとクラスのデフォルトの割り当てが格納されます (audit_event(4)のマニュアルページを参照)。このファイルを編集して、クラスの割り当てを変更できます。ただし、変更した場合は、システムをリブートするか auditconfig -conf を実行して、変更した割り当てをカーネルに読み込む必要があります。

audit_startup スクリプト

監査を使用可能にするには、監査デーモン auditd を起動します。監査デーモンを起動するには、スーパーユーザーまたは同等の役割を持って /usr/sbin/auditd を実行します。詳細については、auditd(1M)のマニュアルページを参照してください。

ファイル /etc/security/audit_startup が存在する場合、システムがマルチユーザーモードに移行すると、自動的に監査デーモンが動作します。このファイルは、監査デーモンを実行する前に起動シーケンスの一部として起動される実行可能スクリプトです (audit_startup(1M) のマニュアルページを参照)。デフォルトの audit_startup スクリプトは、イベントとクラスの割り当てを自動的に構成して、BSM パッケージをインストールしたときに作成された監査ポリシーを設定します。

audit_user ファイル

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

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

これらの監査フィールドは、この順番で処理されます。監査機能を有効にするときは、 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 エントリで指定した内容の他に、システムデフォルト値が適用されます。

注 –

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

audit_warn スクリプト

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

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