O blog da AWS

Consumindo APIs privadas do Amazon API Gateway usando TLS mútuo

Este post foi escrito por Thomas Moore, arquiteto de soluções sênior, Josh Hart, arquiteto de soluções sênior e adaptado para Português por Daniel ABIB, arquiteto sênior de soluções.

Em uma postagem anterior neste blog exploramos o uso do Amazon API Gateway para criar APIs REST privadas que podem ser consumidas em diferentes contas da AWS dentro de uma nuvem privada virtual (VPC). As APIs privadas de várias contas são úteis para fornecedores de software (ISVs) e empresas de SaaS que fornecem conectividade segura para clientes e organizações que criam APIs internas e microsserviços de back-end.

O TLS mútuo (mTLS) é um protocolo de segurança avançado que fornece autenticação bidirecional por meio de certificados entre um cliente e um servidor. O mTLS exige que o cliente envie um certificado X.509 para provar sua identidade ao fazer uma solicitação, junto com o processo padrão de verificação de certificado do servidor. Isso garante que ambas as partes sejam quem afirmam ser.

O processo de conexão do mTLS ilustrado no diagrama acima:

  1. O cliente se conecta ao servidor.
  2. O servidor apresenta seu certificado, que é verificado pelo cliente.
  3. O cliente apresenta seu certificado, que é verificado pelo servidor.
  4. Conexão TLS criptografada estabelecida.

Os clientes usam o mTLS porque ele oferece segurança e verificação de identidade mais fortes do que as conexões TLS padrão. O mTLS ajuda a evitar ataques intermediários e protege contra ameaças como tentativas de falsificação de identidade, interceptação de dados e adulteração. À medida que as ameaças se tornam mais avançadas, o mTLS fornece uma camada extra de defesa para validar as conexões.

A implementação do mTLS aumenta a sobrecarga do gerenciamento de certificados, mas para aplicativos que transmitem dados valiosos ou confidenciais, a segurança extra é importante. Se a segurança for uma prioridade para seus sistemas e usuários, você deve considerar a implantação do mTLS.

Os endpoints regionais do API Gateway têm suporte nativo para mTLS, mas os endpoints privados do API Gateway não oferecem suporte para mTLS, portanto, você deve encerrar o mTLS antes do API Gateway. A postagem anterior do blog mostra como criar APIs mTLS privadas usando um processo de verificação autogerenciado dentro de um contêiner executando um proxy NGINX. Desde então, o Application Load Balancer (ALB) agora oferece suporte nativo ao mTLS, simplificando a arquitetura.

Esta postagem explora a criação de APIs privadas do mTLS usando esse novo recurso.

Configuração do Application Load Balancer mTLS

Você pode ativar a autenticação mútua (mTLS) em um Application Load Balancer novo ou existente. Ao habilitar o mTLS no ouvinte do balanceador de carga, os clientes precisam apresentar certificados confiáveis para se conectar. O balanceador de carga valida os certificados antes de permitir solicitações aos back-ends.

Há duas opções disponíveis ao configurar o mTLS no Application Load Balancer: modo Passthrough e Verify with trust store.

No modo Passthrough, a cadeia de certificados do cliente é passada como um cabeçalho HTTP X-Amzn-Mtls-Clientcert para que o aplicativo inspecione a autorização. Nesse cenário, ainda há um processo de verificação de back-end. A vantagem de adicionar o ALB à arquitetura é que você pode executar o roteamento de aplicativos (camada 7), como roteamento baseado em caminhos, permitindo configurações de roteamento de aplicativos mais complexas.

No modo Verificar com armazenamento confiável (Verify with trust store), o Application Load Balancer valida o certificado do cliente e só permite que os clientes que fornecem certificados confiáveis se conectem. Isso simplifica o gerenciamento e reduz a carga nos aplicativos de back-end.

Este exemplo usa a Autoridade de Certificação Privada da AWS (AWS Private CA), mas as etapas são semelhantes para autoridades de certificação (CA) terceirizadas.

Para configurar o Trust Store de certificados para o ALB:

  1. Crie uma autoridade de certificação privada da AWS. Especifique o Nome Comum (CN) para ser o domínio que você usa para hospedar o aplicativo (por exemplo, api.example.com).
  2. Exporte a CA usando a CLI ou o console e faça o upload do Certificate.pem resultante em um bucket do Amazon S3.
  3. Crie um Trust Store, aponte ele para o certificado carregado na etapa anterior.
  4. Atualize o listener do seu Application Load Balancer para usar esse armazenamento confiável e selecione o comportamento de verificação de mTLS necessário.
  5. Gere certificados para o aplicativo cliente em relação à autoridade de certificação privada, por exemplo, usando os seguintes comandos:
openssl req -new -newkey rsa:2048 -days 365 -keyout my_client.key -out my_client.csr

aws acm-pca issue-certificate –certificate-authority-arn arn:aws:acm-pca:us-east-1:111122223333:certificate-authority/certificate_authority_id–csr fileb://my_client.csr –signing-algorithm “SHA256WITHRSA” –validity Value=365,Type=”DAYS” –template-arn arn:aws:acm-pca:::template/EndEntityCertificate/V1

aws acm-pca get-certificate -certificate-authority-arn arn:aws:acm-pca:us-east-1:111122223333:certificate-authority/certificate_authority_id–certificate-arn arn:aws:acm-pca:us-east-1:account_id:certificate-authority/certificate_authority_id/certificate/certificate_id–output text

Para obter mais detalhes sobre essa parte do processo, consulte como Usar ACM Private CA para Amazon API Gateway Mutual TLS.

Verificação de mTLS do Private API Gateway usando um ALB

Usar o ALB Verify com o modo de armazenamento confiável junto com o API Gateway pode habilitar APIs privadas com mTLS, sem a carga operacional de um serviço de proxy autogerenciado.

Você pode usar esse padrão para acessar o API Gateway na mesma conta da AWS ou em várias contas.

O mesmo padrão de conta permite que clientes dentro da VPC consumam o API Gateway privado chamando a URL do Application Load Balancer. O ALB é configurado para verificar o certificado do cliente fornecido em relação ao armazenamento confiável antes de passar a solicitação para o API Gateway.

Se o certificado for inválido, a API nunca receberá a solicitação. Uma política de recursos no API Gateway garante que as solicitações sejam permitidas somente por meio do VPC endpoint, e um grupo de segurança no VPC endpoint garante que ele só possa receber solicitações do ALB. Isso evita que o cliente ignore o mTLS invocando diretamente o API Gateway ou os VPC endpoints.

O padrão de várias contas usando o AWS PrivateLink fornece a capacidade de se conectar ao endpoint do ALB com segurança em todas as contas e entre VPCs. Isso evita a necessidade de conectar VPCs usando o VPC Peering ou o AWS Transit Gateway e permite que os fornecedores de software forneçam serviços de SaaS para serem consumidos por seus clientes finais. Esse padrão está disponível para implantação como código de exemplo no repositório do GitHub.

O fluxo de uma solicitação do cliente por meio da arquitetura entre contas é o seguinte:

  1. Um cliente no aplicativo envia uma solicitação para o endpoint da API do produtor.
  2. A solicitação é encaminhada via AWS PrivateLink para um Network Load Balancer na conta do consumidor. O Network Load Balancer é um requisito dos serviços do AWS PrivateLink.
  3. O Network Load Balancer usa um grupo-alvo do tipo Application Load Balancer.
  4. O listener do Application Load Balancer está configurado para mTLS no modo de verificação com armazenamento confiável.
  5. Uma decisão de autorização é tomada comparando o certificado do cliente com a cadeia no repositório confiável de certificados.
  6. Se o certificado do cliente for permitido, a solicitação será roteada para o API Gateway por meio do execute-api VPC Endpoint. Uma política de recursos do API Gateway é usada para permitir conexões somente por meio do VPC endpoint.
  7. Qualquer autenticação e autorização adicionais do API Gateway são realizadas, como o uso de um autorizador Lambda para validar um JSON Web Token (JWT).

Usando o exemplo do repositório do GitHub, esta é a resposta esperada de uma solicitação bem-sucedida com um certificado válido:

curl —key my_client.key —cert my_client.pem https://api.example.com/widgets 
 
 {“id”:” 1”,” value”:” 4,99”}

Ao passar um certificado inválido, a seguinte resposta é recebida:

curl: (35) Falha de recv: conexão redefinida por um par

Nomes de domínio personalizados

Um benefício adicional da implementação da solução mTLS com um Application Load Balancer é o suporte para nomes de domínio personalizados privados. Atualmente, os endpoints do Private API Gateway não oferecem suporte a nomes de domínio personalizados. Mas, nesse caso, os clientes primeiro se conectam a um endpoint do ALB, que oferece suporte a um domínio personalizado. O código de exemplo implementa domínios personalizados privados usando um certificado público do AWS Certificate Manager (ACM) no ALB interno e uma zona DNS hospedada no Amazon Route 53. Isso permite que você forneça um URL estático aos consumidores para que, se o API Gateway for substituído, o consumidor não precise atualizar o código.

Lista de revogação de certificados

Opcionalmente, como outra camada de segurança, você também pode configurar uma lista de revogação de certificados para um armazenamento confiável no ALB. As listas de revogação permitem que você revogue e invalide os certificados emitidos antes da data de expiração. Você pode usar esse recurso para desembarcar clientes ou negar credenciais comprometidas, por exemplo.

Você pode adicionar a lista de revogação de certificados a um repositório confiável novo ou existente. A lista é fornecida por meio de um URI do Amazon S3 como um arquivo formatado em PEM.

Conclusão

Este blog post explora maneiras de fornecer autenticação TLS mútua para endpoints privados do API Gateway. Este post anterior mostra como fazer isso usando um proxy NGINX autogerenciado. Esta publicação simplifica a arquitetura usando o suporte nativo ao mTLS, agora disponível para Application Load Balancers.

Esse novo padrão centraliza a autenticação na borda, simplifica a implantação e minimiza a sobrecarga operacional em comparação com a verificação autogerenciada. A Autoridade de Certificação Privada da AWS e as listas de revogação de certificados se integram às credenciais gerenciadas e às políticas de segurança. Isso facilita a exposição segura de APIs privadas em todas as contas e VPCs.

A autenticação mútua e os controles de segurança progressivos estão ganhando importância na arquitetura de cargas de trabalho seguras baseadas na nuvem. Para começar, visite o repositório do GitHub.

Para obter mais recursos de aprendizado sem servidor, visite Serverless Land.

Este blog foi traduzido para Português e o blog original se encontra neste link.

Biografia dos Autores

Thomas Moore é um arquiteto de soluções sênior

Josh Hart é um arquiteto de soluções sênior

Biografia do tradutor


Daniel Abib é arquiteto de soluções sênior na AWS, com mais de 25 anos trabalhando com gerenciamento de projetos, arquiteturas de soluções escaláveis, desenvolvimento de sistemas e CI/CD, microsserviços, arquitetura Serverless & Containers e segurança. Ele trabalha apoiando clientes corporativos, ajudando-os em sua jornada para a nuvem.

https://www.linkedin.com/in/danielabib/