監査の用語と概念

監査サービスでは、次の用語が使用されています。定義によっては、より詳細な説明への参照先も示します。

監査クラス

監査イベントのグループ。監査クラスは、監査対象のイベントのグループの選択方法を提供します。

詳細は、「監査クラスおよび事前選択」、および audit_flags(5)、audit_class(4)、audit_event(4) の各マニュアルページを参照してください。

監査ファイルシステム

バイナリ形式の監査ファイルのリポジトリ。

詳細は、「監査ログ」および audit.log(4) のマニュアルページを参照してください。

監査イベント

監査可能なセキュリティー関連のシステム動作。選択を容易にするために、イベントは監査クラスにグループ化されます。

詳細は、「監査イベント」および audit_event(4) のマニュアルページを参照してください。

監査フラグ

コマンドまたはキーワードへの引数として指定される監査クラス。フラグには、このクラスが成功 (+) または失敗 (-) について監査されることを示すプラス記号またはマイナス記号の接頭辞を付けることができます。直前のキャレット (^) は、成功を監査対象としない (^+) か、または失敗を監査対象としない (^-) ことを示します。

詳細は、audit_flags(5) のマニュアルページおよび「監査クラスの構文」を参照してください。

監査プラグイン

キュー内の監査レコードを指定された場所に転送するモジュール。audit_binfile プラグインは、バイナリ監査ファイルを作成します。バイナリファイルは、監査ファイルシステム上に格納される監査トレールを構成します。audit_remote プラグインは、バイナリ監査レコードをリモートリポジトリに送信します。audit_syslog プラグインは、選択された監査レコードを syslog ログ内に集計します。

詳細は、「監査プラグインモジュール」、および audit_binfile(5)、audit_remote(5)、audit_syslog(5) の各モジュールのマニュアルページを参照してください。

監査ポリシー

サイトで有効または無効を指定できる監査オプションのセット。特定の種類の監査データを記録するかどうかのオプションがあります。また、これらのオプションには、監査キューがいっぱいになったときに監査可能なアクションを中断するかどうかの指定も含まれます。

詳細は、「監査ポリシーについて」および auditconfig(1M) のマニュアルページを参照してください。

監査レコード

監査キュー内に収集された監査データ。1 つの監査レコードにつき 1 つの監査イベントが記述されます。各監査レコードは、一連の監査トークンから構成されます。

詳細は、「監査レコードと監査トークン」および audit.log(4) のマニュアルページを参照してください。

監査トークン

監査レコードまたはイベントのフィールド。各監査トークンには、監査イベントの 1 つの属性 (ユーザー、プログラム、その他のオブジェクトなど) が記述されます。

詳細は、「監査トークンの形式」および audit.log(4) のマニュアルページを参照してください。

監査トレール

デフォルトのプラグイン audit_binfile を使用するすべての監査対象システムからの監査データを格納する 1 つ以上の監査ファイルの集合。

詳細は、「監査トレール」を参照してください。

ローカル監査

ローカルシステム上で生成された監査レコードの収集。レコードは、大域ゾーンまたは非大域ゾーン、あるいはその両方で生成される場合があります。

詳細は、「監査プラグインモジュール」を参照してください。

事後選択

監査トレール内のどの監査イベントを検査するかの選択。デフォルトのアクティブなプラグイン audit_binfile によって監査トレールが作成されます。事後選択ツールである auditreduce コマンドは、監査トレールからレコードを選択します。

詳細は、auditreduce(1M) と praudit(1M) のマニュアルページを参照してください。

事前選択

どの監査クラスをモニターするかの選択。事前選択された監査クラスの監査イベントが監査キュー内に収集されます。事前選択されていない監査クラスは監査されないため、それらのイベントはキューに入りません。

詳細は、「監査クラスおよび事前選択」、および audit_flags(5) と auditconfig(1M) のマニュアルページを参照してください。

公開オブジェクト

root ユーザーによって所有され、すべてのユーザーが読み取ることのできるファイル。たとえば、/etc ディレクトリと /usr/bin ディレクトリは公開オブジェクトです。公開オブジェクトの読み取り専用イベントは監査されません。たとえば、file_read (fr) 監査フラグが事前選択されている場合でも、公開オブジェクトの読み取り動作は監査されません。public 監査ポリシーオプションを変更すると、デフォルトをオーバーライドできます。

リモート監査

アクティブな audit_remote プラグインが構成されている監査対象のシステムから監査レコードを受信して格納する監査リモートサーバー (ARS)。監査対象システムを ARS と区別するには、監査対象システムを「ローカルで監査されるシステム」と呼ぶことができます。

詳細は、auditconfig(1M) のマニュアルページにある -setremote オプションおよび「監査リモートサーバー」を参照してください。

監査イベント

監査イベントは、システム上の監査可能なアクションを表します。監査イベントは、/etc/security/audit_event ファイルに指定します。各監査イベントは、システムコールまたはユーザーコマンドに接続され、1 つ以上の監査クラスに割り当てられます。audit_event ファイルの形式については、audit_event(4) のマニュアルページを参照してください。

たとえば、AUE_EXECVE 監査イベントは、 execve() システムコールを監査します。コマンド auditrecord -e execve は、このエントリを表示します。

execve
  system call execve               See execve(2)
  event ID    23                   AUE_EXECVE
  class       ps,ex                (0x0000000040100000)
      header
      path
      [attribute]                  omitted on error
      [exec_arguments]             output if argv policy is set
      [exec_environment]           output if arge policy is set
      subject
      [use_of_privilege]
      return

監査クラス ps と監査クラス ex のどちらかを事前選択した場合は、すべての execve() システムコールが監査キュー内に記録されます。

監査は、ユーザーに起因するイベントとユーザーに起因しないイベントを処理します。監査ポリシーでは、次のように、イベントが同期イベントと非同期イベントに分割されます。

ユーザーに起因するイベント – ユーザーによって起こるイベント。execve() システムコールはユーザーに起因させることができるため、その呼び出しはユーザーに起因するイベントと見なされます。ユーザーに起因するイベントはすべて、同期イベントです。
ユーザーに起因しないイベント – カーネル割り込みレベルで、またはユーザーが認証される前に発生するイベント。na 監査クラスは、ユーザーに起因しない監査イベントを処理します。たとえば、システムのブートは、ユーザーに起因しないイベントです。ユーザーに起因しないイベントは、そのほとんどが非同期イベントです。ただし、失敗したログインなどの、プロセスが関連付けられている、ユーザーに起因しないイベントは同期イベントです。
同期イベント – システムのプロセスに関連付けられたイベント。システムイベントの大半は同期イベントです。
非同期イベント – プロセスに関連付けられていないイベント。そのため、ブロックした後に呼び起こすプロセスはありません。たとえば、システムの初期ブートや PROM の開始および終了のイベントは、非同期イベントです。

監査サービスによって定義される監査イベントに加えて、サードパーティーのアプリケーションも監査イベントを生成できます。32768 から 65535 までの監査イベント番号がサードパーティーのアプリケーションで使用できます。ベンダーは、イベント番号を予約し、監査インタフェースへのアクセスを取得するために Oracle Solaris の担当者に連絡する必要があります。

監査クラスおよび事前選択

各監査イベントは、1 つまたは複数の監査クラスに属しています。監査クラスは、多数の監査イベントが入った便利な入れ物です。クラスを監査対象として事前選択した場合は、そのクラス内のすべてのイベントが監査キュー内に記録されます。たとえば、ps 監査クラスを事前選択すると、execve()、fork()、およびその他のシステムコールが記録されます。

システム上のイベントまたは特定のユーザーによって開始されるイベントに対して事前選択できます。

システム全体の事前選択 – auditconfig コマンドの -setflags および -setnaflags オプションを使用して、監査のためのシステム全体のデフォルトを指定します。

注 - perzone ポリシーが設定されている場合は、すべてのゾーンでデフォルトの監査クラスを指定できます。perzone 監査の場合は、システム全体ではなく、ゾーン規模がデフォルトです。
ユーザー固有の事前選択 – 個々のユーザーの監査フラグを構成することにより、そのユーザーについて、システム全体の監査のデフォルトとの違いを指定します。useradd、roleadd、 usermod、および rolemod コマンドは、audit_flags セキュリティー属性を user_attr データベース内に配置します。profiles コマンドは、権利プロファイルの監査フラグを prof_attr データベース内に配置します。

監査事前選択マスクにより、ユーザーに対して監査されるイベントのクラスを決定します。ユーザーの事前選択マスクについては、「プロセスの監査特性」を参照してください。構成されたどの監査フラグが使用されるかについては、「割り当てられたセキュリティー属性の検索順序」を参照してください。

監査クラスは、/etc/security/audit_class ファイルに定義されます。各エントリには、クラスの監査マスク、クラスの名前、およびクラスの記述名が含まれます。たとえば、lo および ps クラス定義は、次のように audit_class ファイルに表示されます。

0x0000000000001000:lo:login or logout
0x0000000000100000:ps:process start/stop

監査クラスには、all と no の 2 つのグローバルクラスが含まれています。監査クラスについては、audit_class(4) のマニュアルページを参照してください。クラスの一覧については、/etc/security/audit_class ファイルを参照してください。

監査イベントのクラスへの割り当ては構成可能です。クラスからイベントを削除したり、クラスにイベントを追加したり、新しいクラスを作成して選択したイベントを含めることができます。手順については、「監査イベントの所属先クラスの変更方法」を参照してください。クラスにマップされているイベントを表示するには、auditrecord -c class コマンドを使用します。

監査レコードと監査トークン

各「監査レコード」には、監査された 1 つのイベントの発生が記録されます。レコードには、動作を行なったユーザー、影響を受けたファイル、試みられた動作、その動作が発生した位置と時刻などの情報が含まれます。次の例は、header、subject、return の 3 つのトークンを含む login 監査レコードを示しています。

header,69,2,login - local,,example_system,2010-10-10 10:10:10.020 -07:00
subject,jdoe,jdoe,staff,jdoe,staff,1210,4076076536,69 2 example_system
return,success,0

監査イベントごとに保存される情報の種類は、一連の監査トークンによって定義されます。イベントの監査レコードが生成されるたびに、そのイベントに対して定義されたトークンの一部またはすべてが、そのレコードに書き込まれます。どのトークンが記録されるかは、イベントの性質によって決まります。前の例では、各行が監査トークンの名前で始まっています。監査トークンの内容は、トークン名のあとに続きます。header、subject、および return 監査トークンがまとまって、login - local 監査レコードを構成します。監査レコードを構成するトークンを表示するには、auditrecord -e event コマンドを使用します。

praudit 出力例の各監査トークンの構造については、「監査トークンの形式」を参照してください。監査トークンのバイナリストリームについては、audit.log(4) のマニュアルページを参照してください。

監査プラグインモジュール

監査プラグインモジュールは、監査レコードを監査キューからファイルまたはリポジトリに送信します。少なくとも 1 つのプラグインがアクティブである必要があります。デフォルトでは、audit_binfile プラグインがアクティブです。プラグインは、auditconfig -setplugin plugin-name コマンドを使用して構成します。

監査サービスでは、次のプラグインが提供されます。

audit_binfile プラグイン – バイナリ監査ファイルへの監査キューの配信を処理します。詳細は、audit.log(4) のマニュアルページを参照してください。
audit_remote プラグイン – 監査キューから構成済みのリモートサーバーへのバイナリ監査レコードのセキュアな配信を処理します。audit_remote プラグインは、libgss() ライブラリを使用してサーバーを認証します。この転送は、プライバシと完全性のために保護されます。
audit_syslog プラグイン – 監査キューから syslog ログへの選択されたレコードの配信を処理します。

プラグインを構成するには、auditconfig(1M) のマニュアルページを参照してください。プラグイン構成の例については、「監査ログの構成 (タスク)」のタスクを参照してください。プラグインについては、audit_binfile(5)、audit_remote(5)、audit_syslog(5) の各マニュアルページを参照してください。

監査ログ

監査レコードは監査ログ内に収集されます。監査サービスでは、監査レコードのための 3 つの出力モードが提供されます。

監査ファイルと呼ばれるログは、バイナリ形式で監査レコードを格納します。システムまたはサイトからの一連の監査ファイルによって、完全な監査レコードが提供されます。完全な監査レコードは監査トレールと呼ばれます。これらのログは audit_binfile プラグインで作成され、praudit および auditreduce 事後選択コマンドで確認できます。
audit_remote プラグインは、監査レコードをリモートリポジトリにストリーム出力します。リポジトリは監査トレールを保持し、事後選択ツールを指定する役割を果たします。
syslog ユーティリティーは、監査レコードの概要テキストを収集して格納します。syslog レコードは、完全なレコードではありません。次の例は、login 監査レコードの syslog エントリを示します。
```
Oct 10  10:10:20 example_system auditd: [ID 6472 audit.notice] \
        login - login ok session 4076172534 by root as root:other
```

サイトでは、すべての書式の監査レコードを収集するように監査を構成できます。サイトにあるシステムを、バイナリモードをローカルに使用したり、バイナリファイルをリモートリポジトリに送信したり、syslog モードを使用したりするように構成できます。次の表では、バイナリ監査レコードを syslog 監査レコードと比較しています。

表 26-1 バイナリ、リモート、および syslog 監査レコードの比較

機能	バイナリレコードとリモートレコード	`syslog` レコード
プロトコル	バイナリ – ファイルシステムに書き込みますリモート – リモートリポジトリにストリーム出力します	リモートログ記録に UDP を使用します
データ型	バイナリ形式	テキスト
レコード長	無制限	監査レコードあたり最大 1024 文字
場所	バイナリ – システム上の zpool 内に格納されますリモート – リモートリポジトリ	`syslog.conf` ファイルで指定された場所に格納されます
構成方法	バイナリ – `audit_binfile` プラグインで `p_dir` 属性を設定しますリモート – `audit_remote` プラグインで `p_hosts` 属性を設定し、そのプラグインをアクティブにします	`audit_syslog` プラグインをアクティブにし、`syslog.conf` ファイルを構成します
読み取り方法	バイナリ – 通常、バッチモードでは XML でのブラウザ出力リモート – リポジトリによって手順が規定されます	リアルタイムに、または `syslog` 用に作成されたスクリプトによって検索されますプレーンテキスト形式の出力
完全性	完全であることと、正しい順序で表示されることが保証されます	完全であることは保証されません
タイムスタンプ	協定世界時 (UTC)	監査されているシステム上の時間

バイナリ形式のレコードにより、強力なセキュリティーとカバレージが提供されます。バイナリ出力は、Common Criteria の監査要件などの、セキュリティー認定の要件を満たします。

audit_binfile プラグインは、レコードをスヌーピングから保護されたファイルシステムに書き込みます。単一のシステム上で、すべてのバイナリレコードが収集され、順番に表示されます。バイナリログ上の UTC タイムスタンプにより、1 つの監査トレール上のシステムがタイムゾーンをまたがって分散している場合の正確な比較が可能になります。praudit -x コマンドを使用すると、レコードを XML 形式でブラウザに表示できます。スクリプトを使用して、XML を解析することもできます。

audit_remote プラグインは、レコードをリモートリポジトリに書き込みます。このリポジトリは、ストレージと事後選択を処理します。

これに対して、syslog レコードでは、利便性と柔軟性が向上する可能性があります。たとえば、さまざまなソースから syslog データを収集できます。また、syslog.conf ファイル内の audit.notice イベントをモニターする場合、syslog ユーティリティーは現在のタイムスタンプで監査レコードのサマリーをログに記録します。ワークステーション、サーバー、ファイアウォール、ルーターなどのさまざまなソースからの syslog メッセージ用に開発された管理および分析ツールと同じツールを使用できます。レコードをリアルタイムで表示し、リモートシステム上に格納することができます。

syslog.conf を使用して監査レコードをリモートに格納すると、攻撃者による改変や削除からログデータが保護されます。その一方で、監査レコードをリモートに格納すると、レコードは、サービス拒否や偽装されたソースアドレスなどのネットワーク攻撃を受けやすくなります。また、UDP はパケットを破棄したり、間違った順番でパケットを配信したりすることがあります。syslog エントリの制限は、1024 文字です。そのため、一部の監査レコードがログで切り捨てられる可能性があります。単一のシステム上で、すべての監査レコードが収集されるわけではありません。レコードが順番に表示されない場合もあります。各監査レコードにはローカルシステムの日付と時間が記録されているため、複数のシステムの監査トレールを構成するときにタイムスタンプに依存することはできません。

プラグインと監査ログについての詳細は、次を参照してください。

監査トレールの格納および管理

audit_binfile プラグインがアクティブな場合は、監査ファイルシステムにバイナリ形式の監査ファイルが保持されます。標準インストールでは /var/audit ファイルシステムが使用されますが、追加のファイルシステムも使用できます。すべての監査ファイルシステムの内容は、監査トレールで構成されています。監査レコードは、これらのファイルシステム内に次の順序で格納されます。

プライマリ監査ファイルシステム – システムの監査ファイルのためのデフォルトのファイルシステムである /var/audit ファイルシステム
セカンダリ監査ファイルシステム – システムの監査ファイルが管理者の判断で配置されるファイルシステム

これらのファイルシステムは、audit_binfile プラグインの p_dir 属性への引数として指定されます。各ファイルシステムは、このリスト内で前にあるファイルシステムがいっぱいになるまで使用されません。ファイルシステムエントリのリストを含む例については、「監査ファイルのための ZFS ファイルシステムを作成する方法」を参照してください。

監査ファイルをデフォルトの監査ルートディレクトリに配置すると、監査証跡を確認する際に役立ちます。auditreduce コマンドは、監査ルートディレクトリを使用して監査トレール内のすべてのファイルを検索します。デフォルトの監査ルートディレクトリは /var/audit です。auditreduce コマンドの -M オプションを使用すると、特定のマシンからの監査ファイルを指定できます。また、-S オプションを使用すると、別の監査ファイルシステムを指定できます。詳細は、auditreduce(1M) のマニュアルページを参照してください。

監査サービスでは、監査トレールのファイルを結合したり、フィルタしたりするためのコマンドが提供されます。auditreduce コマンドは、監査トレールの監査ファイルをマージします。また、ファイルをフィルタして特定のイベントを検出できます。praudit コマンドは、バイナリファイルを読み取ります。praudit コマンドのオプションにより、スクリプトやブラウザの表示に適した出力が得られます。

信頼性の高いタイムスタンプの保証

複数のシステムからの監査ログをマージする場合は、それらのシステム上の日付と時間が正確である必要があります。同様に、監査ログをリモートシステムに送信する場合も、記録システムとリポジトリシステムのクロックが正確である必要があります。Network Time Protocol (NTP) では、システムクロックが正確で、調整された状態に維持されます。詳細は、『Oracle Solaris 11 ネットワークサービスの紹介』の第 3 章「時間関連サービス」および xntpd(1M) のマニュアルページを参照してください。

リモートリポジトリの管理

audit_remote プラグインが構成されたあとは、リモートリポジトリが監査レコードを受信します。監査リモートサーバー (ARS) は、監査レコードの受信者を提供します。監査レコードは、保護された接続を経由して ARS にストリーム出力されるため、ローカルに格納される場合と同様に格納できます。ARS を構成するには、「監査ファイルのためのリモートリポジトリを構成する方法」を参照してください。ARS については、「監査リモートサーバー」および ars(5) のマニュアルページを参照してください。

ナビゲーションリンクをスキップ
印刷ビューの終了
	Oracle Solaris 11.1 の管理: セキュリティーサービス Oracle Solaris 11.1 Information Library (日本語)