Mejores prácticas para diseñar un modelo de autorización - Amazon Verified Permissions

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.

Mejores prácticas para diseñar un modelo de autorización

Mientras realiza los preparativos para utilizar el servicio Amazon Verified Permissions en una aplicación de software, puede resultar difícil pasar inmediatamente a redactar instrucciones de política como primer paso. Esto sería similar a comenzar el desarrollo de otras partes de una aplicación escribiendo SQL declaraciones o API especificaciones antes de decidir por completo lo que debe hacer la aplicación. En su lugar, debería empezar con una experiencia de usuario para tener una idea clara de lo que los usuarios finales deberían ver cuando gestionen los permisos en la interfaz de usuario de la aplicación. Después, partiendo de esa experiencia vaya hacia atrás para desarrollar una estrategia de implementación.

A medida que vaya realizando este trabajo, se hará preguntas como las siguientes:

  • ¿Cuáles son mis recursos? ¿Tienen relaciones entre sí? Por ejemplo, ¿los archivos se encuentran dentro de una carpeta?

  • ¿Qué acciones pueden realizar las entidades principales en cada recurso?

  • ¿Cómo adquieren esos permisos las entidades principales?

  • ¿Desea que sus usuarios finales elijan entre permisos predefinidos, como «Administrador», «Operador» u «ReadOnly», o deberían crear declaraciones de políticas ad hoc? ¿O ambos?

  • ¿Los permisos deben heredarse entre recursos, como los archivos que heredan los permisos de una carpeta principal?

  • ¿Qué tipos de consultas son necesarios para ofrecer la experiencia de usuario? Por ejemplo, ¿necesita enumerar todos los recursos a los que puede acceder una entidad principal para mostrar la página de inicio de ese usuario?

  • ¿Pueden los usuarios quedarse sin acceso a sus propios recursos por accidente? ¿Es necesario evitarlo?

El resultado final de este ejercicio se denomina modelo de autorización; define las entidades principales, los recursos, las acciones y la forma en que se interrelacionan entre sí. La elaboración de este modelo no requiere un conocimiento exclusivo de Cedar o del servicio Verified Permissions. Por el contrario, se trata ante todo de un ejercicio de diseño de la experiencia de usuario, como cualquier otro, y puede manifestarse en artefactos como maquetas de interfaces, diagramas lógicos y una descripción general de cómo los permisos influyen en lo que los usuarios ven en el producto. Cedar está diseñado para ser lo suficientemente flexible como para satisfacer las necesidades de los clientes en un modelo, en lugar de forzar al modelo a flexibilizarse de forma poco natural para adaptarse a una implementación de Cedar. Por eso, tener una idea clara de la experiencia de usuario que se desea es la mejor manera de llegar a un modelo óptimo.

En esta sección se proporcionan instrucciones generales sobre cómo abordar el ejercicio de diseño, los aspectos a tener en cuenta y una recopilación de las mejores prácticas para utilizar correctamente Verified Permissions.

Además de las pautas que se presentan aquí, tenga siempre en cuenta las mejores prácticas incluidas en la guía de referencia lingüística sobre las políticas de Cedar.

No existe un modelo canónico “correcto”

Al diseñar un modelo de autorización, no hay una respuesta única y única que sea correcta. Diferentes aplicaciones pueden utilizar de manera efectiva diferentes modelos de autorización para conceptos similares, y es algo que está bien. Por ejemplo, fíjese en la representación del sistema de archivos de un ordenador. Al crear un archivo en un sistema operativo similar a Unix, no hereda automáticamente los permisos de la carpeta principal. Por el contrario, en otros muchos sistemas operativos y en la mayoría de los servicios de intercambio de archivos en línea, los archivos heredan los permisos de su carpeta principal. Ambas opciones son válidas en función de las circunstancias para las que se esté optimizando la aplicación.

La corrección de una solución de autorización no es absoluta, pero debe considerarse en términos de cómo ofrece la experiencia que desean sus clientes y de si protege sus recursos de la manera que esperan. Si su modelo de autorización cumple con estos requisitos, entonces es correcto.

Por eso, empezar el diseño con la experiencia de usuario deseada es el requisito previo más útil para crear un modelo de autorización eficaz.

Céntrese en sus recursos más allá de las operaciones API

En la mayoría de las aplicaciones orientadas al consumidor, los permisos se modelan en función de los recursos compatibles con la aplicación. Por ejemplo, una aplicación para compartir archivos puede representar los permisos como acciones que se pueden realizar en un archivo o una carpeta. Se trata de un modelo bueno y sencillo que abstrae la implementación subyacente y las operaciones de backendAPI.

Por el contrario, otros tipos de aplicaciones, especialmente los servicios web, suelen diseñar los permisos en función de API las propias operaciones. Por ejemplo, si un servicio web proporciona un API nombrecreateThing(), el modelo de autorización puede definir el permiso correspondiente o un nombre action en CedarcreateThing. Esto funciona en muchas situaciones y hace que sea más fácil entender los permisos. Para invocar la operación createThing, necesita el permiso de acción createThing. Parece sencillo, ¿verdad?

Descubrirá que el proceso de inicio de la consola de permisos verificados incluye la opción de crear sus recursos y acciones directamente a partir de unAPI. Se trata de una base útil: un mapeo directo entre el almacén de políticas y el almacén al API que autoriza.

Sin embargo, este enfoque API centrado puede no ser óptimo, ya APIs que no es más que un indicador de lo que sus clientes realmente están intentando proteger: los datos y los recursos subyacentes. Si varios APIs controlan el acceso a los mismos recursos, puede resultar difícil para los administradores razonar sobre las rutas hacia esos recursos y gestionar el acceso en consecuencia.

Por ejemplo, pensemos en un directorio de usuarios que contenga los miembros de una organización. Los usuarios se pueden organizar en grupos y uno de los objetivos de seguridad es impedir que personas no autorizadas descubran la pertenencia a esos grupos. El servicio que administra este directorio de usuarios proporciona dos API operaciones:

  • listMembersOfGroup

  • listGroupMembershipsForUser

Los clientes pueden usar cualquiera de estas operaciones para descubrir la pertenencia a un grupo. Por lo tanto, el administrador de los permisos debe acordarse de coordinar el acceso a ambas operaciones. Esto se complica aún más si más adelante decide agregar una nueva API operación para abordar casos de uso adicionales, como los siguientes.

  • isUserInGroups(una nueva API herramienta para comprobar rápidamente si un usuario pertenece a uno o más grupos)

Desde el punto de vista de la seguridad, esto API abre una tercera vía para descubrir las pertenencias a grupos, lo que interrumpe los permisos cuidadosamente diseñados del administrador.

Le recomendamos que ignore la API semántica y, en cambio, se centre en los datos y recursos subyacentes y en sus operaciones de asociación. Al aplicar este enfoque al ejemplo de pertenencia a un grupo, se obtendría un permiso abstractoviewGroupMembership, como el que debe consultar cada una de las tres API operaciones.

APINombre Permisos
listMembersOfGroup requiere el permiso viewGroupMembership del grupo
listGroupMembershipsForUser requiere el permiso viewGroupMembership del usuario
isUserInGroups requiere el permiso viewGroupMembership del usuario

Al definir este permiso, el administrador puede controlar el acceso al descubrimiento de la pertenencia a un grupo, ahora y siempre. Como compensación, cada API operación ahora debe documentar los posibles permisos que necesite, y el administrador debe consultar esta documentación al crear los permisos. Pero puede ser una desventaja válida cuando sea necesaria para cumplir tus requisitos de seguridad.

La autorización compuesta es normal

La autorización compuesta se produce cuando la actividad de un solo usuario, como hacer clic en un botón de la interfaz de la aplicación, requiere varias consultas de autorización individuales para determinar si esa actividad está permitida. Por ejemplo, mover un archivo a un nuevo directorio de un sistema de archivos puede requerir tres permisos diferentes: la capacidad de eliminar un archivo del directorio de origen, la capacidad de añadir un archivo al directorio de destino y, posiblemente, la capacidad de manipular el archivo en sí (según la aplicación).

Si es la primera vez que diseña un modelo de autorización, podría pensar que todas las decisiones de autorización deben poder resolverse en una única consulta de autorización. Sin embargo, esto puede llevar a modelos demasiado complejos y a instrucciones de políticas complicadas. En la práctica, el uso de autorizaciones compuestas puede resultar útil para crear un modelo de autorización más simple. Un indicador de un modelo de autorización bien diseñado es que, cuando se han descompuesto suficientemente las acciones individuales, las operaciones compuestas, como mover un archivo, se pueden representar mediante una agregación intuitiva de primitivas.

Otra situación en la que se produce una autorización compuesta es cuando varias partes participan en el proceso de concesión de un permiso. Considere la posibilidad de crear un directorio organizativo en el que los usuarios puedan ser miembros de grupos. Un enfoque sencillo consiste en dar permiso al propietario del grupo para añadir a cualquier persona. Sin embargo, ¿qué sucede si quiere que los usuarios den antes su consentimiento para que los agreguen? Esto introduce un acuerdo recíproco en el que tanto el usuario como el grupo deben dar su consentimiento para pertenecer a él. Para ello, puede introducir otro permiso vinculado al usuario y especificar si el usuario se puede añadir a cualquier grupo o a un grupo concreto. Cuando un solicitante intente añadir miembros a un grupo después, la aplicación deberá verificar que se cumplen los dos lados del permiso: que la persona solicitante tiene permiso para añadir miembros al grupo especificado y que el usuario individual que se va a añadir tiene los permisos necesarios para añadirlo. Cuando existen acuerdos de N partes, es habitual utilizar N consultas de autorización compuestas para hacer cumplir cada parte del acuerdo.

Si se enfrenta a un problema de diseño en el que intervienen varios recursos y no tiene claro cómo modelar los permisos, puede ser una señal de que se trata de un escenario de autorización compuesto. En este caso, podría encontrar una solución dividiendo la operación en varias comprobaciones de autorización individuales.

Consideraciones sobre la multitenencia

Es posible que desee desarrollar aplicaciones para que las utilicen varios clientes (empresas que consumen su aplicación o inquilinos) e integrarlas con Amazon Verified Permissions. Antes de desarrollar su modelo de autorización, desarrolle una estrategia multiusuario. Puede administrar las políticas de sus clientes en un almacén de políticas compartido o asignar a cada uno un almacén de políticas por inquilino.

  1. Un almacén de políticas compartido

    Todos los inquilinos comparten un único almacén de pólizas. La aplicación envía todas las solicitudes de autorización al almacén de políticas compartido.

  2. Almacén de políticas por inquilino

    Cada inquilino tiene un almacén de pólizas dedicado. La aplicación consultará diferentes almacenes de pólizas para tomar una decisión de autorización, en función del inquilino que presente la solicitud.

Ninguna de estas estrategias crea un volumen relativamente mayor de solicitudes de autorización que podrían repercutir en su factura. AWS Entonces, ¿cómo debería diseñar su enfoque? Las siguientes son condiciones comunes que podrían contribuir a su estrategia de autorización de arrendamiento múltiple con permisos verificados.

Políticas de inquilinos: aislamiento

El aislamiento de las políticas de cada inquilino de las demás es importante para proteger los datos del inquilino. Cuando cada inquilino tiene su propio almacén de políticas, cada uno tiene su propio conjunto aislado de políticas.

Flujo de autorización

Puede identificar a un inquilino que realiza una solicitud de autorización con un ID de almacén de políticas en la solicitud, si utiliza almacenes de políticas por inquilino. Con un almacén de políticas compartido, todas las solicitudes utilizan el mismo ID de almacén de políticas.

Administración de plantillas y esquemas

Las plantillas de políticas y el esquema de un almacén de políticas añaden un nivel de sobrecarga de diseño y mantenimiento a cada almacén de políticas.

Administración de políticas globales

Es posible que desee aplicar algunas políticas globales a todos los inquilinos. El nivel de gastos generales de administración de las políticas globales varía según el modelo de almacén de políticas compartido y el modelo por inquilino.

Inquilino abandona el embarque

Algunos inquilinos aportarán elementos a su esquema y políticas que sean específicos para su caso. Cuando un inquilino ya no está activo en su organización y usted desea eliminar sus datos, el nivel de esfuerzo varía en función de su nivel de aislamiento respecto a los demás inquilinos.

Cuotas de recursos de servicio

Verified Permissions tiene cuotas de recursos y tasas de solicitudes que pueden influir en su decisión de tener varios arrendatarios. Para obtener más información sobre las cuotas, consulte Cuotas de recursos.

Comparación de los almacenes de políticas compartidos y los almacenes de políticas por inquilino

Cada consideración requiere su propio nivel de dedicación de tiempo y recursos en los modelos de almacenes de políticas compartidos y por inquilino.

Consideración Nivel de esfuerzo en un almacén de políticas compartido Nivel de esfuerzo en los almacenes de pólizas por inquilino
Aislamiento de políticas de inquilinos Medio.Debe incluir los identificadores de los inquilinos en las políticas y solicitudes de autorización. Bajo. El aislamiento es el comportamiento predeterminado. Los demás inquilinos no pueden acceder a las políticas específicas para inquilinos.
Flujo de autorización Bajo. Todas las consultas se dirigen a un almacén de políticas. Medio. Debe mantener los mapeos entre cada inquilino y su ID de almacén de pólizas.
Administración de plantillas y esquemas Bajo. Debe hacer que un esquema funcione para todos los inquilinos. Alto. Los esquemas y las plantillas pueden ser menos complejos individualmente, pero los cambios requieren más coordinación y complejidad.
Administración de políticas globales Bajo. Todas las políticas son globales y se pueden actualizar de forma centralizada. Alto. Debes añadir políticas globales a cada almacén de políticas durante la incorporación. Replica las actualizaciones de las políticas globales entre muchos almacenes de pólizas.
Inquilino abandona el embarque Medio. Debe identificar y eliminar únicamente las políticas específicas del inquilino. Bajo. Elimine el almacén de políticas.
Cuotas de recursos de servicio Altas. Los inquilinos comparten las cuotas de recursos que afectan a los almacenes de políticas, como el tamaño del esquema, el tamaño de las políticas por recurso y las fuentes de identidad por almacén de políticas. Bajo. Cada inquilino tiene cuotas de recursos específicas.

¿Cómo elegir

Cada aplicación multiusuario es diferente. Compare cuidadosamente los dos enfoques y sus consideraciones antes de tomar una decisión arquitectónica.

Si su aplicación no requiere políticas específicas para cada inquilino y utiliza una única fuente de identidad, es probable que la solución más eficaz sea un almacén de políticas compartido para todos los inquilinos. Esto se traduce en un flujo de autorización y una gestión de políticas globales más sencillos. La exclusión de un inquilino mediante un almacén de políticas compartido requiere menos esfuerzo, ya que la aplicación no necesita eliminar las políticas específicas del inquilino.

Sin embargo, si su solicitud requiere muchas políticas específicas para cada inquilino o utiliza varias fuentes de identidad, lo más probable es que los almacenes de pólizas por inquilino sean los más eficaces. Puede controlar el acceso a las políticas de inquilinos con IAM políticas que concedan permisos por inquilino a cada almacén de políticas. La exclusión de un inquilino implica eliminar su almacén de pólizas; en un shared-policy-store entorno, debe buscar y eliminar las políticas específicas del inquilino.

Completar, cuando sea posible, el ámbito de la política

El ámbito de la política es la parte de una instrucción de política de Cedar que aparece después de las palabras clave permit o forbid y entre los paréntesis iniciales.

Ilustración de la estructura de una política de Cedar, incluido el ámbito.

Le recomendamos que complete los valores de principal y resource siempre que sea posible. Esto permite a Verified Permissions indexar las políticas para una recuperación más eficiente y, por lo tanto, mejora el rendimiento. Si necesita conceder los mismos permisos a muchas entidades principales o recursos diferentes, le recomendamos que utilice una plantilla de políticas y la adjunte a cada par de entidad principal y recurso.

Evite crear una política amplia que contenga listas de entidades principales y recursos en una cláusula when. Si lo hace, es probable que se enfrente a límites de escalabilidad o a problemas operativos. Por ejemplo, para añadir o eliminar un solo usuario de una lista grande de una política, es necesario leer toda la política, editar la lista, redactar la nueva política en su totalidad y gestionar los errores de simultaneidad si un administrador sobrescribe los cambios de otro. Por el contrario, si se utilizan muchos permisos específicos, añadir o eliminar un usuario es tan sencillo como añadir o eliminar la única política que se le aplica.

Todos los recursos deben residir en un contenedor

Al diseñar un modelo de autorización, cada acción debe estar asociada a un recurso concreto. Con una acción como viewFile, el recurso al que se puede aplicar es intuitivo: un archivo individual o, quizás, una colección de archivos dentro de una carpeta. Sin embargo, una operación como createFile es menos intuitiva. Al modelar la capacidad de crear un archivo, ¿a qué recurso se aplica? No puede ser al archivo en sí, porque el archivo aún no existe.

Este es un ejemplo de los problemas generales que plantea la creación de recursos. La creación de recursos es un problema que surge al inicio. Debe haber una forma de que algo tenga permiso para crear recursos incluso cuando aún no existan recursos. La solución consiste en reconocer que todos los recursos deben existir dentro de algún contenedor, y es el propio contenedor el que actúa como punto de anclaje de los permisos. Por ejemplo, si ya existe una carpeta en el sistema, la capacidad de crear un archivo se puede modelar como un permiso en esa carpeta, ya que es la ubicación en la que se necesitan permisos para crear una instancia del nuevo recurso.

permit ( principal == User::"6688f676-1aa9-456a-acf4-228340b54e9d", action == Action::"createFile", resource == Folder::"c863f89b-461f-4fc2-b638-e5fa5f79a48b" );

Pero, ¿qué pasa si no existe ninguna carpeta? Quizás se trate de una cuenta de cliente completamente nueva en una aplicación para la que aún no existen recursos. En esta situación, todavía hay un contexto que se puede entender intuitivamente preguntándose: ¿dónde puede el cliente crear nuevos archivos? No querrá que puedan crear archivos dentro de una cuenta de cliente aleatoria. Más bien, hay un contexto implícito: el límite de la propia cuenta del cliente. Por lo tanto, la cuenta en sí misma representa el contenedor para la creación de recursos, y esto se puede modelar explícitamente en una política similar a la del siguiente ejemplo.

// Grants permission to create files within an account, // or within any sub-folder inside the account. permit ( principal == User::"6688f676-1aa9-456a-acf4-228340b54e9d", action == Action::"createFile", resource in Account::"c863f89b-461f-4fc2-b638-e5fa5f79a48b" );

Sin embargo, ¿qué pasa si tampoco existen cuentas? Puede optar por diseñar el flujo de trabajo de registro de clientes para que cree nuevas cuentas en el sistema. Si es así, necesitará un contenedor que incluya el límite máximo en el que el proceso puede crear las cuentas. Este contenedor de nivel raíz representa el sistema en su conjunto y podría denominarse algo así como “raíz del sistema”. Sin embargo, la decisión de si es necesario y qué nombre asignarle le corresponde a usted, el propietario de la aplicación.

Por lo tanto, en este ejemplo de aplicación, la jerarquía de contenedores resultante sería la siguiente:

Una jerarquía de archivos con una raíz del sistema que contiene cuentas. Cada una de las cuentas contiene carpetas que, a su vez, pueden contener archivos.

Este es un ejemplo de jerarquía. Otras también son válidas. Lo que hay que recordar es que la creación de recursos siempre ocurre en el contexto de un contenedor de recursos. Estos contenedores pueden estar implícitos, como el límite de una cuenta, y es fácil pasarlos por alto. Al diseñar su modelo de autorización, asegúrese de tener en cuenta estas suposiciones implícitas para que puedan documentarse y representarse formalmente en el modelo de autorización.

Separar las entidades principales de los contenedores de recursos

Al diseñar una jerarquía de recursos, una de las tendencias más comunes, especialmente en el caso de las aplicaciones orientadas al consumidor, es utilizar la identidad de usuario del cliente como contenedor de recursos en una cuenta de cliente.

Una jerarquía de archivos en la que las identidades de los usuarios son los contenedores de todos los recursos.

Le recomendamos que trate esta estrategia como un antipatrón. Esto se debe a que existe una tendencia natural en las aplicaciones con más funciones a delegar el acceso a usuarios adicionales. Por ejemplo, puede optar por introducir cuentas “familiares”, en las que otros usuarios puedan compartir los recursos de la cuenta. Del mismo modo, los clientes empresariales a veces desean designar a varios miembros de la plantilla como operadores de algunas partes de la cuenta. Es posible que también necesite transferir la propiedad de una cuenta a otro usuario o combinar los recursos de varias cuentas.

Cuando se utiliza la identidad de un usuario como contenedor de recursos para una cuenta, resulta más difícil tener éxito en los escenarios anteriores. Lo que es más preocupante es que, si se concede a otras personas acceso al contenedor de la cuenta con este enfoque, es posible que se les conceda acceso de manera inadvertida para modificar la propia identidad del usuario; por ejemplo, cambiando el correo electrónico o las credenciales de inicio de sesión de Jane.

Por lo tanto, siempre y cuando sea posible, un enfoque más flexible consiste en separar las entidades principales de los contenedores de recursos y modelar la conexión entre ellos utilizando conceptos como “permisos de administrador” o “propiedad”.

Entidades principales y recursos separados con atributos de recurso que vinculan el recurso con las entidades principales asociadas.

Si tiene una aplicación que no puede seguir este modelo disociado, le recomendamos que considere la posibilidad de imitarlo en la medida de lo posible cuando diseñe un modelo de autorización. Por ejemplo, una aplicación que posea un solo concepto denominado Customer que encapsule la identidad del usuario, las credenciales de inicio de sesión y los recursos que posee podría asignarlo a un modelo de autorización que contenga una entidad lógica para Customer Identity (que contenga el nombre, el correo electrónico, etc.) y una entidad lógica independiente para Customer Resources o Customer Account, que actúe como nodo principal para todos los recursos que posee. Ambas entidades pueden compartir el mismo Id, pero con unType diferente.

Entidades principales y recursos separados con un contenedor de recursos más generalizado asociado con las entidades principales.

Uso de atributos o plantillas para representar relaciones

Hay dos formas principales de expresar las relaciones entre los recursos. El momento de utilizar una u otra depende de si la relación ya está almacenada en la base de datos de la aplicación o no y se utiliza por otros motivos, como el cumplimiento. Si es así, adopte el enfoque basado en atributos. Si no es así, entonces adopte el enfoque basado en plantillas.

Relaciones basadas en atributos

Los atributos se pueden utilizar como entrada en la decisión de autorización para representar una relación entre un principal y uno o más recursos.

Este patrón es adecuado cuando se hace un seguimiento de la relación y se administra con fines que van más allá de la mera administración de permisos. Por ejemplo, es necesario registrar al titular principal de la cuenta para cumplir desde el punto de vista financiero con las normas de Conozca a su cliente. Los permisos se derivan de estas relaciones. Los datos de la relación se administran fuera del sistema de autorización y se obtienen como entrada al tomar una decisión de autorización.

El siguiente ejemplo muestra cómo se puede representar la relación entre un usuario Alice y varias cuentas de las que es el titular principal de la cuenta:

// Using a user attribute to represent the primary account holder relationship { "id": "df82e4ad-949e-44cb-8acf-2d1acda71798", "name": "alice", "email": "alice@example.com", "primaryOnAccounts": [ "Account::\"c943927f-d803-4f40-9a53-7740272cb969\"", "Account::\"b8ee140c-fa09-46c3-992e-099438930894\"" ] }

Y, posteriormente, utilizar el atributo dentro de una política:

// Derived relationship permissions permit ( principal, action in Action::"primaryAccountHolderActions", resource )when { resource in principal.primaryOnAccounts };

Por el contrario, la misma relación podría representarse como un atributo del recurso denominado primaryAccountHolders que contiene un conjunto de usuarios.

Si hay varios tipos de relaciones entre los principales y los recursos, estos se deben modelar como atributos diferentes. Por ejemplo, si las cuentas también pueden tener firmantes autorizados y estas personas tienen permisos diferentes en la cuenta, esto se representaría como un atributo diferente.

En el caso anterior, también Alice podría ser un firmante autorizado en una tercera cuenta. El siguiente ejemplo muestra cómo se podría representar esto:

// Using user attributes to represent the primary account holder and authorized signatory relationships { "id": "df82e4ad-949e-44cb-8acf-2d1acda71798", "name": "alice", "email": "alice@example.com", "primaryOnAccounts": [ "Account::\"c943927f-d803-4f40-9a53-7740272cb969\"", "Account::\"b8ee140c-fa09-46c3-992e-099438930894\"" ], "authorizedSignatoryOnAccounts": [ "Account::\"661817a9-d478-4096-943d-4ef1e082d19a\"" ] }

Las políticas correspondientes son las siguientes:

// Derived relationship permissions permit ( principal, action in Action::"primaryAccountHolderActions", resource )when { resource in principal.primaryOnAccounts }; permit ( principal, action in Action::"authorizedSignatoryActions", resource )when { resource in principal.authorizedSignatoryOnAccounts };

Relaciones basadas en plantillas

Si la relación entre los recursos existe únicamente con el propósito de administrar los permisos, es conveniente almacenar esta relación como una política o plantilla vinculada a una plantilla. También puedes pensar en estas plantillas como funciones que se asignan a un recurso específico.

Por ejemplo, en un sistema de administración de documentosAlice, el propietario del documento puede optar por conceder permiso a otro usuario para contribuir al documento. Bob Esto establece una relación de colaboración entre Bob y el documento de Alice. El único propósito de esta relación es conceder permiso para editar y comentar el documento y, por lo tanto, esta relación se puede representar como una plantilla. En estos casos, el enfoque recomendado es crear una plantilla para cada tipo de relación. En los ejemplos siguientes hay dos tipos de relaciones Contributor yReviewer, por lo tanto, dos plantillas.

Las siguientes plantillas se pueden utilizar para crear políticas vinculadas a plantillas para usuarios individuales.

// Managed relationship permissions - Contributor template permit ( principal == ?principal, action in Action::"DocumentContributorActions", resource in ?resource ); // Managed relationship permissions - Reviewer template permit ( principal == ?principal, action in Action::"DocumentReviewerActions", resource in ?resource );

Las siguientes plantillas se pueden utilizar para crear políticas vinculadas a plantillas para grupos de usuarios. La única diferencia con las plantillas para usuarios individuales es que utilizan el in operador en lugar del. ==

// Managed relationship permissions - Contributor template permit ( principal in ?principal, action in Action::"DocumentContributorActions", resource in ?resource ); // Managed relationship permissions - Reviewer template permit ( principal in ?principal, action in Action::"DocumentReviewerActions", resource in ?resource );

A continuación, puede utilizar estas plantillas para crear políticas, como las siguientes, que representen los permisos de relaciones gestionadas cada vez que se concede acceso a un documento.

//Managed relationship permissions permit ( principal in User::"df82e4ad-949e-44cb-8acf-2d1acda71798", action in Action::"DocumentContributorActions", resource in Document::"c943927f-d803-4f40-9a53-7740272cb969" ); permit ( principal in UserGroup::"df82e4ad-949e-44cb-8acf-2d1acda71798", action in Action::"DocumentReviewerActions", resource == Document::"661817a9-d478-4096-943d-4ef1e082d19a" ); permit ( principal in User::"df82e4ad-949e-44cb-8acf-2d1acda71798", action in Action::"DocumentContributorActions", resource in Folder::"b8ee140c-fa09-46c3-992e-099438930894" );

Amazon Verified Permissions puede gestionar de manera eficiente muchas políticas individuales y detalladas durante la evaluación de la autorización y modelar las cosas de esta manera significa que Verified Permissions mantiene un registro de auditoría completo de todas las AWS CloudTrail decisiones de autorización.

Preferencia por los permisos detallados en el modelo y los permisos agregados en la interfaz de usuario

Una estrategia de la que los diseñadores suelen arrepentirse más tarde es diseñar un modelo de autorización con acciones muy amplias, como Read y Write, y darse cuenta más tarde de que es necesario adoptar medidas más específicas. La necesidad de un nivel más detallado puede estar motivada por los comentarios de los clientes a favor de controles de acceso más precisos o por los auditores de cumplimiento y seguridad, que recomiendan el uso de permisos con privilegios mínimos.

Si los permisos específicos no se definen por adelantado, tal vez se necesite una compleja conversión para cambiar el código de la aplicación y las instrucciones de política por permisos de usuario más específicos. Por ejemplo, será necesario modificar un código de la aplicación que anteriormente autorizaba una acción amplia para que utilice las acciones detalladas. Además, las políticas deberán actualizarse para reflejar la migración:

permit ( principal == User::"6688f676-1aa9-456a-acf4-228340b54e9d", // action == Action::"read", -- coarse-grained permission -- commented out action in [ // -- finer grained permissions Action::"listFolderContents", Action::"viewFile" ], resource in Account::"c863f89b-461f-4fc2-b638-e5fa5f79a48b" );

Para evitar esta costosa migración, es mejor definir los permisos detallados por adelantado. Sin embargo, esto puede resultar en una desventaja si, posteriormente, los usuarios finales se ven obligados a comprender un mayor número de permisos detallados, especialmente si la mayoría de los clientes estarían satisfechos con controles generales, como Read y Write. Para quedarse con lo mejor de ambos mundos, puede agrupar los permisos detallados en colecciones predefinidas, como Read y Write, y utilizar mecanismos como plantillas de políticas o grupos de acciones. Al usar este enfoque, los clientes solo ven los permisos generales. Sin embargo, entre bastidores, ha preparado su aplicación para el futuro al modelar los permisos generales como un conjunto de acciones detalladas. Cuando los clientes o los auditores lo soliciten, se pueden exponer los permisos detallados.

Consideración de otros motivos para solicitar la autorización

Por lo general, asociamos las comprobaciones de autorización con las solicitudes de los usuarios. La verificación es una forma de determinar si el usuario tiene permiso para realizar esa solicitud. Sin embargo, también puede utilizar los datos de autorización como un factor que influye en el diseño de la interfaz de la aplicación. Por ejemplo, es posible que desee mostrar una pantalla de inicio con una lista únicamente de los recursos a los que puede acceder el usuario final. Cuando consulte los detalles de un recurso, es posible que desee que la interfaz muestre solo las operaciones que el usuario puede realizar en ese recurso.

Estas situaciones pueden introducir desventajas en el modelo de autorización. Por ejemplo, depender en gran medida de las políticas de control de acceso basadas en atributos (ABAC) puede dificultar la respuesta rápida a la pregunta «¿quién tiene acceso a qué?» Esto se debe a que responder a esa pregunta requiere examinar cada regla comparándola con todas las entidades principales y recursos para determinar si coinciden. Como resultado, un producto que necesite optimizarse para incluir solo los recursos a los que puede acceder el usuario podría optar por utilizar un modelo de control de acceso basado en roles (). RBAC Al usarloRBAC, puede resultar más fácil iterar todas las políticas asociadas a un usuario para determinar el acceso a los recursos.