Solaris のシステム管理 (セキュリティサービス)

監査サービスの構成 (作業マップ)

この節では、監査サービスを構成して有効にするために必要な作業について説明します。次の作業マップは、監査サービスの構成に必要な作業の一覧です。

作業	説明	参照先
1. (省略可能) 監査構成ファイルの変更	監査を必要とするイベント、クラス、およびユーザーを選択する	監査ファイルの構成 (作業マップ)
2. 監査パーティションの作成	監査ファイルのパーティションを作成する	監査パーティションの作成方法
3. `audit_warn` 別名の作成	電子メール警告を送信するユーザーを定義する	`audit_warn` 別名の構成方法
4. (省略可能) 監査ポリシーの変更	追加の監査レコードや監査条件を定義する	監査ポリシーを有効または無効にする方法
5. 監査の有効化	監査を有効にする	監査を有効にする方法
6. (省略可能) 監査の無効化	監査を無効にする	監査を無効にする方法
7. (省略可能) デバイス割り当ての開始	より安全にアクセスできるリムーバブルメディアを選択する	デバイス割り当ての管理 (作業)

監査パーティションの作成方法

次の手順では、監査ファイル用のパーティションの作成方法、および監査に対応するファイルシステムとディレクトリの作成方法について説明します。すでに空のパーティションがある場合、またはすでに空のファイルシステムをマウントしている場合は、必要に応じて手順を省略してください。

スーパーユーザーになるか、同等の役割を引き受けます。

必要なディスク容量を決定します。

ホストごとに 200M バイト以上を割り当てます。ただし、ディスク容量の要件は、実行する監査のボリュームによって異なります。つまり、ディスク容量の要件が割り当てる数値を超えることがあります。予備ディレクトリのパーティション領域も含めてください。

必要に応じて、監査パーティションを作成します。

この手順は、サーバーのインストール時に実行するのが最も簡単です。サーバーにマウントされていないディスク上にパーティションを作成することもできます。パーティション作成方法の詳細については、『Solaris のシステム管理 (基本編)』の「UFS ファイルシステムの作成」を参照してください。
# newfs /dev/rdsk/cwtxdysz
/dev/rdsk/cwtxdysz は、パーティションの raw デバイス名です。

ローカルホストを監査する場合は、予備の監査ディレクトリも作成します。

新しいパーティションのマウント先を作成します。
# mkdir /var/audit/server-name.n
server-name.n は、サーバー名と各パーティションの識別番号を結合したものです。この識別番号は省略できますが、多数の監査ディレクトリを作成する場合はこの番号を使用すると便利です。

新しいパーティションを自動的にマウントするエントリを追加します。

/etc/vfstab ファイルに次のような行を追加します。
/dev/dsk/cwtxdysz /dev/rdsk/cwtxdysz /var/audit/server-name.n ufs 2 yes

(省略可能) 各パーティションの最小空き容量のしきい値を削除します。

デフォルトの構成を使用した場合、ディレクトリの 80% がいっぱいになった時点で警告が生成されます。このため、パーティション上に空き容量を予約する必要はありません。
# tunefs -m 0 /var/audit/server-name.n

新しい監査パーティションをマウントします。
# mount /var/audit/server-name.n

新しいパーティションに監査ディレクトリを作成します。
# mkdir /var/audit/server-name.n/files

マウント先と新しいディレクトリへのアクセス権を訂正します。
# chmod -R 750 /var/audit/server-name.n/files

(省略可能) ファイルサーバー上で、ほかのホストからアクセスできるファイルシステムを定義します。

通常は、監査レコードを格納するために、ディスクファームをインストールします。監査ディレクトリを複数のシステムで使用する場合は、そのディレクトリを NFS サービスを通して共有する必要があります。/etc/dfs/dfstab ファイルに対して、次のようなエントリをディレクトリごとに追加します。
share -F nfs /var/audit/server-name.n/files

(省略可能) ファイルサーバー上で、NFS サービスを起動し直します。

share コマンドまたは share コマンドセットをはじめて実行する場合、NFS デーモンが動作していないことがあります。次のコマンドでデーモンを終了し、再起動してください。NFS サービスの詳細については、『Solaris のシステム管理 (資源管理とネットワークサービス)』の「NFS サービスの設定」を参照してください。
# /etc/init.d/nfs.server stop # /etc/init.d/nfs.server start

例 — 予備の監査ディレクトリを作成する

監査サブシステムを実行するすべてのシステムには、利用できるファイルシステムがほかにない場合に使用するローカルファイルシステムが必要です。この例では、ファイルシステムが egret という名前のシステムに追加されます。このファイルシステムは、ローカルシステムだけで使用されるため、続いてファイルサーバーの手順は必要ありません。

# newfs /dev/rdsk/c0t2d0
# mkdir /var/audit/egret
# grep egret /etc/vfstab
/dev/dsk/c0t2d0s1  /dev/rdsk/c0t2d0s1  /var/audit/egret ufs  2  yes  -
# tunefs -m 0 /var/audit/egret
# mount /var/audit/egret
# mkdir /var/audit/egret/files
# chmod -R 750 /var/audit/egret/files

例 — 新しい監査パーティションを作成する

この例では、新しいファイルシステムが、2 つの新しいディスクに作成されます。この 2 つのディスクは、ネットワーク上のほかのシステムと共有します。

# newfs /dev/rdsk/c0t2d0
# newfs /dev/rdsk/c0t2d1
# mkdir /var/audit/egret.1
# mkdir /var/audit/egret.2
# grep egret /etc/vfstab
/dev/dsk/c0t2d0s1  /dev/rdsk/c0t2d0s1  /var/audit/egret.1 ufs  2  yes  -
/dev/dsk/c0t2d1s1  /dev/rdsk/c0t2d1s1  /var/audit/egret.2 ufs  2  yes  -
# tunefs -m 0 /var/audit/egret.1
# tunefs -m 0 /var/audit/egret.2
# mount /var/audit/egret.1
# mount /var/audit/egret.2
# mkdir /var/audit/egret.1/files
# mkdir /var/audit/egret.2/files
# chmod -R 750 /var/audit/egret.1/files /var/audit/egret.2/files
# grep egret /etc/dfs/dfstab
 share -F nfs /var/audit/egret.1/files
 share -F nfs /var/audit/egret.2/files
# /etc/init.d/nfs.server stop
# /etc/init.d/nfs.server start

`audit_warn` 別名の構成方法

audit_warn スクリプトは、audit_warn という別名に対してメールを生成します。このメールを有効な電子メールアドレスに送信するには、次のいずれかのオプションを行います。

スーパーユーザーになるか、同等の役割を引き受けます。

audit_warn メール別名を構成します。
「オプション 1」 –
audit_warn スクリプトで、audit_warn 別名をほかのメールアカウントに置き換えます。

audit_warn を root アカウントに置き換えると、電子メールメッセージを送信する行は次のようになります。
/usr/ucb/mail -s "$SUBJECT" root
audit_warn スクリプト内の 10 行にこの変更を適用する必要があります。
「オプション 2」 –
audit_warn の電子メールをほかのメールアカウントにリダイレクトします。

この場合、audit_warn 別名を適切なメール別名ファイルに追加します。別名の追加先として、ローカルの /etc/mail/aliases ファイル、名前空間の mail_aliases データベースのいずれかを選択します。root メールアカウントを audit_warn 別名のメンバーとして登録する場合、新しいエントリは次のようになります。
audit_warn: root

監査ポリシーを有効または無効にする方法

監査ポリシーを使用して、ローカルホストの監査レコードの特性を決定します。デフォルトでは、すべての監査ポリシーが無効になっています。使用する監査ポリシーは、有効にする必要があります。各ポリシーについては、監査ポリシーを参照してください。

プログラムレベルで auditon() システムコールを行なって、現在の監査ポリシーを調査したり、有効または無効にしたりすることができます。また、auditconfig コマンドを実行して同じタスクを行うこともできます。また、監査ポリシーの変更内容を固定するために、audit_startup スクリプト内で auditconfig コマンドの監査ポリシーオプションを変更することも可能です。

スーパーユーザーになるか、同等の役割を引き受けます。

(省略可能) 既存の監査ポリシーを確認します。

監査ポリシーを変更するときは、現在使用されているポリシーをすべて確認してください。次のコマンドを実行すると、有効なポリシーがすべて表示されます。
# auditconfig -lspolicy

監査ポリシーを有効または無効にします。
# auditconfig -setpolicy flagpolicyname
flag

flag に + を指定すると、ポリシーが有効になる。flag に - を指定すると、ポリシーが無効になる

policyname

有効または無効にするポリシーを選択する

このポリシーの設定は、次回ブートするまで、または auditconfig -setpolicy コマンドを使ってポリシーを変更するまで持続します。

例 — `cnt` ポリシーを設定する

cnt ポリシーを設定すると、監査パーティションがいっぱいになっても、プロセスはブロックされません。パーティションがいっぱいになるとレコードは破棄されますが、システムは機能し続けます。cnt ポリシーを有効にすると、破棄された監査レコードのカウント数が記録されます。セキュリティを重視する場合は、cnt ポリシーは設定しないでください。ファイルシステムがいっぱいになると、イベントが記録されないことがあるためです。

次のコマンドを実行すると、cnt ポリシーが有効になります。

# auditconfig -setpolicy +cnt

リブートしてもポリシーの設定を維持させるには、auditconfig -setpolicy +cnt コマンドを audit_startup ファイルに追加する必要があります。

監査を有効にする方法

この操作では、監査サービスが開始されます。監査サービスが構成されている場合は、ホストをリブートしたときにもサービスが開始します。

スーパーユーザーになるか、同等の役割を引き受けます。

システムをシングルユーザーモードにします。
# /etc/telinit 1
詳細は、telinit(1M) のマニュアルページを参照してください。

スクリプトを実行して、システムが監査を実行するように構成します。

/etc/security ディレクトリに移動し、bsmconv スクリプトを実行します。このスクリプトは、リブート後に標準 Solaris マシンが監査を実行するよう設定します。bsmconv(1M) のマニュアルページを参照してください。
# cd /etc/security # ./bsmconv

システムをマルチユーザーモードにします。
# /etc/telinit 6
システムがマルチユーザーモードに移行すると、起動ファイル /etc/security/audit_startup によって監査デーモンが自動的に動作します。

監査を無効にする方法

監査が不要になった時点で、bsmunconv コマンドを実行して、監査サブシステムを無効にすることができます。bsmconv(1M) のマニュアルページを参照してください。

スーパーユーザーになるか、同等の役割を引き受けます。

システムをシングルユーザーモードにします。
# /etc/telinit 1
詳細は、telinit(1M) のマニュアルページを参照してください。

スクリプトを実行して、監査を無効にします。

/etc/security ディレクトリに移動し、bsmunconv スクリプトを実行します。
# cd /etc/security # ./bsmunconv

システムをマルチユーザーモードにします。
# /etc/telinit 6