2017-04-16 3 views
2

我々は、次の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よりも優れたパフォーマンスを発揮している場合は、それも面白いです。

答えて

2

アプリケーションの要件とコンプライアンスの要件に基づいて、SSLでCFをオフラインにします。

通常、すべてのエンティティがCF経由でアプリケーションにアクセスする場合(たとえば、一部のクライアントからバックエンドVPCへのVPN接続がない場合)、CFでのオフロードで十分です。両方でSSLを使用した場合のパフォーマンスの違いは重要ではありません。

CFからELBへのインバウンドのみを許可するには、現時点で利用可能な直接的なアプローチはありません。可能なアプローチの1つは、ラムダ関数を使用してELBのセキュリティグループを更新し、AWSから提供されたCF IP範囲からJSON URLを取得することです。

また、ELBには各AZ(通常2または3)のサーバーがある間に、エッジ位置で動作するサーバーが多数存在するため、CFでのSSLオフロードはELBに比べて高速です。

+1

* "可能なアプローチの1つは、ラムダ関数を使ってELBのセキュリティグループを更新し、AWSから提供されたCF IP範囲をJSON URLにすることです。" *これは特に* CloudFront配布あなたのELBに連絡することができます。 –

+1

セキュリティグループがCFのIP範囲でホワイトリストに登録されている場合でも、他のCFもアクセスできますが、CFはレイヤ7のトラフィックしか許可しないため、攻撃サーフェスは減少します。ただし、1つのCFに対して制限する場合は、サーバーで検証されたCF生成ヘッダーと組み合わせたセキュリティグループを使用することができます。 – Ashan

+1

CloudFrontの背後に展開すると、SSLのELBへの影響が最小限に抑えられるという追加の理由は、 ELBとELB間の接続を永続化して再利用するため、これらの接続を設定するオーバーヘッドが最小限に抑えられます。これはSSLの時間とコストのかかる部分です。 –

関連する問題