Descoberta de Ativos em Ambientes Multi-Cloud

Nota 01 da subseção 03 do capítulo 21, que aplica os princípios de EASM ao ambiente de nuvem em múltiplos provedores.
O foco é o inventário contínuo como fundamento do CTEM: sem saber o que existe, nenhuma etapa posterior de priorização tem base sólida.
Dialoga com a nota de IOE do capítulo 03, com a correlação de CSPM desta subseção e com o controle DAT de coleta da seção 15.

1. Contexto e Posicionamento na Biblioteca

O EASM clássico observa a organização de fora para dentro, com varredura e fontes públicas. Em nuvem, o ponto de observação muda de lado: o provedor entrega APIs que descrevem cada recurso da conta, e a descoberta passa a ser um problema de consulta sistemática e de governança de acesso às APIs, e não de dedução externa. Essa mudança é vantajosa para o defensor, porque o inventário ganha precisão de configuração que nenhuma varredura externa alcança, e perigosa, porque a conta que ninguém cadastrou no programa não é consultada por ninguém e vira o ponto cego clássico do ambiente multi-cloud.

Esta nota é a base material da subseção de EASM e cloud security: ela produz o inventário contínuo que a nota de correlação com CSPM consome, e alimenta o grafo de ataque da subseção de supply chain com nós e arestas de identidade e rede. O capítulo 08 já tratou de hunting em cloud e SaaS do ponto de vista da caça em telemetria; aqui o objeto é anterior, a existência e o conhecimento dos ativos. O objetivo prático é que o leitor saia daqui com o desenho de um pipeline de descoberta que cobre AWS, Azure e GCP, trata ativos efêmeros sem gerar ruído infinito e unifica o resultado num inventário único consultável.

2. Por que a Descoberta Multi-Cloud é Diferente

Três características da nuvem rompem o modelo de inventário periódico herdado do datacenter. A primeira é a velocidade de mudança: um recurso existe por quarenta minutos num pipeline de CI e desaparece, e qualquer inventário com cadência diária registra apenas ruído de reconciliação. A segunda é a escala horizontal: contas e assinaturas se multiplicam por projeto, por time e por região, e o número de unidades de administração cresce mais rápido que a equipe de segurança. A terceira é a heterogeneidade de modelos: cada provedor tem seu próprio conceito de identidade, de rede e de recurso, e comparar uma VM da AWS com uma instância do Azure e um Deployment do GCP exige camada de normalização que o datacenter nunca precisou.

O resultado prático dessas três forças é que o inventário manual, ou mesmo semestral, deixa de ter valor: ele descreve um ambiente que não existe mais no momento da leitura. A descoberta em nuvem precisa ser contínua, orientada a eventos quando possível e orientada a consulta em janela curta quando não, e precisa assumir que o estado verdadeiro é aquele descrito pelas APIs do provedor no momento da coleta. Toda outra fonte, o scanner, o CMDB e a planilha do time de plataforma, é camada de reconciliação sobre a API, e não fonte primária.

Existe ainda a diferença de acesso que separa nuvem do datacenter tradicional: a coleta em nuvem é agentless, pois o provedor descreve o recurso sem instalar nada nele, o que reduz atrito de deploy e garante cobertura de recursos recém-criados. O contraponto é que a coleta enxerga o estado declarado, e não o estado em execução, e por isso processos comprometidos dentro de uma máquina limpa só aparecem na telemetria de endpoint. A divisão de trabalho correta é a API do provedor respondendo o que existe e como está configurado, e o EDR e o SIEM respondendo o que aquele recurso tem feito, com o inventário como chave de junção entre as duas visões.

3. APIs Nativas por Provedor

Cada provedor expõe serviços de metadados que funcionam como o catálogo de recursos da conta. A tabela abaixo resume os serviços de inventário e as coletas mínimas para EASM, e serve de checklist para o pipeline de descoberta.

Em AWS, a coleta parte do conjunto de contas registrado no AWS Organizations e percorre regiões, porque recursos em região ignorada são invisíveis ao programa inteiro. Em Azure, o Azure Resource Graph é o atalho mais eficiente, pois permite uma consulta KQL federada sobre todas as assinaturas às quais a identidade de coleta tem leitura. Em GCP, o Cloud Asset Inventory com escopo de organização devolve um snapshot exportável de recursos e políticas de IAM em operação única. Em todos os casos, a identidade usada para coletar deve ser dedicada, com permissão somente leitura, credencial rotacionada e monitorada como ativo de alta sensibilidade, porque quem controla essa identidade enxerga o inventário completo da organização.

Para cada recurso coletado, o registro mínimo que habilita as etapas seguintes do CTEM combina identificação, exposição e vínculo de identidade. A identificação inclui o identificador nativo do recurso, o tipo, a região e a conta de origem. A exposição registra se o recurso tem endereço público, se há regra de firewall que autoriza tráfego da internet e se o serviço tem acesso anônimo configurado. O vínculo de identidade lista as identidades associadas ao recurso, seja como papel executado, seja como principal com permissão sobre ele, porque é esse vínculo que conecta o inventário ao grafo de ataque e ao hunting de identidade.

# AWS: inventario de recursos com IP publico em todas as regioes de uma conta
for r in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
  aws ec2 describe-instances --region "$r" \
    --filters "Name=ip-address,Values=*" \
    --query 'Reservations[].Instances[?PublicIpAddress].[InstanceId,PublicIpAddress,Tags[?Key==`Name`].Value|[0]]' \
    --output text
done

# Azure: consulta federada no Resource Graph por enderecos publicos
az graph query -q "Resources | where type =~ 'microsoft.compute/virtualmachines' | extend ip = properties.networkProfile.networkInterfaces | project name, resourceGroup, subscriptionId, ip" --first 1000

# GCP: exportacao do Cloud Asset Inventory da organizacao
gcloud asset export --organization=123456789 \
  --asset-types=compute.googleapis.com.Instance,storage.googleapis.com.Bucket \
  --output-path=gs://inventario-seguranca/assets-$(date +%F).json

4. Ativos Efêmeros, Contas Shadow e o Inventário Verdadeiro

O ativo efêmero é o caso que quebra qualquer cadência fixa. Instâncias de pipeline, jobs de processamento e ambientes de preview nascem e morrem em minutos, e o tratamento correto não é tentar registrá-los um a um, e sim definir duas classes de coleta: eventos de criação e destruição capturados em tempo quase real, via trilha de auditoria do provedor, e reconciliação periódica que confirma o estado consolidado. A trilha de eventos, como CloudTrail, Activity Log do Azure e Audit Logs do GCP, é a fonte que garante que nenhum ativo existiu sem o inventário saber disso, mesmo que por três minutos.

A conta shadow é o problema anterior à coleta: um time cria uma conta no provedor sem passar pelo cadastro central, e o programa de EASM nunca consulta aquela organização ou aquela assinatura. As defesas operam em três camadas. Na camada de governança, o cadastro de contas com registro obrigatório no onboarding de provedor e bloco técnico de criação não autorizada onde o provedor permite. Na camada de descoberta externa, o EASM clássico encontra recursos que apontam para a organização, certificados com a marca e endereços pertencentes aos intervalos do provedor contratado, e cada descoberta sem correspondência no inventário interno é alerta de shadow. Na camada de financeiro, a fatura consolidada do provedor lista organizações e assinaturas que a segurança não conhece, e o cruzamento mensal de fatura com inventário é o detector mais barato e mais confiável de conta não governada.

A propriedade do ativo é o atributo que transforma inventário em canal de remediação funcional. Toda conta e todo projeto devem nascer com rótulos obrigatórios de time responsável, ambiente e criticidade, e o pipeline de descoberta deve tratar recurso sem rótulo de propriedade como achado de governança com prazo de resolução curto. A experiência de mercado é consistente: descoberta sem dono gera fila de achados que ninguém assume, e a aplicação do rótulo no momento da criação, via política de organização ou infraestrutura como código padrão, é muito mais barata do que caçar dono depois do achado.

5. Unificação do Inventário Multi-Cloud

O inventário unificado é a camada que converte três linguagens de provedor num modelo interno único. O modelo mínimo precisa de poucos campos para ser útil ao CTEM, e cada campo tem dono claro no pipeline: identidade única global, provedor e conta de origem, tipo e classe do recurso, exposição externa, identidades vinculadas, região, carimbo de primeira e última observação e estado. A normalização é o trabalho pesado, e a regra prática é normalizar o mínimo que permita as consultas de priorização, porque normalizar tudo é projeto de CMDB clássico que não termina.

{
  "ativo": {
    "id_global": "aws-123456789012-us-east-1-i-0abc123",
    "provedor": "aws",
    "conta": "123456789012",
    "tipo": "ec2-instance",
    "exposicao_externa": true,
    "ip_publico": "203.0.113.44",
    "identidades_vinculadas": ["svc-web"],
    "regiao": "us-east-1",
    "primeira_observacao": "2026-01-14T08:02:11Z",
    "ultima_observacao": "2026-02-03T06:10:47Z",
    "estado": "ativo",
    "fonte": ["cloudtrail", "reconciliacao-diaria"]
  }
}

Cada campo do modelo existe para responder uma pergunta específica das etapas seguintes, e a tabela abaixo deixa explícito esse contrato de consumo entre o inventário e o resto do programa.

A cadência de reconciliação decide a utilidade do inventário. Uma boa configuração de partida combina ingestão de eventos de mudança em streaming para as contas críticas, reconciliação completa diária para o mesmo conjunto e semanal para o restante, e um job mensal de aposentadoria que marca como extinto qualquer ativo sem observação nova em trinta dias. Cada recurso do pipeline tem dono e alerta de falha, porque inventário silenciosamente parado é pior que ausência de inventário: ele transmite confiança falsa para todas as etapas seguintes do CTEM.

6. Exemplo de Pipeline de Descoberta com APIs

O pipeline de referência tem cinco estágios, e cada um pode começar simples e evoluir independentemente. A tabela abaixo descreve os estágios com sua função, insumo e produto, e serve de esqueleto para a implementação em qualquer orquestrador.

O estágio 5 merece detalhamento porque é onde o pipeline prova a própria integridade. A reconciliação compara três fontes por unidade de coleta: o snapshot da API, o fluxo de eventos e o resultado da última varredura externa da subseção de EASM clássico. Recursos presentes no snapshot e ausentes nos eventos indicam trilha de auditoria incompleta; recursos presentes na varredura externa e ausentes no inventário indicam conta shadow; recursos presentes no inventário e ausentes no snapshot indicam coleta falha ou região esquecida. Cada descompasso tem um alarme próprio e um dono, e a métrica de cobertura, a proporção de recursos do snapshot representados no inventário unificado em menos de quinze minutos, resume a saúde do pipeline inteiro em um número que cabe no reporte executivo.

A configuração de cadência do pipeline cabe em um arquivo declarativo versionado, que serve tanto de documentação quanto de insumo direto para o orquestrador, conforme o exemplo a seguir.

pipeline_descoberta:
  identidade_coleta:
    aws: role/easm-coletor-readonly
    azure: app-registrado com permissao Reader nas assinaturas
    gcp: service account roles/asset.viewer
  cadencias:
    enumeracao_contas: diaria
    coleta_snapshot_criticas: a cada 6 horas
    coleta_snapshot_demais: diaria
    eventos_mudanca: streaming
    reconciliacao_completa: diaria, 03:00
    aposentadoria_sem_observacao: mensal, 30 dias
  alarmes:
    falha_coleta_unidade: critico
    cobertura_inventario_abaixo_de: 98 por cento
    ativo_externo_sem_correspondencia: alerta de governanca
    recurso_sem_rótulo_proprietario: prazo de 7 dias

7. Erros Comuns e Pontos de Atenção

• Coletar com credencial de administrador: a identidade de inventário deve ser somente leitura e dedicada; usar credencial privilegiada transforma o pipeline em vetor de comprometimento e alvo de prioridade do próprio time.
• Esquecer regiões e assinaturas fora do padrão: a região esquecida é o clássico ponto cego de AWS e a assinatura antiga é o equivalente no Azure; a enumeração de unidades de coleta deve vir de fonte autoritativa, e não de lista manual.
• Tratar ativo efêmero como anomalia: em ambiente maduro de nuvem a efemeridade é a regra, e o desenho correto separa ciclo de vida em eventos de inventário consolidado, em vez de gerar alerta para cada criação.
• Deixar o CMDB no comando sobre a verdade: o CMDB reconcilia e governa processos, e a fonte primária de estado em nuvem é a API do provedor; inverter essa hierarquia produz inventário bonito e errado.
• Normalizar demais na primeira versão: o modelo com doze campos já sustenta priorização de exposição; esperar o modelo perfeito adiante o programa meses sem ganho proporcional.
• Ignorar identidades na coleta: o inventário que registra apenas recursos e esquece papéis, permissões e credenciais alimenta o EASM, mas não o grafo de ataque, e a maior parte dos caminhos modernos passa por identidade.
• Guardar snapshots sem política de acesso: o inventário consolidado é um mapa de ataque completo, e os artefatos de coleta merecem o mesmo controle de acesso e retenção aplicado a inteligência sensível.
• Medir o programa pelo número de ativos: volume inflado de itens no inventário não é valor; cobertura verificada, frescor da coleta e proporção de ativos com dono são as métricas que importam.

8. Integração com o Restante da Biblioteca

As conexões estruturais desta nota com o restante da biblioteca seguem quatro caminhos:

• Capítulo 02: a automação de coleta via APIs e a avaliação de qualidade das fontes são o embrião metodológico do pipeline aqui descrito.
• Capítulo 08: o hunting em cloud e SaaS consome o inventário unificado para contextualizar anomalias de uso por ativo e por identidade.
• Capítulo 21: a nota de correlação com CSPM desta subseção cruza o inventário com configurações inseguras, e a subseção de integração consome o inventário nos workflows de remediação.
• Seção 15: o controle INS de inventário e o grupo DAT de coleta encontram aqui a implementação multi-cloud, e o grupo MET mede a cobertura com as métricas do estágio de reconciliação.

A regra que fecha o raciocínio é a precedência do inventário: toda métrica de exposição, todo escore de risco e todo workflow de remediação herdam a qualidade da descoberta, e um ambiente mal inventariado produz CTEM confiante e cego ao mesmo tempo. O indicador de sentinela recomendado é a taxa de ativos descobertos por fonte externa sem correspondência interna, e sua meta operacional é zero recorrente: cada ocorrência é um achado de governança, e não apenas um item a cadastrar.