Architecture de référence Azure Spring Apps

Cet article s’applique à : ✔️ Standard ✔️ Entreprise

Cette architecture de référence est une base qui utilise une conception hub-and-spoke d’entreprise classique pour l’utilisation d’Azure Spring Apps. Dans la conception, Azure Spring Apps est déployé dans un seul sous-réseau (spoke) qui dépend des services partagés hébergés dans le hub. L'architecture est construite avec des composants pour réaliser les principes dans Microsoft Azure Well-Architected Framework.

Il existe deux versions d’Azure Spring Apps : plan Standard et plan Entreprise.

Le plan Azure Spring Apps Standard est composé du serveur de configuration Spring Cloud, du Registre du service Spring Cloud et du service de build kpack.

Le plan Azure Spring Apps Enterprise est composé du service de build VMware Tanzu®, du service™ de configuration d’application pour VMware Tanzu®, du registre de services VMware Tanzu®, de Spring Cloud Gateway pour VMware Tanzu et du portail API pour VMware Tanzu®®.

Pour une implémentation de cette architecture, consultez l’architecture de référence Azure Spring Apps sur GitHub.

Les options de déploiement de cette architecture incluent Azure Resource Manager (ARM), Terraform, Azure CLI et Bicep. Les artefacts de ce référentiel fournissent une base que vous pouvez personnaliser pour votre environnement. Vous pouvez regrouper des ressources telles que pare-feu Azure ou Application Gateway dans différents groupes de ressources ou abonnements. Ce regroupement permet de séparer les différentes fonctions, telles que l’infrastructure informatique, la sécurité, les équipes d’applications métier, etc.

Planification de l’espace d’adressage

Azure Spring Apps nécessite deux sous-réseaux dédiés :

• Environnement d'exécution de service
• Applications Spring Boot

Chacun de ces sous-réseaux nécessite un cluster Azure Spring Apps dédié. Plusieurs clusters ne peuvent pas partager les mêmes sous-réseaux. La taille minimale de chaque sous-réseau est /28. Le nombre d’instances d’application qu’Azure Spring Apps peut prendre en charge varie en fonction de la taille du sous-réseau. Vous trouverez les exigences détaillées du réseau virtuel dans la section Configuration requise pour le réseauvirtuel du déploiement d’Azure Spring Apps dans un réseau virtuel.

Cas d’utilisation

Utilisations courantes de cette architecture :

• Applications privées : applications internes déployées dans des environnements cloud hybrides
• Applications publiques : applications accessibles en externe

Ces cas d’usage sont similaires, à l’exception de leurs règles de sécurité et de trafic réseau. Cette architecture est conçue pour prendre en charge les nuances de chacune d’elles.

Applications privées

La liste suivante décrit les exigences d’infrastructure pour les applications privées. Ces exigences sont typiques dans des environnements hautement réglementés.

• Un sous-réseau ne doit avoir qu’une seule instance d’Azure Spring Apps.
• L’adhésion à au moins un benchmark de sécurité doit être appliquée.
• Les enregistrements DNS (Domain Name Service) de l’hôte d’application doivent être stockés dans Azure Private DNS.
• Les dépendances de service Azure doivent communiquer via des points de terminaison de service ou Private Link.
• Les données au repos doivent être chiffrées.
• Les données en transit doivent être chiffrées.
• Les pipelines de déploiement DevOps peuvent être utilisés (par exemple, Azure DevOps) et nécessitent une connectivité réseau à Azure Spring Apps.
• Le trafic de sortie doit transiter par une appliance virtuelle réseau centrale (NVA) (par exemple, pare-feu Azure).
• Si le serveur de configuration Azure Spring Apps est utilisé pour charger des propriétés de configuration à partir d’un référentiel, le référentiel doit être privé.
• L’approche de sécurité Confiance Zéro de Microsoft nécessite que les secrets, les certificats et les informations d’identification soient stockés dans un coffre sécurisé. Le service recommandé est Azure Key Vault.
• La résolution de noms des hôtes locaux et dans le cloud doit être bidirectionnelle.
• Aucune sortie directe vers l’Internet public, à l’exception du trafic du plan de contrôle.
• Les groupes de ressources gérés par le déploiement d’Azure Spring Apps ne doivent pas être modifiés.
• Les sous-réseaux gérés par le déploiement d’Azure Spring Apps ne doivent pas être modifiés.

La liste suivante montre les composants qui composent la conception :

• Réseau local
  • Service dns (Domain Name Service)
  • Passerelle
• Abonnement Hub
  • Sous-réseau d’Application Gateway
  • Sous-réseau de pare-feu Azure
  • Sous-réseau des services partagés
• Abonnement connecté
  • Sous-réseau Azure Bastion
  • Homologue de réseau virtuel

La liste suivante décrit les services Azure dans cette architecture de référence :

• Azure Key Vault : un service de gestion des informations d’identification soutenu par le matériel qui a une intégration étroite avec les services d’identité Microsoft et les ressources de calcul.

• Azure Monitor : suite complète de services de supervision pour les applications qui déploient à la fois dans Azure et localement.

• Azure Pipelines : un service d’intégration continue / de développement continu (CI/CD) complet qui peut déployer automatiquement des applications Spring Boot mises à jour sur Azure Spring Apps.

• Microsoft Defender pour cloud : un système unifié de gestion de la sécurité et de protection contre les menaces pour les charges de travail sur site, plusieurs clouds et Azure.

• Azure Spring Apps : service managé conçu et optimisé spécifiquement pour les applications Spring Boot basées sur Java et . Applications Steeltoe basées sur NET.

Les diagrammes suivants représentent une conception hub-and-spoke bien conçue qui répond aux exigences ci-dessus :

Applications publiques

La liste suivante décrit les exigences d’infrastructure pour les applications publiques. Ces exigences sont typiques dans des environnements hautement réglementés.

• Un sous-réseau ne doit avoir qu’une seule instance d’Azure Spring Apps.
• L’adhésion à au moins un benchmark de sécurité doit être appliquée.
• Les enregistrements DNS (Domain Name Service) de l’hôte d’application doivent être stockés dans Azure Private DNS.
• Azure DDoS Protection doit être activé.
• Les dépendances de service Azure doivent communiquer via des points de terminaison de service ou Private Link.
• Les données au repos doivent être chiffrées.
• Les données en transit doivent être chiffrées.
• Les pipelines de déploiement DevOps peuvent être utilisés (par exemple, Azure DevOps) et nécessitent une connectivité réseau à Azure Spring Apps.
• Le trafic de sortie doit transiter par une appliance virtuelle réseau centrale (NVA) (par exemple, pare-feu Azure).
• Le trafic d’entrée doit être géré par au moins Application Gateway ou Azure Front Door.
• Les adresses routables Internet doivent être stockées dans le DNS public Azure.
• L’approche de sécurité Confiance Zéro de Microsoft nécessite que les secrets, les certificats et les informations d’identification soient stockés dans un coffre sécurisé. Le service recommandé est Azure Key Vault.
• La résolution de noms des hôtes locaux et dans le cloud doit être bidirectionnelle.
• Pas d'accès direct à l'Internet public, à l’exception du trafic du plan de contrôle.
• Les groupes de ressources gérés par le déploiement d’Azure Spring Apps ne doivent pas être modifiés.
• Les sous-réseaux gérés par le déploiement d’Azure Spring Apps ne doivent pas être modifiés.

La liste suivante montre les composants qui composent la conception :

• Réseau local
  • Service des noms de domaine (DNS)
  • Passerelle
• Abonnement Hub
  • Sous-réseau d’Application Gateway
  • Sous-réseau de pare-feu Azure
  • Sous-réseau des services partagés
• Abonnement connecté
  • Sous-réseau Azure Bastion
  • Homologue de réseau virtuel

La liste suivante décrit les services Azure dans cette architecture de référence :

• Pare-feu d’applications Azure : fonctionnalité d’Azure Application Gateway qui fournit une protection centralisée des applications contre les attaques et vulnérabilités courantes.

• Azure Application Gateway : équilibreur de charge responsable du trafic d’application avec le déchargement TLS (Transport Layer Security) au niveau de la couche 7.

• Azure Key Vault : un service de gestion des informations d’identification soutenu par le matériel qui a une intégration étroite avec les services d’identité Microsoft et les ressources de calcul.

• Azure Monitor : suite complète de services de supervision pour les applications qui déploient à la fois dans Azure et localement.

• Azure Pipelines : un service d’intégration continue / de développement continu (CI/CD) complet qui peut déployer automatiquement des applications Spring Boot mises à jour sur Azure Spring Apps.

• Microsoft Defender pour cloud : un système unifié de gestion de la sécurité et de protection contre les menaces pour les charges de travail sur site, plusieurs clouds et Azure.

• Azure Spring Apps : service managé conçu et optimisé spécifiquement pour les applications Spring Boot basées sur Java et . Applications Steeltoe basées sur NET.

Les diagrammes suivants représentent une conception hub-and-spoke bien conçue qui répond aux exigences ci-dessus. Seul le réseau virtuel hub communique avec Internet :

Connectivité locale d’Azure Spring Apps

Les applications dans Azure Spring Apps peuvent communiquer avec différentes ressources Azure, locales et externes. En utilisant la conception hub-and-spoke, les applications peuvent acheminer le trafic en externe ou vers le réseau local à l’aide d’Express Route ou d’un réseau privé virtuel de site à site (VPN).

Considérations relatives à Azure Well-Architected Framework

Azure Well-Architected Framework est un ensemble d’ensembles de lignes directrices à suivre pour établir une base d’infrastructure solide. Le framework contient les catégories suivantes : optimisation des coûts, excellence opérationnelle, efficacité des performances, fiabilité et sécurité.

Optimisation des coûts

En raison de la nature de la conception du système distribué, l’expansion de l’infrastructure est une réalité. Cette réalité entraîne des coûts inattendus et incontrôlables. Azure Spring Apps est conçu à l’aide de composants qui sont mis à l’échelle afin qu’ils puissent répondre à la demande et optimiser les coûts. Le cœur de cette architecture est Azure Kubernetes Service (AKS). Le service est conçu pour réduire la complexité et la surcharge opérationnelle de la gestion de Kubernetes, ce qui inclut des gains d’efficacité dans le coût opérationnel du cluster.

Vous pouvez déployer différentes applications et types d’applications sur une seule instance d’Azure Spring Apps. Le service prend en charge la mise à l’échelle automatique des applications déclenchées par des métriques ou des planifications qui peuvent améliorer l’utilisation et l’efficacité des coûts.

Vous pouvez également utiliser Application Insights et Azure Monitor pour réduire le coût opérationnel. Avec la visibilité fournie par la solution de journalisation complète, vous pouvez implémenter l’automatisation pour mettre à l’échelle les composants du système en temps réel. Vous pouvez également analyser les données de journal pour révéler des inefficacités dans le code d’application que vous pouvez traiter pour améliorer le coût global et les performances du système.

Excellence opérationnelle

Azure Spring Apps aborde plusieurs aspects de l’excellence opérationnelle. Vous pouvez combiner ces aspects pour vous assurer que le service s’exécute efficacement dans des environnements de production, comme décrit dans la liste suivante :

• Vous pouvez utiliser Azure Pipelines pour vous assurer que les déploiements sont fiables et cohérents tout en vous aidant à éviter les erreurs humaines.
• Vous pouvez utiliser Azure Monitor et Application Insights pour stocker les données de journal et de télémétrie. Vous pouvez évaluer les données de journal et de métrique collectées pour garantir l’intégrité et les performances de vos applications. L’analyse des performances des applications (APM) est entièrement intégrée au service via un agent Java. Cet agent offre une visibilité sur toutes les applications et dépendances déployées sans nécessiter de code supplémentaire. Pour plus d’informations, consultez le billet de blog Surveiller sans effort les applications et les dépendances dans Azure Spring Apps.
• Vous pouvez utiliser Microsoft Defender pour cloud pour vous assurer que les applications maintiennent la sécurité en fournissant une plateforme pour analyser et évaluer les données fournies.
• Le service prend en charge différents modèles de déploiement. Pour plus d’informations, consultez Configurer un environnement de préproduction dans Azure Spring Apps.

Fiabilité

Azure Spring Apps est basé sur AKS. Bien qu’AKS offre un niveau de résilience via le clustering, cette architecture de référence va encore plus loin en incorporant des services et des considérations architecturales pour augmenter la disponibilité de l’application en cas de défaillance du composant.

En s’appuyant sur une conception hub-and-spoke bien définie, la base de cette architecture garantit que vous pouvez la déployer dans plusieurs régions. Pour le cas d’usage de l’application privée, l’architecture utilise azure Private DNS pour garantir une disponibilité continue pendant une défaillance géographique. Pour le cas d’utilisation de l’application publique, Azure Front Door et Azure Application Gateway garantissent la disponibilité.

Sécurité

La sécurité de cette architecture est traitée par son adhésion aux contrôles et aux benchmarks définis par le secteur. Dans ce contexte, le « contrôle » signifie une bonne pratique concise et bien définie, telle que « Utiliser le principe des privilèges minimum lors de l’implémentation de l’accès au système d’information. IAM-05 » Les contrôles de cette architecture proviennent de la matrice de contrôle cloud (CCM) par l’Alliance de sécurité cloud (CSA) et du Microsoft Azure Foundations Benchmark (MAFB) par le Centre de sécurité Internet (CIS). Dans les contrôles appliqués, l’accent est mis sur les principaux principes de conception de la sécurité de la gouvernance, de la mise en réseau et de la sécurité des applications. Il vous incombe de gérer les principes de conception des principes d’identité, de gestion des accès et de stockage en ce qui concerne votre infrastructure cible.

Gouvernance

L’aspect principal de la gouvernance que cette architecture traite est la séparation par le biais de l’isolation des ressources réseau. Dans le CCM, DCS-08 recommande le contrôle d’entrée et de sortie pour le centre de données. Pour satisfaire le contrôle, l’architecture utilise une conception hub-and-spoke à l’aide de groupes de sécurité réseau (NSG) pour filtrer le trafic est-ouest entre les ressources. L’architecture filtre également le trafic entre les services centraux dans le hub et les ressources du spoke. L’architecture utilise une instance de Pare-feu Azure pour gérer le trafic entre Internet et les ressources au sein de l’architecture.

La liste suivante montre le contrôle qui traite la sécurité du centre de données dans cette référence :

Réseau

La conception réseau prenant en charge cette architecture est dérivée du modèle hub-and-spoke traditionnel. Cette décision garantit que l’isolation du réseau est une construction fondamentale. Le contrôle CCM IVS-06 recommande que le trafic entre les réseaux et les machines virtuelles soit restreint et surveillé entre les environnements approuvés et non approuvés. Cette architecture adopte le contrôle en mettant en œuvre les groupes de sécurité réseau pour le trafic est-ouest (dans le « centre de données ») et le Pare-feu Azure pour le trafic nord-sud (en dehors du « centre de données »). Le contrôle CCM IPY-04 recommande que l’infrastructure utilise des protocoles réseau sécurisés pour l’échange de données entre les services. Les services Azure prenant en charge cette architecture utilisent tous des protocoles sécurisés standard tels que TLS pour HTTP et SQL.

La liste suivante montre les contrôles CCM qui traitent de la sécurité réseau dans cette référence :

L’implémentation du réseau est plus sécurisée en définissant des contrôles à partir du MAFB. Les contrôles garantissent que le trafic vers l’environnement est limité à partir de l’Internet public.

La liste suivante montre les contrôles CIS qui traitent de la sécurité réseau dans cette référence :

Azure Spring Apps nécessite un trafic de gestion vers la sortie d’Azure lorsqu’il est déployé dans un environnement sécurisé. Vous devez autoriser les règles de réseau et d’application répertoriées dans les responsabilités des clients pour l’exécution d’Azure Spring Apps dans un réseau virtuel.

Sécurité des applications

Ce principe de conception couvre les composants fondamentaux de l’identité, de la protection des données, de la gestion des clés et de la configuration des applications. Par conception, une application déployée dans Azure Spring Apps s’exécute avec un privilège minimum requis pour fonctionner. L’ensemble de contrôles d’autorisation est directement lié à la protection des données lors de l’utilisation du service. La gestion des clés renforce cette approche de sécurité des applications en couches.

La liste suivante montre les contrôles CCM qui traitent de la gestion des clés dans cette référence :

À partir du CCM, EKM-02 et EKM-03 recommandent des stratégies et des procédures pour gérer les clés et utiliser des protocoles de chiffrement pour protéger les données sensibles. EKM-01 recommande que toutes les clés de chiffrement aient des propriétaires identifiables afin qu’elles puissent être gérées. EKM-04 recommande l’utilisation d’algorithmes standard.

La liste suivante montre les contrôles CIS qui concernent la gestion des clés dans cette référence.

Les contrôles CIS 8.1 et 8.2 recommandent que les dates d’expiration soient définies pour les informations d’identification afin de s’assurer que la rotation est appliquée. Le contrôle CIS 8.4 garantit que le contenu du coffre-fort de clés peut être restauré pour assurer la continuité de l’activité.

Les aspects de la sécurité des applications définissent une base pour l’utilisation de cette architecture de référence pour prendre en charge une charge de travail Spring dans Azure.

Étapes suivantes

Explorez cette architecture de référence via les déploiements ARM, Terraform et Azure CLI disponibles dans le référentiel d’architecture de référence Azure Spring Apps .