Segurança no AWS CloudFormation: Boas Práticas

O AWS CloudFormation transforma sua infraestrutura em templates declarativos, e é exatamente por isso que a segurança no CloudFormation merece o mesmo rigor que você aplica ao código da aplicação. Um template é uma planta de recursos reais — roles de IAM, buckets S3, security groups, bancos de dados — e qualquer fragilidade embutida nessa planta é fielmente reproduzida sempre que o stack faz o deploy, em cada conta e região para onde você o distribui. A boa notícia é que a mesma propriedade "as code" que permite a uma configuração incorreta se espalhar também permite que você a revise, teste e bloqueie automaticamente. Este artigo é um mergulho prático e específico do CloudFormation nas boas práticas de segurança do AWS CloudFormation que impedem que seus templates se tornem uma fonte repetível de risco. Ele faz parte do nosso pilar mais amplo de segurança de Infrastructure as Code; portanto, se você quiser o panorama estratégico entre as ferramentas, comece por lá e volte para os detalhes específicos do CloudFormation.

Um breve enquadramento antes dos detalhes. O CloudFormation não é seguro por padrão no sentido que as pessoas costumam presumir: ele criará com prazer um recurso totalmente aberto se for isso que o seu template descrever. A função dele é tornar real o estado desejado, não julgar se esse estado é seguro. Portanto, a segurança vive em dois lugares — nos templates que você escreve e no pipeline que transforma esses templates em stacks implantados. Acerte nos dois e você obtém templates de CloudFormation seguros que permanecem seguros à medida que evoluem.

Mantenha os segredos fora dos seus templates

O erro mais comum e mais prejudicial no CloudFormation é colocar segredos diretamente em um template. Uma senha de banco de dados, uma chave de API ou um token escrito como string literal passa a estar comitado no controle de versão, copiado em todos os eventos do stack e visível para qualquer pessoa com acesso de leitura ao template ou ao stack. Rotacioná-lo depois significa editar e reimplantar, e o valor antigo permanece para sempre no histórico do git.

A correção é referenciar os segredos em vez de embuti-los. O CloudFormation oferece suporte a dynamic references que resolvem valores no momento do deploy a partir do AWS Secrets Manager ou do SSM Parameter Store, de modo que o segredo nunca aparece no próprio template:

Resources:

  Database:

    Type: AWS::RDS::DBInstance

    Properties:

      Engine: postgres

      MasterUsername: admin

      MasterUserPassword: '{{resolve:secretsmanager:prod/db:SecretString:password}}'

Para valores passados no momento do deploy, declare o parâmetro com NoEcho: true para que ele fique mascarado no console, na CLI e nas respostas da API:

Parameters:

  DbPassword:

    Type: String

    NoEcho: true

    Description: Injected at deploy time; never stored in the template.

NoEcho é uma melhoria genuína, mas trate-o como uma camada, não como uma garantia. Os segredos ainda podem vazar por vários canais paralelos: um parâmetro NoEcho aparece em texto puro se você o referenciar em uma seção Outputs, valores podem surgir em eventos do stack e change sets, e qualquer coisa que você imprima na Lambda de um custom resource pode acabar nos logs do CloudWatch. Então a regra é mais ampla do que "use NoEcho": nunca coloque um segredo em um output, tenha cuidado com o que os custom resources registram e prefira resolver os segredos em tempo de execução a partir de um store gerenciado em vez de passá-los pelo stack.

Aplique o menor privilégio de IAM

O CloudFormation e o IAM se cruzam de duas maneiras, e ambas importam. Primeiro, as roles, policies e usuários de IAM que o seu template cria devem seguir o menor privilégio — conceda apenas as ações e recursos de que uma carga de trabalho realmente precisa, restrinja os ARNs dos recursos em vez de usar "Resource": "*" e resista à conveniência de Action: "*" ou de wildcards amplos no nível de serviço, como s3:*. Uma role que o seu stack provisiona com permissões equivalentes a admin é um risco permanente por toda a vida do stack.

Segundo, há a identidade que o próprio CloudFormation usa. Por padrão, o serviço age com as permissões de quem o chama, mas você pode e geralmente deve anexar uma service role dedicada a um stack, para que suas ações sejam restritas e auditáveis independentemente de quem executa o deploy. Quando um template cria ou modifica recursos de IAM, o CloudFormation exige que você reconheça isso explicitamente com CAPABILITY_IAM, ou CAPABILITY_NAMED_IAM quando esses recursos têm nomes personalizados. Esse reconhecimento existe justamente porque as mudanças de IAM são sensíveis — trate a concessão dele como um ponto de revisão deliberado, não como uma caixa que você marca para fazer um erro desaparecer. Um pull request que de repente precisa de CAPABILITY_NAMED_IAM é um sinal para observar de perto quais permissões estão sendo criadas.

Detecte defaults inseguros de recursos

A maior parte do risco real no CloudFormation não é exótica — são recursos comuns implantados com configurações permissivas ou sem criptografia. Alguns infratores recorrentes:

• Buckets S3 públicos e bucket policies — buckets deixados legíveis para o mundo, ou policies com um Principal igual a "*", são uma fonte perene de exposição de dados. Defina PublicAccessBlockConfiguration e mantenha as bucket policies restritas.
• Security groups abertos — uma regra de ingress que permite 0.0.0.0/0 na porta 22 ou 3389 expõe SSH ou RDP a toda a internet.
• Armazenamento sem criptografia — buckets S3, volumes EBS e instâncias RDS sem criptografia em repouso, ou recursos que pulam a criptografia em trânsito.
• Bancos de dados acessíveis publicamente — uma instância RDS com PubliclyAccessible: true em uma sub-rede pública.

Veja como se parece um security group superexposto em um template — exatamente o tipo de coisa que a análise estática deveria sinalizar antes mesmo do deploy:

  SshFromAnywhere:

    Type: AWS::EC2::SecurityGroup

    Properties:

      GroupDescription: Bad idea

      SecurityGroupIngress:

        - IpProtocol: tcp

          FromPort: 22

          ToPort: 22

          CidrIp: 0.0.0.0/0 # exposes SSH to the whole internet

Essas são propriedades declarativas, o que significa que uma ferramenta de análise estática pode ler o template e dizer que o recurso está mal configurado antes de qualquer chamada de API ser feita. Esse é o hábito de maior alavancagem na segurança do CloudFormation: faça o scan do template, não apenas da conta em execução.

Proteja os stacks implantados: policies, proteção contra terminação e drift

A segurança não termina no deploy. Uma vez que um stack está no ar, três recursos do CloudFormation ajudam a mantê-lo confiável.

As stack policies protegem recursos críticos contra atualizações ou substituições acidentais durante uma atualização de stack. Anexar uma policy que nega atualizações a, digamos, um banco de dados de produção evita que uma mudança descuidada no template o substitua e destrua dados.

A proteção contra terminação impede que um stack seja excluído — seja por acidente, seja por um atacante com permissões sobre o stack — até que a proteção seja explicitamente desativada. Habilite-a em qualquer stack cuja exclusão seria disruptiva.

O drift detection informa quando os recursos reais divergiram do que o template declara. Drift normalmente significa que alguém fez uma mudança diretamente no console ou na CLI, contornando o seu pipeline revisado. Isso é ao mesmo tempo um risco operacional e de segurança: um security group aberto manualmente, ou uma configuração de criptografia silenciosamente desabilitada, não aparecerá nos seus templates. Execute o drift detection em uma cadência regular e investigue tudo o que retornar com drift, porque seus templates só são uma fonte da verdade se a realidade de fato corresponder a eles.

Confie na cadeia de suprimentos dos seus templates

Templates raramente vivem sozinhos. Nested stacks, módulos do CloudFormation e templates compartilhados obtidos do S3 ou de um registry trazem código que você não necessariamente escreveu. Cada um deles é uma dependência de cadeia de suprimentos, e a mesma cautela que você aplica a bibliotecas de terceiros se aplica aqui:

• Obtenha nested stacks e módulos de repositórios e buckets que você controla e nos quais confia, não de URLs públicas arbitrárias.
• Fixe versões em vez de sempre puxar a "latest", para que uma mudança upstream não possa alterar silenciosamente o que você implanta.
• Revise os templates compartilhados antes de adotá-los e refaça o scan deles como parte do seu próprio pipeline, em vez de presumir que um autor upstream já o fez.

Uma configuração incorreta herdada de um nested stack é tão real quanto uma que você mesmo escreveu; portanto, traga os templates importados para dentro do seu limite de scanning e revisão.

Coloque proteções no pipeline

Tudo o que foi dito acima só se torna sustentável quando é automatizado. A revisão manual detecta alguns problemas, mas a maneira confiável de garantir templates de CloudFormation seguros é fazer o seu pipeline aplicá-los a cada mudança.

Comece com linting e policy-as-code. O cfn-lint valida a estrutura do template, as propriedades dos recursos e as intrinsic functions, capturando classes inteiras de erros antes do deploy. O AWS CloudFormation Guard permite que você expresse regras organizacionais como policy — "todo bucket S3 deve bloquear o acesso público", "nenhum security group pode permitir 0.0.0.0/0 na porta 22" — e avalie os templates em relação a elas automaticamente. Rodar isso na integração contínua significa que uma violação de regra aparece como uma verificação falha no pull request, onde é uma edição rápida, em vez de como um incidente semanas depois.

Depois, adicione o scanning de segurança dos próprios templates. Faça o scan de cada template em busca de configurações incorretas — os defaults inseguros descritos acima e mais — e faça o pipeline falhar diante de achados de alta severidade, para que um bucket aberto ou uma policy de IAM ampla demais não possa ser mesclado silenciosamente. Bloqueie os deploys com base nessas verificações da mesma forma que você bloqueia com base em testes que passam. O objetivo é simples: a segurança viaja com a mudança, automaticamente, de modo que o caminho seguro também seja o caminho de menor resistência para os seus desenvolvedores.

Como a Rainforest ajuda

Fazer tudo isso à mão em muitos templates, stacks e contas não escala. A Rainforest traz a segurança do CloudFormation para o seu fluxo de desenvolvimento normal com scanning de infrastructure-as-code que lê seus templates e sinaliza configurações incorretas — armazenamento público, security groups abertos, ausência de criptografia, IAM com privilégios excessivos, segredos em hardcode — antes que sejam enviados. Os achados surgem diretamente nos pull requests e na CI, priorizados por severidade, para que sua equipe corrija os problemas na origem em vez de descobri-los em uma conta ativa. Como a mesma plataforma também cobre o código da sua aplicação e as dependências, você obtém uma visão consistente do risco em toda a stack, em vez de costurar ferramentas desconectadas. E como o CloudFormation é apenas um dos vários formatos de IaC que as equipes usam, fazer o scan dele junto com seus outros templates mantém seus padrões uniformes, não importa como uma determinada peça de infraestrutura seja definida.

Se você quiser vê-la em ação nos seus próprios templates, conheça nossa ferramenta de segurança de IaC, explore a plataforma de application security testing mais ampla ou agende uma demonstração.