13.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. 新しいログを作成します。
  4. ログインスタンスを設定するには、そのログに関連付けられたパラメーターを変更します。これらのパラメーターは log.instance で始まります。

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

    タイプ

    ログファイルのタイプ (例: signedAudit)。

    enable

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

    level

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

    fileName

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

    bufferSize

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

    flushInterval

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

    maxFileSize

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

    rolloverInterval

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

    register [a]

    この変数はデフォルトで false に設定されており、この設定は機能の改善により維持されます。セルフテストメッセージは、selftests.container.logger.fileName で指定されたログファイルにのみ記録されます。

    logSigning [b]

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

    signedAuditCertNickname [c]

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

    events [d]

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

    [a] register はセルフテストログ専用です。
    [b] logSigning は監査ログ専用です。
    [c] signedAuditCertNickname は監査ログ専用です。
    [d] events は監査ログ専用です。
  5. ファイルを保存します。
  6. サブシステムインスタンスを開始します。

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

    Nuxwdog ウォッチドッグを使用している場合は以下を使用します。

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

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

13.3.1.1. 署名付き監査ログの有効化

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

  • 現在の監査ログ設定を表示するには、
    pki-server subsystem-audit-config-show -i <instance_name> コマンドを使用します。

    たとえば、CA サブシステムの場合は以下を実行します。

    # pki-server ca-audit-config-show -i rhcs10-RSA-SubCA
    
      Enabled: True
      Log File: var/lib/pki/rhcs10-RSA-SubCA/logs/ca/signedAudit/ca_audit
      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: NHSM-CONN-XC:auditSigningCert cert-rhcs10-RSA-SubCA CA
    Copy to Clipboard
  • 署名付き監査ログを有効にするには、pki-server ユーティリティーを使用して --logSigning オプションを true に設定します。

    # pki-server subsystem-audit-config-mod --logSigning True -i instance_name
    Copy to Clipboard
    1. インスタンスを停止します。

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

      Nuxwdog ウォッチドッグを使用している場合は以下を使用します。

      # systemctl stop pki-tomcatd-nuxwdog@instance_name.service
      Copy to Clipboard
    2. CA サブシステムの場合は、pki-server <subsystem>-audit-config-mod コマンドを実行します。

      # pki-server ca-audit-config-mod --logSigning True -i rhcs10-RSA-SubCA
        ...
        Log Signing: True
        ...
      Copy to Clipboard
    3. インスタンスを起動します。

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

      Nuxwdog ウォッチドッグを使用している場合は以下を使用します。

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

13.3.1.2. 監査イベントの設定

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

監査イベントの有効化と無効化の詳細は、管理ガイド (Common Criteria Edition) の 12.1.2.3 コンソールでの署名付き監査ログの設定 を参照してください。

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

Certificate System で監査可能なイベントの完全なリストは、管理ガイド (Common Criteria Edition) の付録 E 監査イベント を参照してください。

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

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

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

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

Presence

(attribute=*)

(ReqID=*)

Equality

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

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

  • プロファイル証明書要求の現在の設定を表示するには、以下を実行します。

    $ pki-server ca-audit-event-show PROFILE_CERT_REQUEST -i <instance_name>
    
      Event Name: PROFILE_CERT_REQUEST
      Enabled: True
      Filter: None
    Copy to Clipboard
  • 処理された証明書要求の現在の設定を表示するには、以下を実行します。

    $ *pki-server ca-audit-event-show CERT_REQUEST_PROCESSED -i <instance_name>*
    
      Event Name: CERT_REQUEST_PROCESSED
      Enabled: True
      Filter: None
    Copy to Clipboard
  • InfoName フィールドが rejectReason または cancelReason に設定されている処理済み証明書要求のイベントと、プロファイル証明書要求およびイベントの失敗したイベントのみを記録するには、以下を実行します。

    1. Certificate System を停止します。

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

      Nuxwdog ウォッチドッグを使用している場合は以下を使用します。

      # systemctl stop pki-tomcatd-nuxwdog@instance_name.service
      Copy to Clipboard
    2. プロファイル証明書要求に対して次のコマンドを実行します。

      $ pki-server ca-audit-event-update PROFILE_CERT_REQUEST --filter "(Outcome=Failure)" i <instance_name>
        ...
        Filter: (Outcome=Failure)
      Copy to Clipboard

      これにより、CA の CS.cfg に次のエントリーが作成されます。

      log.instance.SignedAudit.filters.PROFILE_CERT_REQUEST=(Outcome=Failure)
      Copy to Clipboard
    3. 処理された証明書要求に対して次のコマンドを実行します。

      $ pki-server ca-audit-event-update CERT_REQUEST_PROCESSED --filter "(|(InfoName=rejectReason)(InfoName=cancelReason))" i <instance_name>
        ...
        Filter: (|(InfoName=rejectReason)(InfoName=cancelReason))
      Copy to Clipboard

      これにより、CA の CS.cfg に次のエントリーが作成されます。

      log.instance.SignedAudit.filters.CERT_REQUEST_PROCESSED=(|(InfoName=rejectReason)(InfoName=cancelReason))
      Copy to Clipboard
    4. Certificate System を開始します。

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

      Nuxwdog ウォッチドッグを使用している場合は以下を使用します。

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

13.3.2. セルフテストの設定

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. サブシステムインスタンスを停止します。
  2. インスタンスの conf/ ディレクトリーにある CS.cfg ファイルを開きます。
  3. self-test ログの設定を編集するには、selftests.container.logger で始まるエントリーを編集します。指定のない限り、これらのパラメーターはコンプライアンスには影響しません。これには、以下のパラメーターが含まれます。

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

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

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

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

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

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

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

  1. Certificate System インスタンスを停止します。

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

    Nuxwdog ウォッチドッグを使用している場合は以下を使用します。

    # systemctl stop pki-tomcatd-nuxwdog@instance-name.service
    Copy to Clipboard
  2. /CS.cfg ファイルを編集し、debug.enabled パラメーターを設定します。

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

      debug.enabled=false
      Copy to Clipboard
      注記

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

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

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

      debug.enabled=true
      Copy to Clipboard
  3. Certificate System インスタンスを起動します。

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

    Nuxwdog ウォッチドッグを使用している場合は以下を使用します。

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

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

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

例13.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