Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Considérations relatives à la conception multi-locataires d'Amazon Verified Permissions
Plusieurs options de conception sont à prendre en compte lorsque vous implémentez l'autorisation à l'aide d'Amazon Verified Permissions dans une solution SaaS à locataires multiples. Avant d'explorer ces options, clarifiez la différence entre l'*isolation et l'**autorisation* dans un contexte SaaS multi-locataires. [L'isolation](https://docs.aws.amazon.com/whitepapers/latest/saas-architecture-fundamentals/tenant-isolation.html) d'un tenant empêche que les données entrantes et sortantes soient exposées au mauvais locataire. L'autorisation garantit qu'un utilisateur dispose des autorisations nécessaires pour accéder à un locataire.
Dans Autorisations vérifiées, les politiques sont stockées dans un magasin de politiques. Comme décrit dans la [documentation sur les autorisations vérifiées](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/design-multi-tenancy-considerations.html), vous pouvez soit isoler les politiques des locataires en utilisant un magasin de politiques distinct pour chaque locataire, soit autoriser les locataires à partager des politiques en utilisant un magasin de politiques unique pour tous les locataires. Cette section décrit les avantages et les inconvénients de ces deux stratégies d'isolation et décrit comment elles peuvent être déployées à l'aide d'un modèle de déploiement à plusieurs niveaux. Pour plus de contexte, consultez la documentation sur les autorisations vérifiées.
Bien que les critères abordés dans cette section soient axés sur les autorisations vérifiées, les concepts généraux sont ancrés dans l'[état d'esprit d'isolement](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/isolation-mindset.html) et les conseils qu'il fournit. Les applications SaaS doivent toujours prendre en compte [l'isolation des locataires](https://docs.aws.amazon.com/whitepapers/latest/saas-architecture-fundamentals/tenant-isolation.html) dans le cadre de leur conception, et ce principe général d'isolation s'étend à l'inclusion des autorisations vérifiées dans une application SaaS. Cette section fait également référence aux principaux modèles d'isolation SaaS tels que le modèle [SaaS en silo et le modèle SaaS](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/silo-isolation.html) [mutualisé](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/pool-isolation.html). Pour plus d'informations, consultez les [principaux concepts d'isolation](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/core-isolation-concepts.html) dans le AWS Well-Architected Framework, SaaS Lens.
Les principales considérations à prendre en compte lors de la conception de solutions SaaS multi-locataires sont l'isolation et l'intégration des locataires. L'isolement des locataires a un impact sur la sécurité, la confidentialité, la résilience et les performances. L'intégration des locataires a un impact sur vos processus opérationnels en ce qui concerne les frais opérationnels et l'observabilité. Organisations qui optent pour le SaaS ou qui mettent en œuvre des solutions mutualisées doivent toujours prioriser la manière dont la location sera gérée par l'application SaaS. Bien qu'une solution SaaS puisse s'appuyer sur un modèle d'isolation particulier, la cohérence n'est pas nécessairement requise dans l'ensemble de la solution SaaS. Par exemple, le modèle d'isolation que vous choisissez pour les composants frontaux de votre application n'est peut-être pas le même que le modèle d'isolation que vous choisissez pour un microservice ou des services d'autorisation.
**Topics**
+ [Intégration des locataires et enregistrement des locataires utilisateurs](avp-design-onboarding-registration.md)
+ [Boutique de politiques par locataire](avp-design-per-tenant-store.md)
+ [Un magasin de politiques partagé par plusieurs locataires](avp-design-shared-store.md)
+ [Modèle de déploiement à plusieurs niveaux](avp-design-tiered.md)
# Intégration des locataires et enregistrement des locataires utilisateurs
Les applications SaaS respectent le concept des [identités SaaS](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/saas-identity.html) et suivent les meilleures pratiques générales qui consistent à [lier l'identité d'un utilisateur à l'identité d'un locataire](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/general-design-principles.html). La liaison implique le stockage d'un identifiant de locataire sous forme de réclamation ou d'attribut pour l'utilisateur dans le fournisseur d'identité. Cela déplace la responsabilité de mapper les identités aux locataires de chaque application au processus d'enregistrement des utilisateurs. Chaque utilisateur authentifié possède alors l'identité de locataire correcte dans le cadre du jeton Web JSON (JWT).
De même, la sélection du magasin de politiques approprié pour une demande d'autorisation ne doit pas être déterminée par la logique de l'application. Pour déterminer quel magasin de politiques doit être utilisé par une demande d'autorisation particulière, établissez un mappage entre les utilisateurs et les magasins de politiques, ou entre les locataires et les magasins de politiques. Ces mappages sont généralement conservés dans un magasin de données tel qu'Amazon DynamoDB ou Amazon Relational Database Service (Amazon RDS) auquel votre application fait référence. Vous pouvez également fournir ou compléter ces mappages par les données d'un fournisseur d'identité (IdP). La relation entre les locataires, les utilisateurs et les magasins de politiques est ensuite généralement fournie à un utilisateur via un JWT qui contient toutes les relations nécessaires à une demande d'autorisation.
Cet exemple montre comment le JWT peut apparaître pour l'utilisateur`Alice`, qui appartient au locataire `TenantA` et utilise le magasin de politiques avec l'ID du magasin de politiques `ps-43214321` pour l'autorisation.
```
{
"sub":"1234567890",
"name":"Alice",
"tenant":"TenantA",
"policyStoreId":"ps-43214321"
}
```
# Boutique de politiques par locataire
Le modèle de conception de magasin de politiques par locataire d'Amazon Verified Permissions associe chaque locataire d'une application SaaS à son propre magasin de politiques. Ce modèle est similaire au modèle d'[isolation des silos](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/silo-isolation.html) en mode SaaS. Les deux modèles imposent la création d'une infrastructure spécifique au locataire et présentent des avantages et des inconvénients similaires. Les principaux avantages de cette approche sont l'isolation des locataires imposée par l'infrastructure, la prise en charge de modèles d'autorisation uniques par locataire, l'élimination des problèmes de [voisinage bruyants](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/noisy-neighbor.html) et la réduction de l'impact en cas d'échec des mises à jour des politiques ou des déploiements. Les inconvénients de cette approche incluent des processus d'intégration des locataires, des déploiements et des opérations plus complexes. Le magasin de politiques par locataire est l'approche recommandée si la solution dispose de politiques uniques par locataire.
Le modèle de magasin de politiques par locataire peut fournir une approche très cloisonnée de l'isolation des locataires, si votre application SaaS l'exige. Vous pouvez également utiliser ce modèle avec [l'isolation du pool](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/pool-isolation.html), mais votre implémentation des autorisations vérifiées ne bénéficiera pas des avantages standard d'un modèle d'isolation de pool plus large, tels que la simplification de la gestion et des opérations.
Dans un magasin de politiques par locataire, l'isolation des locataires est obtenue en mappant l'identifiant du magasin de politiques d'un locataire à l'identité SaaS de l'utilisateur pendant le processus d'enregistrement de l'utilisateur, comme indiqué précédemment. Cette approche lie étroitement le magasin de politiques du locataire au principal utilisateur et fournit un moyen cohérent de partager la cartographie dans l'ensemble de la solution SaaS. Vous pouvez fournir le mappage à une application SaaS en le gérant dans le cadre d'un IdP ou dans une source de données externe telle que DynamoDB. Cela garantit également que le principal fait partie du locataire et que le magasin de polices du locataire est utilisé.
Cet exemple montre comment le JWT qui contient le `policyStoreId` et `tenant` d'un utilisateur est transmis du point de terminaison d'une API au point d'évaluation des politiques dans un AWS Lambda autorisateur, qui achemine la demande vers le magasin de politiques approprié.
![\[Modèle de magasin de politiques par locataire dans Amazon Verified Permissions\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-per-tenant.png)
L'exemple de politique suivant illustre le paradigme de conception du magasin de politiques par locataire. L'utilisateur `Alice` appartient à `TenantA.` The. policyStoreId `store-a` Il est également mappé à l'identité du locataire `Alice,` et impose l'utilisation du magasin de politiques approprié. Cela garantit que les politiques de `TenantA` sont utilisées.
**Note**
Le modèle de magasin de politiques par locataire isole les politiques des locataires. L'autorisation applique les actions que les utilisateurs sont autorisés à effectuer sur leurs données. Les ressources impliquées dans toute application hypothétique utilisant ce modèle doivent être isolées à l'aide d'autres mécanismes d'isolation, tels que définis dans la documentation de [AWS Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/core-isolation-concepts.html), SaaS Lens.
Dans cette politique, `Alice` est autorisé à consulter les données de toutes les ressources.
```
permit (
principal == MultiTenantApp::User::"Alice",
action == MultiTenantApp::Action::"viewData",
resource
);
```
Pour effectuer une demande d'autorisation et démarrer une évaluation avec une politique d'autorisations vérifiées, vous devez fournir l'ID du magasin de politiques qui correspond à l'identifiant unique mappé au locataire. `store-a`
```
{
"policyStoreId":"store-a",
"principal":{
"entityType":"MultiTenantApp::User",
"entityId":"Alice"
},
"action":{
"actionType":"MultiTenantApp::Action",
"actionId":"viewData"
},
"resource":{
"entityType":"MultiTenantApp::Data",
"entityId":"my_example_data"
},
"entities":{
"entityList":[
[
{
"identifier":{
"entityType":"MultiTenantApp::User",
"entityId":"Alice"
},
"attributes":{},
"parents":[]
},
{
"identifier":{
"entityType":"MultiTenantApp::Data",
"entityId":"my_example_data"
},
"attributes":{},
"parents":[]
}
]
]
}
}
```
L'utilisateur `Bob` appartient au locataire B et policyStoreId `store-b` est également mappé à l'identité du locataire de`Bob`, ce qui impose l'utilisation du magasin de politiques approprié. Cela garantit que les politiques du locataire B sont utilisées.
Dans cette politique, `Bob` est autorisé à personnaliser les données de toutes les ressources. Dans cet exemple, il `customizeData` peut s'agir d'une action spécifique uniquement au locataire B, de sorte que la politique serait unique pour le locataire B. Le modèle de magasin de politiques par locataire prend en charge intrinsèquement les politiques personnalisées sur une base par locataire.
```
permit (
principal == MultiTenantApp::User::"Bob",
action == MultiTenantApp::Action::"customizeData",
resource
);
```
Pour effectuer une demande d'autorisation et démarrer une évaluation avec une politique d'autorisations vérifiées, vous devez fournir l'ID du magasin de politiques qui correspond à l'identifiant unique mappé au locataire. `store-b`
```
{
"policyStoreId":"store-b",
"principal":{
"entityType":"MultiTenantApp::User",
"entityId":"Bob"
},
"action":{
"actionType":"MultiTenantApp::Action",
"actionId":"customizeData"
},
"resource":{
"entityType":"MultiTenantApp::Data",
"entityId":"my_example_data"
},
"entities":{
"entityList":[
[
{
"identifier":{
"entityType":"MultiTenantApp::User",
"entityId":"Bob"
},
"attributes":{},
"parents":[]
},
{
"identifier":{
"entityType":"MultiTenantApp::Data",
"entityId":"my_example_data"
},
"attributes":{},
"parents":[]
}
]
]
}
}
```
Avec les autorisations vérifiées, il est possible, mais pas obligatoire, d'intégrer un IdP à un magasin de politiques. Cette intégration permet aux politiques de faire explicitement référence au principal dans le magasin d'identités en tant que principal des politiques. [Pour plus d'informations sur l'intégration à Amazon Cognito en tant qu'IdP pour les autorisations vérifiées, consultez la documentation relative aux autorisations vérifiées et la documentation [Amazon](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/identity-providers.html) Cognito.](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-authorization-with-avp.html)
Lorsque vous intégrez un magasin de politiques à un IdP, vous ne pouvez utiliser qu'une seule [source d'identité](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/identity-providers.html) par magasin de politiques. Par exemple, si vous choisissez d'intégrer les autorisations vérifiées à Amazon Cognito, vous devez suivre la stratégie utilisée pour isoler les locataires des boutiques de politiques relatives aux autorisations vérifiées et des groupes d'utilisateurs Amazon Cognito. Les magasins de politiques et les groupes d'utilisateurs doivent également se trouver dans le même emplacement Compte AWS.
![\[Intégration des autorisations vérifiées à Amazon Cognito dans le modèle de conception par locataire\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/cognito-per-tenant.png)
Sur le plan opérationnel, le magasin de politiques par locataire présente un avantage en matière d'audit, car vous pouvez facilement interroger l'[activité enregistrée](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/monitoring-overview.html)AWS CloudTrail indépendamment pour chaque locataire. Cependant, nous vous recommandons tout de même de consigner des statistiques personnalisées supplémentaires sur une dimension par locataire sur Amazon CloudWatch.
L'approche du magasin de politiques par locataire nécessite également de porter une attention particulière à deux [quotas d'autorisations vérifiées](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/quotas.html) afin de garantir qu'ils n'interfèrent pas avec le fonctionnement de votre solution SaaS. Ces quotas sont des *Policy Stores par région et par compte* et des *IsAuthorized demandes par seconde, par région et par compte*. Vous pouvez demander des augmentations pour les deux quotas.
Pour un exemple plus détaillé de la mise en œuvre du modèle de magasin de politiques par locataire, consultez le billet de AWS blog sur le [contrôle d'accès SaaS à l'aide d'Amazon Verified Permissions avec un magasin de politiques par locataire](https://aws.amazon.com/blogs/security/saas-access-control-using-amazon-verified-permissions-with-a-per-tenant-policy-store/).
# Un magasin de politiques partagé par plusieurs locataires
Le modèle de conception d'une boutique de politiques multi-locataires partagée utilise une seule boutique de politiques multi-locataires dans Amazon Verified Permissions pour tous les locataires de la solution SaaS. Le principal avantage de cette approche est la simplification de la gestion et des opérations, notamment parce que vous n'avez pas à créer de magasins de polices supplémentaires lors de l'intégration des locataires. Les inconvénients de cette approche incluent une augmentation de l'impact en cas de défaillance ou d'erreur lors de la mise à jour des politiques ou des déploiements, et une plus grande exposition aux effets de [voisinage bruyants](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/noisy-neighbor.html). De plus, nous ne recommandons pas cette approche si votre solution nécessite des politiques uniques pour chaque locataire. Dans ce cas, utilisez plutôt le modèle de magasin de politiques par locataire pour garantir que les politiques du bon locataire sont utilisées.
L'approche d'un magasin de politiques mutualisé partagé est similaire au modèle d'[isolation mutualisé](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/pool-isolation.html) SaaS. Il peut fournir une approche groupée pour isoler les locataires, si votre application SaaS l'exige. Vous pouvez également utiliser ce modèle si votre solution SaaS applique une [isolation cloisonnée](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/silo-isolation.html) à ses microservices. Lorsque vous choisissez un modèle, vous devez évaluer les exigences relatives à l'isolation des données des locataires et à la structure des politiques d'autorisations vérifiées qui sont nécessaires pour une application SaaS de manière indépendante.
Pour appliquer une méthode cohérente de partage de l'identifiant du locataire dans l'ensemble de votre solution SaaS, il est recommandé de mapper l'identifiant à l'identité SaaS de l'utilisateur lors de son enregistrement, comme indiqué précédemment. Vous pouvez fournir ce mappage à une application SaaS en le gérant dans le cadre d'un IdP ou dans une source de données externe telle que DynamoDB. Nous vous recommandons également de mapper l'ID du magasin de politiques partagé aux utilisateurs. Bien que l'identifiant ne soit pas utilisé pour isoler les locataires, il s'agit d'une bonne pratique car elle facilite les changements futurs.
L'exemple suivant montre comment le point de terminaison de l'API envoie un JWT pour les utilisateurs `Alice` et `Bob` les utilisateurs qui appartiennent à des locataires différents mais partagent le magasin de politiques avec l'ID du magasin de politiques à des `store-multi-tenant` fins d'autorisation. Comme tous les locataires partagent un seul magasin de politiques, il n'est pas nécessaire de conserver l'ID du magasin de politiques dans un jeton ou une base de données. Étant donné que tous les locataires partagent un même identifiant de magasin de politiques, vous pouvez fournir cet identifiant en tant que variable d'environnement que votre application peut utiliser pour appeler le magasin de politiques.
![\[Modèle de conception partagé avec autorisations vérifiées\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-shared.png)
L'exemple de politique suivant illustre le paradigme de conception d'une politique partagée par plusieurs locataires. Dans cette politique, le principal `MultiTenantApp::User` qui a le parent `MultiTenantApp::Role` `Admin` est autorisé à consulter les données de toutes les ressources.
```
permit (
principal in MultiTenantApp::Role::"Admin",
action == MultiTenantApp::Action::"viewData",
resource
);
```
Étant donné qu'un seul magasin de politiques est utilisé, le magasin de politiques Verified Permissions doit garantir qu'un attribut de location associé au principal correspond à l'attribut de location associé à la ressource. Cela peut être accompli en incluant la politique suivante dans le magasin de politiques, afin de garantir que toutes les demandes d'autorisation dont les attributs de location ne correspondent pas à la ressource et au principal sont rejetées.
```
forbid(
principal,
action,
resource
)
unless {
resource.Tenant == principal.Tenant
};
```
Pour une demande d'autorisation qui utilise un modèle de magasin de politiques partagé à locataires multiples, l'ID du magasin de politiques est l'identifiant du magasin de politiques partagé. Dans la demande suivante, l'accès `User` `Alice` est autorisé car elle possède un `Role` de`Admin`, et les `Tenant` attributs associés à la ressource et au principal sont les deux`TenantA`.
```
{
"policyStoreId":"store-multi-tenant",
"principal":{
"entityType":"MultiTenantApp::User",
"entityId":"Alice"
},
"action":{
"actionType":"MultiTenantApp::Action",
"actionId":"viewData"
},
"resource":{
"entityType":"MultiTenantApp::Data",
"entityId":"my_example_data"
},
"entities":{
"entityList":[
{
"identifier":{
"entityType":"MultiTenantApp::User",
"entityId":"Alice"
},
"attributes": {
{
"Tenant": {
"entityIdentifier": {
"entityType":"MultitenantApp::Tenant",
"entityId":"TenantA"
}
}
}
},
"parents":[
{
"entityType":"MultiTenantApp::Role",
"entityId":"Admin"
}
]
},
{
"identifier":{
"entityType":"MultiTenantApp::Data",
"entityId":"my_example_data"
},
"attributes": {
{
"Tenant": {
"entityIdentifier": {
"entityType":"MultitenantApp::Tenant",
"entityId":"TenantA"
}
}
}
},
"parents":[]
}
]
}
}
```
Avec les autorisations vérifiées, il est possible, mais pas obligatoire, d'intégrer un IdP à un magasin de politiques. Cette intégration permet aux politiques de faire explicitement référence au principal dans le magasin d'identités en tant que principal des politiques. [Pour plus d'informations sur l'intégration à Amazon Cognito en tant qu'IdP pour les autorisations vérifiées, consultez la documentation relative aux autorisations vérifiées et la documentation [Amazon](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/identity-providers.html) Cognito.](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-authorization-with-avp.html)
Lorsque vous intégrez un magasin de politiques à un IdP, vous ne pouvez utiliser qu'une seule [source d'identité](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/identity-providers.html) par magasin de politiques. Par exemple, si vous choisissez d'intégrer les autorisations vérifiées à Amazon Cognito, vous devez suivre la stratégie utilisée pour isoler les locataires des boutiques de politiques relatives aux autorisations vérifiées et des groupes d'utilisateurs Amazon Cognito. Les magasins de politiques et les groupes d'utilisateurs doivent également se trouver dans le même emplacement Compte AWS.
![\[Intégration des autorisations vérifiées à Amazon Cognito dans un modèle de conception partagé\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/cognito-shared.png)
Du point de vue de l'exploitation et de l'audit, le modèle de magasin de règles partagé par plusieurs locataires présente un inconvénient [dans la mesure où l'activité enregistrée AWS CloudTrail](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/monitoring-overview.html) nécessite des requêtes plus complexes pour filtrer l'activité individuelle du locataire, car chaque CloudTrail appel enregistré utilise le même magasin de politiques. Dans ce scénario, il est utile d'enregistrer des métriques personnalisées supplémentaires sur une dimension par locataire sur Amazon CloudWatch afin de garantir un niveau approprié d'observabilité et de capacité d'audit.
L'approche d'un magasin de politiques mutualisé partagé nécessite également une attention particulière aux [quotas d'autorisations vérifiées](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/quotas.html) afin de garantir qu'ils n'interfèrent pas avec le fonctionnement de votre solution SaaS. Nous vous recommandons notamment de surveiller les *IsAuthorized demandes par seconde, par région et par quota de compte* afin de vous assurer que ses limites ne sont pas dépassées. Vous pouvez demander une augmentation de ce quota.
# Modèle de déploiement à plusieurs niveaux
En créant un modèle de déploiement à plusieurs niveaux, vous pouvez isoler les locataires « niveau entreprise » hautement prioritaires du volume potentiellement plus élevé de clients « niveau standard ». Dans ce modèle, vous pouvez déployer les modifications apportées aux politiques dans les magasins de politiques séparément pour chaque niveau, ce qui permet d'isoler chaque niveau de clients des modifications apportées en dehors de son niveau. Dans le modèle de déploiement hiérarchisé, les magasins de politiques sont généralement créés dans le cadre du provisionnement initial de l'infrastructure pour chaque niveau au lieu d'être déployés lors de l'intégration d'un locataire.
Si votre solution utilise principalement un modèle d'isolation groupée, vous aurez peut-être besoin d'une isolation ou d'une personnalisation supplémentaires. Par exemple, vous pouvez créer un « niveau Premium » dans lequel chaque locataire disposerait de sa propre infrastructure de niveau locataire, ce qui crée un modèle cloisonné en déployant une instance groupée avec un seul locataire. Cela pourrait prendre la forme d'infrastructures « Premium Tier A » et « Premium Tier Tenant B » complètement séparées, y compris des magasins d'assurance. Cette approche aboutit à un modèle d'isolation cloisonné pour le plus haut niveau de clients.
Dans le modèle de déploiement hiérarchisé, chaque magasin de politiques doit suivre le même modèle d'isolation, bien qu'il soit déployé séparément. Étant donné que plusieurs magasins de politiques sont utilisés, vous devez appliquer une méthode cohérente de partage de l'identifiant du magasin de politiques associé au locataire dans l'ensemble de la solution SaaS. Comme dans le cas du modèle de magasin de politiques par locataire, il est recommandé de mapper l'identifiant du locataire à l'identité SaaS de l'utilisateur lors de son inscription.
Le schéma suivant montre trois niveaux : `Standard Tier``Enterprise Tier`, et`Premium Tier 1`. Chaque niveau est déployé séparément dans sa propre infrastructure et utilise un magasin de politiques partagé au sein du niveau. Les niveaux Standard et Enterprise contiennent plusieurs locataires. `TenantA`et `TenantB` se situent dans `Standard Tier` le niveau `TenantC` et `TenantD` sont dans le niveau Enterprise.
`Premium Tier 1`contient uniquement`TenantP`, de sorte que vous pouvez servir le locataire premium comme si la solution reposait sur un modèle d'isolation totalement cloisonné et fournir des fonctionnalités telles que des politiques personnalisées. L'intégration d'un nouveau client haut de gamme entraînerait la création d'une `Premium Tier 2` infrastructure.
**Note**
L'application, le déploiement et l'intégration des locataires dans le niveau premium sont identiques aux niveaux standard et entreprise. La seule différence est que le flux de travail d'intégration de niveau supérieur commence par le provisionnement d'une nouvelle infrastructure de niveau.
![\[Modèle de déploiement hiérarchisé avec autorisations vérifiées\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-tiered-deployment.png)