第 21 章 監査の計画
この章では、インストールした Solaris に対して監査を設定する方法について説明します。特に、監査サービスを有効にする前に、考慮する必要のある問題について説明します。この章の内容は次のとおりです。
監査の概要については、第 20 章「BSM (概要)」を参照してください。サイトで監査を構成する手順については、第 22 章「BSM サービスの管理 (手順)」を参照してください。
監査トレールの処理
監査トレールで使用するファイル領域は、監査にとって大きな問題の 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 ポリシーを設定するを参照 また、監査を無効にした状態で、ログインおよび作業可能なアカウントを作成することもできる。 監査アカウントの例については、例 — 監査管理ログインを作成するを参照 |
使用する監査ポリシーの決定
監査ポリシーを使用して、ローカルホストの監査レコードの特性を決定します。監査ポリシーは、起動スクリプトによって設定されます。監査サービスを有効にする bsmconv スクリプトによって、/etc/security/audit_startup スクリプトが作成されます。audit_startup スクリプトは、auditconfig コマンドを実行することで監査ポリシーを設定します。詳細は、audit_startup(1M) のマニュアルページを参照してください。
監査ポリシーがデフォルトで無効になっているのは、記憶領域要件とシステム処理要求を最小限に抑えるためです。監査ポリシーを動的に有効または無効にするには、auditconfig コマンドを使用します。監査ポリシーを静的に有効または無効にするには、audit_startup スクリプトを使用します。次の表を参照して、1 つまたは複数の監査ポリシーを有効にしたときに発生する追加のオーバーヘッドを考慮しながら、サイトの要件を決定してください。
表 21–1 監査ポリシーの働き
監査コストの制御
監査処理によってシステム資源が消費されるため、どの程度詳しく記録するかを制御する必要があります。監査の対象を決めるときには、監査に伴う次の 3 つのコストを考慮してください。
-
処理時間の増大に伴うコスト
-
監査データの分析に伴うコスト
-
監査データの格納に伴うコスト
監査データの処理時間の増大に伴うコスト
処理時間の増大に伴うコストは、監査に関連する 3 つのコストの中ではもっとも重要性の低い問題です。第 1 に、通常は、イメージ処理や複雑な計算処理などの計算集中型のタスクの実行中には、監査処理が発生しないからです。その他の理由として、単一ユーザーシステムのコストが通常は無視できるほど小さいことが挙げられます。
監査データの分析に伴うコスト
分析に伴うコストは、収集される監査データの量にほぼ比例します。分析コストには、監査レコードをマージして検討するための時間が含まれます。コストにはまた、監査レコードをアーカイブし、それを安全な場所に保管するための時間も含まれます。
生成されるレコードの数が少ないほど、監査トレールの分析にかかる時間も短くなります。以下の項、監査データの格納に伴うコストと 効率的な監査では、効率的に監査を行う方法について説明します。収集するデータの量を削減しながら、サイトのセキュリティ目標を達成することは可能です。
監査データの格納に伴うコスト
格納に伴うコストは、監査コストのうちでもっとも重要です。監査データの量は次の要素によって左右されます。
-
ユーザー数
-
マシン数
-
使用量
-
必要なセキュリティの程度
これらの要因はサイトごとに異なるため、監査データの格納用に前もって確保しておくディスク容量を決定できるような計算式はありません。
all フラグを指定して完全な監査を行うと、ディスクがすぐにいっぱいになります。プログラムのコンパイルといった単純なタスクによってさえ、巨大な監査ファイルが生成される可能性があります。中程度のサイズのプログラムでも、1 分も経たないうちに数千件の監査レコードが生成される可能性があります。たとえば、5 ファイルで合計 5000 行のプログラムの監査トレールが、何 M バイトものディスク容量を占有する可能性があります。事前選択機能を使用して、生成されるレコードの量を減らしておいたほうが賢明です。たとえば、fr クラスを省略すると、監査ボリュームを 3 分の 2 以上も削減できます。また、監査ファイルを効率的に管理することも重要です。監査レコードが生成されたあとにファイル管理を行うことによって、必要なディスク容量を減らせます。
監査を構成する前に、監査フラグを理解しておく必要があります。それらのフラグが監査対象とするイベントの種類を理解しておく必要もあります。適切な基準に基づいて、サイトの監査に関する基本ポリシーを設定します。そのような基準には、サイトで必要なセキュリティの程度や、管理対象ユーザーの種類などが含まれます。
効率的な監査
この節で説明する方法により、組織のセキュリティ目標を達成する一方で、監査効率を高めることができます。
-
ある一定の割合のユーザーのみを任意の時間にランダムに監査する
-
監査ファイルのディスク容量要件を削減するために、監査ファイルを結合、縮小、および圧縮する。ファイルを保管する手順、リムーバブルメディアにファイルを転送する手順、およびファイルをオフラインで格納する手順を決定する
-
監査データの異常な動作をリアルタイムで監視する。特定の動作で生成された監査トレールを監視する手順を設定する。異常なイベントが検出された場合に、それに応じて特定のユーザーまたは特定のマシンの監査レベルを自動的に上げるようなスクリプトを作成する。
たとえば、(1) すべての監査ファイルサーバー上における監査ファイルの作成を監視し、(2) その監査ファイルを tail コマンドを使用して処理するスクリプトを作成する。tail(1) のマニュアルページを参照。tail -0f の出力を praudit コマンドにパイプする。このコマンドは、監査レコードが生成されると監査レコードストリームを生成する。このストリームを分析して、異常なメッセージの種類などを調べ、監査担当者に配布する。また、このスクリプトを使用して、自動応答をトリガーすることもできる。
さらに、このスクリプトには、(3) 監査ディレクトリを常時監視して、新しい not_terminated 監査ファイルが発生していないかを調べるコードを含める必要もある。また、このスクリプトは、(4) 監査ファイルに書き込めなくなったときに、未処理の tail プロセスを終了させる必要もある
- © 2010, Oracle Corporation and/or its affiliates