Architecture et flux de données de Google SecOps

Compatible avec :

Google SecOps

Les environnements de sécurité modernes génèrent d'énormes quantités de données télémétriques dans l'infrastructure cloud native, les microservices et les points de terminaison distribués. Les anciennes architectures de gestion des informations et des événements de sécurité (SIEM) ont souvent du mal à s'adapter à ces volumes de données, ce qui entraîne des requêtes lentes et une visibilité fragmentée.

La plate-forme Google Security Operations fournit une couche d'analyse de sécurité unifiée et hautes performances. Basé sur l'infrastructure qui alimente les principaux services mondiaux de Google, il ingère et interroge des pétaoctets de télémétrie de sécurité avec une latence inférieure à la seconde, tout en éliminant la distinction héritée entre les niveaux de données chaudes et froides.

Ce document décrit l'architecture et les flux de données de Google SecOps, y compris l'ingestion, la normalisation UDM, la détection des menaces YARA-L et la réponse automatisée.

Convergence de l'intelligence, de l'analyse et de la réponse

Google SecOps unifie des fonctionnalités d'opérations de sécurité qui étaient auparavant distinctes. Elle combine l'analyse SIEM et l'orchestration, l'automatisation et la réponse de sécurité (SOAR) dans une plate-forme étroitement couplée. De plus, il intègre des renseignements sur les menaces provenant de Google Threat Intelligence et de VirusTotal, ainsi que des fonctionnalités d'IA générative optimisées par Gemini, directement dans les workflows d'investigation et de détection.

Présentation de l'architecture de la plate-forme

Google SecOps fonctionne comme un plan de sécurité cloud natif spécialisé, basé sur l'infrastructure Google Cloud de base. Il hérite des propriétés de scalabilité, de durabilité et de performances des services Google sous-jacents, y compris Spanner et Colossus.

Contexte du système

Google SecOps sert de plan opérationnel central pour votre environnement de sécurité, en gérant les données à trois étapes principales :

• Entrées : ingèrent la télémétrie des environnements hybrides, y compris les collecteurs sur site (tels que l'agent BindPlane), les API des fournisseurs de services cloud et les connecteurs Software-as-a-Service (SaaS) tiers directs.
• Noyau de traitement : normalise la télémétrie brute dans le schéma UDM structuré, évalue les événements à l'aide du moteur de détection YARA-L et orchestre les workflows à l'aide du moteur de gestion des cas SOAR.
• Sorties : fournit aux analystes des renseignements exploitables sur la sécurité et des insights de triage de l'IA, tout en renvoyant des commandes de confinement automatisées aux environnements cibles via des API et des agents à distance.

Le schéma suivant illustre le contexte système et les flux de données.

Avantage de l'infrastructure

L'un des principaux avantages architecturaux de Google SecOps est son modèle de stockage à chaud unifié. Les anciennes architectures déplacent les données de télémétrie les plus anciennes vers le stockage à froid, ce qui ralentit les requêtes ou nécessite une réhydratation manuelle. En revanche, Google SecOps conserve toutes les données de télémétrie ingérées dans un état actif et indexable pendant 12 mois maximum. Cette conception vous permet d'exécuter des requêtes sur une année complète de données historiques avec les mêmes performances que si vous interrogiez la dernière heure.

Pipeline de collecte et de normalisation des données

Google SecOps utilise un pipeline d'ingestion à haut débit qui transforme les journaux bruts et non structurés en modèle de données unifié (UDM) structuré. Lors de la normalisation, le pipeline enrichit chaque événement avec des métadonnées contextuelles provenant du graphique de contexte des entités.

Architecture de la collecte

L'ingestion de données s'effectue selon trois vecteurs principaux :

• Collecteurs : collecteurs basés sur des agents (tels que l'agent BindPlane ou les agents OpenTelemetry) déployés dans des réseaux locaux pour agréger les données syslog et de paquets. Les collecteurs mettent en mémoire tampon, compressent et chiffrent la télémétrie au niveau de la couche de transport (TLS) avant de la transférer à Google SecOps.
• API d'ingestion : points de terminaison de l'API REST directs qui ingèrent la télémétrie structurée et non structurée des services cloud, des applications personnalisées et des pipelines sans serveur.
• Intégrations tierces : connecteurs intégrés basés sur l'extraction qui récupèrent les journaux, les alertes et les données d'annuaire directement à partir de plates-formes SaaS externes et d'API cloud (telles que Microsoft 365 ou Microsoft Entra ID).

Flux du pipeline de collecte et de préparation des données

Le diagramme suivant détaille les étapes de transformation spécifiques des données brutes au format UDM.

Présentation du schéma du modèle de données unifié

Le modèle de données unifié (UDM) normalise les journaux de différents fournisseurs dans un schéma unique et structuré. Cette représentation standard simplifie les analyses et les recherches en garantissant que les entités équivalentes (telles que les adresses IP, les noms d'utilisateur ou les hachages de fichiers) partagent des chemins de champ cohérents dans toutes les sources de journaux.

Architecture du schéma UDM

L'UDM utilise un schéma hiérarchique fortement typé pour représenter les événements et les entités de sécurité. Il organise les données dans les structures logiques de base suivantes :

• Métadonnées : contexte de l'événement de journal lui-même, y compris le code temporel de l'événement, l'heure d'ingestion, le nom du produit du fournisseur et le type d'événement.
• Principal : entité agissante qui a initié l'activité (par exemple, l'utilisateur d'origine, l'hôte, l'adresse IP ou le processus).
• Cible : entité directement concernée par l'activité (par exemple, le fichier cible, l'hôte de destination ou le compte utilisateur).
• Source, intermédiaire et observateur : participants au réseau secondaire (tels que les proxys de transfert, les pare-feu ou les sauts de routage) impliqués dans la transaction.
• Réseau : attributs de protocole réseau et artefacts de transaction (y compris les protocoles d'application, les requêtes DNS et les détails des requêtes HTTP).
• Résultat de sécurité : action ou niveau de gravité signalés par le dispositif de sécurité (par exemple, ALLOWED, BLOCKED ou QUARANTINED).
• Extensions : champs personnalisés et paires clé-valeur spécifiques aux fournisseurs qui ne font pas partie du schéma de base standard. Pour en savoir plus sur les définitions de mappage et le développement d'analyseurs, consultez Configurer des analyseurs personnalisés et Champs UDM importants.

Diagramme de classe UDM

Le diagramme suivant fournit un plan structurel de l'UDM.

Architecture de la recherche

Google SecOps fournit des mécanismes de recherche puissants adaptés à différents workflows d'investigation. Vous pouvez interroger la télémétrie normalisée dans le stockage à chaud, effectuer une mise en correspondance de modèles par rapport aux journaux bruts non analysés ou rechercher des données structurées sur les cas. Pour obtenir des conseils sur l'optimisation, consultez les bonnes pratiques de recherche dans UDM.

Le tableau suivant récapitule les principales fonctionnalités de recherche disponibles sur la plate-forme :

Type de recherche	Fonction architecturale
Recherche UDM	Moteur de recherche structuré principal qui interroge les événements UDM normalisés et indexés au cours de la période active de 12 mois. Il permet le filtrage, les agrégations et les corrélations multifields sur des sources de journaux disparates.
Analyse du journal brut	Analyse les chaînes de texte d'origine non analysées des journaux ingérés. Cette fonctionnalité est compatible avec les expressions régulières (regex) et les recherches de sous-chaînes pour les artefacts et les paramètres personnalisés non mappés à une syntaxe UDM spécifique.
Recherche en langage naturel	Utilise l'IA Gemini pour traduire les questions en langage naturel directement en syntaxe de recherche UDM formelle, ce qui accélère la création de requêtes et les workflows d'investigation.
Recherche de demandes	Moteur de recherche spécialisé dans la couche de réponse, qui interroge les cas d'investigation, les alertes, les playbooks et les métadonnées d'entité annotées dans la base de données SOAR.

Boucle de détection et de réponse aux menaces

L'architecture Google SecOps crée une boucle de rétroaction continue entre l'analyse de la détection et la réponse automatisée. Les règles de détection génèrent des alertes de haute fidélité qui déclenchent des workflows de réponse, tandis que les résultats des investigations fournissent des commentaires utilisés pour affiner et ajuster la logique de détection future.

Architecture de l'entonnoir de détection

Le moteur de détection utilise une approche en entonnoir à plusieurs étapes pour distiller d'énormes volumes de données de télémétrie de sécurité brutes en alertes de haute fidélité :

1. Ingestion et normalisation : les journaux bruts sont ingérés en continu et mis en forme dans des structures d'événements UDM standards.
2. Enrichissement : les événements sont enrichis de manière dynamique avec des mappages d'alias, des données contextuelles sur les composants et des renseignements sur les menaces mondiales provenant de sources telles que Google Threat Intelligence.
3. Évaluation de la détection : le moteur YARA-L 2.0 avec état évalue les événements enrichis par rapport aux règles comportementales et de menace sur des périodes étendues. Pour obtenir des consignes sur l'optimisation des règles, consultez les bonnes pratiques Yara-L.
4. Hiérarchisation et regroupement : les détections correspondantes sont agrégées dans des alertes, auxquelles sont attribués des scores de risque dynamiques, et regroupées dans des demandes unifiées.

En combinant les données contextuelles sur les composants aux renseignements sur les menaces, cette stratégie en entonnoir filtre les anomalies inoffensives (en réduisant les faux positifs) et met en évidence les véritables menaces (en réduisant les faux négatifs). Votre équipe de sécurité peut ainsi se concentrer sur les incidents exploitables.

Correction automatisée et boucle de rétroaction

Le pipeline de détection et de réponse combine l'évaluation des règles avec état, le tri et l'endiguement automatisés :

1. Évaluation continue : flux de télémétrie UDM enrichis via le moteur de détection avec état YARA-L 2.0.
2. Création de demandes et triage par IA : lorsqu'une condition de règle est remplie, Google SecOps génère une alerte et ouvre une demande. Un agent de tri et d'investigation optimisé par l'IA exécute des recherches dynamiques et des recherches sur le renseignement sur les menaces pour évaluer les résultats.
3. Exécution automatisée des playbooks : si le triage par IA confirme un vrai positif, la plate-forme déclenche des playbooks de réponse automatisés (par exemple, l'isolement d'un point de terminaison ou la suspension d'un compte utilisateur via des agents à distance). Si la demande est classée comme faux positif, elle est automatiquement clôturée.
4. Ajustement continu : les résultats de la correction et les verdicts de tri des analystes sont réinjectés pour affiner les seuils de détection et réduire les futurs faux positifs.

Calque de détection des menaces

Le moteur YARA-L 2.0 évalue la télémétrie UDM entrante à l'aide d'un pipeline de streaming en plusieurs étapes pour détecter les anomalies comportementales et les schémas d'attaque multi-événements sur des périodes prolongées. Vous pouvez également générer et affiner des règles YARA-L à l'aide de Gemini.

Le cycle de vie du traitement de chaque règle YARA-L comporte cinq étapes d'évaluation distinctes :

1. Ingestion (Ingest) : les événements UDM enrichis entrent dans le pipeline d'évaluation de la détection en temps réel.
2. Filtrage (Filter) : les événements entrants sont évalués par rapport aux critères d'événement de la règle (section events). Les événements qui ne correspondent pas sont ignorés, tandis que ceux qui correspondent sont transmis à l'évaluation avec état.
3. Regroupement des correspondances (Window) : les événements correspondants sont regroupés par clés de corrélation spécifiées sur une période définie (de quelques secondes à 12 mois). Le moteur suit plusieurs minuteurs avec état simultanés (TimerStart à TimerEnd) à mesure que les événements s'accumulent.
4. Évaluation des conditions (Condition) : lorsque la fenêtre de correspondance se ferme ou se déclenche, le moteur évalue les seuils requis et les expressions mathématiques définis dans la section condition de la règle (comme les nombres d'événements, les seuils distincts ou les jointures de données croisées).
5. Déclenchement (Trigger) : si la condition est évaluée à True, le moteur génère une détection, ce qui déclenche une alerte et ouvre ou met à jour une demande dans la couche de réponse. Si la valeur est False, l'état est effacé sans déclencher d'alerte.

Machine à états d'exécution des règles

Le diagramme suivant illustre le cycle de vie de l'exécution d'une règle.

Architecture de réponse et exécution à distance

Google SecOps SOAR représente le pilier de réponse de la plate-forme. Il fonctionne comme un moteur d'orchestration au-dessus de la couche d'analyse pour ingérer les alertes, trier les cas et exécuter les workflows de réponse automatisés.

Orchestration, automatisation et investigation

La couche de réponse inclut des outils spécialisés conçus pour simplifier les workflows du centre des opérations de sécurité (SOC) pour l'investigation, la gestion des demandes et l'automatisation des playbooks :

• Gestion des demandes : regroupez les alertes associées dans des demandes unifiées, triez et filtrez les files d'attente des incidents, attribuez des tâches et collaborez sur les enquêtes avec un suivi d'audit complet.
• Concepteur de playbooks : créez des playbooks de réponse automatisée à l'aide d'un canevas visuel sans code par glisser-déposer avec des actions d'intégration prédéfinies.
• Environnement de développement intégré (IDE) : utilisez l'IDE intégré basé sur le code pour écrire des scripts Python personnalisés, modifier des intégrations d'actions existantes et déboguer des workflows d'automatisation complexes.
• Vues d'investigation et outil d'investigation graphique : visualisez les chemins d'attaque et les relations entre les entités à l'aide de vues d'investigation basées sur des graphiques. Les résumés d'entités dédiés (comme les vues "Composant", "Adresse IP", "Hachage", "Domaine" et "Utilisateur") affichent instantanément les événements de la chronologie pertinents.
• Tableaux de bord et rapports : suivez les métriques opérationnelles du SOC, la charge de travail des analystes et le délai moyen de réponse (MTTR) à l'aide de tableaux de bord prêts à l'emploi ou de widgets de reporting personnalisés.

Architecture des composants SOAR

Le diagramme suivant illustre le flux des alertes entrantes dans le moteur de gestion des demandes, qui déclenche des workflows de correction automatisés dans les playbooks visuels et les intégrations IDE personnalisées.

Architecture de l'agent distant

Pour exécuter des actions de correction dans des réseaux privés (tels que des centres de données sur site ou des clouds privés virtuels), Google SecOps s'appuie sur une architecture d'agent distant sécurisée et sortante uniquement.

Dans ce modèle, la plate-forme Google SecOps n'initie jamais de connexions entrantes à votre environnement privé :

1. Lancement de la tâche : lorsqu'une action de playbook nécessite une exécution locale, Google SecOps publie l'instruction dans une file d'attente d'éditeur sécurisée hébergée dans Google Cloud.
2. Interrogation asynchrone : l'agent distant déployé dans votre environnement privé interroge en continu la file d'attente de l'éditeur via une connexion sortante chiffrée par TLS.
3. Exécution locale : lorsqu'une instruction de tâche est récupérée, l'agent distant exécute l'action requise localement sur les outils de sécurité internes ou les points de terminaison réseau (par exemple, en désactivant un compte ou en bloquant un port de pare-feu).
4. Rapports d'état : une fois l'action terminée, l'agent à distance renvoie l'état de l'action et les journaux d'exécution à la file d'attente de l'éditeur via TLS, où ils sont récupérés et affichés dans la vue de la demande SOAR.

Sécurité, conformité et responsabilité partagée

En tant que plate-forme cloud native, Google SecOps fonctionne selon un modèle de responsabilité partagée : Google est responsable de la sécurité de la plate-forme, tandis que vous êtes responsable de la sécurité dans la plate-forme.

Modèle de responsabilité partagée

Google SecOps hérite de la conception de sécurité de base, des capacités de calcul et de l'architecture de stockage de l'infrastructure Google Cloud . Dans ce modèle :

• Google gère la sécurité physique des centres de données, l'infrastructure cloud sous-jacente, la disponibilité de la plate-forme et le chiffrement par défaut des données au repos et en transit.
• Vous gérez la gouvernance des données, les contrôles d'accès et le RBAC des données configurés via Identity and Access Management (IAM), les règles de détection personnalisées et les paramètres de conformité du locataire.

Toutes les exigences de conformité, les règles de résidence des données et les règles d'accès sont héritées et appliquées à partir de la hiérarchie de votre organisation, en passant par les dossiers et les projets, jusqu'à votre locataire contrôlé par la conformité.

Conformité et préparation des entreprises

Pour répondre aux exigences strictes en matière de gouvernance réglementaire et organisationnelle, Google SecOps propose des locataires contrôlés conformes. Ces locataires appliquent des normes de sécurité rigoureuses grâce à Assured Workloads, qui prend en charge à la fois les frameworks de conformité réglementaire et les packages de protection des données techniques.

Cadres de conformité réglementaire compatibles :

• FedRAMP : niveaux d'impact modéré et élevé (FEDRAMP_MODERATE, FEDRAMP_HIGH)
• Niveaux d'impact DoD : IL4 et IL5 (IL4_AND_IL5)
• Santé et finance : HIPAA et PCI DSS (HIPAA, PCI_DSS)

Pour déployer un locataire contrôlé par la conformité, associez votre instance Google SecOps à un projet Google Cloud situé dans un dossier Assured Workloads configuré pour le package de contrôle requis.

Résidence des données et transparence des accès

Les équipes Google SecOps appliquent une isolation stricte des locataires logiques et sont compatibles avec Access Transparency pour vous offrir un contrôle vérifiable et une visibilité sur l'audit de l'accès aux données administratives.

Packages de sécurité et de résidence des données compatibles :

• Clés de chiffrement gérées par le client (CMEK) : contrôlez et gérez les clés utilisées pour chiffrer les données au repos (CMEK_V1).
• Résidence avancée des données : appliquez des limites régionales de résidence des données et des contrôles d'accès administrateur (DRZ_ADVANCED).
• VPC Service Controls : établissez des périmètres sécurisés et personnalisés autour de vos ressources de sécurité cloud à l'aide de VPC Service Controls (VPC-SC).

L'architecture de sécurité de la plate-forme repose sur un modèle d'héritage à quatre niveaux, dans lequel vos contrôles de sécurité administratifs s'appuient sur les bases renforcées de l'infrastructure Google principale :

Pile de sécurité à quatre couches :

1. Couche de contrôle de sécurité du client : vos contrôles administratifs de premier niveau, y compris les contrôles d'accès basés sur les rôles (RBAC) gérés par Identity and Access Management (IAM), les clés de chiffrement gérées par le client (CMEK) et les règles régionales de résidence des données.
2. Couche de sécurité de la plate-forme : isolation logique des locataires, chiffrement par défaut des données au repos et en transit (TLS), et journalisation d'audit Access Transparency.
3. Couche d'infrastructure Google : infrastructure de calcul et de stockage de base, y compris la gestion des clusters Borg, le stockage distribué Colossus et les bases de données mondiales Spanner.
4. Couche de sécurité physique : sécurité fondamentale assurée par les centres de données Google pour les entreprises, les contrôles biométriques multifactoriels et les puces de sécurité Titan personnalisées (roots of trust).

Par exemple, lorsque Access Transparency est activé, si un spécialiste de l'assistance ou de l'ingénierie Google accède aux données de votre locataire pour résoudre une demande d'assistance, il doit fournir une justification d'accès cryptographique valide. Cette demande d'accès est enregistrée de manière sécurisée et est visible dans vos journaux d'audit en temps quasi réel.

Vous avez encore besoin d'aide ? Obtenez des réponses de membres de la communauté et de professionnels Google SecOps.