SLESシステムログをリモートSyslogサーバーに安全にエクスポートする方法

SUSE Linux Enterprise Server (SLES) のシステムログをリモートの syslog コレクタにエクスポートする最も安全で実用的な方法は、TLS を使用した TCP 上で rsyslog を使用し、コレクタ証明書を名前で検証し、転送アクションに専用のキューを割り当てることです。通常の UDP syslog はシンプルですが、機密性やピア認証は提供されません。通常の TCP は配信動作を改善しますが、転送中にログの内容が公開される可能性は依然として残ります。

このガイドでは、GnuTLS ネットワーク ストリーム ドライバ ( gtls) と最新の rsyslog アクション構文を使用します。この手順は、2026 年 10 月 1 日に管理ガイドが更新された SLES 15 SP7 システムを対象としています。設定をそのままコピーする前に、ホスト上の正確なパッケージと rsyslog のバージョンを必ず確認してください。rsyslog のアップストリーム ドキュメントでは、最新のデプロイメントには TLS を使用した TCP を推奨しており、TCP 転送にはアクション キューを使用することを推奨しています。

信頼できる参考資料: SUSE Linux Enterprise Server 15 SP7 ドキュメント、rsyslog omfwd ドキュメント、rsyslog TLS クライアント設定、およびRFC 5425: Syslog の TLS トランスポート マッピング。

クイックリファレンス

転送を設定する前に

リモートコレクターの完全修飾ドメイン名、リッスンしているTCPポート、およびコレクター証明書に署名する認証局（CA）証明書が必要です。相互TLSの場合は、SLESマシン用のクライアント証明書と秘密鍵も必要です。コレクター証明書は、rsyslogで設定したホスト名に対して有効である必要があり、できればサブジェクト代替名（SAN）を使用して有効にする必要があります。名前の不一致を解決するために証明書の検証を無効にしないでください。

リモートコレクターは、TLS syslogを受け入れるように既に設定されている必要があります。この記事ではSLES送信側に焦点を当てています。受信側の設定は、rsyslog、syslog-ng、SIEMアプライアンス、マネージドログサービスなどによって異なるためです。ファイアウォールでシステムが分離されている場合は、SLESホストが設定されたポートでコレクターへのTCP接続を開始できるようにしてください。デフォルトのステートフルfirewalldポリシーでは、通常、SLES送信側で受信ポートを開く必要はありません。

ステップ1：rsyslogがインストールされていることを確認し、現在のビルドを特定します。

まず、パッケージとデーモンのバージョンを確認してください。これにより、古いサンプルコードがサーバーのビルドでサポートされていないディレクティブを使用している場合に発生する混乱を防ぐことができます。

rpm -q rsyslog
rsyslogd -v
systemctl status rsyslog --no-pager

rsyslogがインストールされていない場合は、有効になっているSLESリポジトリからインストールしてください。長時間ログ記録接続を公開する前に、通常のSUSEアップデートプロセスを通じてシステムを最新の状態に保ってください。

ステップ2：GnuTLS rsyslogモジュールをインストールする

SLESでは、TLSネットワークドライバは別パッケージになっています。GnuTLSモジュールをインストールし、基本となるrsyslogパッケージはそのまま残してください。

sudo zypper install rsyslog rsyslog-module-gtls

ファイルが想定どおりのパッケージから取得されたことを確認するには、 を使用しますrpm -ql rsyslog-module-gtls。パッケージ名はディストリビューション固有のものであるため、Debian または RHEL 向けのガイドからパッケージ名をコピーしないでください。

ステップ3：CAとクライアントの認証情報を安全な場所に配置する

組織またはログ記録プラットフォームが発行した証明書を使用してください。本番システムでは、ログ送信ホスト上に新しいプライベートCAを作成することは避けてください。ラボ環境ではテストCAを使用できますが、本番環境の信頼関係は組織のPKIプロセスに従う必要があります。

ルート権限でディレクトリを作成し、ファイルをコピーして、秘密鍵へのアクセスを制限します。例のファイル名は、PKIチームから提供されたパスに置き換えてください。

sudo install -d -m 0755 /etc/rsyslog.d/certs
sudo install -m 0644 ca.pem /etc/rsyslog.d/certs/ca.pem
sudo install -m 0644 sles-client.crt /etc/rsyslog.d/certs/sles-client.crt
sudo install -m 0600 sles-client.key /etc/rsyslog.d/certs/sles-client.key
sudo chown root:root /etc/rsyslog.d/certs/*

ファイル名を信用するのではなく、認証局（CA）とクライアント証明書を検査してください。

openssl x509 -in /etc/rsyslog.d/certs/ca.pem -noout -subject -issuer
openssl x509 -in /etc/rsyslog.d/certs/sles-client.crt -noout -subject -issuer -dates

rsyslog TLSクライアントのドキュメントには、マシンの秘密鍵を保護する必要があることが明記されています。他のユーザーが秘密鍵を読み取ることができれば、そのユーザーはログクライアントになりすますことができる可能性があります。

ステップ4：サーバー名検証によるTLS転送の設定

専用のドロップインを作成します/etc/rsyslog.d/60-remote-tls.conf。リモート転送をベンダー構成から分離することで、レビューとロールバックが容易になります。

global(
    DefaultNetstreamDriver="gtls"
    DefaultNetstreamDriverCAFile="/etc/rsyslog.d/certs/ca.pem"
    DefaultNetstreamDriverCertFile="/etc/rsyslog.d/certs/sles-client.crt"
    DefaultNetstreamDriverKeyFile="/etc/rsyslog.d/certs/sles-client.key"
)

action(
    type="omfwd"
    target="logs.example.com"
    port="6514"
    protocol="tcp"
    StreamDriver="gtls"
    StreamDriverMode="1"
    StreamDriverAuthMode="x509/name"
    StreamDriverPermittedPeers="logs.example.com"
    queue.type="linkedList"
)

StreamDriverMode="1"重要なのは、モードがデフォルトでプレーンな TCP になっている構成では、TLS 対応ドライバを選択するだけでは不十分であるということです。StreamDriverAuthMode="x509/name"次に、リモート証明書を検証し、サーバーの ID が許可されたピアと一致するかどうかを確認します。可能な限り、広範なワイルドカードではなく、証明書内の正確なコレクタ名を使用してください。

上記のアクションは、受信したすべてのメッセージを転送します。特定の機能や優先度のみを転送したい場合は、アクションの前にフィルタを追加してください。たとえば、セキュリティ重視の環境では、認証イベントやデーモンイベントを転送しつつ、大量のアプリケーションデバッグログをローカルに保持することができます。フィルタリングは、すべてのメッセージをホストから送信する必要があるという一律の前提ではなく、保持、インシデント対応、コンプライアンスの要件に基づいて行うべきです。

ステップ5：検証、再起動、テストイベントの送信、配信確認

サービスを再起動する前に、rsyslogの設定全体を検証してください。これは、構文エラーやモジュール参照の欠落を検出する最も迅速な方法です。

sudo rsyslogd -N1

検証が成功した場合は、rsyslogを再起動し、固有のテストメッセージを送信します。

sudo systemctl restart rsyslog
sudo systemctl status rsyslog --no-pager
logger -t sles-tls-test "remote syslog TLS test $(date -Is)"
sudo journalctl -u rsyslog -n 50 --no-pager

コレクター上で、タグsles-tls-testと送信元ホスト名を検索します。リモートアクセスが成功すれば、メッセージがコレクターに到達したことは証明されますが、それだけでは証明書検証が正しく設定されていることを証明するものではありません。より確実な確認方法としては、証明書検証をx509/name有効にしたまま、rsyslogサービスログにTLSハンドシェイクエラーやピア名エラーがないことを確認することです。

接続に失敗した場合は、DNS解決をテストしlogs.example.com、TCP 6514ポートに到達可能であることを確認し、証明書の有効期限を確認し、コレクター証明書に期待されるDNS名が含まれていることを確認してください。また、相互TLSが有効になっている場合、コレクターがSLESクライアント証明書を発行した認証局を信頼していることを確認してください。

トラブルシューティングチェックリスト

• 接続が拒否されました：コレクターが設定されたアドレス/ポートで待機していないか、ファイアウォールが接続を拒否しています。
• タイムアウト：ルーティング、ネットワークACL、またはファイアウォールが、トラフィックをサイレントに破棄している。
• 証明書の検証に失敗しました。CAファイルが間違っているか、不完全か、有効期限が切れているか、またはサーバー証明書チェーンが不完全です。
• ピア名の不一致:target /名前StreamDriverPermittedPeersがコレクター証明書の識別情報と一致しません。
• キーへのアクセスが拒否されました:キーのパスまたはアクセス権限により、rsyslog プロセスが SLES サービス構成内のファイルを読み取ることができません。
• 障害発生時にメッセージが停止する場合は、アクションキューの設計と容量を確認してください。上流のomfwdドキュメントでは、TCP転送用のキューを使用することを特に推奨しており、これにより、宛先が利用できない場合でも通常の処理が妨げられることがなくなります。

見落としやすいセキュリティに関する注意事項

トレードオフを十分に理解していない限り、証明書検証を匿名TLSに置き換えないでください。サーバーを認証せずに暗号化しても、アクティブな中間者攻撃者にログが漏洩する可能性があります。同様に、宛先がTCP 6514ポートを使用しているという理由だけで、SLES送信側で受信側のTCP 6514ポートを開放しないでください。転送は送信クライアント接続です。

クライアントの秘密鍵を認証情報として保護し、証明書の有効期限が切れる前に更新し、IPアドレスの変更後も安定したコレクターホスト名を使用してください。通常のTCP/TLS転送よりも強力な配信保証が必要な場合は、rsyslogのドキュメントで、確認応答配信用に設計された代替手段としてRELPが挙げられています。これは、トランスポート暗号化とは別の設計上の選択肢です。

最終確認

適切なデプロイメントは、次の4つの条件を満たす必要があります。rsyslog構成の検証が正常に完了すること、サービスが再起動後もアクティブな状態を維持すること、コレクターが固有のテストイベントを受信すること、そして送信者ログにTLS信頼エラーやピア名エラーが表示されないこと。これらのチェックに合格したら、証明書の有効期限とリモートコレクターの依存関係を文書化し、今後のメンテナンスで集中ログ記録が予期せず破損しないようにします。