SSLはロードバランサーで終了する必要がありますか？
ウェブアプリケーションサーバーのクラスターをホストする場合、アプリサーバー間のトラフィックの負荷を分散するために、クラスターとパブリックインターネットの間にリバースプロキシ（HAProxy、Nginx、F5など）を配置するのが一般的です。ディープパケットインスペクションを実行するには、SSLをロードバランサー（またはそれ以前）で終了する必要がありますが、ロードバランサーとアプリサーバー間のトラフィックは暗号化されません。 SSLが早期に終了しても、アプリサーバーはパケットスニッフィングまたはARPポイズニングに対して脆弱ではないですか？
SSLをオフロードする必要がありますか？もしそうなら、提供されているデータの整合性を損なうことなくどのようにそれを行うことができますか？私の主な関心事は、メッセージレイヤーの暗号化がオプションではないWebアプリケーションです。
問題は「自分のデータセンターを信頼していますか」ということです。言い換えると、untrustedネットワークがあり、trustが始まる線を細かく描画しようとしているようです。
私の意見では、SSL/TLS信頼は、SSLオフロードデバイスで終了する必要があります。これは、デバイスを管理する部門がネットワークとインフラストラクチャも管理することが多いためです。そこにはある程度の契約上の信頼があります。ネットワークをサポートしているのと同じ人が通常はこれにもアクセスできるため、ダウンストリームサーバーでデータを暗号化する意味はありません。 （マルチテナント環境での例外の可能性、またはより深いセグメンテーションを必要とする固有のビジネス要件）。
SSLがロードバランサーで終了する必要がある2番目の理由は、SSL攻撃を一元化して、 [〜＃〜] crime [〜＃〜] または [〜＃〜 ] beast [〜＃〜] 。 SSLがさまざまなWebサーバーで終了し、異なるOSで実行されている場合、 追加複雑さ が原因で問題が発生する可能性が高くなります。シンプルにしておけば、長期的には問題が少なくなります。
言われていること
- はい、ロードバランサーで終了し、そこでSSLオフロードします。複雑にしないでおく。
- Citrix Netscalerロードバランサー（たとえば）は、URLへの安全でないアクセスを拒否できます。このポリシーロジックとTLSの機能を組み合わせると、データの機密性が維持され、改ざんされないようにする必要があります（私が整合性の要件を適切に理解している場合）
編集：
可能です（そして一般的です）
- ロードバランサーをアウトソーシングする（Amazon、Microsoftなど）
- サードパーティのCDN（Akamai、Amazon、Microsoftなど）を使用する
- または、サードパーティのプロキシを使用してDoS攻撃を防止する
...そのサードパーティからのトラフィックは、管理していないネットワークリンクを介してサーバーに送信されます。したがって、これらの暗号化されていないリンクを信頼しない可能性があります。その場合は、データを再暗号化するか、少なくともすべてのデータをポイントポイントVPN経由で転送する必要があります。
マイクロソフトはそのようなVPN製品を提供しており、境界の安全なアウトソーシングを可能にします。
はい、TLSをオフロードする必要があると私は主張します。私はCitrix Netscalerを使用して、以下で説明するすべてを実行しましたが、F5でも同じことができるはずです。
まず、常にロードバランサーの反対側で再暗号化することを確認する必要がありますが、TLSを復号化するデバイスは、セキュリティの観点から何が行われているのかを検査できる必要があります。このアプローチによってデータの整合性が損なわれることはありません。
多くの人々が私に、バックエンドでの再暗号化は計算的に同じくらい高価になると言っていましたが、それは真実ではありません。 TLSの費用は、TLSオフローダーが処理する接続の構築と終了です。バックエンドでは、サーバーへのより永続的な接続があるため、必要なリソースははるかに少なくなります。
さらに、TLSオフロードがない場合、TLSを介した小さなDDoS攻撃でさえサーバーを完全に破壊します。私はこの状況に非常に精通しており、TLSオフロードは計算の観点から見ると信じられないほどの助けであり、攻撃をさらに連鎖的にブロックすることもできます。非常に大きなDDoS攻撃の場合、軽減戦略をTLSオフローダーとサーバーの間で分割することもできます。
SSL接続内のデータを検査するには、次のいずれかに該当する必要があります。
- トンネルは、検査を行うマシンで終了します。あなたの「ロードバランサー」。
- 検査システムはサーバーの秘密鍵のコピーを知っており、SSL接続は一時的なDiffie-Hellmanを使用しません（つまり、サーバーは名前に「DHE」を含む暗号スイートを許可しません）。
最初のオプションに従う場合、他のSSLトンネルで再暗号化しない限り、データは検査システム（ロードバランサー）とクラスターの間を暗号化されずに移動します。メインのSSL接続は、クライアントブラウザーとロードバランサーの間、および負荷です。バランサーは、それ自体と各クラスターノードの間のSSLリンク（または他の暗号化技術、たとえば IPsec を使用したVPN）を維持します。
パケットインスペクターはデータを復号化するだけで、再暗号化する必要がないため、2番目のオプションはやや軽量です。ただし、これは、すべてのクラスターノードがクライアントと完全なSSLを実行できる、つまりサーバーの秘密キーのコピーを知っていることを意味します。また、DHEをサポートしないことは、 Perfect Forward Secrecy の気の利いた機能が得られないことを意味します（これは致命的ではありませんが、PFSはセキュリティ監査で実際によく見えるので、すばらしいことです）。
どちらの方法でも、ディープパケットインスペクションを実行するノードには、SSLトンネルへの特権アクセスが必要です。これにより、セキュリティがかなり重要になります。
ロードバランサーでSSLを終了することをお勧めします（ネットワーク上、またはCDNプロバイダーなどで）。これは、LBがトラフィックを検査し、ロードバランシングをより適切に実行できることを意味します。また、ロードバランサーが遅いクライアント、壊れたSSL実装、一般的なインターネットの不安定さを処理する責任があることも意味します。ロードバランサーの方が、バックエンドサーバーよりもリソースを確保できる可能性があります。また、世界が見るSSL証明書はすべてロードバランサー上にあることを意味します（うまくいけば、管理が容易になります）。
ここでの代替策は、TCPクライアントからバックエンドサーバーへの接続を単純に負荷分散することです。LBはこの方法で何が行われているかを検査できないため、負荷を均等に分散できません。バックエンドサーバーとバックエンドサーバーはすべてのインターネットの不安定さを処理する必要があります。ロードバランサーやCDNプロバイダーなどを信頼していない場合にのみ、この方法を使用します。
ロードバランサーからバックエンドサーバーに再暗号化するかどうかは、個人の選択と状況の問題です。クレジットカードや金融取引を扱っている場合は、おそらく政府によって規制されているため、再暗号化する必要があります。ロードバランサーとバックエンドサーバー間のトラフィックが信頼できないネットワークを経由する場合も、おそらく再暗号化する必要があります。会社のWebサイトをホストしているだけの場合は、セキュリティの側面をあまり気にしないのであれば、再暗号化による追加のオーバーヘッドを回避できる可能性があります。
再暗号化しても、思ったほどの負荷はかかりません。通常、ロードバランサーはサーバーへの永続的な接続を維持できるため、SSLコストはネットワーク上のその「ホップ」に対して非常に低くなります。
最後に考えるのは、バックエンドサーバー上のアプリケーションです。そこに到着するすべてのトラフィックがHTTPである場合、クライアントが使用していたプロトコルに基づいて決定を下すことはできません。たとえば、 "HTTP経由でログオンページにアクセスしようとしているので、HTTPSバージョンのページにリダイレクトします"とは言えません。ロードバランサーにHTTPヘッダーを追加して「これはHTTPSから来た」と言うことができますが、そのヘッダーはアプリケーションで特別な処理が必要になります。状況によっては、サイト固有の変更を必要とするよりも、再暗号化してアプリケーションを「デフォルト」の方法で動作させる方が簡単な場合があります。
要約すると、ロードバランサーで終了し、バックエンドサーバーに再暗号化します。これを実行して問題が発生した場合は、必要に応じて調整できます。
より低いキーの証明書で内部トラフィックを暗号化することを選択できます。また、スニッフィングや中間者攻撃を防ぐために、ロードバランサーをサーバーのできるだけ近くに配置することをお勧めします。ロードバランサーでSSL終了を実行して、CPUを集中的に使用するジョブをWebサーバーからオフロードできます。選択したLBブランドが、不正なプロトコル接続の検査、DDoS動作の検出などの特定の機能を実行できる場合。