blog conviso

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

March 10, 2023

By

Paschoal

Diniz

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.

Nova call to action

Sobre o autor

Paschoal
Diniz

Bachelor's degree in Computer Science from the Federal University of Alagoas. He has spoken at events such as the NullByte Security Conference and Hackers to Hackers Conference, and presented research projects at national and international events. He has experience in application security, exploit development, and vulnerability research in both userland and kernel land, having discovered vulnerabilities for companies like Microsoft, AMD, and Intel. His interests include operating system internals, compilers, malware development, vulnerability research, and EDR evasion.

Saiba mais