Arquitetura e fluxos de dados do Google SecOps

Compatível com:

Google SecOps

Os ambientes de segurança modernos geram grandes quantidades de telemetria em infraestrutura nativa da nuvem, microsserviços e endpoints distribuídos. As arquiteturas legadas de gerenciamento de eventos e informações de segurança (SIEM) geralmente têm dificuldade de escalonar com esses volumes de dados, resultando em consultas lentas e visibilidade fragmentada.

A plataforma Google Security Operations oferece uma camada de análise de segurança unificada e de alta performance. Criado na mesma infraestrutura que capacita os principais serviços globais do Google, ele ingere e consulta petabytes de telemetria de segurança com latência inferior a um segundo, eliminando a distinção legada entre níveis de dados ativos e inativos.

Este documento descreve a arquitetura e os fluxos de dados do Google SecOps, abrangendo ingestão, normalização do UDM, detecção de ameaças YARA-L e resposta automatizada.

Convergência de inteligência, análise e resposta

O Google SecOps unifica recursos de operações de segurança que eram separados. Ele combina análises de SIEM e orquestração, Automation e resposta de segurança (SOAR) em uma plataforma fortemente acoplada. Além disso, ele incorpora inteligência contra ameaças do Google Threat Intelligence e do VirusTotal, além de recursos de IA generativa com tecnologia do Gemini diretamente nos fluxos de trabalho de investigação e detecção.

Visão geral da arquitetura da plataforma

O Google SecOps funciona como um plano de segurança especializado e nativo da nuvem criado com base na infraestrutura principal Google Cloud . Ele herda as propriedades de escalonabilidade, durabilidade e desempenho dos serviços do Google subjacentes, incluindo Spanner e Colossus.

Contexto do sistema

O Google SecOps serve como o plano operacional central do seu ambiente de segurança, gerenciando dados em três etapas principais:

• Entradas: ingerem telemetria de ambientes híbridos, incluindo coletores locais (como o agente do BindPlane), APIs de provedores de nuvem e conectores diretos de software como serviço (SaaS) de terceiros.
• Núcleo de processamento: normaliza a telemetria bruta no esquema UDM estruturado, avalia eventos usando o mecanismo de detecção YARA-L e organiza fluxos de trabalho usando o mecanismo de gerenciamento de casos SOAR.
• Saídas: fornece inteligência de segurança útil e insights de triagem de IA para analistas, além de enviar comandos de contenção automatizados de volta aos ambientes de destino por APIs e agentes remotos.

O diagrama a seguir ilustra o contexto do sistema e os fluxos de dados.

Vantagem da infraestrutura

Uma das principais vantagens arquitetônicas do Google SecOps é o modelo unificado de armazenamento de acesso frequente. As arquiteturas legadas movem a telemetria mais antiga para o armazenamento de acesso raro, o que deixa as consultas mais lentas ou exige reidratação manual. Por outro lado, o Google SecOps retém toda a telemetria ingerida em um estado ativo e pesquisável por índice por até 12 meses. Com esse design, é possível executar consultas em um ano inteiro de dados históricos com a mesma performance de uma consulta da última hora.

Pipeline de coleta de dados e normalização

O Google SecOps usa um pipeline de ingestão de alta capacidade que transforma registros brutos e não estruturados no Modelo de dados unificado (UDM) estruturado. Durante a normalização, o pipeline enriquece cada evento com metadados contextuais do gráfico de contexto da entidade.

Arquitetura de coleta

A ingestão de dados ocorre em três vetores principais:

• Coletores: coletores baseados em agentes (como o agente do BindPlane ou agentes do OpenTelemetry) implantados em redes locais para agregar dados de syslog e pacotes. Os coletores armazenam em buffer, compactam e criptografam a telemetria na camada de transporte (TLS) antes de encaminhá-la ao Google SecOps.
• APIs de ingestão: endpoints da API REST diretos que ingerem telemetria estruturada e não estruturada de serviços de nuvem, aplicativos personalizados e pipelines sem servidor.
• Integrações de terceiros: conectores integrados baseados em pull que recuperam registros, alertas e dados de diretório diretamente de plataformas SaaS externas e APIs de nuvem, como o Microsoft 365 ou o Microsoft Entra ID.

Fluxo do pipeline de coleta e preparação de dados

O diagrama a seguir detalha as etapas específicas de transformação de dados brutos para o formato UDM.

Visão geral do esquema do modelo de dados unificado

O modelo de dados unificado (UDM) normaliza registros de fornecedores diferentes em um único esquema estruturado. Essa representação padrão simplifica a análise e a pesquisa, garantindo que entidades equivalentes (como endereços IP, nomes de usuário ou hashes de arquivos) compartilhem caminhos de campo consistentes em todas as fontes de registros.

Arquitetura do esquema da UDM

A UDM usa um esquema hierárquico fortemente tipado para representar eventos e entidades de segurança. Ele organiza os dados nas seguintes estruturas lógicas principais:

• Metadados: contexto sobre o evento de registro em si, incluindo o carimbo de data/hora do evento, o tempo de ingestão, o nome do produto do fornecedor e o tipo de evento.
• Principal: a entidade que iniciou a atividade (como o usuário, host, endereço IP ou processo de origem).
• Destino: a entidade diretamente afetada pela atividade, como o arquivo de destino, o host de destino ou a conta de usuário.
• Origem, intermediário e observador: participantes secundários da rede (como proxies de encaminhamento, firewalls ou saltos de roteamento) envolvidos na transação.
• Rede: atributos de protocolo de rede e artefatos de transação, incluindo protocolos de aplicativo, consultas de DNS e detalhes de solicitação HTTP.
• Resultado de segurança: a ação ou o resultado de gravidade informado pelo dispositivo de segurança (como ALLOWED, BLOCKED ou QUARANTINED).
• Extensões: campos personalizados e pares de chave-valor específicos do fornecedor que não se enquadram no esquema principal padrão. Para detalhes sobre o mapeamento de definições e o desenvolvimento de analisadores, consulte Configurar analisadores personalizados e Campos importantes do UDM.

Diagrama de classes da UDM

O diagrama a seguir fornece um modelo estrutural da UDM.

Arquitetura de pesquisa

O Google SecOps oferece mecanismos de pesquisa avançados adaptados a diferentes fluxos de trabalho de investigação. É possível consultar a telemetria normalizada no armazenamento de acesso frequente, fazer correspondência de padrões com registros brutos não analisados ou pesquisar dados de casos estruturados. Para orientações sobre otimização, consulte Práticas recomendadas de pesquisa da UDM.

A tabela a seguir resume os principais recursos de pesquisa disponíveis na plataforma:

Tipo de pesquisa	Função arquitetônica
Pesquisa do UDM	O principal mecanismo de pesquisa estruturada que consulta eventos normalizados e indexados da UDM na janela ativa de 12 meses. Ele permite filtragem, agregações e correlações de vários campos em fontes de registros diferentes.
Verificação de registros brutos	Verifica as strings de texto originais e não analisadas dos registros ingeridos. Esse recurso é compatível com expressões regulares (regex) e pesquisas de substrings para artefatos e parâmetros personalizados não mapeados para uma sintaxe específica do UDM.
Pesquisa com linguagem natural	Usa a IA do Gemini para traduzir perguntas em linguagem natural diretamente para a sintaxe formal de pesquisa da UDM, acelerando os fluxos de trabalho de criação de consultas e investigação.
Pesquisa de casos	Um mecanismo de pesquisa especializado na camada de resposta que consulta casos de investigação, alertas, playbooks e metadados de entidades anotadas no banco de dados SOAR.

Ciclo de detecção e resposta a ameaças

A arquitetura do Google SecOps cria um ciclo de feedback contínuo entre a análise de detecção e a resposta automatizada. As regras de detecção geram alertas de alta fidelidade que acionam fluxos de trabalho de resposta, enquanto os resultados da investigação fornecem feedback usado para refinar e ajustar a lógica de detecção futura.

Arquitetura de funil de detecção

O mecanismo de detecção usa uma abordagem de funil de várias etapas para destilar grandes volumes de telemetria de segurança bruta em alertas de alta fidelidade:

1. Ingestão e normalização: os registros brutos são ingeridos e formatados continuamente em estruturas de eventos UDM padrão.
2. Enriquecimento: os eventos são enriquecidos dinamicamente com mapeamentos de alias, dados contextuais de recursos e inteligência contra ameaças global de fontes como o Google Threat Intelligence.
3. Avaliação de detecção: o mecanismo YARA-L 2.0 com estado avalia eventos enriquecidos em relação a regras comportamentais e de ameaças em janelas de tempo estendidas. Para conferir as diretrizes de otimização de regras, consulte Práticas recomendadas para YARA-L.
4. Priorização e agrupamento: as detecções correspondentes são agregadas em alertas, recebem pontuações de risco dinâmicas e são agrupadas em casos unificados.

Ao combinar dados contextuais de ativos com inteligência contra ameaças, essa estratégia de funil filtra anomalias inofensivas (reduzindo falsos positivos) e destaca ameaças reais (reduzindo falsos negativos), ajudando sua equipe de segurança a se concentrar em incidentes acionáveis.

Correção automatizada e ciclo de feedback

O pipeline de detecção e resposta combina a avaliação de regras com estado e a triagem e contenção automatizadas:

1. Avaliação contínua: fluxos de telemetria da UDM enriquecidos pelo mecanismo de detecção com estado YARA-L 2.0.
2. Criação de casos e triagem de IA: quando uma condição de regra é atendida, o Google SecOps gera um alerta e abre um caso. Um agente de triagem e investigação com tecnologia de IA executa pesquisas dinâmicas e consultas de inteligência contra ameaças para avaliar as descobertas.
3. Execução automatizada de playbook: se a triagem de IA confirmar um verdadeiro positivo, a plataforma vai acionar playbooks de resposta automatizada, como isolar um endpoint ou suspender uma conta de usuário por agentes remotos. Se for classificado como um falso positivo, o caso será fechado automaticamente.
4. Ajuste contínuo: os resultados da correção e os vereditos de triagem dos analistas são repetidos para refinar os limites de detecção e reduzir futuros falsos positivos.

Camada de detecção de ameaças

O mecanismo YARA-L 2.0 avalia a telemetria da UDM recebida usando um pipeline de streaming de várias etapas para detectar anomalias comportamentais e padrões de ataque de vários eventos em janelas de tempo estendidas. Você também pode gerar e refinar regras YARA-L usando o Gemini.

O ciclo de vida de processamento de cada regra YARA-L segue cinco etapas de avaliação distintas:

1. Ingestão (Ingest): os eventos do UDM enriquecidos entram no pipeline de avaliação de detecção em tempo real.
2. Filtragem (Filter): os eventos recebidos são avaliados de acordo com os critérios de evento da regra (seção events). Os eventos que não correspondem são descartados, enquanto os correspondentes passam para a avaliação com estado.
3. Janela de correspondência (Window): os eventos correspondentes são agrupados por chaves de correlação especificadas em um período definido (de segundos a 12 meses). O mecanismo rastreia vários timers com estado simultâneos (TimerStart a TimerEnd) à medida que os eventos se acumulam.
4. Avaliação da condição (Condition): quando a janela de correspondência é fechada ou acionada, o mecanismo avalia os requisitos de limite e as expressões matemáticas definidos na seção condition da regra (como contagens de eventos, limites distintos ou junções de dados cruzados).
5. Acionamento (Trigger): se a condição for avaliada como True, o mecanismo vai gerar uma detecção, acionando um alerta e abrindo ou atualizando um caso na camada de resposta. Se False, o estado será limpo sem acionar um alerta.

Máquina de estados de execução de regras

O diagrama a seguir ilustra o ciclo de vida da execução de uma regra.

Arquitetura de resposta e execução remota

O Google SecOps SOAR representa o pilar de resposta da plataforma. Ele opera como um mecanismo de orquestração acima da camada de análise para ingerir alertas, fazer triagem de casos e executar fluxos de trabalho de resposta automatizada.

Orquestração, automação e investigação

A camada de resposta inclui ferramentas especializadas projetadas para simplificar os fluxos de trabalho da central de operações de segurança (SOC) em investigação, gerenciamento de casos e automação de playbooks:

• Gerenciamento de casos: agrupe alertas relacionados em casos unificados, classifique e filtre filas de incidentes, atribua tarefas e colabore em investigações com rastreamento de auditoria completo.
• Designer de playbook: crie playbooks de resposta automatizada usando uma tela visual de arrastar e soltar sem código com ações de integração pré-criadas.
• Ambiente de desenvolvimento integrado (IDE): use o IDE integrado baseado em código para escrever scripts personalizados em Python, modificar integrações de ações atuais e depurar fluxos de trabalho de automação complexos.
• Visualizações de investigação e investigador de gráficos: visualize caminhos de ataque e relacionamentos de entidades usando visualizações de investigação baseadas em gráficos. Os resumos de entidades dedicadas (como visualizações de recurso, endereço IP, hash, domínio e usuário) mostram eventos relevantes da linha do tempo instantaneamente.
• Painéis e relatórios: acompanhe as métricas operacionais do SOC, a carga de trabalho dos analistas e o tempo médio de resposta (MTTR) usando painéis prontos para uso ou widgets de relatórios personalizados.

Arquitetura de componentes do SOAR

O diagrama a seguir ilustra como os alertas recebidos fluem para o mecanismo de gerenciamento de casos e acionam fluxos de trabalho de correção automatizados em playbooks visuais e integrações personalizadas de IDE.

Arquitetura do agente remoto

Para executar ações de correção em redes privadas (como data centers locais ou nuvens privadas virtuais), o Google SecOps usa uma arquitetura de agente remoto segura e somente de saída.

Nesse modelo, a plataforma do Google SecOps nunca inicia conexões de entrada com seu ambiente particular:

1. Início da tarefa: quando uma ação do playbook exige execução local, o Google SecOps publica a instrução em uma fila de publicação segura hospedada em Google Cloud.
2. Pesquisa assíncrona: o agente remoto implantado no seu ambiente particular pesquisa continuamente a fila do publisher em uma conexão de saída criptografada com TLS.
3. Execução local: quando uma instrução de tarefa é recuperada, o agente remoto executa a ação necessária localmente em ferramentas de segurança internas ou endpoints de rede (como desativar uma conta ou bloquear uma porta de firewall).
4. Relatórios de status: depois de concluído, o agente remoto retorna o status da ação e os registros de execução para a fila do publisher por TLS, onde são recuperados e exibidos na visualização de caso do SOAR.

Segurança, compliance e responsabilidade compartilhada

Como uma plataforma nativa da nuvem, o Google SecOps opera com um modelo de responsabilidade compartilhada: o Google é responsável pela segurança da plataforma, enquanto você é responsável pela segurança na plataforma.

Modelo de responsabilidade compartilhada

O Google SecOps herda o design de segurança principal, os recursos de computação e a arquitetura de armazenamento da infraestrutura do Google Cloud . Neste modelo:

• O Google gerencia:segurança física do data center, infraestrutura em nuvem subjacente, disponibilidade da plataforma e criptografia padrão de dados em repouso e em trânsito.
• Você gerencia:governança de dados, controles de acesso e RBAC de dados configurados com o Identity and Access Management (IAM), regras de detecção personalizadas e configurações de compliance do locatário.

Todos os requisitos de compliance, regras de residência de dados e políticas de acesso são herdados e aplicados da hierarquia da organização para baixo, passando por pastas e projetos até o locatário controlado por compliance.

Compliance e preparação para empresas

Para atender a requisitos rigorosos de governança regulatória e organizacional, o Google SecOps oferece tenants controlados por compliance. Esses locatários aplicam padrões de segurança rigorosos com o Assured Workloads, oferecendo suporte a frameworks de compliance regulatório e pacotes de proteção de dados técnicos.

Estruturas de conformidade regulatória compatíveis:

• FedRAMP:níveis de impacto moderado e alto (FEDRAMP_MODERATE, FEDRAMP_HIGH)
• Níveis de impacto do DoD:IL4 e IL5 (IL4_AND_IL5)
• Saúde e finanças:HIPAA e PCI DSS (HIPAA, PCI_DSS)

Para implantar um locatário controlado por compliance, vincule sua instância do Google SecOps a um projeto Google Cloud localizado em uma pasta do Assured Workloads configurada para o pacote de controle necessário.

Residência de dados e transparência no acesso

A Google SecOps aplica um isolamento lógico estrito de locatários e oferece suporte à Transparência no acesso para dar a você controle verificável e visibilidade de auditoria sobre o acesso aos dados administrativos.

Pacotes de segurança de dados e residência compatíveis:

• Chaves de criptografia gerenciadas pelo cliente (CMEK): controle e gerencie as chaves usadas para criptografar dados em repouso (CMEK_V1).
• Residência de dados avançada:aplique limites regionais de residência de dados e controles de acesso administrativo (DRZ_ADVANCED).
• VPC Service Controls:estabeleça perímetros seguros e personalizados ao redor dos seus recursos de segurança na nuvem usando o VPC Service Controls (VPC-SC).

A arquitetura de segurança da plataforma se baseia em um modelo de herança de quatro camadas, em que seus controles de segurança administrativa são criados com base nos fundamentos reforçados da infraestrutura principal do Google:

A pilha de segurança de quatro camadas:

1. Camada de controle de segurança do cliente: seus controles administrativos de alto nível, incluindo controles de acesso baseado em função (RBAC) gerenciados pelo Identity and Access Management (IAM), chaves de criptografia gerenciadas pelo cliente (CMEK) e políticas regionais de residência de dados.
2. Camada de segurança da plataforma: isolamento lógico do locatário, criptografia padrão para dados em repouso e em trânsito (TLS) e registro de auditoria da Transparência no acesso.
3. Camada de infraestrutura do Google: infraestrutura principal de computação e armazenamento, incluindo gerenciamento de cluster do Borg, armazenamento distribuído do Colossus e bancos de dados globais do Spanner.
4. Camada de segurança física: segurança fundamental com suporte de data centers empresariais do Google, controles biométricos multifator e chips de segurança Titan personalizados (roots of trust).

Por exemplo, quando a Transparência no acesso está ativada, se um especialista de suporte ou engenharia do Google acessar os dados do seu locatário para resolver um tíquete de suporte, ele precisará enviar uma justificativa de acesso criptográfica válida. Essa solicitação de acesso é registrada de forma segura e fica visível nos registros de auditoria quase em tempo real.

Precisa de mais ajuda? Receba respostas de membros da comunidade e profissionais do Google SecOps.