Proteção para Aplicações em Containers

Nos dos últimos artigos tratei do novo universo das aplicações em container e microserviços, técnica padrão para desenvolvimento de aplicações nas empresas digitalizadas, leia-se Amazon, Google e afins, porém ainda longe de dominar o mainstream. No entanto, as várias vantagens não deixam dúvidas com relação ao futuro. Estamos indo em direção acelerada a ela, parte do processo de digitalização da economia. Por outro lado, vimos também que os containers podem ser um prato cheio para disseminação de ameaças, tanto por seu ambiente novo assim como pela dificuldade em protegê-lo com as tecnologias tradicionais de segurança.

Esse mês irei abordar medidas de proteção que podem ser adotadas. O melhor documento que conheço com as boas práticas para pessoas e processos é o documento 800-190 do NIST, o instituto de padronização dos Estados Unidos, cujo título é Application Container Security Guide. E o melhor de tudo é que é público, com acesso livre. A conclusão ao ler o documento é que temos que voltar aos pilares básicos de pessoas, processos e tecnologia. E é inevitável iniciar pelas pessoas, ou, mais especificamente, os desenvolvedores.

O processo dinâmico de desenvolvimento pode levar a alguns dos erros que mencionei mês passado, como a geração de containers contendo vulnerabilidades e falhas de configuração de seu sistema operacional incluído, assim como a falta de controle com o consequente uso de containers comprometidos e que deveriam ser descartados. Além disso, velhos problemas como erros de autenticação ainda permanecem. Ou seja, tudo que desenvolvedores faziam, ou fazem, de errado nas aplicações tradicionais pode ser repetido nas novas aplicações. A solução para os erros pessoais se resolve com educação e processos.

A adoção de processos visa a padronização de procedimentos, como já o sabemos, e é ainda mais essencial em metodologias distribuídas e dinâmicas como a de que estamos falando. Aqui também o NIST nos presta um grande trabalho, sendo indispensável sua leitura. Entre os processos recomendados pelo órgão americano está o de gestão de vulnerabilidades, gestão das imagens e containers, políticas de configuração das imagens, controle de palavras chave em texto aberto, e autenticação e autorização tanto de aplicações como de administradores.

O terceiro pilar é o de tecnologia e não, não há um produto único que dê conta do trabalho. Se algum fornecedor dizer isso a você, recomendo mudar de empresa. Aliás, não sei se hoje em dia ainda existe problema de segurança que possa ser tratado por produto único. O ambiente está tão complexo, e os vetores de ataque tão diversificados, que confiar em produtos é meio caminho para ser comprometido.

O documento do NIST chega a tratar de algumas tecnologias, e a primeira delas é a detecção de vulnerabilidades, porém, claro, adaptada ao mundo dos containers. Eu a colocaria, junto com treinamento e boas práticas, no capítulo de prevenção.

No entanto seria ingenuidade achar que em 2019 só a prevenção é suficiente. Segurança por prevenção sempre foi um sonho dos profissionais de segurança, mas infelizmente a realidade sempre foi impiedosa. Precisamos alterar nosso mindset para o pensamento de que a prevenção irá reduzir significativamente os ataques bem-sucedidos, deixando-nos com menos invasões a detectar. Aqui estou falando de invasões mesmo, não de tentativas. Temos que começar daí, do pior, lembrando-se da máxima “ausência de evidência não é o mesmo que evidência de ausência”. Quais seriam então as partes que deveriam compor uma arquitetura de segurança para aplicações, lembrando que são técnicas e não produtos.

Monitoração de malware na imagem do container

A detecção e resposta a malware é atualmente uma tecnologia consolidada, porém formatada para instalação em sistemas operacionais, no caso, os servidores onde os containers e sua infraestrutura são executados. A necessidade de EDR no servidor host continua necessário, mas também precisamos de monitoração na imagem do container. Malware pode também ser detectado pelo comportamento errático, levando-nos à próxima técnica.

Monitoração de comportamento das aplicações

Assim como o tráfego de redes, o comportamento das aplicações pode revelar muita coisa. Mesmo ataques dia-zero podem ser detectados através de comportamento suspeito similar ao de ataques já conhecidos. Um produto, portanto, deverá possuir um banco de dados já consolidado, além de um bom mecanismo de análise. Inteligência artificial e análise cognitiva começam também a serem incorporadas.

Monitoração da comunicação em rede

A detecção de anomalias de comportamento no tráfego é um dos principais indicadores de comprometimento, e podem indicar um ataque desconhecido ou um desvio de conduta em curso. Há vários produtos que realizam essa tarefa, que deve ser executada no ambiente de nuvem. Tal qual o comportamento de aplicações, o êxito dessa tecnologia está na base de comportamento e capacidade de análise das informações obtidas, principalmente quando lembramos que o tráfego será criptografado.

Aplicar o conceito de zero-trust para as aplicações

Normalmente ligamos o conceito de zero-trust a usuários, o que não está errado, mas ele vai muito mais além, englobando também a rede e aplicações. Uma aplicação deveria possuir o mínimo acesso possível e necessário para executar sua função. Um comportamento típico de ataque é o acesso lateral, ou seja, entre aplicações sem conexão hierárquica entre elas. Uma política zero-trust impede esse tipo de comunicação, mesmo que ela seja detectada pela monitoração de rede e aplicação. Uma cada não anula a outra, na verdade se complementando.

Enforcement de políticas

Políticas de microsegmentação, ou segmentação por software, como por exemplo comunicações de aplicações que violem políticas de PCI, devem ser criadas. Os próprios produtos auxiliam na criação das políticas ao mapear os acessos de aplicações reconhecidas como integras.

* publicado na Revista RTI - Dezembro/2019

Containers e seus riscos

Cada inovação em TI traz embutida uma série de riscos que, se não tratados, podem inviabilizá-la por completo. Não é diferente com a nova geração de aplicações em containers, que pouco a pouco se torna o padrão do mercado. No último artigo eu apresentei essa técnica de desenvolvimento de aplicações e todas as suas várias vantagens, e as razões para sua adoção cada vez mais rápida. Nesse artigo irei comentar os riscos a ela associadas, usando como fonte principal o documento 800-190 do NIST, o instituto de padronização dos Estados Unidos.

Antes de mais nada, é importante compreender que a técnica é, no final, uma evolução dos métodos tradicionais de desenvolvimento e implementação de aplicações. Ou seja, não é algo completamente novo, uma invenção que veio do nada. Portanto, herda muitos dos problemas que habitam o mundo das aplicações, com o agravante que altera a maneira como lidamos com eles. Em outras palavras, estamos lidando com software, e todo software mal escrito possui falhas e vulnerabilidades. O fato de escrever um código para uma aplicação de container não isenta o desenvolvedor dos cuidados básicos de segurança. Um bom exemplo é o antigo SQL Injection, ataque que se mantém válido mesmo para as novas aplicações.

O próprio container é uma evolução da infraestrutura tradicional. É uma imagem de um sistema operacional, porém fechado, contendo todos e apenas os componentes necessários para execução da aplicação nele executada. E todos sabemos que componentes de SO podem também conter vulnerabilidades, e são atualizados frequentemente devido a isto. No entanto, por ser um ambiente fechado, um container não receberá essas correções. Ele precisa ser regenerado com os novos componentes atualizados. Além de vulnerabilidades de software, os componentes podem também ser mal configurados, permitindo acesso não autorizado e manipulação. Varreduras de vulnerabilidade seguem, portanto, essenciais.

Uma preocupação de autoridades é o do comprometimento de containers na origem, ou seja, com malware embutido nos componentes usados na geração da imagem. Trata-se de ameaça bastante avançada, ligada muitas vezes a espionagem industrial e entre países, mas que é real, como foram os casos de componentes de hardware como chips, fornecidos já com código malicioso.

As medidas para contornar os três riscos acima são também evolução das medidas que todos deveriam já ter implementado em suas empresas ou exigidas de seus fornecedores de aplicação: medidas preventivas de segurança desde a fase inicial de desenvolvimento, com o tempo necessário para os testes de segurança tanto da aplicação como da imagem do container, além do cuidado severo com os componentes usados em sua montagem.

Seria ótimo se os riscos fossem limitados a esses, mas a realidade é mais complexa, e tem a ver com o conceito de microserviços, inerente ao ambiente dos containers. Um módulo nunca irá executar uma aplicação completa. Não porque não pode, mas porque não faz sentido por não aproveitar todo o potencial de distribuição e flexibilidade. Dessa forma, uma aplicação será uma coletânea de pequenas aplicações, os microserviços, executados em diferentes containers instalados em qualquer lugar, independentes e reutilizáveis por definição. Uma aplicação financeira, por exemplo, poderá ter um serviço de cadastro segmentado em diversos pequenos módulos, para digitação, validação do CPF, preenchimento automático de endereço a partir do CEP e etc, sem falar do banco de dados. Como cada microserviço é independente, ele pode ser substituído sem prejuízo dos outros serviços que o utilizam, inclusive por um que seja malicioso ou tenha sido comprometido.

Nessa parte lidamos com os riscos do ambiente, muito mais sérios porque são realmente novos, e não basta apenas manter o que já era feito, é necessário criar novos processos e procedimentos. Os primeiros dois riscos são a falta de certificação de containers apropriados para uso, e a garantia de que containers sem a certificados não serão usados. Um exemplo é um microserviço apresentando falha que é substituído por outro que funcionava bem, mas foi descartado por vulnerabilidade, seja por negligência ou por falta de política para o descarte e uso. Uma característica dessa nova geração de aplicativos é a velocidade em que eles são implementados, possibilitada, entre outras coisas, pela reutilização de módulos que, sem maiores controles, podem tornar vulneráveis dezenas de aplicações imediatamente.

Outros riscos também inerentes são o de comunicação, autenticação e autorização entre containers. A comunicação, normalmente criptografada, não elimina todos os riscos. Ela previne que um elemento externo ao ambiente tenha acesso ao tráfego, mas não um componente interno malicioso. O tráfego entre containers será também invisível aos dispositivos de monitoração de rede tradicionais, e assim toda a proteção estará a cargo dos administradores do ambiente. O NIST recomenda por isso que aplicações de diferentes níveis de sensibilidade de proteção de dados sejam executados em redes virtuais apartadas.

Autenticação e autorização andam juntas, e precisam ser configuradas corretamente. No entanto, aqui me refiro entre os containers e ao sistema de orquestração como o Kubernetes. Algo que não deveria ocorrer, mas ainda ocorre, é a implementação de ambientes sem os cuidados para que um usuário não autorizado e mal-intencionado possa deliberadamente alterar o ambiente, permitindo, por exemplo, acesso ao banco de dados a partir de containers não permitidos. Por fim temos os riscos associados aos sistemas operacionais hospedeiros e ao sistema de orquestração propriamente dito, vulnerabilidades de software desses sistemas.

Os benefícios do uso de containers e microserviços extrapolam os riscos, que são em sua grande maioria mitigados por boas práticas de gestão e desenvolvimento seguro de software, e pelo entendimento que o ambiente facilita a distribuição de aplicações, mas complica a gestão e segurança. Além das medidas há aplicações de segurança que elevam bastante o nível de segurança. Iremos discuti-los – processos e tecnologia, no próximo artigo. 


* publicado na Revista RTI - edição de Outubro/19.