PDP centralizado com PEPs em APIs - AWS Orientação prescritiva

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á.

PDP centralizado com PEPs em APIs

O ponto de decisão política (PDP) centralizado com pontos de aplicação de políticas (PEPs) no modelo de APIs 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. Os PEPs são implementados em todas as 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.

A sample multi-tenant SaaS application that uses a centralized PDP with PEPs on APIs

Fluxo de aplicação:

Application flow - step 1

Um usuário autenticado com um token JWT gera uma solicitação HTTP para a Amazon. CloudFront

Application flow - step 2

CloudFront encaminha a solicitação para o Amazon API Gateway configurado como CloudFront origem.

Application flow - step 3

Um autorizador Lambda do API Gateway é chamado para verificar o token JWT.

Application flow - step 4

Os microsserviços respondem à solicitação.

Fluxo de autorização e controle de acesso à API:

Authorization flow - step 1

O PEP chama o serviço de autorização e passa os dados da solicitação, incluindo quaisquer tokens JWT.

Authorization flow - step 2

O serviço de autorização (PDP) pega os dados da solicitação e consulta uma API REST do agente OPA em execução como um sidecar, com os dados da solicitação servindo como entrada para a consulta.

Authorization flow - step 3

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.

Authorization flow - step 4

A OPA devolve uma decisão ao serviço de autorização.

Authorization flow - step 5

A decisão de autorização foi devolvida ao PEP e avaliada.

Nessa arquitetura, os PEPs solicitam 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 é 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 API RESTful 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 PEPs. Fazer com que o serviço de autorização atue como intermediário entre PEPs e OPA permite a inserção de qualquer lógica de transformação entre PEPs e 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 em APIs fornece uma opção fácil para criar um sistema de autorização robusto para APIs. É simples de implementar e também fornece uma interface easy-to-use idempotente para tomar decisões de autorização para APIs, microsserviços, 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.