Por Erick Lemos – Gerente do Security Operations Center (SOC) Real Protect

Mais um incidente de segurança ocorreu devido a sistemas baseados em nuvem mal-configurados. A bola da vez foi o incidente da Verizon, que resultou no vazamento de dados de 6 milhões de clientes da empresa. Um bom lembrete de que a segurança da nuvem é compartilhada entre a fornecedora e o cliente.

Existe uma concepção errada de que o provedor da nuvem possui a responsabilidade integral sobre a segurança do ambiente. A verdade é que os provedores como a Amazon, Google e Microsoft são responsáveis apenas pela segurança física dos data-centers, mas deixam a segurança das máquinas virtuais e aplicações na mão das empresas.

Algumas provedores chegam até a oferecer uma série de adicionais de serviços e ferramentas para proteger as máquinas virtuais e aplicações, mas em última instância a implementação e responsabilidade são do CSO da empresa contratante. Não importa que tipo de serviços e segurança o provedor da nuvem oferece se a empresa contratante não protege sua própria rede, usuários e aplicações.

Uma empresa terceirizada cuidava do back-office e das operações de call-center da Verizon, armazenando todos os dados relativos aos clientes, que incluíam: nomes, endereços, número de telefone, códigos PIN de todos os clientes que ligaram para o call-center da Verizon nos últimos 6 meses.

Tudo isso estava armazenado na AWS no storage S3. A coleta desses dados tinham como objetivo auxiliar a experiência do consumidor, mas como o S3 estava configurado de forma incorreta e permitia acesso externo, qualquer um com paciência o suficiente para descobrir o endereço web teria acesso aos dados.

Criminosos em posse desses dados podem facilmente ligar para as vítimas se passando por funcionários da Verizon e ter acesso às contas desses clientes.

Esse tipo de erro é infelizmente muito comum. Uma pesquisa recente da RedLock descobriu que 40% das empresas inadvertidamente expôs uma parte do ambiente na nuvem publicamente devido a má-configuração.

Falha de configuração é um problema sério

Verizon foi apenas uma das empresas que tiveram seus dados expostos em nuvens públicas devido a erro de configuração. Apenas algumas semanas atrás, uma caso muito semelhante aconteceu com o WWE (primo rico do antigo Telecatch brasileiro). A base de dados estava sem encriptação e de forma pública no AWS S3, sem nenhum controle de acesso nem senha.

Em junho, o Comitê Nacional do Partido Republicano confirmou que informações de 198 milhões de eleitores registrados dos Estados Unidos estavam armazenadas em uma planilha completamente aberta no AWS S3.

O problema em questão não é que a nuvem é insegura, mas em última instância os gestores da empresa são os responsáveis por configurar corretamente e com segurança a rede, as aplicações e os dados.

Uma pesquisa realizada pela consultoria Threat Stack analisou 200 empresas que utilizavam a AWS, o resultado foi que 73% tinham pelo menos uma falha crítica de configuração, como por exemplo permitir acesso não autorizado direto aos dados, usar o objeto mal configurado como parte de uma ataque maior e consequentemente controlar todo o ambiente ao logar no console do AWS. Essas brechas são resultado de negligência de questões básicas de segurança e falta de políticas de TI.

Independente de quem é o responsável pela configuração – administradores de TI, desenvolvedores, engenheiros ou até equipe de segurança – muita gente não entende como configurar corretamente seus ambientes em nuvem. As empresas não podem mais tratar a nuvem pública como um local qualquer para armazenar informações, e sim adotar os seguintes controles e medidas para garantir a proteção contra acessos não autorizados.

1 Saiba sobre o que você é responsável

Os diferentes provedores de nuvem oferecem serviços diferentes entre si, de forma que o nível de responsabilidade entre as partes varia. Provedores de SaaS em geral vão garantir que suas aplicações estão seguras e os dados transmitidos de forma protegida. Contuda, essa não é a realidade dos provedores de infraestrutura de nuvem. Por exemplo, as empresas contratantes possuem total responsabilidade sobre a AWS Elastic Compute Cloud, a EBS e a Amazon Virtual Private Cloud, incluindo a configuração do sistema operacional, gerenciamento de aplicações e proteção dos dados.

Em contraste, a Amazon mantém o sistema operacional e as aplicações do S3, de forma que a contratante passa a ser responsável pelos dados e pelo controle de acesso e políticas de identidade. A Amazon fornece as ferramentas para criptografar os dados da S3, mas fica a critério da contratante fornecer segurança ou não para os dados que entra me saem do servidor. Sempre cheque com o fornecedor exatamente quem está responsável pela segurança dos dados e por cada controle de segurança da infraestrutura de nuvem.

2 Controle quem acessa

O relatório da RedLock também descobriu que 31% dos bancos de dados em nuvens públicas estão abertos para a internet. Mais do que isso, 93% dos recursos em ambientes de nuvens públicas não restringem tráfego outbound de forma nenhuma.

O incidente da Verizon ocorreu porque o S3 estava com acesso externo totalmente permitido. Infelizmente esse é um erro comum. Muitos administradores de rede dão acesso global em seus servidores utilizando as subnets para 0.0.0.0/0. Assim a conexão fica totalmente aberta, dando habilidade para qualquer máquina se conectar.

No caso da AWS, nenhum S3 deve ter política de acesso público.

Outro erro comum é deixar o SSH aberto, algo que 73% das empresas fazem. Outros 13% permitem conexões da internet direto para o SSH, o que significa que qualquer um que descubra a localização do servidor pode passar pelo firewall e acessar os dados.

Os grandes provedores de nuvem fornecem ferramentas de controle de identidade e acesso, utilize-as. Saiba quem possui acesso a quais dados e quando. Quando criar as políticas de acesso e identidade, garanta o mínimo de privilégios necessários e dê permições adicionais somente quando requisitado.

3 Proteja os dados

Outro erro comum é deixar os dados sem criptografia na nuvem. Armazenar dados sensíveis na nuvem sem colocar as devidas proteções e controles para prevenir o acesso ao servidor e proteger os dados é irresponsável.

Onde for possível, mantenha o controle sobre as chaves de criptografia. Ainda que seja possível dar para o provedor de nuvem acesso às chaves, no final do dia, a responsabilidade fica integralmente com o gestor da empresa contratante.

Mesmo quando o serviço de criptografia dos dados é disponibilizado pelo provedor de infraestrutura de nuvem, muitas empresas acabam não implementando. é importante lembrar que a criptografia é um último recurso de segurança – mesmo que a configuração de outros controles falhem e os dados caiam nas mãos de criminosos, eles não poderão ser lidos nem usados.

4 Proteja as credenciais

Não é incomum que chaves de acesso para a AWS estejão expostas. elas podem estar expostas em sistes públicos, repositórios de código-fonte e outros formas. Trate as chaves de acesso à nuvem como um tesouro e eduque a equipe para não deixar essas chaves expostas em lugar algum.

Crie chaves únicas para cada dispositivo externo, restrinja o acesso seguindo o princípio do menor privilégio possível. Tenha certeza de que as chaves não tenham amplas permissões, já que nas mãos erradas, elas podem ser utilizadas para acessar dados sensíveis.

Também tenha uma política de troca dessas senhas de forma periódica. Não utilize a conta de root nem para tarefas de administração, use-a apenas quando não houver outra possibilidade. Para todo o resto, dê aos usuários somente as permissões que eles precisam ter e nada mais.

Por fim, confira as contas e verifique quais não estão sendo utilizadas e desabilite-as. Se ninguém utiliza a conta, não há motivo para dar aos atacantes mais uma forma de acesso.

5 Autenticação em Múltiplos Fatores (MFA)

A MFA fornece uma camada extra de segurança para além do usuário e senha tradicionais, tornando o trabalho dos criminosos ainda mais difícil. O MFA deve ser habilitado para restringir o acesso aos consoles de gerenciamento, dashboards e contas privilegiadas. Pesquisa da ThreatStack encontrou cerca de 62% das empresas no AWS possuem pelo menos 1 conta privilegiada sem MFA habilitado.

6 Melhore a Visibilidade

É quase impossível para os gestores aplicarem políticas de gerenciamento de identidade, controle de acesso entre outras políticas seguras se não houver visibilidade sobre o que está acontecendo na infraestrutura.

Hoje, a maior parte das boas soluções de coleta, correlação e análise de logs se integram perfeitamente com as principais nuvens do mercado, de forma que você poderá implementar a solução e ter visibilidade completa sobre sua infraestrutura em pouco tempo.

Ter visibilidade sobre a infraestrutura também é fundamental para que a equipe de resposta a incidentes de segurança possa atuar corretamente. As informações e logs são o objeto fundamental necessário para que a Equipe de Resposta a Incidentes de Segurança possa realizar seu trabalho.

Não deixe que erros se transformem em incidentes de segurança

Incidentes de segurança não são sempre causados por ataques bem elaborados e sofisticados; dados sensíveis podem estar expostos e facilmente encontráveis devido a erro humano. Erros – esquecer de habilitar algo ou achar que algo está feito e não verificar – podem deixar a porta totalmente aberta para os criminosos. As empresas precisam constantemente auditar a segurança de seus ambientes em nuvem, assim como de seus fabricantes, fornecedores e parceiros. Como o incidente da Verizon mostrou, um problema gerado por uma empresa terceirizada pode se tornar uma grande dor de cabeça.

Por fim, fica a mensagem: não importa quem é o responsável pela segurança da infraestrutura da nuvem, no final do dia, o responsável em última instância para com o que acontece com os dados é a empresa e o gestor de segurança. As empresas hoje não estão maduras o suficiente para seguir para a nuvem, pois aspectos de segurança não são levantados no momento do planejamento desta movimentação.

É muito importante avaliar os riscos, estudar a arquitetura e topologia propostas, requisitos de configuração das soluções, controles de segurança e KPI’s. Além disso, quem ficará responsável por analisar, identificar e responder aos alertas de segurança gerados.