Autorización de SaaS para múltiples inquilinos y control de acceso a la API: opciones de implementación y mejores prácticas

Tabby Ward, Thomas Davis, Gideon Landeman y Tomas Riha, Amazon Web Services ()AWS

Mayo de 2024 (historia del documento)

La autorización y el control de acceso a las API representan un desafío para muchas aplicaciones de software, en particular, para las aplicaciones de software como servicio (SaaS) multiusuario. Esta complejidad es evidente si se tiene en cuenta la proliferación de API de microservicios que deben protegerse y la gran cantidad de condiciones de acceso que se derivan de los diferentes inquilinos, características de los usuarios y estados de las aplicaciones. Para abordar estos problemas de manera eficaz, una solución debe imponer el control de acceso en las numerosas API que presentan los microservicios, las capas de backend for Frontend (BFF) y otros componentes de una aplicación SaaS multiusuario. Este enfoque debe ir acompañado de un mecanismo que sea capaz de tomar decisiones de acceso complejas en función de muchos factores y atributos.

Tradicionalmente, el control de acceso y la autorización de las API se gestionaban mediante una lógica personalizada en el código de la aplicación. Este enfoque era propenso a errores y no era seguro, ya que los desarrolladores que tenían acceso a este código podían cambiar la lógica de autorización de forma accidental o deliberada, lo que podía provocar un acceso no autorizado. Era difícil auditar las decisiones adoptadas mediante la lógica personalizada en el código de la aplicación, ya que los auditores tenían que sumergirse en la lógica personalizada para determinar su eficacia a la hora de mantener un estándar concreto. Además, en general, el control de acceso a las API era innecesario, ya que no había tantas API que proteger. El cambio de paradigma en el diseño de aplicaciones para favorecer los microservicios y las arquitecturas orientadas a los servicios ha aumentado el número de API que deben utilizar una forma de autorización y control de acceso. Además, la necesidad de mantener el acceso basado en el inquilino en una aplicación de SaaS multiinquilino presenta desafíos de autorización adicionales para preservar el arrendamiento. Las mejores prácticas descritas en esta guía ofrecen varios beneficios:

• La lógica de autorización se puede centralizar y escribir en un lenguaje declarativo de alto nivel que no es específico de ningún lenguaje de programación.

• La lógica de autorización se extrae del código de la aplicación y se puede aplicar como un patrón repetible a todas las API de una aplicación.

• La abstracción evita que los desarrolladores realicen cambios accidentales en la lógica de autorización.

• La integración en una aplicación SaaS es coherente y sencilla.

• La abstracción evita la necesidad de escribir una lógica de autorización personalizada para cada punto final de la API.

• Las auditorías se simplifican porque el auditor ya no necesita revisar el código para determinar los permisos.

• El enfoque descrito en esta guía admite el uso de varios paradigmas de control de acceso en función de los requisitos de la organización.

• Este enfoque de autorización y control de acceso proporciona una forma sencilla y directa de mantener el aislamiento de los datos de los inquilinos en la capa de API de una aplicación SaaS.

• Las mejores prácticas proporcionan un enfoque coherente a la hora de incorporar y retirar inquilinos en lo que respecta a la autorización.

• Este enfoque ofrece diferentes modelos de despliegue de autorizaciones (agrupados o aislados), que presentan ventajas y desventajas, como se explica en esta guía.

Resultados empresariales específicos

Esta guía prescriptiva describe los patrones de diseño repetibles para los controles de autorización y acceso a las API que se pueden implementar para aplicaciones SaaS multiusuario. Esta guía está destinada a cualquier equipo que desarrolle aplicaciones con requisitos de autorización complejos o necesidades estrictas de control de acceso a la API. La arquitectura detalla la creación de un punto de decisión política (PDP) o un motor de políticas y la integración de los puntos de aplicación de políticas (PEP) en las API. Se discuten dos opciones específicas para crear un PDP: usar Amazon Verified Permissions con el SDK de Cedar y usar Open Policy Agent (OPA) con el lenguaje de políticas Rego. La guía también analiza la toma de decisiones de acceso basadas en un modelo de control de acceso basado en atributos (ABAC) o en un modelo de control de acceso basado en roles (RBAC), o en una combinación de ambos modelos. Le recomendamos que utilice los patrones y conceptos de diseño que se proporcionan en esta guía para informar y estandarizar la implementación de la autorización y el control de acceso a las API en aplicaciones SaaS multiusuario. Esta guía ayuda a lograr los siguientes resultados empresariales:

• Arquitectura de autorización de API estandarizada para aplicaciones SaaS multiusuario: esta arquitectura distingue entre tres componentes: el punto de administración de políticas (PAP) donde se almacenan y administran las políticas, el punto de decisión de políticas (PDP) donde se evalúan esas políticas para tomar una decisión de autorización y el punto de aplicación de políticas (PEP) que hace cumplir esa decisión. El servicio de autorización hospedado, Verified Permissions, funciona como PAP y como PDP. Como alternativa, puede crear su PDP usted mismo utilizando un motor de código abierto como Cedar u OPA.

• Separación de la lógica de autorización de las aplicaciones: la lógica de autorización, cuando está integrada en el código de la aplicación o se implementa mediante un mecanismo de aplicación ad hoc, puede estar sujeta a cambios accidentales o malintencionados que provocan el acceso involuntario a los datos entre usuarios u otras infracciones de seguridad. Para ayudar a mitigar estas posibilidades, puede utilizar un PAP, como Verified Permissions, para almacenar las políticas de autorización independientemente del código de la aplicación y aplicar una gobernanza sólida a la gestión de esas políticas. Las políticas se pueden mantener de forma centralizada en un lenguaje declarativo de alto nivel, lo que hace que mantener la lógica de autorización sea mucho más sencillo que cuando se integran políticas en varias secciones del código de la aplicación. Este enfoque también garantiza que las actualizaciones se apliquen de forma coherente.

• Enfoque flexible de los modelos de control de acceso: el control de acceso basado en roles (RBAC), el control de acceso basado en atributos (ABAC) o una combinación de ambos modelos son todos enfoques válidos para el control de acceso. Estos modelos intentan cumplir con los requisitos de autorización de una empresa mediante el uso de diferentes enfoques. En esta guía se comparan y contrastan estos modelos para ayudarle a seleccionar el modelo que mejor se adapte a su organización. La guía también analiza cómo se aplican estos modelos a los diferentes lenguajes de políticas de autorización, como OPA/Rego y Cedar. Las arquitecturas analizadas en esta guía permiten adoptar uno o ambos modelos con éxito.

• Control estricto del acceso a las API: esta guía proporciona un método para proteger las API de forma coherente y generalizada en una aplicación con un mínimo esfuerzo. Esto resulta especialmente útil para las arquitecturas de aplicaciones orientadas a servicios o de microservicios que, por lo general, utilizan un gran número de API para facilitar las comunicaciones entre aplicaciones. El estricto control de acceso a las API ayuda a aumentar la seguridad de una aplicación y la hace menos vulnerable a los ataques o la explotación.

Aislamiento de inquilinos y autorización de múltiples inquilinos

Esta guía se refiere a los conceptos de aislamiento de inquilinos y autorización de inquilinos múltiples. 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 consiste en autorizar las acciones entrantes y evitar que se implementen en el arrendatario equivocado. Un usuario hipotético podría estar autenticado y autorizado y, aun así, acceder a los recursos de otro inquilino. La autenticación y la autorización no bloquearán este acceso; es necesario implementar el aislamiento de los inquilinos para lograr este objetivo. Para obtener una explicación más amplia de las diferencias entre estos dos conceptos, consulte la sección sobre el aislamiento de inquilinos del documento técnico sobre los fundamentos de la arquitectura de SaaS.