3 Abordagens para Segurança de Containers

Este artigo analisa como organizações podem adaptar sua abordagem para acompanhar a rápida evolução dos containers.

Os containers estão se tornando a peça central do futuro da TI. Containers Linux já existem à algum tempo, mas eles ainda estão amadurecendo como uma tecnologia a ser usada em cenários corporativos de produção ou de missão crítica. Com isso, a segurança está se tornando um tema central em torno dos containers. Existem muitas soluções propostas para o problema, incluindo a abordagem de que a solução para esse tipo de tecnologia seja algo local como correções de bugs já conhecidos, restringindo mudanças e de modo geral implementando políticas de segurança mais eficientes. Este artigo analisa estas questões e como as organizações podem se adaptar a sua estratégia de segurança para manter o ritmo com a rápida evolução dos containers.

Durante sua palestra na Cloud Foundry Summit, Justin Smith, diretor da Pivotal Software Inc., que também está envolvida com a segurança da Cloud Foundry na Worldwide Threat Assessment em 2015 lista ataques cibernéticos como ameaça número um. "Dispositivos, projetados com requisitos mínimos de segurança, testados e com uma complexidade crescente de redes podem levar a vulnerabilidades generalizadas em infraestruturas civis e sistemas de governo dos Estados Unidos," diz o relatório.

A comunidade de tecnologia está menos preocupada com um ataque cibernético ao estilo Armageddon. "Estamos mais preocupados com um diversos ataques moderados contra um grupo de empresas. Isso interfere apenas na economia delas. Morte por mil concessões de papel," disse Smith.

Segurança é corrigir bugs

As empresas de containers com participações na Landscape optam por abordagens diferentes para segurança. Lars Herrmann, gerente geral da Red Hat disse em uma entrevista, "Containers definem uma forma diferente para a organização de colaboração dentro de uma organização. Esse é realmente um potencial inovador, mas para isso, precisamos de um certo tipo de tecnologia para permitir essa transformação."

Ele disse que a segurança é um aspecto importante deste processo, porque não podemos entrar em produção com lotes de diferentes aplicações sem ter uma sólida compreensão de como é gerenciar a segurança neste ambiente.

Como Linus Torvalds disse uma vez: segurança significa bugs. E, nenhum software é imune a erros. Herrmann disse que até mesmo o código dos melhores desenvolvedores podem ter problemas de segurança simples. Então, as empresas precisam pensar sobre todos os aspectos do processo.

Para proteger as organizações, a Red Hat tem parceria com Black Duck para que os clientes possam identificar e detectar em qual versão está a tecnologia de código aberto, e então correlacionar isso com sua base de dados back-end baseado no que eles sabem sobre a tecnologia em tal versão. "Vamos ver as soluções que mais estão conduzindo insights e fazer uma avaliação de risco mais refinada", disse Herrmann.

A varredura é apenas uma parte do cenário; a segunda é lidar com isso. Herrmann disse que os desenvolvedores poderiam implementar tais condições em um container em um determinado ambiente, com um registro que não atende aos critérios de segurança, assim eles automaticamente poderiam acionar o fluxo de trabalho e reconstruir aquele container com os mais recentes componentes de tempo de execução afim de resolver essa questão de segurança.

Essa é apenas uma peça do quebra-cabeça de segurança.

Segurança significa ser mais rápido

Smith da Pivotal crítica a forma como organizações se aproximam da segurança. Ele disse "... para ficar mais seguro, você pode ser mais rápido. Isso é exatamente o oposto de como as organizações pensam hoje. O que eu quero no meu tempo na Pivotal e meu tempo como parte da Comunidade Cloud Foundry é construir um sistema que em qualquer trimestre o data center fique livre de malwares."

De acordo com Smith, as organizações precisam dificultar que invasores possam comprometer seus sistemas. Deve ser como um player de vídeo para o criador do malware, onde ele possa chegar ao nível 100, mas nunca poder ultrapassar os últimos 5 níveis.

"E todos os servidores dentro do meu data center tiver a vida máxima de duas horas?" Smith disse que. Essa situação causa frustrarão aos atacantes, isso porque limita o tempo necessário para explorar vulnerabilidades, mesmo que conhecidas.

Quando questionado sobre esta abordagem, Herrmann concorda parcialmente que "ser mais rápido" pode parecer mais seguro, mas que depende muito da natureza do ataque. Não existe um fator singular. "Quanto tempo um sistema potencialmente exposto é um fator. Quão mal está exposto é outro fator. Quantas camadas de proteção que você tem é certamente outro fator relevante," apenas para citar alguns.

Herrmann acrescenta que ele na verdade não acredita que, só porque um determinado container esteja disponível por apenas alguns segundos, ninguém seja capaz de comprometê-lo. "Eu digo isso pois os atacantes têm as mesmas tecnologias disponíveis que você tem," disse ele.

Outro problema com a abordagem de que "ser mais rápido você torna mais seguro", disse Herrmann, é que "só porque eu faço tudo de uma forma de integração contínua, estou sempre trazendo o mais recente para todos os lugares... o que também significa trazer constantemente diversos riscos diferentes de vários locais diferentes. Sim, às vezes isso pode funcionar muito bem, mas, e se não? O que você faz então? Bem, reconstruindo a coisa toda com componentes quebrados provavelmente não vai resolver o seu problema. Eventualmente, alguém tem que fornecer uma correção."

Construir sistemas que possam ser atualizados

Um dos principais desenvolvedores do kernel Greg Kroah-Hartman tem a opinião de que as empresas devem construir sistemas que sejam capazes de ser atualizados. Uma brecha na importante segurança é o de sistemas sem patchs funcionando em produção. Kroah-Hartman acrescenta que, embora a comunidade Linux trabalhe rapidamente na corrição bugs para que fornecedores possam disponibilizar para seus usuários, esses fornecedores nem sempre fazem um bom trabalho.

"Nós temos uma histórico muito ruim de manter bugs vivos por um longo tempo. Alguém faz um teste com os bugs mais conhecidos, mas eles podem permanecer por até 5 anos em sistemas. É o tipo de coisa que as pessoas conhecem e sabem como explorar. Eles não são fechados. Isso é um problema em nossa infraestrutura," disse Kroah-hartman.

Outra questão envolve a mentalidade de que uma vez que um sistema é configurado, você não deve mexer nele. Herrmann defende essa abordagem e explica que muito processos tradicionais de segurança tem desde o princípio restringir mudanças. Você deve trabalhar sob a suposição de que, se você pode minimizar o risco em cada única mudança, você pode minimizar o risco em seu sistema resultante. Isso leva à ideia de "não toque em um sistema em execução," isso é tudo. Há filosofias construídas em torno dela: não deixe uma mudança ruim acontecer. Em vez disso, tenha grandes barreiras de proteção em cada mudança, assim você pode separar a mudança boa da mudança ruim.

Não existe bala de prata

A conclusão é de que não não existe bala de prata. As tecnologias de containers estão evoluindo rapidamente. Como eles estão se tornado maduros e continuam a evoluir, a natureza das ameaças irão mudar ao longo do tempo, envolvendo a segurança de computadores, segurança de armazenamento e a segurança da redes, por exemplo.

As organizações precisam ser proativas em relação a segurança em vez de esperar pelo melhor. As organizações precisam ter uma abordagem global na perspectiva de containers, além de precisar absorver diferentes filosofias: restringir alterações, estar sempre a frente, e ter sistemas que possam atualizar rapidamente. É menos sobre software e muito mais sobre a cultura.