Partage via

Sécurisation d’Azure Functions

À 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’Azure App Service, y compris les machines virtuelles Azure, le stockage, les connexions réseau, les infrastructures web et 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 :

  • Vos ressources d’application sont sécurisées à partir des ressources Azure d’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 des secrets (par exemple, les chaînes de connexion) entre votre application et d’autres ressources Azure (telles qu’Azure SQL Database) reste dans Azure et ne dépasse 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.
  • Les connexions avec des outils de gestion à distance tels qu’Azure PowerShell, Azure CLI, les SDK Azure et les API REST sont toutes chiffrées.
  • La gestion des menaces de 24 heures protège l’infrastructure et la plateforme contre les programmes malveillants, le déni de service distribué (DDoS), les attaques man-in-the-middle et d’autres menaces.

Pour plus d’informations sur la sécurité de l’infrastructure et de la plateforme dans Azure, consultez le Centre de gestion de la 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 plus d’informations, consultez Defender pour 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 plus d’informations, 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 plus d’informations, consultez Surveillance Azure Functions avec Journaux Azure Monitor.

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 plus d’informations, 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. Vous devez rediriger HTTP vers HTTPS, car HTTPS utilise le protocole TLS pour fournir une connexion sécurisée, qui est 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 l’ID Microsoft Entra et plusieurs fournisseurs d’identité non-Microsoft 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 clientes.

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 les stratégies d’authentification 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 les restrictions d’adresse 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 à partir de l’ID Microsoft Entra permet à votre application d’accéder facilement à d’autres ressources protégées par Microsoft Entra, telles qu’Azure Key Vault. La plateforme Azure gère l’identité, ce qui élimine la nécessité de provisionner ou de changer des identifiants. Pour plus d’informations sur les identités managées dans Microsoft Entra ID, consultez Identités managées pour les ressources Azure.

Vous pouvez accorder deux types d’identité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é affecté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 attribuées par l'utilisateur. 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 Utiliser des identités managées pour 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.

Il est tentant d’utiliser un caractère générique qui permet à tous les sites d’accéder à votre point de terminaison. Cette approche élimine l’objectif de CORS, qui est d’aider à empêcher les attaques par script intersite. 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. Cette approche rend ces informations d’identification disponibles à la fois 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

Bien que les paramètres d’application soient suffisants pour la plupart des fonctions, vous pouvez 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 la section 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 des secrets pour la connexion à certaines ressources. L’approche présente l’avantage de ne pas exiger la gestion d’un secret et fournit un contrôle d’accès et un audit plus précis.

Lorsque vous écrivez du code qui crée la connexion aux services Azure qui prennent en charge l’authentification Microsoft Entra, vous pouvez utiliser une identité au lieu d’une chaîne secrète ou 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. Cette approche peut potentiellement aider à atténuer les risques liés à l’exécution de code malveillant exécutant 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 remontent jusqu’à l’hôte et l'environnement d'exécution gère ces erreurs. Les liaisons différentes gèrent le traitement des erreurs différemment. Pour plus d’informations, consultez 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 un meilleur 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 Blob et de fichier. Ces clés doivent être présentes dans Azure Key Vault pour que Functions puisse accéder au compte de stockage. Pour plus d’informations, consultez Chiffrer vos données d’application au repos à l’aide de clés gérées par le client.

Une application de fonction dépend fréquemment d’autres ressources, de sorte qu’une partie de la sécurisation de l’application sécurise 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. La plateforme App Service gère les informations d’identification de déploiement. Les informations d’identification 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 ensemble d’informations d’identification pour l’ensemble du compte Azure. Ces informations d’identification peuvent être utilisées pour effectuer un déploiement sur App Service pour n’importe quelle application dans n’importe quel abonnement auquel le compte Azure est autorisé à accéder. Ce jeu d’informations d’identification est la valeur par défaut qui s’affiche dans l’environnement graphique du portail, comme dans Vue d’ensemble et Propriétés dans le volet de ressources de l’application. Lorsqu’un utilisateur reçoit un accès d’application via le contrôle d’accès en fonction du rôle (RBAC) ou des autorisations de coadministrateur, il peut utiliser ses informations d’identification au niveau de l’utilisateur jusqu’à ce que l’accès soit révoqué. Ne partagez pas ces informations d’identification avec d’autres utilisateurs Azure.

  • Informations d’identification au niveau de l’application : un ensemble d’informations d’identification pour chaque application. Ces informations d’identification peuvent être utilisées pour effectuer le déploiement 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 accorder à un utilisateur l’accès aux informations d’identification au niveau de l’application via RBAC, cet utilisateur doit disposer d’autorisations de contributeur ou supérieures sur l’application (y compris le rôle Contributeur de site web intégré). Les lecteurs ne sont pas autorisés à publier et ne peuvent pas accéder à 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 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 approche 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 Sécuriser vos pipelines Azure.

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 utilise l’infrastructure App Service pour permettre à vos fonctions d’accéder aux ressources sans utiliser d’adresses routables sur Internet ou pour 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 de n’importe quelle adresse. Si vous souhaitez en savoir plus, veuillez consulter Restrictions d’accès à 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 Flex Consumption, Elastic Premium et Dedicated (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 gérer un point de terminaison privé, vous devez connaître l’adresse du point de terminaison, et utiliser un enregistrement A pour référencer le point de terminaison que vous tentez d’atteindre.
  • 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 Intégrer votre environnement App Service ILB à Azure Application Gateway.

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 Utilisation de points de terminaison privés.

Étapes suivantes