リバースプロキシのセキュリティ上の利点Java / Tomcat WebApps Locally
従来の知識では、Javaアプリケーションは常にリバースプロキシする必要があります。これは私が常に行ってきたことであり、あらゆる場所で行ってきました。
私は何度も、リバースプロキシが実質的な根拠なしに推奨されていることを読みました。通常、TomcatとApacheを使用します。
一般的にリバースプロキシの利点のいくつかを理解しています。リクエストの検証とフィルタリングの一部をアプリケーションの北に移動していますが、これについて、Javaに固有の詳細な説明があるかどうか疑問に思っていましたか？
私はこれを少しググってみましたが、詳細や説得力のあるものは思いつきませんでした。
TomcatがHTTPリクエストをアプリケーションに直接渡すのではなく、受け取ると想定しています。
明確にするために：以下の答えを読んで、プロキシが一般的に使用される理由や構成方法を尋ねるのではなく、アプリケーションと同じサーバー上で実行した場合に提供されるセキュリティ上の利点（セグメンテーションなどを除く）を尋ねます。
（要求された）セキュリティ上の利点のみに焦点を当てます。これには複数の要素があります。それぞれについて順に説明します。
不正なリクエストを利用する攻撃に対する堅牢性。ここでの考え方は、リバースプロキシが不正な要求を拒否するためのより適切な処理を行うため、サーバーが無効な要求を誤って処理することに依存する攻撃からの保護を適切に処理することです。私の意見では（Tomcatコミッターとして）、Tomcatの場合はこのビューをサポートしません。適用できるのは、サービスをホストするためにインターネットに接続することを意図していないもの（Javaベースである必要はない）を使用している場合です。その後、リバースプロキシを使用すると、センス。
よりシンプルなTLS構成。証明機関がPEM形式でのみ証明書を提供する傾向があったとき、確かに真実であるJava KeyStoreへの変換プロセスは十分に文書化されていませんでした。これに関して全面的に改善がありました。認証局は提供しています= Java KeyStore固有の手順、Java自体がKeyStoresからPKCS12に移行し、TomcatはPEM形式（httpdが使用するのと同じ形式）の証明書を使用できます。）この点は、最近はあまり重要ではありません。
リバースプロキシは、より多くの構成オプションを提供します。これは一般的に当てはまります。ヘッダーをブロックし、外部の認証および承認システムと統合し、応答を変更する必要がある場合は、Tomcatで上記のすべてを実行できますが、Tomcatでこれらのことを実行するためのコードを記述する必要があります。リバースプロキシの構成で行います。これがあなたにとってどれほど重要であるかは、何を達成しようとしているのかに依存します。私が見た1つの利点は、新しい脆弱性が発生したときに、Tomcatよりも簡単に攻撃をブロックするようにリバースプロキシを構成できることです（たとえば、modrewriteを使用）。
反対の議論は、リバースプロキシを追加することにより、攻撃対象領域を増やすことです。ここで、リバースプロキシの脆弱性とJavaコンポーネントの脆弱性について心配する必要があります。
また、リバースプロキシが正しく構成されていることを確認する必要もあります。特に、リバースプロキシがhttpsを終了し、バックエンドにhttpを使用している場合は特にそうです。バックエンドがhttps経由で（リバースプロキシによって）受信されたリクエストと、http経由で受信されたリクエストを確実に認識するように非常に注意する必要があります。そうしないと、安全なセッションIDのリークなどの潜在的な脆弱性に束縛されてしまいます。 http。
一般的に、あなたが知っていることに固執することはおそらくより重要です。 httpdインスタンスの安全な設定に満足している経験豊富なhttpd管理者の場合、わからないことを試みて設定するのではなく、httpdを介してプロキシを行うと、安全な設定になる可能性が高くなります。同様に、経験豊富なTomcat管理者は、見慣れないリバースプロキシを追加するよりも、Tomcatだけでより良い結果を得る可能性があります。
全体として、リバースプロキシ（負荷分散、単一のホスト名を介して複数のサービスを公開する）を使用するための非セキュリティ引数が、それを使用するかどうかの決定を左右する可能性が高いと思います。