Microserviços e segurança de aplicativos

Todos nós sabemos a importância de lavar as mãos para evitar a propagação de doenças, mas quando se trata de segurança de aplicativos, muitas vezes, em vez disso, deixamos para pensá-la como uma decisão tardia. “Aprendemos como adicionar testes aos fluxos de trabalho de desenvolvimento, mas com segurança, muitas vezes assumimos que outra pessoa virá e corrigi-la mais tarde”, conta Sam Newman, keynote speaker da Microservices Conference, ocorrida em Londres na última semana.

Para Newman, a grosso modo, os microserviços são formados em uma espécie de arquitetura hexagonal, e contempla nomes que correspondem às suas capacidades de negócios. Eles também são autônomos entre si, uma autonomia fundamentalmente adquirida através do deploy independente.

dockerCom um sistema monolítico, muitas vezes temos um perímetro ou limite e um banco de dados para proteger. Se alguém invadir esse sistema em consequência de uma violação ou ataque de segurança, provavelmente tudo o que estiver dentro do sistema estará disponível para o invasor. Em um sistema baseado em microserviços, e com segurança adequada, estamos limitando os privilégios que um invasor pode obter e a quantidade de dados disponíveis em um ataque mirando um serviço. Mas temos também uma superfície de ataque maior e mais servidores que podem ser atacados. Lá, as chamadas de método que estavam dentro de um processo monolítico são agora chamadas de rede para APIs expostas. Com muitos servidores e patches manuais, o risco de esquecer de rodar patches para um servidor aumenta.

Muitas vezes não pensamos racionalmente quando vemos uma ameaça ou um vetor potencial de ataque. Geralmente otimizamos para evitar que a ameaça seja explorada, quando deveríamos dar um passo atrás e analisar o problema holisticamente, o que significa que muitas vezes gastamos dinheiro com as coisas erradas, deixando vulnerabilidades abertas em nossos sistemas.

Em vez disso, é importante desenvolver uma abordagem de modelagem de ameaças e quebrar o processo de como pensamos racionalmente sobre onde devemos concentrar energia em torno da prevenção. Dois exemplos disso são “Attack trees”, descritas por Bruce Schneider, e o ciclo de vida do desenvolvimento da segurança na Microsoft com a técnica de modelagem de ameaças “stride e dread”. 

Um passo simples para uma maior segurança é começar a usar o HTTPS em tudo, incluindo o tráfego interno. Isso dará uma garantia de que a carga útil não foi alterada e que o servidor usado é o correto. Let’s encrypt é uma autoridade de certificação livre e automatizada que busca reduzir a burocracia na obtenção de certificados https. Newman observa que o recurso mais importante desses certificados é que ele são automatizados. Para verificar o cliente para o servidor é necessário um certificado de cliente, mas isso é muitas vezes um fardo de gerenciar.

Para Newman, o Docker é uma grande tecnologia, mas observa que muitas imagens oficiais e confiáveis possuem vulnerabilidades críticas, o que significa que quando instalarmos uma delas, também seremos premiados com essas vulnerabilidades. Ele recomenda fortemente o uso de ferramentas como clair, que ajudam fazendo análises estáticas das vulnerabilidades e patches frequentes.

A detecção – ou saber que algo de estranho aconteceu – pode ser útil para evitar novos ataques, mas também é importante encontrar novas vulnerabilidades nos servidores em execução. Muitas vezes os ataques deixam vestígios nos logs, e obter acesso a todos os logs em um local central é uma das primeiras coisas que o desenvolvedor deve fazer, tanto do ponto de vista da segurança como do desenvolvimento de aplicativos.

Além da prevenção e detecção, Newman observa a importância de também pensar em resposta e recuperação. Como você responde a uma violação de segurança e comunica os problemas com seus clientes e como restaurar o sistema se o mesmo estiver corrompido? Restaurar a partir de backups é muito mais difícil quando os dados encontram-se espalhados por inúmeros microserviços.

Fonte: InfoQ

21