Automatizando a segurança do Terraform em implantações do Scalr com Regula [Tutorial]

Introdução à integração entre Regula e Scalr

Regula

Regula permite que equipes de nuvem avaliem Terraform, CloudFormation, Azure Resource Manager e Infrastructure as Code (IaC) do Kubernetes em busca de violações de segurança e conformidade antes da implantação. Regula é uma implementação de código aberto do Rego, a linguagem de consulta usada pelo projeto Open Policy Agent (OPA). Quando aplicável, as políticas do Regula foram mapeadas para os benchmarks do Center for Internet Security (CIS) para Amazon Web Services (AWS), Azure, Google Cloud e Kubernetes Foundation, permitindo que os usuários apliquem essas políticas à IaC antes da implantação.

A capacidade do Regula de analisar IaC em busca de configurações incorretas antes da implantação estende a responsabilidade pela segurança e conformidade na nuvem às equipes de desenvolvimento de uma forma acessível para desenvolvedores, eliminando assim o gargalo de segurança ao implantar infraestrutura na nuvem com IaC. O Regula é mantido por engenheiros da Fugue.

Scalr

Scalr é um software de automação e colaboração para Terraform (TACO) que oferece suporte à automação de pull requests, à CLI nativa do Terraform e a fluxos de trabalho orientados por módulos. O Scalr ajuda organizações de todos os tamanhos a crescer por meio de seu modelo hierárquico, que centraliza operações administrativas como RBAC, controle de políticas com OPA, visualizações operacionais e um registro privado de módulos. Isso permite descentralizar as operações do Terraform de forma controlada, para que desenvolvedores executem fluxos de trabalho do Terraform de maneira independente em seus ambientes.

Objetivo

Combinar os recursos práticos e avançados de análise de IaC do Regula com os recursos de automação e colaboração para Terraform do Scalr, demonstrando como as organizações podem automatizar a implantação segura de infraestrutura na nuvem com Terraform.

Pré-requisitos

Para acompanhar o tutorial, você precisará de:

• Uma conta do Scalr com ganchos personalizados habilitados (observação: esse é um recurso pago). Veja abaixo como configurá-los.

• Um workspace configurado na sua conta do Scalr. É no workspace que todos os objetos relacionados aos recursos gerenciados pelo Terraform são armazenados e administrados.

• Credenciais do provedor de nuvem adicionadas à sua conta do Scalr (nesta demonstração, usarei a AWS).

• Um provedor de sistema de controle de versão (VCS) configurado na sua conta do Scalr (nesta demonstração, usarei o GitHub).

• Atribua scripts/security.bash como gancho personalizado “Before plan” e scripts/validate.bash como gancho personalizado “After plan”.

• A versão mais recente do Regula no diretório /usr/local/bin (nosso script security.bash fará o download e o executará no pipeline do Scalr, mas tê-lo instalado localmente permite avaliar o código antes de enviá-lo).

Se quiser poupar trabalho, você também pode clonar meu repositório executando o seguinte comando no Terminal:

git clone https://github.com/fugue/fugue-scalr-integration.git

O que há no repositório?

A imagem acima mostra visualmente a estrutura de arquivos do meu repositório, que inclui, entre outros:

• main.tf: um arquivo Terraform que declara informações sobre provedores e módulos.

• s3/: um subdiretório com arquivos Terraform que contêm vulnerabilidades intencionais.

• waivers.rego: um arquivo que isenta e desabilita regras selecionadas.

• .regula.yaml: um arquivo de configuração do Regula que declara como quero executá-lo neste repositório.

• scripts/: um subdiretório que contém o gancho personalizado descrito acima.

Veja uma visão mais detalhada do conteúdo do módulo S3, com uma sobreposição que mostra o status de configuração de toda a infraestrutura (as violações dos benchmarks CIS aparecem em vermelho):

Configurando ganchos personalizados do Scalr

Os ganchos personalizados permitem ajustar o fluxo de trabalho principal do Terraform com comandos, scripts e chamadas de API. Além de usar o Regula para analisar segurança e conformidade, os scripts de shell desta demonstração também verificam a formatação e a validação do Terraform.

Os ganchos personalizados podem ser adicionados ao criar um workspace ou a qualquer momento depois, nas configurações do workspace. Basta especificar o que deve ser executado antes e depois de plan e antes e depois de apply. Veja abaixo uma demonstração de como configurar ganchos personalizados:

Nas opções “Advanced” da página “Settings”, o Scalr permite que os usuários escolham o caminho relativo em que os comandos do Terraform serão executados (neste exemplo, selecionei o diretório s3/). Por isso, o caminho para os scripts começa com “./../”.

Automatizando verificações de segurança sem obstáculos

O caminho de menor resistência para chegar à nuvem por meio de IaC leva tanto iniciantes quanto especialistas a usar código Terraform encontrado na internet ou compartilhado entre colegas e equipes, partindo do pressuposto de que ele é seguro e está em conformidade. Esse código pode passar por todas as verificações disponíveis de formatação, lint e validação, mas ainda expor quem o usa a vulnerabilidades potencialmente devastadoras.

Revelando vulnerabilidades ocultas: analisando a infraestrutura com Regula

Nesta demonstração, segui deliberadamente esse caminho de menor resistência e procurei código Terraform que me permitisse implantar um bucket do S3 o mais rápido possível. Primeiro, vou mostrar como esse código Terraform é vulnerável executando regula run localmente neste repositório:

Ao executar esse comando, o Regula:

• detecta automaticamente os arquivos IaC compatíveis em todo o repositório;

• executa uma análise de segurança e conformidade em todos os arquivos IaC compatíveis detectados;

• exibe os resultados da análise em ordem decrescente de gravidade, com as seguintes informações:

  • ID e título da regra da Fugue (por exemplo, FG_R00099).

  • Gravidade da regra (por exemplo, [High]).

  • Link para as etapas de correção da regra (por exemplo, https://docs.fugue.co/FG_R00099.html).

  • Local da violação da regra, indicado por arquivo IaC.

Os resultados da análise acima devem preocupar tanto profissionais de DevOps quanto engenheiros de segurança. Ao copiar, colar e implantar código vulnerável, ficamos expostos a hackers que usam automação para detectar e explorar essas vulnerabilidades. Além disso, fiz essa análise voluntariamente sem integrá-la a um pipeline (como o do Scalr) — não exatamente o caminho de menor resistência! Violações anteriores nos ensinam que hackers da nuvem encontram vulnerabilidades com automação e depois as usam (como um bucket S3 vulnerável) como ponto de entrada para atacar a infraestrutura e os dados que mais precisam ser protegidos. Não usar uma automação semelhante para configurar corretamente os recursos antes que cheguem à nuvem faz com que esses ataques sejam uma questão de “quando”, e não de “se”.

Vamos analisar mais de perto essas violações de regras examinando um trecho do código (se estiver acompanhando, o código abaixo está nas linhas 18 a 26 de s3/bucket.tf, com a indentação deslocada para a esquerda para facilitar a leitura):

18server_side_encryption_configuration {
19  rule {
20    apply_server_side_encryption_by_default {
21      #Un-comment below to satisfy FG_R00099
22      #kms_master_key_id = aws_kms_key.mykey.arn
23      #sse_algorithm     = "aws:kms"
24    }
25  }
26}

Associei as vulnerabilidades intencionais neste código a comentários que indicam como revisá-lo para cumprir as regras numeradas incluídas por padrão no Regula. Da forma como está, o código acima viola a regra FG_R00099 (uma violação de alta gravidade segundo os benchmarks CIS): se for implantado sem as correções necessárias, esse bucket do Amazon Simple Storage Service (S3) exporá os dados armazenados. Para quem está começando e lê esta publicação, seria como deixar aberta a porta de um cofre de banco e de um cofre para guardar objetos de valor. Mesmo que você fizesse seu depósito em um carro-forte (criptografia em trânsito, nesta analogia), não trancar o cofre e o compartimento para guardar objetos de valor (aplicar criptografia no servidor) poderia tornar inúteis essas tentativas de proteger os dados.

O mais preocupante neste exemplo é que a documentação do Terraform da qual extraí esse código explica como implantar um bucket S3 da forma mais simples possível (como costuma acontecer com a documentação), dando prioridade a exemplos de parâmetros obrigatórios e deixando parâmetros opcionais (entre eles, a criptografia no servidor!) para partes posteriores da documentação, que podem passar facilmente despercebidas. Afinal, a configuração dos seus recursos na nuvem é sua responsabilidade: o provedor de nuvem apenas oferece os meios para que você implante e use a infraestrutura na nuvem com segurança.

Por que deixar a segurança ao acaso, se você pode automatizá-la com tanta facilidade?

Flexibilidade na prática: isentando e desabilitando regras

Às vezes, necessidades críticas do negócio entram em conflito com regras de gravidade baixa e média. Por exemplo, uma empresa que depende da entrega de conteúdo por meio de um bucket S3 que hospeda um site estático acabaria se cansando de ver esse bucket violando a regra FG_R00229 (os buckets S3 devem ter todas as opções de “block public access” habilitadas). Os usuários do Regula podem isentar recursos específicos de regras específicas ou desabilitar algumas regras por completo. Nesta demonstração, decidi isentar meu bucket de logs da regra FG_R00274 e desabilitar por completo a regra FG_R00275 da Fugue usando meu documento de isenções (waivers.rego). Veja abaixo como é simples isentar e desabilitar regras no Regula:

package fugue.regula.config

waivers[waiver] {
  waiver := {
    #Waiving bucket logging (for the logging bucket)
    "rule_id": "FG_R00274",
    "resource_id": "module.s3.aws_s3_bucket.logbucket"
  }
}

rules[rule] {
  rule := {
    #Disabling cross region replication (budgetary purposes)
    "rule_id": "FG_R00275",
    "status": "DISABLED"
  }
}

Colocando a segurança de IaC em prática: impedindo que configurações incorretas cheguem à nuvem

Agora vamos ver como o Regula se integra ao backend de estado remoto e operações do Terraform do Scalr para impedir que infraestrutura configurada incorretamente seja implantada na nuvem.

O primeiro script de gancho personalizado (security.bash) baixa, extrai e move a versão mais recente do Regula e a executa para analisar todos os arquivos Terraform (arquivos na linguagem HashiCorp (HCL) ou planos em Terraform JavaScript Object Notation (JSON)). Em seguida, retorna um código de saída diferente de zero e uma mensagem que interrompem a compilação do Scalr, ou um código de saída zero, que permite que ela continue.

O próximo script de gancho personalizado (validate.bash) garante que o Terraform deste repositório seja válido e esteja formatado corretamente segundo os padrões canônicos de HCL. Se o Terraform não for válido, o script retorna um código de saída diferente de zero. Se for válido, o Scalr executa o restante da compilação, executando automaticamente terraform plan e terraform apply. Assim, sua infraestrutura é implantada na nuvem, e o estado do Terraform é mantido na interface fácil de usar do Scalr.

Tentando uma compilação (e falhando)

Agora vou mostrar o que acontece quando envio código Terraform vulnerável ao meu repositório do GitHub. Começo executando os seguintes comandos (<files> é um espaço reservado para os arquivos que devem ser confirmados e enviados ao GitHub):

git add <files>
git commit -m "initiating the scalr terraform pipeline"
git push

O Scalr detectará que confirmei alterações no meu repositório e usará os scripts que forneci para analisar meu Terraform em busca de problemas de segurança e conformidade:

Corrigindo problemas de configuração com Regula

Agora que sei que há configurações incorretas nos meus arquivos Terraform, posso voltar ao repositório no VSCode e executar regula run localmente para corrigir os problemas (ou, se preferir, posso exportar a saída de regula run executado no Scalr). Configurei este repositório para facilitar a reativação dos comentários no código com minhas correções do Terraform, mas configurar sua infraestrutura corretamente é tão simples quanto clicar no link que aparece para cada regra após executar regula run. Repare que as duas regras que estou corrigindo (FG_R00036 e FG_R00101) correspondem a apenas uma linha de código cada. Essas linhas são extraídas diretamente das etapas de correção da regra, disponíveis no link incluído na saída deste comando. É difícil encontrar algo mais simples para desenvolvedores.

Tentando uma compilação (e conseguindo!)

Com minha infraestrutura configurada corretamente, vou enviar novamente as alterações ao meu repositório do GitHub para aproveitar ao máximo os recursos de automação do Terraform do Scalr. Isso executará mais uma vez meus scripts de gancho personalizado e, se forem bem-sucedidos, o Scalr executará terraform plan e terraform apply.

Para demonstrar isso, vou executar novamente os comandos que rodei no início:

git add <files>
git commit -m "initiating the scalr terraform pipeline"
git push

...resultando em uma build bem-sucedida!

E pronto! Com Regula e Scalr, agora temos um pipeline para automatizar com segurança a implantação de infraestrutura na nuvem usando Terraform.

Próximas etapas

O exemplo acima mostra como proteger sua IaC de acordo com os CIS Benchmarks. Mas, se você precisa atender a outros padrões de conformidade, como HIPAA, SOC 2, ISO 27001, NIST 800-53, GDPR, PCI DSS, AWS WAF ou CSA, acesse www.fugue.co. O exemplo também mostra hooks personalizados (um recurso pago do Scalr). Se você precisa de recursos que facilitam o dia a dia, como estimativa de custos de infraestrutura na nuvem, agentes auto-hospedados, SSO ou pré-visualizações de políticas, acesse https://www.scalr.com/.

Quer saber mais sobre Regula? Acesse nosso repositório no GitHub e a documentação. Regula avalia Terraform HCL, JSON de planos do Terraform, YAML/JSON do CloudFormation, manifests YAML do Kubernetes e templates do Azure Resource Manager para identificar problemas de segurança e conformidade. Regula também oferece suporte a isenções, regras personalizadas, ativação e desativação de regras, entre outros recursos.

Quer conhecer outras formas de automatizar a implantação segura de infraestrutura na nuvem? Confira nosso post sobre a integração do Regula com o Travis CI ou nosso post sobre a integração do Regula com o Bitbucket Pipelines.