test

Trusted Solaris の監査管理

サイトでの監査計画

システム管理者、セキュリティ管理者によって最初の Trusted Solaris 用ワークステーションが設定されると、監査が有効になり、デフォルトの監査ロケーション workstation-name:/var/audit に一定数の監査レコードが集められます。セキュリティ管理者は、監査する対象を決定し、イベントとクラスの対応関係をサイト独自の仕様にする (カスタマイズする) かどうかを計画します。システム管理者は、監査ファイルを保存するローカルディスクとリモートディスクの容量、監査管理サーバー、インストールの順番を計画します。

ネットワークに接続されていないワークステーションの監査計画は比較的簡単です。ただ、こうした単独のワークステーションでは、イベントとクラスの対応関係をカスタマイズしても、その時間に見合う効果が得られません。この場合にもっとも重要なのは、作業の効率を落とさないで監査を行うということです。監査パーティションのサイズと場所の計画を立てると、作業の効率低下を防ぐことができます。また、定期保守スケジュールを立てることで、自動的にバックアップをとったり、監査パーティションを解放して、より多くの監査レコードを収集することができます。

監査対象の計画

Trusted Solaris は、ユーザーアクションによるイベントとユーザーアクションを原因としないイベント (監査フラグ na、監査クラス non-attribute) を監査クラスに収集します。このようにして多くのイベントを備えた各監査クラスは、イベントが成功した場合、失敗した場合、またはその両方の場合に監査されます。

監査フラグとそれが示すイベントの種類を理解してから監査を実施してください。サイトに必要なセキュリティの程度と管理するユーザーのタイプに基づいて、監査の方針を立てます。

プロセス監査事前選択マスクが動的に修正されない限り、ユーザーがログインしたときに決定した監査特性は、ログインセッション中すべての子プロセスに引き継がれます。また、データベースが修正されない限り、プロセス事前選択マスクはその後のログインセッションすべてに適用されます。

提供されている監査クラスのリストについては、付録 A 「イベントとクラスの対応関係」を参照してください。リストは、監査クラス別に、各監査イベントに対応するシステムコールまたはユーザーコマンドを示し、監査レコードの書式の説明もしくは参照先を記載しています。

セキュリティ管理者は、サイトのセキュリティポリシーに基づいて監査対象イベントを決定します。システム全体に同じ監査対象を設定できるだけでなく、特定ユーザーに対しては免除したり追加することもできます。

  1. ユーザーアクションを原因としないイベントを監査するかどうか決定します。

    監査フラグ na は、ユーザーアクションを原因としないイベントクラス (non-attribute) を表します。ユーザーアクションを原因としないイベントには、PROM のアクセス、ブート、リモートマウントなどがあります。デフォルトの non-attribute クラスのイベントについては、「監査クラス na のイベント」のリストを参照してください。

    クラスを監査するということは、そのクラスのイベントすべてを監査するということです。ユーザーアクションを原因としないクラスをカスタマイズしたい場合には、「イベントとクラスの対応関係の計画 - サイト独自の設定」を参照してください。

    ユーザーアクションを原因としないイベントを監査するためには、audit_control ファイルの naflags: 行に na フラグを設定します。

  2. イベントが成功した場合に監査するのか、失敗した場合に監査するのか、または成否に関わらず監査するのかを決定します。

    ユーザーアクションを原因としないイベントが成功した場合に監査するには、audit_control ファイルの naflags: 行に次のように記述します。

    naflags:+na

    ユーザーアクションを原因としないイベントが失敗した場合に監査するには、次のように記述します。

    naflags:-na

    ユーザーアクションを原因としないイベントを成否に関わらず監査するには、次のように記述します。

    naflags:na

  3. すべて (all) のイベントを監査するかどうかを決定します。

    注 -

    クラス all には、Trusted Solaris ソフトウェアシステムの監査イベントがすべて含まれます。ただし、特別な状況でない限り、すべてのイベントを監査する必要はありません。

  4. すべてのイベントを監査する場合以外は、監査クラス na 以外についても 手順 1 と 手順 2 を繰り返します。

    最初のワークステーションで監査を設定する場合には、手順 3 、手順 4 での決定も audit_control ファイルに書き込みます。

    naflags: 行に na フラグを入力したのと同じ要領で、audit_control ファイルの flags: 行にフラグを入力します。

  5. 特定のユーザーまたは役割に、システム全体の設定とは異なった監査対象を設定するかどうかを決定します。

    例外を audit_user ファイルに書き込みます。

  6. 整合性を確認します。

    audit_control ファイルの naflags: 行の内容は、Trusted Solaris ネットワークのすべてのワークステーションに共通です。

    audit_control ファイルの flags: 行の内容は、Trusted Solaris ネットワークのすべてのワークステーションに共通です。

    audit_user ファイルの内容は、Trusted Solaris ネットワークのすべてのワークステーションに共通です。

監査対象を計画するときの検討事項

サイトでの監査対象は、サイトの監査ポリシーと、時間、効率、ディスク容量などの監査コストによって決まります。監査コストの説明については、「監査のコストの管理」を参照してください。Trusted Solaris 環境に実装されている監査機能を使用する際は、次の点について検討します。

イベントとクラスの対応関係の計画 - サイト独自の設定

省略可能：この節は、クラスに割り当てるイベントの構成を変更したり、新しいクラスや新しいイベントを作成する場合にお読みください。デフォルトのイベントとクラスの対応関係を使用する場合には、省略してかまいません。

Trusted Solaris の監査クラスは、クラス all を含めて最大 32 個まで設定できます。定義済みのクラスと合わせて 32 個になるまで、サイトで新規クラスを追加できます。

セキュリティ管理者は、クラスとイベントの対応関係を設定します。この対応関係はそのサイトに固有のものです。次の手順に従ってください。

  1. 必要なクラスを決定します。

  2. どのイベントがどのクラスに所属するかを決定します。

    1. 別のクラスにコピーするイベントを決定します。

      監査イベントは複数のクラスに割り当てることができます。たとえば、監査イベント AUE_RENAME は、デフォルトで、file create と file delete の 2 つのクラスに含まれます。

    2. 別のクラスに移動するイベントを決定します。

    3. 別のクラスに追加するイベントを決定します。

  3. クラスごとにイベントの成功、失敗、成功と失敗の両方のうち、どの場合を監査するかを決定します。

    新しいソフトウェアをインストールした場合など、プログラムに Trusted Solaris 7 ソフトウェアが提供するもの以外の監査イベントが含まれている場合には、そのイベントを既存のクラスに追加するか、新しいイベント用のクラスを新規に作成します。

イベントとクラスの対応関係を変更するときの検討事項

Trusted Solaris 環境で監査クラスの内容のデフォルトを変更して新しいクラスを作成するときは、次の要素を検討します。

監査レコード用の容量の計画

ネットワークに接続されていないワークステーションの監査レコードを保存するには、監査レコード専用のローカルパーティションを少なくとも 2 つ設定し、1 つを主パーティション、1 つをバックアップ用パーティションとして、保守スケジュールを組む必要があります。

一方、複数のワークステーションによるネットワークで監査レコードを保存するには、監査レコード専用のローカルパーティション (バックアップパーティション) と、複数の監査サーバーによるネットワーク、さらに監査管理サーバー 1 台を設定する必要があります。各監査サーバーにはリモートホストの監査レコードを保存するためのパーティション (主パーティション) がおかれています。監査サーバーからは、監査トレール全体を監視することができます。監査トレールとは、ネットワーク上の各ワークステーションで作成される監査ファイルのことです。また、監査ファイルとは、ワークステーションで生成される監査レコードを保持するためのファイルのことです。

ネットワークに接続されていないワークステーションの容量の計画

ネットワークに接続されていないワークステーションでは、監査レコードを保持するディスクパーティションのサイズを決定します。効率化のためには、監査レコードを別々のディスクに配置するのがいちばんです。また、安全のためには、そのディスクに 2 つの監査パーティションを設定して、1 つを主な記憶領域とし、もう 1 つを最初のパーティションがいっぱいになった場合のバックアップ記憶領域とするとよいでしょう。ファイルシステムのセキュリティ属性を設定して、監査トレールがのぞき見されないように、監査ディレクトリで制御します。

  1. 監査レコードをバックアップするまでの監査量を推定します。

    セキュリティ上の必要性と監査トレールの保存に使用できるディスク容量とのバランスを検討します。

    ワークステーション 1 台あたりのディスク容量は約 200M バイトですが、必要なディスク容量は監査の処理量によって変わり、この値を大幅に上回ることもあります。監査トレールの保存に使用するディスク所要量を削減したい場合は、「監査のコストの管理」、 「監査の効率」を参照してください。

  2. 監査ファイルシステムがディスク残量の減少を警告するタイミングを決定します。

    audit_control ファイルで、監査パーティションの minfree しきい値を規定します。これはディスクの残量の割合であり、この値に達すると、audit_warn エイリアスによって、監査管理者に、ディスク残量が少なくなったことを知らせる電子メールが送られます。デフォルトでは、ディスク残量が 20% になると警告が送信されます。minfree しきい値は変更可能です。

ネットワークでのディスク容量の計画

ネットワークに接続されたシステムには、ユーザーのワークステーションの監査ファイルを保存する監査サーバー、中央で監査結果の分析とバックアップを行う監査管理サーバーが必要です。また、各ワークステーションにローカル監査パーティションを用意する必要があります。ディレクトリとマウント先にファイルシステムのセキュリティ属性を設定し、監査トレールがのぞき見されないようにします。のワークシートを使って監査計画の内容を記録してください。別の方法で監査ネットワークの設定を記録してもかまいません。

  1. サイトで必要な監査量を決定します。

    セキュリティ上の必要性と監査トレールの保存に使用できるディスク容量とのバランスを検討します。

    分散システム上のワークステーション 1 台あたりのディスク容量は約 200M バイトですが、サイトで必要なディスク容量は監査の処理量によって変わり、この値を大幅に上回ることもあります。監査専用ローカルディスクとリモートディスクを両方とも準備できる場合には、各ディスクをそれぞれ 2 つの監査パーティションに分けてもよいでしょう。サイトのセキュリティを保守しながら監査トレールの保存に使用するディスク容量を削減したい場合は、「監査のコストの管理」、 「監査の効率」を参照してください。

  2. 監査ファイルシステムがディスク残量の減少を警告するタイミングを決定します。

    audit_control ファイルで監査パーティションの minfree しきい値を規定します。minfree しきい値はディスクの残量の割合であり、この値に達すると、audit_warn エイリアスによって監査管理者に、ディスク残量が少なくなったことを知らせる電子メールが送られます。デフォルトでは、ディスク残量が 20% になると、警告が送信されます。minfree しきい値は変更可能です。

  3. 監査サーバーとなるワークステーションを決定します。

    システム管理者とセキュリティ管理者が共同で監査サーバー用ワークステーションのインストールを行なってから、監査クライアント用ワークステーションのインストールを行います。

  4. ワークステーションごとにローカル監査パーティションの計画を立てます。

    ローカルパーティションは、監査サーバーのパーティションがいっぱいになった場合やネットワークを利用できない場合のバックアップパーティションです。

  5. クライアントが使用する監査サーバーと監査ファイルシステムを決定します。

    監査ネットワークのレイアウトを決定します。次の図は、リモートホストの監査レコードを格納するために使用できるファイルシステム /etc/security/audit/egret[.n]/files を持った、監査サーバー egret を示します。

    図 2-1 監査サーバー egret の監査ファイルシステム

    Graphic

  6. 命名規則に従って監査ファイルシステムに名前を付けます。

    図からわかるように、ワークステーションの監査ファイルシステムには、次のような命名規則があります。

    /etc/security/audit/workstationname/files
/etc/security/audit/workstationname.1/files
/etc/security/audit/workstationname.2/files
/etc/security/audit/workstationname.3/files ...

    命名規則については、「監査ファイルの保存場所」を参照してください。

監査の実施計画

ワークステーションに監査計画を実施する作業は、システム管理者とセキュリティ管理者が共同で行います。システム管理者が担当するのは、ディスクと監査サーバーのネットワークの設定であり、セキュリティ管理者が担当するのは、監査対象の決定と、その情報を監査構成ファイルに書き込む作業です。監査ネットワークの設定はシステム管理者とセキュリティ管理者が共同で行います。監査ネットワークには、次のような特徴を持たせてください。