Partager via

Utiliser Azure Key Vault dans une solution mutualisée

Azure Key Vault gère les données sécurisées, notamment les secrets, les clés de chiffrement et les certificats. Cet article décrit les fonctionnalités de Key Vault qui bénéficient aux solutions multitenantes. Il fournit également des liens vers des conseils qui peuvent vous aider à planifier l’utilisation de Key Vault.

Modèles d’isolation

Lorsque vous travaillez avec un système mutualisé qui utilise Key Vault, déterminez le niveau d’isolation dont vous avez besoin. Votre modèle d’isolation dépend des facteurs suivants :

  • Nombre de locataires dont vous disposez

  • Que vous partagiez votre couche d'application entre plusieurs locataires, déployiez des instances d'application à locataire unique, ou déployiez des environnements de déploiement distincts pour chaque locataire

  • Indique si vos locataires doivent gérer leurs propres clés de chiffrement

  • Si vos locataires ont des exigences de conformité qui vous obligent à stocker leurs secrets séparément des secrets d’autres locataires

Le tableau suivant résume les différences entre les principaux modèles de location pour Key Vault.

Considération Coffre pour chaque locataire, dans l’abonnement du fournisseur Coffre pour chaque locataire, dans l’abonnement du locataire Coffre partagé
Isolation des données Élevée Très élevée Faible
Isolation des performances Moyenne. Un débit élevé peut être limité, même avec de nombreux serveurs de stockage. Élevée Faible
Complexité du déploiement Faible à moyenne, en fonction du nombre de locataires Élevée. Le locataire doit accorder correctement l’accès au fournisseur. Faible
Complexité opérationnelle Élevée Faible pour le fournisseur, plus élevée pour le locataire Le moins élevé
Exemple de scénario Instances d’application individuelles pour chaque locataire Clés de chiffrement gérées par le client Solution multilocataire volumineuse dotée d’une couche Application partagée

Coffre pour chaque locataire, dans l’abonnement du fournisseur

Envisagez de déployer un coffre pour chaque locataire au sein de votre abonnement Azure (le fournisseur de services). Cette approche offre une isolation robuste des données pour chaque locataire. Toutefois, vous devez déployer et gérer un nombre croissant de coffres à mesure que le nombre de locataires augmente.

Azure ne limite pas le nombre de coffres-forts que vous pouvez déployer dans un seul abonnement. Mais envisagez d’autres limites :

Coffre pour chaque locataire, dans l’abonnement du locataire

Dans certains scénarios, vos locataires peuvent créer des coffres dans leurs propres abonnements Azure et accorder à votre application l'accès pour utiliser des secrets, des certificats ou des clés. Utilisez cette approche lorsque vous autorisez les clés gérées par le client pour le chiffrement au sein de votre solution.

Pour accéder aux données dans le coffre de votre locataire, le locataire doit fournir à votre application l’accès à son coffre. Ce processus nécessite que votre application s’authentifie via son instance d’ID Microsoft Entra. Vous pouvez publier une application Microsoft Entra ID mutualisée.

Vos locataires doivent effectuer un processus de consentement unique qui inclut les étapes suivantes :

  1. Inscrivez l’application Microsoft Entra mutualisée dans leur locataire Microsoft Entra.

  2. Accordez à votre application multilocataire Microsoft Entra le niveau d'accès approprié à leur coffre de données.

  3. Fournissez l’ID de ressource complet du coffre qu’ils créent.

Une fois cette configuration effectuée, votre code d’application peut utiliser un principal de service associé à l’application Microsoft Entra ID multi-locataires dans votre ID Microsoft Entra pour accéder au coffre de chaque locataire.

Vous pouvez également demander à chaque locataire de créer un principal de service pour que votre service puisse utiliser et vous fournir ses informations d’identification. Toutefois, cette approche vous oblige à stocker et gérer en toute sécurité les informations d’identification pour chaque locataire, ce qui introduit une responsabilité en matière de sécurité.

Si vos clients configurent des contrôles d’accès réseau sur leurs coffres, vérifiez que vous avez accès aux coffres. Concevez votre application pour gérer les situations où un locataire modifie ses contrôles d’accès réseau et bloque votre accès à leurs coffres.

Coffres partagés

Vous pouvez partager les secrets des locataires au sein d’un seul coffre-fort. Vous déployez le coffre dans l'abonnement Azure du fournisseur de solutions et vous gérez le coffre. Cette approche est la plus simple, mais fournit le moins d’isolation des données et d’isolation des performances.

Vous pouvez également déployer plusieurs coffres partagés. Par exemple, une solution qui suit le modèle Empreintes de déploiement déploie probablement un coffre partagé au sein de chaque tampon. De même, si vous déployez une solution multirégion, vous devez déployer des coffres dans chaque région pour les raisons suivantes :

  • Pour éviter la latence du trafic entre régions lorsque vous travaillez avec des données dans votre espace de stockage sécurisé.
  • Pour assurer les exigences de résidence des données
  • Pour activer l’utilisation de coffres régionaux au sein d’autres services nécessitant des déploiements de même région

Lorsque vous travaillez avec un coffre-fort partagé, tenez compte du nombre d’opérations que vous effectuez sur le coffre-fort. Les opérations incluent la lecture des secrets et l’exécution d’opérations de chiffrement ou de déchiffrement. Key Vault impose des limites sur le nombre de demandes effectuées sur un seul coffre et dans tous les coffres au sein d’un abonnement Azure. Suivez les instructions de limitation et appliquez d’autres pratiques recommandées. Cachez en toute sécurité les secrets que vous récupérez et utilisez le chiffrement d’enveloppe pour éviter d’envoyer toutes les opérations de chiffrement à Key Vault. Ces bonnes pratiques vous aident à implémenter des solutions à grande échelle dans un coffre-fort unique.

Si vous devez stocker des secrets, des clés ou des certificats propres au locataire, utilisez une convention de nommage telle qu’un préfixe de nommage. Par exemple, vous pouvez ajouter l’ID de locataire devant le nom de chaque secret. Ensuite, votre code d’application peut facilement charger la valeur d’un secret spécifique pour un locataire spécifique.

Fonctionnalités de Key Vault qui prennent en charge l’architecture mutualisée

Balises

Key Vault prend en charge l’étiquetage des secrets, des certificats et des clés en ajoutant des métadonnées personnalisées. Vous pouvez utiliser une balise pour suivre l’ID de locataire pour chaque secret spécifique au locataire. Mais Key Vault ne prend pas en charge l’interrogation par balises. Cette fonctionnalité fonctionne donc mieux à des fins de gestion plutôt que dans la logique d’application.

Pour plus d’informations, consultez les ressources suivantes :

Prise en charge d’Azure Policy

Si vous déployez un grand nombre de coffres, assurez-vous qu’ils suivent une norme cohérente pour la configuration d’accès réseau, la journalisation des accès réseau et le contrôle d'accès. Pensez à utiliser Azure Policy pour vérifier que les coffres sont configurés selon vos besoins.

Pour plus d’informations, consultez les ressources suivantes :

HSM managé Key Vault et HSM dédié Azure

Si vous devez effectuer un grand nombre d’opérations par seconde et que les limites d’opération Key Vault sont insuffisantes, envisagez d’utiliser le HSM managé ou le HSM dédié. Les deux produits fournissent une quantité réservée de capacité, mais ils augmentent les coûts par rapport à Key Vault. Découvrez les limites du nombre d’instances de ces services que vous pouvez déployer dans chaque région.

Pour plus d’informations, consultez les ressources suivantes :

Contributeurs

Microsoft gère cet article. Les contributeurs suivants ont écrit cet article.

Auteur principal :

  • John Downs | Ingénieur logiciel principal, modèles Azure & Pratiques

Autres contributeurs :

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

  • Last updated on