Déployer Google SecOps : SIEM, SOAR et identité dans une seule plateforme

Dans 56 % des incidents, les organisations ont appris qu'elles étaient compromises par une entité externe, selon Mandiant M-Trends 2024 ; le chiffre de M-Trends 2023 cité par le matériel est encore plus dur : 63 % des organisations confrontées à des incidents n'ont pas su qu'elles avaient été breachées et ont dû l'apprendre par un tiers. Cet écart entre ce qui se passe et ce qui est su est ce qu'une plateforme unifiée promet de combler. « Introduction to Google Security Operations: Unified SecOps », le tutoriel de Google Skills, parcourt Google SecOps de son histoire à la provision du tenant. Ce post le suit dans cet ordre.

Une plateforme avec trois pièces dedans

Google SecOps présente une expérience unifiée de SIEM (le système qui ingère, normalise et rend interrogeables les données de sécurité), SOAR (la couche qui orchestre la réponse avec des playbooks) et de renseignement sur les menaces, soutenue par l'IA avec Gemini et SecLM. Les quatre points forts de capacité sont la collecte de télémétrie on-premise et cloud, le renseignement de menaces appliqué avec ML qui compare les IOC à toute la télémétrie au moment de l'ingestion, l'analytique et la détection avec des recherches qui montent aux pétaoctets, et le triage des alertes avec réponse automatisée pour réduire le MTTR.

L'histoire du produit aide à comprendre la proposition. Elle démarre dans la sécurité interne de Google, une décennie de données de sécurité à l'échelle exaoctet. En 2019, Backstory/Chronicle est lancé avec une ingestion multicloud de plus de 1 300 types de logs et plus de 700 parsers qui convertissent le log brut en UDM (Unified Data Model, le format normalisé avec lequel on enquête et détecte ensuite). En 2022 est venue l'acquisition de Siemplify, qui a apporté le SOAR complet, des playbooks glisser-déposer avec plus de 300 intégrations, et avec cela le renseignement de menaces s'est élargi : Google Threat Intelligence, l'expérience de première ligne de Mandiant avec plus de 500 chercheurs et 350 groupes de menaces suivis, et VirusTotal avec 50 milliards de fichiers et 6 milliards d'URL.

Comment les données circulent

flowchart LR
    F[Sources : multicloud, EDR,<br/>identité, réseau, CNAPP] --> C[Collecteurs et BindPlane<br/>OpenTelemetry, feeds, APIs]
    C --> G[Organisation et projet GCP<br/>Chronicle API, IAM, WIF]
    G --> S[SIEM : normalisation vers UDM,<br/>enquête, détection]
    G --> O[SOAR : playbooks,<br/>intégrations, cas]
    S --> X[Ticketing, confinement,<br/>notifications, remédiation]
    O --> X

SecOps est un SaaS : pas d'infrastructure propre à installer ni à gérer, on y accède par navigateur et on lui envoie des données. Les collecteurs sont le composant on-prem typique, celui qui recueille les sources locales comme les logs Windows ou syslog et les envoie au cloud ; les feeds cloud-to-cloud et par API n'en ont pas besoin. Le Chronicle Forwarder est en cours de dépréciation : Google recommande des collecteurs basés sur OpenTelemetry et BindPlane, une couche d'observabilité incluse avec la licence qui permet de gérer les configurations à grande échelle et, selon la licence, de filtrer, acheminer vers le stockage à froid ou masquer des données. Un détail qu'on passe outre : les collecteurs simples envoient des données brutes, car le traitement se fait sur la plateforme.

Une fois à l'intérieur, le flux continue dans le projet GCP, où vivent le Chronicle API, les politiques IAM et le Workforce Identity Pool et Provider. Là, le SIEM normalise, enquête, détecte et visualise ; le SOAR exécute les playbooks, les intégrations et la gestion des cas. Les sorties vont vers le ticketing, le confinement, les notifications et la remédiation.

Le déploiement, en trois phases

Le processus se résume en trois étapes de haut niveau, et les deux premières sont un prérequis de la troisième.

flowchart TD
    P1[Phase 1 : environnement GCP<br/>organisation, projet 1:1, Chronicle API] --> P2[Phase 2 : authentification<br/>Google Identity ou WIF + Cloud IAM]
    P2 --> P3[Phase 3 : provisionner le tenant]
    P3 --> T{Qui l'exploite ?}
    T -->|Client direct ou revendeur| ST[Single-tenant : sept étapes<br/>et onboarding UI guidé]
    T -->|Client d'un MSSP| MT[Multi-tenant : Customer Management API<br/>et configuration du partenaire]

D'abord, configurer l'environnement GCP. L'organisation GCP est le nœud racine de la hiérarchie des ressources et se crée en enregistrant un compte Workspace ou Cloud Identity, le superadministrateur acceptant les conditions. Le projet GCP est lié à SecOps en relation 1:1 et le Chronicle API doit y être activé ; la recommandation est de créer un projet neuf et dédié.

Ensuite, définir l'authentification, avec deux chemins. Google Identity utilise les comptes Workspace ou Cloud Identity existants, sans fédération, et mappe directement les rôles Cloud IAM aux utilisateurs. Il a des limites déclarées en juillet 2025 : il ne permet pas de personnaliser le RBAC de SOAR, seulement les rôles prédéfinis de Cloud IAM ; ce n'est pas un patron pris en charge pour les clients devant se conformer à FedRAMP High ; et ça ne fonctionne généralement pas dans les déploiements MSSP, où chaque partie utilise son propre IdP et cela n'est pris en charge que par fédération.

Workforce Identity Federation est l'autre chemin : il exige une application SAML avec mapping d'attributs, admet plusieurs SSO, prend en charge FedRAMP High et le RBAC granulaire de SOAR. Ses trois composants s'emboîtent comme des pièces. L'IdP est la source de vérité et doit supporter SAML 2.0 : Cloud Identity, Workspace ou un IdP tiers comme Okta ou Entra ID. Le Workforce Identity Federation vit au niveau de l'organisation GCP : le Pool accorde l'accès et le Provider garde les détails d'un seul IdP. Et les politiques Cloud IAM, dans le projet lié, accordent les rôles SecOps à ces identités avec un member de la forme principalSet du chemin du workforce pool avec le groupe.

Les rôles concernés sont Chronicle API Admin, Editor, Viewer et Limited Viewer (roles/chronicle.*), alignés dans l'IdP avec des groupes comme google-secops-admin. Le couplage entre mondes mérite attention : les attributs SAML requis sont groups, first name, last name et email, et l'ACS URL et l'Entity ID de l'application doivent référencer les IDs du Pool et du Provider, il vaut donc les prédéfinir avant de créer l'application ; le Provider traduit ensuite chaque attribut avec des expressions CEL comme assertion.attributes.first_name[0].

Troisièmement, provisionner le tenant : un processus d'invitation guidé pour le client direct, ou l'API pour les déploiements MSSP.

Single-tenant contre multi-tenant

Le choix du patron décide qui administre et comment se fait la provision. En single-tenant, pour les clients directs ou via revendeur avec licences Enterprise et Enterprise Plus, le client possède la licence et administre son tenant dans son propre projet GCP ; Google administre le SIEM et le SOAR, et tout le flux est piloté par l'UI. Le parcours a sept étapes : organisation GCP, projet GCP dédié avec Chronicle API, IdP avec groupes et application SAML, Workforce Identity Federation avec Pool et Provider, politiques Cloud IAM, provisioning et validation.

L'onboarding guidé fonctionne par invitation : un représentant de Google lance le processus après le cycle de vente, l'utilisateur reçoit un lien par e-mail qui ouvre le provisioning dans la GCP Cloud Console, et là il confirme les informations de l'entreprise, choisit la région géographique de SecOps, révise le service account et configure le SSO. À la fin, l'accès à l'UI est validé.

En multi-tenant, pour les clients d'un partenaire MSSP, GSI ou OEM, le SIEM est géré et le SOAR appartient au partenaire, et l'administration est pilotée par API. Google provisionne d'abord le tenant MSSP, le parent, puis le partenaire configure le projet GCP du client au sein de son organisation (un projet par tenant), son IdP et deux Workforce Identity Pools, avec des politiques Cloud IAM pour les deux. Le tenant du client se crée avec la Customer Management API en cinq appels : GetCustomer, SetWorkforcePoolProvider, SetAuthVersion avec AUTH_VERSION_3, SetUIState et EnableIAM. Deux restrictions pratiques : les tenants client doivent se créer dans la même région que le tenant MSSP, et aujourd'hui les MSSP ne peuvent provisionner que le SIEM, car le provisioning du SOAR est un processus Google.

Le tableau de bord où le travail se fait

Dans une instance unifiée, SIEM et SOAR coexistent dans un seul panneau de navigation. La page d'accueil s'ouvre par défaut sur SIEM Search et est personnalisable ; un SOC peut préférer ouvrir sur Cases. Cases est l'espace principal de l'analyste : nom, sévérité, état et propriétaire du cas visibles sans déplier, avec une ou plusieurs alertes intégrées qui apportent les entités, les sources de détection et les horodatages. Workdesk est le quotidien : My Cases, Pending Actions pour les tâches de playbook en attente de révision manuelle, My Tasks, Requests, Workspace avec les ressources de l'équipe et Announcements pour les communications du SOC.

Ce qui reste à choisir

Choisir un patron n'est pas un détail d'installation : cela définit qui est propriétaire du tenant, qui l'exploite et avec quels outils on lui donne vie. Un client direct obtient la console et sept étapes ; un client de MSSP obtient une séquence d'API et la discipline de la région unique. Et l'authentification, qui passe souvent pour l'étape ennuyeuse, est l'endroit où se décident des choses qui ensuite ne se défont pas d'un clic, comme le RBAC de SOAR ou le chemin vers FedRAMP High.

Ce qui n'a pas été vérifié : les deux contrôles de connaissances n'ont pas été ouverts, donc aucune affirmation sur leurs réponses, et les limites datées, comme celle de Google Identity en juillet 2025, valent d'être revalidées face à la documentation en vigueur avant de concevoir un déploiement réel.

*Source : « Introduction to Google Security Operations: Unified SecOps », de Google Skills.*