Uma das consequências tecnológicas da pandemia corporações foi a adoção de serviços de IaaS a fim de suprir a demanda por serviços digitais.

Centricidade no cliente, agilidade de negócios e redução de custos são os principais motores dessa transformação da infraestrutura.

Mas essa adoção acrescentou complexidade aos negócios, trazendo, em muitos casos, dificuldades para lidar com os novos desafios de segurança inerentes a essa complexidade.

Essa dificuldade levou a ataques às estruturas em nuvem que, em grande parte, se deveu a falhas de configurações e gerenciamento de segurança na ponta dos clientes dos serviços de IaaS.

 

A nuvem sob ataque – Números do Gartner

Em 2021, 50% das empresas, sem saber e por engano, terão exposto alguns serviços de armazenamento IaaS, segmentos de rede, aplicativos ou APIs diretamente para a Internet pública, contra 25% no em 2018.

Até 2023, pelo menos 99% das falhas de segurança na nuvem serão causadas por erros do lado dos clientes de IaaS

No artigo How to Make Cloud More Secure Than Your Own Data Center, o Gartner aponta como principal causa dessas falhas a dificuldade de compreender o fato de que padrões e medidas de segurança utilizados em estruturas locais não se traduzem bem em ambientes em nuvem, levando, em última instância à “lentidão na adoção desses ambientes ou em ambientes menos seguros”.

Identificando os riscos

No white paper Microsegmentação e Orquestração de Segurança para uma Defesa Inatacável da Nuvem, produzido pela FireEye, parceira da Tempest, recomenda-se que a limitação do impacto de potenciais ameaças comece na identificação dos riscos potenciais de malware, o que exige “uma visão consistente e segura de cada aspecto do ambiente”, no entanto, essa é uma das maiores dores dos times de segurança.

Afinal, se é verdade que há uma oferta de produtos incorporados pelos provedores de IaaS que permitem a tomada de decisão de segurança antes que o tráfego atinja os workloads (cargas de trabalho), as defesas de perímetro legadas das corporações normalmente ficam dentro da zona de ataque. Isso traz um risco maior, já que decisões de segurança não são tomadas até que o fluxo de dados chegue à máquina virtual.

Inicialmente, as equipes de DevOps do provedor de nuvem podem codificar controles de segurança em seus scripts de orquestração, mas a escalabilidade pode se tornar um problema:

1)  As equipes de segurança podem não ter visibilidade ou compreensão de quais controles foram implantados, mesmo com o console do provedor de nuvem.

2) As equipes de DevOps podem usar configurações genéricas para controles complexos que resultam em muito acesso e maior risco para a empresa.

3) Mesmo que a nuvem seja um ambiente explicitamente permissivo, as equipes de DevOps podem frequentemente definir configurações incorretas com muito pouco acesso.

4) Gerenciamento e controle limitados sobre as configurações de segurança significam que a equipe de DevOps precisa estar continuamente envolvida nas atualizações de configurações conforme as cargas de trabalho  (workloads) aumentam.

5) O desenvolvimento e a implantação são lentos porque as equipes de segurança não têm uma maneira fácil de ajustar as políticas existentes em vários aplicativos sem codificação e scripts complexos.

Para fugir a estes problemas deve ser explicitamente configurada uma abordagem granular, em nível de workload, com uma lista de permissões de controles nativos da nuvem, antes que qualquer dado possa entrar ou sair de uma carga de trabalho workload, instância ou contêiner. Configurações com controles de acesso de menor privilégio são fundamentais para o sucesso da segurança.

Parâmetros para a proteção de uma nuvem elástica e dinâmica

Workloads movimentam-se, mudam e aumentam com frequência em um ambiente cloud. Isso torna o gerenciamento de políticas de segurança altamente complexo.

Para lidar com essa complexidade, segundo o paper da FireEye, as equipes de DevOps podem tentar aprender os controles de diferentes provedores e escrever scripts para responder aos requisitos dinâmicos, mas isso pode resultar em atrasos na implementação e criar risco interno e questões de auditoria.

Segundo a fabricante, um forte projeto de segurança requer um plano que inclui:

1) Melhor Visibilidade: Visualização de toda a infraestrutura e seus controles de segurança para identificar rapidamente riscos no ambiente e confirmar a implementação da política correta.

2) Orquestração e Automação de Segurança: O provisionamento e o desprovisionamento automático de controles específicos para reduzir os problemas de má configuração e acelerar as operações.

3) Microssegmentação: Uma forma automática de fornecer políticas granulares e minuciosas para máquinas virtuais e containers, com base na função da carga de trabalho (workload).

4) Monitoramento e Governança: Mecanismo para rastrear o status de segurança e identificar ameaças e riscos potenciais.

Cloudvisory, uma solução completa para gestão e orquestração

Para gerenciar, provisionar e corrigir a segurança dos workloads, o Cloudvisory continuamente descobre e visualmente mapeia objetos de segurança e infraestrutura nativa de cada provedor de nuvem.

Por exemplo, na AWS isso inclui contas, regiões, nuvens privadas virtuais (Virtual Private Clouds, VPC), workloads, grupos de segurança e os fluxos de dados de rede entre workloads. No OpenStack, isso inclui contas, regiões, projetos, workloads, grupos de segurança e fluxos de dados.

O Cloudvisory também fornece microssegmentação granular inteligente, simplifica a criação de políticas usando controles de segurança nativos na nuvem, revela configurações de políticas erradas e ajuda a corrigi-las, organiza controles de política para segurança

consistentes, repetíveis e imutáveis em ambientes dinâmicos e automatiza o provisionamento preciso de políticas e o desprovisionamento nos provedores.

Para conhecer mais sobre o Cloudvisory e outras soluções de parceiros da Tempest, clique aqui