Configurar o Acesso Baseado em Recursos para Pontos Finais REST Usando o Gateway de API do OCI
O controle de acesso baseado em recursos permite gerenciar o acesso a recursos com base nos atributos e características do usuário. Isso difere do controle de acesso baseado em atribuição no qual o acesso aos recursos é concedido com base na atribuição. Com o controle de acesso baseado em recursos, as permissões para suas coleções de API REST (implantações) podem ser atribuídas granularmente para consumidores individuais.
Veja algumas vantagens da implementação do controle de acesso baseado em recursos para pontos finais da API REST:
- Implemente controle detalhado para pontos finais de API hospedados no Oracle SaaS e no Oracle Cloud Infrastructure (OCI).
- Evite expor credenciais de API de backend a usuários finais e aplicativos.
- Imponha o acesso baseado em recursos para APIs expostas por meio de vários serviços da OCI, como Oracle Cloud Infrastructure Kubernetes Engine e OCI Functions.
O OCI API Gateway permite recursos adicionais de gerenciamento de API ao implementar o controle de acesso baseado em recursos para pontos finais REST:
- Ajude a monetizar APIs corporativas usando planos de uso.
- Controle o uso da API com limitação de taxa e cotas.
- Aproveite os painéis de controle para monitorar o uso consolidado da API baseada em assinante.
Arquitetura
Essa arquitetura descreve o controle de acesso baseado em recursos para pontos finais REST hospedados no OCI. Os usuários e as solicitações de aplicativos do gerenciamento de capital humano (HCM) e da cadeia de suprimentos e manufatura (SCM) só podem acessar seus respectivos recursos. Os pontos finais REST são hospedados e expostos por meio de aplicativos Oracle SaaS e serviços Oracle, como OCI Functions, Oracle Integration Cloud Service e OCI Kubernetes Engine.
As implantações de HCM e SCM são criadas no Gateway de API do OCI. Os pontos finais REST são configurados nas respectivas implantações como serviços de backend. Os aplicativos confidenciais do OCI Identity and Access Management são usados para domínios do HCM e do SCM. O escopo e os detalhes do público-alvo dos aplicativos confidenciais do cliente devem corresponder à respectiva configuração de validação JWT de implantações do serviço OCI API Gateway. Os consumidores de HCM e SCM devem ter acesso ao URL do token de acesso do aplicativo confidencial, ao ID do cliente, ao segredo do cliente e ao escopo para geração de token. Compartilhe pontos finais de implantação de HCM e SCM do OCI API Gateway com os consumidores.
Provisione o Gateway de API do OCI em uma sub-rede pública para interceptar todo o tráfego da internet. O OCI Functions e o Oracle Integration Cloud Service são serviços nativos do OCI que expõem APIs REST configuradas como implantações de backend do OCI API Gateway. O OCI API Gateway se comunica com essas APIs REST por meio do gateway de serviço. Os serviços de contêiner do OCI Kubernetes Engine podem ser hospedados em sub-redes privadas e os pontos finais REST expostos por meio de clusters do OCI Kubernetes Engine. A comunicação entre os clusters do OCI API Gateway e do OCI Kubernetes Engine pode ser ativada por meio de listas de segurança e regras de roteamento.
O diagrama a seguir ilustra essa arquitetura de referência.
resource-based-access-rest-api-arch.zip
O seguinte diagrama ilustra o fluxo de dados:
O fluxo de dados para usuários de HCM e SCM é semelhante ao seguinte:
- (a,b) Configurar aplicativo confidencial do cliente e aplicativo de recurso com escopo e público-alvo.
- (a,b) Configurar a implantação do OCI API Gateway com ponto final, escopo e público-alvo REST.
- (a,b) O aplicativo do usuário gera um token JWT usando o aplicativo confidencial do cliente. O token contém o escopo codificado e o público-alvo.
- (a,b) Um usuário aciona uma implantação de ponto final do serviço OCI API Gateway usando seu token.
- (a,b) O OCI API Gateway valida o token em relação ao escopo configurado e ao público-alvo na implantação.
- (a,b) Se a validação for bem-sucedida, o respectivo acesso à API será concedido de acordo com a configuração de roteamento.
- (a,b) Se a validação não for bem-sucedida, um erro não autorizado 401 será retornado.
A arquitetura tem os seguintes componentes:
- Região
Região do Oracle Cloud Infrastructure é uma área geográfica localizada que contém um ou mais data centers, denominada domínios de disponibilidade. As regiões são independentes de outras regiões, e grandes distâncias podem separá-las (entre países ou até mesmo continentes).
- Domínios de disponibilidade
Domínios de disponibilidade são data centers stand-alone e independentes dentro de uma região. Os recursos físicos de cada domínio de disponibilidade são isolados dos recursos de outros domínios de disponibilidade, o que oferece tolerância a falhas. Os domínios de disponibilidade não compartilham infraestrutura como energia ou refrigeração ou a rede interna do domínio de disponibilidade. Portanto, uma falha em um domínio de disponibilidade não deve afetar os outros domínios de disponibilidade na região.
- Domínios de falha
Um domínio de falha é um agrupamento de hardware e infraestrutura dentro de um domínio de disponibilidade. Cada domínio de disponibilidade tem três domínios de falha com energia e hardware independentes. Quando você distribui recursos entre vários domínios de falha, seus aplicativos podem tolerar falha no servidor físico, manutenção do sistema e falhas de energia dentro de um domínio de falha.
- Rede virtual na nuvem (VCN) e sub-redes
Uma VCN é uma rede personalizável definida por software que você configura em uma região do Oracle Cloud Infrastructure. Como as redes tradicionais de data center, as VCNs oferecem controle sobre seu ambiente de rede. Uma VCN pode ter vários blocos CIDR não sobrepostos que você pode alterar após a criação da VCN. Você pode segmentar uma VCN em sub-redes, com escopo definido para uma região ou para um domínio de disponibilidade. Cada sub-rede consiste em um intervalo contíguo de endereços que não se sobrepõem a outras sub-redes da VCN. Você pode alterar o tamanho de uma sub-rede após a criação. Uma sub-rede pode ser pública ou privada.
- Mecanismo do Kubernetes do OCI
O Oracle Cloud Infrastructure Kubernetes Engine (Kubernetes Engine ou OKE) é um serviço totalmente gerenciado, escalável e altamente disponível que você pode usar para implantar seus aplicativos em contêineres na nuvem. Você especifica os recursos de computação necessários, e o serviço Kubernetes Engine os provisiona no Oracle Cloud Infrastructure em uma tenancy existente. O OKE usa o Kubernetes para automatizar a implantação, o dimensionamento e o gerenciamento de aplicativos em contêineres entre clusters de hosts.
- Gateway de API
O Oracle API Gateway permite que você publique APIs com pontos finais privados acessíveis na sua rede e que você pode expor à internet pública, se necessário. Os pontos finais suportam validação de API, transformação de solicitação e resposta, CORS, autenticação e autorização e limitação de solicitação.
- Serviço Functions
O Oracle Cloud Infrastructure Functions é uma plataforma Functions-as-a-Service (FaaS) totalmente gerenciada, multitenant, altamente escalável e sob demanda. Ele é alimentado pelo mecanismo de código aberto do Fn Project. As funções permitem que você implante seu código e o chame diretamente ou acione-o em resposta a eventos. O Oracle Functions usa contêineres do Docker hospedados no Oracle Cloud Infrastructure Registry.
- Integração
O Oracle Integration é um serviço totalmente gerenciado que permite integrar seus aplicativos, automatizar processos, obter insight sobre seus processos de negócios e criar aplicativos visuais.
- Serviço IAM (Identity and Access Management)
O Oracle Cloud Infrastructure Identity and Access Management (IAM) é o plano de controle de acesso do Oracle Cloud Infrastructure (OCI) e do Oracle Cloud Applications. A API do serviço IAM e a interface do usuário permitem gerenciar domínios de identidades e os recursos dentro do domínio de identidades. Cada domínio de identidades do OCI IAM representa uma solução de gerenciamento de identidade e acesso independente ou uma população de usuários diferente.
Recomendações
- Ambientes de Produção e Não Produção
Crie vários domínios de identidades e instâncias separadas do OCI API Gateway para produção e não produção para melhor controle do acesso e isolamento do usuário.
- Segurança
Armazene as credenciais de backend no OCI Vault para obter segurança aprimorada. Gere novamente o segredo do cliente se ele estiver comprometido.
Considerações
Considere o seguinte ao implementar essa arquitetura de referência:
- Desempenho
Há recursos de limitação de taxa e cota no Gateway de API do OCI que permitem maximizar o desempenho e reduzir a latência. Aqui estão alguns dos benefícios:
- Mantenha alta disponibilidade e uso adequado de recursos protegendo seu backend de ser sobrecarregado com muitas solicitações.
- Evite ataques de negação de serviço.
- Restringir custos de consumo de recursos.
- Restrinja o uso de APIs pelos usuários dos seus clientes para monetizar APIs.
- Segurança
Estabeleça processos de governança para gerenciar credenciais do cliente e consumidores.
- Disponibilidade
Crie Gateways de API em sub-redes regionais (não sub-redes específicas do domínio de disponibilidade) para garantir alta disponibilidade.
- Custo
O OCI API Gateway é uma opção econômica com um modelo de preço justo.