Security Command Center depuis zéro : actifs, détection et conformité dans un seul tableau de bord

Toute organisation sur Google Cloud accumule le même problème avec le temps : les actifs se multiplient, les sources d'alerte se dispersent, et personne n'a de réponse confortable à « qu'avons-nous et à quel point est-on exposé ? ». Security Command Center (SCC) est la réponse de Google Cloud à cette question : une plateforme de posture de sécurité et de détection de menaces qui réunit inventaire et visibilité des actifs, détection précoce des menaces en intégrant plusieurs sources, détection de vulnérabilités, gestion de la conformité et gestion des actifs avec traçabilité.

La carte complète de cette plateforme est « Security Command Center Fundamentals », de Google Skills, et c'est ce que je parcours ici : les deux tiers, les services de détection, le tableau de bord, les findings et la lecture de conformité.

Les deux tiers et le périmètre d'activation

Le tier standard est gratuit pour tous les utilisateurs de Google Cloud et comprend un tableau de bord centralisé de findings, l'inventaire et la découverte des actifs, des recommandations Security Health de base et les security marks. Le tier premium est payant et ajoute Event Threat Detection, Container Threat Detection, VM Threat Detection, Rapid Vulnerability Detection et Web Security Scanner.

La règle d'héritage compte quand on planifie le budget : si le premium est activé au niveau organisation, tous les projets l'héritent. L'activation peut se faire au niveau organisation, dossier ou projet, et si elle se fait par projet, certaines fonctions de détection et intégrations ne sont pas disponibles à cause du périmètre réduit. Le tier en vigueur se consulte dans Security Command Center → Settings → Tier detail.

Les services, divisés en deux familles

Les services built-in sont inclus dans SCC et les services integrated envoient les findings à SCC depuis d'autres produits. La carte des built-in :

flowchart TD
    subgraph Built[Inclus dans SCC]
        SHA[Security Health Analytics] --> WSS[Web Security Scanner]
    end
    subgraph Premium[Payant dans le tier premium]
        ETD[Event Threat Detection] --> CTD[Container Threat Detection]
        CTD --> VTD[VM Threat Detection]
    end

Security Health Analytics évalue les vulnérabilités et les mauvaises configurations de façon automatisée sur Compute Engine, Cloud Storage, Cloud SQL, Cloud DNS et plus ; il est activé par défaut sur les deux tiers. Web Security Scanner parcourt les applications web sur App Engine, GKE et Compute Engine. Event Threat Detection surveille Cloud Logging à la recherche de malware, de phishing et de force brute. Container Threat Detection inspecte les node images de Container-Optimized OS. Rapid Vulnerability Detection est un scanner sans configuration pour les endpoints publics. Et VM Threat Detection travaille au niveau de l'hyperviseur, activé automatiquement par projet.

Le tableau de bord : sept pages

L'accès se fait par menu de navigation → Security → projet ou organisation. La page overview montre les nouvelles menaces dans le temps, les vulnérabilités par type de ressource et les vulnérabilités actives avec des onglets par catégorie, ressource et projet, tous triables par sévérité, avec des plages allant d'une heure à six mois. Ensuite viennent threats (seulement en premium, par sévérité, catégorie et projet), vulnerabilities, compliance, assets, findings et sources.

Actifs, labels et security marks

La page assets est le dépôt central de toutes les ressources Google Cloud utilisées ou précédemment utilisées, avec filtre rapide par type de ressource, projet (quand SCC est actif au niveau organisation) et région ou zone. En sélectionnant un actif, on voit ses ressources, son état de sécurité (total des findings et propriétaire), ses security marks et labels, et l'onglet full metadata avec les détails de configuration. La liste est mise à jour par Cloud Asset Inventory.

Labels et security marks remplissent des fonctions distinctes et il vaut ne pas les confondre. Les labels classent les actifs par fonction, sensibilité ou exigences de conformité. Les security marks étiquettent les findings avec des informations de sécurité, par exemple l'environnement, pour les localiser et les filtrer.

La page sources est le centre des findings, avec des cartes par source activée : findings by source, container threat detection, web security scanner, security health analytics, event threat detection, sensitive data protection et cloud armor (qui apparaît là comme source intégrée, même si ce n'est pas un service built-in de SCC).

Security Health Analytics, avec détecteurs personnalisés

C'est le moteur activé par défaut, et son cycle a un détail opérationnel à connaître avant de se plaindre : le premier scan d'une ressource activée peut prendre jusqu'à 12 heures, et ensuite la ressource est scannée deux fois par jour. Les détecteurs s'activent ou se désactivent dans l'onglet Modules.

En tier premium, on peut créer des détecteurs personnalisés avec une logique de détection en CEL (Common Expression Language). L'exemple du matériel : détecter si une crypto key de Cloud KMS n'a pas été rotée sur une période. Le flux est Settings → Security Health Analytics → Manage settings → Modules → Create module, avec nom, type de ressource, logique de détection, sévérité, description et étapes de remédiation ; le détecteur peut être testé avec un YAML de asset data avant de le créer (requiert l'API Security Command Center activée). Les résultats apparaissent sur la page vulnerabilities avec état, dernière détection, catégorie (open firewall, open SSH port, public IP), module ID, recommandation, findings actifs et standards.

Les couches de détection, une par une

Event Threat Detection scanne en continu les enregistrements Cloud Logging de l'organisation ou des projets et crée un finding quand il détecte un comportement inhabituel. Il s'active avec le tier premium et s'active ou se désactive par dossier ou projet depuis Settings → Event threat detection → Manage settings. Un détail qui décide si le détecteur fonctionne : pour détecter une force brute SSH, il est indispensable d'activer l'enregistrement d'authentification (auth log), car les détecteurs ne fonctionnent qu'avec les types d'enregistrement que la règle exige. Les détecteurs intégrés ne se modifient qu'au niveau organisation, et depuis Create module on en crée un propre avec nom, régions, sévérité (de critical à low), description et étapes de remédiation. La démo du matériel accorde le rôle Owner de Basic à un compte Gmail externe et déclenche le finding « IAM anomalous grant », avec résumé généré par IA.

Container Threat Detection scanne en continu les node images de Container-Optimized OS pour détecter des attaques en runtime. L'instrumentation collecte l'activité du guest kernel et des scripts bash exécutés et l'envoie, via un DaemonSet user-mode, à un service détecteur ; le DaemonSet travaille en mode best effort, c'est-à-dire que si Kubernetes met du temps à livrer les informations du conteneur, la donnée peut manquer dans le finding. Pour décider si un script bash est malveillant, le service utilise des techniques de traitement du langage naturel. Ses cinq détecteurs : added binary executed, added library loaded, malicious script executed, malicious URL observed (arguments de processus comparés à Google Safe Browsing) et reverse shell. Requiert des clusters GKE en version prise en charge. La démo déploie une image Ubuntu 18.04, copie un binaire vers un autre chemin et l'exécute : le finding « added binary executed » apparaît.

VM Threat Detection travaille avec une instrumentation au niveau de l'hyperviseur, sous la couche système d'exploitation des VM. Détecte le minage de cryptomonnaies, les rootkits en mode kernel et d'autres menaces de haute sévérité sans agent dans la VM, sans consommer le CPU de la VM et sans réseau nécessaire ; les signatures sont gérées par Google. Chaque VM nouvelle est scannée à la création et re-scanée toutes les 30 minutes. Sur le minage de cryptomonnaies, il remonte un finding par processus, par VM et par jour ; les constats non liés à un processus sont regroupés en un finding par VM toutes les 24 heures ; et les menaces persistantes génèrent de nouveaux findings toutes les 24 heures. La démo exécute une application de minage sur une VM de test et déclenche « execution cryptocurrency mining Yara rule », avec onglet résumé et onglet JSON.

Web Security Scanner parcourt les applications web en suivant les liens depuis les URLs de départ et en testant les entrées utilisateur et les gestionnaires d'événements. Il détecte XSS, injection SQL, contenu mixte HTTP/HTTPS et bibliothèques obsolètes ou non sécurisées, aligné avec les catégories OWASP Top 10. Ses limites sont déclarées : il ne prend en charge que les URLs et IPs publiques non protégées par firewall, requiert d'activer son API et le service dans Settings, et n'envoie les findings à SCC que si la case « export to Security Command Center » est cochée dans la configuration du scan. Sans programmation, le scan se déclenche manuellement avec Run et peut prendre plus de 10 minutes.

Findings : l'unité de travail

La page findings est le dépôt central des problèmes détectés, et ses filtres rapides enseignent le vocabulaire du produit. Par state : active (le problème persiste) ou inactive (résolu ou ressource supprimée). Par mute : masque un finding de la vue par défaut. Et par classe : threats (risque actif), vulnerabilities (failles latentes), misconfigurations (configurations qui élargissent la surface d'exploitation), observations (alertes informatives), SCC errors (pannes système qui peuvent empêcher le monitoring) et posture violations (signaux d'affaiblissement de la posture). Aussi par projet, type d'asset, sévérité et source.

flowchart LR
    D[Détection par un service] --> F[Finding actif]
    F --> R[Révision et remédiation]
    R --> I[Inactive ou mute]

Pour travailler en équipe, les permissions régissent l'interaction : securitycenter.admin a un accès complet aux findings (état, remédiation, politiques), tandis que le viewer ne fait que consulter. La démo attribue « Security Center findings viewer » à un utilisateur depuis IAM pour illustrer cette séparation.

Conformité : passed, warning et un CSV

SCC génère des rapports de conformité par projet, dossier ou organisation. Chaque contrôle est évalué comme « passed » (contrôle conforme, sans violations) ou « warning » (findings actifs associés au contrôle), avec des pourcentages de chaque état par standard. Depuis la page de conformité on approfondit les contrôles en warning et on exporte des rapports CSV, en choisissant la date et l'heure du snapshot ; le CSV inclut les projets dans le périmètre, les findings, les ressources scannées et les ressources en violation.

Standards couverts : CIS Google Cloud Computing Foundations Benchmark (de v1.0.0 à v2.0.0), CIS Kubernetes Benchmark, PCI DSS, NIST 853, ISO 27001 et OWASP Top 10. Ce CSV est ce qu'il vaut mieux apporter à un audit.

Ce que la carte laisse et ce qui est resté non exécuté

Ce qui survit à tout changement d'interface, c'est la structure : actifs et sources comme base, détection par couches (événements dans les logs, conteneurs, VM et application web), findings comme unité de travail avec leurs classes et filtres, et conformité comme lecture périodique exportable. Et deux rythmes opérationnels qui évitent les discussions : le premier scan de Security Health Analytics peut prendre jusqu'à 12 heures, et VM Threat Detection re-scan toutes les 30 minutes.

Ce qui est resté non exécuté dans cette documentation : le quiz n'a ni été ouvert ni soumis, la vidéo de bienvenue de la série ne publie ni transcription ni sous-titres sur sa page ni sur YouTube, et les noms d'utilisateurs et de projets cités (secc-user1, app development) sont fictifs de l'environnement de démonstration, de sorte que les parcours décrits se suivent dans un projet propre avec des permissions d'organisation.

---

*Source : « Security Command Center Fundamentals », de Google Skills (cours google.scc-fundamentals).*