Sécurité Google Cloud Platform (GCP) : guide complet 2026 pour les PME et startups

Google Cloud Platform (GCP) est le 3e hyperscaler mondial et la plateforme privilégiée de nombreuses startups tech, entreprises analytics (BigQuery) et organisations utilisant les services IA/ML de Google. Si GCP offre des capacités de sécurité natives puissantes, elles ne sont activées et configurées par défaut que partiellement. Ce guide vous donne les clés pour sécuriser votre environnement GCP en 2026.

L'organisation GCP : la fondation de la sécurité

GCP est organisé hiérarchiquement : Organisation → Dossiers → Projets → Ressources. Cette hiérarchie est cruciale pour la sécurité car les politiques IAM et les constraints s'héritent du niveau supérieur. Une mauvaise organisation dès le début crée des problèmes de sécurité difficiles à corriger.

• Organisation : Le nœud racine, lié à votre domaine Google Workspace ou Cloud Identity. Les admins d'organisation ont un pouvoir total — les comptes Organization Administrator doivent être ultra-protégés (MFA matériel FIDO2, monitoring renforcé).
• Dossiers : Permettent de séparer les environnements (prod, staging, dev) et les équipes (BU A, BU B). Appliquer des contraintes org policy différentes par dossier.
• Projets : L'unité de base pour l'isolation des ressources et la facturation. Chaque application ou workload devrait avoir son propre projet pour une isolation maximale.

IAM GCP : le contrôle d'accès

Principes IAM GCP

IAM GCP (Identity and Access Management) permet de contrôler qui (identité) peut faire quoi (rôle) sur quelle ressource. Les identités peuvent être des comptes Google, des groupes Google, des comptes de service (Service Accounts), ou des identités fédérées (Workload Identity Federation).

• Moindre privilège : Ne jamais utiliser les rôles primitifs (Owner, Editor, Viewer) en production — ils sont trop larges. Utiliser les rôles prédéfinis (roles/storage.objectViewer, roles/compute.instanceAdmin.v1) ou des rôles personnalisés.
• Pas de Owner en production : Le rôle Owner donne un accès total, y compris la facturation. Limiter ce rôle à 1-2 administrateurs, uniquement sur des comptes dédiés (pas des comptes Gmail personnels).
• Service Accounts avec Workload Identity : Pour les applications GKE accédant aux APIs GCP, utiliser Workload Identity Federation plutôt que des clés de service account (JSON keys) — les clés sont des secrets à longue durée de vie très risqués.
• IAM Conditions : Ajouter des conditions temporelles ou contextuelles aux bindings IAM (ex : accès valide uniquement pendant les heures ouvrées, uniquement depuis une IP spécifique).
• Policy Intelligence : Utiliser IAM Recommender pour identifier les permissions excessives accordées mais non utilisées.

Cloud Identity et MFA sur GCP

• Activer MFA pour tous les comptes Cloud Identity, en particulier les administrateurs
• Imposer le 2FA résistant au phishing (clés FIDO2/passkeys) pour les admins d'organisation
• Désactiver la connexion par mot de passe seul — forcer Google SSO
• Activer Context-Aware Access pour conditionner l'accès à la conformité de l'appareil

Organisation Policy : les guardrails GCP

Les Organization Policies (anciennement constraints) permettent d'imposer des règles à toute l'organisation GCP, indépendamment des droits IAM. Ce sont des "guardrails" que même un projet Owner ne peut contourner.

• constraints/iam.disableServiceAccountKeyCreation : Interdire la création de clés JSON de service account — force l'utilisation de Workload Identity
• constraints/compute.skipDefaultNetworkCreation : Ne pas créer le VPC "default" automatiquement dans les nouveaux projets (le VPC default est trop permissif)
• constraints/gcp.resourceLocations : Restreindre la création de ressources à des régions spécifiques (France = europe-west9 Paris, europe-west1 Belgique)
• constraints/compute.requireOsLogin : Forcer l'authentification via OS Login pour les VMs Compute Engine (plus sécurisé que les clés SSH)
• constraints/iam.allowedPolicyMemberDomains : Limiter les membres des bindings IAM aux domaines de votre organisation (empêche le partage à des comptes Gmail externes)
• constraints/storage.publicAccessPrevention : Interdire l'accès public aux buckets Cloud Storage au niveau organisation

VPC et sécurité réseau GCP

VPC Design sécurisé

• Supprimer le VPC default : Le VPC default créé automatiquement dans chaque projet a des règles de pare-feu permissives (allow-icmp, allow-ssh, allow-rdp depuis 0.0.0.0/0). Supprimer ce VPC dans tous les projets et créer des VPC customs avec des règles minimales.
• Shared VPC : Utiliser Shared VPC pour partager un réseau entre plusieurs projets GCP, avec une gestion centralisée des règles de pare-feu et du routage.
• Private Google Access : Activer Private Google Access sur les sous-réseaux pour permettre aux VMs sans IP publique d'accéder aux APIs GCP via le réseau interne Google (sans transiter par Internet).
• Cloud NAT : Pour les VMs qui doivent accéder à Internet en sortie sans avoir d'IP publique, Cloud NAT gère la translation d'adresses de manière centralisée et contrôlable.

Firewall Rules GCP

• Commencer par des règles "deny all" implicites (GCP les applique par défaut) et ajouter des exceptions explicites
• Éviter les règles autorisant 0.0.0.0/0 (tout Internet) — sauf pour les services publics (HTTP/HTTPS via Load Balancer)
• Utiliser des network tags ou service accounts comme sources/destinations plutôt que des plages IP — plus maintenable et précis
• Activer les logs pour toutes les règles de pare-feu (Firewall Rules Logging) — crucial pour la détection et la conformité
• Utiliser Firewall Insights pour identifier les règles inutilisées ou trop permissives

Security Command Center (SCC)

Le Security Command Center est la plateforme de gestion de la posture de sécurité native de GCP. Il centralise les alertes de sécurité, les findings des services de détection et la conformité avec les benchmarks.

• SCC Standard (gratuit) : Vue des assets, détection basique des mauvaises configurations, intégration avec les services Google natifs
• SCC Enterprise (payant) : Threat Detection avancée, Security Health Analytics complet, Event Threat Detection (ETD), Container Threat Detection, Virtual Machine Threat Detection, Web Security Scanner

Les fonctionnalités clés à utiliser :

• Security Health Analytics : Détecte les mauvaises configurations (buckets publics, service accounts avec trop de droits, clés API sans restrictions, VMs avec des disques non chiffrés)
• Event Threat Detection (ETD) : Analyse les logs Cloud Audit pour détecter les comportements malveillants (compromission de compte, mining de crypto, exfiltration de données)
• Container Threat Detection : Runtime security pour GKE (comportements anormaux dans les conteneurs)
• Compliance Reports : Rapports de conformité CIS Benchmark, ISO 27001, PCI DSS, RGPD

Protection des données : Cloud KMS et Secret Manager

Cloud KMS — Chiffrement des données

• Customer-Managed Encryption Keys (CMEK) : Pour les données sensibles, utiliser vos propres clés de chiffrement gérées dans Cloud KMS plutôt que les clés Google par défaut. Disponible pour BigQuery, Cloud Storage, Compute Engine, Cloud SQL.
• Key Rotation : Configurer la rotation automatique des clés (tous les 90 jours recommandé pour les données très sensibles)
• Cloud EKM (External Key Manager) : Pour les données ultra-sensibles (secteur financier, santé), gérer les clés dans un HSM externe (Thales, Entrust) tout en chiffrant sur GCP

Secret Manager

• Stocker tous les secrets (API keys, passwords, certificats, tokens) dans Secret Manager plutôt que dans les variables d'environnement ou les ConfigMaps
• Activer la rotation automatique des secrets via des fonctions Cloud Functions ou Workflows
• Audit des accès aux secrets via Cloud Audit Logs
• Contrôle d'accès granulaire : qui peut lire quel secret, sur quelle version

Cloud Logging et monitoring de sécurité

• Cloud Audit Logs : Activer les Data Access Audit Logs pour les services critiques (BigQuery, Cloud Storage, Cloud SQL) — par défaut seuls les Admin Activity Logs sont activés
• Log Sink vers BigQuery/Cloud Storage : Exporter les logs vers BigQuery pour des analyses long terme ou vers Cloud Storage pour l'archivage conformité (RGPD, NIS2)
• Log-based Metrics et Alerting : Créer des alertes Cloud Monitoring sur les patterns suspects dans les logs (accès non autorisé, modification des org policies, création de service account keys)
• Chronicle SIEM : La solution SIEM de Google Cloud pour une analyse avancée des logs de sécurité avec corrélation et règles de détection YARA-L

Conformité RGPD et NIS2 sur GCP

GCP propose plusieurs fonctionnalités pour faciliter la conformité réglementaire :

• Résidence des données : Utiliser les régions europe-west9 (Paris) ou europe-west1 (Belgique) pour les données soumises au RGPD. Activer la contrainte org policy resourceLocations pour forcer la création en Europe.
• DPA avec Google : Google propose un Data Processing Agreement (DPA) RGPD en ligne. Signer ce DPA est obligatoire si vous traitez des données personnelles d'européens sur GCP.
• Sovereign Controls : Pour les secteurs les plus sensibles (défense, gouvernement), Google propose Sovereign Controls, avec chiffrement géré localement et accès administrateur restreint aux ingénieurs Google basés dans le pays.
• NIS2 — Notification incidents : Configurer des alertes SCC + Cloud Monitoring pour détecter les incidents et alimenter votre procédure de notification ANSSI en 24/72h.
• Compliance Manager / SCC Compliance : Les rapports de conformité SCC Enterprise couvrent NIS2, ISO 27001, RGPD — utilisables pour documenter votre posture de sécurité.

Checklist sécurité GCP en 15 points

• MFA FIDO2 activé pour tous les admins GCP (Cloud Identity)
• Org policy: publicAccessPrevention sur Cloud Storage
• Org policy: resourceLocations restreint à l'Europe
• Org policy: disableServiceAccountKeyCreation activée
• VPC default supprimé dans tous les projets
• Firewall Rules Logging activé
• Security Command Center activé (au moins Standard)
• Cloud Audit Logs (Data Access) activés pour les services critiques
• CMEK configurées pour les données sensibles (BigQuery, Cloud SQL, GCS)
• Secret Manager utilisé pour tous les secrets applicatifs
• IAM Recommender passé et permissions excessives supprimées
• Workload Identity Federation configuré pour les workloads GKE
• VPC Service Controls activés pour les projets avec des données très sensibles
• Cloud Armor configuré pour les applications web exposées
• DPA RGPD signé avec Google et documentation de la localisation des données