Sécuriser des données dans un cluster régulé par AKS pour PCI DSS 3.2.1 (partie 4 sur 9)

Cet article décrit les considérations relatives à un cluster Azure Kubernetes Service (AKS) qui exécute une charge de travail en conformité avec la norme de sécurité des données de l’industrie des cartes de paiement (PCI-DSS 3.2.1).

Cet article fait partie d’une série. Lisez l’introduction.

Cette architecture et l’implémentation sont axées sur l’infrastructure, et non sur la charge de travail. Cet article fournit des considérations générales et des bonnes pratiques pour vous aider à prendre des décisions de conception. Suivez les exigences de la norme officielle PCI-DSS 3.2.1 et utilisez cet article en guise de supplément d’informations, le cas échéant.

Protection des données de titulaires de carte

Condition requise 3 : Protéger les données de titulaires de carte stockées

Vos responsabilités

Condition requise 3.1

Garder le stockage de données de titulaires de carte à un niveau minimal en appliquant des stratégies, procédures et processus de conservation et d’élimination des données, qui comprennent au moins les mesures suivantes pour le stockage des données de titulaires de carte (CHD) :

• Limiter la quantité de stockage des données et les délais de conservation selon les conditions imposées par les exigences légales, réglementaires et/ou commerciales
• Des processus pour la suppression sécurisée des données devenues inutiles
• Des conditions de conservation spécifiques pour les données de titulaires de carte
• Un processus trimestriel pour l’identification et la suppression sécurisée des données de titulaires de carte stockées excédant les conditions de conservation définies.

Vos responsabilités

Ne stockez pas l’état dans le cluster AKS. Si vous choisissez de stocker les données de titulaires de carte (CHD), examinez les options de stockage sécurisé. Ces options incluent le Stockage Azure pour le stockage de fichiers, ou des bases de données comme Azure SQL Database ou Azure Cosmos DB.

Respectez strictement les recommandations standard concernant le type de données de titulaires de carte pouvant être stockées. Définissez des stratégies de conservation des données en fonction de vos besoins métier et du type de stockage utilisé. Voici certains principaux éléments à prendre en compte :

• Comment et où sont stockées les données ?
• Les données stockées sont-elles chiffrées ?
• Quelle est la période de conservation ?
• Quelles actions sont autorisées pendant la période de conservation ?
• Comment supprimez-vous les données stockées après l’expiration de la période de conservation ?

Avoir des stratégies de gouvernance concernant certains de ces choix. Les stratégies Azure intégrées appliquent ces choix. Par exemple, vous pouvez restreindre les types de volumes sur les pods de cluster ou refuser les opérations d’écriture sur le système de fichiers racine.

Passez en revue cette liste de définitions de stratégie et appliquez-les au cluster, le cas échéant.

Vous devrez peut-être mettre temporairement les données en cache. Nous vous recommandons de protéger les données mises en cache pendant leur déplacement vers une solution de stockage. Envisagez d’activer la fonctionnalité de chiffrement basé sur l’hôte sur AKS. Les données stockées sur des machines virtuelles de nœud seront alors chiffrées. Pour plus d’informations, consultez Chiffrement basé sur l’hôte sur Azure Kubernetes Service (AKS). Activez également une stratégie Azure intégrée qui exige le chiffrement du cache et des disques temporaires pour les pools de nœuds.

Quand vous choisissez une technologie de stockage, examinez les fonctionnalités de conservation. Par exemple, le Stockage Blob Azure fournit des stratégies de conservation à durée définie. Une autre option consiste à implémenter une solution personnalisée qui supprime les données en fonction de stratégies de conservation. La gestion du cycle de vie des données (DLM), qui gère les activités de cycle de vie des données en est un exemple. La solution a été conçue à l’aide de services comme Azure Data Factory, Microsoft Entra ID et Azure Key Vault.

Pour plus d’informations, consultez Gestion du cycle de vie des données avec Azure Data Factory.

Condition requise 3.2

Ne stocker aucune donnée d’authentification sensible après autorisation (même chiffrée). Si des données d’identification sensibles sont reçues, rendre toutes les données irrécupérables à la fin du processus d’autorisation.

Vos responsabilités

(S’APPLIQUE À : Condition requise 3.2.1, Condition requise 3.2.2, Condition requise 3.2.3)

Le traitement et la protection des données relèvent de la charge de travail et sont en dehors du périmètre de cette architecture. Voici quelques considérations générale.

Conformément à la norme, les données d’authentification sensibles se composent des données de suivi complètes, de la valeur ou du code de validation de la carte, ainsi que des données de code PIN. Dans le cadre du traitement des données de titulaires de carte, vérifiez que les données d’authentification ne sont pas exposées dans des sources telles que les suivantes :

• Journaux émis à partir des pods.
• Routines de gestion des exceptions.
• Noms de fichiers.
• Caches.

En général, les commerçants ne doivent pas stocker ces informations. Si nécessaire, documentez la justification métier.

Condition requise 3.3

Masquer le numéro de compte principal (PAN) quand il s’affiche (les six premiers chiffres et les quatre derniers sont le nombre maximal de chiffres affichés), de manière à ce que seul le personnel ayant un besoin métier légitime puisse voir le numéro de compte principal dans sa totalité.

Vos responsabilités

Le numéro de compte principal (PAN) est considéré comme constituant des données sensibles et l’exposition à ces données doit être évitée. Une façon de le faire consiste à réduire le nombre de chiffres affichés à l’aide du masquage.

N’implémentez pas le masquage des données dans la charge de travail. Au lieu de cela, utilisez des constructions au niveau de la base de données. La gamme de services Azure SQL, dont Azure Synapse Analytics, prend en charge le masquage dynamique des données, ce qui réduit l’exposition au niveau de la couche Application. Il s’agit d’une fonctionnalité de sécurité basée sur des stratégies qui définit qui peut voir les données non masquées et la quantité de données exposées au moyen du masquage. La méthode de masquage de Carte de crédit affiche les quatre derniers chiffres des champs désignés et ajoute une chaîne constante comme préfixe sous la forme d’une carte de crédit.

Pour plus d’informations, consultez Masquage dynamique des données.

Si vous avez besoin d’importer des données non masquées dans votre cluster, masquez-les dès que possible.

Condition requise 3.4

Rendre le numéro de compte principal (PAN) illisible où qu’il soit stocké (notamment sur support numérique portable, sur support de sauvegarde et dans les journaux), en utilisant l’une des approches suivantes :

• Hachage unilatéral s’appuyant sur un chiffrement fort (la totalité du PAN doit être hachée)
• Troncation (le hachage ne peut pas être utilisé pour remplacer le segment tronqué du PAN)
• Jetons et compléments d’index (les compléments doivent être stockés de manière sécurisée)
• Chiffrement fort associée aux processus et procédures de gestion des clés

Vos responsabilités

Pour cette condition requise, vous devrez peut-être utiliser le chiffrement direct dans la charge de travail. Les recommandations concernant PCI DSS conseillent d’utiliser des algorithmes testés par l’industrie pour faire face à des attaques réelles. Évitez d’utiliser des algorithmes de chiffrement personnalisés.

Des techniques de masquage de données appropriées répondent également à cette condition requise. Vous êtes responsable du masquage de toutes les données de numéro de compte principal (PAN). La gamme de services Azure SQL, dont Azure Synapse Analytics, prend en charge le masquage dynamique des données. Consultez la Condition requise 3.3.

Faites en sorte que le numéro de compte principal (PAN) ne soit pas exposé dans le cadre de vos processus de workflow. Voici quelques éléments à prendre en compte :

• Maintenez le numéro de compte principal (PAN) en dehors des journaux, aussi bien des journaux de workflow que des journaux de gestion des exceptions (attendues ou inattendues). De plus, les flux de données de diagnostics, comme les en-têtes HTTP, ne doivent pas exposer ces données.

• N’utilisez pas un numéro de compte principal (PAN) comme clé de recherche dans le cache ou comme partie d’un nom de fichier généré par ce processus.

• Vos clients peuvent fournir un numéro de compte principal dans des champs de texte de forme libre sans invite. Vérifiez que les processus de validation et de détection du contenu sont en place pour tous les champs de texte de forme libre, ce qui nettoie tout le contenu ressemblant à des données de numéro de compte principal (PAN).

Condition requise 3.4.1

Si un chiffrement de disque est utilisé (au lieu d’un chiffrement de base de données au niveau du fichier ou au niveau des colonnes), l’accès logique doit être géré séparément et indépendamment des mécanismes de contrôle d’accès et d’authentification du système d’exploitation natif (par exemple, en n’utilisant pas de bases de données de comptes d’utilisateur locaux, ou des informations d’identification de connexion réseau générales). Les clés de déchiffrement ne doivent pas être associées à des comptes d’utilisateur.

Vos responsabilités

En général, ne stockez pas l’état dans le cluster AKS. Utilisez un stockage de données externe qui prend en charge le chiffrement au niveau du moteur de stockage.

Dans le Stockage Azure, toutes les données sont chiffrées et déchiffrées à l’aide d’un chiffrement fort. Microsoft gère les clés associées. Les clés de chiffrement autogérées sont préférables. Effectuez toujours le chiffrement en dehors de la couche de stockage et écrivez uniquement des données chiffrées sur le support de stockage, en veillant à ce que les clés ne soient jamais à côté de la couche de stockage.

Avec le Stockage Azure, vous pouvez également utiliser des clés autogérées. Pour plus d’informations, consultez Clés gérées par le client pour le chiffrement du service Stockage Azure.

Des fonctionnalités similaires sont disponibles pour les bases de données. Pour connaître les options Azure SQL, consultez Transparent Data Encryption Azure SQL avec une clé gérée par le client.

Assurez-vous de stocker vos clés dans un gestionnaire de clés géré tel qu’Azure Key Vault, Azure Managed HSM, ou une solution de gestion de clés tierce.

Si vous devez stocker des données temporairement, activez la fonctionnalité de chiffrement de l’hôte d’AKS pour garantir que les données stockées sur des nœuds de machine virtuelle sont chiffrées.

Condition requise 3.5

Documenter et implémenter des procédures afin de protéger les clés utilisées pour sécuriser les données de titulaires de carte stockées contre la divulgation et l’utilisation incorrecte :

Vos responsabilités

Ces points sont décrits dans les sous-sections :

• Maintenez la pratique de l’accès selon le principe des privilèges minimum pour les clés de chiffrement.
• Azure Key Vault et Microsoft Entra ID sont conçus pour prendre en charge les exigences d’autorisation et de journalisation des audits. Pour plus d’informations, consultez Demander l’authentification pour Azure Key Vault.
• Protégez toutes les clés de chiffrement de données à l’aide d’une clé de chiffrement de clé stockée dans un appareil de chiffrement.
• Si vous utilisez des clés autogérées (au lieu de clés gérées par Microsoft), vous devez disposer d’un processus et d’une documentation pour tenir à jour les tâches liées à la gestion des clés.

Condition requise 3.5.1

Condition requise supplémentaire applicable aux fournisseurs de services uniquement : Conserver une description documentée de l’architecture de chiffrement qui comprend ce qui suit :

• Détails de tous les algorithmes, protocoles et clés utilisés pour protéger les données de titulaires de carte, y compris la robustesse des clés et la date d’expiration
• Description de l’utilisation de chaque clé
• Inventaire des HSM et autres SCD dans le cadre de la gestion des clés

Vos responsabilités

L’une des méthodes permettant de stocker des informations sensibles (clés, chaînes de connexion, etc.) consiste à utiliser la ressource Kubernetes native Secret. Vous devez explicitement activer le chiffrement au repos. Vous pouvez également les stocker dans un magasin géré, comme Azure Key Vault. Entre les deux approches, nous vous recommandons d’utiliser un service de magasin géré. L’un des avantages est une réduction de la surcharge des tâches liées à la gestion des clés, comme la rotation des clés.

Par défaut, Azure utilise des clés gérées par Microsoft pour toutes les données chiffrées, par client. Toutefois, certains services prennent également en charge les clés autogérées pour le chiffrement. Si vous utilisez des clés autogérées pour le chiffrement au repos, veillez à prendre en compte un processus et une stratégie qui gèrent les tâches de gestion des clés.

Dans le cadre de votre documentation, incluez des informations relatives à la gestion des clés, comme les détails d’expiration, d’emplacement et de plan de maintenance.

Condition requise 3.5.2

Restreindre l’accès aux clés de chiffrement au plus petit nombre d’opérateurs possible.

Vos responsabilités

Réduisez le nombre de personnes qui ont accès aux clés. Si vous utilisez des attributions de rôle basées sur des groupes, configurez un processus d’audit périodique pour passer en revue les rôles qui dispose d’un accès. Quand les membres de l’équipe de projet changent, les autorisations des comptes qui ne sont plus pertinents doivent être supprimées. Seules les bonnes personnes doivent disposer d’un accès. Utilisez les revues d’accès de Microsoft Entra ID pour revoir régulièrement les adhésions aux groupes.

Envisagez de supprimer les autorisations permanentes en faveur des attributions de rôles juste-à-temps (JIT), de l’activation de rôle à durée limitée et de l’activation de rôle basée sur l’approbation. Par exemple, envisagez d’utiliser la gestion des identités privilégiées.

Condition requise 3.5.3

Stocker les clés secrètes et privées utilisées pour chiffrer/déchiffrer les données de titulaires de carte sous une (ou sous plusieurs) des formes suivantes à tout moment :

• Chiffrées avec une clé de chiffrement de clé qui offre une protection au moins aussi forte que la clé de chiffrement de données et qui est stockée séparément de la clé de chiffrement de données
• Au sein d’un périphérique de chiffrement sécurisé (comme un module de sécurité matériel [hôte] [HSM] ou un périphérique de point d’interaction PTS approuvé)
• En tant que deux composants de clé ou partages de clé de pleine longueur au moins, conformément à la méthode acceptée par l’industrie

Vos responsabilités

Une charge de travail PCI DSS 3.2.1 devra utiliser plusieurs clés de chiffrement dans le cadre de la stratégie de protection des données au repos. Une clé de chiffrement de données (DEK) est utilisée pour chiffrer et déchiffrer les données de titulaires de carte (CHD), mais vous êtes responsable d’une clé de chiffrement de clé (KEK) supplémentaire pour protéger cette clé de chiffrement de données. Vous êtes également chargé de garantir que la clé de chiffrement de clé (KEK) est stockée dans un appareil de chiffrement.

Vous pouvez utiliser Azure Key Vault pour stocker la clé de chiffrement de données (DEK) et utiliser Azure Dedicated HSM pour stocker la clé de chiffrement de clé (KEK). Pour plus d’informations sur la gestion des clés HSM, consultez Présentation d’Azure Dedicated HSM.

Condition requise 3.6

Documenter en détail et déployer tous les processus et procédures de gestion des clés de chiffrement servant au chiffrement des données de titulaires de carte, notamment ce qui suit :

Vos responsabilités

(S’APPLIQUE À : Condition requise 3.6.1, Condition requise 3.6.2, Condition requise 3.6.3, Condition requise 3.2.4)

Si vous utilisez Azure Key Vault pour stocker des secrets comme des clés, des certificats et des chaînes de connexion, protégez-le contre tout accès non autorisé. Microsoft Defender pour Key Vault détecte les tentatives d’accès suspectes et génère des alertes. Vous pouvez consulter ces alertes dans Microsoft Defender pour le cloud. Pour plus d’informations, consultez Microsoft Defender pour Key Vault.

Suivez les recommandations du NIST concernant la gestion des clés. Pour plus d’informations, consultez :

• Gestion de clés de chiffrement.
• Publication spéciale 800-133, Révision 2, Recommandations pour la génération de clés de chiffrement
• Publication spéciale 800-57, Partie 1, Révision 5, Recommandations pour la gestion des clés

Consultez également Microsoft Defender pour Key Vault.

Condition requise 3.6.7

Prévention de la substitution non autorisée des clés de chiffrement.

Vos responsabilités

• Activez les diagnostics sur tous les magasins de clés. Utilisez Azure Monitor pour Key Vault. Il collecte les journaux et les métriques, puis les envoie à Azure Monitor. Pour plus d’informations, consultez Supervision de votre service de coffre de clés avec Azure Monitor pour Key Vault.
• Accordez des autorisations en lecture seule à tous les consommateurs.
• N’accordez pas de permissions permanentes aux utilisateurs ou principaux administratifs. Utilisez les attributions de rôles juste-à-temps (JIT), l’activation de rôle à durée limitée et l’activation de rôle basée sur l’approbation.
• Créez une vue centralisée en intégrant des journaux et des alertes à des solutions SIEM, comme Microsoft Sentinel.
• Agissez sur les alertes et les notifications, en particulier sur les changements inattendus.

Condition requise 3.6.8

Condition requise pour les opérateurs chargés de la gestion de clés de chiffrement de confirmer formellement qu’ils comprennent et acceptent leurs responsabilités en tant que telles.

Vos responsabilités

Tenez à jour la documentation qui décrit les responsabilités des parties en charge des opérations de gestion des clés.

Condition requise 3.7

Vérifier que les stratégies de sécurité et les procédures opérationnelles pour la protection des données de titulaires de carte sont documentées, utilisées et connues de toutes les parties concernées.

Vos responsabilités

Créez une documentation qui servira d’instructions générales, ainsi qu’une série de guides de fonctions à jour de toutes les personnes. Créez une formation pour les nouveaux venus et une formation continue.

Il est essentiel de tenir à jour une documentation complète sur les processus et les stratégies. Plusieurs équipes participent à la protection des données au repos et en transit. Dans votre documentation, fournissez des instructions sur les fonctions de toutes les personnes. Les fonctions doivent comprendre l’ingénierie SRE, le support clientèle, les ventes, les opérations réseau, les opérations de sécurité, les ingénieurs logiciels, les administrateurs de base de données, entre autres. Le personnel doit être formé aux recommandations du NIST et aux stratégies de données au repos pour maintenir l’ensemble de compétences à jour. Les exigences de formation sont traitées dans la Condition requise 6.5 et dans la Condition requise 12.6.

Condition requise 4 : Chiffrez la transmission des données des titulaires de carte sur des réseaux ouverts et publics.

Vos responsabilités

Condition requise 4.1

Utiliser des protocoles de chiffrement fort et de sécurité (par exemple, TLS, IPSEC, SSH, etc.) afin de protéger les données de titulaires de carte sensibles pendant leur transmission sur des réseaux publics ouverts, notamment ce qui suit :

Vos responsabilités

Les données de titulaires de carte (CHD) qui transitent sur l’Internet public doivent être chiffrées. Les données doivent être chiffrées avec TLS 1.2 (ou version ultérieure), avec une prise en charge réduite du chiffrement pour toutes les transmissions. Ne prenez pas en charge les redirections non TLS vers TLS sur les services de transmission de données.

Votre conception doit avoir une chaîne stratégique de points de terminaison TLS. Comme les données transitent via les tronçons réseau, maintenez TLS sur les tronçons qui nécessitent un inspection des paquets. Au minimum, le point de terminaison TLS final doit se trouver au niveau de la ressource d’entrée du cluster. Envisagez de le placer plus loin dans les ressources du cluster.

Utilisez Azure Policy pour gérer la création de ressources :

• Interdisez la création d’une ressource d’entrée non HTTPS.
• Interdisez la création d’une adresse IP publique ou d’équilibreurs de charge publics dans votre cluster, afin de garantir que le trafic web est acheminé via votre passerelle.

Pour plus d’informations, consultez Vue d’ensemble du chiffrement Azure.

Condition requise 4.1.1

Garantir que les réseaux sans fil sur lesquels sont transmises les données de titulaires de carte ou qui sont connectés à l’environnement des données de titulaires de carte utilisent les bonnes pratiques du secteur (par exemple, IEEE 802.11i) afin d’implémenter un chiffrement renforcé pour l’authentification et la transmission.

Vos responsabilités

Cette architecture et cette implémentation ne sont pas conçues pour effectuer des transactions entre un réseau local ou d’entreprise et le cloud sur des connexions sans fil. Pour connaître les points à prendre en compte, reportez-vous aux recommandations fournies dans la norme officielle PCI DSS 3.2.1.

Condition requise 4.2

Ne jamais envoyer de numéros de compte principal (PAN) non protégés à l’aide de technologies de messagerie pour les utilisateurs finaux (par exemple, e-mail, messagerie instantanée, SMS, chat, etc.).

Vos responsabilités

Si votre charge de travail nécessite l’envoi d’e-mails, envisagez de créer une porte de quarantaine des e-mails. Cette validation vous donne la possibilité d’analyser la conformité de tous les messages sortants et de vérifier que des données sensibles ne sont pas incluses. Dans l’idéal, vous devez également envisager cette approche pour les messages de support client.

La validation doit être effectuée au niveau de la charge de travail et du processus de contrôle des changements. Les portes d’approbation doivent comprendre la condition requise.

Pour connaître les points à prendre en compte, reportez-vous aux recommandations fournies dans la norme officielle PCI DSS 3.2.1.

Condition requise 4.3

Garantir que les politiques de sécurité et les procédures opérationnelles pour le chiffrement des transmissions des données de titulaires de carte sont documentées, utilisées et connues de toutes les parties concernées.

Vos responsabilités

Il est essentiel de tenir à jour une documentation complète sur les processus et les stratégies. Cela est particulièrement vrai quand vous gérez des stratégies sur le protocole TLS (Transport Layer Security). Voici certains domaines :

• Points d’entrée de l’Internet public. Par exemple, la prise en charge d’Azure Application Gateway pour les chiffrements TLS.
• Tronçons réseau entre un réseau de périmètre et des pods de charge de travail.
• Chiffrement de pod à pod (s’il est implémenté). Cela peut inclure des détails sur la configuration d’un maillage de service.
• D’un pod au stockage (s’il fait partie de l’architecture).
• D’un pod à des services externes, aux services Azure PaaS qui utilisent TLS, à une passerelle de paiement ou à un système de détection des fraudes.

Les personnes qui utilisent des environnements réglementés doivent être sensibilisées, informées et encouragées au moyen d’incentives à prendre en charge les assurances de sécurité. Ceci est particulièrement important pour les personnes qui font partie du processus d’approbation du point de vue de la stratégie.

Étapes suivantes

Protégez tous les systèmes contre les programmes malveillants et mettez à jour régulièrement les logiciels ou programmes antivirus. Développez et tenez à jour des systèmes sécurisés.