Uma história sobre como a infraestrutura como código pode ser sua aliada em Well-Architecting e na proteção do seu ambiente em nuvem
Por Raphael Bottino, arquiteto de soluções – publicado pela primeira vez no Medium.
Usar a infraestrutura como código (IaC, na abreviação em inglês) é a norma na nuvem. CloudFormation, CDK, Terraform, Serverless Framework, ARM… as opções são infinitas! E elas são tantas porque a IaC faz total sentido! Ela permite que os arquitetos e engenheiros de DevOps versionem a infraestrutura da aplicação tanto quanto os desenvolvedores já estão versionando o código. Portanto, qualquer alteração ruim, se no código ou na infraestrutura da aplicação, pode ser facilmente inspecionada ou, melhor ainda, revertida.
No restante deste artigo, vamos usar o CloudFormation como referência. E, se você é novo em IaC, veja como criar um bucket S3 na AWS como código:
Bem simples, certo? E você pode criar facilmente quantos buckets precisar usando o template acima (se você planeja fazer isso, remova a linha BucketName, pois os nomes são globalmente exclusivos no S3!). Com certeza, é muito mais simples e menos propenso a erros humanos do que clicar em vários botões no console da AWS ou executar comandos na CLI.
Bem, não é assim tão simples …
Embora este seja um template funcional e útil do CloudFormation, seguindo corretamente todas as suas regras, ele não segue as regras de algo maior e mais importante: o AWS Well-Architected Framework. Essa ferramenta incrível é um conjunto de whitepapers que descrevem como arquitetar na AWS, de 5 diferentes pontos de vista, chamados Pilares: Segurança, Otimização de Custos, Excelência Operacional, Confiabilidade e Eficiência de Desempenho. Como você pode ver nos nomes dos pilares, uma arquitetura que segue o framework será mais segura, mais barata, mais fácil de operar, mais confiável e com melhor desempenho.
Os 5 Pilares do Well-Architected Framework
Entre outros, este template irá gerar um bucket S3 que não tem criptografia ativada, não impõe criptografia e não loga nenhum tipo de acesso a ele – tudo recomendado pelo Well-Architected Framework. Pior ainda, essas configurações incorretas são realmente difíceis de detectar na produção e não são visivelmente alertadas pela AWS. Mesmo as excelentes ferramentas de segurança fornecidas por eles, como o Trusted Advisor ou o Security Hub, não fornecerão uma lista fácil para identificar os buckets com essas misconfigurations. Não é à toa que o Gartner afirma que 95% das falhas de segurança em nuvem serão culpa do cliente.
O movimento DevOps trouxe para as massas uma metodologia de falha rápida, que não é exatamente compatível com o cenário acima, onde muitas vezes uma falha é encontrada quando dados não criptografados vazam ou é necessário o log de acesso. A questão é, então, como melhorá-lo? Alerta de spoiler: a resposta está na própria IaC 🙂
Migrando para a esquerda
Mesmo antes de garantir que um template do CloudFormation esteja seguindo as práticas recomendadas da AWS, o primeiro requisito óbvio é garantir que o template seja válido. Uma ferramenta de código aberto fantástica chamada cfn-lint é disponibilizada pela AWS no GitHub e pode ser facilmente adotada em qualquer pipeline de CI/CD, falhando a build se o template não for válido, economizando um tempo precioso. Para encurtar ainda mais o ciclo de feedback e falhar ainda mais rapidamente, a mesma ferramenta pode ser adotada no IDE do desenvolvedor como uma extensão para que o template possa ser validado conforme é codificado. Bem legal, certo? Mas ainda não nos ajuda com o problema de misconfiguration que criamos com esse template realmente simples no início deste post.
O Conformity fornece, entre outros recursos, um endpoint de API para escanear os templates do CloudFormation contra o Well-Architected Framework e é exatamente assim que eu sei que esse template não está aderindo às suas melhores práticas. Essa API pode ser implementada em seu pipeline, assim como o cfn-lint. No entanto, eu queria mover essa checagem para a esquerda, assim como a extensão cfn-lint que eu mencionei antes.
A extensão de Template Scanner do Cloud One – Conformity
Com esse desafio em mente, bem como com a necessidade de escanear rapidamente meus templates em busca de erros de configuração, criei uma extensão do Visual Studio Code que, aproveitando a API do Conformity, permite que o desenvolvedor escaneie o template conforme ele é codificado. A extensão pode ser encontrada aqui ou pesquisando “Conformity” no seu IDE.
Após instalá-lo, o escaneamento de um template é tão fácil quanto executar um comando no VS Code. Abaixo, ele está sendo executado para o nosso exemplo de template:
Escaneamento de um template
Essa ferramenta permite que qualquer pessoa migre a checagem de configuração incorreta e de compliance para a esquerda o máximo possível, pondo-a diretamente nas mãos dos desenvolvedores. Para usar a extensão, você precisará de uma chave Conformity API. Se você não tem uma e deseja testá-la, o Conformity oferece uma avaliação gratuita de 14 dias, sem necessidade de cartão de crédito. Se você gostar, mas achar que esse período não é suficiente para você, entre em contato e tentarei disponibilizá-lo para você.
Mas … E o meu template de bucket?
Ah, a propósito, se você está se perguntando como um template CloudFormation de bucket S3 se parece ao seguir as práticas recomendadas, dê uma olhada:
Template de bucket Well-Architected
Não é tão simples, certo? É exatamente por isso que esse tipo de ferramenta é realmente poderosa, permitindo que os desenvolvedores aprendam à medida que codificam e que as organizações interrompam o deployment de qualquer recurso que não atenda às recomendações da AWS.
