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’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.

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 HTTP 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 de 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 fonctions HTTP pendant le développement. 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 API.

Bien que les clés fournissent un mécanisme de sécurité par défaut, vous pouvez utiliser d’autres options pour sécuriser un point de terminaison HTTP en production. Par exemple, évitez de diffuser un secret partagé dans des applications publiques. Si votre fonction est appelée depuis un client public, vous pouvez envisager de mettre en place un autre mécanisme de sécurité. Pour plus d’informations, consultez Sécuriser un point de terminaison HTTP en production.

Lorsque vous renouvelez les valeurs clés de votre fonction, vous devez redistribuer manuellement les valeurs clé mises à jour à tous les clients qui appellent votre fonction.

Étendues d’autorisation (au niveau de la fonction)

Il existe deux étendues d’accès pour les clés au niveau de la fonction :

  • Fonction : Ces clés s’appliquent uniquement aux fonctions spécifiques sous lesquelles elles sont définies. Utilisées en tant que clés API, elles permettent d’accéder uniquement à ces fonctions.

  • Hôte : Des clés avec une étendue d’hôte permettent d’accéder à toutes les fonctions au sein de l’application de fonction. Utilisées en tant que clés API, elles permettent d’accéder à toute fonction au sein de la Function App.

Chaque clé est nommée pour référence et il existe une clé par défaut (nommée « default ») au niveau de la fonction et de l’hôte. Les clés de fonction prennent le pas sur les clés d’hôte. Quand deux clés portent le même nom, la clé de fonction est toujours utilisée.

Clé principale (au niveau de l’administrateur)

Chaque application de fonction a également une clé d’hôte au niveau de l’administrateur nommée _master. En plus de fournir un accès au niveau de l’hôte à toutes les fonctions de l’application, la clé principale fournit un accès administratif aux API REST du runtime. Cette clé ne peut pas être révoquée. Quand vous définissez un niveau d’accès de admin, les requêtes doivent utiliser la clé principale ; toute autre clé provoque l’échec de l’accès.

Attention

En raison des autorisations élevées que donnent la clé principale dans votre application de fonction, vous ne devez pas la partager avec des tiers ni la distribuer dans des applications clientes natives. Faites preuve de prudence lorsque vous choisissez le niveau d’accès administrateur.

Clé système

Les extensions spécifiques peuvent nécessiter une clé gérée par le système pour accéder aux points de terminaison webhook. Les clés système sont conçues pour les points de terminaison de fonctions spécifiques à l’extension qui sont appelés par les composants internes. Par exemple, le déclencheur Event Grid exige que l’abonnement utilise une clé système lors de l’appel du point de terminaison du déclencheur. Durable Functions utilise également des clés système pour appeler API d’extension de tâche durable.

L’étendue des clés système est déterminée par l’extension, mais elle s’applique généralement à l’ensemble de l’application de fonction. Les clés système peuvent uniquement être créées par des extensions spécifiques, et vous ne pouvez pas définir explicitement leurs valeurs. À l’instar d’autres clés, vous pouvez générer une nouvelle valeur pour la clé à partir du portail ou à l’aide des API clé.

Comparaison des clés

Le tableau suivant compare les utilisations de différents types de clés d’accès :

Action Étendue Clés valides
Exécuter une fonction Fonction spécifique Fonction
Exécuter une fonction Toutes les fonctions Fonction ou hôte
Appeler un point de terminaison administrateur Conteneur de fonctions Hôte (maître uniquement)
Appeler des API d’extension de tâche durables Application de fonction1 Système 2
Appeler un webhook spécifique à une extension (interne) Application de fonction1 système2

1Étendue déterminée par l’extension.
2Noms spécifiques définis par l’extension.

Pour en savoir plus sur les clés d’accès, consultez l’article Déclencheurs et liaisons HTTP.

Référentiels de secrets

Par défaut, les clés sont stockées dans un conteneur de stockage Blob dans le compte fourni par le paramètre AzureWebJobsStorage. Vous pouvez utiliser le paramètre AzureWebJobsSecretStorageType pour remplacer ce comportement et stocker des clés dans un emplacement différent.

Emplacement Valeur Description
Second compte de stockage blob Stocke les clés dans le stockage Blob d’un autre compte de stockage, en fonction de l’URL SAP dans AzureWebJobsSecretStorageSas.
Système de fichiers files Les clés sont conservées dans le système de fichiers, qui est la valeur par défaut dans Functions v1.x.
Azure Key Vault keyvault Le coffre de clés défini dans AzureWebJobsSecretStorageKeyVaultUri est utilisé pour stocker des clés.
Secrets Kubernetes kubernetes L’ensemble de ressources dans AzureWebJobsKubernetesSecretName est utilisé pour stocker des clés. Pris en charge uniquement lors de l’exécution du runtime Functions dans Kubernetes. Azure Functions Core Tools génère automatiquement les valeurs lors du déploiement sur Kubernetes.

Lorsque vous utilisez Key Vault pour le stockage de clés, les paramètres d’application dont vous avez besoin dépendent du type d’identité managée. La version 3.x du runtime Functions prend uniquement en charge les identités managées affectées par le système.

Nom du paramètre Attribué par le système Affecté par l’utilisateur Inscription d'application
AzureWebJobsSecretStorageKeyVaultUri
AzureWebJobsSecretStorageKeyVaultClientId X
AzureWebJobsSecretStorageKeyVaultClientSecret X X
AzureWebJobsSecretStorageKeyVaultTenantId X X

Authentification/autorisation

Alors que les clés de fonction 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é.

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

Gestion des API Azure 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é attribuée par le système est liée à votre application et est supprimée si votre 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 attribuées par l’utilisateur.

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 à 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 déclencheur et de liaison Azure Functions peuvent être configurées à l’aide d’une connexion basée sur l’identité. Aujourd’hui, cela comprend les extensions Azure Blob et de file d’attente Azure. Pour plus d’informations sur la configuration de ces extensions pour utiliser une identité, consultez Utilisation de connexions basées sur l’identité dans Azure Functions.

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 scm d’App Service. Le point de terminaison SCM pour une application de fonction est toujours sous la forme d’une URLhttps://<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 une application 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 acceptera le trafic à partir de n’importe quelle adresse. 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é avec des points de terminaison de service ou privés. Pour plus d’informations, consultez Restreindre votre compte de stockage à un réseau virtuel.

Accès aux sites privés

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 (ASE) fournit un environnement d’hébergement dédié où exécuter vos fonctions. L’environnement App Service vous permet de configurer une passerelle frontend 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