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 télémétrie 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ée sur l'infrastructure sur laquelle reposent les principaux services mondiaux de Google, elle 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 à chaud et à froid.

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 les fonctionnalités d'opérations de sécurité qui étaient auparavant distinctes. Il 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 les renseignements sur les menaces de Google Threat Intelligence et de VirusTotal, ainsi que des fonctionnalités d'IA générative basées sur 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 native spécialisé, basé sur une infrastructure de base Google Cloud . 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 système

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

• Entrées : ingère la télémétrie des environnements hybrides, y compris les collecteurs sur site (tels que l'agent BindPlane), les API de fournisseur de services cloud et les connecteurs directs Software-as-a-Service (SaaS) tiers.
• 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 demandes SOAR.
• Sorties : fournit des renseignements de sécurité exploitables et des insights de tri basés sur l'IA aux analystes, tout en renvoyant des commandes de confinement automatisées aux environnements cibles via des API et des agents distants.

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 architectures héritées déplacent la télémétrie plus ancienne vers le stockage à froid, ce qui ralentit les requêtes ou nécessite une réhydratation manuelle. En revanche, Google SecOps conserve toute la télémétrie ingérée dans un état actif et indexable jusqu'à 12 mois. 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 non structurés en Unified Data Model (UDM) structuré. Lors de la normalisation, le pipeline enrichit chaque événement avec des métadonnées contextuelles provenant du graphique de contexte d'entité.

Architecture de collecte

L'ingestion des 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 transmettre à Google SecOps.
• API d'ingestion : points de terminaison d'API REST directs qui ingèrent la télémétrie structurée et non structurée à partir de services cloud, d'applications personnalisées et de 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 Unified Data Model

L'Unified Data Model (UDM) normalise les journaux de différents fournisseurs dans un schéma unique et structuré. Cette représentation standard simplifie l'analyse et la recherche 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 l'horodatage 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 lancé l'activité (telle que l'utilisateur, l'hôte, l'adresse IP ou le processus d'origine).
• Cible : entité directement affectée par l'activité (telle que le fichier cible, l'hôte de destination ou le compte utilisateur).
• Source, intermédiaire et observateur : participants secondaires au réseau (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é par l'appareil de sécurité (par exemple, ALLOWED, BLOCKED ou QUARANTINED).
• Extensions : champs personnalisés et paires clé/valeur spécifiques au fournisseur qui ne font pas partie du schéma de base standard. Pour en savoir plus sur le mappage des définitions et le développement d'analyseurs, consultez Configurer des analyseurs personnalisés et Champs UDM importants.

Diagramme de classes UDM

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

Architecture de 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 de demande structurées. Pour obtenir des conseils d'optimisation, consultez Bonnes pratiques de recherche UDM.

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

Type de recherche	Fonction architecturale
Recherche UDM	Principal moteur de recherche structuré qui interroge les événements UDM normalisés et indexés dans la fenêtre à chaud de 12 mois. Il permet le filtrage, les agrégations et les corrélations multi-champs dans différentes sources de journaux.
Analyse des journaux bruts	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 qui ne sont pas mappés à une syntaxe UDM spécifique.
Recherche en langage naturel	Utilise l'IA Gemini pour traduire directement les questions en langage naturel 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 demandes 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 détection et la réponse automatisée. Les règles de détection génèrent des alertes haute fidélité qui déclenchent des workflows de réponse, tandis que les résultats de l'investigation 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 télémétrie de sécurité brute en alertes haute fidélité :

1. Ingestion et normalisation : les journaux bruts sont ingérés et mis en forme en continu dans des structures d'événements UDM standard.
2. Enrichissement : les événements sont enrichis de manière dynamique avec des mappages d'alias, des données d'éléments contextuelles 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 menaces sur des fenêtres temporelles étendues. Pour obtenir des conseils sur l'optimisation des règles, consultez Bonnes pratiques YARA-L.
4. Priorisation et regroupement : les détections correspondantes sont agrégées en alertes, auxquelles sont attribués des scores de risque dynamiques, et regroupées dans des demandes unifiées.

En combinant les données d'éléments contextuelles avec les renseignements sur les menaces, cette stratégie d'entonnoir filtre les anomalies inoffensives (réduisant ainsi les faux positifs) et met en évidence les menaces réelles (réduisant ainsi les faux négatifs), ce qui aide votre équipe de sécurité à se concentrer sur les incidents exploitables.

Boucle de correction et de rétroaction automatisées

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

1. Évaluation continue : les flux de télémétrie UDM enrichis passent par le moteur de détection YARA-L 2.0 avec état.
2. Création de demandes et tri 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 basé sur l'IA exécute des recherches dynamiques et des recherches de renseignements sur les menaces pour évaluer les résultats.
3. Exécution automatisée de playbooks : si le tri par IA confirme un vrai positif, la plate-forme déclenche des playbooks de réponse automatisés (par exemple, l'isolation d'un point de terminaison ou la suspension d'un compte utilisateur via des agents distants). Si la demande est classée comme faux positif, elle est automatiquement fermé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.

Couche 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 à plusieurs étapes pour détecter les anomalies comportementales et les modèles d'attaque multi-événements sur des fenêtres temporelles étendues. 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 suit 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 les événements correspondants passent à l'évaluation avec état.
3. Fenêtrage de correspondance (Window) : les événements correspondants sont regroupés par clés de corrélation spécifiées sur une fenêtre temporelle définie (allant 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 exigences de seuil et les expressions mathématiques définies dans la section condition de la règle (telles que les nombres d'événements, les seuils distincts ou les jointures entre données).
5. Déclenchement (Trigger) : si la condition renvoie True, le moteur génère une détection, déclenchant une alerte et ouvrant ou mettant à jour une demande dans la couche de réponse. Si la condition renvoie 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 demandes et exécuter des workflows de réponse automatisés.

Orchestration, automatisation et investigation

La couche de réponse inclut des outils spécialisés conçus pour rationaliser les workflows du centre des opérations de sécurité (SOC) dans les domaines de l'investigation, de la gestion des demandes et de 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 aux investigations avec un suivi d'audit complet.
• Concepteur de playbooks : créez des playbooks de réponse automatisés à 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 les intégrations d'actions existantes et déboguer des workflows d'automatisation complexes.
• Vues d'investigation et investigateur de graphiques : 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 (tels que les vues "Élément", "Adresse IP", "Hachage", "Domaine" et "Utilisateur") affichent instantanément les événements pertinents de la chronologie.
• 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 montre comment les alertes entrantes sont transmises au moteur de gestion des cas et déclenchent 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 uniquement sortante.

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

1. Lancement de tâches : lorsqu'une action de playbook nécessite une exécution locale, Google SecOps publie l'instruction dans une file d'attente de publication 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 publication 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 par rapport aux outils de sécurité internes ou aux points de terminaison réseau (par exemple, la désactivation d'un compte ou le blocage d'un port de pare-feu).
4. Rapports d'état : une fois l'opération terminée, l'agent distant renvoie l'état de l'action et les journaux d'exécution à la file d'attente de publication 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é des locataires.

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

Conformité et préparation des entreprises

Pour répondre aux exigences strictes de gouvernance réglementaire et organisationnelle, Google SecOps propose des locataires contrôlés par la conformité. Ces locataires appliquent des normes de sécurité rigoureuses via Assured Workloads, qui prend en charge à la fois les cadres 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 du 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 Google Cloud projet situé dans un dossier Assured Workloads configuré pour le package de contrôle requis.

Résidence des données et Access Transparency

Google SecOps applique une isolation stricte des locataires logiques et prend en charge Access Transparency pour vous offrir un contrôle vérifiable et une visibilité d'audit sur 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 administratifs (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 couches, dans lequel vos contrôles de sécurité administratifs s'appuient sur les bases renforcées de l'infrastructure Google de base :

La pile de sécurité à quatre couches :

1. Couche de contrôle de sécurité 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 via 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é de base assurée par les centres de données d'entreprise Google, les contrôles biométriques multifacteurs 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 un ticket 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 rendue visible dans vos journaux d'audit en temps quasi réel.

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