Protegendo o Amazon Quick em redes corporativas com AWS PrivateLink

O problema: dados sensíveis atrás do firewall corporativo

Quando os dados empresariais ficam dentro de um data center privado ou atrás de um firewall corporativo, surge um desafio clássico: como permitir que ferramentas de Inteligência Artificial (IA) e dashboards do Amazon Quick acessem essas informações sem expô-las à internet pública?

Para muitas empresas, rotear tráfego pela internet pública é simplesmente inaceitável. Frameworks regulatórios como HIPAA, FedRAMP e PCI-DSS exigem que dados sensíveis permaneçam dentro de perímetros de rede controlados. Mesmo quando conformidade não é o principal motivador, expor caminhos internos de dados amplia a superfície de ataque, complica trilhas de auditoria e introduz latência variável que degrada a experiência do usuário.

A AWS publicou um guia técnico detalhando como resolver exatamente esse problema: conectar fontes de dados on-premises ao Amazon Quick de forma totalmente privada, usando AWS PrivateLink.

Como o Amazon Quick acessa dados privados

O Amazon Quick é um workspace com IA que reúne pesquisa, análise, automação e conversação em uma única experiência. Para entender a arquitetura de conectividade privada, é importante distinguir dois caminhos de tráfego:

Tráfego voltado ao usuário: Cobre o acesso ao console, chamadas de API, uso do Quick Desktop e dashboards embarcados. Todo esse tráfego é roteado por meio de VPC endpoints (Interface Endpoints via PrivateLink).
Tráfego de busca de dados: Ocorre quando o próprio Quick precisa acessar suas fontes de dados para buscar informações. Esse caminho é gerenciado pelas VPC connections, que são Interfaces de Rede Elásticas (ENIs) inseridas diretamente na sua Nuvem Privada Virtual (VPC).

Esses dois caminhos exigem dois mecanismos distintos que trabalham em conjunto, e toda a arquitetura descrita no guia da AWS gira em torno dessa separação.

Quais componentes do Quick usam VPC connections?

Amazon Quick Sight: Consulta bancos de dados on-premises (PostgreSQL, MySQL, SQL Server, Oracle, entre outros) diretamente via ENIs na sua VPC.
Amazon Quick Flows e Amazon Quick Automate: Automatizam tarefas e orquestrações complexas, invocando conectores de ação, incluindo servidores MCP hospedados privadamente na sua VPC.
Quick Agents: Sustentam interações conversacionais e podem invocar conectores de ação diretamente. Quando um agente chama uma API interna, o tráfego passa pela VPC connection.
Amazon Quick Index: Constrói uma camada de busca unificada. Para fontes dentro da VPC ou on-premises, as VPC connections de knowledge base suportam atualmente apenas o Amazon Redshift. Fontes como Confluence, SharePoint, Box, Google Drive, OneDrive e Amazon S3 não suportam VPC connection hoje — consulte as fontes de dados VPC suportadas.
Amazon Quick Research: Acessa fontes empresariais atrás do firewall usando a VPC connection para fontes privadas.

Configurando a conectividade privada: os quatro pilares

Pré-requisitos

Antes de configurar a conectividade privada, a AWS indica que os seguintes itens devem estar em ordem: uma conta AWS ativa com assinatura Enterprise do Amazon Quick (as VPC connections exigem essa edição), uma VPC existente na mesma região do Quick, uma conexão AWS Direct Connect ou VPN Site-to-Site já estabelecida entre a rede on-premises e a VPC, e permissões de Gerenciamento de Identidade e Acesso (IAM) para criar e gerenciar VPC endpoints, security groups e administração do Quick.

1. VPC endpoints para acesso de usuários e API

O Quick requer dois Interface VPC endpoints para acesso privado completo:

Endpoint do website: Serviço com.amazonaws.<region>.quicksight-website. Lida com a maior parte do tráfego de usuários ao console. É necessário criar um registro A para <region>.quicksight.aws.amazon.com apontando para o DNS do VPC endpoint.
Endpoint de API: Serviço com.amazonaws.<region>.quicksight. Lida com chamadas programáticas de API. Com o DNS privado habilitado, chamadas existentes para quicksight.<region>.amazonaws.com roteiam automaticamente pelo endpoint. Para conformidade com FIPS, usa-se com.amazonaws.<region>.quicksight-fips.

Um ponto importante destacado pela AWS: nem todas as APIs do Quick estão disponíveis pelo VPC endpoint de API. Treze APIs não são suportadas, incluindo as APIs de conectores de ação e as APIs de fluxo. Automações que gerenciam conectores ou fluxos programaticamente precisam de um caminho para o endpoint público de API — veja a documentação sobre Quick e Interface VPC endpoints.

Resolução de DNS para os endpoints

Para o endpoint do website, é necessário criar um registro A para <region>.quicksight.aws.amazon.com apontando para o DNS do VPC endpoint. Isso garante que usuários na rede corporativa resolvam a URL do Quick pelo caminho privado. Uma Zona Hospedada Privada (Private Hosted Zone) do Route 53 responde apenas a consultas de dentro das VPCs associadas, então os servidores DNS on-premises devem ser configurados para encaminhar consultas para um endpoint de entrada do Route 53 Resolver na VPC.

Políticas de VPC endpoint

As políticas de VPC endpoint restringem quais contas ou organizações podem usar o endpoint. Para o Quick, as políticas podem ser definidas por ID de conta AWS ou ID de organização. Uma limitação importante: para o endpoint do website, os campos Principal, Action e Resource devem ser todos definidos como *. Condições só podem ser especificadas com os atributos aws:PrincipalAccount ou aws:OrgId. Políticas mais restritivas ao nível de ação só são suportadas no endpoint de API.

Exemplo de política para o endpoint do website:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:PrincipalAccount": ["012345678901"]
        }
      }
    }
  ]
}

Exemplo de política para o endpoint de API (restrita a ações específicas):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": [
        "quicksight:DescribeUser",
        "quicksight:ListUsers"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:PrincipalAccount": ["012345678901"]
        }
      }
    }
  ]
}

2. VPC connections para acesso a fontes de dados

Enquanto os VPC endpoints lidam com o tráfego voltado ao usuário, as VPC connections lidam com o caminho do lado do servidor — ou seja, o Amazon Quick alcançando sua VPC para buscar dados em bancos de dados, fontes do Amazon Redshift e APIs internas.

Quando você cria uma VPC connection no Amazon Quick, ENIs são inseridas nas sub-redes da sua VPC. Essas ENIs permitem que o Quick troque tráfego de rede com recursos dentro da sua VPC e, por extensão, com tudo que seja alcançável a partir dela, incluindo sistemas on-premises conectados via Direct Connect ou VPN.

Antes de criar a VPC connection, é necessário criar uma Função de Execução (Execution Role) IAM dedicada. O Quick não cria essa role automaticamente. Ela precisa de uma política de permissões com as ações do Amazon EC2 que o Quick usa para gerenciar suas ENIs, e de uma política de confiança que permita ao quicksight.amazonaws.com assumir a role.

Política de permissões necessária:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:CreateNetworkInterface",
        "ec2:DeleteNetworkInterface",
        "ec2:ModifyNetworkInterfaceAttribute",
        "ec2:DescribeSubnets",
        "ec2:DescribeSecurityGroups"
      ],
      "Resource": "*"
    }
  ]
}

Política de confiança:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "quicksight.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Um detalhe técnico importante destacado pela AWS: para VPC connections criadas antes de 27 de abril de 2023, o security group associado à interface de rede do Quick não é stateful. É necessário adicionar uma regra de entrada que permita explicitamente o tráfego de retorno da fonte de dados em todas as portas (0–65535). Conexões criadas após essa data usam o comportamento stateful padrão — consulte as regras de entrada e saída de security groups.

3. VPC endpoints para serviços de dados da AWS

O Quick acessa outros serviços AWS (Amazon S3, Amazon Redshift, Amazon Athena, AWS Secrets Manager) ao recuperar dados para dashboards e análises. Para manter todo o tráfego privado, a AWS recomenda criar Interface ou Gateway VPC endpoints para cada um desses serviços na mesma VPC onde as ENIs do Quick estão alocadas:

Amazon S3: Gateway endpoint — com.amazonaws.<region>.s3 (sem custo adicional)
Amazon Redshift: Interface endpoint — com.amazonaws.<region>.redshift
Amazon Athena: Interface endpoint — com.amazonaws.<region>.athena
AWS Secrets Manager: Interface endpoint — com.amazonaws.<region>.secretsmanager
AWS Glue: Interface endpoint — com.amazonaws.<region>.glue

4. Acesso a domínios externos obrigatórios

Mesmo com VPC endpoints configurados, os navegadores dos usuários ainda precisam alcançar alguns domínios para login, assets estáticos, métricas e integrações. Domínios sem suporte a VPC endpoint precisam de conectividade de saída, normalmente via proxy corporativo ou firewall. Entre os principais domínios sem suporte a VPC endpoint estão: *.cloudfront.net (assets estáticos como CSS e JavaScript), *.execute-api.<region>.amazonaws.com (métricas do lado do cliente) e *.kinesisvideo.amazonaws.com (streaming ao vivo de workflows de automação).

Restringindo o acesso exclusivamente ao VPC endpoint

Após configurar e testar os endpoints, é possível forçar que todo acesso à conta Quick passe obrigatoriamente pelo VPC endpoint, bloqueando completamente o acesso pela internet. O Quick oferece controles de restrição por IP e por VPC endpoint que limitam o acesso da conta a uma lista predefinida de intervalos de IP, IDs de VPC ou IDs de VPC endpoint.

Para configurar via CLI da AWS:

aws quicksight update-ip-restriction \
  --aws-account-id ACCOUNT_ID \
  --region REGION \
  --enabled \
  --vpc-endpoint-id-restriction-rule-map \
  vpce-001122def=CorporateVpcEndpoint

Alguns pontos críticos sobre esse recurso: as regras de IP e VPC endpoint se aplicam ao acesso web, embarcado e móvel do Quick, mas não restringem o acesso à API pública. Para restringir chamadas de API de fontes específicas, use políticas IAM com condições aws:SourceIp ou aws:SourceVpce. As regras podem levar até 10 minutos para entrar em vigor. Certifique-se de que seu próprio IP ou VPC endpoint esteja incluído nas regras antes de habilitá-las — caso contrário, você perderá o acesso à sua própria conta.

Controle de identidade e federação

A conectividade de rede privada mantém o tráfego fora da internet, mas não responde à pergunta de quem pode acessar o quê dentro do Quick. O Amazon Quick usa o AWS IAM Identity Center como ponto central para gerenciamento de identidade da força de trabalho, conectando-se ao provedor de identidade corporativo existente via SAML 2.0 para autenticação e SCIM 2.0 para provisionamento automático de usuários e grupos.

O Quick suporta três papéis base: Admin (acesso completo de gerenciamento), Author (criação e publicação de dashboards, agentes, fluxos e apps) e Reader (consumo de dashboards publicados e interação com agentes). Além disso, o Quick Sight suporta Segurança em Nível de Linha (RLS) e Segurança em Nível de Coluna (CLS) para controle granular de quais dados cada usuário ou grupo pode visualizar. As mesmas políticas de segurança que restringem visualizações tradicionais também restringem o que a IA pode referenciar ao gerar respostas.

Para configuração passo a passo do IAM Identity Center com seu provedor de identidade, a AWS disponibiliza o guia Introdução ao IAM Identity Center. Para configurações avançadas de RLS/CLS e federação de identidade, consulte a documentação do IAM Identity Center.

Atenção: Para contas Quick integradas ao IAM Identity Center, a autenticação via navegador requer acesso aos endpoints públicos de login da AWS e do IAM Identity Center. VPC endpoints não cobrem esse caminho de login. É necessário fornecer conectividade de saída via NAT gateway ou proxy — veja as considerações para acesso privado no IAM Identity Center.

Custos estimados

A AWS detalha o modelo de custo dos principais componentes desta arquitetura:

Interface VPC endpoints: US$ 0,01/hora por Zona de Disponibilidade (AZ) + US$ 0,01/GB processado (~US$ 7,20/mês por endpoint por AZ)
Gateway VPC endpoints (S3): Sem custo adicional
VPC connections (ENIs do Quick): Incluídas no Quick Enterprise, sem custo adicional
NAT gateway (para domínios externos): US$ 0,045/hora + US$ 0,045/GB processado (~US$ 32/mês fixo)
VPC Flow Logs: Taxas de ingestão do CloudWatch Logs, variando com o volume de tráfego

Para otimizar custos, a AWS recomenda usar Gateway endpoints para S3 (gratuitos) em vez de Interface endpoints, habilitar VPC Flow Logs seletivamente apenas nas ENIs de endpoint (em vez de toda a VPC), e avaliar se todos os domínios externos precisam de NAT gateway ou se um proxy direcionado seria mais econômico.

Boas práticas de segurança

Nem o isolamento de rede nem os controles de identidade são suficientes sozinhos. A AWS enfatiza que a arquitetura depende de ambas as camadas trabalhando juntas:

Aplique políticas de mínimo privilégio (least-privilege) nos endpoints: restrinja endpoints do website por aws:PrincipalAccount ou aws:OrgId, e no endpoint de API, limite as ações apenas às que sua automação realmente precisa.
Use security groups em camadas: tanto nas ENIs dos VPC endpoints (tráfego de usuário) quanto nas ENIs das VPC connections (tráfego de dados).
Habilite VPC Flow Logs em todas as ENIs de endpoint para capturar metadados de tráfego para monitoramento de segurança e auditoria de conformidade.
Crie VPC connections separadas por ambiente (dev, staging, produção) para evitar acesso cruzado entre ambientes.
Monitore com CloudWatch: configure alarmes para as métricas PacketsDropped e ActiveConnections.

Conclusão

A arquitetura descrita pela AWS estabelece quatro controles complementares: VPC endpoints mantêm o tráfego de usuários privado, VPC connections oferecem ao Quick um caminho privado para as fontes de dados, a federação de identidade determina quem pode acessar o quê, e as restrições de VPC endpoint tornam o caminho privado obrigatório. Com isso em vigor, Quick Agents podem consultar bancos de dados on-premises, Quick Research pode investigar fontes empresariais atrás do firewall, Quick Sight pode visualizar dados sensíveis e Quick Flows pode orquestrar sistemas internos — tudo sem que os dados atravessem a internet pública.

A AWS recomenda começar pelos VPC endpoints para acesso de usuários e API, validar o acesso antes de avançar para as VPC connections de fontes de dados, e habilitar as restrições de VPC endpoint apenas após confirmar que todos os padrões de acesso funcionam pelo caminho privado.

Fonte

Securing Quick access from corporate networks with AWS PrivateLink (https://aws.amazon.com/blogs/machine-learning/securing-quick-access-from-corporate-networks-with-aws-privatelink/)