Security Mesh: o Security Center agora correlaciona sinais de segurança dentro e fora da Salesforce
Novo recurso usa o padrão OCSF para unificar dados de identidade, endpoint e eventos internos numa detecção acionável
O Security Mesh, anunciado na Dreamforce, normaliza sinais de segurança de fontes internas e externas usando o padrão aberto OCSF, destravando detecções como impossible travel e exfiltração de dados. O recurso exige Data 360 e já conta com integrações GA como Okta, CrowdStrike e DigitSec.
Todo cliente de Security Center chega numa hora no mesmo impasse: o dado de segurança existe, mas está espalhado. Um alerta de Real-Time Event Monitoring aqui, um log de login anômalo de um provedor de identidade ali, um evento de endpoint em outra ferramenta completamente fora do ecossistema Salesforce. Cada peça isolada conta uma história incompleta. Juntas, contariam a história real de um ataque em andamento. O problema nunca foi falta de dado. Foi falta de correlação.
É esse buraco que o Security Mesh vem tapar. Anunciado na Dreamforce, é um recurso novo dentro do Security Center (aquele add-on de segurança que já existia para dar visibilidade centralizada de postura) e a proposta é direta: unificar e normalizar sinais de segurança que vêm de dentro e de fora da Salesforce, transformando ruído disperso em detecção acionável.
A arquitetura por trás é simples de entender e faz sentido para quem já trabalha com Data 360: o Security Mesh conecta fontes internas, como o próprio Real-Time Event Monitoring, com feeds externos de parceiros de segurança. E aí entra a parte interessante: em vez de inventar um modelo de dados proprietário, ele adota o Open Cybersecurity Schema Framework (OCSF), um padrão de mercado, para mapear tudo num modelo único e consultável. Username, IP Address, Last Login, Location, Role: não importa se o dado nasceu no Okta, no CrowdStrike ou dentro da própria org, ele cai formatado do mesmo jeito.
Na prática, isso destrava três tipos de detecção que hoje exigem gambiarra de planilha, script ou SIEM externo mal integrado:
- Impossible Travel: usuário loga em São Paulo e vinte minutos depois em Londres. Fisicamente impossível, então é sinal de credencial comprometida. Já vem pronto out-of-the-box.
- Data Exfiltration: a sessão nasce de um lugar ou horário fora do padrão do usuário e, na sequência, dispara chamadas de API em massa ou exportações de relatório muito acima do baseline normal. Esse é o tipo de correlação que separa "log estranho" de "incidente real".
- Active Sessions During Endpoint Compromise: o endpoint do usuário é comprometido (credential stealer, malware) enquanto ele tem uma sessão ativa e com atividade alta na Salesforce. Cruzando isso com Real-Time Event Monitoring, dá para reconstruir exatamente o que aconteceu enquanto "a porta estava aberta".
Sobre disponibilidade: o Security Mesh vem dentro do Security Center e exige Data 360 para funcionar, o que já é um sinalizador importante de arquitetura (mais sobre isso adiante). Hoje já estão GA o Real-Time Event Monitoring nativo e três integrações externas: Okta ISPM (dado de usuário), CrowdStrike (segurança de endpoint) e DigitSec (scanning de código e pipeline). É um começo enxuto, claramente pensado para expandir o catálogo de conectores com o tempo.
Por que isso é diferente de "mais um dashboard de segurança"
O que separa o Security Mesh de um painel bonito é a normalização via OCSF. Qualquer arquiteto que já tentou cruzar log de identidade externo com evento interno da Salesforce sabe a dor: cada fonte tem seu próprio vocabulário, seus próprios nomes de campo, seu próprio fuso horário mal documentado. Ter um padrão de schema aberto por trás resolve o trabalho pesado de ETL de segurança que hoje, na maioria dos clientes, é feito na unha via MuleSoft, script customizado ou ferramenta de SIEM terceira que nunca conversa direito com o ecossistema Salesforce.
Para times de segurança e admins que vivem na Salesforce, isso muda o jogo de "reagir a alerta isolado" para "correlacionar comportamento". Um login estranho sozinho é ruído. Um login estranho seguido de exportação massiva de relatório é incidente. A diferença entre as duas leituras é exatamente o tipo de correlação que o Security Mesh promete entregar nativamente, sem exigir que o cliente monte essa lógica na mão em uma ferramenta externa.
Também importa porque reforça um movimento que já vinha acontecendo: Data 360 deixando de ser "o produto de CDP para marketing" e virando peça de infraestrutura transversal, inclusive para segurança. Quem ainda trata Data 360 como algo isolado do resto da plataforma vai precisar rever esse enquadramento, porque cada vez mais funcionalidades essenciais (não só as de growth) vão depender dela.
Gosto do caminho técnico aqui: usar OCSF em vez de reinventar um schema proprietário é a decisão certa, e mostra que a Salesforce está pensando o Security Mesh como peça de um ecossistema de segurança maior, não como ilha fechada. Mas o ponto que todo arquiteto deveria segurar na reunião com o cliente é a dependência de Data 360 bem implementada: sem isso na fundação, essa funcionalidade nova vira mais uma promessa bonita que não converte em detecção real.
Antes de sair pedindo Security Mesh para o cliente, valide os pré-requisitos de arquitetura: é preciso ter Security Center contratado e Data 360 provisionado e configurado corretamente na org. Se o cliente ainda não tem Data 360 rodando ou tem uma instância mal modelada, o Security Mesh não vai entregar valor nenhum, porque a qualidade da correlação depende diretamente da qualidade do dado que já está fluindo para lá.
Se você já usa Real-Time Event Monitoring, comece mapeando quais das três detecções prontas (Impossible Travel, Data Exfiltration, Active Sessions During Endpoint Compromise) fazem sentido para o perfil de risco do cliente antes de pensar em detecção customizada. E se a empresa já usa Okta, CrowdStrike ou DigitSec, a integração GA já elimina boa parte do trabalho de conector que normalmente cairia em MuleSoft ou script proprietário.
- A dependência de Data 360 não é trivial: é mais uma licença, mais uma camada de configuração e mais um componente de arquitetura para governar. Não trate como "ativa e esquece".
- O catálogo de integrações externas hoje é enxuto (três parceiros GA). Se o cliente usa outra stack de identidade ou EDR fora dessas três, ainda não há conector pronto, e vale confirmar o roadmap antes de prometer algo ao negócio.
- Detecção "out-of-the-box" não substitui tuning. Impossible Travel sem calibração de threshold gera falso positivo em empresa com força de trabalho remota distribuída globalmente; vale revisar com o time de segurança antes de ativar em produção.
- Isso é um add-on pago dentro de Security Center, que já é add-on. Modele custo total antes de vender a ideia internamente.
Este conteúdo foi reescrito e analisado editorialmente em português a partir de informações públicas da fonte indicada.
A resposta sai do que está publicado aqui. Se não estiver, ele diz que não sabe em vez de inventar.