1

この 1 週間ほど、私は AWS の世界、より具体的には Elastic Beanstalk とロード バランシングについて理解を深めてきました...

私が開発しているアプリケーションは、グローバルに適用しているカスタム RequireHttps 属性を使用して SSL/HTTPS 接続を強制します。最初、このセットアップでロード バランサーを構成する際に問題がありましたが、期待どおりに機能しているようです。

私の問題は、Load Balancer/RequireHttps 属性を設定していた頃にちらっと見たブログ投稿に端を発しています。このブログ投稿を引用：

Elastic Beanstalk を使用する場合 ... ロード バランサーとアプリケーション サーバー間の接続が安全ではありません。ただし、ロード バランサーとサーバー間の接続のセキュリティを考慮する必要はありませんが、クライアントとロード バランサー間の接続については考慮する必要があります。

ロード バランサーの構成は私にとってまったく新しい領域であるため、上記が完全に正しいかどうかについては少し懐疑的です。

ロードバランサーとサーバー間の接続は本当に気にならないのですか? ロード バランサーで SSL を終了せず、安全な接続をサーバーに直接渡す方がよいでしょうか?

4

1 に答える 1

1

もう少し調査した後、security.stackexchange に関する次の投稿/ディスカッションに出くわしました: SSL はロード バランサーで終了する必要がありますか?

Makerofthings7:

質問は「自分のデータセンターを信頼していますか」ということのように思えます。言い換えれば、信頼されていないネットワークがどこにあるのかを細かく線引きしようとしているように見え、信頼が始まります.

私の意見では、SSL/TLS 信頼は SSL オフロード デバイスで終了する必要があります。これは、そのデバイスを管理する部門がネットワークとインフラストラクチャも管理することが多いためです。そこにはある程度の契約上の信頼があります。ダウンストリーム サーバーでデータを暗号化する意味はありません。通常、ネットワークをサポートしている同じ人がダウンストリーム サーバーにもアクセスできるからです。(マルチテナント環境、またはより深いセグメンテーションを必要とする独自のビジネス要件では例外となる可能性があります)。

SSL がロード バランサーで終了する必要がある 2 つ目の理由は、CRIME や BEAST などの SSL 攻撃を修正するための一元化された場所が提供されるためです。SSL がさまざまな Web サーバーで終了し、さまざまな OS で実行されている場合、複雑さが増すために問題が発生する可能性が高くなります。シンプルにしておけば、長期的には問題が少なくなります。

@makerofthings7 の言っていることが理にかなっていることがわかります。SSL がロード バランサーとサーバーのどちらで終了しても、ほとんど違いはありません。

于 2013-05-02T10:03:36.387 に答える