As 4 fases da automação da gestão da cloud

A jornada de automação na cloud de um profissional de segurança

Se me encontrar numa conferência, é provável que me ouça dizer que “a segurança na cloud começa na arquitetura e acaba na automação”. Acrescento logo a seguir a importância de adotar uma mentalidade cloud native, mesmo quando se está atolado na realidade de uma migração lift and shift pouco elegante antes de o contrato do data center terminar e de se apagarem as luzes. Apesar de ser uma boa frase de efeito, não capta verdadeiramente como passei de um profissional de segurança do arroz com feijão (firewalls e gestão de patches) a um cloud native da arquitetura e da automação. Em vez de pregar do alto do púlpito, considero mais útil descrever o meu percurso pessoal e as conclusões técnicas que fui tirando pelo caminho. Se é um profissional de segurança, ou alguém que procura qualificar um profissional de segurança para a cloud, é provável que acabe por seguir um caminho muito semelhante.

Fase 1: automatizar configurações

Para mim, tudo começou há cerca de nove anos, quando me pediram para criar o primeiro programa de formação da Cloud Security Alliance. Cedo percebi que precisávamos de laboratórios reproduzíveis, que pudessem ser executados em qualquer parte do mundo, com alunos e formadores cujas competências iam do “programador” ao “auditor que só mexe em papéis”. Nessa altura, a Amazon Web Services ainda não tinha lançado verdadeiramente o IAM e as VPCs eram apenas redes privadas. E conceitos como Infrastructure as Code estavam agora a tornar-se viáveis.

Estava eu, portanto, a tentar perceber como construir na cloud um laboratório prático de uma stack aplicacional para milhares de alunos. De forma consistente, *e* com possibilidade de atualização à medida que a AWS fazia evoluir a sua tecnologia. Na altura, criar as próprias AMIs ainda era uma maçada, mas foi então que descobri as maravilhas do `cloud-init`. Um simples script que eu podia alojar num bucket S3, com duas pequenas linhas que os alunos colavam no campo User Data das suas instâncias, o que configurava as instâncias exatamente como era preciso no arranque. E quando as atualizações de software estragavam alguma coisa, bastava-me atualizar esse script no URL publicado e todas as novas instâncias passavam a usar a nova configuração — magia! Embora isto não ajudasse a aplicar patches em nada que já estivesse em execução, permitia-me manter uma boa experiência de primeira utilização, de forma muito mais fácil do que atualizar e publicar novas AMIs. E, num ato de total imprudência reputacional, ainda pode ver aqui no S3 uma versão posterior.

O meu primeiro passo foi o `cloud-init`. Já não é algo que utilize, mas foi revelador perceber que podia criar um script para um servidor inteiro e pô-lo todo a funcionar, com copiar e colar e um único ficheiro alojado.

Fase 2: automatizar fluxos de trabalho

Mas o passo seguinte teve muito mais impacto. Depois de alguns anos a dar formações práticas e a construir as minhas próprias workloads, comecei a brincar com a ideia de Software Defined Security. À minha frente tinha uma profusão de APIs de cloud, todas a sussurrar-me “chama-me” aos ouvidos. Comecei a procurar exemplos e encontrei… nada. Nem sequer o Security Monkey tinha ainda sido lançado publicamente.

Tinha uma formação agendada para a conferência de segurança Black Hat e decidi usá-la como desculpa para aprender Ruby e as APIs da AWS (através do SDK para Ruby). Acabei por escrever três demonstrações:

• Uma aplicação de resposta a incidentes que colocava uma instância em quarentena, analisava todos os seus metadados, a bloqueava através do AWS IAM, criava imagens de todo o armazenamento e lançava um servidor de análise forense pronto a analisar os snapshots associados. Fazia em 3 segundos o que antes me levava 30 minutos.
• Uma pequena aplicação que se ligava à AWS e ao Chef e identificava todas as instâncias que não estavam a correr o Chef (servidores “não geridos”). Um processo que num datacenter tradicional podia demorar semanas.
• Outra aplicação que abria security groups a um scanner Qualys, desencadeava uma análise e fechava o security group quando esta terminava.

Nunca tinha programado em Ruby, por isso as três demoraram cerca de dois meses de trabalho em part-time até ficarem operacionais. Eram bastante simples, mas aprendi algumas lições valiosas.

• Gerir as credenciais era crítico e tornava também mais difícil partilhar o código e levar outras pessoas a configurar corretamente os seus ambientes. Ler a partir de ficheiros de configuração era… irritante. Sobretudo para coisas como saber qual o security group em que região usar como grupo de quarentena.
• O Ruby funcionava bem no meu sistema local, mas depois rebentava com os limites de serviço e tinha de inserir temporizadores de atraso quando corria o código numa instância na AWS. Os limites de serviço das APIs não são seus amigos.
• Todas estas eram realmente estáticas. Por muito vistosas que fossem nas demonstrações, tudo se resumia a executar código manualmente a partir de um desktop ou de uma instância. Isso não envelheceu bem.

Reuni tudo isto sob o nome “SecuritySquirrel” e pode encontrar as versões de 2014 no GitHub. Acredite ou não, nem sequer são as originais que usei durante alguns anos antes de as publicar.

Fase 3: automatizar a própria cloud

Quando a AWS lançou as Rules para o CloudWatch, juntei código Python suficiente em cerca de 2 horas na manhã do sábado seguinte para reverter qualquer alteração a um security group em 10-15 segundos — incluindo filtros para definir o âmbito da defesa com base em tags, na VPC ou em quem solicitou a alteração. Pode descarregar o código e as instruções e, ao contrário do meu código em Ruby, este ainda funciona bastante bem para código de cloud com 3 anos.

Desde essa primeira demonstração, construí uma biblioteca de automações orientadas a eventos a correr em Lambda, algumas das quais pode descarregar. Nesse pacote, a minha preferida é `identify_internet_facing_servers.py`, que, para efeitos de demonstração, associei a um acionamento quando clico numa versão IoT de um botão Amazon Dash. É isso mesmo, ando com um botão Easy físico no bolso. Encontra quaisquer instâncias com a porta 22 aberta para a Internet e, com um duplo clique no botão, posso revogar as regras, recebendo uma mensagem de texto no telemóvel quando está tudo são e salvo.

A minha principal lição aqui foi inesperada. Não foi o facto de estas automações orientadas a eventos substituírem os meus fluxos de trabalho baseados em hosts, foi o facto de servirem um propósito diferente. Percebi que tinha deixado de construir fluxos de trabalho para fazer as coisas mais depressa e passara a construir barreiras de proteção para manter as coisas seguras em segundo plano. Ambos têm um valor incrível.

Fase 4: automatizar tudo

O meu trabalho mais recente tem incidido na utilização do Jenkins e de Infrastructure as Code (sobretudo CloudFormation) para reforçar a segurança. Esta combinação permite-me automatizar a segurança na própria infraestrutura e nas próprias aplicações e depender menos de ferramentas externas.

Por exemplo, lancei um scanner simples de credenciais para correr no Jenkins e encontrar quaisquer chaves de acesso armazenadas antes mesmo de iniciar o build. Porquê esperar e tentar descobri-las mais tarde? Escrevi depois outros test harnesses que me permitem executar praticamente qualquer ferramenta de avaliação que queira no Jenkins e fazer falhar os builds quando estes não passam algum teste de segurança, como uma análise de rede (dica de profissional: o Jenkins faz falhar um build se lhe enviar, a partir de um script, qualquer código de saída diferente de 0).

Fechando o círculo, damos agora a formação usando templates de CloudFormation para criar todos os elementos da stack aplicacional, de modo a que os alunos se possam concentrar em acrescentar segurança. Passámos de construir servidores de formação consistentes para ambientes de formação consistentes, com AMIs personalizadas que podemos atualizar em minutos… a nível global… com muito pouco esforço, e com todo o software pré-instalado e pronto para a configuração final.

A minha jornada na cloud começou há cerca de nove anos e a minha jornada na automação quase ao mesmo tempo. Comecei por construir coisas e depois tentar automatizar partes, mas hoje parto do pressuposto da automação. O meu trabalho inicial era sobre operações, mas atualmente está quase todo focado na segurança. Em eliminar a sobrecarga operacional e permitir que as partes do meu cérebro dedicadas à segurança se concentrem naquilo em que são melhores. Pelo caminho, aprendi também que nem toda a automação é igual; que há lugar para barreiras de proteção, fluxos de trabalho, orquestração entre plataformas, infrastructure as code e automação de pipelines. Tudo isto proporciona hoje benefícios de segurança quase inimagináveis, mas ainda estamos muito no início, numa altura em que se pode perder uma semana só a fazer a engenharia inversa de uma API mal documentada.

Se trabalha em segurança, está na altura de apurar as suas competências de programação. Se é developer ou de operações, está na altura de apurar as suas competências de segurança. Porque a maior lição de todas é que acabaram os dias da segurança como um chapéu de chuva e chegaram os dias da segurança integrada no tecido.