Se tem algo que merece a sua atenção é formas de aumentar a segurança de um processo, ainda mais algo tão estratégico como infraestrutura. Por isso, hoje eu gostaria de falar não só sobre o conceito de Infraestrutura como código (IaC), mas também de algumas práticas ruins de segurança que você pode evitar – e manter sua operação segura.
Como chegamos na Infraestrutura como código (IaC)
Ao longo do processo de desenvolvimento de software, times de infraestrutura precisam trabalhar para garantir que as soluções criadas sejam disponibilizadas em ambientes de produção atualizados e seguros.
Para tal, estes times de infraestrutura realizam tarefas como:
- configuração de contas e perfis de acesso;
- instalação pacotes das dependências necessárias para que o software funcione apropriadamente, ou
- configuração de sistemas de monitoramento do software e de seus usuários.
Durante algum bom tempo, times de infraestrutura criavam scripts em BASH/Perl/etc para automatizar essas tarefas. No entanto, com o crescimento e disponibilidade de sistemas de cloud, a execução desses scripts se tornou uma tarefa manual, ou seja, demorada, além de ser propensa a erros.
Imagine ter que executar um script escrito em BASH em centenas (ou milhares) de instâncias da AWS? Precisaríamos ter que logar em cada instância, enviar o script para cada uma delas, alterar a permissão de execução do script, para só depois executá-lo.
Infraestrutura como Código (IaC): o que é e sua relevância
Antes de avançar, é importante trazer o conceito.
Infraestrutura como código (do Inglês, Infrastructure as code, ou simplesmente IaC) é o processo de gerenciar e provisionar infraestrutura por meio de código, em vez de fazê-lo manualmente. Por isso, boas práticas de código, da escrita à segurança, são tão importantes.
Scripts de infraestrutura como código surgiram em parte como forma de minimizar o esforço de criação e manutenção das tarefas de infraestrutura. Com scripts de IaC, a execução de um único script pode refletir em centenas (ou milhares) de instâncias de um servidor de nuvem.
De acordo com um relatório de 2019 da RightScale, que conduziu um questionário online com 786 praticantes da indústria de software, 84% mencionaram que utilizam uma estratégia de multi-cloud, ou seja, utilizam de variados serviços de nuvem de diferentes fornecedores, como forma de otimizar os recursos e custos de infraestrutura.
O uso de scripts de infraestrutura é comum em diversas empresas de tecnologia. Em um relatório de 2015, empresas como a Intercontinental Exchange (ICE) afirmam que utilizam scripts de infraestrutura para manter 75% do seu ambiente de desenvolvimento, composto por 20.000 servidores. Nesse mesmo relatório, foi observado que a utilização de scripts de infraestrutura tornou a ICE capaz de diminuir o tempo necessário para provisionar ambientes de desenvolvimento de 1 a 2 dias para 21 minutos.
Ferramentas para Infraestrutura como Código
Na atualidade, há um número significativo de ferramentas que possibilitam a criação de scripts de infraestrutura como código. Dentre as que se destacam estão, por exemplo:
- Ansible;
- Chef;
- Puppet;
- SaltStack;
- Terraform.
De acordo com o mesmo relatório de 2019, Ansible aparece como a ferramenta mais popular para implementação de scripts de IaC. Quando comparado ao mesmo relatório de 2018, Ansible subiu de 36% de adoção para 41% em 2019. No mesmo período, Terraform subiu de 20% de adoção para 31%.
Essas ferramentas fornecem construções de linguagem de programação, como uma sintaxe bem definida e gerenciamento de dependências, de forma que times de infraestrutura (ou de desenvolvimento) possam descrever as tarefas de provisionamento em forma de scripts.
Scripts de IaC como cidadãos de primeiro nível
Os códigos desses scripts, por sua vez, são tratados como cidadãos de primeiro nível, ou seja, passam pelo mesmo controle de qualidade de um código escrito em uma linguagem de programação qualquer. Isso significa que scripts de infraestrutura devem ser mantidos, testados, revisados, depurados, etc.
De forma análoga, scripts de infraestrutura como código, também podem apresentar bugs ou expor brechas de segurança. Uma vez que aplicações de software modernas precisam se comunicar com diferentes (micro-)serviços, uma senha hard-coded em um script de IaC pode ser a cereja do bolo para um usuário malicioso.
Em um cenário em que multi-cloud passa a ser comum, a preocupação com a segurança dos serviços se torna ainda mais relevante.
Mas como podemos fazer para que nossos scripts sejam menos vulneráveis a práticas ruins de segurança? Ou melhor, quais seriam essas práticas e como podemos identificá-las?
8 práticas ruins de segurança em scripts de Infraestrutura como Código
A dupla de pesquisa, Akond Rahman e Laurie Williams, conduziu uma série de estudos empíricos (em parceria com outras pessoas ou não) sobre práticas ruins de segurança em scripts de IaC, por exemplo:
- Security Smells in Ansible and Chef Scripts: A Replication Study
- The Seven Sins: Security Smells in Infrastructure as Code Scripts
- A Different Kind of Smell: Security Smells in Infrastructure as Code Scripts
- The ‘as code’ activities: development anti-patterns for infrastructure as code
Inclusive, aqui no blog da Zup a gente também já falou um pouco sobre estudos empíricos de Engenharia de Software.
Nesses estudos, foram analisados mais de 50.000 scripts de infraestrutura como código, criados em mais de 800 repositórios de projetos de código fonte aberto, disponibilizados em plataformas como GitHub, OpenStack, Mozilla, dentre outros.
Após um extensivo trabalho qualitativo de análise desses scripts, chegaram a um pequeno conjunto de oito práticas ruins de segurança em scripts de IaC que devem ser evitadas.
Importante notar que estas práticas são chamadas de “más práticas”, em vez de “brechas de segurança”. Isso porque as más práticas indicam uma fraqueza de segurança nos scripts (que merecem atenção do time de desenvolvimento e infraestrutura), embora não necessariamente levem a brechas de segurança (que podem interromper a execução do programa).
Vamos conhecer essas oito práticas ruins em detalhes a seguir, através de exemplos de scripts IaC escritos em Puppet.
1 – Admin by default
Admin by default, ou administrador por padrão em português, acontece quando se fornece acesso de administrador para usuários comuns.
Isso vai totalmente contra o princípio do menor privilégio, que sugere que times de desenvolvimento e infraestrutura desenhem sistemas de uma maneira que o menor acesso seja fornecido a uma entidade.
2 – Empty password
Empty password, ou senha em branco em português, refere-se a deixar o campo de senha sem preenchimento. Isso indica a utilização de uma senha fraca (ou seja, que pode ser chutada).
Uma senha em branco é diferente de não usar senhas (como no caso de autenticações baseadas em chaves públicas e privadas). Uma parte de um script IaC escrito em Puppet com essa prática ruim é apresentada a seguir.
'RedHat': {
user {
name => 'admin-user',
password => ''
}
}
3 – Hard-coded secret
Nesse caso, códigos de IaC deixam informações sensíveis hard-coded (codificação rígida), como nome de usuário e senha, no corpo do script.
Essa prática ruim pode ser observada no exemplo abaixo, bem como a “Admin by default” (pois o login seria feito com o usuário administrador).
class ('example'
$power_username= 'admin',
$power_password= 'admin'
) { ... }
4 – Invalid IP address
Invalid IP address, ou endereço de IP inválido em português, refere-se a utilização de um endereço 0.0.0.0 para um serviço de cloud externo, como no exemplo a seguir.
Isto é uma prática ruim, pois pode possibilitar que este endereço receba conexões de qualquer rede.
$bind_host = '0.0.0.0'5 – Suspicious comment
Suspicious comment, ou comentário suspeito em português, se refere a documentar (através de tags como TODO ou FIXME, por exemplo) a presença de defeitos (ou falta de funcionalidades) nos scripts de IaC.
6 – HTTP without TLS
Utilizar HTTP (sem o TLS) para conectar com outros serviços torna as duas pontas menos seguras, uma vez que o HTTP é suscetível a diversos tipos de ataques.
Um exemplo dessa prática ruim abaixo.
$auth_url = 'http://127.0.0.1:35357/v2.0'7 – Weak cryptography algorithms
Está relacionado à utilização de algoritmos fracos de criptografia (tradução do título da prática ruim), como MD5 ou SHA-1.
Outro exemplo a seguir.
'Debian': {
user {
name => ‘admin-user’ ,
password => ht_md5($power_password)
}
}
8 – No integrity check
Essa prática ruim está relacionada a baixar dados de um repositório sem fazer testes de integridade (tradução do título da prática ruim), por meio da assinatura gpg ou checksums.
O quão comum são essas práticas ruins?
Para avaliar a prevalência dessas práticas ruins de segurança em scripts de IaC, a dupla de pesquisa desenvolveu um conjunto de ferramentas que fazem análise estática dos scripts, de forma a buscar ocorrências delas.
Ao rodar essa análise nos mais de 50 mil scripts de IaC escritos, foi observado mais de uma ocorrência por script.
A prática ruim mais observada foi a “Hard-coded secret”, que correspondeu a cerca de 70% das ocorrências. Em segundo lugar ficou “Suspicious comment”, com cerca de 9% de ocorrências.
Conclusão
Com esse trabalho, foi observado que as más práticas não somente acontecem em scripts de IaC, como também acontecem com bastante frequência.
Como forma de reduzir a incidência dessas más práticas, é preciso primeiro conhecê-las.
Quer conhecer mais dicas de segurança para infraestrutura como código? Então assista a essa live feita no TDC Innovation, que aconteceu de 23 a 25 de março de 2021, sobre “Proteção de pipeline DevOps e IaC” com o Fernando Cardoso.
E você, tem mais dicas para aumentar a segurança ao trabalhar com infraestrutura como código? Então conta para a gente nos comentários!
