AWS Builder Center
Título
Zero Trust Network Access (ZTNA): Substituindo VPNs Corporativas por AWS Verified Access e IAM Identity Center

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.

Systems Architect na NTT DATA, Estudante Doutorado na MUST University, 12x AWS e ASD & ADHD
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")

@logger.inject_lambda_context
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 
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article