Google PCA: Sécurité, conformité et architecture de protection des données — Guide d'étude

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

Fait partie du Google Professional Cloud Architect — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Google, ou passez des tests chronométrés sur ExamRoll.io.

Vue d’ensemble

La sécurité, la conformité et la protection des données dans Google Cloud reposent sur la responsabilité partagée et la défense en profondeur. Google sécurise l’infrastructure sous-jacente, tandis que vous concevez des identités, des réseaux, des applications et une gestion des données sécurisés. Adoptez le Zero Trust comme modèle directeur : ne faites jamais confiance implicitement au réseau, vérifiez en permanence l’identité et le contexte, et appliquez strictement le moindre privilège. Concevez en prévision des compromissions : partez du principe que les identifiants peuvent fuiter, que les points d’accès peuvent être sondés et que les services internes peuvent être utilisés à mauvais escient. Compensez avec de multiples contrôles (préventifs, détectifs, réactifs), une cryptographie et une gestion des clés robustes, une surveillance solide et une réponse aux incidents bien rodée.

Les compromis sont inévitables. Des contrôles plus stricts peuvent augmenter la latence, la complexité opérationnelle et les coûts. Votre architecture doit explicitement peser les risques par rapport à la facilité d’utilisation et aux performances, tout en préservant une conformité démontrable et une capacité d’analyse forensique.

Architecture des identités et des accès

• Principes et modèle

  • Moindre privilège par défaut : accordez le plus petit ensemble d’autorisations requis pour accomplir une tâche, et préférez les rôles prédéfinis ou les rôles personnalisés aux rôles primitifs (Owner, Editor, Viewer).
  • Séparation des tâches : répartissez les rôles entre les constructeurs (CI/CD), les déployeurs, les opérateurs et la sécurité. Utilisez des comptes d’urgence (break-glass) avec des contrôles stricts et une journalisation pour les situations critiques.
  • Application du Zero Trust : utilisez l’accès contextuel pour vérifier l’utilisateur, l’appareil, l’emplacement et le risque ; exigez une authentification multifacteur (MFA) forte ; et évaluez en continu le contexte de la session.
  • Organization policy et IAM Deny : codifiez les garde-fous (par exemple, interdire la création de clés de compte de service, restreindre le partage de domaine) et utilisez des stratégies de refus (deny policies) pour appliquer des limites non négociables.

• Implémentation d’IAM et stratégie de comptes de service

  • Établissez un modèle d’accès basé sur la hiérarchie : les dossiers (folders) reflètent les secteurs d’activité ou les environnements (prod, non-prod) ; les projets isolent le périmètre d’impact (blast radius) et la facturation ; les comptes de service (SA) représentent les charges de travail (workloads).
  • Un workload, un compte de service : évitez de partager les SA entre des services non liés. Associez les autorisations au périmètre de déploiement (projet) et au périmètre de la ressource.
  • Préférez les identifiants éphémères via Service Account Impersonation et Workload Identity Federation. Désactivez les clés de compte de service gérées par l’utilisateur ; si c’est inévitable, isolez leur utilisation, effectuez des rotations fréquentes et surveillez-les avec les journaux d’audit.
  • Utilisez les Access Boundaries pour restreindre ce à quoi un SA impersonné peut accéder au moment de la requête (par exemple, limiter les chemins d’objets GCS), contenant ainsi le périmètre d’impact même si un SA privilégié est utilisé à mauvais escient.
  • IAM conditionnel : appliquez des conditions au niveau des ressources (heure, IP, attributs du principal) pour restreindre l’accès. Exemple : interdire l’accès à la production sauf depuis les plages IP de l’entreprise et pendant les fenêtres de maintenance.

• Modes de défaillance et compromis

  • Les rôles sur-privilégiés (par ex., Editor au niveau du projet) augmentent le risque ; préférez des rôles granulaires et validez via les analyseurs de stratégies (policy analyzers).
  • La prolifération des clés de compte de service dans les scripts CI/CD et locaux est un vecteur de violation courant ; avec l’impersonation, certains outils hérités peuvent nécessiter une adaptation.
  • Les stratégies IAM Deny sont puissantes mais peuvent être difficiles à dépanner ; préparez et testez les changements en non-production avec des exécutions à blanc (dry runs) explicites.

Exemple (impersonation sans création de clés) :

undefined

Protection des données et cryptographie

• Cloud KMS et modèles de gestion des clés
  • Le chiffrement natif au repos est activé par défaut. Pour un contrôle supplémentaire, utilisez les clés de chiffrement gérées par le client (CMEK) avec des services comme BigQuery, Cloud Storage, les disques Compute Engine, Pub/Sub et les volumes persistants GKE.
  • Concevez une hiérarchie de clés par environnement et par domaine de données. Utilisez des trousseaux de clés distincts par emplacement et des clés distinctes par application ou jeu de données pour limiter le rayon d’impact.
  • Rotation : activez la rotation planifiée et dépréciez en douceur les anciennes versions de clés avec le chiffrement d’enveloppe pour les applications. Validez la compatibilité des consommateurs avant d’augmenter la fréquence de rotation.
  • External Key Manager (EKM) et External Key Access (EKA) placent les clés en dehors de Google Cloud pour le contrôle réglementaire. Les compromis incluent une latence supplémentaire et une dépendance à la disponibilité des HSM externes ; planifiez des opérations en mode dégradé.
  • Appliquez le principe de moindre privilège IAM sur les CryptoKeys. Utilisez les journaux d’audit au niveau de la clé comme preuve d’accès.

Exemple (CMEK avec rotation) :

• gcloud kms keyrings create app-ring –location=us-central1

• gcloud kms keys create data-key –keyring=app-ring –location=us-central1 –purpose=encryption –rotation-period=90d

• Chiffrement au niveau applicatif

  • Utilisez le chiffrement d’enveloppe (par exemple, Tink) pour chiffrer les champs sensibles au niveau de la couche applicative, permettant un accès sélectif et l’isolation des données des locataires (tenants). Dérivez des clés par locataire pour minimiser l’impact entre locataires.
  • Validez l’intégrité (AEAD) pour empêcher la falsification et la relecture (replay).

• Secret Manager et cycle de vie des secrets

  • Stockez les identifiants, les jetons et les clés d’API en tant que secrets versionnés ; jamais dans les images, Git ou les métadonnées d’instance. Accordez des droits IAM au niveau du secret ou du projet au compte de service d’exécution.
  • Rotation : automatisez à l’aide de Cloud Functions/Cloud Run déclenchées par Pub/Sub pour créer une nouvelle version, mettre à jour les dépendances et révoquer les anciennes versions. Préférez le remplacement des mots de passe de base de données à longue durée de vie par une authentification de base de données basée sur IAM ou des jetons à courte durée de vie.
  • Sécurité de la configuration : séparez la configuration non secrète (ConfigMap, variables d’environnement) des secrets. Empêchez l’exposition des secrets dans les journaux et les messages d’erreur.

Exemple (ajouter une nouvelle version de secret) :

• gcloud secrets versions add db-password –data-file=password.txt –secret=db-password

• Durcissement des ressources de calcul et informatique confidentielle

  • Shielded VMs : activez le démarrage sécurisé (secure boot), le vTPM et la surveillance de l’intégrité pour protéger contre les bootkits et les rootkits. Appliquez via une règle d’organisation et validez dans les pipelines CI/CD.
  • Confidential VMs : le chiffrement de la mémoire par défaut protège les données en cours d’utilisation avec des changements de configuration minimes ; évaluez l’impact sur les performances pour les charges de travail à haut débit et à forte intensité cryptographique.
  • Images durcies : partez de bases optimisées par Google ou durcies selon les normes CIS ; gérez les correctifs avec OS Config et désactivez les paquets et les ports inutiles.

Sécurité du réseau et de la périphérie

• Segmentation du réseau et contrôle de sortie (egress)

  • Segmentez par niveau et par sensibilité en utilisant des VPC, des sous-réseaux et des règles de pare-feu hiérarchiques distincts. Combinez les tags de pare-feu basés sur l’identité avec des contraintes de service à service (par exemple, GKE NetworkPolicy) pour appliquer des contrôles est-ouest.
  • Contrôlez la sortie (egress) avec Cloud NAT, les stratégies DNS et l’accès privé restreint à Google (restricted Private Google Access) pour minimiser l’exfiltration de données. Utilisez des listes d’autorisation de sortie explicites et une inspection par proxy lorsque cela se justifie.

• VPC Service Controls (VPC SC)

  • Construisez des périmètres de service autour des projets hébergeant les données concernées pour atténuer l’exfiltration depuis les API gérées par Google (GCS, BigQuery, Secret Manager, Pub/Sub, etc.).
  • Niveaux d’accès : définissez des conditions de contexte (identité de l’utilisateur, plages IP, posture de l’appareil) qui doivent être satisfaites pour accéder aux services périmétrés.
  • Utilisez des ponts de périmètre (perimeter bridges) pour des flux de travail contrôlés entre plusieurs périmètres et des règles de sortie pour restreindre les destinations. Testez en mode de test (dry-run) pour éviter de casser les pipelines.
  • Limitations : ne protège pas directement le trafic vers les adresses IP de Compute Engine ; complétez avec des contrôles de pare-feu et de sortie (egress). Certains outils et modèles hybrides peuvent nécessiter des comptes de service compatibles avec les périmètres et Private Service Connect vers des VIP restreintes.

• Protection de la périphérie et des applications

  • Cloud Armor : défendez les applications HTTP(S) derrière le load balancer externe global avec une mitigation DDoS L3/L4/L7, des listes d’autorisation/refus d’IP, des contrôles géographiques et une limitation de débit (rate limiting).
  • Règles WAF : appliquez des règles gérées préconfigurées et des signatures personnalisées pour le Top 10 de l’OWASP ; ajustez pour réduire les faux positifs. Attachez par service de backend pour adapter les stratégies par version d’API ou par composant applicatif.
  • Protection des API : placez les API derrière API Gateway ou Apigee pour l’authentification, les quotas, la validation de schéma et la détection de menaces ; intégrez Cloud Armor pour l’application en périphérie ; envisagez reCAPTCHA Enterprise et les contrôles de bots le cas échéant.
  • Compromis : une inspection plus approfondie peut ajouter de la latence et du bruit opérationnel. Mettez les règles en mode prévisualisation (preview), surveillez les journaux et appliquez-les progressivement.

Opérations de sécurité, surveillance et conformité

• Security Command Center (SCC) et détection des menaces

  • SCC agrège l’inventaire des ressources et les résultats à travers les projets et les organisations. Utilisez-le pour établir une base de référence de la posture de sécurité (buckets publics, règles de pare-feu ouvertes), suivre les dérives et piloter les workflows de remédiation.
  • La détection des menaces Premium inclut Event Threat Detection, VM Threat Detection et Container Threat Detection pour identifier les logiciels malveillants, le cryptominage et les comportements anormaux.
  • Intégrez les résultats avec les pipelines de ticketing et de SOAR ; définissez des politiques de suppression/d’exception avec une date d’expiration pour éviter la fatigue liée aux alertes.

• Vulnérabilités et sécurité des artefacts

  • Utilisez Artifact Analysis pour analyser les images de conteneurs à la recherche de CVE ; appliquez des politiques au moment du déploiement avec Binary Authorization et des attestations signées depuis la CI.
  • Gestion des correctifs via OS Config ; surveillez les fenêtres d’exposition et automatisez les déploiements avec des canaris.

• Journaux d’audit, confidentialité et preuves

  • Cloud Audit Logs fournit par défaut les journaux d’activité d’administration (Admin Activity) et d’événements système (System Event) ; les journaux d’accès aux données (Data Access) peuvent être activés par service et sont payants. Acheminez les journaux vers BigQuery pour l’analyse et vers Cloud Storage pour une rétention immuable et la conservation à des fins juridiques (legal hold).
  • Classification des données : utilisez Cloud DLP pour découvrir et classifier les PII (informations personnelles identifiables), appliquer des étiquettes et des tags, et les mapper à des niveaux de protection (CMEK, VPC SC, Confidential VMs).
  • Confidentialité et résidence des données : restreignez les emplacements via une politique d’organisation ; alignez les emplacements de CMEK et de stockage avec les exigences réglementaires.
  • Conservation à des fins juridiques et rétention : activez les politiques de rétention et les conservations sur les buckets ; utilisez Object Versioning si nécessaire. Documentez la chaîne de possession pour les images forensiques et les journaux afin de produire des preuves défendables.

• Réponse aux incidents et préparation à l’analyse forensique

  • Préparez des runbooks, des chemins d’accès et l’automatisation. Assurez-vous que les intervenants disposent d’un accès selon le principe de moindre privilège et que l’audit est activé à travers l’organisation, les dossiers et les projets.
  • Confinement : isolez les instances en les retirant des répartiteurs de charge, en appliquant des règles de pare-feu de refus de sortie (egress), ou en déplaçant les projets dans des politiques d’organisation plus strictes ; désactivez les comptes de service compromis et effectuez la rotation des secrets et des clés.
  • Analyse forensique : créez des snapshots des disques et exportez les images pour une analyse hors ligne ; préservez les journaux via des exportations. Utilisez la mise en miroir de paquets (packet mirroring) le cas échéant. Évitez de modifier les preuves ; travaillez à partir de copies.
  • Récupération : reconstruisez à partir d’images de confiance, réhydratez les secrets et validez avec des tests de fumée (smoke tests) et de sécurité. Menez des revues post-incident et intégrez les leçons apprises dans les garde-fous et les détections.

Scénario de problème pratique

NimbusPay, un SaaS fintech, doit traiter des données marquées PCI à travers des microservices multi-locataires (multi-tenant) sur Google Cloud, garantir la résidence des données dans l’UE, se protéger contre les attaques au niveau de la couche API et produire des preuves auditables des contrôles. Ils déploieront une nouvelle API v2 tout en maintenant la v1 active sous le même nom d’hôte.

Approche :

1. Partitionner les projets et les identités

• Créez des projets distincts par environnement et par niveau de microservice (ingestion, traitement, reporting). Attribuez un compte de service de charge de travail unique par service. Justification : isole le rayon d’impact (blast radius) et mappe le moindre privilège à des charges de travail distinctes.

2. Appliquer le Zero Trust et le moindre privilège

• Accordez des rôles prédéfinis/personnalisés aux comptes de service et aux groupes DevOps ; appliquez un IAM conditionnel pour restreindre l’accès à la production aux adresses IP et aux heures de l’entreprise. Justification : réduit les mouvements latéraux et les modifications accidentelles.

3. Supprimer les clés de compte de service statiques

• Désactivez les clés de SA gérées par l’utilisateur via une politique d’organisation. Utilisez l’usurpation d’identité de compte de service (Service Account Impersonation) pour la CI/CD et les opérations ; appliquez des Access Boundaries limitant les chemins GCS par locataire. Justification : élimine un vecteur fréquent de fuite d’identifiants et restreint l’accès aux données même si les jetons sont volés.

4. Protéger les données avec CMEK et des contrôles régionaux

• Créez des trousseaux de clés (keyrings) et des clés Cloud KMS dans les régions europe-west ; activez CMEK pour les ensembles de données BigQuery, les buckets GCS et les Persistent Disks. Configurez la rotation planifiée et la surveillance des versions. Justification : contrôle cryptographique prouvable aligné sur la résidence dans l’UE et la norme PCI.

5. Adopter le chiffrement au niveau applicatif pour les données de cartes

• Utilisez le chiffrement d’enveloppe (Tink AEAD) avec des clés de données par locataire encapsulées (wrapped) par CMEK ; ne stockez que le texte chiffré dans les bases de données. Justification : protection au niveau du champ et périmètre minimisé lors du tri des incidents.

6. Centraliser les secrets et effectuer une rotation automatique

• Stockez les identifiants de base de données et les jetons d’API dans Secret Manager avec un IAM par service. Implémentez des tâches de rotation déclenchées par Pub/Sub qui créent de nouvelles versions et mettent à jour les déploiements. Si possible, passez à l’authentification IAM pour les bases de données Cloud SQL. Justification : cycle de vie des secrets auditable avec un temps d’arrêt minimal.

7. Segmenter les réseaux et contrôler le trafic de sortie (egress)

• Utilisez des politiques de pare-feu hiérarchiques pour imposer les flux web→API→BD ; refusez directement web→BD. Activez Cloud NAT avec des listes d’autorisation de sortie (allowlists) et Private Google Access (restreint) pour les API Google. Justification : restreint les mouvements est-ouest et bloque l’exfiltration non autorisée.

8. Envelopper les services de données avec VPC Service Controls

• Placez les projets BigQuery, GCS et Secret Manager dans un périmètre de service ; définissez des niveaux d’accès exigeant une adresse IP d’entreprise et des appareils gérés. Testez en mode simulation (dry-run), puis appliquez. Justification : atténue l’exfiltration de données via des jetons volés ou des clients mal configurés.

9. Sécuriser le périmètre (edge) et les API

• Placez le répartiteur de charge HTTPS mondial derrière des règles gérées Cloud Armor et une limitation de débit. Utilisez le routage basé sur le chemin (path-based routing) pour séparer /v1 et /v2 vers des services de backend distincts et appliquez des politiques WAF sur mesure par version. Intégrez Apigee pour l’authentification, les quotas et la validation de schéma. Justification : protection d’API en couches, transition fluide de v1 à v2 et minimisation des faux positifs.

10. Renforcer la sécurité du calcul (compute) et attester les artefacts

• Activez les Shielded VMs et les Confidential VMs pour les nœuds de traitement ; adoptez des images de base renforcées selon les normes CIS. Analysez les images dans Artifact Registry, exigez des attestations signées avec Binary Authorization pour GKE. Justification : protège la chaîne de démarrage et les données en cours d’utilisation, et garantit la confiance dans la chaîne d’approvisionnement (supply-chain).

11. Surveiller la posture et les menaces avec SCC

• Activez SCC Premium pour détecter les configurations à risque et les menaces à l’exécution (runtime) ; intégrez avec le système de ticketing pour les SLA. Supprimez les risques acceptés avec des dates d’expiration. Justification : assurance continue et signal exploitable.

12. Journaliser, conserver et produire des preuves

• Acheminez les journaux d’activité d’administration, d’accès aux données et les VPC Flow Logs vers BigQuery et Cloud Storage avec des politiques de rétention et des conservations à des fins juridiques. Taguez les ensembles de données avec des étiquettes de résidence et de sensibilité. Justification : soutient les enquêtes et les audits externes avec un accès délimité.

13. Préparer la réponse aux incidents et l’analyse forensique

• Créez des runbooks pour isoler les services compromis en déplaçant les projets dans un dossier de quarantaine avec des politiques plus strictes, en désactivant les SA impliqués et en créant des snapshots des disques pour une analyse hors ligne. Justification : confinement rapide avec préservation des preuves.

Commandes courtes pour soutenir le déploiement :

• gcloud kms keyrings create pci-ring –location=europe-west1
• gcloud kms keys create tenant-wrap –keyring=pci-ring –location=europe-west1 –purpose=encryption –rotation-period=90d
• gcloud access-context-manager levels create corp-devices –title=corp-devices –basic-level-spec=‘ipSubnetworks: [“203.0.113.0/24”]’

Avec ces étapes, NimbusPay obtient une protection en couches (identité, crypto, réseau et périmètre), une conformité vérifiable, une évolution contrôlée de l’API sous un seul nom d’hôte, et une préparation pour détecter, confiner et récupérer des incidents.

← Réseau · Tous les domaines · Fiabilité →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →

Parcourir Google →