Architecture multilocataire et Azure Key Vault

  • Article

Azure Key Vault sert à gérer les données sécurisées pour votre solution, notamment les secrets, les clés de chiffrement et les certificats. Dans cet article, nous décrivons certaines des fonctionnalités d’Azure Key Vault qui sont utiles pour les solutions multilocataires. Nous fournissons ensuite des liens vers des conseils susceptibles de vous aider lorsque vous planifiez comment vous allez utiliser Key Vault.

Modèles d’isolation

Lorsque vous travaillez avec un système multilocataire qui utilise Key Vault, vous devez prendre une décision concernant le niveau d’isolation que vous souhaitez utiliser. Le choix des modèles d’isolation que vous utilisez dépend des facteurs suivants :

  • Combien de locataires prévoyez-vous d’avoir ?
  • Partagez-vous votre couche Application entre plusieurs locataires, déployez-vous des instances d’applications monolocataires, ou déployez-vous des empreintes de déploiement distinctes pour chaque locataire ?
  • Vos locataires doivent-ils gérer leurs propres clés de chiffrement ?
  • Vos locataires ont-ils des exigences de conformité qui nécessitent que leurs secrets soient stockés séparément des secrets d’autres locataires ?

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

Considération Coffre par locataire, dans l’abonnement du fournisseur Coffre par locataire, dans l’abonnement du locataire Coffre partagé
Isolation des données Élevé Très élevée Faible
Isolation des performances Moyenne. Le débit élevé peut être limité, même avec de nombreux coffres Élevé 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é Faible pour le fournisseur, plus élevée pour le locataire Minimale
Exemple de scénario Instances d’applications individuelles par locataire Clés de chiffrement gérées par le client Solution multilocataire volumineuse avec une couche Application partagée

Coffre par locataire, dans l’abonnement du fournisseur

Vous pouvez envisager de déployer un coffre pour chacun de vos locataires au sein de votre (en tant que fournisseur de services) abonnement Azure. Cette approche offre une forte isolation entre les données de chaque locataire, mais vous devez déployer et gérer un nombre croissant de coffres à mesure que vous augmentez le nombre de locataires.

Il n’existe aucune limite quant au nombre de coffres que vous pouvez déployer dans un abonnement Azure. Vous devez cependant prendre en compte les limites suivantes :

Coffre par locataire, dans l’abonnement du locataire

Dans certains cas, vos locataires peuvent créer des coffres dans leurs propres abonnements Azure, et ils souhaiteront peut-être accorder à votre application l’accès à l’utilisation de secrets, de certificats ou de clés. Cette approche convient lorsque vous autorisez les clés gérées par le client (CMK) pour le chiffrement dans votre solution.

Pour que l’accès aux données dans le coffre de votre locataire soit possible, le locataire doit fournir à votre application l’accès à son coffre. Ce processus nécessite que votre application s’authentifie par le biais de son instance Microsoft Entra. Une approche consiste à publier une application Microsoft Entra multilocataire. Vos locataires doivent effectuer un processus de consentement ponctuel. Ils enregistrent d’abord l’application Microsoft Entra multilocataire dans leur propre locataire Microsoft Entra. Ensuite, ils accordent à votre application Microsoft Entra multilocataire le niveau d’accès approprié à leur coffre. Ils doivent également vous fournir l’ID de ressource complet du coffre qu’ils ont créé. Ensuite, votre code d’application peut utiliser un principal de service associé à l’application Microsoft Entra multilocataire dans votre propre annuaire Microsoft Entra ID, pour accéder au coffre de chaque locataire.

En guise d’alternative, vous pouvez demander à chaque locataire de créer un principal de service utilisable par votre service, et de vous fournir ses informations d’identification. Toutefois, cette approche nécessite que vous stockiez et gériez de manière sécurisée les informations d’identification pour chaque locataire, ce qui constitue un risque potentiel en matière de sécurité.

Si vos locataires configurent des contrôles d’accès réseau sur leurs coffres, vérifiez que vous serez en mesure d’accéder aux coffres.

Coffres partagés

Vous pouvez choisir de partager les secrets des locataires au sein d’un coffre unique. Le coffre est déployé dans votre (en tant que fournisseur de solutions) abonnement Azure, et vous êtes responsable de sa gestion. Cette approche est la plus simple, mais elle fournit le moins d’isolation des données et d’isolation des performances.

Vous pouvez également choisir de déployer plusieurs coffres partagés. Par exemple, si vous suivez le Modèle d’empreintes de déploiement, il est probable que vous déploierez un coffre partagé dans chaque empreinte. 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 inter-région lors de l’utilisation des données dans votre coffre
  • Pour prendre en charge les exigences en matière de résidence des données
  • Pour permettre l’utilisation de coffres régionaux au sein d’autres services qui nécessitent des déploiements de même région

Lorsque vous utilisez un coffre partagé, il est important de prendre en compte le nombre d’opérations que vous effectuez sur le coffre. 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 quant au nombre de requêtes pouvant être effectuées sur un même coffre et parmi tous les coffres au sein d’un abonnement Azure. Veillez à suivre les instructions relatives à la limitation. Il est important de suivre les pratiques recommandées, notamment la mise en cache sécurisée des secrets que vous récupérez et l’utilisation du chiffrement d’enveloppe pour éviter d’envoyer chaque opération de chiffrement à Key Vault. Lorsque vous suivez ces bonnes pratiques, vous pouvez exécuter des solutions à grande échelle sur un coffre 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 d’Azure Key Vault qui prennent en charge l’architecture multilocataire

Balises

Key Vault prend en charge l’étiquetage des secrets, des certificats et des clés avec des métadonnées personnalisées. Vous pouvez donc utiliser une étiquette pour suivre l’ID de locataire pour chaque secret propre au locataire. Toutefois, Key Vault ne prend pas en charge l’interrogation par étiquettes. Cette fonctionnalité est donc mieux adaptée à des fins de gestion, plutôt qu’à une utilisation dans votre logique d’application.

Plus d’informations :

Prise en charge d’Azure Policy

Si vous décidez de déployer un grand nombre de coffres, il est important de veiller à ce qu’ils respectent une norme cohérente pour le contrôle d’accès, la journalisation et la configuration réseau. Vous pourriez utiliser Azure Policy pour vérifier que les coffres ont été configurés en fonction de vos besoins.

Plus d’informations :

Managed HSM et Dedicated HSM

Si vous devez effectuer un grand nombre d’opérations par seconde et que les limites d’opération de Key Vault sont insuffisantes, utilisez Managed HSM ou Dedicated HSM. Ces deux produits vous fournissent une quantité de capacité réservée, mais ils sont généralement plus coûteux que Key Vault. En outre, tenez compte des limites du nombre d’instances de ces services que vous pouvez déployer dans chaque région.

Plus d’informations :

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteur principal :

  • John Downs | Ingénieur client principal, FastTrack for Azure

Autres contributeurs :

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

Étapes suivantes

Examinez les approches du déploiement et de la configuration pour une architecture mutualisée.