1つのクラウドサービスに使うネイティブTLS、SSH転送、VPN

問題は、二台のクラウドマシン間で何かを暗号化すべきかどうかではなく、どのインターフェースを暗号化し、誰が誰の身元を確認するかです。私はネットワーク図ではなく、すでに自分に何が必要かを知っているサービスから話を始めます。ほとんどの場合は、アプリケーション自身のTLS、SSH経由で転送する一つのTCPポート、全参加者にアドレスを与えるルーテッドオーバーレイという三つの境界で覆えます。強さで順位づけされるのではなく、問題をどれだけ覆うかで順位づけされます。

ネットワークではなくサービスから始める

プロセスから外へ進みます。どのプロトコルを話し、クライアントはどの名前を検証し、誰がそもそも接続を開けるのか。この三つの答えは、どんな比較表よりも速く選択肢を消し、サービスの設定自体が通常数分でそれらに答えます。

ポート8443でHTTPSを提供し、api.internal.exampleの証明書を持つ小さな内部APIを考えます。ホスト上のss -ltnpは何に束縛されているかを示し、openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.exampleはクライアントが実際に使う名前に対して証明書が有効かを示します。両方が健全なら、サービスは自分のストリームを守れ、残るのは到達性だけです。ネットワークを構築するよりはるかに小さな問題です。

ステップ1：サービスは自分自身を守るか

合うときに選ぶ選択肢で、チームが想定するより頻繁に合います。サービスの暗号化はクライアントとサーバーの間の全経路を、途中のすべてのホップを含めて覆い、中央を迂回するトンネルでは改善できません。クライアントの既定ストアにたまたま入っているものに頼らず、期待する名前と信頼を明示的に設定します。

暗号化と到達性は別々の制御のままで、これを混ぜることがこの選択肢が誤る場所です。無制限の公開リスナー上のTLSサービスは依然として誰からの接続試行も受け入れるので、リスナーとネットワーク規則はペイロードが保護されている事実とは独立に定める必要があります。次に、TLS上のAPIは検出エンドポイント、管理ポート、隣の一括転送チャネルについて何も語らないため、依存関係を確認します。それぞれに独自の答えが必要で、保護されていない兄弟が一つあるだけで境界全体が虚構になります。

ステップ2：一つのTCPポートが要件のすべてか

要件が本当に一つのTCPポートなら、転送が機能する最小のものです。SSHのローカル転送は、すでに存在する認証済み接続を通してそのポートを運びます。

形はssh -N -L 8443:127.0.0.1:8443 [email protected]で、重要なのは、127.0.0.1がリモート側で解決されるためサービスへの接続がノートPCではなく踏み台から開かれるという宛先アドレスです。ローカルリスナーを-L 127.0.0.1:8443:...のように狭く束縛し、誤ってサービスを自分のローカルネットワークに公開しないようにします。サーバー側では、クライアントの行儀の良さを信じるのではなく、アカウントが転送できるものを制限します。PermitOpen、AllowTcpForwarding local、既定のGatewayPorts noが、汎用リレーを特定のチャネルに変える三つの設定です。

契約は両方向に狭いものです。SSHは自分のチャネルを守り、踏み台から別のアプリへのさらなるホップには独自の保護が必要です。踏み台のloopbackだけで待ち受けるサービスは、別のネットワーク越しに到達するものとはまったく異なる露出を持ち、転送はそれを変えません。トンネルをそれらの代わりとせず、アプリの認証とTLSチェックを維持します。

これは一つの所有者による一つの接続にはよく機能します。規模が大きくなると、ローカルポートの衝突、監視、鍵のローテーション、再起動後に誰が転送を再開するかという問題を抱えるシステムになります。

ステップ3：ルーティングが実際の要件か

その一覧は最小の選択肢の正直なコストであり、だからこそチームは最終的に、忘れられた数個のバックグラウンドコマンドを管理された何かに置き換えます。置き換えは自動的にVPNではありません。要件がまだ一つのTCPポートなら、文書化された所有者がいる監視付き転送は、オーバーレイより安く運用でき、目に見える形で失敗します。優雅さを測る前に運用上の所有を測りましょう。

ルーティングが要件であるとき、ルーティングが正しい答えになります。通常のIP接続を必要とする複数のアプリ、TCP転送では運べないプロトコル、ホスト間を移動するサービスは、どれも同じ方向を指します。

オーバーレイは参加者にアドレスとルートを与え、そこから重複しない範囲、ルートの所有、DNS、登録、失効、ピアが消えたときに何が起きるかという本当の仕事が始まります。どれもアドレスと一緒には来ません。オーバーレイに受け入れられたピアも、宛先のすべての操作を自動的に許可されるわけではないので、サービスレベルの認証は残ります。

その後あなたが持つもの

残す記録には二つのことが属します。一つ目はクライアントが検証すべき身元で、何かを動かすために名前の確認が緩められると、これらの境界はどれも静かに劣化するからです。二つ目は削除の手順で、アクセスが終わるときにどの鍵、どの規則、どのルートが消え、誰がそれを行うのかという点です。

この道筋は始まった場所、サービスで終わります。実際のトラフィックを覆い、意図したピアを検証する境界を選び、アクセスがどう更新され、監視され、削除されるかを書き留めます。OpenSSHのリファレンスは、狭い契約を約束する前に転送オプションを確認する場所です。削除の手順を一文で説明できないなら、境界は問題より大きいのです。