Digitalização de IaC: uma oportunidade de aprendizado fantástica e negligenciada

Tudo o que você lê sobre infraestrutura como código (IaC) se concentra em como ela funciona ou por que você deseja ter certeza de que ela realmente está sendo construída da maneira que você deseja.

Estas são áreas críticas. Mas será que estamos pensando o suficiente sobre como usamos essa abordagem em nossa organização?

As Melinda Marcos do ESG afirma em um relatório da empresa, “83% das organizações experimentaram um aumento nas configurações incorretas dos modelos IaC” à medida que continuam a adotar a tecnologia.

Sabemos pelo trabalho realizado pela Cloud Security Alliance (“Principais ameaças à computação em nuvem: Onze flagrantes“) e outros, as configurações incorretas continuam a ser um grande risco na nuvem.

IaC é compatível com reduzir
configurações incorretas, sistematizando a criação de infraestrutura, adicionando um nível de rigor e processo que garante que as equipes estejam construindo o que desejam e apenas o que desejam. Se cerca de 83% das equipes não percebem isso, há um problema mais profundo em jogo.

Em equipes menores, onde as partes Dev e Ops da filosofia DevOps estão juntas, isso faz sentido. A IaC permite que essas pequenas equipes usem a mesma linguagem – código – para descrever tudo o que estão fazendo.

É por isso que estamos vendo abstrações de nível ainda mais alto do que ferramentas como Terraform ou AWS CloudFormation no AWSCDK e projetos como cdk8s. Essas abstrações de alto nível são mais confortáveis ​​para os desenvolvedores.

Uma perspectiva de operações/SRE/plataforma de um serviço em nuvem será totalmente diferente da perspectiva do desenvolvedor do mesmo serviço. Um desenvolvedor examinará um serviço de filas e mergulhará em sua interface – um endpoint simples para adicionar e outro para ler? Vendido. Essa é uma integração fácil.

Esta perspectiva operacional visa encontrar os limites. Então, quando essa fila atinge o limite? O desempenho é constante ou muda radicalmente sob carga?

Sim, existem preocupações sobrepostas. E sim, esta é uma visão simplificada. Mas a ideia mantém-se. A IaC resolve muitos problemas, mas também pode criar e ampliar a desconexão entre as equipes. Mais importante ainda, pode destacar a lacuna entre a intenção do que você está tentando construir e a realidade do que você construiu.

Como resultado, é aqui que as preocupações de segurança aumentam frequentemente.

A maioria das ferramentas – comerciais ou de código aberto – concentra-se na identificação de coisas que estão erradas nos modelos de infraestrutura. Esta
é uma boa construção. Fazendo isto
seria ruim. Essas ferramentas visam gerar esses resultados como parte do pipeline de integração/entrega contínua (CI/CD).

Esse é um ótimo começo. Mas ecoa o mesmo problema de linguagem.

Quem está falando e quem está ouvindo?

Quando uma ferramenta IaC destaca um problema, quem o resolverá? Se for a equipe de desenvolvimento, ela possui informações suficientes para saber por que isso foi sinalizado como um problema? Se for a equipe de operações, as consequências do problema estão descritas no relatório?

Para os desenvolvedores, o que muitas vezes acontece é que eles simplesmente ajustam a configuração para fazer o teste IaC passar.

Para operações, normalmente é uma questão de saber se os testes estão sendo aprovados. Se estiverem, passe para a próxima tarefa. Isso não é um golpe para nenhuma das equipes; em vez disso, destaca a disparidade entre as expectativas e a realidade.

O que é necessário é contexto. As ferramentas de segurança IaC fornecem visibilidade sobre o que está prestes a (esperançosamente) ser construído. O objetivo é acabar com os problemas antes eles entram em produção.

As atuais ferramentas de segurança IaC destacam questões reais que precisam ser abordadas. Pegar o resultado dessas ferramentas e enriquecê-lo com contexto adicional específico da equipe responsável pelo código é uma oportunidade perfeita para alguma automação personalizada.

Isso também ajudará a preencher a lacuna linguística. A saída de suas ferramentas está essencialmente em um terceiro idioma – apenas para complicar as coisas – e precisa ser comunicada de uma maneira que faça sentido para o público de desenvolvimento ou de operações. Muitas vezes ambos.

Por exemplo, quando uma verificação sinaliza que uma regra de grupo de segurança não tem uma descrição, por que isso importa? Apenas receber um alerta que diz “Adicione uma descrição para o contexto” não ajuda ninguém a construir melhor.

Esse tipo de sinalização é uma ótima oportunidade para educar as equipes que estão construindo na nuvem. Adicionar uma explicação de que as regras do grupo de segurança devem ser tão específicas quanto possível reduz a oportunidade de ataques maliciosos. Forneça referências a exemplos de regras fortes. Diga isso sem saber a intenção e outras equipes não poderão testar a validade da confirmação de segurança.

A segurança é responsabilidade de todos, portanto, reconhecer a lacuna linguística entre desenvolvedores e operações destacará oportunidades como essa para adicionar automações simples que fornecem insights às suas equipes. Isso ajudará a melhorar o que estão construindo e, como resultado, gerará melhores resultados de segurança.

Sobre o autor

Sou um cientista forense, palestrante e analista de tecnologia tentando ajudá-lo a entender o mundo digital e seu impacto sobre nós. Para usuários comuns, meu trabalho ajuda a explicar quais são os desafios do mundo digital. Qual é o impacto do uso das mídias sociais na sua privacidade? O que significa quando tecnologias como o reconhecimento facial começam a ser utilizadas nas nossas comunidades? Eu ajudo a responder perguntas como essa e muito mais. Para as pessoas que desenvolvem tecnologia, ajudo-as a aplicar uma perspectiva de segurança e privacidade ao seu trabalho, para que possam permitir que os utilizadores tomem decisões mais claras sobre as suas informações e comportamento. Há uma montanha de confusão quando se trata de privacidade e segurança. Não deveria haver. Faço a segurança e a privacidade mais fáceis de entender.