10/21/2016

ロードバランサとサーバ間にSSLを使うか?

Ivan Pepelnjak氏のブログipSpaceより。興味深い。

読者の一人が私にこの疑問を送って来た。
機密データを取り扱う場合、インターネット越しにSSLを使うことは必須である。データセンターのコンポーネント(例えば、フロントエンドのロードバランサやバックエンドのウェブサーバ)間のSSLについてはどうだろうか? 当然だろうか? 質問は「私はデータセンターのネットワークチームを信頼しているか」にまとめることができる。あるいは他に問題になっているものがあるか?

理想は、あなたが全体として信頼できる通信インフラを持っているとして、答えは「インフラを超えてのSSLは必要ない」である。

地球上で、私はネットワークチームについてそれだけ心配いらないと思うが、 同じL2サブネットに置かれている複数のアプリケーションのサーバは別である(横方向に移動しようとする侵入者に向けての架空のシナリオ(ideal scenario))。

また、私はその疑問に「データは普段から暗号化されているか?」と尋ね、答えが"いいえ"なら、次の質問「では、なぜ共有のネットワークインフラよりも共有のストレージインフラを信頼するのですか?」をする。

結局、データセンターの中でSSLはロードバランサとウェブサーバ間でのデータ交換を保護する。データは当然保護が当然だし、ウェブサーバとデータベースサーバ間のデータ交換のようにより重要なデータストリームもある。データベースの通信を暗号化しているか? もし、していないなら、なぜウェブセッションを暗号化するのだろうか?

同じ読者は関連する質問も送って来た:

もし、私があなたの言葉を正しく理解しているとすれば、サーバが同じ保護なしL2セグメント上にいるなら、暗号化は当然である。もしそのパス上にあるなら、各サーバ(もしくは、少なくとも各アプリケーション)は自身の証明書を持つべきだと思う。そうしないと、全てで同じ証明書を持つと、秘密鍵にアクセスを与えている一台のサーバが破られた時に保護できない。私は正しい?

あなたがセキュリティについて真剣に取り組んでいるなら、各アプリケーションで異なる証明書を持つべきである。エフェメラル(一時的)Diffie-Hellman(DHE)鍵交換も使うべきである。

解説

あなたがサーバの秘密鍵を持っているなら、たくさんのTLSトラフィックを複合するのは実に簡単である。多くのTLS鍵交換アルゴリズムは単純化した方法を利用する:

  • クライアントがランダムなセッション鍵を生成する
  • クライアントはサーバの公開鍵でセッション鍵を暗号化する
  • サーバはサーバの秘密鍵を使ってセッション鍵を復号化する

サーバの秘密鍵を持っている場合、セッション鍵を、その後にサーバが交換する全トラフィックを復号化できる(だから、WiresharkでHTTPSトラフィックを復号化できる)。

いくつかのTLS鍵交換アルゴリズムは前方秘匿性(forward secrecy)を提供する。そうすると、秘密鍵を持っていたとしても、セッション鍵(そして後の暗号化データ)を得ることは不可能になる。これらのアルゴリズムはDiffie-Hellman鍵交換に依存しており、もっと正確にいうとエフェメラルDHで、セッション鍵が全てのTLSセッションに向け生成される。

より詳細は、ウィキペディアのTLSの解説を読んでほしい。