Sécuriser les applications dans Microsoft Azure App Service avec NGINX Plus

Cedric Derue

L’essor du cloud computing — et en particulier des offres de plateforme en tant que service (PaaS) et de conteneur en tant que service (CaaS) — transforme la manière dont les entreprises déploient et exploitent leurs applications métier. L’un des principaux défis lors de la conception d’applications cloud consiste à choisir des services cloud entièrement gérés qui réduisent les coûts et les tâches opérationnelles chronophages sans compromettre la sécurité.

Cet article de blog vous explique comment héberger des applications sur Microsoft Azure App Service et les sécuriser avec NGINX Plus afin de les protéger contre les attaques provenant d’Internet.

Présentation rapide de Microsoft Azure App Service

Microsoft Azure App Service est une plateforme entièrement gérée, conçue pour les entreprises, qui permet aux organisations de déployer des applications web, des API et des applications mobiles dans Microsoft Azure sans avoir à gérer l’infrastructure sous-jacente, comme illustré à la figure 1. Azure App Service offre les principales fonctionnalités suivantes :

• Web Apps vous permet de déployer et d’exécuter des applications web dans différents langages et frameworks (ASP.NET, Node.js, Java, PHP et Python). Ce service permet également de gérer des applications web évolutives et fiables à l’aide d’Internet Information Services (IIS), grâce à des fonctionnalités complètes de gestion des applications (surveillance, basculement de l’environnement intermédiaire vers la production, suppression des applications déployées, etc.). Il fournit également un environnement d’exécution Docker permettant d’exécuter des applications web sous Linux dans des conteneurs.
• API Apps fournit les outils nécessaires au déploiement d’API REST prenant en charge le CORS (partage des ressources entre origines multiples). Azure API Apps peut être facilement sécurisé avec Azure Active Directory, l’authentification unique (SSO) via les réseaux sociaux ou OAuth, sans qu’aucune modification du code ne soit nécessaire.
• Mobile Apps permet de déployer rapidement des services back-end mobiles prenant en charge des fonctionnalités essentielles telles que l’authentification, les notifications push, la gestion des utilisateurs, le stockage cloud, etc.

Avec Azure App Service, Microsoft offre une solution complète et rapide pour exécuter des applications web dans le cloud. Les développeurs peuvent ainsi développer leurs applications localement à l’aide d’ASP.NET, Java, Node.js, PHP et Python, puis les déployer facilement sur Azure App Service avec Microsoft Visual Studio ou Azure CLI. Les équipes DevOps peuvent également tirer parti de la fonctionnalité de déploiement continu d’Azure App Service pour déployer rapidement et de manière fiable les versions de leurs applications dans plusieurs environnements.

Les applications sur Azure App Service peuvent accéder à d’autres ressources déployées sur Azure ou établir des connexions via des VPN aux ressources de l’entreprise sur site.

Comprendre les environnements Azure App Service

Par défaut, une application créée avec Azure App Service est directement exposée à Internet et associée à un sous-domaine de azurewebsites.net. Pour renforcer sa sécurité, vous pouvez protéger votre application à l’aide de la terminaison SSL ou de protocoles d’authentification et d’autorisation tels qu’OAuth2 ou OpenID Connect (OIDC). Toutefois, il n’est pas possible de personnaliser le réseau avec des règles de sécurité granulaires pour les flux entrants et sortants, ni d’appliquer un intergiciel tel qu’un pare-feu d’applications web (WAF) afin de prévenir les attaques malveillantes ou l’exploitation de vulnérabilités provenant d’Internet.

Si vous exécutez des applications sensibles dans Azure App Service et souhaitez les protéger, vous pouvez utiliser Azure App Service Environment (ASE). Un ASE est un environnement isolé déployé dans un réseau virtuel et dédié aux applications d’un seul client. Vous bénéficiez ainsi d’un meilleur contrôle sur le trafic réseau entrant et sortant de vos applications.

Avec les ASE, vous pouvez déployer des applications web, API, mobiles ou de fonctions dans un environnement plus sécurisé et à très grande échelle, comme illustré à la Figure 2.

Création d’un nouvel ASE v2

Il existe deux versions de l’ASE : ASE v1 et ASE v2. Dans cet article, nous nous intéressons à ASE v2.

Vous pouvez créer un nouvel ASE v2 manuellement à l’aide du portail Azure, ou automatiquement à l’aide d’Azure Resource Manager.

Lors de la création d’un nouvel ASE, vous devez choisir entre deux types de déploiement :

• Un ASE externe expose les applications hébergées dans l’ASE via une adresse IP publique.
• Un ASE ILB expose les applications hébergées dans l’ASE sur une adresse IP privée accessible uniquement au sein de votre réseau virtuel Azure. Le point de terminaison interne correspond à ce qu’Azure appelle un équilibreur de charge interne (ILB).

Dans l’exemple suivant, nous choisissons un ASE avec ILB afin d’empêcher tout accès depuis Internet. Ainsi, les applications déployées dans notre ASE sont uniquement accessibles depuis les machines virtuelles (VM) exécutées sur le même réseau. Les deux commandes suivantes utilisent Azure Resource Manager et Azure CLI pour provisionner un nouvel ASE v2 avec ILB :

$ azure config mode arm$ azure group deployment create my-resource-group my-deployment-name --template-uri https://raw.githubusercontent.com/azure/azure-quickstart-templates/master/201-web-app-asev2-ilb-create/azuredeploy.json

Sécurisation de l’accès aux applications dans un ASE accessible au public

Si, en revanche, vous souhaitez que votre application soit accessible depuis Internet, vous devez la protéger contre les acteurs malveillants qui pourraient tenter de dérober les informations sensibles qui y sont stockées.

Pour sécuriser les applications au niveau de la couche 7 dans un ASE, deux options principales s’offrent à vous :

• Azure Application Gateway
• NGINX Plus avec le module WAF NGINX ModSecurity module

(Vous pouvez le remplacer par un contrôleur de mise à disposition d’applications [ADC] personnalisé doté de fonctionnalités WAF, mais ce cas d’utilisation n’est pas abordé ici.)

Le choix de la solution dépend de vos contraintes de sécurité. D’un côté, Azure Application Gateway fournit une solution clé en main pour appliquer les politiques de sécurité, sans vous obliger à assurer la maintenance de l’infrastructure sous-jacente. De l’autre, le déploiement de NGINX Plus sur des machines virtuelles vous offre une pile puissante, ainsi qu’un contrôle et une flexibilité accrus pour ajuster précisément vos règles de sécurité.

Pour choisir entre Azure Application Gateway et NGINX Plus afin d’équilibrer la charge et de sécuriser les applications créées au sein d’un environnement ASE, il est nécessaire de bien comprendre les fonctionnalités offertes par chaque solution. Si Azure Application Gateway convient aux cas d’utilisation simples, il lui manque, pour les cas plus complexes, de nombreuses fonctionnalités incluses de série dans NGINX Plus.

Le tableau suivant compare la prise en charge des fonctionnalités d’équilibrage de charge et de sécurité dans Azure Application Gateway et NGINX Plus. Vous trouverez plus de détails sur les fonctionnalités de NGINX Plus sous le tableau.

Fonctionnalité Azure Application Gateway NGINX PlusCapacité d’atténuation Couche applicative (couche 7) Couche applicative (couche 7)Prise en charge de HTTP ✅ ✅Prise en charge de HTTP/2 ❌ ✅Prise en charge de WebSocket ❌ ✅Déchargement SSL ✅ ✅Capacités de routage Décision simple basée sur l’URL de la requête ou affinité de session basée sur les cookies Capacités de routage avancéesListes de contrôle d’accès basées sur les adresses IP ❌ (doivent être définies au niveau de l’application web dans Azure) ✅Points de terminaison Toute adresse IP interne Azure, adresse IP Internet publique, machine virtuelle Azure ou service cloud Azure Toute adresse IP interne Azure, adresse IP Internet publique, machine virtuelle Azure ou service cloud AzurePrise en charge du réseau virtuel Azure Applications accessibles depuis Internet et applications internes (réseau virtuel) Applications accessibles depuis Internet et applications internes (réseau virtuel)WAF ✅ ✅Attaques volumétriques Partielle PartielleAttaques de protocole Partielle PartielleAttaques au niveau de la couche applicative ✅ ✅Authentification HTTP Basic ❌ ✅Authentification JWT ❌ ✅Authentification unique OpenID Connect ❌ ✅

Comme vous pouvez le constater, NGINX Plus et Azure Application Gateway font tous deux office de contrôleurs de mise à disposition d’applications (ADC), avec des fonctionnalités d’équilibrage de charge de couche 7 et un pare-feu d’applications web (WAF), afin d’assurer une protection renforcée contre les vulnérabilités et les attaques web courantes.

NGINX Plus offre plusieurs fonctionnalités supplémentaires qui ne sont pas disponibles dans Azure Application Gateway :

• Réécriture et redirection d’URL – Avec NGINX Plus, vous pouvez réécrire l’URL d’une requête avant de la transmettre à un serveur backend. Vous pouvez ainsi modifier l’emplacement des fichiers ou les chemins des requêtes sans changer l’URL communiquée aux clients. Vous pouvez également rediriger les requêtes. Par exemple, vous pouvez rediriger toutes les requêtes HTTP vers un serveur HTTPS.
• Limites de connexions et de débit – Vous pouvez configurer plusieurs limites pour contrôler le trafic entrant et sortant de vos instances NGINX Plus. Il s’agit notamment de limites concernant le nombre de connexions entrantes, le débit des requêtes entrantes, les connexions aux nœuds backend et le débit de transmission des données de NGINX Plus vers les clients.
• Prise en charge de HTTP/2 et de WebSocket – NGINX Plus prend en charge HTTP/2 et WebSocket au niveau de la couche applicative (couche 7). Ce n’est pas le cas d’Azure Application Gateway ; en revanche, Azure Load Balancer les prend en charge au niveau de la couche réseau (couche 4), où fonctionnent TCP et UDP.

Pour renforcer la sécurité, vous pouvez déployer Azure DDoS Protection afin d’atténuer les menaces au niveau des couches 3 et 4, en complément des fonctionnalités d’atténuation des menaces de couche 7 fournies par Azure Application Gateway ou NGINX Plus.

Utiliser NGINX Plus avec Azure App Service pour sécuriser les applications

La figure 3 montre comment combiner NGINX Plus et Azure App Service afin de fournir un environnement sécurisé pour l’exécution d’applications métier en production. Cette stratégie de déploiement exploite les fonctionnalités d’équilibrage de charge et de WAF de NGINX Plus.

Le déploiement combine les composants suivants :

• Réseau virtuel Azure (VNet) – Représente un réseau virtuel dans le cloud Azure dédié à votre organisation. Il fournit une isolation logique qui permet aux ressources Azure de communiquer entre elles de manière sécurisée au sein d’un réseau virtuel. Ici, nous avons défini deux sous-réseaux : Internal pour les applications web qui ne sont pas directement exposées à Internet et Waf pour NGINX Plus et l’infrastructure sous-jacente.
• Azure App Service Environment – Cet exemple de déploiement utilise deux exemples d’applications web – Application web 1 et Application web 2 – pour montrer comment sécuriser et répartir la charge entre différentes applications web avec NGINX Plus. Dans NGINX Plus, vous distribuez les requêtes entre différentes applications web en configurant des blocs upstream distincts, et vous effectuez un routage du contenu basé sur l’URI à l’aide de blocs location. Voici la configuration NGINX Plus minimale permettant d’atteindre cet objectif (ici, toutes les requêtes sont envoyées au même groupe en amont) :

upstream backend {    server IP-address-of-your-ASE-ILB;
}

server {
    location / {
        proxy_set_header Host $host;
        proxy_pass http://backend;
    }
}

• NGINX Plus – Répartit la charge des connexions HTTP(S) entre plusieurs applications web. Le déploiement de NGINX Plus sur une machine virtuelle vous offre davantage de contrôle sur l’infrastructure que les autres services Azure. Par exemple, avec une machine virtuelle, vous pouvez choisir le système d’exploitation (Linux ou Windows) qui s’exécute au sein d’un réseau virtuel isolé. En effet, les machines virtuelles Azure sont disponibles pour toutes les distributions Linux prises en charge par NGINX Plus (à l’exception d’Amazon Linux, pour des raisons évidentes).
• Groupes identiques de machines virtuelles Azure – Les groupes identiques de machines virtuelles sont une ressource de calcul Azure qui permet de déployer et de gérer un ensemble de machines virtuelles identiques. Vous pouvez configurer la taille des machines virtuelles et les affecter au réseau virtuel approprié. Toutes les machines virtuelles exécutées au sein du groupe sont équilibrées par un équilibreur de charge Azure, qui assure la connectivité TCP entre les instances. Ici, chaque machine virtuelle du groupe repose sur l’image NGINX Plus disponible sur Azure Marketplace. Les groupes identiques de machines virtuelles sont conçus pour offrir une véritable mise à l’échelle automatique.

Azure prend également en charge les groupes de ressources afin de regrouper facilement et de manière logique les ressources Azure d’une application. L’utilisation d’un groupe de ressources n’a aucune incidence sur la conception et la topologie de l’infrastructure, c’est pourquoi nous ne les représentons pas ici.

Haute disponibilité et mise à l’échelle automatique de NGINX Plus avec les groupes de machines virtuelles identiques Azure

Un groupe de machines virtuelles identiques Azure vous offre la puissance de la virtualisation et la possibilité d’adapter la capacité à tout moment, sans avoir à acheter ni à assurer la maintenance du matériel physique nécessaire à cette mise à l’échelle. Toutefois, vous restez responsable de la maintenance des machines virtuelles, notamment de leur configuration, de l’application des correctifs et des mises à jour de sécurité, ainsi que de l’installation des logiciels qui s’y exécutent.

Dans l’architecture illustrée à la Figure 4, les instances NGINX Plus sont déployées en mode actif-actif pour assurer une haute disponibilité au sein d’un groupe de machines virtuelles identiques Azure. Une configuration actif-actif est particulièrement avantageuse, car toutes les machines virtuelles NGINX Plus peuvent traiter les requêtes entrantes acheminées par Azure Load Balancer, offrant ainsi une capacité à moindre coût.

Avec les groupes de machines virtuelles identiques Azure, vous pouvez également configurer facilement la mise à l’échelle automatique des instances NGINX Plus en fonction de l’utilisation moyenne du processeur. Dans ce cas, veillez à synchroniser les fichiers de configuration de NGINX Plus. Pour ce faire, vous pouvez utiliser la fonctionnalité de partage de configuration de NGINX Plus, comme décrit dans le Guide d’administration de NGINX Plus.

Résumé

En utilisant Azure App Service pour vos applications cloud et NGINX Plus en frontal de vos applications web, API et back-ends mobiles, vous pouvez répartir la charge et sécuriser ces applications à l’échelle mondiale. L’utilisation conjointe de NGINX Plus et d’Azure App Service vous permet de bénéficier d’une infrastructure avec répartition de charge complète et d’un niveau élevé de protection contre les exploitations de vulnérabilités et les attaques provenant du Web. Vous disposez ainsi d’une architecture robuste permettant d’exécuter en toute sécurité des applications critiques en production.

Ressources

Vue d’ensemble de Web Apps (Microsoft)
Présentation des environnements App Service (Microsoft)
Créer une passerelle d’application avec un pare-feu d’applications web à l’aide du portail Azure (Microsoft)
Comparer les fonctionnalités de NGINX Open Source et de NGINX Plus (NGINX)
Équilibrage de charge HTTP (NGINX)

Le coauteur invité Cedric Derue est architecte de solutions et Microsoft MVP chez Altran. Le coauteur invité Vincent Thavonekham est directeur régional Microsoft et Azure MVP chez VISEO.

À propos de l’auteur

Cedric Derue

Autres articles de Cedric Derue