Infrastructure as Code: automatizando e protegendo infraestruturas na nuvem

Fundamentos de IaC - Apresentação

Apresentando o curso e o instrutor

Olá! Bem-vindos ao curso de Infrastructure as Code: automatizando e protegendo infraestruturas na nuvem. Já nos perguntamos como as grandes empresas criam seus recursos computacionais dentro da cloud (nuvem)? Como, através da utilização de código, podemos planejar, implementar, monitorar e manter um estado seguro dos recursos?

Meu nome é Rodrigo da Silva Ferreira Caneppele e serei o instrutor neste curso, no qual pretendemos formar nosso conhecimento sobre o que é infraestrutura como código.

Audiodescrição: Rodrigo é um homem branco, de cabelo castanho claro e liso, olhos castanhos, e veste uma blusa azul. Ele está em um ambiente de escritório com uma parede clara ao fundo.

Compartilhando a experiência do instrutor

Falando um pouco sobre mim, sou especialista em cloud pública e atualmente trabalho como engenheiro de software em uma instituição financeira. Tenho mais de 10 anos de experiência e minha especialidade é resolver problemas com soluções de engenharia. Com soluções de engenharia, quero dizer resolver o problema na raiz, não implementar apenas soluções paliativas. É olhar para o que temos no parque computacional e desenhar o melhor estado possível, além de como isso pode ser mantido e monitorado.

Explorando o conteúdo do curso

Falando sobre o curso, nós vamos entender o que é infraestrutura como código e quais são as melhores práticas conhecidas para utilizá-la dentro das clouds. Vamos explorar, por exemplo, o uso do AWS CloudFormation com o Terraform. Também abordaremos questões de automação e remediação automática, onde, mesmo que algum recurso esteja fora do código, é possível implementar código para mantê-lo em um estado seguro.

Tudo isso será feito em relação direta com o compliance de segurança que isso abrange, como Shift Left Security e CIS, entre outros frameworks. Implementaremos tudo dentro do padrão de CI/CD, utilizando GitOps e pipelines, compreendendo o que cada fase do código pode fazer por nós, profissionais de segurança da informação.

Iniciando a jornada de descoberta

Nós garantimos que essa será uma jornada de descoberta sobre a evolução do uso da infraestrutura, desde como era utilizada até como a utilizamos atualmente. Vamos explorar como podemos nos beneficiar de um projeto de gestão de mudanças dentro da nossa cloud, através de código, pipelines e controles de segurança. Vamos começar?

Fundamentos de IaC - O que é IaC?

Introduzindo o módulo de fundamentos em IaC

Olá, pessoal! Bem-vindos ao módulo de fundamentos em IaC. Na nossa primeira aula, vamos falar sobre o que é o IaC e os pilares da segurança em nuvem.

Começamos com uma linha do tempo, onde entendemos que, na década de 90, todos os servidores eram configurados e provisionados manualmente. Para tentar solucionar isso, nos anos 2000, surgiram as primeiras ferramentas de automação e configuração de servidor, chamadas Puppet e Chef. O objetivo dessas ferramentas era simples: descrever o estado desejado do servidor através de scripts, buscando a padronização.

Evolução do IaC e sua integração com DevOps

Um pouco depois, já em 2010 e 2012, o termo IaC (Infrastructure as Code, ou Infraestrutura como Código) passou a ser uma consolidação na indústria. Grandes empresas começaram a associar o IaC diretamente à cultura DevOps, que integra a área de desenvolvimento com a área de operação de TI. Logo depois, tivemos o lançamento do AWS CloudFormation, que é uma linguagem declarativa para criar recursos dentro da nuvem da AWS. Pouco tempo depois, a HashiCorp aproveitou o momento e lançou o Terraform.

A combinação dessas ferramentas será bastante explorada neste curso. Elas são destaque porque permitiram que nossa infraestrutura se tornasse reproduzível, reutilizável e com controle de versionamento. Isso impulsionou a adoção do código como padrão por todas as empresas.

Explorando a escalabilidade e a padronização no IaC

Indo um pouco para a teoria, temos a conexão entre o IaC e a escalabilidade. A escalabilidade é a capacidade de ampliar ou reduzir os recursos de TI conforme a demanda, de forma previsível e eficiente. Existem momentos específicos no ano que exigem maior capacidade computacional e outros que exigem menos. Esse processo precisa ocorrer com previsibilidade e eficiência. Assim como precisamos aumentar a capacidade, também precisamos diminuí-la, e esse processo deve funcionar adequadamente.

Para que tudo isso ocorra, é necessário ter um padrão. Precisamos definir, através do código, a configuração padrão para que os serviços funcionem corretamente.

Relacionando IaC com auditoria e segurança

Um ponto muito importante é que o IaC (Infraestrutura como Código) atualmente interage diretamente com a auditoria e a segurança. A definição do estado pode ser avaliada por auditores ou por qualquer pessoa responsável por verificar se a configuração está adequada. Utilizando o versionamento de código e GitOps, é possível detectar automaticamente desvios de padrão. Por exemplo, o AWS S3 Bucket é uma ferramenta para armazenar objetos dentro da AWS. Se definirmos esse recurso como padrão privado, mas identificarmos que um deles foi criado e ficou público, podemos, por meio da automação, reconfigurá-lo para o padrão desejado. Isso atende à auditoria, pois demonstra que definimos o estado, monitoramos o ambiente e corrigimos quando necessário.

Cito aqui o vice-presidente de segurança da Netflix, Jason Chan, que deu algumas entrevistas para a AWS sobre como utilizavam a cloud (nuvem). Ele mencionou que geralmente pensamos na automação como uma forma de economizar tempo, reduzir erros e diminuir o trabalho manual, e isso se aplica à segurança também. Essa entrevista foi dada em 2020.

Recomendando leituras e reflexões sobre o passado

Também recomendamos o livro "O Projeto Fênix". É uma leitura valiosa, especialmente para quem é mais novo e deseja entender como era trabalhar em uma grande empresa antes da infraestrutura como código. O livro aborda como eram utilizados os recursos computacionais quando não havia uma definição clara para ambientes de teste e produção. Imagine, na década de 1990, ter que enviar e-mails ou até mesmo ir pessoalmente à mesa de alguém para perguntar sobre alterações feitas. Como era lidar com isso durante o período de férias? O livro traz várias situações que nos ajudam a entender a importância do momento atual e a perceber que fazemos parte de uma revolução.

Agradecemos por assistir até aqui e vamos seguir para a segunda aula.

Fundamentos de IaC - Declarativo vs. imperativo

Introduzindo a aula e objetivos

Olá, pessoal! Bem-vindos ao vídeo 2 da aula de fundamentos de IaC. Nesta aula, vamos discutir o modelo declarativo versus o imperativo, suas diferenças e os riscos de segurança associados. Anteriormente, abordamos os fundamentos de IaC e o panorama histórico até chegarmos ao ponto em que o código se tornou o modelo padrão para o aprovisionamento de recursos.

Nesta aula, começaremos a explorar o que é um código Terraform, explicando algumas nomenclaturas. Até o final, seremos capazes de compreender visualmente o que é um código Terraform e o que é um script, por exemplo.

Explicando o modelo declarativo

Iniciando com o modelo declarativo, por definição, ele significa que definimos, através de parâmetros, qual é o estado desejado para um recurso. Delegamos à infraestrutura como código, como o Terraform, a responsabilidade de determinar o "como". O próprio Terraform, por meio de seus planos, decide como aprovisionar, mas a definição é nossa responsabilidade.

Gostaríamos de mostrar brevemente que, em duas linhas, definimos qual é a nossa cloud, qual é a nossa região e o que desejamos que essa instância seja. Vamos começar definindo o bloco de código chamado provider, onde especificamos qual é a nossa cloud e a região onde queremos que o recurso seja criado:

provider "aws" {
  region = "us-east-1"
}

Detalhando a configuração do recurso no modelo declarativo

Da linha 5 até a linha 12, definimos que o nosso recurso é do tipo aws_instance, atribuímos um nome aleatório, especificamos a imagem base para a criação da instância, o tipo dela e a tag que ela terá. Veja como isso é feito:

resource "aws_instance" "web_server" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"

  tags = {
    Name = "ServidorWeb"
  }
}

O modelo declarativo está alinhado com as melhores práticas de desenvolvimento de software. Ele propõe o uso do Terraform para gerar o estado do recurso, o que significa que teremos uma espécie de fotografia desse recurso no momento em que gerarmos o terraform init e, em seguida, o terraform plan. Teremos um arquivo que descreve exatamente a configuração definida.

Discutindo riscos e segurança no modelo declarativo

Dessa forma, podemos alinhar com auditoria e segurança, pois teremos um código que, no dia X, do mês X, do ano X, terá essa configuração. Caso desejemos alterar esse código, ele precisará passar por todo o processo de CI/CD. Assim, sabemos o que, quem e como.

Quais são os riscos relacionados a isso? Eles estão relacionados à parte humana.

Podemos, por completo desconhecimento ou até por esquecimento, não incluir recursos com seus padrões de propriedades essenciais para garantir sua segurança. Por exemplo, no exemplo apresentado, não foi especificado qual é o Security Group (grupo de segurança) em que essa instância será criada, ou se ela será pública ou não. Também não foi mencionado nas tags (etiquetas) da AWS qual é o time responsável pela criação dessa instância. Portanto, nem sempre seguimos o modelo adequado. Esse é um dos principais riscos desse modelo.

Explicando o modelo imperativo

Falando sobre o modelo imperativo, desde o início, definimos a ordem e o método para alcançar o estado desejado do recurso. Começamos desde a linha 1, definindo qual é o script, e seguimos passo a passo. Primeiro, instalamos a atualização, depois instalamos o serviço desejado, como, por exemplo, o Apache. Vamos ver como isso é feito em um script Bash:

#!/bin/bash

# Atualiza o sistema
sudo apt-get update -y

# Instala o Apache
sudo apt-get install apache2 -y

# Inicia o serviço Apache
sudo systemctl start apache2

# Habilita para iniciar automaticamente no boot
sudo systemctl enable apache2

Discutindo riscos e controle no modelo imperativo

Os riscos do modelo imperativo estão na falta de definição de estado. Não se sabe exatamente quando o código foi criado: hoje, ontem, no mês passado ou no ano passado. Embora existam maneiras de implementar um modelo imperativo, geralmente ele oferece pouco rastreamento e controle sobre quem fez o quê e quando.

Para ter um panorama dos tópicos abordados sobre segurança e ajudar a equilibrar qual é o melhor caso para utilizar e quais riscos devem ser calculados em relação à abordagem, é importante refletir. Como é o controle de deploy (implantação) utilizando cada modelo? É possível realizar um rollback (reversão) seguro? É possível relatar mudanças caso o time de segurança questione? Como o recurso está sendo provisionado? Quem foi a última pessoa a modificá-lo? Como foi modificado? Existe algum tipo de controle de permissão? Por exemplo, se o código está no GitHub, quais são as pessoas ou times que têm permissão para modificar, aprovar uma mudança ou até mesmo executar a própria pipeline que gera o recurso?

Concluindo e próximos passos

Assim, podemos começar a definir qual modelo será utilizado para o padrão de provisionamento. Nas próximas aulas, continuaremos discutindo quais são as abordagens adequadas para infraestrutura como código. Agradecemos por assistir até aqui e nos vemos na próxima aula.

Sobre o curso Infrastructure as Code: automatizando e protegendo infraestruturas na nuvem

O curso Infrastructure as Code: automatizando e protegendo infraestruturas na nuvem possui 259 minutos de vídeos, em um total de 66 atividades. Gostou? Conheça nossos outros cursos de Segurança em DevOps, ou leia nossos artigos de DevOps.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Fundamentos de IaC