Sumário Executivo
A suposição mais perigosa nos projetos de migração para a nuvem é a de que, junto com a infraestrutura, a responsabilidade pela segurança também é entregue ao provedor. A previsão amplamente citada do Gartner — "até 2025, 99 % das falhas de segurança na nuvem terão origem no cliente" — foi confirmada em campo: a infraestrutura dos grandes provedores de nuvem raramente é quebrada; o que se quebra são as lacunas que o cliente deixa em sua própria área de responsabilidade.[1]
O lado dos custos aponta na mesma direção. Segundo o relatório Cost of a Data Breach 2025 da IBM, o custo médio global de uma violação é de US$ 4,44 milhões; as violações que envolvem dados espalhados por vários ambientes ficam acima da média.[2] A descoberta marcante do relatório de 2023 da IBM completa o quadro: 82 % das violações examinadas envolviam dados armazenados na nuvem.[3] Segundo a pesquisa da Flexera, cerca de 89 % das organizações usam mais de uma nuvem — ou seja, essa superfície de risco não é o problema de um único provedor, mas da inconsistência entre os ambientes.[4]
Este relatório examina a camada mais mal compreendida do modelo de responsabilidade compartilhada: a entrega e a proteção de aplicações. Ele abre a matriz de responsabilidade camada por camada, enumera os erros de configuração da camada de aplicação que mais vemos em campo e analisa por que o desvio de políticas é a lacuna menos percebida em ambientes híbridos.
A Lacuna de Segurança na Nuvem em Números
Participação do cliente nas falhas de segurança na nuvem (previsão do Gartner)
Média global (IBM 2025)
Proporção nas violações examinadas (IBM 2023)
Organizações que usam mais de uma nuvem (Flexera)
O Modelo É Simples; a Interpretação, Não
O modelo de responsabilidade compartilhada em si não é complexo: o provedor é responsável pela segurança da nuvem; o cliente, pela segurança do que está na nuvem. A complexidade nasce do deslocamento da fronteira conforme o modelo de serviço muda — e do fato de as organizações imaginarem essa fronteira mais acima do que ela realmente está. No IaaS, tudo a partir do sistema operacional é do cliente; no PaaS, a plataforma passa ao provedor, mas a configuração da aplicação não; mesmo no SaaS, a classificação de dados, as políticas de acesso e a configuração de identidade permanecem com o cliente.
O ponto crítico é este: seja qual for o seu modelo, o controle do tráfego que chega à sua aplicação — quem acessa, qual requisição é legítima, quais dados saem — nunca passa ao provedor. O provedor pode oferecer ferramentas; a responsabilidade ele não assume.
Matriz de Responsabilidade: Camada por Camada
| Camada | IaaS | PaaS | SaaS |
|---|---|---|---|
| Infraestrutura física e hipervisor | Provedor | Provedor | Provedor |
| Controles de rede | Compartilhada | Compartilhada | Provedor |
| Sistema operacional e middleware | Cliente | Provedor | Provedor |
| Aplicação e políticas de tráfego | Cliente | Cliente | Compartilhada |
| Dados, identidade e configuração de acesso | Cliente | Cliente | Cliente |
Os Erros de Camada de Aplicação Mais Comuns em Campo
Os erros que alimentam as violações na nuvem não são exóticos; os mesmos padrões se repetem. Nas classificações de ameaças da Cloud Security Alliance, configuração incorreta e controle de mudanças insuficiente ocupam o topo há anos.[5] Os que mais vemos em campo:
WAF Esquecido em Modo de Detecção
Políticas de WAF colocadas em modo de detecção durante a migração — "vamos só observar primeiro" — nunca passam ao modo de proteção na correria da entrada em produção. A organização se acha protegida; o WAF apenas gera logs.
Regras de Rede Excessivamente Amplas
Regras amplas de NSG/grupo de segurança abertas para resolver um problema tornam-se permanentes. Exceções 0.0.0.0/0 "temporárias" deixam endpoints de gerenciamento fora do inventário expostos à internet.
Tráfego Sem Criptografia Após a Terminação
O TLS é terminado no balanceador de carga e o tráfego flui em texto claro na rede interna. Na nuvem, o conceito de "rede interna" é mais permeável do que no data center; deixar o tráfego leste-oeste sem criptografia é a lacuna mais silenciosa da sua área de responsabilidade.
Endpoints de API Fora do Inventário
Cada microsserviço migrado para a nuvem gera novos endpoints de API. Endpoints não descobertos e sem schema ficam fora da cobertura do WAF; os atacantes preferem os endpoints não documentados aos documentados.
Desvio de Regras Entre Ambientes
O conjunto de regras ajustado durante anos no on-prem é traduzido "aproximadamente" para outro motor na nuvem. Os dois motores tomam decisões diferentes para a mesma requisição; ninguém sabe qual ambiente está certo.
Configuração de Identidade no Padrão
Acesso condicional, obrigatoriedade de MFA e políticas de sessão são deixados no padrão "para endurecer depois". Na nuvem, a identidade tomou o lugar do perímetro de rede; uma configuração de identidade padrão equivale a uma muralha de perímetro padrão.
A vulnerabilidade híbrida mais comum não é um CVE, é uma falha de processo: maduro no data center, padrão na nuvem. Enquanto a cópia on-prem da mesma aplicação está atrás de uma política de WAF rigorosa, a cópia na nuvem roda por meses com o conjunto básico de assinaturas. Os atacantes escaneiam as duas cópias e entram pela mais fraca. O desvio de políticas não se corrige sozinho com o tempo; cresce enquanto não for medido.
O Custo Real da Complexidade Híbrida
Operar dois motores WAF distintos não significa apenas duas licenças. Significa duas linguagens de regras, duas listas de exceções, dois processos de teste, dois conjuntos de evidências de auditoria e duas especializações separadas. A equipe de segurança projeta cada mudança duas vezes, testa duas vezes, documenta duas vezes. Essa carga cognitiva se manifesta exatamente nos momentos mais críticos — durante a resposta a incidentes: a resposta à pergunta de qual regra estava ativa em qual ambiente leva horas, não minutos.
No lado da auditoria, o custo é ainda mais visível. PCI DSS, KVKK/GDPR e as regulamentações setoriais exigem evidências de auditoria para cada ambiente dentro do escopo. Comprovar a mesma proteção de duas formas diferentes em dois produtos diferentes multiplica o tempo de preparação para auditorias; os achados de inconsistência nascem, na maioria das vezes, das diferenças de interpretação entre os dois produtos.
O multicloud amplia esse quadro de forma multiplicativa, não linear. Os dados da Flexera mostram que a grande maioria das organizações usa mais de uma nuvem;[4] cada novo ambiente traz um novo conjunto de serviços nativos de segurança e uma nova linguagem de configuração. À medida que o número de ambientes cresce, a afirmação "a mesma proteção em todos os ambientes" se torna indefensável, a menos que seja construída com base em políticas, e não em ferramentas.
Implicações Defensivas
Faça o Inventário dos Fluxos de Dados
Qual aplicação está em qual ambiente, quais dados ela toca, quem inspeciona seu tráfego? Sem inventário, a matriz de responsabilidade fica no papel.
Documente a Matriz de Responsabilidade
Para cada modelo de serviço, documente explicitamente a fronteira provedor/cliente e não deixe nenhuma camada sem dono. Confirme com um compromisso por escrito a suposição de que "o provedor cuida disso".
Estabeleça um Plano Único de Políticas
Execute o mesmo conjunto de controles — o mesmo motor WAF, a mesma linguagem de regras, o mesmo processo de exceções — em todos os ambientes. Quando a tradução de regras desaparece, o policy drift é impedido estruturalmente.
Garanta Criptografia e Visibilidade de Ponta a Ponta
Imponha o TLS não apenas na borda, mas também no tráfego leste-oeste; inspecione o tráfego criptografado sem deixar pontos cegos.
Valide Continuamente
Teste a equivalência de políticas continuamente, não em uma auditoria anual: a mesma requisição deve receber a mesma decisão em todos os ambientes. Um desvio deve ser um alarme, não um achado de auditoria.
A Abordagem TR7: A Mesma Proteção em Todos os Ambientes
A resposta do TR7 a esse quadro é executar a mesma plataforma em todos os ambientes:
A Mesma Imagem no Azure Marketplace
A plataforma virtual TR7 é oferecida como imagem pronta no Azure Marketplace; o mesmo motor do hardware roda na nuvem.
Portabilidade de Políticas
Regras de WAF, perfis SSL/TLS e políticas de acesso são levados entre os ambientes sem tradução de regras; uma única lista de exceções, um único conjunto de evidências de auditoria.
Portabilidade de Licenças
As licenças são vinculadas à organização, não à plataforma; acompanham a carga de trabalho entre o Azure, o GCP e os hipervisores suportados.
Gerenciamento de Tráfego Híbrido
O GTM faz o roteamento entre os lados on-prem e nuvem com base em saúde, geografia e latência; estabelece a espinha dorsal da migração gradual.
Referências e Fontes
Fonte da previsão de que "até 2025, 99 % das falhas de segurança na nuvem terão origem no cliente". https://www.gartner.com/smarterwithgartner/is-the-cloud-secure
Fonte primária para o custo médio global de violação (US$ 4,44 milhões) e os detalhamentos de custo por ambiente. https://www.ibm.com/reports/data-breach
Fonte da descoberta de que 82 % das violações examinadas envolviam dados armazenados na nuvem.
Pesquisa anual sobre as taxas de adoção de multicloud e as estratégias corporativas de nuvem. https://www.flexera.com/blog/cloud/cloud-computing-trends-flexera-state-of-the-cloud-report/
Classificação de ameaças em que configuração incorreta e controle de mudanças insuficiente ocupam o topo. https://cloudsecurityalliance.org/research/top-threats
Documentação oficial das fronteiras de responsabilidade provedor/cliente por modelo de serviço. https://learn.microsoft.com/azure/security/fundamentals/shared-responsibility
A Mesma Proteção em Todos os Ambientes
Você não precisa reconstruir a camada de segurança na migração para a nuvem. O TR7 leva as políticas de proteção e entrega do seu data center para o Azure com o mesmo motor; oferece um plano único de políticas, gerenciamento único e um único conjunto de evidências de auditoria.
Explorar a Solução WAAP