Google PCD: Identité, authentification et sécurité des applications — Guide d'étude

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

Fait partie du Google Professional Cloud Developer — 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

L’identité est le nouveau périmètre sur Google Cloud. Les applications doivent authentifier les principaux (utilisateurs, services) et les autoriser avec un accès de moindre privilège aux données et aux API, tout en protégeant les secrets, les clés et la chaîne d’approvisionnement logicielle. Cette section décrit les pratiques de conception et d’exploitation de bout en bout qui combinent Google Cloud IAM, les protocoles d’authentification modernes, les défenses réseau et API, le chiffrement, la journalisation et les processus de réponse. L’accent est mis sur les identifiants éphémères, les politiques centralisées et les contrôles en couches qui échouent en toute sécurité (fail safely).

Identités, authentification et contrôle d’accès

Rôles IAM et comptes de service
- Utilisez la hiérarchie des ressources (organisation > dossier > projet) et les rôles prédéfinis plutôt que les rôles primitifs. Préférez les rôles personnalisés uniquement lorsque les rôles prédéfinis sont trop larges.
- Assignez des comptes de service (SA) aux charges de travail (workloads). Ne réutilisez pas les SA par défaut de Compute Engine ou App Engine. Un SA par périmètre de workload simplifie le moindre privilège et la rotation de la confiance.
- Appliquez le moindre privilège en accordant l’ensemble minimal de permissions au périmètre de ressource le plus restreint.
- Impersonation : Préférez les identifiants éphémères via Service Account Token Creator pour permettre aux humains, aux systèmes CI/CD ou à d’autres services d’obtenir un accès éphémère sans stocker de clés :
  - Accordez le rôle roles/iam.serviceAccountTokenCreator sur le SA cible à l’identité appelante.
  - Exemple : gcloud auth print-access-token –impersonate-service-account sa-ci@proj.iam.gserviceaccount.com
- Workload Identity
  - GKE : Utilisez Workload Identity pour lier les comptes de service Kubernetes aux comptes de service Google ; les jetons sont projetés et échangés automatiquement, sans clés JSON.
  - Workloads externes : Utilisez Workload Identity Federation pour échanger des identifiants OIDC/SAML (par exemple, depuis GitHub Actions ou on-prem) contre des jetons d’accès Google sans stocker de clés à longue durée de vie.
- Modes de défaillance et compromis
  - Des rôles trop larges ou des attributions à un périmètre étendu mènent à des mouvements latéraux. L’absence des privilèges Token Creator bloque les flux d’impersonation. Les fichiers de clés JSON augmentent le rayon d’impact (blast radius) d’une violation.
Authentification utilisateur avec OAuth 2.0, OpenID Connect et Google Identity
- Pour l’authentification des utilisateurs finaux, utilisez OIDC avec Google comme IdP ou un IdP d’entreprise ; validez les jetons d’identification (ID tokens) côté serveur. Pour l’accès aux API, utilisez des jetons d’accès OAuth 2.0 avec les scopes appropriés.
- Validez les jetons : vérifiez iss, aud, exp, iat et la signature en utilisant les JWK de l’IdP ; mettez en cache les JWK et imposez la rotation des clés.
- Pour les backends mobiles/SPA, privilégiez le flux Authorization Code avec PKCE. Évitez les flux implicites.
- Pour la communication de service à service, utilisez le flux JWT de compte de service OAuth 2.0 ou mTLS ; évitez les clés d’API statiques.
- Exemple (impersonation de jeton avec gcloud) : gcloud auth application-default print-access-token –impersonate-service-account api-sa@p.iam.gserviceaccount.com
- Modes de défaillance
  - Ne pas valider aud/iss permet la confusion de jetons (token confusion). Accepter des jetons expirés ou ne pas effectuer la rotation des JWK augmente le risque. L’utilisation de jetons de rafraîchissement (refresh tokens) dans les applications mobiles expose des identifiants à longue durée de vie.
Identity-Aware Proxy (IAP) pour l’accès par navigateur
- Utilisez IAP pour protéger les applications HTTP sur Cloud Run, GKE ou Compute Engine sans y intégrer de logique d’authentification. Appliquez le rôle « Utilisateur d’application Web sécurisée par IAP » pour l’accès.
- Les applications reçoivent un en-tête signé (x-goog-iap-jwt-assertion). Vérifiez le JWT pour faire confiance à l’identité et à l’e-mail de l’utilisateur ; ne vous fiez pas à X-Forwarded-* pour l’authentification.
- Pièges courants : chemins de contournement non routés via IAP, pare-feu de backend mal configuré, ou faire confiance aux en-têtes d’IP client sans l’intégrité de Cloud Load Balancing.

Secrets, clés et chiffrement

Secret Manager
- Stockez les clés d’API, les mots de passe de base de données et les secrets de webhook dans Secret Manager. Appuyez-vous sur le versionnement, les contrôles IAM et les journaux d’audit.
- Modèles d’accès
  - Récupérez au démarrage et mettez en cache en mémoire ; rafraîchissez sur des signaux de changement de secret (notifications Pub/Sub).
  - Évitez d’intégrer (bake) des secrets dans les images ou les variables d’environnement. Si des variables d’environnement sont utilisées, assurez-vous qu’elles ne soient jamais journalisées ou incluses dans les rapports de plantage.
- Rotation
  - Automatisez avec Cloud Scheduler + Cloud Functions/Run pour créer de nouvelles versions, mettre à jour les dépendances et déprécier les anciennes.
  - Exemple : gcloud secrets versions access latest –secret db-password
- Modes de défaillance
  - Des appels excessifs à Secret Manager par requête ajoutent de la latence et risquent d’épuiser les quotas. L’absence du rôle roles/secretAccessor provoque des erreurs 403 à l’exécution.
Cloud KMS et chiffrement applicatif
- Utilisez le chiffrement d’enveloppe : une clé de chiffrement de données (DEK) générée localement chiffre les données ; une clé gérée par le client (CMEK) dans Cloud KMS chiffre la DEK (la KEK).
- Effectuez une rotation régulière des clés ; planifiez le rechiffrement. Préférez le modèle « déchiffrer l’ancien, chiffrer le nouveau » à l’écriture ; les tâches de rechiffrement en masse pour les données au repos sont plus coûteuses.
- Activez les CMEK pour les services (BigQuery, GCS, Pub/Sub, Cloud SQL, etc.) lorsque la conformité l’exige. Conservez les clés KMS dans la même région que les données.
- Exemple CLI :
  - Chiffrer : gcloud kms encrypt –location=global –keyring=app-kr –key=data-key –plaintext-file=note.txt –ciphertext-file=note.txt.enc
  - Déchiffrer : gcloud kms decrypt –location=global –keyring=app-kr –key=data-key –ciphertext-file=note.txt.enc –plaintext-file=note.txt
- Utilisez des bibliothèques de cryptographie éprouvées (par exemple, Tink) pour éviter les erreurs d’implémentation.
- Modes de défaillance
  - Une non-concordance des emplacements empêche l’utilisation des CMEK. Le déchiffrement KMS à chaque requête ajoute de la latence ; mettez en cache les DEK en mémoire en tenant compte de leur rotation. L’absence du rôle roles/cloudkms.cryptoKeyEncrypterDecrypter entraîne des erreurs 403.

Autorisation, API et sécurité du périmètre

Autorisation des applications
- Vérifications basées sur les rôles : simples, rapides, mais grossières. Le contrôle d’accès basé sur les attributs (ABAC) utilise les attributs de l’utilisateur, les attributs de la ressource et le contexte (heure, état de l’appareil) pour des décisions affinées.
- Centraliser l’évaluation des politiques ou utiliser un sidecar/OPA ; propager de manière cohérente les revendications d’identité et de locataire (tenant) à travers les microservices.
- Modèles multi-locataires
  - Intégrer le tenant_id dans les jetons d’authentification et l’appliquer dans chaque chemin d’accès aux données ; utiliser le filtrage au niveau des lignes ou des ensembles de données distincts par locataire pour une isolation stricte.
  - Envisager des comptes de service ou des clés KMS par locataire si une isolation réglementaire est requise.
- Modes de défaillance
  - Références d’objet directes non sécurisées (IDOR) dues à l’absence de vérification du locataire. Logiques d’autorisation divergentes entre les services, entraînant une application incohérente.
Conception d’API sécurisée
- Valider et normaliser toutes les entrées ; rejeter les charges utiles surdimensionnées. Appliquer des types de contenu stricts. Modéliser la menace pour les téléversements de fichiers ; utiliser des URL signées pour les objets volumineux.
- Limitation de débit et quotas : utiliser la limitation de débit de Cloud Armor ou Apigee pour atténuer les abus et les erreurs 429. Implémenter un backoff exponentiel avec gigue (jitter) sur les clients.
- CORS
  - Retourner un Access-Control-Allow-* minimal ; éviter les origines génériques (wildcard) pour les requêtes avec authentifiants. La mise en cache des requêtes preflight réduit la latence.
- Défenses contre CSRF
  - Préférer les API sans état (stateless) avec des jetons bearer dans les en-têtes Authorization. Pour les sessions basées sur les cookies, utiliser SameSite=strict ou lax, des cookies sécurisés et un jeton CSRF (double soumission ou synchroniseur).
- Exemple (règle Cloud Armor) :
  - gcloud compute security-policies rules create 1000 –security-policy web-policy –expression “request.path.matches(’/api/’)” –action rate_based_ban –rate-limit-threshold-count 100 –rate-limit-threshold-interval-sec 60
- Modes de défaillance
  - Une limitation naïve basée sur l’IP peut être contournée avec IPv6 ou des proxys. Un CORS trop permissif permet la fuite de jetons. L’absence de jetons CSRF avec les cookies permet le détournement de session (session riding).
Contrôles réseau et périmètre de données
- Utiliser des politiques de pare-feu hiérarchiques et des règles de pare-feu VPC ; autoriser les vérifications de santé (health checks) des Google Front Ends lorsqu’ils sont derrière un HTTP(S) Load Balancing.
- Exemple :
  - gcloud compute firewall-rules create allow-lb –network prod –allow tcp:80,tcp:443 –source-ranges 130.211.0.0/22,35.191.0.0/16 –direction INGRESS
- Cloud Armor fournit un WAF, une défense contre les bots et des restrictions géographiques/IP ; ajuster les règles et examiner les faux positifs.
- L’accès privé aux services (Private Service Access) fournit une connectivité par IP privée aux services gérés par Google (par exemple, Cloud SQL, Memorystore) ; éviter la sortie publique (egress) et les listes d’autorisation d’IP.
- VPC Service Controls réduit le risque d’exfiltration de données en créant des périmètres autour des services compatibles ; à combiner avec Access Context Manager pour le contexte de l’appareil/de la localisation.
- Modes de défaillance
  - Des périmètres mal configurés bloquent le CI/CD ou interrompent les appels inter-services. Des allocations PSA manquantes empêchent l’attachement d’IP privées. Des règles WAF trop strictes peuvent provoquer des incidents de disponibilité.

Sécurité de la chaîne d’approvisionnement, journalisation et réponse

Sécurité de la chaîne d’approvisionnement logicielle
- Stocker les artefacts dans Artifact Registry ; imposer l’analyse des vulnérabilités. Faire échouer les builds en cas de CVE critiques/élevées, avec un suivi des exceptions aux politiques.
- Épingler les dépendances et les images de base ; éviter la version « latest ». Générer et vérifier les SBOM (Software Bill of Materials). Utiliser Binary Authorization pour exiger des images signées avant le déploiement.
- Signer les images avec Cosign et enregistrer la provenance ; adopter des pratiques de build alignées sur SLSA. Utiliser Workload Identity Federation pour la CI afin d’éliminer les clés JSON.
- Modes de défaillance
  - Les dépendances non épinglées téléchargent des versions vulnérables. Ignorer la provenance permet la falsification des images. Le stockage des identifiants de registre ou des clés de compte de service dans les journaux de CI entraîne une fuite de secrets.
Journalisation et surveillance de la sécurité
- Activer les journaux d’audit Admin Activity et Data Access pour les projets et services critiques. Acheminer les journaux vers un projet dédié avec un accès restreint.
- Créer des métriques Cloud Logging pour les échecs d’authentification, les refus d’autorisation et les erreurs d’évaluation des politiques ; alerter via Cloud Monitoring.
- Exemple (idée de métrique de compteur personnalisé) : Compter les taux de 401/403 sur /api/* et alerter en cas d’écarts par rapport à la ligne de base.
- Triage et remédiation des menaces
  - Utiliser Security Command Center pour agréger les résultats ; créer des playbooks pour les scénarios clés (fuite de clé, force brute, modifications IAM anormales).
  - Automatiser les remédiations courantes (révoquer les jetons, désactiver les clés, effectuer la rotation des secrets, mettre en quarantaine les comptes de service).
- Conception respectueuse de la vie privée
  - Minimiser les PII (informations personnelles identifiables) ; tokeniser lorsque c’est possible. Masquer les valeurs sensibles dans les journaux ; utiliser Cloud DLP pour la classification. Appliquer des politiques de rétention minimale et de stockage régional.
- Modes de défaillance
  - La désactivation des journaux Data Access empêche la détection de l’exfiltration. Les libellés à haute cardinalité font exploser les coûts. La journalisation des secrets crée une exposition durable.

Scénario de problème pratique

Acme Retail construit un portail d’analyse multi-locataire (multi-tenant) sur Cloud Run avec un frontend React, une API Python et des jeux de données BigQuery par locataire. Les exigences incluent le SSO pour les employés et les clients, l’isolation des locataires, la gestion des secrets et des clés, l’accès privé aux bases de données, un WAF et une limitation de débit, ainsi qu’une posture CI/CD robuste sans clés à longue durée de vie.

Approche :

Établir les identités et le moindre privilège

Créer un compte de service Google dédié par microservice (api-sa, ingest-sa). Accorder des rôles de moindre privilège au niveau du projet ou du jeu de données (par exemple, roles/bigquery.dataEditor sur les jeux de données des locataires).
Justification : Les SA par service limitent le rayon d’impact (blast radius) et simplifient la rotation ; les rôles à portée restreinte réduisent les mouvements latéraux.

Utiliser Workload Identity Federation pour la CI/CD

Configurer GitHub Actions OIDC pour usurper l’identité de deployer-sa via les rôles roles/iam.workloadIdentityUser et roles/iam.serviceAccountTokenCreator. Déployer sur Cloud Run avec des jetons d’usurpation d’identité.
Justification : Supprime les clés JSON de la CI ; les identifiants à courte durée de vie réduisent le risque de vol.

Frontend et authentification des utilisateurs

Configurer IAP sur le Load Balancer HTTPS devant les services Cloud Run. Intégrer Google comme IdP pour les employés et l’IdP du client via la fédération. Restreindre l’accès avec le rôle « Utilisateur d’application Web sécurisée par IAP » (IAP-secured Web App User) aux groupes autorisés.
Justification : Authentification centralisée pour les applications de navigateur ; aucune logique d’authentification dans les services ; prise en charge du SSO.

Valider l’identité IAP dans l’API

Vérifier l’en-tête x-goog-iap-jwt-assertion dans l’API ; imposer la présence d’une revendication (claim) tenant_id (mappée à partir d’un groupe ou d’une revendication personnalisée).
Justification : Garantie d’identité forte de la part d’IAP ; l’intégration du contexte du locataire dans chaque requête assure une autorisation cohérente en aval.

Mettre en œuvre une autorisation sensible au locataire

Stocker les politiques par locataire et mapper les utilisateurs à des rôles (viewer, analyst, admin). À chaque requête, vérifier le rôle et les conditions ABAC (correspondance de tenant_id, feature flags).
Justification : Combine la simplicité du RBAC avec la flexibilité de l’ABAC ; élimine les vulnérabilités IDOR en appliquant une portée par locataire.

Secrets et accès à la base de données

Stocker les mots de passe de la base de données et les jetons d’API tiers dans Secret Manager ; accorder le rôle roles/secretmanager.secretAccessor uniquement au SA de l’API. Accéder aux secrets au démarrage et les rafraîchir sur notification de rotation via Pub/Sub.
Justification : Pas d’identifiants en dur ; accès auditable ; rotation opportune sans redémarrage.

Chiffrement des données et CMEK

Créer un trousseau (keyring) et des clés Cloud KMS par environnement. Activer CMEK sur les jeux de données BigQuery et les buckets Cloud Storage. Utiliser le chiffrement d’enveloppe pour tout blob sensible stocké par l’application.
Justification : Les clés gérées par le client (CMEK) répondent aux exigences de conformité et assurent une séparation des tâches.

Connectivité privée et périmètre de service

Utiliser l’accès privé aux services (private service access) pour l’IP privée de Cloud SQL. Créer un périmètre VPC Service Controls pour le projet hébergeant BigQuery et GCS ; ajouter des politiques de contexte d’accès (Access Context) pour l’accès des administrateurs d’entreprise.
Justification : Élimine les chemins de sortie publics ; réduit le risque d’exfiltration de données.

Sécurité de l’API, limitation de débit, CORS et CSRF

Appliquer une politique de sécurité Cloud Armor avec des règles gérées WAF et une limitation de débit au LB HTTP(S) externe ; ajuster les listes d’autorisation (allowlists) pour les IP des partenaires. Configurer un CORS strict (origines explicites) pour l’API et utiliser des jetons Authorization: Bearer ; les cookies ne sont pas utilisés.
Justification : Atténue les risques du Top 10 de l’OWASP et les abus ; empêche la fuite d’identifiants inter-origines ; évite les attaques CSRF en n’utilisant pas de cookies.

Renforcement de la chaîne d’approvisionnement

Stocker les images dans Artifact Registry. Activer l’analyse des vulnérabilités et faire échouer les builds en cas de CVE critiques. Signer les images avec Cosign et imposer Binary Authorization pour exiger les signatures d’Acme en production.
Justification : Empêche l’exécution d’artefacts non validés ; maintient la provenance.

Journalisation, surveillance et alertes

Activer les journaux d’audit (Audit Logs) et les acheminer vers un projet centralisé. Créer des métriques basées sur les journaux pour les pics de 401/403, les permissionDenied de BigQuery et les accès à Secret Manager. Alerter sur les anomalies et configurer des vérifications de disponibilité (uptime checks) Cloud Monitoring pour les points d’accès publics.
Justification : Détection précoce des échecs d’authentification et des abus ; surveillance de la disponibilité.

Playbooks d’incident et exercices de rotation

Documenter les étapes pour révoquer les SA compromis (désactiver, effectuer la rotation des clés, invalider les jetons), effectuer la rotation des secrets et rechiffrer avec de nouvelles versions de clés KMS. Tester trimestriellement.
Justification : Une réponse préparée et reproductible minimise les temps d’arrêt et l’exposition des données.

Cette conception garantit des identités vérifiables à courte durée de vie à chaque étape, une autorisation cohérente et sensible au locataire, des secrets et des clés protégés, des chemins de données privés et une chaîne d’approvisionnement renforcée, avec des workflows d’observabilité et de réponse qui maintiennent la résilience du système face aux attaques et lors des opérations de routine.

← Données d’application · Tous les domaines · Livraison continue →

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