Preguntas frecuentes

En esta sección se proporcionan respuestas a las preguntas más frecuentes sobre la implementación del control de acceso y la autorización de las API en aplicaciones SaaS multiusuario.

P: ¿Cuál es la diferencia entre autorización y autenticación?

R. La autenticación es el proceso de verificar quién es un usuario. La autorización otorga permisos a los usuarios para acceder a un recurso específico.

P: ¿Cuál es la diferencia entre la autorización y el aislamiento de inquilinos en una aplicación SaaS?

R. El aislamiento de inquilinos se refiere a los mecanismos explícitos que se utilizan en un sistema SaaS para garantizar que los recursos de cada inquilino, incluso cuando operan en una infraestructura compartida, estén aislados. La autorización de varios inquilinos se refiere a la autorización de acciones entrantes y a impedir que se implementen en el arrendatario equivocado. Un usuario hipotético podría estar autenticado y autorizado, pero podría seguir accediendo a los recursos de otro inquilino. Nada de lo relacionado con la autenticación y la autorización bloquea necesariamente este acceso, pero es necesario aislar al inquilino para lograr este objetivo. Para obtener más información sobre estos dos conceptos, consulte el debate sobre el aislamiento de inquilinos en el documento técnico Fundamentos de la arquitectura de AWS SaaS.

P: ¿Por qué debo considerar el aislamiento de inquilinos para mi solicitud de SaaS?

R. Las aplicaciones SaaS tienen varios inquilinos. Un inquilino puede ser una organización cliente o cualquier entidad externa que utilice esa aplicación SaaS. Según el diseño de la aplicación, esto significa que los inquilinos pueden estar accediendo a recursos compartidos APIs, a bases de datos u otros recursos. Es importante mantener el aislamiento de los inquilinos (es decir, estructuras que controlen estrictamente el acceso a los recursos y bloqueen cualquier intento de acceder a los recursos de otro inquilino) para evitar que los usuarios de un inquilino accedan a la información privada de otro inquilino. Las aplicaciones SaaS suelen diseñarse para garantizar que el aislamiento de los inquilinos se mantenga en toda la aplicación y que los inquilinos solo puedan acceder a sus propios recursos.

P: ¿Por qué necesito un modelo de control de acceso?

R. Los modelos de control de acceso se utilizan para crear un método coherente para determinar cómo conceder el acceso a los recursos de una aplicación. Esto se puede hacer asignando funciones a los usuarios que estén estrechamente alineadas con la lógica empresarial, o puede basarse en otros atributos contextuales, como la hora del día o si un usuario cumple una condición predefinida. Los modelos de control de acceso constituyen la lógica básica que utiliza la aplicación al tomar decisiones de autorización para determinar los permisos de los usuarios.

P: ¿Es necesario el control de acceso mediante API para mi aplicación?

R: Sí. APIs debe comprobar siempre que la persona que llama tiene el acceso adecuado. El control de acceso generalizado a través de la API también garantiza que el acceso solo se conceda en función de los inquilinos, de modo que se pueda mantener el aislamiento adecuado.

P: ¿Por qué se PDPs recomiendan los motores de políticas o la autorización?

R. Un punto de decisión de políticas (PDP) permite transferir la lógica de autorización del código de la aplicación a un sistema independiente. Esto puede simplificar el código de la aplicación. También proporciona una interfaz easy-to-use ideal para tomar decisiones de autorización para microservicios APIs, capas de backend for Frontend (BFF) o cualquier otro componente de la aplicación.

P: ¿Qué es un PEP?

R. Un punto de aplicación de políticas (PEP) es responsable de recibir las solicitudes de autorización que se envían al PDP para su evaluación. Un PEP puede estar en cualquier parte de una aplicación donde se deban proteger los datos y los recursos o donde se aplique la lógica de autorización. PEPs son relativamente simples en comparación con. PDPs Un PEP es responsable únicamente de solicitar y evaluar una decisión de autorización y no requiere que se le incorpore ninguna lógica de autorización.

P: ¿Cómo debo elegir entre los permisos verificados de Amazon y OPA?

R. Para elegir entre permisos verificados y Open Policy Agent (OPA), ten siempre en cuenta tu caso de uso y tus requisitos exclusivos. Verified Permissions ofrece una forma totalmente gestionada de definir permisos detallados, auditar los permisos en todas las aplicaciones y centralizar el sistema de administración de políticas para sus aplicaciones, a la vez que se cumplen los requisitos de latencia de las aplicaciones con un procesamiento de milisegundos. OPA es un motor de políticas de código abierto y de uso general que también puede ayudarlo a unificar las políticas en toda su gama de aplicaciones. Para ejecutar OPA, debe alojarla en su AWS entorno, normalmente con un contenedor o funciones. AWS Lambda

Verified Permissions usa el lenguaje de políticas de código abierto Cedar, mientras que OPA usa Rego. Por lo tanto, la familiaridad con uno de estos lenguajes podría llevarle a elegir esa solución. Sin embargo, te recomendamos que leas información sobre ambos idiomas y, a continuación, retomes el problema que intentas resolver para encontrar la mejor solución para tu caso de uso.

P: ¿Existen alternativas de código abierto a los permisos verificados y a la OPA?

R. Hay algunos sistemas de código abierto que son similares a Verified Permissions y al Open Policy Agent (OPA), como el Common Expression Language (CEL). Esta guía se centra tanto en los permisos verificados, que es una administración de permisos escalable y un servicio de autorización detallado, como en la OPA, que está ampliamente adoptada, documentada y adaptable a muchos tipos diferentes de aplicaciones y requisitos de autorización.

P: ¿Necesito redactar un servicio de autorización para usar la OPA o puedo interactuar directamente con la OPA?

R: Puede interactuar con OPA directamente. En el contexto de esta guía, un servicio de autorización se refiere a un servicio que traduce las solicitudes de decisiones de autorización en consultas de la OPA y viceversa. Si su solicitud puede consultar y aceptar las respuestas de la OPA directamente, no es necesario introducir esta complejidad adicional.

P: ¿Cómo superviso el tiempo de actividad de mis agentes de la OPA y con fines de auditoría?

R: La OPA proporciona un registro y una supervisión básica del tiempo de actividad, aunque es probable que su configuración predeterminada no sea suficiente para las implementaciones empresariales. Para obtener más información, consulte la DevOps sección sobre supervisión y registro que aparece anteriormente en esta guía.

P: ¿Cómo puedo supervisar los permisos verificados para comprobar el tiempo de actividad y realizar auditorías?

R. Los permisos verificados son un servicio AWS gestionado y se puede supervisar su disponibilidad a través del AWS Health Dashboard. Además, Verified Permissions permite iniciar AWS CloudTrail sesión en Amazon CloudWatch Logs, Amazon S3 y Amazon Data Firehose.

P: ¿Qué sistemas operativos y AWS servicios puedo usar para ejecutar OPA?

R. Puede ejecutar OPA en macOS, Windows y Linux. Los agentes de OPA se pueden configurar en agentes de Amazon Elastic Compute Cloud (Amazon EC2), así como en servicios de contenerización como Amazon Elastic Container Service (Amazon ECS) y Amazon Elastic Kubernetes Service (Amazon EKS).

P: ¿Qué sistemas operativos y AWS servicios puedo usar para ejecutar los permisos verificados?

R: Verified Permissions es un servicio AWS gestionado y está gestionado por AWS. No se necesita ninguna configuración, instalación o alojamiento adicionales para utilizar los permisos verificados, excepto la capacidad de realizar solicitudes de autorización al servicio.

P: ¿Puedo ejecutar OPA AWS Lambda?

R. Puede ejecutar OPA en Lambda como una biblioteca Go. Para obtener información sobre cómo hacerlo con un autorizador Lambda de API Gateway, consulte la entrada del AWS blog Creación de un autorizador Lambda personalizado mediante Open Policy Agent.

P: ¿Cómo debo decidir entre un enfoque de PDP distribuido o un PDP centralizado?

R: Esto depende de su aplicación. Lo más probable es que se determine en función de la diferencia de latencia entre un modelo PDP distribuido y uno centralizado. Le recomendamos que cree una prueba de concepto y pruebe el rendimiento de la aplicación para verificar la solución.

P: ¿Puedo usar OPA también para otros casos de uso APIs?

R: Sí. La documentación de la OPA proporciona ejemplos de Kubernetes, Envoy, Docker, Kafka, SSH y sudo, y Terraform. Además, OPA puede devolver respuestas JSON arbitrarias a las consultas mediante el uso de reglas parciales de Rego. Según la consulta, OPA se puede utilizar para responder a muchas preguntas con respuestas en formato JSON.

P: ¿Puedo usar también los permisos verificados para otros casos de uso APIs?

R: Sí. Los permisos verificados pueden proporcionar una ALLOW DENY respuesta a cualquier solicitud de autorización que reciba. Los permisos verificados pueden proporcionar respuestas de autorización para cualquier aplicación o servicio que requiera decisiones de autorización.

P: ¿Puedo crear políticas en Verified Permissions utilizando el lenguaje de políticas de IAM?

R: No. Debe utilizar el lenguaje de políticas de Cedar para crear políticas. Cedar se ha diseñado para facilitar la gestión de permisos de los recursos de las aplicaciones de los clientes, mientras que el lenguaje de políticas AWS Identity and Access Management (IAM) ha evolucionado para facilitar el control de acceso a AWS los recursos.