Dans Azure, sécuriser les liens entre Storage Accounts et Function App est important. Ces connexions permettent de stocker le code source et les secrets, entre autres. Et ces liens peuvent devenir un point de vulnérabilité s’ils reposent sur des Shared Access Keys.
Dans cet article, nous allons explorer les différentes connexions entre une Function App et son/ses Storage Account(s). Nous verrons ensuite comment les sécuriser avec les Managed Identities et Azure Key Vault. Cela améliorera la posture de sécurité de votre environnement Azure.
Lors de la création d’une nouvelle Function App, deux connexions peuvent exister avec un Storage Account. Elles apparaissent dans les variables d’environnement de la Function App :
La première connexion à un Storage Account est l’Azure Web Jobs Storage. C’est dans ce Storage Account que notre fonction app va créer deux containers blobs :
Ce Storage Account là est obligatoire. Les informations stockées dedans sont essentielles pour le bon fonctionnement de notre Function App. Une connexion défaillante à ce niveau-là empêchera totalement cette dernière de fonctionner.
Vous pouvez trouvez la documentation de cet App Settings ici.
Cette connexion, bien qu’elle puisse pointer vers le même Storage Account, est différente. Elle donne accès à l’Azure File Storage d’un Storage Account. Dans ce partage de fichiers, la Function App stocke le code source de l’application. Ce code est utilisé lors du Scale Out pour redéployer la fonction. Cette configuration est obligatoire pour les Function Apps à la consommation qui ne sont pas en Run-From-Package ou en conteneur Docker. La documentation est ici.
Actuellement, comme on peut le voir dans les variables d’environnement, les Storage Accounts sont reliés aux Function Apps via une Shared Access Key. Comme son nom l’indique, il s’agit d’une clé d’accès partagée, visible dans les paramètres de la Function App. Cette clé permet d’accéder au Storage Account avec plus ou moins de droits.
Cette méthode présente plusieurs inconvénients. Elle oblige à gérer la clé et à la stocker quelque part. Si elle change, il faut anticiper et reporter la nouvelle valeur dans la Function App. De plus, si une personne malveillante accède à cette clé visible dans les paramètres, cela peut créer une faille de sécurité.
Pour sécuriser les liens entre Storage Accounts et Function App, la meilleure pratique est de remplacer les Shared Access Keys par l’utilisation des Managed Identities. Cette méthode permet à un composant Azure d’accéder à un autre en utilisant une identité dans Microsoft Entra ID. Cette identité peut être propre à la ressource (System Assigned Identity) ou créée séparément puis assignée à plusieurs ressources (User Assigned Identity). Les Managed Identities permettent de gérer les connexions entre composants Azure de façon sécurisée, sans avoir à manipuler de clés d’accès.
Pour que notre Function App se connecte au Storage Account « Azure Web Jobs Storage » via Managed Identity, il vas falloir faire plusieurs choses :
Premièrement il faut assigner à sa Function App une Managed Identity :
Pour cela dans la section « Identity », vous sélectionnez l’onglet correspondant au type de Managed Identity voulu (System Assigned ou User Assigned). Dans l’onglet System Assigned Identity, il suffit de basculer le statut à « On ». Quant à User Assigned Identity, il faut ajouter l’identité précédemment créée.
Ensuite il faut assigner des droits à la Managed Identity pour accéder au Storage Account en question :
Pour ce faire dans le Storage Account vous pouvez cliquer sur « Access Control » pour voir les assignements de rôle. Il est possible d’ajouter le rôle Storage Blob Data Contributor à votre Managed Identity.
Pour finir il ne vous reste plus qu’à spécifier dans votre Function App que l’on veut se servir de la Managed Identity pour accéder au Storage Account. Il faut remplacer l’App Setting AzureWebJobStorage par 3 autres :
Vous avez maintenant configuré correctement votre Function App. Elle utilise la Managed Identity qui lui est assignée pour pouvoir se connecter au Storage Account de manière sécurisée.
Vous pouvez maintenant désactiver la possibilité de s’y connecter via Shared Access key pour plus de sécurité (attention tout de même aux effets de bords) dans la configuration de votre Storage Account :
Le setting WEBSITE_CONTENTAZUREFILECONNECTIONSTRING diffère du précédent : on stocke dedans une connexion string qui donne accès à un Azure File Storage et non à un blob storage. Actuellement, Azure File Storage ne prend pas en charge les Managed Identities.
Pour sécuriser cette connexion, conservez la Shared Access Key et stockez-la dans un Azure Key Vault. La Function App doit ensuite référencer cette valeur dans ses App Settings et accéder au Key Vault via Managed Identity.
Commencez par créer, dans le Key Vault, une nouvelle entrée contenant la chaîne de connexion du Storage Account à utiliser.
Il faut ensuite assigner les droits pour que notre Managed Identity puisse accéder au Key Vault. C’est possible en rajoutant le rôle Key Vault Certificate User :
Il faut maintenant référencer la valeur du secret dans l’App Setting de la Function App avec ça :
@Microsoft.Keyvault(SecretUri={LeLienDuKeyvault}/secrets/{leNomDuSecret})
Ajoutez également un paramètre pour demander à la Function App de ne pas valider la valeur lors du déploiement. À ce stade, la Function App n’a pas encore récupéré la valeur depuis le Key Vault.
Au moment du déploiement, vérifiez qu’un conteneur Azure File Storage existe déjà dans le Storage Account. Son nom doit correspondre à la valeur de ce paramètre.
Avant de déployer la Function App, créez un conteneur nommé demo-articleblob-ddebab0e (il peut être vide). Cette étape est obligatoire, car la Function App ne peut pas créer elle-même un conteneur vide lorsque la validation de l’App Setting WEBSITE_CONTENTSHARE est ignorée.
Intégrez cette étape dans votre solution de déploiement (que ce soit ARM Template, Bicep, Terraform ou autres)
Une fois ces étapes terminées, la Function App fonctionne sans Shared Access Key dans ses paramètres. Elle récupère la chaîne de connexion du Storage Account en référencant la valeur du secret dans le Key Vault via Managed Identity.
Les liens vers le(s) Storage Account(s) ont une importance dans le fonctionnement de la Function App. Mais ça peut être une faille si on ne fait pas attention.
Il est donc conseillé de supprimer les Shared Access Keys ou de les stocker dans un Azure Key Vault sécurisé. Cela permet de limiter les risques liés à la gestion manuelle des accès.
En contrepartie, il est nécessaire d’utiliser les Managed Identities pour conserver ces liens.
Ces approches renforcent la protection des échanges entre services Azure sans sacrifier la flexibilité ni l’automatisation.
