test

SunSHIELD 基本セキュリティモジュール

第 2 章 監査機能の管理

この章では監査機能を設定し、管理する方法を説明します。監査機能により、システム管理者はユーザの動作を監視できます。管理者は監査機構を使用してセキュリティが破られる可能性を検出できます。監査機能は、システムの使用について不審なパターンや異常なパターンを発見し、特定のユーザに関する疑わしい動作を追跡する方法を提供します。また、監査は抑止力としても機能します。つまり、ユーザは自分の動作が監査されそうだと考えると、違反行為を思いとどまる可能性が大きくなります。

監査機能の概要

監査を正常に機能させるには、識別と認証という 2 つのセキュリティ機能が重要な役割を果たします。ログイン時にユーザがユーザ名とパスワードを与えると、固有の監査 ID がそのユーザのプロセスに関連付けられます。監査 ID は、ログインセッション中に起動されるすべてのプロセスによって継承されます。ユーザが ID を変更しても (su(1M) のマニュアルページを参照)、 実行するすべての動作は同じ監査 ID によって追跡されます。

監査機能によって次のことが可能になります。

システム管理者は、システムの構成時にどの動作を監視するかを選択します。管理者は各ユーザに行う監査の程度を細かく調整することもできます。

監査データを収集したら、監査ファイル縮小ツールと変換ツールによって監査トレールの注目すべき部分を検査できます。たとえば、個別のユーザまたはグループの監査レコードを調べるか、特定の日に発生した特定のタイプのイベントのレコードをすべて調べるか、または、特定の日時に発生したレコードだけを取り出すかを選択できます。

この章では、監査機能を設定し、管理する方法を説明します。監査データを変換する方法については、第 4 章「デバイスの割り当て」を参照してください。

監査機能の起動

/usr/sbin/auditd を root として実行して監査デーモンを起動すると、監査機能が使用可能になります (auditd(1M) のマニュアルページを参照)。

パス名 /etc/security/audit_startup を持つファイルがあると、システムがマルチユーザモードになったときに監査デーモンが自動的に実行されます。 実際には、このファイルは監査デーモンを実行する前に起動シーケンスの一部として起動される実行可能スクリプトです (audit_startup(1M) のマニュアルページを参照)。イベントを自動的にクラス別に構成して、監査方針を設定するデフォルトの audit_startup スクリプトは BSM パッケージのインストール時に設定されます。

監査クラスとイベント

セキュリティに関わりを持つ動作について監査を行います。 監査可能なシステム動作は監査イベントとして etc/security/audit_event ファイル内に定義します。 各監査可能イベントは、記号名、イベント番号、事前選択クラスのセット、および短い説明によって定義します (autit_event(4) のマニュアルページを参照)。

ほとんどのイベントは個々のユーザの動作が原因で発生します。 しかし、一部のイベントはカーネル割り込みレベルで発生したり、ユーザが識別され認証される前に発生したりするので、ユーザに帰因しないものもあります。ユーザに帰因しないイベントも監査されます。

各監査イベントは、1 つまたは複数の監査クラスに属するものとして定義します。イベントをクラスに割り当てると、管理者はより多くのイベントを、より簡単に処理できるようになります。 イベントをクラスに割り当てると、管理者はより多くのイベントを、より簡単に処理できるようになります。また、クラス自体も変更できます。これらの変更は audit_event ファイル内で行います。

管理者が特定のイベントを含むクラスを監査のために事前選択することによって、監査可能なイベントが監査トレールに記録されます。32 の監査クラスのうち、18 のクラスを定義します。この 18 のクラスには 2 つのグローバルクラス、all と no が含まれます。

カーネルイベント

カーネルによって生成されるイベント (システムコール) には、1 から 2047 までのイベント番号が付けられます。カーネルイベントのイベント名は AUE_ たとえば、creat() システムコールのイベント番号は 4でイベント名は AUE_CREATです。

ユーザレベルのイベント

カーネルの外側でアプリケーションソフトウェアによって生成されるイベントの番号は、2048 から 65535 までの範囲にあります。 イベント名は AUE_ で始まり、その後にイベントを表す小文字のニーモニックが続きます。ファイル /etc/security/audit_event, 内で各イベントの番号を調べてください。 表 2-1 に、ユーザに関連するイベントの一般的なカテゴリを示します。

表 2-1 監査イベントのカテゴリ

番号の範囲 

イベントのタイプ 

2048-65535 

ユーザレベルの監査イベント 

2048-32767 

SunOS ユーザレベルのプログラム用に予約 

32768-65536 

サードパーティアプリケーション用に使用可

監査レコード

各監査レコード には、監査された 1 つのイベントの発生が記述されます。誰がその動作を行ったか、どのファイルが影響を受けたか、どのような動作が試みられたか、いつ、どこでその動作が発生したかといった情報が含まれます。

監査イベントごとに保存される情報は、監査トークンのセットとして定義されます。 1 つのイベントに対して監査レコードが作成されるたびに、イベントの内容に従ってそのレコードに、トークンの一部またはすべてが書き込まれます。 付録 A には、各イベントに定義された監査トークンと各トークンの意味がすべてリストされています。

監査レコードはトレール内に収集され (audit.log(4) のマニュアルページを参照)、praudit コマンドによってユーザが読める書式に変換できます(praudit(1M) のマニュアルページを参照)。詳細については、第 3 章「監査トレールの分析」を参照してください。

監査フラグ

監査フラグは監査対象となるイベントのクラスを示します。マシン全体で有効な監査関連のデフォルト値は、audit_control ファイル内のフラグによって各マシン上のすべてのユーザ用に指定されます。 詳細については、「audit_controlファイル 」を参照して下さい。

システム管理者は、監査フラグを audit_user ファイルにあるユーザエントリに入れることにより、各ユーザに対して監査を行う対象を修正できます。また、監査フラグは、auditconfig コマンドの引数として使用できます (auditconfig(1M) のマニュアルページを参照)。

監査フラグの定義

表 2-2 に、事前に定義されている各監査クラスの監査フラグ (これはクラスを表す短縮名です)、ロング名、および説明を示します。システム管理者は、監査構成ファイル内の監査クラスを使用して、監査の対象となるイベントのクラスを指定します。audit_classファイルを修正することにより、クラスの定義を追加したり、クラス名を変更できます (audit_class(4) のマニュアルページを参照)。

表 2-2 監査クラス

短縮名 

ロング名 

短い説明 

no

no_class

イベントの事前選択をオフにするためのヌル値

fr

file_read

データの読み取り、読み取りのためのオープンなど 

fw

file_write

データの書き込み、書き込みのためのオープンなど 

fa

file_attr_acc

オブジェクト属性へのアクセス : stat、pathconf など

fm

file_attr_mod

オブジェクト属性の変更 : chown、flock など

fc

file_creation

オブジェクトの作成 

fd

file_deletion

オブジェクトの削除 

cl

file_close

close システムコール

pc

process

プロセスの操作 : fork、exec、exit など

nt

network

ネットワークイベント: bind、connect、accept など

ip

ipc

System V の IPC 操作

na

non_attrib

ユーザが原因ではないイベント 

ad

administrative

管理的な操作 

lo

login_logout

ログインとログアウトのイベント 

ap

application

アプリケーションが定義するイベント 

io

ioctl

ioctl システムコール

ex

exec

プログラムの実行 

ot

other

その他 

all

all

全フラグのセット

監査フラグの構文

イベントのクラスは、付けられている接頭辞に応じて、成功したか失敗したかについて、成功した場合のみ、または、失敗した場合のみ、監査を行うことができます。監査フラグの構文は次のとおりです。

prefixflag

次の表に、成功した場合も失敗した場合も監査する接頭辞、成功した場合のみ、または失敗した場合のみ監査する接頭辞をそれぞれ示します。

表 2-3 監査フラグに使用する接頭辞

接頭辞 

意味 

なし

成功と失敗の両方の場合に監査する 

+

成功の場合のみ監査する 

-

失敗の場合のみ監査する 

これらの監査フラグがどのように連動するかという例として、lo を考えてみます。これは「ログインとログアウトの成功した場合すべて、および、ログインの失敗した場合すべて」を意味する監査フラグです (ログアウトに失敗することはありません)。別の例としては、-all は失敗したすべての種類の試みを意味し、+all は成功したすべての種類の試みを意味します。

注意 - 注意 -

allフラグは大量のデータを生成し、すぐに監査ファイルシステムをいっぱいにします。したがってこのフラグは、すべてを監査しなければならない特別な理由がある場合にのみ使用してください。

設定済みの監査フラグを変更する接頭辞

次の接頭辞を 3 つの方法のいずれかで使用します。つまり、すでに指定されているフラグを変更する場合に、audit_control ファイル内のflags 行を使用するか、audit_user ファイル内のユーザエントリの flags を使用するか、または auditconfig を使用して、監査フラグを変更します (auditconfig(1M) のマニュアルページを参照)。

次の表に示す接頭辞を監査クラスの短縮名とともに使用して、指定済みの監査クラスをオンまたはオフにします。これらの接頭辞は、指定済みのフラグのみをオンまたはオフにします。

表 2-4 指定済みの監査フラグを変更する接頭辞

接頭辞 

意味 

^-

失敗した試みに対する監査をオフにする 

^+

成功した試みに対する監査をオフにする

^

成功した試みと失敗した試みの両方に対して監査をオフにする 

^- 接頭辞は、次の例のように audit_control ファイルの flags 行で使用します。

次の例では、lo フラグ と ad フラグが、すべてのログインと管理的な操作について成功と失敗の両方の場合に、監査することを指定しています。-all は「失敗したすべてのイベント」を監査することを意味します。^- 接頭辞は「指定したクラスの、失敗した試みについての監査をオフにする」ため、^-fc フラグは、失敗したすべてのイベントの監査を指定した以前のフラグを変更します。したがって、この 2 つのフィールドを合わせると、「ファイルシステムオブジェクトの作成に失敗した試みを除けば、失敗したイベントをすべて監査する」ことを意味します。 


flags:lo,ad,-all,^-fc

audit_controlファイル

各マシン上の audit_control ファイルは、監査デーモンによって読み込まれます (audit_control(4) のマニュアルページを参照)。audit_control ファイルは /etc/security ディレクトリにあります。分散システムのマシンは監査ファイルシステムをさまざまな場所からマウントしているか、異なる順序で指定しているので、各マシン上では別の audit_controlファイルが管理されます。たとえば、マシン A の一次監査ファイルシステムは、マシン B の二次監査ファイルシステムになっている場合があります。

audit_control ファイル内では、4 種類の情報を 4 種類の行で指定します。

管理者は、構成時に audit_control ファイルをマシンごとに作成します。

管理者は、システム構成時に audit_control ファイルを作成した後で、それを編集できます。変更した後に audit -s を実行して監査デーモンに audit_control ファイルを再度読み込むように指示します。

注 -

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

audit_control ファイルのサンプル

次の例は、マシン dopey で使用する audit_control ファイルです。dopey では、監査サーバ flinpen 上にある 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_user ファイル内のユーザ監査フィールド

あるユーザを他のユーザと異なる方法で監査することが望ましい場合には、管理者は audit_user ファイルを編集してユーザに監査フラグを追加できます。これらの監査フラグが指定されている場合は、監査制御ファイル内で指定されているシステム全体で有効なフラグと組み合わされ、そのユーザに関してどのイベントクラスを監査するかが決定されます。管理者が audit_user ファイル内のユーザエントリに追加するフラグは、audit_control ファイルにあるデフォルトを次の 2 つの方法で変更します。1 つは、このユーザについては決して監査されないイベントクラスのセットを指定する方法で、もう 1 つは、常に監査の対象となるイベントクラスのセットを指定する方法です。

audit_user ファイルの各ユーザエントリには、3 つのフィールドがあります。最初のフィールドは username フィールド 、2 つ目は always-audit フィールド、3 つ目は never-audit フィールドです。フィールドは順番に処理されるので、監査機能は 2 つ目の always-audit で使用可能になり、3 つ目の never-audit で使用不可になります。

注 -

never-audit フィールド内で all を設定したままにするというのがよくある間違いです。この場合、そのユーザに関してすべての監査機能がオフになり、never-audit フィールド内で設定されたフラグセットが上書きされてしまいます。

あるユーザにフラグを使用することと、always-audit のセットからクラスを削除することとは異なります。たとえば、(次の例のように) ファイルシステムのオブジェクトの読み込みに成功した場合を除き、ユーザ fred の動作はすべて監査の対象にしたと仮定します (すべてのデータ読み込み動作を監査する場合に生成される監査データの 4 分の 3 程度に監査データを抑えながら、あるユーザに関するほとんどすべての動作を監査するには、この方法が適しています)。また、システムのデフォルトをユーザ fred に適用するとします。次に 2 つの audit_user エントリを示します。

正しいエントリ


fred:all,^+fr:

間違ったエントリ


fred:all:+fr

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

注 -

成功したイベントと失敗したイベントは別個に取り扱われるので、プロセスが生成する監査レコードの量は、そのイベントが成功したときよりも、失敗したときの方が多くなることがあります。

プロセスの監査特性

はじめてログインするときに次の監査特性が設定されます。

プロセス事前選択マスク

ユーザがログインするときには、login により、 audit_control ファイルにあるマシン全体の監査フラグが audit_user ファイルにあるユーザ固有の監査フラグ (もしあれば) と組み合わされ、そのユーザのプロセスに使用するプロセス事前選択マスクが確立されます。プロセス事前選択マスクは、各監査イベントクラス内のイベントで監査レコードを生成させるかどうかを指定します。

プロセス事前選択マスクを取得するアルゴリズムは次のとおりです。つまり、audit_control ファイル内の flags: 行にある監査フラグが、audit_userファイル内のユーザエントリの always-audit フィールドにあるフラグに追加されます。audit_user ファイル内のユーザエントリの never-audit フィールドは、このときに合計から差し引かれます。

ユーザのプロセス事前選択マスク = (flags: 行 + always audit フラグ) - never audit フラグ

監査 ID

ユーザがログインすると、プロセスはまた、ユーザの監査 ID を取得し、この監査 ID はユーザの初期プロセスが起動するすべての子プロセスに継承されます。監査 ID はアカウントの追跡を強制するのにも役立ちます。ユーザが root になった後も、監査 ID は変わらずそのまま残ります。各監査レコード内に保存された監査 ID を使用すると、管理者はいつでも動作を追跡してログインしたもとのユーザまでたどることができます。

監査セッション ID

監査セッション ID はログイン時に割り当てられ、すべての子孫のプロセスに継承されます。

端末 ID　

端末 ID は、ホスト名とインターネットアドレスからなり、その後にユーザがログインした物理デバイスを識別する固有の番号が続きます。通常、ログインはコンソールから行われ、そのコンソールデバイスに対応する番号は 0 になります。

監査トレールの作成

監査トレールは監査デーモンによって作成されます (詳細は、auditd(1M) のマニュアルページを参照してください)。監査デーモンは、マシンが起動されるとそのマシン上で起動されます。 auditd は、ブート時に起動されると、監査トレールデータを収集し、監査レコードを監査ファイルに書き込む処理を受け持ちます。このファイルを監査ログファイルとも呼びます。 ファイルの書式についての詳細は、audit.log(4) のマニュアルページを参照してください。

監査デーモンは root として動作します。監査デーモンによって作成されるファイルは、すべて root に所有されます。auditd は、監査するクラスがなくても動作を継続し、監査レコードを置く場所を探します。また、カーネルの監査バッファがいっぱいになったためにマシンの他の動作が中断されても、auditd は動作を続けます。監査動作を続行できるのは、auditd が監査の対象ではないからです。

監査デーモンは、一度に 1 つしか実行できません。第 2 の監査デーモンを起動しようとすると、エラーメッセージが表示され、その新しい監査デーモンが終了します。 監査デーモンに問題がある場合は、audit -t を使用して auditd を正常に終了させ、手作業で再起動してみる必要があります。

デーモンが監査ディレクトリを切り替えたり、問題 (記憶領域不足など) が発生すると、 auditd によって audit_warn スクリプトが実行されます。 分散システムであることから、 audit_warn スクリプトは audit_warn の別名にメールを送り、コンソールにメッセージを送ります。 サイトでは、ニーズに合わせて audit_warn をカスタマイズする必要があります。 audit_warn スクリプトをカスタマイズする方法については、「audit_warn スクリプト」を参照してください。

audit_data ファイル

auditd は、各マシン上で起動されると、ファイル /etc/security/audit_data を作成します。 このファイルの書式は、1 つのエントリに、コロンで区切られた 2 つのフィールドがあります (audit_data(4) のマニュアルページを参照)。第 1 のフィールドは監査デーモンのプロセス ID で、第 2 のフィールドは、監査デーモンが監査レコードを現在書き込んでいる監査ファイルのパス名です。 

# cat /etc/security/audit_data
116:/etc/security/audit/blinken.1/files/19910320100002.not_terminated.lazy

監査デーモンの役割

次に、監査デーモン auditd の役割を示します。

マシンがマルチユーザモードで起動されるときに監査デーモンが起動されたり、または、監査デーモンが audit -s コマンドにより auditd ファイルを編集後にもう一度読み取るように命令を受けると、auditd は必要な空き容量を判断し、audit_control ファイルからディレクトリのリストを読み取り、それを監査ファイルの作成場所の候補として使用します。

監査デーモンは、このディレクトリのリストへのポインタを最初から管理します。監査デーモンが監査ファイルを作成しなければならなくなるたびに、監査デーモンはそのカレントポインタから始めて、監査ファイルをリスト内の最初の使用可能ディレクトリに入れます。管理者が audit -s コマンドを入力すると、このポインタをリストの先頭にリセットできます。audit -n コマンドを使用して、新しい監査ファイルに切り替えるようにデーモンに命令すると、新しいファイルは現在のファイルと同じディレクトリ内で作成されます。

監査デーモンが使用できるディレクトリ

監査デーモンがあるディレクトリを使用するには、そのディレクトリにアクセスできることが条件となります。つまり、そのディレクトリがマウントされ、ネットワーク経由 (リモートの場合) のアクセスが許可され、ディレクトリに対するアクセス権がなければなりません。また、監査ファイルをディレクトリに保存するには、十分な空き領域がなければなりません。audit_control ファイルの minfree: 行を編集して、デフォルトの 20 パーセントを変更できます。minfree の設定が 20 パーセントというデフォルトの最小空き領域の場合は、ファイルシステムが 80 パーセントを超えていっぱいになると、audit_warn の別名に電子メール通知が送信されます。

十分な空き領域が残っているディレクトリがリストになければ、デーモンはリストの先頭からはじめて最後に達するまで、ハード限界に達せず使用可能領域が残っている最初のアクセス可能なディレクトリを選択します。デフォルト構成では、適切なディレクトリがなければ、デーモンは監査レコードの処理を停止し、監査レコードを生成中のすべてのプロセスが中断されるまで、カーネル内に蓄積します。

監査ファイルを常に管理可能な状態に保つ

監査ファイルを管理可能なサイズに保つために、監査ファイルを定期的に切り替える cron ジョブを設定できます (cron(1M) のマニュアルページを参照)。切り替え間隔は、収集される監査データの量に応じて、1 時間ごとから 1 日に 2 度までの範囲で設定できます。データにフィルタをかけ、不要な情報を削除して圧縮できます。

audit_warn スクリプト

監査デーモンは、監査レコードの書き込み中に異常な条件が発生すると、/etc/security/audit_warn スクリプトを起動します。audit_warn(1M) のマニュアルページを参照してください。このスクリプトをサイトでカスタマイズして、手作業による介入が必要な場合に警告を出したり、自動処理を行わせることができます。どのエラー条件が発生した場合も、audit_warn はメッセージをコンソールに書き込み、audit_warn の別名に送ります。管理者は、BSM を使用可能にした後で、この別名を設定しておく必要があります。

監査デーモンは次の条件を検出すると audit_warn を起動します。

auditreduce コマンドの使用方法

auditreduce を使用すると、1 つまたは複数の入力監査ファイルから監査レコードをマージしてまとめたり、監査レコードの事後選択を実行できます。auditreduce(1M) のマニュアルページを参照してください。監査トレール全体をマージするには、システム管理者は分散システムのすべての監査ファイルシステムがマウントされているマシン上で、auditreduce コマンドを入力します。

BSM を実行する複数のマシンが分散システムの一部として管理されているときは、各マシンが監査可能なイベントを実行し、監査レコードをマシン固有の監査ファイルに書き込みます。この手順によってソフトウェアが単純化され、マシンが障害を起こした場合の信頼性が高まります。しかし、各マシンによって独自の監査ファイルセットが生成されるので、auditreduce を使用しないと、すべてのファイルを個別に調べてどのユーザに帰因するかを判断しなければなりません。

auditreduce コマンドによって、監査トレール全体の管理作業を効率化できます。auditreduce (または、より高いインタフェースを提供するために独自に作成したシェルスクリプト) を使用すると、レコードの生成方法や格納場所に関係なく、システム内のすべてのファイルの論理上の組み合わせを 1 つの監査トレールとして読むことができます。

auditreduce プログラムは、監査デーモンによって生成された監査トレールを処理します。1 つまたは複数の監査ファイルからレコードが選択され、マージされて、1 つの時系列順のファイルが生成されます。auditreduce のマージ機能と選択機能は論理的に他に依存しません。auditreduce はレコードが読み取られると、入力ファイルがマージされてディスクに書き込まれる前に、そこからメッセージを選択します。

オプションを指定しなければ、auditreduce は監査トレール全体 (デフォルトの監査ルートディレクトリ /etc/security/audit 内のすべてのサブディレクトリ内のすべての監査ファイルです) をマージして、すべての監査レコードを標準出力に送ります。praudit コマンドによって、レコードをユーザが読める書式に変換されます。

次の例は、auditreduce コマンドの一部のオプションによって実行される動作です。

引数を指定しなければ、auditreduce はデフォルトの監査ルートディレクトリである /etc/security/audit の下のすべてのサブディレクトリ内で、date.date.hostname ファイルが入っている files ディレクトリを検索します。auditreduce コマンドは、さまざまなホストの監査データ (図 2-1) や、さまざまな監査サーバの監査データ (図 2-2) が別々のディレクトリに入っている場合に便利です。

図 2-1 ホスト別に分類された監査トレール

Graphic

監査データはデフォルトディレクトリに入っていなくてもかまいません。これは、/etc/security/audit のパーティションが小さすぎるため、または、別のパーティションを /etc/security/audit にシンボリックリンクせずに、そのパーティションに監査データを保存したい場合です。auditreduce に /etc/security/audit の代わりに別のディレクトリ (-R) を指定するか、または特定のサブディレクトリ (-S) を指定できます。

# auditreduce -R /var/audit-alt
# auditreduce -S /var/audit-alt/host1
図 2-2 サーバ別に分類された監査トレール

Graphic

次のように特定のファイルをコマンド引数として指定すると、それらのファイルのみを処理するように auditreduce に対して指示できます。


# auditreduce /var/audit/bongos/files/1993*.1993*.bongos

他のオプションとコマンドの使用例については、auditreduce(1M) のマニュアルページを参照してください。

監査コストの制御

監査処理によってシステム資源が消費されるので、どの程度詳しく記録するかを制御しなければなりません。監査の対象を決めるときには、監査に伴う次の 3 つのコストを考慮してください。

処理時間の増大に伴うコスト

処理時間の増大に伴うコストは、監査に関連する 3 つのコストの中では最も重要性の低い問題です。第 1 に、通常は、イメージ処理や複雑な計算処理など、計算集中型のタスクを実行中には監査処理が発生しないからです。第 2 に、1 人のユーザだけが使うワークステーションでは CPU に十分な余裕があるからです。

分析に伴うコスト

分析に伴うコストは、収集される監査データの量にほぼ比例します。この種のコストには、監査レコードをマージして検討する所要時間や、それをファイルに保存して安全な場所に保管する所要時間が含まれます。

生成するレコードが少ないほど分析に要する時間も短くなるので、この後の節ではサイトのセキュリティ目標を保ちつつ、収集するデータ量を削減する方法について説明します。

格納に伴うコスト

格納コストは、監査に伴うコストのうちで最も重要です。監査データの量は次の要素によって左右されます。

各要素は状況により異なるので、監査データの格納用に前もって確保しておくディスク容量を決定できるような計算式はありません。

完全な監査 (all フラグで指定します) の場合は、ディスクがすぐいっぱいになってしまいます。中程度のサイズのプログラム (5 つのファイルで合計 5000 行のプログラムなど) をコンパイルするなど、1 分もかからないごく単純なタスクでも、数千の監査レコードが生成され、何メガバイトものディスク領域を消費する可能性があります。したがって、事前選択機能を使用して、生成されるレコードの量を削減しておくことが大変重要になります。たとえば、すべてのクラスを監査するのではなく、fr クラスを省略すると、監査ボリュームを 3 分の 2 以上も削減できます。また、監査レコードが作成された後も、必要なディスク容量を削減するために監査ファイルを効率よく管理することが重要です。

この後の節では、サイトのセキュリティに関するニーズを満たしつつ、監査対象を選択して収集される監査データの量を削減し、格納に伴うコストを削減する方法について、いくつかのヒントを示します。また、監査ファイル記憶装置と保存手順を設定し、記憶領域の所要量を削減する方法についても説明します。

監査機能を構成する前に、監査フラグと、フラグが立てられるイベントのタイプを理解しておく必要があります。サイトで必要なセキュリティの程度と、管理の対象となるユーザのタイプに基づいて、組織の監査上の基本方針を設定してください。

プロセス監査の事前選択マスクが動的に変更されない限り、ユーザのログイン時に設定される監査特性は、ログインセッション中に発生するすべてのプロセスに継承されます。また、データベースが変更されない限り、プロセス事前選択マスクは後続のすべてのログインセッションに適用されます。

動的制御とは、プロセスの実行中に管理者が設定する制御のことです。この制御が有効なのは、影響を受けるプロセス (および、その子プロセス) が存在する間だけですが、次回のログイン時には有効になりません。監査コマンドはログインしている現在のマシンにのみ適用されるので、動的制御は一度に 1 つのマシンにのみ適用されます。ただし、あるマシン上で動的な変更を行う場合は、それと同時にすべてのマシン上でも同じように変更する必要があります。

各プロセスは、監査クラス用に 1 ビットのフラグを 2 組ずつ持っています。1 組目はそのクラスのイベントが正常に要求されたときにプロセスが監査対象になるかどうかを制御します。2 組目は、イベントが要求されたが (何らかの原因で) 失敗したときに、プロセスが監査対象になるかどうかを制御します。これは、システムのセキュリティをやぶろうとする場合のブラウズ操作やその他の試行操作を検出するために使用されるため、一般的にプロセスが成功した場合よりも失敗した場合の方が詳しく監査されます。

静的なデータベース内でユーザ単位の監査制御情報を提供するだけでなく、1 台のマシン上でユーザのプロセスが動作している間に、監査の状態を動的に調整できます。

特定のユーザについての監査フラグを変更するには、-setpmask、-setumask、または -setsmask オプションを指定して auditconfig コマンドを使用します。このコマンドによって、1 つのプロセス、監査セッション ID、または監査ユーザ ID のプロセス監査フラグがそれぞれ変更されます。auditconfig(1M) のマニュアルページと 「auditconfig コマンド」を参照してください。

通常のユーザの監査

管理者は、デフォルト構成に合わせて監査機能を設定します。audit_control ファイル内で指定したシステムワイドな監査フラグに従って、すべてのユーザと管理者を管理対象にすることができます。個々のユーザに対する監査機能を微調整するには、audit_user ファイル内でそのユーザのエントリを変更します。audit_control(4) と audit_user(4) のマニュアルページを参照してください。また、新しくユーザを追加するときに、ユーザのエントリに監査フラグを追加できますが、新規ユーザのアカウントのロックを解除し、そのユーザのセキュリティ属性を構成した直後に、そのユーザの監査機能を設定する必要があります。

効率的な監査

この節で説明する方法により、組織のセキュリティ目標を達成する一方で、監査効率を高めることができます。

もう 1 つの方法は、監査トレールをリアルタイムで監視することです。異常なイベントが検出された場合に、それに応じて特定のユーザまたはマシンの監査レベルを自動的に上げるようなスクリプトを作成できます。

監査トレールをリアルタイムで監視し、異常なイベントが発生していないかどうかを調べるには、すべての監査ファイルサーバ上で監査ファイルの生成を監視し、それを tail コマンド (tail(1) のマニュアルページを参照) で処理するスクリプトを作成します。tail -0f の出力をパイプにより praudit に渡すようにすると、監査レコードが生成されたときすぐにそれを表示して確認できます。この出力を分析して、異常なメッセージのタイプや他の兆候の有無を調べ、監査担当者に送付したり、自動応答の切り替えに使用できます。このスクリプトを作成して、アクティブな新しい not_terminated 監査ファイルがないかどうか、また、ファイルが書き込まれなくなったとき (つまり、新しいファイルに切り替えられたとき) に tail プロセスが終了しているかどうかを、監査ディレクトリ内で絶えず調べるようにする必要があります。

audit ファイルを組み合わせて縮小する方法

    -O オプションを指定して auditreduce を使用すると、複数の監査ファイルを組み合わせて 1 つにまとめ、指定した出力ファイルに保存できます。

auditreduce を使用すると、組み合わせと削除を自動的に実行できますが (auditreduce(1M) のマニュアルページの -C、-D オプションを参照)、通常はファイルを手作業で (find を使用して) 選択し、指定したファイルセットを auditreduce を使用して組み合わせる方が簡単です。この方法で autreduce を使用すると、入力ファイル内のすべてのレコードがマージされて、1 つの出力ファイルにまとめられます。その後に、入力ファイルを削除し、auditreduce で検索できるように、出力ファイルをディレクトリ /etc/security/audit/server-name/files に保存する必要があります。

# auditreduce -O combined-filename

また、auditreduce プログラムでは、入力ファイルを組み合わせるときに不要なレコードを除去して、出力ファイル内のレコード数を削減できます。完全な監査トレールを検索する必要がある場合にはバックアップテープから回復できることを前提にして、ログインとログアウトイベントを除いた、数カ月のすべてのレコードを auditreduce を使用して削除するようなこともあります。 

# auditreduce -O daily.summary -b 19930513 -c lo; compress *daily.summary
# mv *daily.summary /etc/security/summary.dir

監査トレールについて

この節では、監査ファイルの格納場所、命名方法、分散システム全体で監査ファイルの記憶領域を管理する方法について説明します。

監査トレールは、監査デーモン auditd が起動されるときに作成され、新しい監査ファイルが作成されたとき、または監査デーモンが終了するときに閉じられます。監査トレールは複数の監査ディレクトリ内の監査ファイルから構成される場合や、監査ディレクトリに複数の監査トレールが入っている場合があります。

ほとんどの場合監査ディレクトリは、別個の監査ファイルシステムパーティションになります。他のファイルシステムに組み込むこともできますが、この方法はお勧めできません。

原則として、一次監査ディレクトリは別のパーティションにマウントされた専用の監査ファイルシステム内に配置します。通常、すべての監査ファイルシステムは /etc/security/audit のサブディレクトリです。これらのファイルシステムは、監査ディレクトリが監査ファイルでいっぱいになっても、パーティションをそのまま通常どおり使用できるように、専用の監査ファイルシステムにする必要があります。

監査ディレクトリは、監査専用でない他のファイルシステム内に物理的に配置することもできますが、最後の手段として確保しているディレクトリを除き、この方法は使用しないでください。最後の手段として確保しているディレクトリとは、他の適切なディレクトリが使用できないときに限り監査ファイルが書き込まれるディレクトリです。また、専用の監査ファイルシステムの外側に監査ディレクトリを配置できるのは、監査機能がオプションで、監査トレールを保存することよりもディスクをフル活用することの方が重要なソフトウェア開発環境などです。セキュリティが重視される実行環境では、監査ディレクトリを他のファイルシステム内に入れることは許されません。

ディスクフルマシンには、少なくとも 1 つはローカルの監査ディレクトリを用意する必要があります。このディレクトリは、監査サーバと通信できない場合に、最後の手段として確保しているディレクトリとして使用できます。

監査ディレクトリは、読み取り/書き込み (rw) オプションを使用してマウントしてください。監査ディレクトリをリモートで (NFS を使用して) マウントするときは、intr オプションも使用してください。 監査ファイルシステムを、格納先の監査サーバ上でリストしてください。エクスポートリストには、監査サーバを使うよう構成されたすべてのマシンが含まれるはずです。

監査ファイルシステムを、格納先の監査サーバ上でリストしてください。エクスポートリストには、監査サーバを使うよう構成されたすべてのマシンが含まれるはずです。

監査ファイルの詳細

各監査ファイルは、それ自身で意味がわかるレコードの集合です。ファイル名には、レコードが生成された時間の範囲と、それを生成したマシン名が含まれます。

監査ファイルの命名

完全な監査ファイルには、次の書式の名前が付いています。 


start-time.finish-time.machine

この場合、start-time は監査ファイル内の最初の監査レコードの生成時刻、finish-time は最後のレコードの生成時刻、machine はファイルを生成したマシンの名前です。監査ファイルの名前の例については、「閉じられた監査ファイルの名前の例」を参照してください。

監査ログファイルがまだアクティブな場合は、次の書式の名前が付いています。 


start-time.not_terminated.machine

監査ファイル名の使用方法

auditreduce は、ファイル名のタイムスタンプを使用して、要求された特定期間内のレコードが入ったファイルを検索します。このタイムスタンプが重要なのは、1 カ月分以上の監査ファイルがオンライン上に存在する可能性があり、24 時間以内に生成されたレコードをすべて検索するとコストが大きくなりすぎるからです。

タイムスタンプの書式と意味

start-time と end-time は 1 秒単位のタイムスタンプで、グリニッジ標準時で指定されます。その書式は、次のように年が 4 桁で、月、日、時、分、秒が 2 桁ずつになっています。 


YYYYMMDDHHMMSS

このタイムスタンプにはグリニッジ標準時が使用されるので、夏時間によるずれがあっても正しい順序でソートされることが保証されます。また、グリニッジ標準時が使用されるので、日時を把握しやすいように現在の時間帯に変換しなければなりません。監査ファイルを auditreduce ではなく標準ファイルコマンドで操作するときには、この点に注意してください。

まだアクティブなファイルのファイル名の例

まだアクティブなファイル名の書式は次のとおりです。 


YYYYMMDDHHMMSS.not_terminated.hostname

次の例を参照してください。


19900327225243.not_terminated.lazy

監査ログファイルの名前には開始日が使用されるので、上記の例はグリニッジ標準時の 1990 年 3 月 27 日午後 10:52:43 から始まったことがわかります。ファイル名のうち not_terminated は、このファイルがまだアクティブであるか、または auditd が予期しないときに割り込まれたことを意味します。末尾の名前 lazy は、監査データが収集されているホストの名前です。

閉じられた監査ファイルの名前の例

閉じられた監査ログファイルの名前の書式は次のとおりです。 


YYYYMMDDHHMMSS.YYYYMMDDHHMMSS.hostname

次の例を参照してください。


19900320005243.19900327225351.lazy

上記の例は、グリニッジ標準時の 1990 年 3 月 20 日の午前 12:52:43 に始まったことがわかります。このファイルは、グリニッジ標準時の 3 月 27 日午後 0:53:51 に閉じられました。末尾の名前 lazy は、監査データが収集されているマシンのホスト名です。

auditd が予期しないときに割り込まれるといつも、その時点で開いていた監査ファイルは not_terminated で終わるファイル名タイムスタンプを取得します。また、マシンがリモートでマウントされた監査ファイルに書き込んでいるときに、ファイルサーバがクラッシュするか、またはアクセスできなくなると、not_terminated で終わるタイムスタンプがカレントファイルの名前に付いたままになります。監査デーモンは、古い名前の監査ファイルをそのまま残して新しい監査ファイルを開きます。

not_terminated マークが付いたアクティブでないファイルの処理

auditreduce コマンドは、not_terminated マークが付いたファイルを処理しますが、この種のファイルの終わりには不完全なレコードが入っていることがあるので、それ以上処理するとエラーが発生する可能性があります。エラーを防ぐには、不完全なレコードが入っているファイルを整理してください。ファイルを整理する前に、そのファイルに auditd が書き込み中でないかどうかを確認してください。チェックするには、audit_data ファイルを調べて auditd の現在のプロセス番号を確認します。そのプロセスがまだ実行中で、audit_data 内のファイル名が問題のファイルと同じ場合は、そのファイルを整理しないでください。

auditreduce で -O オプションを使用するとファイルを整理できます。これによって、古いファイル内のすべてのレコードが入った新しいファイルが作成され、正しいファイル名タイムスタンプが付けられます。この処理を実行すると、各監査ファイルの先頭に付いていた以前のファイルポインタは失われます。

または、ファイル全体を読み取り、最後のレコードを突き止めてファイル名を変更し、不完全なレコードを整理するプログラムを作成することもできます。また、以前のファイルポインタをそのまま残し、次にどのファイルを使用するかを決定するプログラムも作成できます。

監査パーティションを作成してエクスポートする方法

  1. 各マシンに少なくとも 1 つの「一次監査ディレクトリ」を割り当てます。

    一次監査ディレクトリは、通常の条件下でマシンが監査ファイルを配置するディレクトリです。

  2. 一次監査ディレクトリとは異なる監査ファイルサーバ上で、各マシンに少なくとも 1 つの「二次監査ディレクトリ」を割り当てます。

    二次監査ディレクトリは、一次ディレクトリがいっぱいになった場合や、ネットワーク障害、NFS サーバのクラッシュなどの原因でアクセスできなくなった場合に、マシンが監査ファイルを配置するディレクトリです。

  3. 各ディスクフルマシン上で、最後の手段として確保するローカルの監査ディレクトリ (できれば専用の監査ファイルシステム) を作成します。このディレクトリは、ネットワークにアクセスできなくなったときや、一次と二次のディレクトリが使用できないときに使用されます。

  4. 一次と二次の宛先として使用するディレクトリを、システム内の監査サーバに均等に分散させます。

  5. この節で説明した要件に従って監査ファイルシステムを作成します。

    /etc/security ディレクトリには、すべての監査ファイルと、監査制御に関連する他のファイルがいくつか入ったサブディレクトリがあります。/etc/security ディレクトリにはマシンごとの audit_data ファイルが入っており、ブート時に監査デーモンを正常に起動するには、このファイルが使用可能でなければならないので、/etc/security ディレクトリがルートファイルシステムになければなりません。

    監査用の事後選択ツールは、デフォルトで /etc/security/audit の下のディレクトリ内を検索します。このため、監査サーバ上の最初の監査ファイルシステムのマウントポイントに使用するパス名は、/etc/security/audit/ です (この場合、server-name は監査サーバ名です)。監査サーバ上に複数の監査パーティションがある場合、2 番目のマウントポイントの名前は /etc/security/audit/server-name.1、3 番目の名前は /etc/security/audit/server-name.2 というようになります。

    たとえば、監査サーバ winken 上で使用可能な監査ファイルシステムの名前は、/etc/security/audit/winken と /etc/security/audit/winken.1 になります。

    この監査サーバ上では、各監査ファイルシステムに files というサブディレクトリもなければなりません。この files サブディレクトリに監査ファイルが格納され、auditreduce コマンドによって検索されます。たとえば、監査サーバ winken 上の監査ファイルシステムには files サブディレクトリがあり、その完全パス名は /etc/security/audit/winken/files となります。

    各マシン上のローカルの audit_control ファイルが、監査ファイルに対して files サブディレクトリに監査ファイルを格納するように指示しているかどうかを確認する必要があります。次の例は、eagle から監査ファイルシステムをマウントしているマシン上の audit_control ファイルの dir: 行を示しています。

    dir: /etc/security/audit/eagle/files

    監査サーバ上で (何らかの理由で) /etc/security/audit/server-name[.suffix] ディレクトリが使用できないときに、マシンのローカルルートファイルシステムが監査ファイルでいっぱいになるのを防ぐには、別の階層レベルが必要です。監査サーバ上には files サブディレクトリがあり、どのクライアントにも files サブディレクトリがないため、マウントに失敗した場合に監査ファイルをローカルのマウントポイントディレクトリ上で自動的に作成できなくなります。

    各監査ディレクトリに監査ファイル以外のデータが入っていないかどうかを確認してください。

  6. 監査ファイルシステムに必要な許可を割り当てます。

    下記の 表 2-5 は、/etc/security/audit/server-name files ディレクトリと、その下に必ず作成する files ディレクトリ上になければならない許可を示しています。

    表 2-5 監査ファイルの許可

    所有者 

    グループ 

    許可 

    root 

    staff 

    2750 

audit_control ファイルのエントリの例

audit_control ファイルに dir: エントリを追加するときは、files サブディレクトリまでの完全パスを指定しなければなりません。次の例は、監査ファイルが専用のローカルディスクに格納されるサーバ blinken に関する audit_control ファイルの dir: エントリを示しています。 

# cat /etc/security/audit_control
dir:/etc/security/audit/blinken.1/files
dir:/etc/security/audit/blinken.2/files

監査を構成する方法

次の手順は、監査ディレクトリを設定し、監査の対象となる監査クラスを指定するために必要な操作の概要を示しています。

  1. ディスクをフォーマットし、パーティションに分割して、専用の監査パーティションを作成します。

    経験では、分散システム上に配置するマシンごとに 100 M バイトを割り当てることになっています。ただし、どれくらいのディスク容量が自分のサイトに必要かは、どの程度の監査を実施するかによって異なり、マシン 1 台当り 100 M バイトをはるかに上回るようなこともあります。

  2. 監査ファイルシステムを専用パーティションに割り当てます。

    NFS でマウントされた監査ファイルシステムを使用できない場合に備えて、ディスクフルマシンごとにローカルマシン上でバックアップ監査ディレクトリを作成しておく必要があります。

  3. 各マシンがシングルユーザモードになっている間に、各専用監査パーティション上で tunefs -m 0 を実行して、予約済みのファイルシステム領域を 0 パーセントに縮小します。

    予約領域のパーセンテージ (minfree 制限と呼びます) は、audit_control ファイル内で監査パーティションに関して指定されています。デフォルトは 20 パーセントですが、このパーセンテージは調整できます。この値はサイトごとに audit_control ファイル内で設定するので、すべてのファイルシステム用にデフォルトで自動的に予約され確保されているファイルシステム領域を削除する必要があります。

  4. 監査サーバ上で各監査ディレクトリに必要な許可を設定し、各監査ディレクトリ内で files というサブディレクトリを作成します。

    chown と chmod を使用して、各監査ディレクトリと各 files サブディレクトリに必要な許可を割り当てます。

  5. 監査サーバを使用している場合は、/etc/dfs/dfstab ファイルといっしょに監査ディレクトリをエクスポートします。

  6. files サブディレクトリを指定して、各マシン上の audit_control ファイル内にすべての監査ディレクトリに関する audit_control ファイルエントリを作成します。

  7. 各監査クライアント上で、/etc/vfstab ファイル内に監査ファイルシステムに関するエントリを作成します。

  8. 各監査クライアント上で、マウントポイントのディレクトリを作成し、chmod と chown を使用して適切な許可を設定します。

監査構成の計画を立てる方法

まず、監査トレール記憶領域の計画を作成します。

  1. /etc/security/audit_class ファイル内で、サイトで必要なクラスを定義します。

    デフォルトのクラスが適切であれば、新しいクラスを定義する必要はありません。audit_class(4) のマニュアルページを参照してください。

  2. /etc/security/audit_event 内でイベントとクラスのマッピングを設定します。

    デフォルトのマッピングがサイトのニーズに合っている場合は、この手順は不要です。audit_event(4) のマニュアルページを参照してください。

  3. サイトで必要な監査の程度を決定します。

    サイトのセキュリティ上のニーズを考慮して、監査トレールの格納に必要なディスク領域を決定します。

    サイトのセキュリティを確保しながら記憶領域の要件を削減する方法と、監査記憶領域を設定する方法のガイドラインについては、「監査コストの制御」、「効率的な監査」、「監査トレールについて」を参照してください。

  4. どのマシンを監査サーバとして使用し、どのマシンを監査サーバのクライアントとして使用するかを決定します。

  5. 監査ファイルシステムの名前と位置を決定します。

  6. どのマシンが監査サーバ上のどの監査ファイルシステムを使用するかの計画を作成します。

記憶領域の計画を作成したら、監査の対象となるユーザと監査内容を決定します。

  1. システム単位で監査したい監査クラスと、監査クラスの選択に使用するフラグを決定します。

  2. 一部のユーザを他のユーザより詳しく監査するかどうかを決定し、ユーザの監査特性の変更に使用するフラグを決定します。

    詳細は、「プロセスの監査特性」を参照してください。

  3. 最小空き領域 (minfree) を決定します。これは弱い制限とも呼ばれ、警告が送られる前に監査ファイルシステム上に残っていなければならない空き領域です。

    使用可能な容量が minfree のパーセンテージを下回ると、監査デーモンは次の適切なファイルシステムに切り替えて、soft 制限を超えたことを示す通知を送ります (適切な監査ファイルシステムについては、「監査デーモンが使用できるディレクトリ」 を参照してください)。

    デフォルトでは、各マシン上で一定の程度の監査が構成されます。デフォルトの audit_control ファイルには、表 2-6 の各行が入っています。各行によって、監査ディレクトリが /var/audit として設定され、システムワイドな監査フラグ (lo) が 1 つ設定され、minfree のしきい値が 20 パーセントに設定され、非帰因フラグが 1 つ設定されます。

    表 2-6 audit_controlファイル内のエントリ
    dir:/var/audit
flags:lo
minfree:20
naflags:ad

  4. /etc/security/audit_control ファイルを編集します。

    1. このマシン上でどの監査ファイルシステムを監査トレールの格納に使用するかを指定します。

      監査ディレクトリごとに dir: エントリをカレントマシンで使用できるようにします。分散システムの監査ディレクトリ方式を設定する方法については、「監査トレールについて」を参照してください。

    2. flags: フィールド内で、すべてのユーザのプロセスに適用されるシステムワイドな監査フラグを指定します。

      flags: フィールドで指定したシステムワイドな監査フラグは、すべてのユーザのプロセスに適用されるので、各マシン上で同じフラグを設定する必要があります。

    3. 必要であれば、minfree のパーセンテージを変更して監査のしきい値を拡大または縮小します。

    4. 特定のユーザに帰因しないイベントに適用される naflags: を指定します。

  5. 変更が必要であれば、auditconfig を使用して監査方針を変更します。

    auditconfig(1M) のマニュアルページ、または 「auditconfig コマンド」を参照してください。方針を指定する変数は動的なカーネル変数なので、その値はシステムの終了時に保存されません。したがって、適切な起動スクリプトを使用して目的の方針を設定する必要があります。

  6. cnt 方針を設定するか、または監査管理アカウントを設定します。

    監査トレールがあふれた場合に備えて、システムを引き続き機能させられるように cnt 方針を使用可能にするか、または監査されなくても機能できるようにアカウントを 1 つ使用可能にしなければなりません。このアカウントを設定する手順は次のとおりです。

    1. /etc/passwd ファイルに次のエントリを追加します。

      audit::0:1::/:/sbin/sh
      注 -

      このエントリは、root が所有するプロセスを正常に機能させるために、root ユーザのエントリの下に追加しなければなりません。

    2. 対応するエントリを /etc/shadow ファイルに追加するには、次のように入力します。

      # pwconv
pwconv: WARNING user audit has no password

      監査アカウントのパスワードは手順 d. で設定します。

    3. /etc/security/audit_user ファイルに次のエントリを追加して、このアカウントの監査をオフにします。

      audit:no:all

    4. passwd を使用して新しいアカウントのパスワードを設定します。

      # passwd audit

      このアカウントを通じて実行される処置は監査の対象外なので注意してください。システムの完全性を保護するには、簡単には推測できないパスワードを使用してください。この例では、アカウント名として audit を使用しています。アカウントを設定する場合は、サイトに適した名前を選択してください。

監査トレールのオーバーフローを防ぐ

すべての監査ファイルシステムがいっぱいになると、audit_warn はすべての監査ファイルシステム上で強い制限値を超えたことを示すメッセージをコンソールに送り、別名にもメールを送ります。デフォルトで、監査デーモンはループ内に残り、ある程度の領域が解放されるまで休眠して領域の有無をチェックします。監査対象の処置はすべて中断されます。

サイトのセキュリティ要件の関係で、監査トレールのオーバーフローによってシステムの動作が中断されるよりは、一部の監査データが失われる方がよいという場合があります。その場合は、自動検出機能を構築するか、ファイルを audit_warn スクリプトに移動するか、または auditconfig を設定してレコードを削除させることができます。

監査トレールのオーバーフローを防ぐ方法

セキュリティ方針の関係ですべての監査データを保存する必要がある場合は、次の手順にしたがいます。

  1. 定期的に監査ファイルを保存し、保存した監査ファイルを監査ファイルシステムから削除するようなスケジュールを設定します。

  2. バックアップをテープに作成するか、保存ファイルシステムに移動して、監査ファイルを手作業で保存します。

  3. 監査レコードの解釈に必要な、内容に対応する情報を、監査トレールといっしょに格納します。

  4. どんな監査ファイルを移動したかを示すレコードをオフラインで保管します。

  5. 保存したテープを適切な方法で保管します。

  6. サマリファイルを作成して、格納する監査データのボリュームを削減します。

    auditreduce のオプションを使用すると、監査トレールからサマリファイルを抽出できるため、サマリファイルには指定したタイプの監査イベントのみが入っています。たとえば、すべてのログインとログアウトの監査レコードのみが入ったサマリファイルがあります。第 3 章「監査トレールの分析」を参照してください。

auditconfig コマンド

autoconfig コマンドは、監査構成パラメータを設定するためのコマンド行インタフェースを提供します。auditconfig(1M) のマニュアルページを参照してください。auditconfig コマンドには次のようなオプションを使用できます。

-chkconf

カーネル監査イベントとクラスのマッピングの構成をチェックし、矛盾があれば報告します。

-conf

カーネルイベントとクラスのマッピングが、audit_event ファイル内の現在のマッピングと一致するように実行時に再構成します。

-getcond

マシンの監査条件を取得します。表 2-7 に考えられる応答を示します。

表 2-7 考えられる監査条件

応答 

意味 

auditing

監査が使用可能でオンになっている。 

no audit

監査は使用可能だがオフになっている。 

disabled

監査モジュールは使用可能になっていない。 

-setcond condition

マシンの監査条件を auditing または noaudit で設定します。

-getclass event_number

指定するイベントがマップされている事前選択クラスを取得します。

-setclass event_number audit_flags

指定するイベントがマップされる事前選択クラスを設定します。

-lsevent

現在構成されている (実行時) カーネルとユーザ監査イベント情報を表示します。

-getpinfo pid

指定するプロセスの監査 ID、事前選択マスク、端末 ID、監査セッション ID を取得します。

-setpmask pid flags

指定するプロセスの事前選択マスクを設定します。

-setsmask asid flags

指定する監査セッション ID を持つすべてのプロセスの事前選択マスクを設定します。

-setumask auid flags

指定するユーザ監査 ID を持つすべてのプロセスの事前選択マスクを設定します。

-lspolicy

監査方針のリストと、それぞれの短い説明を表示します。

-getpolicy

現在の監査方針フラグを取得します。

-setpolicy policy_flag[,policy_flag]

監査方針フラグを指定する方針に設定します。次の監査方針の設定を参照してください。

監査方針の設定

-setpolicy フラグを指定して auditconfig を使用すると、デフォルトの Solaris-BSM 監査方針を変更できます。-lspolicy 引数を指定して auditconfig コマンドを使用すると、変更できる監査方針が表示されます。次のような方針フラグがあります。

arge

execv に関する環境変数を記録します (exec(2) のマニュアルページを参照)。デフォルトではこの情報を記録しません。

argv

execv のコマンド行引数を記録します。デフォルトではこれらの情報を記録しません。

cnt

待ち行列がいっぱいになっても、監査対象の動作を中断せず、単に削除された監査レコード数をカウントします。デフォルトでは中断します。

group

監査レコードに補助グループトークンを含ませます。デフォルトでは、グループトークンは含まれません。

path

監査レコードに二次 path トークンを追加します。一般に、これらの二次パスは、動的にリンクされた共有ライブラリまたはシェルスクリプトのコマンドインタープリタのパス名です。デフォルトでは、これらは含まれません。

trail

すべてのレコードに trailer トークンが含まれます。デフォルトでは、trailer トークンは記録されません。

seq

すべての監査レコードにシーケンス番号が含まれます。デフォルトでは、シーケンス番号は含まれません (シーケンス番号を使用すると、クラッシュダンプを分析して監査レコードが失われたかどうかを調べることができます)。

どのイベントがどの監査クラスに属するかを変更する方法

次の手順で、デフォルトのイベントとクラスとのマッピングを変更します。

  1. /etc/security/audit_event ファイルを編集して、目的の各イベントのクラスマッピングを変更します。

  2. システムをリブートするか、または auditconfig -conf を実行して、実行時カーネルイベントとクラスとのマッピングを変更します。

クラス定義の変更

ファイル /etc/security/audit_class には、クラス定義が格納されます。サイト固有の定義を追加して、デフォルトの定義を変更できます。このファイル内の各エントリの書式は次のとおりです。

mask:name:description

各クラスはマスク内の 1 ビットとして表されます。これは符号なしの整数で、32 種類の使用可能なクラスと、2 つのメタクラス all と no を示します。all は、使用可能なすべてのクラスを連結したものです。no は無効なクラスです。このクラスにマップされたイベントは監査されません。no クラスにのみマップされたイベントは、all クラスがオンになっていても監査されません。次は、audit_class ファイルの例です。

0x00000000:no:invalid class
0x00000001:fr:file read
0x00000002:fw:file write
0x00000004:fa:file attribute access
0x00000008:fm:file attribute modify
0x00000010:fc:file create
0x00000020:fd:file delete
0x00000040:cl:file close
0xffffffffff:all:all classes

システムカーネル内で no クラスがオンになっていると、監査トレールは監査イベント AUE_NULL のレコードでいっぱいになってしまいます。