Infraestrutura como código precisa de controles contínuos

Infraestrutura como código transforma servidores, redes, permissões e serviços de nuvem em arquivos que podem ser revisados e aplicados repetidamente. Isso melhora a consistência, mas também amplia o impacto de uma alteração insegura: um erro aprovado pode ser replicado em vários ambientes. A prioridade da equipa defensiva deve ser tratar o código de infraestrutura como software de produção, com revisão independente, análise automatizada, controlo de privilégios e capacidade de reversão antes da aplicação.

A decisão operacional não é escolher entre velocidade e segurança. É definir quais mudanças podem seguir automaticamente, quais exigem aprovação humana e quais devem ser bloqueadas. Uma regra simples ajuda: qualquer modificação que altere exposição à internet, identidade, armazenamento de dados ou acesso administrativo precisa de evidência de revisão e de um plano de retorno.

O risco está no ciclo

O primeiro erro é olhar apenas para o ficheiro final. O risco pode entrar no módulo reutilizado, na variável de ambiente, no estado armazenado pelo orquestrador, na conta que executa o pipeline ou no artefato transferido para a plataforma cloud. Uma configuração aparentemente segura pode receber permissões excessivas de uma dependência, expor uma porta através de um valor padrão ou gravar uma credencial em logs.

A orientação da OWASP para segurança de infraestrutura como código recomenda incorporar segurança ao ciclo de desenvolvimento. Isso inclui modelação de ameaças, gestão de segredos, controlo de versão, privilégio mínimo, análise estática, verificação de dependências, análise de imagens e integração dos controlos ao CI/CD. A consequência prática é importante: a equipa não deve esperar a execução para descobrir que um recurso foi definido de forma insegura.

O repositório também precisa de regras de proteção. Revisões devem mostrar quem mudou o quê, qual recurso será afetado e por que a alteração é necessária. Branches protegidas, aprovação por uma pessoa diferente do autor e bloqueio de execução a partir de forks não confiáveis reduzem a possibilidade de uma alteração maliciosa chegar ao ambiente. O histórico só é útil se o estado aplicado puder ser comparado com o código aprovado.

Defina uma barreira mínima

Um controlo eficaz começa antes do merge. A análise deve verificar permissões amplas, armazenamento público, cifragem ausente, grupos de segurança permissivos, imagens não autorizadas, regiões proibidas e recursos sem proprietário. O resultado precisa distinguir uma falha bloqueadora de uma recomendação. Se tudo for tratado como emergência, os operadores aprendem a ignorar o sistema.

Use políticas como código para expressar requisitos que possam ser testados de maneira repetível. Exemplos: nenhum armazenamento de dados deve nascer público; nenhuma conta de aplicação deve receber privilégios administrativos; todo recurso crítico deve ter proprietário, ambiente e classificação de dados; e toda alteração de identidade deve exigir revisão especializada. A política deve ser executada sobre o plano de mudança, não apenas sobre o código, porque valores resolvidos e módulos podem alterar o resultado final.

A análise estática não substitui a revisão. Ela identifica padrões conhecidos, mas não compreende sozinha se determinada permissão é necessária para um processo de negócio. Por isso, a equipa deve documentar exceções com prazo, proprietário e compensação. Uma exceção sem data de revisão tende a tornar-se a nova configuração normal.

Proteja identidade e segredos

A conta usada pelo pipeline merece o mesmo cuidado que uma conta administrativa. Separe identidades de leitura, planeamento e aplicação. Conceda à etapa de validação apenas o acesso necessário para consultar metadados e gerar um plano. A etapa que aplica mudanças deve ser isolada, auditada e acionada apenas depois das aprovações previstas. Quando a plataforma permitir, prefira credenciais temporárias e vincule a autorização ao repositório, à branch e ao contexto da execução.

Segredos não devem ser gravados em ficheiros de configuração, no repositório, em imagens ou no resultado de um plano. A OWASP observa que tokens, palavras-passe e chaves SSH podem ser expostos quando são mantidos em ficheiros simples ou em sistemas de controlo de código. O armazenamento deve usar um serviço de segredos com controlo de acesso, rotação e auditoria. Também é necessário mascarar valores em logs e impedir que comandos de diagnóstico imprimam o ambiente completo.

A rotação precisa de um procedimento testado. Revogar uma credencial sem saber quais serviços a utilizam pode interromper produção; mantê-la ativa depois de uma exposição prolonga o risco. Registe dependências, defina uma janela de troca e valide o funcionamento com a nova credencial antes de invalidar a anterior. Em caso de vazamento, a prioridade é revogar, procurar usos históricos e verificar alterações feitas pela identidade comprometida.

Controle a aplicação

O plano gerado pelo sistema deve ser um artefato verificável. Guarde o código, as versões dos módulos, as entradas relevantes, a identidade executora, o resultado das políticas e a aprovação associada. Evite aplicar novamente um plano antigo depois de uma mudança no estado real. Antes de executar, confirme que o alvo continua a ser o ambiente esperado e que não houve alteração de credenciais ou de configuração.

A assinatura de artefatos acrescenta uma barreira contra adulteração entre a construção e o uso. A OWASP recomenda assinar artefatos durante a construção e validar os dados assinados antes da utilização. Na prática, assine módulos, imagens ou pacotes que serão consumidos pelo pipeline, mantenha a chave de assinatura fora do ambiente de construção e rejeite artefatos cuja origem não possa ser confirmada.

O modelo de desenvolvimento seguro do NIST recomenda integrar práticas de segurança ao ciclo de desenvolvimento e usar uma linguagem comum entre produtores, compradores e consumidores de software. Para infraestrutura, isso significa transformar requisitos de segurança em evidências: revisão, teste, origem do artefato, aprovação e registo da execução. A documentação não deve ser um relatório produzido depois do incidente; deve acompanhar a mudança.

Monitore o desvio

Uma implementação aprovada não encerra o controlo. Console, API, operador de nuvem, automação externa ou processo de recuperação podem alterar o ambiente sem atualizar o repositório. Compare periodicamente o estado observado com a configuração declarada e trate o desvio como evento de segurança quando envolver exposição pública, identidade, logging ou dados sensíveis.

Registe criação, alteração e remoção de recursos, mudanças de políticas, uso de credenciais do pipeline, falhas de validação e tentativas de aplicar configurações rejeitadas. O log deve permitir responder quem executou a ação, qual identidade foi usada, qual recurso mudou, de onde veio a solicitação e qual era o valor anterior. Sem o valor anterior, a investigação perde tempo e a reversão fica dependente de suposições.

Crie alertas para padrões que exigem decisão rápida: aumento inesperado de privilégios, desativação de trilhas de auditoria, criação de armazenamento público, alteração de regras de rede e execução fora da janela prevista. O alerta deve apontar para um procedimento, não apenas para um painel. Se a equipa não souber quem decide, como conter e qual configuração restaurar, o monitoramento não produz resiliência.

Procedimento para esta semana

O resultado esperado não é um pipeline que bloqueia tudo. É uma cadeia na qual cada mudança sensível tem contexto, responsável, validação e caminho de retorno. Comece pelas identidades e pelos recursos expostos; depois melhore a cobertura de políticas, a assinatura e a deteção de desvio. Essa ordem reduz o risco operacional sem exigir uma reconstrução completa da plataforma.

Fontes

OWASP — Infrastructure as Code Security

NIST — Secure Software Development Framework

Para aprofundar a operação de deteção, consulte também a análise sobre logs de segurança e o guia de autorização de APIs na nuvem.