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.
Nenhum comentário:
Postar um comentário