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

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

Fait partie du Google Associate Cloud Engineer — 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 sur Google Cloud reposent sur un modèle de responsabilité partagée et une approche sécurisée par défaut de défense en profondeur. Google sécurise l’infrastructure physique, les services fondamentaux et le chiffrement par défaut, tandis que vous sécurisez l’identité et les accès, la classification et la conservation des données, les configurations applicatives et les processus opérationnels. Concevez selon le principe du moindre privilège à travers la hiérarchie des ressources, utilisez des groupes plutôt que des individus, préférez les identités gérées et les identifiants à courte durée de vie, et superposez les contrôles afin que la défaillance d’un seul contrôle n’entraîne pas de compromission. Intégrez l’observabilité et les workflows de réponse dès le début pour que la posture puisse être mesurée et améliorée en continu.

Fondations de l’identité et des accès

• Responsabilité partagée et moindre privilège
  • Organisez les projets sous une seule organisation avec des dossiers qui reflètent les périmètres de confiance. Appliquez des contraintes de règles d’administration (Organization Policy) pour imposer des paramètres sécurisés par défaut (par exemple, interdire les adresses IP publiques, restreindre les emplacements, empêcher la création de clés de compte de service).
  • Attribuez les rôles IAM à des Google Groups, pas à des utilisateurs, et préférez les rôles prédéfinis aux rôles de base. Révisez régulièrement les liaisons de rôles et supprimez les droits inutilisés.

  • Activez l’auditabilité et l’attribution. Pour l’accès administrateur au système d’exploitation des VM, utilisez OS Login avec des clés SSH par utilisateur ; attribuez aux groupes les rôles roles/compute.osLogin ou roles/compute.osAdminLogin. Exemple :

undefined

-

undefined

• Pièges courants : attribuer les rôles owner ou editor à des utilisateurs, utiliser des clés SSH à l’échelle du projet et créer des clés de compte de service à longue durée de vie.

• Protection de l’accès aux applications avec BeyondCorp et Identity-Aware Proxy (IAP)

  • IAP termine l’accès basé sur l’identité à la périphérie du réseau de Google pour les applications HTTPS et pour le transfert TCP (SSH/RDP), éliminant le besoin d’exposer des applications ou des bastions à Internet. Associez-le à des règles d’accès contextuel (Access Context Manager) pour exiger une posture d’appareil, des plages d’adresses IP ou des groupes d’utilisateurs spécifiques.
  • Avantages : authentification/autorisation (AuthN/Z) centralisée, attribution forte, surface d’attaque réduite et politique de pare-feu simplifiée (refuser le trafic entrant sauf pour le load balancer/IAP).
  • Inconvénients : une mauvaise configuration peut bloquer les administrateurs ; prévoyez une procédure d’urgence (un rôle owner de projet restreint, un accès à la console hors bande). Certains protocoles hérités ou services non-HTTP peuvent nécessiter le transfert TCP d’IAP ou des contrôles alternatifs.

• Comptes de service et identité de charge de travail

  • Préférez attacher des comptes de service à Compute Engine, GKE avec Workload Identity, Cloud Run et Cloud Functions pour que les charges de travail obtiennent automatiquement des jetons à courte durée de vie. Évitez d’intégrer des clés ; désactivez la création de clés de compte de service avec une règle d’administration. Limitez strictement la portée IAM sur les comptes de service (principe du moindre privilège).
  • Pièges courants : attribuer largement le rôle roles/iam.serviceAccountUser, ce qui permet l’usurpation d’identité ; des comptes de service avec des privilèges excessifs qui deviennent des cibles pour le mouvement latéral.

Protection des données et gestion des clés

• Chiffrement, Cloud KMS, CMEK et chiffrement d’enveloppe
  • Par défaut, Google chiffre toutes les données au repos et en transit. Pour un contrôle accru et la séparation des tâches, utilisez les clés de chiffrement gérées par le client (CMEK) dans Cloud KMS. De nombreux services (BigQuery, Cloud Storage, Pub/Sub, disques Compute Engine) prennent en charge les CMEK ; les services utilisent le chiffrement d’enveloppe, où votre CMEK encapsule des clés de chiffrement de données (DEK) par objet ou par bloc.

  • Planifiez la hiérarchie des clés : des trousseaux de clés par région, des clés cryptographiques par domaine de données, et une rotation tous les 90 à 365 jours en fonction du risque. Exemple de rotation :

undefined

• Contrôle d’accès : n’attribuez aux comptes de service le rôle Chiffreur/Déchiffreur de clés cryptographiques Cloud KMS (Cloud KMS CryptoKey Encrypter/Decrypter) que sur les clés nécessaires. Surveillez avec les journaux d’utilisation de Cloud KMS.

• Pièges et compromis : la désactivation ou la suppression d’une CMEK rend les données dépendantes illisibles ; planifiez des guides opérationnels d’incident, vérifiez deux fois les permissions IAM avant une rotation et maintenez la disponibilité des clés à travers les déploiements. Envisagez d’utiliser External Key Manager si vous devez conserver les clés en dehors de Google Cloud ; tenez compte de la latence supplémentaire et du risque de dépendance externe.

• Secret Manager et l’élimination des identifiants codés en dur

  • Stockez les clés d’API, les mots de passe de base de données et les jetons dans Secret Manager avec une gestion automatique des versions et un accès basé sur IAM. Intégrez la rotation via Cloud Scheduler → Pub/Sub → Cloud Functions/Run, qui met à jour le système en amont et écrit une nouvelle version du secret. Les applications récupèrent les secrets au démarrage ou à la demande et les mettent en cache de manière minimale.
  • Bonnes pratiques : ne jamais commiter de secrets dans le code ou les images ; éviter d’afficher les secrets dans les journaux ; attribuer le rôle roles/secretmanager.secretAccessor aux identités de charge de travail ; utiliser des libellés pour marquer la sensibilité.
  • Pièges courants : intégrer des secrets dans des variables d’environnement qui sont journalisées en cas de plantage ; oublier de mettre à jour les applications en aval après une rotation ; des permissions IAM trop larges sur les secrets.

• Classification, conservation et confidentialité des données

  • Classifiez les données (publiques, internes, confidentielles, réglementées) et taguez les ressources avec des libellés. Utilisez la sécurité au niveau des colonnes et les règles d’accès aux lignes de BigQuery pour un contrôle granulaire. Pour la découverte et le masquage, utilisez Sensitive Data Protection (DLP).
  • Mettez en œuvre la conservation : cycle de vie des objets Cloud Storage (transitions de classe basées sur l’âge, suppression), règles de conservation de bucket avec des blocages (holds), et TTL de table ou de partition BigQuery. Alignez la conservation sur les besoins légaux ; une conservation plus longue augmente le risque et le coût.
  • Confidentialité et résidence des données : restreignez les emplacements des ressources avec des règles d’administration ; choisissez un stockage multirégional ou régional en fonction des exigences de souveraineté et de latence. Produisez des preuves avec les journaux d’audit et les tableaux de bord de posture de SCC.

Sécurité du réseau et en périphérie

• Défense en profondeur pour les réseaux

  • Utilisez les règles de pare-feu VPC avec une posture de refus par défaut ; n’autorisez que les plages sources et les ports nécessaires. Privilégiez Private Google Access et Private Service Connect pour maintenir le trafic API hors de l’internet public. Journalisez les VPC Flow Logs et les journaux des règles de pare-feu (Firewall Rules Logging) ; examinez régulièrement les schémas de trafic sortant.
  • Pour le contrôle du trafic sortant, refusez tout le trafic sortant (egress) puis autorisez explicitement les destinations nécessaires via un proxy de sortie FQDN ou un NAT plus un proxy. Surveillez les journaux Cloud NAT et configurez la journalisation DNS.

• VPC Service Controls (VPC SC), périmètres de service et niveaux d’accès

  • Encadrez les API Google compatibles (par exemple, BigQuery, Storage, Pub/Sub) dans des périmètres de service pour atténuer les risques d’exfiltration de données, même en cas de compromission des identifiants. Utilisez Access Context Manager pour définir des niveaux d’accès par groupe d’utilisateurs, adresse IP ou posture de l’appareil, permettant des politiques contextuelles.
  • Configurez des règles de sortie (egress) pour les intégrations légitimes entre périmètres et les ponts de périmètre (perimeter bridges) lorsque cela est nécessaire. Testez avec le mode de simulation (dry-run) de VPC SC pour identifier les ruptures potentielles avant la mise en application.
  • Modes de défaillance : blocage involontaire des tâches CI/CD ou inter-projets, échec des intégrations tierces, ou contournement par les développeurs avec des appareils non gérés. Documentez les exceptions et examinez-les régulièrement.

• Cloud Armor, protection DDoS et règles WAF

  • Le réseau mondial en périphérie de Google fournit une protection DDoS L3/L4 permanente. Cloud Armor ajoute des protections L7 pour les équilibreurs de charge HTTP(S) externes, incluant la limitation de débit, l’accès basé sur la géolocalisation/IP, des expressions personnalisées et des ensembles de règles WAF préconfigurées.
  • Exemple pour créer et attacher un WAF de base :
    • gcloud compute security-policies create web-waf
    • gcloud compute security-policies rules create 1000 –security-policy=web-waf –expression=“evaluatePreconfiguredWaf(‘sqli-v33-stable’)” –action=deny-403 –preview
    • Attachez la politique à votre service de backend d’équilibreur de charge HTTPS.
  • Bonnes pratiques : démarrez les règles en mode prévisualisation (preview) pour réduire les faux positifs, ajoutez des règles d’autorisation pour le trafic connu et fiable, et activez la protection adaptative si vous êtes éligible. Compromis : Cloud Armor s’applique aux équilibreurs de charge HTTP(S) et basés sur un proxy ; les équilibreurs de charge réseau et les équilibreurs de charge internes nécessitent d’autres contrôles.

Opérations de sécurité et conformité

• Security Command Center (SCC) et gestion de la posture de sécurité

  • Utilisez SCC comme plan de contrôle pour la visibilité sur les risques. Le niveau Standard agrège les résultats de mauvaises configurations et les données de vulnérabilité ; le niveau Premium ajoute des détections de menaces (par exemple, Event Threat Detection, VM and Container Threat Detection) et des aperçus des chemins d’attaque.
  • Triez les résultats par gravité, assignez des responsables et suivez-les jusqu’à leur résolution. Exportez les résultats vers BigQuery ou Pub/Sub pour l’intégration SIEM et la conservation des preuves. Mesurez en continu la posture par rapport aux politiques de l’organisation et définissez des alertes sur les régressions.

• Shielded VM, démarrage sécurisé (secure boot), vTPM, surveillance de l’intégrité et renforcement de l’OS

  • Activez les fonctionnalités de Shielded VM pour bloquer les rootkits et la falsification du démarrage : Secure Boot, vTPM et Integrity Monitoring pour détecter les changements dans les chargeurs de démarrage et le noyau. Certains noyaux personnalisés ou modules non signés peuvent échouer au Secure Boot ; validez les images avant l’activation.
  • Renforcez l’OS avec OS Config pour la conformité des correctifs, des référentiels alignés sur le CIS, des paquets minimaux, une connexion SSH sans mot de passe et la journalisation des événements sudo et d’authentification. Préférez le transfert TCP IAP pour SSH et restreignez l’entrée à 0.0.0.0/0.

• Journalisation pour l’investigation numérique, triage des incidents, confinement et remédiation

  • Journalisation pour permettre l’investigation numérique : journaux d’audit Admin Activity et Data Access, VPC Flow Logs, Firewall Rules Logging, journaux Cloud DNS, journaux de l’équilibreur de charge, et journaux d’accès à Cloud KMS et Secret Manager. Exportez vers un projet de journalisation centralisé et BigQuery avec une rétention et des contrôles d’accès appropriés.
  • Playbook de triage et de confinement :
    • Validez les indicateurs avec les résultats de SCC et les journaux corrélés.
    • Confinez en révoquant les jetons suspects, en désactivant les comptes de service compromis, en ajoutant des règles de pare-feu de refus ou en isolant temporairement les instances avec des tags.
    • Préservez les preuves : créez des instantanés (snapshots) des disques, exportez les journaux, capturez la mémoire si nécessaire à l’aide d’outils approuvés, et enregistrez la chaîne de possession.
    • Remédiez : effectuez la rotation des secrets et des clés, appliquez les correctifs aux vulnérabilités, reconstruisez à partir d’images saines connues, ajoutez des détections pour prévenir la récurrence, et effectuez une revue post-incident pour renforcer les contrôles.

Scénario de problème pratique

Nimbus Finance exécute des charges de travail web et API derrière des équilibreurs de charge HTTP(S) externes, traite des données réglementées dans BigQuery et Cloud Storage, et autorise un accès d’administration à distance à ses ingénieurs. Un récent exercice red-team a démontré des risques d’exfiltration de données via des identifiants compromis et des mouvements latéraux. L’équipe des opérations doit renforcer l’accès, protéger les données et améliorer la détection sans perturber la livraison.

1. Appliquer OS Login avec attribution des actions d’administration

• Étapes : Activer OS Login à l’échelle du projet ; ajouter compute.osAdminLogin au groupe des ingénieurs ; supprimer les clés SSH à l’échelle du projet.
• Justification : Les clés SSH par utilisateur et les attributions de rôles basées sur IAM fournissent une attribution claire et une révocation simple. L’élimination des clés partagées réduit les mouvements latéraux.

2. Contrôler l’accès à distance avec IAP et l’accès contextuel

• Étapes : Placer l’interface d’administration derrière un équilibreur de charge HTTPS protégé par IAP ; exiger l’appartenance au groupe des opérations et la posture de l’adresse IP/de l’appareil de l’entreprise via Access Context Manager.
• Justification : L’accès zero-trust supprime l’exposition publique et applique de manière centralisée les conditions d’identité et d’appareil, réduisant ainsi les risques de phishing et de credential stuffing.

3. Implémenter le WAF Cloud Armor avec une mise en application progressive

• Étapes : Créer une politique Cloud Armor ; activer les règles WAF préconfigurées pour SQLi/XSS en mode prévisualisation ; ajouter une règle de limitation de débit pour /login ; surveiller les journaux ; puis mettre en application.
• Justification : Le mode prévisualisation réduit les faux positifs ; les limitations de débit ciblées atténuent le credential stuffing et les bots sans nuire au trafic légitime.

4. Envelopper les services de données dans des VPC Service Controls

• Étapes : Créer un périmètre de service pour les projets BigQuery et Cloud Storage ; définir des règles de sortie pour les tâches CI/CD et d’analyse approuvées ; exiger des niveaux d’accès basés sur le groupe et le réseau.
• Justification : Les périmètres atténuent l’exfiltration de données utilisant des identifiants valides en restreignant où et comment les données protégées peuvent être consultées.

5. Appliquer des CMEK avec Cloud KMS et planifier la rotation

• Étapes : Créer des trousseaux de clés et des clés cryptographiques régionaux pour BigQuery et Storage ; accorder le rôle roles/cloudkms.cryptoKeyEncrypterDecrypter uniquement aux comptes de service ; définir un calendrier de rotation de 180 jours ; surveiller les journaux d’utilisation des clés.
• Justification : Les CMEK appliquent la séparation des tâches et des frontières cryptographiques contrôlées ; la rotation limite le rayon d’impact si une clé est exposée.

6. Centraliser les secrets avec Secret Manager et automatiser la rotation

• Étapes : Déplacer les jetons de base de données et de tiers dans Secret Manager ; accorder un accès selon le principe de moindre privilège aux charges de travail ; implémenter une tâche Cloud Scheduler → Pub/Sub → Cloud Run pour effectuer la rotation des secrets et créer de nouvelles versions.
• Justification : Élimine les identifiants codés en dur ; le versionnage et l’automatisation assurent une rotation prévisible et auditable avec un temps d’arrêt minimal.

7. Renforcer la sécurité de l’hôte avec Shielded VM et le renforcement de l’OS

• Étapes : Activer Secure Boot, vTPM et Integrity Monitoring sur toutes les instances Compute Engine ; imposer une connexion SSH sans mot de passe ; utiliser OS Config pour appliquer les correctifs chaque semaine et appliquer les référentiels CIS.
• Justification : Empêche la falsification au niveau du démarrage, détecte la dérive et réduit la surface d’attaque exploitable sur les nœuds de calcul.

8. Augmenter l’observabilité et la gestion de la posture avec SCC

• Étapes : Activer SCC Premium dans toute l’organisation ; configurer des notifications en temps réel vers Pub/Sub ; exporter les résultats et les journaux vers BigQuery ; créer des tableaux de bord pour les KPI clés (résultats élevés ouverts, temps moyen de remédiation).
• Justification : Une visibilité unifiée raccourcit les fenêtres de détection-réponse et fournit des preuves de conformité.

9. Préparer et tester un playbook d’incident

• Étapes : Documenter les étapes de triage, les comptes de secours privilégiés et les actions de confinement (désactivation IAM, isolement par pare-feu, révocation de jetons) ; s’exercer trimestriellement ; appliquer la rétention des journaux et les rétentions d’objets dans le projet de preuves.
• Justification : Des flux de travail éprouvés réduisent les erreurs sous pression et préservent l’intégrité pour l’investigation numérique, l’analyse des causes profondes et les rapports réglementaires.

10. Valider les changements et minimiser les perturbations

• Étapes : Utiliser l’exécution à blanc (dry run) de VPC SC et le mode prévisualisation de Cloud Armor pour détecter les ruptures ; déployer par environnement avec des canaries ; maintenir un plan de restauration et des fenêtres de maintenance.
• Justification : Un déploiement contrôlé atténue les risques de disponibilité liés au renforcement de la sécurité tout en atteignant la réduction ciblée des risques d’exfiltration et d’accès.

← Surveillance · Tous les domaines · Fiabilité →

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

Parcourir Google →