test

Trusted Solaris の監査管理

監査フラグ

監査フラグは、監査クラスの短形式名です。audit_control(4) ファイル、audit_user(4) ファイルで監査フラグを使用することにより、監査するクラスを指定できます。また、監査フラグは、auditconfig(1M) コマンドの引数として使用できます。

audit_control ファイルについては、「ワークステーションの監査」で説明します。また、audit_user ファイルについては、「audit_user ファイル」で説明します。

監査フラグの定義

表 A-1 に、事前定義済みの監査クラスを示します。左から順に、監査フラグ (監査クラスを表す短形式名)、監査クラス名 (長形式名)、監査マスク、デフォルトで監査クラスにある監査イベントのリストへのポインタを表しています。システム管理者は、監査フラグを監査構成ファイル内で使用することにより、監査を行うイベントクラスを指定します。audit_class(4) ファイルに新しくクラスを追加したり、既存のクラスの名前を変更することも可能です。

監査フラグの構文

イベントが成功した場合、失敗した場合、またはイベントの成否にかかわらず、クラスのイベントを監査することができます。どんな場合に監査を行うかは、接頭辞によって決まります。監査フラグの書式は次のとおりです。 

監査フラグ
-lo				# イベントが失敗した場合に監査を行う
+lo				# イベントが成功した場合に監査を行う
lo				# イベントの成否にかかわらず監査を行う

監査フラグ +lo は「成功したすべてのログインとログアウト」を表し、監査フラグ -lo は「失敗したすべてのログイン」を表します (ログアウトに失敗することはありません)。監査フラグ lo は「成功したすべてのログインとログアウト、失敗したすべてのログイン」を表します。

注 -

監査クラス xs を失敗した場合について監査してはなりません。これは、監査トレールに多数の雑音が生成されるためです。正しい監査フラグは +xs です。X サーバーの監査クラスの詳細については、audit_class(4) ファイルを参照してください。

このほかに、成功した処理すべてを監査する +all フラグがあります。

注意 - 注意 -

フラグ all は大量のデータを生成するので、監査ファイルシステムがすぐにいっぱいになります。特別な理由で全イベントを監査する必要がある場合以外は、フラグ all を使用しないでください。

次の表に示す接頭辞は、どのような場合に監査クラスの監査を行うかを規定します。それぞれ、イベントが成功した場合、失敗した場合、またはイベントの成否にかかわらず監査を行うことを表しています。

表 1-2 監査フラグで使用する接頭辞

接頭辞 

定義 

なし 

イベントの成否にかかわらず監査 

+

成功した場合に限って監査 

-

失敗した場合に限って監査

すでに設定されている監査フラグを修正する接頭辞

修正接頭辞には、3 通りの使用方法があります。具体的には、audit_control(4) ファイルの flags: 行で使用して規定済みのフラグを修正するか、audit_user(4) ファイルのユーザーエントリの中のフラグに使用するか、auditconfig(1M) コマンドの引数に使用するかです。

表 1-3 の接頭辞を監査フラグに付けると、すでに規定されている監査クラスの有効・無効を切り替えることができます。接頭辞には、すでに規定されているフラグの有効・無効を切り替える働きしかありません。

表 1-3 すでに規定されている監査フラグの修正に使用する接頭辞

接頭辞 

定義 

^-

失敗した処理の監査を無効にする 

^+

成功した処理の監査を無効にする 

^

失敗した処理と成功した処理両方の監査を無効にする 

次の例では、接頭辞 ^- を audit_control ファイルの flag: 行で使用しています。 

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

監査ファイルの保存場所

どのワークステーションでも、/etc/security/audit ディレクトリには監査ログファイルすべてを収めたサブディレクトリがあります。/etc/security ディレクトリには、監査構成に関連するファイルが収められていて、ブート時に監査デーモンが使用するワークステーションごとの audit_data ファイルもここに含まれます。このディレクトリは必ずルートファイルシステムの一部としてください。

監査事後選択ツールは、デフォルトでは /etc/security/audit の下のディレクトリを検索します。したがって、監査サーバーにはじめて監査ファイルシステムをマウントする場合、そのパス名は、/etc/security/audit/server-name (server-name は監査サーバーの名前) のような書式になります。監査サーバーに複数の監査パーティションがある場合、第 2 のマウント先のパス名は /etc/security/audit/server-name.1 、第 3 のマウント先のパス名は /etc/security/audit/server-name.2 となり、以下同様に続きます。

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

各監査ファイルシステムには、files という名前のサブディレクトリがあります。監査ファイルはこの files サブディレクトリに収められており、これを検索するには auditreduce コマンドを使用します。監査ファイルサーバー audubon の場合、 files サブディレクトリのフルパス名は /etc/security/audit/audubon/files になります。

監査デーモンは、各ワークステーションのローカルファイル audit_control の命令に従って、監査ファイルを files サブディレクトリに配置します。たとえば、監査サーバー eagle から監査ファイルシステムをマウントする場合、ワークステーションの audit_control ファイルの dir: 行は次のようになります。

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

なんらかの理由で監査サーバーの /etc/security/audit/server-name[.suffix] (server-name は監査サーバーの名前、.suffix は監査パーティションを表わす接尾辞) ディレクトリが使用できない場合、臨時の階層レベルを使ってワークステーションのローカルルートファイルシステムが監査ファイルでいっぱいになるのを防ぐことができます。files サブディレクトリは監査サーバーにあり、ローカルの監査ログファイルも監査サーバーと同様に /etc/security/audit/client-name (client-name はクライアント名) という名前になります。このため、万一マウントに失敗しても、ローカルのマウント先ディレクトリに監査ファイルが作成されてしまうことはありません。

監査ディレクトリのアクセス権

次の表に、/etc/security/audit/workstation-name (workstation-name はワークステーション名) ディレクトリのアクセス権と、そのすぐ下の files ディレクトリのアクセス権を示します。

表 1-4 監査ディレクトリとファイルのアクセス権

所有者 

グループ 

アクセス権 

audit 

audit 

750 

ワークステーションの監査

監査の設定は、セキュリティ管理者がワークステーションごとに行います。設定ファイルは、audit_control です。このファイルは各ワークステーションにあり、監査デーモンがこれを読み取ります (audit_control(4) のマニュアルページを参照してください)。audit_control ファイルは、/etc/security ディレクトリにあります。

通常、dir: 行と minfree: 行はワークステーション固有なので、ワークステーションごとに別々の audit_control ファイルを管理することになります。分散システムでは、これ以外の行は全く同じになります。

audit_control ファイルでは、次のように 4 種類の情報を別々の行に規定します。

セキュリティ管理者は、各ワークステーションでの構成時にデフォルトの audit_control ファイルを修正します。

分散システムのセキュリティ管理者は、audit_control ファイルの構成が終わったら、これをその他のワークステーションに配布します。このファイルを変更した場合、管理者はネットワーク上のすべてのワークステーションで audit -s を実行し、監査デーモンに audit_control ファイルをもう一度読み込ませます。

注 -

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

audit_control ファイルの例

次に、ワークステーション willet の audit_control ファイルの例を示します。willet は、監査サーバー egret の 2 つの監査ファイルシステムと、監査管理サーバー audubon からマウントした 3 番目の監査ファイルシステムを使用します。3 番目のファイルシステムは、egret の監査ファイルシステムがいっぱいであるか、または使用できない場合に限って、監査レコードを保存します。minfree の値が 20% になっているので、ファイルシステムの 80% がいっぱいになり、現在のワークステーションの監査データが新しいディレクトリに保存される時点で警告スクリプトが実行されます (audit_warn(1M) のマニュアルページを参照)。フラグは、ログインと管理操作すべてをその成否にかかわらず監査することと、ファイルシステムのオブジェクト作成の失敗を除く全種類の失敗イベントを監査することを表しています。 

flags:lo,ad,-all,^-fc
naflags:lo,nt
minfree:20
dir:/etc/security/audit/egret/files
dir:/etc/security/audit/egret.1/files
#
# Audit filesystem used when egret fills up
#
dir:/etc/security/audit/audubon

例外的な監査を実施するユーザー

セキュリティ管理者は、デフォルト構成の監査を設定します。audit_control ファイルに規定したシステム全体の監査フラグで、ユーザーと管理者全員を監査することができます。ここで、ユーザーごとに監査内容を微調整するためには、audit_user ファイルにユーザーエントリを追加します。新規ユーザーを追加する際に監査フラグを追加することもできます。監査の設定は、アカウントのロックを解除し、新規ユーザーのセキュリティ属性を設定してから行なってください。

注 -

1 台のワークステーション上の静的監査データベース (audit_control、audit_user、audit_startup、および audit_warn) を変更した場合は、変更をネットワーク上のすべてのワークステーションにコピーしてください。「監査構成ファイルをネットワーク上の各ワークステーションに配布する方法」を参照してください。

静的データベースにユーザー単位の監査管理情報を記述できるのはもちろんですが、ワークステーションでユーザープロセスが実行されている間でも、監査の条件を動的に調整することができます。

audit_user ファイル

一部のユーザーに対して他と異なる監査を行うことが望ましい場合には、管理者は、audit_user ファイルを編集して個々のユーザーに監査フラグを追加することができます。ここで指定したフラグと、監査管理ファイルに規定されているシステム全体のフラグとの組み合わせで、そのユーザーを監査するイベントクラスが決まります。管理者は、audit_user ファイルのユーザーエントリにフラグを追加して、audit_control ファイルのデフォルトを変更します。そのとき、そのユーザーについては監査をまったく行わないイベントクラスのセットが規定されるか、常に監査を行うイベントクラスのセットが規定されるかのどちらかになります。

したがって、個々のユーザーの監査内容は、次に示すとおり、ワークステーションの監査フラグと、ユーザーの常時監査実行フラグ、監査回避フラグの組み合わせとなります。

監査内容 = (ワークステーションの監査フラグ + ユーザーの常時監査実行フラグ) - ユーザーの監査回避フラグ　

audit_user ファイルはユーザーごとに設定します。このファイルのエントリには 3 つのフィールドがあり、順に、「ユーザー名」フィールド、「常時監査実行」フィールド、「監査回避」フィールドといいます。

後の 2 つの監査フィールドは順番に処理されます。最初のフィールドで監査が有効になり、2 番目のフィールドで監査が無効になります。

注 -

「監査回避」フィールドには all を設定しないでください。「常時監査実行」フィールドのフラグ設定が打ち消され、そのユーザーの監査がすべて無効になってしまいます。

「監査回避」フラグをユーザーに適用することと、「常時監査実行」 のセットからクラスを削除することは異なります。たとえば、下の例では、katya というユーザーに対して、ファイルシステムのオブジェクトの読み取りの成功を除くすべての監査を行います (この設定では、すべてのデータ読み込みを監査する場合の約 3/4 の監査データを生成するだけでユーザーの行動のほぼ全部を監査できます)。同時にシステムデフォルトを katya に割り当てるとすると、audit_user のエントリには次の 2 通りが考えられます。

正しい設定は次のようになります。

katya:all,^+fr:

次の設定は誤りです。

katya:all:+fr

最初の例では、「ファイルの読み取り成功以外すべてを常時監査する」ということを表し、2 番目の例では「全部を常時監査するが、成功したファイル読み取りの監査は行わない」ということを表します。2 番目の例が誤りなのは、この設定がシステムデフォルトより優先されるためです。一方、最初の例では、audit_user に規定した内容とともに、それ以前のデフォルトも適用されるので、期待通りの結果が得られます。

注 -

成功イベントと失敗イベントは別々に扱われます。たとえば、エラーが発生した場合にプロセスから生成される監査レコードの数が、イベントが成功した場合より多くなることがあります。

動的制御では、プロセスの実行中に管理者が所定の場所に入力した命令が参照されます。この制御は、プロセスとその子プロセスが存在する間だけ継続し、次にログインするときには無効になります。監査コマンドは、現在ログインしているワークステーションだけに適用されるので、複数台のワークステーションで動的制御を行うことはできません。

各プロセスには、監査クラス用として 1 ビットのフラグが 2 セットあります。そのうちの 1 セットでは、クラス内のイベントの要求が成功した場合にプロセスを監査するかどうかを制御し、もう一方のセットでは、イベントを要求しても何らかの理由で失敗した場合に監査するかどうかを制御します。プロセスの監査にあたっては、一般に、成功よりも失敗の方がより重点的に監査されます。これは、監査結果を利用して、ブラウズしたり、システムのセキュリティを破ろうとする各種の行為を検知するためです。

プロセス監査の特性

次の監査特性は、最初のログイン時に設定します。

プロセス事前選択マスク

ユーザーがログインすると、login によって、audit_control ファイルのワークステーション全体の監査フラグと、audit_user ファイルにユーザー固有の監査フラグがある場合はそのフラグが 組み合わされ、そのユーザーのプロセスのプロセス事前選択マスクが設定されます。プロセス事前選択マスクによって、各監査イベントクラスのイベントが監査レコードを生成するかどうかが規定されます。

プロセス事前選択マスクを得るためのアルゴリズムは次のとおりです。まず、audit_control ファイルの flags: 行の監査フラグが、audit_user ファイルのユーザーエントリにある「常時監査実行」フィールドのフラグに追加されます。次に audit_user ファイルのユーザー項目にある「監査回避」フィールドのフラグが全体から引かれます。 

ユーザープロセス事前選択マスク = (flags: 行 +「常時監査実行」フラグ) -「監査回避」フラグ

監査 ID

ユーザーのログイン時、各プロセスは監査 ID を取得します。この監査 ID は、ユーザーの最初のプロセスによって生成した子プロセスすべてに引き継がれるため、ユーザーの行動を追跡するのに役立ちます。ユーザーが役割になった後でも監査 ID は変わりません。また、各監査レコードに監査 ID が保存されるため、管理者はいつでもログインした元のユーザーまで戻って、そのアクションを追跡することができます。

監査セッション ID

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

端末 ID

端末 ID は、ホスト名とインターネットアドレス、それに続く固有番号で構成され、この固有番号でユーザーがログインした物理デバイスを識別します。たいていの場合、ログインはコンソールを通じて行うので、コンソールデバイスに対応する固有番号は 0 になります。

audit_data ファイル

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


# cat /etc/security/audit_data116:/etc/security/audit/egret.1/files/
19910320100002.not_terminated.tern

監査デーモンの役割

監査デーモン auditd(1M) の処理内容を次にまとめます。

監査デーモンがワークステーションのマルチユーザーモードへの移行と共に起動する場合、または、audit -s コマンドによって、監査デーモンがファイルの編集後にファイルを再度読み込むように指示されている場合、auditd は必要な空き領域の大きさを判断して audit_control ファイルからディレクトリのリストを読み込み、そのディレクトリを監査ファイルの作成場所の候補とします。

監査デーモンのポインタは、常に、このリストの 1 番最初のディレクトリに位置しています。監査デーモンは、監査ファイルを作成しなくてはならなくなるたびに、現在監査デーモンのポインタがある、リスト中の最初のディレクトリにファイルを配置します。

監査データ保存時のディレクトリの最適化

監査レコードの保存に適しているディレクトリとは、監査デーモンにアクセスできるディレクトリです。つまり、そのディレクトリがマウントされ、遠隔の場合はネットワーク経由でのアクセスが認可されていることと、ディレクトリに対するアクセス権を持っていることが条件です。監査ファイルの保存用にディレクトリを最適化するためには、空き領域が十分に残っていることも必要です。この場合、audit_control ファイルの minfree: 行を編集してデフォルト値の 20% を変更できます。たとえば、minfree の設定が空き領域のデフォルト最低値 20% の場合、ファイルシステムの使用容量が 80% を越えると、audit_warn エイリアスに電子メール通知が送られます。

リスト中のどのディレクトリにも十分な空き領域が残っていない場合には、デーモンはリストの冒頭から検索を開始し、使用可能な領域のあるアクセス可能な最初のディレクトリを選び出して制限値に達するまで使用します。デフォルトの構成では、適したディレクトリがない場合には、デーモンは監査レコードの処理を停止し、監査レコードを生成しているプロセスがすべて中断されるまでの間、カーネルにレコードを蓄積します。

監査ファイルを処理しやすいサイズで保存

監査ファイルを処理しやすいサイズで保存するためには、cron ジョブを設定します。cron ジョブによって、監査ファイルを定期的に切り替えることができます (cron(1M) のマニュアルページを参照)。その間隔は、収集する監査データの量によって 1 時間に 1 回から 1 日に 2 回までの範囲です。ここでデータをフィルタにかけて不要なデータを削除し、さらに圧縮することができます。