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.
# Implémentation d'un PDP à l'aide des autorisations vérifiées par Amazon
Amazon Verified Permissions est un service de gestion des autorisations et d'autorisation évolutif et détaillé que vous pouvez utiliser pour mettre en œuvre un point de décision politique (PDP). En tant que moteur de politiques, il peut aider votre application à vérifier les actions des utilisateurs en temps réel et à mettre en évidence les autorisations trop privilégiées ou non valides. Il aide vos développeurs à créer des applications plus sécurisées plus rapidement en externalisant les autorisations et en centralisant la gestion et l'administration des politiques. En séparant la logique d'autorisation de la logique d'application, Verified Permissions permet le découplage des politiques.
En utilisant les autorisations vérifiées pour implémenter un PDP et en implémentant le moindre privilège et la vérification continue au sein des applications, les développeurs peuvent aligner l'accès à leurs applications sur les principes du [Zero Trust](https://aws.amazon.com/security/zero-trust/). En outre, les équipes de sécurité et d'audit peuvent mieux analyser et auditer qui a accès à quelles ressources au sein d'une application. Verified Permissions utilise [Cedar](https://www.cedarpolicy.com/en), un langage de politique open source spécialement conçu et axé sur la sécurité, pour définir des contrôles d'accès basés sur des politiques basés sur le contrôle d'accès basé sur les rôles (RBAC) et le contrôle d'accès basé sur les attributs (ABAC) pour un contrôle d'accès plus granulaire et contextuel.
Les autorisations vérifiées fournissent des fonctionnalités utiles pour les applications SaaS, telles que la possibilité d'activer l'autorisation multi-locataires en utilisant plusieurs fournisseurs d'identité tels qu'Amazon Cognito, Google et Facebook. Une autre fonctionnalité d'autorisations vérifiées particulièrement utile pour les applications SaaS est la prise en charge des rôles personnalisés par locataire. Si vous concevez un système de gestion de la relation client (CRM), un locataire peut définir la granularité de l'accès par opportunités de vente en fonction d'un ensemble de critères particuliers. Un autre locataire peut avoir une autre définition. Les systèmes d'autorisations sous-jacents de Verified Permissions peuvent prendre en charge ces variations, ce qui en fait un excellent candidat pour les cas d'utilisation du SaaS. Les autorisations vérifiées permettent également de rédiger des politiques qui s'appliquent à tous les locataires. Il est donc simple d'appliquer des politiques de protection pour empêcher tout accès non autorisé en tant que fournisseur de SaaS.
![\[Utiliser les autorisations vérifiées d'Amazon pour implémenter un PDP\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp.png)
**Pourquoi utiliser des autorisations vérifiées ?**
Utilisez les autorisations vérifiées auprès d'un fournisseur d'identité tel qu'[Amazon Cognito](https://aws.amazon.com/cognito/) pour bénéficier d'une solution de gestion des accès plus dynamique et basée sur des règles pour vos applications. Vous pouvez créer des applications qui aident les utilisateurs à partager des informations et à collaborer tout en préservant la sécurité, la confidentialité et la confidentialité de leurs données. Les autorisations vérifiées contribuent à réduire les coûts opérationnels en vous fournissant un système d'autorisation précis pour appliquer l'accès en fonction des rôles et des attributs de vos identités et de vos ressources. Vous pouvez définir votre modèle de politique, créer et stocker des politiques dans un emplacement central et évaluer les demandes d'accès en quelques millisecondes.
Dans Verified Permissions, vous pouvez exprimer des autorisations à l'aide d'un langage déclaratif simple et lisible par l'homme appelé Cedar. Les politiques rédigées dans Cedar peuvent être partagées entre les équipes quel que soit le langage de programmation utilisé par l'application de chaque équipe.
**Points à prendre en compte lorsque vous utilisez des autorisations vérifiées**
Dans Autorisations vérifiées, vous pouvez créer des politiques et les automatiser dans le cadre du provisionnement. Vous pouvez également créer des politiques au moment de l'exécution dans le cadre de la logique de l'application. La meilleure pratique consiste à utiliser un pipeline d'intégration et de déploiement continus (CI/CD) pour administrer, modifier et suivre les versions des politiques lorsque vous créez des politiques dans le cadre de l'intégration et du provisionnement des locataires. Une application peut également administrer, modifier et suivre les versions des politiques ; toutefois, la logique de l'application n'exécute pas intrinsèquement cette fonctionnalité. Pour prendre en charge ces fonctionnalités dans votre application, vous devez explicitement concevoir votre application pour implémenter cette fonctionnalité.
S'il est nécessaire de fournir des données externes provenant d'autres sources pour prendre une décision d'autorisation, ces données doivent être récupérées et fournies à Verified Permissions dans le cadre de la demande d'autorisation. Le contexte, les entités et les attributs supplémentaires ne sont pas récupérés par défaut avec ce service.
# Aperçu du cèdre
Cedar est un langage de contrôle d'accès flexible, extensible et évolutif basé sur des politiques qui aide les développeurs à exprimer les autorisations des applications sous forme de politiques. Les administrateurs et les développeurs peuvent définir des politiques qui autorisent ou interdisent aux utilisateurs d'agir sur les ressources de l'application. Plusieurs politiques peuvent être associées à une seule ressource. Lorsqu'un utilisateur de votre application essaie d'effectuer une action sur une ressource, votre application demande l'autorisation du moteur de politiques Cedar. Cedar évalue les politiques applicables et renvoie une `ALLOW` `DENY` décision. Cedar prend en charge les règles d'autorisation pour tout type de principal et de ressource, permet le contrôle d'accès basé sur les rôles (RBAC) et le contrôle d'accès basé sur les attributs (ABAC), et soutient l'analyse grâce à des outils de raisonnement automatisés.
Cedar vous permet de séparer votre logique métier de la logique d'autorisation. Lorsque vous faites des demandes à partir du code de votre application, vous appelez le moteur d'autorisation de Cedar pour déterminer si la demande est autorisée. Si elle est autorisée (la décision l'est`ALLOW`), votre application peut effectuer l'opération demandée. Si elle n'est pas autorisée (la décision l'est`DENY`), votre application peut renvoyer un message d'erreur. Les principales caractéristiques du cèdre incluent :
+ **Expressivité** — Cedar est spécialement conçu pour prendre en charge les cas d'utilisation des autorisations et a été développé dans un souci de lisibilité humaine.
+ **Performance** — Cedar prend en charge les politiques d'indexation pour une extraction rapide et fournit une évaluation en temps réel rapide et évolutive avec une latence limitée.
+ **Analyse** — Cedar propose des outils d'analyse qui peuvent optimiser vos politiques et vérifier votre modèle de sécurité.
Pour plus d'informations, consultez le [site Web de Cedar](https://www.cedarpolicy.com/).
# Exemple 1 : ABAC de base avec autorisations vérifiées et Cedar
Dans cet exemple de scénario, Amazon Verified Permissions est utilisé pour déterminer quels utilisateurs sont autorisés à accéder aux informations d'un microservice de paie fictif. Cette section inclut des extraits de code Cedar pour montrer comment utiliser Cedar pour prendre des décisions en matière de contrôle d'accès. Ces exemples ne sont pas destinés à fournir une exploration complète des fonctionnalités fournies par Cedar et Verified Permissions. Pour une présentation plus complète de Cedar, consultez la [documentation de Cedar](https://docs.cedarpolicy.com/).
Dans le schéma suivant, nous aimerions appliquer deux règles commerciales générales associées à la `viewSalary` `GET` méthode : les *employés peuvent consulter leur propre salaire* et les *employés peuvent consulter le salaire de toute personne relevant d'eux.* Vous pouvez appliquer ces règles commerciales en utilisant les politiques d'autorisations vérifiées.
![\[Exemple d'implémentation ABAC de base avec Amazon Verified Permissions et Cedar pour implémenter un PDP\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-example-1.png)
*Les employés peuvent consulter leur propre salaire.*
Dans Cedar, la construction de base est une *entité* qui représente un principe, une action ou une ressource. Pour effectuer une demande d'autorisation et démarrer une évaluation avec une politique d'autorisations vérifiées, vous devez fournir un *principal,* une *action*, une *ressource* et une *liste d'entités.*
+ Le principal (`principal`) est l'utilisateur ou le rôle connecté.
+ L'action (`action`) est l'opération évaluée par la demande.
+ La ressource (`resource`) est le composant auquel l'action accède.
+ La liste des entités (`entityList`) contient toutes les entités requises pour évaluer la demande.
Pour satisfaire à la règle commerciale, *les employés peuvent consulter leur propre salaire*, vous pouvez fournir une politique d'autorisations vérifiées telle que la suivante.
```
permit (
principal,
action == Action::"viewSalary",
resource
)
when {
principal == resource.owner
};
```
Cette politique évalue `ALLOW` si le propriétaire de l'attribut `Action` est égal au principal `viewSalary` et si la ressource contenue dans la demande est le même. Par exemple, si Bob est l'utilisateur connecté qui a demandé le rapport salarial et qu'il est également le propriétaire du rapport salarial, la politique est évaluée à`ALLOW`.
La demande d'autorisation suivante est soumise à Verified Permissions pour être évaluée par l'exemple de politique. Dans cet exemple, Bob est l'utilisateur connecté qui fait la `viewSalary` demande. Bob est donc le principal du type d'entité`Employee`. L'action que Bob essaie d'effectuer est `viewSalary,` et la ressource qui s'`viewSalary`affichera est `Salary-Bob` de type`Salary`. Afin d'évaluer si Bob peut visualiser la `Salary-Bob` ressource, vous devez fournir une structure d'entité qui lie le type `Employee` avec une valeur de `Bob` (le principal) à l'attribut propriétaire de la ressource qui possède le type`Salary`. Vous fournissez cette structure dans un`entityList`, où les attributs associés à `Salary` incluent un propriétaire, qui spécifie et `entityIdentifier` qui contient le type `Employee` et la valeur`Bob`. Verified Permissions compare les informations `principal` fournies dans la demande d'autorisation à `owner` l'attribut associé à la `Salary` ressource pour prendre une décision.
```
{
"policyStoreId": "PAYROLLAPP_POLICYSTOREID",
"principal": {
"entityType": "PayrollApp::Employee",
"entityId": "Bob"
},
"action": {
"actionType": "PayrollApp::Action",
"actionId": "viewSalary"
},
"resource": {
"entityType": "PayrollApp::Salary",
"entityId": "Salary-Bob"
},
"entities": {
"entityList": [
{
"identifier": {
"entityType": "PayrollApp::Salary",
"entityId": "Salary-Bob"
},
"attributes": {
"owner": {
"entityIdentifier": {
"entityType": "PayrollApp::Employee",
"entityId": "Bob"
}
}
}
},
{
"identifier": {
"entityType": "PayrollApp::Employee",
"entityId": "Bob"
},
"attributes": {}
}
]
}
}
```
La demande d'autorisation adressée à Verified Permissions renvoie le résultat suivant, où l'attribut `decision` est `ALLOW` ou`DENY`.
```
{
"determiningPolicies":
[
{
"determiningPolicyId": "PAYROLLAPP_POLICYSTOREID"
}
],
"decision": "ALLOW",
"errors": []
}
```
Dans ce cas, comme Bob essayait de consulter son propre salaire, la demande d'autorisation envoyée à Verified Permissions est évaluée à`ALLOW`. Cependant, notre objectif était d'utiliser les autorisations vérifiées pour appliquer deux règles commerciales. La règle métier qui stipule ce qui suit doit également être vraie :
*Les employés peuvent consulter le salaire de toute personne relevant d'eux.*
Pour satisfaire à cette règle commerciale, vous pouvez définir une autre politique. La politique suivante détermine `ALLOW` si l'action est effectuée `viewSalary` et si la ressource contenue dans la demande possède un attribut `owner.manager` égal au principal. Par exemple, si Alice est l'utilisateur connecté qui a demandé le rapport salarial et qu'Alice est la responsable du propriétaire du rapport, la politique est évaluée à`ALLOW`.
```
permit (
principal,
action == Action::"viewSalary",
resource
)
when {
principal == resource.owner.manager
};
```
La demande d'autorisation suivante est soumise à Verified Permissions pour être évaluée par l'exemple de politique. Dans cet exemple, Alice est l'utilisateur connecté qui fait la `viewSalary` demande. Alice est donc la principale et l'entité est du type`Employee`. L'action qu'Alice essaie d'effectuer est`viewSalary`, et la ressource qui s'`viewSalary`affichera est du type `Salary` avec une valeur de`Salary-Bob`. Pour évaluer si Alice peut consulter la `Salary-Bob` ressource, vous devez fournir une structure d'entité qui lie le type `Employee` avec une valeur de `Alice` à l'`manager`attribut, qui doit ensuite être associé à l'`owner`attribut du type `Salary` avec une valeur de`Salary-Bob`. Vous fournissez cette structure dans un`entityList`, où les attributs associés à `Salary` incluent un propriétaire, qui spécifie et `entityIdentifier` qui contient le type `Employee` et la valeur`Bob`. Les autorisations vérifiées vérifient d'abord l'`owner`attribut, qui est évalué en fonction du type `Employee` et de la valeur`Bob`. Ensuite, Verified Permissions évalue l'`manager`attribut associé `Employee` et le compare au principal fourni pour prendre une décision d'autorisation. Dans ce cas, la décision est prise `ALLOW` parce que les `resource.owner.manager` attributs `principal ` et sont équivalents.
```
{
"policyStoreId": "PAYROLLAPP_POLICYSTOREID",
"principal": {
"entityType": "PayrollApp::Employee",
"entityId": "Alice"
},
"action": {
"actionType": "PayrollApp::Action",
"actionId": "viewSalary"
},
"resource": {
"entityType": "PayrollApp::Salary",
"entityId": "Salary-Bob"
},
"entities": {
"entityList": [
{
"identifier": {
"entityType": "PayrollApp::Employee",
"entityId": "Alice"
},
"attributes": {
"manager": {
"entityIdentifier": {
"entityType": "PayrollApp::Employee",
"entityId": "None"
}
}
},
"parents": []
},
{
"identifier": {
"entityType": "PayrollApp::Salary",
"entityId": "Salary-Bob"
},
"attributes": {
"owner": {
"entityIdentifier": {
"entityType": "PayrollApp::Employee",
"entityId": "Bob"
}
}
},
"parents": []
},
{
"identifier": {
"entityType": "PayrollApp::Employee",
"entityId": "Bob"
},
"attributes": {
"manager": {
"entityIdentifier": {
"entityType": "PayrollApp::Employee",
"entityId": "Alice"
}
}
},
"parents": []
}
]
}
}
```
Jusqu'à présent, dans cet exemple, nous avons fourni les deux règles commerciales associées à la `viewSalary` méthode : les *employés peuvent consulter leur propre salaire* et les *employés peuvent consulter le salaire de toute personne relevant d'eux, aux* autorisations vérifiées sous forme de politiques visant à satisfaire aux conditions de chaque règle commerciale de manière indépendante. Vous pouvez également utiliser une seule politique d'autorisations vérifiées pour satisfaire aux conditions des deux règles commerciales :
*Les employés peuvent consulter leur propre salaire et celui de toute personne relevant d'eux.*
Lorsque vous utilisez la demande d'autorisation précédente, la politique suivante `ALLOW` détermine si l'action est `viewSalary` et si la ressource contenue dans la demande possède un attribut `owner.manager` égal à ou un attribut `owner` égal à. `principal` `principal`
```
permit (
principal,
action == PayrollApp::Action::"viewSalary",
resource
)
when {
principal == resource.owner.manager ||
principal == resource.owner
};
```
Par exemple, si Alice est l'utilisateur connecté qui demande le rapport salarial, et si Alice est soit la responsable du propriétaire, soit la propriétaire du rapport, alors la politique est évaluée à`ALLOW`.
Pour plus d'informations sur l'utilisation d'opérateurs logiques avec les politiques Cedar, consultez la [documentation de Cedar](https://docs.cedarpolicy.com/policies/syntax-operators.html).
# Exemple 2 : RBAC de base avec autorisations vérifiées et Cedar
Cet exemple utilise Verified Permissions et Cedar pour illustrer le RBAC de base. Comme mentionné précédemment, la structure de base de Cedar est une entité. Les développeurs définissent leurs propres entités et peuvent éventuellement créer des relations entre les entités. L'exemple suivant inclut trois types d'entités : `Users``Roles`, et`Problems`. `Students`et `Teachers` peuvent être considérées comme des entités du type `Role,` et chacune `User` peut être associée à zéro ou à l'un des`Roles`.
![\[Exemple d'implémentation RBAC de base avec Amazon Verified Permissions et Cedar pour implémenter un PDP\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-example-2.png)
Dans Cedar, ces relations sont exprimées en liant le `Role` `Student` au `User` `Bob` en tant que parent. Cette association regroupe logiquement tous les utilisateurs étudiants dans un seul groupe. Pour plus d'informations sur le regroupement dans Cedar, consultez la [documentation de Cedar](https://docs.cedarpolicy.com/overview/terminology.html#term-group).
La politique suivante évalue la décision `ALLOW` d'action `submitProblem,` pour tous les principaux liés au groupe logique `Students` de ce type. `Role`
```
permit (
principal in ElearningApp::Role::"Students",
action == ElearningApp::Action::"submitProblem",
resource
);
```
La politique suivante détermine la décision prise `ALLOW` pour l'action `submitProblem` ou `answerProblem` pour tous les principes liés au groupe logique `Teachers` du type. `Role`
```
permit (
principal in ElearningApp::Role::"Teachers",
action in [
ElearningApp::Action::"submitProblem",
ElearningApp::Action::"answerProblem"
],
resource
);
```
Afin d'évaluer les demandes avec ces politiques, le moteur d'évaluation doit savoir si le principal référencé dans la demande d'autorisation est membre du groupe approprié. Par conséquent, l'application doit transmettre les informations pertinentes relatives à l'appartenance au groupe au moteur d'évaluation dans le cadre de la demande d'autorisation. Cela se fait par le biais de la `entities` propriété, qui vous permet de fournir au moteur d'évaluation Cedar des données d'attribut et d'appartenance à un groupe pour le principal et la ressource impliqués dans l'appel d'autorisation. Dans le code suivant, l'appartenance à un groupe est indiquée par le fait `User::"Bob"` qu'un parent est appelé`Role::"Students"`.
```
{
"policyStoreId": "ELEARNING_POLICYSTOREID",
"principal": {
"entityType": "ElearningApp::User",
"entityId": "Bob"
},
"action": {
"actionType": "ElearningApp::Action",
"actionId": "answerProblem"
},
"resource": {
"entityType": "ElearningApp::Problem",
"entityId": "SomeProblem"
},
"entities": {
"entityList": [
{
"identifier": {
"entityType": "ElearningApp::User",
"entityId": "Bob"
},
"attributes": {},
"parents": [
{
"entityType": "ElearningApp::Role",
"entityId": "Students"
}
]
},
{
"identifier": {
"entityType": "ElearningApp::Problem",
"entityId": "SomeProblem"
},
"attributes": {},
"parents": []
}
]
}
}
```
Dans cet exemple, Bob est l'utilisateur connecté qui fait la `answerProblem` demande. Par conséquent, Bob est le principal et l'entité est du type`User`. L'action que Bob essaie d'effectuer est`answerProblem`. Afin d'évaluer si Bob peut effectuer l'`answerProblem`action, vous devez fournir une structure d'entité qui lie l'entité `User` à une valeur de `Bob` et lui attribue son appartenance au groupe en répertoriant une entité parent sous `Role::"Students"` le nom. Étant donné que les entités du groupe d'utilisateurs `Role::"Students"` sont uniquement autorisées à effectuer l'action`submitProblem`, cette demande d'autorisation est évaluée à`DENY`.
En revanche, si le type `User` qui a une valeur égale à `Alice` et qui fait partie du groupe `Role::"Teachers"` essaie d'exécuter l'`answerProblem`action, la demande d'autorisation est évaluée comme suit`ALLOW`, car la politique stipule que les principaux membres du groupe `Role::"Teachers"` sont autorisés à effectuer l'action `answerProblem` sur toutes les ressources. Le code suivant montre ce type de demande d'autorisation qui est évalué à`ALLOW`.
```
{
"policyStoreId": "ELEARNING_POLICYSTOREID",
"principal": {
"entityType": "ElearningApp::User",
"entityId": "Alice"
},
"action": {
"actionType": "ElearningApp::Action",
"actionId": "answerProblem"
},
"resource": {
"entityType": "ElearningApp::Problem",
"entityId": "SomeProblem"
},
"entities": {
"entityList": [
{
"identifier": {
"entityType": "ElearningApp::User",
"entityId": "Alice"
},
"attributes": {},
"parents": [
{
"entityType": "ElearningApp::Role",
"entityId": "Teachers"
}
]
},
{
"identifier": {
"entityType": "ElearningApp::Problem",
"entityId": "SomeProblem"
},
"attributes": {},
"parents": []
}
]
}
}
```
# Exemple 3 : contrôle d'accès multi-locataires avec RBAC
Pour développer l'exemple RBAC précédent, vous pouvez étendre vos exigences pour inclure la mutualisation du SaaS, qui est une exigence courante pour les fournisseurs de SaaS. Dans les solutions multi-locataires, l'accès aux ressources est toujours fourni au nom d'un locataire donné. En d'autres termes, les utilisateurs du locataire A ne peuvent pas voir les données du locataire B, même si ces données sont logiquement ou physiquement colocalisées dans un système. L'exemple suivant montre comment vous pouvez implémenter l'isolation des locataires en utilisant plusieurs [magasins de politiques d'autorisations vérifiées](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/policy-stores.html), et comment vous pouvez utiliser des rôles d'utilisateur pour définir des autorisations au sein du locataire.
L'utilisation du modèle de conception Per Tenant Policy Store est une bonne pratique pour maintenir l'isolement des locataires tout en mettant en œuvre un contrôle d'accès avec des autorisations vérifiées. Dans ce scénario, les demandes des utilisateurs du locataire A et du locataire B sont vérifiées par rapport à des magasins de politiques distincts, `DATAMICROSERVICE_POLICYSTORE_A` et`DATAMICROSERVICE_POLICYSTORE_B`, respectivement. Pour plus d'informations sur les considérations relatives à la conception des autorisations vérifiées pour les applications SaaS multi-locataires, consultez la section [Considérations relatives à la conception multi-locataires des autorisations vérifiées](avp-design-considerations.md).
![\[Exemple de contrôle d'accès multi-locataires avec RBAC, Amazon Verified Permissions et Cedar\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-example-3.png)
La politique suivante se trouve dans le magasin `DATAMICROSERVICE_POLICYSTORE_A` de politiques. Il vérifie que le principal fera partie du groupe `allAccessRole` de type`Role`. Dans ce cas, le principal sera autorisé à effectuer les `updateData` actions `viewData` et sur toutes les ressources associées au locataire A.
```
permit (
principal in MultitenantApp::Role::"allAccessRole",
action in [
MultitenantApp::Action::"viewData",
MultitenantApp::Action::"updateData"
],
resource
);
```
Les politiques suivantes se trouvent dans le magasin `DATAMICROSERVICE_POLICYSTORE_B` de politiques. La première politique vérifie que le principal fait partie du `updateDataRole` groupe de types`Role`. En supposant que tel soit le cas, il autorise les principaux à effectuer l'`updateData`action sur les ressources associées au locataire B.
```
permit (
principal in MultitenantApp::Role::"updateDataRole",
action == MultitenantApp::Action::"updateData",
resource
);
```
Cette deuxième politique stipule que les principaux qui font partie du `viewDataRole` groupe de types `Role` doivent être autorisés à effectuer l'`viewData`action sur les ressources associées au locataire B.
```
permit (
principal in MultitenantApp::Role::"viewDataRole",
action == MultitenantApp::Action::"viewData",
resource
);
```
La demande d'autorisation faite par le locataire A doit être envoyée au magasin de `DATAMICROSERVICE_POLICYSTORE_A` politiques et vérifiée par les politiques appartenant à ce magasin. Dans ce cas, cela est vérifié par la première politique décrite précédemment dans le cadre de cet exemple. Dans cette demande d'autorisation, le principal de type `User` avec une valeur `Alice` de demande d'effectuer l'`viewData`action. Le principal appartient au groupe `allAccessRole` de types`Role`. Alice essaie d'exécuter l'`viewData`action sur la `SampleData` ressource. Alice ayant un `allAccessRole` rôle à jouer, cette évaluation aboutit à une `ALLOW` décision.
```
{
"policyStoreId": "DATAMICROSERVICE_POLICYSTORE_A",
"principal": {
"entityType": "MultitenantApp::User",
"entityId": "Alice"
},
"action": {
"actionType": "MultitenantApp::Action",
"actionId": "viewData"
},
"resource": {
"entityType": "MultitenantApp::Data",
"entityId": "SampleData"
},
"entities": {
"entityList": [
{
"identifier": {
"entityType": "MultitenantApp::User",
"entityId": "Alice"
},
"attributes": {},
"parents": [
{
"entityType": "MultitenantApp::Role",
"entityId": "allAccessRole"
}
]
},
{
"identifier": {
"entityType": "MultitenantApp::Data",
"entityId": "SampleData"
},
"attributes": {},
"parents": []
}
]
}
}
```
Si, au contraire, vous consultez une demande faite par le locataire B`User Bob`, vous verrez quelque chose comme la demande d'autorisation suivante. La demande est envoyée au magasin de `DATAMICROSERVICE_POLICYSTORE_B` politiques car elle provient du locataire B. Dans cette demande, le principal `Bob` souhaite effectuer l'action `updateData` sur la ressource`SampleData`. Cependant, ne `Bob` fait pas partie d'un groupe ayant accès à l'action `updateData` sur cette ressource. La demande aboutit donc à une `DENY` décision.
```
{
"policyStoreId": "DATAMICROSERVICE_POLICYSTORE_B",
"principal": {
"entityType": "MultitenantApp::User",
"entityId": "Bob"
},
"action": {
"actionType": "MultitenantApp::Action",
"actionId": "updateData"
},
"resource": {
"entityType": "MultitenantApp::Data",
"entityId": "SampleData"
},
"entities": {
"entityList": [
{
"identifier": {
"entityType": "MultitenantApp::User",
"entityId": "Bob"
},
"attributes": {},
"parents": [
{
"entityType": "MultitenantApp::Role",
"entityId": "viewDataRole"
}
]
},
{
"identifier": {
"entityType": "MultitenantApp::Data",
"entityId": "SampleData"
},
"attributes": {},
"parents": []
}
]
}
}
```
Dans ce troisième exemple, `User Alice ` essaie d'exécuter l'`viewData`action sur la ressource`SampleData`. Cette demande est dirigée vers le magasin de `DATAMICROSERVICE_POLICYSTORE_A` politiques car le principal `Alice` appartient à la locataire A. `Alice` fait partie du groupe `allAccessRole` de ce type`Role`, ce qui lui permet d'effectuer l'`viewData`action sur les ressources. En tant que telle, la demande aboutit à une `ALLOW` décision.
```
{
"policyStoreId": "DATAMICROSERVICE_POLICYSTORE_A",
"principal": {
"entityType": "MultitenantApp::User",
"entityId": "Alice"
},
"action": {
"actionType": "MultitenantApp::Action",
"actionId": "viewData"
},
"resource": {
"entityType": "MultitenantApp::Data",
"entityId": "SampleData"
},
"entities": {
"entityList": [
{
"identifier": {
"entityType": "MultitenantApp::User",
"entityId": "Alice"
},
"attributes": {},
"parents": [
{
"entityType": "MultitenantApp::Role",
"entityId": "allAccessRole"
}
]
},
{
"identifier": {
"entityType": "MultitenantApp::Data",
"entityId": "SampleData"
},
"attributes": {},
"parents": []
}
]
}
}
```
# Exemple 4 : Contrôle d'accès multi-locataires avec RBAC et ABAC
Pour améliorer l'exemple RBAC présenté dans la section précédente, vous pouvez ajouter des attributs aux utilisateurs afin de créer une approche hybride RBAC-ABAC pour le contrôle d'accès multi-locataires. Cet exemple inclut les mêmes rôles que dans l'exemple précédent, mais ajoute l'attribut user `account_lockout_flag` et le paramètre de contexte`uses_mfa`. L'exemple adopte également une approche différente pour mettre en œuvre le contrôle d'accès multi-locataires en utilisant à la fois le RBAC et l'ABAC, et utilise un magasin de politiques partagé au lieu d'un magasin de politiques différent pour chaque locataire.
![\[Exemple de contrôle d'accès multi-locataires avec RBAC, ABAC, Amazon Verified Permissions et Cedar\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-example-4.png)
Cet exemple représente une solution SaaS multi-locataires dans laquelle vous devez fournir des décisions d'autorisation pour le locataire A et le locataire B, comme dans l'exemple précédent.
Pour implémenter la fonctionnalité de verrouillage utilisateur, l'exemple ajoute l'attribut `account_lockout_flag` au principal de l'`User`entité dans la demande d'autorisation. Cet indicateur verrouille l'accès des utilisateurs au système et `DENY` octroie tous les privilèges à l'utilisateur bloqué. L'`account_lockout_flag`attribut est associé à l'`User`entité et est actif `User` jusqu'à ce que le drapeau soit activement révoqué au cours de plusieurs sessions. L'exemple utilise la `when` condition pour évaluer`account_lockout_flag`.
L'exemple ajoute également des détails sur la demande et la session. Les informations contextuelles indiquent que la session a été authentifiée à l'aide de l'authentification multifactorielle. Pour implémenter cette validation, l'exemple utilise la `when` condition pour évaluer l'`uses_mfa`indicateur dans le cadre du champ de contexte. Pour plus d'informations sur les meilleures pratiques en matière d'ajout de contexte, consultez la [documentation de Cedar](https://docs.cedarpolicy.com/auth/entities-syntax.html).
```
permit (
principal in MultitenantApp::Role::"allAccessRole",
action in [
MultitenantApp::Action::"viewData",
MultitenantApp::Action::"updateData"
],
resource
)
when {
principal.account_lockout_flag == false &&
context.uses_mfa == true &&
resource in principal.Tenant
};
```
Cette politique empêche l'accès aux ressources à moins que celles-ci ne soient dans le même groupe que l'`Tenant`attribut du principal demandeur. Cette approche visant à maintenir l'isolement des locataires est appelée approche *One Shared Multi-Tenant Policy Store*. Pour plus d'informations sur les considérations relatives à la conception des autorisations vérifiées pour les applications SaaS multi-locataires, consultez la section [Considérations relatives à la conception multi-locataires des autorisations vérifiées](avp-design-considerations.md).
La politique garantit également que le directeur est membre de `allAccessRole` et limite les actions à `viewData` et`updateData`. En outre, cette politique vérifie que `account_lockout_flag` c'est le cas `false` et que la valeur de contexte de est `uses_mfa` évaluée à. `true`
De même, la politique suivante garantit que le principal et la ressource sont associés au même locataire, ce qui empêche l'accès entre locataires. Cette politique garantit également que le directeur est membre `viewDataRole` et limite les actions à`viewData`. En outre, il vérifie que la valeur de contexte `account_lockout_flag` est `false` et que la valeur de contexte de est `uses_mfa` évaluée à. `true`
```
permit (
principal in MultitenantApp::Role::"viewDataRole",
action == MultitenantApp::Action::"viewData",
resource
)
when {
principal.account_lockout_flag == false &&
context.uses_mfa == true &&
resource in principal.Tenant
};
```
La troisième politique est similaire à la précédente. La politique exige que la ressource soit membre du groupe correspondant à l'entité représentée par`principal.Tenant`. Cela garantit que le principal et la ressource sont associés au locataire B, ce qui empêche l'accès entre locataires. Cette politique garantit que le directeur est membre `updateDataRole` et limite les actions à`updateData`. En outre, cette politique vérifie que la valeur de contexte `account_lockout_flag` est `false` et que la valeur de contexte de est `uses_mfa` évaluée à. `true`
```
permit (
principal in MultitenantApp::Role::"updateDataRole",
action == MultitenantApp::Action::"updateData",
resource
)
when {
principal.account_lockout_flag == false &&
context.uses_mfa == true &&
resource in principal.Tenant
};
```
La demande d'autorisation suivante est évaluée selon les trois politiques décrites plus haut dans cette section. Dans cette demande d'autorisation, le principal de type `User` et avec une valeur de `Alice` fait une `updateData` demande avec le rôle`allAccessRole`. `Alice`possède l'attribut `Tenant` dont la valeur est`Tenant::"TenantA"`. L'action `Alice` que vous essayez d'exécuter est `updateData,` et la ressource à laquelle elle sera appliquée est `SampleData` du type`Data`. `SampleData`a `TenantA` comme entité mère.
Selon la première politique du magasin de `` politiques, `Alice` vous pouvez effectuer l'`updateData`action sur la ressource, en supposant que les conditions de la `when` clause de la politique sont remplies. La première condition exige que l'`principal.Tenant`attribut soit évalué à`TenantA`. La deuxième condition exige que l'attribut `account_lockout_flag` du principal soit`false`. La dernière condition exige que le contexte `uses_mfa` soit`true`. Les trois conditions étant remplies, la demande renvoie une `ALLOW` décision.
```
{
"policyStoreId": "DATAMICROSERVICE_POLICYSTORE",
"principal": {
"entityType": "MultitenantApp::User",
"entityId": "Alice"
},
"action": {
"actionType": "MultitenantApp::Action",
"actionId": "updateData"
},
"resource": {
"entityType": "MultitenantApp::Data",
"entityId": "SampleData"
},
"context": {
"contextMap": {
"uses_mfa": {
"boolean": true
}
}
},
"entities": {
"entityList": [
{
"identifier": {
"entityType": "MultitenantApp::User",
"entityId": "Alice"
},
"attributes": {
{
"account_lockout_flag": {
"boolean": false
},
"Tenant": {
"entityIdentifier": {
"entityType":"MultitenantApp::Tenant",
"entityId":"TenantA"
}
}
}
},
"parents": [
{
"entityType": "MultitenantApp::Role",
"entityId": "allAccessRole"
}
]
},
{
"identifier": {
"entityType": "MultitenantApp::Data",
"entityId": "SampleData"
},
"attributes": {},
"parents": [
{
"entityType": "MultitenantApp::Tenant",
"entityId": "TenantA"
}
]
}
]
}
}
```
# Exemple 5 : filtrage de l'interface utilisateur avec des autorisations vérifiées et Cedar
Vous pouvez également utiliser les autorisations vérifiées pour implémenter le filtrage RBAC des éléments de l'interface utilisateur en fonction des actions autorisées. Cela est extrêmement utile pour les applications qui comportent des éléments d'interface utilisateur contextuels susceptibles d'être associés à des utilisateurs ou à des locataires spécifiques dans le cas d'une application SaaS à locataires multiples.
Dans l'exemple suivant, `Users` des ne `Role` `viewer` sont pas autorisés à effectuer des mises à jour. Pour ces utilisateurs, l'interface utilisateur ne doit afficher aucun bouton de mise à jour.
![\[Exemple de filtrage de l'interface utilisateur avec Amazon Verified Permissions et Cedar\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-example-5.png)
Dans cet exemple, une application Web d'une seule page comporte quatre boutons. Les boutons visibles dépendent `Role` de l'utilisateur actuellement connecté à l'application. Lorsque l'application Web d'une seule page affiche l'interface utilisateur, elle interroge les autorisations vérifiées pour déterminer les actions que l'utilisateur est autorisé à effectuer, puis génère les boutons en fonction de la décision d'autorisation.
La politique suivante indique que le type dont la valeur est égale `Role` à `viewer` peut afficher à la fois les utilisateurs et les données. Une décision `ALLOW` d'autorisation pour cette politique nécessite une `viewUsers` action `viewData` ou, et nécessite également qu'une ressource soit associée au type `Data` ou`Users`. Une `ALLOW` décision autorise l'interface utilisateur à afficher deux boutons : `viewDataButton` et`viewUsersButton`.
```
permit (
principal in GuiAPP::Role::"viewer",
action in [GuiAPP::Action::"viewData", GuiAPP::Action::"viewUsers"],
resource
)
when {
resource in [GuiAPP::Type::"Data", GuiAPP::Type::"Users"]
};
```
La politique suivante indique que le type `Role` dont la valeur est égale à ne `viewerDataOnly` peut afficher que les données. Une décision `ALLOW` d'autorisation pour cette politique nécessite une `viewData` action et nécessite également qu'une ressource soit associée au type`Data`. Une `ALLOW` décision autorise l'interface utilisateur à afficher le bouton`viewDataButton`.
```
permit (
principal in GuiApp::Role::"viewerDataOnly",
action in [GuiApp::Action::"viewData"],
resource in [GuiApp::Type::"Data"]
);
```
La politique suivante indique que le type `Role` dont la valeur est égale à `admin` peut modifier et afficher les données et les utilisateurs. Une décision `ALLOW` d'autorisation pour cette politique nécessite une action de `updateData``updateUsers`, `viewData,` ou`viewUsers`, et nécessite également qu'une ressource soit associée au type `Data` ou`Users`. Une `ALLOW` décision autorise l'interface utilisateur à afficher les quatre boutons : `updateDataButton``updateUsersButton`,`viewDataButton`, et`viewUsersButton`.
```
permit (
principal in GuiApp::Role::"admin",
action in [
GuiApp::Action::"updateData",
GuiApp::Action::"updateUsers",
GuiApp::Action::"viewData",
GuiApp::Action::"viewUsers"
],
resource
)
when {
resource in [GuiApp::Type::"Data", GuiApp::Type::"Users"]
};
```