Guide

Les charges de travail GKE doivent accéder aux API GCP sans gérer les clés de compte de service.

→Activer et configurer Workload Identity sur le cluster GKE. Mapper les comptes de service Kubernetes (KSA) aux comptes de service Google (GSA).

Pourquoi: Élimine le risque de fuite des clés de compte de service en utilisant des identifiants de courte durée, automatiquement renouvelés et dérivés des tokens KSA.

Référence↗

Fournir un accès aux applications web internes depuis n'importe quel réseau, basé sur l'identité de l'utilisateur et la posture de l'appareil, sans VPN.

→Utiliser Identity-Aware Proxy (IAP) avec Access Context Manager. Définir les niveaux d'accès basés sur l'IP, l'état de l'appareil (via Endpoint Verification) et l'identité de l'utilisateur.

Pourquoi: Déplace le contrôle d'accès du périmètre réseau vers les utilisateurs et appareils individuels, appliquant les principes du zéro-trust.

Référence↗

Une pipeline CI/CD (par exemple, GitHub Actions, GitLab) doit accéder aux ressources GCP sans identifiants de longue durée.

→Utiliser Workload Identity Federation. Créer un pool de fournisseurs pour l'IdP externe (par exemple, GitHub OIDC) et configurer des conditions d'attribut pour restreindre l'accès à des dépôts ou branches spécifiques.

Pourquoi: Authentification sans clé pour les charges de travail externes. Le système externe fournit son propre token, qui est échangé contre un token GCP de courte durée.

Appliquer des politiques de sécurité IAM à l'échelle de l'organisation, telles que la prévention de la création de clés de compte de service ou la restriction des autorisations IAM à des domaines spécifiques.

→Utiliser les contraintes de politique d'organisation telles que `iam.disableServiceAccountKeyCreation` et `iam.allowedPolicyMemberDomains`.

Pourquoi: Les politiques d'organisation sont héritées et ne peuvent pas être outrepassées par les propriétaires de projets, garantissant une posture de sécurité cohérente.

Un utilisateur a besoin d'un accès administratif temporaire, auditable et soumis à approbation à un environnement de production pour un incident.

→Utiliser Privileged Access Manager (PAM) pour un accès juste-à-temps (JIT). L'utilisateur demande un rôle spécifique pour une durée limitée, ce qui passe par un flux de travail d'approbation.

Pourquoi: Élimine les privilèges permanents, un risque de sécurité majeur. L'accès est limité dans le temps, justifié et entièrement audité.

Plusieurs équipes partagent un cluster GKE. Chaque équipe doit uniquement gérer les ressources au sein de son propre namespace.

→Accorder le rôle IAM `roles/container.clusterViewer` au niveau du projet. Utiliser les `Role` et `RoleBinding` RBAC de Kubernetes au sein de chaque namespace pour accorder des permissions spécifiques (par exemple, éditer, visualiser).

Pourquoi: Sépare l'authentification au niveau du cluster (IAM) de l'autorisation au niveau du namespace (Kubernetes RBAC), offrant un contrôle multi-locataire granulaire.

Les API doivent être appelées à l'aide d'identifiants de courte durée au lieu de clés statiques.

→Utiliser l'usurpation d'identité de compte de service. Accorder à un principal le rôle `roles/iam.serviceAccountTokenCreator` sur un compte de service cible pour générer des tokens d'accès OAuth 2.0 de courte durée.

Pourquoi: Évite de distribuer et de gérer des clés de longue durée. Les tokens expirent automatiquement (par défaut 1 heure), réduisant les risques en cas de compromission.

Un contractuel a besoin d'accéder à des ressources spécifiques, mais l'accès doit expirer automatiquement après 30 jours.

→Accorder le rôle IAM nécessaire avec une condition IAM basée sur le temps, par exemple, `request.time < timestamp("YYYY-MM-DDTHH:MM:SSZ")`.

Pourquoi: Automatise la révocation de l'accès, évitant le nettoyage manuel et garantissant que l'accès n'est pas prolongé par inadvertance.

Autoriser uniquement les images conteneur signées par la pipeline CI/CD à être déployées sur les clusters GKE de production.

→Implémenter Binary Authorization. Créer une attestation dans la pipeline CI pour signer les images. Configurer une politique Binary Authorization sur le cluster GKE pour exiger cette attestation.

Pourquoi: Applique une chaîne d'approvisionnement logicielle sécurisée en empêchant les images non vérifiées ou altérées de s'exécuter en production.

Référence↗

Accorder des permissions aux ressources basées sur leurs tags attribués, et non sur des noms de ressources individuels.

→Utiliser les conditions IAM avec des expressions de tag de ressource, comme `resource.matchTag("123456789/env", "prod")`.

Pourquoi: Permet un contrôle d'accès basé sur les attributs (ABAC) évolutif. Les permissions sont dynamiques et s'appliquent automatiquement à mesure que les ressources sont taguées.

Permettre à un projet de service de déployer des VM dans un projet hôte Shared VPC sans accorder de droits d'administrateur réseau.

→Dans le projet hôte, accorder au compte de service du projet de service le rôle `roles/compute.networkUser` sur le ou les sous-réseaux spécifiques qu'il doit utiliser.

Pourquoi: Suit le principe du moindre privilège. Les projets de service peuvent utiliser le réseau mais ne peuvent pas le modifier (par exemple, changer les règles de pare-feu), celui-ci restant géré de manière centralisée.

Un utilisateur avec `storage.admin` ne peut pas créer de bucket. Vous devez identifier la cause première.

→Vérifier l'existence d'une politique de refus IAM à un niveau supérieur (dossier, organisation) qui refuse la permission `storage.buckets.create`.

Pourquoi: Les politiques de refus IAM outrepassent toujours toutes les politiques d'autorisation. C'est un outil puissant pour faire respecter des limites de sécurité non négociables.

Activer l'SSO pour les utilisateurs d'Active Directory sur site afin qu'ils accèdent à la console Google Cloud.

→Utiliser Google Cloud Directory Sync (GCDS) pour synchroniser les identités vers Cloud Identity. Configurer la fédération (SAML) entre Cloud Identity et AD FS (ou un autre IdP).

Pourquoi: Maintient AD comme source de vérité pour les identités tout en offrant une expérience SSO fédérée et transparente aux utilisateurs.

Chiffrer les données dans GCP, mais les clés de chiffrement ne doivent jamais quitter le HSM sur site.

→Utiliser Cloud External Key Manager (EKM). Cela permet aux services GCP d'utiliser des clés provenant d'un système de gestion de clés externe pour les opérations CMEK.

Pourquoi: Offre un contrôle maximal et répond aux exigences strictes de souveraineté des données en gardant le matériel de clé en dehors de Google Cloud.

Référence↗

Trouver et classer automatiquement les données sensibles (PII, PHI) sur tous les actifs Cloud Storage et BigQuery.

→Configurer les scans de découverte Cloud Data Loss Prevention (DLP). Les résultats peuvent automatiquement peupler Data Catalog avec des tags.

Pourquoi: Fournit un inventaire et une classification automatisés des données, ce qui constitue la base des politiques de gouvernance et de protection des données.

Une équipe d'analystes doit interroger des données contenant des PII, mais ne doit pas voir les valeurs sensibles brutes. L'intégrité référentielle doit être maintenue.

→Utiliser un modèle de désidentification Cloud DLP avec chiffrement déterministe ou hachage cryptographique.

Pourquoi: Transforme les données sensibles en pseudonymes. Les méthodes déterministes garantissent que la même entrée produit toujours la même sortie, permettant les jointures et les agrégations.

Un cadre de conformité (par exemple, pour les services financiers) exige que les clés de chiffrement soient protégées par un HSM certifié FIPS 140-2 Niveau 3.

→Utiliser Cloud KMS avec un niveau de protection HSM. Cela crée des clés au sein d'un module de sécurité matérielle géré.

Pourquoi: Satisfait les exigences de conformité de haut niveau en utilisant du matériel dédié et certifié pour la gestion des clés sans gérer les HSM physiques.

S'assurer que les nouvelles ressources (par exemple, buckets GCS, ensembles de données BigQuery) sont toujours chiffrées avec des clés gérées par le client (CMEK), et non avec des clés gérées par Google.

→Appliquer la politique d'organisation `constraints/gcp.restrictNonCmekServices`.

Pourquoi: Fournit un contrôle préventif qui force les services spécifiés à utiliser CMEK, assurant une posture de protection des données cohérente.

Les données doivent être stockées dans un état immuable (WORM - Write-Once-Read-Many) pendant une période de rétention spécifique pour des raisons légales ou de conformité.

→Configurer un bucket Cloud Storage avec une politique de rétention et activer Bucket Lock.

Pourquoi: Bucket Lock rend la politique de rétention irréversible, garantissant que les objets ne peuvent être ni supprimés ni modifiés, même par les administrateurs, avant la fin de la période de rétention.

Les identifiants de base de données d'application stockés comme secrets doivent être automatiquement renouvelés sans provoquer d'interruption de l'application.

→Utiliser Secret Manager avec rotation automatique configurée. La rotation déclenche une Cloud Function qui met à jour le mot de passe dans la base de données et crée une nouvelle version du secret.

Pourquoi: La rotation gérée et automatisée réduit le risque de compromission des identifiants. Les applications référencent la version `latest` pour récupérer le nouveau secret de manière transparente.

Une charge de travail traite des données très sensibles, et les données doivent rester chiffrées même en mémoire (en cours d'utilisation).

→Utiliser Confidential Computing en déployant la charge de travail sur des VM confidentielles.

Pourquoi: Fournit un chiffrement de la mémoire basé sur le matériel, protégeant les données de l'hyperviseur et des autres VM. Utiliser l'attestation pour vérifier l'intégrité de l'environnement.

Restreindre l'accès à des colonnes sensibles spécifiques dans une table BigQuery sans créer de vues séparées.

→Utiliser la sécurité au niveau des colonnes de BigQuery. Appliquer des policy tags Data Catalog aux colonnes sensibles et accorder le rôle "Fine-Grained Reader" sur ces policy tags aux utilisateurs/groupes autorisés.

Pourquoi: Applique un accès granulaire directement sur la table, ce qui est plus évolutif et gérable que de maintenir plusieurs vues autorisées.

Protéger les données sensibles dans un bucket GCS même si les permissions IAM sont mal configurées et accordent un accès public.

→Chiffrer les objets avec une clé de chiffrement gérée par le client (CMEK) et contrôler strictement l'accès à cette clé dans Cloud KMS.

Pourquoi: Crée un système à deux clés. Un attaquant a besoin des permissions pour l'objet GCS ET pour la clé KMS afin de déchiffrer les données, offrant une défense en profondeur.

Empêcher la suppression immédiate accidentelle ou malveillante des clés Cloud KMS critiques.

→Lors de la création de la clé, configurer la propriété `destroy_scheduled_duration` à une valeur comme 30 jours.

Pourquoi: Impose une période d'attente avant qu'une clé ne soit définitivement détruite, offrant une fenêtre de récupération en cas de suppression accidentelle.

Une exigence légale de prouver qu'un fichier dans Cloud Storage n'a pas été altéré depuis son téléchargement.

→Lors du téléchargement, recalculer le hachage MD5 ou CRC32C du fichier et le comparer au hachage stocké dans les métadonnées de l'objet Cloud Storage.

Pourquoi: Fournit une preuve cryptographique de l'intégrité de l'objet. Cloud Storage calcule et stocke automatiquement ces hachages lors du téléchargement.

Empêcher la copie de données d'un projet sensible vers un bucket public, même par un utilisateur ayant le rôle `owner`.

→Placer le projet sensible au sein d'un périmètre VPC Service Controls. Cela restreint le mouvement des données vers d'autres projets en dehors du périmètre.

Pourquoi: VPC Service Controls agit comme un pare-feu centré sur les données qui outrepasse les permissions IAM pour la sortie des données, offrant une défense puissante contre l'exfiltration.

Référence↗

Protéger une application web publique contre les attaques DDoS volumétriques et les exploits web courants (par exemple, SQLi, XSS).

→Placer l'application derrière un équilibreur de charge HTTP(S) externe global et y attacher une politique de sécurité Cloud Armor avec des règles WAF préconfigurées.

Pourquoi: L'équilibreur de charge absorbe les attaques DDoS à la périphérie de Google. Cloud Armor fournit un pare-feu d'application web géré pour bloquer les 10 principales menaces OWASP.

Une interconnexion dédiée est utilisée pour la connectivité entre le site sur site et GCP, mais le trafic doit être chiffré pour des raisons de conformité.

→Configurer un tunnel VPN HA sur les attachements VLAN de Cloud Interconnect.

Pourquoi: Combine la bande passante élevée et la faible latence d'une connexion dédiée avec le chiffrement IPsec d'un VPN.

Les systèmes sur site doivent appeler les API Google (par exemple, BigQuery, GCS) sans transiter par l'internet public.

→Configurer l'accès privé Google pour les hôtes sur site. Utiliser Cloud Interconnect ou VPN, et configurer le DNS pour résoudre `*.googleapis.com` vers la plage VIP restreinte.

Pourquoi: Maintient le trafic vers les services Google sur le réseau privé de Google, améliorant la sécurité et potentiellement réduisant les coûts de sortie.

Appliquer le TLS mutuel (mTLS) pour toutes les communications service-à-service au sein d'un cluster GKE.

→Déployer Anthos Service Mesh (ou Istio) et activer l'authentification stricte des pairs mTLS pour les namespaces pertinents.

Pourquoi: Chiffre et authentifie automatiquement tout le trafic au sein du mesh, atteignant un modèle de réseau zéro-trust sans modifications du code de l'application.

Un VPC consommateur a besoin d'accéder en privé à un service (par exemple, une API interne) exécuté dans un VPC producteur sans utiliser de peering ni d'IP publiques.

→Le producteur publie le service en utilisant Private Service Connect. Le consommateur crée un endpoint dans son VPC qui route en privé vers le service.

Pourquoi: Découple la connectivité réseau de l'accès aux services. C'est le moyen moderne et évolutif de fournir un accès privé aux services à travers les VPC et les organisations.

Déployer un cluster GKE où les nœuds n'ont pas d'IP publiques et le plan de contrôle n'est pas exposé à internet.

→Créer un cluster GKE privé. Activer l'accès privé Google sur le sous-réseau pour l'accès des nœuds aux API GCP. Configurer les réseaux autorisés du maître pour restreindre l'accès au plan de contrôle à des IP spécifiques (par exemple, le réseau d'entreprise).

Pourquoi: Réduit considérablement la surface d'attaque du cluster en supprimant les points d'accès publics pour les nœuds et le plan de contrôle.

Dans un cluster GKE, les pods d'un service `frontend` ne devraient être autorisés à communiquer qu'avec les pods d'un service `backend`, et rien d'autre.

→Créer des ressources Kubernetes NetworkPolicy. Appliquer une politique d'entrée aux pods `backend` qui autorise le trafic uniquement depuis les pods `frontend`, basée sur les labels de pod.

Pourquoi: Fournit un pare-feu au niveau des pods au sein du cluster, permettant un modèle de réseau à moindre privilège pour les microservices.

Les VM sans IP externes doivent accéder à internet. Tout le trafic sortant doit provenir d'un petit ensemble d'adresses IP prévisibles pour être autorisé par des tiers.

→Configurer Cloud NAT pour le sous-réseau contenant les VM.

Pourquoi: Fournit une traduction d'adresses réseau gérée pour le trafic internet sortant des instances privées, avec journalisation centralisée et allocation d'IP.

Appliquer une règle de pare-feu de base à l'échelle de l'organisation, telle que le refus de tout SSH depuis internet, qui ne peut être outrepassée par les équipes de projet.

→Créer une politique de pare-feu hiérarchique au niveau de l'organisation ou du dossier avec une règle de refus pour le port 22 depuis `0.0.0.0/0` à haute priorité.

Pourquoi: Les politiques hiérarchiques sont évaluées avant les règles au niveau du VPC, permettant aux équipes de sécurité centrales d'appliquer des gardes de sécurité réseau non négociables.

Résoudre les noms d'hôtes internes au sein d'un VPC sans divulguer les requêtes aux serveurs DNS publics.

→Configurer une zone gérée privée Cloud DNS pour vos domaines internes et l'associer à votre VPC.

Pourquoi: Fournit un DNS autoritaire pour les ressources internes au sein du réseau VPC, améliorant la sécurité et la gérabilité.

Lorsque Security Command Center détecte une menace (par exemple, cryptominage), isoler automatiquement la VM affectée.

→Configurer SCC pour publier les résultats dans un sujet Pub/Sub. Déclencher une Cloud Function qui reçoit le résultat et modifie les tags réseau de la VM pour appliquer une règle de pare-feu de "quarantaine" préconfigurée.

Pourquoi: Permet une réponse aux incidents automatisée et quasi en temps réel, réduisant le temps dont dispose un attaquant dans l'environnement.

Collecter les journaux d'audit de tous les projets de l'organisation et les stocker pendant 7 ans dans un format immuable pour la conformité.

→Créer un sink de journaux au niveau de l'organisation vers un bucket Cloud Storage. Configurer le bucket de destination avec une politique de rétention de 7 ans et Bucket Lock.

Pourquoi: Un sink agrégé centralise les journaux. Bucket Lock garantit que les journaux sont inviolables et répondent aux exigences strictes de rétention de conformité.

Une VM est suspectée d'être compromise. Elle doit être mise hors ligne immédiatement, mais les preuves doivent être préservées pour l'analyse forensique.

→Arrêter l'instance de VM (pour stopper l'activité) et créer immédiatement un snapshot de son disque persistant. Ensuite, l'isoler avec des règles de pare-feu.

Pourquoi: Arrêter l'instance contient la menace, tandis que le snapshot crée une copie du disque à un instant T pour l'analyse sans risque d'altération des preuves.

Détecter quand un compte de service est utilisé depuis une localisation géographique inhabituelle ou effectue des activités anormales.

→Activer le niveau Premium de Security Command Center, qui inclut Event Threat Detection. Ce service analyse les journaux pour détecter les comportements anormaux.

Pourquoi: Utilise l'intelligence des menaces et l'apprentissage automatique de Google pour détecter les menaces difficiles à trouver avec des alertes basées sur des règles, telles que des identifiants compromis.

Une équipe de sécurité centrale doit analyser et corréler les signaux de sécurité de GCP, AWS et des systèmes sur site dans une seule plateforme.

→Ingérer tous les journaux et la télémétrie pertinents dans Chronicle Security Operations (SIEM).

Pourquoi: Chronicle est un SIEM cloud-native conçu pour l'analyse à l'échelle du pétaoctet, avec des analyseurs et des règles de détection intégrés pour les environnements multi-cloud et hybrides.

Détecter quand des ressources GCP gérées par Terraform sont modifiées manuellement via la console, créant une dérive de configuration.

→Configurer un flux Cloud Asset Inventory pour envoyer des notifications de modification d'actifs en temps réel à un sujet Pub/Sub. Un service peut ensuite comparer ces modifications à l'état Terraform.

Pourquoi: Fournit une visibilité en temps réel sur toutes les modifications de ressources, permettant la détection automatisée des modifications hors bande.

Une organisation a des milliers de résultats SCC et doit se concentrer sur ceux qui présentent le risque le plus immédiat pour les actifs critiques.

→Utiliser la simulation de chemin d'attaque dans SCC Premium. Définir les actifs de grande valeur et la simulation identifiera et priorisera les résultats qui forment un chemin direct vers ces actifs.

Pourquoi: Passe d'une priorisation basée sur les vulnérabilités à une priorisation basée sur les risques. Elle met en évidence les combinaisons toxiques de résultats qu'un attaquant pourrait exploiter.

Détecter les activités malveillantes à l'intérieur d'un conteneur GKE en cours d'exécution, telles qu'un shell inattendu ou une connexion de reverse shell.

→Activer Container Threat Detection dans Security Command Center.

Pourquoi: Fournit une visibilité en temps réel sur le comportement des conteneurs, détectant les menaces que l'analyse des vulnérabilités (qui a lieu avant l'exécution) ne peut pas voir.

Une enquête forensique réseau nécessite de capturer et d'analyser le contenu complet des paquets du trafic entre deux VM spécifiques.

→Configurer Packet Mirroring pour cloner le trafic des VM source et l'envoyer à une VM collectrice exécutant des outils d'inspection comme Wireshark ou Zeek.

Pourquoi: Fournit une capture complète des paquets pour une analyse approfondie, contrairement aux VPC Flow Logs qui ne contiennent que des métadonnées.

Empêcher le déploiement de configurations Terraform non sécurisées (par exemple, buckets GCS publics).

→Intégrer un outil de test de sécurité par analyse statique (SAST) comme `tfsec` ou Checkov dans la pipeline CI/CD. Faire échouer la build si des violations de sécurité sont détectées.

Pourquoi: Implémente la sécurité "shift-left" en détectant les mauvaises configurations avant leur déploiement, réduisant le besoin de remédiation réactive.

Une entreprise doit s'assurer que, pour des raisons de conformité, certaines données et traitements ne peuvent avoir lieu que dans les régions de l'UE.

→Appliquer la contrainte de politique d'organisation `gcp.resourceLocations`, n'autorisant que les régions de l'UE spécifiées.

Pourquoi: Ceci est un contrôle technique préventif qui applique la résidence des données au niveau de la création des ressources, ce qui est requis pour des réglementations comme le GDPR.

Une institution financière exige que les ingénieurs du support Google obtiennent une approbation explicite et limitée dans le temps avant d'accéder à leurs données pour un cas de support.

→Activer Access Approval et configurer les approbateurs. Toutes les demandes d'accès de Google généreront une requête qui doit être approuvée.

Pourquoi: Fournit un contrôle client sur l'accès administratif de Google, une exigence clé pour les industries fortement réglementées.

Un auditeur doit vérifier précisément les actions entreprises par le personnel de Google lorsqu'il a été autorisé à accéder à votre environnement.

→Activer et examiner les journaux Access Transparency. Ces journaux fournissent un flux quasi en temps réel des actions entreprises par le personnel de Google.

Pourquoi: Fournit une piste d'audit immuable des actions des administrateurs Google, offrant une visibilité et soutenant les exigences de conformité.

Surveiller en continu l'environnement GCP pour détecter les configurations qui violent une norme de conformité spécifique, comme PCI DSS ou HIPAA.

→Utiliser Security Health Analytics dans Security Command Center, avec la norme de conformité pertinente activée dans le tableau de bord.

Pourquoi: Automatise les contrôles de conformité par rapport aux références de l'industrie, offrant une visibilité continue et générant des résultats pour toute mauvaise configuration détectée.

Un auditeur demande le rapport SOC 2 Type II de Google et l'attestation de conformité PCI DSS.

→Utiliser le Compliance Reports Manager dans la console Google Cloud pour accéder et télécharger les rapports d'audit et les certifications.

Pourquoi: Fournit un portail en libre-service permettant aux clients d'obtenir la documentation de conformité nécessaire pour soutenir leurs propres processus d'audit.

Une agence gouvernementale américaine doit déployer une charge de travail qui répond aux exigences de conformité FedRAMP High.

→Déployer l'application au sein d'un environnement Assured Workloads configuré pour le régime de conformité FedRAMP High.

Pourquoi: Assured Workloads applique automatiquement les contrôles et les garde-fous nécessaires (par exemple, emplacement des données, restrictions d'accès du personnel) pour aider à respecter les normes de conformité spécifiques.