Trusted Solaris は、ユーザーアクションによるイベントとユーザーアクションを原因としないイベント (監査フラグ na、監査クラス non-attribute) を監査クラスに収集します。このようにして多くのイベントを備えた各監査クラスは、イベントが成功した場合、失敗した場合、またはその両方の場合に監査されます。
監査フラグとそれが示すイベントの種類を理解してから監査を実施してください。サイトに必要なセキュリティの程度と管理するユーザーのタイプに基づいて、監査の方針を立てます。
プロセス監査事前選択マスクが動的に修正されない限り、ユーザーがログインしたときに決定した監査特性は、ログインセッション中すべての子プロセスに引き継がれます。また、データベースが修正されない限り、プロセス事前選択マスクはその後のログインセッションすべてに適用されます。
提供されている監査クラスのリストについては、付録 A 「イベントとクラスの対応関係」を参照してください。リストは、監査クラス別に、各監査イベントに対応するシステムコールまたはユーザーコマンドを示し、監査レコードの書式の説明もしくは参照先を記載しています。
セキュリティ管理者は、サイトのセキュリティポリシーに基づいて監査対象イベントを決定します。システム全体に同じ監査対象を設定できるだけでなく、特定ユーザーに対しては免除したり追加することもできます。
ユーザーアクションを原因としないイベントを監査するかどうか決定します。
監査フラグ na は、ユーザーアクションを原因としないイベントクラス (non-attribute) を表します。ユーザーアクションを原因としないイベントには、PROM のアクセス、ブート、リモートマウントなどがあります。デフォルトの non-attribute クラスのイベントについては、「監査クラス na のイベント」のリストを参照してください。
クラスを監査するということは、そのクラスのイベントすべてを監査するということです。ユーザーアクションを原因としないクラスをカスタマイズしたい場合には、「イベントとクラスの対応関係の計画 - サイト独自の設定」を参照してください。
ユーザーアクションを原因としないイベントを監査するためには、audit_control ファイルの naflags: 行に na フラグを設定します。
イベントが成功した場合に監査するのか、失敗した場合に監査するのか、または成否に関わらず監査するのかを決定します。
ユーザーアクションを原因としないイベントが成功した場合に監査するには、audit_control ファイルの naflags: 行に次のように記述します。
naflags:+na
ユーザーアクションを原因としないイベントが失敗した場合に監査するには、次のように記述します。
naflags:-na
ユーザーアクションを原因としないイベントを成否に関わらず監査するには、次のように記述します。
naflags:na
すべて (all) のイベントを監査するかどうかを決定します。
クラス all には、Trusted Solaris ソフトウェアシステムの監査イベントがすべて含まれます。ただし、特別な状況でない限り、すべてのイベントを監査する必要はありません。
すべてのイベントを監査する場合以外は、監査クラス na 以外についても 手順 1 と 手順 2 を繰り返します。
最初のワークステーションで監査を設定する場合には、手順 3 、手順 4 での決定も audit_control ファイルに書き込みます。
naflags: 行に na フラグを入力したのと同じ要領で、audit_control ファイルの flags: 行にフラグを入力します。
特定のユーザーまたは役割に、システム全体の設定とは異なった監査対象を設定するかどうかを決定します。
例外を audit_user ファイルに書き込みます。
整合性を確認します。
audit_control ファイルの naflags: 行の内容は、Trusted Solaris ネットワークのすべてのワークステーションに共通です。
audit_control ファイルの flags: 行の内容は、Trusted Solaris ネットワークのすべてのワークステーションに共通です。
audit_user ファイルの内容は、Trusted Solaris ネットワークのすべてのワークステーションに共通です。
サイトでの監査対象は、サイトの監査ポリシーと、時間、効率、ディスク容量などの監査コストによって決まります。監査コストの説明については、「監査のコストの管理」を参照してください。Trusted Solaris 環境に実装されている監査機能を使用する際は、次の点について検討します。
監査対象ごとに監査レコードが作成されるため、すぐにディスクが占有されてしまう
最初は監査対象を少なくしておいて、監査パーティションがいっぱいになるタイミングを確認しましょう。こうすると、経験に基づいてディスクの必要量を推定したり、監査ファイルの保存の計画を立てることができます。監査トレールのサイズの見当がつけば、監査クラスを細かく設定することができます。
監査クラスに含まれるイベント数によって生成されるレコードの数が決まるわけではない
file read クラスには login or logout クラスとほぼ同数のイベントがありますが、file read クラスのイベントの成功を監査するように設定すると、login or logout クラスに同様の設定をした場合に比べて、生成されるレコードの数がかなり多くなります。
失敗したイベントの監査では異常なイベントが検出され、成功したイベントの監査ではシステムの使用状況が監視される
サイトポリシーでシステムの使用状況を監視するように定められている場合には、監査トレールに使用する容量を、異常なイベントを監査する場合より多めに確保しておくとよいでしょう。
失敗したイベントの監査では、成功したイベントの監査ほど多くのレコードが生成されない
たとえば、熟練したユーザーで構成される Trusted Solaris システムで file read イベントの失敗を監査した場合、file read クラスのイベントの成功を監査する場合に比べて、生成されるレコードの数がかなり少なくなります。
監査クラスごとに構成を変えたり、新しい監査クラスを設定すると、より効率的にサイトの要件を満たすことができる。また、サイトポリシーで特に監査するよう定められていない監査イベントを除外すると、監査トレールのサイズを小さくすることができる
たとえば、デバイス用のクラス de を作成した場合について考えましょう。デバイスを構成する際に、クラス de の成功したイベントを監査すると、構成とテストの完了したデバイスの監査レコードが得られます。すべてのデバイスが構成されたら、今度はクラス de の失敗したイベントを監査します。
一部のクラスを断続的に監査するように設定した場合でも、サイトの要件を満たすことができる
たとえば、上の例の監査クラス de を断続的に監査することもできます。cron ジョブ (auditconfig(1M) コマンド) を使って、特定のクラスの監査の有効と無効を切り替えたり、別の監査フラグを動的に設定することができます。