As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Modelos de design para OPA
Usando um PDP centralizado com um PEPs APIs
O ponto de decisão política (PDP) centralizado com pontos de aplicação de políticas (PEPs) no APIs modelo segue as melhores práticas do setor para criar um sistema eficaz e de fácil manutenção para controle e autorização de acesso à API. Essa abordagem apóia vários princípios fundamentais:
-
A autorização e o controle de acesso à API são aplicados em vários pontos do aplicativo.
-
A lógica de autorização é independente do aplicativo.
-
As decisões de controle de acesso são centralizadas.
Esse modelo usa um PDP centralizado para tomar decisões de autorização. PEPs são implementados de todo APIs para fazer solicitações de autorização ao PDP. O diagrama a seguir mostra como você pode implementar esse modelo em um aplicativo SaaS multilocatário hipotético.
Fluxo do aplicativo (ilustrado com textos explicativos numerados em azul no diagrama):
-
Um usuário autenticado com um JWT gera uma solicitação HTTP para a Amazon. CloudFront
-
CloudFront encaminha a solicitação para o Amazon API Gateway, que está configurado como CloudFront origem.
-
Um autorizador personalizado do API Gateway é chamado para verificar o JWT.
-
Os microsserviços respondem à solicitação.
Fluxo de autorização e controle de acesso à API (ilustrado com textos explicativos numerados em vermelho no diagrama):
-
O PEP chama o serviço de autorização e passa os dados da solicitação, incluindo qualquer JWTs um.
-
O serviço de autorização (PDP) pega os dados da solicitação e consulta uma API REST do agente OPA, que está sendo executada como um sidecar. Os dados da solicitação servem como entrada para a consulta.
-
A OPA avalia a entrada com base nas políticas relevantes especificadas pela consulta. Os dados são importados para tomar uma decisão de autorização, se necessário.
-
A OPA devolve uma decisão ao serviço de autorização.
-
A decisão de autorização é devolvida ao PEP e avaliada.
Nessa arquitetura, PEPs solicite decisões de autorização nos endpoints de serviço da Amazon CloudFront e do Amazon API Gateway e para cada microsserviço. A decisão de autorização é tomada por um serviço de autorização (o PDP) com um sidecar da OPA. Você pode operar esse serviço de autorização como um contêiner ou como uma instância de servidor tradicional. O sidecar da OPA expõe sua RESTful API localmente para que a API seja acessível somente ao serviço de autorização. O serviço de autorização expõe uma API separada que está disponível para o. PEPs Fazer com que o serviço de autorização PEPs atue como intermediário entre uma OPA permite a inserção de qualquer lógica de transformação entre PEPs uma OPA que possa ser necessária, por exemplo, quando a solicitação de autorização de um PEP não está em conformidade com a entrada de consulta esperada pela OPA.
Você também pode usar essa arquitetura com mecanismos de política personalizados. No entanto, todas as vantagens obtidas com o OPA devem ser substituídas pela lógica fornecida pelo mecanismo de política personalizada.
Um PDP centralizado com PEPs on APIs fornece uma opção fácil de criar um sistema de autorização robusto para. APIs É simples de implementar e também fornece uma easy-to-use interface repetível para tomar decisões de autorização para microsserviços APIs, camadas de Backend for Frontend (BFF) ou outros componentes do aplicativo. No entanto, essa abordagem pode criar muita latência em seu aplicativo, porque as decisões de autorização exigem a chamada de uma API separada. Se a latência da rede for um problema, você pode considerar uma PDP distribuída.
Usando um PDP distribuído com um PEPs APIs
O ponto de decisão de política distribuído (PDP) com pontos de aplicação de políticas (PEPs) no APIs modelo segue as melhores práticas do setor para criar um sistema eficaz para controle e autorização de acesso à API. Assim como acontece com o PDP centralizado com PEPs um APIs modelo, essa abordagem suporta os seguintes princípios fundamentais:
-
A autorização e o controle de acesso à API são aplicados em vários pontos do aplicativo.
-
A lógica de autorização é independente do aplicativo.
-
As decisões de controle de acesso são centralizadas.
Você pode se perguntar por que as decisões de controle de acesso são centralizadas quando o PDP é distribuído. Embora o PDP possa existir em vários locais em um aplicativo, ele deve usar a mesma lógica de autorização para tomar decisões de controle de acesso. Todos PDPs fornecem as mesmas decisões de controle de acesso com as mesmas entradas. PEPs são implementados de todo APIs para fazer solicitações de autorização ao PDP. A figura a seguir mostra como esse modelo distribuído pode ser implementado em um aplicativo SaaS multilocatário hipotético.
Nessa abordagem, PDPs são implementados em vários locais no aplicativo. Para componentes de aplicativos que têm recursos computacionais integrados que podem executar OPA e oferecer suporte a um PDP, como um serviço em contêiner com um sidecar ou uma instância do Amazon Elastic Compute Cloud (Amazon EC2), as decisões de PDP podem ser integradas diretamente ao componente do aplicativo sem a necessidade de fazer uma chamada de API para um serviço de PDP centralizado. RESTful Isso tem a vantagem de reduzir a latência que você pode encontrar no modelo PDP centralizado, porque nem todo componente do aplicativo precisa fazer chamadas de API adicionais para obter decisões de autorização. No entanto, um PDP centralizado ainda é necessário nesse modelo para componentes de aplicativos que não têm recursos computacionais integrados que permitam a integração direta de um PDP, como o serviço Amazon ou Amazon CloudFront API Gateway.
O diagrama a seguir mostra como essa combinação de uma PDP centralizada e uma PDP distribuída pode ser implementada em um hipotético aplicativo SaaS multilocatário.
Fluxo do aplicativo (ilustrado com textos explicativos numerados em azul no diagrama):
-
Um usuário autenticado com um JWT gera uma solicitação HTTP para a Amazon. CloudFront
-
CloudFront encaminha a solicitação para o Amazon API Gateway, que está configurado como CloudFront origem.
-
Um autorizador personalizado do API Gateway é chamado para verificar o JWT.
-
Os microsserviços respondem à solicitação.
Fluxo de autorização e controle de acesso à API (ilustrado com textos explicativos numerados em vermelho no diagrama):
-
O PEP chama o serviço de autorização e passa os dados da solicitação, incluindo qualquer JWTs um.
-
O serviço de autorização (PDP) pega os dados da solicitação e consulta uma API REST do agente OPA, que está sendo executada como um sidecar. Os dados da solicitação servem como entrada para a consulta.
-
A OPA avalia a entrada com base nas políticas relevantes especificadas pela consulta. Os dados são importados para tomar uma decisão de autorização, se necessário.
-
A OPA devolve uma decisão ao serviço de autorização.
-
A decisão de autorização é devolvida ao PEP e avaliada.
Nessa arquitetura, PEPs solicite decisões de autorização nos endpoints de serviço do API Gateway CloudFront e de cada microsserviço. A decisão de autorização para microsserviços é feita por um serviço de autorização (o PDP) que opera como um sidecar com o componente do aplicativo. Esse modelo é possível para microsserviços (ou serviços) executados em contêineres ou instâncias do Amazon Elastic Compute Cloud EC2 (Amazon). Decisões de autorização para serviços como o API Gateway ainda CloudFront exigiriam o contato com um serviço de autorização externo. Independentemente disso, o serviço de autorização expõe uma API que está disponível para o. PEPs Fazer com que o serviço de autorização PEPs atue como intermediário entre uma OPA permite a inserção de qualquer lógica de transformação entre PEPs uma OPA que possa ser necessária, por exemplo, quando a solicitação de autorização de um PEP não está em conformidade com a entrada de consulta esperada pela OPA.
Você também pode usar essa arquitetura com mecanismos de política personalizados. No entanto, todas as vantagens obtidas com o OPA devem ser substituídas pela lógica fornecida pelo mecanismo de política personalizada.
Um PDP distribuído com PEPs on APIs fornece uma opção para criar um sistema de autorização robusto para APIs. É simples de implementar e fornece uma easy-to-use interface repetível para tomar decisões de autorização para microsserviços APIs, camadas de Backend for Frontend (BFF) ou outros componentes do aplicativo. Essa abordagem também tem a vantagem de reduzir a latência que você pode encontrar no modelo PDP centralizado.
Usando um PDP distribuído como biblioteca
Você também pode solicitar decisões de autorização de um PDP que é disponibilizado como uma biblioteca ou pacote para uso em um aplicativo. O OPA pode ser usado como uma biblioteca Go terceirizada. Para outras linguagens de programação, adotar esse modelo geralmente significa que você deve criar um mecanismo de política personalizado.
