Partager via

Sécurisation d’Azure Functions

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.

Azure App Service sécurise et renforce activement ses composants de plateforme, notamment les machines virtuelles Azure, le stockage, les connexions réseau, les infrastructures web et les fonctionnalités d’intégration et de gestion. App Service effectue des vérifications de conformité continues et rigoureuses pour garantir que :

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.

Bien que la planification du développement, du déploiement et du fonctionnement sécurisés de fonctions serverless soit identique à celle de n’importe quelle application hébergée sur le web ou dans le cloud, les applications serverless sont probablement vulnérables aux variations des attaques traditionnelles. Pour en savoir plus sur les attaques potentielles sur l’infrastructure serverless, consultez le Top 10 de l’OWASP : interprétation serverless.

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 for Cloud

Defender pour le cloud s’intègre à votre application de fonction dans le portail. Il fournit une évaluation rapide des vulnérabilités de sécurité potentielles 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 d’Azure Functions avec les 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 que vous exposez fournissent publiquement un vecteur d’attaque pour les acteurs malveillants. Lors de la sécurisation de vos points de terminaison HTTP, utilisez une approche de sécurité en couches. Utilisez ces techniques pour réduire la vulnérabilité des points de terminaison HTTP exposés publiquement, classées de la plupart des bases aux plus sécurisées et restrictives :

Exiger HTTPS

Par défaut, les clients peuvent se connecter à des applications web en utilisant aussi bien le protocole HTTP que le protocole HTTPS. Redirigez 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 de HTTPS, vous devez également exiger la dernière version 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 utilise des clés pour rendre plus difficile l’accès à vos points de terminaison de fonction. Sauf si vous définissez le niveau d’accès HTTP sur une fonction anonymousdéclenchée par HTTP, les requêtes doivent inclure une clé d’accès dans la requête. Pour plus d’informations, consultez Utiliser des clés d’accès dans Azure Functions.

Bien que les clés d’accès puissent empêcher l’accès indésirable, la seule façon de sécuriser réellement 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é, sécurisez l’ensemble de l’architecture d’application à l’intérieur d’un réseau virtuel à l’aide de points de terminaison privés ou en s’exécutant en isolation.

Désactiver les points de terminaison d’administration

Les applications de fonction peuvent servir des points de terminaison d’administration sous l’itinéraire /admin. Vous pouvez utiliser ces points de terminaison 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. Vous pouvez également accéder aux opérations d’administration via l’API Azure Resource ManagerMicrosoft.Web/sites, qui offre azure RBAC. Pour désactiver les /admin points de terminaison, définissez la propriété functionsRuntimeAdminIsolationEnabled du site dans votre application à true. Pour plus d’informations, consultez la référence de propriété functionsRuntimeAdminIsolationEnabled .

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. Utilisez cette stratégie pour implémenter des règles d’autorisation personnalisées pour vos fonctions. Vous pouvez utiliser des informations utilisateur à partir de votre code de 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. À l’aide d’APIM, vous pouvez configurer votre application de fonction pour accepter les requêtes uniquement à partir de l’adresse IP de votre instance APIM. Pour plus d’informations, consultez les restrictions d’adresse IP.

Autorisations

Comme avec n’importe quelle application ou service, exécutez votre application de fonction avec les autorisations possibles les plus basses.

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 prennent effet 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 d’analyse pour 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.

Utilisez des identités gérées au lieu de secrets pour les connexions à partir de certains déclencheurs et liens. 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 de 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 vous connecter aux différents services et ressources nécessaires pour exécuter votre code, les applications de fonction ont besoin 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, 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. Utilisez le nom du paramètre d’application (clé) 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é, que le runtime utilise. Par défaut, vous stockez la connexion à ce compte de stockage dans un paramètre d’application nommé AzureWebJobsStorage.

Azure chiffre les paramètres d’application et les chaînes de connexion. Les paramètres de l’application et les chaînes de connexion sont déchiffrés uniquement avant d’être injectés dans la mémoire du processus de votre application au démarrage de l’application. 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, faites référence aux paramètres de l’application aux secrets Azure Key Vault.

Lorsque vous développez des fonctions sur votre ordinateur local, vous pouvez également chiffrer les paramètres par défaut dans le local.settings.json fichier. Pour plus d’informations, consultez 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é

Utilisez des identités à la place des secrets pour la connexion à certaines ressources. Cette 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.

Vous pouvez configurer certaines extensions de liaison Azure Functions pour accéder aux services à l’aide de connexions basées sur des identités. 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 l’exécution totale des fonctions dans votre application de fonction, l’exécution s’arrête lorsque la limite est atteinte. Cette approche peut potentiellement aider à protéger contre le 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 supposez pas que les données entrantes dans votre fonction sont déjà validées ou nettoyées. 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. Pour obtenir des conseils sur la sécurisation de ces ressources, 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 le stockage.

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. Vous utilisez ces informations d’identification de déploiement pour sécuriser vos déploiements d’applications de fonction. La plateforme App Service gère les informations d’identification de déploiement et les chiffre au repos.

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

  • Les informations d’identification au niveau de l’utilisateur fournissent un jeu unique d’informations d’identification de déploiement pour l’ensemble du compte Azure d’un utilisateur. Un utilisateur disposant d’un accès d’application via le contrôle d’accès en fonction du rôle (RBAC) ou des autorisations de coadministrateur peut utiliser ses informations d’identification au niveau de l’utilisateur tant qu’ils disposent de ces autorisations.

    Vous pouvez utiliser vos informations d’identification spécifiques à l’utilisateur pour déployer une application sur App Service via Git local ou FTP/S dans n’importe quel abonnement auquel votre compte Azure a accès. Vous ne partagez pas ces informations d’identification avec d’autres utilisateurs Azure. Vous pouvez réinitialiser vos identifiants au niveau de l'utilisateur à tout moment.

  • L’étendue de l’application ou les informations d’identification au niveau de l’application sont un ensemble d’informations d’identification par application qui peuvent être utilisées pour déployer cette application uniquement. Ces informations d’identification sont générées automatiquement pour chaque application lors de la création et ne peuvent pas être configurées manuellement, mais le mot de passe peut être réinitialisé à tout moment.

    Un utilisateur doit disposer d’au moins des autorisations de niveau Contributeur sur une application, y compris le rôle Contributeur de site web intégré, pour pouvoir accéder aux informations d’identification au niveau de l’application via RBAC. Le rôle lecteur ne peut pas publier et ne peut 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.

Lorsque vous n’utilisez pas FTP, conservez-le désactivé. Vous pouvez modifier ce paramètre dans le portail. Si vous choisissez d’utiliser FTP, appliquez FTPS.

Sécuriser le point de terminaison scm

Chaque application de fonction a un point de terminaison de service scm correspondant que le service d’Outils avancés (Kudu) utilise 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 utilisant un point de terminaison distinct scm , vous pouvez contrôler les déploiements et d’autres fonctionnalités d’outils avancés pour les applications de fonction isolées ou exécutées dans un réseau virtuel. Le scm point de terminaison 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é

Étant donné que vous devez prendre en compte la sécurité à chaque étape du processus de développement, il est judicieux d’implémenter également des validations de sécurité dans un environnement de déploiement continu. Cette approche est parfois appelée DevSecOps. En utilisant Azure DevOps pour votre pipeline de déploiement, vous pouvez 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

En limitant l’accès réseau à votre application de fonction, vous pouvez contrôler qui peut accéder à vos points de terminaison de fonctions. 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 et de refus pour contrôler le trafic vers votre application. Les règles sont évaluées par ordre de priorité. Si vous ne définissez aucune règle, votre application accepte le trafic à partir d’une adresse quelconque. 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

Point de terminaison privé Azure est une interface réseau qui vous connecte de façon privée et sécurisée à un service avec Azure Private Link. Le point de terminaison privé utilise une adresse IP privée de votre réseau virtuel, intégrant ainsi efficacement le service à votre réseau virtuel.

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 isolation

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

En utilisant des services de passerelle tels qu’Azure Application Gateway et Azure Front Door, vous pouvez configurer un pare-feu d’applications web (WAF). Les règles WAF surveillent ou bloquent les attaques détectées, ce qui fournit une couche supplémentaire de protection pour vos fonctions. Pour configurer un WAF, votre application de fonctions doit s’exécuter dans un environnement ASE ou utiliser des points de terminaison privés (version préliminaire). Pour plus d’informations, consultez Utilisation de points de terminaison privés.

Étapes suivantes

  • Last updated on