As 5 principais preocupações de segurança em infraestrutura como código

A infraestrutura como código (IaC) mudou a forma como implantamos e gerenciamos nossa infraestrutura em nuvem. Em vez de configurar servidores e redes manualmente com uma grande equipe de operações, agora podemos definir a arquitetura dos nossos serviços por meio de código. A IaC permite automatizar a implantação da infraestrutura, escalar toda a frota de servidores, manter um histórico das mudanças na arquitetura e testar alterações incrementais na rede. Não é à toa que a IaC se tornou a principal forma de equipes e empresas configurarem e gerenciarem serviços em nuvem.

No entanto, embora a IaC traga muitos benefícios, ela também envolve preocupações de segurança. Veja as 5 principais preocupações de segurança em IaC e as práticas recomendadas para mitigá-las.

1. Configurações incorretas em templates de IaC

Uma das maiores preocupações de segurança em IaC são as configurações incorretas no template. O código e as dependências de templates de IaC podem conter bugs que comprometem a infraestrutura sem querer ou oferecem a um invasor experiente meios para explorar o sistema.

Por exemplo, imagine que um template de IaC inclua sem querer credenciais de nome de usuário e senha codificadas diretamente para um banco de dados com dados confidenciais de usuários, como informações financeiras ou dados pessoais identificáveis (PII). Um invasor que obtenha acesso não autorizado a esse template poderá visualizar os dados e manipular o banco de dados.

Da mesma forma, imagine um template de IaC com o endereço IP de um servidor crítico codificado diretamente. O servidor pode se tornar alvo de um ataque de negação de serviço (DoS), e talvez seja difícil responder rapidamente e atualizar a infraestrutura. É essencial usar recursos de entrada parametrizada ou variáveis de ambiente para separar credenciais e informações confidenciais do código do template.

Outro exemplo é usar frameworks de IaC desatualizados ou obsoletos e outras dependências de terceiros. Invasores podem descobrir novas falhas em versões antigas do código e explorá-las para tirar proveito de configurações incorretas até então desconhecidas. O risco é ainda maior quando os mesmos templates de IaC são compartilhados entre diferentes ambientes, pois uma única configuração incorreta pode ter um impacto muito maior. É importante manter e atualizar o código regularmente e avaliar com cuidado as dependências de terceiros para garantir que estejam atualizadas.

Para proteger ainda mais os templates de IaC, devemos adotar práticas de codificação segura. Isso inclui escrever código de IaC robusto, com validação de entradas e parâmetros nas funções, e usar frameworks de teste e controle de versão para validar e acompanhar as mudanças no código, permitindo tratar erros rapidamente. Também devemos verificar se o template funciona corretamente durante a implantação e a remoção para evitar custos inesperados com serviços que não foram removidos como deveriam.

2. Armazenamento e transmissão inseguros de segredos

O gerenciamento de segredos é outra preocupação crítica de segurança em IaC. Senhas e chaves de API representam um risco quando são expostas. Pessoas mal-intencionadas podem usar outras informações confidenciais, como URLs de webhooks ou endereços IP, para enviar spam, esgotar recursos e derrubar um serviço ou uma rede.

Até mesmo o acesso somente leitura a um template de IaC pode fornecer informações valiosas sobre a infraestrutura a invasores, ajudando-os a identificar possíveis configurações incorretas. Isso facilita o planejamento e a execução de ataques direcionados.

Felizmente, frameworks de IaC e plataformas de nuvem permitem armazenar e usar esses segredos com segurança. Por exemplo, o Terraform Cloud oferece um recurso de gerenciamento de segredos para garantir que esses valores confidenciais sejam criptografados e armazenados corretamente. Além disso, os serviços de nuvem costumam fornecer segredos automaticamente — como chaves de acesso e strings de conexão com bancos de dados — por meio de variáveis de ambiente. Assim, podemos substituí-los por nossos próprios valores durante o desenvolvimento local.

3. Políticas de controle de acesso mal configuradas e desvio de configuração

O OWASP Top 10, documento reconhecido mundialmente sobre segurança de aplicações web, considera o controle de acesso insuficiente e as configurações incorretas na nuvem preocupações significativas.

Hackers podem explorar políticas de acesso permissivas demais para recursos como servidores e armazenamento de dados na nuvem, a fim de executar ataques ou obter informações privadas. Buckets do AWS S3 mal configurados já causaram o vazamento de dados confidenciais, como credenciais, PII e informações de cartões de crédito.

Invasores podem explorar configurações por meio de portas de rede abertas, limites de taxa irrestritos ou dados não criptografados em trânsito ou em repouso. Depois, podem tirar proveito dessas configurações incorretas para obter acesso não autorizado, roubar dados confidenciais ou interromper serviços.

Configurações incorretas também podem surgir de forma menos visível ao longo do tempo por causa do desvio de configuração, que ocorre quando as mudanças na infraestrutura não são documentadas nem gerenciadas corretamente. Por exemplo, talvez você aplique patches no sistema sem registrar as mudanças, ou engenheiros façam login para investigar problemas, alterem configurações manualmente e se esqueçam de revertê-las. Essas ações dificultam a identificação e a correção de riscos potenciais que não aparecem no template de IaC, deixando o sistema exposto a ameaças.

Os templates de IaC ajudam a reduzir alguns desses riscos por meio da automação e do controle de versão, mas não resolvem tudo. É frustrante esperar muito tempo pela implantação de um template de IaC e descobrir que ela falhou por causa de um erro de permissões. Pode dar vontade de usar uma política com acesso total para resolver o problema, mas esse atalho cria configurações incorretas que poderiam ser evitadas.

Para garantir um controle de acesso adequado, siga sempre o princípio do menor privilégio (PoLP) e limite as permissões ao máximo. Conceda acesso apenas quando necessário, usando políticas de controle definidas com rigor, chaves com rotação automática e funções de acesso temporário.

Ferramentas de auditoria de segurança, como Snyk Infrastructure as Code e Snyk Container, também podem ajudar a analisar e monitorar a infraestrutura, automatizando o processo e facilitando a manutenção de configurações seguras e políticas de acesso.

4. Arquivos de estado inseguros

Como a maioria dos frameworks de IaC gera arquivos de estado para registrar o estado atual da infraestrutura implantada, é fundamental mantê-los seguros e sincronizados com o estado real da nuvem. Arquivos de estado em texto simples podem conter informações detalhadas sobre a segurança dos recursos na nuvem. A única forma de proteger essas informações é criptografar o arquivo de estado e proteger o acesso a ele.

Se perdermos esse arquivo de estado, deixamos de ter um registro do estado da infraestrutura implantada com os templates ou o código de IaC. Essa perda exigiria importar manualmente os recursos existentes na nuvem de volta para o arquivo de estado persistente, para que o gerenciamento futuro da IaC não fosse afetado.

Se a IaC for gerenciada em um pipeline automatizado de CI/CD, a perda do arquivo de estado poderá resultar na destruição ou criação de recursos, causando indisponibilidade do sistema ou perda de dados. Da mesma forma, um arquivo de estado corrompido ou fora de sincronia pode virar uma bagunça rapidamente quando os recursos precisam ser mapeados manualmente e tudo precisa ser reconstruído.

Podemos evitar essa situação com algumas precauções simples:

• Armazene o arquivo de estado remotamente na nuvem para facilitar o compartilhamento e o backup.

• Ative o controle de versões para recuperá-lo caso o arquivo seja corrompido.

• Use um mecanismo de bloqueio de arquivo para que apenas uma pessoa possa implantar e alterar o arquivo de estado por vez.

• Criptografe o arquivo ao armazená-lo para impedir que um invasor o descriptografe, mesmo que consiga acessá-lo.

• Restrinja o acesso ao arquivo de estado para que apenas a equipe possa acessá-lo. Mesmo quando os segredos são armazenados com segurança e ficam fora dos templates de IaC, eles podem aparecer em texto simples nos arquivos de estado. Por isso, é essencial criptografar esses arquivos e limitar o acesso para evitar o vazamento de segredos.

5. Falta de testes e validação

Templates de IaC que não são testados e validados minuciosamente podem resultar em implantações inseguras ou configurações incorretas, permitindo que invasores comprometam a infraestrutura.

Ao integrar testes e validação ao fluxo de desenvolvimento de IaC, podemos identificar, reduzir e minimizar riscos desde o início e proteger nossa infraestrutura de forma proativa.

Ao testar e validar IaC, considere as seguintes perguntas:

• O template de IaC foi implantado com sucesso?

• Os controles de acesso e as configurações correspondem ao código?

• Os recursos foram mapeados e referenciados corretamente?

• A atividade do servidor é monitorada e registrada corretamente?

• A infraestrutura consegue lidar com o volume de tráfego necessário?

As práticas recomendadas para testar e validar IaC seguem os mesmos princípios gerais aplicáveis a todo código. Implemente um processo de revisão de código na equipe. Teste o código em um ambiente de homologação antes de implantá-lo em produção. Use ferramentas de lint para detectar erros de sintaxe e formatação e escreva testes unitários — por exemplo, para verificar nomes ou identificadores de recursos. Analise código de IaC de alto nível, gerado por ferramentas como Pulumi, com ferramentas automatizadas de teste estático de segurança de aplicações (SAST), como Snyk Code.

Em última análise, a melhor maneira de desenvolver, testar e validar IaC com segurança é integrar a segurança ao processo de desenvolvimento. Uma forma de fazer isso é com Snyk Infrastructure as Code, uma ferramenta especializada para aprimorar os testes e a validação de IaC. Ela se integra perfeitamente às ferramentas e aos fluxos de trabalho de desenvolvimento, permitindo desenvolver IaC com segurança de forma contínua e em tempo real.

Snyk Infrastructure as Code analisa o código em busca de possíveis configurações incorretas ou violações de políticas e oferece informações práticas e recomendações para corrigir os problemas encontrados. Podemos usar essas informações para melhorar a postura geral de segurança da nossa IaC e garantir a conformidade.

Conclusão

Neste artigo, exploramos cinco preocupações de segurança ao usar IaC. Também vimos como lidar com elas, seguindo o princípio do menor privilégio, adotando práticas de codificação segura e integrando ferramentas de segurança ao processo.

Não dá para subestimar a importância de adotar práticas recomendadas para manter a IaC segura — especialmente diante das possíveis consequências de uma IaC insegura. Ao negligenciar questões como credenciais codificadas diretamente, segredos mal gerenciados e desvio de configuração, corremos o risco de anular os benefícios da IaC e provocar possíveis violações de dados, acessos não autorizados e interrupções de serviços essenciais.

Ao integrar a segurança de forma proativa ao processo de desenvolvimento de IaC e adotar práticas recomendadas, podemos reduzir riscos com eficácia, proteger nossa infraestrutura e resguardar nossos negócios e clientes.