Topologie et connectivité du réseau pour l’accélérateur de zone d’atterrissage Azure Spring Apps

Cet article décrit des considérations et des suggestions de conception pour le réseau où la charge de travail Spring Boot est placée. Votre conception cible dépend des besoins de la charge de travail et des exigences de sécurité et de conformité de votre organisation.

L’équipe de plateforme centralisée et l’équipe d’application partagent la responsabilité de la zone de conception réseau. L’équipe de la plateforme sélectionne la topologie de mise en réseau, qui peut être une topologie de réseau de modèle hub-and-spoke traditionnel ou Virtual WAN (managée par Microsoft). L’équipe d’application est responsable des choix de conception du réseau spoke. La charge de travail est censée avoir des dépendances sur les services partagés gérés par la plateforme. L’équipe d’application doit comprendre les implications de ces dépendances et communiquer ses exigences afin que les objectifs globaux de la charge de travail soient atteints.

Pour plus d’informations sur la conception de la plateforme, consultez Topologie et connectivité réseau.

Suivez ces considérations et recommandations de conception comme les meilleures pratiques en matière de contrôles de sous-réseau, d’entrée et de sortie.

Remarques relatives à la conception

• Isolation. L’équipe centrale peut fournir un réseau virtuel permettant à l’équipe d’application d’exécuter ses charges de travail. Si la charge de travail Spring Boot présente des préoccupations séparées des autres charges de travail, envisagez d’approvisionner votre propre réseau virtuel pour le runtime du service Spring App et l’application.

• Sous-réseau. Considérez la scalabilité de l’application lorsque vous choisissez la taille du sous-réseau et le nombre d’applications.

  Si vous utilisez des sous-réseaux existants ou apportez vos propres tables de routage, mettez en place des stratégies pour vous assurer que les règles ajoutées par Azure Spring Apps ne sont pas mises à jour ou supprimées.

  La sécurité est un autre aspect. Considérez les règles qui autorisent ou refusent le trafic vers le sous-réseau.

• Trafic de sortie (sortant). Le trafic en provenance du réseau virtuel doit être routé via le pare-feu Azure ou une appliance virtuelle réseau (NVA).

  Considérez les limitations de l’équilibreur de charge intégré fourni par Azure Spring Apps. En fonction de vos besoins, vous devrez peut-être personnaliser les chemins d’accès sortants à l’aide du routage défini par l’utilisateur (UDR), par exemple pour acheminer tout le trafic via une NVA.

• Trafic d’entrée (entrant). Envisagez d’utiliser un proxy inverse pour le trafic destiné à Azure Spring Apps. En fonction de vos besoins, choisissez des options natives telles que Azure Application Gateway et Front Door ou des services régionaux tels que la gestion des API (APIM). Si ces options ne répondent pas aux besoins de la charge de travail, des services non Azure peuvent être envisagés.

Recommandations de conception

Ces recommandations fournissent une aide normative pour l’ensemble des considérations précédentes.

Réseau virtuel et sous-réseaux

• Azure Spring Apps nécessite l’autorisation du propriétaire pour accéder à votre réseau virtuel. Ce rôle est nécessaire pour octroyer un principal de service dédié et dynamique au déploiement et la maintenance. Pour plus d’informations, consultez Déploiement d’Azure Spring Apps dans un réseau virtuel.

• Azure Spring Apps déployé dans un réseau privé fournit un nom de domaine complet (FQDN) accessible uniquement au sein du réseau privé. Créez une zone DNS privée Azure pour l’adresse IP de votre application Spring. Liez le DNS privé à votre réseau virtuel en attribuant un nom de domaine complet privé au sein de Azure Spring Apps. Pour obtenir des instructions détaillées, consultez Accéder à votre application dans un réseau privé.

• Azure Spring Apps nécessite deux sous-réseaux dédiés. Un sous-réseau a le runtime de service et l’autre sous-réseau pour les applications Spring Boot.

  La taille de bloc CIDR minimale de chacun de ces sous-réseaux est /28. Le sous-réseau runtime et le sous-réseau d’application ont besoin d’un espace d’adressage minimal de /28. Cependant, le nombre d’applications Spring que vous pouvez déployer influence la taille du sous-réseau. Pour plus d’informations sur le nombre maximal d’instances d’application par plage de sous-réseaux, consultez Utilisation de plages de sous-réseaux plus petites.

• Si vous utilisez Azure Application Gateway comme proxy inverse devant Azure Spring Apps, vous avez besoin d’un autre sous-réseau pour cette instance. Pour plus d’informations, consultez Utilisation d’Application Gateway comme proxy inverse.

• Utilisez des groupes de sécurité réseau (NSG) sur des sous-réseaux pour filtrer le trafic est-ouest vers votre sous-réseau runtime de service.

• Les groupes de ressources et sous-réseaux gérés par le déploiement de Azure Spring Apps ne doivent pas être modifiés.

Trafic de sortie

• Par défaut, Azure Spring Apps dispose d’un accès Internet sortant illimité. Utilisez une appliance virtuelle réseau telle que le pare-feu Azure pour filtrer le trafic nord-sud. Tirez parti du pare-feu Azure dans le réseau hub centralisé pour réduire la surcharge de gestion.

  Notes

  Le trafic de sortie vers des composants Azure Spring est nécessaire pour prendre en charge les instances de service. Pour plus d’informations sur des points de terminaison et des ports spécifiques, consultez Exigences du réseau Azure Spring Apps.

• Azure Spring Apps fournit un type de trafic sortant de routage défini par l’utilisateur (UDR) pour contrôler entièrement le chemin du trafic de sortie. OutboundType doit être défini lors de la création d’une nouvelle instance de service Azure Spring Apps. Il ne peut pas être mis à jour par la suite. OutboundType peut être configuré uniquement avec un réseau virtuel. Pour plus d’informations, consultez Personnaliser une sortie Azure Spring Apps avec un routage défini par l’utilisateur.

• L’application doit communiquer avec d’autres services Azure dans la solution. Utilisez Azure Private Link pour les services pris en charge si vos applications nécessitent une connectivité privée.

Trafic d’entrée

• Utilisez un proxy inverse pour vous assurer que les utilisateurs malveillants ne peuvent pas contourner le pare-feu d’applications web (WAF) ou se soustraire aux limites des limitations de requêtes. Azure Application Gateway avec WAF intégré est recommandé.

  Si vous bénéficiez du niveau Entreprise, utilisez le point de terminaison attribué par l’application Spring Cloud Gateway comme pool principal de l’Application Gateway. Ce point de terminaison est résolu en adresse IP privée dans le sous-réseau du runtime du service Azure Spring Apps.

  Ajoutez un groupe de sécurité réseau au sous-réseau du runtime du service qui autorise uniquement le trafic provenant du sous-réseau Application Gateway, du sous-réseau Azure Spring Apps et de Azure Load Balancer.

  Notes

  Vous pouvez choisir une alternative pour le proxy inverse, telle que Azure Front Door ou des services non Azure. Pour plus d’informations sur les options de configuration, consultez Exposer Azure Spring Apps via un proxy inverse.

• Azure Spring Apps peut être déployé dans un réseau virtuel par injection VNet ou en dehors du réseau. Pour plus d’informations, consultez Résumé de configuration.

Étapes suivantes

Considérations relatives à la sécurité pour l’accélérateur de zone d’atterrissage Azure Spring Apps