Segurança de Infrastructure as Code (IaC): o guia completo

Infrastructure as Code mudou a forma como as equipes constroem e operam sistemas e, ao fazê-lo, mudou o problema de segurança. Quando suas redes, bancos de dados, permissões e clusters são todos definidos em arquivos de texto que são aplicados automaticamente, a segurança de IaC passa a ser a prática de garantir que essas definições sejam seguras antes mesmo de provisionarem um recurso. Este guia percorre o que significa segurança de infrastructure as code, as ameaças específicas a ela, como fazer o scanning de IaC ao longo do ciclo de vida de desenvolvimento de software e as práticas que evitam que uma base crescente de código de infraestrutura acumule risco em silêncio.

Se você é responsável por uma plataforma, um pipeline ou pela segurança de qualquer um dos dois, o apelo do IaC é evidente: os ambientes se tornam reproduzíveis, revisáveis e versionados. O problema é que cada uma dessas propriedades é uma faca de dois gumes. Reproduzível significa que um erro se reproduz perfeitamente. Revisável significa que nada é seguro a menos que alguém realmente revise. Versionado significa que um secret commitado hoje fica no seu histórico para sempre. Uma infrastructure as code segura é o que fecha essa lacuna.

O que é IaC e por que a segurança de IaC importa

Infrastructure as Code é a prática de definir e provisionar infraestrutura — computação, armazenamento, rede, identidade e os serviços em cima disso — por meio de arquivos de definição legíveis por máquina, em vez de cliques manuais em um console. As ferramentas aplicam esses arquivos para criar, atualizar e remover recursos reais. As definições vivem no controle de versão junto do código da aplicação, passam pela mesma revisão e CI e se tornam a única fonte de verdade sobre como um ambiente deve ser.

Esse modelo é poderoso e remodela o cenário de segurança de três formas específicas.

Configuração incorreta em escala. Os incidentes de nuvem mais comuns não são exploits exóticos; são configurações incorretas — um bucket de armazenamento deixado público, um security group aberto para o mundo, uma identidade com mais permissão do que precisa. Em um console, uma configuração incorreta é um erro em um único lugar. Em IaC, uma configuração incorreta fica embutida em um template ou módulo que pode ser aplicado dezenas de vezes em regiões, contas e equipes. A eficiência que torna o IaC valioso é exatamente o que transforma um pequeno erro em um erro sistêmico.

Drift. O IaC parte do princípio de que o código é a verdade. Mas alguém faz uma mudança emergencial no console às 2 da manhã, ou um processo automatizado altera um recurso, e agora o ambiente em execução não corresponde mais ao que está no controle de versão. Essa lacuna — o drift — é perigosa porque suas revisões, scans e auditorias operam todos sobre o código, enquanto os atacantes operam sobre o que está de fato rodando. Um drift não detectado significa que seus controles de segurança estão inspecionando uma ficção.

Erros repetíveis. As equipes copiam módulos. Elas dão fork em um exemplo que funciona, ajustam dois valores e colocam em produção. Se o original tinha um padrão inseguro, todo descendente o herda, e a correção agora precisa ser rastreada em tudo que algum dia tomou emprestado dele. Bons padrões se propagam pelo IaC, e os ruins também.

A segurança de IaC importa porque move o ponto de controle para o único lugar onde uma correção é barata e universal: a definição. Mude o módulo e todo ambiente construído a partir dele é corrigido. Essa é a mesma lógica de shift-left que sustenta a application security moderna, aplicada à camada de infraestrutura.

O modelo de ameaças do IaC

Para proteger a infrastructure as code, ajuda ser concreto sobre o que de fato dá errado. Estas são as categorias recorrentes.

Padrões inseguros

Muitos recursos são permissivos de fábrica, ou se tornam permissivos quando você omite uma configuração. Armazenamento sem criptografia, logging desabilitado, TLS não imposto, policies padrão generosas demais — nenhum desses lança um erro no momento do apply. Eles simplesmente provisionam em silêncio e esperam. Padrões inseguros são o achado mais comum de todos porque "deixar de fora" é mais fácil do que "configurar corretamente", e as ferramentas raramente resistem por conta própria.

Secrets expostos em código e state

Credenciais hardcoded, API keys, senhas de banco de dados e certificados privados acabam em arquivos de IaC com mais frequência do que qualquer um gosta de admitir. Uma vez commitado, um secret vive no histórico do git mesmo depois de ser removido da versão atual. Pior ainda, secrets frequentemente vão parar em arquivos de state — o registro dos recursos provisionados — em texto puro, incluindo valores que nunca deveriam ter sido persistidos. Manter secrets fora de ambos os lugares é uma preocupação de primeira ordem.

IAM permissivo demais

Identity and access management é onde o risco de IaC se concentra. Ações com wildcard, recursos com wildcard, roles que podem assumir outras roles e permissões concedidas "para fazer funcionar" durante a depuração que nunca são revertidas. Um IAM amplo demais é o que transforma um único componente comprometido em uma tomada completa do ambiente, porque o raio de impacto de qualquer violação é definido pelo que a identidade comprometida tinha permissão de fazer.

Armazenamento público e caminhos de rede abertos

Armazenamento exposto à internet pública e regras de rede que permitem ingress de qualquer lugar são fontes perenes de exposição de dados. Em IaC, isso muitas vezes parece inofensivo — um único CIDR de 0.0.0.0/0, um access block deixado sem definir — mas são exatamente as condições que levam a violações. Merecem verificações de policy dedicadas porque seu impacto é desproporcional ao quão pequena a mudança parece em um diff.

Módulos não fixados e a supply chain

O IaC puxa módulos, providers e imagens base externos. Se essas referências não estão fixadas — flutuando em "latest" ou em uma branch sem versão — você herda o que quer que mude a montante, incluindo mudanças maliciosas, sem revisão. Essa é a face de infraestrutura do risco de supply chain de software, que o OWASP Top 10 (2025) eleva como A03: Software Supply Chain Failures. Fixe versões, verifique a integridade onde puder e trate código de infraestrutura de terceiros com o mesmo escrutínio que dependências de aplicação de terceiros.

Exposição do arquivo de state

O state merece sua própria linha no modelo de ameaças. Ele registra a topologia completa do seu ambiente e, como observado, pode conter secrets em texto puro. State armazenado em um backend não protegido — um bucket sem criptografia, sem controles de acesso, sem versionamento — é um mapa da sua infraestrutura entregue a qualquer um que o encontre. O state remoto deve ser criptografado, rigorosamente permissionado, versionado e bloqueado contra escritas concorrentes.

Scanning de IaC no SDLC: faça o shift left e continue

A prática de segurança de IaC mais eficaz de todas é fazer o scanning das definições cedo e repetidamente, em cada etapa em que uma pessoa ou um pipeline as toca. O scanning de IaC — analisar estaticamente os arquivos de definição contra um conjunto de regras de segurança — é como você detecta as ameaças acima antes que provisionem qualquer coisa. O objetivo não é um único gate, mas uma série deles, cada um mais barato do que o incidente que previne. Essa é a expressão de infraestrutura do movimento mais amplo de DevOps para DevSecOps.

Pre-commit

O gate mais precoce e mais barato roda na máquina do engenheiro antes mesmo de o código ser commitado. Hooks de pre-commit detectam problemas óbvios — um secret prestes a ser commitado, uma configuração incorreta gritante — em segundos, com todo o contexto da mudança fresco na mente do autor. Mantenha essas verificações rápidas e focadas; o trabalho delas é feedback instantâneo, não análise exaustiva.

Pull request

O pull request é onde a segurança de IaC se torna uma atividade de equipe. Resultados de scan postados diretamente no PR transformam a segurança em parte da revisão de código, em vez de uma cerimônia separada. Este é o lugar certo para o conjunto completo de regras: os achados aparecem em contexto, nas linhas específicas que os introduziram, e são resolvidos antes do merge. Trazer os resultados como comentários no PR — com explicações claras e correções sugeridas — é o que faz a diferença entre desenvolvedores que se engajam com a segurança e desenvolvedores que a contornam.

CI

A integração contínua é a rede de proteção de imposição. Mesmo com verificações de pre-commit e de PR, a CI é onde você define a policy que não pode ser pulada: falhar o build em achados de alta severidade, bloquear merges que reintroduzem um problema já corrigido e produzir os artefatos e a trilha de auditoria dos quais a conformidade depende. O scanning na CI também captura qualquer coisa que tenha escapado dos gates anteriores, mais fáceis de pular.

Momento do plan e da admission

O scanning estático lê o código; o scanning em plan-time e admission-time inspeciona o que o código de fato vai fazer. Avaliar uma mudança planejada contra a policy — antes de ela ser aplicada — captura problemas que só emergem da combinação de recursos, ou de valores resolvidos no momento do plan. Para clusters, o admission control faz o trabalho equivalente no momento do deploy, rejeitando workloads que violam a policy antes que elas cheguem a rodar. Este é o último gate antes de a mudança virar realidade, e é o mais difícil de contornar.

Detecção de drift

Por fim, fazer o scanning do código não basta se o ambiente em execução pode divergir dele silenciosamente. A detecção de drift compara a infraestrutura ativa com as definições commitadas e sinaliza qualquer coisa que não corresponda. Ela fecha o ciclo aberto pelo modelo de ameaças: garante que o ambiente que seus controles de segurança inspecionaram é o ambiente que está de fato rodando, e transforma mudanças fora de banda de risco invisível em um sinal revisável.

Os principais formatos — e que cada um precisa ser protegido

O IaC não é uma única tecnologia, mas uma família de ferramentas e formatos, cada um com sua própria sintaxe, seus próprios idiomatismos e seus próprios erros característicos. Um programa completo de segurança de IaC precisa entender todos os que você usa. Aqui está o panorama, com aprofundamentos nos guias dedicados.

Terraform é a ferramenta de provisionamento de propósito geral mais amplamente adotada, abrangendo quase toda nuvem e serviço por meio de providers. Suas preocupações de segurança giram em torno da gestão de state, do pinning de providers e módulos e da facilidade com que IAM e regras de rede permissivos escorregam para dentro do HCL. Veja o guia dedicado sobre Terraform security.

Ansible cuida da gestão de configuração e do provisionamento por meio de playbooks. Seus riscos pendem para secrets em variables e vaults, escalonamento de privilégios e tasks que alcançam fontes não verificadas. O guia de Ansible security cobre isso em profundidade.

CloudFormation é a linguagem de provisionamento nativa de uma grande nuvem, expressa em templates JSON ou YAML. Padrões inseguros, secrets hardcoded em parameters e roles amplos demais são os suspeitos de sempre; o guia de CloudFormation security vai além.

Além desses três, vários outros formatos aparecem o tempo todo e cada um precisa do mesmo tratamento. Manifests de Kubernetes e charts Helm definem workloads e suas permissões, onde pods com privilégios excessivos, security contexts ausentes e serviços expostos são comuns — o guia de Kubernetes security cobre esse conjunto de preocupações, e as imagens de container merecem seu próprio scanning via container security. Templates ARM e Bicep são os formatos nativos de outra grande nuvem, com os mesmos padrões de padrão-inseguro e permissão-excessiva. Pulumi permite definir infraestrutura em linguagens de programação de propósito geral, o que traz a ergonomia familiar do desenvolvedor junto com as preocupações de application security da própria linguagem.

O fio condutor: cada um desses é código que provisiona recursos reais e relevantes para a segurança, e cada um merece ser escaneado. Uma lacuna na cobertura — um formato que suas ferramentas não entendem — é um ponto cego que um atacante só precisa encontrar uma vez.

Policy as code

À medida que o número de regras e o número de equipes crescem, a revisão ad hoc deixa de escalar. Policy as code é a resposta: você expressa seus requisitos de segurança e conformidade como policy legível por máquina que roda automaticamente contra o seu IaC. A abordagem mais comum usa um motor e uma linguagem de policy de propósito geral — OPA com Rego é o exemplo amplamente adotado — para definir regras como "nenhum armazenamento pode ser público", "todos os volumes devem ser criptografados" ou "nenhuma policy de IAM pode usar ações com wildcard".

O retorno é consistência e velocidade. Policy as code transforma seus padrões em guardrails que se aplicam de forma idêntica a cada mudança, cada equipe e cada ambiente, sem que uma pessoa precise se lembrar deles. Ela remove a discussão do pull request — a policy passa ou não passa — e lhe dá um único lugar versionado e revisável para evoluir seus requisitos. Codificar guardrails também significa que, à medida que seus padrões amadurecem, a melhoria se propaga por toda parte de uma só vez, a mesma alavancagem que torna o IaC valioso em primeiro lugar, voltada para a defesa.

Gestão de secrets e state

Duas preocupações permeiam tudo o que foi dito acima e vale destacá-las explicitamente.

Secrets. A regra é simples de enunciar e exige disciplina para manter: secrets nunca pertencem ao código-fonte de IaC. Use um secrets manager dedicado e referencie os secrets em runtime, em vez de embuti-los. Faça o scanning continuamente em busca de secrets que escapem mesmo assim — no código e no histórico de commits — e, quando um for encontrado, rotacione-o, porque apagar um secret commitado não desfaz a exposição. Trate toda credencial que tenha tocado o controle de versão como comprometida até ser rotacionada.

State. O state remoto é infraestrutura sensível. Armazene-o em um backend criptografado com controles de acesso rígidos, habilite o versionamento para poder se recuperar de um apply ruim e use state locking para impedir que escritas concorrentes o corrompam. Esteja ciente do que vai parar no state — incluindo secrets que são persistidos ali em texto puro — e restrinja quem e o que pode lê-lo. O acesso ao state deve ser tão restrito quanto o acesso ao banco de dados de produção, porque funcionalmente é o que ele é.

Um fluxo de remediação que os desenvolvedores realmente vão usar

Encontrar problemas é só metade do trabalho; a outra metade é conseguir corrigi-los sem travar a entrega. Um fluxo que funciona tende a compartilhar alguns traços.

Priorize pelo risco real. Nem todo achado é urgente. Classifique por severidade e, criticamente, por explorabilidade e exposição — um problema público, não autenticado e de alto privilégio supera um teórico enterrado três camadas abaixo. Dê aos desenvolvedores uma lista curta e ordenada, não uma parede de alertas indiferenciados.

Entregue os achados em contexto. Um resultado é acionável quando aparece onde o trabalho acontece — no pull request, na linha específica, com uma explicação em linguagem simples de por que importa e uma correção sugerida concreta. Quanto mais distante um achado está do código e do momento que o introduziu, menor a probabilidade de ele ser corrigido.

Controle o ruído. Nada mata um programa de segurança mais rápido do que falsos positivos. Ajuste as regras ao seu ambiente, dê suporte a exceções documentadas com datas de expiração para riscos aceitos e garanta que um achado suprimido seja uma decisão deliberada e revisável, em vez de uma verificação silenciosamente desabilitada.

Previna regressões. Uma vez corrigido um problema, uma policy na CI deve impedir que ele volte. O objetivo é uma catraca: a postura de segurança do seu IaC só aperta com o tempo, porque cada classe de problema resolvida se torna um guardrail imposto.

Boas práticas

Juntando os fios, um programa maduro de segurança de IaC se parece com isto:

• Faça o scanning em cada etapa — pre-commit, PR, CI, momento do plan ou da admission — e adicione detecção de drift para que o state em execução não possa divergir sem ser visto.
• Imponha o menor privilégio em toda parte, especialmente em IAM. Comece do zero e conceda apenas o necessário; wildcards são um cheiro ruim, não um atalho.
• Fixe cada dependência — módulos, providers, imagens base — e revise as atualizações deliberadamente, em vez de flutuar em "latest".
• Mantenha secrets fora do código-fonte e do state. Use um secrets manager, faça o scanning do histórico e rotacione qualquer coisa exposta.
• Codifique seus padrões como policy para que a configuração segura seja o padrão e a imposição seja consistente entre as equipes.
• Use módulos seguros e revisados como a forma padrão de provisionar, para que bons padrões se propaguem em vez de erros copiados-e-ajustados.
• Trate o state como infraestrutura sensível de nível de produção — criptografado, versionado, bloqueado e rigorosamente permissionado.
• Dê aos desenvolvedores feedback rápido e contextual e um caminho de baixo atrito para corrigir, porque um controle que é contornado não protege nada.

Como a Rainforest ajuda

Proteger a infrastructure as code não deveria significar costurar uma ferramenta separada para cada formato e etapa. A Rainforest inclui IaC scanning como parte de sua plataforma de application security testing, analisando seu Terraform, CloudFormation, Ansible, manifests de Kubernetes e outras definições contra um amplo conjunto de regras de segurança e conformidade — e trazendo os resultados para onde sua equipe já trabalha, diretamente no pull request, com explicações claras e correções sugeridas.

Como o risco de IaC não vive isolado, esse scanning fica lado a lado com software composition analysis (SCA) para os módulos e dependências que sua infraestrutura puxa, detecção de secrets no código e no histórico e container security para as imagens que sua infraestrutura executa. O resultado é cobertura em todas as camadas que um ambiente real de fato tem, com uma priorização que aponta as equipes para o que importa e um fluxo projetado para ser corrigido, não ignorado.

Se você está tentando se antecipar à configuração incorreta em escala, agende uma demo e veja como o IaC scanning se encaixa em um único fluxo de application security.