Segurança em Cloud – O que é preciso saber?

Antes de começarmos, é importante dizer que este assunto não pode ser resumido em apenas um artigo. A ideia aqui é apresentar um cenário macro para que técnicos e gestores possam dispor de mais informações sobre o assunto e que a interação possa ser mais produtiva.

Vamos começar pelo conceito básico: “Movi meu ‘servidor’ para a nuvem e não preciso me preocupar mais com segurança. Agora é tudo com eles”. Essa é uma frase bastante comum, mas infelizmente é uma afirmação equivocada. A gestão da segurança, bem como os impactos resultantes de uma invasão ou vazamento de dados serão de responsabilidade de sua empresa. Seu provedor de cloud poderá auxiliá-lo na operacionalização de algumas tarefas ou no fornecimento de ferramentas que atendam a sua política de segurança.

Provedores são responsáveis pela segurança do ambiente de cloud. Mas o que isso quer dizer? Eles são responsáveis por garantir que infraestrutura física deles (datacenters), o hardware utilizado, o software de gerenciamento e a interconectividade do ambiente estão seguros e atualizados.

A segurança do que roda no seu cloud ou no seu ambiente virtualizado é de sua responsabilidade. Você deve gerenciar itens como segurança de rede, controles de acesso e identidade, segurança de dados, sistemas operacionais, aplicativos utilizados dentre outros. E não esqueça que a segurança dos computadores de seus funcionários e de seus servidores continua sendo sua responsabilidade. Afinal de contas, além do uso do cloud por seus funcionários, temos a troca de dados entre os dois ambientes que deve estar protegida para evitar que os dados sejam roubados enquanto estiverem em trânsito.

Este modelo é conhecido como segurança compartilhada. Veja como alguns dos grandes players se colocam sobre o assunto:

AWS – “a AWS é responsável por proteger a infraestrutura que executa todos os serviços oferecidos na Nuvem AWS. Essa infraestrutura é composta por hardware, software, redes e instalações que executam os Serviços de nuvem AWS.” [Segurança Compartilha na AWS]

Azure – “Você é responsável por ajudar a proteger seus dados e suas identidades, os recursos locais e os componentes da nuvem que você controla.” [A segurança na nuvem é uma responsabilidade compartilhada]

Google Cloud Platform (GCP) – “O Google tem o compromisso de manter seus projetos seguros, mas segurança é uma responsabilidade compartilhada.” [Visão geral da segurança do Google]

Mas o que isso significa?

Significa que não basta pensar que ao alocar um workload (servidor, aplicação ou serviço) em um provedor de cloud – independente se o provedor é um grande player, um parceiro estratégico local ou um provedor de nicho – devemos nos preocupar com a segurança do ambiente e das informações.

Vamos a um exemplo: a empresa X lançou um site para venda de artigos de perfumaria, um e-commerce. Para que o site tenha um mínimo de estabilidade e segurança, temos: datacenter, link, ambiente de cloud, redundância, sistema operacional do servidor, banco de dados, gateway de pagamento, autenticação dos administradores, usuários e desenvolvedores, dentre outros.

No modelo compartilhado, os três primeiros itens – datacenter, link e máquina virtual – são de responsabilidade do provedor. O servidor de banco de dados pode até ser gerenciado pelo provedor, mas a política de acesso é de responsabilidade da empresa. Os demais itens devem ser gerenciados pelo time da empresa X de acordo com sua política e segurança.

Sem um gerenciamento ativo poderemos ter um hacker atacando o banco de dados se aproveitando de um login sem senha ou com senha fraca para roubar os dados dos clientes. Um outro ataque pode ser realizado contra o servidor WEB para adicionar em uma de suas páginas um script de phishing ou ransomware que irá prejudicar seus consumidores e potencialmente sua reputação. Outro ataque comum é adicionar um script para coletar informações fornecidas no carrinho de compras antes delas serem enviadas ao gateway de pagamento, roubando assim as informações de seus consumidores. Estes são apenas alguns exemplos de ataques realizados contra ambientes de e-commerce sem uma proteção ativa.

Os ambientes de cloud hoje em dia são mais complexos. O uso de VPCs (redes privadas virtuais); de ferramentas para automatização de criação, aumento e redução do ambiente de acordo com a demanda como CloudFormation, Azure Resource Manager, Google Cloud Deployment Manager, Terraform e Ansible; e, a integração cada vez maior das equipes de desenvolvimento e operações (DevOps) trazem enormes benefícios. Entretanto carregam em si também uma enorme responsabilidade para os profissionais envolvidos, notadamente para o time de segurança.

Na topologia de seu ambiente, caso você possua mais de um VPC, procure tratar esses ambientes como dois escritórios remotos. É tentador permitir que a rede de um VPC se comunique diretamente com a do outro sem passar pelo firewall (aqui já estou considerando que o firewall é um dos elementos de segurança de sua VPC). Entretanto, essa comunicação elimina regras de segurança básicas. Se um servidor que está no VPC A precisa acessar um banco de dados que está no VPC B, este tráfego deve passar pelos gateways, sendo explicitamente liberado nos firewalls.

Vamos a um exemplo de auto provisionamento. Um escritório de advocacia possui um servidor de consultas processuais que na maior parte do tempo consegue atender perfeitamente as consultas dos advogados e estagiários com um único servidor WEB. Entretanto, em alguns momentos ocorrem picos de consumo em que é necessário um segundo servidor. Para isso existe um script de auto provisionamento que coloca o segundo servidor em funcionamento durante o pico e o remove quando o pico passa.

Em uma manutenção para o deploy (lançamento) de uma nova versão realizado em um sábado à noite, o script de auto provisionamento foi alterado e a porta 21 (FTP) passou a não estar mais bloqueada para acesso apenas de redes conhecidas. Por uma questão de design ou de política (estou relatando um cenário que já presenciei inúmeras vezes, embora não concorde com ele), o firewall não bloqueia tráfego externo para FTP. Temos aqui um ponto que será explorado pelos hackers.

E não se considere inexpressivo para ser vítima de um hacker. A maioria dos ataques se inicia via script, ou seja, de forma automatizada. Em 2019, para um de seus relatórios em a Sophos configurou de forma anônima 10 clouds Windows na AWS com o RDP (serviço de acesso remoto) liberado. Esses servidores são conhecidos como honeypots (pote de mel). O conceito do honeypot é simular alguma falha ou configuração específica e permitir a coleta de informações sobre as tentativas de invasão. O servidor alocado em São Paulo foi atacado 52 segundos após entrar em operação.

Como proceder então?

Análise a documentação de seu fornecedor, como por exemplo o AWS Security Best Practices, o Azure security best practices and patterns ou Tutorial: explore as práticas recomendadas. Estas são as políticas dos três maiores fornecedores. Se você for cliente de outro fornecedor, questione-o sobre práticas recomendadas. Estes materiais devem ser analisados pelo time de segurança de sua empresa para verificar possíveis alterações em sua política de segurança.

Faça as alterações necessárias em sua política de segurança corporativa para contemplar seu(s) ambiente(s) de cloud(s). Treine os profissionais. Não só os de segurança, mas todos. Principalmente os que estarão mais diretamente envolvidos como desenvolvedores, DevOps, rede, suporte etc.

Os processos de atualização e melhorias do ambiente, criação e apagamento automático de novas máquinas devem ser, sempre que possível, monitorados para verificar se estão de acordo com a política de segurança e, quando aplicável, ao(s) compliance(s) que a empresa deve seguir.

Avalie a possibilidade de uso de uma ferramenta CSPM (Cloud Security Posture Management). Seu objetivo é confrontar seu ambiente de cloud atual com um conjunto de regras de segurança: modelo escolhido. Esse modelo pode ser um framework de segurança (NIST, ISO27001, best practice do seu fornecedor), um compliance (HIPAA, PCI-DSS). Itens desejáveis na ferramenta são: visão de topologia, período de varredura configurável e, principalmente, permitir a conexão com repositórios de código para análise dos scripts de infraestrutura.

Como dito no primeiro parágrafo, este artigo não encerra o assunto segurança em cloud. Itens como ShadowIT (uso de serviços em nuvem pela empresa sem o conhecimento dos times de TI e segurança); IAM (Identity and Access Management); criptografia; firewall; prevenção a malware e ransomware; monitoramento; Disaster Recovery e Business Continuity (DR/BC) (não é porque os servidores estão na nuvem que não é necessário se preocupar com falhas ou desastres); segurança de serviços como buckets (repositórios de arquivos), bancos de dados ...