User's blog

AWS Management Console Private Access: acesso sem internet para ambientes isolados

Written by

Make.com Service User

in

O problema que a AWS resolveu

Organizações em setores regulados como serviços financeiros, governo, defesa e saúde costumam restringir suas cargas de trabalho a ambientes de rede isolados, sem qualquer acesso à internet pública. Até recentemente, havia uma tensão clara nesse modelo: era possível restringir o acesso ao AWS Management Console a contas e redes corporativas autorizadas, mas o console em si ainda exigia conectividade com a internet para funcionar completamente.

Isso colocava as equipes de segurança diante de uma escolha difícil — permitir alguma saída para a internet para usar o console, ou negar o acesso ao console para operadores que trabalham em ambientes completamente isolados.

A AWS anunciou a disponibilidade geral do AWS Management Console Private Access com suporte a Nuvens Privadas Virtuais (VPCs) sem conectividade com a internet. Agora, todo o tráfego dos consoles de serviço suportados — fluxos de autenticação, assets estáticos (JavaScript, CSS, imagens), APIs exclusivas do console e chamadas às APIs de serviços AWS — pode ser roteado por endpoints de VPC via AWS PrivateLink, eliminando a necessidade de internet gateway, NAT gateway ou qualquer rota para a internet pública. O recurso está disponível em todas as Regiões comerciais da AWS para um conjunto selecionado de consoles de serviço suportados.

O que mudou em relação ao lançamento anterior

Em 2023, a AWS lançou a primeira versão do Console Private Access, que já permitia rotear chamadas de console, sign-in e APIs de serviço por endpoints de VPC. No entanto, os assets estáticos e as APIs exclusivas do console ainda dependiam de conectividade com a internet. Esse gap foi eliminado com este lançamento.

Dois cenários principais atendidos

Tráfego do console em redes sem acesso à internet

Com a atualização, o tráfego dos consoles de serviço suportados flui inteiramente pelos endpoints de VPC — sem listas de domínios permitidos para manter, sem proxies interceptando TLS e sem a necessidade de aceitar fluxos exclusivamente via CLI como solução de contorno. O mesmo caminho funciona a partir do Amazon WorkSpaces, instâncias do Amazon Elastic Compute Cloud (Amazon EC2) e redes on-premises conectadas via AWS Direct Connect ou AWS Site-to-Site VPN.

Combinando com Políticas de Controle de Recursos (RCPs) de sign-in e políticas de recursos de sign-in, é possível garantir que a autenticação no console só seja bem-sucedida a partir de redes esperadas — mesmo que credenciais válidas sejam apresentadas de outro lugar, a sessão é negada.

Prevenção de exfiltração de dados

O Private Access também permite restringir quais contas AWS e identidades organizacionais podem usar o AWS Management Console a partir da VPC. Isso impede o acesso via contas pessoais ou contas fora da organização. Ao anexar uma política de endpoint de VPC com a condição aws:ResourceOrgID, as ações do console ficam automaticamente limitadas a recursos dentro da organização. As RCPs de sign-in adicionam uma segunda camada, garantindo que a autenticação só funcione a partir de redes dentro do perímetro.

Como o tráfego flui em um ambiente sem internet

O Console Private Access utiliza três endpoints de VPC distintos para cobrir todo o tráfego necessário:

  • Fluxos de autenticação — sign-in, troca de credenciais e requisições de token de sessão
  • Assets estáticos — JavaScript, CSS e imagens que renderizam a interface do console
  • Chamadas de API do console de serviço — as requisições de backend feitas quando usuários interagem com os consoles de serviço

O fluxo completo a partir de uma carga de trabalho em uma VPC privada funciona assim: o navegador do operador requisita <região>.console.aws.amazon.com; o encaminhador de DNS corporativo repassa a consulta para um endpoint de entrada do Amazon Route 53 Resolver configurado na VPC, que encaminha o tráfego para o endpoint de VPC do console. O tráfego flui de on-premises via Direct Connect (ou AWS Site-to-Site VPN) até a VPC, e o endpoint de VPC roteia o tráfego para o serviço do console pela rede privada da AWS. O console redireciona para o endpoint de sign-in, que avalia as políticas de endpoint de VPC, políticas baseadas em recursos (RBPs) e RCPs antes de redirecionar de volta ao console. Por fim, o console carrega o conteúdo estático pelo endpoint de VPC do console-static e aplica as restrições de identidade e recurso ao fazer chamadas às APIs dos serviços AWS.

Controles de perímetro de dados aplicados ao console

O Console Private Access e as políticas de recursos de sign-in são uma extensão natural das Políticas de Controle de Serviço (SCPs), RCPs e políticas de endpoint de VPC que as equipes já utilizam para tráfego de API. Agora, os mesmos controles de perímetro de dados para identidade, recurso e rede que protegem o acesso programático também protegem as sessões interativas do navegador.

A tabela de controles cobre quatro objetivos principais:

  • Identidade: Apenas identidades confiáveis podem acessar recursos — via RCPs e RBPs de sign-in, restringindo quais principals podem autenticar no console usando condições como aws:PrincipalOrgID, aws:PrincipalAccount e aws:PrincipalArn.
  • Recurso: Identidades só podem acessar recursos confiáveis — via SCP com aws:ResourceOrgID, que segue os principals em cada sessão do console e nega chamadas de API cujo recurso-alvo esteja fora da organização.
  • Rede (identidade): Identidades só acessam recursos a partir de redes esperadas — via SCPs de perímetro de rede com aws:SourceVpc. Com o Private Access, requisições enviadas pelo console aos serviços suportados carregam aws:SourceVpc definido para a VPC que hospeda os endpoints.
  • Rede (recurso): Recursos só podem ser acessados a partir de redes esperadas — via RBPs e RCPs de sign-in que negam autenticação no console a partir de redes inesperadas, usando condições como aws:SourceIp, aws:SourceVpc, aws:SourceVpce e aws:VpcSourceIp.

Guia de implantação passo a passo

A AWS recomenda um rollout incremental, validando cada etapa antes de expandir para Regiões e Unidades Organizacionais (OUs) adicionais. Para quem quiser validar a mecânica antes de construir a solução completa, o guia de início rápido com ambiente de teste apresenta uma configuração mínima com uma única VPC, os três endpoints e uma política permissiva.

Pré-requisitos

Passo 1: Mapear o acesso atual ao console

Antes de qualquer mudança, use o CloudTrail para mapear como os usuários acessam o console hoje. Busque por eventName = ConsoleLogin em uma janela representativa (recomenda-se 30 dias) e revise os campos sourceIPAddress, vpcEndpointId e awsRegion. Identifique quais tipos de identidade estão em uso: usuário root, usuário IAM, federação SAML e AWS IAM Identity Center. Escolha a OU ou conta que será usada no piloto — evite contas de produção ou compartilhadas.

Passo 2: Criar os endpoints de VPC do Private Access

Na Região escolhida, crie ou identifique uma VPC para hospedar os endpoints e, em seguida, crie três endpoints de interface de VPC nessa VPC:

  • com.amazonaws.<região>.console — para o console
  • com.amazonaws.<região>.signin — para o AWS Sign-In
  • com.amazonaws.<região>.console-static — para APIs exclusivas do console (obrigatório apenas se a VPC não tiver caminho para a internet)

Passo 3: Configurar o DNS privado

Para cargas de trabalho dentro da VPC que usam o Amazon Route 53 Resolver padrão, nenhuma configuração adicional de DNS é necessária — basta habilitar o nome de DNS privado em cada endpoint (PrivateDnsEnabled = true). Se você usar um resolver de DNS customizado ou uma zona hospedada privada, é necessário configurá-lo explicitamente para mapear os domínios do console para os endereços dos endpoints. Consulte a documentação de zonas hospedadas privadas e a documentação de endpoints obrigatórios do Console Private Access para a lista completa de domínios.

Para cargas de trabalho fora da VPC — como escritórios corporativos conectados via Direct Connect ou Site-to-Site VPN — garanta que o resolver de DNS corporativo retorne os endereços dos endpoints para esses domínios. O post Simplify DNS management in a multi-account environment with Route 53 Resolver traz orientações detalhadas.

Passo 4: Verificar a conectividade privada

Faça login no console a partir de uma carga de trabalho dentro da VPC. Para confirmar que o tráfego está roteando pelos endpoints de VPC, verifique o ícone de cadeado na barra de navegação do console. Você também pode confirmar no CloudTrail que eventos recentes de ConsoleLogin mostram o campo vpcEndpointId preenchido com um dos seus IDs de endpoint. Veja um exemplo de evento:

{
  "eventVersion": "1.08",
  "userIdentity": {
    "type": "AssumedRole",
    "principalId": "AROA3XFRBF23EXAMPLE:john.doe",
    "arn": "arn:aws:sts::123456789012:assumed-role/Admin/john.doe",
    "accountId": "123456789012"
  },
  "eventTime": "2026-07-08T19:15:32Z",
  "eventSource": "signin.amazonaws.com",
  "eventName": "ConsoleLogin",
  "awsRegion": "us-east-1",
  "sourceIPAddress": "10.0.1.47",
  "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)...",
  "requestParameters": null,
  "responseElements": {
    "ConsoleLogin": "Success"
  },
  "additionalEventData": {
    "LoginTo": "https://console.aws.amazon.com/console/home",
    "MobileVersion": "No",
    "MFAUsed": "Yes",
    "vpcEndpointId": "vpce-0abc123def456789a"
  },
  "eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
  "eventType": "AwsConsoleSignIn",
  "recipientAccountId": "123456789012"
}

Se o console não carregar, verifique: se o DNS privado está habilitado em cada endpoint; se os grupos de segurança dos endpoints permitem HTTPS (TCP 443) das sub-redes das cargas de trabalho; e se, para tráfego externo à VPC, o DNS corporativo retorna os IPs privados dos endpoints. Para validação end-to-end, execute traceroute console.aws.amazon.com a partir da sua estação de trabalho e confirme que o caminho usa apenas hops privados.

Passo 5: Aplicar políticas de endpoint de VPC

Anexe uma política de endpoint nos endpoints do console e do AWS Sign-In que limite o acesso a identidades da sua organização. Comece com uma política permissiva Allow * e confirme que o tráfego está roteando pelos endpoints. Depois, adicione restrições usando as condições aws:PrincipalOrgID e aws:ResourceOrgID. A referência completa está no guia do usuário do Console Private Access. Para políticas além do piloto, consulte Data perimeters on AWS e o repositório de exemplos de políticas de perímetro de dados no GitHub.

Passo 6: Aplicar uma política de Sign-In

As políticas de Sign-In negam requisições de autenticação no console que não correspondam às condições de rede ou de principal definidas. A política é composta por uma instrução de pré-autenticação cobrindo signin:Authenticate e uma instrução de pós-autenticação cobrindo signin:AuthorizeOAuth2Access e signin:CreateOAuth2Token — inclua ambas.

Para o piloto, implante a política como uma RCP a partir da conta de gerenciamento do AWS Organizations. Como a RCP se aplica a todas as contas da organização, recomenda-se pilotar em uma organização de teste dedicada antes de expandir. Ative a aplicação chamando a API signin:PutConsoleAuthorizationConfiguration para a organização na Região us-east-1.

Importante: Configure pelo menos um principal excluído como caminho de acesso emergencial (break-glass) antes de habilitar a RCP. O principal recomendado é uma role IAM dedicada.

Exemplo — Restringir acesso à VPC corporativa:

aws signin put-resource-permission-statement \
  --source-vpc vpc-0abc123def456789 \
  --requested-region us-west-2 \
  --excluded-principal "arn:aws:iam::123456789012:user/EmergencyAdmin" \
  --region us-east-1

Exemplo — Restringir acesso a um intervalo de IP específico:

aws signin put-resource-permission-statement \
  --source-ip "IP_ADDRESS" \
  --excluded-principal "arn:aws:iam::123456789012:role/BreakGlassRole" \
  --region us-east-1

Habilitar a autorização do console para a organização:

aws signin put-console-authorization-configuration \
  --target-id <your-target-id> \
  --region us-east-1

Para exemplos de políticas, referência da Interface de Linha de Comando da AWS (AWS CLI) e o procedimento de recuperação em caso de bloqueio, consulte o post sobre RBPs de sign-in e a documentação de controle de acesso ao console com políticas baseadas em recursos.

Passo 7: Adicionar endpoints de VPC para cada serviço

Os endpoints do Private Access carregam o shell do console, mas não as chamadas de API de serviço que o console faz em nome do usuário. Em uma VPC sem internet gateway, essas chamadas não têm para onde ir. Por isso, é necessário adicionar um endpoint de VPC para cada serviço utilizado.

Para o piloto, crie um endpoint de interface do AWS KMS (com.amazonaws.<região>.kms) na mesma VPC, com DNS privado habilitado, e confirme que a lista de chaves carrega ao acessar o console do AWS Key Management Service (AWS KMS) de dentro da VPC. Repita para cada serviço necessário. A lista atual de serviços que suportam PrivateLink está na documentação do AWS PrivateLink. Consoles de serviços que não suportam PrivateLink não funcionarão em VPCs sem internet e precisam ser tratados separadamente.

Passo 8: Ocultar Regiões e serviços não configurados (opcional)

Links do console para serviços ou Regiões sem endpoints configurados falharão dentro da VPC. Para evitar que usuários naveguem para páginas quebradas, use a Personalização de Experiência do Usuário (UXC) para ocultar Regiões e serviços que não fazem parte da implantação do Private Access. A UXC é configurada no nível da conta e se aplica à navegação, resultados de busca e menus de seleção de serviços.

Passo 9: Validar e expandir

Após aplicar as políticas de endpoint e a RCP de Sign-In a uma conta piloto, valide dois cenários: login de dentro da rede corporativa (deve ter sucesso) e login de fora da rede corporativa (deve ser negado na etapa de Sign-In, antes de chegar ao console). No CloudTrail, confirme que os eventos ConsoleLogin mostram vpcEndpointId preenchido para tráfego de dentro da rede. Para negações inesperadas, procure eventos ConsoleLogin com as mensagens de erro Authorization denied because of a resource-based policy ou Authorization denied because of a resource control policy.

Considerações importantes

  • IAM Identity Center: O suporte ao sign-in via IAM Identity Center ainda não está disponível por endpoint de VPC. A autenticação inicial de Single Sign-On (SSO) ainda precisa transitar pela internet.
  • Acesso programático: RBPs e RCPs de Sign-In controlam o sign-in interativo no console. Requisições do AWS SDK e da AWS CLI assinadas com SigV4 não são afetadas. Esse também é o caminho de recuperação: um principal com permissão signin:DeleteConsoleAuthorizationConfiguration pode desabilitar a aplicação programaticamente se a autorização do console estiver mal configurada.
  • Aplicações integradas ao AWS Sign-In: As políticas de Sign-In também se aplicam ao Amazon Connect, Amazon WorkSpaces, Amazon QuickSight, AWS Health Dashboard, Amazon AppStream 2.0 e Amazon Lightsail quando essas aplicações usam o AWS Sign-In para autenticar.
  • Suporte parcial a consoles: O Console Private Access está disponível em todas as Regiões comerciais da AWS, mas suporta apenas um subconjunto dos consoles de serviço. Consulte a documentação de Regiões, consoles de serviço e funcionalidades suportadas no Private Access. Para serviços não suportados, a conectividade com a internet ainda é necessária.
  • Custos: São cobrados os preços regulares de endpoint do AWS PrivateLink e processamento de dados para cada endpoint e cada Região implantada. Os três endpoints do Private Access (console, signin e console-static), mais os endpoints de serviço já utilizados, são os itens relevantes de custo.

Conclusão

Com o AWS Management Console Private Access, a AWS estendeu o framework de perímetro de dados ao próprio console interativo. Agora, os quatro objetivos de controle — identidade, recurso, rede de identidade e rede de recurso — que já eram aplicados ao tráfego de API também se aplicam às sessões de navegador. Para começar, consulte a documentação do AWS Management Console Private Access, as arquiteturas de referência do Console Private Access e o guia Establishing a data perimeter on AWS.

Fonte

Extend your data perimeter to the AWS Management Console with Private Access (https://aws.amazon.com/blogs/security/extend-your-data-perimeter-to-the-aws-management-console-with-private-access/)

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

More posts