我々は、次のAWSインフラストラクチャを使用します。SSLオフロード
Route53-> CloundFront - > Elasticbeanstalk(+ロードバランサ= ELB) - > EC2インスタンスを
今、私たちは、CloudFrontの上に設定SSL証明書を持っていますELBレベルで同じものを使用し、CFとELBの間でエンドツーエンドの暗号化を提供します。 AWS CFと原点の間のEnd2Endは、ベストプラクティスhereとして説明されています。
これは、このpictureのFull SSL(厳密)を指します(これはCloudFlareスタック用ですが、これは決して気にならないほど優れています)。私たちはAWS CFレベルでSSLをオフロードして、図に示すようにCFからELBへのFlexible SSLへのラウンドトリップを避けたいと考えています。
CFレベルでSSLをオフロードすることをお勧めしますか? CFレベル後にend2end暗号化を落とす価値のあるパフォーマンス改善はありますか?
何らかのAWS CFからの接続のみを受け入れるようにELBを制限することはできますか?
さらに、ELB SSL performanceに関するパフォーマンス上の懸念があります(これはうまくいくと思われますが、まだ懸念があります)。一般に、AWS CFがSSL復号化作業でELBよりも優れたパフォーマンスを発揮している場合は、それも面白いです。
* "可能なアプローチの1つは、ラムダ関数を使ってELBのセキュリティグループを更新し、AWSから提供されたCF IP範囲をJSON URLにすることです。" *これは特に* CloudFront配布あなたのELBに連絡することができます。 –
セキュリティグループがCFのIP範囲でホワイトリストに登録されている場合でも、他のCFもアクセスできますが、CFはレイヤ7のトラフィックしか許可しないため、攻撃サーフェスは減少します。ただし、1つのCFに対して制限する場合は、サーバーで検証されたCF生成ヘッダーと組み合わせたセキュリティグループを使用することができます。 – Ashan
CloudFrontの背後に展開すると、SSLのELBへの影響が最小限に抑えられるという追加の理由は、 ELBとELB間の接続を永続化して再利用するため、これらの接続を設定するオーバーヘッドが最小限に抑えられます。これはSSLの時間とコストのかかる部分です。 –