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.
# Implementación de un PDP mediante permisos verificados de Amazon
Amazon Verified Permissions es un servicio de autorización y administración de permisos escalable y detallado que puede utilizar para implementar un punto de decisión política (PDP). Como motor de políticas, puede ayudar a su aplicación a verificar las acciones de los usuarios en tiempo real y a destacar los permisos excesivamente privilegiados o no válidos. Ayuda a sus desarrolladores a crear aplicaciones más seguras con mayor rapidez al externalizar la autorización y centralizar la gestión y la administración de las políticas. Al separar la lógica de autorización de la lógica de la aplicación, Verified Permissions permite desvincular las políticas.
Al utilizar los permisos verificados para implementar un PDP y al implementar la verificación continua y con privilegios mínimos en las aplicaciones, los desarrolladores pueden ajustar el acceso a las aplicaciones a los principios de confianza [cero](https://aws.amazon.com/security/zero-trust/). Además, los equipos de seguridad y auditoría pueden analizar y auditar mejor quién tiene acceso a qué recursos de una aplicación. Verified Permissions utiliza [Cedar](https://www.cedarpolicy.com/en), un lenguaje de políticas de código abierto diseñado específicamente y que prioriza la seguridad, para definir los controles de acceso basados en políticas basados en el control de acceso basado en roles (RBAC) y el control de acceso basado en atributos (ABAC) para lograr un control de acceso más detallado y sensible al contexto.
Los permisos verificados proporcionan algunas funciones útiles para las aplicaciones SaaS, como la capacidad de habilitar la autorización de varios inquilinos mediante el uso de varios proveedores de identidad, como Amazon Cognito, Google y Facebook. Otra función de permisos verificados que resulta especialmente útil para las aplicaciones SaaS es la compatibilidad con funciones personalizadas por inquilino. Si está diseñando un sistema de gestión de las relaciones con los clientes (CRM), un cliente podría definir la granularidad del acceso a las oportunidades de venta en función de un conjunto concreto de criterios. Otro inquilino podría tener otra definición. Los sistemas de permisos subyacentes de Verified Permissions admiten estas variaciones, lo que lo convierte en un excelente candidato para los casos de uso de SaaS. Los permisos verificados también permiten redactar políticas que se apliquen a todos los inquilinos, por lo que es sencillo aplicar políticas de protección para evitar el acceso no autorizado como proveedor de SaaS.
![\[Uso de permisos verificados de Amazon para implementar un PDP\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp.png)
**¿Por qué usar permisos verificados?**
Use permisos verificados con un proveedor de identidad como [Amazon Cognito para](https://aws.amazon.com/cognito/) obtener una solución de administración de acceso más dinámica y basada en políticas para sus aplicaciones. Puede crear aplicaciones que ayuden a los usuarios a compartir información y colaborar, a la vez que mantienen la seguridad, la confidencialidad y la privacidad de sus datos. Los permisos verificados ayudan a reducir los costos operativos al proporcionarle un sistema de autorización detallado para imponer el acceso en función de las funciones y los atributos de sus identidades y recursos. Puede definir su modelo de políticas, crear y almacenar políticas en una ubicación central y evaluar las solicitudes de acceso en milisegundos.
En Verified Permissions, puedes expresar los permisos mediante un lenguaje declarativo simple y legible por humanos llamado Cedar. Las políticas que están escritas en Cedar se pueden compartir entre los equipos, independientemente del lenguaje de programación que utilice la aplicación de cada equipo.
**¿Qué hay que tener en cuenta al utilizar permisos verificados**
En Verified Permissions, puede crear políticas y automatizarlas como parte del aprovisionamiento. También puede crear políticas en tiempo de ejecución como parte de la lógica de la aplicación. Como práctica recomendada, debería utilizar una canalización de integración e implementación continuas (CI/CD) para administrar, modificar y realizar un seguimiento de las versiones de las políticas cuando cree políticas como parte de la incorporación y el aprovisionamiento de los inquilinos. Como alternativa, una aplicación puede administrar, modificar y realizar un seguimiento de las versiones de las políticas; sin embargo, la lógica de la aplicación no ofrece esta funcionalidad de forma inherente. Para admitir estas capacidades en su aplicación, debe diseñarla de forma explícita para implementar esta funcionalidad.
Si es necesario proporcionar datos externos de otras fuentes para tomar una decisión de autorización, estos datos deben recuperarse y proporcionarse a Verified Permissions como parte de la solicitud de autorización. El contexto, las entidades y los atributos adicionales no se recuperan de forma predeterminada con este servicio.
# Descripción general de Cedar
Cedar es un lenguaje de control de acceso flexible, ampliable y escalable basado en políticas que ayuda a los desarrolladores a expresar los permisos de las aplicaciones como políticas. Los administradores y desarrolladores pueden definir políticas que permitan o prohíban a los usuarios actuar con los recursos de la aplicación. Se pueden adjuntar varias políticas a un único recurso. Cuando un usuario de la aplicación intenta realizar una acción en un recurso, la aplicación solicita la autorización del motor de políticas de Cedar. Cedar evalúa las políticas aplicables y devuelve una `DENY` decisión `ALLOW` o decisión. Cedar respalda las reglas de autorización para cualquier tipo de capital y recurso, permite el control de acceso basado en roles (RBAC) y el control de acceso basado en atributos (ABAC), y apoya el análisis mediante herramientas de razonamiento automatizadas.
Cedar le permite separar la lógica empresarial de la lógica de autorización. Cuando realiza solicitudes desde el código de su aplicación, llama al motor de autorización de Cedar para determinar si la solicitud está autorizada. Si está autorizada (la decisión lo es`ALLOW`), su aplicación puede realizar la operación solicitada. Si no está autorizada (la decisión sí`DENY`), la aplicación puede devolver un mensaje de error. Las principales características de Cedar incluyen:
+ **Expresividad**: Cedar está diseñado específicamente para respaldar los casos de uso de autorizaciones y se desarrolló teniendo en cuenta la legibilidad humana.
+ **Rendimiento**: Cedar admite las políticas de indexación para una recuperación rápida y proporciona una evaluación rápida y escalable en tiempo real con una latencia limitada.
+ **Análisis**: Cedar admite herramientas de análisis que pueden optimizar sus políticas y verificar su modelo de seguridad.
Para obtener más información, consulte el [sitio web de Cedar](https://www.cedarpolicy.com/).
# 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](https://docs.cedarpolicy.com/).
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\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-example-1.png)
*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 entidad`Employee`. La acción que Bob intenta realizar es de ese tipo `viewSalary,` y el recurso que se `viewSalary` mostrará es `Salary-Bob` de ese tipo`Salary`. 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 tipo`Salary`. Esta estructura se proporciona en un`entityList`, donde los atributos asociados `Salary` incluyen un propietario, que especifica un propietario `entityIdentifier` que contiene el tipo `Employee` y el valor`Bob`. 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` o`DENY`.
```
{
"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 a`ALLOW`. 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 tipo`Employee`. La acción que Alice intenta realizar es`viewSalary`, y el recurso que `viewSalary` se mostrará es del tipo `Salary` con un valor de`Salary-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 de`Salary-Bob`. Esta estructura se proporciona en una`entityList`, donde los atributos asociados `Salary` incluyen un propietario, que especifica una `entityIdentifier` que contiene el tipo `Employee` y el valor`Bob`. Verified Permissions comprueba primero el `owner` atributo, que evalúa el tipo `Employee` y el valor`Bob`. 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](https://docs.cedarpolicy.com/policies/syntax-operators.html).
# Ejemplo 2: RBAC básico con permisos verificados y Cedar
En este ejemplo, se utilizan permisos verificados y Cedar para demostrar el RBAC básico. Como se mencionó anteriormente, la construcción básica de Cedar es una entidad. Los desarrolladores definen sus propias entidades y, si lo desean, pueden crear relaciones entre entidades. El siguiente ejemplo incluye tres tipos de entidades: `Users``Roles`, y`Problems`. `Students`y `Teachers` pueden considerarse entidades de este tipo `Role,` y cada una de ellas `User` puede estar asociada a cero o a cualquiera de las`Roles`.
![\[Ejemplo de implementación básica de RBAC con Amazon Verified Permissions y Cedar para implementar un PDP\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-example-2.png)
En Cedar, estas relaciones se expresan vinculando el `Role` `Student` a `User` `Bob` como su matriz. Esta asociación agrupa de forma lógica a todos los usuarios estudiantes en un grupo. Para obtener más información sobre la agrupación en Cedar, consulte la documentación de [Cedar](https://docs.cedarpolicy.com/overview/terminology.html#term-group).
La siguiente política evalúa la decisión de la acción `ALLOW` `submitProblem,` para todos los principales que están vinculados al grupo lógico `Students` de este tipo. `Role`
```
permit (
principal in ElearningApp::Role::"Students",
action == ElearningApp::Action::"submitProblem",
resource
);
```
La siguiente política evalúa la decisión `ALLOW` de la acción `submitProblem` o `answerProblem` de todos los principios que están vinculados al grupo `Teachers` lógico de este tipo. `Role`
```
permit (
principal in ElearningApp::Role::"Teachers",
action in [
ElearningApp::Action::"submitProblem",
ElearningApp::Action::"answerProblem"
],
resource
);
```
Para evaluar las solicitudes con estas políticas, el motor de evaluación necesita saber si el director al que se hace referencia en la solicitud de autorización es miembro del grupo apropiado. Por lo tanto, la solicitud debe transmitir la información relevante sobre la pertenencia al grupo al motor de evaluación como parte de la solicitud de autorización. Esto se hace a través de la `entities` propiedad, que le permite proporcionar al motor de evaluación de Cedar los datos sobre los atributos y la pertenencia al grupo del director y el recurso involucrados en la solicitud de autorización. En el siguiente código, la pertenencia a un grupo se indica definiendo `User::"Bob"` como la llamada a un padre`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": []
}
]
}
}
```
En este ejemplo, Bob es el usuario registrado que realiza la `answerProblem` solicitud. Por lo tanto, Bob es el principal y la entidad es de ese tipo`User`. La acción que Bob intenta realizar es`answerProblem`. Para evaluar si Bob puede realizar la `answerProblem` acción, es necesario proporcionar una estructura de entidad que vincule a la entidad `User` con un valor de `Bob` y asigne su pertenencia a un grupo mediante la inclusión de una entidad principal como`Role::"Students"`. Como las entidades del grupo `Role::"Students"` de usuarios solo pueden realizar la acción`submitProblem`, esta solicitud de autorización se evalúa como. `DENY`
Por otro lado, si el tipo `User` que tiene un valor de `Alice` y forma parte del grupo `Role::"Teachers"` intenta realizar la `answerProblem` acción, la solicitud de autorización se evalúa como tal`ALLOW`, ya que la política establece que los directores del grupo pueden realizar la acción `answerProblem` en todos `Role::"Teachers"` los recursos. El código siguiente muestra este tipo de solicitud de autorización que se evalúa como. `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": []
}
]
}
}
```
# Ejemplo 3: Control de acceso multiusuario con RBAC
Para profundizar en el ejemplo anterior de RBAC, puede ampliar sus requisitos para incluir la multitenencia de SaaS, que es un requisito común para los proveedores de SaaS. En las soluciones multiarrendatario, el acceso a los recursos siempre se proporciona en nombre de un arrendatario determinado. Es decir, los usuarios del arrendatario A no pueden ver los datos del arrendatario B, incluso si esos datos están colocados lógica o físicamente en un sistema. El siguiente ejemplo ilustra cómo puede implementar el aislamiento de inquilinos mediante varios [almacenes de políticas de permisos verificados](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/policy-stores.html) y cómo puede emplear las funciones de usuario para definir los permisos dentro del inquilino.
Utilizar el patrón de diseño del almacén de políticas por inquilino es una práctica recomendada para mantener el aislamiento de los inquilinos y, al mismo tiempo, implementar el control de acceso con permisos verificados. En este escenario, las solicitudes de los usuarios del inquilino A y del inquilino B se verifican comparándolas con almacenes de políticas independientes `DATAMICROSERVICE_POLICYSTORE_A` y`DATAMICROSERVICE_POLICYSTORE_B`, respectivamente. Para obtener más información sobre las consideraciones de diseño de permisos verificados para aplicaciones SaaS de varios inquilinos, consulte [la sección Consideraciones de diseño de permisos verificados para múltiples inquilinos](avp-design-considerations.md).
![\[Ejemplo de control de acceso de múltiples inquilinos con RBAC, Amazon Verified Permissions y Cedar\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-example-3.png)
La siguiente política se encuentra en el almacén de políticas. `DATAMICROSERVICE_POLICYSTORE_A` Verifica que el principal formará parte del grupo `allAccessRole` de tipo`Role`. En este caso, el director podrá realizar `updateData` las acciones `viewData` y acciones en todos los recursos que estén asociados al inquilino A.
```
permit (
principal in MultitenantApp::Role::"allAccessRole",
action in [
MultitenantApp::Action::"viewData",
MultitenantApp::Action::"updateData"
],
resource
);
```
Las siguientes políticas se encuentran en el almacén `DATAMICROSERVICE_POLICYSTORE_B` de políticas. La primera política comprueba que el principal forma parte del `updateDataRole` grupo de tipos`Role`. Suponiendo que ese sea el caso, da permiso a los directores para realizar la `updateData` acción con los recursos que están asociados al inquilino B.
```
permit (
principal in MultitenantApp::Role::"updateDataRole",
action == MultitenantApp::Action::"updateData",
resource
);
```
Esta segunda política exige que los directores que formen parte del `viewDataRole` grupo de este tipo `Role` puedan realizar la `viewData` acción con los recursos asociados al arrendatario B.
```
permit (
principal in MultitenantApp::Role::"viewDataRole",
action == MultitenantApp::Action::"viewData",
resource
);
```
La solicitud de autorización realizada por el arrendatario A debe enviarse al almacén `DATAMICROSERVICE_POLICYSTORE_A` de políticas y verificarse mediante las políticas que pertenecen a ese almacén. En este caso, se verifica mediante la primera política analizada anteriormente como parte de este ejemplo. En esta solicitud de autorización, el principal de tipo `User` con un valor de `Alice` solicita realizar la `viewData` acción. El principal pertenece al grupo `allAccessRole` de tipos`Role`. Alice está intentando realizar la `viewData` acción en el `SampleData` recurso. Como Alice tiene la `allAccessRole` función, esta evaluación da como resultado una `ALLOW` decisión.
```
{
"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, por el contrario, consulta una solicitud realizada por el inquilino B`User Bob`, verá algo parecido a la siguiente solicitud de autorización. La solicitud se envía al almacén de `DATAMICROSERVICE_POLICYSTORE_B` políticas porque proviene del arrendatario B. En esta solicitud, el director `Bob` desea realizar la acción `updateData` en el recurso`SampleData`. Sin embargo, `Bob` no forma parte de un grupo que tenga acceso a la acción `updateData` de ese recurso. Por lo tanto, la solicitud da lugar a una `DENY` decisión.
```
{
"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": []
}
]
}
}
```
En este tercer ejemplo, `User Alice ` intenta realizar la `viewData` acción en el recurso`SampleData`. Esta solicitud se dirige al almacén de `DATAMICROSERVICE_POLICYSTORE_A` políticas porque la principal `Alice` pertenece al arrendatario A. `Alice` forma parte de este tipo `allAccessRole` de grupo`Role`, lo que le permite realizar la `viewData` acción con los recursos. Como tal, la solicitud da lugar a una `ALLOW` decisión.
```
{
"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": []
}
]
}
}
```
# Ejemplo 4: Control de acceso multiusuario con RBAC y ABAC
Para mejorar el ejemplo del RBAC de la sección anterior, puede añadir atributos a los usuarios para crear un enfoque híbrido RBAC-ABAC para el control de acceso de varios usuarios. Este ejemplo incluye las mismas funciones del ejemplo anterior, pero añade el atributo de usuario y el parámetro de contexto. `account_lockout_flag` `uses_mfa` El ejemplo también adopta un enfoque diferente para implementar el control de acceso multiusuario mediante RBAC y ABAC, y usa un almacén de políticas compartido en lugar de un almacén de políticas diferente para cada inquilino.
![\[Ejemplo de control de acceso multiusuario con RBAC, ABAC, Amazon Verified Permissions y Cedar\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-example-4.png)
Este ejemplo representa una solución SaaS multiusuario en la que debe proporcionar decisiones de autorización para el arrendatario A y el arrendatario B, de forma similar al ejemplo anterior.
Para implementar la función de bloqueo de usuarios, el ejemplo agrega el atributo `account_lockout_flag` a la `User` entidad principal en la solicitud de autorización. Este indicador bloquea el acceso del usuario al sistema y `DENY` otorga todos los privilegios al usuario bloqueado. El `account_lockout_flag` atributo está asociado a la `User` entidad y estará en vigor `User` hasta que la marca se revoque activamente en varias sesiones. En el ejemplo se usa la `when` condición para evaluar`account_lockout_flag`.
El ejemplo también agrega detalles sobre la solicitud y la sesión. La información de contexto especifica que la sesión se ha autenticado mediante la autenticación multifactorial. Para implementar esta validación, el ejemplo usa la `when` condición para evaluar el `uses_mfa` indicador como parte del campo de contexto. Para obtener más información sobre las prácticas recomendadas para añadir contexto, consulte la [documentación 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
};
```
Esta política impide el acceso a los recursos a menos que el recurso esté en el mismo grupo que el `Tenant` atributo del principal solicitante. Este enfoque para mantener el aislamiento de los inquilinos se denomina enfoque de *un almacén de políticas compartido para varios inquilinos*. Para obtener más información sobre las consideraciones de diseño de permisos verificados para aplicaciones SaaS de varios inquilinos, consulte [la sección Consideraciones de diseño de permisos verificados para múltiples inquilinos](avp-design-considerations.md).
La política también garantiza que el director sea miembro de `allAccessRole` y restringe las acciones a y. `viewData` `updateData` Además, esta política verifica que así `account_lockout_flag` sea `false` y que el valor de contexto para la `uses_mfa` evaluación sea igual a. `true`
Del mismo modo, la siguiente política garantiza que tanto el principal como el recurso estén asociados al mismo inquilino, lo que impide el acceso entre inquilinos. Esta política también garantiza que el director sea miembro `viewDataRole` y restringe las acciones a. `viewData` Además, verifica que el `account_lockout_flag` es `false` y que el valor de contexto para el que se `uses_mfa` evalúa. `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 tercera política es similar a la anterior. La política exige que el recurso sea miembro del grupo que corresponda a la entidad por la que está representado`principal.Tenant`. Esto garantiza que tanto el principal como el recurso estén asociados al inquilino B, lo que impide el acceso entre inquilinos. Esta política garantiza que el director sea miembro `updateDataRole` y restringe las acciones a. `updateData` Además, esta política verifica que `account_lockout_flag` es `false` y que el valor de contexto se `uses_mfa` evalúa como tal. `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 siguiente solicitud de autorización se evalúa mediante las tres políticas descritas anteriormente en esta sección. En esta solicitud de autorización, el principal del tipo `User` y con un valor de `Alice` realiza una `updateData` solicitud con el rol`allAccessRole`. `Alice`tiene el atributo `Tenant` cuyo valor es`Tenant::"TenantA"`. La acción que `Alice` se intenta realizar es de ese tipo `updateData,` y el recurso al que se aplicará es `SampleData` de ese tipo`Data`. `SampleData`tiene `TenantA` como entidad principal.
Según la primera política del almacén de `` políticas, `Alice` puede realizar la `updateData` acción en el recurso, suponiendo que se cumplan las condiciones de la `when` cláusula de la política. La primera condición requiere que el `principal.Tenant` atributo se evalúe`TenantA`. La segunda condición requiere que el atributo del principal `account_lockout_flag` sea`false`. La condición final requiere que el contexto `uses_mfa` sea`true`. Como se cumplen las tres condiciones, la solicitud devuelve una `ALLOW` decisión.
```
{
"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"
}
]
}
]
}
}
```
# Ejemplo 5: filtrado de la interfaz de usuario con permisos verificados y Cedar
También puedes usar los permisos verificados para implementar el filtrado RBAC de los elementos de la interfaz de usuario en función de las acciones autorizadas. Esto es extremadamente valioso para las aplicaciones que tienen elementos de interfaz de usuario sensibles al contexto que podrían estar asociados a usuarios o inquilinos específicos en el caso de una aplicación SaaS multiusuario.
En el siguiente ejemplo, `Users` no `Role` `viewer` están autorizados a realizar actualizaciones. Para estos usuarios, la interfaz de usuario no debería mostrar ningún botón de actualización.
![\[Ejemplo de filtrado de interfaz de usuario con Amazon Verified Permissions y Cedar\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-example-5.png)
En este ejemplo, una aplicación web de una sola página tiene cuatro botones. Los botones que están visibles dependen `Role` del usuario que esté actualmente conectado a la aplicación. A medida que la aplicación web de una sola página renderiza la interfaz de usuario, consulta los permisos verificados para determinar qué acciones está autorizado a realizar el usuario y, a continuación, genera los botones en función de la decisión de autorización.
La siguiente política especifica que el tipo `Role` con un valor de `viewer` puede ver tanto los usuarios como los datos. La decisión de `ALLOW` autorizar esta política requiere una `viewUsers` acción `viewData` o, además, requiere que se asocie un recurso al tipo `Data` o`Users`. Una `ALLOW` decisión permite a la interfaz de usuario representar dos botones: `viewDataButton` y`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 siguiente política especifica que el tipo `Role` con un valor de solo `viewerDataOnly` puede ver datos. La decisión de `ALLOW` autorizar esta política requiere una `viewData` acción y también requiere que se asocie un recurso al tipo`Data`. Una `ALLOW` decisión permite que la interfaz de usuario renderice el botón`viewDataButton`.
```
permit (
principal in GuiApp::Role::"viewerDataOnly",
action in [GuiApp::Action::"viewData"],
resource in [GuiApp::Type::"Data"]
);
```
La siguiente política especifica que el tipo `Role` con un valor de `admin` puede editar y ver datos y usuarios. La decisión de `ALLOW` autorizar esta política requiere una acción de `updateData``updateUsers`, `viewData,` o`viewUsers`, y también requiere que se asocie un recurso al tipo `Data` o`Users`. Una `ALLOW` decisión permite a la interfaz de usuario representar los cuatro botones: `updateDataButton``updateUsersButton`,`viewDataButton`, y`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"]
};
```