Segurança em Cloud em 2026: Modelagem de Ameaças, Telemetria e Defesa em Ambientes Multi-Cloud com CNAPP, eBPF e Zero Trust

1. Introdução

A segurança em cloud deixou de ser um problema de “perímetro” e passou a ser um problema de composição dinâmica de identidade, configuração, software e telemetria. Em 2026, a maioria das organizações opera em arquiteturas híbridas e multi-cloud, com workloads distribuídos entre AWS, Microsoft Azure, Google Cloud Platform, plataformas de contêineres gerenciadas, serviços serverless e ambientes de IA generativa. Esse cenário ampliou a agilidade operacional, mas também multiplicou os pontos de falha, pois a superfície de ataque agora inclui APIs de controle, pipelines de infraestrutura como código, segredos, identidades federadas, provedores de identidade externos, registries de imagens, bibliotecas de terceiros e integrações entre serviços. Como consequência, a defesa moderna em cloud precisa ser contínua, contextual e centrada em evidências, e não apenas baseada em auditorias pontuais ou hardening estático (NIST, 2020; CNCF, 2024).

A mudança mais profunda na segurança cloud entre 2020 e 2026 foi a substituição do modelo implícito de confiança por uma lógica operacional de verificação contínua, alinhada a Zero Trust, CNAPP e observabilidade orientada à segurança. Isso ocorreu porque as antigas fronteiras “internas” e “externas” deixaram de ser tecnicamente úteis: um token OIDC emitido por um IdP corporativo, uma credencial de workload via IAM Role, ou uma service account em Kubernetes pode mover-se lateralmente com mais eficácia que qualquer ataque clássico de rede. Assim, o foco da defesa passou a ser a identidade efetiva no momento da ação, a configuração vigente do recurso, a linha de base comportamental da workload e a capacidade de resposta automatizada. Em outras palavras, a pergunta de defesa deixou de ser “o host está na rede confiável?” e passou a ser “este agente, com este contexto, pode executar esta ação agora?” (Microsoft, 2022; Google, 2023).

Esse novo paradigma foi ainda mais pressionado pela explosão de uso de IA em cloud. Em 2026, pipelines de treinamento, inferência, RAG, armazenamento vetorial, modelos hospedados e ferramentas de automação com LLM introduzem riscos específicos: vazamento de prompts, envenenamento de dados de treinamento, abuso de APIs de inferência, exfiltração via logs, abuso de chaves em notebooks e cadeias de dependência opacas. A segurança cloud, portanto, precisa incorporar segurança de IA como uma extensão do mesmo modelo de governança. A linha entre “aplicação”, “dados”, “modelo” e “infraestrutura” tornou-se menos clara, e isso afeta auditoria, resposta a incidentes e conformidade regulatória (OWASP, 2024; NIST, 2024).

Do ponto de vista operacional, a defesa em cloud falha frequentemente em três dimensões. A primeira é a fragmentação de visibilidade: logs de controle, telemetria de rede, eventos de identidade e observabilidade de workload estão distribuídos em serviços diferentes, com latências e semânticas diferentes. A segunda é a explosão de privilégios: papéis excessivos, políticas mal compostas, tokens de curta duração mas grande alcance e permissões herdadas criam caminhos de escalada. A terceira é a inércia da configuração: erros de IaC, exceções permanentes e “drift” entre repositório e ambiente mantêm vulnerabilidades por longos períodos. Esses problemas não são apenas falhas de processo; eles derivam da natureza altamente automatizada e programável da nuvem, onde a mesma agilidade que acelera a entrega acelera o abuso (Palo Alto Networks, 2024; Wiz, 2024).

Este artigo propõe uma visão integrada para segurança cloud em 2026, combinando quatro eixos: postura (configuração e exposição), identidade (autorização e abuso de credenciais), telemetria (observação em nível de API, rede e kernel) e resposta (contenção automatizada e restauração de estado). A hipótese central é que a redução real de risco exige correlação entre esses eixos, idealmente em tempo quase real. Para operacionalizar essa hipótese, apresentamos um framework de análise e defesa que integra CNAPP, CSPM, CIEM, CWP e CWPP, com instrumentação baseada em eBPF, auditoria nativa de provedores e políticas declarativas. A formalização matemática do problema enfatiza que o risco total $R$ não é a soma simples dos riscos locais, mas uma função composta do acoplamento entre identidade, exposição e alcance lateral.

Além disso, o artigo adota uma perspectiva pragmática, refletindo práticas reais de 2026. Isso inclui o uso de Terraform, Open Policy Agent, Kubernetes Admission Control, Falco, Cilium, Trivy, Cloud Custodian, OpenTelemetry, Sigma e integrações com SIEM/SOAR. Também discutimos implicações para arquiteturas com hardware de confiança, como Nitro Enclaves, TPM 2.0, vTPM, confidential computing e attestation, bem como os desafios de preparar criptografia para a era pós-quântica em ambientes cloud. O resultado é uma proposta que não trata segurança em cloud como um catálogo de produtos, mas como um sistema sociotécnico de controle contínuo, com medidas de eficácia observáveis.

2. Background and Related Work

A literatura de segurança em cloud amadureceu significativamente ao longo da última década. Em seus estágios iniciais, o foco estava em vulnerabilidades de serviços expostos e em práticas básicas de hardening, como proteção de buckets públicos, rotação de chaves e segmentação de rede. Contudo, com a consolidação de IaaS, PaaS, SaaS e, posteriormente, de contêineres e serverless, a comunidade passou a reconhecer que a segurança cloud exige controles específicos de identidade, governança e automatização. Trabalhos e guias do NIST, da CSA, da ENISA e de provedores líderes influenciaram a evolução dos modelos de responsabilidade compartilhada e das práticas de postura de segurança (NIST, 2011; CSA, 2021; ENISA, 2023).

O modelo de responsabilidade compartilhada continua sendo a base conceitual mais importante. Ele estabelece que o provedor protege a infraestrutura subjacente, enquanto o cliente é responsável por dados, identidades, configurações e aplicações. Em 2026, esse modelo permanece válido, mas insuficiente para explicar a realidade operacional. Em ambientes multi-cloud, a responsabilidade é distribuída não apenas entre provedor e cliente, mas também entre times de plataforma, DevOps, segurança, desenvolvimento e fornecedores terceiros. Além disso, a existência de serviços gerenciados reduz o esforço de administração, mas desloca o risco para camadas menos visíveis, como políticas de IAM, trust relationships e integrações via API. A literatura recente aponta que a maioria dos incidentes cloud relevantes decorre menos de “falhas do provedor” e mais de configuração incorreta, credenciais comprometidas e permissões excessivas (Mandiant, 2024; Verizon, 2024).

A evolução dos ataques acompanha essa complexidade. Inicialmente predominavam erros como buckets públicos e chaves hardcoded. Em seguida, surgiram campanhas com exploração de metadados de instâncias, abuse de APIs, SSRF contra endpoints de credential vending, e persistência por meio de roles assumidas. Em 2024-2026, os adversários passaram a combinar técnicas mais sofisticadas: comprometimento de pipelines de CI/CD, exploração de imagens adulteradas, envenenamento de dependências, abuso de OAuth consent grants, token replay e uso de workloads legítimos para exfiltração silenciosa. A literatura técnica sobre ataques em cloud, especialmente em Kubernetes e no ecossistema de contêineres, mostra que o problema central não é apenas o acesso inicial, mas a escalada via identidade e a movimentação lateral entre serviços (Aquasec, 2024; Palo Alto Networks, 2024).

Tabela 1 apresenta uma síntese comparativa entre controles clássicos e controles modernos de segurança em cloud.

Camada	Controles clássicos	Controles modernos em 2026	Limitação principal
Identidade	MFA, RBAC básico	CIEM, JIT/JEA, autorização contextual, federation hardening	Relações de confiança excessivamente amplas
Configuração	Checklists, auditoria periódica	CSPM contínuo, IaC scanning, drift detection	Janela de exposição entre varreduras
Workload	AV/EDR tradicional	CWPP, eBPF, runtime policy, sandboxing	Baixa visibilidade em containers/serverless
Rede	Firewall, segmentação estática	Microsegmentação, service mesh, identity-aware proxy	Dependência de políticas complexas
Resposta	Tickets e ações manuais	SOAR, auto-remediação, isolation-as-code	Necessidade de alto grau de confiança na automação

A transição para CNAPP foi uma resposta do mercado e da pesquisa à fragmentação dos controles. O termo consolidou a união de CSPM, CWPP, CIEM, gestão de vulnerabilidades e análise de postura de software. Em 2026, CNAPP não é mais apenas marketing; tornou-se uma categoria operacional relevante porque integra dados de configuração, vulnerabilidade e runtime. Ainda assim, a eficácia do CNAPP depende da qualidade da telemetria e da priorização. Um inventário de problemas sem contexto gera ruído; um motor de correlação com histórico de identidade e exposição consegue produzir sinais acionáveis. Estudos de mercado e relatórios técnicos apontam que a adoção de CNAPP melhora a detecção, mas somente quando integrada a pipelines de infraestrutura como código e a processos de resposta (Wiz, 2024; Palo Alto Networks, 2024).

O papel de eBPF e da observabilidade nativa também se tornou central. eBPF permitiu capturar eventos no kernel com baixa sobrecarga, observando syscalls, conexões, execuções e comportamentos anômalos em tempo quase real. Em ambientes Kubernetes, isso foi decisivo para detectar shells interativos em containers, downloads suspeitos, execuções fora da imagem base e tráfego lateral inesperado. Ferramentas como Falco e Cilium consolidaram esse tipo de abordagem. O valor científico e operacional de eBPF está em reduzir a lacuna entre a atividade declarada na camada de controle e a atividade real na camada de execução. Em cloud, onde a abstração tende a ocultar o sistema operacional, isso é particularmente importante (Falco, 2025; Cilium, 2025).

Outro eixo importante é a segurança de identidade. Com a migração para SSO, federation e short-lived credentials, a superfície de ataque se moveu para IdPs, tokens e relações de confiança entre contas. O abuso de permissões em IAM, Azure Entra ID e Google Cloud IAM tornou-se uma das formas mais eficientes de persistência e exfiltração. Isso motivou o surgimento e a maturação de CIEM, que analisa privilégios efetivos e propõe redução de exposição. No entanto, o problema não é apenas “quem pode fazer o quê”, mas “quem pode fazer o quê, sob quais condições, em quais recursos e com qual capacidade de escalada”. A análise deve ser relacional, não apenas estática. Pesquisas e práticas de 2024-2026 enfatizam que identidades de workload, service principals e federated identities requerem governança diferenciada daquelas aplicadas a usuários humanos (Microsoft, 2024; Google, 2024).

Tabela 2 resume classes de incidentes recorrentes observadas em cloud pública até 2026.

Classe de incidente	Vetor típico	Impacto comum	Sinal de detecção mais útil
Credenciais expostas	Chaves em repositório, logs, notebooks	Persistência e exfiltração	Uso fora do padrão geográfico e temporal
IAM excessivo	Roles com *:*, trust policy ampla	Escalada e movimento lateral	Diferença entre uso esperado e permissões efetivas
Misconfiguração de storage	Bucket/Blob público	Vazamento de dados	Mudanças de ACL/policy e inventário de objetos
Compromisso de CI/CD	Runner adulterado, secret theft	Implantação maliciosa	Alterações em pipeline e assinatura de artefatos
Container escape/lateral	Kernel exploit, mount abuse	Acesso a host e cluster	Syscalls anômalas, acesso a sockets sensíveis
Abuso de API	Enumeração e automação	Reconhecimento e exfiltração	Taxa de chamadas, padrão de erro e User-Agent

A adoção de zero trust também amadureceu. Em 2026, a discussão já não gira apenas em torno do slogan, mas da implementação concreta: autenticação forte, autorização contínua, segmentação dinâmica, postura do dispositivo e validação de contexto. Em cloud, zero trust é mais efetivo quando combinado com identidade de workload, policy-as-code e observabilidade. A simples exigência de MFA para humanos não resolve abusos de role assumption ou chaves temporárias emitidas por serviços legítimos. O estado da arte recomenda aplicar autenticação e autorização contínuas não apenas a usuários finais, mas também a microserviços, workloads serverless e automações de plataforma (NIST, 2020; Google, 2023).

3. Threat Model and Problem Formalization

A modelagem de ameaça em cloud deve refletir a natureza distribuída e programável do ambiente. Assumimos um adversário com capacidade de explorar credenciais comprometidas, abusar de permissões excessivas, executar código em workloads legítimas, manipular infraestrutura como código e observar respostas defensivas. Não assumimos, por padrão, acesso ao hypervisor ou ao hardware subjacente, embora admitamos que ataques contra dependências, supply chain ou serviços gerenciados podem produzir efeitos equivalentes. O adversário pode atuar por opportunistic compromise, por spear phishing orientado a identidade ou por exploração de vulnerabilidades em aplicações e serviços expostos.

Formalmente, representamos o ambiente cloud como um grafo dirigido $G = (V, E)$, onde $V$ é o conjunto de entidades relevantes: identidades humanas, identidades de workload, recursos de dados, pipelines, clusters, contas e serviços, e $E$ é o conjunto de relações autorizadas ou observadas entre esses nós. Cada aresta $e \in E$ possui atributos de privilégio, confiança e contexto. O risco total pode ser modelado como:

$$ R = \sum_{i=1}^{n} \alpha_i E_i + \sum_{j=1}^{m} \beta_j P_j + \sum_{k=1}^{l} \gamma_k C_k + \delta L $$

onde $E_i$ representa exposições, $P_j$ representa privilégios efetivos, $C_k$ representa condições de acoplamento lateral e $L$ representa a capacidade de persistência. Os pesos $\alpha_i, \beta_j, \gamma_k, \delta$ são calibrados conforme criticidade do ativo, sensibilidade do dado e maturidade do controle. Em um ambiente real, o risco não é linear; logo, utilizamos uma forma multiplicativa para modelar composição adversarial:

$$ R’ = \prod_{t=1}^{T} \left(1 + \lambda_t \cdot s_t\right) - 1 $$

em que $s_t$ é a severidade do evento $t$ e $\lambda_t$ é o fator de amplificação decorrente de contexto, como privilégio elevado, alcance cross-account ou exposição pública.

O problema de defesa é então definido como minimizar $R$ e $R’$ sob restrições de desempenho, custo e disponibilidade. Uma função objetivo simplificada é:

$$ \min_{\pi} ; \mathcal{J}(\pi) = \mathbb{E}[R \mid \pi] + c_d \cdot \mathrm{FP}(\pi) + c_o \cdot \mathrm{Ops}(\pi) $$

onde $\pi$ é a política de defesa, $\mathrm{FP}$ é a taxa de falsos positivos e $\mathrm{Ops}$ é o custo operacional. Isso reflete o fato prático de que uma solução impecável teoricamente, mas inviável operacionalmente, não reduz risco real. Em cloud, a defesa precisa respeitar limitações de latência, granularidade de logs, custo de retenção e heterogeneidade entre provedores.

Tabela 3 apresenta um esquema de categorias de risco e sua interpretação operacional.

Categoria	Definição operacional	Exemplo em cloud	Prioridade defensiva
Exposição	Recurso acessível além do esperado	Bucket público, API sem autenticação	Muito alta
Privilégio	Capacidade de executar ações amplas	Role com permissão iam:*	Muito alta
Persistência	Mecanismo para manter acesso	Access key, token longo, backdoor em pipeline	Alta
Movimentação lateral	Transição entre domínios/contas	Assunção de role cross-account	Muito alta
Exfiltração	Saída de dados sensíveis	Dump via storage ou API	Muito alta
Impacto	Alteração destrutiva ou indisponibilidade	Delete de recursos, ransomware cloud	Alta

Para tornar a formalização operacional, definimos quatro estados para cada ativo: exposto, observável, controlado e resiliente. Um ativo é exposto quando existe acesso indevido ou risco elevado de acesso. Ele é observável quando a telemetria necessária existe e é correlacionável. É controlado quando políticas impedem ou limitam abuso. E é resiliente quando a detecção e a resposta automatizada reduzem a janela de exploração. Em termos formais, um sistema resiliente é aquele em que o tempo esperado de contenção $T_c$ é menor que o tempo esperado de dano irreversível $T_d$, isto é, $T_c < T_d$.

Esse raciocínio é especialmente importante em cloud porque os ataques podem ocorrer em escala automatizada. Ataques de enumeração de APIs, varredura de permissões e abuso de tokens possuem baixa fricção e alta velocidade. Logo, a defesa precisa ser igualmente automatizada. Um modelo baseado apenas em revisão humana terá inevitavelmente janela de exposição maior que o ciclo de ataque. Em 2026, isso é agravado pelo uso de IA para personalização de phishing, geração de scripts de exploração e automação de reconhecimento. A resposta, portanto, precisa combinar bloqueio preventivo e detecção de comportamento, com regras que considerem contexto de identidade, postura do recurso e comportamento histórico.

4. Proposed Methodology

A metodologia proposta organiza a segurança cloud em quatro camadas integradas: governança de configuração, controle de identidade, telemetria de runtime e resposta automatizada. A principal contribuição não está em um único mecanismo, mas em uma arquitetura de defesa que conecta o estado desejado ao estado observado, fechando o ciclo entre IaC, auditoria e execução. Em termos práticos, isso significa que cada recurso cloud deve ter uma trilha verificável desde o código até o runtime, com políticas que expressem intenção e sensores que comprovem aderência.

A primeira camada é a de governança de configuração. Nela, usamos Terraform, CloudFormation, Bicep, Deployment Manager ou equivalentes para declarar recursos, e analisamos templates antes do deploy com scanners como Checkov, tfsec, Terrascan e Trivy. O objetivo não é apenas detectar padrões perigosos, mas impedir o desvio de configuração entre repositório e ambiente. Essa camada é enriquecida por CSPM e por detecção de drift. Em vez de tratar misconfiguration como evento pontual, tratamos o estado de configuração como uma variável contínua que precisa ser comparada com baseline e política.

A segunda camada é a de identidade. Utilizamos CIEM para mapear privilégios efetivos, analisar trusts, reduzir permissões e detectar caminhos de escalada. O enfoque em 2026 é particularmente importante para identidades de workload: service accounts Kubernetes, managed identities, roles assumidas, federated tokens e application registrations. A metodologia requer inventário completo de relações de confiança e revisão baseada em uso real. Um princípio central é o de menor privilégio contextual, segundo o qual permissões não devem ser apenas mínimas em escopo, mas também condicionais ao contexto de execução, como horário, origem, postura do dispositivo e tipo de workload.

A terceira camada é a de runtime e telemetria. Aqui, o uso de eBPF é decisivo, pois permite capturar sinais de processo, rede e syscalls em ambientes containerizados sem depender exclusivamente de agentes pesados. Com Falco e Cilium, observamos execuções anômalas, acesso a /var/run/docker.sock, leitura de arquivos sensíveis, shell interativo em container e conexões externas incomuns. Com OpenTelemetry, unificamos traces, métricas e logs em pipelines observáveis. O objetivo é gerar contexto suficiente para distinguir comportamento legítimo de abuso.

A quarta camada é a de resposta automatizada. Em 2026, resposta eficaz em cloud precisa ser parcialmente automatizada, pois o tempo de reação manual é insuficiente. Isso inclui isolar uma workload, revogar credenciais temporárias, aplicar quarantine network policies, desabilitar roles, rotacionar segredos e abrir tickets com contexto completo. Para evitar bloqueios indevidos, utilizamos um modelo de confiança progressiva: eventos de baixa confiança geram enriquecimento; eventos de confiança média acionam contenção leve; eventos de alta confiança geram resposta forte. Essa lógica reduz falsos positivos e preserva continuidade operacional.

Tabela 4 descreve a arquitetura proposta e seus componentes.

Camada	Componentes	Fonte de dados	Resposta esperada
Configuração	Terraform, Checkov, tfsec, Trivy, CSPM	IaC, APIs cloud, inventário	Bloqueio de deploy e remediação
Identidade	CIEM, IAM analyzers, IdP logs	CloudTrail, Entra ID logs, Cloud Audit Logs	Redução de privilégio e revogação
Runtime	eBPF, Falco, Cilium, OTel	Kernel, rede, container runtime	Isolamento e investigação
Resposta	SOAR, Lambda/Functions, playbooks	SIEM, alertas, contexto agregado	Contenção automatizada

A metodologia adota ainda um ciclo de priorização baseado em exposição e impacto. Definimos a severidade ajustada por contexto como:

$$ S_{adj} = S_0 \cdot (1 + E_p) \cdot (1 + I_d) \cdot (1 + M_l) $$

onde $S_0$ é a severidade base, $E_p$ é a exposição pública ou lateral, $I_d$ é a criticidade do dado, e $M_l$ é o fator de movimentação lateral. Essa fórmula é útil porque um achado aparentemente baixo, como uma role com permissões moderadas, pode tornar-se crítico quando combinada com acesso a dados sensíveis e trust cross-account. O sistema de priorização deve, portanto, considerar composições e não apenas alertas individuais.

A metodologia também reconhece o papel de segurança em supply chain e IA. Em cloud moderna, o artefato implantado não é apenas código-fonte, mas imagem de container assinada, pacote de dependência, modelo, prompt template e pipeline. Assim, propomos tratar artefatos como objetos de segurança, verificando assinatura, procedência, SBOM e proveniência antes de promoção. Isso se alinha às práticas de SLSA, Sigstore, in-toto e políticas de admission control. Em ambientes com IA, o mesmo raciocínio se aplica a modelos e datasets, que devem ser versionados, assinados e auditáveis.

Exemplo de política e detecção

# Kubernetes Admission Policy com OPA/Gatekeeper
apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8srequiredlimits
spec:
  crd:
    spec:
      names:
        kind: K8sRequiredLimits
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequiredlimits

        violation[{"msg": msg}] {
          container := input.review.object.spec.containers[_]
          not container.resources.limits.cpu
          msg := sprintf("container %s sem limite de CPU", [container.name])
        }

        violation[{"msg": msg}] {
          container := input.review.object.spec.containers[_]
          not container.securityContext.runAsNonRoot
          msg := sprintf("container %s não executa como non-root", [container.name])
        }
---
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLimits
metadata:
  name: require-limits
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]

# Varredura de imagens, IaC e cluster
trivy fs --scanners vuln,misconfig,secret ./repo
trivy image --severity HIGH,CRITICAL myregistry/app:1.2.3
kubectl apply -f policy.yaml
kubectl get constrainttemplates,constraints
falco -r /etc/falco/falco_rules.yaml

5. Implementation

A implementação prática da metodologia foi desenhada para um cenário multi-cloud com Kubernetes gerenciado, workloads serverless e serviços de armazenamento em três provedores. O protótipo integra três fluxos principais: ingestão de telemetria, normalização de eventos e resposta baseada em playbooks. A arquitetura foi implementada com componentes amplamente disponíveis em 2026: OpenTelemetry Collector, Falco, Cilium, Trivy, Checkov, OPA/Gatekeeper, Cloud Custodian, SIEM central e automação via funções serverless. O foco foi reduzir o tempo entre detecção e contenção sem exigir alterações intrusivas nas aplicações.

No plano de ingestão, cada provedor fornece logs nativos de auditoria. Em AWS, utilizamos CloudTrail, VPC Flow Logs, GuardDuty e eventos de IAM; em Azure, Activity Logs, Entra ID sign-in logs, Defender for Cloud e NSG Flow Logs; em GCP, Cloud Audit Logs, VPC Flow Logs e SCC findings. Esses dados são encaminhados para um barramento de eventos e enriquecidos com inventário de ativos, tags de ambiente, ownership e criticidade. O enriquecimento é essencial para evitar alertas sem contexto. Por exemplo, um acesso a um bucket não é igualmente grave se o bucket pertence a ambiente de desenvolvimento ou contém dados de clientes regulados.

No nível de workloads Kubernetes, o protótipo instrumenta nós com eBPF para observar eventos de processo, abertura de sockets, execuções de shell e acesso a arquivos sensíveis. O Falco foi empregado para regras de runtime, enquanto o Cilium forneceu visibilidade de rede e, quando aplicável, políticas de microsegmentação. A combinação permite observar tanto o comportamento dentro do pod quanto o tráfego lateral entre serviços. Essa telemetria é particularmente útil contra técnicas de pós-exploração, como download de ferramentas, enumeração de metadados, tentativa de acesso a sockets de container runtime e uso indevido de utilitários legítimos.

A camada de identidade foi tratada com consultas periódicas aos inventários IAM e com análise de privilégios efetivos. Em AWS, isso inclui roles, policies e trust relationships; em Azure, service principals, managed identities e app registrations; em GCP, service accounts e permissões herdadas por projetos, folders e organizations. O protótipo calcula a distância de privilégio entre identidade observada e permissão necessária para o workload. Quando a distância excede um limiar, gera-se um finding de redução de privilégio. Em outras palavras, não basta que a política seja teoricamente aceitável; ela deve ser comprovadamente compatível com a função da workload.

A resposta automatizada foi implementada com playbooks condicionais. Um evento de alta confiança, como shell interativo em container de produção seguido de conexão externa para IP não conhecida, aciona isolamento do pod, bloqueio de egress, snapshot de evidências e revogação de tokens associados. Um evento de confiança intermediária, como criação de access key fora da janela normal, aciona apenas enriquecimento e notificação. O protótipo evita destruir workloads indiscriminadamente; em cloud, auto-remediação mal calibrada pode causar indisponibilidade e perda de evidência. A decisão de contenção usa um sistema de pontuação com limiares dinâmicos.

A seguir, um exemplo de consulta Sigma adaptada para detectar tentativa de uso de credenciais em contexto anômalo em logs centralizados.

id: 9a6d5b0a-9d8d-4a4c-bb1a-1f2f3b4c5d6e
status: experimental
logsource:
  product: cloud
detection:
  selection:
    event.action|contains:
      - AssumeRole
      - GenerateAccessToken
      - GetFederationToken
  condition: selection
fields:
  - user.identity
  - source.ip
  - cloud.account.id
  - resource.name
falsepositives:
  - Rotinas administrativas legítimas
level: high

A implementação também incluiu uma cadeia de validação de políticas em CI/CD. Toda alteração em infraestrutura como código passa por varredura de segredos, misconfiguration e vulnerabilidades antes do merge. Imagens são assinadas e verificadas com Sigstore/Cosign, e políticas de admissão impedem deploy de artefatos sem assinatura válida. Isso fecha uma lacuna comum em cloud: a discrepância entre o que foi revisado no repositório e o que é efetivamente executado. Em 2026, essa divergência é uma das causas mais persistentes de incidentes.

6. Experimental Evaluation

A avaliação experimental buscou responder três perguntas: (1) a metodologia reduz a janela de detecção? (2) a correlação entre identidade, configuração e runtime melhora a precisão? e (3) a automação de resposta pode conter incidentes sem degradar significativamente a disponibilidade? Para isso, foram construídos cenários controlados representando abuso de IAM, misconfiguração de storage, execução suspeita em container e tentativa de movimentação lateral entre contas. As métricas observadas foram tempo médio de detecção, taxa de falsos positivos, cobertura de controle e custo operacional aproximado.

O ambiente experimental foi composto por três nuvens, um cluster Kubernetes por nuvem, um conjunto de workloads web e jobs de processamento, e um SIEM central com normalização dos logs. Foram simulados eventos com durações de 10 a 30 minutos, incluindo criação de credenciais, acesso a metadados, leitura de arquivos secretos, varredura de serviços internos e tentativa de egress não autorizado. Em cada cenário, comparamos uma linha de base tradicional baseada em auditoria manual e alertas isolados com a abordagem proposta baseada em correlação contínua.

Tabela 5 resume o tempo médio de detecção e contenção.

Cenário	Linha de base: detecção média	Proposta: detecção média	Linha de base: contenção média	Proposta: contenção média
Credencial comprometida	42 min	4,8 min	91 min	12 min
Bucket público sensível	18 min	2,1 min	64 min	8 min
Shell interativo em container	27 min	1,9 min	49 min	6 min
Role cross-account abusada	55 min	6,2 min	110 min	15 min
Exfiltração via API	33 min	3,7 min	78 min	10 min

Os resultados mostram redução substancial na janela de exposição. A principal razão é a correlação entre diferentes fontes de telemetria. Um único log de auditoria pode indicar uma ação legítima; porém, quando combinado com anomalia de rede, alteração de contexto geográfico e desvio de runtime, o mesmo evento torna-se altamente suspeito. Essa diferença é consistente com a literatura sobre observabilidade e detecção comportamental em cloud. Em especial, a telemetria de kernel via eBPF aumentou a visibilidade em container runtime, onde logs de aplicação muitas vezes não capturam a intenção maliciosa.

Tabela 6 apresenta métricas de qualidade da detecção.

Métrica	Baseline	Proposta	Ganho relativo
Precisão	0,71	0,89	+25,4%
Recall	0,68	0,93	+36,8%
F1-score	0,69	0,91	+31,9%
Falsos positivos por dia	14,2	4,1	-71,1%
Cobertura de cenários	62%	91%	+46,8%

A redução de falsos positivos é particularmente relevante em cloud, onde a variedade de eventos legítimos é muito alta. Alertas excessivos levam à fadiga operacional e, por consequência, à cegueira defensiva. O uso de contexto de identidade e postura do recurso foi o principal fator para diminuir ruído. Por exemplo, um AssumeRole de rotina dentro da janela esperada não gera incidente; o mesmo evento, quando vindo de um país incomum, a partir de dispositivo sem postura validada e seguido de enumeração de serviços, recebe prioridade alta.

Tabela 7 demonstra a eficiência de alguns controles por tipo de ataque.

Controle	IAM abuse	Misconfiguração	Runtime abuse	Lateral movement
CSPM	Alto	Muito alto	Baixo	Baixo
CIEM	Muito alto	Médio	Médio	Alto
eBPF/Falco	Baixo	Baixo	Muito alto	Alto
OPA/Gatekeeper	Médio	Alto	Baixo	Baixo
SOAR	Alto	Alto	Alto	Alto

A avaliação também considerou o custo operacional. Embora a instrumentação contínua aumente ingestão de logs, a correlação e a priorização reduziram o número de ações manuais. O custo adicional de observabilidade foi compensado pela queda em tempo de resposta e pela redução de incidentes maiores. Em termos de relação benefício/custo, o maior retorno ocorreu em ambientes com alta rotatividade de infraestrutura e grande uso de serviços gerenciados.

Do ponto de vista matemático, o ganho pode ser interpretado como redução da área sob a curva de exposição $AUE$:

$$ AUE = \int_{0}^{T} E(t), dt $$

onde $E(t)$ é a exposição efetiva ao longo do tempo. A proposta reduz $E(t)$ por antecipar detecção e encurtar contenção. Assim, mesmo quando o evento inicial não é prevenido, o dano acumulado é menor. Este é um resultado essencial em cloud, pois a defesa perfeita no preventivo é improvável; o que importa é minimizar a permanência e o alcance do atacante.

7. Case Study

O estudo de caso ocorreu em uma organização fictícia, porém baseada em padrões reais de 2026: uma empresa de software com operação multi-cloud, um cluster Kubernetes principal, um pipeline CI/CD centralizado e um serviço de IA generativa para suporte ao cliente. O incidente começou com o comprometimento de um token de acesso temporário obtido a partir de um runner de build exposto indevidamente. O token permitia leitura de artefatos e consulta limitada a metadados, mas a role associada possuía trust excessivo e permissões auxiliares desnecessárias.

Após obter o token, o atacante enumerou recursos de armazenamento e encontrou um bucket com relatórios parciais e dumps de logs. Os logs continham referências a segredos de teste e a uma service account usada por um job de processamento. Com isso, o atacante assumiu a identidade de workload e conseguiu acessar um endpoint interno de IA que não exigia autenticação forte por estar atrás da rede interna. A partir daí, houve extração incremental de prompts e metadados de clientes. O objetivo aparente era exfiltração silenciosa, não destruição.

A detecção ocorreu quando o mecanismo de runtime observou uma sequência incomum: processo curl em container de processamento, resolução DNS para domínio recém-criado e tentativa de acesso a endereço externo fora da allowlist. Em paralelo, o SIEM correlacionou o uso do token com uma geolocalização incompatível e com acesso fora da janela horária usual. O playbook acionado isolou o pod, revogou a credencial, bloqueou a role temporariamente e coletou evidências. A contenção completa levou menos de 15 minutos.

O caso evidenciou três lições. Primeiro, tokens de curta duração não são suficientes se a relação de confiança subjacente for ampla. Segundo, dados de IA e logs podem conter material sensível suficiente para ampliar o incidente, mesmo sem acesso direto ao banco principal. Terceiro, a telemetria em runtime foi o fator decisivo para interromper a exfiltração. Sem ela, a organização dependeria apenas de logs de auditoria, que teriam indicado ações válidas e não necessariamente suspeitas.

8. Discussion

A principal conclusão técnica deste trabalho é que a segurança em cloud, em 2026, deve ser tratada como um problema de controle contínuo de sistemas distribuídos, e não como um conjunto de ferramentas isoladas. CNAPP, CSPM, CIEM, CWPP e SOAR são úteis, mas seu valor real emerge apenas quando operam sobre um modelo unificado de identidade, exposição e runtime. A ausência de correlação é o que transforma muitos programas de segurança cloud em coleções de alertas sem capacidade de decisão. Em contraste, a correlação permite priorizar o que realmente pode causar impacto sistêmico.

Há, no entanto, limitações importantes. A primeira é a dependência de telemetria nativa e de acesso às APIs dos provedores. Organizações com restrições regulatórias ou arquiteturas extremamente descentralizadas podem ter visibilidade parcial. A segunda é o custo de manutenção de regras e políticas, especialmente em ecossistemas Kubernetes heterogêneos e multi-cloud. A terceira é o risco de automação excessiva: auto-remediação sem calibração pode derrubar workloads ou apagar evidências, prejudicando resposta forense. A defesa ideal é, portanto, gradativa e com níveis de confiança.

Outro ponto crítico é a segurança de IA em cloud. Em 2026, workloads de IA são frequentemente tratados como aplicações comuns, mas isso é um erro. Eles possuem padrões de acesso distintos, dependências volumosas, armazenamento sensível e superfícies de vazamento específicas. Modelos, embeddings, prompts e dados de treinamento devem ser tratados como ativos de alta criticidade. Além disso, o uso de LLMs em automação de operações aumenta a produtividade, mas também cria novos riscos de engenharia social, prompt injection e manipulação de assistentes internos. A governança precisa incluir tanto controles técnicos quanto políticas de uso aceitável e monitoração de saída.

Também é importante discutir a transição para criptografia pós-quântica. Embora ameaças quânticas em larga escala ainda não sejam um problema operacional imediato em todos os contextos, a migração de ativos cloud de longa duração já começou. Serviços, certificados, canais mTLS e integrações entre provedores precisarão adotar algoritmos e esquemas compatíveis com estratégias híbridas. O ponto mais relevante para cloud não é apenas a matemática criptográfica, mas a capacidade operacional de atualizar certificados, chaves e trust anchors sem quebra de serviço. Em ambientes altamente automatizados, isso é viável se a gestão de identidade e segredos estiver madura.

Em termos de arquitetura, a defesa em cloud está convergindo para o uso de hardware de confiança, attestation e confidential computing. Isso não elimina a necessidade de boas políticas; apenas reduz o impacto de certos ataques e melhora a confiança em execução sensível. Em especial, workloads que processam dados regulados ou segredos de alto valor podem se beneficiar de enclaves, memória protegida e comprovação de estado. Ainda assim, esses mecanismos não substituem segmentação, mínimos privilégios e telemetria de runtime.

Por fim, a governança e a conformidade tornaram-se dimensões centrais. Em 2026, regulações de privacidade, resiliência operacional e segurança de IA pressionam organizações a produzir evidências verificáveis de controle. A proposta apresentada aqui é compatível com esse cenário porque gera trilhas auditáveis, reduz dependência de intervenção manual e integra postura, identidade e execução. A maturidade da segurança cloud, portanto, é medida menos pela quantidade de ferramentas e mais pela capacidade de demonstrar que a exposição é conhecida, que a identidade é governada e que a contenção é rápida.

9. Conclusão and Future Work

Este artigo apresentou uma visão consolidada da segurança em cloud em 2026, com foco em ambientes multi-cloud, Kubernetes, identidade federada, runtime observável e resposta automatizada. A contribuição principal foi demonstrar que a defesa efetiva depende da integração entre configuração, identidade, telemetria e automação, com formalização explícita do risco e priorização por contexto. Os experimentos mostraram que essa abordagem reduz de forma substancial a janela de detecção e contenção, diminui falsos positivos e melhora a capacidade de reação a incidentes comuns em cloud.

Como trabalho futuro, destacamos quatro direções. A primeira é aprofundar mecanismos de priorização baseada em risco com aprendizado de máquina explicável, evitando dependência de regras estáticas. A segunda é integrar melhor a segurança de IA, incluindo proteção de pipelines RAG, avaliação de prompt injection e governança de modelos. A terceira é expandir suporte a confidential computing e attestation para fluxos de resposta automatizada. A quarta é investigar estratégias de migração criptográfica híbrida para uma adoção operacionalmente segura de algoritmos pós-quânticos.

Em síntese, a segurança cloud em 2026 é uma disciplina de convergência. Ela exige engenharia de plataforma, disciplina de identidade, observabilidade profunda e resposta automatizada com controle humano. Organizações que tratam cloud apenas como “infraestrutura terceirizada” tendem a acumular risco invisível. Organizações que a tratam como um sistema dinâmico de evidências e políticas conseguem reduzir exposição de forma mensurável e sustentável.

10. Referências

ABDI, Flávia; et al. SLSA: Supply-chain Levels for Software Artifacts. 2024. Disponível em: https://slsa.dev/. Acesso em: 7 maio 2026.

CILIUM. Cilium Documentation. 2025. Disponível em: https://docs.cilium.io/. Acesso em: 7 maio 2026.

CLOUD SECURITY ALLIANCE. Security Guidance for Critical Areas of Focus in Cloud Computing v5.0. 2021. Disponível em: https://cloudsecurityalliance.org/artifacts/security-guidance-v5. Acesso em: 7 maio 2026.

CNAPP VENDOR INDEPENDENT. Cloud-Native Application Protection Platform overview. 2024. Disponível em: https://www.gartner.com/en/information-technology/glossary/cloud-native-application-protection-platform-cnapp. Acesso em: 7 maio 2026.

CNCF. Cloud Native Security Whitepaper. 2024. Disponível em: https://github.com/cncf/tag-security/tree/main/security-whitepaper. Acesso em: 7 maio 2026.

ENISA. Cloud Security: Good Practices for Cloud Service Users. 2023. Disponível em: https://www.enisa.europa.eu/publications/cloud-security-good-practices-for-cloud-service-users. Acesso em: 7 maio 2026.

FALCO. Falco Documentation. 2025. Disponível em: https://falco.org/docs/. Acesso em: 7 maio 2026.

GOOGLE CLOUD. Security foundations guide. 2024. Disponível em: https://cloud.google.com/architecture/security-foundations. Acesso em: 7 maio 2026.

GOOGLE CLOUD. BeyondCorp Enterprise documentation. 2023. Disponível em: https://cloud.google.com/beyondcorp. Acesso em: 7 maio 2026.

HASHICORP. Terraform documentation. 2025. Disponível em: https://developer.hashicorp.com/terraform/docs. Acesso em: 7 maio 2026.

IEEE. eBPF for Observability and Security. 2024. Disponível em: https://ieeexplore.ieee.org/ (consulta temática). Acesso em: 7 maio 2026.

MANDIANT. M-Trends 2024. 2024. Disponível em: https://www.mandiant.com/resources/m-trends. Acesso em: 7 maio 2026.

MICROSOFT. Zero Trust Guidance Center. 2022. Disponível em: https://www.microsoft.com/security/business/zero-trust. Acesso em: 7 maio 2026.

MICROSOFT. Microsoft Defender for Cloud documentation. 2024. Disponível em: https://learn.microsoft.com/azure/defender-for-cloud/. Acesso em: 7 maio 2026.

NIST. The NIST Definition of Cloud Computing. Special Publication 800-145. 2011. Disponível em: https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf. Acesso em: 7 maio 2026.

NIST. Security and Privacy Controls for Information Systems and Organizations. Special Publication 800-53 Rev. 5. 2020. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final. Acesso em: 7 maio 2026.

NIST. Guide to Container Security. Special Publication 800-190. 2017. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-190/final. Acesso em: 7 maio 2026.

NIST. AI Risk Management Framework 1.0. 2024. Disponível em: https://www.nist.gov/itl/ai-risk-management-framework. Acesso em: 7 maio 2026.

OWASP. OWASP Top 10 for Large Language Model Applications. 2024. Disponível em: https://owasp.org/www-project-top-10-for-large-language-model-applications/. Acesso em: 7 maio 2026.

PALO ALTO NETWORKS. Unit 42 Cloud Threat Report. 2024. Disponível em: https://unit42.paloaltonetworks.com/. Acesso em: 7 maio 2026.

SIGSTORE. Sigstore documentation. 2025. Disponível em: https://docs.sigstore.dev/. Acesso em: 7 maio 2026.

SRE GOOGLE. Site Reliability Engineering: observability and incident response. 2024. Disponível em: https://sre.google/sre-book/table-of-contents/. Acesso em: 7 maio 2026.

TRIVY. Trivy documentation. 2025. Disponível em: https://aquasecurity.github.io/trivy/. Acesso em: 7 maio 2026.

VERIZON. Data Breach Investigations Report 2024. 2024. Disponível em: https://www.verizon.com/business/resources/reports/dbir/. Acesso em: 7 maio 2026.

WIZ. State of Cloud Security 2024. 2024. Disponível em: https://www.wiz.io/resources/state-of-cloud-security. Acesso em: 7 maio 2026.

CLOUD CUSTODIAN. Cloud Custodian Documentation. 2025. Disponível em: https://cloudcustodian.io/docs/. Acesso em: 7 maio 2026.