Ce guide aborde les questions spécifiques aux applications Google Kubernetes Engine (GKE) lorsque vous mettez en œuvre des responsabilités client conformes aux exigences relatives à la norme PCI DSS (Payment Card Industry Data Security Standard).
Clause de non-responsabilité : Le présent guide est fourni à titre informatif uniquement. Les informations ou recommandations qui y sont mentionnées n'ont pas vocation à constituer des conseils juridiques. Il appartient à chaque client d'évaluer indépendamment sa propre utilisation des services de manière appropriée afin de s'acquitter de ses obligations légales en termes de conformité.
Présentation de la conformité avec la norme PCI DSS et GKE
Si vous gérez des données de cartes de paiement, vous devez les sécuriser, qu'elles résident dans une base de données locale ou dans le cloud. La norme PCI DSS a été développée pour encourager et améliorer la sécurité des données des titulaires de cartes, et simplifier l'adoption à grande échelle de mesures de sécurité des données cohérentes au niveau mondial. La norme PCI DSS offre les bases en termes d'exigences techniques et opérationnelles destinées à protéger les données de carte de crédit. La norme PCI DSS s'applique à toutes les entités impliquées dans le traitement des cartes de paiement, y compris les marchands, les processeurs, les acquéreurs, les émetteurs et les fournisseurs de services. La norme PCI DSS s'applique également à toutes les autres entités qui stockent, traitent ou transmettent des données de titulaire de carte (CHD) ou des données d'authentification sensibles (SAD), ou les deux.
Les applications en conteneurs ont récemment gagné en popularité en migrant d'anciennes charges de travail comprises dans une architecture basée sur des VM (machines virtuelles) vers une architecture en conteneurs. Google Kubernetes Engine est un environnement géré et prêt à l'emploi pour le déploiement d'applications en conteneur. Il regroupe les dernières innovations de Google en matière de productivité des développeurs, d'efficacité des ressources, d'automatisation des opérations et de flexibilité Open Source pour accélérer vos temps de production.
La conformité est une responsabilité partagée dans le cloud. Google Cloud, y compris GKE (modes de fonctionnement Autopilot et Standard), respecte les exigences de la norme PCI DSS. Nos responsabilités sont décrites dans la matrice de responsabilité partagée.
Audience visée
- Les clients qui souhaitent amener des charges de travail conformes à la norme PCI dans Google Cloud impliquant GKE.
- Les développeurs, responsables de la sécurité, responsables de la conformité, administrateurs informatiques et autres employés responsables de la mise en œuvre des contrôles et de la conformité aux exigences de la norme PCI DSS.
Avant de commencer
Pour les recommandations qui vont suivre, vous devrez peut-être utiliser les éléments suivants :
- Ressources Organisation, Dossier et Projet Google Cloud
- Gestion de l'authentification et des accès (IAM)
- Google Kubernetes Engine
- VPC Google Cloud
- Google Cloud Armor
- API Cloud Data Loss Prevention (partie intégrante de la protection des données sensibles)
- Identity-Aware Proxy (IAP)
- Security Command Center
Ce guide est destiné aux personnes qui connaissent déjà le fonctionnement des conteneurs et de GKE.
Portée
Ce guide décrit ci-dessous les exigences de la norme PCI DSS, qui constituent des préoccupations spécifiques à GKE. Il offre également des conseils pour les satisfaire. Il a été rédigé par rapport à la version 4.0 de la norme. Ce guide ne couvre pas l'intégralité des exigences relatives à la norme PCI DSS. Les informations fournies dans ce guide peuvent aider les organisations à se conformer à la norme PCI DSS, mais il ne s'agit pas de conseils exhaustifs. Les organisations peuvent faire appel à un Évaluateur de sécurité qualifié PCI (QSA) pour une validation officielle.
Terminologie
Cette section définit les termes utilisés dans ce guide. Pour en savoir plus, reportez-vous au glossaire PCI DSS.
- CHD
données du titulaire de carte. Comprend au minimum le numéro complet du compte principal (PAN). Les données du titulaire de carte peuvent prendre la forme du PAN complet, accompagné de l'une ou de plusieurs des informations suivantes :
- Nom du titulaire de la carte
- Date d'expiration et/ou code de service
- Données d'authentification sensibles (SAD)
- CDE
environnement des données des titulaires de cartes. Les personnes, les processus et la technologie qui stockent, traitent ou transmettent des données de titulaires de cartes ou des données d'authentification sensibles.
- PAN
numéro de compte principal. Un élément majeur des données du titulaire de la carte, que vous avez l'obligation de protéger selon la norme PCI DSS. Le PAN prend généralement la forme d'un numéro à 16 chiffres, unique pour chaque carte de paiement (crédit et débit). Il permet d'identifier l'émetteur et le compte du titulaire de la carte.
- Code PIN
numéro d'identification personnel. Un mot de passe numérique uniquement connu par l'utilisateur et le système. Il permet d'authentifier l'utilisateur sur le système.
- QSA
évaluateur de sécurité qualifié. Une personne certifiée par le PCI SSC pour procéder à des vérifications et à des analyses de conformité.
- SAD
données d'authentification sensibles. Dans le cadre de la conformité PCI, il s'agit des données qui permettent aux émetteurs de cartes d'autoriser des transactions. Comme pour les données des titulaires de cartes, la norme PCI DSS exige la protection des SAD. De plus, les SAD ne peuvent pas être conservées par les marchands et leurs sociétés de traitement des paiements. Les SAD incluent les éléments suivants :
- Données de "suivi" générées par les bandes magnétiques
- "Données équivalentes aux données de suivi" générées par la puce et par les cartes sans contact
- Codes de validation de la sécurité (par exemple, le numéro à 3 ou 4 chiffres inscrit sur les cartes), qui permettent d'effectuer des transactions en ligne ou sans sa carte à portée de main
- Codes PIN et PIN blocks
- Segmentation
Dans le cadre de la norme PCI DSS, il s'agit d'une pratique visant à isoler le CDE du reste du réseau de l'entité. La segmentation ne constitue pas une exigence de la norme PCI DSS. Toutefois, il s'agit d'une méthode fortement recommandée pour aider à diminuer les éléments suivants :
- Champ d'application et coût de l'évaluation PCI DSS
- Coût et difficulté de la mise en œuvre et de la gestion des contrôles PCI DSS
- Risques pour une organisation (réduit en consolidant les données des titulaires de cartes dans des emplacements moins nombreux et mieux contrôlés)
Segmenter l'environnement des données de titulaires de cartes
L'environnement des données de titulaires de cartes (CDE) comprend les personnes, les processus et les technologies qui stockent, traitent ou transmettent des données de titulaires de cartes ou des données d'authentification sensibles. Dans le contexte de GKE, le CDE comprend également les éléments suivants :
- Des systèmes fournissant des services de sécurité (par exemple, IAM).
- Des systèmes simplifiant la segmentation (exemple : projets, dossiers, pare-feu, clouds privés virtuels (VPC) et sous-réseaux).
- Les pods et clusters d'applications qui stockent, traitent ou transmettent des données de titulaires de cartes. Sans segmentation appropriée, la totalité de votre présence sur le cloud peut s'inscrire dans le champ d'application de la norme PCI DSS.
Pour être considéré comme étant hors du champ d'application de la norme PCI DSS, un composant système doit être correctement isolé du CDE, de sorte que même si sa sécurité était compromise, celle du CDE ne s'en trouverait pas impactée.
Une condition préalable essentielle à la réduction du champ d'application du CDE est une bonne compréhension des besoins et des processus de l'entreprise concernant le stockage, le traitement et la transmission des données des titulaires de cartes. Limiter les données des titulaires de cartes à un nombre d'emplacements le plus restreint possible en éliminant les données inutiles et en consolidant les données nécessaires peut vous obliger à repenser entièrement vos pratiques commerciales de longue date.
Vous pouvez segmenter votre CDE de différentes façons sur Google Cloud. Cette section traite des moyens suivants :
- Segmentation logique à l'aide de la hiérarchie des ressources
- Segmentation du réseau à l'aide de VPC et de sous-réseaux
- Segmentation de niveau de service à l'aide de VPC
- Autres remarques pour tous les clusters concernés
Segmentation logique à l'aide de la hiérarchie des ressources
Il existe plusieurs façons d'isoler votre CDE au sein de votre structure organisationnelle à l'aide de la hiérarchie des ressources de Google Cloud. Les ressources Google Cloud sont organisées de façon hiérarchique. La ressource Organisation est le nœud racine de la hiérarchie des ressources Google Cloud. Les dossiers et les projets relèvent de la ressource Organisation. Les dossiers peuvent contenir des projets et des dossiers. Les dossiers permettent de contrôler l'accès aux ressources dans l'arborescence de dossiers au moyen d'autorisations IAM au niveau du dossier. Ils servent également à regrouper des projets semblables. Un projet constitue une limite de confiance pour toutes vos ressources et un point d'application IAM.
Vous pouvez regrouper tous les projets couverts par la norme PCI dans un seul dossier afin de les isoler au niveau du dossier. Vous pouvez également utiliser un projet pour tous les clusters et applications PCI inclus dans le champ d'application. Vous pouvez également créer un projet et un cluster pour chaque application PCI et les utiliser pour organiser vos ressources Google Cloud. Quelle que soit votre méthode, nous vous recommandons de conserver les charges de travail couvertes et non couvertes dans des projets différents.
Configurer la segmentation réseau à l'aide des sous-réseaux VPC personnalisés
Vous pouvez vous servir du cloud privé virtuel (VPC) et des sous-réseaux pour provisionner votre réseau, ainsi que pour regrouper et isoler des ressources associées au CDE. Les réseaux VPC constituent une isolation logique d'une section de cloud public. Les réseaux VPC fournissent des réseaux évolutifs et flexibles pour vos instances de machines virtuelles Compute Engine et pour les services qui exploitent les instances de VM, y compris GKE. Pour plus d'informations, consultez la présentation du VPC et consultez les bonnes pratiques et architectures de référence.
Segmentation de niveau de service à l'aide de VPC Service Controls et de Google Cloud Armor
Alors que les VPC et les sous-réseaux fournissent la segmentation et créent un périmètre permettant d'isoler votre CDE, VPC Service Controls augmente le périmètre de sécurité au niveau de la couche 7. VPC Service Controls peut servir à créer un périmètre autour de vos projets couverts par le CDE. VPC Service Controls offre les contrôles suivants :
- Contrôle d'entrée. Seuls les clients et les identités autorisées peuvent accéder au périmètre de sécurité.
- Contrôle de sortie. Seules les destinations autorisées sont accessibles aux identités et aux clients situés dans votre périmètre de sécurité.
Vous pouvez utiliser Google Cloud Armor pour créer des listes d'adresses IP afin d'autoriser ou de refuser l'accès à votre Équilibreur de charge HTTP(S) à la périphérie du réseau Google Cloud. En examinant les adresses IP les plus proches de l'utilisateur et du trafic malveillant, vous aidez à empêcher le trafic malveillant de consommer des ressources ou de s'introduire dans vos réseaux VPC.
Utilisez VPC Service Controls pour définir un périmètre de service autour des projets couverts. Ce périmètre régit les chemins d'accès de VM à service et de service à service, ainsi que le trafic d'entrée et de sortie VPC.
Créer et gérer un réseau et des systèmes sécurisés
La création et la gestion d'un réseau sécurisé englobent les exigences 1 et 2 de la norme PCI DSS.
Exigence 1
Installer et gérer une configuration de pare-feu pour protéger les données de titulaire de carte, ainsi que le trafic entrant et sortant du CDE.
Les concepts de mise en réseau des conteneurs et de GKE diffèrent de ceux des VM classiques. Les pods peuvent se contacter directement, sans NAT, même entre nœuds. Cela crée une topologie de réseau simple qui peut vous surprendre si vous avez pour habitude de gérer des systèmes plus complexes. La première étape concernant la sécurité réseau pour GKE consiste à vous familiariser avec ces concepts de mise en réseau.
Avant d'aborder les exigences individuelles comprises sous l'exigence 1, vous souhaiterez peut-être consulter les concepts de mise en réseau suivants en lien avec GKE :
Règles de pare-feu. Les règles de pare-feu permettent de restreindre le trafic vers vos nœuds. Les nœuds GKE sont provisionnés en tant qu'instances Compute Engine et ont recours aux même mécanismes de pare-feu que les autres instances. Au sein de votre réseau, vous pouvez appliquer ces règles de pare-feu à chaque instance en utilisant des tags. Chaque pool de nœuds reçoit son propre ensemble de tags que vous pouvez utiliser dans des règles. Par défaut, chaque instance appartenant à un pool de nœuds reçoit un tag qui identifie le cluster GKE spécifique contenant ce pool de nœuds. Ce tag est utilisé dans les règles de pare-feu que GKE crée automatiquement pour vous. Vous pouvez ajouter des tags personnalisés au moment de la création du cluster ou du pool de nœuds en utilisant l'option
--tagsde Google Cloud CLI.Règles de réseau. Les règles de réseau vous permettent de limiter les connexions réseau entre les pods, ce qui peut contribuer à limiter le pivotement du réseau et les mouvements latéraux à l'intérieur du cluster en cas de problème de sécurité rencontré avec un pod. Pour utiliser les règles de réseau, vous devez activer cette fonctionnalité de manière explicite lors de la création du cluster GKE. Vous pouvez l'activer sur un cluster existant, ce qui entraînera le redémarrage des nœuds du cluster. Par défaut, la communication entre les pods est toujours ouverte. Par conséquent, si vous souhaitez segmenter votre réseau, vous devez appliquer des règles de mise en réseau au niveau du pod. Dans GKE, vous pouvez définir une règle de réseau à l'aide de l'API Network Policy de Kubernetes ou à l'aide de l'outil
kubectl. Ces règles de trafic au niveau du pod identifient les pods et les services qui peuvent accéder au cluster.Espaces de noms. Les espaces de noms permettent de segmenter les ressources au sein de votre cluster Kubernetes. Kubernetes est fourni avec un espace de noms par défaut prêt à l'emploi. Toutefois, vous pouvez créer plusieurs espaces de noms dans votre cluster. Les espaces de noms sont isolés de façon logique les uns des autres. Ils offrent un champ d'application pour les pods, les services et les déploiements dans le cluster, de sorte que les utilisateurs qui interagissent avec un espace de noms n'aient pas accès au contenu d'un autre espace de noms. Toutefois, les espaces de noms d'un même cluster ne limitent pas la communication entre les espaces de noms. C'est là que les règles de réseau entrent en jeu. Pour en savoir plus sur la configuration des espaces de noms, consultez l'article de blog Bonnes pratiques relatives aux espaces de noms.
Le schéma ci-dessous illustre les concepts précédents les uns par rapport aux autres, ainsi que d'autres composants GKE tels que les clusters, les nœuds et les pods.
Exigence 1.1
Les processus et mécanismes d'installation et de maintenance des contrôles de sécurité du réseau sont définis et compris
Exigence 1.1.2
Décrire les groupes, les rôles et les responsabilités pour la gestion des composants réseau.
Pour commencer, comme avec la plupart des services sur Google Cloud, vous devez configurer des rôles IAM afin de mettre en place les autorisations sur GKE. Lorsque vous avez configuré vos rôles IAM, vous devez ajouter une configuration de contrôle des accès basé sur les rôles Kubernetes (RBAC) dans le cadre d'une stratégie d'autorisation Kubernetes.
Pour l'essentiel, toute configuration IAM s'applique à toutes les ressources Google Cloud et à tous les clusters d'un projet. La configuration de Kubernetes RBAC s'applique aux ressources de chaque cluster Kubernetes et permet une gestion précise des autorisations au niveau de l'espace de noms. Avec GKE, ces approches d'autorisation fonctionnent en parallèle, avec les capacités d'un utilisateur qui représentent efficacement une union entre les rôles IAM et RBAC qui lui sont attribués :
- Servez-vous d'IAM pour contrôler les groupes, les rôles et les responsabilités liés à la gestion logique des composants réseau dans GKE.
- Utilisez Kubernetes RBAC pour accorder des autorisations précises aux règles de réseau au sein des clusters Kubernetes afin de contrôler le trafic entre pods et de prévenir tout changement accidentel ou non autorisé de la part d'utilisateurs extérieurs au CDE.
- Soyez capable de justifier tous les utilisateurs et autorisations IAM et RBAC. En règle générale, lorsque les évaluateurs de sécurité qualifiés testent les contrôles, ils cherchent une justification de l'entreprise concernant IAM et RBAC.
Exigence 1.2
Les contrôles de sécurité du réseau (NSC) sont configurés et gérés.
Commencez par configurer des règles de pare-feu sur les instances de Compute Engine qui exécutent vos nœuds GKE. Les règles de pare-feu vont protéger ces nœuds de cluster.
Configurez ensuite les règles de réseau pour limiter les flux et protéger les pods d'un cluster. Une règle de réseau spécifie les groupes de pods autorisés à communiquer entre eux et avec d'autres points de terminaison du réseau. La fonctionnalité d'application de la règle de réseau de GKE vous permet de contrôler la communication entre les pods et les services de votre cluster. Pour segmenter davantage votre cluster, créez plusieurs espaces de noms en son sein. Les espaces de noms sont isolés de façon logique les uns des autres. Ils offrent un champ d'application pour les pods, les services et les déploiements dans le cluster, de sorte que les utilisateurs qui interagissent avec un espace de noms n'aient pas accès au contenu d'un autre espace de noms. Toutefois, les espaces de noms d'un même cluster ne limitent pas la communication entre les espaces de noms. C'est là que les règles de réseau entrent en jeu. Les espaces de noms permettent de segmenter les ressources au sein de votre cluster Kubernetes. Pour en savoir plus sur la configuration des espaces de noms, consultez l'article de blog Bonnes pratiques relatives aux espaces de noms.
Par défaut, en l'absence de règle d'espace de noms définie, tout le trafic entrant et sortant est autorisé à circuler dans l'ensemble des pods de cet espace de noms. Par exemple, vous pouvez créer une règle d'isolation par défaut pour un espace de noms en créant une règle de réseau qui sélectionne tous les pods, mais qui n'autorise aucun trafic entrant vers ces pods.
Exigence 1.2.2
Toutes les modifications apportées aux connexions réseau et aux configurations des NSC sont approuvées et gérées conformément au processus de contrôle des modifications défini à l'exigence 6.5.1.
Pour traiter vos configurations réseau et votre infrastructure comme du code, vous devez établir un pipeline d'intégration et de livraison continues (CI/CD) dans le cadre de vos processus de gestion et de contrôle du changement.
Vous pouvez utiliser les modèles Cloud Deployment Manager ou Terraform dans le cadre du pipeline CI/CD pour créer des règles de réseau sur vos clusters. Avec Deployment Manager ou Terraform, vous pouvez traiter la configuration et l'infrastructure comme du code. Vous pouvez donc facilement reproduire des copies cohérentes de votre environnement de production actuel ou d'autres environnements. Vous serez ensuite autorisé à écrire des tests unitaires et d'autres tests pour vérifier le bon fonctionnement du changement apporté au réseau. Un processus de contrôle du changement comprenant une approbation peut se gérer via les fichiers de configuration stockés dans un dépôt de révision.
À l'aide de Terraform Config Validator, vous pouvez définir des contraintes pour appliquer les règles de sécurité et de gouvernance. En ajoutant Config Validator à votre pipeline CI/CD, vous pouvez ajouter une étape à n'importe quel workflow. Cette étape permet de valider un plan Terraform ou de le refuser en cas de non-respect des règles.
Exigence 1.2.5
Tous les services, protocoles et ports autorisés sont identifiés, approuvés et ont des besoins définis.
Pour des contrôles d'entrée renforcés pour vos clusters GKE, vous pouvez utiliser des réseaux autorisés pour restreindre certaines plages d'adresses IP capables d'atteindre le plan de contrôle de votre cluster. GKE utilise TLS (Transport Layer Security) et l'authentification afin de fournir un accès sécurisé au point de terminaison des maîtres du cluster à partir du réseau Internet public. Cet accès vous donne la possibilité d'administrer votre cluster depuis n'importe où. En utilisant des réseaux autorisés, vous pouvez restreindre davantage l'accès à des ensembles d'adresses IP spécifiés.
Vous pouvez vous servir de Google Cloud Armor pour créer des listes d'autorisation et d'interdiction d'adresses IP et des règles de sécurité pour les applications hébergées sur GKE. Dans un cluster GKE, le trafic entrant est géré par l'équilibrage de charge HTTP(S), un composant de Cloud Load Balancing. En règle générale, l'équilibreur de charge HTTP(S) est configuré par le contrôleur d'entrée GKE, qui obtient les informations de configuration à partir d'un objet Ingress Kubernetes. Pour en savoir plus, consultez la section Configurer des règles Google Cloud Armor avec GKE.
Exigence 1.3
L'accès réseau depuis et vers l'environnement des données des titulaires de cartes est limité.
Pour garantir la confidentialité des données sensibles, vous pouvez configurer des communications privées entre les clusters GKE au sein de vos réseaux VPC et avec les déploiements hybrides sur site à l'aide de VPC Service Controls et de l'accès privé à Google.
Exigence 1.3.1
Le trafic entrant vers le CDE est restreint comme suit :
- Seul le trafic nécessaire est autorisé.
- Tout autre trafic est spécifiquement refusé.
Envisagez de mettre en œuvre une configuration Cloud NAT avec GKE pour limiter le trafic Internet entrant à ce cluster uniquement. Vous pouvez configurer un cluster privé pour les clusters non publics dans votre CDE. Dans un cluster privé, les nœuds ne disposent que d'adresses IP internes RFC 1918, ce qui garantit que leurs charges de travail sont isolées de l'Internet public.
Exigence 1.4
Les connexions réseau entre les réseaux approuvés et non approuvés sont contrôlées.
Vous pouvez répondre à cette exigence en utilisant les mêmes méthodes mentionnées pour l'Exigence 1.3.
Exigence 1.4.3
Des mesures anti-spoofing sont mises en œuvre pour détecter et bloquer les adresses IP source falsifiées afin qu'elles n'entrent pas dans le réseau de confiance.
Pour mettre en œuvre des mesures anti-spoofing, vous devez utiliser des adresses IP d'alias sur les pods et les clusters GKE afin de détecter les adresses IP sources falsifiées et de les empêcher d'entrer dans le réseau. Un cluster qui s'appuie sur des plages d'adresses IP d'alias est appelé cluster de VPC natif.
Exigence 1.4.5
La divulgation des adresses IP internes et des informations de routage est limitée aux parties autorisées.
Vous pouvez utiliser un agent de masquage d'adresses IP GKE pour effectuer la traduction d'adresses réseau (NAT) pour traduire plusieurs adresses IP en une seule sur un cluster. Cette fonction masque plusieurs adresses IP sources derrière une même adresse.
Exigence 2
Appliquer des configurations sécurisées à tous les composants du système
L'exigence 2 indique comment renforcer les paramètres de sécurité en supprimant les valeurs par défaut et les identifiants fournisseurs. Renforcer la sécurité du cluster relève de la responsabilité du client.
Exigence 2.2
Les composants système sont configurés et gérés de manière sécurisée.
Assurez-vous que ces normes englobent toutes les failles de sécurité et qu'elles sont cohérentes avec les normes de renforcement du système acceptées par l'industrie. Les sources des normes de renforcement acceptées par l'industrie peuvent inclure, sans s'y limiter, les organismes suivants :Exigence 2.2.4
Seuls les services, les protocoles, les daemons et les fonctions nécessaires sont activés, et toutes les fonctionnalités inutiles sont supprimées ou désactivées.
Exigence 2.2.5
- Une justification métier est documentée.
- Des fonctionnalités de sécurité additionnelles sont documentées et mises en œuvre, ce qui réduit le risque d'utilisation de services, de protocoles ou de daemons non sécurisés.
Exigence 2.2.6
Les paramètres de sécurité du système sont configurés de façon à éviter tout usage inadéquat.
Avant le déploiement
Avant de migrer vos conteneurs vers GKE, nous vous recommandons de prendre les mesures suivantes :
- Commencez avec une image de base gérée de conteneur qui est créée, mise à jour et contrôlée pour les failles par une source fiable. Envisagez de créer un ensemble d'images de base "connues" ou "clés" à destination de vos développeurs. Une option plus restrictive consiste à utiliser une image minimale ou une image de base scratch.
- Recherchez les failles des images de conteneur à l'aide d'Artifact Analysis.
- Mettez en place une règle DevOps/SecOps pour n'ajouter aux conteneurs que les bibliothèques et les fichiers binaires approuvés.
Au moment de la configuration
Lors de la configuration, nous vous recommandons de suivre les conseils ci-dessous :
- Utilisez Container-Optimized OS par défaut comme image de nœud pour GKE. Container-Optimized OS est basé sur Chromium OS et optimisé pour la sécurité des nœuds.
- Activez la mise à niveau automatique des nœuds pour les clusters qui exécutent vos applications. Cette fonctionnalité met automatiquement à niveau le nœud vers la version de Kubernetes qui s'exécute dans le plan de contrôle géré, optimisant ainsi la stabilité et la sécurité.
- Activez la réparation automatique des nœuds. Lorsque cette fonctionnalité est activée, GKE vérifie régulièrement l'état du nœud et l'utilise pour déterminer s'il doit être réparé. Si un nœud doit être réparé, celui-ci est drainé et un autre nœud est créé, puis ajouté au cluster.
- Activez Cloud Monitoring et Cloud Logging pour afficher tous les événements, y compris les événements liés à la sécurité et l'état d'intégrité du nœud. Créez des règles d'alerte Cloud Monitoring afin de recevoir une notification en cas d'incident de sécurité.
- Appliquez des comptes de service avec le moins de privilèges aux nœuds GKE.
- Passez en revue et appliquez, le cas échéant, les instructions de la section GKE du guide Google Cloud CIS Benchmark. La consignation des audits Kubernetes est déjà activée par défaut, et les journaux des requêtes adressées à
kubectlet à l'API GKE sont écrits dans les journaux de Cloud Audit. - Configurez les journaux d'audit.
Protéger les données du compte
La protection des données des titulaires de cartes englobe les exigences 3 et 4 de la norme PCI DSS.
Exigence 3
Protéger les données de compte stockées.
L'exigence 3 de la norme PCI DSS stipule que les techniques de protection telles que le chiffrement, la troncature, le masquage et le hachage constituent des composants essentiels pour la protection des données des titulaires de cartes. Si un intrus contourne d'autres contrôles de sécurité et parvient à accéder aux données chiffrées, sans les clés de chiffrement appropriées, les données lui seront illisibles et inutilisables.
Prenez également connaissance d'autres méthodes de protection des données stockées qui pourraient atténuer les risques potentiels. Par exemple, pour atténuer les risques, vous pourriez éviter de stocker les données des titulaires de cartes sauf en cas de nécessité absolue, tronquer les données des titulaires de cartes si le PAN complet n'est pas nécessaire ou encore ne pas envoyer les PAN non protégés via des technologies de messagerie pour utilisateurs finaux, telles que les e-mail ou la messagerie instantanée.
Voici quelques exemples de systèmes dans lesquels les CHD peuvent persister dans le cadre de vos processus de traitement des paiements lorsqu'ils sont exécutés sur Google Cloud :
- Buckets Cloud Storage
- Instances BigQuery
- Datastore
- Cloud SQL
Notez que les CHD peuvent être stockées par inadvertance dans des journaux de communication via e-mail ou via le service client. Par mesure de prudence, il est conseillé d'utiliser la protection des données sensibles pour filtrer ces flux de données et ainsi limiter votre environnement couvert aux systèmes de traitement des paiements.
Sur Google Cloud, les données sont chiffrées au repos par défaut et chiffrées en transit par défaut lorsqu'elles franchissent les limites physiques. L'activation de ces protections ne nécessite aucune configuration supplémentaire.
Exigence 3.5
Le numéro de compte principal (PAN) est sécurisé partout où il est stocké.
La tokenisation est un procédé permettant de rendre illisibles les données du PAN. Pour en savoir plus, voir le guide de solution Tokeniser des données de titulaire de carte sensibles conformément à la norme PCI DSS.
Vous pouvez vous servir de l'API DLP pour analyser, explorer et signaler des données de titulaire de carte. La protection des données sensibles dispose d'une compatibilité native pour l'analyse et le classement des données PAN de 12 à 19 chiffres dans Cloud Storage, BigQuery et Datastore. Il offre également une API de diffusion de contenu permettant une compatibilité avec des applications, des charges de travail personnalisées et des sources de données supplémentaires. En outre, vous pouvez utiliser l'API DLP pour tronquer (effacer) ou hacher les données.
Exigence 3.6
Les clés cryptographiques utilisées pour protéger les données de compte stockées sont sécurisées.
Le service KMS (Cloud Key Management Service) est un système de stockage géré pour les clés de chiffrement. Il permet de générer, d'utiliser, d'alterner et de détruire des clés de chiffrement. Même si Cloud KMS ne permet pas de stocker directement des secrets, tels que les données des titulaires de cartes, il peut servir à chiffrer ces données.
Les secrets dans le cadre de Kubernetes sont des objets secrets Kubernetes qui vous permettent de stocker et de gérer des informations sensibles, telles que des mots de passe, des jetons et des clés.
Par défaut, Google Cloud chiffre les contenus client stockés au repos. GKE traite et gère ce chiffrement par défaut sans requérir aucune action supplémentaire de votre part. Le chiffrement des secrets au niveau de la couche d'application fournit une couche de sécurité supplémentaire pour les données sensibles telles que les secrets. Cette fonctionnalité vous permet d'utiliser une clé gérée dans Cloud KMS pour chiffrer les données au niveau de la couche d'application. Elle offre une protection contre les pirates informatiques qui réussiraient à accéder à une copie de l'instance de stockage de la configuration Kubernetes de votre cluster.
Exigence 4
Protéger les données des titulaires de cartes avec une cryptographie renforcée lors de la transmission sur des réseaux publics ouverts.
Les données couvertes doivent être chiffrées lors de la transmission effectuée sur des réseaux facilement accessibles (des réseaux publics, par exemple) par des individus malveillants.
Istio est un "service mesh", ou maillage de services, Open Source, qui se superpose de manière transparente aux applications distribuées existantes. Istio gère et adapte l'authentification, l'autorisation et le chiffrement du trafic entre microservices. Il s'agit d'une plate-forme comprenant des API qui vous permettent de vous intégrer à n'importe quelle plate-forme de journalisation, télémétrie ou système de règles. L'ensemble de fonctionnalités d'Istio vous permet de gérer efficacement une architecture de microservices distribuée tout en offrant une méthode uniforme pour sécuriser, connecter et surveiller ces derniers.
Exigence 4.1
Les processus et les mécanismes de protection des données des titulaires de cartes par une cryptographie forte lors de la transmission sur des réseaux ouverts et publics sont définis et documentés.
Istio vous permet de créer un réseau de services déployés, avec l'équilibrage de charge, l'authentification de service à service et la surveillance. Vous pouvez également l'utiliser pour fournir des communications sécurisées de service à service dans un cluster, avec une authentification et une autorisation basées sur le protocole TLS mutuel. Le protocole TLS mutuel (mTLS) est une négociation TLS effectuée deux fois, établissant le même niveau de confiance dans les deux sens (par opposition à une confiance client-serveur unidirectionnelle).
Istio vous permet de déployer des certificats TLS sur chaque pod GKE d'une application. Les services qui s'exécutent sur le pod peuvent se servir de mTLS pour identifier de manière renforcée leurs identités appairées. La communication de service à service est acheminée par un tunnel via des proxys Envoy côté client et côté serveur. Envoy utilise des ID SPIFFE pour établir des connexions mTLS entre les services. Pour en savoir plus sur le déploiement d'Istio sur GKE, reportez-vous à la documentation GKE. Pour plus d'informations sur les versions TLS compatibles, consultez la référence Istio Gestion du trafic. Utilisez TLS version 1.2 ou ultérieure.
Si votre application est exposée à Internet, utilisez l'équilibrage de charge HTTP(S) GKE avec un routage d'entrée configuré pour utiliser HTTP(S). L'équilibrage de charge HTTP(S), configuré par un objet Ingress, comprend les fonctionnalités suivantes :
- Configuration flexible pour les services. Un objet Ingress définit la manière dont le trafic atteint vos services et dont il est acheminé vers votre application. En outre, un objet Entrée peut fournir une adresse IP unique pour plusieurs services de votre cluster.
- Intégration aux services réseau Google Cloud Un objet Ingress peut configurer des fonctionnalités Google Cloud telles que des certificats SSL gérés par Google (version bêta), Google Cloud Armor, Cloud CDN et Identity-Aware Proxy.
- Possibilité d'utiliser plusieurs certificats TLS. Un objet Entrée peut spécifier l'utilisation de plusieurs certificats TLS pour l'arrêt des requêtes.
Lorsque vous créez un objet Ingress, le contrôleur d'entrée GKE crée un équilibreur de charge HTTP(S) Cloud et le configure en fonction des informations spécifiées dans l'objet Ingress et les services associés.
Mettre en place un programme de gestion des failles
La mise en place d'un programme de gestion des failles englobe les exigences 5 et 6 de la norme PCI DSS.
Exigence 5
Protéger l'ensemble des systèmes et des réseaux contre les logiciels malveillants.
L'exigence 5 de la norme PCI DSS stipule que les logiciels antivirus doivent être utilisés sur tous les systèmes couramment affectés par des logiciels malveillants afin de les protéger contre les menaces logicielles actuelles et capables d'évoluer. Les conteneurs ne font pas exception à cette règle.
Exigence 5.2
Les logiciels malveillants (malware) sont bloqués, ou détectés et traités.
Vous devez mettre en œuvre des programmes de gestion des failles pour vos images de conteneur.
Nous vous recommandons d'effectuer les actions suivantes :
- Consultez régulièrement les correctifs de sécurité les plus récents et appliquez-les sur les conteneurs.
- Effectuez des analyses des failles régulières sur applications en conteneurs et les fichiers binaires/bibliothèques.
- Analysez les images comprises dans le pipeline de compilation.
- Abonnez-vous à un service de renseignements sur les failles pour recevoir des informations actualisées sur les failles liées à l'environnement et aux bibliothèques utilisées dans les conteneurs.
Google Cloud collabore avec divers fournisseurs de solutions de sécurité des conteneurs pour améliorer la sécurité au sein des déploiements Google Cloud des clients. Nous vous recommandons d'utiliser des solutions et des technologies de sécurité validées pour augmenter la défense en profondeur de votre environnement GKE. Pour obtenir la liste des partenaires de sécurité validés par Google Cloud, consultez la page Partenaires de sécurité.
Exigence 5.2.2
La ou les solutions anti-logiciels malveillants déployées :
- Détectent tous les types de logiciels malveillants connus.
- Suppriment, bloquent ou contiennent tous les types connus de logiciels malveillants.
Exigence 5.2.3
Tous les composants système qui ne sont pas menacés par des logiciels malveillants font l'objet d'une évaluation périodique qui comprend les éléments suivants :
- Une liste documentée de tous les composants système non menacés par des logiciels malveillants.
- L'identification et l'évaluation de l'évolution des menaces liées aux logiciels malveillants pour ces composants système.
- Confirmation que ces composants système ne nécessitent toujours pas de protection contre les logiciels malveillants.
Il existe de nombreuses solutions disponibles permettant d'effectuer des analyses de logiciels malveillants. Toutefois, la norme PCI DSS reconnaît que tous les systèmes ne sont pas égaux face à la probabilité d'être vulnérables. Souvent, les marchands déclarent que leurs serveurs Linux, leurs mainframes et machines semblables ne sont pas "couramment affectés par les logiciels malveillants", et sont donc exemptés de l'exigence 5.2.2. Dans ce cas, l'exigence 5.2.3 s'applique et vous devez mettre en œuvre un système d'évaluation périodique des menaces.
N'oubliez pas que ces règles s'appliquent aux nœuds et aux pods d'un cluster GKE.
Exigence 5.3
Les mécanismes et processus de protection contre les logiciels malveillants sont actifs et font l'objet d'une surveillance et d'une maintenance.
Les exigences 5.2, 5.3 et 11.5 requièrent des analyses antivirus et la surveillance de l'intégrité des fichiers (FIM) sur tous les hôtes couverts. Nous vous recommandons de mettre en œuvre une solution dans laquelle tous les nœuds peuvent être analysés par un agent approuvé au sein du cluster ou dans laquelle chaque nœud dispose d'un analyseur qui signale jusqu'à un seul point de terminaison de gestion.
Pour en savoir plus, consultez la présentation de la sécurité pour GKE et la présentation de la sécurité pour Container-Optimized OS.
Une solution commune aux exigences relatives aux antivirus et à FIM consiste à verrouiller votre conteneur afin que seuls les dossiers autorisés spécifiques disposent d'un accès en écriture. Pour ce faire, vous exécutez vos conteneurs en tant qu'utilisateur non racine et utilisez des autorisations du système de fichiers pour empêcher tout accès en écriture à tous les répertoires, à l'exception des répertoires de travail, au sein du système de fichiers du conteneur. Désactivez l'élévation des privilèges pour éviter le contournement des règles du système de fichiers.
Exigence 6
Développer et gérer des systèmes et des logiciels sécurisés.
L'exigence 6 de la norme PCI DSS stipule que vous devez mettre en place un cycle de développement logiciel renforcé qui intègre la sécurité à chaque étape de développement.
Exigence 6.2
Les logiciels sur mesure et personnalisés sont développés de manière sécurisée.
Exigence 6.2.1
Les logiciels sur mesure et personnalisés sont développés de manière sécurisée, comme suit :
- Sur la base des normes industrielles et/ou des meilleures pratiques en matière de développement sécurisé.
- Conformément à la norme PCI DSS (par exemple, authentification et journalisation sécurisées).
- En tenant compte des questions de sécurité de l'information à chaque étape du cycle de développement des logiciels.
Vous pouvez utiliser l'autorisation binaire pour garantir que seuls les conteneurs approuvés sont déployés dans GKE. Si vous souhaitez activer uniquement les images autorisées par un ou plusieurs attesteurs spécifiques, vous pouvez configurer une autorisation binaire pour appliquer une stratégie avec des règles nécessitant des attestations basées sur les résultats de l'analyse des failles. Vous pouvez également rédiger des stratégies qui nécessitent l'approbation d'une image par une ou plusieurs parties approuvées (nommées "certificateurs") avant que celle-ci ne soit déployée. Pour un pipeline de déploiement à plusieurs étapes dans lequel les images progressent, de la phase de développement à la phase de tests, en passant par les clusters de production, vous pouvez vous servir des certificateurs pour vous assurer que tous les processus requis sont terminés avant que le logiciel ne passe à l'étape suivante.
Au moment du déploiement, l'autorisation binaire applique votre stratégie en vérifiant que l'image du conteneur respecte toutes les contraintes requises, y compris l'approbation de tous les certificateurs nécessaires au déploiement de l'image. Si l'image satisfait aux exigences, le service autorise son déploiement. Sinon, le déploiement est bloqué jusqu'à ce que l'image soit conforme.
Pour en savoir plus sur l'autorisation binaire, consultez la page Configurer pour GKE.
En cas d'urgence, vous pouvez contourner une stratégie d'autorisation binaire à l'aide du workflow en mode bris de glace. Tous les incidents gérés dans ce mode sont enregistrés dans les journaux d'audit Cloud.
GKE Sandbox réduit le besoin d'interaction directe entre un conteneur et son hôte, ce qui limite la surface d'attaque en cas de compromission de l'hôte et réduit la marge de manœuvre des acteurs malveillants.
Exigence 6.3
Les failles de sécurité sont identifiées et traitées.
Exigence 6.3.1
Les failles de sécurité sont identifiées et gérées comme suit :
- Les nouvelles failles de sécurité sont identifiées à l'aide de sources d'information sur les failles de sécurité reconnues par l'industrie, y-compris les alertes des équipes d'intervention d'urgence informatique (CERT) nationales et internationales.
- Les failles se voient attribuées un niveau de risque sur la base des meilleures pratiques de l'industrie et en tenant compte des répercussions potentielles.
- Les niveaux de risques identifient, au minimum, toutes les failles considérées comme étant à haut risque ou critiques pour l'environnement.
- Les failles concernant les logiciels sur mesure et personnalisés, ainsi que les logiciels tiers (par exemple des systèmes d'exploitation et des bases de données) sont couvertes.
La sécurité dans le cloud est une responsabilité partagée entre le fournisseur cloud et le client.
Dans GKE, Google gère le plan de contrôle, qui inclut les VM maître, le serveur API et les autres composants exécutés sur ces VM, ainsi que la base de données etcd. Cela inclut les mises à jour, les correctifs, le scaling et les réparations, tous ces éléments étant conditionnés par un objectif de niveau de service (SLO). Pour le système d'exploitation des nœuds, tel que Container-Optimized OS ou Ubuntu, GKE effectue rapidement n'importe quel correctif pour ces images disponibles. Si la mise à jour automatique est activée, ces correctifs sont automatiquement déployés. (Il s'agit ici de la couche de base de votre conteneur. Le procédé est différent lorsque le système d'exploitation s'exécute dans vos conteneurs).
Pour en savoir plus sur le modèle de responsabilité partagée de GKE, consultez la page Explorer la sécurité des conteneurs : le modèle de responsabilité partagée dans GKE.
Google offre plusieurs services de sécurité pour aider à intégrer la sécurité dans votre pipeline CI/CD. Pour identifier les failles dans vos images de conteneurs, vous pouvez utiliser l'analyse des failles de Google Artifact Analysis. Lorsqu'une image de conteneur est transférée vers Google Container Registry (GCR), celle-ci est automatiquement analysée. Cela permet de détecter les failles et les vulnérabilités CVE connues. Les failles se voient attribuer des niveaux de gravité (critique, élevé, moyen, faible et minime) en fonction des scores CVSS.
Exigence 6.4
Les applications Web destinées au public sont protégées contre les attaques.
Web Security Scanner vous permet d'analyser les applications Web publiques App Engine, Compute Engine et GKE à la recherche de failles courantes, allant des scripts intersites aux erreurs de configuration, en passant par les ressources vulnérables. Les analyses peuvent être effectuées à la demande et planifiées depuis la console Google Cloud. À l'aide des API Security Scanner, vous pouvez automatiser l'analyse dans le cadre des tests de sécurité compris dans le pipeline de compilation de votre application.
Mettre en œuvre des mesures renforcées pour le contrôle des accès
La mise en œuvre de mesures renforcées pour le contrôle des accès englobe les exigences 7, 8, et 9 de la norme PCI DSS.
Exigence 7
Restreindre l'accès aux composants du système et aux données des titulaires de cartes sur la base du besoin de connaître.
L'exigence 7 se concentre sur le moindre privilège ou sur le besoin de connaître. Cela signifie que la norme PCI DSS accorde l'accès au minimum de données possible et le strict minimum de droits nécessaires à l'exécution de la tâche.
Exigence 7.2
L'accès aux composants du système et aux données est défini et attribué de manière appropriée.
IAM et le contrôle des accès basé sur les rôles Kubernetes (RBAC) collaborent pour offrir un contrôle des accès précis à votre environnement GKE. IAM vous permet de gérer l'accès des utilisateurs et les autorisations d'accès aux ressources Google Cloud dans votre projet CDE. Dans GKE, vous pouvez également utiliser IAM pour gérer l'accès et les actions que les utilisateurs et les comptes de service peuvent effectuer dans vos clusters, comme la création et la suppression de clusters.
Kubernetes RBAC vous permet de configurer des ensembles d'autorisations précis qui définissent la façon dont un utilisateur Google Cloud, des comptes de service Google Cloud ou un groupe d'utilisateurs (Google Groupes) peut interagir avec n'importe quel objet Kubernetes dans votre cluster ou dans un espace de noms spécifique de votre cluster. Parmi les autorisations RBAC, il est possible de modifier des déploiements ou des ConfigMaps, de supprimer des pods ou d'afficher des journaux à partir d'un pod. Vous accordez aux utilisateurs ou aux services des autorisations IAM limitées, telles que le rôle Lecteur de cluster Google Kubernetes Engine ou des rôles personnalisés, puis vous appliquez, le cas échéant, des autorisations Kubernetes RBAC associées à des rôles (RoleBindings).
Cloud Identity Aware Proxy (IAP) peut être intégré via un objet Entrée pour GKE afin de contrôler l'accès au niveau de l'application pour les employés ou les personnes nécessitant un accès à vos applications PCI.
En outre, vous pouvez utiliser les règles de l'organisation pour limiter les API et les services disponibles dans un projet.
Exigence 7.2.2
L'accès est attribué aux utilisateurs, y compris aux utilisateurs privilégiés, en fonction des éléments suivants :
- La classification et la fonction de l'emploi.
- Les moindres privilèges nécessaires à l'exercice des responsabilités professionnelles.
En plus de s'assurer que les utilisateurs et les comptes de service respectent le principe du moindre privilège, vous devez vérifier que c'est également le cas pour les conteneurs. Une bonne pratique lors de l'exécution d'un conteneur consiste à exécuter le processus avec un utilisateur non racine. Vous pouvez appliquer cette pratique à l'aide du contrôleur d'admission PodSecurity.
PodSecurity est un contrôleur d'admission Kubernetes qui vous permet d'appliquer les normes de sécurité des pods aux pods exécutés sur vos clusters GKE. Les normes de sécurité des pods sont des règles de sécurité prédéfinies qui répondent aux besoins de sécurité élevés des pods dans Kubernetes. Ces règles peuvent être de très permissives à très restrictives. PodSecurity remplace l'ancien contrôleur d'admission PodSecurityPolicy qui a été supprimé dans la version 1.25 de Kubernetes. Des instructions sont disponibles pour migrer depuis PodSecurityPolicy vers PodSecurity.
Exigence 8
Identifier les utilisateurs et authentifier l'accès aux composants système
L'exigence 8 stipule qu'un identifiant unique doit être attribué à chaque personne ayant accès aux systèmes PCI couverts afin de s'assurer que chaque individu puisse assumer la responsabilité de ses actes.
Exigence 8.2
L'identification des utilisateurs et les comptes associés pour les utilisateurs et les administrateurs sont strictement gérés tout au long du cycle de vie du compte.
Exigence 8.2.1
Tous les utilisateurs se voient attribuer un identifiant unique avant de pouvoir accéder aux composants système ou aux données des titulaires de cartes.
Exigence 8.2.5
L'accès des utilisateurs dont le compte est clôturé est immédiatement révoqué.
IAM et Kubernetes RBAC peuvent tous les deux servir à contrôler les accès au cluster GKE. Dans les deux cas, vous pouvez accorder des autorisations à un utilisateur. Nous recommandons à vos utilisateurs de s'associer au système d'identité existant pour que vous puissiez gérer les comptes utilisateur et les stratégies dans un seul et même emplacement.
Exigence 8.3
Une authentification forte pour les utilisateurs et les administrateurs est établie et gérée.
Exigence 8.3.1
- Des informations que vous seul connaissez, comme un mot de passe ou une phrase secrète
- Un appareil que vous seul possédez, comme un dispositif de jeton ou une carte à puce
- Un élément d'authentification physique, comme des données biométriques.
Les certificats sont liés à l'identité des utilisateurs lorsqu'ils s'authentifient auprès de kubectl.
Tous les clusters GKE sont configurés pour accepter les comptes d'utilisateur et de service Google Cloud en validant les identifiants et en récupérant l'adresse e-mail associée à l'utilisateur ou au compte de service. Par conséquent, les identifiants de ces comptes doivent inclure le champ d'application OAuth userinfo.email pour que l'authentification puisse réussir.
Exigence 9
Restreindre l'accès physique aux données de titulaire de carte
Google est responsable des contrôles de sécurité physique sur tous les centres de données Google sous-jacents à Google Cloud.
Surveiller et tester régulièrement les réseaux
La surveillance et les tests réguliers des réseaux englobent les exigences 10 et 11 de la norme PCI DSS.
Exigence 10
Journaliser et surveiller tous les accès aux composants système et aux données des titulaires de cartes.
Exigence 10.2
Les journaux d'audit sont mis en œuvre pour permettre la détection d'anomalies et d'activités suspectes, ainsi que pour l'analyse forensique des événements.
La journalisation d'audit Kubernetes est activée par défaut pour les clusters Kubernetes. Elle enregistre de manière chronologique les appels passés vers le serveur d'API Kubernetes. Les entrées du journal d'audit Kubernetes sont utiles pour enquêter sur les demandes d'API suspectes, pour collecter des statistiques ou pour créer des alertes de surveillance pour les appels d'API indésirables.
Les clusters GKE intègrent une configuration par défaut pour la journalisation d'audit GKE avec les journaux d'audit Cloud et Logging. Vous pouvez consulter les entrées du journal d'audit Kubernetes dans votre projet Google Cloud.
Outre les entrées écrites par Kubernetes, les journaux d'audit de votre projet contiennent des entrées écrites par GKE.
Pour différencier vos charges de travail CDE et extérieures au CDE, nous vous recommandons d'ajouter des étiquettes à vos pods GKE, qui s'appliqueront également aux métriques et aux journaux émis à partir de ces charges de travail.
Exigence 10.2.2
- Identification de l'utilisateur
- Type d'événement
- Date et heure
- Information indiquant la réussite ou l'échec
- Origine de l'événement
- Identité ou nom des données, du composant système, de la ressource, ou du service affectés (par exemple, nom et protocole)
Chaque entrée de journal d'audit dans Logging est un objet de type LogEntry qui contient les champs suivants :
- Charge utile, de type
protoPayload. La charge utile de chaque entrée du journal d'audit est un objet de typeAuditLog. Vous trouverez l'identité de l'utilisateur dans le champAuthenticationInfodes objetsAuditLog. - L'événement spécifique, que vous pouvez trouver dans le champ
methodNamedeAuditLog. - Un horodatage.
- État de l'événement, que vous pouvez trouver dans les objets
responsede l'objetAuditLog. - Requête d'opération, que vous pouvez trouver dans les objets
requestetrequestMetadatade l'objetAuditLog. - Le service qui va être exécuté, que vous trouverez dans l'objet
AuditDatadansserviceData.
Exigence 11
Tester régulièrement la sécurité des systèmes et des réseau.
Exigence 11.3
Les failles externes et internes sont régulièrement identifiées, hiérarchisées et traitées.
Exigence 11.3.1
- Au moins une fois tous les trois mois.
- Les failles critiques et à haut risque (selon les classements des risques de faille de l'entité définis à l'Exigence 6.3.1) sont résolues.
- De nouvelles analyses sont réalisées pour confirmer que toutes les failles critiques et à haut risque (comme indiqué ci-dessus) ont été résolues.
- L'outil d'analyse est maintenu à jour pour disposer des informations les plus récentes au sujet des failles.
- Les analyses sont effectuées par du personnel qualifié et le testeur agit en toute indépendance sur le plan organisationnel.
L'analyse des failles d'Artifact Analysis effectue les types d'analyse suivants pour les images de Container Registry :
Analyse initiale. Lorsque vous activez pour la première fois l'API Artifact Analysis, celle-ci analyse vos images dans Container Registry et extrait le gestionnaire de packages, la base d'image et les occurrences de failles des images.
Analyse incrémentielle. Artifact Analysis analyse les nouvelles images au fur et à mesure de leur téléchargement dans Container Registry.
Analyse continue. Lorsque Artifact Analysis reçoit de nouvelles informations et des informations actualisées sur les failles provenant de sources de failles, il réexécute l'analyse des conteneurs pour maintenir à jour la liste des occurrences de failles des images déjà analysées.
Exigence 11.5
Les intrusions sur le réseau et les modifications de fichiers inattendues sont détectées et traitées.
Exigence 11.5.1
- Tout le trafic est surveillé au périmètre du CDE.
- Tout le trafic est surveillé aux points critiques du CDE.
- Le personnel est alerté en cas de suspicion d'intrusion.
- Tous les moteurs de détection et de prévention des intrusions, de même que les références et les signatures, sont tenus à jour.
La Mise en miroir de paquets de Google Cloud peut être utilisée avec Cloud IDS pour détecter les intrusions sur le réseau. La mise en miroir de paquets de Google Cloud transfère tout le trafic réseau de vos VM Compute Engine ou de vos clusters Google Cloud vers une adresse désignée. Cloud IDS peut utiliser ce trafic en miroir pour détecter toute une série de menaces, y compris les tentatives de code d'exploitation, les analyses de port, les dépassements de tampon, la fragmentation du protocole, le trafic de commande et de contrôle (C2), et les logiciels malveillants.
Security Command Center vous offre une visibilité centralisée sur l'état de sécurité des services Google Cloud, y compris GKE, ainsi que sur les éléments de votre organisation tout entière, ce qui vous permet de prévenir, détecter et traiter les menaces plus facilement. Avec Security Command Center, vous êtes averti en cas de détection de menaces à haut risque telles que les logiciels malveillants, le minage de cryptomonnaie, l'accès non autorisé aux ressources Google Cloud, les attaques DDoS sortantes, l'analyse des ports et les attaques par force brute sur SSH, grâce à l'analyse des journaux Cloud Logging.
Mettre en place une stratégie de sécurité de l'information
Une stratégie de sécurité élevée pose les bases concernant la sécurité et indique aux personnes ce qu'on attend de leur part. Dans ce cas, les "personnes" désignent les employés à temps plein et à temps partiel, les employés temporaires, les prestataires et les consultants ayant accès à votre CDE.
Exigence 12
Renforcer la sécurité des informations à l'aide de règles d'administration et de programmes.
Pour en savoir plus sur cette exigence 12, consultez la Matrice de responsabilité partagée PCI de Google Cloud.
Effectuer un nettoyage
Si vous avez utilisé des ressources en suivant cet article (par exemple, si vous avez démarré de nouvelles VM ou utilisé les scripts Terraform), vous pouvez éviter que des frais ne soient facturés sur votre compte Google Cloud en supprimant le projet dans lequel vous avez utilisé ces ressources.
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.
Étape suivante
- Obtenez plus d'informations sur la conformité avec la norme de sécurité des données PCI.
- Essayez le kit de démarrage Terraform.
- Découvrez des architectures de référence, des schémas et des bonnes pratiques concernant Google Cloud. Consultez notre Centre d'architecture cloud.