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.

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.

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'viewSalaryaffichera est Salary-Bob de typeSalary. 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 typeSalary. Vous fournissez cette structure dans unentityList, où les attributs associés à Salary incluent un propriétaire, qui spécifie et entityIdentifier qui contient le type Employee et la valeurBob. 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 ouDENY.

{
    "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 typeEmployee. L'action qu'Alice essaie d'effectuer estviewSalary, et la ressource qui s'viewSalaryaffichera est du type Salary avec une valeur deSalary-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'managerattribut, qui doit ensuite être associé à l'ownerattribut du type Salary avec une valeur deSalary-Bob. Vous fournissez cette structure dans unentityList, où les attributs associés à Salary incluent un propriétaire, qui spécifie et entityIdentifier qui contient le type Employee et la valeurBob. Les autorisations vérifiées vérifient d'abord l'ownerattribut, qui est évalué en fonction du type Employee et de la valeurBob. Ensuite, Verified Permissions évalue l'managerattribut 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.