BlueSun, un fournisseur SaaS mondial, dispose d'une application web interne sur 10.1.2.10:443 dans le VNet hub et souhaite la publier sur Internet en utilisant une seule adresse IP publique sur Azure Firewall DNAT. Ils exigent que le point de terminaison externe soit https://app.bluesun.com et souhaitent que le pare-feu termine le TLS pour l'inspection IDPS, puis re-chiffre vers le backend en utilisant le certificat interne existant. Quelle configuration DNAT et de pare-feu permet d'accomplir cela ?

La bonne réponse est de créer une règle DNAT sur Azure Firewall, d'activer l'inspection TLS avec un certificat de pare-feu pour app.bluesun.com, et de s'assurer que le backend utilise également un certificat pour app.bluesun.com. Cela permet au pare-feu de déchiffrer le trafic pour l'inspection IDPS (exigence de terminaison TLS), puis de le rechiffrer vers le serveur backend (exigence de rechiffrement avec le certificat interne existant). Les autres options sont incorrectes car : La première option mentionne le "passthrough TLS en aval", ce qui contredit l'exigence de rechiffrement par le pare-feu. Le passthrough TLS empêcherait le pare-feu de rechiffrer le trafic. La troisième option suggère d'utiliser un WAF Azure Application Gateway, ce qui est une solution différente et plus complexe que ce qui est demandé, et ne répond pas directement à l'exigence de DNAT et d'inspection/rechiffrement par le pare-feu. La quatrième option propose un équilibreur de charge devant le pare-feu, ce qui n'est pas nécessaire pour une publication directe via Azure Firewall DNAT et ajoute une complexité inutile.