Architecture multilocataire et Azure Key Vault
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 vous offre une isolation des données robuste entre les données de chaque locataire. Cependant, cela nécessite de déployer et de gérer un nombre croissant de coffres au fur et à 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 :
- Il existe des limites à l’échelle de l’abonnement sur le nombre de requêtes que vous pouvez effectuer dans une période donnée. Ces limites s’appliquent quel que soit le nombre de coffres dans l’abonnement. Il est donc important de suivre nos conseils concernant la limitation, même lorsque vous avez des coffres propres au locataire.
- Il existe une limite quant au nombre d’attributions de rôles Azure que vous pouvez créer dans un abonnement. Lorsque vous déployez et configurez un grand nombre de coffres dans un abonnement, vous risquez d’approcher de ces limites.
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. Cependant, cette approche nécessite que vous stockiez et gériez en toute sécurité les informations d’identification de chaque locataire, ce qui constitue un risque pour la sécurité.
Si vos locataires configurent des contrôles d’accès réseau sur leurs coffres, assurez-vous de pouvoir accéder aux coffres. Concevez votre application pour gérer les situations où un locataire modifie ses contrôles d’accès réseau et vous empêche d’accéder à ses 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 :
- Comment choisir entre Azure Key Vault et le service HSM dédié Azure ?
- Azure HSM dédié est-il fait pour vous ?
Contributeurs
Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.
Auteur principal :
- John Downs | Ingénieur logiciel principal
Autres contributeurs :
- Jack Lichwa | Gestionnaire de produit principal, Azure Key Vault
- Arsen Vladimirskiy | Ingénieur client principal, FastTrack for Azure
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.