test

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

第 23 章 監査の計画

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

監査トレールの処理

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

問題 

説明 

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

サイトのセキュリティ上の必要性を考慮して、監査トレールに使用できるディスク容量を決定する。サイトのセキュリティを確保しながら領域要件を削減する方法と、監査記憶領域を設定する方法については、「監査コストの制御」 および 「効率的な監査」を参照

2. 監査するシステムと、監査ファイルを格納するシステムを決定する 

ネットワーク上で監査するホストを決定する。監査するホストごとに、1 つ以上のローカル監査ディレクトリを作成する。次に、監査トレールの大部分を格納するホストを決定する  

3. 監査ディレクトリの名前と位置を決定する 

使用するすべての監査ディレクトリの一覧を作成する 

4. ホストと監査ディレクトリを対応付ける 

ホストと監査ディレクトリの割り当てを作成する。この手順を行なって、監査作業の負荷を分散する 

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

経験の少ないシステム管理者は、ユーザーとシステムの動作について、できるだけ多くの情報を収集しようとする傾向があります。この場合、監査ファイルがすぐに大きくなり、空き領域がなくなる可能性があります。このため、監査する作業の種類を選択することをお勧めします。

問題 

説明 

1. サイトに必要な監査クラスを決定する 

監査クラスの追加やデフォルトクラスの変更は、監査サービスを開始する前に行うことを推奨する。監査クラスについては、「監査フラグ」 を参照

2. イベントからクラスへの割り当てを決定する  

多くの場合、デフォルトの割り当てをそのまま使用できる。ただし、新しいクラスを追加したり、クラスを変更したりした場合は、イベントを別のクラスに移動しなければならないこともある 

3. すべてのマシン上のすべてのユーザーについて、監査するクラスを決定する 

audit_control ファイルにあるシステム全体の監査フラグは、すべてのユーザーとプロセスに適用される。監査フラグは、監査クラスの監査が正常終了したとき、失敗したとき、またはその両方の場合に決定される。Solaris がインストールされたマシン上のすべての audit_control ファイルには、同じ監査フラグが設定されている必要がある

4. インストール全体の監査設定のユーザー例外を決定する 

一部のユーザーの監査をシステム全体の設定と異なる設定にするときは、各マシン上の audit_user ファイルでそのユーザーのエントリを変更する。詳細は、「ユーザーの監査特性の変更方法」を参照

5. 最小空きディスク容量 (minfree) を決定する。警告が送信されるまで、監査ファイルシステムのディスク容量を使用できる

監査ファイルシステムのディスク容量が minfree の割合を下回ると、監査デーモンは次に利用できる監査ディレクトリに切り替え、ソフト制限値を超えたことを示す警告を送信する。詳細は、「例 - 警告に対するソフト制限値を変更する」を参照

6. サイトに必要な監査ポリシーを決定する 

ポリシー変数は動的なカーネル変数であるため、その値はシステムの終了時には保存されない。このため、適切な起動スクリプトを使用して、適切なポリシーを設定する必要がある。詳細は、「監査ポリシーを有効または無効にする方法」を参照

7. audit_warn メールの別名の管理方法を決定する

auditd デーモンは、監査ディレクトリを切り替えるか問題 (ディスク容量の不足など) を検出したときに、audit_warn スクリプトを実行する。デフォルトでは、audit_warn スクリプトは、audit_warn の別名にメールを送信し、コンソールにメッセージを送信する。ほかの別名にメッセージを送信するには、別名を変更するか、スクリプトを変更する必要がある。詳細は、「audit_warn 別名の構成方法」を参照

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

監査トレールのオーバーフローが発生しても、システムを引き続き動作させるには、cnt ポリシーを有効にする。cnt ポリシーの例については、「例 - cnt ポリシーを設定する」を参照

また、監査を無効にした状態で、ログインおよび作業可能なアカウントを作成することもできる。監査アカウントの例については、「例 - 監査管理ログインを作成する」を参照

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

監査ポリシーは、特定の構成を有効または無効にした監査オプションを参照します。プログラムレベルで auditon システムコールを行なって、現在の監査ポリシーを調査したり、有効または無効にしたりすることができます。また、auditconfig コマンドを実行して同じタスクを行うこともできます。

デフォルトでは、すべての監査ポリシーは無効になっています。監査ポリシーを使用するときは、それらを有効にする必要があります。

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

ポリシー名 

説明 

ポリシーを変更する理由 

arge

無効にすると、実行済みプログラムスクリプトの環境変数が exec 監査レコードから除外される

有効にすると、実行済みプログラムスクリプトの環境変数が exec 監査レコードに追加される。監査レコードには、より詳細な情報が記録される

無効にすると、収集される情報が大幅に少なくなる 

このオプションは、少数のユーザーを監査しているとき、または exec プログラムで使用している環境変数に問題があるときに、有効にする

argv

無効にすると、実行済みプログラムスクリプトの引数が exec 監査レコードから除外される

有効にすると、実行済みプログラムスクリプトの引数が exec 監査レコードに追加される。監査レコードには、より詳細な情報が記録される

無効にすると、収集される情報が大幅に少なくなる 

このオプションは、少数のユーザーを監査しているとき、または exec プログラムが正常に動作しないことがはっきりしているときに、有効にする

cnt

無効にすると、ディスク容量の不足が原因で監査レコードを監査トレールに追加できない場合、ユーザーまたはアプリケーションがブロックされる 

有効にすると、監査レコードが生成されないまま、イベントを完了できる。監査レコードは生成されないが、カウントは行われる 

セキュリティを最優先する場合は、無効にする 

セキュリティよりシステムの可用性が重要な場合は、有効にする 

group

無効にすると、グループの一覧が監査レコードに追加されない 

有効にすると、グループの一覧が特別なトークンとしてすべての監査レコードに追加される

サイトのセキュリティが重要な場合、通常は無効にする 

どのグループが監査可能なイベントを生成しているかを監査する必要があるときは、有効にする 

path

無効にすると、1 つのシステムコールで使用されたパスが、あっても 1 つだけ監査レコードに記録される 

有効にすると、監査イベントで使用されたすべてのパスが、すべての監査レコードに記録される 

無効にすると、監査レコードにパスが、あっても 1 つだけ記録される 

有効にすると、1 つのシステムコールで使用された各ファイル名またはパスが、監査レコードに path トークンとして記録される

seq

無効にすると、監査レコードに順序番号が追加されない 

有効にすると、すべての監査レコードに順序番号 (seqトークン) が追加される

監査が問題なく動作しているときは、無効にしてもかまわない 

監査ファイルが正しく書き込まれているかどうかを確認するときは、有効にする。ファイルが壊れた場合 (監査レコードがすべて書き込まれなかった場合など) は、順序番号が順不同であったり、一部の番号が抜けていたりすると、不正なレコードをより速く検出できる可能性がある 

trail

無効にすると、trailer トークンが監査レコードに追加されない

有効にすると、trailer トークンがすべての監査レコードに追加される

無効にすると、作成される監査レコードが小さくなる 

有効にすると、各監査レコードの最後に trailer トークンが常に付加される。trailer トークンは、多くの場合、デバッグ時に順序トークンとともに使用される。ファイルが破壊した場合 (監査レコードがすべて書き込まれなかった場合など)、auditreduce コマンドによる再同期が、レコードが正常な場合より、早く終了する

監査コストの制御

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

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

処理時間の増大に伴うコストは、監査に関連する 3 つのコストの中ではもっとも重要性の低い問題です。第 1 に、通常は、イメージ処理や複雑な計算処理などの、計算集中型のタスクの実行中には監査処理が発生しないからです。第 2 に、1 人のユーザーだけが使用するシステムのコストは通常小さく、無視してもかまわないからです。

分析に伴うコスト

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

生成するレコードが少ないほど、分析に必要な時間も短くなります。「格納に伴うコスト」および 「効率的な監査」では、収集するデータ量を削減しながら、サイトのセキュリティ要件を実現する方法について説明します。

格納に伴うコスト

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

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

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

監査機能を構成する前に、監査フラグと、フラグが立てられるイベントの種類を理解しておく必要があります。サイトで必要なセキュリティの程度と、管理の対象となるユーザーの種類に基づいて、サイトの監査についての基本ポリシーを設定します。

効率的な監査

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