リバースプロキシ-別のテクノロジースタックにする必要がありますか？
私が検討しているリバースプロキシの設定について懐疑的な質問がありました。
現在、DMZ（下図のS1、S2）に負荷分散されたアプリケーションサーバーのペアがあります。これらは外部クライアントからのインバウンド要求を受け入れます。また、内部ネットワークリソースへの接続も行います（例： DBサーバー、メッセージブローカー）
DMZセットアップはかなり標準的です：2つのファイアウォール-内部と外部に面しています。外部に面したファイアウォールは、特定のポート上の特定のサーバーリソースへの外部リクエストのみを許可します。内部に面したファイアウォールは許可しますDMZサーバーは内部ネットワークリソース（DBサーバー、メッセージブローカーなど）への指定された接続を開きます）
今、私はこのセットアップが安全ではないと述べているアーキテクチャの提案を持っています。この提案では、2つのDMZサーバーを内部ネットワークに移動する必要があります。DMZでは、これらは「リバースプロキシ」サーバー（下図の「RP」）に置き換えられます。「RP」 'インバウンド要求を受け入れ、それらをS1/S2にプロキシします。ここでの主なセールスポイントは、内部サーバーinitiate'リバースプロキシへのネットワーク接続です。 'DMZ内のサーバー。
したがって、この：
[EXTERNAL] [DMZ] [INTERNAL]
Client --> || S1/S2 || --> DB,MQ
...これに置き換えられています：
[EXTERNAL] [DMZ] [INTERNAL]
Client --> || RP || <-- S1/S2 --> DB,MQ
RPは、基本的にS1/S2（同じテクノロジースタック）の簡略版です。これは、S1/S2によって開始された持続的接続を介してS1/S2に外部要求を伝達します。
私の質問： RPのテクノロジースタックがS1/S2と同一であるとすると（同じテクノロジー、より少ないコード）-新しいセットアップはどのように重要な追加の保護を提供しますか？
アプリケーション攻撃は、S1/S2に無防備に到達しませんか？具体的には、RPを危険にさらすと、S1/S2も危険にさらされる可能性があります。これは実際にリスクプロファイルを悪化させませんか（S1/S2は現在内部ネットワークにあるため）？
いくつかの情報を追加し、上記のポイントを拡張します。
このセットアップでは、ロードバランサー（「LB」）は基本的に透過的です（つまり、RPはLBではありません）。さまざまな理由により、LBはインバウンド要求を終了できません。
個人的に、私は非常にRPが追加するセキュリティに懐疑的です。私の推論：RPが何らかの形で完全に侵害されている場合（バッファオーバーラン/シェルコードなど）、内部ネットワークのS1/S2への接続を簡単に乗り越えることができます（誰が接続を開始するかは関係ありません-そこにあります）、そして同様のS1/S2でのエクスプロイト（同様の技術のおかげで）。侵害されたS1/S2がDMZではなくソフトアンダーベリー（つまりイントラネット）に配置されているため、問題はさらに悪化しています。
フロントエンドとバックエンドのテクノロジーが異なるとセキュリティがわずかに向上しますが、その量についてはかなり議論の余地があります。簡単に言えば、フロントエンドが危険にさらされているからといって、それ自体がバックエンドやネットワークの他の技術が危険にさらされていることを意味するわけではありません。フロントエンドを危険にさらすために使用された方法がバックエンドに実装できるようになったと主張することはできますが、必ずしもその方法が新しいターゲットに対して有効であるとは限りません。
そうは言っても、フロントエンドとバックエンドの両方でほぼ同じシステムと構成を使用している場合は、そうです。そのうちの1つに異なるテクノロジーを使用することで、セキュリティを強化できます。
同じテクノロジーを使用する場合でも、異なるテクノロジーを使用する場合でも、システムごとに異なるアカウントを使用することをお勧めします。
まず、ほとんどのロードバランサーはリバースプロキシとして機能します wikipediaf5 devcentral 。ただし、ロードバランサー（またはリバースプロキシ）の設計方法に固有の保護には違いがあります。注：今後は、「ロードバランサー」（LB）と「リバースプロキシ」（RP）という用語を同じ意味で使用します。
LBは、すべての通信の仲介役として機能することにより、セキュリティを強化します。ほとんどのエンタープライズグレードのLBは、レイヤー7プロキシとして機能します。 Webトラフィックの場合、クライアント側のHTTPセッションはLBで完全に終了し、LBはサーバー側のHTTP接続をサーバーに再確立します。レイヤー7（l7）の終了を強制することにより、ペイロード全体を確認、スクラブし、サーバーにクリーンで最適化して送り返すことができます。多くの場合、LBはアドオンモジュールとしてWebアプリケーションファイアウォールも実装し、トラフィックをWebサーバーに送り返す前に、トラフィックの異常なパターンをさらに検査します。
上記のモデルでLBによって提供される保護の相対的な強度は、トラフィックが17以下のレベルで終了しているかどうかによって異なります。一部のロードバランサーはネットワーク層でのみ機能する場合があります。つまり、基本的に、トラフィックがクライアント側からサーバー側に流れるときに、LBがIP /ポート情報を書き換えるだけです。さらに、パフォーマンスを向上させるために、ネットワーク/トランスポート層でのみ機能するようにl7フルプロキシが可能なLBを構成することは完全に可能です（l7の終了はリソースを大量に消費します）。このような場合、ロードバランサーはトラフィックを可能な限り完全にスクラブしない可能性があります。
モデルに戻ると、RP = LBの場合、アーキテクチャの観点から、提案されたアーキテクチャは現在のモデルよりもさらに複雑になります。ただし、ここで重要なのは提案されたモデルであり、S1/S2はDMZへのアウトバウンド接続を開始します。攻撃者はRPを危険にさらす可能性がありますが、S1/S2または内部ネットワークに戻る新しいセッションを確立することはできません。ただし、S1/S2またはDB、MQにアプリケーションの弱点がある場合、攻撃者はS1/S2にアクセスするためにネットワークにトンネルバックする可能性があります。さらに、「RP」はS1/S2と同じ技術スタックを使用しているため、S1/S2の弱点は「RP」にも存在する可能性があります。ただし、「RP」が壊れない場合、提案されたモデルは、S1/S2のネットワークスタックが保護され、攻撃が最初にアプリケーションスタックを標的にする必要があるという点でセキュリティ体制を強化します。
このモデルが追加するセキュリティの価値については議論の余地がありますが（攻撃者がdmz/int fwを破った場合、イントラネットにオープンアクセスできます&&このモデルは一般的な槍釣り攻撃から保護しません）、そのようなモデルはより受け入れられる可能性がありますそうでないよりもコンプライアンスの人。これは特に、CHD環境にアクセスできるシステムも対象となるPCIコンプライアンスの場合に当てはまります。上記の場合、DMZ全体がスコープ内にある可能性がありますが、CHD環境からアウトバウンドに接続を確立すると、「RP」のみがスコープに追加されます。これが事実であることを意味するのではなく、アーキテクトがこの方法でPCIスコープの縮小に取り組むのを見てきました。