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ías empezar con una experiencia de usuario. 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? ¿Cómo están organizados? Por ejemplo, ¿los archivos se encuentran dentro de una carpeta?

• ¿La organización de los recursos desempeña un papel en el modelo de permisos?

• ¿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 roles son globales o tienen un ámbito de aplicación? Por ejemplo, ¿un «operador» está limitado a un solo inquilino o por «operador» se entiende el operador de toda la aplicación?

• ¿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 pueden hacer 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.

Para ayudar a responder a las preguntas y llegar a un modelo óptimo, haga lo siguiente:

• Revise los patrones de diseño de Cedar en la Guía de referencia sobre el lenguaje normativo de Cedar.

• Tenga en cuenta las mejores prácticas de la Guía de referencia sobre el lenguaje de las políticas de Cedar.

• Tenga en cuenta las mejores prácticas incluidas en esta página.

No existe un modelo canónico “correcto”

Cuando se diseña 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, los permisos se modelan en función de los recursos admitidos. 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, a medida que vaya desarrollando su modelo, este enfoque API centrado puede no ser adecuado para las aplicaciones con modelos de autorización muy detallados, ya que no APIs son 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 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 abstracto, por ejemploviewGroupMembership, que cada una de las tres API operaciones debe consultar.

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.

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. Para obtener más información, consulte Consideraciones de diseño para varios inquilinos de Amazon Verified Permissions en la Guía AWS prescriptiva.

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 exclusivo. 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 tendrá un gran impacto en su AWS factura. 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

Cuando su aplicación tiene varios almacenes de políticas, sus plantillas de políticas y un esquema de 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	Alto. 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.