test

Trusted Solaris の監査管理

第 1 章 監査の基本

この章では、監査の機能について説明します。監査は、1 台のワークステーション上で行われる場合と、複数台の Trusted Solaris ワークステーションで構成されたネットワーク上で行われる場合があります。

監査で実行できることは次のとおりです。

監査は、不正に対する抑止力にもなります。つまり、行動を監査される可能性があるとわかっていれば、ユーザーはあまり不正を犯さなくなるのです。

監査の概要

監査機能は、Trusted Solaris オペレーティングシステムのすべてのリリースに含まれている重要な要素です。監査機能はデフォルトで有効になっていますが、無効にしたい場合は、2 つのファイルに変更を加えます。監査ソフトウェアはすべて、次に挙げるパッケージの初期システムインストールに含まれています。

Trusted Solaris の監査機能はデフォルトで有効になっています。この機能には拡張性があり、システム管理者やセキュリティ管理者による設定も行えます。監査レコードはデフォルトで workstation-name :/var/audit/ ディレクトリに保存されます。また、スーパーユーザーは、監査クラス login_logout と non-attribute のイベントについて監査されます。

システム管理者は、監査レコードを保存するための専用パーティションを用意できます。監査結果を分析する担当者は、Trusted Solaris ネットワーク内の全ワークステーションから全レコードを集め、1 件の監査トレールにまとめる (併合する) ことができます。ワークステーションのネットワークから集めた監査レコードは、1 つの大きなファイルとして開くことができます。また、各種の基準を適用して、収集するレコードを選択することができます。

監査データが 1 つの監査トレールにまとめられたら、監査を評価する担当者は、選択 (「事後選択」という) ツールや変換ツールを使って、監査トレールの特定部分を調べることができます。たとえば、ユーザー別、グループ別、ホスト名別、特定の日付の特定種類のイベント別、1 日の時間別などのように、レコードを選択できます。

Trusted Solaris の監査では、監査管理を簡単にするため、監査イベントをクラス分けすることができます。セキュリティ管理者が監査するイベントクラスを指定すると、そのクラスのイベントすべてについて監査が行われます。ユーザーコマンドやカーネルシステムコールも監査イベントです。監査するイベントのクラスは、ワークステーションごとに指定することができます。スーパーユーザーのような特定ユーザーを特に監査することもできます。

セキュリティ管理者は、イベントとクラスのもともとの対応関係を修正して拡張することができます。一部のイベントについては、サイトのセキュリティポリシーに必要ない詳細部分を監査レコードから削除できます。各監査クラスは、ワークステーションごとに、失敗したイベント、成功したイベント、またはその両方について監査されます。監視するアクティビティを選択することを「事前選択」といいます。事前選択で知らせる相手を指定できます。

Trusted Solaris 監査サブシステムでは、機密ラベル admin_high を付けることで、監査レコードがのぞき見されないようになっています。監査構成ファイルをアクセスできるのは適切な管理役割ユーザーだけであり、特権がなければ、レコードを監査待ち行列へ送ることはできません。ISV とインテグレータには、特別な特権 proc_audit_appl が与えられているため、各アプリケーションの監査レコードを監査待ち行列に追加することができます。監査イベント番号 32768 から 65535 までは他社のトラステッドアプリケーション (トラステッドコンピューティングベースのアプリケーション) 用です。

監査の成否は、識別と認証の 2 つのセキュリティ機能で決まります。ログイン時にユーザーがユーザー名とパスワードを入力すると、そのユーザーのプロセスに固有の監査 ID が割り当てられ、ログインセッション中に開始したプロセスのすべてでその監査 ID が引き継がれます。たとえば、ユーザーが、管理役割になって識別情報を変更した場合でも、そのユーザーのアクションはすべて同じ監査 ID で追跡されます。

この章の残りの部分では、監査サブシステムについて説明します。第 2 章「監査の設定」では、監査の設定方法と管理方法について説明します。章の後半では、設定と保守の手順を示します。第 3 章「監査トレールの管理と監査結果の分析」では、監査トレールの概要、監査トレールのファイルの管理方法と読み取り方法について説明します。章の後半では、監査トレールの一般的な管理とその分析手順を示します。

監査の機構

監査は、監査デーモンによって実行されます。監査デーモンには 6 つの監査ファイル、audit_class(4)、audit_event(4)、audit_control(4)、audit_user(4)、 audit_startup(1M)、および audit_warn(1M) があり、それぞれに設定を加えることができます。監査ファイルは /etc/security ディレクトリに収められており、監査の対象、監査ログの保存場所、障害発生時の対処方法は、ここに指定します。デフォルトでは、スーパーユーザーは、監査クラス lo (ログイン / ログアウト) のイベントについて監査されます。また、その監査レコードは /var/audit ディレクトリのファイルに記述され、障害が発生した場合にも電子メールは送信されません。

監査機能の中断や再開は、ワークステーションをリブートしないで行うことができるため、監査対象を動的に変更することができます。

監査の開始

監査は、通常、ワークステーションをブートして監査デーモンが起動すると有効になります (auditd(1M) のマニュアルページを参照)。障害発生時には、admin_high シェルにある /usr/sbin/auditd を実行して手動でデーモンを起動します。この作業はセキュリティ管理者が行います。

/etc/security/audit_startup というパス名を持つファイルがある場合には、システムがマルチユーザーモードに入ると監査デーモンが自動的に実行されます。このファイルは本来は実行可能スクリプトであり、監査デーモンを実行する直前に起動シーケンスの一部として呼び出されます (audit_startup(1M) のマニュアルページを参照)。デフォルトの audit_startup スクリプトは、イベントとクラスの対応関係を自動的に構成し、監査ポリシーを設定します。このスクリプトは監査パッケージのインストール時に作成されます。

セキュリティ管理者は、audit_startup スクリプトを編集してデフォルトの監査ポリシーを変更することができます。監査ポリシーについては 「監査ポリシーの設定」を参照してください。

監査クラスと監査イベント

セキュリティに関連したアクションについて監査を行います。監査可能なシステムアクションは、/etc/security/audit_event ファイルに「監査イベント」として定義されています。ここには、各監査イベントの記号名、イベント番号、事前選択クラスのセット、簡単な説明も定義されています (audit_event(4) のマニュアルページを参照)。

イベントのほとんどは、個々のユーザーのアクションが原因で発生しますが、ユーザーアクションを原因としないイベントもあります。こうしたイベントはカーネル割り込みレベルで発生したり、ユーザーが識別、認証される前に発生します。このようなユーザーアクションを原因としないイベントも監査することができます。

各監査イベントは、1 つまたは複数の「監査クラス」に属しています。管理者は、監査デーモンに監査対象を設定する際に、「監査フラグ」という監査クラスの短形式名を指定します。クラスを指定すると、そのクラス内の全イベントが同時に指定されます。また、監査イベントとクラスの対応関係やクラス自体の構成も、管理者が行います。構成の変更には audit_event ファイルを使用します。新しいクラスは、audit_class ファイルに追加されます。

監査イベントが監査トレールに記録されるかどうかは、管理者がその監査イベントを含む監査クラスを事前選択しているかによって決まります。

監査クラス

監査クラスの定義は /etc/security/audit_class ファイルに保存されます。サイト固有の定義を追加したり、デフォルトの定義を変更する場合は、このファイルを使用します。ファイル中のエントリはどれも次の書式をとります。

mask:name:description

この場合、mask はマスク、name はクラス名、description は説明を表しています。各クラスは、マスクのビットとして、符号なし整数で表されます。使用できるクラスは最大 32 個で、このほかに all、no の 2 つのグローバルクラスがあります。all は監査する全クラスの集合であり、no は監査しないクラスの集合です。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
0x00000100:nt:network
0x00000200:ip:ipc
0x00000400:na:non-attribute
0x00001000:lo:login or logout
0x00002000:ax:x server
0x00004000:ap:application
0x000f0000:ad:administrative
0x00010000:ss:change system state
0x00020000:as:system-wide administration
0x00040000:aa:audit administration
0x00080000:ao:other administration
0x00300000:pc:process
0x00100000:ps:process start/stop
0x00200000:pm:process modify
0x20000000:io:ioctl
0x40000000:fn:fcntl
0x80000000:ot:other
0xffffffff:all:all classes

監査で実際に no クラスを有効にしていると、監査トレールには監査イベント AUE_NULL のレコードが書き込まれます。

カーネルイベント

カーネル (システムコール) が生成するイベントには、1 から 2047 までのイベント番号が割り当てられています。カーネルイベントのイベント名は AUE_ で始まり、イベントのニーモニックが大文字で続きます。たとえば、creat() システムコールのイベント番号は 4、イベント名は AUE_CREAT です。

カーネルイベントの中には、特権の使用法の判断を監査する AUE_UPRIV という疑似イベントが 1 つ定義されています。

AUE_UPRIV 疑似イベントを事前選択していると、カーネルイベントの監査を指定していなくても、監査情報が収集されます。たとえば、カーネルイベント AUE_OPEN_R の監査を指定していなくても、特権の使用法の判断がシステムコール AUE_OPEN_R の一部であれば、疑似イベント AUE_UPRIV が有効となり、AUE_OPEN_R が監査トレールに書き込まれます。

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

カーネル外部のトラステッドアプリケーションで生成されるイベントには、2048 から 65535 までのイベント番号が割り当てられます。イベント名は AUE_ で始まり、イベントのニーモニックが小文字で続きます。/etc/security/audit_event ファイルには、それぞれのイベントが番号順に一覧表示されています。クラス別のイベントの一覧については、付録 A 「イベントとクラスの対応関係」 を参照してください。次の表に、ユーザー関連イベントの一般的なカテゴリを示します。

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

番号範囲 

イベントの種類 

2048‾65535 

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

2048‾32767 

Solaris および Trusted Solaris のユーザーレベルのプログラム用 

32768‾65536 

他社のアプリケーションで使用 

ユーザーアクションを原因としないイベント

ユーザーアクションを原因としないイベントには、AUE_ENTERPROM などがあります。

監査レコード

監査レコード 1 件には、監査イベント 1 件の発生が記録されています。ここには、アクションを実行したユーザー、それによって影響を受けたファイル、試みられたアクションの種類、発生場所や日時などの情報が含まれています。

各監査イベントについて記録される情報の種類は、監査トークンのセットで定義されます。あるイベントに対する監査レコードが作成されるたびに、レコードには、定義されているトークンの一部または全部が書き込まれます。この内容は、イベントの性質と監査ポリシーによって決まります。付録 B 「監査レコードの詳細」では、イベントごとに定義されるすべての監査トークンとそれぞれのトークンの意味を示します。

複数の監査トークンによって 1 つの監査レコードが構成され、この監査レコードが複数集まって、1 つの監査ファイルが構成されます。監査トレールとは、分散システムにある 1 つ以上の監査ファイルのことです。監査トレールの構造を 図 1-1 に示します。この監査トレールは、praudit でユーザーが読める形式に変換できます (praudit(1M) のマニュアルページを参照)。 auditreduce(1M) を使うと、特定の監査レコードを目的にあわせて選択することができます。詳細は第 3 章「監査トレールの管理と監査結果の分析」を参照してください。

図 1-1 監査トークンから監査トレールまで

Graphic

監査フラグ

監査フラグは、監査クラスの短形式名です。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 回までの範囲です。ここでデータをフィルタにかけて不要なデータを削除し、さらに圧縮することができます。

audit_warn スクリプト

監査デーモンが監査レコードを書き込んでいるときに異常が発生すると、 /etc/security/audit_warn スクリプトが呼び出されます。audit_warn(1M) のマニュアルページを参照してください。このスクリプトをサイトでカスタマイズして、ユーザーの介入を要する場合に警告を出したり、自動処理を行うように設定することができます。どんなエラー状態が発生した場合でも、audit_warn はコンソールにメッセージを書き込み、audit_warn エイリアスにメッセージを送ります。このエイリアスは、監査を有効にした後で管理者が設定します。

audit_warn は、監査デーモンが次の状態を検出した場合に呼び出されます。

監査のコストの管理

システム資源は、監査処理によって消費されます。このため、監査記録の詳細度を管理する必要があります。監査対象は、次の 3 つのコストを考慮して決定します。

処理時間の増大によるコストは、この 3 つの監査コストの中ではもっとも重要性が低い問題です。第 1 には、画像処理や複雑な計算など、コンピュータに負担のかかる作業の処理中には監査が行われないからです。第 2 に、シングルユーザーのワークステーションでは CPU サイクルに十分な余裕があるからです。

監査結果の分析にかかるコストは、収集する監査データの量におおよそ比例します。監査結果の分析コストには、監査レコードを 1 つにまとめて内容を評価するための時間と、レコードをアーカイブとして安全な場所に保管するための時間があります。

生成するレコードの量が少ないほど分析にかかる時間は少なくなります。次の節では、サイトのセキュリティ目標を達成するのに十分な条件を満たしながら、収集するデータ量を減らす方法について説明します。

監査データの保存によるコストが、監査コストのうちもっとも重要です。監査データの量は次の項目に影響されます。

コスト要因は状況が変化するたびに変わるので、監査データを保存するためのディスク容量をあらかじめ決めておくことはできません。

完全監査 (all フラグを使用) を行うと、ディスクがすぐにいっぱいになってしまいます。たとえば、中程度のサイズのプログラム (5 つのファイルで合計 5000 行のプログラムなど) をコンパイルするなど、ごく単純なタスクでも、1 分も経過しないうちに数千もの監査レコードが生成され、何メガバイトものディスク領域を消費する恐れがあります。したがって、事前選択機能を使って、生成するレコードの量を減らすことが非常に大切です。たとえば、fr クラスを監査しないだけでも監査量を 2/3 以上減らすことができます。監査レコードを作成した後も、監査ファイル管理によって、使用するディスク領域を効率的に減らしていくことが大切です。

監査の効率

サイトのセキュリティ目標を厳守しながら監査の効率化を図るため、何を監査するか、いつ監査するか、どこへファイルを保存するかを検討します。実際には次のような例が考えられます。

auditconfig コマンド

auditconfig コマンドは、監査構成情報を取得したり監査ポリシーを設定するためのコマンド行インタフェースです。このコマンドを audit_startup(1M) スクリプトで使用すると、監査デーモンの起動時に監査ポリシーを設定することができます。auditconfig コマンドの使用例については、auditconfig(1M) のマニュアルページや 「動的手続き」を参照してください。

-chkconf

カーネル監査イベントとクラスの対応関係を検査し、矛盾があれば報告します。

-conf

カーネル監査イベントとクラスの対応関係を実行時に構成しなおして、audit_event ファイルの最新の割り当てに一致させます。

-getcond

ワークステーションの監査条件を取得します。次に考えられる応答を示します。

auditing

監査は有効で実行可能

noaudit

監査は有効だが実行回避

disabled

監査モジュールは無効

-setcond condition

ワークステーションの監査条件を auditing または noaudit に設定します。監査を無効にするためには、audit スクリプトと system (4) ファイルを変更してシステムを再起動します。手順については、「監査を無効にする方法」を参照してください。

-getclass event_number

指定するイベントが対応づけられている事前選択クラスを獲得します。

-setclass event_number

指定するイベントが対応づけられている事前選択クラスを設定します。

-lsevent

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

-getpinfo pid

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

-setkmask +/-audit_flags

指定する監査フラグに対してユーザーアクションを原因としないイベントのカーネル事前選択マスクを設定します。

-setkmaskac

audit_control ファイルの naflags フィールドに規定されたクラスに対してユーザーアクションを原因としないイベントのカーネル事前選択マスクを設定します。

-setpmask pid flags

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

-setsmask asid flags

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

-setumask auid flags

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

-lspolicy

監査ポリシーのリストと項目ごとの簡単な説明を表示します。

-getpolicy

最新の監査ポリシーフラグを獲得します。

-setpolicy policy_flag

指定するポリシーに監査ポリシーフラグを設定します。次の「監査ポリシーの設定」を参照してください。

監査ポリシーの設定

auditconfig コマンドに引数 -setpolicy を付けて実行すると、デフォルトの Trusted Solaris 監査ポリシーを変更できます。監査ポリシーを設定すると、監査レコードにオプションの監査トークンが追加されます。auditconfig コマンドに引数 -lspolicy を付けて実行すると、オプションの監査ポリシーが表示されます。各監査ポリシーとそれぞれの簡単な説明については、「現在の監査ポリシーを決定する方法」を参照してください。わかりにくいポリシーフラグについては、補足説明を次に示します。

注意 - 注意 -

評価済みの構成で監査を実行する場合に、cnt ポリシーや passwd ポリシーを有効にすることはできません。これらのポリシーは設定しません。

ahlt

監査待ち行列に送ることができない非同期の監査イベントが発生した場合にコンピュータを停止します。デフォルトでは、ワークステーションは停止しません。

cnt

待ち行列がいっぱいの場合にも監査アクションを中断せず、生成された監査レコードの数をカウントします。デフォルトでは、監査アクションは中断します。

注 -

デフォルトの設定に戻すためには、cnt ポリシーを削除します。監査ポリシーの置き換え、追加、削除の例については、「監査ポリシーを一時的に設定する方法」を参照してください。

path

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

seq

各監査レコードにシーケンス番号を収めます。デフォルトではシーケンス番号は収められていません (シーケンス番号を使ってクラッシュダンプを分析し、監査レコードの欠落がないかどうか調べることができます)。