プロトコルの切り替えは実装する価値のあるセキュリティ対策ですか？
私たちはインターネット向けアプリケーションを複数のVLANに展開し、あるVLANから次のVLANへの通信は別のプロトコルまたはプロトコルの他の実装で行わなければならないというルールがあります。
例えば。
[Internet] --https-> [Apache@VLAN1] --ajp--> [Tomcat@VLAN2] --jdbc--> [pgsql@VLAN3]
Vs.
[Internet] --https-> [Apache@VLAN1] --https--> [Apache@VLAN2] --https--> [Apache@VLAN3]
Vs.
[Internet] --https-> [Apache@VLAN1] --https--> [Tomcat@VLAN2] --https--> [nginx@VLAN3]
背後にある理由は、プロトコル実装の1つにエクスプロイトがある場合、同じエクスプロイトを使用して次のVLANのホストに侵入できないことです。
すべてのサービスがREST APIを提供している場合、これを達成するのは難しい場合があります。
これについて私が読むことができる文献はありますか？または、同じ保護を実現するアプローチ。
説明したようにプロトコルを切り替えるには、データを新しいプロトコルに変換するために、転送されたデータの構文とセマンティクスを分析する必要があります。また、最初にセマンティクスを明確に定義する必要があることも意味します。セマンティクス自体を明確に定義することで、セキュリティを向上させることができます。また、データを新しいプロトコルに変換するときにこれらのセマンティクスが暗黙的に適用されるため、攻撃者が受信者を悪用する能力がさらに低下します。
セマンティクスの定義と適用は、新しいプロトコルに変換せずに行うこともできます。ただし、別のプロトコルに変換するには、構文とセマンティクスのより厳密な定義が必要であり、ショートカットを作成して一部のチェックをスキップすることは困難です。これまでのところ、プロトコルの切り替えを必要とすることは、開発者がデータが最初にどのように見えるべきかを実際に理解し、それを強制することを確実にするための素晴らしいアイデアです。
もちろん、これは実際の翻訳が必要な場合にのみ機能します。これは、例ではHTTPとJDBCの間のケースですが、HTTPSとHTTPの間のケースではありません。 HTTPSは単なるTLS over HTTPであり、プロトコルセマンティクスを適用するのではなく、TLSレイヤーを取り除くだけで十分です。
これはコメントであることを意味します。私はコメントできればいいのですが（まだまだですが）上記の例に基づいて、暗号化されたプロトコル（https）から別のプロトコルに移行することには大きなメリットはないと思われますネットワーク内のプレーンテキストプロトコル（http）から（おそらく）暗号化されていないプロトコル（jdbc）へ。暗号化されていることから始めてください。笑。また、プロトコルを強制することが常に可能であるとは限りません。 JDBCに悩まされている可能性があります。
ただし、そこでフードチェーンの一部をクラックすると、各セグメントが異なる方法で暗号化されている場合でも、データを取得します。たとえば、VLAN1がある場合、実際にはロードバランサーがSSLオフロードを実行しており、接続はまだVLAN2へのHTTPSです。ただし、キーとSSLセッションは異なり、安全なJDBCを使用してアプリ層から暗号化されます（アプリ層からのプロトコルは、プロトコルの選択肢の多くではありません）.
はい、暗号化されています。常に望ましいですが、それが彼らの代わりにどういう意味なのでしょうか。
[インターネット] --httpsオフロード-> [VLAN1] --https新しいセッション-> [VLAN2]-セキュアjdbc-> [VLAN3]
それはミットを停止します。