0

基本的に、Azure Front Door との間の要求/応答のみを許可します。さまざまなオプションがありますが、実装とベスト プラクティスの詳細を見つけるのに苦労しています。適切な解決策は、2 つのサービスを統合するために使用する仮想ネットワークを作成することだと思います。

ニュアンスが 1 つあります。Web アプリにはステージング スロットがあり、別のソリューションが必要になる可能性があります。これは、Azure Active Directory を使用して運用前へのパブリック アクセスを防ぐためです。

ここでもう少し洞察を見つけましたが、それでも少しわかりにくいことがわかりました。

Front Door でサブドメインを持つカスタム ドメインがある場合、Web アプリのバックエンド アドレスへの直接アクセスを防止し、カスタム DNS と Front Door のみを許可する簡単な方法があるはずです。

これは役に立ちましたが、まだ Front Door から 403 を受信して​​いるため、構成方法に何か不足しているに違いありません。

ミドルウェア？これも役に立ちましたが、ミドルウェアによってのみ達成できることを示しているようで、.NET Core ではなく Node/Express を実行しています。ミドルウェア コードでしか実現できないというのは本当ですか?

これも同じ詳細に言及しています。

何が欠けている？異なるアプリケーション スタック間でこれを構成する方法。

4

2 に答える 2

1

IP ACL と 'X-Azure-FDID' ヘッダーのチェックの両方が必要だと思います。(いらないといいのですが…)。IP 制限のみを使用する場合、バックエンドは世界中のすべての Front Door に対して引き続き開かれ、他の Azure 顧客の Front Door に対しても開かれます。また、「X-Azure-FDID」ヘッダーのチェックのみを使用すると、攻撃者が力ずくでヘッダーを推測しようとする可能性があります。バックエンドを保護できるのは、IP ACL とヘッダーのチェックの組み合わせだけです。これは、'X-Azure-FDID' ヘッダーが実際の Front Door サービスによって追加されたものであり、スプーフィングされていないことを確認できるためです。

明確に説明されているこの投稿も参照してください。

于 2020-08-24T13:29:47.850 に答える