audit_binfile プラグインを使用している場合は、ストレージコストが監査のもっとも大きなコストになります。監査データの量は次の要素によって左右されます。
ユーザー数
システム数
使用量
要求される追跡容易性と説明義務の程度
これらの要因はサイトごとに異なるため、監査データの格納用に前もって確保しておくディスク容量を決定できるような計算式はありません。次の情報を参考にしてください。
監査クラスを理解します。
監査を構成する前に、クラスに含まれるイベントの種類を理解しておく必要があります。監査のイベントからクラスへのマッピングを変更すると、監査レコード収集を最適化できます。
監査クラスを慎重に事前選択し、生成されるレコードの量を減らします。
完全な監査、つまり –all クラスを使用した監査では、ディスク容量がすぐにいっぱいになります。プログラムのコンパイルといった単純なタスクによってさえ、巨大な監査ファイルが生成される可能性があります。中程度のサイズのプログラムでも、1 分も経たないうちに数千件の監査レコードが生成される可能性があります。
たとえば、–file_read 監査クラス fr を省くと、監査ボリュームを著しく削減できます。失敗した処理だけの監査を選択すると、監査ボリュームが減ることもあります。たとえば、失敗した file_read 処理 -fr のみを監査すると、すべての file_read イベントの監査よりも生成されるレコードを大幅に少なくすることができます。
audit_binfile プラグインを使用している場合は、監査ファイルの効率的な管理も重要です。たとえば、監査ファイル専用の ZFS ファイルシステムを圧縮できます。
サイトの監査方針を策定します。
サイトで必要な追跡容易性の程度や、管理対象ユーザーの種類などの基準に基づいて、方針を策定します。