Application web redondante interzone de base hautement disponible

Cette architecture de référence s'appuie sur l'architecture d'application Web de base et l'étend afin de fournir des conseils détaillés pour la conception d'une application Web sécurisée, redondante par rapport à la zone et hautement disponible sur Azure. L’architecture expose un point de terminaison public via Azure Application Gateway avec Web Application Firewall. Il achemine les requêtes vers Azure App Service via Private Link. L’application App Service utilise l’intégration de réseau virtuel et Private Link pour communiquer de manière sécurisée avec les services PaaS Azure tels qu’Azure Key Vault et Azure SQL Database.

Architecture

Figure 1 : Architecture Azure App Service de base

Téléchargez un fichier Visio de cette architecture.

Composants

De nombreux éléments de cette architecture sont les mêmes que ceux de l'architecture de base des applications Web. La liste suivante ne met en évidence que les changements apportés à l'architecture de base.

• Application Gateway est un équilibreur de charge de couche 7 (HTTP/S) et un gestionnaire de trafic web. Il utilise le routage basé sur le chemin d’URL pour distribuer le trafic entrant entre les zones de disponibilité et décharge le chiffrement pour améliorer les performances de l’application.
• Web Application Firewall (WAF) est un service cloud natif qui protège les applications web contre les attaques courantes telles que l’injection SQL et le scripting inter-site. WAF offre une visibilité sur le trafic vers et depuis votre application web, ce qui vous permet de surveiller et de sécuriser votre application.
• Azure Key Vault est un service qui stocke et gère de manière sécurisée les secrets, les clés de chiffrement et les certificats. Il centralise la gestion des informations sensibles.
• Azure Réseau virtuel est un service qui vous permet de créer des réseaux virtuels privés isolés et sécurisés dans Azure. Pour une application web sur App Service, vous avez besoin d’un sous-réseau de réseau virtuel pour utiliser des points de terminaison privés pour une communication sécurisée entre les ressources.
• Private Link permet aux clients d’accéder aux services PaaS (platform as a service) Azure directement à partir de réseaux virtuels privés sans utiliser d’adresse IP publique.
• Azure DNS est un service d’hébergement pour les domaines DNS, qui offre une résolution de noms à l’aide de l’infrastructure Microsoft Azure. Les zones DNS privées permettent de mapper le nom de domaine complet (FQDN) d'un service à l'adresse IP d'un point de terminaison privé.

Mise en réseau

La sécurité réseau est au cœur de l’architecture de base d’App Services (voir figure 2). À partir d’un niveau élevé, l’architecture réseau garantit les éléments suivants :

1. Point d’entrée sécurisé unique pour le trafic client
2. Le trafic réseau est filtré
3. Les données en transit sont chiffrées de bout en bout avec TLS
4. L’exfiltration de données est réduite au minimum en conservant le trafic dans Azure grâce à l’utilisation de Private Link
5. Les ressources réseau sont logiquement regroupées et isolées les unes des autres par le biais de la segmentation réseau

Flux réseau

Figure 2 : Architecture réseau de l’application de base Azure App Service

Voici des descriptions du flux entrant du trafic Internet vers l’instance App Service et du flux d’App Service vers les services Azure.

Flux entrant

1. L’utilisateur envoie une requête à l’adresse IP publique Application Gateway.
2. Les règles WAF sont évaluées. Les règles WAF affectent positivement la fiabilité du système en se protégeant contre diverses attaques, comme l'écriture de scripts inter-site (XSS) et l'injection de SQL. Azure Application Gateway retourne une erreur au demandeur si une règle WAF est violée et que le traitement s'arrête. Si aucune règle WAF n'est violée, Application Gateway achemine la requête vers le pool back-end, qui dans ce cas est le domaine par défaut App Service.
3. La zone DNS privée privatelink.azurewebsites.net est liée au réseau virtuel. La zone DNS a un enregistrement A qui mappe le domaine par défaut de l'App Service à l'adresse IP privée du point de terminaison privé de l'App Service. Cette zone DNS privée liée permet à Azure DNS de résoudre le domaine par défaut à l’adresse IP du point de terminaison privé.
4. La requête est acheminée vers une instance App Service via le point de terminaison privé.

App Service au flux des services PaaS Azure

1. App Service effectue une requête au nom DNS du service Azure requis. La requête peut être adressée à Azure Key Vault pour obtenir un secret, à Stockage Azure pour obtenir un fichier zip de publication, à Azure SQL Database ou à tout autre service Azure prenant en charge Private Link. La fonctionnalité d’intégration de réseau virtuel App Service route la requête via le réseau virtuel.
2. Comme à l’étape 3 du flux entrant, la zone DNS privée liée a un enregistrement A qui mappe le domaine du service Azure à l’adresse IP privée du point de terminaison privé. De même, cette zone DNS privée liée permet à Azure DNS de résoudre le domaine par défaut à l’adresse IP du point de terminaison privé.
3. La requête est acheminée vers le service via le point de terminaison privé.

Entrée vers App Services

Application Gateway est une ressource régionale qui répond aux exigences de cette architecture de base. Application Gateway est un équilibreur de charge de couche 7 évolutif et régional qui prend en charge des fonctionnalités telles que le pare-feu d’applications web et le déchargement TLS. Tenez compte des points suivants lors de l’implémentation d’Application Gateway pour l’entrée dans Azure App Services.

• Déployez Application Gateway et configurez une stratégie WAF avec un ensemble de règles géré par Microsoft. Utilisez le mode prévention pour atténuer les attaques web qui peuvent entraîner l'indisponibilité d'un service d'origine (App Service dans l'architecture).
• Implémentez le chiffrement TSL de bout en bout.
• Utilisez des points de terminaison privés pour implémenter l’accès privé entrant à votre App Service.
• Envisagez d’implémenter la mise à l’échelle automatique pour Application Gateway afin de s’ajuster facilement aux flux de trafic dynamiques.
• Envisagez d’utiliser une mise à l’échelle minimale instance nombre de trois et utilisez toujours toutes les zones de disponibilité prises en charge par votre région. Bien que Application Gateway soit déployé de manière hautement disponible, même pour une mise à l’échelle unique des instances, la création d’un instance en cas de défaillance peut prendre jusqu’à sept minutes. Le déploiement de plusieurs instances sur Zones de disponibilité permet de garantir, en cas d’échec, qu’une instance est en cours d’exécution pendant la création d’une nouvelle instance.
• Désactivez l’accès au réseau public sur App Service pour garantir l’isolation du réseau. Dans Bicep, cela s’effectue en paramétrant publicNetworkAccess: 'Disabled' sous properties/siteConfig.

Flux d’App Services vers les services Azure

Cette architecture utilise l’intégration de réseau virtuel pour App Service, en particulier pour acheminer le trafic vers des points de terminaison privés via le réseau virtuel. L'architecture de base ne permet pas à tout le routage du trafic de forcer tout le trafic sortant via le réseau virtuel, mais simplement le trafic interne, tel que le trafic lié aux points de terminaison privés.

Les services Azure qui ne nécessitent pas d’accès à partir de l’Internet public ont des points de terminaison privés activés et des points de terminaison publics désactivés. Les points de terminaison privés sont utilisés tout au long de cette architecture pour améliorer la sécurité en permettant à vos App Service de se connecter aux services Private Link directement à partir de votre réseau virtuel privé sans utiliser d’adressage IP public.

Dans cette architecture, Azure SQL Database, Stockage Azure et Key Vault ont tous des points de terminaison publics désactivés. Les pare-feu de service Azure sont uniquement utilisés pour autoriser le trafic provenant d'autres services Azure autorisés. Vous devez également configurer d'autres services Azure avec des points de terminaison privés comme Azure Cosmos DB et Azure Redis Cache. Dans cette architecture, Azure Monitor n’utilise pas de point de terminaison privé, mais il le peut.

L’architecture de base implémente une zone DNS privée pour chaque service. La zone DNS privée contient un enregistrement A qui est mappé entre le nom de domaine complet du service et l'adresse IP privée du point de terminaison privé. Les zones sont liées au réseau virtuel. Les groupes de zones DNS privées garantissent la création et la mise à jour automatiques des enregistrements DNS des liens privés.

Tenez compte des points suivants lors de l’implémentation de l’intégration de réseau virtuel et des points de terminaison privés.

• Utilisez les conseils de configuration de zone DNS des services Azure pour nommer des zones DNS privées.
• Configurez des pare-feu de service pour vous assurer que le compte de stockage, le coffre de clés, les SQL Database et d’autres services Azure ne peuvent être connectés qu’en privé.
  • Définissez la règle d’accès réseau par défaut du compte de stockage pour refuser tout le trafic.
  • Activez Key Vault pour Private Link.
  • Refusez l'accès du réseau public à Azure SQL.

Segmentation et sécurité du réseau virtuel

Le réseau de cette architecture a des sous-réseaux distincts pour Application Gateway, les composants d’intégration App Service et les points de terminaison privés. Chaque sous-réseau a un groupe de sécurité réseau qui limite le trafic entrant et sortant pour ces sous-réseaux à ce qui est requis. Le tableau suivant montre une vue simplifiée des règles de groupe de sécurité réseau que la base de référence ajoute à chaque sous-réseau. Le tableau donne le nom de la règle et la fonction.

Tenez compte des points suivants lors de l’implémentation de la segmentation et de la sécurité du réseau virtuel.

• Activez la protection DDoS pour le réseau virtuel avec un sous-réseau qui fait partie d’une passerelle applicative avec une adresse IP publique.
• Ajoutez un groupe de sécurité réseau à chaque sous-réseau si possible. Vous devez utiliser les règles les plus strictes qui activent les fonctionnalités complètes de la solution.
• Utilisation de groupes de sécurité d’application. Les groupes de sécurité d'application vous permettent de regrouper des groupes de sécurité réseau, ce qui facilite la création de règles pour les environnements complexes.

Voici un exemple de schéma de sous-réseau virtuel :

Source : Azure-Samples\app-service-baseline-implementation

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.

Fiabilité

La fiabilité permet de s’assurer que votre application tient vos engagements auprès de vos clients. Pour plus d’informations, consultez la page Vue d’ensemble du pilier de fiabilité.

L’architecture App Services de base se concentre sur la redondance zonale pour les services régionaux clés. Les zones de disponibilité sont des emplacements physiquement séparés au sein d’une région. Ils fournissent une redondance zonale pour les services de prise en charge lorsque deux instances ou plus sont déployées dans des régions de prise en charge. Lorsqu’une zone subit un temps d’arrêt, les autres zones peuvent toujours ne pas être affectées.

L'architecture garantit également qu'il existe suffisamment d'instances des services Azure pour répondre à la demande. Les sections suivantes fournissent des conseils de fiabilité pour les services clés de l’architecture. De cette façon, les zones de disponibilité vous aident à atteindre la fiabilité en fournissant une haute disponibilité et une tolérance de défaillance.

Application Gateway

Déployez Azure Application Gateway version 2 dans une configuration redondante interzone. Envisagez d'utiliser un nombre minimum d'instances d'échelle d'au moins trois pour éviter le temps de démarrage de six à sept minutes d'une instance d'Application Gateway en cas de défaillance.

App Services

• Déployez au moins trois instances d’App Services avec la prise en charge des zones de disponibilité.
• Implémentez des points de terminaison de contrôle d’intégrité dans vos applications et configurez la fonctionnalité de contrôle d’intégrité App Service pour rediriger les demandes à partir d’instances non saines. Pour plus d’informations sur le contrôle d’intégrité App Service, consultez Surveiller les instances App Service à l’aide du contrôle d’intégrité. Pour plus d’informations sur l’implémentation de points de terminaison de contrôle d’intégrité dans les applications ASP.NET, consultez Contrôles d’intégrité dans ASP.NET Core.
• Surprovisionnez la capacité pour pouvoir gérer les défaillances de zone.

SQL Database

• Déployez Azure SQL DB avec les niveaux Usage général, Premium ou Critique pour l'entreprise avec la redondance de zone activée. Les niveaux Usage général, Premium et Critique pour l'entreprise prennent en charge la redondance de zone dans Azure SQL DB.
• Configurez les sauvegardes de base de données SQL pour utiliser le stockage redondant interzone (ZRS) ou le stockage géo-redondant interzone (GZRS).

Stockage d'objets blob

• Le Stockage redondant interzone (ZRS) Azure réplique vos données de façon synchrone dans les trois zones de disponibilité de la région. Créez des comptes de stockage ZRS ou GZRS standard pour vous assurer que les données sont répliquées entre les zones de disponibilité.
• Créez des comptes de stockage distincts pour les déploiements, les ressources web et les autres données, afin de pouvoir les gérer et les configurer séparément.

Efficacité des performances

L’efficacité des performances est la capacité de votre charge de travail à s’adapter à la demande des utilisateurs de façon efficace. Pour plus d’informations, consultez Vue d’ensemble du pilier d’efficacité des performances.

Les sections suivantes traitent de la scalabilité des composants clés de cette architecture.

Application Gateway

• Implémentez la mise à l’échelle automatique pour Application Gateway pour effectuer un scale-in ou un scale-out afin de répondre à la demande.
• Définissez le nombre maximal d’instances sur un nombre supérieur à vos besoins attendus. Seules les unités de capacité que vous utilisez vous seront facturées.
• Définissez un nombre minimal d’instances capables de gérer de petits pics de trafic. Vous pouvez utiliser l’utilisation moyenne des unités Compute pour calculer votre nombre minimal d’instances.
• Suivez les instructions sur le dimensionnement du sous-réseau Application Gateway.

App Service

• Utilisez des plans Standard ou supérieurs avec au moins trois instances de travail pour la haute disponibilité.
• Activez la mise à l’échelle automatique pour vous assurer que vous pouvez effectuer un scale-up ou un scale-down pour répondre à la demande.
• Envisagez d’ouvrir un ticket de support pour augmenter le nombre maximal de Workers à deux fois le nombre d’instances si votre App Service utilise systématiquement la moitié du nombre maximal d’instances. Le nombre maximal d’instances par défaut est de 30 pour un plan Premium App Service et de 10 pour un plan Standard.
• Envisagez de déployer plusieurs tampons de l’application lorsque votre App Service commence à atteindre les limites supérieures.
• Choisissez le bon plan Azure App Service qui répond aux exigences de votre charge de travail.
• Ajoutez Azure CDN à Azure App Service pour servir du contenu statique.
• Envisagez App Service Environment si les voisins bruyants sont un problème.

SQL Server

La mise à l’échelle des ressources de base de données est un sujet complexe en dehors de l’étendue de cette architecture. Tenez compte des ressources suivantes lors de la mise à l’échelle de votre base de données,

• Mettre à l’échelle de façon dynamique les ressources de base de données moyennant un temps d’arrêt minimal
• Scale-out avec Azure SQL Database
• Utiliser des réplicas en lecture seule pour décharger des charges de travail de requêtes en lecture seule

Autre guide de scalabilité

• Passez en revue les limites et quotas d’abonnement pour vous assurer que les services sont mis à l’échelle à la demande.
• Envisagez la mise en cache pour les types de données suivants afin d’augmenter les performances et la scalabilité :
  • Les données de transaction semi-statiques.
  • L’état de la session.
  • La sortie HTML. Cela peut être utile dans les applications qui restituent une sortie HTML complexe.

Sécurité

L’architecture App Service de base se concentre sur les recommandations de sécurité essentielles pour votre application web. Il est essentiel de comprendre le fonctionnement du chiffrement et de l’identité à chaque couche pour sécuriser votre charge de travail.

App Service

• Désactiver les méthodes d’authentification locales pour les déploiements de sites FTP et SCM
• Désactivez le débogage à distance.
• Utilisez la dernière version de TLS.
• Activez Microsoft Defender pour App Service.
• Utilisez les dernières versions des plateformes, langages de programmation, protocoles et infrastructures pris en charge.
• Envisagez App Service Environment si vous avez besoin d’une isolation plus élevée ou d’un accès réseau sécurisé.

Chiffrement

Une application web de production doit chiffrer les données en transit à l’aide de HTTPS. Le protocole HTTPS s’appuie sur TLS (Transport Layer Security) et utilise des clés publiques et privées pour le chiffrement. Vous devez stocker un certificat (X.509) dans Key Vault et autoriser Application Gateway à récupérer la clé privée. Pour les données au repos, certains services chiffrent automatiquement les données et d'autres vous permettent de les personnaliser.

Données en transit

Dans l’architecture de base de référence, les données en transit sont chiffrées de l’utilisateur vers l’application web dans App Service. Le flux de travail suivant décrit le fonctionnement du chiffrement à un niveau élevé.

1. L’utilisateur envoie une requête HTTPS à l’application web.
2. La requête HTTPS atteint la passerelle d’application.
3. La passerelle d’application utilise un certificat (X.509) dans Key Vault pour créer une connexion TLS sécurisée avec le navigateur web de l’utilisateur. La passerelle d’application déchiffre la requête HTTPS afin que le pare-feu d’applications web puisse l’inspecter.
4. La passerelle d’application crée une connexion TLS avec App Service pour chiffrer à nouveau la requête de l’utilisateur. App Service offre une prise en charge native du protocole HTTPS. Vous n’avez donc pas besoin d’ajouter un certificat à App Service. La passerelle d’application envoie le trafic chiffré à App Service. App Service déchiffre le trafic et l’application web traite la requête.

Tenez compte des recommandations suivantes lors de la configuration du chiffrement des données en transit.

• Pour charger votre certificat dans Key Vault. Le chiffrement HTTPS nécessite un certificat (X.509). Vous avez besoin d’un certificat d’une autorité de certification approuvée pour votre domaine personnalisé.
• Stockez la clé privée du certificat dans Key Vault.
• Suivez les instructions fournies dans Accorder l’autorisation aux applications d’accéder à un coffre de clés Azure à l’aide d’Azure RBAC et d’identités managées pour les ressources Azure afin de permettre à Application Gateway d’accéder à la clé privée du certificat. N’utilisez pas de stratégies d’accès Key Vault pour fournir l’accès. Les stratégies d'accès ne vous permettent d'accorder que des permissions générales, et pas seulement à des valeurs spécifiques.
• Activer le chiffrement de bout en bout. App Service est le pool de back-end pour la passerelle d’application. Lorsque vous configurez le paramètre back-end pour le pool principal, utilisez le protocole HTTPS sur le port principal 443.

Données au repos

• Chiffrez les données sensibles dans Azure SQL Database à l’aide du chiffrement transparent des données. Les données transparentes chiffrent l’intégralité de la base de données, des sauvegardes et des fichiers journaux des transactions, et ne nécessitent aucune modification de votre application web.
• Réduisez la latence de chiffrement de la base de données. Pour réduire la latence de chiffrement, placez les données que vous devez sécuriser dans sa propre base de données et activez uniquement le chiffrement pour cette base de données.
• Comprendre la prise en charge du chiffrement intégré. Stockage Azure chiffre automatiquement les données au repos à l’aide du chiffrement côté serveur (AES 256 bits). Azure Monitor chiffre automatiquement les données au repos à l'aide de clés gérées par Microsoft (MMK).

Gestion de l’identité et de l’accès

La base de référence App Service configure l’authentification et l’autorisation pour les identités utilisateur (utilisateurs) et les identités de charge de travail (ressources Azure) et implémente le principe des privilèges minimum.

Identités utilisateur

• Utilisez le mécanisme d’authentification intégré pour App Service (« EasyAuth »). EasyAuth simplifie le processus d’intégration des fournisseurs d’identité dans votre application web. Il gère l’authentification en dehors de votre application web, de sorte que vous n’avez pas à apporter de modifications significatives au code.
• Configurez l’URL de réponse pour le domaine personnalisé. Vous devez rediriger l'application web vers https://<application-gateway-endpoint>/.auth/login/<provider>/callback. Remplacez par <application-gateway-endpoint> l’adresse IP publique ou le nom de domaine personnalisé associé à votre passerelle d’application. Remplacez <provider> par le fournisseur d'authentification que vous utilisez, tel que « aad » pour Microsoft Entra ID. Vous pouvez utiliser la documentation Azure Front pour configurer ce flux avec Application Gateway ou Configuration d’Application Gateway.

Identités de charge de travail

• Utilisez une identité managée pour les identités de charge de travail. Identité managée permet aux développeurs de ne plus avoir à gérer les informations d’authentification.
• Utilisez des identités managées affectées par l’utilisateur. Une identité affectée par le système peut entraîner l’échec des déploiements d’infrastructure en tant que code en fonction des conditions de concurrence et de l’ordre des opérations. Vous pouvez utiliser des identités managées affectées par l’utilisateur pour éviter certains de ces scénarios d’erreur de déploiement. Pour plus d’informations, voir Identités managées.

Excellence opérationnelle

L’excellence opérationnelle couvre les processus d’exploitation qui déploient une application et maintiennent son fonctionnement en production. Pour plus d’informations, consultez Vue d’ensemble du pilier Excellence opérationnelle.

Le déploiement de l’application App Service de base suit les instructions fournies dans CI/CD pour Azure Web Apps avec Azure Pipelines. En plus de ces conseils, l'architecture de base d'App Services prend en compte le fait que l'application et le compte de stockage de déploiement sont sécurisés par le réseau. L’architecture refuse l’accès public à App Service. Cela signifie que vous ne pouvez pas déployer à partir de l’extérieur du réseau virtuel. La base de référence vous montre comment déployer le code d’application dans le réseau virtuel à l’aide d’agents de déploiement auto-hébergés. Les conseils de déploiement suivants se concentrent sur le déploiement du code d’application et non sur le déploiement de modifications d’infrastructure ou de base de données.

Figure 3 : Déploiement d’applications Azure App Service

Flux de déploiement

1. Dans le cadre du pipeline de mise en production, le pipeline publie une requête de travail pour les agents auto-hébergés dans la file d’attente des travaux. La requête de travail consiste pour l'agent à télécharger le fichier zip de publication de l'artefact dans un compte de stockage Azure.

2. L’agent de déploiement auto-hébergé récupère la nouvelle requête de travail via l’interrogation. Il télécharge le travail et l’artefact de build.

3. L'agent de déploiement auto-hébergé charge le fichier zip sur le compte de stockage via le point de terminaison privé du compte de stockage.

4. Le pipeline continue et un agent managé récupère un travail suivant. L’agent managé effectue un appel CLI pour mettre à jour le WEBSITE_RUN_FROM_PACKAGE appSetting au nom du nouveau fichier zip de publication pour l’emplacement intermédiaire.

   az webapp config appsettings set -g MyResourceGroupName -n MyUniqueApp --slot staging --settings WEBSITE_RUN_FROM_PACKAGE=UriToNewZip
   

5. Azure App Service extrait le nouveau fichier zip de publication du stockage via le point de terminaison privé du compte de stockage. L’instance intermédiaire redémarre avec le nouveau package, car WEBSITE_RUN_FROM_PACKAGE a été défini sur un nom de fichier différent.

6. Le pipeline reprend et exécute les tests de fumée ou attend l’approbation. Si les tests réussissent ou si l'approbation est donnée, le pipeline permute les emplacements de préproduction et de production.

Conseils pour le déploiement

L’exemple suivant met en évidence des conseils de déploiement clés pour l’architecture de base.

• Utilisez Exécuter à partir du package pour éviter les conflits de déploiement. Lorsque vous exécutez votre application directement à partir d’un package dans Azure App Service, les fichiers du package ne sont pas copiés dans le répertoire wwwroot. Au lieu de cela, le package ZIP lui-même est monté directement en tant que répertoire wwwroot en lecture seule. Cela élimine les conflits de verrouillage de fichiers entre le déploiement et l’exécution et garantit que seules les applications entièrement déployées s’exécutent à tout moment
• Incluez les numéros de version dans les fichiers zip du package déployé. La mise à jour de l’appSetting WEBSITE_RUN_FROM_PACKAGE vers le package de déploiement avec un nom de fichier différent amène App Services à récupérer automatiquement la nouvelle version et à redémarrer le service.
• Utilisez des emplacements de déploiement pour les déploiements de code résilient.
• Envisagez d’utiliser un mélange d’agents managés et auto-hébergés.
  • Utilisez des agents auto-hébergés pour charger le fichier zip du package sur le compte de stockage sur le point de terminaison privé. L’agent initie la communication avec le pipeline par le biais de l’interrogation. Il n’est donc pas nécessaire d’ouvrir le réseau pour un appel entrant.
  • Utilisez des agents managés pour les autres travaux dans le pipeline.
• Automatisez les déploiements d’infrastructure avec l’infrastructure en tant que code (IaC).
• Validez en permanence la charge de travail pour tester les performances et la résilience de l’ensemble de la solution à l’aide de services tels que Azure Load Testing et Azure Chaos Studio.

Configuration

Les applications nécessitent à la fois des valeurs de configuration et des secrets. Utilisez les conseils suivants pour la configuration et la gestion des secrets.

• Ne vérifiez jamais de secrets tels que des mots de passe ou des clés d’accès dans le contrôle de code source.
• Utiliser Azure Key Vault pour stocker des clés
• Utilisez laconfiguration App Service pour la configuration de votre application. Si vous devez externaliser la configuration à partir de la configuration de votre application ou exiger la prise en charge de l’indicateur de fonctionnalité, envisagez d’utiliser Azure App Configuration.
• Utilisez des références Key Vault dans la configuration App Service pour exposer en toute sécurité des secrets dans votre application.
• Si vous avez besoin de paramètres de production et de préproduction différents, vous pouvez créer des paramètres d’application spécifiques à un emplacement et qui ne seront pas transférés. Lorsque vous échangez un emplacement de déploiement, les paramètres d’application sont échangés par défaut.
• Définissez des variables d’environnement locales pour le développement local ou tirez parti des fonctionnalités de la plateforme d’application. La configuration d’App Services expose les paramètres d’application en tant que variables d’environnement. Visual Studio, par exemple, vous permet de définir des variables d’environnement dans les profils de lancement. Il vous permet également d’utiliser les paramètres d’application et les secrets utilisateur pour stocker les paramètres et secrets d’application locaux.

Surveillance

Le monitoring est la collecte et l’analyse des données des systèmes informatiques. L’objectif de la surveillance est l’observabilité à plusieurs couches pour suivre l’intégrité et la sécurité des applications web. L’observabilité est une facette clé de l’architecture de base App Service.

Pour surveiller votre application web, vous devez collecter et analyser les métriques et les journaux à partir du code de votre application, de l’infrastructure (runtime) et de la plateforme (ressources Azure). Pour plus d’informations, consultez Journal d’activité Azure, Journaux de ressources Azure et Journaux d’application.

Surveiller la plateforme

La supervision de plateforme est la collecte de données à partir des services Azure dans votre architecture. Tenez compte des conseils suivants concernant la surveillance de la plateforme.

• Ajoutez un paramètre de diagnostic pour chaque ressource Azure. Chaque service Azure a un ensemble différent de journaux et de métriques que vous pouvez capturer. Utilisez le tableau suivant pour déterminer les métriques et les journaux que vous souhaitez collecter.

  Ressource Azure	Descriptions des métriques et des journaux
  Application Gateway	Application Gateway descriptions des métriques et des journaux
  Pare-feu d’applications web	Descriptions des journaux et des métriques du pare-feu d’applications web
  App Service	Descriptions des métriques et des journaux App Service
  Azure SQL Database	Description des métriques et journaux Azure SQL Database
  CosmosDB	Descriptions des métriques et des journaux Azure Cosmos DB
  Key Vault	Descriptions des métriques et des journaux Key Vault
  Stockage Blob	Descriptions des métriques et des journaux Stockage Blob Azure
  Application Insights	Descriptions des métriques et des journaux Application Insights
  Adresse IP publique	Descriptions des journaux et des métriques d’adresses IP publiques

• Comprendre le coût de la collecte des métriques et des journaux. En général, plus vous collectez de métriques et de journaux, plus il en coûte. Pour plus d’informations, consultez Calculs et options des coûts Log Analytics etTarification de l’espace de travail Log Analytics.

• Créer des alertes. Vous devez créer des alertes pour toutes les ressources Azure dans l’architecture et configurer des actions pour corriger les problèmes. Choisissez les règles d’alerte courantes et recommandées pour commencer et les modifier au fil du temps en fonction des besoins. Pour plus d'informations, consultez les pages suivantes :

  • Vue d’ensemble des alertes Azure Monitor
  • Alertes Application Gateway
  • Alertes App Service :
  • Alertes Azure SQL Database
  • Alertes de stockage Blob
  • Alertes Key Vault

Application Gateway

Application Gateway supervise l’intégrité des ressources dans son pool back-end. Utilisez les journaux d’accès à Application Gateway pour collecter des informations telles que l’horodatage, le code de réponse HTTP et le chemin d’URL. Pour plus d’informations, consultez Sonde d'intégrité par défaut Application Gateway et Journaux d’intégrité et de diagnostic du back-end.

App Service

App Service dispose d’outils de surveillance intégrés que vous devez activer pour améliorer l’observabilité. Si votre application web dispose déjà de fonctionnalités de télémétrie et de surveillance (« instrumentation in-process »), elle doit continuer à travailler sur App Service.

• Activez l’instrumentation automatique. App Service dispose d’une extension d’instrumentation que vous pouvez activer sans modification du code. Vous bénéficiez d’une visibilité de l’analyse des performances des applications (APM). Pour plus d’informations, consultez Surveiller le niveau de performance Azure App Service.
• Activez le suivi distribué. L’instrumentation automatique offre un moyen de surveiller les systèmes cloud distribués via un suivi distribué et un profileur de niveau de performance.
• Utilisez l’instrumentation basée sur le code pour la télémétrie personnalisée. Azure Application Insights prend également en charge l’instrumentation basée sur le code pour la télémétrie d’application personnalisée. Ajoutez le Kit de développement logiciel (SDK) Application Insights à votre code et utilisez l’API Application Insights.
• Activez les journaux App Service. La plateforme App Service prend en charge quatre journaux supplémentaires que vous devez activer pour prendre en charge le dépannage. Ces journaux sont des journaux d’application, des journaux de serveur web, des messages d’erreur détaillés et un suivi des requêtes ayant échoué.
• Utilisez une journalisation structurée. Ajoutez une bibliothèque de journalisation structurée au code de votre application. Mettez à jour votre code pour utiliser des paires clé-valeur et activer les journaux des applications dans App Service pour stocker ces journaux dans votre Log Analytics Workspace.
• Activez le case App Service Health. Le case activée d’intégrité redirige les requêtes loin des instances non saines et remplace les instances non saines. Votre plan App Service doit utiliser au moins deux instances pour que les contrôles d’intégrité fonctionnent.

Base de données

• Base de données utilisateur Insights. Pour bases de données Azure SQL, vous devez configurer SQL Insights dans Azure Monitor. La base de données Insights utilise des vues de gestion dynamique pour exposer les données dont vous avez besoin pour surveiller l’intégrité, diagnostiquer les problèmes et optimiser les performances. Pour Azure SQL Database, consultez Surveillance d’Azure SQL Database avec Azure Monitor.
• Si votre architecture inclut Cosmos DB, vous n’avez pas besoin d’activer ou de configurer quoi que ce soit pour utiliser Cosmos DB Insights.

Gouvernance

Les applications web bénéficient de Azure Policy en appliquant des décisions architecturales et de sécurité. Azure Policy peut rendre (1) impossible le déploiement (refus) ou (2) facile la détection (audit) de la dérive de configuration à partir de l’état souhaité. Cela vous permet d'intercepter les déploiements d'infrastructure en tant que code (IaC) ou les modifications du Portail Azure qui s'écartent de l'architecture convenue. Vous devez placer toutes les ressources de votre architecture sous la gouvernance Azure Policy. Utilisez des stratégies ou des initiatives de stratégie intégrées lorsque cela est possible pour appliquer des décisions essentielles de topologie de réseau, de fonctionnalité de service, de sécurité et de surveillance, par exemple :

• App Service doit désactiver l’accès réseau public
• App Service doit utiliser l’intégration de réseau virtuel
• App Service doit utiliser Azure Private Link pour se connecter aux services PaaS.
• Dans App Service, les méthodes d’authentification locale doivent être désactivées pour les déploiements de sites SCM et FTP
• Le débogage à distance doit être désactivé pour les applications App Service
• Les applications App Service doivent utiliser la dernière version TLS
• Microsoft Defender pour App Service doit être activé
• Le pare-feu d’applications web (WAF) doit être activé pour Application Gateway

Consultez d’autres stratégies intégrées pour les services clés tels que les composants d’Application Gateway et de mise en réseau, App Service, Key Vault et la surveillance. Il est possible de créer des stratégies personnalisées ou d’utiliser des stratégies de communauté (par exemple à partir de zones d’atterrissage Azure) si les stratégies intégrées ne couvrent pas entièrement vos besoins. Préférez les stratégies intégrées lorsqu’elles sont disponibles.

Étapes suivantes

Ressources associées

• Guide Azure Private Link dans Azure Virtual WAN
• Montez une application en puissance dans Azure App Service
• Migrer App Service vers la prise en charge des zones de disponibilité
• Mise à l’échelle d’Application Gateway v2 et de WAF v2