Ejemplo 1: ABAC básico con permisos verificados y Cedar - AWS Guía prescriptiva

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Ejemplo 1: ABAC básico con permisos verificados y Cedar

En este escenario de ejemplo, Amazon Verified Permissions se utiliza para determinar qué usuarios pueden acceder a la información de un microservicio de nómina ficticio. Esta sección incluye fragmentos de código de Cedar para demostrar cómo se puede utilizar Cedar para tomar decisiones de control de acceso. Estos ejemplos no pretenden ofrecer una exploración completa de las capacidades que ofrecen Cedar y Verified Permissions. Para obtener una descripción más completa de Cedar, consulte la documentación de Cedar.

En el siguiente diagrama, nos gustaría aplicar dos reglas comerciales generales asociadas al viewSalary GET método: los empleados pueden ver su propio salario y los empleados pueden ver el salario de cualquier persona que dependa de ellos. Puedes hacer cumplir estas reglas empresariales mediante las políticas de permisos verificados.

Ejemplo de una implementación básica de ABAC con Amazon Verified Permissions y Cedar para implementar un PDP

Los empleados pueden ver su propio salario.

En Cedar, la construcción básica es una entidad, que representa un principal, una acción o un recurso. Para realizar una solicitud de autorización e iniciar una evaluación con una política de permisos verificados, debe proporcionar una entidad principal, una acción, un recurso y una lista de entidades.

  • El principal (principal) es el usuario o rol que ha iniciado sesión.

  • La acción (action) es la operación que evalúa la solicitud.

  • El recurso (resource) es el componente al que accede la acción.

  • La lista de entidades (entityList) contiene todas las entidades necesarias para evaluar la solicitud.

Para cumplir con la norma empresarial, los empleados pueden ver su propio salario, puedes proporcionar una política de permisos verificados como la siguiente.

permit (
    principal,
    action == Action::"viewSalary",
    resource
)
when {
    principal == resource.owner
};

Esta política evalúa ALLOW si el atributo Action is viewSalary y el recurso de la solicitud tienen un propietario de atributo igual al principal. Por ejemplo, si Bob es el usuario registrado que solicitó el informe salarial y también es el propietario del informe salarial, la política se evalúa como. ALLOW

La siguiente solicitud de autorización se envía a Verified Permissions para que la evalúe el modelo de política. En este ejemplo, Bob es el usuario que ha iniciado sesión y que realiza la viewSalary solicitud. Por lo tanto, Bob es el principal del tipo de entidadEmployee. La acción que Bob intenta realizar es de ese tipo viewSalary, y el recurso que se viewSalary mostrará es Salary-Bob de ese tipoSalary. Para evaluar si Bob puede ver el Salary-Bob recurso, es necesario proporcionar una estructura de entidad que vincule el tipo Employee con un valor Bob (el principal) con el atributo propietario del recurso que contiene el tipoSalary. Esta estructura se proporciona en unentityList, donde los atributos asociados Salary incluyen un propietario, que especifica un propietario entityIdentifier que contiene el tipo Employee y el valorBob. Verified Permissions compara lo principal proporcionado en la solicitud de autorización con el owner atributo asociado al Salary recurso para tomar una decisión.

{
  "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 solicitud de autorización a Verified Permissions devuelve lo siguiente como resultado, donde el atributo decision es ALLOW oDENY.

{
    "determiningPolicies": 
        [ 
            {
                "determiningPolicyId": "PAYROLLAPP_POLICYSTOREID" 
            }
        ],
    "decision": "ALLOW",
    "errors": [] 
}

En este caso, dado que Bob estaba intentando ver su propio salario, la solicitud de autorización enviada a Verified Permissions equivale aALLOW. Sin embargo, nuestro objetivo era utilizar los permisos verificados para hacer cumplir dos normas empresariales. La regla empresarial que establece lo siguiente también debería ser cierta:

Los empleados pueden ver el salario de cualquier persona que dependa de ellos.

Para cumplir con esta regla empresarial, puede proporcionar otra política. La siguiente política evalúa ALLOW si la acción es igual al principal viewSalary y si el recurso de la solicitud tiene un atributo owner.manager igual al principal. Por ejemplo, si Alice es la usuaria que inició sesión y solicitó el informe salarial y Alice es la administradora del propietario del informe, la política se evaluará como tal. ALLOW

permit (
    principal,
    action == Action::"viewSalary",
    resource
)
when {
    principal == resource.owner.manager
};

La siguiente solicitud de autorización se envía a Verified Permissions para que la evalúe el modelo de política. En este ejemplo, Alice es el usuario que ha iniciado sesión y que realiza la viewSalary solicitud. Por lo tanto, Alice es la principal y la entidad es de ese tipoEmployee. La acción que Alice intenta realizar esviewSalary, y el recurso que viewSalary se mostrará es del tipo Salary con un valor deSalary-Bob. Para evaluar si Alice puede ver el Salary-Bob recurso, debe proporcionar una estructura de entidad que vincule el tipo Employee con un valor de Alice con el manager atributo, que luego debe asociarse al owner atributo del tipo Salary con un valor deSalary-Bob. Esta estructura se proporciona en unaentityList, donde los atributos asociados Salary incluyen un propietario, que especifica una entityIdentifier que contiene el tipo Employee y el valorBob. Verified Permissions comprueba primero el owner atributo, que evalúa el tipo Employee y el valorBob. A continuación, Verified Permissions evalúa el manager atributo asociado Employee y lo compara con el principal proporcionado para tomar una decisión de autorización. En este caso, la decisión se ALLOW debe a que los resource.owner.manager atributos principal y son equivalentes.

{
  "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": []
      }
    ]
  }
}

Hasta ahora, en este ejemplo, hemos proporcionado las dos reglas de negocio asociadas al viewSalary método: los empleados pueden ver su propio salario y los empleados pueden ver el salario de cualquier persona que dependa de ellos. Los permisos verificados son políticas para cumplir las condiciones de cada regla de negocio de forma independiente. También puede utilizar una única política de permisos verificados para cumplir las condiciones de ambas reglas empresariales:

Los empleados pueden ver su propio salario y el de cualquier persona que dependa de ellos.

Al utilizar la solicitud de autorización anterior, la siguiente política evalúa ALLOW si la acción es viewSalary y el recurso de la solicitud tiene un atributo owner.manager igual a o un atributo owner igual a. principal principal 

permit (
    principal,
    action == PayrollApp::Action::"viewSalary",
    resource
)
when {
    principal == resource.owner.manager ||
    principal == resource.owner
};

Por ejemplo, si Alice es el usuario que ha iniciado sesión y solicita el informe salarial y si Alice es la gestora del propietario o la propietaria del informe, la política se evalúa como. ALLOW

Para obtener más información sobre el uso de operadores lógicos con las políticas de Cedar, consulte la documentación de Cedar.