Editor Top
|
Al desarrollar una nueva aplicación o integrar una existente en un nuevo entorno, la autenticación y autorización del usuario requiere un esfuerzo significativo para implementarse correctamente. En el pasado, habría creado su propio sistema de autenticación, pero hoy puede usar un proveedor de identidad externo como Amazon Cognito. Sin embargo, la lógica de autorización normalmente se implementa en el código.
Esto podría comenzar de manera bastante simple, con todos los usuarios asignados a un rol para su función laboral. Sin embargo, con el tiempo, estos permisos se vuelven cada vez más complejos. El número de roles se expande a medida que los permisos se vuelven más detallados. Los nuevos casos de uso impulsan la necesidad de permisos personalizados. Por ejemplo, un usuario puede compartir un documento con otro en un rol diferente, o un agente de soporte puede requerir acceso temporal a una cuenta de cliente para resolver un problema. La administración de permisos en el código es propensa a errores y presenta desafíos significativos al auditar permisos y decidir quién tiene acceso a qué, particularmente cuando estos permisos se expresan en diferentes aplicaciones y usan múltiples lenguajes de programación.
En re: inventar 2022, presentamos en versión preliminar Amazon Verified Permissions, un servicio de autorización y administración de permisos detallado para sus aplicaciones que se puede usar a cualquier escala. Amazon Verified Permissions centraliza los permisos en un almacén de políticas y ayuda a los desarrolladores a usar esos permisos para autorizar las acciones de los usuarios dentro de sus aplicaciones. De manera similar a cómo un proveedor de identidad simplifica la autenticación, un almacén de políticas le permite administrar la autorización de manera consistente y escalable.
Para definir permisos detallados, Amazon Verified Permissions utiliza Cedroun lenguaje de políticas de código abierto y kit de desarrollo de software (SDK) para el control de acceso. Puede definir un esquema para su modelo de autorización en términos de tipos principales, tipos de recursos y acciones válidas. De esta forma, cuando se crea una política, se valida con su modelo de autorización. Puede simplificar la creación de políticas similares utilizando plantillas. Los cambios en el almacén de políticas se auditan para que pueda ver quién realizó los cambios y cuándo.
Luego, puede conectar sus aplicaciones a Amazon Verified Permissions a través de los SDK de AWS para autorizar solicitudes de acceso. Para cada solicitud de autorización, las políticas relevantes se recuperan y evalúan para determinar si la acción está permitida o no. Puede reproducir esas solicitudes de autorización para confirmar que los permisos funcionan según lo previsto.
Hoy, me complace compartir que Amazon Verified Permissions está generalmente disponible con nuevas capacidades y una experiencia de usuario simplificada en la consola de administración de AWS.
Veamos cómo puedes usarlo en la práctica.
Creación de un almacén de políticas con permisos verificados de Amazon
En la consola de permisos verificados de Amazon, elijo Crear almacén de políticas. Un almacén de políticas es un contenedor lógico que almacena políticas y esquemas. Las decisiones de autorización se toman en función de todas las políticas presentes en un almacén de políticas.
Para configurar el nuevo almacén de políticas, puedo usar diferentes métodos. Puedo comenzar con una configuración guiada, un almacén de políticas de muestra (como una aplicación para compartir fotos, una tienda en línea o un administrador de tareas) o un almacén de políticas vacío (recomendado para usuarios avanzados). Yo selecciono Configuración guiadaingrese un espacio de nombres para mi esquema (MyApp), y elige Próximo.
Los recursos son los objetos sobre los que pueden actuar los principales. En mi aplicación, tengo Users (directores) que pueden crear, leer, actualizar y eliminar Documents (recursos). Empiezo a definir el Documents tipo de recurso.
Ingreso el nombre del tipo de recurso y agrego dos atributos requeridos:
owner(Cadena) para especificar quién es el propietario del documento.isPublic(booleano) para marcar documentos públicos que cualquiera puede leer.
Especifico cuatro acciones para el Document tipo de recurso:
DocumentCreateDocumentReadDocumentUpdateDocumentDelete
yo entro User como el nombre del tipo principal que usará estas acciones en Documents. Entonces, elijo Próximo.
Ahora configuro el User tipo principal. Puedo usar una configuración personalizada para integrar una fuente de identidad externa, pero en este caso, uso un grupo de usuarios de Amazon Cognito que creé antes. yo elijo Conectar grupo de usuarios.
En el cuadro de diálogo, selecciono la región de AWS donde se encuentra el grupo de usuarios, ingreso el ID del grupo de usuarios y elijo Conectar.
Ahora que el grupo de usuarios de Amazon Cognito está conectado, puedo agregar otro nivel de protección al validar los ID de la aplicación del cliente. Por ahora, elijo no usar esta opción.
En el Atributos principales sección, selecciono qué atributos planeo usar para el control de acceso basado en atributos en mis políticas. Yo selecciono sub (el sujeto), utilizado para identificar al usuario final de acuerdo con el Especificación de OpenID Connect. Puedo seleccionar más atributos. Por ejemplo, puedo usar email_verified en una política para otorgar permisos solo a los usuarios de Amazon Cognito cuyo correo electrónico se haya verificado.
Como parte de la creación del almacén de políticas, creo una primera política para dar acceso de lectura al usuario danilop hacia doc.txt documento.
En el siguiente código, la consola me brinda una vista previa de la política resultante utilizando el lenguaje Cedar.
Finalmente, elijo Crear almacén de políticas.
Adición de permisos al almacén de políticas
Ahora que se ha creado el almacén de políticas, elijo Políticas en el panel de navegación. En el Crear política desplegable, elijo Crear política estática. Una política estática contiene toda la información necesaria para su evaluación. En mi segunda política, permito que cualquier usuario lea documentos públicos. Por defecto todo está prohibido, así que en Efecto de la política yo elijo Permiso.
En el Alcance de la políticaDejo Todos los directores y Todos los recursos seleccionado y seleccione el DocumentRead acción. En el Política sección, cambio la when cláusula de condición para limitar los permisos a los recursos donde isPublic es igual a true:
Ingreso una descripción para la póliza y elijo Crear política.
Para mi tercera política, creo otra política estática para permitir el acceso total al propietario de un documento. De nuevo, en Efecto de la políticaelijo Permitir y, en el Alcance de la políticaDejo Todos los directores y Todos los recursos seleccionado. Esta vez también me despido Todas las acciones seleccionado.
En el Política sección, cambio la when cláusula de condición para limitar los permisos a los recursos donde el owner es igual a la sub del rector:
En mi aplicación, necesito permitir el acceso de lectura a usuarios específicos que no son propietarios de un documento. Para simplificar eso, creo una plantilla de política. Las plantillas de políticas me permiten crear políticas a partir de una plantilla que usa marcadores de posición para algunos de sus valores, como el principal o el recurso. Los marcadores de posición en una plantilla son palabras clave que comienzan con el ? personaje.
En el panel de navegación, elijo Plantillas de políticas y luego Crear plantilla de política. Ingreso una descripción y uso el siguiente cuerpo de plantilla de política. Al usar esta plantilla, puedo especificar el valor para el ?principal y ?resource marcadores de posición
Finalizo la creación de la plantilla de política. Ahora uso la plantilla para simplificar la creación de políticas. yo elijo Políticas en el panel de navegación y luego Crear una política vinculada a una plantilla en el Crear menú desplegable de políticas. Selecciono la plantilla de política que acabo de crear y elijo Próximo.
Para dar acceso a un usuario (danilop) para un documento específico (new-doc.txt), solo paso los siguientes valores (tenga en cuenta que MyApp es el espacio de nombres del almacén de políticas):
- Para el Principal:
MyApp::User::"danilop" - Para el Recurso:
MyApp::Document::"new-doc.txt"
Finalizo la creación de la póliza. Ahora es el momento de probar si las políticas funcionan como se esperaba.
Probar políticas en la consola
En mis aplicaciones, puedo usar los SDK de AWS para ejecutar una solicitud de autorización. La consola proporciona una forma de simular lo que harían mis aplicaciones. yo elijo Banco de pruebas en el panel de navegación. Para simplificar las pruebas, utilizo el modo visual. Como alternativa, tengo la opción de usar la misma sintaxis JSON que en los SDK.
Como Principalpaso el janedoe usuario. Como RecursoYo suelo requirements.txt. No es un documento público (isPublic es false) y el owner atributo es igual a janedoe‘s sub. Para el AcciónYo selecciono MyApp::Action::"DocumentUpdate".
Al ejecutar una solicitud de autorización, puedo pasar Entidades adicionales con más información sobre principales y recursos asociados con la solicitud. Por ahora, dejo esta parte vacía.
yo elijo Ejecutar solicitud de autorización en la parte superior para ver la decisión basada en las políticas actuales. Como era de esperar, la decisión es permitir. Aquí, también veo qué políticas han sido satisfechas por la solicitud de autorización. En este caso, es la política la que permite el acceso total al propietario del documento.
Puedo probar otros valores. Si cambio el propietario del documento y la acción a DocumentReadla decisión es denegar. Si luego configuro el atributo de recurso isPublic a truela decisión es permitir porque existe una política que permite a todos los usuarios leer documentos públicos.
Manejo de grupos en permisos
Los usuarios administrativos de mi aplicación deben poder eliminar cualquier documento. Para hacerlo, creo un rol para los usuarios administradores. Primero, elijo Esquema en el panel de navegación y luego Editar esquema. En la lista de tipos de entidades, elijo agregar una nueva. yo suelo Role como Escribe un nombre y añádelo. Luego, selecciono User en los tipos de entidad y editarlo para agregar Role como padre. Guardo los cambios y creo la siguiente política:
En el Banco de pruebasejecuto una solicitud de autorización para verificar si el usuario jeffbarr puede eliminar (DocumentDelete) recurso doc.txt. Como no es el propietario del recurso, se deniega la solicitud.
Ahora, en el Entidades adicionalesagrego el MyApp::User entidad con jeffbarr como identificador. Como padre, agrego el MyApp::Role entidad con admin como identificador y confirmar. La consola me avisa de esa entidad MyApp::Role::"admin" se hace referencia, pero no se incluye en los datos de entidades adicionales. Elijo agregarlo y solucionar este problema.
Vuelvo a ejecutar una solicitud de autorización y ahora está permitida porque, según las entidades adicionales, el principal (jeffbarr) es un admin.
Uso de permisos verificados de Amazon en su aplicación
En mis aplicaciones, puedo ejecutar solicitudes de autorización usando el isAuthorized acción API (o isAuthrizedWithTokensi el principal proviene de una fuente de identidad externa).
Por ejemplo, el siguiente código de Python utiliza el SDK de AWS para Python (Boto3) para comprobar si un usuario tiene acceso de lectura a un documento. La solicitud de autorización utiliza el almacén de políticas que acabo de crear.
import boto3
import time
verifiedpermissions_client = boto3.client("verifiedpermissions")
POLICY_STORE_ID = "XAFTHeCQVKkZhsQxmAYXo8"
def is_authorized_to_read(user, resource):
authorization_result = verifiedpermissions_client.is_authorized(
policyStoreId=POLICY_STORE_ID,
principal={"entityType": "MyApp::User", "entityId": user},
action={"actionType": "MyApp::Action", "actionId": "DocumentRead"},
resource={"entityType": "MyApp::Document", "entityId": resource}
)
print('Can {} read {} ?'.format(user, resource))
decision = authorization_result["decision"]
if decision == "ALLOW":
print("Request allowed")
return True
else:
print("Request denied")
return False
if is_authorized_to_read('janedoe', 'doc.txt'):
print("Here's the doc...")
if is_authorized_to_read('danilop', 'doc.txt'):
print("Here's the doc...")
Ejecuto este código y, como puede esperar, el resultado está en línea con las pruebas realizadas anteriormente.
Disponibilidad y precios
Amazon Verified Permissions está disponible hoy en todas las regiones comerciales de AWS, excepto aquellas que se encuentran en China.
Con Amazon Verified Permissions, solo paga por lo que usa en función de la cantidad de solicitudes de autorización y llamadas API realizadas al servicio. Para obtener más información, consulte Precios de permisos verificados de Amazon.
Con los permisos verificados de Amazon, puede configurar permisos detallados mediante el Cedro lenguaje de políticas y simplificar el código de sus aplicaciones. De esta forma, los permisos se mantienen en un almacén centralizado y son más fáciles de auditar. Aquí puedes leer más sobre cómo construimos Cedar con razonamiento automatizado y pruebas diferenciales.
Administre la autorización de sus aplicaciones con Amazon Verified Permissions.
— Danilo
