
Título Zero Trust Network Access (ZTNA): Substituindo VPNs Corporativas por AWS Verified Access e IAM Identity Center
O artigo orienta engenheiros seniores na orquestração do AWS Verified Access acoplado ao AWS IAM Identity Center para expor aplicações internas diretamente na internet pública com segurança absoluta. O material explora a criação de políticas de acesso baseadas na linguagem Cedar, a avaliação da postura do dispositivo (Device Posture) e a verificação criptográfica de tokens Web JSON (JWT) em adaptadores hexagonais da camada de computação.
Redes virtuais privadas corporativas baseiam seu modelo de segurança no perímetro, operando sob a premissa falha de que qualquer entidade interna é sistemicamente confiável. Quando credenciais são comprometidas ou um dispositivo corporativo é infectado, o invasor transpõe a barreira da rede e obtém movimentação lateral irrestrita através de centenas de microsserviços legados. Essa topologia plana transforma incidentes isolados de segurança em vazamentos massivos de dados. A implementação de Zero Trust Network Access utilizando o AWS Verified Access erradica essa vulnerabilidade de forma categórica. Ao extinguir as redes virtuais privadas e adotar a validação de acesso baseada em identidade e postura do dispositivo para cada requisição HTTP individual, os arquitetos de segurança eliminam o acesso genérico à camada de rede (Layer 3). Essa infraestrutura assegura que aplicações internas críticas sejam expostas com segurança, avaliando fidedignamente o contexto do usuário antes de alocar qualquer recurso computacional, reduzindo a superfície de ataque a zero.
Pré-requisitos
A construção deste perímetro de confiança zero requer proficiência na linguagem de políticas Cedar e na orquestração de provedores de identidade federados. A infraestrutura deve ser provisionada utilizando o Terraform versão 1.7.0 ou superior, orquestrando o provedor HashiCorp AWS versão 5.40.0. A camada de integração da aplicação exige o Python 3.12, acoplado à biblioteca
PyJWT para decodificação criptográfica e verificação de atestados (claims), juntamente com a biblioteca aws-lambda-powertools versão 2.34.0. Privilégios de administrador no AWS IAM Identity Center são mandatórios para configurar aplicações em nuvem e exportar a relação fiduciária corporativa.Passo a Passo
Provedores de Confiança e Identidade Contínua
O estabelecimento de um perímetro Zero Trust inicia com a delegação da autenticação para o AWS Verified Access Trust Provider. A justificativa técnica subjacente dita que endereços IP são atributos voláteis e facilmente falsificáveis, tornando-se obsoletos para autorização corporativa moderna. Configuramos o Trust Provider para integrar-se nativamente ao AWS IAM Identity Center, permitindo que ele receba e valide atestados de identidade de usuários autenticados (Tokens OIDC). Paralelamente, instanciamos um segundo provedor de confiança focado na postura do dispositivo (Device Trust Provider), conectando a AWS a plataformas de detecção e resposta de endpoints da corporação. Isso garante que um usuário utilizando credenciais válidas seja sumariamente bloqueado caso tente acessar a infraestrutura a partir de um laptop com firewall desativado ou sem o agente de conformidade instalado.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
resource "aws_verifiedaccess_trust_provider" "identity_center" {
policy_reference_name = "idc"
trust_provider_type = "user"
user_trust_provider_type = "iam-identity-center"
tags = {
Environment = "Production"
Domain = "Security"
}
}
resource "aws_verifiedaccess_trust_provider" "device_posture" {
policy_reference_name = "crowdstrike"
trust_provider_type = "device"
device_trust_provider_type = "crowdstrike"
device_options {
tenant_id = var.crowdstrike_tenant_id
}
}
Como traduzimos as declarações textuais complexas oriundas destes múltiplos provedores de confiança independentes em regras matemáticas inflexíveis que governem efetivamente a permissão de tráfego aos sistemas corporativos isolados?
Grupos de Acesso e Avaliação Matemática via Cedar
Traduzimos essas declarações construindo Verified Access Groups governados por políticas declarativas estritas escritas na linguagem Cedar. O raciocínio arquitetônico exige agrupar aplicações com o mesmo perfil de risco sob o mesmo limite de governança. O grupo atua como o motor de inferência central do AWS Verified Access. Se uma requisição atinge a borda sem o token OIDC correto, ela é descartada imediatamente, protegendo a rede contra enchentes de conexões ilegítimas. A política Cedar injetada no código Terraform avalia as declarações exatas fornecidas pelos Trust Providers. Ela impõe que o e-mail do usuário pertença ao domínio oficial e que a pontuação de risco global (Risk Score) proveniente do provedor de postura do dispositivo seja inferior a um limiar numérico pré-estabelecido.
1
2
3
4
5
6
7
8
9
10
11
resource "aws_verifiedaccess_group" "finance_applications" {
verifiedaccess_instance_id = aws_verifiedaccess_instance.main.id
policy_document = jsonencode({
"CedarJson": "permit(principal, action, resource) when { context.idc.user.email.contains(\"@enterprise.com\") && context.crowdstrike.risk_score < 30 };"
})
tags = {
RiskTier = "High"
}
}
Uma vez que o pacote HTTP submetido pelo usuário passa pela avaliação rigorosa e inegociável do motor Cedar, como roteamos esse tráfego legitimado para os balaceadores internos que protegem nossa frota de instâncias sem expô-las fisicamente à internet?
Endpoints de Acesso e Roteamento Reverso Invisível
Roteamos o tráfego validado construindo Verified Access Endpoints associados a balanceadores de carga de aplicação privados (Internal ALBs). O serviço Verified Access provisiona Interfaces de Rede Elástica (ENIs) gerenciadas e escaláveis conectadas ao grupo fiduciário. Quando a política Cedar aprova a requisição temporalmente, o Endpoint atua como um proxy reverso criptografado. Ele encapsula o tráfego HTTP original e o encaminha através da Amazon VPC de forma invisível para o Application Load Balancer localizado exclusivamente em sub-redes privadas roteáveis apenas internamente. A decisão técnica de ocultar o ALB atrás desta infraestrutura extirpa a necessidade de expor portas na internet pública, mitigando radicalmente varreduras de vulnerabilidade e ataques de esgotamento de recursos (DDoS) na camada de computação da aplicação alvo.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
resource "aws_verifiedaccess_endpoint" "finance_dashboard" {
application_domain = "finance.enterprise.com"
attachment_type = "vpc"
domain_certificate_arn = aws_acm_certificate.public_cert.arn
endpoint_domain_prefix = "finance-dash"
endpoint_type = "load-balancer"
verified_access_group_id = aws_verifiedaccess_group.finance_applications.id
load_balancer_options {
protocol = "https"
port = 443
load_balancer_arn = aws_lb.internal_finance_alb.arn
subnet_ids = [var.private_subnet_1, var.private_subnet_2]
}
security_group_ids = [aws_security_group.ava_egress.id]
}
Como os adaptadores hexagonais da aplicação alvo, encapsulados nas camadas mais profundas da Amazon VPC, identificam positivamente o funcionário solicitante sem necessitar reavaliar sessões de rede persistentes que já foram extintas pela infraestrutura de borda?
Injeção de Contexto Assinado e Consumo Hexagonal
Os adaptadores de computação identificam o funcionário inspecionando o Token Web JSON (JWT) injetado perfeitamente pelo AWS Verified Access no cabeçalho HTTP transacional
x-amzn-ava-user-context. O Verified Access assina criptograficamente este JWT com sua própria chave privada de infraestrutura, garantindo que nenhum ator malicioso ou balanceador intermediário tenha forjado os dados. O adaptador primário em Python extrai esse cabeçalho, decodifica a carga utilizando o algoritmo ES256 e verifica a assinatura matemática contra a chave pública da AWS. O raciocínio central garante que a aplicação confie na identidade sem manter estado ou consultar o banco de dados do Identity Center. Após a verificação estrita, a aplicação mapeia o endereço de e-mail e os identificadores de departamento, instanciando um objeto de domínio seguro e autorizando a execução final do microsserviço.Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
import os
import json
import jwt
import requests
from typing import Dict, Any
from aws_lambda_powertools import Logger
logger = Logger(service="FinanceAdapter")
class VerifiedAccessAdapter:
def __init__(self, region: str, endpoint_id: str):
# A chave pública é imutável e fornecida pela AWS para verificar o JWT gerado pelo AVA
self.public_key_url = f"https://public-keys.auth.elb.{region}.amazonaws.com/{endpoint_id}"
self.public_key = None
def _fetch_public_key(self) -> str:
if not self.public_key:
response = requests.get(self.public_key_url, timeout=2.0)
response.raise_for_status()
self.public_key = response.text
return self.public_key
def decode_and_verify_context(self, headers: Dict[str, str]) -> Dict[str, Any]:
jwt_token = headers.get('x-amzn-ava-user-context')
if not jwt_token:
raise PermissionError("Cabeçalho de contexto Zero Trust ausente.")
public_key = self._fetch_public_key()
try:
# A decodificação matemática garante a proveniência intransponível do dado
decoded_claims = jwt.decode(
jwt_token,
public_key,
algorithms=["ES256"],
options={"verify_signature": True, "verify_exp": True}
)
logger.info(f"Contexto decodificado com sucesso para {decoded_claims.get('email')}")
return decoded_claims
except jwt.PyJWTError as e:
logger.error(f"Violação de assinatura JWT interceptada: {str(e)}")
raise PermissionError("Invalidez matemática no atestado de identidade.")
ava_adapter = VerifiedAccessAdapter(region="us-east-1", endpoint_id="ve-0abcd1234efgh5678")
def lambda_handler(event: Dict[str, Any], context: Any) -> Dict[str, Any]:
# Extração de cabeçalhos normalizados (em minúsculas)
headers = {k.lower(): v for k, v in event.get('headers', {}).items()}
try:
user_context = ava_adapter.decode_and_verify_context(headers)
return {
"statusCode": 200,
"body": json.dumps({
"status": "Acesso Autorizado",
"corporate_identity": user_context.get("email")
})
}
except PermissionError as e:
return {"statusCode": 401, "body": json.dumps({"error": str(e)})}
Solução de Problemas Comuns
A anomalia primária na implantação do AWS Verified Access manifesta-se através de erros HTTP 403 Forbidden persistentes, onde o CloudWatch Logs correspondente ao grupo de acesso acusa a falha
OIDC Token Verification Failed. Esse sintoma evidencia categoricamente assimetria de configuração temporal (Clock Skew) ou caducidade precoce no provedor de identidade, caso o Trust Provider seja configurado com um Identity Provider (IdP) externo de terceiros. A mitigação exige o alinhamento dos relógios NTP dos servidores federados e a padronização do tempo de expiração do Token de Acesso (Access Token TTL) para valores tolerantes, garantindo que o Verified Access consiga renovar o artefato OIDC antes que a sessão sofra expiração silenciosa.Outro bloqueio persistente ocorre na forma de HTTP 504 Gateway Timeout ou HTTP 502 Bad Gateway no navegador do usuário durante a etapa de roteamento reverso, embora a autenticação IAM conclua com sucesso. Isso sinaliza indiscutivelmente uma fratura na topologia de rede local (Security Groups). O Application Load Balancer privado alvo deve possuir regras de entrada (Ingress Rules) na porta HTTPS que permitam o tráfego originado explicitamente do bloco CIDR das sub-redes pertencentes ou referenciando o ID do Grupo de Segurança (Security Group ID) acoplado ao Verified Access Endpoint. A omissão desta regra fará o Load Balancer descartar os pacotes de proxy no nível da interface de rede (ENI), estourando o tempo limite da conexão HTTP.
Conclusão
A transição de redes virtuais privadas (VPNs) tradicionais para a arquitetura AWS Verified Access materializa o paradigma Zero Trust Network Access (ZTNA) na fundação das operações. Ao avaliar as identidades e o contexto sistêmico iterativamente a cada transação, arquitetos de nuvem isolam aplicações corporativas da internet sem adicionar fricção operacional. A padronização deste fluxo garante auditorias invioláveis. A evolução contínua da malha orienta a incorporação do AWS WAF diretamente aos Endpoints de Acesso para proteção na Camada 7. Para corporações que adotam estratégias híbridas, esta topologia de validação mapeia-se de maneira idêntica aos preceitos técnicos do Microsoft Entra Private Access, unificando a governança e a blindagem fiduciária em todas as frentes operacionais.
Referências
Gilman, E., & Barth, D. (2017). Zero trust networks: Building secure systems in untrusted networks. O'Reilly Media.
Rose, S., Borchert, O., Mitchell, S., & Connelly, S. (2020). Zero trust architecture (NIST Special Publication 800-207). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-207
Amazon Web Services. (2023). Secure internal applications with AWS Verified Access. AWS Architecture Center. https://docs.aws.amazon.com/verified-access/latest/ug/what-is-verified-access.html
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article