| ナビゲーションリンクをスキップ | |
| 印刷ビューの終了 | |
|
Oracle Solaris 11.1 の管理: セキュリティーサービス Oracle Solaris 11.1 Information Library (日本語) |
| ナビゲーションリンクをスキップ | |
| 印刷ビューの終了 | |
|
|
Oracle Solaris 11.1 の管理: セキュリティーサービス Oracle Solaris 11.1 Information Library (日本語) |
パート II システム、ファイル、およびデバイスのセキュリティー
10. Oracle Solaris のセキュリティー属性 (参照)
22. Kerberos エラーメッセージとトラブルシューティング
2 つの監査プラグイン audit_binfile と audit_syslog、は、ローカル監査ログを作成できます。次のタスクは、これらのログの構成に役立ちます。
次のタスクマップは、さまざまなプラグインの監査ログを構成するための手順を示しています。audit_binfile プラグインに対するログの構成はオプションです。その他のプラグインに対するログは、管理者が構成する必要があります。
|
次の手順は、監査ファイルのための ZFS プールや、対応するファイルシステムとマウントポイントを作成する方法を示しています。デフォルトでは、audit_binfile プラグインの監査ファイルは /var/audit ファイルシステムに保持されます。
始める前に
ZFS File System Management および ZFS Storage Management 権利プロファイルが割り当てられている管理者になる必要があります。後者のプロファイルを使用すると、ストレージプールを作成できます。詳細は、「割り当てられている管理権限を使用する方法」を参照してください。
ホストあたり少なくとも 200M バイトのディスク容量を割り当てます。ただし、必要な監査の量によりディスク容量要件が決まります。つまり、要件によっては、この数値を超えることもあります。
注 - デフォルトのクラスの事前選択によって、ログイン、ログアウト、役割の引き受けなどの、lo クラス内のイベントの記録されたインスタンスごとに約 80 バイトずつ拡大するファイルが /var/audit 内に作成されます。
zpool create コマンドは、ZFS ファイルシステムのコンテナであるストレージプールを作成します。詳細は、『Oracle Solaris 11.1 の管理: ZFS ファイルシステム』の第 1 章「Oracle Solaris ZFS ファイルシステム (概要)」を参照してください。
# zpool create audit-pool mirror disk1 disk2
たとえば、c3t1d0 と c3t2d0 の 2 つのディスクから auditp プールを作成し、それらをミラー化します。
# zpool create auditp mirror c3t1d0 c3t2d0
ファイルシステムとマウントポイントは 1 つのコマンドで作成します。作成時に、ファイルシステムがマウントされます。たとえば、次の図は、ホスト名で格納された監査トレールのストレージを示しています。
注 - ファイルシステムの暗号化を予定している場合は、作成時にファイルシステムを暗号化する必要があります。例については、例 28-12 を参照してください。
暗号化には管理が必要です。たとえば、マウント時にはパスフレーズが必要です。詳細は、『Oracle Solaris 11.1 の管理: ZFS ファイルシステム』の「ZFS ファイルシステムの暗号化」を参照してください。
# zfs create -o mountpoint=/mountpoint audit-pool/mountpoint
たとえば、auditf ファイルシステムの /audit マウントポイントを作成します。
# zfs create -o mountpoint=/audit auditp/auditf
# zfs create -p auditp/auditf/system
たとえば、sys1 システムのための暗号化されていない ZFS ファイルシステムを作成します。
# zfs create -p auditp/auditf/sys1
追加のファイルシステムを作成する 1 つの理由は、監査のオーバーフローを回避するためです。手順 8 に示すように、ファイルシステムあたりの ZFS 割り当て制限を設定できます。各割り当て制限に達すると、audit_warn 電子メールエイリアスによって通知されます。領域を解放するために、閉じられた監査ファイルをリモートサーバーに移動できます。
# zfs create -p auditp/auditf/sys1.1 # zfs create -p auditp/auditf/sys1.2
プール内のすべてのファイルシステムについて、次の ZFS プロパティーを off に設定します。
# zfs set devices=off auditp/auditf # zfs set exec=off auditp/auditf # zfs set setuid=off auditp/auditf
ZFS では通常、圧縮はファイルシステムのレベルで設定されます。ただし、このプール内のすべてのファイルシステムに監査ファイルが含まれているため、圧縮はプールのトップレベルのデータセットで設定されます。
# zfs set compression=on auditp
『Oracle Solaris 11.1 の管理: ZFS ファイルシステム』の「ZFS の圧縮、複製解除、暗号化のプロパティー間の関連」も参照してください。
親のファイルシステム、子孫のファイルシステム、またはその両方で割り当て制限を設定できます。親の監査ファイルシステム上で割り当て制限を設定した場合は、子孫のファイルシステム上の割り当て制限によって追加の制限が課せられます。
次の例では、auditp プール内の両方のディスクが割り当て制限に達すると、audit_warn スクリプトによって監査管理者に通知されます。
# zfs set quota=510G auditp/auditf
次の例では、auditp/auditf/ system ファイルシステムの割り当て制限に達すると、audit_warn スクリプトによって監査管理者に通知されます。
# zfs set quota=170G auditp/auditf/sys1 # zfs set quota=170G auditp/auditf/sys1.1 # zfs set quota=165G auditp/auditf/sys1.2
デフォルトでは、監査ファイルはプールのサイズまで拡大できます。管理容易性のために、監査ファイルのサイズを制限します。例 28-14 を参照してください。
例 28-12 監査ファイルのための暗号化されたファイルシステムを作成する
サイトのセキュリティー要件に従うために、管理者は、暗号化を有効にして監査ファイルシステムを作成します。次に、管理者はマウントポイントを設定します。
# zfs create -o encryption=on auditp/auditf Enter passphrase for auditp/auditf': /** Type 8-character minimum passphrase**/ Enter again: /** Confirm passphrase **/ # zfs set -o mountpoint=/audit auditp/auditf
パスフレーズがないとファイルシステムに到達できないため、管理者はパスフレーズをセキュアな場所に保存します。
管理者が auditf ファイルシステムの下に追加のファイルシステムを作成した場合は、これらの子孫のファイルシステムも暗号化されます。
例 28-13 /var/audit ディレクトリに割り当て制限を設定する
この例では、管理者は、デフォルトの監査ファイルシステム上で割り当て制限を設定します。この割り当て制限に達すると、audit_warn スクリプトによって監査管理者に警告が通知されます。
# zfs set quota=252G rpool/var/audit
この手順では、audit_binfile プラグインの属性を使用して、監査トレールに追加のディスク容量を割り当てます。
始める前に
Audit Configuration 権利プロファイルが割り当てられている管理者になる必要があります。詳細は、「割り当てられている管理権限を使用する方法」を参照してください。
audit_binfile(5) のマニュアルページの「オブジェクト属性」のセクションを参照してください。
# man audit_binfile
...
OBJECT ATTRIBUTES
The p_dir attribute specifies where the audit files will be created.
The directories are listed in the order in which they are to be used.
The p_minfree attribute defines the percentage of free space that the
audit system requires before the audit daemon invokes the audit_warn
script.
The p_fsize attribute defines the maximum size that an audit
file can become before it is automatically closed and a new
audit file is opened. ... The format of the p_fsize value can
be specified as an exact value in bytes or in a human-readable
form with a suffix of B, K, M, G, T, P, E, Z (for bytes,
kilobytes, megabytes, gigabytes, terabytes, petabytes, exabytes,
or zettabytes, respectively). Suffixes of KB, MB, GB, TB, PB, EB,
and ZB are also accepted.デフォルトのファイルシステムは /var/audit です。
# auditconfig -setplugin audit_binfile p_dir=/audit/sys1.1,/var/audit
前のコマンドは、/audit/sys1.1 ファイルシステムを監査ファイルのプライマリディレクトリとして、またデフォルトの /var/audit ファイルシステムをセカンダリディレクトリとして設定します。このシナリオでは、/var/audit は最後の手段としてのディレクトリです。この構成を成功させるには、/audit/sys1.1 ファイルシステムが存在する必要があります。
「監査ファイルのための ZFS ファイルシステムを作成する方法」でも同様のファイルシステムを作成しました。
auditconfig -setplugin コマンドは、構成された値を設定します。この値は監査サービスのプロパティーであるため、このサービスがリフレッシュまたは再開されたときに復元されます。構成された値は、監査サービスがリフレッシュまたは再開されたときにアクティブになります。構成された値とアクティブな値については、auditconfig(1M) のマニュアルページを参照してください。
# audit -s
例 28-14 audit_binfile プラグインのためのファイルサイズを制限する
次の例では、バイナリ監査ファイルのサイズが特定のサイズに設定されます。このサイズは M バイト単位で指定されます。
# auditconfig -setplugin audit_binfile p_fsize=4M
# auditconfig -getplugin audit_binfile
Plugin: audit_binfile
Attributes: p_dir=/var/audit;p_fsize=4M;p_minfree=1;
デフォルトでは、監査ファイルは無制限に拡大できます。作成する監査ファイルを小さくするために、管理者は 4M バイトのファイルサイズ制限を指定します。このサイズ制限に達すると、監査サービスは新しいファイルを作成します。このファイルサイズ制限は、管理者が監査サービスをリフレッシュしたあとに有効になります。
# audit -s
例 28-15 監査プラグインに対するいくつかの変更を指定する
次の例では、高いスループットと大規模な ZFS プールを備えたシステム上の管理者が、audit_binfile プラグインのキューサイズ、バイナリファイルのサイズ、および弱い制限値の警告を変更します。管理者は、監査ファイルを 4G バイトまで拡大できるようにし、ZFS プールの残りが 2% になったら警告を受信するようにし、許可されるキューサイズを 2 倍にします。デフォルトのキューサイズは、active audit queue hiwater mark (records) = 100 にあるように、カーネル監査キューの高位境界値 100 になります。
# auditconfig -getplugin audit_binfile
Plugin: audit_binfile
Attributes: p_dir=/var/audit;p_fsize=2G;p_minfree=1;
# auditconfig -setplugin audit_binfile "p_minfree=2;p_fsize=4G" 200
# auditconfig -getplugin audit_binfile
Plugin: audit_binfile
Attributes: p_dir=/var/audit;p_fsize=4G;p_minfree=2;
Queue size: 200
変更した指定は、管理者が監査サービスをリフレッシュしたあとに有効になります。
# audit -s
例 28-16 監査プラグインのキューサイズを削除する
次の例では、audit_binfile プラグインのキューサイ が削除されます。
# auditconfig -getplugin audit_binfile
Plugin: audit_binfile
Attributes: p_dir=/var/audit;p_fsize=4G;p_minfree=2;
Queue size: 200
# auditconfig -setplugin audit_binfile "" 0
# auditconfig -getplugin audit_binfile
Plugin: audit_binfile
Attributes: p_dir=/var/audit;p_fsize=4G;p_minfree=2;
空の引用符 ("") によって、現在の属性値が保持されます。最後の 0 は、プラグインのキューサイズをデフォルトに設定します。
プラグインに対する qsize の指定の変更は、管理者が監査サービスをリフレッシュしたあとに有効になります。
# audit -s
例 28-17 警告のための弱い制限値を設定する
この例では、ファイルシステムの 2% がまだ使用可能なときに警告が発行されるように、すべての監査ファイルシステムの最小空き容量のレベルが設定されます。
# auditconfig -setplugin audit_binfile p_minfree=2
デフォルトの割合 (%) は 1 です。大規模な ZFS プールの場合は、適度に低い割合を選択します。たとえば、16T バイトプールの 10% は約 16G バイトであり、これにより、大量のディスク容量が残っているときに監査管理者に警告が通知されます。2 の値を指定すると、約 2G バイトのディスク容量が残っているときに audit_warn メッセージが送信されます。
audit_warn 電子メールエイリアスが警告を受信します。エイリアスを設定するには、「audit_warn 電子メールエイリアスの構成方法」を参照してください。
大規模なプールの場合、管理者はファイルサイズも 3G バイトに制限します。
# auditconfig -setplugin audit_binfile p_fsize=3G
プラグインに対する p_minfree と p_fsize の指定は、管理者が監査サービスをリフレッシュしたあとに有効になります。
# audit -s
この手順では、audit_remote プラグインの属性を使用して、監査トレールをリモート監査リポジトリに送信します。Oracle Solaris システム上にリモートリポジトリを構成するには、「監査ファイルのためのリモートリポジトリを構成する方法」を参照してください。
始める前に
リモートリポジトリに監査ファイルの受信者が存在する必要があります。Audit Configuration 権利プロファイルが割り当てられている管理者になる必要があります。詳細は、「割り当てられている管理権限を使用する方法」を参照してください。
audit_remote(5) のマニュアルページの「オブジェクト属性」のセクションを参照してください。
# man audit_remote
...
OBJECT ATTRIBUTES
The p_hosts attribute specifies the remote servers.
You can also specify the port number and the GSS-API
mechanism.
The p_retries attribute specifies the number of retries for
connecting and sending data. The default is 3.
The p_timeout attribute specifies the number of seconds
in which a connection times out.デフォルトポートは、solaris_audit IANA 割り当て済みポート 16162/tcp です。デフォルトのメカニズムは kerberos_v5 です。タイムアウトのデフォルトは 5 秒です。また、プラグインのキューサイズも指定できます。
この例では、受信側のシステムは別のポートを使用します。
# auditconfig -setplugin audit_remote p_hosts=ars.example.com:16088:kerberos_v5
たとえば、次のコマンドは、すべてのオプション属性の値を指定します。
# auditconfig -setplugin audit_remote "p_retries=;p_timeout=3" 300
たとえば、次のコマンドは、プラグインの値を指定して確認します。
# auditconfig -getplugin audit_remote
Plugin: audit_remote (inactive)
Attributes: p_hosts=ars.example.com:16088:kerberos_v5;p_retries=5;p_timeout=3;
Queue size: 300
# auditconfig -setplugin audit_remote active監査サービスは、リフレッシュ時に監査プラグインの変更を読み取ります。
# audit -s
例 28-18 監査キューのバッファーサイズのチューニング
この例では、監査キューが audit_remote プラグインの背後でいっぱいになっています。この監査対象システムは多数のクラスを監査するように構成されており、トラフィック量の多い、低速なネットワークを経由して転送しています。管理者は、プラグインのバッファーサイズを増やすことによって、レコードがキューから削除される前に監査キューを拡張可能にし、バッファーの制限を超えることがないようにます。
audsys1 # auditconfig -setplugin audit_remote "" 1000 audsys1 # audit -s
この手順では、1 つまたは複数の監査対象システムから監査レコードを受信して格納するためのリモートシステムである監査リモートサーバー (ARS) を構成します。次に、リモートサーバー上で監査デーモンをアクティブにします。
この構成は 2 つの部分から成ります。最初に、監査データをセキュアに転送するためのベースとなるセキュリティーメカニズム、つまり、KDC を構成します。2 番目に、監査対象システムと ARS の両方に監査サービスを構成します。この手順は、ARS と KDC が同じサーバー上に存在している、1 つの監査対象クライアントと 1 つの ARS を含むシナリオを示しています。より複雑なシナリオも同様に構成できます。
始める前に
root 役割になる必要があります。「監査レコードのリモートストレージへのストリーム出力を準備する方法」の説明に従って、Kerberos パッケージをインストールしました。「監査ファイルをリモートリポジトリに送信する方法」の説明に従って、監査対象システムを構成した管理者とともに作業しています。
監査対象システムと ARS の両方が使用できるシステム上の KDC、各システムのホスト主体、および audit サービス主体が必要です。
サイトで KDC が構成されている場合は、それを使用し、手順 c に進みます。次の一連のコマンドは、KDC の構成方法を示しています。
arstore # kdcmgr -a audr/admin -r EXAMPLE.COM create master
このコマンドは、管理主体 audr/admin を使用して EXAMPLE.COM レルム内にマスター KDC を作成し、そのマスター KDC を有効にして、Kerberos サービスを開始します。
詳細は、kdcmgr(1M) のマニュアルページを参照してください。
# kdcmgr status
KDC Status Information
--------------------------------------------
svc:/network/security/krb5kdc:default (Kerberos key distribution center)
State: online since Wed Feb 29 01:59:27 2012
See: man -M /usr/share/man -s 1M krb5kdc
See: /var/svc/log/network-security-krb5kdc:default.log
Impact: None.
KDC Master Status Information
--------------------------------------------
svc:/network/security/kadmin:default (Kerberos administration daemon)
State: online since Wed Feb 29 01:59:28 2012
See: man -M /usr/share/man -s 1M kadmind
See: /var/svc/log/network-security-kadmin:default.log
Impact: None.
Transaction Log Information
--------------------------------------------
Kerberos update log (/var/krb5/principal.ulog)
Update log dump :
Log version # : 1
Log state : Stable
Entry block size : 2048
Number of entries : 13
First serial # : 1
Last serial # : 13
First time stamp : Wed Feb 29 01:59:27 2012
Last time stamp : Mon Mar 5 19:29:28 2012
Kerberos Related File Information
--------------------------------------------
(Displays any missing files)KDC システム上で kadmin.local コマンドを入力することによって、この主体を追加できます。または、kadmin コマンドを使用し、パスワードを指定することによって、リモートから主体を追加できます。この例では、arstore システムが KDC を実行しています。
# kadmin -p audr/admin kadmin: addprinc -randkey audit/arstore.example.com@EXAMPLE.COM kadmin: ktadd audit/arstore.example.com@EXAMPLE.COM
受信者と送信者は鍵を持っている必要があります。
enigma # kclient
.. Enter the Kerberos realm: EXAMPLE.COM
.. KDC hostname for the above realm: arstore.example.com
.. Will this client need service keys ? [y/n]: y# auditconfig -setremote group create Bank_A
Bank_A が接続グループです。hosts 属性が定義されていないため、このグループはすべての接続を受け入れます。つまり、これはワイルドカードグループです。audit_remote プラグインが正しく構成されているこの Kerberos レルム内の監査対象システムはすべて、この ARS に到達できます。
# auditconfig -setremote group Bank_A "hosts=enigma.example.com"
接続グループ Bank_A は現在、enigma システムからの接続のみを受け入れます。その他のどのホストからの接続も拒否されます。
# auditconfig -setremote group Bank_A "binfile_size=4GB" # auditconfig -getremote Audit Remote Server Attributes: listen_address=;login_grace_time=30;max_startups=10;listen_port=0; Connection group: Bank_A (inactive) Attributes: binfile_dir=/var/audit;binfile_fsize=4GB;binfile_minfree=1; hosts=enigma.example.com;
ARS を指定するには、p_hosts 属性を使用します。
enigma # auditconfig -setplugin audit_remote active p_hosts=arstore.example.com
enigma # auditconfig -getplugin audit_remote
Plugin: audit_remote
Attributes: p_retries=3;p_timeout=5;p_hosts=arstore.example.com;監査サービスは、リフレッシュ時に監査プラグインの変更を読み取ります。
# audit -s
KDC は現在、監査対象システム enigma と ARS の間の接続を管理しています。
例 28-19 監査レコードの同じ ARS 上の異なるファイルの場所へのストリーム出力
この例では、手順にある例を拡張します。管理者は、2 つの接続グループを作成することによって、ARS 上のホストごとに監査レコードを分離します。
audsys1 からの監査ファイルは、この ARS 上の Bank_A の接続グループにストリーム出力されます。
arstore # auditconfig -setremote group create Bank_A
arstore # auditconfig -setremote group active Bank_A "hosts=audsys1"
"hosts=audsys1;binfile_dir=/var/audit/audsys1;binfile_fsize=4M;"
audsys2 からの監査ファイルは、Bank_B の接続グループにストリーム出力されます。
arstore # auditconfig -setremote group create Bank_B
arstore # auditconfig -setremote group active Bank_B \
"hosts=audsys2;binfile_dir=/var/audit/audsys2;binfile_fsize=4M;"
保守を容易にするために、管理者はその他の属性値を同様に設定します。
arstore # auditconfig -getremote
Audit Remote Server
Attributes: listen_address=;login_grace_time=30;max_startups=10;listen_port=0;
Connection group: Bank_A
Attributes: binfile_dir=/var/audit/audsys1;binfile_fsize=4M;binfile_minfree=1;
hosts=audsys1
Connection group: Bank_B
Attributes: binfile_dir=/var/audit/audsys2;binfile_fsize=4M;binfile_minfree=1;
hosts=audsys2例 28-20 KDC の別のシステム上への ARS の配置
この例では、管理者は ARS を KDC の別のシステム上に配置します。最初に、管理者はマスター KDC を作成して構成します。
kserv # kdcmgr -a audr/admin -r EXAMPLE.COM create master kserv # kadmin.local -p audr/admin kadmin: addprinc -randkey audit/arstore.example.com@EXAMPLE.COM kadmin: ktadd -t /tmp/krb5.keytab.audit audit/arstore.example.com@EXAMPLE.COM
/tmp/krb5.keytab.audit ファイルを ARS (arstore) にセキュアに転送したあと、管理者はこのファイルを正しい場所に移動します。
arstore # chown root:root krb5.keytab.audit arstore # chmod 600 krb5.keytab.audit arstore # mv krb5.keytab.audit /etc/krb5/krb5.keytab
このファイルを書き換えるのではなく、管理者には、ARS 上で ktutil コマンドを使用して KDC の krb5.keytab.audit ファイルを arstore の /etc/krb5/krb5.keytab ファイル内の既存の鍵とマージする方法もあります。
最後に、管理者は監査対象システム上で鍵を生成します。
enigma # kclient .. Enter the Kerberos realm: EXAMPLE.COM .. KDC hostname for the above realm: kserv.example.com .. Will this client need service keys ? [y/n]: y
監査サービスに、監査キュー内の監査レコードの一部またはすべてを syslog ユーティリティーにコピーするよう指示できます。バイナリ監査データと概要テキストの両方を記録した場合、バイナリデータでは完全な監査レコードが提供されるのに対して、概要ではリアルタイムで確認できるようにデータがフィルタリングされます。
始める前に
audit_syslog プラグインを構成するには、Audit Configuration 権利プロファイルが割り当てられている管理者になる必要があります。syslog ユーティリティーを構成して auditlog ファイルを作成するには、root 役割になる必要があります。
注 - p_flags 監査クラスが、システムのデフォルトとして、あるいはユーザーまたは権利プロファイルの監査フラグで事前選択されている必要があります。事前選択されていないクラスについてレコードは収集されません。
# auditconfig -setplugin audit_syslog active p_flags=lo,+as,-ss
# svcs system-log STATE STIME FMRI disabled 13:11:55 svc:/system/system-log:rsyslog online 13:13:27 svc:/system/system-log:default
注 - rsyslog サービスインスタンスがオンラインである場合は、rsyslog.conf ファイルを変更します。
リフレッシュ時に、監査サービスによって変更が監査プラグインに読み込まれます。
# audit -s
監査サービスでは、大量の出力が生成される可能性があります。ログの管理方法については、logadm(1M) のマニュアルページを参照してください。
例 28-21 syslog 出力の監査クラスを指定する
次の例では、syslog ユーティリティーによって、事前選択された監査クラスのサブセットが収集されます。pf クラスは、例 28-10 で作成されます。
# auditconfig -setnaflags lo,na # auditconfig -setflags lo,ss # usermod -K audit_flags=pf:no jdoe # auditconfig -setplugin audit_syslog active p_flags=lo,+na,-ss,+pf
auditconfig コマンドの引数はシステムに、すべてのログイン/ログアウト、ユーザーに起因しないイベント、およびシステム状態監査レコードの変更を収集するよう指示します。audit_syslog プラグインエントリは syslog ユーティリティーに、すべてのログイン、ユーザーに起因しない成功したイベント、およびシステム状態の失敗した変更を収集するよう指示します。
jdoe ユーザーに関して、このバイナリユーティリティーは、pfexec コマンドへの成功した呼び出しと失敗した呼び出しを収集します。syslog ユーティリティーは、pfexec コマンドへの成功した呼び出しを収集します。
例 28-22 syslog 監査レコードをリモートシステムに配置する
syslog.conf ファイル内の audit.notice エントリを変更して、リモートシステムを指定します。この例では、ローカルシステムの名前は sys1.1 です。リモートシステムは、remote1 です。
sys1.1 # cat /etc/syslog.conf … audit.notice @remote1
remote1 システム上の syslog.conf ファイル内にある audit.notice エントリはログファイルを指定します。
remote1 # cat /etc/syslog.conf … audit.notice /var/adm/auditlog
|