Solaris のシステム管理 (セキュリティサービス)

Solaris 監査の計画 (作業)

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

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

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

すべてのゾーンに対して大域ゾーン内で単一の監査サービスを構成できます。
ゾーンごとに監査サービスを 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 つのローカル監査ディレクトリに容量を割り当てます。監査ディレクトリを指定する方法は、例 30–3 を参照してください。

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

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

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

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

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

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

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

始める前に

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

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

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

単一システムイメージ監査トレールは監査対象のシステムを 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 エントリを同じにします。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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