rsyslogと相互TLSを使用したSLES Syslogの安全な転送

SUSE Linux Enterprise Server (SLES) のシステムログを安全に転送するには、rsyslog を設定して TLS で保護された TCP ポート 6514 経由でメッセージを送信し、コレクターの証明書名を確認し、テスト イベントで配信を確認します。SLES 15 SP7 は、2026 年 3 月 27 日に OpenSSL TLS モジュールを追加するオプションの rsyslog アップデートを受けましたが、以下の設定では、gtls代わりに確立された GnuTLS ( ) モジュールを意図的に使用しています。

この手順では、SLES 15 の送信者sles01.example.netと rsyslog コレクターを使用しますlogs.example.net。両方の名前とすべての証明書パスを、ご自身の値に置き換えてください。相互 TLS を使用するため、コレクターは送信者を認証し、送信者もコレクターを認証します。

1. rsyslogとSLESのログ記録パスを確認します。

両方のホストで、登録済みのSUSEリポジトリからrsyslogデーモンとそのGnuTLSモジュールをインストールしてください。既存のインストール環境では、最初のパッケージは既に含まれている場合があります。

sudo zypper install rsyslog rsyslog-module-gtls
rpm -q rsyslog rsyslog-module-gtls
sudo systemctl enable --now rsyslog
rsyslogd -v

/etc/rsyslog.confルールを追加する前に、既存のスニペットを確認してください/etc/rsyslog.d/。特に、*.* @@host同じ宛先に対する古い暗号化されていない転送ルールはすべて無効にしてください。そうしないと、メッセージがTLSを使用しないルートを含む2つのルートを経由する可能性があります。

SLES はsystemd-journaldジャーナル イベントに を使用し、rsyslog は syslog 入力を処理します。必要なイベントが既存の入力構成を通じて rsyslog に到達することを確認してください。SUSE のドキュメントForwardToSyslog=yesには/etc/systemd/journald.conf、ジャーナルから syslog への転送に関する記述があります。ジャーナル リーダーを個別に有効にすると重複イベントが発生する可能性があるため、変更する前にデプロイメントを確認してください。この手順では、rsyslog によって既に処理されたメッセージが転送され、 の下のすべてのファイルが/var/log自動的に転送されるわけではありません。

2. 信頼できるサーバー証明書とクライアント証明書を準備する

logs.example.net組織が管理する認証局（CA）を使用して、収集者用のDNSサブジェクト代替名を含む証明書と、sles01.example.net送信者を識別するための別の証明書を発行してください。証明書がTLSサーバーまたはクライアントの役割に対して有効であり、両方のマシンが発行元のCAを信頼していることを確認してください。生成と更新については、PKIのプロセスに従ってください。複数のホスト間で秘密鍵を再利用しないでください。

管理者が承認したセキュアチャネル経由で適切なファイルをコピーします。この例では、両方のマシンが を使用します/etc/rsyslog.d/tls/ca.pem。コレクターにはさらにserver-cert.pemと がありserver-key.pem、送信者にはclient-cert.pemと がありますclient-key.pem。

sudo install -d -m 0750 /etc/rsyslog.d/tls
sudo chmod 0600 /etc/rsyslog.d/tls/*-key.pem
sudo chmod 0644 /etc/rsyslog.d/tls/ca.pem

必要に応じて、証明書と鍵へのアクセスをrsyslogサービスIDに制限してください。診断情報、シェル履歴、Gitリポジトリ、エクスポートされたログストリームに秘密鍵を漏らさないでください。デーモンを再起動する前に、rsyslogプロセスが鍵を読み取れることを確認してください。

3. コレクター上で認証付きTLSレシーバーを有効にする

にlogs.example.net、以下をとして追加します/etc/rsyslog.d/30-tls-listener.conf。がimtcp既に他の場所でロードされている場合は、モジュールロードステートメントを1つだけ残します。専用のルールセットは、リモートで受信したメッセージをローカルシステムメッセージと混在させるのではなく、別のファイルに配置します。

global(
  DefaultNetstreamDriverCAFile="/etc/rsyslog.d/tls/ca.pem"
  DefaultNetstreamDriverCertFile="/etc/rsyslog.d/tls/server-cert.pem"
  DefaultNetstreamDriverKeyFile="/etc/rsyslog.d/tls/server-key.pem"
)
module(load="imtcp")
ruleset(name="remote_tls") {
  action(type="omfile" file="/var/log/remote-tls.log")
}
input(
  type="imtcp"
  port="6514"
  StreamDriver.Name="gtls"
  StreamDriver.Mode="1"
  StreamDriver.AuthMode="x509/name"
  PermittedPeer="sles01.example.net"
  ruleset="remote_tls"
)

StreamDriver.Mode="1"TLSを有効にし、承認された証明書IDを持たないクライアントを拒否しx509/nameますPermittedPeer。許可される名前が1つだけなのは意図的なものです。認証を弱めるのではなく、他の送信者を追加する場合は、承認済みピアリストを拡張してください。

sudo rsyslogd -N1
sudo systemctl restart rsyslog
sudo firewall-cmd --permanent --add-port=6514/tcp
sudo firewall-cmd --reload
sudo ss -ltn | grep ':6514'

コレクターが firewalld を使用している場合にのみ、ファイアウォールコマンドを実行してください。ホストまたはアップストリームのファイアウォールを使用して、受信 TCP/6514 を既知の送信元ネットワークに制限してください。ポートを開放しても、証明書認証は置き換えられません。また、既存の平文リスナーが意図せず公開されていないことを確認してください。

4. SLESにTLS転送とバウンドキューを追加する

ではsles01.example.net、rsyslog 作業ディレクトリが存在し、サービスによって書き込み可能であることを確認してください。ここに示されているディレクトリは例示です。workDirectoryパッケージ化されたセットアップに既に設定されているディレクトリが含まれている場合は、それを保持してください。次のスニペットを に追加します/etc/rsyslog.d/60-tls-forward.conf。

global(
  DefaultNetstreamDriverCAFile="/etc/rsyslog.d/tls/ca.pem"
  DefaultNetstreamDriverCertFile="/etc/rsyslog.d/tls/client-cert.pem"
  DefaultNetstreamDriverKeyFile="/etc/rsyslog.d/tls/client-key.pem"
)
*.* action(
  type="omfwd"
  target="logs.example.net"
  port="6514"
  protocol="tcp"
  StreamDriver="gtls"
  StreamDriverMode="1"
  StreamDriverAuthMode="x509/name"
  StreamDriverPermittedPeers="logs.example.net"
  queue.type="LinkedList"
  queue.filename="tls_forward"
  queue.size="10000"
  queue.maxDiskSpace="1g"
  queue.saveOnShutdown="on"
  action.resumeRetryCount="-1"
)

TLS設定は、送信前にコレクターを認証します。ディスクアシストアクションキューは、短時間の障害発生時にメッセージをバッファリングし、転送アクションの失敗を再試行しますが、無限ではなく、すべてのメッセージ損失を防ぐ保証もありません。使用可能なディスク容量、キューの制限、プロセスのシャットダウン動作、および受信側の健全性は依然として重要です。ディスクバッファリングに頼る前に、rsyslogの実効作業ディレクトリを確認し、適切な所有権で作成してください。

送信元を検証して再起動します。

sudo rsyslogd -N1
sudo systemctl restart rsyslog

構成検証が失敗した場合は、再起動せずに、最初に報告されたエラーを修正してください。既存のrsyslog環境では、グローバル証明書ディレクティブが他のTLSアクションに影響を与える可能性があります。他の送信アクションを確認し、異なる認証情報が必要な場合は、サポートされているアクションごとの証明書パラメータを使用してください。

5. 受信確認を行い、ハンドシェイクの失敗を調査する

まず、コレクターがTCP/6514でリッスンしていること、および送信側がファイアウォール経由でホストに到達できることを確認してください。次に、SLES送信側で以下のコマンドを実行します。

logger -t sles-tls-check "TLS forwarding probe"

コレクター上で、設定済みのリモートログファイルを検索します。

sudo grep 'TLS forwarding probe' /var/log/remote-tls.log
sudo journalctl -u rsyslog -n 50 --no-pager

マーカーが見つかったということは、/var/log/remote-tls.logこのテストにおいてアプリケーションレベルの転送パスが正しく機能したことを示しています。ただし、すべてのアプリケーション固有のログファイルが収集されていることを証明するものではありません。認証を個別にテストするには、管理されたメンテナンス期間中に、一時的に信頼できない別の証明書または一致しないピア名を使用し、TLS接続が失敗することを確認してください。その後、すぐに元の構成に戻してください。

マーカーが表示されない場合は、以下の順序でエラーを確認してください。

• リスナーが存在しない、または接続が拒否された場合：systemctl status rsyslog TCP/6514 およびコレクターファイアウォールルールを確認してください。
• TLS または証明書の障害:証明書の SAN を およびPermittedPeerと比較しますStreamDriverPermittedPeers。CA チェーン、有効期限、システム クロック、および秘密鍵の権限を確認します。
• 接続はされているがイベントが発生していない：重複または欠落しているジャーナル/syslog入力、中断されている転送アクション、およびディスクキュー容量を確認してください。journalctl -u rsyslog両方のホストで確認してください。

この方法は、公式のSLES 15 SP7システムログガイド、rsyslog証明書認証クライアントガイド、imtcpリスナーリファレンス、およびomfwd転送リファレンスに準拠しています。2026年3月のSUSEアップデート通知には、オプションのOpenSSLモジュールの追加について記載されています。設定はSLESサービスパックによって異なるため、変更を本番環境に適用する前に、インストール済みのrsyslogビルドで検証してください。