18.3. CS.cfg ファイルでのログの設定

インストールの設定中に、インスタンスの CS.cfg を直接編集して、ロギングを設定することができます。

サブシステムインスタンスを停止します。

# systemctl stop pki-tomcatd-nuxwdog@instance_name.service

/var/lib/pki/instance_name/subsystem_type/conf ディレクトリーの CS.cfg ファイルを開きます。
新しいログを作成します。

ログインスタンスを設定するには、そのログに関連付けられたパラメーターを変更します。これらのパラメーターは log.instance で始まります。

表18.3 ログエントリーパラメーター
パラメーター	説明
type	ログファイルのタイプ。システムはエラーおよびシステムログを作成します。トランザクションは監査ログを記録します。
enable	ログがアクティブかどうかを設定します。有効にするログのみがイベントを記録します。
level	テキストフィールドにログレベルを設定します。このレベルは、フィールドに手動で入力する必要があります。選択メニューはありません。ログレベル設定は、「ログレベル (メッセージカテゴリー)」に記載されている数値です。
fileName	ログファイルへのファイル名を含む完全パス。サブシステムユーザーには、ファイルへの読み書きパーミッションがなければなりません。
bufferSize	ログのキロバイトサイズ (KB) のバッファーサイズ。バッファーがこのサイズに達すると、バッファーの内容はフラッシュされ、ログファイルにコピーされます。デフォルトのサイズは 512 KB です。バッファーロギングの詳細は、「バッファー付きおよびバッファーなしのロギング」を参照してください。
flushInterval	バッファーの内容がフラッシュされてログファイルに追加されるまでの時間 (秒単位)。デフォルトの間隔は 5 秒です。
maxFileSize	ローテーションされる前に可能なログファイルのサイズをキロバイト (KB) 単位で設定できます。このサイズに達すると、ファイルはローテーションファイルにコピーされ、ログファイルが新たに開始されます。ログファイルのローテーションに関する詳細は、「ログファイルローテーション」を参照してください。デフォルトのサイズは 2000 KB です。
rolloverInterval	サーバーがアクティブなログファイルをローテーションする頻度。利用可能な選択肢は hourly、daily、weekly、monthly、および yearly です。デフォルトの選択は monthly です。詳細は、「ログファイルローテーション」を参照してください。
logSigning^[a]	署名付きロギングを有効にします。このパラメーターが有効な場合は、signedAuditCertNickname パラメーターの値を指定します。このオプションは、監査人だけがログを表示できることを意味します。値は true または false です。
signedAuditCertNickname^[a]	監査ログの署名に使用される証明書のニックネーム。この証明書の秘密鍵は、ログに署名するためにサブシステムからアクセスできる必要があります。
events^[a]	監査ログにログを記録するイベントを指定します。ログイベントは、空白のないコンマで区切ります。
^[a] これは監査ログのみになります。

ファイルを保存します。
サブシステムインスタンスを開始します。
```
# systemctl start pki-tomcatd@instance_name.service
```
または (nuxwdog watchdog を使用している場合)
```
# systemctl start pki-tomcatd-nuxwdog@instance_name.service
```

18.3.1. 署名監査ログの有効化および設定

18.3.1.1. 署名監査ログの有効化

デフォルトでは、監査ロギングはインストール時に有効になります。ただし、インストール後に、ログ署名を手動で有効にする必要があります。

現在の監査ロギング設定を表示するには、以下を実行します。

# pki-server subsystem-audit-config-show
  Enabled: True
  Log File: audit_signing_log_file
  Buffer Size (bytes): 512
  Flush Interval (seconds): 5
  Max File Size (bytes): 2000
  Rollover Interval (seconds): 2592000
  Expiration Time (seconds): 0
  Log Signing: False
  Signing Certificate: audit_signing_certificate

署名付き監査ログを有効にするには、以下を実行します。

pki-server ユーティリティーを使用して、--logSigning オプションを true に設定します。
```
# pki-server subsystem-audit-config-mod --logSigning True
  ...
  Log Signing: True
  ...
```

インスタンスを再起動します。

# systemctl restart pki-tomcatd@instance_name.service

または (nuxwdog watchdog を使用している場合)

# systemctl start pki-tomcatd-nuxwdog@instance_name.service

18.3.1.2. 監査イベントの設定

18.3.1.2.1. 監査イベントの有効化および無効化

監査イベントの有効化および無効化の詳細は、『Red Hat Certificate System 管理ガイド』の『コンソールでの署名監査ログの設定』セクションを参照してください。

さらに、監査イベントフィルターは、より詳細な選択に設定できます。「監査イベントのフィルタリング」を参照してください。

Certificate System で監査可能なイベントの完全リストは、『Red Hat Certificate System 監査ガイド』の『監査イベント』を参照してください。

18.3.1.2.2. 監査イベントのフィルタリング

Certificate System では、管理者はフィルターを設定して、イベント属性に基づいて監査ファイルに記録される監査イベントを設定できます。

フィルターの形式は LDAP フィルターと同じです。ただし、Certificate System は、以下のフィルターのみをサポートします。

表18.4 サポート対象の Audit イベントフィルター
タイプ	形式	例
Presence	(attribute=*)	(ReqID=*)
Equality	(attribute=value)	(Outcome=Failure)
Substring	(attribute=initialany...anyfinal)	(SubjectID=admin)
`AND` 演算	(&(filter_1)(filter_2)...(filter_n))	(&(SubjectID=admin)(Outcome=Failure))
`OR` 演算	(\|(filter_1)(filter_2)...(filter_n))	(\|(SubjectID=admin)(Outcome=Failure))
`NOT` 演算	(!(filter))	(!(SubjectID=admin))

LDAP フィルターの詳細は、『Red Hat Directory Server Administration Guide』の『Using Compound Search Filters』セクションを参照してください。

例18.2 監査イベントのフィルタリング

プロファイル証明書要求と処理された証明書の現在の設定を表示するには、以下のコマンドを実行します。

$ pki-server ca-audit-event-show PROFILE_CERT_REQUEST
  Event Name: PROFILE_CERT_REQUEST
  Enabled: True
  Filter: None

$ pki-server ca-audit-event-show CERT_REQUEST_PROCESSED
  Event Name: CERT_REQUEST_PROCESSED
  Enabled: True
  Filter: None

InfoName フィールドが rejectReason または cancelReason に設定されている処理済み証明書要求のイベントと、プロファイル証明書要求およびイベントの失敗したイベントのみを記録するには、以下を実行します。

以下のコマンドを実行します。

$ pki-server ca-audit-event-update PROFILE_CERT_REQUEST --filter "(Outcome=Failure)"
  ...
  Filter: (Outcome=Failure)

$ pki-server ca-audit-event-update CERT_REQUEST_PROCESSED --filter "(|(InfoName=rejectReason)(InfoName=cancelReason))"
  ...
  Filter: (|(InfoName=rejectReason)(InfoName=cancelReason))

Certificate System を再起動します。

# systemctl restart pki-tomcatd@instance_name.service

または (nuxwdog watchdog を使用している場合)

# systemctl start pki-tomcatd-nuxwdog@instance_name.service

18.3.2. セルフテストの設定

セルフテスト機能と個々のセルフテストは、CS.cfg ファイルで登録され、設定されます。セルフテストが有効になっている場合、そのセルフテストはオンデマンドまたは起動時に対して一覧表示され、空かまたは critical として設定されます。

重要なセルフテストには、セルフテストの名前の後にコロンと単語 critical があります。それ以外の場合は、何もありません。オンデマンドセルフテスト中に重要なセルフテストが失敗すると、サーバーはシャットダウンします。起動中に重要なセルフテストが失敗すると、サーバーは起動しません。

インスタンスのインストール時に、実装されたセルフテストが自動的に登録され、設定されます。登録および設定されるセルフテストは、サブシステムタイプに関連するものです。

自己テストの重大度は、CS.cfg ファイルのそれぞれの設定を変更することで変更されます。

18.3.2.1. 起動時のデフォルトのセルフテスト

以下の自己テストは、起動時にデフォルトで有効になります。

CA サブシステムでは、起動時に以下のセルフテストがデフォルトで有効になっています。

CAPresence: CA サブシステムが存在することを確認するために使用されます。
CAValidity: CA サブシステムが現在有効であり、期限切れでないことを確認するために使用されます。これには、CA 証明書の有効期限を確認する必要があります。
SystemCertsVerification: システム証明書が現在有効であり、有効期限が切れていないか、または取り消されていないことを確認するために使用されます。CA サブシステムの場合は、各証明書の有効性テストのみが実行され、OCSP 要求が発生する可能性のある証明書検証テストは除外されます。この動作は、以下の設定パラメーターで上書きできます。
```
selftests.plugin.SystemCertsVerification.FullCAandOCSPVerify=true
```
デフォルトでは、この設定パラメーターが存在しない場合は false と見なされます。

KRA サブシステムの場合は、次のセルフテストが有効になります。

KRAPresence: KRA サブシステムが存在することを確認するために使用されます。
KRAValidity: KRA サブシステムが現在有効であり、期限切れでないことを確認するために使用されます。これには、KRA 証明書の有効期限を確認する必要があります。
SystemCertsVerification: システム証明書が現在有効であり、有効期限が切れていないか、または取り消されていないことを確認するために使用されます。

OCSP サブシステムでは、以下のセルフテストが有効になります。

OCSPPresence: OCSP サブシステムの有無を確認するために使用されます。
OCSPValidity: OCSP サブシステムが現在有効であり、期限切れでないことを確認するために使用されます。これには、OCSP 証明書の有効期限を確認する必要があります。
SystemCertsVerification: システム証明書が現在有効であり、有効期限が切れていないか、または取り消されていないことを確認するために使用されます。OCSP サブシステムの場合は、各証明書の有効性テストのみが実行され、OCSP 要求が発生する可能性のある証明書検証テストは除外されます。この動作は、以下の設定パラメーターで上書きできます。
```
selftests.plugin.SystemCertsVerification.FullCAandOCSPVerify=true
```
デフォルトでは、この設定パラメーターが存在しない場合は false と見なされます。

TKS サブシステムの場合は、次のセルフテストが有効になります。

TKSKnownSessionKey: TKS サブシステムの既知のセッションキーの検証に使用されます。これにより、TKS は、TPS およびサポート対象のスマートカードの代わりに鍵の作成を適切に支援できます。
SystemCertsVerification: システム証明書が現在有効であり、有効期限が切れていないか、または取り消されていないことを確認するために使用されます。

TPS サブシステムの場合は、次のセルフテストが有効になります。

TPSPresence: TPS サブシステムが存在することを確認するために使用されます。
TPSValidity: TPS サブシステムが現在有効であり、期限切れでないことを確認するために使用されます。これには、TPS 証明書の有効期限を確認する必要があります。
SystemCertsVerification: システム証明書が現在有効であり、有効期限が切れていないか、または取り消されていないことを確認するために使用されます。

18.3.2.2. セルフテスト設定の変更

デフォルトでは、セルフテスト設定は準拠しています。ただし、一部の設定により、自己テストロギングの表示やパフォーマンスを向上させることができます。セルフテストの設定を変更するには、以下を実行します。

サブシステムインスタンスを停止します。
インスタンスの conf/ ディレクトリーにある CS.cfg ファイルを開きます。
self-test ログの設定を編集するには、selftests.container.logger で始まるエントリーを編集します。指定のない限り、これらのパラメーターはコンプライアンスには影響しません。これには、以下のパラメーターが含まれます。
- bufferSize: ログのバッファーサイズをキロバイト単位 (KB) で指定します。デフォルトのサイズは 512 KB です。バッファーがこのサイズに達すると、バッファーの内容はフラッシュされ、ログファイルにコピーされます。
- enable - 有効にする場合は true を指定します。有効にするログのみがイベントを記録します。この値は、コンプライアンスのために有効にする必要があります。
- fileName: ファイル名を含む、メッセージを書き込むファイルの完全パスを指定します。サーバーに、ファイルへの読み取り/書き込み権限が必要です。デフォルトでは、self-test ログファイルは /var/log/pki-name/logs/selftest.log です。
- flushInterval: バッファーをファイルにフラッシュする間隔を秒単位で指定します。デフォルトの間隔は 5 秒です。flushInterval は、バッファーの内容がフラッシュされログファイルに追加されるまでの時間です。
- level: デフォルトの選択は 1 です。このログは、1 以外のレベルでは設定されません。
- maxFileSize: エラーログのファイルサイズをキロバイト単位 (KB) で指定します。デフォルトのサイズは 100 KB です。maxFileSize は、ログファイルがローテーションされる前のサイズを決定します。このサイズに達すると、ファイルはローテーションファイルにコピーされ、新しいログファイルが起動します。
- rolloverInterval: アクティブなエラーログファイルをサーバーがローテーションする頻度を指定します。選択肢は hourly、daily、weekly、monthly、および yearly です。デフォルトの選択は monthly です。
- type: transaction に設定してください。これは変更しないでください。
セルフテストを実行する順序を編集するには、コンマとスペースで区切った次のパラメーターの値としてセルフテストのいずれかをリストすることにより、順序を指定します。
セルフテストをクリティカルとしてマークするには、リスト内のセルフテストの名前にコロンとクリティカルという単語を追加します。
セルフテストを無効にするには、selftests.container.order.onDemand または selftests.container.order.startup のパラメーターの値の設定を削除します。
ファイルを保存します。
サブシステムを起動します。

18.3.3. デバッグログの追加設定

18.3.3.1. デバッグログの有効化および無効化

デフォルトでは、デバッグロギングは Certificate System で有効になっています。ただし、特定の状況では、管理者がこの機能を無効にまたは再有効化する必要があります。

/var/lib/pki/instance_name/subsystem_type/conf/CS.cfg ファイルを編集し、debug.enabled のパラメーターを設定します。
- デバッグのロギングを無効にするには、以下を設定します。
```
debug.enabled=false
```
  注記
  デバッグログは監査ロギングの一部では ありません。デバッグログは、Certificate System で特定の障害をデバッグする場合や、インストールの失敗時に便利です。
  デフォルトで、デバッグログは有効です。望ましい場合には、管理者はデバッグロギングを安全に無効にして詳細度を下げることができます。
- デバッグロギングを有効にするには、以下を実行します。
```
debug.enabled=true
```
Certificate System インスタンスを再起動します。
```
# systemctl restart pki-tomcatd@instance-name.service
```
または (nuxwdog watchdog を使用している場合)
```
# systemctl restart pki-tomcatd-nuxwdog@instance-name.service
```

18.3.3.2. デバッグログファイルのローテーション設定

Certificate System は、デバッグログをローテーションできません。デバッグロギングはデフォルトで有効になり、これらのログはファイルシステムが満杯になるまで増加します。logrotate などの外部ユーティリティーを使用してログをローテーションします。

例18.3 logrotate を使用したデバッグログのローテーション

以下の内容で /etc/logrotate.d/rhcs_debug などの設定ファイルを作成します。

/var/log/pki/instance_name/subsystem/debug {
     copytruncate
     weekly
     rotate 5
     notifempty
     missingok
}

1 つの設定ファイルで複数のサブシステムのデバッグログをローテーションするには、ログへのパスを空白で区切って、中括弧の前にリストします。以下に例を示します。

/var/log/pki/instance_name/ca/debug /var/log/pki/instance_name/kra/debug {
     ...
}

logrotate および、この例で使用するパラメーターの詳細は、logrotate(8) の man ページを参照してください。

18.3. CS.cfg ファイルでのログの設定

18.3.1. 署名監査ログの有効化および設定

18.3.1.1. 署名監査ログの有効化

18.3.1.2. 監査イベントの設定

18.3.1.2.1. 監査イベントの有効化および無効化

18.3.1.2.2. 監査イベントのフィルタリング

18.3.2. セルフテストの設定

18.3.2.1. 起動時のデフォルトのセルフテスト

18.3.2.2. セルフテスト設定の変更

18.3.3. デバッグログの追加設定

18.3.3.1. デバッグログの有効化および無効化

18.3.3.2. デバッグログファイルのローテーション設定

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

多様性を受け入れるオープンソースの強化

会社概要

Red Hat legal and privacy links

Red Hat legal and privacy links