パート IV 監査とデバイス管理

第 20 章 BSM (概要)

基本セキュリティモジュール (Basic Security Module、BSM) には、2 つのセキュリティ機能があります。1 つ目の監査メカニズムには、監査データの分析を支援するツールが含まれています。2 つ目のデバイス割り当てメカニズムでは、リムーバブルデバイスまたは割り当て可能デバイスに必要なオブジェクト再利用特性を提供します。

この章では、BSM の概念について説明します。この章の内容は次のとおりです。

• 監査とは

• 監査の機能

• 監査とセキュリティとの関連

• BSM の用語

• デバイス割り当て

監査とは

監査とは、マシンリソースの使用状況に関するデータを収集することです。監査データは、セキュリティに関連するシステムイベントの記録を提供します。このデータは、ホストで発生する動作の責任の割り当てに使用できます。監査を正常に機能させるには、識別と認証という 2 つのセキュリティ機能が重要です。 ログイン時にユーザーがユーザー名とパスワードを与えると、一意の監査 ID がそのユーザーのプロセスに関連付けられます。監査 ID は、ログインセッション中に起動されるすべてのプロセスに継承されます。ユーザーが ID を変更しても、実行するすべての動作は同じ監査 ID によって追跡されます。su(1M) のマニュアルページを参照してください。

監査サブシステムを使うと、次の処理が可能になります。

• ホスト上で発生するセキュリティに関係するイベントの監視

• ネットワーク全体の監査トレールにイベントを記録

• 誤った使用または権限のない動作の検出

• アクセスパターンの確認と、ユーザーおよびオブジェクトのアクセス履歴の調査

• 保護メカニズムを迂回しようとする操作の検出

• スーパーユーザー権限を使用しているユーザーの検出

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

監査データを収集したあと、監査ファイル縮小ツールと変換ツールによって監査トレールの注目すべき部分を調査できます。たとえば、個々のユーザーまたは特定グループの監査レコードを確認できます。特定の日に発生した特定の種類のイベントに対するすべてのレコードを調査できます。または、特定の時間帯に生成されたレコードを選択することもできます。

監査の機能

監査とは、指定したイベントが発生したときに監査レコードを生成することです。通常、次のイベントが発生すると監査レコードが生成されます。

• システムの起動とシャットダウン

• ログインとログアウト

• プロセスまたはスレッドの作成と破棄

• オブジェクトを開く、閉じる、削除する、または名前を変更する

• スーパーユーザー権限または役割権限の使用

• 識別と認証動作

• プロセスまたはユーザーによる任意アクセス制御 (DAC)

• インストール固有の管理動作

次の 3 つが監査レコードの生成元になります。

• アプリケーション

• 非同期イベントの結果

• プロセスのシステムコールの結果

関連するイベント情報が取得されると、その情報は監査レコードの書式に変換されます。監査レコードは、監査キューと呼ばれるカーネルバッファーに格納されます。カーネルの監査キューに一時的に保管された監査レコードは、監査ファイルに書き込まれます。監査ファイルの場所は、audit_control ファイルのエントリによって決定されます。監査ファイルの配置先として、同一マシン上の複数のパーティション、異なる複数のマシン上のパーティション、またはネットワークで接続されている複数のマシン上のパーティションを選択できます。接続された監査ファイルの集合は、監査トレールと呼ばれます。

監査レコードは、発生順に監査ファイルに蓄積されます。各監査レコードには、イベントを識別する情報、イベントの発生元、イベントの時刻、およびその他の関連情報が格納されます。

監査とセキュリティとの関連

コンピュータシステム、特にネットワーク上のシステムのセキュリティを確保するのは簡単ではありません。セキュリティの確保には、システムまたはユーザーのプロセスが開始する前に動作を制御するメカニズムが必要となります。セキュリティの確保には、動作の経過を監視するツールが必要となります。また、セキュリティの確保には、動作終了後に動作内容を報告することも必要です。初期設定の Solaris 監査の場合、ユーザーのログイン前かマシンのプロセスが開始する前に、パラメータが設定されている必要があります。また、ほとんどの監査には、現在のイベントを監視し、指定されたパラメータを満たすイベントを報告する機能が含まれます。Solaris 監査がこれらのイベントを監視および報告する方法については、第 21 章「監査の計画」および第 22 章「BSM サービスの管理 (手順)」を参照してください。

監査では、ハッカーによる不正な侵入を防止することはできません。ただし、監査サブシステムでは、たとえば、特定のユーザーが特定の日時に特定の動作を行なったことが報告されます。監査報告では、入力パスとユーザー名によってこのユーザーを特定できます。これらの情報は、すぐに端末に表示したり、ファイルに出力してあとで分析したりできます。このように、監査サブシステムの提供するデータから、次のことが判断できます。

• どのようにシステムセキュリティが低下したか

• 必要なセキュリティレベルを実現するために対応が必要なセキュリティホールはどれか

BSM の用語

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

監査イベント

セキュリティに関連するシステム動作について監査を行うことができます。これらの監査可能な動作を、「監査イベント」と呼びます。監査イベントは、/etc/security/audit_event ファイルに指定します。監査可能な各イベントは、このファイル内で、シンボル名、イベント番号、一連の選択済みクラス、および簡単な説明によって定義されています。audit_event(4) のマニュアルページを参照してください。

監査イベントには、いくつかのカテゴリがあります。まず、カーネルレベルのイベントとユーザーレベルのイベントに大きく分けられます。カーネルによって生成されたイベントは、カーネルレベルのイベントと呼ばれます。アプリケーションによって生成されたイベントは、ユーザーレベルのイベントと呼ばれます。次の表に示すように、カーネルレベルのイベントには、ユーザーレベルのイベントよりも小さい監査イベント番号が割り当てられています。

カーネルレベルの監査イベント

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

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

アプリケーションソフトウェアによって生成されるイベントは、カーネルの外側にあります。アプリケーションソフトウェアによってユーザーレベルのイベントが生成されます。ユーザーレベルのイベントは、2048 から 65535 までの番号です。イベント名は AUE_ で始まり、そのあとにイベントを表す小文字のニーモニックが続きます。たとえば、rlogin コマンドのイベント番号は 6155 で、イベント名は AUE_rlogin です。表 20–2 にユーザーに関連するイベントの一般的なカテゴリを示します。

ユーザーに起因しない監査イベント

ほとんどのイベントは個々のユーザーの動作が原因で発生しますが、そうでないイベントも存在します。カーネル割り込みレベルでイベントが発生した場合や、ユーザーが識別および認証される前にイベントが発生した場合、それらのイベントは「ユーザーに起因しない」イベントです。ユーザーに起因しないイベントは、監査可能です。次の例は、/etc/security/audit_event ファイル内のユーザーに起因しないイベントを 2 つ示しています。

153:AUE_ENTERPROM:enter prom:na
6156:AUE_mountd_mount:mount:na

AUE_ENTERPROM はカーネルレベルの na イベントです。AUE_mountd_mount はユーザーレベルの na イベントです。

監査クラス

各監査イベントは、1 つまたは複数の「監査クラス」に属するものとして定義します。監査クラスは、多数の監査イベントが入った便利な入れ物です。あるクラスを監査対象として選択した場合、そのクラスに属するすべてのイベントを監査対象として選択したことになります。監査クラスは、/etc/security/audit_class ファイルに定義されます。各エントリには、クラスの名前、監査マスク、および短縮名が含まれます。

0x00000010:fc:file create
0x00000400:na:non-attribute

監査イベントのクラスへの割り当ては構成可能です。これらの構成の変更は audit_event ファイル内で行います。

監査可能な特定のイベントが監査トレール内に記録されるのは、その特定のイベントを含む監査クラスを監査対象として事前に選択した場合です。監査クラスは、32 クラスまで設定できます。クラスには、all および no という 2 つのグローバルクラスが含まれます。 監査クラスについては、表 23–1 を参照してください。audit_class(4) のマニュアルページも参照してください。

監査フラグ

「監査フラグ」は監査クラスの短縮名です。マシン全体で有効な監査関連のデフォルト値は、audit_control ファイル内の監査フラグによって指定します。audit_control ファイルについては、audit_controlファイル を参照してください。

マシン全体の監査デフォルトに対する例外を、個々のユーザーごとに定義できます。audit_user ファイル内で、ユーザーのエントリに監査フラグを設定します。監査フラグは、auditconfig コマンドの引数としても使用します。auditconfig(1M) と audit_user(4) のマニュアルページを参照してください。

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

各「監査レコード」には、監査された 1 つのイベントの発生が記述されます。レコードには、動作を行なったユーザー、影響を受けたファイル、試みられた動作、その動作が発生した位置と時刻などの情報が含まれます。次の行は、praudit コマンドによって処理された監査レコードの一例です。

header,81,2,login - local,,Mon May  6 16:55:48 PDT 2002, + 486 msec
subject,root,root,other,root,other,378,378,0 0 example_machine
text,successful login
return,success,0

監査レコードは監査ファイル内に収集されます。1 つのマシンやサイト内に存在する監査ファイルの集合は「監査トレール」と呼ばれます。監査ファイルの処理方法については、audit.log(4) のマニュアルページを参照してください。監査レコードをユーザーが読める書式に変換するには、praudit コマンドを使用します。praudit の出力例については、praudit コマンドを参照してください。praudit(1M) のマニュアルページも参照してください。

監査イベントごとに保存される情報の種類は、一連の「監査トークン」によって定義されます。 イベントの監査レコードが生成されるたびに、そのイベントに対して定義されたトークンの一部またはすべてが、そのレコードに書き込まれます。どのトークンが記録されるかは、イベントの性質によって決まります。監査レコードの説明を生成するには、bsmrecord コマンドを使用します。次の出力は、creat() システムコール使用時に生成される監査レコードの構造を示しています。header で始まる各行が監査トークンです。

creat
  system call creat                see creat(2)
  event ID    4                    AUE_CREAT
  class       fc                   (0x00000010)
      header
      path
      [attribute]
      subject
      return

詳細は、監査レコードの書式の表示方法を参照してください。各監査トークンの構造については、監査トークンの形式を参照してください。audit.log(4) のマニュアルページにも、監査トークンの情報が記載されています。

監査ディレクトリ

監査ディレクトリには、監査ファイルの集合を保管します。通常のインストールでは、多くの監査ディレクトリが使用されます。監査ディレクトリには、次の 3 つのタイプがあります。

• 「一次監査ディレクトリ」 – 通常の条件下で、システム監査ファイルが配置されるディレクトリ

• 「二次監査ディレクトリ」 – 一次ディレクトリがいっぱいか使用できない場合に、システム監査ファイルが配置されるディレクトリ

• 「最後のディレクトリ」 – 一次監査ディレクトリと二次監査ディレクトリが使用できない場合に使用されるローカル監査ディレクトリ

デバイス割り当て

デバイス割り当てメカニズムを使用すれば、CD-ROM などのデバイスに対するアクセスを制限できます。デバイスクリーンスクリプトは、デバイス使用後にデバイスに残されたデータをすべて削除します。これらの動作により、デバイスのセキュリティが向上します。詳細は、デバイス割り当ての管理 (作業)または デバイス割り当て参照を参照してください。

第 21 章 監査の計画

この章では、インストールした Solaris に対して監査を設定する方法について説明します。特に、監査サービスを有効にする前に、考慮する必要のある問題について説明します。この章の内容は次のとおりです。

• 監査トレールの処理

• 監査担当者と監査対象の決定

• 使用する監査ポリシーの決定

• 監査コストの制御

• 効率的な監査

監査の概要については、第 20 章「BSM (概要)」を参照してください。サイトで監査を構成する手順については、第 22 章「BSM サービスの管理 (手順)」を参照してください。

監査トレールの処理

監査トレールで使用するファイル領域は、監査にとって大きな問題の 1 つです。各ホストには、監査ファイル用に構成されたいくつかの監査ディレクトリが必要です。ホスト上で監査を有効にする前に、最初に監査ディレクトリの構成方法を決定する必要があります。次の表は、監査トレール記憶領域を計画するときに、解決する必要のある問題の一覧です。

監査担当者と監査対象の決定

監査する動作の種類を上手に選択し、有用な監査情報を収集することが望まれます。監査ファイルはすぐに大きくなり、空き領域がなくなる可能性があるため、監査対象を計画する必要があります。

使用する監査ポリシーの決定

監査ポリシーを使用して、ローカルホストの監査レコードの特性を決定します。監査ポリシーは、起動スクリプトによって設定されます。監査サービスを有効にする bsmconv スクリプトによって、/etc/security/audit_startup スクリプトが作成されます。audit_startup スクリプトは、auditconfig コマンドを実行することで監査ポリシーを設定します。詳細は、audit_startup(1M) のマニュアルページを参照してください。

監査ポリシーがデフォルトで無効になっているのは、記憶領域要件とシステム処理要求を最小限に抑えるためです。監査ポリシーを動的に有効または無効にするには、auditconfig コマンドを使用します。監査ポリシーを静的に有効または無効にするには、audit_startup スクリプトを使用します。次の表を参照して、1 つまたは複数の監査ポリシーを有効にしたときに発生する追加のオーバーヘッドを考慮しながら、サイトの要件を決定してください。

監査コストの制御

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

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

• 監査データの分析に伴うコスト

• 監査データの格納に伴うコスト

監査データの処理時間の増大に伴うコスト

処理時間の増大に伴うコストは、監査に関連する 3 つのコストの中ではもっとも重要性の低い問題です。第 1 に、通常は、イメージ処理や複雑な計算処理などの計算集中型のタスクの実行中には、監査処理が発生しないからです。その他の理由として、単一ユーザーシステムのコストが通常は無視できるほど小さいことが挙げられます。

監査データの分析に伴うコスト

分析に伴うコストは、収集される監査データの量にほぼ比例します。分析コストには、監査レコードをマージして検討するための時間が含まれます。コストにはまた、監査レコードをアーカイブし、それを安全な場所に保管するための時間も含まれます。

生成されるレコードの数が少ないほど、監査トレールの分析にかかる時間も短くなります。以下の項、監査データの格納に伴うコストと 効率的な監査では、効率的に監査を行う方法について説明します。収集するデータの量を削減しながら、サイトのセキュリティ目標を達成することは可能です。

監査データの格納に伴うコスト

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

• ユーザー数

• マシン数

• 使用量

• 必要なセキュリティの程度

これらの要因はサイトごとに異なるため、監査データの格納用に前もって確保しておくディスク容量を決定できるような計算式はありません。

all フラグを指定して完全な監査を行うと、ディスクがすぐにいっぱいになります。プログラムのコンパイルといった単純なタスクによってさえ、巨大な監査ファイルが生成される可能性があります。中程度のサイズのプログラムでも、1 分も経たないうちに数千件の監査レコードが生成される可能性があります。たとえば、5 ファイルで合計 5000 行のプログラムの監査トレールが、何 M バイトものディスク容量を占有する可能性があります。事前選択機能を使用して、生成されるレコードの量を減らしておいたほうが賢明です。たとえば、fr クラスを省略すると、監査ボリュームを 3 分の 2 以上も削減できます。また、監査ファイルを効率的に管理することも重要です。監査レコードが生成されたあとにファイル管理を行うことによって、必要なディスク容量を減らせます。

監査を構成する前に、監査フラグを理解しておく必要があります。それらのフラグが監査対象とするイベントの種類を理解しておく必要もあります。適切な基準に基づいて、サイトの監査に関する基本ポリシーを設定します。そのような基準には、サイトで必要なセキュリティの程度や、管理対象ユーザーの種類などが含まれます。

効率的な監査

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

• ある一定の割合のユーザーのみを任意の時間にランダムに監査する

• 監査ファイルのディスク容量要件を削減するために、監査ファイルを結合、縮小、および圧縮する。ファイルを保管する手順、リムーバブルメディアにファイルを転送する手順、およびファイルをオフラインで格納する手順を決定する

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

  たとえば、(1) すべての監査ファイルサーバー上における監査ファイルの作成を監視し、(2) その監査ファイルを tail コマンドを使用して処理するスクリプトを作成する。tail(1) のマニュアルページを参照。tail -0f の出力を praudit コマンドにパイプする。このコマンドは、監査レコードが生成されると監査レコードストリームを生成する。このストリームを分析して、異常なメッセージの種類などを調べ、監査担当者に配布する。また、このスクリプトを使用して、自動応答をトリガーすることもできる。

  さらに、このスクリプトには、(3) 監査ディレクトリを常時監視して、新しい not_terminated 監査ファイルが発生していないかを調べるコードを含める必要もある。また、このスクリプトは、(4) 監査ファイルに書き込めなくなったときに、未処理の tail プロセスを終了させる必要もある

第 22 章 BSM サービスの管理 (手順)

この章では、監査を組み込んだ Solaris 環境を設定および管理する手順について説明します。また、監査トレールおよびデバイス割り当ての管理方法についても説明します。この章では、次の作業マップについて説明します。

• BSM サービスの管理 (作業マップ)

• 監査ファイルの構成 (作業マップ)

• 監査サービスの構成 (作業マップ)

• 監査レコードの管理 (作業マップ)

• 割り当て可能デバイスの追加 (作業マップ)

監査の概要については、第 20 章「BSM (概要)」を参照してください。計画時のヒントについては、第 21 章「監査の計画」を参照してください。

BSM サービスの管理 (作業マップ)

次の作業マップは、BSM サービスの管理に必要な主な作業の一覧です。

監査ファイルの構成 (作業マップ)

ネットワーク上で監査プロセスを有効にする前に、監査構成ファイルを編集します。このあとに説明する手順の多くは、サービスの再開またはローカルシステムのリブートが必要です。監査構成ファイルの編集は、できるだけ BSM サービスを開始する前に完了してください。

次の表は、この節で説明する操作の一覧です。

監査フラグの選択方法

監査フラグは、/etc/security/audit_control ファイルに定義されます。監査フラグを使用して、監査ログに記録する監査レコードのクラスを選択します。

1. スーパーユーザーになるか、同等の役割を引き受けます。

2. (省略可能) audit_control ファイルのバックアップコピーを保存します。

   # cp /etc/security/audit_control /etc/security/audit_control.save

3. audit_control ファイルに新しいエントリを追加します。

   各エントリの書式は次のとおりです。

   title:string

   title

   行の種類を定義する。dir:、flags:、minfree:、または naflags: を選択できる

   string

   この種類の行に関連付けるデータを指定する

4. 監査デーモンを実行して、新しい audit_control ファイルを読み込みます。

   監査デーモンの内部に、読み込んだ情報が格納されます。新しい情報を使用するには、システムをリブートするか、次のコマンドを入力します。

   # audit -s

例 — 監査トレールファイルの位置を変更する

dir: で始まる行には、監査トレールファイルの格納に使用する監査ファイルシステムを定義します。この例では、監査トレールファイルの位置を 2 つ追加定義しています。

# cat /etc/security/audit_control
dir:/etc/security/audit/host.1/files
dir:/etc/security/audit/host.2/files
dir:/var/audit
flags:
minfree:10
naflags:lo

例 — すべてのユーザーに適用される監査フラグを変更する

audit_control ファイルの flags 行には、監査するイベントのクラスを定義します。このフラグは、ホスト上のすべてのユーザーに適用されます。クラスは空白を入れずにコンマで区切ります。この例では、すべてのユーザーを対象に lo クラスのイベントが監査されます。

# cat /etc/security/audit_control
dir:/var/audit
flags:lo
minfree:10
naflags:lo

例 — 警告に対するソフト制限値を変更する

audit_control ファイルの minfree 行には、すべての監査ファイルシステムの最小空き領域レベルを定義します。この例では、利用できるファイルシステムの領域が 10 % だけになったときに警告が発行されるように、ソフト制限値を設定しています。

# cat /etc/security/audit_control
dir:/var/audit
flags:
minfree:10
naflags:lo

例 — ユーザーに起因しないイベントの監査を変更する

audit_control ファイルの naflags: 行には、ホスト上のすべてのユーザーを対象に監査する、ユーザーに起因しないイベントのクラスを定義します。クラスは空白を入れずにコンマで区切ります。この例では、na イベントクラスが追加されます。

# cat /etc/security/audit_control
dir:/var/audit
flags:
minfree:10
naflags:lo,na

ユーザーの監査特性の変更方法

ユーザーごとの定義は、/etc/security/audit_user ファイルに格納されます。これらの定義は、audit_control ファイル内のフラグに対する例外です。

1. スーパーユーザーになるか、同等の役割を引き受けます。

2. (省略可能) audit_user ファイルのバックアップコピーを保存します。

   # cp /etc/security/audit_user /etc/security/audit_user.save

3. audit_user ファイルに新しいエントリを追加します。

   各エントリの書式は次のとおりです。

   username:always:never

   username

   監査するユーザー名を選択する

   always

   常に監査する監査クラスの一覧を選択する

   never

   監査しない監査クラスの一覧を選択する

   複数のフラグを指定するには、監査クラスをコンマで区切ります。監査ファイルの詳細は、監査クラスと監査フラグを参照してください。

4. 監査デーモンで新しいデータが使用できるようにします。

   新しいデータを使用するには、システムをリブートします。該当のユーザーをいったんログアウトさせてからログインし直させることもできます。

例 — 1 人のユーザーの監査を変更する

この例のエントリでは、ユーザー sue がログインクラス (lo) の任意のプログラムにアクセスすると、監査レコードが生成されます。

# grep sue /etc/security/audit_user
sue:lo:

例 — 監査管理ログインを作成する

ログインを監査対象としている場合にすべての監査パーティションがいっぱいになると、ユーザーがホストにログインできなくなる可能性があります。この状況を回避するために、監査を行わない特別なアカウントを設定できます。特別なアカウントは、監査パーティションがいっぱいになった場合でもホストにログインできるため、このようなパーティションの問題を解決することができます。この例では、アカウント auditadm を監査しないように定義します。

# grep auditadm /etc/security/audit_user
auditadmin:no:yes

監査管理アカウントの使用を許されたユーザーについては、別の方法で監視する必要があります。

監査クラスの追加方法

監査クラスは、/etc/security/audit_class ファイルに定義されます。

1. スーパーユーザーになるか、同等の役割を引き受けます。

2. (省略可能) audit_class ファイルのバックアップコピーを保存します。

   # cp /etc/security/audit_class /etc/security/audit_class.save

3. audit_class ファイルに新しいエントリを追加します。

   各エントリの書式は次のとおりです。

   0xnumber:name:description

   0x

   number が 16 進であることを示す

   number

   一意の監査クラスマスクを定義する

   name

   監査クラスの 2 文字の名前を定義する

   description

   監査クラスの記述名を定義する

4. BSM サービスで新しいデータが使用できるようにします。

   新しいデータを使用するには、システムをリブートするか、次のコマンドを入力します。

   # auditconfig -conf

例 — 新しい監査クラスを設定する

この例では、次のようなエントリを audit_class ファイルに追加します。このエントリによって、ta という名前の新しい監査クラスが作成されます。

0x01000000:ta:test application

監査イベントの所属先クラスの変更方法

イベントからクラスへの割り当ては、/etc/security/audit_event ファイル内に定義されています。

1. スーパーユーザーになるか、同等の役割を引き受けます。

2. (省略可能) audit_event ファイルのバックアップコピーを保存します。

   # cp /etc/security/audit_event /etc/security/audit_event.orig

3. 特定のイベントの flag を変更して、そのイベントが属するクラスを変更します。

   各エントリの書式は次のとおりです。

   number:event:program:flag

   number

   監査イベント ID を定義する

   event

   監査イベントの名前を定義する

   program

   監査レコードの作成を開始するシステムコールまたはユーザーレベルのプログラム実行可能ファイルを定義する

   flag

   監査クラスの 2 文字の名前を定義する

4. BSM サービスで新しいデータが使用できるようにします。

   新しいデータを使用するには、システムをリブートするか、次のコマンドを入力します。

   # auditconfig -conf # audit -s

例 — サイト固有の監査イベントの割り当てを作成する

この例では、新しいクラスを定義して、そのクラスにイベントを追加します。割り当てを使用するには、新しいクラスを audit_control ファイル内に記述してから、システムをリブートします。

1. audit_class ファイルで、監視したい監査イベントのみを収集するため、サイト固有のクラスを定義します。

   0x00000800:sc:site class

2. audit_event ファイルで、一連の監査イベントの所属先を新しいクラスに変更します。

   26:AUE_SETGROUPS:setgroups(2):sc 27:AUE_SETPGRP:setpgrp(2):sc 40:AUE_SETREUID:setreuid(2):sc 41:AUE_SETREGID:setregid(2):sc 214:AUE_SETEGID:setegid(2):sc 215:AUE_SETEUID:seteuid(2):sc

3. audit_controlファイルで新しいフラグを使用します。次のエントリは、ログインを監査するとともに、sc クラスに属するイベントのすべての正常な起動を監査します。

   flags:lo,+sc

4. 新しい構成によってすべてのプロセスが確実に監査されるようにするには、システムをリブートします。または、次の一連のコマンドを使えば、そのマシンを使用する各ユーザーが正しく監査されるようになります。auid はユーザー ID です。

   # auditconfig -conf # audit -s # setumask auid lo,+sc

監査イベントの追加方法

監査イベントの定義は、/etc/security/audit_event ファイルに格納されます。

1. スーパーユーザーになるか、同等の役割を引き受けます。

2. (省略可能) audit_event ファイルのバックアップコピーを保存します。

   # cp /etc/security/audit_event /etc/security/audit_event.save

3. audit_event ファイルに新しいエントリを追加します。

   各エントリの書式は次のとおりです。

   number:name:description:classes

   number

   一意の監査イベント番号を定義する。32767 以降の番号を指定する

   name

   一意の監査イベント名を定義する

   description

   監査イベントの説明を記述する。監査イベントのマニュアルページ名が含まれることが多い

   classes

   このイベントを含む監査クラスを選択する

4. 監査デーモンで新しいデータが使用できるようにします。

   新しいデータを使用するには、システムをリブートするか、次のコマンドを入力します。

   # auditconfig -conf

例 — 新しい監査イベントを追加する

この例のエントリは、ローカルアプリケーションの新しい監査イベントを定義しています。

# grep localapp /etc/security/audit_event
32768:AUE_localapp:localapp(1):ta

監査サービスの構成 (作業マップ)

この節では、監査サービスを構成して有効にするために必要な作業について説明します。次の作業マップは、監査サービスの構成に必要な作業の一覧です。

監査パーティションの作成方法

次の手順では、監査ファイル用のパーティションの作成方法、および監査に対応するファイルシステムとディレクトリの作成方法について説明します。すでに空のパーティションがある場合、またはすでに空のファイルシステムをマウントしている場合は、必要に応じて手順を省略してください。

1. スーパーユーザーになるか、同等の役割を引き受けます。

2. 必要なディスク容量を決定します。

   ホストごとに 200M バイト以上を割り当てます。ただし、ディスク容量の要件は、実行する監査のボリュームによって異なります。つまり、ディスク容量の要件が割り当てる数値を超えることがあります。予備ディレクトリのパーティション領域も含めてください。

3. 必要に応じて、監査パーティションを作成します。

   この手順は、サーバーのインストール時に実行するのが最も簡単です。サーバーにマウントされていないディスク上にパーティションを作成することもできます。パーティション作成方法の詳細については、『Solaris のシステム管理 (基本編)』の「UFS ファイルシステムの作成」を参照してください。

   # newfs /dev/rdsk/cwtxdysz

   /dev/rdsk/cwtxdysz は、パーティションの raw デバイス名です。

   ローカルホストを監査する場合は、予備の監査ディレクトリも作成します。

4. 新しいパーティションのマウント先を作成します。

   # mkdir /var/audit/server-name.n

   server-name.n は、サーバー名と各パーティションの識別番号を結合したものです。この識別番号は省略できますが、多数の監査ディレクトリを作成する場合はこの番号を使用すると便利です。

5. 新しいパーティションを自動的にマウントするエントリを追加します。

   /etc/vfstab ファイルに次のような行を追加します。

   /dev/dsk/cwtxdysz /dev/rdsk/cwtxdysz /var/audit/server-name.n ufs 2 yes

6. (省略可能) 各パーティションの最小空き容量のしきい値を削除します。

   デフォルトの構成を使用した場合、ディレクトリの 80% がいっぱいになった時点で警告が生成されます。このため、パーティション上に空き容量を予約する必要はありません。

   # tunefs -m 0 /var/audit/server-name.n

7. 新しい監査パーティションをマウントします。

   # mount /var/audit/server-name.n

8. 新しいパーティションに監査ディレクトリを作成します。

   # mkdir /var/audit/server-name.n/files

9. マウント先と新しいディレクトリへのアクセス権を訂正します。

   # chmod -R 750 /var/audit/server-name.n/files

10. (省略可能) ファイルサーバー上で、ほかのホストからアクセスできるファイルシステムを定義します。

    通常は、監査レコードを格納するために、ディスクファームをインストールします。監査ディレクトリを複数のシステムで使用する場合は、そのディレクトリを NFS サービスを通して共有する必要があります。/etc/dfs/dfstab ファイルに対して、次のようなエントリをディレクトリごとに追加します。

    share -F nfs /var/audit/server-name.n/files

11. (省略可能) ファイルサーバー上で、NFS サービスを起動し直します。

    share コマンドまたは share コマンドセットをはじめて実行する場合、NFS デーモンが動作していないことがあります。次のコマンドでデーモンを終了し、再起動してください。NFS サービスの詳細については、『Solaris のシステム管理 (資源管理とネットワークサービス)』の「NFS サービスの設定」 を参照してください。

    # /etc/init.d/nfs.server stop # /etc/init.d/nfs.server start

例 — 予備の監査ディレクトリを作成する

監査サブシステムを実行するすべてのシステムには、利用できるファイルシステムがほかにない場合に使用するローカルファイルシステムが必要です。この例では、ファイルシステムが egret という名前のシステムに追加されます。このファイルシステムは、ローカルシステムだけで使用されるため、続いてファイルサーバーの手順は必要ありません。

# newfs /dev/rdsk/c0t2d0
# mkdir /var/audit/egret
# grep egret /etc/vfstab
/dev/dsk/c0t2d0s1  /dev/rdsk/c0t2d0s1  /var/audit/egret ufs  2  yes  -
# tunefs -m 0 /var/audit/egret
# mount /var/audit/egret
# mkdir /var/audit/egret/files
# chmod -R 750 /var/audit/egret/files

例 — 新しい監査パーティションを作成する

この例では、新しいファイルシステムが、2 つの新しいディスクに作成されます。この 2 つのディスクは、ネットワーク上のほかのシステムと共有します。

# newfs /dev/rdsk/c0t2d0
# newfs /dev/rdsk/c0t2d1
# mkdir /var/audit/egret.1
# mkdir /var/audit/egret.2
# grep egret /etc/vfstab
/dev/dsk/c0t2d0s1  /dev/rdsk/c0t2d0s1  /var/audit/egret.1 ufs  2  yes  -
/dev/dsk/c0t2d1s1  /dev/rdsk/c0t2d1s1  /var/audit/egret.2 ufs  2  yes  -
# tunefs -m 0 /var/audit/egret.1
# tunefs -m 0 /var/audit/egret.2
# mount /var/audit/egret.1
# mount /var/audit/egret.2
# mkdir /var/audit/egret.1/files
# mkdir /var/audit/egret.2/files
# chmod -R 750 /var/audit/egret.1/files /var/audit/egret.2/files
# grep egret /etc/dfs/dfstab
 share -F nfs /var/audit/egret.1/files
 share -F nfs /var/audit/egret.2/files
# /etc/init.d/nfs.server stop
# /etc/init.d/nfs.server start

audit_warn 別名の構成方法

audit_warn スクリプトは、audit_warn という別名に対してメールを生成します。このメールを有効な電子メールアドレスに送信するには、次のいずれかのオプションを行います。

1. スーパーユーザーになるか、同等の役割を引き受けます。

2. audit_warn メール別名を構成します。

   「オプション 1」 –

   audit_warn スクリプトで、audit_warn 別名をほかのメールアカウントに置き換えます。

   audit_warn を root アカウントに置き換えると、電子メールメッセージを送信する行は次のようになります。

   /usr/ucb/mail -s "$SUBJECT" root

   audit_warn スクリプト内の 10 行にこの変更を適用する必要があります。

   「オプション 2」 –

   audit_warn の電子メールをほかのメールアカウントにリダイレクトします。

   この場合、audit_warn 別名を適切なメール別名ファイルに追加します。別名の追加先として、ローカルの /etc/mail/aliases ファイル、名前空間の mail_aliases データベースのいずれかを選択します。root メールアカウントを audit_warn 別名のメンバーとして登録する場合、新しいエントリは次のようになります。

   audit_warn: root

監査ポリシーを有効または無効にする方法

監査ポリシーを使用して、ローカルホストの監査レコードの特性を決定します。デフォルトでは、すべての監査ポリシーが無効になっています。使用する監査ポリシーは、有効にする必要があります。各ポリシーについては、監査ポリシーを参照してください。

プログラムレベルで auditon() システムコールを行なって、現在の監査ポリシーを調査したり、有効または無効にしたりすることができます。また、auditconfig コマンドを実行して同じタスクを行うこともできます。また、監査ポリシーの変更内容を固定するために、audit_startup スクリプト内で auditconfig コマンドの監査ポリシーオプションを変更することも可能です。

1. スーパーユーザーになるか、同等の役割を引き受けます。

2. (省略可能) 既存の監査ポリシーを確認します。

   監査ポリシーを変更するときは、現在使用されているポリシーをすべて確認してください。次のコマンドを実行すると、有効なポリシーがすべて表示されます。

   # auditconfig -lspolicy

3. 監査ポリシーを有効または無効にします。

   # auditconfig -setpolicy flagpolicyname

   flag

   flag に + を指定すると、ポリシーが有効になる。flag に - を指定すると、ポリシーが無効になる

   policyname

   有効または無効にするポリシーを選択する

   このポリシーの設定は、次回ブートするまで、または auditconfig -setpolicy コマンドを使ってポリシーを変更するまで持続します。

例 — cnt ポリシーを設定する

cnt ポリシーを設定すると、監査パーティションがいっぱいになっても、プロセスはブロックされません。パーティションがいっぱいになるとレコードは破棄されますが、システムは機能し続けます。cnt ポリシーを有効にすると、破棄された監査レコードのカウント数が記録されます。セキュリティを重視する場合は、cnt ポリシーは設定しないでください。ファイルシステムがいっぱいになると、イベントが記録されないことがあるためです。

次のコマンドを実行すると、cnt ポリシーが有効になります。

# auditconfig -setpolicy +cnt

リブートしてもポリシーの設定を維持させるには、auditconfig -setpolicy +cnt コマンドを audit_startup ファイルに追加する必要があります。

監査を有効にする方法

この操作では、監査サービスが開始されます。監査サービスが構成されている場合は、ホストをリブートしたときにもサービスが開始します。

1. スーパーユーザーになるか、同等の役割を引き受けます。

2. システムをシングルユーザーモードにします。

   # /etc/telinit 1

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

3. スクリプトを実行して、システムが監査を実行するように構成します。

   /etc/security ディレクトリに移動し、bsmconv スクリプトを実行します。このスクリプトは、リブート後に標準 Solaris マシンが監査を実行するよう設定します。bsmconv(1M) のマニュアルページを参照してください。

   # cd /etc/security # ./bsmconv

4. システムをマルチユーザーモードにします。

   # /etc/telinit 6

   システムがマルチユーザーモードに移行すると、起動ファイル /etc/security/audit_startup によって監査デーモンが自動的に動作します。

監査を無効にする方法

監査が不要になった時点で、bsmunconv コマンドを実行して、監査サブシステムを無効にすることができます。bsmconv(1M) のマニュアルページを参照してください。

1. スーパーユーザーになるか、同等の役割を引き受けます。

2. システムをシングルユーザーモードにします。

   # /etc/telinit 1

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

3. スクリプトを実行して、監査を無効にします。

   /etc/security ディレクトリに移動し、bsmunconv スクリプトを実行します。

   # cd /etc/security # ./bsmunconv

4. システムをマルチユーザーモードにします。

   # /etc/telinit 6

監査レコードの管理 (作業マップ)

監査トレールを管理することによって、ネットワーク上のユーザーの動作を監視することができます。監査プロセスを行うと、大量のデータが生成される可能性があります。次の手順では、さまざまな監査データを使用して作業を行う方法について説明します。

次の表は、この節で説明する操作の一覧です。

監査レコードの書式の表示方法

bsmrecord コマンドは、監査イベントの監査 ID、監査クラス、選択マスク、およびレコード書式を表示します。このコマンドは、audit_class ファイル内と audit_event ファイル内のレコードを使用します。

次のように -a オプションを指定してコマンドを実行すると、すべての監査イベントのレコード書式が表示されます。-h オプションを指定すると、HTML 形式で一覧が出力されます。出力されたファイルは、ブラウザを使って表示できます。

bsmrecord コマンドを使ってすべての監査イベントのレコード書式を HTML ファイルに出力します。

% bsmrecord -a -h> audit.events.html

*html ファイルはブラウザを使って表示できます。ブラウザの検索ツールを使って特定のレコードを検索します。

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

例 — プログラムの監査レコード書式を表示する

この例では、login プログラムによって生成されたすべての監査レコードの書式を表示します。

% bsmrecord -p login

terminal login
  program     /usr/sbin/login      see login(1)
  event ID    6152                 AUE_login
  class       lo                   (0x00001000)
      header
      subject
      text                         error message or "successful login"
      return

login: logout
  program     /usr/sbin/login      see login(1)
  event ID    6153                 AUE_logout
  class       lo                   (0x00001000)
      header
      subject
      text                         "logout" username
      return

rlogin
  program     /usr/sbin/login      see login(1) - rlogin
  event ID    6155                 AUE_rlogin
  class       lo                   (0x00001000)
      header
      subject
      text                         success/fail message
      return

telnet login
  program     /usr/sbin/login      see login(1) - telnet
  event ID    6154                 AUE_telnet
  class       lo                   (0x00001000)
      header
      subject
      text                         success/fail message
      return

例 — 監査クラスの監査レコード書式を表示する

この例では、fd クラスに属するすべての監査レコードの書式を表示します。

% bsmrecord -c fd

ftruncate
    Not used.

truncate
    Not used.

unlink
  system call unlink               see unlink(2)
  event ID    6                    AUE_UNLINK
  class       fd                   (0x00000020)
      header
      path
      [attribute]
      subject
      return

監査レコードのマージ方法

次のタスクでは、すべての監査ディレクトリのすべての監査ファイルをマージする方法について説明します。監査トレールの内容を分析する場合は、次の手順を行います。

1. スーパーユーザーになるか、同等の役割を引き受けます。

2. 一次監査ディレクトリに移動します。

   # cd /etc/security/audit/server-name.1/files

   マージされたファイルは、/etc/security/audit/server-name.1/files ディレクトリ内に格納されます。このディレクトリは保護されています。

3. 監査レコードをマージします。

   # auditreduce> merged.log

   server-name 上の audit_control ファイル内の dir: 行に指定されているすべてのディレクトリがマージされます。マージされたレコードは、カレントディレクトリの merged.log ファイル内に格納されます。

例 — 監査トレール全体を表示する

監査トレール全体を一度に表示するには、auditreduce コマンドの出力を praudit コマンドにパイプします。

# auditreduce | praudit

例 — 監査トレール全体を印刷する

出力を lp コマンドにパイプすると、その出力はプリンタに送られます。

# auditreduce | praudit | lp

例 — 監査ファイルの結合と削減

auditreduce の -O オプションを使用して、複数の監査ファイルを 1 つのファイルに結合し、そのファイルを指定した出力ファイルに保存します。auditreduce を使用すると、このような結合と削除を自動的に実行できます。auditreduce(1M) のマニュアルページの -C オプションと -D オプションを参照してください。ただし、ファイルを手動で選択したほうが効率的です。find コマンドを使用したあと、auditreduce を使用して指定した一連のファイルだけを結合します。

この方法で auditreduce コマンドを使用すると、入力ファイルのすべてのレコードが 1 つの出力ファイルにマージされます。マージが完了したら、入力ファイルは削除する必要があります。また、出力ファイルは、/etc/security/audit/server-name /files という名前のディレクトリに保存し、auditreduce が出力ファイルを検索できるようにする必要があります。

# auditreduce -O combined-filename

auditreduce コマンドを使用すると、出力ファイル内のレコード数を減らすこともできます。このコマンドは、入力ファイルの結合時に不要なレコードを除外できます。たとえば、auditreduce コマンドを使用して、1 か月以上経過した監査ファイルから、ログインレコードとログアウトレコード以外のレコードを削除することができます。監査トレール全体が必要になった場合は、バックアップテープから監査トレールを復元できます。

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

例 — 選択した日付のユーザーの動作を表示する

次の例では、1999 年 4 月 13 日におけるユーザー tamiko のログイン時刻とログアウト時刻を、システム管理者が確認します。管理者は、lo イベントクラスを要求します。短い書式の日付は、yymmdd 形式で出力されます。長い書式については、auditreduce(1M) のマニュアルページを参照してください。

# auditreduce -d 990413 -u tamiko -c lo | praudit

例 — 選択レコードを 1 つのファイルにコピーする

この例では、特定の日付におけるログイン、ログアウトのメッセージが監査トレールから選択されます。これらのメッセージは対象ファイルにマージされます。対象ファイルは、通常の監査ルートディレクトリ以外のディレクトリに書き込まれます。

# auditreduce -c lo -d 990413 -O /usr/audit_summary/logins 

-O オプションを使用すると、開始時刻と終了時刻を示す 14 文字のタイムスタンプと接尾辞 logins が付いた監査ファイルが作成されます。

/usr/audit_summary/19990413000000.19990413235959.logins

例 — not_terminated 監査ファイルを整理する

監査ファイルが開いている状態で監査デーモンが終了してしまうことがあります。また、サーバーがアクセス不能になって、強制的に別のサーバーに切り替わってしまうことがあります。このような場合、その監査ファイルは監査レコードとして使用されなくなりますが、監査ファイルの終了時刻として文字列 not_terminated が付いたままになります。このようなファイルが見つかった場合、ファイルが使用されていないことを手動で確認します。開いたままのファイルを整理するには、正しいオプションを使用してファイル名を指定します。

# audit -s
19990414121112.not_terminated.egret
# auditreduce -O egret 19990413120429.not_terminated.egret

audit コマンドは、現在の監査ファイル名を確認します。auditreduce コマンドは、正しいファイル名と正しいタイムスタンプを持つ新しい監査ファイルを作成します。正しいファイル名には、正しい接尾辞 (egret) が含まれます。auditreduce は、すべてのレコードをこのファイルにコピーします。

監査レコードの表示方法

1. スーパーユーザーになるか、同等の役割を引き受けます。

2. /usr/audit_summary/logins などの監査ファイルディレクトリに移動します。

   # cd /usr/audit_summary/logins

3. praudit コマンドを使ってファイルを読み取ります。

   # praudit 19990413000000.19990413235959.logins | more

例 — 監査レコードを XML 形式に変換する

この例では、監査レコードを XML 形式に変換します。XML 形式はブラウザで表示できます。この形式は、報告を作成する際にも使用できます。

# praudit -x 19990413000000.19990413235959.logins> 19990413.logins.xml

*xml ファイルはブラウザを使って表示できます。スクリプトを使えば、XML ファイルの内容を操作して目的の情報を抽出できます。

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

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

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

2. 監査ファイルを手動でテープにバックアップします。これらのファイルを保存ファイルシステムに移動することもできます。

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

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

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

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

   監査トレールからサマリーファイルを抽出するには、auditreduce コマンドのオプションを使用します。サマリーファイルには、指定された種類の監査イベントのレコードだけが含まれます。例 — 監査ファイルの結合と削減と 例 — 選択レコードを 1 つのファイルにコピーするの例を参照してください。

デバイス割り当ての管理 (作業)

デバイス割り当てを使用して、さまざまなリムーバブルメディアに関連するセキュリティリスクを減らすことができます。

割り当て可能デバイスの追加 (作業マップ)

次の表は、新しい割り当て可能デバイスの定義に必要な、主な手順の一覧です。

割り当て可能デバイスのロックファイルの設定方法

ロックファイルとは、 /etc/security/dev ディレクトリに作成されるサイズ 0 のファイルです。割り当て可能デバイスごとに 1 つのファイルが作成されます。割り当て可能デバイスのロックファイルがない場合は、そのデバイスを割り当てることができず、誰もアクセスできません。

1. スーパーユーザーになるか、同等の役割を引き受けます。

2. dminfo コマンドを使用して、 device_maps ファイルのエントリからそのデバイスのデバイス名を取得します。

   device_maps ファイル と、dminfo(1M) および device_maps(4) のマニュアルページを参照してください。たとえば、デバイスタイプ st のデバイス名は st0 です。次の手順では、そのデバイス名をロックファイル名として使用します。

3. touch コマンドを使用して、そのデバイスの空のロックファイルを作成します。

   ファイル名としてデバイス名を使用します。device-name に代入してください。

   # cd /etc/security/dev # touch device-name # chmod 600 device-name # chown bin device-name # chgrp bin device-name

割り当て可能デバイスの変更方法

次の手順では、デバイス割り当てメカニズムに使用できるデバイスを定義します。

1. スーパーユーザーになるか、同等の役割を引き受けます。

2. /etc/security/device_allocate ファイルに一覧されているデバイスを確認します。

3. device_allocate ファイルには指定されていないデバイスのうち、割り当て可能にするデバイスを決定します。

4. device_allocate ファイルを編集して新しいデバイスを追加します。

   各エントリの書式は次のとおりです。

   device-name;device-type;;;;program

   device-name

   デバイス名を指定する

   device-type

   デバイスタイプを指定する

   program

   実行するパージプログラムを指定する

デバイスを割り当てる方法

1. スーパーユーザーになるか、同等の役割を引き受けます。

2. デバイス名を指定して allocate コマンドを使用します。

   sar1% allocate st0

allocate コマンドの - g オプションを使用して、デバイスタイプでデバイスを割り当てることもできます。

コマンドでデバイスを割り当てられない場合は、コンソールウィンドウにエラーメッセージが表示されます。割り当てのエラーメッセージについては、allocate(1) のマニュアルページを参照してください。

例 — プリンタを割り当てる

allocate コマンドを実行したユーザーだけがプリンタを使用できます。

sarl% allocate /dev/lp/chestnut

デバイスの割り当てを解除する方法

割り当てを解除すると、ほかのユーザーもユーザーの使用後にそのデバイスを割り当てて使用できるようになります。

1. deallocate コマンドに続けてデバイスファイル名を使用し、デバイスの割り当てを解除します。

   sar1% deallocate st0

例 — プリンタの割り当てを解除する

chestnut という名前のプリンタの割り当てを解除するには、次のコマンドを入力します。

# deallocate /dev/lp/chestnut

例 — 強制的に割り当てを解除する

ユーザーに割り当てられたデバイスは、プロセスが終了するとき、またはそのユーザーがログアウトするときに、自動的にその割り当てが解除されません。次の書式の deallocate コマンドは、通常、ユーザーが特定のデバイスの割り当てを解除し忘れたときのために使用します。次のコマンドは、デバイス割り当てを解除して、ほかのユーザーがデバイス割り当てを行えるようにします。

# deallocate -F st0

例 — すべてのデバイスの割り当てを解除する

すべてのデバイスの割り当てを解除できるのは、システムを初期化しているときだけです。

# deallocate -I

第 23 章 BSM サービス (参照)

この章では、BSM サービスの重要なコンポーネントである、監査サブシステムとデバイス割り当てメカニズムについて説明します。

監査メカニズムを使用して、システムが通常と異なる方法で使用されていないかどうか検査すると、潜在的なセキュリティ違反を検出できます。また、通常と異なる動作を追跡して、特定のユーザーを突き止めることができるため、セキュリティ違反を抑えることができます。つまり、ユーザーは自分の動作が監査されそうだと考えると、違反行為を思いとどまる可能性が大きくなります。

この章の内容は次のとおりです。

• 監査コマンド

• 監査サービスファイル

• 監査管理プロファイル

• 監査クラスと監査フラグ

• 監査ポリシー

• プロセスの監査特性

• 監査トレール

• 監査ファイルの命名規則

• 監査レコードの構造

• 監査トークンの形式

• デバイス割り当て参照

監査の概要については、第 20 章「BSM (概要)」を参照してください。計画時のヒントについては、第 21 章「監査の計画」を参照してください。サイトで監査を構成する手順については、第 22 章「BSM サービスの管理 (手順)」を参照してください。

監査コマンド

この節では、監査サービスで使用されるコマンドについて説明します。

監査デーモン

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

• auditd は、 audit_control ファイル内で指定されたディレクトリ内の監査ログファイルを、指定された順序で開き、閉じます。

• auditd は、監査データをカーネルから読み取り、監査ログファイルに書き込みます。

• auditd は、監査ディレクトリ内のデータ量が audit_controlファイル内で指定された上限を超えると、 audit_warn スクリプトを実行します。デフォルトでは、このスクリプトは audit_warn メールの別名とコンソールに警告を送信します。

• デフォルトでは、監査ディレクトリがすべていっぱいになると、監査レコードを生成するプロセスは中断されます。また、auditd コマンドは、コンソールと audit_warn メールの別名にメッセージを送ります。この監査ポリシーは、auditconfig コマンドを使用して構成し直すことができます。この時点では、システム管理者だけが、監査メカニズムの修復を行えます。管理者は、ログインして監査ファイルをテープに書き込んだり、監査ファイルをシステムから削除したり、その他のクリーンアップを実行したりできます。

auditd デーモンは、マシンがマルチユーザーモードになると自動的に起動されますが、コマンド行から起動することもできます。監査デーモンが起動すると、デーモンは監査ログファイルに必要な空き容量を判断します。

監査デーモンは、audit_control ファイル内に指定されている監査ディレクトリに、監査ファイルを作成します。監査デーモンは、このディレクトリの一覧へのポインタを、最初のディレクトリに位置付けます。監査デーモンは、監査ファイルを作成する必要があるたびに、一覧内の最初の使用可能ディレクトリ内に監査ファイルを格納します。一覧は、監査デーモンの現在のポインタ位置から始まります。このポインタを一覧の最初のディレクトリに設定し直すには、audit -s コマンドを実行します。audit -n コマンドは、新しい監査ファイルに切り替えるように監査デーモンに指示します。新しいファイルは、現在のファイルと同じディレクトリ内に作成されます。

audit コマンド

audit コマンドは、監査デーモンの動作を制御します。audit コマンドは、次の操作を実行できます。

• 監査機能を使用可能および使用不可にする

• 監査デーモンを設定し直す

• ローカルマシンの監査事前選択マスクを調整する

• 監査レコードを別の監査ログファイルに書き込む

利用できるオプションについては、audit(1M) のマニュアルページを参照してください。

bsmrecord コマンド

bsmrecord コマンドは、/etc/security/audit_event ファイル内に定義されている監査イベントの書式を表示します。監査イベントの監査 ID、監査クラス、監査フラグ、およびレコードのトークンが順に出力されます。オプションを指定しなかった場合、 bsmrecord は端末での表示に適した形で出力します。-h オプションを指定した場合、ブラウザでの表示に適した形式で出力します。使用例については、監査レコードの書式の表示方法を参照してください。詳細は、bsmrecord(1M) のマニュアルページを参照してください。

auditreduce コマンド

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

auditreduce コマンドを使用すると、複数のマシン上のすべての監査対象動作を、1 か所から追跡できます。このコマンドは、すべての監査ファイルを論理的に結合し、単一の監査トレールとして読み取ることができます。サイト内のすべてのマシンが同一の監査構成を持つようにするとともに、サーバーと監査ログファイル用のローカルディレクトリを作成しておく必要があります。auditreduce では、レコードの生成方法や格納場所は無視されます。オプションを指定しなかった場合、auditreduce コマンドは、監査ルートディレクトリのすべてのサブディレクトリ内のすべての監査ファイルの監査レコードをマージします。通常、/etc/security/audit が監査ルートディレクトリです。auditreduce コマンドは、マージ結果を標準出力に送ります。マージ結果は、時系列に並べて 1 つの出力ファイルに格納することもできます。このファイルの形式はバイナリデータです。

auditreduce コマンドを使用して、特定の種類のレコードを選択し、解析に利用することもできます。auditreduce コマンドのマージ機能と選択機能は、論理的にほかに依存しません。auditreduce は、入力ファイルのレコードを読み取ると、マージしてディスクに書き込む前に、データを抽出します。

praudit コマンドは、auditreduce コマンドのバイナリ出力を、ユーザーが読める書式に変換します。

auditreduce コマンドにオプションを指定すると、次の操作も実行できます。

• 特定の監査フラグによって生成された監査レコードを要求する

• 特定のユーザーによって作成された監査レコードを要求する

• 特定の日付に作成された監査レコードを要求する

auditreduce に引数を指定しなかった場合は、デフォルトの監査ルートディレクトリ /etc/security/audit 内のサブディレクトリが検査されます。このコマンドは、start-time.end-time.hostname ファイルが配置されている files ディレクトリを検査します。auditreduce コマンドは、監査データが異なるディレクトリに格納されている場合に非常に有用です。図 23–1 は、監査データがホスト別のディレクトリ内に格納されている場合を示しています。図 23–2 は、監査データが監査サーバー別のディレクトリ内に格納されている場合を示しています。

図 23–1 ホストごとに格納された監査トレール

図 23–2 サーバーごとに格納された監査トレール

/etc/security/audit のパーティションが小さい場合、デフォルトのディレクトリに監査データを格納しない方法もあります。-R オプションを使用して、auditreduce コマンドを別のディレクトリに渡すことができます。

# auditreduce -R /var/audit-alt 

-S オプションを使用して、特定のサブディレクトリを指定することもできます。

# auditreduce -S /var/audit-alt/host1 

特定の監査ログファイルだけを処理するには、auditreduce にそのファイルをコマンド引数として直接指定できます。

# auditreduce /var/audit/egret/files/2001*.2001*egret

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

praudit コマンド

praudit コマンドは、標準入力からバイナリ形式の監査レコードを読み込み、そのレコードを表示可能な書式で表示します。auditreduce コマンドまたは 1 つの監査ファイルからの出力は、praudit コマンドの入力にパイプできます。catコマンドを使用すると、複数のファイルを連結して入力にパイプすることができます。tail コマンドを使用すると、現在の監査ファイルを入力にパイプできます。

praudit コマンドでは、次の 5 つの出力形式を生成できます。

• デフォルト – デフォルトでは、1 行に 1 つの監査トークンが表示されます。デフォルトでは、監査イベントは ioctl(2) などのその内容が表示され、テキストで表示できる値はすべてテキスト形式で表示されます。たとえば、ユーザーは、ユーザー ID ではなく、ユーザー名で表示されます。

• -l オプション – このオプションでは、1 行に 1 つの監査レコードが表示されます。-d オプションを指定すると、トークンフィールドおよびトークン間で使用される区切り文字を変更できます。デフォルトの区切り文字は、コンマです。

• -r オプション – このオプションでは、数値で表現できる値はすべて数値として表示されます。たとえば、ユーザーはユーザー ID で、インターネットアドレスは 16 進形式で、モードは 8 進形式で表示されます。監査イベントは、イベント番号 (158 など) で表示されます。

• -s オプション – このオプションでは、監査イベントがテーブル名 ( AUE_IOCTL など) で表示されます。その他のトークンは、デフォルトと同じ形式で表示されます。

• -x オプション – このオプションでは、監査レコードが XML 形式で表示されます。このオプションは、出力結果をブラウザや XML を操作するスクリプトに入力する場合に便利です。

  XML は、監査サブシステムが提供する DTD によって記述されます。また、Solaris ソフトウェアにはスタイルシートも付属しています。DTD とスタイルシートは /usr/share/lib/xml ディレクトリ内に格納されています。

praudit のデフォルトの出力形式では、各レコードは監査トークンのシーケンスとして容易に識別できます。各トークンは 1 行ごとに出力されます。各監査レコードは header トークンで始まります。awk コマンドなどを使用すると、出力をさらに処理できます。

次の出力は、 headerトークンを praudit コマンドのデフォルトで出力したものです。

header,240,1,ioctl(2),es,Tue Sept  7 16:11:44 1999, + 270 msec

次の出力は、同じ header トークンを praudit -r コマンドで出力したものです。

20,240,1,158,0003,699754304, + 270 msec

例 — praudit 出力をスクリプトで処理する

praudit コマンドの出力は、必要に応じてテキストとして操作できます。たとえば、auditreduce コマンドでは選択できないレコードを選択したいことがあります。単純なシェルスクリプトを使用すると、praudit の出力を処理できます。次の単純なスクリプトの例は、1 つの監査レコードを 1 行にまとめ、ユーザーが指定した文字列を検索し、最後に監査ファイルを元の形式に戻します。具体的には、スクリプトは次の処理を実行します。

1. header トークンに、Control-A という接頭辞を目印として付けます。

2. 1 つのレコード内のすべての監査トークンを 1 行に結合します。ただし、改行の情報は Control-A として保持されます。

3. grep コマンドを実行します。

4. 元の改行を復元します。

#!/bin/sh
praudit | sed -e '1,2d' -e '$s/^file.*$//' -e 's/^header/^aheader/' \\
| tr '\\012\\001' '\\002\\012' \\
| grep "$1" \\
| tr '\\002' '\\012'

スクリプトの ^a は、^ と a という 2 つの文字ではなく、Control-A です。この接頭辞によって、ヘッダートークンが、テキストとして表示される header 文字列と区別されます。

auditconfig コマンド

auditconfig コマンドは、監査構成パラメータを取得して設定するためのコマンド行インタフェースを提供します。auditconfig コマンドは、次の操作を実行できます。

• 監査ポリシーの表示、チェック、構成

• 監査状態 (オン/オフ) の確認

• 監査状態 (オン/オフ) の切り替え

• 監査ディレクトリと監査ファイルの管理

• 監査キューの管理

• 事前選択マスクの取得/設定

• 監査イベントの監査クラスへの割り当ての取得/設定

• セッション ID や監査 ID などの構成情報の取得/設定

• プロセス、シェル、セッションの監査特性の構成

• 監査統計情報のリセット

利用できるオプションについては、auditconfig(1M) のマニュアルページを参照してください。

監査サービスファイル

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

• /etc/system ファイル

• audit_class ファイル

• audit_controlファイル

• audit_data ファイル

• audit_event ファイル

• audit_startup スクリプト

• audit_user ファイル

• audit_warn スクリプト

/etc/system ファイル

/etc/system ファイルには、カーネルが初期設定で読み込み、システム動作をカスタマイズするためのコマンドが格納されます。bsmconv および bsmunconv シェルスクリプトは、監査機能を起動および終了するときに使用され、/etc/system ファイルを変更します。bsmconv シェルスクリプトは、 /etc/system ファイルに次の行を追加します。

set c2audit:audit_load=1

set c2audit:audit_load=1 コマンドは、システムのブート時に監査モジュール (カーネルモジュールの一種) をロードします。bsmunconv シェルスクリプトは、システムのリブート時に監査を無効にします。このコマンドは、/etc/system ファイルから c2audit の行を削除します。

audit_class ファイル

/etc/security/audit_class ファイルには、既存の監査クラスの定義が含まれます。監査クラスは、監査イベントのグループです。各監査クラスには、クラスの短縮名として監査フラグが関連付けられます。audit_control ファイル内のこの短縮名を使用して、監査するイベントのクラスを事前選択します。監査フラグでは、接頭辞を使ってきめ細かな選択が行えます。詳細については、監査フラグの構文を参照してください。

root ユーザーまたはそれと同等の役割を持つ管理者は、監査クラスの定義を変更できます。管理者は、audit_class ファイルをテキストエディタで編集することによって、新しい監査クラスを定義したり、既存クラスの名前を変更したり、既存クラスにその他のさまざまな変更を施したりすることができます。詳細は、audit_class(4)のマニュアルページを参照してください。監査フラグについては、監査フラグの定義を参照してください。

audit_controlファイル

各マシン上の /etc/security/audit_control ファイルは、監査デーモンによって読み込まれます。詳細については、audit_control(4) のマニュアルページを参照してください。audit_control ファイルは /etc/security ディレクトリにあります。各マシンには、独自の audit_control ファイルがローカルに格納されています。このファイルを使用すると、個々のマシン上で、さまざまな場所にある監査ファイルシステムをさまざまな順序でマウントすることが可能となります。たとえば、マシン A の一次監査ファイルシステムは、マシン B の二次監査ファイルシステムになっている場合があります。

audit_control ファイルには、次の 4 種類の情報を指定します。各行の情報は、キーワードで始まります。

• 「監査フラグ」行は flags: で始まります。 この行に指定する監査フラグでは、マシン上のすべてのユーザーを対象に監査するイベントのクラスを、事前選択します。ここで指定する監査フラグは、「マシン全体の監査フラグ」または「マシン全体の監査事前選択マスク」と呼びます。 監査フラグは、空白を入れずにコンマで区切ります。

• 「帰属不可能フラグ」行は naflags: で始まります。この行に指定する監査フラグでは、特定のユーザーに起因しない動作が発生したときに監査するイベントクラスを、事前選択します。監査フラグは空白を入れずにコンマで区切ります。

• 「監査しきい値」行は minfree: で始まります。この行では、すべての監査ファイルシステムに確保する最小空き領域のレベルを定義します。minfree の割合は、0 以上で指定します。デフォルトは 20% です。監査ファイルシステムの使用率が 80% に達すると、次に利用可能な監査ディレクトリに監査データが格納されるようになります。audit_warn(1M) のマニュアルページを参照してください。

• 「ディレクトリ定義」行は dir: で始まります。 各行には、監査ログファイルを格納するためにマシンが使用する、監査ファイルシステムとディレクトリを定義します。1 行または複数行のディレクトリを定義できます。dir: 行では、順番が重要になります。auditd デーモンは、ここで指定した順番でディレクトリに監査ファイルを作成します。1 番目のディレクトリがそのマシンの 1 次監査ディレクトリになり、2 番目のディレクトリが 2 次監査ディレクトリになります。1 番目のディレクトリがいっぱいになると、監査デーモンは 2 番目以降のディレクトリに監査トレールファイルを作成します。 audit(1M) のマニュアルページを参照してください。

audit_control ファイルは、各マシン上での構成処理中に作成されます。

audit_control ファイルを変更したときは、audit -s コマンドを実行すると、監査デーモンによってファイルが再度読み取られます。

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

audit_control ファイルの例

次の例は、マシン dopey で使用する audit_control ファイルです。dopey では、監査サーバー blinken 上で 2 つの監査ファイルシステムを使用し、2 つ目の監査サーバー winken からマウントされる 3 つ目の監査ファイルシステムを使用します。3 つ目のファイルシステムは、blinken 上の監査ファイルシステムがいっぱいであるか使用できないときにだけ使用されます。minfree の値として 20% を指定しているため、ファイルシステムの使用率が 80% に達した時点で警告スクリプトが実行されます。以下のフラグでは、監査対象としてログイン操作と管理操作が指定されています。これらの操作について、その成功と失敗が監査されます。ファイルシステムオブジェクト作成の失敗を除くすべての失敗が、監査対象となります。また、ユーザーに起因しないイベントも監査されています。

flags:lo,am,-all,^-fc
naflags:lo,nt
minfree:20
dir:/etc/security/audit/blinken/files
dir:/etc/security/audit/blinken.1/files
#
# blinken がいっぱいになったときに使用する監査ファイルシステム
#
dir:/etc/security/audit/winken 

audit_data ファイル

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

# cat /etc/security/audit_data
116:/etc/security/audit/blinken.1/files/19990320100002.not_terminated.dopey

audit_event ファイル

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

audit_startup スクリプト

/etc/security/audit_startup スクリプトは、システムがマルチユーザーモードに移行すると監査デーモンを自動的に起動します。このスクリプトは、監査デーモンの実行直前に起動シーケンスの一部として起動されます。詳細は、audit_startup(1M)のマニュアルページを参照してください。

デフォルトの audit_startup スクリプトは、イベントからクラスへの割り当てを自動的に構成し、監査ポリシーを設定します。このスクリプトは、BSM パッケージのインストール時に作成されます。

audit_user ファイル

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

• そのユーザーについて常に監査するイベントクラスを指定する

• そのユーザーについて監査しないイベントクラスを指定する

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

• username フィールド

• always-audit フィールド

• never-audit フィールド

これらの監査フィールドは、この順番で処理されます。always-audit フィールドは、指定されたクラスの監査を有効にします。never-audit フィールドは、指定されたクラスの監査を無効にします。

never-audit フィールド内で all 監査フラグを設定したままにする誤りがよくあるので注意してください。all 監査フラグを指定したままにすると、そのユーザーの監査がすべてオフに設定され、always-audit フィールドに設定されているフラグが無効になります。このフラグは、audit_control ファイルで設定されたマシン全体の監査フラグよりも優先されます。

ユーザーの never-audit フラグは、システムのデフォルト値よりも優先されます。システムのデフォルトを有効にしたい場合も考えられます。たとえば、ファイルシステムオブジェクトの正常な読み込みを除いて、ユーザー tamiko のすべてのイベントを監査するとします。この方法は、ユーザーのほとんどすべての動作を監査しますが、監査データは、すべてのデータ読み取りを監査した場合の約 4 分の 3 しか生成されません。このとき、システムデフォルトを tamiko に適用したいとします。次に 2 つの audit_user エントリ例を示します。

正しいエントリ

tamiko:all,^+fr:

間違ったエントリ

tamiko:all:+fr

1 つ目の例は、「ファイル読み取り動作を除くすべての動作を監査する」ことを表しています。2 つ目の例は「常にすべての動作を監査するが、正常なファイルの読み取り動作はまったく監査しない」ことを表しています。2 つ目の例は正しいエントリではありません。never-audit フィールドがシステムのデフォルト値を無効にするからです。1 つ目の例では期待どおりの結果になります。always-audit フラグには、all フラグへの例外が含まれています。never-audit フィールドにはフラグが指定されていないため、audit_control ファイル内のシステムデフォルト値は無効になりません。

正常終了したイベントと失敗したイベントは別々に取り扱われます。プロセスが生成する監査レコードの数は、イベントが正常終了した場合よりも失敗した場合のほうが多くなる可能性があります。

audit_warn スクリプト

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

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

• 監査ディレクトリが minfree の許容値を超えていっぱいになった場合。minfree 値はソフト制限値で、監査ファイルシステム上で使用できる領域の割合です。

  audit_warn スクリプトは、文字列 soft と、使用可能領域が下限値を下回ったディレクトリ名を使用して起動されます。監査デーモンは、次の適切なディレクトリに自動的に切り替えます。デーモンは、新しいディレクトリが minfree 制限値に達するまで、このディレクトリに監査ファイルを書き込みます。その後、監査デーモンは、audit_control ファイルに指定された順序で残りの各ディレクトリに順次アクセスします。デーモンは、各ディレクトリが minfree 制限値に達するまで監査レコードを書き込みます。

• すべての監査ディレクトリが minfree のしきい値に達した場合。

  文字列 allsoft を使用して audit_warn スクリプトが起動されます。コンソールにメッセージが書き込まれます。さらに、audit_warn の別名にメールが送信されます。

  audit_control ファイルに指定されたすべての監査ディレクトリが minfree しきい値に達すると、監査デーモンは最初のディレクトリに戻ります。デーモンは、そのディレクトリが完全にいっぱいになるまで監査レコードを書き込みます。

• 監査ディレクトリが完全にいっぱいになり、残りの容量がなくなった場合。

  文字列 hard とディレクトリ名を使用して、audit_warn スクリプトが起動されます。コンソールにメッセージが出力されます。さらに、audit_warn の別名にメールが送信されます。

  監査デーモンは、使用可能領域が残っている次の適切なディレクトリに自動的に切り替えます。その後、監査デーモンは、audit_control ファイルに指定された順序で残りの各ディレクトリに順次アクセスします。デーモンは、各ディレクトリがいっぱいになるまで完全レコードを書き込みます。

• すべての監査ディレクトリが完全にいっぱいになった場合。引数として文字列 allhard を使用して、audit_warn スクリプトが起動されます。

  デフォルトの構成では、コンソールにメッセージが書き込まれます。さらに、audit_warn の別名にメールが送信されます。監査レコードを生成するプロセスは中断されます。監査デーモンはループに入り、領域が使用可能になるのを待って監査レコードの処理を再開します。監査レコードが処理されるまで、監査対象の動作は待機します。監査レコードを生成しようとするプロセスは、すべて中断されます。このため、別の監査管理アカウントを設定し、監査機能を有効にしないで操作できるように設定する必要があります。このように設定すれば、操作を中断せずに継続することができます。

• 内部エラーが発生した場合。次のような内部エラーが考えられます。

  • ebusy – 別の監査デーモンプロセスがすでに動作している

  • tmpfile – 一時ファイルを使用できない

  • auditsvc – auditsvc() システムコールが失敗した

  • postsigterm – 監査のシャットダウン中に信号を受信した

  audit_warn の別名にメールが送られます。

• audit_control ファイルの構文に問題が検出された場合。デフォルトでは、コンソールにメッセージが書き込まれます。さらに、audit_warn の別名にメールが送信されます。

監査管理プロファイル

Solaris オペレーティング環境には、監査サービスを構成するためのプロファイルや監査トレールを分析するためのプロファイルが用意されています。

• Audit Control – 特定の役割が Solaris 監査を構成できるようにするためのプロファイル。このプロファイルは、監査ファイルを構成したり監査コマンドを実行したりする権限を付与します。Audit Control プロファイルで割り当てられた役割が実行できるコマンドは次のとおりです。 audit、auditd、auditconfig、bsmconv、および bsmunconv

• Audit Review – 特定の役割が Solaris 監査レコードを分析できるようにするためのプロファイル。このプロファイルは、praudit コマンドと auditreduce コマンドを使って監査レコードを読み取る権限を付与します。このプロファイルで割り当てられた役割は、 auditstat コマンドを実行することもできます

• System Administrator – Audit Review プロファイルを含むプロファイル。System Administrator プロファイルで割り当てられた役割は、監査レコードを分析できます。

プロファイルを役割に割り当てるには、役割の作成を参照してください。

監査クラスと監査フラグ

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

監査フラグを audit_user ファイルにあるユーザーエントリに入れることにより、各ユーザーについて監査を行う対象を変更できます。監査フラグは、auditconfig コマンドの引数としても使用します。auditconfig(1M) のマニュアルページを参照してください。

監査フラグの定義

次の表に、事前に定義されている監査クラスを示します。この表には、監査フラグ、ロング名、および短い説明が記載されています。監査フラグは、監査クラスを表す短縮名です。監査するイベントのクラスを指定するときは、監査構成ファイルの監査フラグを使用します。監査フラグは、auditconfig などの監査コマンドの引数としても使用します。新しいクラスを定義するには、audit_class ファイルを変更します。既存クラスの名前の変更も可能です。詳細は、audit_class(4) のマニュアルページを参照してください。

監査フラグの構文

監査フラグの接頭辞によって、イベントクラスが成功した場合に監査するのか、失敗した場合に監査するのか、が決まります。接頭辞を指定しなかったクラスは、成功した場合も失敗した場合も監査されます。次の表に、監査フラグの書式といくつかの例を示します。

all フラグを指定すると、大量のデータが生成され、監査ファイルシステムがすぐにいっぱいになる可能性があります。all フラグは、特別な理由ですべての活動を監査する場合にだけ使用してください。

監査フラグを変更する接頭辞

キャレット接頭辞 ^ を使えば、選択されている監査フラグをさらに変更できます。次の表は、キャレット接頭辞を使って選択済みの監査フラグを変更する方法を示したものです。

監査フラグの接頭辞は、次のファイルとコマンドで使用できます。

• audit_control ファイルの flags 行で使用する

• audit_user ファイルのユーザーエントリの flags フィールドで使用する

• auditconfig コマンドの引数で使用する

audit_control ファイル内での接頭辞の使用例については、audit_controlファイル を参照してください。

監査ポリシー

監査ポリシーには、監査トレールにトークンまたは情報を追加するかどうかを指定します。監査ポリシーについては、使用する監査ポリシーの決定 を参照してください。

プロセスの監査特性

最初のログイン時に次の監査特性が設定されます。

• 「プロセス事前選択マスク」 – audit_control ファイル内の監査フラグと audit_user ファイル内の監査フラグを結合したもの。ユーザーがログインすると、login コマンドは、これらのフラグを結合し、そのユーザーのプロセスに対する「プロセス事前選択マスク」を確立します。 プロセス事前選択マスクは、各監査イベントクラス内のイベントで監査レコードを生成するかどうかを指定します。

  プロセス事前選択マスクを取得するアルゴリズムは、次の式で表されます。

  user's process preselection mask = (flags: line + always-audit flags) - never-audit flags

  audit_control ファイル内の flags: 行にある監査フラグを、audit_userファイル内のユーザーエントリの always-audit フィールドにあるフラグに追加します。次に、ユーザーの never-audit フィールドにあるフラグを、全体のフラグから減算します。

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

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

• 「端末 ID (ポート ID、マシン ID)」 – 端末 ID は、ホスト名とインターネットアドレスで構成され、そのあとにユーザーがログインした物理デバイスを識別する一意の番号が続きます。通常、ログインはコンソールから行われ、そのコンソールデバイスに対応する番号は 0 になります。

監査トレール

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

監査ディレクトリは、監査専用でないほかのファイルシステム内に物理的に配置することもできますが、予備のディレクトリを除き、この配置は行わないでください。予備のディレクトリとは、他の適切なディレクトリが使用できないときに限り、監査ファイルが書き込まれるディレクトリです。

監査ディレクトリを監査専用でないファイルシステムに配置してもかまわない場合が、もう 1 つあります。つまり、ソフトウェア開発環境を使用していて、監査がオプションである場合は、そうしてもかまいません。監査トレールを保存するよりも、ディスク容量を有効に使用するほうが重視されるからです。しかし、セキュリティが重視される環境では、監査ディレクトリをほかのファイルシステム内に入れることは許されません。

また、次の要因も考慮する必要があります。

• 各ホストには、少なくとも 1 つのローカル監査ディレクトリを用意する必要があります。このローカルディレクトリは、ホストが監査サーバーと通信できなかった場合の予備ディレクトリとして使用できます。

• 監査ディレクトリは、読み取りオプションと書き込みオプション (rw) を使用してマウントしてください。監査ディレクトリをリモートマウントするときは、intr および noac オプションも使用してください。

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

監査ファイルの命名規則

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

監査ファイルの命名

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

start-time.finish-time.machine 

• start-time – 監査ファイル内の最初の監査レコードが生成された時刻

• finish-time – 最後のレコードがファイルに書き込まれた時刻

• machine – ファイルを生成したマシン名

監査ファイル名の例については、閉じられた監査ファイル名の例を参照してください。

監査ログファイルが動作中である場合は、次の書式の名前が付いています。

start-time.not_terminated.machine

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

auditreduce コマンドは、ファイル名に含まれるタイムスタンプを手掛かりにして、特定期間内のレコードを検索します。1 か月あるいはそれ以上蓄積された監査ファイルがオンライン上に存在する可能性もあるため、これらのタイムスタンプは重要な意味を持ちます。24 時間以内に生成されたレコードをすべてのファイルから検索するとなると、莫大な時間がかかることがあります。

タイムスタンプの書式と説明

start-time と end-time は 1 秒単位のタイムスタンプです。これらのタイムスタンプは、グリニッジ標準時 (GMT) で指定されます。タイムスタンプの書式は、次のように年が 4 桁で、2 桁ずつの月、日、時、分、秒があとに続きます。

YYYYMMDDHHMMSS

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

動作中のファイル名の例

動作中のファイル名の書式は次のとおりです。

YYYYMMDDHHMMSS.not_terminated.machine

次に例を示します。

19990327225243.not_terminated.dopey

監査ログファイルの名前には、開始日が使用されます。上記の例の監査ファイルは、GMT の1990 年 3 月 27 日午後 10:52:43 に作成されています。ファイル名のうち not_terminated は、このファイルがまだ動作中であるか、または auditd デーモンが予期しない割り込みを行なったことを意味します。末尾の名前 dopey は、監査データが収集されているマシンのホスト名です。

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

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

YYYYMMDDHHMMSS.YYYYMMDDHHMMSS.hostname

次に例を示します。

19990320005243.19900327225351.dopey

この例の監査ログファイルは、GMT の 1999 年 3 月 20 日の午前 12:52:43 に作成されています。このファイルは、GMT の 3 月 27 日午後 10:53:51 に閉じられました。末尾の名前 dopey は、監査データが収集されたマシンのホスト名です。

auditd が予期しない割り込みを行うと、その時点で開いている監査ファイル名には not_terminated が付きます。たとえば、マシンがリモートマウントされた監査ファイルに書き込んでいるときに、ファイルサーバーにアクセスできなくなることがあります。マウントされた監査ファイルにアクセスできなくなると、not_terminated 指定がファイル名に付いたままになります。サービスが復旧すると、監査デーモンは、古い監査ファイルの名前はそのままにして、新しい監査ファイルを開きます。

監査レコードの構造

監査レコードは、一連の監査トークンです。監査トークンには、ユーザー ID、時刻、日付などのイベント情報が入っています。監査レコードは、header トークンで始まり、オプションの trailer トークンで終わります。ほかの監査トークンには、監査可能なイベントに関連する情報が入っています。次の図は、標準的な監査レコードを示しています。

図 23–3 標準的な監査レコードの構造

監査トークンの形式

各トークンにはトークンの種類識別子とそのあとにトークン固有のデータが続いています。各トークンの種類には固有の形式があります。次の表は、各トークンの名前と説明の一覧です。

監査レコードには、必ず header トークンが入っています。header トークンは、監査トレール内で監査レコードの始まりを示します。ユーザーの動作に起因しないイベントからの監査レコードを除き、どの監査レコードにも subject トークンが入っています。ユーザーに起因するイベントの場合、この 2 つのトークンはイベントを引き起こしたプロセスの値を参照します。非同期イベントの場合、process トークンはシステムを参照します。

acl トークン

acl トークンには、アクセス制御リストに関する情報を記録します。次の 4 つの固定フィールドがあります。

• acl トークンであることを特定するトークン ID

• ACL タイプを指定するフィールド

• ACL ID フィールド

• ACL に関連付けるアクセス権を一覧するフィールド

praudit コマンドでは、acl トークンは次のように表示されます。

acl,tpanero,staff,0755

次の図に acl トークンの形式を示します。

図 23–4 acl トークンの形式

arbitrary トークン

arbitrary トークンは、監査トレール用にデータをカプセル化します。4 つの固定長フィールドと 1 つのデータ配列からなっています。固定長フィールドは次のとおりです。

• arbitrary トークンであることを特定するトークン ID

• 推奨される形式フィールド (16 進など)

• カプセル化するデータのサイズを指定する (短い形式など) サイズフィールド

• 後続の項目数を指定するカウントフィールド

トークンの残りの部分は、指定された形式の 1 つまたは複数の項目からなっています。praudit コマンドでは、arbitrary トークンは次のように表示されます。

arbitrary,decimal,int,1
42

次の図に arbitrary トークンの形式を示します。

図 23–5 arbitrary トークンの形式

次の表は、出力形式フィールドに指定できる値を示します。

次の表は、項目サイズフィールドに指定できる値を示します。

arg トークン

arg トークンには、システムコールの引数情報 (システムコールの引数番号、引数の値、およびオプションの説明) が含まれています。このトークンを使用すると、監査レコード内で 32 ビット整数のシステムコール引数を指定できます。次の 5 つのフィールドがあります。

• argトークンであることを特定するトークン ID

• トークンが参照するシステムコールの引数の ID

• 引数の値

• テキスト文字列の長さ

• テキスト文字列

praudit コマンドでは、arg トークンは次のように表示されます。

argument,1,0x00000000,addr

arg トークンの形式を示します。

図 23–6 arg トークンの形式

attr トークン

attr トークンには、ファイル v ノードからの情報が含まれています。次のトークンには 7 つのフィールドがあります。

• attr トークンであることを特定するトークン ID

• ファイルのアクセスモードと種類

• 所有者のユーザー ID

• 所有者のグループ ID

• ファイルシステム ID

• i ノード ID

• ファイルが示すデバイス ID

ファイルシステム ID とデバイス ID の詳細は、statvfs(2) のマニュアルページを参照してください。

attr トークンには通常、path トークンが付いています。attr トークンはパスの検索中に生成されます。パス検索エラーが発生すると、必要なファイル情報を取得するための v ノードが利用できません。このため、attr トークンは監査レコードの一部として組み込まれません。praudit コマンドでは、attr トークンは次のように表示されます。

attribute,100555,root,staff,1805,13871,-4288

attr トークンの形式を示します。

図 23–7 attr トークンの形式

exec_args トークン

exec_args トークンは、 exec() システムコールへの引数を記録します。次の 2 つの固定フィールドがあります。

• exec_args トークンであることを特定するトークン ID

• exec() システムコールに渡す引数の数を表すカウント

このトークンの残りの部分は、0 個以上の NULL で終わる文字列からなっています。praudit コマンドでは、 exec_args トークンは次のように表示されます。

vi,/etc/security/audit_user

exec_args トークンの形式を示します。

図 23–8 exec_args トークンの形式

exec_args トークンは、監査ポリシー argv が有効なときにだけ出力されます。

exec_env トークン

exec_envトークンは、exec() システムコールの現在の環境変数を記録します。次の 2 つの固定フィールドがあります。

• exec_env トークンであることを特定するトークン ID

• exec() システムコールに渡す引数の数を表すカウント

このトークンの残りの部分は、0 個以上の NULL で終わる文字列からなっています。praudit コマンドでは、exec_env トークンは次のように表示されます。

exec_env,25,
GROUP=staff,HOME=/export/home/matrix,HOST=mestrix,HOSTTYPE=sun4u,HZ=100,
LC_COLLATE=en_US.ISO8859-1,LC_CTYPE=en_US.ISO8859-1,LC_MESSAGES=C,
LC_MONETARY=en_US.ISO8859-1,LC_NUMERIC=en_US.ISO8859-1,
LC_TIME=en_US.ISO8859-1,LOGNAME=matrix,MACHTYPE=sparc,
MAIL=/var/mail/matrix,OSTYPE=solaris,PATH=/usr/sbin:/usr/bin,PS1=#,
PWD=/var/audit,REMOTEHOST=192.168.13.5,SHELL=/usr/bin/csh,SHLVL=1,
TERM=dtterm,TZ=US/Pacific,USER=matrix,VENDOR=sun

次の図に exec_env トークンの形式を示します。

図 23–9 exec_env トークンの形式

exec_env トークンは、監査ポリシー arge が有効なときにだけ出力されます。

exit トークン

exit トークンは、プログラムの終了状態を記録します。次のフィールドがあります。

• exit トークンであることを特定するトークン ID

• exit() システムコールに渡されるプログラムの終了状態

• 終了状態を記述するか、システムエラー番号を示す戻り値

praudit コマンドでは、exit トークンは次のように表示されます。

exit,Error 0,0

次の図に exit トークンの形式を示します。

図 23–10 exit トークンの形式

file トークン

file トークンは、監査デーモンによって生成される特殊なトークンです。このトークンは、古い監査ファイルが終了した時点で、新しい監査ファイルの開始と古い監査ファイルの終了をマークします。監査デーモンは、このトークンを含む特殊な監査レコードを構築して、連続する監査ファイルを 1 つの監査トレールに「リンク」します。次の 4 つのフィールドがあります。

• file トークンであることを特定するトークン ID

• ファイルが作成または閉じた日時を識別する時刻と日付のスタンプ

• NULL 終了文字を含むファイル名のバイト数

• NULL で終了するファイル名を保持するフィールド

praudit コマンドでは、file トークンは次のように表示されます。

file,Tue Sep  1 13:32:42 1992, + 79249 msec,
	/var/audit/localhost/files/19990901202558.19990901203241.quisp

次の図に file トークンの形式を示します。

図 23–11 file トークンの形式

group トークン (現在は使用しない)

このトークンは、newgroups トークンに置き換えられています。newgroups トークンは同じ種類の情報を少ない領域で提供します。ここでは完全を期すために group トークンについて説明しますが、アプリケーション設計者は newgroups トークンを使用してください。praudit の出力では、どちらのトークン ID にも group というラベルが付いているため、praudit がこれら 2 つのトークンを区別しない点に注意してください。

group トークンは、プロセスの資格からグループエントリを記録します。group トークンには次の 2 つの固定長フィールドがあります。

• group トークンであることを特定するトークン ID

• サイズが NGROUPS_MAX (16) のグループエントリの配列

このトークンの残りの部分は 0 個以上のグループエントリからなっています。praudit コマンドでは、group トークンは次のように表示されます。

group,staff,admin,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1

次の図に group トークンの形式を示します。

図 23–12 group トークンの形式

group トークンは、監査ポリシー group が有効なときにだけ出力されます。

header トークン

header トークンは、監査レコードの始まりをマークし、trailer トークンとの組み合わせでレコード内のほかのすべてのトークンを囲む特殊なトークンです。次の 6 つのフィールドがあります。

• header トークンであることを特定するトークン ID

• この監査レコード全体の長さのバイト数。ヘッダーとトレーラを含む

• この監査レコード構造体のバージョンを特定するバージョン番号

• このレコードが表す監査イベントの種類を特定する監査イベント ID

• この監査イベントの特殊な特性を特定する ID 修飾子

• レコードの作成日時

64 ビットシステムでは、header トークンは、32 ビットタイムスタンプではなく 64 ビットタイムスタンプで表示されます。

praudit では、ioctl() システムコールの header トークンは次のように表示されます。

header,240,1,ioctl(2),es,Tue Sept  1 16:11:44 2001, + 270000 msec

次の図に header トークンの形式を示します。

図 23–13 header トークンの形式

ID 修飾子フィールドでは、次のフラグが定義されています。

0x4000			PAD_NOTATTR						nonattributable event
0x8000			PAD_FAILURE						fail audit event

in_addr トークン

in_addr トークンには、インターネットプロトコルアドレスが含まれます。Solaris 8 リリースから、IPv4 形式、IPv6 形式のいずれかでインターネットアドレスを表示できるようになりました。IPv4 アドレスは 4 バイトを使用します。IPv6 アドレスは、16 バイトを使って種類を記述し、さらに 16 バイトを使用してアドレスを記述します。次の 2 つのフィールドがあります。

• in_addr トークンであることを特定するトークン ID

• インターネットアドレス

praudit コマンドでは、in_addr トークンは次のように表示されます。

ip address,129.150.113.7

次の図に in_addr トークンの形式を示します。

図 23–14 in_addr トークンの形式

ip トークン (現在は使用しない)

ip トークンには、インターネットプロトコルのヘッダーのコピーが含まれます。次の 2 つのフィールドがあります。

• ip トークンであることを特定するトークン ID

• IP ヘッダーのコピー (全部で 20 バイト)

praudit コマンドでは、ip トークンは次のように表示されます。

ip address,0.0.0.0

IP ヘッダー構造は、/usr/include/netinet/ip.h ファイル内で定義されています。次の図に ip トークンの形式を示します。

図 23–15 ip トークンの形式

ipc トークン

ipc トークンには、特定のIPC オブジェクトを識別するために呼び出し元に使用される System V IPC メッセージ、セマフォ、または共有メモリーハンドルが含まれています。次の 3 つのフィールドがあります。

• IPC トークンであることを特定するトークン ID

• IPC オブジェクトの形式を指定する形式フィールド

• IPC オブジェクトを識別するハンドル

praudit コマンドでは、ipc トークンは次のように表示されます。

IPC,msg,3

IPC オブジェクト識別子は、コンテキストに依存しない Solaris 監査トークンに準拠していません。IPC オブジェクトを一意に識別するグローバルな「名前」はありません。代わりに、IPC オブジェクトはハンドルで識別されます。これらのハンドルは、IPC オブジェクトの動作中にのみ有効です。しかし IPC オブジェクトの識別は問題となりません。System V の IPC メカニズムはあまり使用されず、すべてのメカニズムが同じ監査クラスを共有するからです。

次の表は、IPC オブジェクトの形式フィールドに指定できる値の一覧です。値は /usr/include/bsm/audit.h ファイル内で定義されます。

次の図に ipc トークンの形式を示します。

図 23–16 ipc トークンの形式

ipc_perm トークン

ipc_perm トークンには、System V の IPC アクセス情報が含まれています。このトークンは、IPC 共有メモリーイベント、IPC セマフォイベント、および IPC メッセージイベントによって生成される監査レコードに追加されます。次の 8 つのフィールドがあります。

• ipc_perm トークンであることを特定するトークン ID

• IPC 所有者のユーザー ID

• IPC 所有者のグループ ID

• IPC 作成者のユーザー ID

• IPC 作成者のグループ ID

• IPC のアクセスモード

• IPC のシーケンス番号

• IPC 鍵の値

praudit コマンドでは、ipc_perm トークンは次のように表示されます。

IPC perm,root,wheel,root,wheel,0,0,0x00000000

値は、IPC オブジェクトに関連付けられた ipc_perm 構造から取り出されます。次の図に ipc_perm トークンの形式を示します。

図 23–17 ipc_perm トークンの形式

iport トークン

iport トークンには、TCP (または UDP) ポートアドレスが含まれています。次の 2 つのフィールドがあります。

• iport トークンであることを特定するトークン ID

• TCP または UDP ポートのアドレス

praudit コマンドでは、iport トークンは次のように表示されます。

ip port,0xf6d6

次の図に iport トークンの形式を示します。

図 23–18 iport トークンの形式

newgroups トークン

group トークンは、このトークンによって置き換えられます。praudit の出力では、どちらのトークン ID にも group というラベルが付いているため、praudit はこれら 2 つのトークンを区別しない点に注意してください。

newgroups トークンは、プロセスの資格からグループエントリを記録します。次の 2 つの固定長フィールドがあります。

• newgroups トークンであることを特定するトークン ID

• この監査レコードに含まれるグループ数を表すカウント

このトークンの残りの部分は 0 個以上のグループエントリからなっています。praudit コマンドでは、newgroups トークンは次のように表示されます。

group, staff, admin

次の図に newgroups トークンの形式を示します。

図 23–19 newgroups トークンの形式

newgroups トークンは、監査ポリシー group が有効なときにだけ出力されます。

opaque トークン

opaque トークンには、フォーマットされていないデータが一連のバイトとして含まれています。次の 3 つのフィールドがあります。

• opaque トークンであることを特定するトークン ID

• このデータのバイト数

• バイトデータ配列

praudit コマンドでは、opaque トークンは次のように表示されます。

opaque,12,0x4f5041515545204441544100

次の図に opaque トークンの形式を示します。

図 23–20 opaque トークンの形式

path トークン

path トークンには、オブジェクトのアクセスパス情報が含まれています。次のフィールドがあります。

• path トークンであることを特定するトークン ID

• パス長のバイト数

• システムの実ルートを基点としたオブジェクトへの絶対パス

praudit コマンドでは、path トークンは次のように表示されます。パス長フィールドは、表示されません。

path,/etc/security/audit_user

次の図に path トークンの形式を示します。

図 23–21 path トークンの形式

process トークン

process トークンには、信号の受信者など、プロセスに関連するユーザーの情報が含まれています。次の 9 つのフィールドがあります。

• process トークンであることを特定するトークン ID

• 不変監査 ID

• 実効ユーザー ID

• 実効グループ ID

• 実ユーザー ID

• 実グループ ID

• プロセス ID

• 監査セッション ID

• デバイス ID とマシン ID で構成される端末 ID

監査 ID、ユーザー ID、グループ ID、プロセス ID、セッション ID は、短い形式ではなく長い形式です。

セッション ID、実ユーザー ID、または実グループ ID の processトークンのフィールドを使用できないことがあります。その場合、値は -1 に設定されます。

端末 ID を含むトークンには、いくつかの種類があります。praudit コマンドは、これらの違いを吸収します。このため、端末 ID を含むすべてのトークンで、端末 ID は同じ方法で処理されます。端末 ID は、IP アドレスとポート番号の組み合わせか、デバイス ID です。モデムに接続されたシリアルポートなどのデバイス ID は、0 である可能性があります。端末 ID には、次の書式があります。

デバイス番号の場合、端末 ID は次のようになります。

• 「32 ビットアプリケーション」 – 4 バイトのデバイス番号、4 バイトは未使用

• 「64 ビットアプリケーション」 – 8 バイトのデバイス番号、4 バイトは未使用

Solaris 8 よりも前のリリースのポート番号の場合、端末 ID は次のようになります。

• 「32 ビットアプリケーション」 – 4 バイトのポート番号、4 バイトの IP アドレス

• 「64 ビットアプリケーション」 – 8 バイトのポート番号、4 バイトの IP アドレス

Solaris 8 リリースまたは Solaris 9 リリースのポート番号の場合、端末 ID は次のようになります。

• 「32 ビット IPv4」 – 4 バイトのポート番号、4 バイトの IP タイプ、4 バイトの IP アドレス

• 「32 ビット IPv6」 – 4 バイトのポート番号、4 バイトの IP タイプ、16 バイトの IP アドレス

• 「64 ビット IPv4」 – 8 バイトのポート番号、4 バイトの IP タイプ、4 バイトの IP アドレス

• 「64 ビット IPv6」 – 8 バイトのポート番号、4 バイトの IP タイプ、16 バイトの IP アドレス

praudit コマンドでは、process トークンは次のように表示されます。

process,root,root,wheel,root,wheel,0,0,0,0.0.0.0

次の図に process トークンの形式を示します。

図 23–22 process トークンの形式

return トークン

return トークンには、システムコールの戻り状態 (u_error) とプロセスの戻り値 (u_rval1) が含まれています。次の 3 つのフィールドがあります。

• return トークンであることを特定するトークン ID

• システムコールのエラー状態

• システムコールの戻り値

return トークンは、必ずシステムコールに関してカーネルによって生成される監査レコードの一部として返されます。このトークンは、アプリケーションを監査中の終了状態と他の戻り値を示します。

praudit コマンドにより return トークンは次のように表示されます。

return,success,0

次の図に return トークンの形式を示します。

図 23–23 return トークンの形式

seq トークン

seq トークン (シーケンストークン) は、シーケンス番号が含まれるオプションのトークンです。このトークンは、デバッグに使用されます。seq ポリシーが有効な場合は、このトークンが各監査レコードに追加されます。次の 2 つのフィールドがあります。

• seq トークンであることを特定するトークン ID

• シーケンス番号が含まれる 32 ビットの符号なし長形式フィールド

シーケンス番号は、監査レコードが生成されて監査トレールに組み込まれるたびに 1 ずつ増分します。praudit コマンドでは、seq トークンは次のように表示されます。

sequence,1292

次の図に seq トークンの形式を示します。

図 23–24 seq トークンの形式

seq トークンは、監査ポリシー seq が有効なときだけ出力されます。

socket トークン

socket トークンには、インターネットソケットを記述する情報が含まれています。次の 6 つのフィールドがあります。

• socket トークンであることを特定するトークン ID

• 参照するソケットの型 (TCP、UDP、UNIX) を示すソケット形式フィールド

• ローカルポートアドレス

• ローカルのインターネットアドレス

• リモートポートアドレス

• リモートのインターネットアドレス

praudit コマンドでは、socket トークンは次のように表示されます。

socket,0x0000,0x0000,0.0.0.0,0x0000,0.0.0.0

Solaris 8 リリースから、IPv4 形式、IPv6 形式のいずれかでインターネットアドレスを表示できるようになりました。IPv4 アドレスは 4 バイトを使用します。IPv6 アドレスは、16 バイトを使って種類を記述し、さらに 16 バイトを使ってアドレスを記述します。次の図に socket トークンの形式を示します。

図 23–25 socket トークンの形式

subject トークン

subject トークンには、操作を実行するユーザーまたは実行する予定のユーザーを記述します。形式は process トークンと同じです。次の 9 つのフィールドがあります。

• subject トークンであることを特定するトークン ID

• 不変監査 ID

• 実効ユーザー ID

• 実効グループ ID

• 実ユーザー ID

• 実グループ ID

• プロセス ID

• 監査セッション ID

• デバイス ID とマシン ID で構成される端末 ID

監査 ID、ユーザー ID、グループ ID、プロセス ID、セッション ID は、短い形式ではなく長い形式です。

セッション ID、実ユーザー ID、または実グループ ID の subject トークンのフィールドを使用できないことがあります。その場合、値は -1 に設定されます。

端末 ID を含むトークンには、いくつかの種類があります。praudit コマンドは、これらの違いを吸収します。このため、端末 ID を含むすべてのトークンで、端末 ID は同じ方法で処理されます。端末 ID は、IP アドレスとポート番号の組み合わせか、デバイス ID です。モデムに接続されたシリアルポートなどのデバイス ID は、0 である可能性があります。端末 ID には、次の書式があります。

デバイス番号の場合、端末 ID は次のようになります。

• 「32 ビットアプリケーション」 – 4 バイトのデバイス番号、4 バイトは未使用

• 「64 ビットアプリケーション」 – 8 バイトのデバイス番号、4 バイトは未使用

Solaris 8 よりも前のリリースのポート番号の場合、端末 ID は次のようになります。

• 「32 ビットアプリケーション」 – 4 バイトのポート番号、4 バイトの IP アドレス

• 「64 ビットアプリケーション」 – 8 バイトのポート番号、4 バイトの IP アドレス

Solaris 8 リリースまたは Solaris 9 リリースのポート番号の場合、端末 ID は次のようになります。

• 「32 ビット IPv4」 – 4 バイトのポート番号、4 バイトの IP タイプ、4 バイトの IP アドレス

• 「32 ビット IPv6」 – 4 バイトのポート番号、4 バイトの IP タイプ、16 バイトの IP アドレス

• 「64 ビット IPv4」 – 8 バイトのポート番号、4 バイトの IP タイプ、4 バイトの IP アドレス

• 「64 ビット IPv6」 – 8 バイトのポート番号、4 バイトの IP タイプ、16 バイトの IP アドレス

subjectトークンは、必ずシステムコールに関してカーネルによって生成される監査レコードの一部として返されます。praudit コマンドでは、subject トークンは次のように表示されます。

subject,cjc,cjc,staff,cjc,staff,424,223,0 0 quisp

次の図に subject トークンの形式を示します。

図 23–26 subject トークンの形式

text トークン

text トークンにはテキスト文字列が含まれています。次の 3 つのフィールドがあります。

• text トークンであることを特定するトークン ID

• テキスト文字列の長さ

• テキスト文字列

praudit コマンドでは、text トークンは次のように表示されます。

text,aw_test_token

次の図に text トークンの形式を示します。

図 23–27 text トークンの形式

trailer トークン

header と trailer の 2 つのトークンは、監査レコードの終端を区別し、他のすべてのトークンを囲む特殊なトークンです。header トークンは監査レコードを開始します。 trailer トークンは監査レコードを終了します。 trailer トークンは省略可能です。trailer トークンは、trail 監査ポリシーが設定されているときにだけ、各レコードの最後のトークンとして追加されます。

trailer トークンを含む監査レコードが生成された場合、auditreduce コマンドは、trailer がレコードの header を正しくポイントしているかどうかを確認します。また、trailer トークンを使用すると監査トレールを逆方向に検索できます。

3 つのフィールドがあります。

• trailer トークンであることを特定するトークン ID

• レコードの終了を示すパッド番号

• header トークンと trailerトークンを含む監査レコードの合計文字数

praudit コマンドでは、trailer トークンは次のように表示されます。

trailer,136

次の図に trailer トークンの形式を示します。

図 23–28 trailer トークンの形式

デバイス割り当て参照

デバイス割り当てを行うことによって、承認されていないユーザーがリムーバブルメディアを使用できないようにします。ユーザーへのデバイス割り当てを要求することができます。デバイスを使用する権限を拒否することができます。そのような割り当てによって、データの損失、コンピュータウィルスなどのセキュリティ違反からサイトを保護できます。次の節では、デバイス割り当てについて説明します。

デバイス割り当てメカニズムの構成要素

デバイス割り当てメカニズムは、次の要素で構成されます。

• allocate、deallocate、dminfo、list_devices コマンド。詳細については、デバイス割り当てコマンドの使用方法を参照してください。

• /etc/security/device_allocate ファイル。詳細については、device_allocate(4) のマニュアルページを参照してください。

• /etc/security/device_maps ファイル。詳細については、 device_maps(4) のマニュアルページを参照してください。

• ロックファイル。割り当て可能デバイスごとに /etc/security/dev ディレクトリに配置する

• 各割り当て可能デバイスに関連付けられた「デバイス特殊ファイル」の変更後の属性

• 各割り当て可能デバイスのデバイスクリーンスクリプト

device_allocate ファイル、device_maps ファイル、およびロックファイルは、ローカル構成ファイルです。これらのファイルは、ネームサービスデータベースとして管理されません。テープドライブ、フロッピーディスクドライブ、およびプリンタはすべて、特定のマシンに接続されるためです。

デバイス割り当てコマンドの使用方法

この節では、管理者向けのコマンド allocate、deallocate、および list_devices のオプションのいくつかについて説明します。これらのオプションにアクセスできるのは、root またはそれと同等の役割のみです。各コマンドについての詳細は、それぞれのマニュアルページを参照してください。

割り当てエラー状態

割り当て可能デバイスは、デバイス特殊ファイルのモードが 0100 でかつユーザー bin とグループ bin に所有されている場合に、「割り当てエラー状態」になります。割り当てエラー状態になっているデバイスを割り当てたい場合は、そのデバイスの割り当ての強制解除を試みます。-F オプションを指定して deallocate コマンドを実行すると、割り当てが強制的に解除されます。または、allocate -U を使用して、そのデバイスをユーザーに割り当てます。いったんデバイスが割り当てられると、発生したエラーメッセージを調査できます。デバイスの問題が解決したら、強制オプション -F を使用して、デバイスの割り当てエラー状態をクリアする必要があります。

device_maps ファイル

/etc/security/device_maps ファイルを調べると、各割り当て可能デバイスに関連付けられたデバイス名、デバイスの種類、デバイス特殊ファイルを判断できます。 device_maps(4) のマニュアルページを参照してください。デバイスマップは、デバイス割り当てを設定したときに作成されます。device_maps の初期ファイルは、BSM を有効にしたときに、bsmconv によって作成されます。この初期 device_maps ファイルは、あくまでも開始点として使用する必要があります。device_maps は、使用する環境に合わせて拡張およびカスタマイズできます。

device_maps ファイルでは、デバイスごとにデバイス特殊ファイルの割り当てが定義されます。多くの場合、この割り当ては単純ではありません。このファイルによって、各種のプログラムはどのデバイス特殊ファイルがどのデバイスに割り当てられているかを検出できます。たとえば、dminfo コマンドを使用すると、デバイス名、デバイスの種類およびデバイス特殊ファイルを取得して、割り当て可能なデバイスを設定するときに指定できます。dminfo コマンドは、device_maps ファイルを使用してデバイス割り当て情報を報告します。

各デバイスは、次の形式の 1 行のエントリで表されます。

device-name:device-type:device-list

エントリを次の行に続けるには、行末にバックスラッシュ (\) を付けます。コメントも挿入できます。# を付けると、それに続くすべてのテキストは、行末にバックスラッシュ (\) のない次の改行までコメントになります。どのフィールドでも先行ブランクと後続ブランクを使用できます。

次の例では、SCSI テープ st0 とフロッピーディスク fd0 の device_maps ファイルエントリを示します。

fd0:\
	fd:\
	/dev/fd0 /dev/fd0a /dev/fd0b /dev/rfd0 /dev/rfd0a /dev/rfd0b:\
					.
					.
					.
st0:\
	st:\
	/dev/rst0 /dev/rst8 /dev/rst16 /dev/nrst0 /dev/nrst8 /dev/nrst16:\

device_allocate ファイル

device_allocate ファイルを変更して、デバイスを割り当て可能から割り当て不可に変更したり、新しいデバイスを追加したりします。device_allocate ファイルの例を次に示します。

st0;st;;;;/etc/security/lib/st_clean
fd0;fd;;;;/etc/security/lib/fd_clean
sr0;sr;;;;/etc/security/lib/sr_clean
audio;audio;;;*;/etc/security/lib/audio_clean

割り当て可能にするデバイスは、BSM を初期構成するときに定義します。上述の device_allocate ファイルの例のように、デフォルトのデバイスとそれらに定義されている特性をそのまま使用することもできます。システム稼働後の実行中にマシンにデバイスを追加するときには、新しいデバイスを割り当て可能にするかどうかを決定する必要があります。

BSM をインストールしたあとで、デバイスのエントリは device_allocate ファイルを変更できます。割り当てたいデバイスは、使用する前に各マシン上の device_allocate ファイル内で定義する必要があります。現在、カートリッジテープドライブ、フロッピーディスクドライブ、CD-ROM デバイス、およびオーディオチップが、割り当て可能と見なされます。これらのデバイスタイプには、デバイスクリーンスクリプトが用意されています。

Xylogics^TM テープドライブまたは Archive テープドライブでは、SCSI デバイス用に用意されている st_clean スクリプトが使用できます。モデム、端末、グラフィックスタブレットなどの割り当て可能デバイスについては、独自のデバイスクリーンスクリプトを作成する必要があります。このスクリプトは、対応するデバイスタイプのオブジェクト再使用の要件を満たしている必要があります。

device_allocate ファイル内のエントリは、デバイスが割り当て可能であると特に記述されていない限り、そのデバイスが割り当て可能であることを説明しません。上述の device_allocate ファイルの例では、オーディオデバイスエントリの第 5 フィールドにアスタリスク (*) が指定されています。第 5 フィールド内のアスタリスクは、そのデバイスが割り当て可能でないことをシステムに示します。つまり、システム管理者はユーザーにデバイスを使用する前に割り当てたり、あとで割り当てを解除するように要求したりする必要がありません。このフィールドに他の文字列が入っている場合は、デバイスが割り当て可能であることを示します。

各デバイスは、次の形式の 1 行のエントリで表します。

device-name;device-type;reserved;reserved;alloc;device-clean

たとえば、次の行はデバイス名 st0 のエントリを示しています。

st0;st;;;;;/etc/security/lib/st_clean

エントリを次の行に続けるには、行末にバックスラッシュ (\) を付けます。コメントも挿入できます。# を付けると、それに続くすべてのテキストは、行末にバックスラッシュ (\) のない次の改行までコメントになります。どのフィールドでも先行ブランクと後続ブランクを使用できます。

次の表では、device_allocate ファイル内の各フィールドについて詳しく説明します。

デバイスクリーンスクリプト

「デバイスクリーン」スクリプトは、使用可能なすべてのデータを再使用する前に物理デバイスからパージするというセキュリティ要件に対応するものです。デフォルトでは、カートリッジテープドライブ、フロッピーディスクドライブ、CD-ROM デバイス、オーディオデバイスには、必要なデバイスクリーンスクリプトが用意されています。この節では、デバイスクリーンスクリプトが実行する処理について説明します。

オブジェクトの再使用

デバイス割り当てによって、オブジェクト再使用の要件の一部が満たされます。デバイスクリーンスクリプトによって、あるユーザーがデバイスに残したデータは確実にクリアされます。データのクリアは、そのデバイスが別のユーザーによって割り当て可能になる前に実行されます。

テープ用のデバイスクリーンスクリプト

st_clean デバイスクリーンスクリプトでは、3 つのテープデバイスがサポートされます。サポートされるテープデバイスは次のとおりです。

• SCSI 1/4 インチテープ

• Archive 1/4 インチテープ

• オープンリール 1/2 インチテープ

st_cleanスクリプトでは、mt コマンドの rewofflオプションを使用して、デバイスのクリーンアップを制御します。詳細は、mt(1) のマニュアルページを参照してください。このスクリプトは、システムブート中に実行されると、デバイスを照会します。スクリプトは、そのデバイスがオンラインになっているかどうかを調べます。デバイスがオンラインになっていた場合、スクリプトはさらに、そのデバイスにメディアが挿入されているかどうかを調べます。1/4 インチのテープデバイスにメディアが挿入されていた場合、このデバイスは割り当てエラー状態になります。このため、管理者はそのデバイスを手動でクリーンアップする必要があります。

通常のシステム操作中に、allocate または deallocate コマンドを対話型モードで実行すると、メディアを取り出すように求めるプロンプトが表示されます。スクリプトは、メディアがデバイスから取り出されるまで一時停止します。

フロッピーディスクと CD-ROM 用のデバイスクリーンスクリプト

次の表に、フロッピーディスクとCD-ROM 用のデバイスクリーンスクリプトを示します。

スクリプトは、eject コマンドを使用してドライブからメディアを取り出します。詳細については、eject(1) のマニュアルページを参照してください。eject コマンドが失敗すると、デバイスは割り当てエラー状態になります。

オーディオ用のデバイスクリーンスクリプト

オーディオデバイスは、audio-clean スクリプトを使用してクリーンアップします。スクリプトは、AUDIO_DRAIN ioctl システムコールを実行してデバイスをフラッシュしてから、AUDIO_SETINFO ioctl システムコールを実行してデバイス構成をデフォルトにリセットします。また、スクリプトは AUDIOGETREG ioctl システムコールを使用して、オーディオチップレジスタを検出します。レジスタのデフォルト設定にリセットする場合は、AUDIOSETREG ioctl システムコールを使用します。

新しいデバイスクリーンスクリプトの作成

システムに新しく割り当て可能デバイスを追加する場合は、独自のデバイスクリーンスクリプトを作成する必要があります。deallocate コマンドは、デバイスクリーンスクリプトにパラメータを渡します。次のように、パラメータはデバイス名を含む文字列です。詳細は、device_allocate(4)のマニュアルページを参照してください。

st_clean -[I|F|S] device-name

デバイスクリーンスクリプトは、正常終了した場合は 0 を、失敗した場合は 1 以上の値を返します。オプション -I、-F、-S を使用すると、スクリプトに実行モードを判断させることができます。次の表は、オプションの一覧です。

デバイス割り当てメカニズムの機能

この節では、デバイス割り当てメカニズムの機能について例を挙げて説明します。

allocate コマンドは、まず/etc/security/dev ディレクトリ内で、指定されたデバイスのデバイス名が付いたロックファイルがあるかどうかを確認します。ファイルが allocate によって所有されている場合は、ロックファイルの所有権が allocate コマンドを起動したユーザー名に変更されます。

次に、allocate コマンドは、device_allocate ファイル内にそのデバイスのエントリが存在するかどうかを確認します。このコマンドはさらに、デバイスが割り当て可能に設定されているかどうかを、そのエントリ内で確認します。

次の例の最初の一覧は、/etc/security/dev 内に、st0 デバイスを所有者 bin、グループ bin、モード 600 で使用するロックファイルがあることを示しています。2 つ目の一覧は、それに関連するデバイス特殊ファイルが正しく設定されていて、所有者は bin、グループは bin、モードは 000: であることを示します。

untouchable% ls -lg /etc/security/dev/st0
-rw------- 1 bin bin      		      0 Dec 6 15:21 /etc/security/dev/st0
untouchable% ls -lg /devices/sbus@1,f8000000/esp@0,800000
c--------- 1 bin bin		       18,  4 May 12 13:11 st@4,0:
c--------- 1 bin bin	       18, 20 May 12 13:11 st@4,0:b
c--------- 1 bin bin	       18, 28 May 12 13:11 st@4,0:bn
c--------- 1 bin bin	       18, 12 May 12 13:11 st@4,0:c
					 .
					 .
					 .
c--------- 1 bin bin	       18,  0 May 12 13:11 st@4,0:u
c--------- 1 bin bin	       18, 16 May 12 13:11 st@4,0:ub
c--------- 1 bin bin	       18, 24 May 12 13:11 st@4,0:ubn
c--------- 1 bin bin	       18,  8 May 12 13:11 st@4,0:un

次の例では、ユーザー vanessa がデバイス st0 を割り当てます。

untouchable% whoami
vanessa
untouchable% allocate st0

ユーザー vanessa が allocate コマンドを実行してテープ st0 を割り当てると、allocate はまず /etc/security/dev/st0 ファイルが存在することを確認します。ロックファイルが存在しない場合や、allocate 以外のユーザーに所有されている場合は、ユーザー vanessa はデバイスを割り当てることができません。

allocate コマンドは、正しい所有権とアクセス権が設定されたロックファイルを見つけると、次に、device_allocate ファイル内にそのデバイスのエントリが存在するかどうかを確認します。このコマンドはまた、デバイスが割り当て可能として指定されているかどうかを、そのエントリ内で確認します。

この例では、st0 デバイスのデフォルトの device_allocate エントリでは、デバイスが割り当て可能として指定されています。allocate コマンドではこれらの条件がすべて満たされていることを認識し、デバイスが vanessa に割り当てられます。

allocate コマンドは、/dev ディレクトリ内でデバイスに関連付けられたデバイス特殊ファイルの所有権とアクセス権を変更します。st0 デバイスをユーザー vanessa に割り当てるために、それに関連付けられたデバイス特殊ファイルのモードを 600 に変更し、所有者を vanessa に変更します。

また、allocate コマンドは、/etc/security/dev ディレクトリ内でデバイスに関連付けられたロックファイルの所有権も変更します。st0 デバイスをユーザー vanessa に割り当てるために、/etc/security/dev/st0 の所有者を vanessa に変更します。

次の例では、ユーザー vanessa が デバイス名 st0 を指定して allocate コマンドを実行すると、/etc/security/dev/st0 の所有者が vanessa に変更され、デバイス特殊ファイルに関連付けられた所有者も vanessa に変更されます。最後に、ユーザー vanessa にファイルの読み取り権と書き込み権が与えられます。

untouchable% whoami
vanessa
untouchable% allocate st0
untouchable% ls -lg /etc/security/dev/st0
-rw------- 1 vanessa staff 		      0 Dec 6 15:21 /etc/security/dev/st0
untouchable% ls -la /devices/sbus@1,f8000000/esp@0,800000
.
.
.
crw------- 1 vanessa 18,  4 May 12 13:11 st@4,0:
crw------- 1 vanessa 18, 12 May 12 13:11 st@4,0:b
crw------- 1 vanessa 18, 12 May 12 13:11 st@4,0:bn
crw------- 1 vanessa 18, 12 May 12 13:11 st@4,0:c
.
.
.
crw------- 1 vanessa 18,  4 May 12 13:11 st@4,0:u
crw------- 1 vanessa 18, 12 May 12 13:11 st@4,0:ub
crw------- 1 vanessa 18, 12 May 12 13:11 st@4,0:ubn
crw------- 1 vanessa 18, 12 May 12 13:11 st@4,0:un