Partager via

Architecture de référence Azure Spring Apps

  • Article

Notes

Azure Spring Apps est le nouveau nom du service Azure Spring Cloud. Bien que le service ait un nouveau nom, vous verrez l’ancien nom à divers endroits pendant un certain temps, car nous travaillons à mettre à jour les ressources telles que les captures d’écran, les vidéos et les diagrammes.

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

Cette architecture de référence est une base qui utilise une conception Hub-and-Spoke typique des entreprises pour l’utilisation d’Azure Spring Apps. Dans la conception, Azure Spring Apps est déployé dans un même spoke dépendant des services partagés hébergés dans le hub. L’architecture est conçue avec des composants permettant de réaliser les principes de Microsoft Azure Well-Architected Framework.

Il existe deux variantes d’Azure Spring Apps : le plan Standard et le 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 Entreprise se compose du service de build VMware Tanzu®, du service™ de configuration d’application pour VMware Tanzu®, du registre du service VMware Tanzu®, de la passerelle Spring Cloud gateway pour VMware Tanzu® et du portail API pour VMware Tanzu®.

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

Les options de déploiement de cette architecture sont Azure Resource Manager (ARM), Terraform, Azure CLI et Bicep. Les artefacts de ce référentiel fournissent une base que vous pouvez adapter à 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 différentes fonctions, telles que l’infrastructure informatique, la sécurité, les équipes chargées des applications commerciales, etc.

Planification de l’espace d’adressage

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

  • Runtime du service
  • Applications Spring Boot

Chacun de ces sous-réseaux nécessite un cluster Azure Spring Apps dédié. Les clusters multiples ne peuvent pas partager les mêmes sous-réseaux. La taille minimale de chaque sous-réseau est de /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 détails de la configuration requise pour le réseau virtuel dans la section Configuration requise pour le réseau virtuel de Déployer Azure Spring Apps dans un réseau virtuel.

Avertissement

La taille du sous-réseau sélectionné ne peut pas chevaucher l’espace d’adressage du réseau virtuel existant et ne doit pas chevaucher les plages d’adresses de sous-réseau locales ou appairées.

Cas d'utilisation

Utilisations courantes de cette architecture :

  • Applications privées : applications internes déployées dans des environnements de cloud hybrides
  • Applications publiques : applications accessibles de l’extérieur

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

Applications privées

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

  • Un sous-réseau ne doit avoir qu’une seule instance d’Azure Spring Apps.
  • Le respect d’au moins un point de référence de sécurité doit être appliqué.
  • Les enregistrements DNS (Domain Name Service) de l’hôte d’application doivent être stockés dans DNS privé Azure.
  • Les dépendances de service Azure doivent communiquer par l’intermédiaire de points de terminaison de service ou d’une liaison privée.
  • Les données au repos doivent être chiffrées.
  • Les données en transit doivent être chiffrées.
  • Des 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 traverser une appliance centrale de réseau virtuel (par exemple, Pare-feu Azure).
  • Si Azure Spring Apps Config Server est utilisé pour charger des propriétés de configuration à partir d’un dépôt, ce dernier doit être privé.
  • L’approche de sécurité Zero Trust de Microsoft exige 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 répertorie les composants qui constituent la conception :

  • Réseau local
    • Service de nom de domaine (DNS)
    • Passerelle
  • Abonnement au hub
    • Sous-réseau d’Application Gateway
    • Sous-réseau de Pare-feu Azure
    • Sous-réseau de services partagés
  • Abonnement connecté
    • Sous-réseau d’Azure Bastion
    • Appairage de réseaux virtuels

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

  • Azure Key Vault : service de gestion des informations d’identification soutenu par matériel informatique qui est étroitement intégré aux services d’identité et aux ressources de calcul de Microsoft.

  • Azure Monitor : suite complète de services de surveillance pour les applications déployées sur Azure et localement.

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

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

  • Azure Spring Apps : service géré conçu et optimisé spécifiquement pour les applications Spring Boot en Java et les applications Steeltoe.

The following diagrams represent a well-architected hub and spoke design that addresses the above requirements:

Applications publiques

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

  • Un sous-réseau ne doit avoir qu’une seule instance d’Azure Spring Apps.
  • Le respect d’au moins un point de référence de sécurité doit être appliqué.
  • Les enregistrements DNS (Domain Name Service) de l’hôte d’application doivent être stockés dans DNS privé Azure.
  • Azure DDoS Protection doit être activé.
  • Les dépendances de service Azure doivent communiquer par l’intermédiaire de points de terminaison de service ou d’une liaison privée.
  • Les données au repos doivent être chiffrées.
  • Les données en transit doivent être chiffrées.
  • Des 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 traverser une appliance centrale de réseau virtuel (par exemple, Pare-feu Azure).
  • Le trafic d’entrée doit être géré au moins par Application Gateway ou Azure Front Door.
  • Les adresses Internet routables doivent être stockées dans DNS public Azure.
  • L’approche de sécurité Zero Trust de Microsoft exige 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 répertorie les composants qui constituent la conception :

  • Réseau local
    • Service de nom de domaine (DNS)
    • Passerelle
  • Abonnement au hub
    • Sous-réseau d’Application Gateway
    • Sous-réseau de Pare-feu Azure
    • Sous-réseau de services partagés
  • Abonnement connecté
    • Sous-réseau d’Azure Bastion
    • Appairage de réseaux virtuels

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

  • Pare-feu Azure Application : fonctionnalité d’Azure Application Gateway qui protège les applications de manière centralisée contre les vulnérabilités et codes malveillants exploitant une faille de sécurité les plus courants.

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

  • Azure Key Vault : service de gestion des informations d’identification soutenu par matériel informatique qui est étroitement intégré aux services d’identité et aux ressources de calcul de Microsoft.

  • Azure Monitor : suite complète de services de surveillance pour les applications déployées sur Azure et localement.

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

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

  • Azure Spring Apps : service géré conçu et optimisé spécifiquement pour les applications Spring Boot en Java et les applications Steeltoe.

Les diagrammes suivants représentent une conception en étoile bien architecturée qui répond aux exigences ci-dessus : Seul le réseau virtuel hub communique avec Internet :

Connectivité locale 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 vers l’extérieur ou vers le réseau local à l’aide d’Express Route ou d’un réseau privé virtuel (VPN) site à site.

Considérations relatives à Azure Well-Architected Framework

Azure Well-Architected Framework est un ensemble de principes directeurs à suivre pour l’établissement d’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 des systèmes distribués, l’expansion de l’infrastructure est une réalité. Cette réalité se traduit par des coûts inattendus et incontrôlables. Azure Spring Apps est construit à l’aide de composants qui sont mis à l’échelle de manière à pouvoir répondre à la demande et optimiser les coûts. Azure Kubernetes Service (AKS) est au cœur de cette architecture. 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 différents types d’applications sur une instance unique 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 la rentabilité.

Vous pouvez également utiliser Application Insights et Azure Monitor pour réduire le coût d’exploitation. Grâce à la visibilité fournie par la solution complète de journalisation, 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 corriger pour améliorer le coût et les performances du système dans leur ensemble.

Excellence opérationnelle

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

  • Vous pouvez utiliser Azure Pipelines pour garantir la fiabilité et la cohérence des déploiements 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 par le biais d’un agent Java. Cet agent fournit une visibilité sur toutes les applications déployées et les dépendances sans nécessiter de code supplémentaire. Pour plus d’informations, consultez le billet de blog Superviser sans effort les applications et les dépendances dans Azure Spring Apps.
  • Vous pouvez utiliser Microsoft Defender pour le cloud pour vous assurer que les applications maintiennent la sécurité en fournissant une plateforme permettant d’analyser et d’é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 grâce au clustering, cette architecture de référence intègre des services et des considérations architecturales pour accroître la disponibilité de l’application en cas de défaillance d’un 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. En cas d’utilisation d’une application privée, l’architecture utilise DNS privé Azure pour garantir la disponibilité continue pendant une défaillance géographique. En cas d’utilisation d’une application publique, Azure Front Door et Azure Application Gateway garantissent la disponibilité.

Sécurité

La sécurité de cette architecture est assurée par son respect des contrôles et des points de référence définis par le secteur d’activité. Dans ce contexte, le « contrôle » désigne une pratique recommandée concise et bien définie, telle que « utiliser le principe de privilège 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 CCM (Cloud Control Matrix) via leCloud Security Alliance (CSA) et duMicrosoft Azure Foundations MAFB (MAFB) via 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é, à savoir la gouvernance, la mise en réseau et la sécurité des applications. Il vous appartient de gérer les principes de conception de l’identité, de la gestion des accès et du stockage en fonction de votre infrastructure cible.

Gouvernance

Le principal aspect de la gouvernance que cette architecture aborde est la séparation par l’isolation des ressources réseau. Dans la CCM, DCS-08 recommande le contrôle des entrées et des sorties sur le centre de données. Pour satisfaire ce contrôle, l’architecture utilise une conception hub-and-spoke utilisant des 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 dans le 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 de la sécurité du centre de données dans cette référence :

ID du contrôle CSA CCM Domaine du contrôle CSA CCM
DCS-08 Sécurité du centre de sécurité – Entrée de personnes non autorisées

Réseau

La conception du réseau prenant en charge cette architecture est dérivée du modèle hub-and-spoke traditionnel. Cette décision garantit que l’isolement 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 implémentant les NSG pour le trafic est-ouest (au sein du « centre de données ») et le Pare-feu Azure pour le trafic nord-sud (hors 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 qui prennent en charge cette architecture utilisent tous des protocoles sécurisés standard tels que TLS pour HTTP et SQL.

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

ID du contrôle CSA CCM Domaine du contrôle CSA CCM
IPY-04 Protocoles réseau
IVS-06 Sécurité réseau

L’implémentation du réseau est en outre sécurisée par la définition de contrôles du MAFB. Ces contrôles garantissent que le trafic dans l’environnement est limité à partir de l’Internet public.

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

ID du contrôle CIS Description du contrôle CIS
6.2 Vérifie que l’accès SSH à partir d’Internet est restreint.
6.3 Vérifie qu’aucune base de données SQL n’autorise l’accès à 0.0.0.0/0 (N’IMPORTE QUELLE ADRESSE IP).
6.5 Vérifie que Network Watcher est défini sur « Activé ».
6.6 Vérifie que l’entrée à l’aide d’UDP est restreinte à partir d’Internet.

Azure Spring Apps exige que le trafic de gestion sorte d’Azure lorsqu’il est déployé dans un environnement sécurisé. Vous devez autoriser les règles de réseau et d’application énumérées dans Responsabilités du client pour l’exécution d’Azure Spring Apps dans VNET.

Sécurité des applications

Ce principe de conception couvre les composantes fondamentales de l'identité, de la protection des données, de la gestion des clés et de la configuration des applications. De par sa conception, une application déployée dans Azure Spring Apps s’exécute avec le privilège minimum requis pour fonctionner. L’ensemble des 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 la sécurité des applications par couches.

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

ID du contrôle CSA CCM Domaine du contrôle CSA CCM
EKM-01 Chiffrement et gestion des clés – Droit d’utilisation
EKM-02 Chiffrement et gestion des clés – Génération de clés
EKM-03 Chiffrement et gestion des clés – Protection des données sensibles
EKM-04 Chiffrement et gestion des clés – Stockage et accès

Dans la CCM, EKM-02 et EKM-03 recommandent des stratégies et des procédures pour gérer les clés et utiliser les protocoles de chiffrement afin de 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 répertorie les contrôles CIS qui traitent de la gestion des clés dans cette référence :

ID du contrôle CIS Description du contrôle CIS
8.1 Vérifie que la date d’expiration est définie sur toutes les clés.
8,2 Vérifie que la date d’expiration est définie sur tous les secrets.
8,4 Vérifie que le coffre de clés est récupérable.

Les contrôles CIS 8.1 et 8.2 recommandent que des dates d’expiration soient définies pour les informations d’identification afin de garantir l’application de la rotation. Le contrôle CIS 8.4 s’assure que le contenu du coffre de clés peut être restauré pour garantir la continuité de l’activité.

Ces aspects de la sécurité des applications constituent une base pour l’utilisation de cette architecture de référence afin de 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 dépôt Architecture de référence Azure Spring Apps.