Sécuriser l’accès réseau pour les applications de fonction

Une application Function App avec une authentification configurée contrôle qui peut l’appeler, mais le point de terminaison de la fonction reste accessible via n’importe quel chemin d’accès réseau, y compris l’internet public. Les contrôles réseau ajoutent une couche de contrôle distincte : en limitant les chemins réseau qui peuvent atteindre la fonction, et en contrôlant les chemins réseau que la fonction utilise pour ses propres appels sortants. L’authentification et l’isolation réseau sont indépendantes et complémentaires. Les deux doivent être en place pour une posture de sécurité défendable.

Restreindre l’accès entrant avec des listes d’autorisation IP

Les restrictions d’accès vous permettent de définir une liste triée par priorité des règles d’autorisation et de refus basées sur l’adresse IP source, la plage CIDR (Classless Inter-Domain Route) ou Azure balise de service. Lorsqu’une règle explicite existe, un refus implicite s’applique à tout le trafic qui ne correspond pas , vous n’avez pas besoin d’ajouter manuellement une règle de refus.

Pour les applications de fonction qui doivent accepter uniquement les appels entrants à partir de services Azure spécifiques, les règles d’étiquette de service fournissent une solution propre. Par exemple, pour accepter les appels de webhook uniquement à partir de Azure Event Grid, ajoutez une règle autorisant l’étiquette de service AzureEventGrid et refusez tout le trafic. La balise de service couvre la plage complète d'adresses IP utilisées par ce service Azure. Vous n'avez donc pas besoin de gérer des plages d'adresses IP individuelles pour les services qui utilisent des pools d'adresses dynamiques.

Les restrictions d’accès sont disponibles dans tous les plans d’hébergement d’applications de fonction, notamment Consommation, Flex Consumption, Elastic Premium et Dedicated.

Déployer un point de terminaison privé pour l’accès entrant

Lorsque le trafic de l’application de fonction ne doit jamais traverser l’Internet public, un point de terminaison privé supprime entièrement le point de terminaison public. Un point de terminaison privé attribue à l’application de fonction une adresse IP privée au sein de votre réseau virtuel (réseau virtuel). Tout le trafic entrant arrive via cette adresse IP privée : les appelants externes ne peuvent pas atteindre l’URL de fonction à partir d’Internet, car aucun itinéraire public n’existe.

Les points de terminaison privés pour les applications de fonction sont pris en charge dans les plans d’hébergement Flex Consumption, Elastic Premium et Dedicated (App Service). Le plan consommation standard ne prend pas en charge les points de terminaison privés.

Une fois qu'un point de terminaison privé est configuré, les appelants au sein du réseau virtuel, y compris d'autres services Azure connectés au même réseau, résolvent le nom d'hôte de la fonction en adresse IP privée. Cette résolution de noms nécessite Azure DNS zones privées. Si votre fonction est le serveur principal pour Gestion des API Azure ou une passerelle Application Gateway, ces ressources se connectent à l’application de fonction via le point de terminaison privé plutôt qu’une URL publique, en conservant tout le trafic sur le Azure principal.

Configurer l’intégration de réseau virtuel pour le trafic sortant

Les points de terminaison privés contrôlent l’accès entrant à l’application de fonction Azure, c’est-à-dire ce qui peut y accéder. L’intégration au réseau virtuel contrôle l’accès sortant — c’est-à-dire les ressources auxquelles l’application Function peut accéder. Il s’agit de contrôles distincts et servent des objectifs différents.

Une fois l’intégration de réseau virtuel activée, l’application de fonction achemine ses appels réseau sortants via un sous-réseau délégué dans votre réseau virtuel. Cela permet à la fonction d’appeler des ressources qui ne sont pas exposées à l’Internet public : un compte Cosmos DB sans accès public, un compte de stockage verrouillé sur des sous-réseaux de réseau virtuel spécifiques ou une API REST privée hébergée sur une machine virtuelle dans le même réseau.

L’intégration de réseau virtuel régional est disponible dans les plans Flex Consumption, Elastic Premium et Dedicated et est la configuration recommandée pour la plupart des scénarios. L’application de fonction et le réseau virtuel doivent se trouver dans la même région Azure. L’intégration utilise un sous-réseau délégué : ce sous-réseau ne peut pas être utilisé pour d’autres ressources telles que des machines virtuelles ou des points de terminaison privés.

Configurer CORS pour les clients basés sur un navigateur

Le partage de ressources inter-origines (CORS) s’applique lorsque les applications web basées sur un navigateur appellent directement des applications de fonction déclenchées par HTTP. Par défaut, les navigateurs bloquent les demandes d’origine croisée. Azure Functions vous permet de configurer les origines autorisées à effectuer ces demandes.

En production, spécifiez des origines explicites autorisées, par exemple https://contoso-retail.com. N’utilisez jamais le caractère générique (*) en production. Une configuration CORS générique permet à n’importe quelle origine d’effectuer des demandes à votre application de fonction, ce qui supprime la protection inter-origine fournie par CORS pour les clients basés sur le navigateur.

Les restrictions CORS s’appliquent uniquement aux clients HTTP basés sur un navigateur. Les appels de serveur à serveur (à partir de services principaux, de services Azure ou de clients HTTP non-rowser) ne sont pas soumis à l'application CORS. CORS est un mécanisme de sécurité de navigateur, et non un contrôle d’accès côté serveur.

Référencer les secrets Key Vault dans les paramètres de l’application

Les paramètres d’application dans Azure Functions sont l’un des emplacements les plus courants où les chaînes de connexion et les clés API finissent par être stockées en texte brut. Le modèle de référence Key Vault remplace une valeur de paramètre d’application en texte brut par une référence que l’application de fonction résout lors de l’exécution à l’aide de son identité managée.

La syntaxe d’une référence Key Vault dans un paramètre d’application est la suivante :

@Microsoft.KeyVault(SecretUri=https://<vault-name>.vault.azure.net/secrets/<secret-name>/<version>)

Si vous omettez l’identificateur de version, l’application de fonction résout la dernière version du secret. Cela est utile pour les secrets qui pivotent régulièrement : la fonction récupère la valeur mise à jour dans les 24 heures de rotation, sans redéploiement.

Pour utiliser des références Key Vault :

1. Activez une identité managée attribuée par le système sur l’application de fonction.
2. Affectez le rôle d’utilisateur Key Vault Secrets à l’identité managée sur le Key Vault.
3. Remplacez la valeur de texte brut dans chaque paramètre d’application par la syntaxe de référence @Microsoft.KeyVault(...).

L’application de fonction résout la référence au démarrage et injecte la valeur secrète comme valeur de paramètre d’application. Le code de fonction lit le paramètre à l’aide de Environment.GetEnvironmentVariable("SETTING_NAME") , le même appel utilisé pour tout autre paramètre d’application, sans connaître la couche de référence Key Vault.