Como proteger ferramentas de Infraestrutura como Código?

Como o nome indica, Infraestrutura como Código (IaC) é a prática de definir como código e arquivos de configuração a infraestrutura na qual suas aplicações são executadas. Isso nos permite não apenas automatizar o provisionamento dos recursos, mas também submetê-los aos mesmos processos de ciclo de vida que, historicamente, eram aplicados apenas à base de código da aplicação. Se você está começando com IaC, confira este artigo, no qual explicamos o que é Infraestrutura como Código (IaC) e quais são as implicações de segurança do seu uso no mundo real.

Há muitas ferramentas de automação de infraestrutura para implementar IaC. Muitas são oferecidas por provedores de nuvem pública, como o CloudFormation da Amazon Web Services e o Resource Manager (ARM) do Azure, além de projetos compatíveis com várias plataformas de infraestrutura, como Hashicorp Terraform e Pulumi.

Essas ferramentas de IaC baseadas em linguagens declarativas são ideais para técnicas de análise estática, que permitem detectar e corrigir problemas de segurança com mais eficácia antes mesmo de a infraestrutura definida ser implantada. As práticas recomendadas de segurança para IaC estão em constante evolução. Ao desenvolvermos o produto Snyk IaC, buscamos facilitar ao máximo a adoção de IaC pelas organizações, ajudando os desenvolvedores não apenas a identificar problemas, mas também a entender seu contexto e como corrigi-los.

Vamos conhecer algumas das ferramentas populares de Infraestrutura como Código e as medidas de segurança que você pode aplicar no código para proteger suas aplicações e plataformas.

Ferramentas de Infraestrutura como Código

Soluções oferecidas por provedores de nuvem

AWS CloudFormation, Azure Resource Manager (ARM), e Google Deployment Manager (GDM)Todos os principais provedores de nuvem criam suas próprias ferramentas de IaC para automatizar o provisionamento de infraestrutura. Elas definem declarativamente o estado desejado das implantações usando modelos JSON ou YAML. No caso do Google Deployment Manager, também é possível usar Jinja e Python.

Amazon Cloud Development Kit (CDK)Lançado em 2019, o Amazon Cloud Development Kit (CDK) permite que desenvolvedores definam implantações usando linguagens de programação de alto nível, como JavaScript, Python ou C# (veja a lista completa de linguagens aqui). Além de oferecer uma sintaxe mais familiar, ele permite a integração com IDEs e o empacotamento de padrões em bibliotecas reutilizáveis e estruturas de código testadas, sem depender de copiar e colar JSON/YAML entre projetos. O CDK gera JSON do CloudFormation. Assim, a Amazon oferece um ambiente voltado para desenvolvedores que ainda aproveita sua ferramenta de orquestração de infraestrutura CloudFormation, testada em larga escala.

Soluções para várias nuvens

Hashicorp TerraformO Terraform é uma ferramenta de provisionamento automatizado que pode provisionar e configurar uma grande variedade de plataformas e produtos por meio de plugins de provedores.

PulumiO Pulumi é um projeto de IaC de código aberto que oferece SDKs em várias linguagens de programação para provisionar e gerenciar recursos em diversas plataformas.

Problemas que merecem atenção e exemplos de análise

Independentemente do provedor de nuvem ou da ferramenta de IaC escolhida, há alguns pontos comuns que merecem atenção do ponto de vista da segurança. Vamos analisar alguns deles com exemplos usando Terraform e AWS. Todos esses exemplos estão neste repositório do GitHub. Também incluí capturas de tela que mostram como a ferramenta Snyk IaC apresenta os possíveis problemas encontrados.

Credenciais

No diretório principal do nosso repositório Git, há um arquivo main.tf com vários problemas comuns. A análise da Snyk aponta um problema de alta gravidade e cinco de gravidade média, como mostra a imagem abaixo.

Em primeiro lugar, nunca inclua credenciais de qualquer tipo no controle de versão. Parece óbvio, mas fóruns na internet estão repletos de exemplos de repositórios de código que contêm credenciais — muitos deles públicos! Infelizmente, muitos desses exemplos só foram descobertos depois de serem explorados. Isso costuma acontecer quando alguém inclui o arquivo por engano. Uma situação especialmente traiçoeira ocorre quando uma credencial é incluída e depois removida em um commit posterior: o desenvolvedor pode não perceber, mas ela continua no histórico do repositório. Há técnicas para detectar esse problema, como usar arquivos .gitignore ou scripts de hook de pré-commit, por exemplo, o “git-secrets” do AWS Labs.

Também encontramos vários problemas relacionados às senhas de contas do IAM. É importante observar que há uma política por conta da AWS e que, ao configurar uma, você substituirá a política padrão fornecida pela Amazon. Por isso, especifique todas essas opções.

Criptografia em serviços de armazenamento

Por padrão, os volumes EBS têm a criptografia ativada, mas os buckets do S3 não. É importante verificar ambos para garantir a conformidade com as políticas da sua empresa e as diretrizes regulatórias aplicáveis. No nosso repositório de demonstração, declaramos alguns recursos de armazenamento no arquivo modules/storage/main.tf, que você pode ver sendo analisado abaixo:

Aqui, vemos exemplos das duas violações sinalizadas, além de um aviso de prioridade mais baixa sobre a ausência de logs de acesso ao servidor do S3. Ao abrir um desses alertas, você encontra detalhes sobre o problema, seu impacto e uma recomendação de como resolvê-lo.

A classificação de gravidade alta, média ou baixa de cada política pode ser alterada para corresponder às políticas da sua organização.

Faixas de entrada e saída de grupos de segurança e firewalls

No arquivo modules/vpc/main.tf, encontramos outro problema comum: o acesso de entrada foi configurado de forma mais abrangente do que provavelmente deveria.

Assim como no caso das credenciais codificadas, isso costuma acontecer durante o desenvolvimento ou a resolução de problemas e acaba sendo incluído por engano no controle de versão junto com outras alterações. Neste exemplo, é muito improvável que alguém realmente queira abrir a porta 22 para toda a internet — mas é isso que pode estar acontecendo. É fundamental restringir o tráfego de entrada e saída das suas redes e permitir acesso apenas às faixas de IP que realmente precisam dele.

Rotação de chaves

No nosso último exemplo, temos o arquivo modules/pki/main.tf, em que uma chave foi configurada sem rotação.

Este é outro caso em que o comportamento padrão muitas vezes não é o mais adequado do ponto de vista do fortalecimento da segurança. É claro que essa recomendação pressupõe que sua organização não tenha um processo separado para rotacionar chaves. Mas, se você usa o serviço de gerenciamento de chaves do provedor de nuvem, é bem provável que a melhor opção seja deixar essa tarefa a cargo dele.

Quão seguras são suas iniciativas de IaC?

Agora que você viu alguns exemplos de problemas que podem passar despercebidos com facilidade no código de IaC, quanto você confia na segurança do seu? Lembre-se: segurança não deve ser deixada para depois. Você pode executar essas mesmas verificações — além de outras para provedores de nuvem e Kubernetes — no seu repositório agora mesmo, gratuitamente, e identificar problemas antes que sejam implantados ou explorados.

Crie uma conta gratuita na Snyk e siga as instruções para criar um projeto a partir do seu repositório. Em poucos minutos, você receberá recomendações práticas para corrigir os problemas encontrados.