O cenário de segurança na nuvem nunca foi tão desafiador quanto agora. Na medida em que empresas brasileiras intensificam sua migração para ambientes cloud – em grande parte pela busca por inovação acelerada e escalabilidade de recursos – as ameaças avançam na mesma proporção.
Essa constatação é reforçada pelo recente relatório da Orca Security, o 2025 State of Cloud Security Report, que apresenta dados sobre o crescimento das vulnerabilidades e o aumento da complexidade causada pela adoção multicloud. No Brasil, onde a nuvem se tornou peça-chave nas estratégias de negócios e os riscos regulatórios da LGPD ampliam ainda mais a responsabilidade corporativa, os achados desse estudo global oferecem insights fundamentais para que equipes técnicas possam se reforçar contra ameaças e proteger suas organizações de forma proativa.
State of Cloud Security Report – Panorama Geral
O relatório da Orca Security apresenta um panorama abrangente dos desafios atuais. Em média, cada ativo em nuvem possui 115 vulnerabilidades conhecidas – um volume impressionante, e que deixa claro a dificuldade das equipes em manter os ambientes atualizados. Quase um terço de todos os ativos de nuvem está em estado negligenciado, seja por execução em sistemas operacionais sem suporte ou permanecendo sem patches por mais de 180 dias.
Esses ativos negligenciados tornam-se alvos fáceis para invasores, servindo como pontos de entrada convenientes. O estudo também mostra que 58% das empresas carregam pelo menos uma vulnerabilidade com mais de 20 anos de idade em seus sistemas – ou seja, falhas descobertas no início dos anos 2000 que jamais foram corrigidas. A presença persistente de vulnerabilidades antigas como essas ilustra um problema sistêmico de falta de correções e gerenciamento de patches, intensificando o risco de exploits bem-sucedidos.
Ao mesmo tempo, a superfície de ataque na nuvem segue em rápida expansão e os riscos se multiplicam aceleradamente. Mais da metade das empresas (55%) já adotam uma estratégia multicloud, usando dois ou mais provedores de nuvem.
Isso traz vantagens de flexibilidade e resiliência, porém dificulta a visibilidade e a padronização de segurança em todos os ambientes. Um ambiente disperso entre AWS, Azure, Google Cloud e outros aumenta a complexidade de monitoramento, configuração e resposta a incidentes.
Ao menos 76% das empresas possuem pelo menos um ativo em nuvem exposto publicamente que também permite movimento lateral dentro do ambiente. Em outras palavras, em três a cada quatro empresas há algum servidor, serviço ou recurso aberto à internet e conectado internamente, criando um caminho potencial para comprometimento amplo – o atacante que explora esse único ponto pode escalar privilégios e se mover lateralmente para atingir dados sensíveis ou serviços críticos.
De fato, em 13% das organizações analisadas, um único ativo suporta mais de 1000 caminhos de ataque diferentes dentro do ambiente. Esses números reforçam o paradoxo do defensor: enquanto o agressor precisa encontrar apenas uma brecha, a defesa deve estar atenta o tempo todo.
Outro ponto importante é que os riscos permeiam todo o ciclo de vida de aplicações em nuvem, não apenas os sistemas em produção. Ao menos 85% das empresas possuem senhas ou credenciais sem criptografia em seus repositórios de código-fonte
Isso inclui chaves de API, tokens de acesso, senhas e outros dados sensíveis inseridos no código durante o desenvolvimento. Caso esses repositórios sejam expostos – seja por vazamento ou má configuração – atacantes podem extrair essas credenciais e obter acesso privilegiado a sistemas e dados. Essa prática vulnerável acaba ampliando o risco em todo o ecossistema cloud, já que um simples descuido na etapa de desenvolvimento pode se converter em uma brecha grave em produção.
Crescimento do multicloud e desafios de visibilidade
Utilizar múltiplos provedores de nuvem tornou-se prática comum: hoje, 55% das empresas globais distribuem suas cargas entre dois ou mais provedores. No Brasil, essa tendência também se confirma à medida que empresas buscam evitar dependência de um único fornecedor e aproveitar benefícios específicos de cada plataforma.
Estratégias multicloud trazem benefícios como alta disponibilidade e escolha otimizada de serviços (por exemplo, usar recursos de IA avançados de um provedor enquanto hospeda sistemas legados em outro).
Contudo, esse movimento vem acompanhado de desafios de visibilidade e governança. Com aplicações e dados espalhados em diferentes ambientes, manter políticas de segurança consistentes se torna complexo – cada nuvem possui configurações, ferramentas de monitoramento e modelos de permissões distintos.
O relatório publicado pela Orca ressalta que a expansão do multicloud está redesenhando a natureza dos desafios em segurança. Equipes de segurança frequentemente enfrentam “pontos cegos”, onde faltam visibilidade unificada dos ativos e tráfego entre plataformas.
Isso pode resultar em configurações incorretas passarem despercebidas – por exemplo, uma storage bucket aberta ao público em um provedor pode não receber a mesma atenção que recursos em outro ambiente, devido a ferramentas e alertas fragmentados. Além disso, auditorias e conformidade (como aderência à LGPD e outras normas) tornam-se mais difíceis quando dados sensíveis estão distribuídos entre várias infraestruturas.
Um caso prático do risco multicloud é a dificuldade em gerenciar atualizações e patches de forma centralizada. Com diferentes tipos de máquinas virtuais, containers e serviços gerenciados distribuídos, manter todos os sistemas atualizados contra vulnerabilidades é desafiador. Essa complexidade contribui para o dado já mencionado de 115 vulnerabilidades em média por ativo – muitas vezes, as equipes não conseguem acompanhar o ritmo de correções em todos os ambientes.
Adversários sabem disso e exploram falhas em qualquer brecha disponível. Portanto, embora a estratégia multicloud seja quase inevitável para grandes organizações (seja por otimização ou para evitar lock-in), ela exige uma postura robusta de gestão unificada de segurança, com ferramentas que agreguem visibilidade de múltiplas nuvens em um só painel, políticas comuns e automação de verificações de conformidade. No contexto brasileiro, onde a migração para cloud vem acelerada – estimativas de mercado mostram crescimento anual expressivo nos investimentos em nuvem – adotar multicloud sem perder o controle de segurança é uma prioridade estratégica.
Adoção da IA na nuvem e novas ameaças
A Inteligência Artificial tem sido um recurso bastante utilizado, e a pesquisa aponta que 84% das empresas já utilizam algum recurso de IA em seus ambientes de nuvem. Esse número impressiona e indica que a maioria das empresas incorporou desde APIs de Machine Learning (aprendizado de máquina) gerenciadas pelos provedores até modelos e frameworks de IA de código aberto rodando em suas instâncias.
No Brasil, vemos cada vez mais empresas adotando Machine Learning na nuvem para analisar dados de clientes, automação inteligente e outros casos de uso. Porém, essa corrida pela IA traz consigo novos riscos de segurança.
Entretanto, ao menos 62% das organizações identificaram ao menos um pacote de IA vulnerável em seu ambiente cloud. Bibliotecas e modelos de IA populares frequentemente contêm falhas de segurança que podem ser exploradas se não forem atualizadas.
Alguns dos CVEs mais prioritários associados a pacotes de IA permitem execução remota de código (RCE), abrindo caminho para invasões completas do sistema. Por exemplo, vulnerabilidades como a CVE-2024-39705 (relacionada ao kit NLTK de processamento de linguagem natural) e a CVE-2025-32434 (associada ao framework PyTorch) estão entre as mais encontradas e permitem que um atacante execute código malicioso em servidores de IA.
Ao menos 72% das empresas que usam NLTK tinham a CVE-2024-39705 presente, e 57% das que usam PyTorch estavam expostas à CVE-2025-32434, ambas falhas graves que aguardavam correção no momento do estudo. Esses exemplos ressaltam a urgência de tratar vulnerabilidades em ferramentas de IA com a mesma seriedade das demais, já que um modelo comprometido pode servir de porta de entrada para todo o ambiente.
Outro aspecto é que a popularização de serviços de IA gerenciados versus ferramentas não gerenciadas cria diferentes superfícies de ataque. Muitas empresas usam serviços de IA nativos dos provedores (como AWS SageMaker, Azure ML ou APIs do Google Vertex AI) com bibliotecas de código aberto instaladas manualmente em VMs ou contêineres.
Exposição de dados sensíveis
Conforme as empresas migram mais dados críticos para a nuvem, garantir a proteção dessas informações torna-se imperativo. No entanto, o relatório aponta que 38% das organizações que armazenam dados sensíveis em bancos de dados na nuvem acabam deixando esses bancos expostos publicamente.
Ou seja, quase 4 em cada 10 empresas possuem alguma base de dados com informações confidenciais (como dados pessoais de clientes, registros financeiros, informações de saúde etc.) acessível a partir da internet – muitas vezes por falha de configuração.
Essa exposição de dados pode ocorrer, por exemplo, em um servidor de banco de dados em nuvem configurado sem restrições de firewall, ou um cluster de Big Data que deveria estar restrito à rede interna mas ficou acessível pela internet.
As consequências de um deslize desses são graves: além do dano reputacional e impacto nos negócios, no Brasil isso representa violação à LGPD (Lei Geral de Proteção de Dados), sujeitando a organização a multas e sanções regulatórias. Casos de vazamentos massivos por configurações incorretas de armazenamento em nuvem já ocorreram globalmente e localmente.
Empresas brasileiras de diversos setores têm enfrentado incidentes em que milhões de registros pessoais foram expostos por um simples recurso de armazenamento ou instância de banco aberta sem querer. Tais incidentes reforçam que segurança e conformidade andam juntas – um erro operacional pode se converter rapidamente em um problema jurídico sério.
Portanto, mapear onde estão os dados sensíveis na nuvem e garantir que estejam sempre protegidos (com criptografia, autenticação adequada e restrição de acesso de rede) é uma atividade obrigatória dentro das políticas de governança de dados. Outro vetor crítico de exposição são os deixados em código-fonte. Impressionantes 85% das empresas possuem secrets em texto plano nos repositórios de código, segundo o relatório. Isso inclui credenciais de banco de dados, chaves de serviços em nuvem, tokens de API de terceiros etc., inseridos por desenvolvedores para facilitar testes e integrações.
O problema surge quando esses repositórios vazam ou são acessíveis além do que deveriam – por exemplo, um projeto público no GitHub contendo uma chave de acesso da nuvem, ou um colaborador mal-intencionado que faz exfiltração do código interno. Com essas credenciais em mãos, invasores podem escalar privilégios rapidamente: acessar bases de dados, extrair grandes volumes de informação confidencial ou até movimentar-se lateralmente na rede utilizando os mesmos privilégios que o sistema comprometido possuía. De fato, há casos documentados de ataques em que a cadeia de eventos começou com a exposição de um token no GitHub, culminando em invasão de servidores corporativos.
Para mitigar esse risco, é essencial adotar práticas robustas de gestão de secrets, alinhadas aos princípios de DevSecOps. Recomenda-se nunca armazenar senhas ou chaves diretamente no código – em vez disso, utilizar serviços de vault (cofres de secrets) ou serviços de gerenciamento de secrets oferecidos pelos provedores de nuvem.
Além disso, ferramentas de varredura de código fonte (SAST) podem ser incorporadas no pipeline CI/CD para detectar automaticamente padrões de possíveis credenciais antes que o código seja enviado a repositórios. Equipes de desenvolvimento devem ser treinadas para reconhecer a sensibilidade desses dados e adotar controles como rotacionar chaves periodicamente e monitorar ativamente repositórios públicos por divulgações acidentais. Em paralelo, a área de segurança pode simular cenários de vazamento de credenciais e verificar se mecanismos de detecção e resposta conseguiriam identificar acessos indevidos originados com essas chaves – isso ajuda a avaliar a resiliência da empresa caso algum secret vaze.
Ativos negligenciados e vulnerabilidades sem correção
Um outro ponto que o relatório aponta é a quantidade de ativos “abandonados” ou desatualizados presentes nos ambientes cloud. Ao menos 32% dos ativos em nuvem, em média, encontram-se em estado negligenciado – executando sistemas operacionais obsoletos ou ficando meses sem aplicar atualizações.
Esses sistemas acabam se tornando verdadeiras “bombas-relógio” dentro da infraestrutura: apesar de funcionarem e muitas vezes serem esquecidos pelos times, estão repletos de brechas conhecidas que os invasores podem explorar facilmente.
A negligência de ativos é um exemplo clássico do paradoxo do defensor mencionado: para uma equipe de TI sobrecarregada, um servidor esquecido pode passar batido; já um atacante vai enxergar nele um alvo perfeito para obter acesso inicial, já que dificilmente é monitorado de perto.
Além disso, a quantidade de ativos negligenciados vem aumentando ano a ano, indicando que esse é um problema crescente e disseminado em praticamente todas as organizações e setores.
A maioria das empresas (93%) possui ao menos uma vulnerabilidade com mais de 10 anos de idade em algum sistema; e em 58% das organizações existe pelo menos uma vulnerabilidade presente há mais de 20 anos. Esse dado impressiona – significa que falhas divulgadas no início dos anos 2000 (ou até finais dos anos 90) continuam sem correção em sistemas atuais. Essas vulnerabilidades muito antigas frequentemente têm exploração conhecida e até ferramentas de ataque disponíveis publicamente há décadas.
Duas das vulnerabilidades mais importantes dos últimos anos – Log4Shell (falha no Log4j divulgada em 2021) e Spring4Shell (falha no Spring Framework de 2022) – ainda estão presentes em mais da metade das empresas analisadas.
Mais de 57% das empresas têm pelo menos um ativo vulnerável a Log4Shell ou Spring4Shell, mostrando como mesmo bugs de alta prioridade permanecem sem patch em muitos casos.
Pior, cerca de 32% dos ativos em nuvem vulneráveis a Log4Shell estão expostos publicamente, aumentando drasticamente a probabilidade de serem explorados a qualquer momento. Essa persistência de vulnerabilidades conhecidas sugere falhas não apenas técnicas, mas também processuais – priorização incorreta de patches, janelas de manutenção insuficientes ou teste inadequado de atualizações podem contribuir para esse cenário.
O problema é que a presença massiva de sistemas desatualizados não passou despercebida pelos adversários. Grupos de ameaças avançadas estão explorando agressivamente essas brechas.
Por exemplo, um comunicado conjunto recente de agências como FBI e NSA alertou sobre as atividades da APT29 (um grupo ligado à inteligência estrangeira) focadas em explorar vulnerabilidades de software para obter acesso inicial e mover-se lateralmente nos ambientes das vítimas. Entre os alvos destacados estavam empresas de tecnologia e saúde – setores onde, conforme o relatório mostra, 84% das organizações têm pelo menos um serviço web desatualizado exposto.
No Brasil não é diferente: setores de infraestrutura, governo e saúde, por exemplo, têm sido visados por ataques que tiram proveito de servidores desprotegidos ou aplicações sem patch. Diante disso, as organizações precisam reforçar suas práticas de gerenciamento de patches e atualização contínua. Isso inclui mapear todos os ativos (inclusive os “esquecidos”), aplicar políticas de atualização automatizada sempre que possível e, crucialmente, priorizar correções com base em risco.
Nem todas as vulnerabilidades têm o mesmo peso – a recomendação moderna é focar naquelas que são ativamente exploráveis e que estão expostas em caminhos de ataque críticos. Ferramentas de análise de exploitabilidade e attack path podem ajudar a determinar quais falhas corrigir primeiro para reduzir a probabilidade de uma invasão bem-sucedida.
Movimento lateral e privilégios excessivos: o outro lado da moeda
Além de vulnerabilidades em sistemas, a arquitetura e configurações de acesso em nuvem podem ampliar os danos em caso de invasão. O conceito de movimento lateral refere-se à capacidade de um invasor, após comprometer um ponto na rede, percorrer internamente para atingir outros sistemas.
Ao menos 76% das organizações possuem ativos públicos que servem de ponte para o interior do ambiente cloud. Isso pode ocorrer, por exemplo, se uma máquina virtual exposta tiver credenciais ou conexões de rede a um banco de dados interno – ao comprometer a VM, o atacante ganha passagem para o banco. Ambientes mal segmentados ou sem segmentação alguma na nuvem facilitam essa movimentação. No contexto de multicloud, há cenários em que um recurso em uma nuvem tem acesso a recursos em outra nuvem, ou via redes privadas interconectadas, o que expande ainda mais o alcance do movimento lateral caso não haja controles rígidos.
Outro ponto importante é que 93% das organizações utilizando Kubernetes possuem pelo menos uma conta de serviço do K8s com privilégios elevados demais. Kubernetes é amplamente adotado (presente em 70% das empresas pesquisadas) por orquestrar aplicativos containerizados, mas sua má configuração pode introduzir riscos graves.
Contas de serviço superprivilegiadas significam que, se um invasor comprometer qualquer pod ou componente do cluster, ele pode usar aquelas credenciais para escalar privilégios no cluster inteiro, acessar dados sensíveis ou até derrubar workloads críticos. Além disso, o estudo encontrou que metade das empresas possui pelo menos um cluster Kubernetes executando com versão não suportada (ou seja, desatualizada) – combinando software desatualizado com contas privilegiadas, cria-se um cenário ideal para exploit e tomada de controle do ambiente de orquestração.
Esse problema não se limita ao Kubernetes. Em geral, permissões excessivas e identidades não gerenciadas são uma dor de cabeça na nuvem. Muitas empresas acumulam usuários, papéis (roles) e contas de serviço que excedem em muito o necessário – a chamada explosão de identidades na nuvem. Aproximadamente 67% das organizações têm pelo menos uma conta de serviço Kubernetes não utilizada.
Expandindo além do K8s, podemos imaginar que nas contas cloud (AWS IAM, Entra ID etc.) ocorre algo similar: contas antigas que ninguém removeu, chaves de acesso não rotacionadas, permissões genéricas (wildcards) atribuídas por comodidade.
Tudo isso cria oportunidades para criminosos. Uma conta em desuso pode ser comprometida sem levantar suspeitas, e se tiver privilégios altos, o invasor terá caminho livre. Uma permissão ampla demais pode permitir que um malware, ao infectar um aplicativo, realize ações inesperadas na infraestrutura (como alterar configurações, extrair dados de vários serviços, desligar instâncias, etc.).
Para combater esses riscos de movimento lateral e abuso de privilégios, as organizações devem investir em segurança de identidade e arquitetura Zero Trust. Isso inclui aplicar rigorosamente o Princípio do Mínimo Privilégio (PoLP) – cada usuário, aplicação ou serviço deve ter apenas as permissões indispensáveis para sua função.
Na prática, requer revisar regularmente as políticas IAM, remover acessos desnecessários e segmentar a rede de forma que mesmo se um recurso for comprometido, ele não abra porta para todos os demais. Em Kubernetes e demais plataformas, configurações padrão devem ser endurecidas: desabilitar credenciais de alta permissão sempre que possível, usar Namespaces e Network Policies para limitar comunicação, e implementar autenticação robusta e controles de acesso centralizados para todas as contas de serviço.
Ferramentas de CIEM (Cloud Infrastructure Entitlement Management) e análises automáticas de políticas podem ajudar a identificar direitos em excesso e sugerir ajustes. Por fim, monitoramento de atividades suspeitas é crucial – por exemplo, se uma conta de serviço raramente usada de repente fizer chamadas incomuns, isso deve disparar alertas para investigação imediata.
Cenário brasileiro: ameaças e regulamentações locais
No Brasil, o cenário de segurança em nuvem acompanha muitas das tendências globais destacadas pelo relatório, porém com alguns contornos específicos. A adoção de nuvem pelas empresas brasileiras cresceu exponencialmente nos últimos anos, impulsionada pela transformação digital e, mais recentemente, pelas exigências de trabalho remoto e serviços online.
Estima-se que a maioria das grandes empresas nacionais já migrou parte substancial de sua infraestrutura de TI para provedores como AWS, Azure e Google Cloud, muitas vezes em arquiteturas multicloud similares às dos players globais. Isso significa que os mesmos desafios de visibilidade, configuração e integridade de ativos se manifestam nos ambientes locais.
De fato, casos de vazamento de dados em nuvem no Brasil têm se tornado comuns nas manchetes: desde bases de dados de órgãos públicos expostas indevidamente, até dados de clientes de empresas privadas deixados em servidores acessíveis a qualquer internauta.
Cada incidente desses reforça a importância da segurança preventiva e da cultura de proteção de dados. Um fator crítico no contexto brasileiro é a conformidade regulatória com a LGPD (Lei Geral de Proteção de Dados). Em vigor desde 2020, a LGPD impõe obrigações rígidas quanto à proteção de dados pessoais – inclusive quando armazenados ou processados em nuvem. Isso agrega uma camada de urgência: além dos prejuízos de um incidente de segurança em nuvem por si só, as organizações nacionais ainda podem enfrentar multas de até 2% do faturamento (limitadas a R$50 milhões por infração) e danos à imagem caso dados de clientes vazem por falhas de segurança.
Órgãos reguladores brasileiros, como a ANPD (Autoridade Nacional de Proteção de Dados), já investigam incidentes e cobram medidas das empresas afetadas. Assim, garantir a configuração segura de ambientes cloud, controle de acesso rigoroso e criptografia de dados sensíveis não é apenas boa prática – é também uma necessidade de conformidade legal. Setores regulados, como o financeiro e de saúde, enfrentam cobranças adicionais de seus reguladores específicos para demonstrar governança sobre ambientes em nuvem. Por exemplo, instituições financeiras supervisionadas pelo Banco Central precisam aderir a políticas de segurança cibernética que incluem controles em provedores de nuvem, avaliação de riscos de terceiros, etc.
Outro desafio local é a escassez de profissionais especializados em segurança da informação e nuvem. A demanda por especialistas em cloud security superou em muito a oferta no mercado brasileiro. Muitas empresas relatam dificuldade em contratar ou reter talentos com experiência em arquiteturas cloud e DevSecOps, levando a equipes sobrecarregadas.
Esse déficit de recursos humanos qualificados torna ainda mais complexo lidar com a avalanche de vulnerabilidades e alertas que ambientes multicloud geram. Ferramentas e plataformas de segurança que automatizam detecções, priorizam riscos e até utilizam IA para filtrar eventos ajudam a mitigar um pouco o problema, mas investir na capacitação da equipe interna também é fundamental. Iniciativas de treinamento, certificações em cloud e parcerias com consultorias podem elevar o nível de preparo das equipes brasileiras para enfrentar ameaças modernas.
Por fim, vale mencionar que os atacantes também estão atentos ao Brasil. Grupos de ransomware internacionais têm alvejado empresas locais, muitas vezes explorando exatamente brechas como as descritas no relatório Orca: uma VPN em nuvem sem correção, uma credencial vazada em repositório público, um servidor exposto sem proteção. Em 2023 e 2024, vimos ondas de ataques de ransomware impactando desde prefeituras e órgãos governamentais até grandes redes varejistas nacionais, frequentemente envolvendo sequestro de dados em infraestrutura cloud.
Esses episódios elevam a conscientização, mas também demonstram que nenhuma empresa está fora de alcance. Adversários falam português – no submundo digital proliferam tutoriais e ferramentas voltadas a explorar serviços em nuvem mal configurados, e cibercriminosos locais e estrangeiros colaboram para atingir alvos rentáveis no país.
Recomendações para fortalecer a segurança na nuvem
Diante de tantos desafios mapeados pelo relatório de riscos na nuvem 2025, é fundamental que as empresas transformem esses insights em ações concretas. A seguir estão algumas recomendações estratégicas para equipes de segurança e infraestrutura implementarem em suas operações de nuvem, visando mitigar riscos e elevar o nível de proteção:
Mapeie e proteja seus ativos críticos: Mantenha um inventário atualizado de todos os ativos em nuvem (VMs, contêineres, bancos de dados, funções serverless etc.) e identifique quais abrigam dados sensíveis ou funções de negócio vitais. Priorize a proteção desses “crown jewels” – assegure monitoramento contínuo, segmentação de rede adequada e controles extras nesses ativos de alto valor. Em paralelo, elimine ativos esquecidos ou desnecessários que apenas ampliam a superfície de ataque.
Previna a negligência de workloads: Estabeleça processos para evitar que sistemas fiquem sem suporte ou sem patch. Use ferramentas de gerenciamento de configuração para aplicar atualizações automáticas sempre que possível. Defina políticas claras de ciclo de vida: se um servidor ou serviço não recebe patches por 180 dias, isso deve acionar alertas ou mesmo sua remoção.
Descontinue softwares legados que não recebem mais atualizações do fornecedor e migre para alternativas suportadas. Lembre-se: ativos negligenciados são porta de entrada preferida dos atacantes.
Priorize correções com inteligência de risco: Diante de milhares de vulnerabilidades, adote uma abordagem orientada por risco para patching. Foque nas falhas exploráveis e expostas em seu ambiente. Utilize análises de Reachability (alcance/explorabilidade) para identificar quais vulnerabilidades têm caminho aberto até a internet ou até dados críticos, e corrija-as primeiro. Aplique patches de emergências em vulnerabilidades de alta gravidade (CVSS alto) ou com exploits conhecidos, como as citadas Log4Shell e similares, antes que possam ser utilizadas contra sua empresa.
Fortaleça a proteção de dados e segredos: Faça varreduras regulares para descobrir onde vivem dados sensíveis no seu ambiente cloud (bases de dados, data lakes, backups, logs). Depois de identificados, aplique criptografia em repouso e em trânsito, restrinja rigorosamente quem ou o quê pode acessá-los e monitore acessos (logs e auditorias constantes).
Implemente ferramentas de Data Loss Prevention (DLP) para evitar exfiltração. Em relação a credenciais e segredos, invista em cofres de segredos e certifique-se de que nenhum segredo está em repositório de código ou em variáveis de ambiente expostas. Rotacione chaves e senhas periodicamente e utilize autenticação multifator em tudo que for possível.
Aplique Princípio do Mínimo Privilégio (PoLP): Revise as permissões de usuários, contas de serviço e funções nas suas nuvens. Remova acessos desnecessários e reduza privilégios excessivos imediatamente. Estruture políticas IAM de forma que cada aplicação ou usuário tenha somente as permissões estritamente necessárias. Considere soluções de Just-In-Time Access para conceder acessos privilegiados temporariamente quando requeridos, evitando deixar portas abertas continuamente. No Kubernetes, garanta que contas de serviço não usem tokens default com poderes administrativos – delimite o escopo por namespace e função.
Melhore a segurança de IA em uso: Trate modelos e serviços de IA como ativos críticos. Proteja seus pipelines de IA, controlando quem pode alterar modelos e quais bibliotecas são permitidas. Acompanhe boletins de segurança dos principais frameworks (TensorFlow, PyTorch, scikit-learn etc.) e atualize-os regularmente para corrigir CVEs conhecidos. Da mesma forma, aproveite ferramentas de IA a favor da segurança: soluções modernas permitem usar Machine Learning para priorizar alertas, detectar anomalias e até identificar configurações inseguras automaticamente.
Invista em monitoramento contínuo e resposta ágil: Adote o mantra “Trust, but verify”. Mesmo com todos os controles, assuma que brechas podem ocorrer. Portanto, implemente monitoramento 24×7 de logs e atividades em todos os ambientes cloud.
Configure alertas para padrões suspeitos (ex.: muitos dados saindo de um storage, criação inesperada de usuários privilegiados, varreduras internas de porta indicando movimento lateral). Mantenha um plano de resposta a incidentes cloud, com papéis definidos e procedimentos de contenção específicos para nuvem (isolamento de VPC, revogação de chaves comprometidas, etc.). Realize testes de invasão periódicos e exercícios Red Team focados em cenários de nuvem para validar suas defesas.
Fomente cultura e capacitação em segurança cloud: Tecnologia sozinha não resolve o problema. As equipes precisam estar preparadas e conscientes. Promova treinamentos regulares em segurança da informação, simule cenários de ataque na nuvem para educar desenvolvedores e administradores sobre as melhores práticas.
Diante da escassez de profissionais, considere parcerias com consultorias especializadas ou provedoras de serviços gerenciados de segurança em nuvem para suplementar sua equipe.
No contexto brasileiro, essas lições têm ressonância direta, dada a rápida digitalização e a pressão regulatória por proteção de dados. A boa notícia é que, conhecendo os riscos, as empresas podem agir: investir em tecnologia de segurança apropriada, melhorar processos internos e desenvolver talentos que darão conta de proteger a nuvem.
Acima de tudo, é fundamental abordar a segurança em nuvem de forma proativa e holística, integrando pessoas, processos e ferramentas. Somente assim é possível colher os frutos da computação em nuvem – escalabilidade, inovação, eficiência – com a mitigação dos perigos que a acompanham.
