Applications web gérées en toute sécurité

Azure App Service
Azure Application Gateway
Azure SQL Database
Passerelle VPN Azure
Azure Web Application Firewall

Cet article fournit un aperçu du déploiement d’applications sécurisées en utilisant l’Environnement App Service. Pour limiter l’accès aux applications à partir d’Internet, le service Azure Application Gateway et le pare-feu d’applications web Azure sont utilisés. Cet article fournit également des conseils sur l’intégration continue et le déploiement continu (CI/CD) pour les environnements ASE à l’aide d’Azure DevOps.

Ce scénario est généralement déployé dans des secteurs tels que les banques et les assurances, où les clients sont conscients de la nécessité d’une sécurité au niveau de la plateforme, en plus de la sécurité au niveau de l’application. Pour illustrer ces concepts, nous allons utiliser une application qui permet aux utilisateurs d’envoyer des notes de frais.

Cas d’usage potentiels

Pensez à ce scénario pour les cas d’usage suivants :

  • création d’une application web Azure nécessitant une sécurité supplémentaire ;
  • fourniture d’une location dédiée au lieu de plans App Service de locataire partagé ;
  • utilisation d’Azure DevOps avec un App Service Environment doté d’un équilibreur de charge interne (ILB).

Architecture

Diagramme montrant l’architecture de l’exemple de scénario pour le déploiement d’App Service Environment ILB sécurisé.

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

Dataflow

  1. Les requêtes HTTP/HTTPS arrivent d’abord sur la passerelle d’application.
  2. En option (non illustré dans le diagramme), vous pouvez activer l'authentification Microsoft Entra pour l'application Web. Après que le trafic atteint la passerelle d’application, l’utilisateur sera invité à fournir des informations d’identification pour s’authentifier auprès de l’application.
  3. Les demandes de l’utilisateur transitent par l’équilibreur de charge interne (ILB) de l’environnement, qui achemine à son tour le trafic vers l’application web Dépenses.
  4. L’utilisateur procède ensuite à la création d’une note de frais.
  5. Dans le cadre de la création de la note de frais, l’application API déployée est appelée pour récupérer le nom et l’adresse e-mail du responsable de l’utilisateur.
  6. La note de frais créée est stockée dans Azure SQL Database.
  7. Pour faciliter le déploiement continu, le code est archivé dans l’instance Azure DevOps.
  8. L’agent Azure DevOps est installé sur la machine virtuelle de build, ce qui permet à celle-ci d’extraire les bits de l’application web à déployer dans App Service Environment (car la machine virtuelle de build est déployée dans un sous-réseau au sein du même réseau virtuel).

Components

  • L’App Service Environment fournit un environnement dédié entièrement isolé pour l’exécution sécurisée de l’application à grande échelle. En outre, étant donné que App Service Environment et les charges de travail qui s’exécutent sur celui-ci se trouvent derrière un réseau virtuel, il fournit également une couche supplémentaire de sécurité et d’isolation. La nécessité d’une échelle et d’une isolation élevées a conduit à la sélection d’un App Service Environment ILB.
  • Cette charge de travail utilise le niveau de service App Service isolé, de manière à ce que l'application s'exécute dans un environnement privé dédié dans un centre de données Azure en utilisant des processeurs plus rapides, un stockage SSD (solid-state drive) et un ratio mémoire/coeur doublé par rapport à la version Standard.
  • Azure App Service Application web et API App hébergent des applications web et des API RESTful. Ces applications et API sont hébergées sur le plan de services isolé, qui offre également la mise à l'échelle automatique, les domaines personnalisés, etc. mais dans un niveau dédié.
  • Azure Application Gateway est un équilibreur de charge de trafic web opérant au niveau de la couche 7, qui gère le trafic vers l’application web. Il offre un déchargement SSL qui élimine les frais généraux supplémentaires liés aux serveurs web hébergeant l’application web pour déchiffrer à nouveau le trafic.
  • Le pare-feu d’application web est une fonctionnalité de la passerelle d’application. L’activation du pare-feu d’application web dans la passerelle d’application améliore encore la sécurité. Le pare-feu d’application web utilise les règles du projet Open Worldwide Application Security Project (OWASP) pour protéger l’application web contre des attaques telles que le cross-site scripting, le détournement de session et l’injection SQL.
  • Azure SQL Database a été sélectionné parce que la plupart des données de cette application sont des données relationnelles, avec certaines données sous forme de documents et d’objets blob.
  • La mise en réseau Azure fournit diverses fonctionnalités de mise en réseau dans Azure, et les réseaux peuvent être appairés avec d'autres réseaux virtuels dans Azure. Les connexions peuvent également être établies avec des centres de données locaux via ExpressRoute ou site à site. Dans ce cas, un point de terminaison de service est activé sur le réseau virtuel pour s’assurer que les données circulent uniquement entre le réseau virtuel Azure et l’instance SQL Database.
  • Azure DevOps est utilisé pour aider les équipes à collaborer sur des sprints à l’aide de fonctionnalités qui facilitent le développement agile, ainsi que pour créer des pipelines de build et de mise en production.
  • Une machine virtuelle de build Azure a été créée afin que l’agent installé puisse extraire la build ad hoc et déployer l’application web dans l’environnement.

Autres solutions

Un App Service Environment peut exécuter des applications web standard sur Windows ou, comme dans cet exemple, les applications web déployées dans l’environnement s’exécutent chacune en tant que conteneurs Linux. Un App Service Environment a été sélectionné pour héberger ces applications en conteneur à instance unique. D’autres solutions sont disponibles. Lisez les considérations ci-dessous lors de la conception de votre solution.

  • Azure Service Fabric : Si votre environnement est principalement basé sur Windows et vos charges de travail principalement basées sur .NET Framework, et que vous n’envisagez pas encore de réarchitecturer .NET Core, utilisez Service Fabric pour prendre en charge et déployer des conteneurs Windows Server. En outre, Service Fabric prend en charge les API de programmation C# ou Java et, pour le développement de microservices natifs, les clusters peuvent être approvisionnés sur Windows ou Linux.
  • Azure Kubernetes service (AKS) est un projet open source et une plateforme d’orchestration plus adaptée à l’hébergement d’applications multiconteneurs complexes qui utilisent généralement une architecture basée sur des microservices. AKS est un service Azure géré qui élimine les complexités liées à l’approvisionnement et à la configuration d’un cluster Kubernetes. Toutefois, une connaissance significative de la plateforme Kubernetes restant nécessaire pour la prendre en charge et la gérer, il se peut que l’hébergement d’une poignée d’applications web en conteneur à instance unique ne soit pas la meilleure option.

D’autres options pour la couche Données incluent :

  • Azure Cosmos DB : Si la majorité des données sont dans un format non relationnel, Azure Cosmos DB est une bonne alternative. Cette plateforme permet d’exécuter d’autres modèles de données comme des données MongoDB, Cassandra ou Graph, ou un stockage Table simple.

Considérations

Lors du gestion des certificats sur App Service Environment ILB, certains aspects doivent être pris en compte. Vous devez générer un certificat relié à une racine de confiance sans nécessiter qu’une demande de signature de certificat soit générée par le serveur sur lequel le certificat sera stocké. Avec Internet Information Services (IIS), par exemple, la première étape consiste à générer une requête de signature de certificat (CSR) à partir de votre serveur IIS, puis à l'envoyer à l'autorité émettrice du certificat SSL.

Vous ne pouvez pas émettre une CSR à partir de l’équilibreur de charge interne (ILB) d’un Environnement App Service. Pour gérer cette limitation, il est recommandé d’utiliser la procédure générique.

La procédure générique vous permet d’utiliser une preuve de propriété de nom DNS au lieu d’une demande de signature de certificat. Si vous êtes propriétaire d’un espace de noms DNS, vous pouvez placer un enregistrement TXT de DNS spécial. La procédure générique vérifie alors que l’enregistrement est présent et, si c’est le cas, sait que vous possédez le serveur DNS parce que vous disposez de l’enregistrement approprié. Sur la base de ces informations, le service émet un certificat qui est inscrit auprès d’une racine approuvée, que vous pouvez ensuite charger sur votre ILB. Vous n’avez pas à vous soucier des magasins de certificats individuels sur les Web Apps, car vous disposez d’un certificat SSL racine de confiance sur l’ILB.

Effectuez un travail de certificat SSL auto-signé ou émis en interne si vous souhaitez effectuer des appels sécurisés entre les services s’exécutant dans un App Service Environment ILB. Une autre solution à considérer pour faire fonctionner App Service Environment ILB avec un certificat SSL émis en interne et pour charger l'autorité de certification interne dans le magasin racine approuvé.

Lors de l’approvisionnement de l’App Service Environment, tenez compte des limitations suivantes au moment de choisir un nom de domaine pour l’environnement. Les noms de domaine ne peuvent pas être :

  • net
  • azurewebsites.net
  • p.azurewebsites.net
  • nameofthease.p.azurewebsites.net

En outre, le nom de domaine personnalisé utilisé pour les applications, et le nom de domaine utilisé par l’App Service Environment ILB ne peuvent pas se chevaucher. Pour un App Service Environment ILB dont le nom de domaine est contoso.com, vous ne pouvez pas utiliser pour vos applications des noms de domaine personnalisés tels que :

  • www.contoso.com
  • abcd.def.contoso.com
  • abcd.contoso.com

Choisissez pour l’App Service Environment ILB un domaine qui n’est pas en conflit avec ces noms de domaine personnalisés. Vous pouvez utiliser quelque chose comme contoso-internal.com pour le domaine de votre environnement pour cet exemple, car cela n’est pas en conflit avec les noms de domaines personnalisés qui se terminent par . contoso.com.

Un autre point à prendre en considération est le DNS. Pour permettre aux applications se trouvant dans l’App Service Environment de communiquer entre elles, par exemple, pour qu’une application web puisse communiquer avec une API, vous devez configurer un DNS pour votre réseau virtuel contenant l’ASE. Vous pouvez soit apporter votre propre DNS, soit utiliser une zone privée d’Azure DNS.

Disponibilité

Extensibilité

Sécurité

Résilience

Déployer ce scénario

Pour déployer ce scénario, suivez ce didacticiel pas à pas montrant comment déployer manuellement chaque composant. Sélectionnez App Service Environment v3 au lieu de v2, lorsque vous suivez le didacticiel. Ce didacticiel fournit également un exemple d’application .NET qui exécute une simple application de notes de frais de Contoso.

Tarifs

Explorez le coût d’exécution de ce scénario. Tous les services sont préconfigurés dans le calculateur de coût. Pour pouvoir observer l’évolution de la tarification pour votre cas d’usage particulier, modifiez les variables appropriées en fonction du trafic que vous escomptez.

Nous proposons trois exemples de profils de coût basés sur la quantité de trafic que vous escomptez :

  • Petit : cet exemple de tarification représente les composants nécessaires pour une instance de niveau de production minimale servant quelques milliers d’utilisateurs par mois. L’application utilise une seule instance d’une application web standard, suffisante pour permettre une mise à l’échelle automatique. Chacun des autres composants est mis à l’échelle vers un niveau de base qui minimisera les coûts tout en garantissant qu’il y a un support d’accord de niveau de service (SLA) et une capacité suffisante pour gérer une charge de travail de niveau production.
  • Moyen : les composants nécessaires pour un déploiement de taille moyenne. Ici, nous estimons environ 100 000 utilisateurs au cours d’un mois. Le trafic attendu est traité dans une instance unique d’App Service avec un niveau standard modéré. En outre, des niveaux modérés des services Cognitive et de recherche sont ajoutés à la calculatrice.
  • Grand : une application destinée à un déploiement à grande échelle, de l’ordre de plusieurs millions d’utilisateurs par mois et de plusieurs téraoctets de données. À ce niveau d’utilisation, des applications web hautes performances de niveau Premium déployées dans plusieurs régions, avec Traffic Manager en frontal, sont nécessaires. Les données incluent les composants stockage, bases de données et SDN, configurés pour plusieurs téraoctets de données.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteur principal :

  • Faisal Mustafa | Ingénieur client senior

Étapes suivantes