Sécuriser l’accès au coffre-fort à votre application

Même toi ne devrait pas être autorisé à voir les secrets de votre coffre-fort Azure. Ce qui signifie que la création d’un coffre-fort clé n’est utile que si vous limitez l’accès à ses secrets à une seule chose: votre application.

Certaines choses à propos de votre application ne doivent être partagées avec personne: mot de passe de base de données, informations d’identification pour réclamer les inscriptions des applications et plus encore. La bonne réponse est de mettre ces secrets dans un coffre-fort Azure et, dans mon post précédent, Codage Azure 12: Configuration d’un coffre-fort Azure et ajout de secretsJ’ai parcouru le processus de mise en place d’un coffre-fort clé et de stockage des chaînes de texte («Secrets» dans le monde clé du coffre-fort) et des certificats dans ce coffre-fort.

Une fois votre coffre-fort clé, cependant, vous souhaitez également limiter la permission de lire votre coffre-fort clé pour uniquement les services d’applications au sein de votre application qui ont besoin d’accès. C’est le sujet de ce post.

Pour l’étude de cas que j’utilise pour cette série, les applications qui ont besoin d’accéder à mon coffre-fort clé sont:

Contrôlant l’accès au coffre-fort clé

Pour contrôler l’accès à votre coffre-fort clé dans une application Azure native dans le cloud, vous attribuez à votre coffre-fort une identité gérée assistée par le système et donnez cette identité gérée les autorisations dont il a besoin pour lire les secrets du coffre-fort.

Vous pouvez également utiliser une identité gérée attribuée par l’utilisateur avec votre service d’application et donner à cette identité les autorisations dont il a besoin pour accéder à la faute. Cependant, par défaut, le service d’application n’utilisera qu’une identité attribuée par le système. Donc, si vous souhaitez utiliser une identité attribuée par l’utilisateur, vous devez utiliser soit un Azure CLI ou PowerShell Command Pour que votre service d’applications utilise une identité attribuée par l’utilisateur (ou intégrez l’ID de l’identité gérée dans votre code). Cela me semble être comme quelque chose qui serait facilement omis et, par conséquent, je vais utiliser une identité attribuée par le système.

Pour que votre service d’applications génére une identité gérée assistée par le système, surfez d’abord sur votre service d’application dans le portail Azure et, dans le menu de gauche, forez Paramètres pour sélectionner Identité. Dans le Système attribué onglet qui apparaît dans la page à droite, définissez le Statut basculer Sur pour activer une identité gérée attribuée par le système pour votre service. Parce que cette identité est attribuée au système, vous devrez répéter ce processus si vous supprimez et recréez votre service d’application (sauf si vous utilisez des modèles, comme je l’ai décrit dans un article précédent, Codage Azure 11: recréation et déploiement de ressources azure avec des modèles de bras et de biceps.

Ensuite, vous devez donner à cette nouvelle identité les autorisations dont il a besoin pour lire les éléments de votre coffre-fort. Pour ce faire, cliquez sur le Affectations de rôle azur bouton qui apparaît plus bas sur la page d’identité pour ouvrir une nouvelle page. Sur cette page, à l’extrémité gauche du menu en haut de la page, cliquez sur le + Ajouter une affectation de rôle Choix du menu pour ouvrir un panneau à droite.

Dans ce panneau, à partir du Portée liste déroulante, sélectionnez Voûte clé. Ci-dessous, sélectionnez l’abonnement approprié dans le Abonnement liste déroulante (dans la plupart des cas, ce sera l’abonnement que vous avez utilisé avec le reste des ressources de cette application). De Ressource liste déroulante, sélectionnez votre coffre-fort (Warehousemgmtvaultdans mon cas).

Dans la liste déroulante des rôles, vous voudrez sélectionner l’un de ces trois rôles:

• Utilisateur clé des secrets de coffre-fort: Peut lire des secrets de texte stockés dans le coffre-fort
• Utilisateur de certificat de coffre-fort clé: Peut lire des certificats stockés dans le saut
• Utilisateur clé de la cryptographie du coffre-fort: Peut utiliser des clés de chiffrement stockées dans le coffre-fort pour crypter et déchiffrer les valeurs

Pour les trois cas que je couvre dans ce post, je lis toujours un secret, alors je choisis le Utilisateur clé des secrets de coffre-fort rôle. Dans un article ultérieur, je vais mettre en place l’un de mes inscriptions d’applications pour exiger que la demande fournisse un certificat afin de réclamer l’enregistrement (et les autorisations qui l’accompagnent), donc je repartirai de discuter des certificats jusque-là. Dans mon application d’étude de cas, je n’ai pas besoin de récupérer des clés de chiffrement, donc je n’ai pas besoin d’attribuer cette autorisation à aucune des applications de mon étude de cas.

Après avoir choisi un rôle, cliquez sur le Sauvegarder Le bouton en bas de la page pour économiser votre choix, fermez le panneau et revenez à la liste des rôles que vous avez donnés votre service d’application (il peut prendre quelques minutes pour que de nouvelles affectations de rôle prennent effet, alors ne paniquez pas si une nouvelle affectation de rôle n’apparaît pas immédiatement).

Actuellement, ce panneau vous permettra d’attribuer des rôles à l’identité attribuée au système mais ne vous permettra pas retirer affectations de rôles. Si vous ajoutez un rôle que vous souhaitez supprimer plus tard, vous devrez le faire de la page Affichage de la page Contrôle d’accès (IAM) de votre coffre-fort.

Vous avez maintenant configuré vos services d’application pour accéder à votre coefficient clé, en applications côté client ou côté serveur exécutées dans ce service d’application peut retirer ces valeurs du coffre-fort. Dans mes prochains articles, je vais vous montrer comment faire cela.