Liste de vérification de renforcement de la sécurité GCP pour les petites et moyennes équipes

Chemins de menace courants sur GCP

La plupart des incidents infonuagiques commencent par une petite lacune de responsabilité ou de configuration. Repérez ces chemins avant qu'un attaquant ne le fasse.

• Un utilisateur, un compte de service ou une identité de charge de travail disposant d'autorisations excessives peut transformer un seul identifiant volé en un accès étendu à plusieurs projets.
• Un point de terminaison de gestion exposé, un port de débogage ou une règle de pare-feu permissive peut contourner tous les contrôles conçus pour le trafic applicatif normal.
• Un bucket de stockage public ou une URL signée trop permissive peut exposer des données client sans aucune compromission visible de l'application.
• Les charges de travail obsolètes créent un risque durable lorsque d'anciennes images, des espaces de noms oubliés, des comptes de service inutilisés et des ressources sans responsable restent déployables.
• L'absence de preuves d'audit, ou leur conservation trop courte, rend difficile de déterminer qui a modifié une règle, quand l'accès a commencé et quelles données ont été atteintes.
• Une sauvegarde non testée n'est qu'un espoir. Les échecs de restauration, la conservation incomplète et les clés de chiffrement inaccessibles peuvent transformer un événement de sécurité en perte permanente.

Identité et accès

Considérez l'identité comme le principal plan de contrôle. Chaque personne, processus d'automatisation et charge de travail doit disposer d'une identité distincte, avec un objectif bien délimité.

Rendre explicites les limites des ressources

Utilisez l'organisation et les dossiers pour mettre en place des garde-fous, et séparez le développement, la préproduction et la production dans des projets distincts ou derrière des limites de confiance plus strictes. Appliquez les règles d'administration au niveau le plus élevé possible, restreignez l'utilisation des services et évitez de partager des projets de production entre des produits sans rapport.

Accorder le rôle minimal au niveau le plus restreint

Préférez les rôles prédéfinis ou personnalisés aux rôles primitifs trop larges, attribuez-les à des groupes et à des identités de charge de travail, et utilisez les conditions IAM lorsqu'un nom de ressource ou un tag permet de restreindre l'accès. Examinez les autorisations inutilisées et supprimez les accès permanents à la production qui ne devraient relever que d'une procédure d'accès d'urgence (break-glass).

Supprimer les identifiants de longue durée

Utilisez Workload Identity Federation for GKE pour que les pods reçoivent des identifiants de courte durée sans clés de compte de service exportées. Bloquez la création et l'importation de clés à l'aide de règles d'administration lorsque c'est possible, inventoriez les clés restantes et configurez des alertes sur les modifications IAM à haut risque dans Cloud Audit Logs.

Réseau et périphérie

Partez du principe qu'un défaut de l'application finira par être accessible depuis le réseau. Limitez ce à quoi ce défaut peut accéder.

Partir d'un refus par défaut et ajouter des chemins nommés

Utilisez des règles de pare-feu VPC fondées sur le moindre privilège et des NetworkPolicies Kubernetes pour le trafic des pods. Séparez les environnements dans des réseaux distincts, documentez chaque chemin d'entrée et supprimez les règles de débogage trop larges qui autorisent les ports de gestion ou tous les protocoles depuis de vastes plages d'adresses.

Garder les nœuds et les plans de contrôle privés

Désactivez les adresses IP externes sur les nœuds GKE. Privilégiez le point de terminaison privé du plan de contrôle basé sur DNS et, lorsqu'un point de terminaison IP est inévitable, restreignez-le à l'aide de réseaux autorisés. Donnez aux charges de travail un chemin de sortie défini plutôt qu'un large accès à Internet.

Ne publier que les services publics voulus

Exposez les applications via une passerelle ou un équilibreur de charge revu, et non via des adresses de pods ou de nœuds exposées par hasard. Assurez la terminaison TLS avec des certificats gérés, restreignez les hôtes et les chemins d'entrée, appliquez des limites de requêtes et de débit, et placez les interfaces d'administration derrière un accès basé sur l'identité.

Données et secrets

Protégez les données au repos, en transit et en cours d'utilisation, puis prouvez que vous pouvez les récupérer. La découverte des données fait partie du contrôle.

Empêcher l'accès public accidentel

Appliquez la protection contre l'accès public et l'accès uniforme au niveau du bucket sur Cloud Storage. Classez les buckets selon leur sensibilité, restreignez l'accès aux objets et aux clés, activez la journalisation pour les données à forte valeur et utilisez des clés de chiffrement gérées par le client lorsque votre modèle de risque ou de conformité l'exige.

Garder les secrets hors des images et du code source

Stockez les identifiants dans Secret Manager et accordez l'accès à une identité de charge de travail et à une version de secret précises. Effectuez la rotation des secrets de manière délibérée, évitez de les copier dans Git ou dans des images de conteneurs, et ne considérez pas les Kubernetes Secrets ordinaires comme une limite de protection complète.

Tester la restauration, pas seulement la création des sauvegardes

Définissez des objectifs de point de reprise (RPO) et de délai de reprise (RTO), conservez des copies en dehors du domaine de défaillance de production et protégez l'accès aux sauvegardes et aux clés de chiffrement contre l'identité de la charge de travail. Effectuez régulièrement des restaurations dans un environnement isolé, vérifiez les données et consignez le temps écoulé ainsi que toute étape manuelle.

Renforcement de la sécurité GKE

GKE sécurise le plan de contrôle géré, mais la configuration de votre cluster, vos espaces de noms, vos règles d'admission et vos charges de travail restent sous votre responsabilité.

Faire des espaces de noms le contrat d'isolation

Séparez les équipes et les environnements dans des espaces de noms ou des clusters, liez-y des rôles Kubernetes RBAC restreints, et appliquez des quotas de ressources et des NetworkPolicies. Évitez les accès en écriture à l'échelle du cluster pour la livraison des applications, et attribuez à chaque charge de travail son propre compte de service lorsqu'elle a besoin d'une identité distincte.

N'admettre que les images et les configurations de confiance

Appliquez le standard Pod Security restreint ou des règles Policy Controller équivalentes. Déployez les images par condensé immuable, analysez-les pour détecter les vulnérabilités, utilisez Binary Authorization lorsque la provenance compte, et refusez les accès inattendus à l'hôte, les élévations de privilèges et les liaisons cluster-admin.

Supprimer les privilèges inutiles des conteneurs

Exécutez les conteneurs en tant qu'utilisateur non root, supprimez les capacités Linux, utilisez un système de fichiers racine en lecture seule lorsque c'est possible et appliquez le profil seccomp RuntimeDefault. Ne montez pas le jeton du compte de service sans nécessité, évitez les conteneurs privilégiés et les espaces de noms de l'hôte, limitez au strict minimum le compte de service des nœuds, et utilisez Shielded Nodes avec Container-Optimized OS.

Détection et reprise

Les contrôles finissent par échouer. Appuyez-vous sur des preuves et sur des procédures rodées par des exercices, et non sur la certitude que personne n'a commis d'erreur.

Collecter les preuves dont vous aurez besoin

Conservez Cloud Audit Logs ainsi que les journaux système et de charges de travail GKE dans une destination centralisée, avec une durée de conservation adaptée à vos besoins d'investigation. Activez de manière sélective les journaux d'audit pour l'accès aux données sensibles, restreignez l'accès aux journaux et enregistrez les modifications administratives apportées à IAM, au pare-feu, au stockage et à la configuration des clusters.

Alerter sur les changements significatifs pour la sécurité

Déclenchez des alertes en cas d'exposition publique du stockage, de modifications étendues du pare-feu ou d'IAM, de clés de compte de service inattendues, de refus d'admission, d'exposition du plan de contrôle, d'échecs d'authentification répétés, de journalisation désactivée, de sauvegardes en échec et de certificats arrivant à expiration. Acheminez chaque alerte vers un responsable, avec les étapes permettant de la confirmer ou de l'écarter.

S'entraîner à la réponse aux incidents

Rédigez des runbooks courts pour les identifiants divulgués, les données rendues publiques, les charges de travail compromises et la perte de régions ou de projets. Précisez qui peut autoriser le confinement, comment révoquer les accès, comment préserver les preuves et comment rétablir le service. Testez les runbooks avec les personnes qui les utiliseront.

Une liste de vérification priorisée sur 30, 60 et 90 jours

Si votre base de référence est incomplète, ordonnez le travail de façon à réduire d'abord l'exposition, puis à rendre les examens ultérieurs reproductibles.

Jours 1 à 30 : fermer les chemins évidents

Inventoriez les projets et leurs responsables, supprimez les identifiants inutilisés et de longue durée, vérifiez la journalisation d'audit, bloquez les buckets publics, examinez les règles de pare-feu et les attributions IAM les plus larges, identifiez les lacunes des sauvegardes de production et corrigez tout point de terminaison public sans responsable. Attribuez un responsable et une échéance à chaque constat.

Jours 31 à 60 : rendre la base de référence reproductible

Faites passer la configuration du réseau, des identités et des charges de travail dans une infrastructure en tant que code revue et une livraison GitOps. Adoptez Workload Identity, des nœuds privés, le niveau restreint de Pod Security, la vérification des images de confiance, des journaux centralisés et des alertes sur les changements les plus importants.

Jours 61 à 90 : prouver et pérenniser

Réalisez des tests de restauration et un exercice sur table de réponse aux incidents, examinez les accès privilégiés et l'expiration des exceptions, analysez de nouveau les images et les dépendances, vérifiez que les responsables reçoivent bien les alertes et mesurez les écarts restants. Inscrivez ces vérifications dans un cycle d'examen récurrent avant que les preuves ne deviennent obsolètes.

Utilisez cette liste de vérification comme point de départ. Snow Tree peut mettre en place cette base de référence dans le cadre de l'exploitation de sa plateforme gérée ou d'une mission de conseil ciblée.

Plateforme gérée · Conseil

Références officielles

Considérez les recommandations actuelles de Google comme la source de référence technique lorsque les paramètres par défaut de la plateforme ou les fonctionnalités des produits évoluent.

• Google Cloud : bonnes pratiques pour renforcer la sécurité de votre cluster GKE
• Google Cloud : bonnes pratiques de sécurité pour GKE