監査サービスでは、次の用語が使用されています。定義によっては、より詳細な説明への参照先も示します。
表 28–1 Solaris 監査の用語
用語 |
定義 |
---|---|
監査クラス |
監査イベントのグループ。監査クラスは、監査対象のイベントのグループの選択方法を提供します。詳細は、「監査クラスおよび事前選択」を参照してください。 |
監査ディレクトリ |
バイナリ形式の監査ファイルのリポジトリ。監査ディレクトリのタイプについては、「監査ログ」を参照してください。 |
監査イベント |
監査対象のセキュリティー関連のシステム動作。選択を容易にするために、イベントは監査クラスにグループ化されます。監査対象のシステム動作については、「監査イベント」を参照してください。 |
監査ポリシー |
サイトで有効または無効を指定できる監査オプションのセット。特定の種類の監査データを記録するかどうかのオプションがあります。また、監査トレールがいっぱいになった場合に監査を中断するかどうかも指定できます。詳細は、「監査ポリシーの決定」を参照してください。 |
監査レコード |
監査ファイルに格納される監査データ。1 つの監査レコードにつき 1 つの監査イベントが記述されます。各監査レコードは、一連の監査トークンから構成されます。監査レコードの詳細は、「監査レコードと監査トークン」を参照してください。 |
監査トークン |
監査レコードまたはイベントのフィールド。各監査トークンには、監査イベントの 1 つの属性 (ユーザー、プログラム、その他のオブジェクトなど) が記述されます。すべての監査トークンの説明は、「監査トークンの形式」を参照してください。 |
監査トレール |
監査サービスを実行するすべてのシステムからの監査データを格納する 1 つまたは複数の監査ファイルの集合。詳細は、「監査トレール」を参照してください。 |
事前選択 |
事前選択とは、監査サービスの有効化前に行う、監視する監査クラスの選択です。事前選択された監査クラスの監査イベントは、監査トレールに記録されます。事前選択されない監査クラスは監査されず、監査トレールに記録されません。事後選択ツールの auditreduce コマンドを使用すると、監査トレールからレコードを選択できます。詳細は、「監査クラスおよび事前選択」を参照してください。 |
公開オブジェクト |
公開オブジェクトとは、root ユーザーが所有し、すべてのユーザーが読み取り可能なファイルです。たとえば、/etc ディレクトリと /usr/bin ディレクトリは公開オブジェクトです。公開オブジェクトの読み取り専用イベントは監査されません。たとえば、file_read (fr) 監査フラグが事前選択されている場合でも、公開オブジェクトの読み取り動作は監査されません。public 監査ポリシーオプションを変更すると、デフォルトを上書きできます。 |
監査プラグイン |
カーネルキューの監査レコードを指定した場所に転送するモジュール。audit_binfile.so プラグインはバイナリ監査ファイル (監査証跡) を作成します。audit_syslog.so プラグインは、選択した監査レコードを syslog ログにフィルタします。詳細は、「監査プラグインモジュール」を参照してください。 |
セキュリティーに関連するシステム動作について監査を行うことができます。これらの監査可能な動作を、「監査イベント」と呼びます。監査イベントは、/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 監査レコードの比較を示します。
表 28–2 バイナリ形式の監査レコードと syslog 監査レコードの比較
機能 |
バイナリレコード |
syslog レコード |
---|---|---|
プロトコル |
ファイルシステムに書き込みます |
遠隔ログ記録に UDP を使用します |
データ型 |
バイナリ形式 |
テキスト |
レコード長 |
無制限 |
監査レコードあたり最大 1024 文字 |
場所 |
ローカルディスク、および NFS を使用してマウントされたディレクトリに格納されます |
syslog.conf ファイルで指定された場所に格納されます |
設定方法 |
audit_control ファイルを編集して、監査ディレクトリを保護し NFS でマウントします |
audit_control ファイルを編集して、 syslog.conf ファイルを編集します |
読み取り方法 |
通常、バッチモード XML 形式によるブラウザの出力 |
リアルタイムで、または syslog 用に作成したスクリプトによる検索 プレーンテキスト形式の出力 |
完全性 |
完全であることと正確な順番で表示されることが保証されます |
完全であることは保証されません |
タイムスタンプ |
グリニッジ標準時 (GMT) |
監査されているシステム上の時間 |
バイナリ形式のレコードにより、強力なセキュリティーとカバレージが提供されます。バイナリ出力は、共通基準制御アクセス保護プロファイル (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) のマニュアルページ
「監査ディレクトリ」はバイナリ形式で監査ファイルを保持します。通常のインストールでは、多くの監査ディレクトリが使用されます。すべての監査ディレクトリの内容は、「監査トレール」で構成されています。監査レコードは、次の順番で監査ディレクトリに格納されます。
「一次監査ディレクトリ」 – 通常の条件下で、システム監査ファイルが配置されるディレクトリ
「二次監査ディレクトリ」 – 一次監査ディレクトリがいっぱいか使用できない場合に、システム監査ファイルが配置されるディレクトリ
「最後のディレクトリ」 – 一次監査ディレクトリと二次監査ディレクトリが使用できない場合に使用されるローカル監査ディレクトリ
ディレクトリは、audit_control ファイルに指定されます。各ディレクトリは、上記の順番で前のディレクトリがいっぱいになるまで使用されません。ディレクトリエントリのリストを含む注釈付きの audit_control ファイルについては、例 30–3 を参照してください。
監査ファイルをデフォルトの監査ルートディレクトリに配置すると、監査証跡を確認する際に役立ちます。auditreduce コマンドは、監査ルートディレクトリを使用して監査証跡内のすべてのファイルを検索します。デフォルトの監査ルートディレクトリは /etc/security/audit です。このディレクトリは、/var/audit に象徴的にリンクされています。/var/audit/hostname /files という名前のディレクトリにある監査ファイルは、auditreduce コマンドで簡単に見つかります。詳細は、「auditreduce コマンド」を参照してください。
監査サービスには、監査トレールのファイルを結合したり削除したりするコマンドがあります。auditreduce コマンドは、監査トレールの監査ファイルをマージします。また、ファイルをフィルタして特定のイベントを検出できます。praudit コマンドは、バイナリファイルを読み取ります。praudit コマンドのオプションにより、スクリプトやブラウザの表示に適した出力が得られます。