Qu’est-ce que la sécurité Google Cloud ?
La sécurité Google Cloud n’est pas un produit qu’on active, mais deux choses distinctes : un ensemble de services de protection et de détection intégrés à la plateforme, et un partage de responsabilités qui laisse au client une part du travail que beaucoup découvrent après coup.
Google sécurise l’infrastructure : les centres de données, le matériel, l’hyperviseur, le chiffrement des données au repos et en transit entre ses sites. Le client reste responsable de ses données, de ses accès, de la configuration de ses services et du code qu’il déploie.
La quasi-totalité des incidents que l’on observe sur GCP relève de cette seconde moitié : un bucket Cloud Storage ouvert au public, un compte de service surprivilégié, une clé d’API laissée dans un dépôt Git.
Le modèle de responsabilité partagée : qui protège quoi ?
La frontière se déplace selon le type de service utilisé, ce qui explique bien des malentendus.
- Sur une machine virtuelle Compute Engine, le client gère le système d’exploitation, les correctifs, le pare-feu applicatif et les comptes locaux.
- Sur un service managé comme Cloud Run ou BigQuery, Google prend en charge le socle et les mises à jour. Restent au client les droits d’accès, le cloisonnement des données et la journalisation.
- Dans tous les cas, l’identité et les autorisations relèvent du client. C’est le point qui concentre le plus d’erreurs.
Autrement dit, une plateforme correctement sécurisée par son fournisseur peut être ouverte à quatre vents par une configuration client. Le contrat de sécurité de Google ne compense pas un rôle Éditeur attribué à un compte de service.
Les services de sécurité de Google Cloud
Le catalogue s’est étoffé et plusieurs produits ont changé de nom, ce qui rend les articles anciens trompeurs. Les intitulés en vigueur :
- IAM : la gestion des identités et des autorisations, qui conditionne tout le reste. Rôles prédéfinis, rôles personnalisés, comptes de service.
- Security Command Center : la console de posture et de détection, qui remonte les mauvaises configurations et les menaces. Trois niveaux existent, Standard, Premium et Enterprise ; ce dernier est déprécié et s’arrêtera le 21 mai 2027, avec bascule automatique vers Premium.
- Google Security Operations, anciennement Chronicle : la plateforme SIEM et SOAR de Google, avec ses règles de détection écrites en YARA-L et son modèle de données unifié (UDM).
- Google Threat Intelligence : le renseignement sur la menace, issu du rapprochement de Mandiant, de VirusTotal et des données de Google.
- Cloud Armor : pare-feu applicatif et protection anti-DDoS placés devant les services exposés, avec des règles fondées sur l’OWASP Core Rule Set 4.22 et deux niveaux, Standard et Enterprise.
- Sensitive Data Protection, ex-Cloud DLP : découverte et masquage des données personnelles dans les bases et les fichiers.
- Chrome Enterprise Premium, ex-BeyondCorp Enterprise : l’accès aux applications conditionné à l’identité et à l’état du poste, sans VPN.
- Cloud KMS et les clés gérées par le client (CMEK), pour garder la maîtrise du chiffrement, et Secret Manager pour les mots de passe et jetons applicatifs.
- Model Armor : filtrage à l’exécution des échanges avec les modèles d’IA générative, contre l’injection de prompt, le contournement des garde-fous et la fuite de données personnelles. Gratuit jusqu’à deux millions de jetons par mois, puis 0,10 dollar par million.
Comment sécuriser un projet Google Cloud ?
Les mesures qui changent réellement le niveau de risque sont peu nombreuses et rarement spectaculaires.
- Appliquer le moindre privilège dans IAM. Les rôles de base (Lecteur, Éditeur, Propriétaire) sont commodes et beaucoup trop larges ; les rôles prédéfinis par service font le travail.
- Structurer l’organisation en dossiers et projets séparés par environnement, et poser des règles d’organisation qui interdisent par défaut l’exposition publique.
- Délimiter un périmètre avec VPC Service Controls autour des services qui portent des données sensibles, pour empêcher l’exfiltration même avec des identifiants valides.
- Conserver et centraliser les Cloud Audit Logs. Sans journaux, une enquête après incident se réduit à des suppositions.
- Supprimer les clés de comptes de service au profit de la fédération d’identité, et faire tourner ce qui ne peut pas être supprimé.
- Brancher Cloud Armor devant les applications exposées, et traiter les alertes de Security Command Center plutôt que de les accumuler.
La question du RGPD revient systématiquement. Google Cloud propose de choisir la région d’hébergement des données, ce qui permet de les garder dans l’Union européenne, et publie ses engagements contractuels de sous-traitant. Cela règle la localisation, pas l’ensemble de la conformité : la base légale, la durée de conservation et les droits des personnes restent à la charge du responsable de traitement.
Sécurité GCP, AWS ou Azure : quelles correspondances ?
Les trois fournisseurs proposent le même type de briques sous des noms différents, ce qui complique la lecture des offres d’emploi et des architectures.
- Posture et détection : Security Command Center chez Google, Security Hub et GuardDuty chez AWS, Microsoft Defender for Cloud chez Azure.
- Pare-feu applicatif : Cloud Armor, AWS WAF associé à Shield, Azure Web Application Firewall.
- Données sensibles : Sensitive Data Protection, Amazon Macie, Microsoft Purview.
- Gestion des clés : Cloud KMS, AWS KMS, Azure Key Vault.
Les concepts se transposent, les détails d’implémentation beaucoup moins. Un ingénieur sécurité AWS confirmé devient opérationnel sur GCP en quelques semaines, mais il butera d’abord sur la hiérarchie organisation-dossier-projet et sur l’héritage des rôles IAM, qui n’ont pas d’équivalent direct.
Exemples ou cas d’usage concrets
Une entreprise découvre via Security Command Center qu’un bucket contenant des exports clients est accessible sans authentification. Le correctif prend cinq minutes ; la question qui suit, savoir qui y a accédé, dépend entièrement de la présence de journaux d’accès activés avant l’incident.
Un site marchand subit une vague de tentatives de connexion automatisées. Cloud Armor filtre le trafic en amont sur des critères géographiques et de fréquence, ce qui évite de dimensionner l’application pour absorber une attaque.
Une plateforme de santé isole ses données derrière un périmètre VPC Service Controls. Un compte compromis dans un projet voisin ne peut plus copier les données vers l’extérieur, même avec des droits de lecture valides.
Une équipe qui met en production un assistant conversationnel interne place Model Armor devant le modèle, pour bloquer les tentatives d’injection de prompt et éviter que des données personnelles ne repartent dans les réponses.
Quels profils recrute-t-on sur la sécurité Google Cloud ?
Le marché français reste dominé par AWS et Azure, ce qui rend les profils sécurité orientés Google Cloud nettement moins nombreux. Les entreprises concernées sont souvent des sociétés produit, des acteurs de la donnée et quelques grands comptes ayant fait ce choix pour leur plateforme analytique.
- Cloud security engineer : conçoit la hiérarchie IAM, les règles d’organisation et les périmètres, automatise le tout en Terraform.
- Analyste SOC : traite les détections, écrit des règles YARA-L dans Google Security Operations, mène les investigations.
- Ingénieur DevSecOps : intègre les contrôles dans les pipelines de déploiement et sécurise les images de conteneurs.
- Architecte cloud : arbitre le cloisonnement, la stratégie de chiffrement et la localisation des données.
Côté certification, la référence est la Professional Cloud Security Engineer de Google Cloud : deux heures, 50 à 60 questions à choix multiples, 200 dollars. Point rarement mentionné dans les annonces françaises, elle n’existe qu’en anglais et en japonais, sans version française.
En entretien, la question la plus révélatrice ne porte pas sur le catalogue de produits mais sur la responsabilité partagée : demander à un candidat ce que Google ne protège pas trie très vite.