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 infraestruturas nativas da nuvem, microsserviços e endpoints distribuídos. As arquiteturas legadas de gerenciamento de eventos e informações de segurança (SIEM, na sigla em inglês) geralmente têm dificuldade para 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. Criada na mesma infraestrutura que capacita os principais serviços globais do Google, ela ingere e consulta petabytes de telemetria de segurança com latência de menos de um segundo, eliminando a distinção legada entre camadas de dados ativos e inativos.

Este documento descreve a arquitetura e os fluxos de dados do Google SecOps, abrangendo ingestão, normalização de 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 historicamente separados. Ele combina a análise de SIEM e a orquestração, Automation e resposta de segurança (SOAR, na sigla em inglês) 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 Gemini diretamente nos fluxos de trabalho de investigação e detecção.

Visão geral da arquitetura da plataforma

O Google SecOps opera 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 performance 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 estágios principais:

• Entradas: ingere telemetria de ambientes híbridos, incluindo coletores locais (como o agente BindPlane), APIs de provedores de nuvem e conectores diretos de software como serviço (SaaS) de terceiros.
• Núcleo de tratamento: normaliza a telemetria bruta no esquema UDM estruturado, avalia eventos usando o mecanismo de detecção YARA-L e orquestra fluxos de trabalho usando o mecanismo de gerenciamento de casos SOAR.
• Saídas: oferece inteligência de segurança útil e insights de triagem de IA para analistas, enquanto envia comandos de contenção automatizados de volta para 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 torna as consultas mais lentas ou exige a reidratação manual. Em contraste, o Google SecOps retém toda a telemetria ingerida em um estado ativo e pesquisável por índice por até 12 meses. Esse design permite 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, na sigla em inglês) 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 BindPlane ou agentes 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 diretos da API REST 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, na sigla em inglês) 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 registro.

Arquitetura do esquema UDM

O UDM usa um esquema hierárquico e 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).
• Fonte, 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 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 específicos do fornecedor e pares de chave-valor que ficam fora do esquema principal padrão. Para mais detalhes sobre definições de mapeamento e desenvolvimento de analisadores, consulte Configurar analisadores personalizados e Campos importantes do UDM.

Diagrama de classe UDM

O diagrama a seguir fornece um projeto estrutural do 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, realizar a correspondência de padrões em registros brutos não analisados ou pesquisar dados de casos estruturados. Para orientações de otimização, consulte Práticas recomendadas de pesquisa do 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 UDM normalizados e indexados na janela ativa de 12 meses. Ele permite filtragem, agregações e correlações de vários campos em fontes de registro diferentes.
Verificação de registro bruto	Verifica as strings de texto originais e não analisadas dos registros ingeridos. Esse recurso oferece suporte a expressões regulares (`regex`) e pesquisas de substrings para artefatos e parâmetros personalizados não mapeados para uma sintaxe UDM específica.
Pesquisa em linguagem natural	Usa a IA do Gemini para traduzir perguntas em linguagem natural diretamente para a sintaxe de pesquisa UDM formal, acelerando a criação de consultas e os fluxos de trabalho de 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.

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

A arquitetura do Google SecOps cria um loop 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 de recursos contextuais 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 de comportamento e ameaças em janelas de tempo estendidas. Para diretrizes de otimização de regras, consulte Práticas recomendadas da 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 de recursos contextuais 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.

Loop de feedback e correção automatizada

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

1. Avaliação contínua: os fluxos de telemetria UDM enriquecidos pelo mecanismo de detecção YARA-L 2.0 com estado.
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 pesquisas de inteligência contra ameaças para avaliar as descobertas.
3. Execução automatizada de playbooks: se a triagem de IA confirmar um verdadeiro positivo, a plataforma acionará playbooks de resposta automatizados (como isolar um endpoint ou suspender uma conta de usuário por agentes remotos). Se classificado como um falso positivo, o caso será fechado automaticamente.
4. Ajuste contínuo: os resultados da correção e os vereditos de triagem do analista são repetidos para refinar os limites de detecção e reduzir falsos positivos futuros.

Camada de detecção de ameaças

O mecanismo YARA-L 2.0 avalia a telemetria UDM recebida usando um pipeline de streaming de várias etapas para detectar anomalias de comportamento e padrões de ataque de vários eventos em janelas de tempo estendidas. Também é possível gerar e refinar regras YARA-L usando o Gemini.

O ciclo de vida de tratamento de cada regra YARA-L segue cinco estágios de avaliação distintos:

1. Ingestão (Ingest): eventos UDM enriquecidos entram no pipeline de avaliação de detecção em tempo real.
2. Filtragem (Filter): os eventos recebidos são avaliados em relação aos critérios de evento da regra (seção events). Os eventos que não correspondem são descartados, enquanto os eventos 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 uma janela de tempo definida (de segundos a 12 meses). O mecanismo rastreia vários timers com estado simultâneos (TimerStart a TimerEnd) à medida que os eventos são acumulados.
4. Avaliação de 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 definidas 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 gera 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 estado de execução de regras

O diagrama a seguir ilustra o ciclo de vida de uma execução de 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, casos de triagem e executar fluxos de trabalho de resposta automatizados.

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

A camada de resposta inclui ferramentas especializadas projetadas para simplificar os fluxos de trabalho do centro de operações de segurança (SOC, na sigla em inglês) 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 playbooks: crie playbooks de resposta automatizados 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 Python personalizados, 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 relações de entidades usando visualizações de investigação baseadas em gráficos. Resumos de entidades dedicados (como visualizações de recursos, endereços IP, hashes, domínios e usuários) mostram eventos relevantes da linha do tempo instantaneamente.
• Painéis e relatórios: acompanhe as métricas operacionais do SOC, a carga de trabalho do analista e o tempo médio de resposta (MTTR, na sigla em inglês) usando painéis prontos para uso ou widgets de relatórios personalizados.

Arquitetura de componentes 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 de IDE personalizadas.

Arquitetura de agente remoto

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

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

1. Iniciação de tarefas: quando uma ação de playbook exige execução local, o Google SecOps publica a instrução em uma fila de editor segura hospedada em Google Cloud.
2. Pesquisa assíncrona: o agente remoto implantado no seu ambiente particular pesquisa continuamente a fila do editor em uma conexão de saída criptografada por 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ório de status: quando concluído, o agente remoto retorna o status da ação e os registros de execução para a fila do editor por TLS, onde é recuperado e mostrado na visualização de caso SOAR.

Segurança, compliance e responsabilidade compartilhada

Como uma plataforma nativa da nuvem, o Google SecOps opera sob 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 Google Cloud infraestrutura. Nesse 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 pelo 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 sua organização 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 locatários controlados por compliance. Esses locatários aplicam padrões de segurança rigorosos por meio do Assured Workloads, oferecendo suporte a frameworks de compliance regulatório e pacotes técnicos de proteção de dados.

Frameworks de compliance regulatório com suporte:

• FedRAMP:níveis de impacto moderado e alto (FEDRAMP_MODERATE, FEDRAMP_HIGH)
• Níveis de impacto do Departamento de Defesa: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 Google Cloud projeto localizado em uma pasta do Assured Workloads configurada para o pacote de controle necessário.

Residência de dados e transparência no acesso

O Google SecOps aplica um isolamento lógico rigoroso do locatário e oferece suporte à Transparência no acesso para oferecer controle verificável e visibilidade de auditoria sobre o acesso aos dados administrativos.

Pacotes de segurança de dados e residência com suporte:

• Chaves de criptografia gerenciadas pelo cliente (CMEK, na sigla em inglês): 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 em torno dos recursos de segurança da nuvem usando o VPC Service Controls (VPC-SC).

A arquitetura de segurança da plataforma depende de um modelo de herança de quatro camadas, em que os controles de segurança administrativa são baseados nas fundações reforçadas 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 nível superior, incluindo controles de acesso baseados 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 Borg, armazenamento distribuído Colossus e bancos de dados globais Spanner.
4. Camada de segurança física: segurança fundamental com suporte dos 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 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 com segurança 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.