O dilema do uso de Infrastructure as Code (IaC) para a Segurança de Aplicações

Construir aplicações seguras vai muito além de construir apenas código seguro. Quando falamos de cibersegurança, alguns dos conceitos mais importantes a serem considerados são os de “Defesa em Profundidade” e “Redução da Superfície de Ataque”.

Se fizermos analogia a uma residência para facilitar a compreensão desses conceitos, defesa em profundidade seria como adicionar barreiras que dificultem a ação de um invasor. Por exemplo, subir a altura dos muros, colocar cercas elétricas, trocar o cadeado por um mais forte, colocar grades nas janelas, etc.

No caso da redução da superfície de ataque, podemos exemplificar como a ação de reduzir os pontos expostos que poderiam ser explorados por um agente mal-intencionado. Seria algo como guardar o carro na garagem ou guardar o cortador de grama e a bicicleta que estavam no quintal para evitar que sejam roubados.

Mas o que é IaC (Infrastructure as Code) e o que ela tem a ver com esses conceitos? Mais ainda, como ela pode te ajudar — ou não — a construir e entregar software de uma forma mais segura?

Infrastructure as Code (IaC) + AppSec

Infrastructure as a Code (IaC) é uma prática na qual a infraestrutura é descrita e gerenciada como código. São scripts que podem ser escritos em linguagem de fácil entendimento que permitem referir-se a recursos remotos e montá-los como um quebra-cabeça automaticamente em vez de que se faça isso manualmente.

Com ela, é possível criar e destruir ambientes completos de servidores, interfaces de rede, conexões, regras de acesso e fluxos de informações com poucos comandos em questão de poucos minutos.

A segurança de aplicações (AppSec) é o conceito que trata sobre como garantir que as aplicações sejam pensadas, planejadas, construídas e entregues de forma segura, identificando e mitigando possíveis ameaças e vulnerabilidades desde a fase inicial.

A IaC pode aprimorar muito o ciclo de vida de desenvolvimento de software seguro (S-SDLC) de várias maneiras.

Por exemplo:

• Agilizam o processo de desenvolvimento e reduzem erros manuais, permitindo que os desenvolvedores se concentrem em tarefas mais importantes, como segurança;

• Podem ser auditados e controlados, facilitando a garantia de que as políticas de segurança e conformidade estão sendo seguidas consistentemente em todo o ciclo de desenvolvimento;

• Permitem a criação e replicação de infraestruturas consistentes, que podem ser usadas para configurar rapidamente novos ambientes para teste e desenvolvimento, reduzindo o risco de configurações incorretas;

• Possibilitam integração a pipelines CI/CD, facilitando a implantação de aplicações e atualizações de maneira segura e consistente;

• Podem fornecer maior visibilidade no processo de desenvolvimento, facilitando o rastreamento de alterações e a identificação de possíveis problemas de segurança.

Se analisarmos conceitualmente todos os pontos mencionados acima, perceberemos que todos eles têm relação, de alguma forma, com a Defesa em Profundidade e Redução da Superfície de Ataque. 

O dilema se apresenta

Mas, ao mesmo tempo em que a IaC pode trazer benefícios por evitar erros humanos diante da necessidade recorrente de destruição e reconstrução de ambientes de infraestrutura de aplicações, ela também pode trazer problemas de segurança.

Veja alguns exemplos:

• A configuração incorreta de componentes de infraestrutura ou configurações incorretas introduzidas durante as atualizações podem levar a vulnerabilidades de segurança que podem ser replicadas diversas vezes, até o momento em que uma auditoria perceba a falha;

• Os scripts podem conter informações confidenciais, como senhas ou chaves privadas que, se não forem devidamente protegidos, podem colocar em risco os sistemas da organização;

• A IaC pode depender de bibliotecas e dependências de software externas, que podem conter vulnerabilidades ou serem usadas para introduzir códigos maliciosos;

• Scripts IaC são armazenados em sistemas de controle de versão, tornando-os acessíveis a todos os usuários autorizados. Isso pode aumentar o risco de ameaças internas ou exposição acidental de informações confidenciais;

• A IaC permite implantações rápidas e automatizadas, o que pode levar a consequências indesejadas se as alterações não forem devidamente testadas e auditadas antes da implantação.

A Infrastructure as a Code fornece uma maneira de automatizar e gerenciar a implantação e configuração de componentes de infraestrutura de maneira mais segura e replicável. Ela pode ajudar a reduzir o risco de vulnerabilidades de segurança e melhorar o nível de segurança das aplicações, desde que alguns pontos importantes sejam observados.

Como esses abaixo:

• Faz-se necessário o uso de assinaturas digitais para garantir a autenticidade e evitar adulteração ou substituição de código;

• Há a necessidade de utilização de um sistema de gerenciamento de segredos para armazenar e gerenciar informações confidenciais, como senhas e chaves de API, para impedir o acesso não autorizado;

• Outro ponto importante é a implementação de controles de acesso baseados em função para limitar o acesso a informações e operações confidenciais no pipeline CI/CD;

• É Importante que a rede seja segmentada para restringir o acesso ao pipeline CI/CD de fontes externas e limitar o impacto potencial de uma violação de segurança;

• A criptografia das comunicações entre todos os componentes no pipeline CI/CD para evitar espionagem e adulteração é fundamental;

• É necessário realizar regularmente avaliações de segurança e testes de penetração para identificar e solucionar vulnerabilidades no pipeline CI/CD;

• As interfaces de rede devem ser configuradas para permitirem apenas o tráfego necessário para a comunicação dos diferentes módulos da aplicação e seus dados.

A solução para o dilema

Diante do que foi exposto, fica claro que há aí um conflito:

 O uso da IaC auxilia no processo da construção de software com mais segurança por adicionar camadas de segurança ao automatizar o processo e evitar falhas humanas. Por outro lado, as más configurações em infraestruturas criadas por IaC podem expandir drasticamente a superfície de ataque.

Algumas ponderações importantes devem ser feitas pela organização durante o processo de avaliação sobre o uso de Infrastructure as a Code, principalmente no que diz respeito a custo/benefício. É necessária uma reflexão racional sobre a real necessidade do uso dessa tecnologia, sobre os custos para mantê-la e se realmente é o momento certo para essa mudança.

Muitas empresas iniciam o processo de utilização da IaC sem muito planejamento e não se atentam para o impacto que a utilização dessas ferramentas podem trazer no quesito segurança. Executam essas mudanças pensando na comodidade e não refletem sobre as consequências para o negócio.

Outras implementam a IaC pensando na segurança que a automação pode trazer, mas não se atentam ao tamanho da nova superfície de ataque que acabaram de criar, muito menos quanto a tudo o que será necessário para guarnecê-la.

A IaC é uma tecnologia que necessita de times maduros e especializados, que pensem constantemente em como tornar seus scripts e cada vez melhores utilizando as informações passadas por pentesters e auditores. Portanto, é uma tecnologia com um custo elevado.

Todas essas variáveis, incluindo os custos das ferramentas necessárias para a implantação das soluções em IaC devem ser consideradas na hora de decidir se realmente a organização está no momento exato para começar a utilizá-las.