Les environnements serverless et PaaS ont pour but de libérer la productivité des développeurs en simplifiant les tâches de gestion et en leur permettant de se concentrer sur l'essentiel, à savoir la logique de leurs applications. Mais cela ne doit pas se faire au détriment de la sécurité, et les meilleures pratiques doivent être faciles à appliquer. Heureusement, App Service et Azure Functions offrent de nombreuses fonctionnalités qui facilitent considérablement la sécurisation de vos applications.

Nous annonçons aujourd'hui la mise à disposition de nouvelles fonctionnalités de sécurité qui réduisent le volume de code requis pour gérer les identités et les secrets. Ces fonctionnalités sont les suivantes :

• Références Key Vault pour Paramètres d'application (préversion publique)
• Identités managées affectées par l'utilisateur (préversion publique)
• Identités managées pour App Service sur Linux/Web App pour conteneurs (préversion publique)
• Données de liaison ClaimsPrincipal pour Azure Functions
• Prise en charge d'Access-Control-Allow-Credentials dans la configuration CORS

Nous continuons également à investir dans Azure Security Center en tant que hub principal dédié à la sécurité de vos ressources Azure, car celui-ci peut se révéler très efficace pour détecter et résoudre les vulnérabilités de configuration, limiter votre exposition aux menaces ou détecter les attaques afin de vous permettre d'y répondre. Par exemple, Security Center vous aidera à vérifier que toutes vos applications fonctionnent bien en mode HTTPS seulement. Si ce n'est déjà fait, faites un essai.

Penchons-nous maintenant sur ces nouvelles fonctionnalités.

Références Key Vault pour Paramètres d'application (préversion publique)

À l'occasion de la conférence Microsoft Ignite 2018, nous avons présenté en avant-première une nouvelle fonctionnalité permettant aux applications de se procurer leurs paramètres d'application à partir de Key Vault. J'ai l'honneur de vous annoncer que cette fonctionnalité est désormais disponible sous forme de préversion publique !

De plus en plus d'organisations adoptent des stratégies sécurisées de gestion des secrets, ce dont je me félicite. Azure Key Vault vous fournit une source fiable pour vos secrets, avec un contrôle total sur les stratégies d'accès et sur l'historique d'audit. Bien que la fonctionnalité Paramètres d'application d'App Service et Azure Functions soit jugée sûre, avec un chiffrement des secrets au repos, elle ne vous fournit pas les fonctionnalités de gestion dont vous avez probablement besoin.

Mais pour utiliser Key Vault, il est généralement nécessaire de rédiger un nouveau code. Nous avons constaté qu'il est difficile pour les équipes de mettre à jour l'ensemble des environnements dans lesquels leur application est exécutée avec des secrets, en particulier pour les applications héritées. Les déclencheurs Azure Functions posent également des problèmes, car ils sont gérés par la plateforme. Cette nouvelle fonctionnalité s'attaque à ces deux scénarios.

Approvisionnement des Paramètres d'application à partir de Key Vault

La fonctionnalité de références Key Vault permet à votre application de fonctionner comme si elle utilisait les Paramètres d'application tels quels, ce qui signifie qu'aucune modification du code n'est nécessaire. Vous trouverez tous les détails dans la documentation consacrée à la fonctionnalité de références Key Vault, mais je vais ici vous en présenter les grandes lignes.

Cette fonctionnalité requiert une identité managée affectée par le système pour votre application. Plus loin dans cet article, nous nous pencherons aussi sur les identités affectées par l'utilisateur.

Vous devrez ensuite configurer une stratégie d'accès sur votre instance de Key Vault. Celle-ci accordera à votre application une autorisation GET pour accéder aux secrets. Apprenez à configurer une stratégie d'accès.

Enfin, définissez la valeur d'un paramètre d'application quelconque sur une référence au format suivant :

@Microsoft.KeyVault(SecretUri=secret_uri_with_version)

Sachant que secret_uri_with_version correspondant à l'URI complet d'un secret dans Key Vault. Par exemple : https://myvault.vault.azure.net/secrets/mysecret/ec96f02080254f109c51a1f14cdb1931

C'est tout ! Aucun changement de code n'est requis !

Pour cette préversion initiale, vous devez explicitement définir une version secrète, car nous n'avons pas encore de système de gestion des rotations intégré. Nous espérons être en mesure d'en fournir un dès que possible.

Identités managées affectées par l'utilisateur (préversion publique)

La prise en charge existante des identités managées est dite « affectée par le système ». L'idée est la suivante : l'identité est créée par la plateforme pour une application spécifique, puis liée au cycle de vie de l'application. Si vous supprimez l'application, l'identité est immédiatement supprimée d'Azure Active Directory.

Nous présentons aujourd'hui une préversion des identités affectées par l'utilisateur, lesquelles sont créées en tant que ressources Azure, puis affectées à une application donnée. Une identité affectée par l'utilisateur peut également être affectée à plusieurs applications, et une application peut avoir plusieurs identités affectées par l'utilisateur.

Pour en savoir plus sur la création et l'utilisation d'une identité affectée par l'utilisateur, reportez-vous à « Créer, répertorier, supprimer ou affecter un rôle à une identité managée affectée par l'utilisateur à l'aide du portail Azure ». Une fois l'identité créée, vous pouvez l'affecter à votre application en reconfigurant celle-ci avec un pointeur orienté vers cette identité. Pour en savoir plus, consultez la documentation consacrée aux identités managées. Veuillez noter que cette préversion n'est pas prise en charge dans les clouds souverains.

Conseil : même s'il est possible d'utiliser une même identité avec plusieurs ressources, mieux vaut éviter de surpartager des identités et d'accorder des autorisations à des ressources qui n'en ont pas besoin. Suivez toujours le principe du moindre privilège et, par défaut, créez des identités distinctes pour chacun des composants de votre application. Ne partagez les identités que lorsque cela s'avère vraiment nécessaire.

Identités managées pour App Service sur Linux/Web App pour conteneurs (préversion publique)

Nous sommes également ravis d'étendre notre prise en charge des identités managées à App Service sur Linux/Web App pour conteneurs. Désormais, les applications Linux peuvent bénéficier de la même expérience d'authentification clé en main de service à service, sans avoir à gérer d'informations d'identification. Cette préversion inclut à la fois la prise en charge affectée par le système et celle affectée par l'utilisateur. Outre la mise à disposition d'un service de jetons facilitant les demandes d'accès aux ressources telles que Key Vault et Azure Resource Manager, cette nouvelle prise en charge permet également aux applications Linux d'accéder à la fonctionnalité de références Key Vault mentionnée précédemment.

Pour commencer à utiliser vos applications Linux, vous pouvez suivre les étapes de configuration décrites dans la documentation « Guide pratique pour utiliser des identités managées pour App Service et Azure Functions ».

Données de liaison ClaimsPrincipal pour Azure Functions

Depuis la première préversion d'Azure Functions, vous pouvez utiliser la fonctionnalité Autorisation/Authentification d'App Service pour limiter l'accès à vos applications de fonction. Aujourd'hui, nous facilitons l'utilisation des identités entrantes à partir de votre code de fonction. Le déploiement, qui est en cours de finalisation, sera disponible dans Azure pour toutes les applications de fonction d'ici la fin de la semaine.

Pour .NET, il s'agira d'un objet ClaimsPrincipal, semblable à celui que vous verriez dans ASP.NET. L'objet sera automatiquement injecté si vous ajoutez un objet ClaimsPrincipal à votre signature de fonction, comme pour l'injection d'ILogger.

using System.Net;
using Microsoft.AspNetCore.Mvc;
using System.Security.Claims;

public static IActionResult Run(HttpRequest req, ClaimsPrincipal principal, ILogger log)
{
     // ...
     return new OkResult();
}

Dans une prochaine mise à jour, d'autres langues disposeront d'un accès via l'objet de contexte. En attendant, il s'agit d'une préversion .NET uniquement. Pour en savoir plus sur cette fonctionnalité, consultez la référence du déclencheur HTTP.

J'apprécie beaucoup la façon dont les fonctions dépendant de l'identité sont ainsi nettoyées. Cette fonctionnalité, associée à la liaison de jetons, supprime une bonne portion de code non essentielle à votre logique métier.

Prise en charge d'Access-Control-Allow-Credentials dans la configuration CORS

Enfin, nous disposons d'une mise à jour rapide de notre fonctionnalité CORS qui permet de définir l'en-tête Access-Control-Allow-Credentials. Cette opération est nécessaire chaque fois que vous devez envoyer des cookies ou un jeton dans le cadre de l'appel de votre API. Si cet en-tête de réponse n'est pas défini, le navigateur ne transmettra pas de données.

Pour en savoir plus sur la fonctionnalité CORS et sur ce nouveau paramètre, reportez-vous au didacticiel « Héberger une API RESTful avec CORS dans Azure App Service ». Pour activer l'en-tête, il vous suffit de mettre à jour votre configuration CORS en définissant « supportCredentials » sur true.

L'en-tête Access-Control-Allow-Credentials peut également être activé dans l'hôte Functions local à des fins de développement, grâce à une demande de tirage (pull request) de la communauté.

Pour résumer

Comme pour toutes nos préversions, n'hésitez pas à essayer ces fonctionnalités et à nous donner votre avis !

Si vous souhaitez solliciter de nouvelles fonctionnalités, veuillez poster une idée sur UserVoice (pour Functions ou App Service). Pour les problèmes relatifs à Functions, veuillez poser une question sur notre référentiel GitHub. Vous pouvez également contacter l'équipe sur Twitter @AzureFunctions.

N'hésitez pas à nous faire part de vos commentaires. Et maintenant, sécurisez vos applications !