監査処理によってシステムリソースが消費されるため、どの程度詳しく記録するかを制御する必要があります。監査の対象を決めるときには、監査に伴う次の 3 つのコストを考慮してください。
処理時間の増大に伴うコスト
監査データの分析に伴うコスト
デフォルトのプラグイン audit_binfile を使用している場合は、監査データのストレージコストも考慮する必要があります。
処理時間の増大に伴うコストは、監査に関連する 3 つのコストの中ではもっとも重要性の低い問題です。通常、イメージ処理や複雑な計算処理などの計算集中型のタスクの実行中には、監査処理が発生しません。また、audit_binfile プラグインを使用している場合は、監査管理者が、事後選択のタスクを監査対象システムから監査データの分析専用のシステムに移動できます。最後に、カーネルイベントが事前選択されていないかぎり、監査サービスがシステム性能に測定可能な影響を与えることはありません。
分析に伴うコストは、収集される監査データの量にほぼ比例します。分析コストには、監査レコードをマージして検討するための時間が含まれます。
audit_binfile プラグインで収集されるレコードの場合は、レコードやそれをサポートしているネームサービスデータベースをアーカイブしたり、それらのレコードを安全な場所に保管したりするために必要な時間もコストに含まれます。サポートしているデータベースには、groups、hosts、および passwd が含まれています。
生成されるレコードの数が少ないほど、監査トレールの分析にかかる時間も短くなります。以降のセクション、監査データの格納に伴うコストおよび効率的な監査では、効率的に監査する方法について説明します。効果的な監査では、収集するデータの量を削減しながら、サイトのセキュリティー目標を達成します。
audit_binfile プラグインを使用している場合は、ストレージコストが監査のもっとも大きなコストになります。監査データの量は次の要素によって左右されます。
ユーザー数
システム数
使用量
要求される追跡容易性と説明義務の程度
これらの要因はサイトごとに異なるため、監査データの格納用に前もって確保しておくディスク容量を決定できるような計算式はありません。次の情報を参考にしてください。
監査クラスを理解します。
監査を構成する前に、クラスに含まれるイベントの種類を理解しておく必要があります。監査のイベントからクラスへのマッピングを変更すると、監査レコード収集を最適化できます。
監査クラスを慎重に事前選択し、生成されるレコードの量を減らします。
完全な監査、つまり –all クラスを使用した監査では、ディスク容量がすぐにいっぱいになります。プログラムのコンパイルといった単純なタスクによってさえ、巨大な監査ファイルが生成される可能性があります。中程度のサイズのプログラムでも、1 分も経たないうちに数千件の監査レコードが生成される可能性があります。
たとえば、–file_read 監査クラス fr を省くと、監査ボリュームを著しく削減できます。失敗した処理だけの監査を選択すると、監査ボリュームが減ることもあります。たとえば、失敗した file_read 処理 -fr のみを監査すると、すべての file_read イベントの監査よりも生成されるレコードを大幅に少なくすることができます。
audit_binfile プラグインを使用している場合は、監査ファイルの効率的な管理も重要です。たとえば、監査ファイル専用の ZFS ファイルシステムを圧縮できます。
サイトの監査方針を策定します。
サイトで必要な追跡容易性の程度や、管理対象ユーザーの種類などの基準に基づいて、方針を策定します。