Partage via

Sécurisation d’Azure Functions

  • Article

À de nombreux égards, la planification du développement, du déploiement et de l’exploitation sécurisés des fonctions serverless est très similaire à celle d’une application web ou hébergée sur le cloud. Azure App Service fournit l’infrastructure d’hébergement pour vos applications de fonction. Cet article décrit des stratégies de sécurité pour exécuter votre code de fonction, ainsi que la façon dont App Service peut vous aider à sécuriser vos fonctions.

Les composants de plateforme d’App Service, notamment les machines virtuelles Azure, le stockage, les connexions réseau, les frameworks web, les fonctionnalités de gestion et d’intégration, sont activement sécurisés et renforcés. App Service fait régulièrement l’objet de vérifications de conformité strictes pour garantir les points suivants :

  • Les ressources de votre application sont protégées des ressources Azure des autres clients.
  • Les instances de machine virtuelle et les logiciels de runtime sont régulièrement mis à jour pour que soient traitées les vulnérabilités récemment découvertes.
  • La communication de secrets (tels que des chaînes de connexion) entre votre application et d’autres ressources Azure (telles que SQL Database) reste dans Azure et ne franchit pas les limites du réseau. Les secrets sont toujours chiffrés quand ils sont stockés.
  • Toutes les communications via les fonctionnalités de connectivité d’App Service, telles que la connexion hybride, sont chiffrées.
  • Toutes les connexions avec les outils de gestion à distance, tels qu’Azure PowerShell, Azure CLI, les SDK Azure et les API REST, sont chiffrées.
  • La gestion continue des menaces protège l’infrastructure et la plateforme contre les programmes malveillants, le déni de service distribué (DDoS), les attaques de l’intercepteur (man-in-the-middle, MITM) et bien d’autres menaces.

Pour plus d’informations sur la sécurité de l’infrastructure et de la plateforme dans Azure, consultez Centre de confidentialité Azure.

Pour obtenir un ensemble de suggestions de sécurité qui suivent le benchmark de sécurité Microsoft Cloud, consultez la base de référence de sécurité pour Azure Functions.

Opération sécurisée

Cette section vous guide dans la configuration et l’exécution de votre application de fonction de manière aussi sécurisée que possible.

Defender pour le cloud

Defender pour le cloud s’intègre à votre application de fonction dans le portail. Il évalue rapidement et gratuitement les vulnérabilités potentielles de sécurité liées à la configuration. Les applications de fonction qui s’exécutent dans un plan dédié peuvent également utiliser les fonctionnalités de sécurité renforcée de Defender pour le cloud pour un coût supplémentaire. Pour en savoir plus, consultez Protéger vos applications Web et API Azure App Service.

Journal et surveillance

Pour détecter les attaques, une solution consiste à utiliser la supervision des activités et l’analytique des journaux d’activité. Functions s’intègre à Application Insights pour collecter des données de journal, de performances et d’erreur pour votre application de fonction. Application Insights détecte automatiquement les anomalies de performance et intègre de puissants outils d’analyse conçus pour aider à diagnostiquer les problèmes et à comprendre la manière dont vos fonctions sont utilisées. Pour en savoir plus, consultez Surveiller l’exécution des fonctions Azure.

Functions s’intègre également aux journaux d’activité d’Azure Monitor pour vous permettre de consolider les journaux des applications de fonction avec des événements système pour faciliter l’analyse. Vous pouvez utiliser les paramètres de diagnostic pour configurer l’exportation en continu des journaux d’activité et des métriques de la plateforme pour vos fonctions vers la destination de votre choix, par exemple un espace de travail Log Analytics. Pour en savoir plus, consultez Monitorage d’Azure Functions avec Azure Monitor Logs.

Pour automatiser la détection et la réponse aux menaces à l’échelle de l’entreprise, transmettez en continu vos journaux et événements dans un espace de travail Log Analytics. Vous pouvez ensuite connecter Microsoft Sentinel à cet espace de travail. Pour en savoir plus, consultez Présentation de Microsoft Sentinel.

Pour plus d’informations sur les recommandations de sécurité pour l’observabilité, consultez la Base de référence de sécurité Azure pour Azure Functions.

Points de terminaison HTTP sécurisés

Les points de terminaison HTTP exposés publiquement fournissent un vecteur d’attaque pour les acteurs malveillants. Lorsque vous sécurisez vos points de terminaison HTTP, vous devez utiliser une approche de sécurité en couches. Ces techniques peuvent être utilisées pour réduire la vulnérabilité des points de terminaison HTTP exposés publiquement, classées de la plus basique à la plus sécurisée et restrictive :

Exiger HTTPS

Par défaut, les clients peuvent se connecter à des applications web en utilisant aussi bien le protocole HTTP que le protocole HTTPS. Nous vous recommandons de rediriger le protocole HTTPS vers HTTPS, car HTTPS utilise le protocole SSL/TLS pour garantir une connexion sécurisée, à la fois chiffrée et authentifiée. Pour en savoir plus, consultez Enforce HTTPS (Renforcer HTTPS).

Lorsque vous avez besoin d’un protocole HTTPS, vous devez également disposer de la dernière version du protocole TLS. Pour en savoir plus, consultez Enforce TLS versions (Renforcer les versions TLS).

Pour plus d’informations, consultez Connexions sécurisées (TLS).

Clé d’accès aux fonctions

Functions vous permet d’utiliser des clés pour rendre plus difficile l’accès à vos points de terminaison de fonction. Si le niveau d’accès HTTP sur une fonction déclenchée par HTTP n’est pas défini sur anonymous, les requêtes doivent contenir une clé d’accès. Pour plus d’informations, consultez Utiliser des clés d’accès dans Azure Functions.

Alors que les clés d’accès peuvent offrir une certaine atténuation des risques d’accès indésirable, la seule façon de sécuriser véritablement vos points de terminaison de fonction consiste à implémenter l’authentification positive des clients accédant à vos fonctions. Vous pouvez ensuite prendre des décisions d’autorisation basées sur l’identité.

Pour le niveau de sécurité le plus élevé, vous pouvez également sécuriser toute l’architecture de l’application à l’intérieur d’un réseau virtuel à l’aide de points de terminaison privés ou à l’aide d’une exécution en isolation..

Désactiver les points de terminaison d’administration

Les applications de fonction peuvent servir des points de terminaison administratifs sous l’itinéraire /admin qui peuvent être utilisés pour les opérations telles que l’obtention d’informations d’état de l’hôte et l’exécution d’appels de test. Lorsqu’elles sont exposées, les demandes adressées à ces points de terminaison doivent inclure la clé principale de l’application. Les opérations d’administration sont également disponibles via l’API Microsoft.Web/sites Azure Resource Manager, qui offre le contrôle d’accès en fonction du rôle (RBAC) Azure. Vous pouvez désactiver les points de terminaison /admin en définissant la propriété de site functionsRuntimeAdminIsolationEnabled sur true. Cette propriété ne peut pas être définie pour les applications s’exécutant sur la référence SKU Consommation Linux et elle ne peut pas être définie pour les applications s’exécutant sur la version 1.x d’Azure Functions. Si vous utilisez la version 1.x, vous devez d’abord migrer vers la version 4.x.

Activer l’authentification/autorisation App Service

La plateforme App Service vous permet d’utiliser Microsoft Entra ID et plusieurs fournisseurs d’identité tiers pour authentifier les clients. Vous pouvez utiliser cette stratégie afin d'implémenter des règles d'autorisation personnalisées pour vos fonctions, et vous pouvez utiliser les informations utilisateur dans le code de votre fonction. Pour plus d’informations, consultez Authentification et autorisation dans Azure App Service et Utilisation des identités de clients.

Utiliser la Gestion des API Azure (APIM) pour authentifier les requêtes

La Gestion des API offre une variété d’options de sécurité des API pour les requêtes entrantes. Pour plus d’informations, consultez Stratégies d’authentification dans Gestion des API. Avec Gestion des API Azure en place, vous pouvez configurer votre application de fonction pour qu’elle accepte seulement les requêtes provenant de l’adresse IP de votre instance Gestion des API Azure. Pour plus d’informations, consultez Restriction des adresses IP.

autorisations

Comme pour n’importe quelle application ou n’importe quel service, l’objectif est d’exécuter votre application de fonction avec les autorisations les plus basses possibles.

Autorisations de gestion des utilisateurs

Functions prend en charge le contrôle d’accès en fonction du rôle Azure (RBAC Azure). Les rôles Azure pris en charge par Functions sont Contributeur, Propriétaire et Lecteur.

Les autorisations sont effectives au niveau de l’application de fonction. Le rôle de Contributeur est requis pour effectuer la plupart des tâches au niveau application de fonction. Vous avez également besoin du rôle Contributeur avec l’autorisation Lecteur de surveillance pour pouvoir visualiser les données du journal dans Application Insights. Seul le rôle de Propriétaire peut supprimer une application de fonction.

Organiser les fonctions par privilège

Les chaînes de connexion et d’autres informations d’identification stockées dans les paramètres d’application donnent à toutes les fonctions de l’application de fonction le même ensemble d’autorisations dans la ressource associée. Envisagez de réduire le nombre de fonctions ayant accès à des informations d’identification spécifiques en déplaçant des fonctions qui n’utilisent pas lesdites informations d’identification vers une application de fonction distincte. Vous pouvez toujours utiliser des techniques telles que le chaînage de fonctions pour passer des données entre des fonctions dans différentes applications de fonction.

Identités managées

Une identité managée de Microsoft Entra ID permet à votre application d’accéder facilement à d’autres ressources protégées Microsoft Entra, comme Azure Key Vault. Managée par la plateforme Azure, l’identité ne nécessite pas que vous approvisionniez ou permutiez de secrets. Pour plus d’informations sur les identités managées dans Microsoft Entra ID, consultez Identités managées pour les ressources Azure.

Deux types d’identité peuvent être accordés à votre application :

  • Une identité affectée par le système est liée à l’application et est supprimée si l’application est supprimée. Une application ne peut avoir qu’une seule identité attribuée par le système.
  • Une identité attribuée par l’utilisateur est une ressource Azure autonome qui peut être assignée à votre application. Une application peut avoir plusieurs identités affectées par l’utilisateur et une identité affectée par l’utilisateur peut être affectée à plusieurs ressources Azure, telles que deux applications App Service.

Les identités managées peuvent être utilisées à la place des secrets pour les connexions à partir de certains déclencheurs et de certaines liaisons. Consultez Connexions basées sur l’identité.

Pour plus d’informations, consultez Guide pratique pour utiliser des identités managées avec App Service et Azure Functions.

Restreindre l’accès CORS

Le Cross-origin ressource sharing (CORS) est un moyen d’autoriser l’exécution des applications web dans un autre domaine pour effectuer des demandes à vos points de terminaison de déclencheur HTTP. App Service fournit une prise en charge intégrée pour la gestion des en-têtes CORS requis dans les requêtes HTTP. Les règles CORS sont définies au niveau d’une application de fonction.

Bien qu’il soit tentant d’utiliser un caractère générique qui permette à tous les sites d’accéder à votre point de terminaison, cela élimine l’objectif de CORS, qui est d’empêcher les attaques par scripting inter-site. Ajoutez plutôt une entrée CORS distincte pour le domaine de chaque application web qui doit accéder à votre point de terminaison.

Gestion des secrets

Pour pouvoir se connecter aux différents services et ressources qui doivent exécuter votre code, les applications de fonction doivent être en mesure d’accéder aux secrets, tels que les chaînes de connexion et les clés de service. Cette section décrit comment stocker les secrets requis par vos fonctions.

Ne stockez jamais de secrets dans votre code de fonction.

Paramètres de l’application

Par défaut, vous stockez les chaînes de connexion et les secrets utilisés par votre application de fonction et les liaisons en tant que paramètres d’application. Ces informations d’identification sont alors disponibles pour votre code de fonction et les différentes liaisons utilisées par la fonction. Le nom du paramètre d’application (clé) est utilisé pour récupérer la valeur réelle, qui est le secret.

Par exemple, chaque application de fonction nécessite un compte de stockage associé, qui est utilisé par le runtime. Par défaut, la connexion à ce compte de stockage est stockée dans un paramètre d’application nommé AzureWebJobsStorage.

Les paramètres de l’application et les chaînes de connexion sont stockés dans Azure. Ils sont déchiffrés uniquement avant d’être injectés dans la mémoire de processus de votre application au démarrage de celle-ci. Les clés de chiffrement sont régulièrement permutées. Si vous préférez gérer le stockage sécurisé de vos secrets, le paramètre d’application doit plutôt faire référence aux secrets Azure Key Vault.

Vous pouvez également chiffrer les paramètres par défaut dans le fichier local.settings.json lors du développement de fonctions sur votre ordinateur local. Pour plus d’informations, consultez la section Chiffrer le fichier de paramètres locaux.

Références Key Vault

Même si les paramètres d’application sont suffisants pour la plupart des fonctions, vous pouvez souhaiter partager les mêmes secrets entre plusieurs services. Dans ce cas, le stockage redondant des secrets entraîne plus de vulnérabilités potentielles. Une approche plus sécurisée consiste à utiliser un service de stockage secret central et à utiliser des références à ce service au lieu des secrets eux-mêmes.

Azure Key Vault est un service qui fournit une gestion centralisée des secrets, avec un contrôle total sur les stratégies d’accès et l’historique d’audit. Vous pouvez utiliser une référence Key Vault à place d’une chaîne de connexion ou d’une clé dans vos paramètre d’application. Pour en savoir plus, consultez Utiliser des références Key Vault pour App Service et Azure Functions.

Connexions basées sur l’identité

Les identités peuvent être utilisées à la place de secrets pour la connexion à certaines ressources. Cela présente l’avantage de ne pas nécessiter la gestion d’un secret et fournit un contrôle d’accès et un audit plus précis.

Quand vous écrivez du code qui crée la connexion aux services Azure prenant en charge l’authentification Microsoft Entra, vous pouvez choisir d’utiliser une identité au lieu d’un secret ou d’une chaîne de connexion. Pour plus d’informations sur les deux méthodes de connexion, reportez-vous à la documentation de chaque service.

Certaines extensions de liaison Azure Functions peuvent être configurées afin d’accéder aux services à l’aide de connexions basées sur l’identité. Pour plus d’informations, consultez Configurer une connexion basée sur l’identité.

Configurer un quota d’utilisation

Envisagez de paramétrer un quota d’utilisation sur l’exécution des fonctions dans un plan de consommation. Lorsque vous définissez une limite quotidienne de Go-s sur la somme de l’exécution totale des fonctions dans votre application de fonction, l’exécution est arrêtée lorsque la limite est atteinte. Cela peut permettre de réduire le code malveillant qui exécute vos fonctions. Pour savoir comment estimer la consommation de vos fonctions, consultez Estimation des coûts d’un plan de consommation.

Validation des données

Les déclencheurs et les liaisons utilisés par vos fonctions ne fournissent aucune validation de données supplémentaire. Votre code doit valider toutes les données reçues à partir d’un déclencheur ou d’une liaison d’entrée. Si un service en amont est compromis, vous ne voulez pas que les entrées non validées circulent dans vos fonctions. Par exemple, si votre fonction stocke des données à partir d’une file d’attente de stockage Azure dans une base de données relationnelle, vous devez valider les données et paramétrer vos commandes pour éviter les attaques par injection de code SQL.

Ne partez pas du principe que les données entrant dans votre fonction ont déjà été validées ou assainies. Il est également judicieux de vérifier que les données écrites dans les liaisons de sortie sont valides.

des erreurs

Bien qu’il semble basique, il est important d’écrire une bonne gestion des erreurs dans vos fonctions. Les erreurs non gérées se propagent à l’hôte et sont gérées par le runtime. Les liaisons différentes gèrent le traitement des erreurs différemment. Pour plus d’informations, consultez Conseils de gestion des erreurs Azure Functions.

Désactiver le débogage à distance

Assurez-vous que le débogage à distance est désactivé, sauf lorsque vous déboguez activement vos fonctions. Vous pouvez désactiver le débogage à distance sous l’onglet Paramètres généraux de la Configuration de votre application de fonction dans le portail.

Restreindre l’accès CORS

Azure Functions prend en charge le partage des ressources cross-origin (CORS). CORS est configuré dans le portail et par le biais d’Azure CLI. La liste des origines autorisées CORS s’applique au niveau de l’application de fonction. Quand CORS est activé, les réponses incluent l’en-tête Access-Control-Allow-Origin. Pour plus d'informations, consultez la page Partage des ressources cross-origin.

N’utilisez pas de caractères génériques dans votre liste d’origines autorisées. Répertoriez plutôt les domaines spécifiques à partir desquels vous souhaitez obtenir des requêtes.

Stocker les données chiffrées

Le stockage Azure chiffre toutes les données dans un compte de stockage au repos. Pour plus d'informations, consultez Fonctionnalité de chiffrement du service Stockage Azure pour les données au repos.

Par défaut, les données sont chiffrées avec des clés managées par Microsoft Pour plus de contrôle sur les clés de chiffrement, vous pouvez fournir des clés gérées par le client à utiliser pour le chiffrement des données de fichiers et d’objets blob. Ces clés doivent être présentes dans Azure Key Vault pour que Functions puisse accéder au compte de stockage. Pour en savoir plus, consultez Chiffrement au repos à l’aide de clés gérées par le client.

Une application de fonction dépend souvent de ressources supplémentaires. La sécurisation de l’application passe donc en partie par la sécurisation de ces ressources externes. Au minimum, la plupart des applications de fonction incluent une dépendance à Application Insights et Stockage Azure. Consultez la base de référence de sécurité Azure pour Azure Monitor et la base de référence de sécurité Azure pour Stockage pour obtenir une aide concernant la sécurisation de ces ressources.

Important

Le compte de stockage permet de stocker les données importantes de l’application, dont parfois le code proprement dit de l’application. Vous devez limiter l’accès des autres applications et utilisateurs au compte de stockage.

Vous avez également tout intérêt à consulter l’aide relative aux types de ressources dont dépend la logique de votre application, à la fois en tant que déclencheurs et liaisons, et à partir du code de votre fonction.

Déploiement sécurisé

Azure Functions, outil d’intégration, facilite la publication de code de projet de fonction locale dans Azure. Il est important de comprendre le fonctionnement du déploiement lors de la prise en compte de la sécurité d’une topologie d’Azure Functions.

Informations d’identification de déploiement

Les déploiements d’App Service nécessitent un ensemble d’informations d’identification de déploiement. Ces informations d’identification de déploiement sont utilisées pour sécuriser vos déploiements d’application de fonction. Les informations d’identification de déploiement sont gérées par la plateforme App Service et sont chiffrées au repos.

Il existe deux types d’informations d'identification de déploiement :

  • Informations d’identification au niveau de l’utilisateur : un seul ensemble d’informations d’identification pour l’intégralité du compte Azure. Il peut être utilisé pour déployer sur App Service pour n’importe quelle application et dans n’importe quel abonnement auxquels le compte Azure est autorisé à accéder. C’est l’ensemble par défaut qui est présenté dans l’interface utilisateur graphique du portail, comme la vue d’ensemble et les propriétés de la page Ressources de l’application. Lorsqu'un utilisateur est autorisé à accéder à l’application via le contrôle d’accès en fonction du rôle (RBAC) ou des autorisations de coadmin, il peut se servir de ses propres informations d’identification tant que l’accès n’est pas révoqué. Ne partagez pas ces informations d’identification avec d’autres utilisateurs d’Azure.

  • Informations d’identification au niveau de l’application : un seul ensemble d’informations d’identification pour chaque application. Celui-ci peut être utilisé pour déployer sur cette application uniquement. Les informations d’identification de chaque application sont générées automatiquement à la création de l’application. Elles ne peuvent pas être configurées manuellement, mais peuvent être réinitialisées à tout moment. Pour qu’un utilisateur puisse accéder aux informations d’identification de niveau application via RBAC, il doit avoir un rôle de contributeur ou supérieur sur l’application (y compris le rôle intégré de contributeur de site web). Les lecteurs ne sont pas autorisés à publier et n’ont pas accès à ces informations d’identification.

À ce stade, Key Vault n’est pas pris en charge pour les informations d’identification de déploiement. Pour plus d’informations sur la façon de configurer les informations d’identification de déploiement, consultez Configurer les informations d’identification de déploiement pour Azure App Service.

Désactiver le protocole FTP

Par défaut, un point de terminaison FTP est activé pour chaque application de fonction. Le point de terminaison FTP est accessible à l’aide des informations d’identification de déploiement.

Le protocole FTP n’est pas recommandé pour le déploiement de votre code de fonction. Les déploiements FTP sont manuels et nécessitent la synchronisation des déclencheurs. Pour plus d’informations, consultez Déploiement FTP.

Si vous n’avez pas l’intention d’utiliser le protocole FTP, vous devez le désactiver dans le portail. Si vous choisissez d’utiliser le protocole FTP, vous devez renforcer les protocoles FTPS.

Sécuriser le point de terminaison scm

Chaque application de fonction a un point de terminaison de service scm correspondant qui est utilisé par le service d’Outils avancés (Kudu) pour les déploiements et d’autres extensions de site d’App Service. Le point de terminaison scm SCM pour une application de fonction est toujours sous la forme d’une URL https://<FUNCTION_APP_NAME>.scm.azurewebsites.net. Lorsque vous utilisez l’isolement réseau pour sécuriser vos fonctions, vous devez également tenir compte de ce point de terminaison.

En ayant un point de terminaison scm distinct, vous pouvez contrôler les déploiements et d’autres fonctionnalités d’outils avancés pour des applications de fonction qui sont isolées ou en cours d’exécution dans un réseau virtuel. Le point de terminaison scm prend en charge l’authentification de base (à l’aide des informations d’identification de déploiement) et l’authentification unique avec vos informations d’identification du portail Azure. Pour plus d’informations, consultez Accessing the Kudu service (Accès au service Kudu).

Valide continue de la sécurité

Comme la sécurité doit être prise en considération à chaque étape du processus de développement, il est logique de mettre également en œuvre des validations de sécurité dans un environnement de déploiement continu. Cette procédure est parfois appelée DevSecOps. L’utilisation d’Azure DevOps pour votre pipeline de déploiement vous permet d’intégrer la validation dans le processus de déploiement. Pour plus d’informations, consultez Learn how to add continuous security validation to your CI/CD pipeline (Guide pratique pour ajouter une validation de sécurité continue à votre pipeline CI/CD).

Sécurité du réseau

La restriction de l’accès réseau à votre application de fonction vous permet de contrôler qui peut accéder à vos points de terminaison Functions. Functions tire parti de l’infrastructure App Service pour permettre à vos fonctions d’accéder aux ressources sans utiliser d’adresses de routage par Internet ou de restreindre l’accès à Internet à un point de terminaison de fonction. Pour en savoir plus sur les options de mise en réseau, consultez Options de mise en réseau d’Azure Functions.

Définir les restrictions d’accès

Les restrictions d’accès vous permettent de définir des listes de règles d’autorisation/de refus pour contrôler le trafic vers votre application. Les règles sont évaluées par ordre de priorité. Si aucune règle n’est définie, votre application accepte le trafic à partir d’une adresse quelconque. Pour en apprendre davantage, consultez Restrictions d’accès dans Azure App Service.

Sécuriser le compte de stockage

Quand vous créez une application de fonction, vous devez créer un compte de stockage Azure à usage général qui prend en charge le stockage Blob, File d’attente et Table, ou établir un lien vers un compte de ce type. Vous pouvez remplacer ce compte de stockage par un compte sécurisé grâce à un réseau virtuel avec un accès activé par des points de terminaison de service ou privés. Pour plus d’informations, consultez Restreindre votre compte de stockage à un réseau virtuel.

Déployer votre application de fonction sur un réseau virtuel

Le point de terminaison privé Azure est une interface réseau qui vous connecte de manière privée et sécurisée à un service s’appuyant sur Azure Private Link. Le point de terminaison privé utilise une adresse IP privée de votre réseau virtuel pour apporter le service à votre réseau virtuel de façon effective.

Vous pouvez utiliser un point de terminaison privé pour vos fonctions hébergées dans les plans Premium et App Service.

Si vous souhaitez effectuer des appels vers des points de terminaison privés, vous devez vous assurer que vos recherches DNS seront résolues sur le point de terminaison privé. Vous pouvez appliquer ce comportement de l’une des façons suivantes :

  • Intégrer à des zones privées Azure DNS Lorsque votre réseau virtuel n’a pas de serveur DNS personnalisé, cette opération est effectuée automatiquement.
  • Gérer le point de terminaison privé dans le serveur DNS utilisé par votre application. Pour ce faire, vous devez connaître l’adresse du point de terminaison privé, puis pointer le point de terminaison que vous essayez d’atteindre vers cette adresse à l’aide d’un enregistrement A.
  • Configurez votre propre serveur DNS pour le transfert vers des zones privées Azure DNS.

Pour plus d’informations, consultez Utilisation de points de terminaison privés pour Web Apps.

Déployer votre application de fonction en isolement

Azure App Service Environment fournit un environnement d’hébergement dédié où exécuter vos fonctions. Ces environnements vous permettent de configurer une passerelle front-end unique que vous pouvez utiliser pour authentifier toutes les requêtes entrantes. Pour plus d’informations, consultez Configuration d’un pare-feu d’applications Web (WAF) pour un environnement App Service.

Utiliser un service de passerelle

Les services de passerelle, tels que Azure Application Gateway et Azure Front Door vous permettent de configurer un pare-feu d’applications Web (WAF). Les règles WAF sont utilisées pour surveiller ou bloquer les attaques détectées, ce qui permet d’avoir une couche supplémentaire de protection pour vos fonctions. Pour configurer un WAF, votre application de fonction doit être exécutée dans un ASE ou à l’aide de points de terminaison privés (préversion). Pour plus d’informations, consultez Utiliser des points de terminaison privés.

Étapes suivantes