La sécurité de Google Cloud Platform (GCP) repose sur cinq piliers pour un débutant : comprendre le modèle de responsabilité partagée Google, maîtriser la hiérarchie Organization → Folder → Project, configurer l'IAM (principaux, rôles prédéfinis, service accounts, bindings et conditions), isoler les périmètres sensibles via VPC Service Controls, et monitorer en continu avec Security Command Center + Cloud Audit Logs. Les deux risques #1 sur GCP en 2026 sont les clés JSON de service accounts exfiltrées (remplacement obligatoire par Workload Identity Federation) et les buckets Cloud Storage publics involontaires (bloquer via Public access prevention + Organization Policy). Cet article détaille les concepts fondamentaux, les commandes gcloud essentielles, les différences avec AWS et Azure, les outils de scan, et la checklist à appliquer sur un nouveau projet.
Modèle de responsabilité partagée GCP
Avant toute configuration, comprendre qui est responsable de quoi.
| Couche | Responsabilité |
|---|---|
| Infrastructure physique (data centers, réseau) | |
| Hyperviseur, OS host, hardware | |
| OS guest (VMs Compute Engine) | Client |
| Middleware, runtime, libraries | Client |
| Application code et dépendances | Client |
| Configuration réseau (VPC, firewall) | Client |
| IAM et contrôle d'accès | Client |
| Chiffrement au repos (par défaut) | Google (clés Google-managed) |
| Chiffrement des données en transit TLS | Partagé (Google fournit, client configure) |
| Secrets, clés, tokens applicatifs | Client |
| Détection et réponse aux incidents | Partagé |
Les services managés (Cloud Run, App Engine, Cloud Functions, BigQuery) décalent plus de responsabilité vers Google, mais l'IAM, la configuration d'accès, les secrets et la logique applicative restent toujours à la charge du client.
Resource Hierarchy : la fondation
GCP organise ses ressources selon une hiérarchie native à 4 niveaux :
Organization (domaine d'entreprise, ex. example.com)
│
├── Folder (optionnel, regroupement logique)
│ │
│ ├── Folder (imbrication possible jusqu'à 10 niveaux)
│ │ │
│ │ └── Project (unité de facturation + isolation par défaut)
│ │ │
│ │ └── Resource (VM, bucket, DB, cluster, etc.)
│ │
│ └── Project
│
└── Project (directement sous Org)Règle fondamentale : les policies IAM et les Organization Policies sont héritées descendantes. Une contrainte appliquée au niveau Organization s'applique par défaut à tous les projets en dessous, sauf override explicite.
Organization Policies essentielles pour un débutant
# Interdire la création de clés JSON de service accounts (recommandé)
gcloud resource-manager org-policies enable-enforce \
iam.disableServiceAccountKeyCreation \
--organization=ORG_ID
# Interdire l'accès public aux Cloud Storage par défaut
gcloud resource-manager org-policies enable-enforce \
storage.publicAccessPrevention \
--organization=ORG_ID
# Restreindre les régions autorisées (conformité data residency)
gcloud resource-manager org-policies allow \
gcp.resourceLocations \
"in:eu-locations" \
--organization=ORG_ID
# Exiger OS Login sur toutes les VMs (pas de clés SSH manuelles)
gcloud resource-manager org-policies enable-enforce \
compute.requireOsLogin \
--organization=ORG_IDCes quatre Organization Policies couvrent déjà une large part des risques de misconfiguration classiques.
IAM : le cœur du contrôle d'accès
Concepts fondamentaux
Principal (identité)
├── User Google (alice@example.com)
├── Service Account (app-backend@project.iam.gserviceaccount.com)
├── Google Group (security-team@example.com)
├── Workforce Identity (SSO entreprise)
└── Workload Identity Federation (workload externe)
Role (ensemble de permissions)
├── Primitive (Owner, Editor, Viewer - à éviter en 2026)
├── Predefined (ex. roles/storage.objectViewer - granulaire)
└── Custom (permissions précises définies par vous)
Binding
= (principal + role) attaché à une ressource ou à un scope hiérarchique
avec condition IAM optionnelle
IAM Condition (optionnelle)
Expression CEL qui restreint quand/comment le binding s'applique
Exemples : heures, attributs ressource, contexte réseauLes erreurs IAM les plus fréquentes à éviter
- Primitive roles :
roles/owner,roles/editoraccordent des permissions énormes. Éviter sauf cas exceptionnel documenté. - Attribution au niveau Project quand elle devrait être au niveau ressource (bucket, topic, dataset).
- Service account avec Owner : une clé compromise donne un contrôle complet du projet.
- Partage de service accounts entre services différents.
- Absence de review régulière : IAM Policy Analyzer hebdomadaire recommandé.
Commandes IAM essentielles
# Qui a accès à ce bucket ?
gcloud storage buckets get-iam-policy gs://my-bucket
# Ajouter un binding sur un bucket
gcloud storage buckets add-iam-policy-binding gs://my-bucket \
--member=user:alice@example.com \
--role=roles/storage.objectViewer
# Voir les rôles d'un user au niveau projet
gcloud projects get-iam-policy PROJECT_ID \
--flatten="bindings[].members" \
--filter="bindings.members:alice@example.com" \
--format="table(bindings.role)"
# Lister les service accounts d'un projet
gcloud iam service-accounts list --project=PROJECT_ID
# Analyser les permissions réellement utilisées (detect over-privileged)
gcloud asset analyze-iam-policy-longrunning \
--organization=ORG_ID \
--identity="user:alice@example.com"Service Accounts : le piège des clés JSON
Les service accounts sont l'identité utilisée par le code pour accéder à GCP. Deux méthodes d'authentification possibles, et la différence est critique.
Méthode à éviter - clés JSON
Génération d'une clé JSON → fichier téléchargé localement
→ envoyé dans secrets CI/CD ou fichier .env
→ risque d'exfiltration via :
- commit accidentel dans un repo public (trufflehog détecte)
- laptop développeur compromis
- logs applicatifs mal filtrés
- phishing de développeur
→ credentials long-lived, difficile à rotateCette méthode est explicitement déconseillée par Google depuis 2023. Le top 5 des causes de compromission GCP en 2025-2026 inclut systématiquement « fuite de clé JSON service account ».
Méthode recommandée 2026 - Workload Identity Federation
Workload Identity Federation (WIF) permet à un workload externe (GitHub Actions, GitLab CI, Jenkins, Kubernetes hors GKE) d'obtenir un token GCP court-durée via une fédération OIDC, sans jamais télécharger de clé.
# GitHub Actions - déploiement GCP avec WIF (sans clé JSON)
name: deploy-gcp
on: [push]
permissions:
contents: read
id-token: write # requis pour OIDC
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- id: auth
uses: google-github-actions/auth@v2
with:
workload_identity_provider: projects/123/locations/global/workloadIdentityPools/gh/providers/gh-oidc
service_account: deployer@my-project.iam.gserviceaccount.com
- name: Deploy to Cloud Run
run: gcloud run deploy my-app --image=gcr.io/my-project/app:${{ github.sha }}Pour les workloads qui tournent dans GKE, utiliser Workload Identity Federation for GKE : chaque Kubernetes Service Account est mappé à un GCP Service Account, sans secrets en cluster.
Réseau : VPC, firewall et Service Controls
VPC et segmentation
# Créer un VPC custom (ne jamais utiliser le VPC default en prod)
gcloud compute networks create prod-vpc --subnet-mode=custom
# Créer un subnet par environnement
gcloud compute networks subnets create prod-eu-west1 \
--network=prod-vpc --region=europe-west1 --range=10.10.0.0/24
# Firewall rule par défaut : tout bloquer en entrée
gcloud compute firewall-rules create deny-all-ingress \
--network=prod-vpc --action=DENY --direction=INGRESS \
--rules=all --priority=65534
# Autoriser SSH seulement depuis IAP (pas d'Internet direct)
gcloud compute firewall-rules create allow-ssh-from-iap \
--network=prod-vpc --action=ALLOW --direction=INGRESS \
--rules=tcp:22 --source-ranges=35.235.240.0/20Le tunneling via Identity-Aware Proxy (IAP) évite d'exposer SSH sur Internet, authentifié via Google et IAM.
VPC Service Controls (VPC-SC)
VPC Service Controls créent un périmètre de sécurité logique autour d'un ensemble de services GCP (Cloud Storage, BigQuery, Pub/Sub, etc.). Les données ne peuvent pas sortir du périmètre, même si un attaquant dispose de credentials valides.
Sans VPC-SC :
Attaquant vole une clé de service account
→ peut exfiltrer les données d'un bucket vers un bucket attaquant
→ pas de frein technique
Avec VPC-SC :
Périmètre défini autour du projet + services
→ même avec credentials valides, exfiltration vers l'extérieur bloquée
→ logs d'audit des tentativesVPC-SC est la réponse GCP aux exfiltrations de données type SolarWinds. Pas d'équivalent direct AWS ou Azure.
Cloud Armor
WAF natif GCP, protège Load Balancers et Cloud Run des attaques L7 (OWASP Top 10, DDoS volumétrique). Intégration native avec les règles preconfigured OWASP ModSecurity Core Rule Set.
Secrets et chiffrement
Secret Manager
Service dédié à la gestion des secrets (tokens API, mots de passe, certificats). Remplace les secrets stockés en dur dans le code ou dans Cloud Storage.
# Créer un secret
gcloud secrets create db-password --replication-policy=automatic
# Stocker une version
echo -n "super-secret-password" | gcloud secrets versions add db-password --data-file=-
# Accorder accès à un service account
gcloud secrets add-iam-policy-binding db-password \
--member=serviceAccount:app@my-project.iam.gserviceaccount.com \
--role=roles/secretmanager.secretAccessor
# Accéder dans le code (Python)
# from google.cloud import secretmanager
# client = secretmanager.SecretManagerServiceClient()
# name = f"projects/my-project/secrets/db-password/versions/latest"
# response = client.access_secret_version(request={"name": name})
# password = response.payload.data.decode("UTF-8")Cloud KMS
Service de gestion de clés cryptographiques. Utilisé pour :
- Chiffrement de données sensibles au-delà du chiffrement automatique Google.
- Customer-Managed Encryption Keys (CMEK) sur Cloud Storage, BigQuery, Compute disks.
- Signature et vérification (ex. cosign keyless avec Fulcio + Cloud KMS).
- Hardware Security Module (Cloud HSM) pour exigences certifiées FIPS 140-2 niveau 3.
Monitoring et détection
Cloud Audit Logs
Logs d'audit centralisés générés automatiquement pour toutes les actions API. Trois types :
| Type | Contenu | Activé par défaut |
|---|---|---|
| Admin Activity | Actions IAM, création/suppression ressources | Oui, gratuit |
| Data Access | Lecture/écriture données | Non (coût élevé) |
| System Event | Actions internes Google | Oui |
| Policy Denied | Refus d'accès IAM ou VPC-SC | Oui |
Activer Data Access logs sur les buckets et bases de données sensibles est recommandé pour la forensics mais génère du volume. Alternative 2026 : activer uniquement sur ressources classées sensibles (PII, PCI, santé).
Security Command Center
Plateforme centrale de sécurité GCP. Trois niveaux en 2026.
Standard (gratuit) :
Security Health Analytics (100+ contrôles CIS)
Sensitive Actions Service
Inventory des ressources
Premium (~50 USD/mois par compte de service actif) :
Event Threat Detection (détection d'attaques)
Container Threat Detection (GKE runtime)
Web Security Scanner (DAST managé)
Rapports PCI DSS, CIS, ISO 27001, NIST 800-53
Enterprise (pricing custom) :
Attack Path Simulation (visualisation chaînes d'attaque)
Mandiant Threat Intelligence intégré
CSPM multi-cloud (AWS, Azure)
SIEM-like Cloud ChroniclePour un débutant : activer Standard dès le premier jour, évaluer Premium dès qu'on a des données sensibles ou une conformité en ligne de mire.
Bonnes pratiques essentielles pour démarrer
Les 10 actions à appliquer sur un nouveau projet GCP.
- Créer une hiérarchie : Organization + Folder par environnement (dev, staging, prod) + Project par application.
- Activer Security Command Center Standard sur l'Organization.
- Appliquer les 4 Organization Policies :
disableServiceAccountKeyCreation,publicAccessPrevention,resourceLocations,requireOsLogin. - Désactiver le VPC default et créer un VPC custom avec subnets par environnement.
- IAM au niveau le plus granulaire : rôles prédéfinis sur ressources, pas primitive au projet.
- Workload Identity Federation obligatoire pour tout CI/CD externe.
- Secret Manager pour tous les secrets applicatifs, jamais dans le code.
- Activer Cloud Audit Logs Admin Activity (gratuit, par défaut) et Data Access sur ressources sensibles.
- VPC Service Controls autour des projets contenant PII ou données sensibles.
- Scanner régulièrement avec Prowler ou Security Command Center. Viser CIS GCP Benchmark > 80 %.
Différences clés avec AWS et Azure
| Aspect | AWS | Azure | GCP |
|---|---|---|---|
| Hiérarchie | Organizations + OUs | Management Groups + Subscriptions | Organization + Folders + Projects (natif) |
| Identités humaines | IAM Users / IAM Identity Center | Entra ID (ex-Azure AD) | Google Workspace / Cloud Identity |
| Service identity | IAM Roles via STS | Managed Identities | Service Accounts |
| Federation workloads externes | OIDC via IAM role | Workload Identity Federation | Workload Identity Federation |
| Security Posture Management | Security Hub | Defender for Cloud | Security Command Center |
| Secrets management | Secrets Manager | Key Vault | Secret Manager |
| WAF natif | AWS WAF | Azure Application Gateway | Cloud Armor |
| Périmètre de données | Aucun direct (VPC + endpoints) | Private Endpoints | VPC Service Controls (unique) |
| Chiffrement au repos par défaut | Oui | Oui | Oui |
Le différenciateur GCP le plus cité : hiérarchie native propre et VPC Service Controls comme périmètre d'exfiltration. Le différenciateur AWS : maturité et profondeur du catalogue. Le différenciateur Azure : intégration Microsoft (Entra ID, M365, Defender).
Outils open source pour auditer GCP
Prowler (multi-cloud OSS) :
CLI en Python, 200+ contrôles GCP
Mapping CIS, NIST, ISO, HIPAA, PCI DSS
Intégration CI/CD (exit code, SARIF, JSON)
Commande : prowler gcp --project-ids my-project
ScoutSuite (NCC Group) :
Rapport HTML visuel
Commande : scout gcp --project-id my-project
Cloud Custodian (CNCF) :
Policies YAML déclaratives
Remédiation automatique possible
Détection continue
Forseti Security :
Historique, maintenu par communauté
Policies Rego / OPA compatibles
gcloud scc (natif) :
Query SCC findings depuis CLI
gcloud scc findings list --organization=ORG_IDRessources d'apprentissage structurées
Gratuit :
Google Cloud Skills Boost (anciennement Qwiklabs)
→ « Security Engineer Learning Path » : 40 labs pratiques
GCP Security Best Practices Center (docs.cloud.google.com/security)
GCP CIS Benchmark v2.0 (PDF public, 170+ pages)
Blog Google Cloud Security (publications régulières)
Livres :
Google Cloud Certified Professional Cloud Security Engineer Study Guide (2023)
Google Cloud Platform Security Handbook - Packt (2024)
Certifications :
Professional Cloud Security Engineer (PCSE) : 200 USD, 2 h
Associate Cloud Engineer (ACE) : prérequis recommandé
Labs hands-on :
Google CloudSkillsBoost : quests Security Engineer
KodeKloud GCP Security path
Cybrary Google Cloud Security Fundamentals
Communauté :
Reddit r/googlecloud
Google Cloud Security Community (security.googlecloudcommunity.com)
Stack Overflow tag google-cloud-platformPoints clés à retenir
- 5 piliers GCP security pour débutant : modèle de responsabilité partagée, Resource Hierarchy, IAM, VPC Service Controls + Cloud Armor, Security Command Center + Cloud Audit Logs.
- Deux risques dominants 2026 : clés JSON de service account exfiltrées (remplacer par Workload Identity Federation) et buckets Cloud Storage publics involontaires (bloquer via Organization Policy).
- 4 Organization Policies à appliquer au jour 1 :
disableServiceAccountKeyCreation,publicAccessPrevention,resourceLocations,requireOsLogin. - VPC Service Controls est le différenciateur GCP sans équivalent AWS/Azure : périmètre d'exfiltration qui protège même en cas de credentials volés.
- Security Command Center Standard (gratuit) couvre 60 % des besoins CSPM basiques. Premium devient rentable dès qu'il y a données sensibles ou conformité (PCI DSS, HIPAA, ISO 27001).
- Outils open source : Prowler (multi-cloud, 200+ contrôles GCP), ScoutSuite, Cloud Custodian. Combo minimal Prowler + Cloud Custodian = CSPM viable pour petite équipe.
- Certification cible : Professional Cloud Security Engineer (PCSE). Labs gratuits sur Google Cloud Skills Boost.
Pour un parcours d'apprentissage complet qui intègre GCP Security avec AWS et Azure, voir la roadmap Cloud Security 2026. Pour resituer GCP Security dans une discipline DevSecOps complète, lire la roadmap DevSecOps et différence entre DevOps et DevSecOps. Pour sécuriser les workloads GKE avec des contrôles images et runtime, scan de conteneurs : pourquoi et comment détaille la stack outillée.
