O imperador da segurança na nuvem não tem calças

Como qualquer um que tenha trabalhado em uma equipe multifuncional sem um dono claro sabe, responsabilidade “compartilhada” ou “conjunta” geralmente significa que todos assumem que outra pessoa está cuidando do problema. Sem um esforço claro para garantir que nada fique entre as duas (ou mais) equipes, algo sempre se perde.

O modelo de responsabilidade compartilhada e os provedores de serviços em nuvem

O modelo de “responsabilidade compartilhada” dos serviços em nuvem é mais ou menos assim: o provedor de nuvem protege tudo abaixo de um determinado nível (este nível geralmente é seu software) e é responsável por protegê-lo. Considere a fundação de sua casa. Você, o cliente, é responsável por proteger tudo acima da fundação – protegendo a casa, se quiser.

Parece muito claro e simples – e como todas as analogias claras e simples, não resiste à inspeção. Se você já olhou para uma casa, é claro, percebe que não há uma linha simples que você possa traçar separando os requisitos entre a fundação e o que está acima dela. As interconexões entre os sistemas separados são essenciais para a integridade estrutural da casa; o mesmo acontece com as interconexões entre uma plataforma de nuvem e os aplicativos que vivem em cima dela.

Configurações incorretas da nuvem e ferramentas complexas

A realidade é que a forma como um cliente configura um serviço em nuvem é fundamental para a segurança dos aplicativos que vivem em cima dele. Construindo em uma nuvem pública? Você expôs uma função Lambda ao público? Talvez você não tenha habilitado o controle de acesso do Lake Formation em seu data lake. Talvez você nunca tenha habilitado a segurança de dados avançada em seu AzureSqlDBServer. Ou há uma função de nuvem do GCP com privilégios de invocação pública.

Esse problema vai além das ofertas de nuvem pública de infraestrutura como serviço. Se você estiver usando uma rede de entrega de conteúdo para defesa contra DDoS, você se lembrou de tornar seu nome de host de origem imprevisível? Quando você integrou a malha de aplicativos de negócios entre seus serviços SaaS, você acidentalmente permitiu que algum usuário invocasse uma API que é necessária apenas para, digamos, Finanças?

A lista de maneiras pelas quais um cliente pode levar um tiro no pé é notavelmente grande. As melhores plataformas de nuvem investem muita energia para tornar esses descuidos raros e garantir que essas não sejam as configurações padrão. Mas nenhum provedor é perfeito em todos os seus serviços de nuvem e nem todas as plataformas de nuvem tornam seu sistema seguro para uso. E, pior, eles realmente não têm nenhum incentivo para informar seus clientes sobre as várias opções de configuração inseguras, especialmente se forem particularmente ruins nisso.

Ironicamente, as plataformas de nuvem que fornecem mais serviços de segurança para seus clientes geralmente criam uma maior complexidade no uso desses serviços. Cada kit de ferramentas requer conhecimento suficiente para usá-lo corretamente, pois agora existem empresas inteiras que existem para vender serviços apenas para configurar corretamente seus serviços em nuvem.

Melhorando a segurança na nuvem mantendo-se coberto

Se apenas um comprador pudesse perguntar a um fornecedor: “Quais são as maneiras mais arriscadas de usar e configurar esses serviços?”

Infelizmente, em vez de se concentrar em seu próprio uso de serviços em nuvem, a maioria dos clientes envia uma planilha gigante de perguntas de estoque com base no NIST CSF ou BITS SIG para garantir que o fornecedor esteja configurando ‘a ele mesmo’ corretamente. Em vez disso, talvez seja hora dos clientes usarem o processo de gerenciamento de risco de terceiros para começar a fazer perguntas perspicazes sobre sua própria segurança.

Ou, em termos de modelo de responsabilidade compartilhada, só porque seu provedor de nuvem tem uma bela calça, se você não souber colocar um cinto e enfiar a camisa, na melhor das hipóteses, ficará um pouco frio. Na pior das hipóteses, você se verá exposto de maneiras desagradáveis.