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

監査サービスの構成と有効化 (手順)

構成ファイルをサイト用に構成したあと、監査ファイルのディスク容量を設定する必要があります。監査サービスのほかの属性を設定して、サービスを有効にする必要もあります。この節では、構成の設定を変更したときに監査サービスを更新する手順も説明します。

非大域ゾーンがインストールされている場合、監査対象の大域ゾーンと同じようにゾーンを監査することができます。非大域ゾーンを別々に監査する場合は、非大域ゾーンの監査構成ファイルを変更することができます。監査構成ファイルをカスタマイズする方法については、「監査ファイルの構成 (作業マップ)」を参照してください。

監査ファイルのパーティションの作成方法

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

Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

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

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

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

この手順は、サーバーのインストール時に実行するのがもっとも簡単です。サーバーにマウントされていないディスク上にパーティションを作成することもできます。パーティションの作成方法については、『Solaris のシステム管理 (デバイスとファイルシステム)』の第 11 章「ディスクの管理 (手順)」を参照してください。
# newfs /dev/rdsk/cwtxdysz
この例で、 /dev/rdsk/cwt xdysz は、パーティションの 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 サービスを起動し直します。

このコマンドが、ユーザーが起動した最初の 1 つまたは複数の share コマンドの場合、NFS デーモンが実行されていないことがあります。
- NFS サービスがオフラインの場合、サービスを有効にします。
  % svcs \*nfs\* disabled Nov_02 svc:/network/nfs/rquota:default offline Nov_02 svc:/network/nfs/server:default # svcadm enable network/nfs/server
- NFS サービスが実行中の場合、サービスを再起動します。
  % svcs \*nfs\* online Nov_02 svc:/network/nfs/client:default online Nov_02 svc:/network/nfs/server:default # svcadm restart network/nfs/server
NFS サービスの詳細は、『Solaris のシステム管理 (ネットワークサービス)』の「NFS サービスの設定」を参照してください。永続的なサービスの管理の詳細は、『Solaris のシステム管理 (基本編)』の第 18 章「サービスの管理 (概要)」および smf(5) のマニュアルページを参照してください。

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

監査サービスを実行するすべてのシステムには、利用できるファイルシステムがほかにない場合に使用するローカルファイルシステムが必要です。この例では、ファイルシステムが 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

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

この例では、新しいファイルシステムが、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
# svcadm enable network/nfs/server

例 30–15 ZFS 監査パーティションを作成する

この例では、管理者は、ZFS 監査パーティションの作成後に script コマンドを実行します。コマンドの出力は次のとおりです。

# zpool create auditf mirror c0t4d0 c0t5d0
# zfs create -o mountpoint=/audit auditf/audit
# zfs create auditf/audit/noddy
# zfs create auditf/audit/noddy/files
# zfs create auditf/audit/blinken
# zfs create auditf/audit/blinken/files
# zfs set devices=off auditf/audit
# zfs set exec=off auditf/audit
# zfs set setuid=off auditf/audit
# zfs set sharenfs=on auditf/audit
# share
-               /audit/blinken/files   rw   ""
-               /audit/noddy   rw   ""
-               /audit/blinken   rw   ""
-               /audit/noddy/files   rw   ""
-               /audit   rw   ""
# ^D
script done on Fri Apr 10 10:10:20 2009

次に、遠隔システム remotesys からのマウントを表示します。

# dfshares remotesys
RESOURCE                             SERVER ACCESS    TRANSPORT
remotesys:/audit/blinken/files       remotesys  -         -
remotesys:/audit/noddy               remotesys  -         -
remotesys:/audit/blinken             remotesys  -         -
remotesys:/audit/noddy/files         remotesys  -         -
remotesys:/audit                     remotesys  -         -

最後に、/audit ファイルシステムを /var/audit にマウントします。

# mount remotesys:/audit /var/audit
# ls /var/audit
blinken  noddy

`audit_warn` 電子メールエイリアスの構成方法

audit_warn スクリプトは、audit_warn という電子メールエイリアスに対してメールを生成します。有効な電子メールアドレスにこのメールを送信するには、手順 2 で説明するオプションのいずれか 1 つに従います。

Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

audit_warn 電子メールエイリアスを構成します。

次のオプションのいずれかを選択します。
- オプション 1 – audit_warn スクリプトで、audit_warn 電子メールエイリアスをほかの電子メールアカウントに置き換えます。
  
  スクリプトの次の行で電子メールエイリアスを変更します。
  ADDRESS=audit_warn # standard alias for audit alerts
- オプション 2 – audit_warn 電子メールをほかの電子メールアカウントにリダイレクトします。
  
  この場合、audit_warn 電子メールエイリアスを適切なメールエイリアスファイルに追加します。別名の追加先として、ローカルの /etc/mail/aliases ファイル、名前空間の mail_aliases データベースのいずれかを選択します。root 電子メールアカウントを audit_warn 電子メールエイリアスのメンバーとして登録する場合、新しいエントリは次のようになります。
  audit_warn: root

監査ポリシーを構成する方法

監査ポリシーを使用して、ローカルホストの監査レコードの特性を決定します。監査が有効な場合、/etc/security/audit_startup ファイルの内容により、監査ポリシーが決まります。

auditconfig コマンドを使用すると、現在の監査ポリシーオプションを検査および変更できます。また、監査ポリシーの変更内容を固定するために、audit_startup スクリプト内で auditconfig コマンドの監査ポリシーオプションを変更することも可能です。

Audit Control プロファイルを含む役割を引き受けるか、スーパーユーザーになります。

Audit Control プロファイルを含む役割を作成する方法およびユーザーに役割を割り当てる方法については、「RBAC の構成 (作業マップ)」を参照してください。

監査ポリシーを確認します。

監査を有効にする前に、audit_startup ファイルの内容により、監査ポリシーが決まります。

#! /bin/sh
...
/usr/bin/echo "Starting BSM services."
/usr/sbin/auditconfig -setpolicy +cnt Counts rather than drops records
/usr/sbin/auditconfig -conf  Configures event-class mappings
/usr/sbin/auditconfig -aconf Configures nonattributable events

使用可能なポリシーオプションを表示します。
$ auditconfig -lspolicy
注 –
perzone と ahlt ポリシーオプションは、大域ゾーンでのみ設定できます。

選択した監査ポリシーオプションを有効または無効にします。
# auditconfig -setpolicy prefixpolicy
prefix

prefix 値 + を指定するとポリシーオプションが有効になります。prefix 値 - を指定するとポリシーオプションが無効になります。

policy

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

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

各ポリシーオプションの詳細は、「監査ポリシーの決定」を参照してください。

例 30–16 `cnt` および `ahlt` 監査ポリシーオプションを設定する

この例では、cnt ポリシーが無効になり、ahlt ポリシーが有効になります。これらの設定では、監査パーティションがいっぱいで非同期イベントが発生した場合、システムの使用が停止します。同期イベントが発生すると、スレッドを作成したプロセスがハングアップします。これらの設定は、セキュリティーが可用性よりも重要な場合に適しています。

次の audit_startup エントリによって、再起動を行なっても cnt ポリシーオプションが無効で ahlt ポリシーを有効のままになります。

# cat /etc/security/audit_startup
#!/bin/sh
/usr/bin/echo "Starting BSM services."
/usr/sbin/deallocate -Is
/usr/sbin/auditconfig -conf
/usr/sbin/auditconfig -aconf
/usr/sbin/auditconfig -setpolicy -cnt	
/usr/sbin/auditconfig -setpolicy +ahlt

例 30–17 `seq` 監査ポリシーを一時的に設定する

この例では、auditd デーモンが実行中で、ahlt 監査ポリシーが設定されています。seq 監査ポリシーが現在のポリシーに追加されます。seq ポリシーは、sequence トークンをすべての監査レコードに追加します。監査レコードが破壊されたときやレコードが破棄されているとき、監査サービスのデバッグに役立ちます。

+ 接頭辞により、現在の監査ポリシーを seq に置き換えるのではなく、seq オプションが監査ポリシーに追加されます。auditconfig コマンドにより、ポリシーはコマンドが次に起動するまで、または次のブートまで有効になります。

$ auditconfig -setpolicy +seq
$ auditconfig -getpolicy
audit policies = ahlt,seq

例 30–18 `perzone` 監査ポリシーを設定する

この例では、perzone 監査ポリシーが、大域ゾーンの audit_startup スクリプト内で設定されます。ゾーンのブート時に、非大域ゾーンは、そのゾーン内の監査構成設定に関する監査レコードを収集します。

$ cat /etc/security/audit_startup
#!/bin/sh
/usr/bin/echo "Starting BSM services."
/usr/sbin/deallocate -Is
/usr/sbin/auditconfig -conf
/usr/sbin/auditconfig -aconf
/usr/sbin/auditconfig -setpolicy +perzone
/usr/sbin/auditconfig -setpolicy +cnt

例 30–19 監査ポリシーを変更する

この例では、auditd デーモンが実行中で、監査ポリシーが設定されています。auditconfig コマンドは、セッションの間、ahlt と cnt ポリシーを変更します。これらの設定により、監査ファイルシステムがいっぱいになると、監査レコードは破棄されますが、カウントされます。ahlt ポリシーの設定での制限については、手順 3 を参照してください。

$ auditconfig -setpolicy +cnt
$ auditconfig -setpolicy -ahlt
$ auditconfig -getpolicy
audit policies = cnt,seq

変更をaudit_startup ファイルに書き込むと、ポリシーは永続的に有効になります。

$ cat /etc/security/audit_startup
#!/bin/sh
/usr/bin/echo "Starting BSM services."
/usr/sbin/deallocate -Is
/usr/sbin/auditconfig -conf
/usr/sbin/auditconfig -aconf
/usr/sbin/auditconfig -setpolicy +cnt

ahlt ポリシーはデフォルトで無効になっているため、-ahlt オプションをファイル内で指定する必要はありません。この設定は、監査レコードのセキュリティーよりも可用性が重要な場合に適しています。

監査サービスを有効にする方法

この手順では、監査サービスをすべてのゾーンで有効にします。非大域ゾーンで監査デーモンを起動するには、例 30–20 を参照してください。

監査が安全に構成されると、監査が有効化されるまで、システムはシングルユーザーモードになります。マルチユーザーモードで監査を有効にすることもできます。

始める前に

次の作業を完了してから、この手順をスーパーユーザーとして実行してください。

計画 – 「Solaris 監査の計画 (作業マップ)」
監査ファイルのカスタマイズ – 「監査ファイルの構成 (作業マップ)」
監査パーティションの設定 – 「監査ファイルのパーティションの作成方法」
監査警告メッセージの設定 – 「audit_warn 電子メールエイリアスの構成方法」
監査ポリシーの設定 – 「監査ポリシーを構成する方法」

注 –

監査が成功するには、ホスト名変換が正しく機能している必要があります。ネームサービスの hosts データベースが正しく構成され、機能している必要があります。

hosts データベースの構成については、nsswitch.conf(4) および netconfig(4) のマニュアルページを参照してください。詳細は、『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』または『Solaris のシステム管理 (ネーミングとディレクトリサービス : NIS+ 編)』を参照してください。

監査サービスを有効にするスクリプトを実行します。

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

# cd /etc/security
# ./bsmconv
This script is used to enable the Basic Security Module (BSM).
Shall we continue with the conversion now? [y/n] y
bsmconv: INFO: checking startup file.
bsmconv: INFO: turning on audit module.
bsmconv: INFO: initializing device allocation.

The Basic Security Module is ready.
If there were any errors, please fix them now.
Configure BSM by editing files located in /etc/security.
Reboot this system now to come up with BSM enabled.

スクリプトの働きについては、bsmconv(1M) のマニュアルページを参照してください。

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

スクリプトのもう 1 つの働きは、デバイス割り当てを有効にすることです。デバイス割り当ての設定方法は、「デバイス割り当ての管理 (作業マップ)」を参照してください。

例 30–20 非大域ゾーンで監査を有効にする

次の例では、監査が大域ゾーンで有効になり非大域ゾーンがブートされたあと、大域ゾーン管理者が perzone ポリシーを有効にします。非大域ゾーンのゾーン管理者は、ゾーンの監査ファイルを構成して、ゾーンで監査デーモンを起動します。

zone1# svcadm enable svc:/system/auditd

監査サービスを無効にする方法

ある時点で監査サービスが不要になった場合、この手順は監査が有効になる前のシステム状態にシステムを戻します。非大域ゾーンが監査されている場合は、その監査サービスも無効になります。

注意 –

このコマンドによって、デバイス割り当ても無効になります。デバイス割り当てを可能にする場合は、このコマンドを実行しないでください。デバイス割り当てを保ったまま監査を無効にする方法については、例 30–21 を参照してください。

スーパーユーザーになり、システムをシングルユーザーモードにします。
% su Password: <Type root password> # init S
詳細は、init(1M) のマニュアルページを参照してください。

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

/etc/security ディレクトリに移動し、bsmunconv スクリプトを実行します。
# cd /etc/security # ./bsmunconv
スクリプトのもう 1 つの働きは、デバイス割り当てを無効にすることです。

bsmunconv スクリプトの詳細は、bsmconv(1M) のマニュアルページを参照してください。

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

例 30–21 デバイス割り当てを保持したまま監査を無効にする

この例では、監査サービスはレコードの収集を停止しますが、デバイス割り当ては引き続き機能します。audit_user ファイルのすべてのユーザーエントリと同様に、audit_control ファイルの flags、naflags、および plugin エントリからのすべての値が削除されます。

## audit_control file
flags:
naflags:

## audit_user file

auditd デーモンが実行されますが、監査レコードは保持されません。

例 30–22 監査をゾーン単位で無効にする

この例では、監査サービスが無効化された zone1 内で、監査サービスが実行を停止します。デバイス割り当ては引き続き機能します。perzone 監査ポリシーが設定されていない状態で、このコマンドが大域ゾーンで実行されると、大域ゾーンだけでなくすべてのゾーンで監査が無効になります。

zone1 # audit -t

監査サービスの更新方法

この手順では、デーモの実行中に監査構成ファイルを変更した場合に、auditd デーモンを再起動します。

Audit Control 権利プロファイルを含む役割を引き受けるか、あるいはスーパーユーザーになります。

Audit Control 権利プロファイルを含む役割の作成方法およびユーザーに役割を割り当てる方法については、「RBAC の構成 (作業マップ)」を参照してください。

適切なコマンドを選択します。
- audit_control ファイルの naflags 行を変更する場合は、ユーザーに起因しないイベント用のカーネルマスクを変更します。
  $ /usr/sbin/auditconfig -aconf
  リブートすることもできます。
- audit_control ファイルのほかの行を変更する場合は、audit_control ファイルを再度読み込みます。
  
  監査デーモンは、audit_control ファイルからの情報を内部で格納します。新しい情報を使用するには、システムを再起動するか、または変更されたファイルを監査デーモンが読み込むようにします。
  $ /usr/sbin/audit -s
  注 –
  監査レコードは、各プロセスに関連付けられた監査事前選択マスクに基づいて生成されます。audit -s を実行しても、既存のプロセス内のマスクは変更されません。既存プロセスの事前選択マスクを変更するには、プロセスを再起動する必要があります。リブートすることもできます。
  
  audit -s コマンドを使用すると、監査デーモンはディレクトリと最小限の空きの値を audit_control ファイルから再度読み取ります。このコマンドにより、後続のログインにより発生するプロセス用の事前選択マスクの生成が変更されます。
- 監査デーモンの実行中に audit_event ファイルまたは audit_class ファイルを変更する場合は、監査サービスを再表示します。
  
  変更したイベントからクラスへのマッピングをシステムに読み込み、マシンを使用する各ユーザーが正しく監査されているかを確認します。
  $ auditconfig -conf $ auditconfig -setumask auid classes
  auid
  
  ユーザー ID です。
  
  classes
  
  事前に選択された監査クラスです。
  
  例については、「ユーザーの事前選択マスクを変更する方法」を参照してください。
- 稼動中のシステムで監査ポリシーを変更するには、例 30–17 を参照してください。

例 30–23 監査デーモンを再起動する

この例では、システムをシングルユーザーモードにしたあとで、マルチユーザーモードに戻します。システムがマルチユーザーモードになったとき、変更された構成ファイルがシステムに読み込まれます。

# init S
# init 6