パート VII Solaris 監査

このパートでは、Solaris 監査サブシステムの設定、管理、および使用方法について説明します。

第 28 章 Solaris 監査 (概要)

Solaris 監査はシステムの使用状況を記録します。監査サービスには、監査データの分析を支援するツールが含まれています。

この章では、Solaris オペレーティングシステム での監査機能について説明します。この章の内容は次のとおりです。

• 「監査とは」

• 「監査の機能」

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

• 「監査の用語と概念」

• 「ゾーンを含むシステムでの監査」

• 「Solaris 10 リリースでの Solaris 監査拡張機能」

計画の提案については、第 29 章Solaris 監査の計画を参照してください。ご使用のシステムで監査を設定する手順については、第 30 章Solaris 監査の管理 (作業)を参照してください。参照情報については、第 31 章Solaris 監査 (参照)を参照してください。

監査とは

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

監査サービスを使うと、次の処理が可能になります。

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

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

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

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

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

• ユーザーが ID を変更するときに発生する特権の拡大使用の検出

システムの構成時に、どの監査レコードのクラスを監視するかを選択します。各ユーザーに行う監査の程度は、細かく調整することもできます。次の図は、Solaris 監査のフローの詳細を示しています。

図 28–1 監査のフロー

監査データは、カーネルに収集された後、プラグインにより適切な場所に配布されます。次に、事後選択ツールで、監査証跡の必要な部分を削減して調査できます。たとえば、個々のユーザーまたは特定グループの監査レコードを確認できます。特定の日に発生した特定の種類のイベントに対するすべてのレコードを調査できます。または、特定の時間帯に生成されたレコードを選択することもできます。

非大域ゾーンをインストールするシステムは、大域ゾーンからと同じようにすべてのゾーンを監査できます。これらのシステムは、非大域ゾーンのさまざまなレコードを収集するように構成することもできます。詳細は、「監査と Solaris ゾーン」を参照してください。

監査の機能

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

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

• ログインとログアウト

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

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

• 特権機能または役割に基づくアクセス制御 (RBAC) の使用

• 識別動作と認証動作

• プロセスまたはユーザーによるアクセス権の変更

• パッケージのインストールなどの管理動作

• サイト固有のアプリケーション

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

• アプリケーション

• 非同期監査イベントの結果

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

関連するイベント情報が取得されると、その情報は監査レコードの書式に変換されます。次に、レコードは監査ファイルに書き込まれます。完全な監査レコードがバイナリ形式で格納されます。Solaris 10 リリースでは、syslog ユーティリティーを使用して、監査レコードを記録することもできます。

バイナリ形式の監査ファイルは、ローカルファイルシステムに格納できます。ファイルは、NFS がマウントされたファイルサーバーにも格納できます。監査ファイルの配置先として、同一システム上の複数のパーティション、異なる複数のシステム上のパーティション、または異なるが接続されているネットワーク上の複数のシステム上のパーティションを選択できます。接続された監査ファイルの集合は、監査トレールと呼ばれます。監査レコードは、発生順に監査ファイルに蓄積されます。各監査レコードには、イベントを識別する情報、イベントの発生元、イベントの時刻、およびその他の関連情報が格納されます。

監査レコードは、syslog ユーティリティーを使用して監視することもできます。これらの監査ログはローカルに格納することができます。あるいは、ログは、UDP プロトコルを使用して遠隔システムに送信することもできます。詳細は、「監査ログ」を参照してください。

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

Solaris 監査を使用して、システムが通常と異なる方法で使用されていないかどうか検査すると、潜在的なセキュリティー侵害を検出できます。また、通常と異なる動作を追跡して、特定のユーザーを突き止めることができるため、セキュリティー侵害を抑止できます。活動を監査されていることをユーザーが知っている場合、悪質な活動を試みる可能性は低くなると考えられます。

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

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

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

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

監査の用語と概念

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

監査イベント

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

たとえば、次のエントリは、exec() システムコールの監査イベントを定義します。

7:AUE_EXEC:exec(2):ps,ex

監査クラス ps または ex の監査を事前選択すると、exec() システムコールは監査トレールに記録されます。

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

• ユーザーに起因するイベント – ユーザーによって起こるイベント。exec() システムコールはユーザーに起因します。そのため、この呼び出しはユーザーに起因するイベントと見なされます。ユーザーに起因するイベントはすべて、同期イベントです。

• ユーザーに起因しないイベント – カーネル割り込みレベルで、またはユーザーが認証される前に発生するイベント。na 監査クラスは、ユーザーに起因しない監査イベントを処理します。たとえば、システムのブートはユーザーに起因しないイベントです。ユーザーに起因しないイベントの多くは、非同期イベントです。ただし、失敗したログインなど、プロセスが関連付けられている場合、ユーザーに起因しないイベントは同期イベントです。

• 同期イベント – システムのプロセスに関連付けられたイベント。システムイベントの大半は同期イベントです。

• 非同期イベント – プロセスに関連付けられていないイベント。そのため、ブロックした後に呼び起こすプロセスはありません。たとえば、システムの初期起動や PROM の開始および終了のイベントは、非同期イベントです。

監査イベントが属するクラスが事前選択されていると、イベントは監査トレールに記録されます。たとえば、監査対象に ps と na 監査クラスを事前選択すると、ほかのイベントとともに exec() システムコールおよびシステムのブート動作が監査トレールに記録されます。

Solaris 監査サービスによって定義される監査イベントのほかに、Sun 以外のアプリケーションも監査イベントを生成できます。32768 から 65535 までの監査イベント番号が Sun 以外のアプリケーションで使用できます。

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

各監査イベントは、1 つまたは複数の「監査クラス」に属しています。監査クラスは、多数の監査イベントが入った便利な入れ物です。監査対象としてクラスを「事前選択」すると、そのクラスのすべてのイベントが監査トレールに記録されるように指定されます。システム上のイベントまたは特定のユーザーによって開始されるイベントに対して事前選択できます。監査サービスの実行開始後、事前選択されたクラスに監査クラスを動的に追加したり削除したりできます。

• システム全体の事前選択 – audit_control ファイルの flags、naflags、および plugin 行にシステム全体の監査デフォルトを指定します。audit_control ファイルについては、「audit_control ファイル」を参照してください。また、audit_control(4) のマニュアルページも参照してください。

• ユーザー固有の事前選択 – audit_user データベースにある個々のユーザーに対するシステム全体の監査デフォルトに追加を指定します。

  監査事前選択マスクにより、ユーザーに対して監査されるイベントのクラスを決定します。ユーザーの監査事前選択マスクとは、システム全体のデフォルトとユーザーに対して指定された監査クラスの組み合わせです。詳細については、「プロセスの監査特性」を参照してください。

  audit_user データベースは、ローカルまたはネームサービスで管理できます。Solaris 管理コンソールは、データベースを管理するグラフィカルユーザーインタフェース (GUI) を備えています。詳細は、audit_user(4) のマニュアルページを参照してください。

• 動的な事前選択 – プロセスまたはセッションに追加したり削除したりする監査クラスを auditconfig コマンドの引数として指定します。詳細は、auditconfig(1M) のマニュアルページを参照してください。

事後選択コマンド auditreduce を使用すると、事前選択された監査レコードからレコードを選択できます。詳細は、「監査トレールの検証」および auditreduce(1M) のマニュアルページを参照してください。

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

0x00100000:ps:process start/stop
0x00000400:na:non-attribute

監査クラスは、32 クラスまで設定できます。クラスには、all および no という 2 つのグローバルクラスが 含まれます。監査クラスについては、audit_class(4) のマニュアルページを参照してください。

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

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

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

header,81,2,login - local,,2003-10-13 11:23:31.050 -07:00
subject,root,root,other,root,other,378,378,0 0 example_system
text,successful login
return,success,0

監査イベントごとに保存される情報の種類は、一連の「監査トークン」によって定義されます。イベントの監査レコードが生成されるたびに、そのイベントに対して定義されたトークンの一部またはすべてが、そのレコードに書き込まれます。どのトークンが記録されるかは、イベントの性質によって決まります。前の例では、各行が監査トークンの名前で始まっています。監査トークンの内容は、名前のあとに続きます。4 つの監査トークンが集まって、login 監査レコードを構成しています。

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

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

監査プラグインモジュールを指定して、事前選択で監査キューに配置したレコードを処理できます。プラグインは、audit_control ファイル内のエントリです。

• audit_binfile.so プラグイン - バイナリ監査ファイルへの監査キューの配信を処理します。audit_control ファイルで、プラグインが指定されておらず dir エントリに値がある場合、監査デーモンがこのプラグインを使用します。

• audit_syslog.so プラグイン - 選択したレコードの監査キューから syslog ログへの配信を処理します。

audit_control ファイルの構文は、audit_control(4) のマニュアルページを参照してください。たとえば、「監査ファイルの構成 (作業マップ)」でタスクを参照します。

プラグインについては、audit_binfile(5)、audit_syslog(5)、および audit_control(4) のマニュアルページを参照してください。

監査ログ

監査レコードは監査ログ内に収集されます。Solaris 監査では、監査ログ用の 2 つの出力モードがあります。「監査ファイル」と呼ばれるログは、バイナリ形式で監査レコードを格納します。システムまたはサイトからの一連の監査ファイルでは、完全な監査レコードが提供されます。完全な監査レコードは「監査トレール」と呼ばれます。

syslog ユーティリティーを使用して、テキストバージョンの監査レコードの概要を収集して格納します。syslog レコードは、完全なレコードではありません。次の例は、login 監査レコードの syslog エントリを示します。

Oct 13  11:24:11 example_system auditd: [ID 6472 audit.notice] \
        login - login ok session 378 by root as root:other

サイトは監査レコードを両方の形式で格納できます。使用中のシステムを設定して、バイナリモード、syslog モード、または両方のモードを使用できます。次の表は、バイナリ形式の監査レコードと syslog 監査レコードの比較を示します。

バイナリ形式のレコードにより、強力なセキュリティーとカバレージが提供されます。バイナリ出力は、共通基準制御アクセス保護プロファイル (CAPP) などのセキュリティー認証の要件を満たします。各レコードは、傍受されないように保護したファイルシステムに書き込まれます。 単一のシステム上で、すべてのバイナリ形式のレコードが、収集され順番に表示されます。バイナリログの GMT タイムスタンプにより、特定の監査トレールのシステムが複数の時間帯にわたって配信されるとき、正確に比較することができます。praudit -x コマンドを使用すると、レコードを XML 形式でブラウザに表示できます。スクリプトを使用して、XML を解析することもできます。

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

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

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

• audit_syslog(5) のマニュアルページ

• audit.log(4) のマニュアルページ

• 「syslog 監査ログの構成方法」

監査証跡の格納

「監査ディレクトリ」はバイナリ形式で監査ファイルを保持します。通常のインストールでは、多くの監査ディレクトリが使用されます。すべての監査ディレクトリの内容は、「監査トレール」で構成されています。監査レコードは、次の順番で監査ディレクトリに格納されます。

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

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

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

ディレクトリは、audit_control ファイルに指定されます。各ディレクトリは、上記の順番で前のディレクトリがいっぱいになるまで使用されません。ディレクトリエントリのリストを含む注釈付きの audit_control ファイルについては、例 30–3 を参照してください。

監査ファイルをデフォルトの監査ルートディレクトリに配置すると、監査証跡を確認する際に役立ちます。auditreduce コマンドは、監査ルートディレクトリを使用して監査証跡内のすべてのファイルを検索します。デフォルトの監査ルートディレクトリは /etc/security/audit です。このディレクトリは、/var/audit に象徴的にリンクされています。/var/audit/hostname /files という名前のディレクトリにある監査ファイルは、auditreduce コマンドで簡単に見つかります。詳細は、「auditreduce コマンド」を参照してください。

監査トレールの検証

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

ゾーンを含むシステムでの監査

ゾーンは、Solaris OS の単一インスタンス内に作成される仮想化オペレーティング環境です。監査サービスは、ゾーン内でのアクティビティーも含め、システム全体を監査します。非大域ゾーンがインストールされたシステムでは、単一の監査サービスを実行してすべてのゾーンを同様に監査することができます。あるいは、大域ゾーンも含め、ゾーンごとに監査サービスを 1 つずつ構成することもできます。

次の条件を満たすサイトでは、単一の監査サービスを実行できます。

• 単一イメージの監査トレールを必要とするサイトである。

• 非大域ゾーンがアプリケーションコンテナとして使用されている。ゾーンが 1 つの管理ドメインの一部になっています。つまり、どの非大域ゾーンにおいても、ネームサービスファイルがカスタマイズされていません。

  システム上のすべてのゾーンが 1 つの管理ドメインに含まれている場合、zonename 監査ポリシーを使えば、複数のゾーンで実行される監査イベントを区別できます。

• 管理者が低い監査オーバーヘッドを望んでいる。大域ゾーン管理者がすべてのゾーンを同様に監査します。また、大域ゾーンの監査デーモンがシステム上のすべてのゾーンを処理します。

次の条件を満たすサイトでは、ゾーンごとに監査サービスを 1 つずつ実行できます。

• 単一イメージの監査トレールを必要としないサイトである。

• 非帯域ゾーンでネームサービスファイルがカスタマイズされている。これらの個々の管理ドメインは通常、サーバーとして機能します。

• 個々のゾーン管理者が、自身が管理するゾーンの監査を制御する必要がある。ゾーンごとの監査では、ゾーン管理者は、自身が管理するゾーンの監査を有効にするか無効にするかを決定できます。

ゾーンごとの監査の利点は、監査トレールをゾーンごとにカスタマイズできることと、ゾーンの監査をゾーン単位で無効化できることです。これらの利点は、管理オーバーヘッドによって相殺される可能性があります。ゾーン管理者はすべての監査構成ファイルをカスタマイズします。各ゾーンでは、独自の監査デーモンが実行され、独自の監査キューや監査ログが用意されます。ゾーンの監査ログファイルの管理を行う必要があります。

Solaris 10 リリースでの Solaris 監査拡張機能

Solaris 9 リリースと比較して、次の機能が Solaris 監査に追加されました。

• Solaris 監査で、syslog ユーティリティーを使用して監査ファイルをテキスト形式で格納できます。詳細は、「監査ログ」を参照してください。syslog ユーティリティーを使用するために audit_control ファイルを設定する方法は、「syslog 監査ログの構成方法」を参照してください。

• praudit コマンドで、新しい出力形式 (XML) が使用できるようになりました。XML は、移植性のある、処理可能な標準の形式です。XML 形式の出力は、ブラウザを使用して表示できるほか、報告用に XML スクリプトへの入力としても使えます。 praudit コマンドの -x オプションについては、「praudit コマンド」を参照してください。

• 一連のデフォルトの監査クラスが整理されました。監査メタクラスによって、より細かい監査クラスをグループ化することができます。クラスのデフォルト集合の一覧については、「監査クラスの定義」を参照してください。

• bsmconv コマンドを使用しても、Stop-A キーの使用が無効化されなくなりました。Stop-A イベントは監査可能です。

• 監査レコードのタイムスタンプは、ISO 8601 形式で報告されます。この標準については、http://www.iso.org を参照してください。

• 3 つの監査ポリシーオプションが追加されました。

  • public – 読み取り専用イベントの公開オブジェクトは監査されなくなりました。公開ファイルを監査しないようにすれば、監査ログの量を大幅に減らすことができます。このため、機密性の高いファイルの読み取りイベントが監視しやすくなります。公開オブジェクトについては、「監査の用語と概念」を参照してください。

  • perzone – perzone ポリシーは広く影響します。別々の監査デーモンが各ゾーンで実行します。デーモンは、ゾーンに固有の監査構成ファイルを使用します。また、監査キューもゾーンに固有です。詳細については、auditd(1M) および auditconfig(1M) のマニュアルページを参照してください。ゾーンの詳細は、「監査と Solaris ゾーン」を参照してください。ポリシーの詳細は、「ゾーン内の監査の計画方法」を参照してください。

  • zonename – 監査イベントが発生した Solaris ゾーンの名前が監査レコードに含まれます。ゾーンの詳細は、「監査と Solaris ゾーン」を参照してください。オプションを使用する場合については、「監査ポリシーの決定」を参照してください。

• 5 つの監査トークンが追加されました。

  • cmd トークンは、コマンドに割り当てられた引数のリストおよび環境変数のリストを記録します。詳細は、 「cmd トークン」を参照してください。

  • path_attr トークンは、path トークンオブジェクトの下にある属性ファイルオブジェクトの処理を記録します。詳細は、「path_attr トークン」を参照してください。

  • privilege トークンは、プロセス上の特権の使用を記録します。詳細は、「privilege トークン」を参照してください。

  • uauth トークンは、コマンドまたは動作による承認の使用を記録します。詳細は、「uauth トークン」を参照してください。

  • zonename トークンは、監査イベントが発生した非大域ゾーンの名前を記録します。zonename 監査ポリシーのオプションにより、zonename トークンが監査レコードに含まれるかどうかを指定します。詳細は、 「zonename トークン」を参照してください。

    概要は、「監査と Solaris ゾーン」を参照してください。ゾーンの詳細は、『Oracle Solaris のシステム管理 (Oracle Solaris コンテナ : 資源管理と Oracle Solaris ゾーン)』のパート II「ゾーン」を参照してください。

第 29 章 Solaris 監査の計画

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

• 「Solaris 監査の計画 (作業マップ)」

• 「監査ポリシーの決定」

• 「監査コストの制御」

• 「効率的な監査」

監査の概要は、第 28 章Solaris 監査 (概要)を参照してください。ご使用のシステムで監査を設定する手順については、第 30 章Solaris 監査の管理 (作業)を参照してください。参照情報については、第 31 章Solaris 監査 (参照)を参照してください。

Solaris 監査の計画 (作業マップ)

次の作業マップは、ディスク容量および記録するイベントの計画に必要とされる主要な作業を示しています。

Solaris 監査の計画 (作業)

監査する動作の種類を適切に選択し、有用な監査情報を収集することが望まれます。監査ファイルはすぐに大きくなり、空き領域がなくなる可能性があるため、十分なディスク容量を割り当てる必要があります。監査対象者と監査対象も注意して計画する必要があります。

ゾーン内の監査の計画方法

システムでゾーンが実装されている場合、監査を構成する方法が 2 つあります。

• すべてのゾーンに対して大域ゾーン内で単一の監査サービスを構成できます。

• ゾーンごとに監査サービスを 1 つずつ構成できます。

トレードオフについては、「ゾーンを含むシステムでの監査」を参照してください。

1. 次のいずれかの方法を選択します。

   • オプション 1 - すべてのゾーンに対して単一の監査サービスを構成します。

     すべてのゾーンを同様に監査する場合、単一イメージの監査トレールが作成される可能性があります。単一イメージの監査トレールが作成されるのは、システム上のすべてのゾーンが 1 つの管理ドメインの一部になっている場合です。その場合、すべてのゾーン内のレコードが同一の設定に基づいて事前選択されるため、監査レコードの比較が容易に行えます。

     この構成では、すべてのゾーンが 1 つのシステムの一部として扱われます。大域ゾーンがシステム上で唯一の監査デーモンを実行して、すべてのゾーンに対して監査ログを収集します。監査構成ファイルのカスタマイズを大域ゾーン内でのみ行ったあと、それらの監査構成ファイルをすべての非大域ゾーンにコピーします。

     1. audit_control ファイルを大域ゾーンからすべての非大域ゾーンにコピーします。

     2. すべてのゾーンで同じ audit_user データベースを使用します。

        audit_user データベースは、ローカルファイルでも、共有されたネームサービスから取得してもかまいません。

     3. ゾーンに基づいて監査レコードを選択できるようにします。

        ゾーン名を監査レコードの一部として含めるには、大域ゾーンで zonename ポリシーを設定します。次に、auditreduce コマンドで、監査証跡からゾーンに基づいて監査イベントを選択できます。例については、auditreduce(1M) のマニュアルページを参照してください。

     単一イメージ監査証跡を計画するには、「監査対象者と監査対象イベントの計画方法」を参照してください。最初の手順から始めます。また、大域ゾーン管理者は、「監査レコード用の記憶領域を計画する方法」の説明に従って記憶領域を確保する必要もあります。

   • オプション 2 - ゾーンごとに監査サービスを 1 つずつ構成できます。

     ゾーンごとにネームサービスファイルが異なる場合や、ゾーン管理者が自身のゾーン内の監査を制御しようとする場合には、ゾーンごとの監査の構成を選択します。

     • ゾーンごとの監査を構成する場合は、大域ゾーンに監査を構成する必要があります。大域ゾーンで perzone 監査ポリシーを設定します。監査ポリシーを設定するには、「ゾーンごとの監査を構成する方法」を参照してください。

       ---

       注 –

       ネームサービスファイルが非大域ゾーンでカスタマイズされ、perzone ポリシーが設定されていない場合は、使用可能なレコードの選択に監査ツールを注意して使用する必要があります。あるゾーン内のユーザー ID は、異なるゾーン内の同じ ID とは異なるユーザーを指している可能性があります。

       ---

     • 発生元のゾーンを追跡できるレコードを生成するには、大域ゾーンで zonename 監査ポリシーを設定します。大域ゾーン内で、zonename を使用して auditreduce コマンドを実行します。次に、zonename ゾーン内で、auditreduce の出力に対して praudit コマンドを実行します。

     • 各ゾーン管理者がゾーンの監査ファイルを構成します。

       非大域ゾーン管理者は、perzone と ahlt 以外のすべてのポリシーオプションを設定できます。

     • 各ゾーン管理者はゾーン内で監査を有効化または無効化できます。

     すべてのゾーン内の監査構成ファイルをカスタマイズするには、「監査対象者と監査対象イベントの計画方法」を参照して、すべてのゾーン用に計画します。最初の手順は省略できます。また、各ゾーン管理者は、「監査レコード用の記憶領域を計画する方法」の説明に従って各ゾーンの記憶領域を確保する必要もあります。

監査レコード用の記憶領域を計画する方法

監査トレールには専用のファイル領域が必要です。監査ファイル用の専用ファイル領域は、使用可能でセキュリティー保護されている必要があります。各システムには、監査ファイル用に構成されたいくつかの監査ディレクトリが必要です。システム上で監査を有効にする前に、最初に監査ディレクトリの構成方法を決定する必要があります。次の手順は、監査トレール記憶領域を計画するときに、解決する必要のある問題を扱っています。

始める前に

非大域ゾーンを実装している場合は、この手順を行う前に 「ゾーン内の監査の計画方法」の手順を完了してください。

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

   サイトのセキュリティー上の必要性を考慮して、監査トレールに使用できるディスク容量を決定します。

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

2. 監査対象のシステムを決定します。

   これらのシステム上で、少なくとも 1 つのローカル監査ディレクトリに 容量を割り当てます。監査ディレクトリを指定する方法は、例 30–3 を参照してください。

3. 監査ファイルを格納するシステムを決定します。

   一次および二次監査ディレクトリを保持するサーバーを決定します。監査ディレクトリ用のディスクの構成例は、「監査ファイルのパーティションの作成方法」を参照してください。

4. 監査ディレクトリの名前をつけます。

   使用するすべての監査ディレクトリの一覧を作成します。命名ガイドラインについては、「監査証跡の格納」および「auditreduce コマンド」を参照してください。

5. システムと監査ディレクトリの対応付けを決定します。

   システムと監査ディレクトリのマッピングを作成します。このマッピングにより、監査作業の負荷を分散します。図については、図 31–1 と図 31–2 を参照してください。

監査対象者と監査対象イベントの計画方法

始める前に

非大域ゾーンを実装している場合は、この手順を行う前に 「ゾーン内の監査の計画方法」の手順を完了してください。

1. 単一システムイメージの監査トレールが必要かどうかを決定します。

   システムが単一の管理ドメイン内にある場合、単一システムイメージの監査トレールを作成できます。各システムが異なるネームサービスを使用している場合は、次の手順から始めます。すべてのシステムごとに計画の手順を完了する必要があります。

   単一システムイメージ監査トレールは監査対象のシステムを 1 つのマシンとして扱います。サイト用の単一システムイメージ監査トレールを作成するには、インストール内のすべてのシステムを次のように構成する必要があります。

   • 同一のネームサービスを使用する。

     監査レコードを解釈するには、auditreduce と praudit の 2 つのコマンドを使用します。監査レコードを正しく解釈するためには、passwd、hosts、および audit_user ファイルの整合性がとれている必要があります。

   • すべてのシステムに対して、同じ audit_warn、audit_event、audit_class、および audit_startup ファイルを使用します。

   • 同一の audit_user データベースを使用します。このデータベースは、NIS や LDAP などのネームサービス内に存在していてもかまいません。

   • audit_control ファイル内の flags、naflags、および plugin エントリを同じにします。

2. 監査ポリシーを決定します。

   auditconfig -lspolicy コマンドを使用して、使用可能なポリシーオプションを表示します。デフォルトでは、cnt ポリシーだけが使用可能になっています。詳細は、手順 8 を参照してください。

   ポリシーオプションの働きについては、「監査ポリシーの決定」を参照してください。監査ポリシーを設定するには、「監査ポリシーを構成する方法」を参照してください。

3. イベントからクラスへのマッピングを変更するかを決定します。

   多くの場合、デフォルトのマッピングをそのまま使用できます。ただし、新しいクラスの追加、クラス定義の変更、あるいは、特定のシステムコールのレコードが役に立たないという判断をした場合は、イベントを別のクラスに移動する必要がある場合もあります。

   例は、「監査イベントの所属先クラスの変更方法」を参照してください。

4. 事前選択する監査クラスを決定します。

   監査クラスの追加やデフォルトクラスの変更は、監査サービスを開始する前に行うことを推奨します。

   audit_control ファイル内の flags、naflags、および plugin エントリの監査クラス値は、すべてのユーザーとプロセスに適用されます。事前選択されたクラスによって、監査クラスが監査されるのは成功の場合か、失敗の場合か、またはその両方の場合かが決定されます。

   監査クラスを事前選択するには、「audit_control ファイルの変更方法」を参照してください。

5. システム全体の事前選択された監査クラスのユーザー例外を決定します。

   一部のユーザーの監査をシステム全体の事前選択された監査クラスと異なる設定にするときは、audit_user データベース内の各ユーザーのエントリを変更します。

   例は、「ユーザーの監査特性の変更方法」を参照してください。

6. 最小空きディスク容量を決定します。

   監査ファイルシステム上のディスク容量が minfree の割合を下回ると、auditd デーモンは次に利用できる監査ディレクトリに切り替えます。デーモンは、弱い制限値を超えたことを示す警告を送信します。

   最小空きディスク容量を設定するには、例 30–4 を参照してください。

7. audit_warn 電子メールのエイリアスの管理方法を決定します。

   audit_warn スクリプトは、監査システムが管理上の注意を要求する状況を通知する必要があるときに実行されます。デフォルトでは、audit_warn スクリプトは、audit_warn のエイリアスに電子メールを送信し、コンソールにメッセージを送信します。

   エイリアスを設定するには、「audit_warn 電子メールエイリアスの構成方法」を参照してください。

8. すべての監査ディレクトリがいっぱいになったときの動作を決定します。

   デフォルトでは、監査トレールのオーバーフローが発生しても、システムは引き続き動作します。システムは破棄された監査レコードを数えますが、イベントを記録しません。セキュリティーをより向上させるためには、cnt ポリシーを無効にして、ahlt ポリシーを有効にします。ahlt ポリシーは、非同期イベントが監査キューに配置できない場合、システムを停止します。

   これらのポリシーオプションについては、「非同期イベントおよび同期イベントの監査ポリシー」を参照してください。これらのポリシーオプションを設定するには、例 30–16 を参照してください。

9. 監査レコードを、バイナリ形式、syslog 形式、または両方の形式のいずれで収集するかを決定します。

   概要は、「監査ログ」を参照してください。

   例は、「syslog 監査ログの構成方法」を参照してください。

監査ポリシーの決定

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

ほとんどの監査ポリシーオプションがデフォルトで無効になっているのは、記憶領域要件とシステム処理要求を最小限に抑えるためです。監査ポリシーオプションを動的に有効または無効にするには、auditconfig コマンドを使用します。監査ポリシーオプションを永続的に有効または無効にするには、audit_startup スクリプトを使用します。

次の表を参照して、1 つまたは複数の監査ポリシーオプションを有効にしたときに発生する追加のオーバーヘッドを考慮しながら、サイトの要件を決定してください。

非同期イベントおよび同期イベントの監査ポリシー

ahlt ポリシーおよび cnt ポリシーは、監査キューがいっぱいで追加のイベントを受け入れられない場合の動作を管理します。ポリシーは独立して関連しています。ポリシーの組み合わせには、それぞれ次のような効果があります。

• -ahlt +cnt は、出荷時のデフォルトのポリシーです。このデフォルトのポリシーにより、イベントが記録できない場合でも、監査対象イベントが処理されます。

  -ahlt ポリシーでは、非同期イベントの監査レコードがカーネル監査キューに配置できない場合、システムがイベントをカウントして処理を続行します。大域ゾーンで、as_dropped カウンタがカウントを記録します。

  +cnt ポリシーでは、同期イベントがカーネル監査キューに到達しても配置できない場合、システムがイベントをカウントして処理を続行します。ゾーンの as_dropped カウンタがカウントを記録します。

  -ahlt +cnt の構成は通常、処理の続行により監査レコードが失われる可能性があっても処理を続行する必要のある場合に使用します。auditstatdrop フィールドは、ゾーンで破棄された監査レコードの数を示します。

• +ahlt -cnt ポリシーでは、イベントがカーネル監査キューに追加できない場合、処理が停止します。

  +ahlt ポリシーでは、非同期イベントの監査レコードがカーネル監査キューに配置できない場合、すべての処理が停止されます。システムはパニック状態になります。非同期イベントは、監査キューには入らず、呼び出しスタックのポインタから復元する必要があります。

  -cnt ポリシーでは、同期イベントがカーネル監査キューに配置できない場合、イベントを配信しようとするスレッドがブロックされます。スレッドは、監査領域が使用可能になるまでスリープキューに配置されます。カウントは保持されません。プログラムは、監査領域が使用可能になるまでハングアップしたように見えることがあります。

  +ahlt -cnt の構成は通常、システムの可用性より監査イベントの記録を優先する場合に使用します。プログラムは、監査領域が使用可能になるまでハングアップしたように見えます。auditstat wblk フィールドは、スレッドがブロックされた回数を示します。

  ただし、非同期イベントが発生した場合、システムがパニック状態になり停止します。監査イベントのカーネルキューは、保存したクラッシュダンプから手動で復元できます。非同期イベントは、監査キューには入らず、呼び出しスタックのポインタから復元する必要があります。

• -ahlt -cnt ポリシーでは、非同期イベントがカーネル監査キューに配置できない場合、イベントがカウントされ処理が続行します。同期イベントがカーネル監査キューに配置できない場合、イベントを配信しようとするスレッドがブロックされます。スレッドは、監査領域が使用可能になるまでスリープキューに配置されます。カウントは保持されません。プログラムは、監査領域が使用可能になるまでハングアップしたように見えることがあります。

  -ahlt -cnt の構成は通常、非同期監査レコードが失われる可能性より、すべての同期監査イベントの記録を優先する場合に使用します。auditstat wblk フィールドは、スレッドがブロックされた回数を示します。

• +ahlt +cnt ポリシーでは、非同期イベントがカーネル監査キューに配置できない場合、システムがパニック状態になります。同期イベントがカーネル監査キューに配置できない場合、システムがイベントをカウントして処理を続行します。

監査コストの制御

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

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

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

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

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

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

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

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

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

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

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

• ユーザー数

• システム数

• 使用量

• 要求される追跡容易性と説明義務の程度

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

• 監査クラスを慎重に事前選択し、生成されるレコードの量を減らします。

  all クラスを指定して完全な監査を行うと、ディスクがすぐにいっぱいになります。プログラムのコンパイルといった単純なタスクによってさえ、巨大な監査ファイルが生成される可能性があります。中程度のサイズのプログラムでも、1 分も経たないうちに数千件の監査レコードが生成される可能性があります。

  たとえば、file_read 監査クラス fr を省くと、監査ボリュームを著しく削減できます。失敗した処理だけの監査を選択すると、監査ボリュームが減ることもあります。たとえば、失敗した file_read 処理 -fr のみを監査すると、すべての file_read イベントの監査よりも生成されるレコードを大幅に少なくすることができます。

• また、監査ファイルを効率的に管理することも重要です。監査レコードが生成されたあとにファイル管理を行うことによって、必要なディスク容量を減らせます。

• 監査クラスを理解します。

  監査を構成する前に、クラスに含まれるイベントの種類を理解しておく必要があります。監査のイベントからクラスへのマッピングを変更すると、監査レコード収集を最適化できます。

• サイトの監査方針を策定します。

  実用的な方法を基に方針を策定します。そのような基準には、サイトで必要な追跡容易性の程度や、管理対象ユーザーの種類などが含まれます。

効率的な監査

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

• 一回にある一定の割合のユーザーのみをランダムに監査します。

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

• 監査データの異常な動作をリアルタイムで監視します。すでに持っている管理および分析ツールを拡張すると、syslog ファイル内の監査レコードを処理できます。

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

  たとえば、次のようにスクリプトを作成します。

  1. すべての監査ファイルサーバー上における監査ファイルの作成を監視します。

  2. tail コマンドを使用して、監査ファイルを処理します。

     tail -0f コマンドから praudit コマンドに出力をパイプすることにより、レコードが生成されたときに監査レコードのストリームを生成できます。詳細は、tail(1) のマニュアルページを参照してください。

  3. このストリームを分析して異常なメッセージの種類やほかの兆候を調べ、または監査担当者に分析を配信します。

     また、このスクリプトを使用して、自動応答を発生させることもできます。

  4. 監査ディレクトリを常時監視して、新しい not_terminated 監査ファイルが発生していないかを調べます。

  5. 監査ファイルに書き込めなくなったときに、未処理の tail プロセスを終了します。

第 30 章 Solaris 監査の管理 (作業)

この章では、監査対象の Solaris システムの設定と管理に役立つ手順を説明します。また、監査トレールの管理方法についても説明します。この章の内容は次のとおりです。

• 「Solaris 監査 (作業マップ)」

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

• 「監査サービスの構成と有効化 (作業マップ)」

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

• 「Solaris 監査のトラブルシューティング (作業マップ)」

監査サービスの概要は、第 28 章Solaris 監査 (概要)を参照してください。計画の提案については、第 29 章Solaris 監査の計画を参照してください。参照情報については、第 31 章Solaris 監査 (参照)を参照してください。

Solaris 監査 (作業マップ)

次の作業マップは、監査の管理に必要な主な作業を示します。作業は順番に並んでいます。

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

次の作業マップは、サイトで監査をカスタマイズするファイルの構成手順の一覧です。ほとんどの作業は省略可能です。

監査ファイルの構成 (手順)

ネットワーク上で監査を有効にする前に、サイトの監査要件の監査構成ファイルをカスタマイズします。また、監査サービスを再起動またはローカルシステムをリブートして、監査サービスが有効になったあとに変更された構成ファイルの読み取りを行うこともできます。ただし、監査構成のカスタマイズに必要な作業は、できる限り監査サービスを開始する前に行います。

ゾーンを実装している場合、大域ゾーンからすべてのゾーンを監査することができます。監査出力内のゾーンを区別するには、zonename ポリシーオプションを指定します。非大域ゾーンを別々に監査するには、大域ゾーン内の perzone ポリシーを指定して、非大域ゾーンの監査構成ファイルをカスタマイズします。概要については、「監査と Solaris ゾーン」を参照してください。計画については、「ゾーン内の監査の計画方法」を参照してください。手順については、「ゾーンでの監査サービスの構成 (手順)」を参照してください。

audit_control ファイルの変更方法

/etc/security/audit_control ファイルを使用して、システム全体の監査を構成します。ファイルは、監査対象のイベント、監査警告の発行時期、および監査ファイルの場所を決定します。

1. Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

   Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

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

   # cp /etc/security/audit_control /etc/security/audit_control.orig

3. サイトの audit_control ファイルを変更します。

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

   keyword:value

   keyword

   行の種類を定義します。種類には、dir、flags、minfree、naflags、および plugin があります。Solaris 10 リリースでは、dir 行および minfree 行は非推奨です。

   キーワードの説明は、次の例を参照してください。

   value

   その種類の行に関連するデータを指定します。

   ---

   注 –

   監査ディレクトリの場所を指定するには、audit_binfile.so プラグインの p_dir 属性を使用します。最小空き容量を指定するには、p_minfree 属性を使用します。

   ---

4. (省略可能) ファイルの構文を確認します。

   # audit -v /etc/security/audit_control syntax ok

例 30–1 すべてのユーザーの監査クラスを事前選択する

audit_control ファイルの flags 行には、監査対象のユーザーに起因するイベントのクラスを定義します。このフラグは、システム上のすべてのユーザーに適用されます。クラスをコンマで区切ります。空白が使用できます。この例では、すべてのユーザーを対象に lo クラスおよび ap クラスのイベントが監査されます。°

## audit_control file
flags:lo,ap
naflags:lo
plugin:name=...

どのイベントがクラスに割り当てられているかを確認するには、audit_event ファイルを参照してください。bsmrecord コマンドを使用することもできます (例 30–27 参照)。

例 30–2 ユーザーに起因しないイベントを事前選択する

この例では、na クラス内のすべてのイベント、およびユーザーに起因しないすべての login イベントが監査対象です。

## audit_control file
flags:lo
naflags:lo,na
plugin:name=...

例 30–3 バイナリ監査データの場所を指定する

audit_binfile.so プラグインの p_dir フラグは、バイナリ監査データに使用する監査ファイルシステムを一覧表示します。この例では、バイナリ監査データ用に 3 つの場所が定義されています。ディレクトリは、1 次ディレクトリから予備のディレクトリの順に一覧表示されます。plugin 行には改行は含まれません。

## audit_control file
##
flags:lo
naflags:lo,na
plugin:name=audit_binfile.so; p_dir=/var/audit/egret.1/files,
/var/audit/egret.2/files,/var/audit

バイナリ監査データを保持するファイルシステムの設定方法は、「監査ファイルのパーティションの作成方法」を参照してください。

例 30–4 警告のための弱い制限値を変更する

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

plugin 行には改行は含まれません。

## audit_control file
#
flags:lo
naflags:lo,na
plugin:name=audit_binfile.so; p_dir=/var/audit/examplehost.1/files,
/var/audit/examplehost.2/files,/var/audit/localhost/files; p_minfree=10

audit_warn エイリアスが警告を受け取ります。エイリアスを設定するには、「audit_warn 電子メールエイリアスの構成方法」を参照してください。

syslog 監査ログの構成方法

監査サービスで、監査キューにある一部またはすべての収集した監査レコードを syslog にコピーできます。次の手順では、バイナリ監査データとテキスト監査データを保存します。収集されたテキスト監査データは、バイナリデータのサブセットです。

始める前に

監査クラスを事前に選択する必要があります。事前に選択される監査クラスは、audit_control ファイルの naflags 行および flags 行で指定します。また、audit_user ファイルの個々のユーザーについてクラスを事前に選択し、auditconfig コマンドで監査クラスを動的に追加できます。

1. Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

   Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

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

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

3. audit_syslog.so プラグインエントリを追加します。

   ## audit_control file flags:lo,ss naflags:lo,na plugin:name=audit_binfile.so;p_dir=/var/audit; p_minfree=20; plugin:name=audit_syslog.so;p_flags=+lo,-ss

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

   plugin:name=name; qsize=max-queued-records;p_*=value

   • name= name – プラグインの名前を一覧表示します。有効な値は、audit_binfile.so および audit_syslog.so です。

   • qsize= max-queued-records – プラグインに送信される監査データについて、キューに入れるレコードの最大数を指定します。この属性は省略可能です。

   • p_*=value – プラグイン固有の属性を指定します。audit_syslog.so プラグインは p_flags を受け入れます。audit_binfile.so プラグインは、p_dir、p_minfree、および p_fsize を受け入れます。p_fsize 属性は、Solaris 10 10/08 で導入されました。

   プラグイン固有の属性の詳細は、audit_binfile(5) の OBJECT ATTRIBUTES の節および audit_syslog(5) のマニュアルページを参照してください。

4. audit.notice エントリを syslog.conf ファイルに追加します。

   エントリは、ログファイルの場所を含みます。

   # cat /etc/syslog.conf … audit.notice /var/adm/auditlog

   テキストログは、バイナリ監査ファイルの格納場所には格納しないでください。バイナリ監査ファイルを読み取る auditreduce コマンドは、監査パーティション内にあるファイルをすべてバイナリ監査ファイルと見なします。

5. ログファイルを作成します。

   # touch /var/adm/auditlog

6. syslog サービスの構成情報を更新します。

   # svcadm refresh system/system-log

7. syslog ログファイルを定期的に保管します。

   監査サービスでは、大量の出力が生成される可能性があります。ログの管理方法については、logadm(1M) のマニュアルページを参照してください。

例 30–5 syslog 出力の監査クラスを指定する

次の例では、syslog ユーティリティーを使用して、事前に選択された監査クラスのサブセットを収集します。

## audit_user file
jdoe:pf

## audit_control file
flags:lo,ss
naflags:lo,na
plugin:name=audit_binfile.so; p_dir=/var/audit/host.1/files,
/var/audit/host.2/files,/var/audit/localhost/files; p_minfree=10
plugin:name=audit_syslog.so; p_flags=-lo,-na,-ss,+pf

flags と naflags エントリにより、システムはログインおよびログアウト、ユーザーに起因しないイベント、およびシステム状態の変更のすべての監査レコードをバイナリ形式で収集します。audit_syslog.so プラグインエントリにより、syslog ユーティリティーは失敗したログイン、ユーザーに起因しない失敗したイベント、および失敗したシステム状態の変更だけを収集します。jdoe ユーザーの場合、バイナリ監査レコードにはプロファイル認識シェルの使用がすべて含まれます。syslog ユーティリティーは、成功したプロファイル認識コマンドを収集します。pf クラスは、例 30–10 で作成されます。

例 30–6 syslog 監査レコードを遠隔システムに配置する

syslog.conf ファイル内の audit.notice エントリを変更して、遠隔システムを指定します。この例では、ローカルシステムの名前は、example1 です。遠隔システムは、remote1 です。

example1 # cat /etc/syslog.conf
…
audit.notice       @remote1

remote1 システム上の syslog.conf ファイル内にある audit.notice エントリはログファイルを指定します。

remote1 # cat /etc/syslog.conf
…
audit.notice       /var/adm/auditlog

例 30–7 audit_control ファイルでプラグインを使用する

audit_control ファイルのフラグなし情報を指定する際には、plugin エントリの使用をお勧めします。この例では、監査フラグの選択の後に、プラグイン情報が一覧表示されています。

## audit_control file
flags:lo,ss
naflags:lo,na
plugin:name=audit_binfile.so;p_minfree=10; p_dir=/var/audit
plugin:name=audit_syslog.so; p_flags=+lo

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

ユーザーごとの定義は、audit_user データベースに格納されます。 これらの定義は、指定されたユーザーに関して、audit_control ファイルで事前に選択されたクラスを変更します。nsswitch.conf ファイルは、ローカルファイルまたはネームサービスデータベースのどちらを使用するかを決定します。ユーザーの最終監査事前定義マスクを計算する方法は、「プロセスの監査特性」を参照してください。

1. Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

   Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

2. (省略可能) audit_user データベースのバックアップコピーを保存します。

   # cp /etc/security/audit_user /etc/security/audit_user.orig

3. audit_user データベースに新しいエントリを追加します。

   ローカルデータベースの場合、各エントリの書式は次のようになります。

   username:always-audit:never-audit

   username

   監査するユーザー名を選択します。

   always-audit

   指定したユーザーについて常に監査する監査クラスの一覧を選択します。

   never-audit

   指定したユーザーについて監査しない監査クラスの一覧を選択します。

   複数のクラスを指定するには、監査クラスをコンマで区切ります。

   audit_user エントリは、ユーザーの次回のログイン時に有効になります。

例 30–8 1 人のユーザーに関して監査するイベントを変更する

この例では、audit_control ファイルは、システム用の事前に選択された監査クラスを含みます。

## audit_control file
…
flags:lo,ss
naflags:lo,na

audit_user ファイルは例外を表示します。ユーザー jdoe がプロファイルシェルを使用すると、監査されます。

## audit_user file
jdoe:pf

jdoe の監査事前選択マスクは、audit_user 設定と audit_control 設定を結合したものです。auditconfig -getaudit コマンドは、jdoe の事前選択マスクを表示します。

# auditconfig -getaudit
audit id = jdoe(1234567)
process preselection mask = ss,pf,lo(0x13000,0x13000)
terminal id (maj,min,host) = 242,511,example1(192.168.160.171)
audit session id = 2138517656

例 30–9 システムではなくユーザーだけを監査する

この例では、システム上での 4 人のログインと役割活動が監査されます。audit_control ファイルは、システム用の監査クラスを事前に選択しません。

## audit_control file
…
flags:
naflags:

audit_user ファイルは、次のように 4 人のユーザー用の 2 つの監査クラスを事前に選択します。

## audit_user file
jdoe:lo,pf
kdoe:lo,pf
pdoe:lo,pf
sdoe:lo,pf

次の audit_control ファイルは、不当な侵入を記録します。audit_user ファイルとの組み合わせにより、この例の最初の audit_control ファイルに比べてシステムをより確実に保護します。

## audit_control file
…
flags:
naflags:lo
plugin:name=...

監査クラスの追加方法

独自の監査クラスを作成すると、サイトで監視する監査イベントだけをそのクラスに入れることができます。1 つのシステムにそのクラスを追加するときは、監査されているすべてのシステムに変更をコピーする必要があります。

1. Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

   Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

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

   # cp /etc/security/audit_class /etc/security/audit_class.orig

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

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

   0xnumber:name:description

   0x

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

   number

   一意の監査クラスマスクを定義します。

   name

   監査クラスの文字の名前を定義します。

   description

   監査クラスの記述名を定義します。

   エントリはファイル内で一意である必要があります。既存の監査クラスのマスクを使用しないでください。

例 30–10 新しい監査クラスを作成する

この例では、監査イベントの小さなセットを保持するクラスを作成します。audit_class ファイルに追加されるエントリは次のとおりです。

0x10000000:pf:profile command

このエントリによって、pf という名前の新しい監査クラスが作成されます。例 30–11 で、この新しい監査クラスにデータを割り当てます。

注意事項

audit_class ファイルをカスタマイズした場合、audit_user に対する変更が新しい監査クラスと一致するようにします。audit_user 内の監査クラスが audit_class データベースのサブセットになっていないと、エラーが発生します。

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

既存の監査クラスのサイズを減らしたり、独自のクラスにイベントを入れたりするために、監査イベントのクラスメンバーシップを変更できます。1 つのシステム上で監査イベントから監査クラスへのマッピングを再構成する場合は、監査されているすべてのシステムに変更をコピーする必要があります。

1. Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

   Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

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

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

3. 特定のイベントがどのクラスに属するかを変更するには、イベントの class-list を変更します。

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

   number:name:description:class-list

   number

   監査イベント ID です。

   name

   監査イベントの名前です。

   description

   通常、監査レコードの作成を発生させるシステムコールまたは実行可能プログラム。

   class-list

   コンマ区切りの監査クラスの一覧です。

例 30–11 既存の監査イベントを新しいクラスにマッピングする

この例では、既存の監査イベントを 例 30–10 で作成した新しいクラスにマッピングします。audit_control ファイルに、バイナリ監査レコードは、pf クラス内のイベントの成功または失敗を書き込みます。syslog 監査ログは、pf クラスのイベントの失敗だけを書き込みます。

# grep pf | /etc/security/audit_class
0x10000000:pf:profile command
# vi /etc/security/audit_event
6180:AUE_prof_cmd:profile command:ua,as,pf
# vi audit_control
...
flags:lo,pf
plugin:name=audit_binfile.so; p_dir=/var/audit; p_minfree=10
plugin:name=audit_syslog.so; p_flags=-lo,-pf

例 30–12 setuid プログラムの使用を監査する

この例では、setuid と setgid プログラムの呼び出しを監視するためにイベントを保持するクラスを作成します。バイナリ監査レコードは、lo クラスおよび na クラスのイベントの成功と失敗、st クラスのイベントの成功を書き込みます。syslog 監査ログは、st クラスのイベントの成功だけを書き込みます。

# vi /etc/security/audit_class
0x00000800:st:setuid class
# vi /etc/security/audit_event
26:AUE_SETGROUPS:setgroups(2):st
27:AUE_SETPGRP:setpgrp(2):st
40:AUE_SETREUID:setreuid(2):st
41:AUE_SETREGID:setregid(2):st
214:AUE_SETEGID:setegid(2):st
215:AUE_SETEUID:seteuid(2):st

# vi audit_control
## audit_control file
flags:lo,+st
naflags:lo,na
plugin:name=audit_binfile.so; p_dir=/var/audit; p_minfree=10
plugin:name=audit_syslog.so; p_flags=-lo,+st

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

次の作業マップは、監査サービスの構成と有効化の手順を示しています。作業は順番に並んでいます。

監査サービスの構成と有効化 (手順)

構成ファイルをサイト用に構成したあと、監査ファイルのディスク容量を設定する必要があります。監査サービスのほかの属性を設定して、サービスを有効にする必要もあります。この節では、構成の設定を変更したときに監査サービスを更新する手順も説明します。

非大域ゾーンがインストールされている場合、監査対象の大域ゾーンと同じようにゾーンを監査することができます。非大域ゾーンを別々に監査する場合は、非大域ゾーンの監査構成ファイルを変更することができます。監査構成ファイルをカスタマイズする方法については、「監査ファイルの構成 (作業マップ)」を参照してください。

監査ファイルのパーティションの作成方法

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

1. Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

   Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

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

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

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

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

   # newfs /dev/rdsk/cwtxdysz

   この例で、 /dev/rdsk/cwt xdysz は、パーティションの 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 サービスを起動し直します。

    このコマンドが、ユーザーが起動した最初の 1 つまたは複数の share コマンドの場合、NFS デーモンが実行されていないことがあります。

    • NFS サービスがオフラインの場合、サービスを有効にします。

      % svcs \*nfs\* disabled Nov_02 svc:/network/nfs/rquota:default offline Nov_02 svc:/network/nfs/server:default # svcadm enable network/nfs/server

    • NFS サービスが実行中の場合、サービスを再起動します。

      % svcs \*nfs\* online Nov_02 svc:/network/nfs/client:default online Nov_02 svc:/network/nfs/server:default # svcadm restart network/nfs/server

    NFS サービスの詳細は、『Solaris のシステム管理 (ネットワークサービス)』の「NFS サービスの設定」を参照してください。永続的なサービスの管理の詳細は、『Solaris のシステム管理 (基本編)』の第 18 章「サービスの管理 (概要)」および smf(5) のマニュアルページを参照してください。

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

監査サービスを実行するすべてのシステムには、利用できるファイルシステムがほかにない場合に使用するローカルファイルシステムが必要です。この例では、ファイルシステムが 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

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

この例では、新しいファイルシステムが、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
# svcadm enable network/nfs/server

例 30–15 ZFS 監査パーティションを作成する

この例では、管理者は、ZFS 監査パーティションの作成後に script コマンドを実行します。コマンドの出力は次のとおりです。

# zpool create auditf mirror c0t4d0 c0t5d0
# zfs create -o mountpoint=/audit auditf/audit
# zfs create auditf/audit/noddy
# zfs create auditf/audit/noddy/files
# zfs create auditf/audit/blinken
# zfs create auditf/audit/blinken/files
# zfs set devices=off auditf/audit
# zfs set exec=off auditf/audit
# zfs set setuid=off auditf/audit
# zfs set sharenfs=on auditf/audit
# share
-               /audit/blinken/files   rw   ""
-               /audit/noddy   rw   ""
-               /audit/blinken   rw   ""
-               /audit/noddy/files   rw   ""
-               /audit   rw   ""
# ^D
script done on Fri Apr 10 10:10:20 2009

次に、遠隔システム remotesys からのマウントを表示します。

# dfshares remotesys
RESOURCE                             SERVER ACCESS    TRANSPORT
remotesys:/audit/blinken/files       remotesys  -         -
remotesys:/audit/noddy               remotesys  -         -
remotesys:/audit/blinken             remotesys  -         -
remotesys:/audit/noddy/files         remotesys  -         -
remotesys:/audit                     remotesys  -         -

最後に、/audit ファイルシステムを /var/audit にマウントします。

# mount remotesys:/audit /var/audit
# ls /var/audit
blinken  noddy 

audit_warn 電子メールエイリアスの構成方法

audit_warn スクリプトは、audit_warn という電子メールエイリアスに対してメールを生成します。有効な電子メールアドレスにこのメールを送信するには、手順 2 で説明するオプションのいずれか 1 つに従います。

1. Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

   Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

2. audit_warn 電子メールエイリアスを構成します。

   次のオプションのいずれかを選択します。

   • オプション 1 – audit_warn スクリプトで、audit_warn 電子メールエイリアスをほかの電子メールアカウントに置き換えます。

     スクリプトの次の行で電子メールエイリアスを変更します。

     ADDRESS=audit_warn # standard alias for audit alerts

   • オプション 2 – audit_warn 電子メールをほかの電子メールアカウントにリダイレクトします。

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

     audit_warn: root

監査ポリシーを構成する方法

監査ポリシーを使用して、ローカルホストの監査レコードの特性を決定します。監査が有効な場合、/etc/security/audit_startup ファイルの内容により、監査ポリシーが決まります。

auditconfig コマンドを使用すると、現在の監査ポリシーオプションを検査および変更できます。また、監査ポリシーの変更内容を固定するために、audit_startup スクリプト内で auditconfig コマンドの監査ポリシーオプションを変更することも可能です。

1. Audit Control プロファイルを含む役割を引き受けるか、スーパーユーザーになります。

   Audit Control プロファイルを含む役割を作成する方法およびユーザーに役割を割り当てる方法については、「RBAC の構成 (作業マップ)」を参照してください。

2. 監査ポリシーを確認します。

   監査を有効にする前に、audit_startup ファイルの内容により、監査ポリシーが決まります。

   #! /bin/sh ... /usr/bin/echo "Starting BSM services." /usr/sbin/auditconfig -setpolicy +cnt Counts rather than drops records /usr/sbin/auditconfig -conf Configures event-class mappings /usr/sbin/auditconfig -aconf Configures nonattributable events

3. 使用可能なポリシーオプションを表示します。

   $ auditconfig -lspolicy

   ---

   注 –

   perzone と ahlt ポリシーオプションは、大域ゾーンでのみ設定できます。

   ---

4. 選択した監査ポリシーオプションを有効または無効にします。

   # auditconfig -setpolicy prefixpolicy

   prefix

   prefix 値 + を指定するとポリシーオプションが有効になります。prefix 値 - を指定するとポリシーオプションが無効になります。

   policy

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

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

   各ポリシーオプションの詳細は、「監査ポリシーの決定」を参照してください。

例 30–16 cnt および ahlt 監査ポリシーオプションを設定する

この例では、cnt ポリシーが無効になり、ahlt ポリシーが有効になります。これらの設定では、監査パーティションがいっぱいで非同期イベントが発生した場合、システムの使用が停止します。同期イベントが発生すると、スレッドを作成したプロセスがハングアップします。これらの設定は、セキュリティーが可用性よりも重要な場合に適しています。

次の audit_startup エントリによって、再起動を行なっても cnt ポリシーオプションが無効で ahlt ポリシーを有効のままになります。

# cat /etc/security/audit_startup
#!/bin/sh
/usr/bin/echo "Starting BSM services."
/usr/sbin/deallocate -Is
/usr/sbin/auditconfig -conf
/usr/sbin/auditconfig -aconf
/usr/sbin/auditconfig -setpolicy -cnt	
/usr/sbin/auditconfig -setpolicy +ahlt

例 30–17 seq 監査ポリシーを一時的に設定する

この例では、auditd デーモンが実行中で、ahlt 監査ポリシーが設定されています。seq 監査ポリシーが現在のポリシーに追加されます。seq ポリシーは、sequence トークンをすべての監査レコードに追加します。監査レコードが破壊されたときやレコードが破棄されているとき、監査サービスのデバッグに役立ちます。

+ 接頭辞により、現在の監査ポリシーを seq に置き換えるのではなく、seq オプションが監査ポリシーに追加されます。auditconfig コマンドにより、ポリシーはコマンドが次に起動するまで、または次のブートまで有効になります。

$ auditconfig -setpolicy +seq
$ auditconfig -getpolicy
audit policies = ahlt,seq	

例 30–18 perzone 監査ポリシーを設定する

この例では、perzone 監査ポリシーが、大域ゾーンの audit_startup スクリプト内で設定されます。ゾーンのブート時に、非大域ゾーンは、そのゾーン内の監査構成設定に関する監査レコードを収集します。

$ cat /etc/security/audit_startup
#!/bin/sh
/usr/bin/echo "Starting BSM services."
/usr/sbin/deallocate -Is
/usr/sbin/auditconfig -conf
/usr/sbin/auditconfig -aconf
/usr/sbin/auditconfig -setpolicy +perzone
/usr/sbin/auditconfig -setpolicy +cnt

例 30–19 監査ポリシーを変更する

この例では、auditd デーモンが実行中で、監査ポリシーが設定されています。auditconfig コマンドは、セッションの間、ahlt と cnt ポリシーを変更します。これらの設定により、監査ファイルシステムがいっぱいになると、監査レコードは破棄されますが、カウントされます。ahlt ポリシーの設定での制限については、手順 3 を参照してください。

$ auditconfig -setpolicy +cnt
$ auditconfig -setpolicy -ahlt
$ auditconfig -getpolicy
audit policies = cnt,seq

変更をaudit_startup ファイルに書き込むと、ポリシーは永続的に有効になります。

$ cat /etc/security/audit_startup
#!/bin/sh
/usr/bin/echo "Starting BSM services."
/usr/sbin/deallocate -Is
/usr/sbin/auditconfig -conf
/usr/sbin/auditconfig -aconf
/usr/sbin/auditconfig -setpolicy +cnt

ahlt ポリシーはデフォルトで無効になっているため、-ahlt オプションをファイル内で指定する必要はありません。この設定は、監査レコードのセキュリティーよりも可用性が重要な場合に適しています。

監査サービスを有効にする方法

この手順では、監査サービスをすべてのゾーンで有効にします。非大域ゾーンで監査デーモンを起動するには、例 30–20 を参照してください。

監査が安全に構成されると、監査が有効化されるまで、システムはシングルユーザーモードになります。マルチユーザーモードで監査を有効にすることもできます。

始める前に

次の作業を完了してから、この手順をスーパーユーザーとして実行してください。

• 計画 – 「Solaris 監査の計画 (作業マップ)」

• 監査ファイルのカスタマイズ – 「監査ファイルの構成 (作業マップ)」

• 監査パーティションの設定 – 「監査ファイルのパーティションの作成方法」

• 監査警告メッセージの設定 – 「audit_warn 電子メールエイリアスの構成方法」

• 監査ポリシーの設定 – 「監査ポリシーを構成する方法」

監査が成功するには、ホスト名変換が正しく機能している必要があります。ネームサービスの hosts データベースが正しく構成され、機能している必要があります。

hosts データベースの構成については、nsswitch.conf(4) および netconfig(4) のマニュアルページを参照してください。詳細は、『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』または『Solaris のシステム管理 (ネーミングとディレクトリサービス : NIS+ 編)』を参照してください。

1. 監査サービスを有効にするスクリプトを実行します。

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

   # cd /etc/security # ./bsmconv This script is used to enable the Basic Security Module (BSM). Shall we continue with the conversion now? [y/n] y bsmconv: INFO: checking startup file. bsmconv: INFO: turning on audit module. bsmconv: INFO: initializing device allocation. The Basic Security Module is ready. If there were any errors, please fix them now. Configure BSM by editing files located in /etc/security. Reboot this system now to come up with BSM enabled.

   スクリプトの働きについては、bsmconv(1M) のマニュアルページを参照してください。

2. システムを再起動します。

   # reboot

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

   スクリプトのもう 1 つの働きは、デバイス割り当てを有効にすることです。デバイス割り当ての設定方法は、「デバイス割り当ての管理 (作業マップ)」を参照してください。

例 30–20 非大域ゾーンで監査を有効にする

次の例では、監査が大域ゾーンで有効になり非大域ゾーンがブートされたあと、大域ゾーン管理者が perzone ポリシーを有効にします。非大域ゾーンのゾーン管理者は、ゾーンの監査ファイルを構成して、ゾーンで監査デーモンを起動します。

zone1# svcadm enable svc:/system/auditd

監査サービスを無効にする方法

ある時点で監査サービスが不要になった場合、この手順は監査が有効になる前のシステム状態にシステムを戻します。非大域ゾーンが監査されている場合は、その監査サービスも無効になります。

このコマンドによって、デバイス割り当ても無効になります。デバイス割り当てを可能にする場合は、このコマンドを実行しないでください。デバイス割り当てを保ったまま監査を無効にする方法については、例 30–21 を参照してください。

1. スーパーユーザーになり、システムをシングルユーザーモードにします。

   % su Password: <Type root password> # init S

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

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

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

   # cd /etc/security # ./bsmunconv

   スクリプトのもう 1 つの働きは、デバイス割り当てを無効にすることです。

   bsmunconv スクリプトの詳細は、bsmconv(1M) のマニュアルページを参照してください。

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

   # init 6

例 30–21 デバイス割り当てを保持したまま監査を無効にする

この例では、監査サービスはレコードの収集を停止しますが、デバイス割り当ては引き続き機能します。audit_user ファイルのすべてのユーザーエントリと同様に、audit_control ファイルの flags、naflags、および plugin エントリからのすべての値が削除されます。

## audit_control file
flags:
naflags:

## audit_user file

auditd デーモンが実行されますが、監査レコードは保持されません。

例 30–22 監査をゾーン単位で無効にする

この例では、監査サービスが無効化された zone1 内で、監査サービスが実行を停止します。デバイス割り当ては引き続き機能します。perzone 監査ポリシーが設定されていない状態で、このコマンドが大域ゾーンで実行されると、大域ゾーンだけでなくすべてのゾーンで監査が無効になります。

zone1 # audit -t

監査サービスの更新方法

この手順では、デーモの実行中に監査構成ファイルを変更した場合に、auditd デーモンを再起動します。

1. Audit Control 権利プロファイルを含む役割を引き受けるか、あるいはスーパーユーザーになります。

   Audit Control 権利プロファイルを含む役割の作成方法およびユーザーに役割を割り当てる方法については、「RBAC の構成 (作業マップ)」を参照してください。

2. 適切なコマンドを選択します。

   • audit_control ファイルの naflags 行を変更する場合は、ユーザーに起因しないイベント用のカーネルマスクを変更します。

     $ /usr/sbin/auditconfig -aconf

     リブートすることもできます。

   • audit_control ファイルのほかの行を変更する場合は、audit_control ファイルを再度読み込みます。

     監査デーモンは、audit_control ファイルからの情報を内部で格納します。新しい情報を使用するには、システムを再起動するか、または変更されたファイルを監査デーモンが読み込むようにします。

     $ /usr/sbin/audit -s

     ---

     注 –

     監査レコードは、各プロセスに関連付けられた監査事前選択マスクに基づいて生成されます。audit -s を実行しても、既存のプロセス内のマスクは変更されません。既存プロセスの事前選択マスクを変更するには、プロセスを再起動する必要があります。リブートすることもできます。

     ---

     audit -s コマンドを使用すると、監査デーモンはディレクトリと最小限の空きの値を audit_control ファイルから再度読み取ります。このコマンドにより、後続のログインにより発生するプロセス用の事前選択マスクの生成が変更されます。

   • 監査デーモンの実行中に audit_event ファイルまたは audit_class ファイルを変更する場合は、監査サービスを再表示します。

     変更したイベントからクラスへのマッピングをシステムに読み込み、マシンを使用する各ユーザーが正しく監査されているかを確認します。

     $ auditconfig -conf $ auditconfig -setumask auid classes

     auid

     ユーザー ID です。

     classes

     事前に選択された監査クラスです。

     例については、「ユーザーの事前選択マスクを変更する方法」を参照してください。

   • 稼動中のシステムで監査ポリシーを変更するには、例 30–17 を参照してください。

例 30–23 監査デーモンを再起動する

この例では、システムをシングルユーザーモードにしたあとで、マルチユーザーモードに戻します。システムがマルチユーザーモードになったとき、変更された構成ファイルがシステムに読み込まれます。

# init S
# init 6

ゾーンでの監査サービスの構成 (手順)

監査サービスは、ゾーン内での監査イベントも含め、システム全体を監査します。非大域ゾーンがインストールされたシステムでは、すべてのゾーンを同様に監査することも、ゾーンごとに監査を制御することもできます。背景情報については、「ゾーンを含むシステムでの監査」を参照してください。計画を立てるには、「ゾーン内の監査の計画方法」を参照してください。

すべてのゾーンの監査を同様に構成する方法

この手順に従えば、すべてのゾーンを同様に監査できます。この方法を使えば、必要とされるコンピュータオーバーヘッドと管理リソースが最小になります。

1. 大域ゾーンの監査を構成します。

   1. 「監査ファイルの構成 (作業マップ)」の作業を行います。

   2. 「監査サービスの構成と有効化 (作業マップ)」の作業を行います。ただし、次の点は例外になります。

      • perzone 監査ポリシーを有効にしないでください。

      • 監査サービスを有効にしないでください。監査サービスの有効化は、非大域ゾーンの監査の構成が完了したあとで行います。

2. 大域ゾーンからすべての非大域ゾーンに、監査構成ファイルをコピーします。

   編集した次のファイルをすべてコピーします。 audit_class、audit_control、audit_event、audit_user。audit_startup と audit_warn はコピーしないでください。編集していないファイルをコピーする必要はありません。

   2 つの選択肢があります。スーパーユーザーとして、ファイルをコピーすることも、ファイルをループバックマウントすることもできます。非大域ゾーンが動作している必要があります。

   • ファイルをコピーします。

     1. 大域ゾーンから、非大域ゾーンの /etc/security ディレクトリを一覧表示します。

        # ls /zone/zonename/etc/security/

     2. ゾーンの /etc/security ディレクトリに監査構成ファイルをコピーします。

        # cp /etc/security/audit-file /zone/zonename/etc/security/audit-file

        その後、ある監査構成ファイルを大域ゾーンで変更した場合には、そのファイルを非大域ゾーンにコピーし直します。

   • 構成ファイルをループバックマウントします。

     1. 大域ゾーンから、非大域ゾーンを停止します。

        # zoneadm -z non-global-zone halt

     2. 大域ゾーンで変更した監査構成ファイルごとに読み取り専用のループバックマウントを 1 つずつ作成します。

        # zonecfg -z non-global-zone add fs set special=/etc/security/audit-file set dir=/etc/security/audit-file set type=lofs add options [ro,nodevices,nosetuid] end exit

     3. 変更を有効にするには、非大域ゾーンをブートします。

        # zoneadm -z non-global-zone boot

        システムをリブートしても構いません。

        その後、ある監査構成ファイルを大域ゾーンで変更した場合には、非大域ゾーンにループバックマウントされたファイルを更新するためにシステムをリブートします。

例 30–24 監査構成ファイルをループバックマウントする

この例では、システム管理者が audit_class、audit_event、audit_control、audit_user、audit_startup、および audit_warn ファイルを変更しました。

audit_startup および audit_warn ファイルは、大域ゾーンでしか読み取られないため、非大域ゾーンでループバックマウントする必要はありません。

このシステム machine1 上で、管理者は 2 つの非大域ゾーン machine1–webserver と machine1–appserver を作成しました。管理者が監査構成ファイルのカスタマイズを完了しました。管理者があとでファイルを変更した場合は、変更を有効にするためにシステムがリブートされます。

# zoneadm -z machine1-webserver halt
# zoneadm -z machine1-appserver halt
# zonecfg -z machine1-webserver 
 add fs
    set special=/etc/security/audit_class
    set dir=/etc/security/audit_class
    set type=lofs
    add options [ro,nodevices,nosetuid]
    end
 add fs
    set special=/etc/security/audit_event
    set dir=/etc/security/audit_event
    set type=lofs
    add options [ro,nodevices,nosetuid]
    end
 add fs
    set special=/etc/security/audit_control
    set dir=/etc/security/audit_control
    set type=lofs
    add options [ro,nodevices,nosetuid]
    end 
add fs
    set special=/etc/security/audit_user
    set dir=/etc/security/audit_user
    set type=lofs
    add options [ro,nodevices,nosetuid]
    end
 exit
# zonecfg -z machine1-appserver 
 add fs
    set special=/etc/security/audit_class
    set dir=/etc/security/audit_class
    set type=lofs
    add options [ro,nodevices,nosetuid]
    end
...
 exit

ゾーンがリブートされると、監査構成ファイルはゾーン内で読み取り専用になります。

ゾーンごとの監査を構成する方法

この手順に従えば、個々のゾーン管理者が自身のゾーン内で監査サービスを制御できます。ポリシーオプションの完全な一覧については、auditconfig(1M) のマニュアルページを参照してください。

1. 大域ゾーンで監査を構成します。ただし、監査サービスは有効にしないでください。

   1. 「監査ファイルの構成 (作業マップ)」の作業を行います。

   2. 「監査サービスの構成と有効化 (作業マップ)」の作業を行います。ただし、次の点は例外になります。

      • perzone 監査ポリシーを追加してください。例については、例 30–18 を参照してください。

      • 監査サービスを有効にしないでください。監査サービスの有効化は、非大域ゾーンの監査の構成が完了したあとで行います。

2. 各非大域ゾーンで監査ファイルを構成します。

   ---

   注 –

   監査を無効にする予定の非大域ゾーンでは、この手順をスキップできます。監査を無効にするには、例 30–25 を参照してください。

   ---

   1. 「監査ファイルの構成 (作業マップ)」の作業を行います。

   2. 「監査サービスの構成と有効化 (作業マップ)」で説明した手順に従います。

   3. システム全体の監査設定は構成しないでください。

      具体的には、非大域ゾーンの audit_startup ファイルに perzone や ahlt ポリシーを追加しないでください。また、非大域ゾーンから bsmconv コマンドを実行しないでください。

   4. 使用するゾーンで監査を有効にします。

      監査の構成後に大域ゾーンをリブートすると、使用するゾーンの監査が自動的に有効になります。

      システムのリブート後に大域ゾーン管理者が perzone 監査ポリシーを有効にした場合、個々のゾーン管理者が監査の有効化を行う必要があります。詳細は、例 30–20 を参照してください。

3. 大域ゾーンで監査サービスを有効にします。

   手順については、「監査サービスを有効にする方法」を参照してください。

例 30–25 非大域ゾーンで監査を無効にする

この例は、大域ゾーンで perzone 監査ポリシーが設定されている場合に正しく機能します。noaudit ゾーンのゾーン管理者が、そのゾーンの監査を無効にします。この管理者は、監査を無効にするつもりであったため、監査構成ファイルを編集していませんでした。

noauditzone # svcadm disable svc:/system/auditd

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

次の作業マップは、監査レコードの選択、分析、および管理の手順を示しています。

監査レコードの管理

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

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

必要な監査データを検索するスクリプトを作成するためには、監査イベント内のトークンの順番を知る必要があります。bsmrecord コマンドは、監査イベントの監査イベント番号、監査クラス、選択マスク、およびレコード書式を表示します。

1. すべての監査イベントレコードを HTML ファイルに出力します。

   -a オプションを指定すると、すべての監査イベントレコードの書式が表示されます。-h オプションを指定すると、ブラウザで表示できる HTML 形式で一覧が出力されます。

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

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

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

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

この例では、login プログラムによって生成されたすべての監査レコードの書式を表示します。login プログラムには、rlogin、telnet、newgrp、Solaris 管理コンソールへの役割ログイン、および Solaris Secure Shell も含まれます。

% bsmrecord -p login
login: logout
  program     various              See login(1)
  event ID    6153                 AUE_logout
…

newgrp
  program     newgrp               See newgrp login
  event ID    6212                 AUE_newgrp_login
…

rlogin
  program     /usr/sbin/login      See login(1) - rlogin
  event ID    6155                 AUE_rlogin
…

SMC: role login
  program     SMC server           See role login
  event ID    6173                 AUE_role_login
…

/usr/lib/ssh/sshd
  program     /usr/lib/ssh/sshd    See login - ssh
  event ID    6172                 AUE_ssh
…

telnet login
  program     /usr/sbin/login      See login(1) - telnet
  event ID    6154                 AUE_telnet
  …

例 30–27 ある監査クラスの監査レコード書式を表示する

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

% bsmrecord -c fd

rmdir
  system call rmdir                See rmdir(2)
  event ID    48                   AUE_RMDIR
  class       fd                   (0x00000020)
      header
      path
      [attribute]
      subject
      [use_of_privilege]
      return

unlink
  system call unlink               See unlink(2)
  event ID    6                    AUE_UNLINK
  …

unlinkat
  system call unlinkat             See openat(2)
  event ID    286                  AUE_UNLINKAT
  …

監査トレールの監査ファイルをマージする方法

すべての監査ディレクトリ内のすべての監査ファイルをマージすると、監査トレール全体の内容を分析できます。auditreduce コマンドを使用すると、入力ファイルのすべてのレコードが 1 つの出力ファイルにマージされます。マージが完了すると、入力ファイルを削除できます。出力ファイルが /etc/security/audit/server-name/files という名前のディレクトリに配置されている場合、完全パスを指定しなくても、auditreduce コマンドは出力ファイルを検索できます。

この手順は、バイナリ監査レコードだけに適用します。

1. Audit Review プロファイルを含む役割を引き受けるか、スーパーユーザーになります。

   System Administrator 役割には、 Audit Review プロファイルが含まれます。Audit Review プロファイルを含む役割を別々に作成することもできます。役割を作成する方法と役割をユーザーに割り当てる方法については、「RBAC の構成 (作業マップ)」を参照してください。

2. マージされた監査ファイルを格納するディレクトリを作成します。

   # mkdir audit-trail-directory

3. ディレクトリへのアクセスを制限します。

   # chmod 700 audit-trail-directory # ls -la audit-trail-directory drwx------ 3 root sys 512 May 12 11:47 . drwxr-xr-x 4 root sys 1024 May 12 12:47 ..

4. 監査トレール内の監査レコードをマージします。

   ディレクトリを audit-trail-directory に変更して、指定した接尾辞を持つファイルに監査レコードをマージします。ローカルシステム上にある audit_control ファイルの dir 行に指定されているすべてのディレクトリがマージされます。

   # cd audit-trail-directory # auditreduce -Uppercase-option -O suffix

   大文字オプションを auditreduce コマンドに指定すると、監査トレール内のファイルを操作できます。次の大文字オプションがあります。

   -A

   監査トレール内のすべてのファイルを選択します。

   -C

   完全ファイルだけを選択します。このオプションは、接尾辞 not_terminated を持つファイルを無視します。

   -M

   特定の接尾辞を持つファイルを選択します。接尾辞はマシン名、またはサマリーファイルに指定した接尾辞です。

   -O

   開始時刻と終了時刻を示す 14 文字のタイムスタンプおよび接尾辞 suffix が付いた監査ファイルを現在のディレクトリに作成します。

例 30–28 サマリーファイルに監査ファイルをコピーする

次の例では、System Administrator 役割 sysadmin は、すべてのファイルを監査トレールからマージされたファイルにコピーします。

$ whoami
sysadmin
$ mkdir /var/audit/audit_summary.dir
$ chmod 700 /var/audit/audit_summary.dir
$ cd /var/audit/audit_summary.dir
$ auditreduce -A -O All
$ ls *All
20030827183214.20030827215318.All

次の例では、完全ファイルだけが監査トレールからマージされたファイルにコピーされます。

$ cd /var/audit/audit_summary.dir
$ auditreduce -C -O Complete
$ ls *Complete
20030827183214.20030827214217.Complete

次の例では、完全ファイルだけが example1 マシンからマージされたファイルにコピーされます。

$ cd /var/audit/audit_summary.dir
$ auditreduce -M example1 -O example1summ
$ ls *summ
20030827183214.20030827214217.example1summ

例 30–29 監査ファイルをサマリーファイルに移動する

auditreduce で - D オプションを指定すると、監査ファイルをほかの場所にコピーしたときにその監査ファイルを削除します。次の例では、あるシステムの完全監査ファイルを、あとで調べるためにサマリーディレクトリにコピーします。

$ cd /var/audit/audit_summary.dir
$ auditreduce -C -O daily_example1 -D example1
$ ls *example1
20030827183214.20030827214217.daily_example1

このコマンドが正常に完了すると、*daily_example1 ファイルへの入力となった example1 システムの監査ファイルが削除されます。

監査トレールから監査イベントを選択する方法

調べる監査レコードをフィルタリングすることができます。フィルタリングオプションの一覧については、auditreduce(1M) のマニュアルページを参照してください。

1. Audit Review プロファイルを含む役割を引き受けるか、スーパーユーザーになります。

   System Administrator 役割には、 Audit Review プロファイルが含まれます。Audit Review プロファイルを含む役割を別々に作成することもできます。役割を作成する方法と役割をユーザーに割り当てる方法については、「RBAC の構成 (作業マップ)」を参照してください。

2. 監査トレールまたは指定した監査ファイルから必要なレコードを選択します。

   auditreduce -lowercase-option argument [optional-file]

   argument

   小文字オプションが必要とする特定の引数。たとえば、-c オプションは、ua などの監査クラスの argument を必要とします。

   -d

   特定の日付のイベントをすべて選択します。argument の日付の形式は、yyyymmdd です。ほかの日付オプション -b と -a は、特定の日付の前と後のイベントを選択します。

   -u

   特定のユーザーのイベント属性をすべて選択します。argument はユーザー名です。もう 1 つのユーザーオプション -e は、実効ユーザー ID のイベント属性をすべて選択します。

   -c

   事前選択された監査クラス内のイベントをすべて選択します。argument は監査クラス名です。

   -m

   特定の監査イベントのインスタンスをすべて選択します。argument は監査イベントです。

   optional-file

   監査ファイルの名前です。

例 30–30 監査ファイルを結合して削減する

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

# cd /var/audit/audit_summary.dir
# auditreduce -O lo.summary -b 20030827 -c lo; compress *lo.summary

例 30–31 na 監査レコードをサマリーファイルにコピーする

この例では、監査トレール内の、ユーザーに起因しない監査イベントのすべてのレコードが、1 つのファイルに収集されます。

$ whoami
sysadmin
$ cd /var/audit/audit_summary.dir
$ auditreduce -c na -O nasumm
$ ls *nasumm
20030827183214.20030827215318.nasumm

マージされた nasumm 監査ファイルは、na レコードの開始時刻と終了時刻のタイムスタンプが記録されます。

例 30–32 指定した監査ファイル内で監査イベントを検索する

監査ファイルを手動で選択して、指定された一連のファイルだけを検索できます。たとえば、前の例の *nasumm ファイルをさらに処理して、システムブートイベントを検索できます。これを行うには、auditreduce コマンドの最後の引数にファイル名を指定します。

$ auditreduce -m 113 -O systemboot 20030827183214.20030827215318.nasumm
20030827183214.20030827183214.systemboot

20030827183214.20030827183214.systemboot ファイルは、システムブート監査イベントだけを含みます。

例 30–33 ユーザー監査レコードをサマリーファイルにコピーする

この例では、特定のユーザー名を含む監査トレール内のレコードがマージされます。-e オプションを指定すると実効ユーザーが検索されます。-u オプションを指定すると監査ユーザーが検索されます。

$ cd /var/audit/audit_summary.dir
$ auditreduce -e tamiko -O tamiko

このファイル内の特定のイベントを検索できます。次の例では、2003 年 9 月 7 日にユーザーがログインした時間が確認されます。接尾辞にユーザーの名前が付いたファイルだけが確認されます。日付の短い形式は、yyyymmdd です。

# auditreduce -M tamiko -O tamikolo -d 20030907 -u tamiko -c lo

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

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

# auditreduce -c lo -d 20030827 -O /var/audit/audit_summary.dir/logins
# ls /var/audit/audit_summary.dir/*logins
/var/audit/audit_summary.dir/20030827183936.20030827232326.logins

バイナリ監査ファイルの内容を表示する方法

praudit コマンドを使用すると、バイナリ監査ファイルの内容を表示できます。auditreduce コマンドから出力をパイプしたり、特定の監査ファイルを読み取ったりできます。さらに処理する場合に -x オプションが役立ちます。

1. Audit Review プロファイルを含む役割を引き受けるか、スーパーユーザーになります。

   System Administrator 役割には、 Audit Review プロファイルが含まれます。Audit Review プロファイルを含む役割を別々に作成することもできます。役割を作成する方法と役割をユーザーに割り当てる方法については、「RBAC の構成 (作業マップ)」を参照してください。

2. 次の praudit コマンドの 1 つを使用して、目的に沿った出力を生成します。

   次の例は、同じ監査イベントからの praudit 出力を表示します。監査ポリシーは、sequence トークンと trailer トークンを含むように設定されています。

   • praudit -s コマンドを使用して、短い書式で 1 行につき 1 トークンの監査レコードを表示します。-l オプションを指定して、1 行に各レコードを配置します。

     $ auditreduce -c lo | praudit -s header,101,2,AUE_rlogin,,example1,2003-10-13 11:23:31.050 -07:00 subject,jdoe,jdoe,staff,jdoe,staff,749,749,195 1234 server1 text,successful login return,success,0 sequence,1298

   • praudit -r コマンドを使用して、監査レコードの raw 書式で 1 行につき 1 トークンの監査レコードを表示します。-l オプションを指定して、1 行に各レコードを配置します。

     $ auditreduce -c lo | praudit -r 21,101,2,6155,0x0000,192.168.60.83,1062021202,64408258 36,2026700,2026700,10,2026700,10,749,749,195 1234 192.168.60.17 40,successful login 39,0,0 47,1298

   • praudit -x コマンドを使用して、XML 形式で 1 行につき 1 トークンの監査レコードを表示します。-l オプションを指定して、1 レコードの XML 出力を 1 行に配置します。

     $ auditreduce -c lo | praudit -x <record version="2" event="login - rlogin" host="example1" time="Wed Aug 27 14:53:22 PDT 2003" msec="64"> <subject audit-uid="jdoe" uid="jdoe" gid="staff" ruid="jdoe" rgid="staff" pid="749" sid="749" tid="195 1234 server1"/> <text>successful login</text> <return errval="success" retval="0"/> <sequence seq-num="1298"/> </record>

例 30–35 監査トレール全体を印刷する

lp コマンドにパイプすると、監査トレール全体の出力がプリンタに送られます。プリンタへのアクセスを制限してください。

# auditreduce | praudit | lp -d example.protected.printer

例 30–36 特定の監査ファイルを表示する

この例では、サマリーログインファイルを端末ウィンドウで調べます。

# cd /var/audit/audit_summary.dir/logins
# praudit 20030827183936.20030827232326.logins | more

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

この例では、監査レコードを XML 形式に変換します。

# praudit -x 20030827183214.20030827215318.logins > 20030827.logins.xml

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

注意事項

次のようなメッセージは、praudit コマンドを使用するために必要な権限がないことを示しています。

praudit: Can't assign 20090408164827.20090408171614.example1 to stdin.

not_terminated 監査ファイルを整理する方法

監査ファイルが開いている状態で監査デーモンが終了することがあります。また、サーバーがアクセス不能になって、強制的に別のサーバーに切り替わってしまうことがあります。このような場合、その監査ファイルは監査レコードとして使用されなくなりますが、監査ファイルの終了タイムスタンプとして文字列 not_terminated が付いたままになります。auditreduce -O コマンドを使用して、ファイルに正しいタイムスタンプを付けます。

1. 監査ファイル上の not_terminated 文字列が付いたファイルを作成順に一覧表示します。

   # ls -R1t audit-directory*/files/* | grep not_terminated

   -R

   サブディレクトリ内のファイルを一覧表示します。

   -t

   最新のファイルからもっとも古いファイルの順で一覧表示します。

   -1

   1 列でファイルを一覧表示します。

2. 古い not_terminated ファイルを整理します。

   古いファイルの名前を auditreduce -O コマンドに指定します。

   # auditreduce -O system-name old-not-terminated-file

3. 古い not_terminated ファイルを削除します。

   # rm system-name old-not-terminated-file

例 30–38 閉じた not_terminated 監査ファイルを整理する

次の例では、not_terminated ファイルを検索し、名前を変更して、元のファイルを削除します。

ls -R1t */files/* | grep not_terminated
…/egret.1/20030908162220.not_terminated.egret
…/egret.1/20030827215359.not_terminated.egret
# cd */files/egret.1
# auditreduce -O egret 20030908162220.not_terminated.egret
# ls -1t
20030908162220.not_terminated.egret Current audit file
20030827230920.20030830000909.egret Input (old) audit file
20030827215359.not_terminated.egret
# rm 20030827215359.not_terminated.egret
# ls -1t
20030908162220.not_terminated.egret Current audit file
20030827230920.20030830000909.egret Cleaned up audit file

新しいファイルの開始タイムスタンプは、not_terminated ファイル内にある最初の監査イベントの時間を反映します。終了タイムスタンプは、そのファイル内にある最後の監査ファイルの時間を反映します。

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

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

1. 監査ファイルを定期的に保存するスケジュールを設定します。

   ファイルをオフラインのメディアにバックアップして、監査ファイルを保管します。これらのファイルを保存ファイルシステムに移動することもできます。

   syslog ユーティリティーを使用してテキスト監査ログを収集している場合、テキストログを保管します。詳細は、logadm(1M) のマニュアルページを参照してください。

2. スケジュールを設定して、保管された監査ファイルを監査ファイルシステムから削除します。

3. 補助情報を保存し保管します。

   監査レコードの解釈に必要な情報を、監査トレールとともに格納します。

4. 保管した監査ファイルの記録をとります。

5. 保存したメディアを適切な方法で保管します。

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

   監査トレールからサマリーファイルを抽出するには、auditreduce コマンドのオプションを使用します。サマリーファイルには、指定された種類の監査イベントのレコードだけが含まれます。サマリーファイルを抽出するには、例 30–30 および例 30–34 を参照してください。

Solaris 監査のトラブルシューティング (作業)

この節では、さまざまな Solaris 監査のエラーメッセージ、設定、ほかのツールによる監査について説明します。ここで示す手順は、使用中のシステムで必要な監査イベントを記録する際に役立ちます。

Solaris 監査のトラブルシューティング (作業マップ)

次の作業マップでは、Solaris 監査のトラブルシューティングの手順を示します。

Solaris 監査が実行中であるかどうかを判定する方法

監査が有効になっているはずだが、1 次監査ディレクトリに監査レコードがない場合、次の手順を試してください。

始める前に

ネームサービスの hosts データベースが正しく構成され、機能しています。ネームサービスの問題をデバッグする場合は、次の情報を参照してください。

• nsswitch.conf(4) のマニュアルページ

• 『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』

• 『Solaris のシステム管理 (ネーミングとディレクトリサービス : NIS+ 編)』

1. 監査が実行中であるかどうかを判定します。

   • c2audit カーネルモジュールがロード済みであることを確認します。

     # modinfo | grep c2audit

     リストがない場合、監査が実行中でないことを示しています。次のリストは、監査が実行中であることを示しています。

     40 132ce90 14230 186 1 c2audit (C2 system call)

   • 監査デーモンが動作していることを確認します。

     auditd サービスの状態を確認します。次のリストは、監査が実行中でないことを示しています。

     # svcs -x auditd svc:/system/auditd:default (Solaris audit daemon) State: disabled since Fri Aug 14 19:02:35 2009 Reason: Disabled by an administrator. See: http://sun.com/msg/SMF-8000-05 See: auditd(1M) See: audit(1M) Impact: This service is not running.

     次のリストは、監査サービスが実行中であることを示しています。

     # svcs auditd STATE STIME FMRI online 10:10:10 svc:/system/auditd:default

   • 現在の監査の状況を確認します。

     次のリストは、監査が実行中でないことを示しています。

     # auditconfig -getcond auditconfig: auditon(2) failed. auditconfig: error = Operation not supported(48)

     次のリストは、監査が実行中であることを示しています。

     # auditconfig -getcond audit condition = auditing

   監査サービスが実行中でない場合、有効にします。手順については、「監査サービスを有効にする方法」を参照してください。

2. audit_control ファイルの構文を確認します。

   # audit -v /etc/security/audit_control audit: audit_control must have either a valid "dir:" entry or a valid "plugin:" entry with "p_dir:" specified.

   エラーを修正します。syntax ok というメッセージは、ファイルの構文が正しいことを示しています。

3. audit_control ファイルについて、flags キーワードおよび naflags キーワードの値が有効であることを確認します。

   # grep flags /etc/security/audit_control flags:lo naflags:na,lp

   audit_control ファイルに無効な値が含まれている場合、有効な値を指定します。前述の例で、lp は無効なクラスです。

4. audit_user ファイルについて、すべてのユーザーの値が有効であることを確認します。

   # tail audit_user ... # User Level Audit User File # # File Format # # username:always:never # root:lo:no admin:lp:no

   audit_user ファイルに無効な値が含まれている場合、有効な値を指定します。前述の例で、lp は無効なクラスです。

5. カスタマイズ監査クラスを作成した場合、そのクラスにイベントが割り当て済みであることを確認します。

   たとえば、次の audit_control ファイルには、Oracle Solaris ソフトウェアが配信していないクラスが含まれています。

   # grep flags /etc/security/audit_control flags:lo,pf naflags:na,lo

   pf クラスの作成については、「監査クラスの追加方法」を参照してください。

   1. クラスが audit_class ファイルで定義されていることを確認します。

      監査クラスマスクは一意である必要があります。

      # grep pf /etc/security/audit_class 0x10000000:pf:profile command

      クラスが定義されていない場合、定義します。そうでない場合、audit_control ファイルおよび audit_user ファイルからクラスを削除します。

   2. イベントがクラスに割り当てられていることを確認します。

      # grep pf /etc/security/audit_event 6180:AUE_prof_cmd:profile command:ua,as,pf

      イベントがクラスに割り当てられていない場合、適切なイベントをこのクラスに割り当てます。

6. 前述の手順で問題が見つからなかった場合、システムログファイル /var/adm/messages および /var/log/syslog を確認します。

   1. 問題を検出して修正します。

   2. 次に、監査サービスが実行中である場合、再起動します。

      # audit -s

   3. 監査サービスが実行中でない場合、有効にします。

      手順については、「監査サービスを有効にする方法」を参照してください。

生成される監査レコードの量を削減する方法

使用しているシステムで監査する必要のあるイベントを決定した後、次に示す方法で管理可能な監査ファイルを作成します。

1. デフォルトの監査ポリシーを使用します。

   具体的には、監査証跡へのイベントと監査トークンの追加を回避します。次のポリシーは、監査証跡のサイズに影響します。

   • arge ポリシー – 環境変数を exec 監査イベントに追加します。

   • argv ポリシー – コマンドパラメータを exec 監査イベントに追加します。

   • public ポリシー – ファイルイベントを監査対象とする場合、公開ファイルで監査可能なイベントが発生するたびに、監査証跡にイベントを追加します。ファイルクラスには、fa、fc、fd、fm、fr、fw、cl などがあります。公開ファイルの定義については、「監査の用語と概念」を参照してください。

   • path ポリシー – path トークンを、省略可能な path トークンを含む監査イベントに追加します。

   • group ポリシー – group トークンを、省略可能な newgroups トークンを含む監査イベントに追加します。

   • seq ポリシー – sequence トークンをすべての監査イベントに追加します。

   • trail ポリシー – trailer トークンをすべての監査イベントに追加します。

   • windata_down ポリシー – Trusted Extensions で構成されたシステムで、ラベル付きウィンドウの情報がダウングレードされるときにイベントを追加します。

   • windata_up ポリシー – Trusted Extensions で構成されたシステムで、ラベル付きウィンドウの情報がアップグレードされるときにイベントを追加します。

   • zonename ポリシー – ゾーン名をすべての監査イベントに追加します。大域ゾーンが唯一の構成ゾーンである場合、zone, global をすべての監査イベントに追加します。

   次の監査レコードは、ls コマンドの使用を示しています。ex クラスが監査対象で、デフォルトのポリシーが使用されています。

   header,375,2,execve(2),,mach1,2009-08-06 11:19:57.388 -07:00 path,/usr/bin/ls subject,jdoe,root,root,root,root,1401,737,0 0 mach1 return,success,0

   すべてのポリシーがオンの場合、同じレコードが次のようになります。

   header,375,2,execve(2),,mach1,2009-08-06 11:19:57.388 -07:00 path,/usr/bin/ls attribute,100555,root,bin,136,432,0 exec_args,1,ls exec_env,9,HOME=/,HZ=,LANG=C,LOGNAME=root,MAIL=/var/mail/root,PATH=/u sr/sbin:/usr/bin,SHELL=/sbin/sh,TERM=xterm,TZ=US/Pacific path,/lib/ld.so.1 attribute,100755,root,bin,136,4289,0 subject,jdoe,root,root,root,root,1401,737,0 0 mach1 group,root,other,bin,sys,adm,uucp,mail,tty,lp,nuucp,daemon return,success,0 zone,global sequence,313540 trailer,375

2. audit_syslog.so プラグインを使用して、一部の監査イベントを syslog に送信します。

   この方法は、syslog ログに送信する監査イベントのバイナリレコードを保持する必要がない場合にのみ有効です。auditreduce コマンドを使用すると、レコードからバイナリファイルを取り除くことができるため、バイナリファイルのサイズが削減されます。

3. 特定のユーザーおよび役割について、監査イベントに audit_user ファイルを使用します。

   audit_control ファイルの監査クラスの数を減らすことにより、すべてのユーザーの監査の量を削減します。audit_user ファイルで、特定のユーザーおよび役割の監査クラスを追加します。

4. 独自のカスタマイズ監査クラスを作成します。

   使用しているシステムで監査クラスを作成できます。このクラスに、監視が必要な監査イベントをすべて指定します。手順については、「監査クラスの追加方法」を参照してください。

   ---

   注 –

   既存の監査クラスの割り当てを変更する場合、新しいバージョンの Solaris OS にアップグレードするときに変更内容が失われることがあります。インストールログを慎重に確認してください。

   ---

ユーザーによるすべてのコマンドを監査する方法

サイトのセキュリティーポリシーの一環として、root ユーザーまたは管理役割により実行されるすべてのコマンドについて監査レコードが必要になることがあります。また、サイトによっては、ユーザーが実行するすべてのコマンドの監査レコードを必要とする場合もあります。

1. lo クラスおよび ex クラスを監査します。

   ex クラスは、exec() 関数および execve() 関数のすべての呼び出しを監査します。lo クラスは、ログイン、ログアウト、および画面ロックを監査します。次の出力は、ex クラスおよび lo クラスのすべてのイベントを一覧表示します。

   7:AUE_EXEC:exec(2):ps,ex 23:AUE_EXECVE:execve(2):ps,ex ... 6152:AUE_login:login - local:lo 6153:AUE_logout:logout:lo 6154:AUE_telnet:login - telnet:lo 6155:AUE_rlogin:login - rlogin:lo 6158:AUE_rshd:rsh access:lo 6159:AUE_su:su:lo 6162:AUE_rexecd:rexecd:lo 6163:AUE_passwd:passwd:lo 6164:AUE_rexd:rexd:lo 6165:AUE_ftpd:ftp access:lo 6171:AUE_ftpd_logout:ftp logout:lo 6172:AUE_ssh:login - ssh:lo 6173:AUE_role_login:role login:lo 6212:AUE_newgrp_login:newgrp login:lo 6213:AUE_admin_authenticate:admin login:lo 6221:AUE_screenlock:screenlock - lock:lo 6222:AUE_screenunlock:screenlock - unlock:lo 6227:AUE_zlogin:login - zlogin:lo

   • 管理者についてこれらのクラスを監査するには、audit_user ファイルを変更します。

     次の例では、サイトが sysadm、auditadm、および netadm という 3 つの役割を作成しています。これらの役割と root アカウントは、exec クラスおよび lo クラスについて監査されます。

     ## audit_user file root:lo,ex:no sysadm:lo,ex:no auditadm:lo,ex:no netadm:lo,ex:no

   • ユーザーに起因しないイベントについて lo クラスを監査するには、audit_control ファイルを変更します。

     ## audit_control file ... naflags:lo ...

   • すべてのユーザーについてこれらのクラスを監視するには、audit_control ファイルを変更します。

     ## audit_control file flags:lo,ex naflags:lo ...

     出力は次のようになります。

     header,375,2,execve(2),,mach1,2009-08-06 11:19:57.388 -07:00 path,/usr/bin/ls subject,jdoe,root,root,root,root,1401,737,0 0 mach1 return,success,0

2. コマンドの引数を記録するには、argv ポリシーを設定します。

   ## audit_startup script ... auditconfig -setpolicy +argv ...

   exec_args トークンは、コマンド引数を記録します。

   header,375,2,execve(2),,mach1,2009-08-06 11:19:57.388 -07:00 path,/usr/bin/ls exec_args,1,ls subject,jdoe,root,root,root,root,1401,737,0 0 mach1 return,success,0

3. コマンドの実行環境を記録するには、arge ポリシーを設定します。

   ## audit_startup script ... auditconfig -setpolicy +arge ...

   exec_env トークンは、コマンド環境を記録します。

   header,375,2,execve(2),,mach1,2009-08-06 11:19:57.388 -07:00 path,/usr/bin/ls exec_env,9,HOME=/,HZ=,LANG=C,LOGNAME=root,MAIL=/var/mail/root, PATH=/usr/sbin:/usr/bin,SHELL=/sbin/sh,TERM=xterm,TZ=US/Pacific subject,jdoe,root,root,root,root,1401,737,0 0 mach1 return,success,0

4. 引数とコマンド環境を記録するには、両方のポリシーを設定します。

   ## audit_startup script ... auditconfig -setpolicy +argv auditconfig -setpolicy +arge ...

   出力は次のようになります。

   header,375,2,execve(2),,mach1,2009-08-06 11:19:57.388 -07:00 path,/usr/bin/ls exec_args,1,ls exec_env,9,HOME=/,HZ=,LANG=C,LOGNAME=root,MAIL=/var/mail/root, PATH=/usr/sbin:/usr/bin,SHELL=/sbin/sh,TERM=xterm,TZ=US/Pacific subject,jdoe,root,root,root,root,1401,737,0 0 mach1 return,success,0

特定のファイルに対する変更の監査レコードを検索する方法

/etc/passwd や /etc/default ディレクトリ内のファイルなど、限られた数のファイルに対するファイル書き込みを記録する場合、auditreduce コマンドを使用してファイルを見つけます。

1. fw クラスを監査します。

   audit_user ファイルにクラスを追加すると、audit_control ファイルにクラスを追加する場合よりも、生成されるレコードが少なくなります。

   • fw クラスを audit_user ファイルに追加します。

     ## audit_user file root:fw:no sysadm:fw:no auditadm:fw:no netadm:fw:no

   • fw クラスを audit_control ファイルに追加します。

     ## audit_control file flags:lo,fw ...

2. 特定のファイルの監査レコードを検索するには、auditreduce コマンドを使用します。

   # /usr/sbin/auditreduce -o file=/etc/passwd,/etc/default -O filechg

   auditreduce コマンドは、file 引数のすべてのインスタンスについて監査証跡を検索します。このコマンドにより、接尾辞 filechg を持つバイナリファイルが作成されます。このファイルには、必要なファイルのパス名を含むすべてのレコードが含まれています。-o file=pathname オプションの構文については、auditreduce(1M) のマニュアルページを参照してください。

3. filechg ファイルを読み取るには、praudit コマンドを使用します。

   # /usr/sbin/praudit *filechg

ユーザーの事前選択マスクを変更する方法

audit_control ファイルまたは ファイルを変更する場合、すでにログインしているユーザーの事前選択マスクは変更されません。事前選択マスクを強制的に変更する必要があります。

始める前に

監査を有効にしてユーザーがログインしてから、audit_control ファイルの flags または naflags の値を変更しました。新しく選択された監査クラスの監査対象とするために、すでにログインしているユーザーが必要です。

1. すでにログインしているユーザーの事前選択マスクを更新します。

   2 つの選択肢があります。既存のセッションを終了するか、auditconfig コマンドを使用してユーザーの事前選択マスクを更新します。

   • ユーザーの既存のセッションを終了します。

     ユーザーがログアウトしてふたたびログインするか、管理者がアクティブなセッションを手動で終了できます。新しいセッションでは、新しい事前選択マスクが継承されます。ただし、ユーザーの終了が実用的でない場合もあります。

   • 各ユーザーの事前選択マスクを動的に変更します。

     audit_control ファイルの flags 属性が lo から lo,ex に変更されたものとします。

     1. ユーザーの監査 ID および監査セッション ID を決定します。

        まず、すべての通常ユーザーを検索します。次の例では、管理者が、root、daemon、または lp により所有されていないすべてのプロセスを検索します。

        # /usr/bin/pgrep -v -u root,daemon,lp | more .. 3941 3948 3949 10640 ...

        次に、ユーザーのプロセスの 1 つを使用して、ユーザーの監査 ID を検索します。

        # auditconfig -getpinfo 3941 audit id = jdoe(1002) process preselection mask = lo(0x1000,0x1000) terminal id (maj,min,host) = 9426,65559,mach1(192.168.123.234) audit session id = 713

        ユーザーの事前選択マスクには、lo クラスが含まれますが、新しく追加された ex クラスは含まれません。

     ユーザーの監査 ID は 1002 です。ユーザーの監査セッション ID は 713 です。

2. ユーザーの事前選択マスクを変更します。

   次の 2 つの方法のいずれかを使用します。

   • ユーザーの監査セッション ID を使用して、ユーザーの事前選択マスクを変更します。

     # /usr/sbin/auditconfig -setsmask lo,ex 713

   • ユーザーの監査 ID を使用して、ユーザーの事前選択マスクを変更します。

     # /usr/sbin/auditconfig -setumask lo,ex 1002

3. 事前選択マスクが変更されたことを確認します。

   # auditconfig -getpinfo 3941 audit id = jdoe(1002) process preselection mask = ex,lo(0x40001000,0x40001000) terminal id (maj,min,host) = 9426,65559,mach1(192.168.123.234) audit session id = 713

特定のイベントが監査されないようにする方法

メンテナンスのために、監査イベントが監査されないようにする必要が生じることがあります。

1. イベントのクラスを no クラスに変更します。

   たとえば、イベント 26 および 27 は pm クラスに属しています。

   ## audit_event file ... 25:AUE_VFORK:vfork(2):ps 26:AUE_SETGROUPS:setgroups(2):pm 27:AUE_SETPGRP:setpgrp(2):pm 28:AUE_SWAPON:swapon(2):no ...

   これらのイベントを no クラスに変更します。

   ## audit_event file ... 25:AUE_VFORK:vfork(2):ps 26:AUE_SETGROUPS:setgroups(2):no 27:AUE_SETPGRP:setpgrp(2):no 28:AUE_SWAPON:swapon(2):no ...

   pm クラスが現在監査中である場合でも、既存のセッションはイベント 26 および 27 を監査します。これらのイベントの監査を停止するには、ユーザーの事前選択マスクを更新する必要があります。

   ---

   注意 –

   audit_event ファイルではイベントをコメントにしないでください。このファイルは、praudit コマンドがバイナリ監査ファイルを読み取るときに使用します。また、このファイルに一覧表示されたイベントが、保管された監査ファイルに含まれることがあります。

   ---

2. ユーザーの事前選択マスクを更新するには、「ユーザーの事前選択マスクを変更する方法」の手順に従います。

バイナリ監査ファイルのサイズを制限する方法

バイナリ監査ファイルは無制限に増大します。保管や検索を容易にするために、サイズの制限が必要となることがあります。元のファイルから小さいバイナリファイルを作成することもできます。

1. Solaris 10 10/08 リリース以降、個々のバイナリ監査ファイルのサイズを制限するには p_fsize 属性を使用します。

   audit_binfile.so プラグインの p_fsize 属性により、監査ファイルのサイズを制限できます。デフォルト値はゼロ (0) で、この場合はファイルが無制限に増大します。値は、512,000 から 2,147,483,647 までのバイト数で指定します。指定したサイズに達すると、現在の監査ファイルが閉じられ、新しいファイルが開きます。

   次の例では、監査ファイルのサイズを 1M バイトに制限します。

   plugin:name=audit_binfile.so; p_dir:/var/audit; p_fsize=1024000

2. auditreduce コマンドを使用して、レコードを選択し、これらのレコードを詳細分析用にファイルに書き込みます。

   auditreduce -lowercase オプションは特定のレコードを検索します。

   auditreduce -Uppercase オプションは選択したレコードをファイルに書き込みます。詳細は、auditreduce(1M) のマニュアルページを参照してください。

ほかの OS からのログインを監査する方法

Solaris OS では、ソースに関係なく、すべてのログインを監査できます。

1. ユーザーに起因するイベントおよび起因しないイベントの lo クラスを監査します。

   このクラスは、ログイン、ログアウト、および画面ロックを監査します。

   ## audit_control file flags:lo naflags:lo ...

   ---

   注 –

   ssh ログインを監査するには、使用している Solaris システムで Solaris ssh デーモンを実行する必要があります。このデーモンは、Solaris 監査用に変更されます。詳細は、「Solaris Secure Shell と OpenSSH プロジェクト」を参照してください。

   ---

FTP および SFTP ファイル転送を監査する方法

FTP サービスは、ファイル転送のログを作成します。SSH プロトコルで実行する SFTP サービスは、Solaris 監査で監査できます。Solaris 監査では、両方のサービスへのログインを監査できます。

1. FTP サービスのファイル転送とコマンドのログを作成するには、ftpaccess(4) のマニュアルページを参照してください。

   使用可能なログ作成オプションについては、「ログ作成機能」に関する節を参照してください。特に、有用なログを作成できるのは、log commands オプションおよび log transfers オプションです。

2. sftp ファイル転送のログを作成するには、次の方法のいずれかまたは両方を実行します。

   • ファイル読み取りを監査します。

     SSH 接続によるファイル転送は、sftp コマンドを使用します。これらの転送は、+fr 監査フラグを使用して記録できます。失敗した sftp ファイル転送を監査するには、-fr 監査フラグを監査します。

     成功した sftp セッションの出力は次のとおりです。

     header,138,2,open(2) - read,,ma2,2009-08-25 14:48:58.770 -07:00 path,/home/jdoe/vpn_connect attribute,100644,jdoe,staff,391,437,0 subject,jdoe,jdoe,staff,jdoe,staff,4444,120289379,8457 65558 ma1 return,success,6

   • 冗長オプションを sftp コマンドに使用します。

     -v オプションは 3 回まで繰り返すことができます。

     # sftp -vvv [ other options ] hostname

3. FTP および SFTP サービスへのアクセスを記録するには、lo クラスを監査します。

   次の出力に示すとおり、ftpd デーモンへのログインおよびログアウトで監査レコードが生成されます。

   % bsmrecord -c lo | more ... in.ftpd program /usr/sbin/in.ftpd See ftp access event ID 6165 AUE_ftpd class lo (0x00001000) header subject [text] error message return in.ftpd program /usr/sbin/in.ftpd See ftp logout event ID 6171 AUE_ftpd_logout class lo (0x00001000) header subject return ...

   SSH ログインは、sftp コマンドへのすべてのアクセスを記録します。

   ... /usr/lib/ssh/sshd program /usr/lib/ssh/sshd See login - ssh event ID 6172 AUE_ssh class lo (0x00001000) header subject [text] error message return

第 31 章 Solaris 監査 (参照)

この章では、Solaris 監査の重要なコンポーネントを説明します。この章の内容は次のとおりです。

• 「監査コマンド」

• 「監査サービスで使用されるファイル」

• 「監査を管理するための権利プロファイル」

• 「監査と Solaris ゾーン」

• 「監査クラス」

• 「監査プラグイン」

• 「監査ポリシー」

• 「プロセスの監査特性」

• 「監査トレール」

• 「バイナリ監査ファイルの命名規則」

• 「監査レコードの構造」

• 「監査トークンの形式」

Solaris 監査の概要は、第 28 章Solaris 監査 (概要)を参照してください。計画の提案については、第 29 章Solaris 監査の計画を参照してください。ご使用のシステムで監査を設定する手順については、第 30 章Solaris 監査の管理 (作業)を参照してください。

監査コマンド

この節では、次の各コマンドについての情報を提供します。

• 「auditd デーモン」

• 「audit コマンド」

• 「bsmrecord コマンド」

• 「auditreduce コマンド」

• 「praudit コマンド」

• 「auditconfig コマンド」

auditd デーモン

次のリストは、auditd デーモンのタスクの概要を示します。

• audit_control ファイルに指定されているディレクトリ内の監査ファイルを開いたり閉じたりします。ファイルは、記述した順序で開かれます。

• 1 つ以上のプラグインを読み込みます。Sun では 2 つのプラグインを提供します。audit_binfile.so プラグインは、バイナリ監査データをファイルに書き込みます。audit_syslog.so プラグインは、選択した監査レコードの概要テキストを syslog ログに渡します。

• カーネルから監査データを読み取り、auditd プラグインを使用してデータを出力します。

• audit_warn スクリプトを実行して、さまざまな状況を警告します。binfile.so プラグインは、audit_warn スクリプトを実行します。デフォルトでは、このスクリプトは audit_warn 電子メールエイリアスとコンソールに警告を送信します。syslog.so プラグインは、audit_warn スクリプトを実行しません。

• デフォルトでは、監査ディレクトリがすべていっぱいになると、監査レコードを生成するプロセスは中断されます。また、auditd デーモンは、コンソールと audit_warn 電子メールエイリアスにメッセージを送ります。この時点では、システム管理者だけが、監査サービスの修復を行えます。管理者は、ログインして監査ファイルをオフラインメディアに書き込んだり、監査ファイルをシステムから削除したり、その他のクリーンアップ作業を実行したりできます。

  この監査ポリシーは、auditconfig コマンドを使用して構成し直すことができます。

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

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

audit コマンド

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

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

• auditd デーモンを設定し直します

• ローカルシステム上のプロセス事前選択マスクを調整します

• 監査レコードを別の監査ファイルに書き込みます

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

bsmrecord コマンド

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

auditreduce コマンド

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

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

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

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

• 指定された監査クラスによって生成された監査レコードを要求します

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

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

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

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

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

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

# auditreduce -R /var/audit-alt 

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

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

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

praudit コマンド

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

praudit コマンドでは、次の 4 つの出力形式を生成できます。5 番目のオプション -l (長形式) では、出力の 1 行に 1 つの監査レコードが表示されます。デフォルトでは、出力の 1 行につき 1 つの監査トークンが表示されます。-d オプションを指定すると、トークンフィールドおよびトークン間で使用される区切り文字を変更できます。デフォルトの区切り文字は、コンマです。

• デフォルト – オプションを指定しないで praudit コマンドを実行すると、1 行につき 1 つの監査トークンが表示されます。監査イベントは ioctl(2) システムコールなどのその内容が表示されます。テキストで表示できる値はすべてテキスト形式で表示されます。たとえば、ユーザーは、ユーザー ID ではなく、ユーザー名で表示されます。

• –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 -l コマンドで出力したものです。

header,173,2,settppriv(2),,example1,2003-10-13 13:46:02.174 -07:00

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

121,173,2,289,0x0000,192.168.86.166,1066077962,174352445

例 31–1 praudit 出力をスクリプトで処理する

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

#!/bin/sh
#
## This script takes an argument of a user-specified string.
#  The sed command prefixes the header tokens with Control-A
#  The first tr command puts the audit tokens for one record 
#  onto one line while preserving the line breaks as Control-A
#
praudit | sed -e '1,2d' -e '$s/^file.*$//' -e 's/^header/^aheader/' \\
| tr '\\012\\001' '\\002\\012' \\
| grep "$1" \\ Finds the user-specified string
| tr '\\002' '\\012' Restores the original newline breaks

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

auditconfig コマンド

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

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

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

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

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

• 監査キューの管理

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

• 監査イベントの監査クラスへのマッピングの取得/設定

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

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

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

コマンドオプションの詳細は、auditconfig(1M) のマニュアルページを参照してください。

監査サービスで使用されるファイル

監査サービスでは、次のファイルが使用されます。

• 「system ファイル」

• 「syslog.conf ファイル」

• 「audit_class ファイル」

• 「audit_control ファイル」

• 「audit_event ファイル」

• 「audit_startup スクリプト」

• 「audit_user データベース」

• 「audit_warn スクリプト」

• 「bsmconv スクリプト」

system ファイル

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

set c2audit:audit_load=1

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

syslog.conf ファイル

/etc/syslog.conf ファイルは、audit_control ファイルと一緒に使用して、監査レコードをテキスト形式で格納します。syslog ユーティリティーが監査レコードを格納できるように、syslog.conf ファイルを設定できます。例は、「syslog 監査ログの構成方法」を参照してください。

audit_class ファイル

/etc/security/audit_class ファイルは、監査クラスを定義します。監査クラスは、監査イベントのグループです。audit_control ファイル内のこのクラス名を使用して、監査するイベントのクラスを事前選択します。クラスには、失敗したイベントだけ、または正常なイベントだけを選択する接頭辞を使用できます。詳細は、「監査クラスの構文」を参照してください。

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

audit_control ファイル

各システム上の/etc/security/audit_control ファイルには、auditd デーモンの構成情報が含まれます。このファイルを使用すると、すべてのシステムが、その監査レコードを格納する遠隔監査ファイルシステムをマウントできるようになります。

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

• flags キーワード – このキーワードで始まるエントリは、システム上のすべてのユーザーを対象に監査するイベントのクラスを事前選択します。ここで指定する監査クラスは、「システム全体の監査事前選択マスク」を指定します。監査クラスはコンマで区切ります。

• naflags キーワード – このキーワードで始まるエントリは、特定のユーザーに起因しない動作が発生したときに監査するイベントのクラスを事前選択します。監査クラスはコンマで区切ります。na イベントクラスは、このエントリにあります。naflags エントリを使用すると、通常はユーザーに起因するがユーザーに起因できないほかのイベントクラスのログをとることができます。たとえば、ブート時に起動するプログラムがファイルを読み取ると、naflags エントリ内の fr がそのイベントのレコードを作成します。

• minfree キーワード – このキーワードは非推奨です。audit_binfile.so プラグインの p_minfree 属性を使用します。

  p_minfree 属性は、すべての監査ファイルシステムについて、最小空き容量レベルをパーセントで定義します。この割合は、0 以上で指定する必要があります。デフォルトは 20% です。監査ファイルシステムの使用率が 80% に達すると、次に利用可能な監査ディレクトリに監査データが格納されるようになります。詳細は、audit_warn(1M) のマニュアルページを参照してください。

• dir キーワード – このキーワードは非推奨です。audit_binfile.so プラグインの p_dir 属性を使用します。

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

• plugin キーワード – プラグインモジュール audit_binfile.so および audit_syslog.so のプラグインパスを指定します。audit_binfile.so モジュールは、バイナリ監査ファイルの作成を処理します。audit_syslog.so モジュールは、Solaris 監査レコードをテキスト形式にリアルタイムで変換します。audit_syslog.so プラグインの p_flags 属性に指定された監査クラスは、事前選択された監査クラスのサブセットである必要があります。

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

例 31–2 audit_control ファイルの例

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

Solaris 10 リリースでは、dir 行および minfree 行は非推奨です。次の例では、plugin 行に改行が含まれていません。

flags:lo,am,-all,^-fc
naflags:lo,nt
plugin:name=audit_binfile.so; p_minfree=20; p_dir=/var/audit/blinken/files,
/var/audit/blinken.1/files,/var/audit/winken
plugin:name=audit_syslog.so; p_flags=-lo,-am

audit_event ファイル

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

audit_startup スクリプト

システムがマルチユーザーモードに移行すると、/etc/security/audit_startup スクリプトが監査サービスを自動的に構成します。auditd デーモンは、スクリプトが次のタスクを実行してから起動します。

• 監査イベントから監査クラスへのマッピングを構成する

• 監査ポリシーオプションを設定する

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

audit_user データベース

/etc/security/audit_user データベースは、システム全体の事前選択クラスを個々のユーザーごとに変更します。audit_user データベース内のユーザーエントリに追加するクラスは、audit_control ファイルにある設定を次の 2 つの方法で変更します。

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

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

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

username:always-audit-classes:never-audit-classes

監査フィールドは、順番に処理されます。

• always-audit-classes フィールドは、指定されたクラスの監査を有効にします。このフィールドを使用してシステム全体の設定を変更します。たとえば、always-audit-classes フィールドに all を指定すると、ユーザーのすべての動作が監査されます。

• never-audit-classes フィールドは、指定されたクラスの監査を無効にします。このフィールドを使用して、システム設定を上書きします。never-audit-classes フィールドに all を指定すると、audit_control ファイルに指定された監査クラスを含め、ユーザーのすべての監査がオフになります。

たとえば、ファイルシステムオブジェクトの正常な読み取り動作を除き、システム全体の監査設定を tamiko というユーザーに適用するとします。次の audit_user エントリでの 2 番目のコロン (:) の位置に注意してください。

tamiko:^+fr:no  modify system defaults for fr

前述のエントリは、「正常なファイル読み取り動作を除くすべての動作を監査する」ことを意味しています。

ユーザー tamiko について、正常なファイル読み取り動作を除くすべての動作を監査する場合、次のエントリを使用します。

tamiko:all,^+fr:no  audit everything except fr

ユーザー tamiko の正常なファイル読み取り動作について、システムのデフォルト設定を上書きするとします。次のエントリは、「常にすべての動作を監査するが、正常なファイルの読み取り動作はまったく監査しない」ことを意味しています。

tamiko:all:+fr    override system defaults for fr

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

audit_warn スクリプト

auditd デーモンで監査レコードの書き込み中に異常な状態が発生すると、/etc/security/audit_warn スクリプトは電子メールエイリアスに通知します。このスクリプトをサイトに合わせてカスタマイズすることで、手動による対処が必要な状態を警告するようにしたり、そのような状態を自動的に処理するための方法を指定したりできます。エラーが発生すると、audit_warn スクリプトは、daemon.alert の重要度で syslog にメッセージを書き込みます。syslog.conf を使用すると、syslog メッセージのコンソール表示を設定できます。audit_warn スクリプトはさらに、audit_warn 電子メールエイリアスにもメッセージを送信します。このエイリアスは、監査構成の一部として設定します。

auditd デーモンは、次の条件を検出すると audit_warn スクリプトを起動し、audit_warn エイリアスに電子メールを送信します。

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

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

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

  文字列 allsoft を使用して audit_warn スクリプトが起動されます。コンソールにメッセージが出力されます。さらに、audit_warn のエイリアスに電子メールが送信されます。

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

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

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

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

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

  デフォルトでは、コンソールにメッセージが書き込まれます。さらに、audit_warn のエイリアスに電子メールが送信されます。監査レコードを生成するプロセスは中断されますが、監査レコードはカウントされます。監査レコードは生成されません。この状況に対処する方法の例については、例 30–16 と「監査トレールのオーバーフローを防ぐ方法」を参照してください。

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

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

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

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

  • plugin name – プラグインの実行中にエラーが発生した

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

perzone 監査ポリシーが設定されている場合、非大域ゾーンの auditd のインスタンスがゾーンの audit_warn スクリプトを呼び出します。詳細は、audit_warn(1M) のマニュアルページを参照してください。

bsmconv スクリプト

/etc/security/bsmconv スクリプトは、監査サービスを有効にします。bsmunconv コマンドは、監査サービスを無効にします。bsmconv スクリプトを実行したあと、監査ディレクトリと監査構成ファイルを設定します。リブート時に、監査が有効になります。

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

監査を管理するための権利プロファイル

Solaris OS には、監査サービスを構成したり監査トレールを分析したりするための権利プロファイルが用意されています。

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

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

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

監査サービスを扱う役割を設定する方法については、「RBAC の構成 (作業マップ)」を参照してください。

監査と Solaris ゾーン

非大域ゾーンは、大域ゾーンの監査とまったく同様に監査することも、独自のフラグ、記憶領域、および監査ポリシーを設定することもできます。

すべてのゾーンが同様に監査される場合には、大域ゾーンの構成ファイルが、すべてのゾーンにおける監査の設定を提供します。+zonename ポリシーオプションが役に立ちます。このオプションが指定されていると、すべてのゾーンからの監査レコードには、ゾーンの名前が含まれます。監査レコードをゾーン名を使用して、事後選択することができます。監査ポリシーの詳細は、「監査ポリシーの決定」を参照してください。例については、「監査ポリシーを構成する方法」を参照してください。

ゾーンを個別に監査することもできます。ポリシーオプション perzone が大域ゾーンで指定されているとき、各非大域ゾーンは、それぞれの監査デーモンの実行、監査キューの処理、および監査レコードの内容と場所の指定を行います。非大域ゾーンは、ほとんどの監査ポリシーオプションを指定できます。システム全体に影響するポリシーを設定できないため、非大域ゾーンは ahlt または perzone ポリシーを指定できません。詳細については、「ゾーンを含むシステムでの監査」および 「ゾーン内の監査の計画方法」を参照してください。

ゾーンの詳細は、『Oracle Solaris のシステム管理 (Oracle Solaris コンテナ : 資源管理と Oracle Solaris ゾーン)』のパート II「ゾーン」を参照してください。

監査クラス

システム全体での Solaris 監査のデフォルト値は、1 つ以上のイベントのクラスを指定して事前選択されます。クラスは、システムの audit_control ファイルでシステムごとに事前選択されます。システムを使用するすべてのユーザーが、これらのイベントのクラスに対して監査されます。このファイルについては、「audit_control ファイル」を参照してください。

監査クラスを構成し、新しい監査クラスを作成できます。監査クラス名は、最長 8 文字です。クラスの説明は、72 文字に制限されています。数値と英数字以外の文字が使用できます。

audit_user データベースのユーザーのエントリに監査クラスを追加して、ユーザーごとの監査対象を変更できます。監査クラスは、auditconfig コマンドの引数としても使用します。詳細は、auditconfig(1M) のマニュアルページを参照してください。

監査クラスの定義

次の表に、事前に定義されている監査クラス、監査クラスの記述名、および短い説明を示します。

/etc/security/audit_class ファイルを変更して、新しいクラスを定義できます。既存クラスの名前の変更も可能です。詳細は、audit_class(4) のマニュアルページを参照してください。

監査クラスの構文

成功した場合に監査されるイベント、失敗した場合に監査されるイベント、または両方の場合に監査されるイベントがあります。接頭辞を指定しなかったイベントのクラスは、成功した場合も失敗した場合も監査されます。プラス (+) 接頭辞が付いた場合、イベントのクラスは成功した場合のみが監査されます。マイナス (-) 接頭辞が付く場合、イベントのクラスは失敗した場合のみが監査されます。次の表に、監査クラスの例をいくつか示します。

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

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

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

• audit_control ファイルの flags 行

• audit_control ファイルの plugin:name=audit_syslog.so; p_flags= 行

• audit_user データベース内のユーザーのエントリ

• auditconfig コマンドオプションの引数として

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

監査プラグイン

監査プラグインでは、監査キューの監査レコードの処理方法を指定します。監査プラグインである audit_binfile.so および audit_syslog.so は、audit_control ファイル内で指定されます。このプラグインとパラメータを使って、次の内容を指定できます。

• audit_binfile.so プラグイン、p_dir パラメータにより、バイナリデータの送信先

• audit_binfile.so プラグイン、p_minfree パラメータにより、管理者への警告の基準となるディスクの最小空き容量

• audit_binfile.so プラグイン、p_fsize パラメータにより、監査ファイルの最大サイズ

  p_fsize パラメータプラグインは、Solaris 10 10/08 リリース以降使用可能

• audit_syslog.so プラグイン、p_flags パラメータにより、syslog に送信する監査レコードの選択

• qsize パラメータにより、そのプラグインでキューに入る監査レコードの最大数

audit_binfile(5)、audit_syslog(5)、および audit_control(4) のマニュアルページを参照してください。

監査ポリシー

監査ポリシーには、監査トレールにトークンまたは情報を追加するかどうかを指定します。

arge、argv、group、path、seq、trail、windata_down、windata_up、および zonename ポリシーは、監査レコードにトークンを追加します。

その他のポリシーでは、トークンは追加されません。ahlt および cnt ポリシーはカーネル監査レコードが配信できない場合の動作を決定、public ポリシーは公開ファイルの監査を制限、perzone ポリシーは非大域ゾーンの別個の監査キューを確立します。

さまざまな監査ポリシーオプションの働きについては、「監査ポリシーの決定」を参照してください。監査ポリシーオプションについては、auditconfig(1M) のマニュアルページの -setpolicy オプションを参照してください。使用可能なポリシーオプションのリストについては、auditconfig -lspolicy コマンドを実行します。

プロセスの監査特性

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

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

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

  (flags line + always-audit-classes) - never-audit-classes

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

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

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

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

監査トレール

「監査トレール」はバイナリ監査ファイルを含み、auditd デーモンによって作成されます。bsmconv コマンドにより監査サービスが有効になると、システムの起動時に auditd デーモンが起動します。auditd デーモンは、監査トレールデータを収集し、監査レコードを書き込みます。

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

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

監査ファイルシステムを管理するときは、次の要因も考慮する必要があります。

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

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

• 監査ファイルシステムを、格納先の監査サーバー上で一覧してください。エクスポートリストには、サイトで監査対象のすべてのシステムが含まれるべきです。

バイナリ監査ファイルの命名規則

各バイナリ監査ファイルは、自己完結したレコードの集合です。ファイル名には、レコードが生成された時間の範囲と、それを生成したシステム名が含まれます。

バイナリ監査ファイル名

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

start-time.end-time.system

start-time

監査ファイル内の最初の監査レコードが生成された時刻です

end-time

最後のレコードがファイルに書き込まれた時刻です

system

ファイルを生成したシステム名です

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

start-time.not_terminated.system

not_terminated および閉じられた監査ファイルの名前の例については、「not_terminated 監査ファイルを整理する方法」を参照してください。

バイナリ監査ファイルのタイムスタンプ

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

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

YYYYMMDDHHMMSS

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

監査レコードの構造

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

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

監査レコード分析

監査レコード分析には、監査トレールのレコードの事後選択が必要です。次の 2 つの方法のうちのいずれかを使用して、収集されたバイナリデータを解析できます。

• バイナリデータストリームを解析します。データストリームを解析するには、各トークン内のフィールドの順番と各レコード内のトークンの順番を知る必要があります。また、さまざまな監査レコードを知る必要もあります。たとえば、ioctl() システムコールは、「Invalid file descriptor」の監査レコードからのさまざまなトークンを含む「Bad file name」の監査レコードを作成します。

  • 各監査トークン内のバイナリデータの順番については、audit.log(4) のマニュアルページを参照してください。

  • 監査レコード内のトークンの順番の説明については、bsmrecord コマンドを使用してください。bsmrecord コマンドによる出力には、さまざまな条件で発生するさまざまな形式が示されます。角括弧 ([]) は、監査トークンが省略可能であることを表しています。詳細は、bsmrecord(1M) のマニュアルページを参照してください。例については、「監査レコードの書式の表示方法」を参照してください。

• praudit コマンドを使用します。コマンドのオプションにより、さまざまなテキスト出力が得られます。たとえば、praudit -x コマンドを使用すると、スクリプトとブラウザへの入力のための XML が得られます。praudit 出力には、単にバイナリデータの解析に使用するためだけのフィールドは含まれません。出力は、バイナリフィールドの順番どおりではありません。また、praudit 出力の順番と形式は、Solaris リリース間で保証されているわけでもありません。

  praudit 出力の例については、「バイナリ監査ファイルの内容を表示する方法」、および praudit(1M) のマニュアルページを参照してください。

  監査トークンごとの praudit 出力については、「監査トークンの形式」セクションでそれぞれのトークンを参照してください。

監査トークンの形式

各監査トークンにはトークンの種類識別子と、そのあとにトークン固有のデータが続いています。各トークンの種類には固有の形式があります。次の表は、各トークンの名前と簡単な説明の一覧です。廃止されたトークンは、以前の Solaris リリースとの互換性のために維持されています。

監査レコードは常に header トークンで始まります。header トークンは、監査トレール内で監査レコードの始まりを示します。ユーザーの動作に起因するイベントの場合、subject と process トークンは、イベントを発生させたプロセスの値を参照します。ユーザーの動作に起因しないイベントの場合、process トークンはシステムを参照します。

acl トークン

acl トークンは、アクセス制御リスト (ACL) に関する情報を記録します。

acl トークンは、次の 4 つの固定長フィールドで構成されます。

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

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

• ACL 値フィールド

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

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

<acl type="1" value="root" mode="6"/>

arbitrary トークン (廃止)

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

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

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

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

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

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

arbitrary,decimal,int,1
42

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

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

arg トークン

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

arg トークンには次の 5 つのフィールドがあります。

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

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

• 引数の値

• テキスト文字列の長さ

• テキスト文字列

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

<argument arg-num="2" value="0x0" desc="new file uid"/>

attribute トークン

attribute トークンには、ファイル vnode からの情報が含まれています。

attribute トークンには次の 7 つのフィールドがあります。

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

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

• 所有者のユーザー ID

• 所有者のグループ ID

• ファイルシステム ID

• ノード ID

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

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

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

<attribute mode="100644" uid="adm" gid="adm" fsid="136" nodeid="2040" device="0"/>

cmd トークン

cmd トークンは、コマンドに割り当てられた引数のリストおよび環境変数のリストを記録します。

cmd トークンには次のフィールドがあります。

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

• コマンドの引数のカウント

• 引数の一覧

• 次のフィールドの長さ

• 引数の内容

• 環境変数のカウント

• 環境変数の一覧

• 次のフィールドの長さ

• 環境変数の内容

praudit -x コマンドでは、cmd トークンのフィールドは次のように表示されます。次に示すのは、切り詰められた cmd トークンです。行は、表示の都合上、折り返して記載されています。

<cmd><arge>WINDOWID=6823679</arge>
<arge>COLORTERM=gnome-terminal</arge>
<arge>...LANG=C</arge>...<arge>HOST=machine1</arge>
<arge>LPDEST=printer1</arge>...</cmd>

exec_args トークン

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

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

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

このトークンの残りの部分は、count 文字列からなっています。praudit -x コマンドでは、exec_args トークンのフィールドは次のように表示されます。

<exec_args><arg>/usr/bin/sh</arg><arg>/usr/bin/hostname</arg></exec_args>

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

exec_env トークン

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

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

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

このトークンの残りの部分は、count 文字列からなっています。praudit -x コマンドでは、exec_env トークンのフィールドは次のように表示されます。行は、表示の都合上、折り返して記載されています。

<exec_env><env>_=/usr/bin/hostname</env>
<env>DTXSERVERLOCATION=local</env><env>SESSIONTYPE=altDt</env>
<env>LANG=C</env><env>SDT_NO_TOOLTALK=1</env><env>SDT_ALT_HELLO=/bin/true</env>
<env>PATH=/usr/bin:/usr/openwin/bin:/usr/ucb</env>
<env>OPENWINHOME=/usr/openwin</env><env>LOGNAME=jdoe</env><env>USER=jdoe</env>
<env>DISPLAY=:0</env><env>SHELL=/bin/csh</env><env>START_SPECKEYSD=no</env>
<env>SDT_ALT_SESSION=/usr/dt/config/Xsession2.jds</env><env>HOME=/home/jdoe</env>
<env>SDT_NO_DTDBCACHE=1</env><env>PWD=/home/jdoe</env><env>TZ=US/Pacific</env>
</exec_env>

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

exit トークン (廃止)

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

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

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

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

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

exit,Error 0,0

file トークン

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

praudit -x コマンドでは、file トークンのフィールドは次のように表示されます。このトークンは、監査証跡の次のファイルを特定します。行は、表示の都合上、折り返して記載されています。

<file iso8601="2009-04-08 14:18:26.200 -07:00">
/var/audit/machine1/files/20090408211826.not_terminated.machine1</file>

group トークン (廃止)

このトークンは、groups トークンに置き換えられています。「groups トークン」を参照してください。

groups トークン

groups トークンは group トークンを置き換えます。groups トークンは、プロセスの資格からグループエントリを記録します。

group トークンには次の 2 つの固定長フィールドがあります。

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

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

このトークンの残りの部分は、count グループエントリからなっています。

praudit -x コマンドでは、groups トークンのフィールドは次のように表示されます。

<group><gid>staff</gid><gid>other</gid></group>

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

header トークン

header トークンは、監査レコードの開始を示すという意味で、特殊なトークンです。trailer トークンとの組み合わせでレコード内のほかのすべてのトークンを囲む特殊なトークンです。

header トークンには次の 8 つのフィールドがあります。

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

• この監査レコード全体の長さのバイト数。header トークンと trailer トークンを含みます

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

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

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

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

  0x4000 PAD_NOTATTR nonattributable event 0x8000 PAD_FAILURE failed audit event

• アドレスの種類。IPv4 または IPv6

• マシンのアドレス

• レコードの作成日時

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

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

header,69,2,su,,machine1,2009-04-08 13:11:58.209 -07:00

praudit -x コマンドでは、header トークンのフィールドは監査レコードの先頭に表示されます。行は、表示の都合上、折り返して記載されています。

<record version="2" event="su" host="machine1" 
iso8601="2009-04-08 13:11:58.209 -07:00">

ip_addr トークン

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

in_addr トークンには次の 3 つのフィールドがあります。

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

• IP アドレスの種類。IPv4 または IPv6

• IP アドレス

praudit -x コマンドでは、ip_addr トークンの内容は次のように表示されます。

<ip_address>machine1</ip_address>

ip トークン (廃止)

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

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

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

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

ip address,0.0.0.0

IP ヘッダー構造は、/usr/include/netinet/ip.h ファイル内で定義されています。

ipc トークン

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

ipc トークンには次の 3 つのフィールドがあります。

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

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

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

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

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

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

<IPC ipc-type="shm" ipc-id="15"/>

ipc_perm トークン

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

ipc_perm トークンには次の 8 つのフィールドがあります。

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

• IPC 所有者のユーザー ID

• IPC 所有者のグループ ID

• IPC 作成者のユーザー ID

• IPC 作成者のグループ ID

• IPC のアクセスモード

• IPC のシーケンス番号

• IPC 鍵の値

praudit -x コマンドでは、ipc_perm トークンのフィールドは次のように表示されます。行は、表示の都合上、折り返して記載されています。

<IPC_perm uid="jdoe" gid="staff" creator-uid="jdoe" 
creator-gid="staff" mode="100600" seq="0" key="0x0"/>

値は、IPC オブジェクトに関連付けられた ipc_perm 構造から取り出されます。

iport トークン

iport トークンには、TCP または UDP ポートアドレスが含まれています。

iport トークンには次の 2 つのフィールドがあります。

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

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

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

ip port,0xf6d6

opaque トークン (廃止)

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

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

• このデータのバイト数

• バイトデータ配列

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

opaque,12,0x4f5041515545204441544100

path トークン

path トークンには、オブジェクトのアクセスパス情報が含まれています。

path トークンには次のフィールドがあります。

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

• パスの長さ

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

praudit コマンドでは、path トークンは 2 番目のフィールドなしで、次のように表示されます。

path,/etc/security/audit_user

praudit -x コマンドでは、path トークンの内容は次のように表示されます。

<path>/etc/security/audit_user</path>

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

図 31–4 path トークンの形式

path_attr トークン

path_attr トークンには、オブジェクトのアクセスパス情報が含まれています。アクセスパスは、path トークンオブジェクトの下の属性ファイルオブジェクトのシーケンスを指定します。openat() などのシステムコールは、属性ファイルにアクセスします。属性ファイルオブジェクトの詳細については、fsattr(5) のマニュアルページを参照してください。

path_attr トークンには次のフィールドがあります。

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

• 属性ファイルパスのセクション数を表すカウント

• count NULL で終わっている文字列

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

path_attr,1,attr_file_name

privilege トークン

privilege トークンは、プロセス上での特権の使用を記録します。privilege トークンは、基本セットの特権に対して記録されません。特権が管理者の処理により基本セットから削除された場合、その特権の使用は記録されます。特権の詳細は、「特権 (概要)」を参照してください。

privilege トークンには次のフィールドがあります。

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

• 次のフィールドの長さ

• 特権セットの名前

• 次のフィールドの長さ

• 特権の一覧

praudit -x コマンドでは、privilege トークンのフィールドは次のように表示されます。行は、表示の都合上、折り返して記載されています。