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

Cet article explique comment déployer des applications sécurisées à l’aide de l’environnement App Service. Cette architecture utilise Azure Application Gateway et le pare-feu d’applications web Azure pour restreindre l’accès aux applications à partir d’Internet. Cet article explique également comment intégrer l’intégration continue et le déploiement continu (CI/CD) aux environnements App Service à l’aide d’Azure DevOps.

Les secteurs tels que les banques et les assurances utilisent souvent cette solution, car les clients apprécient la sécurité au niveau de la plateforme et de l’application. Pour illustrer ces concepts, l’exemple d’application suivant permet aux utilisateurs d’envoyer des rapports de dépenses.

Architecture

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

Flux de données

Le flux de données suivant correspond au diagramme précédent :

1. Les requêtes HTTP et HTTPS atteignent la passerelle d’application.

2. Si vous le souhaitez, l’authentification Microsoft Entra est activée pour l’application web. Une fois le trafic atteint la passerelle d’application, l’utilisateur est invité à fournir des informations d’identification pour s’authentifier auprès de l’application. Le diagramme ne montre pas cette étape.

3. L’utilisateur demande un flux via l’équilibreur de charge interne (ILB) de l’environnement, qui achemine le trafic vers l’application web des dépenses.

4. L’utilisateur crée un rapport de dépenses.

5. Dans le cadre de la création du rapport de frais, l’application API déployée est appelée pour récupérer le nom et l’e-mail du responsable de l’utilisateur.

6. Le système stocke le rapport de dépenses dans Azure SQL Database.

7. Pour faciliter le déploiement continu, le code est archivé dans l’instance Azure DevOps.

8. La machine virtuelle de build inclut l’agent Azure DevOps. Cet agent permet à la machine virtuelle de build d’extraire les artefacts de l’application web et de les utiliser pour déployer l’application web dans l’environnement App Service. La machine virtuelle de build réside dans un sous-réseau au sein du même réseau virtuel que l’environnement App Service.

Composants

• L’environnement App Service fournit un environnement entièrement isolé et dédié pour exécuter en toute sécurité l’application à grande échelle. L’environnement App Service et ses charges de travail se trouvent derrière un réseau virtuel, de sorte que la configuration ajoute une couche supplémentaire de sécurité et d’isolation. Ce scénario utilise un environnement App Service ILB pour répondre à la nécessité d’une mise à l’échelle et d’une isolation élevées.

• Cette charge de travail utilise le niveau tarifaire isolé d’App Service. L’application s’exécute dans un environnement privé dédié dans un centre de données Azure qui utilise des processeurs plus rapides et un stockage SSD (Solid-State Drive) et fournit les fonctionnalités de scale-out maximales.

• Les fonctionnalités Web Apps et API Apps d’App Service hébergent des applications web et des API RESTful. Ces applications et API sont hébergées sur le plan de service isolé, qui fournit également la mise à l’échelle automatique, les domaines personnalisés et d’autres fonctionnalités d’un niveau dédié.

• Application Gateway est un équilibreur de charge de trafic web de couche 7 qui gère le trafic vers l’application web. Il fournit le déchargement SSL (Secure Sockets Layer), ce qui supprime la surcharge du déchiffrement du trafic des serveurs web qui hébergent l’application.

• Le pare-feu d’applications web est une fonctionnalité d’Application Gateway qui améliore la sécurité. Le pare-feu d’applications web utilise des règles Open Worldwide Application Security Project (OWASP) pour protéger l’application web contre les attaques, telles que le script intersite, les détournements de session et l’injection SQL.

• SQL Database stocke les données de l’application. La plupart des données sont relationnelles, avec certaines des données stockées sous forme de documents et d’objets blob.

• Le réseau virtuel Azure fournit différentes fonctionnalités de mise en réseau dans Azure. Vous pouvez appairer des réseaux virtuels ensemble et établir des connexions avec des centres de données locaux via ExpressRoute ou un réseau privé virtuel de site à site (VPN). Ce scénario permet à un point de terminaison de service sur le réseau virtuel de s’assurer que les données circulent uniquement entre le réseau virtuel Azure et l’instance SQL Database.

• Azure DevOps prend en charge le développement agile en aidant les équipes à collaborer pendant les sprints et en fournissant des outils pour créer des pipelines de génération et de mise en production.

• Une machine virtuelle de build Azure permet à l’agent installé d’extraire la build respective et de déployer l’application web dans l’environnement.

Autres solutions

Un environnement App Service peut exécuter des applications web régulières sur Windows ou, comme dans cet exemple, les applications web qui s’exécutent en tant que conteneurs Linux déployés dans l’environnement. Ce scénario utilise un environnement App Service pour héberger ces applications conteneurisées à instance unique. Tenez compte des alternatives suivantes lorsque vous concevez votre solution :

• Azure Container Apps est une plateforme serverless qui réduit la surcharge de l’infrastructure et économise des coûts lors de l’exécution d’applications conteneurisées. Il élimine la nécessité de gérer la configuration du serveur, l’orchestration de conteneurs et les détails du déploiement. Container Apps fournit toutes les ressources de serveur up-to-date requises pour maintenir vos applications stables et sécurisées.

• Azure Kubernetes Service (AKS) est un projet open source et une plateforme d’orchestration conçue pour héberger des applications multicontainer complexes qui utilisent généralement une architecture basée sur des microservices. AKS est un service Azure managé qui simplifie l’approvisionnement et la configuration d’un cluster Kubernetes. Vous devez avoir une connaissance significative de la plateforme Kubernetes pour la prendre en charge et la gérer, de sorte que l’hébergement de quelques applications web conteneurisées à instance unique peut ne pas être la meilleure option.

Utilisez l’alternative suivante pour le niveau de données :

• Azure Cosmos DB est une bonne option si la plupart de vos données sont au format non relationnelle.

Cas d’usage potentiels

Tenez compte de cette solution pour les cas d’usage suivants :

• Créez une application web Azure qui nécessite une sécurité supplémentaire.
• Fournissez une location dédiée plutôt que des plans App Service de locataire partagé.
• Utilisez Azure DevOps avec un environnement App Service équilibré en interne .

Traiter les décisions de conception TLS et DNS

Les paramètres DNS (Domain Name System) pour le suffixe de domaine par défaut de l’environnement App Service ne limitent pas l’accessibilité de l’application à ces noms. La fonctionnalité de suffixe de domaine personnalisé pour un environnement App Service ILB vous permet d’utiliser votre propre suffixe de domaine pour accéder aux applications hébergées dans votre environnement App Service.

Un suffixe de domaine personnalisé définit un domaine racine que l’environnement App Service utilise. Pour un environnement App Service ILB, le domaine racine par défaut est appserviceenvironment.net. Un environnement App Service ILB est interne au réseau virtuel d’un client, ce qui permet aux clients d’utiliser un domaine racine en plus du domaine par défaut qui s’aligne sur leur environnement de réseau virtuel. Par exemple, Contoso Corporation peut utiliser un domaine racine par défaut pour internal.contoso.com les applications destinées à être résolus et accessibles uniquement dans le réseau virtuel de Contoso. Une application de ce réseau virtuel peut être accessible en accédant .APP-NAME.internal.contoso.com

Le suffixe de domaine personnalisé s’applique à l’environnement App Service. Cette fonctionnalité diffère d’une liaison de domaine personnalisée sur une instance App Service individuelle.

Si le certificat utilisé pour le suffixe de domaine personnalisé contient une entrée SAN (Subject Alternate Name) pour *.scm.CUSTOM-DOMAIN, le site Gestionnaire de contrôle de code source (SCM) devient accessible à partir de APP-NAME.scm.CUSTOM-DOMAIN. Vous pouvez uniquement accéder au SCM sur un domaine personnalisé à l’aide de l’authentification de base. L’authentification unique est disponible uniquement lorsque vous utilisez le domaine racine par défaut.

Tenez compte des facteurs suivants lorsque vous gérez des certificats sur un environnement App Service ILB :

• Stockez un certificat SSL ou TLS (Transport Layer Security) valide dans un coffre de clés Azure dans . Format PFX.

• Vérifiez que le certificat est inférieur à 20 Ko.

• Utilisez un certificat générique pour le nom de domaine personnalisé sélectionné.

• Configurez une identité managée affectée par le système ou affectée par l’utilisateur pour votre environnement App Service. L’identité managée s’authentifie auprès du coffre de clés Azure où réside le certificat SSL ou TLS.

• Attendez-vous à ce que l’environnement App Service applique les modifications de certificat dans un coffre de clés dans un délai de 24 heures après la rotation.

Accès réseau à Azure Key Vault

• Vous pouvez accéder au coffre de clés publiquement ou via un point de terminaison privé accessible à partir du sous-réseau où l’environnement App Service est déployé.

• Si vous utilisez l’accès public, vous pouvez sécuriser votre coffre de clés pour accepter uniquement le trafic à partir de l’adresse IP sortante de l’environnement App Service.

• L’environnement App Service utilise l’adresse IP sortante de la plateforme comme adresse source lorsqu’il accède au coffre de clés. Vous trouverez cette adresse IP dans la page Adresses IP du portail Azure.

Configuration DNS

Pour accéder à vos applications dans votre environnement App Service à l’aide de votre suffixe de domaine personnalisé, configurez votre propre serveur DNS ou configurez DNS dans une zone DNS privée Azure pour votre domaine personnalisé. Pour plus d’informations, consultez configuration DNS.

Sécuriser le nom d’hôte par défaut unique

La fonctionnalité de nom d’hôte par défaut unique sécurisée fournit une solution à long terme pour protéger vos ressources contre les entrées DNS et la prise de contrôle de sous-domaine. Si vous activez cette fonctionnalité pour vos ressources App Service, personne ne peut recréer des ressources qui ont le même nom d’hôte par défaut. Cette protection empêche les acteurs malveillants d’exploiter les entrées DNS qui s’étendent et de prendre le contrôle des sous-domaines. Pour plus d’informations, consultez Sécuriser les noms d’hôte par défaut uniques.

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework, un ensemble de principes directeurs que vous pouvez utiliser pour améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Well-Architected Framework.

Fiabilité

La fiabilité permet de s’assurer que votre application peut respecter les engagements que vous prenez à vos clients. Pour plus d’informations, consultez la liste de vérification de la révision de conception pour la fiabilité.

• Envisagez d’utiliser la mise à l’échelle géo-distribuée avec les environnements App Service pour une plus grande résilience et scalabilité.

• Passez en revue les modèles de conception classiques pour la résilience et implémentez-les, le cas échéant.

• Envisagez d’utiliser la géoréplication active pour le niveau de données et le stockage géoredondant pour les images et les files d’attente.

• Pour plus d’informations, consultez les ressources suivantes :

  • Modèles d’application web d’entreprise
  • Fiabilité dans l’environnement App Service
  • Configurer l’environnement App Service pour la redondance de zone

Disponibilité

• Envisagez d’appliquer les modèles de conception classiques pour la disponibilité lorsque vous créez votre application cloud.

• Passez en revue les considérations relatives à la disponibilité dans l’architecture de référence d’application web App Service appropriée.

• Pour obtenir d’autres considérations relatives à la disponibilité, consultez les guides de fiabilité par service.

Sécurité

La sécurité offre des garanties contre les attaques délibérées et l’utilisation abusive de vos données et systèmes précieux. Pour plus d’informations, consultez la liste de vérification de la révision de conception pour la sécurité.

• Passez en revue les considérations de sécurité dans l’architecture de référence d’application web App Service appropriée.

• Envisagez de suivre le processus de cycle de vie du développement de la sécurité pour aider les développeurs à créer des logiciels plus sécurisés et à répondre aux exigences de conformité de la sécurité tout en réduisant les coûts de développement.

• Utilisez azure DDoS Protection et les meilleures pratiques de conception des applications pour améliorer la protection contre les attaques par déni de service distribué (DDoS). Activez la protection DDoS sur les réseaux virtuels de périmètre.

Optimisation des coûts

L’optimisation des coûts se concentre sur les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez la liste de contrôle de révision de conception pour l’optimisation des coûts.

Explorez le coût d’exécution de ce scénario. Les exemples de profils de coût suivants sont basés sur le trafic attendu. Tous les services sont préconfigurés dans la calculatrice de coûts.

• Petit déploiement : cet exemple de tarification représente les composants d’une instance minimale au niveau de la production qui sert quelques milliers d’utilisateurs chaque mois. L’application utilise une seule petite instance d’une application web isolée. Chaque composant supplémentaire est mis à l’échelle vers un niveau De base pour réduire les coûts tout en garantissant la prise en charge du contrat de niveau de service (SLA) et une capacité suffisante pour gérer une charge de travail au niveau de la production.

• Déploiement moyen : cet exemple de tarification représente les composants d’un déploiement de taille modérée qui sert environ 100 000 utilisateurs chaque mois. Une instance App Service isolée à taille modérée gère le trafic. La capacité Application Gateway et SQL Database augmentent pour prendre en charge la charge de travail ajoutée.

• Déploiement volumineux : cet exemple de tarification représente les composants d’une application à grande échelle qui sert des millions d’utilisateurs chaque mois et déplace les téraoctets de données. Ce niveau d’utilisation nécessite des applications web de niveau isolé et hautes performances déployées dans plusieurs régions et frontales par Azure Traffic Manager. L’estimation inclut Traffic Manager et des instances De réseau virtuel et Application Gateway supplémentaires. La capacité de la base de données SQL augmente pour prendre en charge la charge de travail ajoutée.

Pour afficher la tarification de votre cas d’usage particulier, modifiez les variables appropriées pour qu’elles correspondent à votre trafic attendu.

Efficacité des performances

L’efficacité des performances fait référence à la capacité de votre charge de travail à mettre à l’échelle pour répondre efficacement aux demandes des utilisateurs. Pour plus d’informations, consultez la liste de vérification de la révision de conception pour l’efficacité des performances.

• Comprendre le fonctionnement de la mise à l’échelle dans les environnements App Service.

• Passez en revue les bonnes pratiques pour la mise à l’échelle automatique des applications cloud.

• Comprendre les modèles de conception classiques pour l’extensibilité lorsque vous créez une application cloud.

• Passez en revue les considérations relatives à l’extensibilité dans l’architecture de référence d’application web App Service appropriée.

Contributeurs

Microsoft gère cet article. Les contributeurs suivants ont écrit cet article.

Auteur principal :

• Nicholas McCollum | Ingénieur client principal

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

• Intégrer votre environnement App Service ILB à une passerelle d’application Azure
• Mise à l’échelle géo-distribuée avec des environnements App Service

Ressources associées

• Architecture de référence des applications web App Service
• Déploiement d’entreprise à haute disponibilité via un environnement App Service