Ocultação de origem

O Origin Cloaking é um conjunto de técnicas que visa reduzir a superfície de ataque de aplicações Web. É uma prática recomendada usar o CloudFront como um único ponto de entrada para aplicações Web, onde controles de segurança, como proteções contra ataques de DDoS e bots indesejados, são aplicados. A Ocultação da origem impede que agentes mal-intencionados contornem o CloudFront e seus controles de segurança para atacar diretamente a origem, usando regras de firewall para bloquear qualquer tráfego que não venha do ponto de entrada do CloudFront. A ocultação da origem pode ser obtida em várias camadas do modelo OSI.

Quando sua origem permitir que você controle o acesso à rede de entrada, adicione restrições para permitir apenas o tráfego proveniente da rede do CloudFront.

Se sua origem for uma instância do EC2, um Application Load Balancer ou um Network Load Balancer, você poderá manter sua origem em uma sub-rede privada na sua VPC e aproveitar o recurso Origens da VPC do CloudFront. Ele permite que você restrinja o acesso exclusivamente às distribuições do CloudFront configuradas com Origens da VPC em sua própria conta da AWS.

Se precisar deixar esses recursos em uma sub-rede pública (por exemplo, seu ALB será acessado por várias CDNs) ou se você tiver um tipo de origem que não é compatível com Origens da VPC do CloudFront, você pode restringir o acesso ao CloudFront usando grupos de segurança. Você precisa associar sua origem a um grupo de segurança, ao qual adiciona a lista de prefixos gerenciada pela AWS para o Amazon CloudFront.

Se sua origem estiver on-premises, você poderá restringir o acesso ao CloudFront permitindo listar os endereços IP de origem do CloudFront, que podem ser encontrados nesta lista de IPs ao filtrar o valor CLOUDFRONT_ORIGIN_FACING do campo serviço. Nessa abordagem, você precisa assinar alterações de IP para atualizar sua ACL. Confira esta postagem do blog para saber como implementar a ocultação de origem em servidores Web on-premises usando firewalls de terceiros. Para aumentar o isolamento da Internet, considere configurar o AWS Direct Connect entre sua infraestrutura on-premises e a AWS usando interfaces virtuais públicas na conexão do Direct Connect.

O controle de acesso na camada de rede é um ponto de partida, mas talvez não seja suficiente para você. Por exemplo, se alguém descobrir o nome do domínio de origem on-premisses, poderá criar uma distribuição do CloudFront em sua própria conta da AWS e ignorar sua própria distribuição. Outro exemplo é usar o recurso Origem da VPC para restringir sua origem a uma distribuição específica do CloudFront em sua conta da AWS, em vez de torná-la acessível a todas as distribuições do CloudFront configuradas com Origens da VPC em sua conta da AWS. Nesse caso, considere fazer um hardening usando o controle de acesso à camada de aplicação.

O bloqueio de alguns tipos de origens no CloudFront é muito simples com o controle de acesso de origem (OAC), um recurso do CloudFront que assina solicitações para determinados tipos de origens de forma nativa usando o algoritmo AWS Signature versão 4 (sigv4) com base nas políticas do IAM. No momento, o OAC é compatível com S3, MediaStore, MediaPackage, URLs de funções do Lambda e S3 Object Lambda. Quando o OAC é usado com o S3, é possível manter seu bucket do S3 privado, com acesso exclusivo ao CloudFront com base nas políticas de bucket do S3.

Quando o tipo de origem não é compatível com o OAC, você pode assinar solicitações para sua origem usando funções de borda. Exemplos de implementações são explicados nos seguintes blogs:

• Solicitações de assinatura usando Sigv4 com o Lambda@Edge para o AWS API Gateway
• Solicitações de assinatura usando MD5 com o Lambda@Edge para servidores NGINX

Se a sua origem não oferece suporte à assinatura de solicitações ou você não considera que esse nível de controle de acesso é necessário para sua aplicação, você pode configurar o CloudFront para enviar um cabeçalho personalizado contendo um segredo compartilhado com sua origem, que pode ser validado pela sua origem para processar a solicitação. Considere o seguinte exemplo de implementação:

• Origem baseada em ALB. Você pode validar o cabeçalho secreto em uma origem baseada em ALB usando uma regra de ALB ou usando uma regra do AWS WAF se o seu ALB já estiver associado a uma WebACL do AWS WAF.
• Origem baseada no API Gateway. Você pode validar o cabeçalho secreto em um API Gateway usando chaves de API.
• Origem baseada em NGINX. Supondo que o CloudFront envie um cabeçalho personalizado X-CloudFront com o valor abc123, você pode validar o cabeçalho secreto no servidor Web baseado em Nginx (baseado na nuvem ou on-premises) adicionando o seguinte código na etiqueta do servidor do arquivo de configuração /etc/nginx/nginx.conf:
  
  if ($http_x_cloudfront != "abc123") {
      return 403;
  }
• Origem baseada em Apache. Supondo que o CloudFront envie um cabeçalho personalizado X-CloudFront com o valor abc123, você pode validar o cabeçalho secreto no servidor Web baseado em Apache (baseado na nuvem ou on-premises) adicionando o seguinte código no arquivo de configuração httpd.conf (e no arquivo ssl.conf, se usado):
  
  RewriteEngine On
  RewriteCond %{HTTP:x-cloudfront} !^abc123$ [NC]
  RewriteRule ^ - [F]

Em todos os casos, é recomendável alternar esse segredo compartilhado regularmente para reduzir o risco de segredos vazados. Nas implementações de exemplo compartilhadas acima, tanto a que usa o API Gateway quanto a que usa ALB incluem uma automação para alternância de segredos.