第 29 章 Solaris 監査の計画
この章では、インストールした Solaris に対して監査サービスを設定する方法について説明します。特に、監査サービスを有効にする前に、考慮する必要のある問題について説明します。この章の内容は次のとおりです。
監査の概要は、第 28 章Solaris 監査 (概要)を参照してください。ご使用のシステムで監査を設定する手順については、第 30 章Solaris 監査の管理 (作業)を参照してください。参照情報については、第 31 章Solaris 監査 (参照)を参照してください。
Solaris 監査の計画 (作業マップ)
次の作業マップは、ディスク容量および記録するイベントの計画に必要とされる主要な作業を示しています。
|
作業 |
参照先 |
|---|---|
|
非大域ゾーンの監査計画を決定します | |
|
監査トレールの記憶領域容量を計画します | |
|
監査対象者と監査対象イベントを決定します |
Solaris 監査の計画 (作業)
監査する動作の種類を適切に選択し、有用な監査情報を収集することが望まれます。監査ファイルはすぐに大きくなり、空き領域がなくなる可能性があるため、十分なディスク容量を割り当てる必要があります。監査対象者と監査対象も注意して計画する必要があります。
ゾーン内の監査の計画方法
システムでゾーンが実装されている場合、監査を構成する方法が 2 つあります。
-
すべてのゾーンに対して大域ゾーン内で単一の監査サービスを構成できます。
-
ゾーンごとに監査サービスを 1 つずつ構成できます。
トレードオフについては、「ゾーンを含むシステムでの監査」を参照してください。
-
次のいずれかの方法を選択します。
-
オプション 1 - すべてのゾーンに対して単一の監査サービスを構成します。
すべてのゾーンを同様に監査する場合、単一イメージの監査トレールが作成される可能性があります。単一イメージの監査トレールが作成されるのは、システム上のすべてのゾーンが 1 つの管理ドメインの一部になっている場合です。その場合、すべてのゾーン内のレコードが同一の設定に基づいて事前選択されるため、監査レコードの比較が容易に行えます。
この構成では、すべてのゾーンが 1 つのシステムの一部として扱われます。大域ゾーンがシステム上で唯一の監査デーモンを実行して、すべてのゾーンに対して監査ログを収集します。監査構成ファイルのカスタマイズを大域ゾーン内でのみ行ったあと、それらの監査構成ファイルをすべての非大域ゾーンにコピーします。
-
audit_control ファイルを大域ゾーンからすべての非大域ゾーンにコピーします。
-
すべてのゾーンで同じ audit_user データベースを使用します。
audit_user データベースは、ローカルファイルでも、共有されたネームサービスから取得してもかまいません。
-
ゾーンに基づいて監査レコードを選択できるようにします。
ゾーン名を監査レコードの一部として含めるには、大域ゾーンで 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 監査ログの構成方法」を参照してください。
監査ポリシーの決定
監査ポリシーを使用して、ローカルシステムの監査レコードの特性を決定します。監査ポリシーオプションは、起動スクリプトによって設定されます。監査サービスを有効にする bsmconv スクリプトによって、/etc/security/audit_startup スクリプトが作成されます。audit_startup スクリプトは、auditconfig コマンドを実行することで監査ポリシーを設定します。スクリプトの詳細は、audit_startup(1M) のマニュアルページを参照してください。
ほとんどの監査ポリシーオプションがデフォルトで無効になっているのは、記憶領域要件とシステム処理要求を最小限に抑えるためです。監査ポリシーオプションを動的に有効または無効にするには、auditconfig コマンドを使用します。監査ポリシーオプションを永続的に有効または無効にするには、audit_startup スクリプトを使用します。
次の表を参照して、1 つまたは複数の監査ポリシーオプションを有効にしたときに発生する追加のオーバーヘッドを考慮しながら、サイトの要件を決定してください。
表 29–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 ファイル内の監査レコードを処理できます。
また、特定の動作に対して監査トレールを監視する手順を設定します。異常なイベントが検出された場合に、それに応じて特定のユーザーまたは特定のシステムの監査レベルを自動的に上げるようなスクリプトを作成します。
-
すべての監査ファイルサーバー上における監査ファイルの作成を監視します。
-
tail コマンドを使用して、監査ファイルを処理します。
tail -0f コマンドから praudit コマンドに出力をパイプすることにより、レコードが生成されたときに監査レコードのストリームを生成できます。詳細は、tail(1) のマニュアルページを参照してください。
-
このストリームを分析して異常なメッセージの種類やほかの兆候を調べ、または監査担当者に分析を配信します。
また、このスクリプトを使用して、自動応答を発生させることもできます。
-
監査ディレクトリを常時監視して、新しい not_terminated 監査ファイルが発生していないかを調べます。
-
監査ファイルに書き込めなくなったときに、未処理の tail プロセスを終了します。
-
- © 2010, Oracle Corporation and/or its affiliates