Sécurisation des applications dans Microsoft Azure App Service avec NGINX Plus

L’essor du cloud computing – et en particulier des offres de plate-forme en tant que service (PaaS) et de conteneur en tant que service (CaaS) – modifie la manière dont les entreprises déploient et exploitent leurs applications métier. L’un des défis les plus importants lors de la conception d’applications cloud est de 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 montre comment héberger des applications sur Microsoft Azure App Service et les sécuriser avec NGINX Plus pour empêcher les attaques provenant d’Internet.

Bref aperçu de Microsoft Azure App Service

Microsoft Azure App Service est une plateforme de niveau entreprise entièrement gérée qui permet aux organisations de déployer des applications Web, API et mobiles dans Microsoft Azure sans gérer l’infrastructure sous-jacente, comme illustré dans la figure 1. Azure App Service fournit 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). Il gère également des applications Web évolutives et fiables à l'aide d'Internet Information Services (IIS) avec des capacités complètes de gestion des applications (surveillance, passage de la phase de préparation à la production, suppression des applications déployées, etc.). Il fournit également un environnement d'exécution Docker pour exécuter des applications Web sur Linux avec des conteneurs.
• API Apps apporte les outils permettant de déployer des API REST avec prise en charge CORS (Cross-Origin Resource Sharing). Les applications API Azure peuvent être facilement sécurisées avec Azure Active Directory, l’authentification unique (SSO) du réseau social ou OAuth, sans qu’aucune modification de code ne soit requise.
• Les applications mobiles offrent un moyen rapide de déployer des services back-end mobiles qui prennent 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 propose un moyen riche et rapide d’exécuter des applications Web sur le cloud. En effet, les développeurs peuvent développer leurs applications localement en utilisant ASP.NET, Java, Node.js, PHP et Python et les déployer facilement sur Azure App Service avec Microsoft Visual Studio ou Azure CLI. Les équipes DevOps peuvent également bénéficier de la fonctionnalité de déploiement continu d’Azure App Service pour déployer les versions d’applications rapidement et de manière fiable sur plusieurs environnements.

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

Comprendre les environnements Azure App Service

Fondamentalement, une application créée avec Azure App Service est exposée directement à Internet et attribuée à un sous-domaine de azurewebsites.net . Pour plus de sécurité, vous pouvez protéger votre application avec une terminaison SSL ou avec des protocoles d'authentification et d'autorisation tels que OAuth2 ou OpenID Connect (OIDC). Cependant, il n’est pas possible de personnaliser le réseau avec des règles de sécurité entrantes et sortantes précises ou d’appliquer un middleware tel qu’un pare-feu d’application Web (WAF) pour empêcher les attaques malveillantes ou les exploits provenant d’Internet.

Si vous exécutez des applications sensibles dans Azure App Service et souhaitez les protéger, vous pouvez utiliser les environnements Azure App Service (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 des applications.

Avec les ASE, vous pouvez déployer des applications Web, API, mobiles ou fonctionnelles dans un environnement plus sécurisé à très grande échelle, comme illustré dans la figure 2.

Créer un nouvel ASE v2

Il existe deux versions de l'ASE : ASE v1 et ASE v2. Dans cet article, nous discutons d’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 par l’ASE via une adresse IP publique.
• Un ASE ILB expose les applications hébergées par l’ASE sur une adresse IP privée accessible uniquement à l’intérieur de votre réseau virtuel Azure. Le point de terminaison interne est ce qu’Azure appelle un équilibreur de charge interne (ILB).

Dans l'exemple suivant, nous choisissons un ASE ILB pour empêcher l'accès depuis Internet. Ainsi, les applications déployées dans notre ASE ne sont accessibles qu’à partir de 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 ILB ASE v2 :

$ azure config mode arm $ azure group deployment create mon-groupe-de-ressources mon-nom-de-déploiement --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 environnement ASE accessible au public

Si, en revanche, vous souhaitez que votre application soit accessible depuis Internet, vous devez la protéger contre les attaquants malveillants qui pourraient tenter de voler des informations sensibles stockées dans votre application.

Pour sécuriser les applications au niveau de la couche 7 dans un ASE, vous avez deux choix principaux :

• Passerelle d'application Azure
• NGINX Plus avec le module WAF NGINX ModSecurity

(Vous pouvez remplacer un contrôleur de distribution d’applications [ADC] personnalisé par des fonctionnalités WAF, mais nous ne couvrons pas ce cas d’utilisation ici.)

Le choix de la solution dépend de vos contraintes de sécurité. D’une part, Azure Application Gateway fournit une solution clé en main pour l’application de la sécurité et ne nécessite pas de maintenance de l’infrastructure sous-jacente. D’autre part, le déploiement de NGINX Plus sur des machines virtuelles vous offre une pile puissante avec plus de contrôle et de flexibilité pour affiner vos règles de sécurité.

Choisir entre Azure Application Gateway et NGINX Plus pour équilibrer la charge et sécuriser les applications créées dans un ASE nécessite une bonne compréhension des fonctionnalités fournies par chaque solution. Bien qu’Azure Application Gateway fonctionne pour les cas d’utilisation simples, pour les cas d’utilisation complexes, il ne fournit pas de nombreuses fonctionnalités fournies en standard 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. Plus de détails sur les fonctionnalités de NGINX Plus apparaissent sous le tableau.

Comme vous pouvez le constater, NGINX Plus et Azure Application Gateway agissent tous deux comme des ADC avec des fonctionnalités d’équilibrage de charge de couche 7 ainsi qu’un WAF pour garantir une protection renforcée contre les vulnérabilités et les exploits Web courants.

NGINX Plus fournit plusieurs fonctionnalités supplémentaires manquantes 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. Cela signifie que vous pouvez modifier l'emplacement des fichiers ou demander des chemins sans modifier l'URL annoncée aux clients. Vous pouvez également rediriger les demandes. Par exemple, vous pouvez rediriger toutes les requêtes HTTP vers un serveur HTTPS.
• Limites de connexion et de débit – Vous pouvez configurer plusieurs limites pour contrôler le trafic vers et depuis vos instances NGINX Plus. Il s'agit notamment de limites sur le nombre de connexions entrantes, le taux de requêtes entrantes, les connexions aux nœuds back-end et le taux de transmission de données de NGINX Plus aux clients.
• Prise en charge HTTP/2 et WebSocket – NGINX Plus prend en charge HTTP/2 et WebSocket au niveau de la couche application (couche 7). Azure Application Gateway ne le fait pas ; à la place, Azure Load Balancer les prend en charge au niveau de la couche réseau (couche 4), où fonctionnent TCP et UDP.

Pour plus de sécurité, vous pouvez déployer Azure DDoS Protection pour 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.

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

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

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 en toute sécurité entre elles dans un réseau virtuel. Ici, nous avons défini deux sous-réseaux : Interne pour les applications Web qui ne sont pas exposées directement à Internet et Waf pour NGINX Plus et l'infrastructure qui le sous-tend.

• Environnement Azure App Service – Cet exemple de déploiement utilise deux exemples d’applications Web – Web App 1 et Web App 2 – pour montrer comment sécuriser et équilibrer la charge de différentes applications Web avec NGINX Plus. Dans NGINX Plus, vous distribuez les requêtes à différentes applications Web en configurant des blocs en amont distincts et effectuez le routage du contenu en fonction de l'URI avec des blocs d'emplacement . Ce qui suit montre la configuration minimale de NGINX Plus qui répond à cet objectif (ici, toutes les requêtes vont au même groupe en amont) :

  backend en amont { serveur adresse-IP-de-votre-ASE-ILB ; } serveur { emplacement / { proxy_set_header Hôte $host; proxy_pass http://backend; } }
  

• NGINX Plus – Équilibre la charge des connexions HTTP(S) sur plusieurs applications Web. Le déploiement de NGINX Plus dans une machine virtuelle vous donne plus de contrôle sur l’infrastructure que les autres services Azure. Par exemple, avec une VM, vous pouvez choisir le système d’exploitation (Linux ou Windows) qui s’exécute à l’intérieur 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).
• Ensembles de machines virtuelles identiques Azure : les ensembles de machines virtuelles identiques sont une ressource de calcul Azure que vous pouvez utiliser pour déployer et gérer un ensemble de machines virtuelles identiques. Vous pouvez configurer la taille de la machine virtuelle et l’affecter au réseau virtuel approprié. Toutes les machines virtuelles exécutées dans le groupe de mise à l’échelle sont équilibrées par un équilibreur de charge Azure qui fournit une connectivité TCP entre les instances de machine virtuelle. Ici, chaque machine virtuelle du groupe de mise à l’échelle est basée sur l’image NGINX Plus disponible sur Azure Marketplace. Les ensembles d'échelle sont conçus pour fournir une véritable mise à l'échelle automatique.

Azure prend également en charge les groupes de ressources comme moyen simple de regrouper les ressources Azure d’une application de manière logique. L’utilisation d’un groupe de ressources n’a aucun impact sur la conception et la topologie de l’infrastructure, et nous ne les montrons pas ici.

Haute disponibilité et mise à l'échelle automatique de NGINX Plus avec les ensembles de machines virtuelles Azure

Un ensemble de machines virtuelles Azure vous offre la puissance de la virtualisation avec la possibilité d’évoluer à tout moment sans avoir à acheter et à entretenir le matériel physique qui prend en charge la mise à l’échelle. Cependant, vous êtes toujours responsable de la maintenance de la machine virtuelle en effectuant des tâches telles que la configuration, la mise à jour des correctifs, la mise à jour de sécurité et l'installation des logiciels qui s'exécutent dessus.

Dans l’architecture illustrée dans la Figure 4, les instances NGINX Plus sont déployées pour une haute disponibilité active-active au sein d’un groupe de machines virtuelles Azure. Une configuration active-active est idéale, car toutes les machines virtuelles NGINX Plus peuvent gérer une demande entrante acheminée par Azure Load Balancer, vous offrant ainsi une capacité rentable.

Avec les ensembles de machines virtuelles Azure, vous pouvez également configurer facilement la mise à l’échelle automatique des instances NGINX Plus en fonction de l’utilisation moyenne du processeur. Vous devez prendre soin de synchroniser les fichiers de configuration NGINX Plus dans ce cas. Vous pouvez utiliser la fonctionnalité de partage de configuration NGINX Plus à cette fin, comme décrit dans le Guide d'administration NGINX Plus .

Résumé

En utilisant Azure App Service pour vos applications cloud et NGINX Plus devant vos applications Web, API et back-ends mobiles, vous pouvez équilibrer la charge et sécuriser ces applications à l’échelle mondiale. En utilisant NGINX Plus conjointement avec Azure App Service, vous obtenez une infrastructure entièrement équilibrée avec un niveau de protection élevé contre les exploits et les attaques du Web. Cela garantit une conception robuste pour exécuter des applications critiques en production de manière sécurisée.

Ressources

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

Cédric Derue, co-auteur invité, est architecte de solutions et Microsoft MVP chez Altran. Vincent Thavonekham, co-auteur invité, est directeur régional Microsoft et Azure MVP chez VISEO.