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.
Diseñe modelos para OPA
Uso de un PDP centralizado con PEPs APIs
El APIs modelo de punto de decisión de políticas (PDP) centralizado con puntos de aplicación de políticas (PEPs) sigue las mejores prácticas del sector para crear un sistema eficaz y de fácil mantenimiento para el control de acceso y la autorización de las API. Este enfoque se basa en varios principios clave:
-
La autorización y el control de acceso a la API se aplican en varios puntos de la aplicación.
-
La lógica de autorización es independiente de la aplicación.
-
Las decisiones de control de acceso están centralizadas.
Este modelo utiliza un PDP centralizado para tomar decisiones de autorización. PEPs se implementan en todos los APIs casos para realizar solicitudes de autorización al PDP. El siguiente diagrama muestra cómo se puede implementar este modelo en una hipotética aplicación SaaS multiusuario.
Flujo de la aplicación (ilustrado con rótulos numerados en azul en el diagrama):
-
Un usuario autenticado con un JWT genera una solicitud HTTP a Amazon. CloudFront
-
CloudFront reenvía la solicitud a Amazon API Gateway, que está configurado como CloudFront origen.
-
Se llama a un autorizador personalizado de API Gateway para verificar el JWT.
-
Los microservicios responden a la solicitud.
Flujo de autorización y control de acceso a la API (ilustrado con rótulos numerados en rojo en el diagrama):
-
El PEP llama al servicio de autorización y pasa los datos de la solicitud, incluidos los datos. JWTs
-
El servicio de autorización (PDP) toma los datos de la solicitud y consulta la API REST de un agente de OPA, que funciona como un sidecar. Los datos de la solicitud sirven como entrada para la consulta.
-
La OPA evalúa la entrada en función de las políticas relevantes especificadas en la consulta. Los datos se importan para tomar una decisión de autorización si es necesario.
-
La OPA devuelve la decisión al servicio de autorización.
-
La decisión de autorización se devuelve al PEP y se evalúa.
En esta arquitectura, PEPs solicite las decisiones de autorización en los puntos de enlace del servicio para Amazon CloudFront y Amazon API Gateway, y para cada microservicio. La decisión de autorización la toma un servicio de autorización (el PDP) con un sidecar OPA. Puede utilizar este servicio de autorización como un contenedor o como una instancia de servidor tradicional. El sidecar de OPA expone su RESTful API de forma local, por lo que solo el servicio de autorización puede acceder a ella. El servicio de autorización expone una API independiente que está disponible para. PEPs Hacer que el servicio de autorización actúe como intermediario entre PEPs una OPA permite insertar cualquier lógica de transformación entre PEPs una OPA que pueda ser necesaria, por ejemplo, cuando la solicitud de autorización de un PEP no se ajusta a la entrada de consulta esperada por la OPA.
También puede usar esta arquitectura con motores de políticas personalizados. Sin embargo, cualquier ventaja que se obtenga con la OPA debe sustituirse por la lógica proporcionada por el motor de políticas personalizado.
Un PDP centralizado con PEPs on APIs proporciona una opción sencilla para crear un sistema de autorización sólido. APIs Es fácil de implementar y también proporciona una easy-to-use interfaz repetible para tomar decisiones de autorización para microservicios APIs, capas de backend for Frontend (BFF) u otros componentes de la aplicación. Sin embargo, este enfoque puede generar una latencia excesiva en la aplicación, ya que las decisiones de autorización requieren llamar a una API independiente. Si la latencia de la red es un problema, podría considerar la posibilidad de utilizar un PDP distribuido.
Uso de un PDP distribuido con PEPs APIs
El APIs modelo de punto de decisión de políticas distribuido (PDP) con puntos de aplicación de políticas (PEPs) sigue las mejores prácticas del sector para crear un sistema eficaz de control y autorización del acceso a las API. Al igual que con el PDP centralizado PEPs sin APIs modelo, este enfoque apoya los siguientes principios clave:
-
La autorización y el control de acceso a la API se aplican en varios puntos de la aplicación.
-
La lógica de autorización es independiente de la aplicación.
-
Las decisiones de control de acceso están centralizadas.
Quizás se pregunte por qué las decisiones de control de acceso están centralizadas cuando se distribuye el PDP. Si bien el PDP puede estar en varios lugares de una aplicación, debe usar la misma lógica de autorización para tomar decisiones de control de acceso. Todos PDPs proporcionan las mismas decisiones de control de acceso con las mismas entradas. PEPs se implementan en todos los APIs casos para realizar solicitudes de autorización al PDP. La siguiente figura muestra cómo se puede implementar este modelo distribuido en una hipotética aplicación SaaS multiusuario.
En este enfoque, PDPs se implementan en varios lugares de la aplicación. En el caso de los componentes de la aplicación que tienen capacidades informáticas integradas que pueden ejecutar OPA y admitir un PDP, como un servicio en contenedores con un sidecar o una instancia de Amazon Elastic Compute Cloud (Amazon EC2), las decisiones de PDP se pueden integrar directamente en el componente de la aplicación sin tener que realizar una llamada de RESTful API a un servicio PDP centralizado. Esto tiene la ventaja de reducir la latencia que se puede encontrar en el modelo PDP centralizado, ya que no todos los componentes de la aplicación tienen que realizar llamadas a la API adicionales para obtener decisiones de autorización. Sin embargo, un PDP centralizado sigue siendo necesario en este modelo para los componentes de la aplicación que no tienen capacidades informáticas integradas que permitan la integración directa de un PDP, como el servicio Amazon o Amazon API CloudFront Gateway.
El siguiente diagrama muestra cómo se puede implementar esta combinación de un PDP centralizado y un PDP distribuido en una hipotética aplicación SaaS multiusuario.
Flujo de la aplicación (ilustrado con rótulos numerados en azul en el diagrama):
-
Un usuario autenticado con un JWT genera una solicitud HTTP a Amazon. CloudFront
-
CloudFront reenvía la solicitud a Amazon API Gateway, que está configurado como CloudFront origen.
-
Se llama a un autorizador personalizado de API Gateway para verificar el JWT.
-
Los microservicios responden a la solicitud.
Flujo de autorización y control de acceso a la API (ilustrado con rótulos numerados en rojo en el diagrama):
-
El PEP llama al servicio de autorización y pasa los datos de la solicitud, incluidos los datos. JWTs
-
El servicio de autorización (PDP) toma los datos de la solicitud y consulta la API REST de un agente de OPA, que funciona como un sidecar. Los datos de la solicitud sirven como entrada para la consulta.
-
La OPA evalúa la entrada en función de las políticas relevantes especificadas en la consulta. Los datos se importan para tomar una decisión de autorización si es necesario.
-
La OPA devuelve la decisión al servicio de autorización.
-
La decisión de autorización se devuelve al PEP y se evalúa.
En esta arquitectura, PEPs solicite las decisiones de autorización en los puntos finales del servicio para CloudFront API Gateway y para cada microservicio. La decisión de autorización de los microservicios la toma un servicio de autorización (el PDP) que funciona como un sidecar con el componente de la aplicación. Este modelo es posible para microservicios (o servicios) que se ejecutan en contenedores o instancias de Amazon Elastic Compute Cloud (Amazon EC2). Las decisiones de autorización para servicios como API Gateway y, aun así, CloudFront requerirían ponerse en contacto con un servicio de autorización externo. En cualquier caso, el servicio de autorización expone una API que está disponible para PEPs. Hacer que el servicio de autorización actúe como intermediario entre PEPs una OPA permite insertar cualquier lógica de transformación entre PEPs una OPA que pueda ser necesaria, por ejemplo, cuando la solicitud de autorización de un PEP no se ajusta a la entrada de consulta esperada por la OPA.
También puede usar esta arquitectura con motores de políticas personalizados. Sin embargo, cualquier ventaja que se obtenga con la OPA debe sustituirse por la lógica proporcionada por el motor de políticas personalizado.
Un PDP distribuido con PEPs on APIs ofrece la opción de crear un sistema de autorización sólido para APIs él. Es fácil de implementar y proporciona una easy-to-use interfaz repetible para tomar decisiones de autorización para microservicios APIs, capas de backend para frontend (BFF) u otros componentes de la aplicación. Este enfoque también tiene la ventaja de reducir la latencia que puede producirse en el modelo PDP centralizado.
Uso de un PDP distribuido como biblioteca
También puede solicitar decisiones de autorización a un PDP que esté disponible como biblioteca o paquete para su uso en una aplicación. OPA se puede usar como una biblioteca de terceros de Go. En el caso de otros lenguajes de programación, la adopción de este modelo generalmente implica crear un motor de políticas personalizado.
