Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

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

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

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

    # systemctl stop pki-tomcatd-nuxwdog@instance_name.service
    Copy to Clipboard
  2. /var/lib/pki/<instance_name>/<subsystem_type>/conf ディレクトリーの CS.cfg ファイルを開きます。
  3. 新しいログを作成するには、システムまたはトランザクションログのすべてのエントリーをコピーします。これらは、log.instance.Transactions または log.instance.System で始まるパラメーターです。ログセクションの下部にすべてのエントリーを貼り付け、各パラメーターの Transactions または System という単語を新しい名前に変更して、このインスタンスの名前を変更します。

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

    表17.3 ログエントリーパラメーター
    パラメーター説明

    type

    ログファイルのタイプ。システム はエラーおよびシステムログを作成します。トランザクション は監査ログを記録します。

    enable

    ログがアクティブかどうかを設定します。有効にするログのみがイベントを記録します。

    level

    テキストフィールドにログレベルを設定します。このレベルは、フィールドに手動で入力する必要があります。選択メニューはありません。ログレベル設定は、「ログレベル (メッセージカテゴリー)」 に記載されている数値です。

    fileName

    ログファイルへのファイル名を含む完全パス。サブシステムユーザーには、ファイルへの読み書きパーミッションがなければなりません。

    bufferSize

    ログのキロバイトサイズ (KB) のバッファーサイズ。バッファーがこのサイズに達すると、バッファーの内容はフラッシュされ、ログファイルにコピーされます。デフォルトのサイズは 512 KB です。バッファーロギングの詳細は、「バッファー付きおよびバッファーなしのロギング」 を参照してください。

    flushInterval

    バッファーの内容がフラッシュされてログファイルに追加されるまでの時間 (秒単位)。デフォルトの間隔は 5 秒です。

    maxFileSize

    ローテーションされる前に可能なログファイルのサイズをキロバイト (KB) 単位で設定できます。このサイズに達すると、ファイルはローテーションファイルにコピーされ、ログファイルが新たに開始されます。ログファイルのローテーションに関する詳細は、「ログファイルローテーション」 を参照してください。デフォルトのサイズは 2000 KB です。

    rolloverInterval

    サーバーがアクティブなログファイルをローテーションする頻度。利用可能な選択肢は hourly、daily、weekly、monthly、および yearly です。デフォルトの選択は monthly です。詳細は、「ログファイルローテーション」 を参照してください。

    register

    この変数が false (デフォルト値) に設定されている場合には、セルフテストのメッセージは、selftests.container.logger.fileName で指定されるログファイルにのみログに記録されます。この変数が true に設定されている場合は、セルフテストのメッセージは selftests.container.logger.fileName によって指定したログファイルと、log.instance.Transactions.fileName で指定されたログファイルの両方に書き込まれます。

    logSigning

    署名付きロギングを有効にします。このパラメーターが有効な場合は、signedAuditCertNickname パラメーターの値を指定します。このオプションは、監査人だけがログを表示できることを意味します。値は true または false です。

    signedAuditCertNickname

    監査ログの署名に使用される証明書のニックネーム。この証明書の秘密鍵は、ログに署名するためにサブシステムからアクセスできる必要があります。

    events

    監査ログにログを記録するイベントを指定します。ログイベントは、空白のないコンマで区切ります。

  5. ファイルを保存します。

  6. サブシステムインスタンスを開始します。 

    systemctl start pki-tomcatd@instance_name.service
    Copy to Clipboard

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

    # systemctl start pki-tomcatd-nuxwdog@instance_name.service
    Copy to Clipboard

17.3.1. 署名付き監査ログの有効化と設定

17.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
Copy to Clipboard

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

  1. pki-server ユーティリティーを使用して、--logSigning オプションを true に設定します。 

    # pki-server subsystem-audit-config-mod --logSigning True
  ...
  Log Signing: True
  ...
    Copy to Clipboard

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

    # systemctl restart pki-tomcatd@instance_name.service
    Copy to Clipboard

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

    # systemctl start pki-tomcatd-nuxwdog@instance_name.service
    Copy to Clipboard

17.3.1.2. 監査イベントの設定

17.3.1.2.1. 監査イベントの有効化と無効化

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

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

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

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

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

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

表17.4 サポート対象の監査イベントフィルター
型形式例

要否

(attribute=*)

(ReqID=*)

等式

(attribute=value)

(Outcome=Failure)

部分文字列

(attribute=initial*any*…​*any*final)

(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 管理ガイド の 複合検索フィルターの使用 セクションを参照してください。

例17.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
Copy to Clipboard

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

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

    $ 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))
    Copy to Clipboard

  2. Certificate System を再起動します。 

    # systemctl restart pki-tomcatd@instance_name.service
    Copy to Clipboard

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

    # systemctl start pki-tomcatd-nuxwdog@instance_name.service
    Copy to Clipboard

17.3.2. セルフテストの設定

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

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

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

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

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

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

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

  • CAPresence: CA サブシステムが存在することを確認するために使用されます。
  • CAValidity: CA サブシステムが現在有効であり、期限切れでないことを確認するために使用されます。これには、CA 証明書の有効期限を確認する必要があります。

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

    selftests.plugin.SystemCertsVerification.FullCAandOCSPVerify=true
    Copy to Clipboard

    デフォルトでは、この設定パラメーターが存在しない場合は false と見なされます。

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

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

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

  • OCSPPresence: OCSP サブシステムの有無を確認するために使用されます。
  • OCSPValidity: OCSP サブシステムが現在有効であり、期限切れでないことを確認するために使用されます。これには、OCSP 証明書の有効期限を確認する必要があります。

  • SystemCertsVerification: システム証明書が現在有効であり、有効期限が切れていないか、または取り消されていないことを確認するために使用されます。OCSP サブシステムの場合は、各証明書の有効性テストのみが実行され、OCSP 要求が発生する可能性のある証明書検証テストは除外されます。この動作は、以下の設定パラメーターで上書きできます。 

    selftests.plugin.SystemCertsVerification.FullCAandOCSPVerify=true
    Copy to Clipboard

    デフォルトでは、この設定パラメーターが存在しない場合は false と見なされます。

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

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

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

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

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

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

  1. サブシステムインスタンスを停止します。
  2. インスタンスの conf/ ディレクトリーにある CS.cfg ファイルを開きます。

  3. self-test ログの設定を編集するには、selftests.container.logger で始まるエントリーを編集します。指定のない限り、これらのパラメーターはコンプライアンスには影響しません。これには、以下のパラメーターが含まれます。

    • bufferSize: ログのバッファーサイズをキロバイト単位 (KB) で指定します。デフォルトのサイズは 512 KB です。バッファーがこのサイズに達すると、バッファーの内容はフラッシュされ、ログファイルにコピーされます。
    • enable: 有効にする場合は true を指定します。有効にするログのみがイベントを記録します。この値は、コンプライアンスのために有効にする 必要 があります。
    • fileName: ファイル名を含む、メッセージを書き込むファイルの完全パスを指定します。サーバーに、ファイルへの読み取り/書き込み権限が必要です。デフォルトでは、セルフテストのログファイルは /selftest.log です。
    • flushInterval: バッファーをファイルにフラッシュする間隔を秒単位で指定します。デフォルトの間隔は 5 秒です。flushInterval は、バッファーの内容がフラッシュされログファイルに追加されるまでの時間です。
    • level: デフォルトでは 1 が選択されています。このログは、1 以外のレベルでは設定されません。
    • maxFileSize: エラーログのファイルサイズをキロバイト単位 (KB) で指定します。デフォルトのサイズは 100 KB です。maxFileSize は、ログファイルがローテーションされる前のサイズを決定します。このサイズに達すると、ファイルはローテーションファイルにコピーされ、新しいログファイルが起動します。
    • register: この変数が false (デフォルト値) に設定されている場合には、セルフテストのメッセージは、selftests.container.logger.fileName で指定されるログファイルにのみログに記録されます。この変数が true に設定されている場合は、セルフテストのメッセージは selftests.container.logger.fileName によって指定したログファイルと、log.instance.Transactions.fileName で指定されたログファイルの両方に書き込まれます。
    • rolloverInterval: アクティブなエラーログファイルをサーバーがローテーションする頻度を指定します。選択肢は hourly、daily、weekly、monthly、および yearly です。デフォルトの選択は monthly です。
    • type: transaction に設定してください。これは変更しないでください。

  4. セルフテストを実行する順序を編集するには、コンマとスペースで区切った次のパラメーターの値としてセルフテストのいずれかをリストすることにより、順序を指定します。

    セルフテストをクリティカルとしてマークするには、リスト内のセルフテストの名前にコロンとクリティカルという単語を追加します。

    セルフテストを無効にするには、selftests.container.order.onDemand または selftests.container.order.startup のパラメーターの値の設定を削除します。

  5. ファイルを保存します。
  6. サブシステムを起動します。

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

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

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

  1. /CS.cfg ファイルを編集し、debug.enabled パラメーターを設定します。

    • デバッグのロギングを無効にするには、以下を設定します。 

      debug.enabled=false
      Copy to Clipboard
      注記

      デバッグログは監査ロギングの一部では ありません。デバッグログは、Certificate System で特定の障害をデバッグする場合や、インストールの失敗時に便利です。

      デフォルトで、デバッグログは有効です。望ましい場合には、管理者はデバッグロギングを安全に無効にして詳細度を下げることができます。

    • デバッグロギングを有効にするには、以下を実行します。 

      debug.enabled=true
      Copy to Clipboard

  2. Certificate System インスタンスを再起動します。 

    # systemctl restart pki-tomcatd@instance-name.service
    Copy to Clipboard

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

    # systemctl restart pki-tomcatd-nuxwdog@instance-name.service
    Copy to Clipboard

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

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

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

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

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

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

/var/log/pki/ instance_name/ca/debug /var/log/pki/ instance_name/kra/debug {
     ...
}
Copy to Clipboard

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

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

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

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat