アプライアンスのログをリモートコレクターへ安全に送る方法

アプライアンスはログを出力でき、コレクターはインターネットの反対側にあり、誰もが最初に尋ねるのはどのトンネルを構築するかです。その枠組みは間違った場所から始まっています。転送方式を決めるのは、アプライアンスが生成できる形式、コレクターが受け入れる認証、そしてリンクが切れたときに「配送済み」が何を意味するべきかです。これら三つの答えを書き留めれば、転送方式はたいてい自ら決まります。

アプライアンスが出力できるものから始める

実際には三つの形しかありません。UDP または TCP 上の個別の syslog イベント、製品に組み込まれた認証済み HTTPS アップロード、またはディスクに書き出して移動する必要のある完全なファイルです。UDP syslog しか送れないファイアウォールは、トンネルを追加しても TLS 送信者にはならず、暗号化された封筒の中に入っても未確認のデータグラムを送り続けます。

まず送信側を棚卸しします。プロトコル、TLS 対応とどの TLS ライブラリか、コレクターの証明書を検証できるか、クライアント証明書を提示できるか、送信バッファが再起動を生き延びるか、そしてアプライアンスにできないことは経路上の別の何かが行う必要があり、その別の何かが設計の一部になります。

TLS syslog：両端が話せる場合の最短経路

アプライアンスが TLS 上の syslog をサポートし、コレクターがそれを終端するなら、それを使って止めます。アプリケーション層のプロトコルが自らを守り、コレクターが送信者を認証し、可用性を自分で負う余分なホップはありません。落とし穴は、「TLS syslog」が幅広い実装を覆っていることであり、現在の安全な syslog の指針は古いチュートリアルの暗号リストから先へ進んでおり、だからこそ動作していたフォワーダーがライブラリ更新後に壊れるのです。

rsyslog では、トランスポートモジュールの名前だけでどの時代かが分かり、lmnsd_gtls は GnuTLS を包み、lmnsd_ossl は OpenSSL を包み、現行の 8.x パッケージは後者を同梱しており、証明書検証付きの転送アクションはおおよそ次のようになり、正確なパラメーター名はインストール済みのバージョンで確認する価値があります。

action(type="omfwd" target="collector.example" port="6514" protocol="tcp"
       StreamDriver.Name="ossl" StreamDriver.Mode="1" StreamDriver.AuthMode="x509/name"
       StreamDriver.CAFile="/etc/pki/ca.pem"
       queue.type="LinkedList" queue.filename="fwdq" queue.maxDiskSpace="1g"
       queue.saveOnShutdown="on" action.resumeRetryCount="-1")

送信側をデバッグする前にエンドポイントを検証します。openssl s_client -connect collector.example:6514 -servername collector.example -CAfile /etc/pki/ca.pem -verify_return_error は有効なチェーンでハンドシェイクを完了するか、どの検査が失敗したかを正確に伝えます。ノートパソコンではなくアプライアンスから試すべきであり、重要なのはアプライアンスのトラストストアだからです。

SFTP：ファイルには適し、ストリームには不適

ファイルベースの配送は、ローテーションするログだけを書き出すアプライアンスに適しています。SSH ベースの転送はホスト鍵、アカウントごとの鍵、監査できるファイルシステムを提供し、TLS をまったく扱えない機器にとっては妥当な信頼の筋書きです。イベントストリームには不向きで、「ファイルは毎時書き出される」とは、障害が現在の時間の末尾を失わせることを意味します。

ホスト検証は有効のままにし、プロンプトを避けるためにそれを切るバッチ呼び出しは、転送が持つ唯一の認証を無効にします。

sftp -b /etc/logship/batch -o BatchMode=yes -o StrictHostKeyChecking=yes      -o IdentitiesOnly=yes -i /etc/logship/id_ed25519 [email protected]

プロビジョニング時にホスト鍵をアカウントの known_hosts に固定し、アカウントを対象ディレクトリに限定し、chroot 付きの internal-sftp サブシステムを優先し、再送の話も計画します。部分的な失敗の後にファイルを再送する場合、コレクターは到着時刻ではなく、通常は名前とチェックサムで重複と新規ファイルを区別できなければなりません。

ローカルゲートウェイやトンネルが誠実な答えである場合

一部のアプライアンスは、誰も公開したくない形式しか話せません。その場合、アプライアンス自身のネットワーク上の許可されたコレクターがネイティブ形式を受け取り、TLS で先へ転送します。何を買うのかを正確に述べるべきで、ゲートウェイで始まる暗号化は、アプライアンスとゲートウェイの間の区間を遡って保護しないため、そのホップには依然として独自の信頼境界とアクセス制御が必要です。

ルーティングされたサイトまたはデバイスのトンネルは最も重い選択肢であり、コレクターがプライベートアドレスを保持する必要があるうえに複数のサービスを運ぶ場合に正しい選択です。アドレス計画、アクセス規則、戻り経路、トンネル端点のライフサイクルを伴います。内部プロトコルも改善せず、IPsec トンネル内の UDP syslog は配送確認のないデータグラムサービスのままです。

何を選んでも、コレクターの認可は転送より狭く保ちます。トンネルの識別子は端点に属し、メッセージ内の特定のホスト名フィールドをどの下流のアプライアンスが生成したかについては何も語りません。

発送前に配送契約を書く

暗号化、認証、保持は異なる問いに答えるもので、キューは保持ポリシーではなく、最初のログがアプライアンスを離れる前に、このコレクターで確認が実際に何を意味するかを決めます。回線上で受信したのか、処理のために受理したのか、それともストレージに永続的に書き込んだのかです。これは三つの異なる保証であり、コレクターの再起動を生き延びるのは最後の一つだけです。

次に運用上の問いを文書で答えます。未送信のイベントはどこで待ち、そのバッファは停電を生き延びるのか。満杯になったら何が起こり、誰に通知されるのか。再試行はどう制限され、重複はどう識別されるのか。転送ホップがホスト名を書き換える可能性があるなか、どのフィールドが送信者の身元を証明するのか。

設計は一つの段落で説明できるほど小さく保ち、必要なイベントを運ぶ最小の対応転送方式に、それが提供しない保証の明示的な記述を添えます。答えが二つのホップを必要とするなら、runbook にそう書き、各ホップに責任者を置きます。