Ce document inclut les bonnes pratiques et les consignes pour les services Google Cloudtels que Compute Engine, Google Kubernetes Engine (GKE), Pub/Sub, Dataflow et les fonctions Cloud Run lorsque vous exécutez des charges de travail surGoogle Cloud.
Commandes de calcul
Ces contrôles s'appliquent aux services de calcul.
Définir les instances de VM pouvant activer le transfert IP
| ID de contrôle Google | VPC-CO-6.3 |
|---|---|
| Implémentation | Obligatoire |
| Description | La contrainte compute.vmCanIpForward définit les instances de VM pouvant activer le transfert IP. Par défaut, toutes les VM peuvent activer le transfert IP sur n'importe quel réseau virtuel. Spécifiez les instances de VM en utilisant l'un des formats suivants :
|
| Produits applicables |
|
| Chemin d'accès | constraints/compute.vmCanIpForward |
| Opérateur | = |
| Valeur |
|
| Type | Liste |
| Contrôles NIST-800-53 associés |
|
| Commandes associées du profil CRI |
|
| Informations connexes |
Désactiver la virtualisation imbriquée des VM
| ID de contrôle Google | VPC-CO-6.6 |
|---|---|
| Implémentation | Obligatoire |
| Description | La contrainte booléenne compute.disableNestedVirtualization désactive la virtualisation imbriquée à accélération matérielle pour les VM Compute Engine. |
| Produits applicables |
|
| Chemin d'accès | constraints/compute.disableNestedVirtualization |
| Opérateur | Is |
| Valeur |
|
| Type | Booléen |
| Contrôles NIST-800-53 associés |
|
| Commandes associées du profil CRI |
|
| Informations connexes |
Limiter les adresses IP externes sur les VM
| ID de contrôle Google | VPC-CO-6.2 |
|---|---|
| Implémentation | Obligatoire |
| Description | Sauf si cela est nécessaire, empêchez la création d'instances Compute Engine avec des adresses IP publiques. La contrainte de liste Empêchez les instances Compute Engine d'avoir des adresses IP externes pour réduire considérablement leur exposition à Internet. Toute instance dotée d'une adresse IP externe est immédiatement détectable et devient une cible directe pour les analyses automatisées, les attaques par force brute et les tentatives d'exploitation des failles. À la place, exigez des instances qu'elles utilisent des adresses IP privées et gérez l'accès via des chemins contrôlés, authentifiés et enregistrés, comme le tunnel Identity-Aware Proxy (IAP) ou un hôte bastion. L'adoption de cette posture de refus par défaut est une bonne pratique de sécurité fondamentale qui permet de réduire votre surface d'attaque et d'appliquer une approche zéro confiance à votre réseau. Cette contrainte n'est pas rétroactive. |
| Produits applicables |
|
| Chemin d'accès | constraints/compute.vmExternalIpAccess |
| Opérateur | = |
| Valeur |
|
| Type | Liste |
| Contrôles NIST-800-53 associés |
|
| Commandes associées du profil CRI |
|
| Informations connexes |
Définir les adresses IP externes autorisées pour les instances de VM
| ID de contrôle Google | CBD-CO-6.3 |
|---|---|
| Implémentation | Obligatoire |
| Description | La contrainte de liste |
| Produits applicables |
|
| Chemin d'accès | compute.vmExternalIpAccess |
| Opérateur | = |
| Valeur |
|
| Type | Liste |
| Contrôles NIST-800-53 associés |
|
| Commandes associées du profil CRI |
|
| Informations connexes |
Exiger un connecteur VPC pour les fonctions Cloud Run
| ID de contrôle Google | CF-CO-4.4 |
|---|---|
| Implémentation | Obligatoire |
| Description | La contrainte booléenne |
| Produits applicables |
|
| Chemin d'accès | constraints/cloudfunctions.requireVPCConnector |
| Opérateur | = |
| Valeur |
|
| Type | Booléen |
| Contrôles NIST-800-53 associés |
|
| Commandes associées du profil CRI |
|
| Informations connexes |
Configurer des règles de stockage des messages
| ID de contrôle Google | PS-CO-4.1 |
|---|---|
| Implémentation | Facultatif |
| Description | Si vous publiez des messages sur le point de terminaison Pub/Sub mondial, Pub/Sub les stocke automatiquement dans la région Google Cloud la plus proche. Pour contrôler les régions dans lesquelles vos messages sont stockés, configurez une règle de stockage des messages sur votre sujet.
Pour configurer des règles de stockage des messages pour les sujets, utilisez l'une des méthodes suivantes :
|
| Produits applicables |
|
| Contrôles NIST-800-53 associés |
|
| Commandes associées du profil CRI |
|
| Informations connexes |
Désactiver les adresses IP externes pour les jobs Dataflow
| ID de contrôle Google | DF-CO-6.1 |
|---|---|
| Implémentation | Facultatif |
| Description | Désactivez les adresses IP externes pour les tâches d'administration et de surveillance liées aux jobs Dataflow. Configurez plutôt l'accès à vos VM de nœud de calcul Dataflow à l'aide de SSH. Activez l'accès privé à Google et spécifiez l'une des options suivantes dans votre job Dataflow :
Où :
|
| Produits applicables |
|
| Contrôles NIST-800-53 associés |
|
| Commandes associées du profil CRI |
|
| Informations connexes |
Utiliser des tags réseau pour les règles de pare-feu
| ID de contrôle Google | DF-CO-6.2 |
|---|---|
| Implémentation | Facultatif |
| Description | Les tags réseau sont des attributs textuels associés aux VM Compute Engine, telles que les VM de nœud de calcul Dataflow. Les tags réseau vous permettent d'appliquer des règles de pare-feu de réseau VPC et des routes statiques personnalisées à des instances de VM spécifiques. Dataflow permet d'ajouter des tags réseau à toutes les VM de nœud de calcul qui exécutent une tâche Dataflow particulière. |
| Produits applicables |
|
| Contrôles NIST-800-53 associés |
|
| Commandes associées du profil CRI |
|
| Informations connexes |
Contrôles des conteneurs
Ces contrôles s'appliquent aux conteneurs dans GKE.
Limiter l'accès au plan de contrôle
| ID de contrôle Google | GKE-CO-1.1 |
|---|---|
| Implémentation | Obligatoire |
| Description | Par défaut, le plan de contrôle et les nœuds des clusters Google Kubernetes Engine (GKE) disposent d'adresses Internet routables auxquelles il est possible d'accéder depuis n'importe quelle adresse IP. Restreignez l'accès réseau au plan de contrôle en utilisant un point de terminaison basé sur le DNS et en créant des clusters privés. Le plan de contrôle est le centre de gestion d'un cluster Kubernetes. L'exposer à Internet en fait une cible privilégiée pour les pirates informatiques. Cette configuration rend le plan de contrôle privé et le supprime d'Internet. Limiter l'accès au plan de contrôle permet de s'assurer que seuls les appareils vérifiés du réseau privé de votre organisation peuvent gérer le cluster, ce qui réduit considérablement le risque d'attaque externe. |
| Produits applicables |
|
| Contrôles NIST-800-53 associés |
|
| Commandes associées du profil CRI |
|
| Informations connexes |
Utiliser les règles de pare-feu selon le principe du moindre privilège
| ID de contrôle Google | GKE-CO-1.2 |
|---|---|
| Implémentation | Obligatoire |
| Description | Lorsque vous créez des règles de pare-feu, utilisez le principe du moindre privilège pour ne fournir un accès qu'à l'objectif requis. Si possible, assurez-vous que vos règles de pare-feu n'entrent pas en conflit avec les règles de pare-feu par défaut de GKE. |
| Produits applicables |
|
| Contrôles NIST-800-53 associés |
|
| Commandes associées du profil CRI |
|
| Informations connexes |
Utiliser Google Groupes pour RBAC
| ID de contrôle Google | GKE-CO-1.3 |
|---|---|
| Implémentation | Obligatoire |
| Description | Utilisez Google Groupes pour le contrôle des accès basé sur les rôles (RBAC), qui vous permet également d'intégrer vos pratiques de gestion des comptes utilisateur existantes, telles que la révocation d'accès lorsqu'un utilisateur quitte votre organisation. Google Groupes pour RBAC permet de gérer efficacement l'accès aux clusters à l'aide d'Identity and Access Management (IAM) et de Google Groupes. Cette fonctionnalité convient à la plupart des organisations qui utilisent Google Groupes. |
| Produits applicables |
|
| Contrôles NIST-800-53 associés |
|
| Commandes associées du profil CRI |
|
| Informations connexes |
Activer les nœuds GKE protégés
| ID de contrôle Google | GKE-CO-1.4 |
|---|---|
| Implémentation | Obligatoire |
| Description | Activez les nœuds GKE protégés pour la validation cryptographique des nœuds de votre cluster. Les nœuds GKE protégés fournissent une identité et une intégrité de nœud solides et vérifiables. Activez les nœuds GKE protégés lorsque vous créez ou mettez à jour des clusters. Dans la mesure du possible, utilisez des nœuds GKE protégés avec démarrage sécurisé pour authentifier également les composants de démarrage de vos VM de nœuds pendant le processus de démarrage. N'utilisez pas le démarrage sécurisé si vous avez besoin de modules de noyau non signés tiers. Les nœuds GKE protégés sont activés par défaut lorsque vous créez un cluster. |
| Produits applicables |
|
| Contrôles NIST-800-53 associés |
|
| Commandes associées du profil CRI |
|
| Informations connexes |
Utiliser Container-Optimized OS avec l'environnement d'exécution containerd
| ID de contrôle Google | GKE-CO-1.5 |
|---|---|
| Implémentation | Obligatoire |
| Description | Utilisez Container-Optimized OS pour implémenter un OS de conteneur renforcé et géré. Les systèmes d'exploitation à usage général incluent de nombreux programmes supplémentaires qui ne sont pas nécessaires à l'exécution des conteneurs et créent donc une cible plus grande et inutile pour les pirates informatiques. Container-Optimized OS est un système d'exploitation minimal et verrouillé qui réduit considérablement cette surface d'attaque en n'incluant que ce qui est nécessaire. En tant qu'OS géré, Container-Optimized OS dispose également de correctifs de sécurité qui sont automatiquement appliqués par Google. Cela permet de s'assurer que les failles critiques sont corrigées et de réduire votre charge de travail opérationnelle. Une image qui inclut Container-Optimized OS avec containerd (cos_containerd) a containerd comme environnement d'exécution principal des conteneurs, directement intégré à Kubernetes. containerd est le composant d'exécution principal de Docker et est conçu pour fournir des fonctionnalités de conteneur de base pour l'interface CRI (Container Runtime Interface) de Kubernetes. Il est beaucoup moins complexe que le daemon Docker complet et présente donc une surface d'attaque plus petite. |
| Produits applicables |
|
| Contrôles NIST-800-53 associés |
|
| Commandes associées du profil CRI |
|
| Informations connexes |
Utiliser Workload Identity Federation for GKE
| ID de contrôle Google | GKE-CO-1.6 |
|---|---|
| Implémentation | Obligatoire |
| Description | Utilisez Workload Identity Federation for GKE afin de vous authentifier de manière sécurisée auprès des API Google Cloud à partir des charges de travail Google Kubernetes Engine (GKE). Workload Identity Federation for GKE offre une alternative plus simple et plus sûre à l'utilisation de clés de compte de service. |
| Produits applicables |
|
| Contrôles NIST-800-53 associés |
|
| Commandes associées du profil CRI |
|
| Informations connexes |
Activer GKE Sandbox
| ID de contrôle Google | GKE-CO-1.7 |
|---|---|
| Implémentation | Obligatoire |
| Description | Utilisez GKE Sandbox pour ajouter un niveau de sécurité supplémentaire et empêcher ainsi un code non approuvé d'affecter le noyau hôte sur les nœuds de votre cluster Google Kubernetes Engine (GKE). GKE Sandbox améliore l'isolation des charges de travail non approuvées ou sensibles, en offrant une couche de protection supplémentaire contre les attaques d'échappement de conteneur. |
| Produits applicables |
|
| Contrôles NIST-800-53 associés |
|
| Commandes associées du profil CRI |
|
| Informations connexes |
Désactiver le port accessible en lecture seule du kubelet
| ID de contrôle Google | GKE-CO-1.9 |
|---|---|
| Implémentation | Obligatoire |
| Description | Désactivez le port en lecture seule du kubelet (10255) et utilisez le port plus sécurisé (10250) à la place. Kubernetes n'effectue aucune vérification d'authentification ni d'autorisation sur ce port. Le kubelet diffuse les mêmes points de terminaison sur le port 10250, authentifié et plus sécurisé. Vous ne pouvez désactiver le port accessible en lecture seule et non sécurisé du kubelet que dans la version 1.26.4-gke.500 ou ultérieure de GKE. |
| Produits applicables |
|
| Contrôles NIST-800-53 associés |
|
| Commandes associées du profil CRI |
|
| Informations connexes |
Utiliser les espaces de noms et les autorisations RBAC pour limiter l'accès aux ressources du cluster
| ID de contrôle Google | GKE-CO-1.10 |
|---|---|
| Implémentation | Obligatoire |
| Description | Créez des espaces de noms ou des clusters distincts pour chaque équipe et chaque environnement afin d'implémenter le principe du moindre privilège pour l'accès à Kubernetes. Affectez des centres de coûts et les libellés appropriés à chaque espace de noms pour renforcer la responsabilisation et permettre le rejet de débit. N'accordez aux développeurs que le niveau d'accès à leur espace de noms dont ils ont besoin pour déployer et gérer leur application, en particulier en production. Planifiez les tâches que vos utilisateurs doivent effectuer sur le cluster et définissez les autorisations dont ils ont besoin pour chaque tâche. Attribuez les rôles IAM (Identity and Access Management) appropriés pour Google Kubernetes Engine (GKE) aux groupes et aux utilisateurs afin de leur fournir des autorisations au niveau du projet et utilisez le contrôle d'accès RBAC pour accorder des autorisations au niveau d'un cluster et d'un espace de noms. |
| Produits applicables |
|
| Contrôles NIST-800-53 associés |
|
| Commandes associées du profil CRI |
|
| Informations connexes |
Limiter le trafic entre les pods
| ID de contrôle Google | GKE-CO-1.11 |
|---|---|
| Implémentation | Obligatoire |
| Description | Par défaut, tous les pods d'un cluster peuvent communiquer entre eux. Contrôlez la communication entre les pods en fonction de vos charges de travail. Lorsque vous limitez l'accès réseau aux services, il est beaucoup plus difficile pour les pirates informatiques de se déplacer latéralement dans le cluster. Cela présente également l'avantage de doter les services d'une protection contre les dénis de service accidentels ou intentionnels. Il existe deux façons de contrôler le trafic :
|
| Produits applicables |
|
| Contrôles NIST-800-53 associés |
|
| Commandes associées du profil CRI |
|
| Informations connexes |
Utiliser des contrôleurs d'admission pour appliquer les règles
| ID de contrôle Google | GKE-CO-1.12 |
|---|---|
| Implémentation | Obligatoire |
| Description | Les contrôleurs d'admission sont des plug-ins qui régissent et appliquent la façon dont le cluster est utilisé. Activez-les pour utiliser certaines des fonctionnalités de sécurité les plus avancées de Kubernetes, car ils constituent un élément important de l'approche de défense en profondeur pour renforcer votre cluster. Par défaut, les pods de Kubernetes peuvent fonctionner avec des capacités allant au-delà de leurs besoins. Utilisez des contrôles d'admission pour limiter les capacités du pod à celles requises pour la charge de travail. GKE permet de nombreux contrôles de l'exécution des pods afin qu'elle se limite aux fonctionnalités explicitement autorisées. Par exemple, Policy Controller est disponible pour les clusters dans les parcs. Kubernetes dispose également du contrôleur d'admission PodSecurity intégré qui vous permet d'appliquer les normes de sécurité des pods dans des clusters individuels. Policy Controller est une fonctionnalité de GKE qui vous permet d'appliquer et de valider la sécurité sur des clusters GKE à grande échelle à l'aide de règles déclaratives. |
| Produits applicables |
|
| Contrôles NIST-800-53 associés |
|
| Commandes associées du profil CRI |
|
| Informations connexes |
Restreindre les capacités d'automodification des charges de travail
| ID de contrôle Google | GKE-CO-1.13 |
|---|---|
| Implémentation | Obligatoire |
| Description | Certaines charges de travail Kubernetes, en particulier les charges de travail système, sont autorisées à s'automodifier. Par exemple, certaines charges de travail effectuent des autoscaling verticaux sur elle-mêmes. Bien que cette capacité soit pratique, elle peut permettre à un pirate informatique ayant déjà compromis un nœud de passer au niveau supérieur dans le cluster. Par exemple, un pirate informatique peut faire en sorte qu'une charge de travail sur le nœud se modifie pour s'exécuter en tant que compte de service plus privilégié qui existe dans le même espace de noms. N'accordez pas aux charges de travail l'autorisation de se modifier elles-mêmes par défaut. Lorsque l'automodification est nécessaire, limitez les autorisations en appliquant des contraintes Gatekeeper ou Policy Controller, telles que NoUpdateServiceAccount de la bibliothèque Open Source Gatekeeper, qui offre plusieurs règles de sécurité utiles. Lorsque vous déployez des règles, autorisez les contrôleurs qui gèrent le cycle de vie du cluster à les contourner. Les contrôleurs doivent apporter des modifications au cluster, telles que l'application de mises à niveau de cluster. Par exemple, si vous déployez la règle NoUpdateServiceAccount sur GKE, vous devez définir les paramètres suivants dans la contrainte : parameters: allowedGroups: - system:masters allowedUsers: - system:addon-manager |
| Produits applicables |
|
| Contrôles NIST-800-53 associés |
|
| Commandes associées du profil CRI |
|
| Informations connexes |
Surveiller les configurations de vos clusters
| ID de contrôle Google | GKE-CO-1.14 |
|---|---|
| Implémentation | Obligatoire |
| Description | Vérifiez les configurations de votre cluster pour repérer d'éventuels écarts par rapport aux paramètres que vous avez définis. Les paramètres couverts par ces bonnes pratiques, ainsi que d'autres erreurs de configuration courantes, peuvent être vérifiés automatiquement à l'aide de Security Command Center. |
| Produits applicables |
|
| Contrôles NIST-800-53 associés |
|
| Commandes associées du profil CRI |
|
| Informations connexes |
Appliquer l'autorisation binaire
| ID de contrôle Google | BIN-CO-1.1 |
|---|---|
| Implémentation | Obligatoire |
| Description | Utilisez l'autorisation binaire pour vous assurer que des images fiables sont déployées sur Google Kubernetes Engine (GKE) et Cloud Run. L'autorisation binaire permet de s'assurer que seules les images de conteneurs vérifiées et fiables peuvent être déployées dans vos clusters, ce qui renforce la sécurité de la chaîne d'approvisionnement logicielle. |
| Produits applicables |
|
| Chemin d'accès | constraints/binaryauthorization.requireBinauthz |
| Opérateur | == |
| Valeur |
|
| Contrôles NIST-800-53 associés |
|
| Commandes associées du profil CRI |
|
| Informations connexes |
Étapes suivantes
Consultez les paramètres de gestion des données.
Consultez d'autres Google Cloud bonnes pratiques et consignes de sécurité.