Visão geral

Este documento descreve as práticas recomendas para introduzir mudanças nas configurações dos serviços de borda da AWS, como CloudFront, Lambda@Edge e AWS WAF. Essas mudanças podem incluir a atualização do código da função do CloudFront, a modificação do runtime de uma função do Lambda@Edge, a adição de um novo comportamento de cache no CloudFront, a atualização das regras do WAF ou a ativação de novos atributos do CloudFront, como HTTP/3. Se você tem configurações relativamente estáticas e simples e prefere uma interface de usuário para gerenciamento manual, pode confiar no console da AWS. No entanto, para configurações mais complexas, é recomendável aproveitar os pipelines de CI/CD para implantar alterações de configuração e atualizações de código de forma controlada.

Pipeline de CI/CD

Infraestrutura como código (IaaC)

Os pipelines de CI/CD melhoram os ciclos de lançamento de software aumentando a velocidade de desenvolvimento, oferecendo maior qualidade de código e reduzindo erros humanos por meio da automação. Os serviços de borda da AWS, como o CloudFront, e as funções de borda podem ser gerenciados em um pipeline de CI/CD usando a Infraestrutura como código (IaC). Os recursos da borda podem ser implantados por meio de APIs (por exemplo, a API do CloudFront), da AWS CLI ou de ferramentas de abstração de alto nível, como CloudFormation, Terraform e o Kit de desenvolvimento em nuvem (CDK).

IaC baseada em CDK

O CDK, baseado no CloudFormation, fornece o mais alto nível de abstração ao permitir que você implante recursos da AWS usando uma linguagem de programação. Por exemplo, as três linhas de código JavaScript a seguir podem implantar um bucket do S3 tendo o CloudFront como origem:

const myBucket = new s3.Bucket(this, 'myBucket');
new cloudfront.Distribution(this, 'myDist', {
  defaultBehavior: { origin: new origins.S3Origin(myBucket) },
});

Confira a biblioteca de estruturas de CDK para ver estruturas reutilizáveis para incluir em seu código CDK.

Implantação e orquestração

Em seu pipeline de CI/CD, você precisará de um repositório como o AWS CodeCommit para armazenar seu código (código CDK, código de funções de borda), uma ferramenta como o AWS CodeDeploy para implantar sua infraestrutura e uma ferramenta de orquestração como o AWS CodePipeline para gerenciar as etapas do pipeline. Esta publicação do blog demonstra o uso de ferramentas de desenvolvimento da AWS para implementar um pipeline de CI/CD para o CloudFront, mas você também pode usar suas ferramentas de CI/CD preferidas. Ao criar seu pipeline de CI/CD para serviços de borda da AWS, considere as seguintes limitações:

  • O CloudFront, o CloudFront Functions e as WebACLs regionais do AWS WAF podem ser implantados em qualquer região da AWS
  • O Lambda@Edge e as WebACLs do WAF para o CloudFront somente podem ser implantados na região us-east-1 no Norte da Virgínia.
  • As políticas do Firewall Manager devem ser implantadas na conta da AWS do administrador do Firewall Manager

Teste e preparação

Sua configuração de borda pode ser testada em diferentes níveis. Primeiro, você pode replicar sua infraestrutura, como uma distribuição do CloudFront com uma WebACL do AWS WAF em contas de testes. Isso pode ser feito durante a fase de desenvolvimento ou para executar testes funcionais automatizados antes de passar para a produção. Observe que você não pode usar duas distribuições do CloudFront com o mesmo CNAME. Consequentemente, você precisa diferenciar a configuração do CNAME para seu recurso do CloudFront com base na fase de CI/CD. Por exemplo, você pode usar o nome de domínio do CloudFront (por exemplo, xyz.cloudfront.net) para a fase de desenvolvimento, um CNAME dedicado para preparação (por exemplo, staging.www.example.com) e o CNAME público para implantação na produção (por exemplo, www.example.com). Você também pode diferenciar os controles de segurança por estágio, como restringir o acesso a IPs específicos usando o AWS WAF para a fase de preparação.

Depois que sua nova configuração passar pelo teste, você poderá implementar uma abordagem de lançamento de canário usando o atributo de implantação contínua do CloudFront para testar a mudança na produção em uma pequena parte do seu tráfego. Com esse atributo, você pode criar uma configuração diferente para a sua distribuição de produção e enviar apenas uma parte do seu tráfego global para ela. Você tem duas opções de rotear o tráfego para a nova configuração: usar um cabeçalho de solicitação específico (útil para testes sintéticos) ou usar uma política ponderada para rotear uma porcentagem configurável do tráfego para a nova configuração, com a opção de habilitar a aderência. Na versão atual desse atributo, você só pode testar alterações em um subconjunto de parâmetros da configuração do CloudFront. Consulte a documentação para entender melhor o que você pode testar usando esse atributo.

Configuração dinâmica

Considere um cenário em que várias equipes introduzam mudanças na configuração do CloudFront, mas uma única equipe gerencia o pipeline de CI/CD para todas as equipes. Por exemplo, equipes diferentes podem gerenciar microsserviços separados, todas expondo suas APIs no domínio principal hospedado por uma única distribuição do CloudFront. Se você permitir que cada equipe acesse a configuração completa da distribuição do CloudFront, aumentará o raio de influência de uma única alteração incorreta. Por outro lado, se você permitir apenas que a equipe de CI/CD faça alterações na distribuição do CloudFront, você diminui a velocidade de desenvolvimento e introduz um gargalo no ciclo de vida do lançamento. Em vez disso, você pode gerar a configuração dinamicamente com base em configurações parciais de propriedade de cada equipe de microsserviços. Em uma implementação simples, cada equipe pode gerenciar a configuração da sua própria rota (armazenamento de cache, funções de borda etc.) em um arquivo baseado em texto hospedado em um bucket do S3. Em seu pipeline de CI/CD, você pode introduzir uma etapa adicional para criar dinamicamente a configuração final do CloudFront usando os diferentes arquivos de configuração parcial.

Implantação do AWS WAF e do AWS Shield

Os serviços Shield e WAF podem ser implantados usando as mesmas ferramentas descritas anteriormente em um pipeline de CI/CD.

No entanto, é recomendável usar o AWS Firewall Manager para implantar regras do WAF e proteções do Shield com as seguintes vantagens:

  • Ele facilita a aplicação de uma governança de segurança central (por exemplo, implantação de regras centrais em combinação de regras gerenciadas por equipes de aplicações)
  • Ele oferece uma implantação mais rápida, o que é crucial para corrigir vulnerabilidades críticas usando o AWS WAF.
  • Ele simplifica a implantação em contas e canais heterogêneos de CI/CD (por exemplo, herdados de aquisições). No entanto, com essa abordagem, você precisa gerenciar o desvio se estiver usando um pipeline de CI/CD com detecção de desvios.

Além disso, você pode usar um pipeline de CI/CD para fazer alterações nas políticas do Firewall Manager na conta do administrador, que será implantada em toda a sua organização da AWS pelo Firewall Manager, conforme demonstrado pelo OLX.

A implantação de regras do WAF com segurança no deu ambiente de produção pode ser feita usando estratégias diferentes. Você pode adicionar novas regras a uma WebACL existente no modo de contagem e depois alterá-la para o modo de bloqueio. No entanto, com essa abordagem, você precisa prestar atenção ao WCU máximo da sua WebACL. Outra abordagem seria implantar mudanças em uma WebACL de teste e testar as alterações em um ambiente de preparação.

Recursos

Esta página foi útil para você?

 Feedback