Exigence 3 : Protéger les données stockées des titulaires de carte

Les exigences détaillées de la présente section sont pertinentes pour HCL Commerce. Examinez chaque point avec soin.

Attention: Pour toute élimination sécurisée des anciens fichiers de base de données (par exemple, à partir des versions précédentes de HCL Commerce) ainsi que d'anciens fichiers clés et d'autres données importantes, vous devez développer une stratégie d'élimination à l'aide d'un ou de plusieurs des outils suivants :
SRM
Utilisez le paramètre -p 7 pour spécifier 7 passes de suppression. SDelete implémente la norme de nettoyage et d'assainissement du ministère de la Défense DOD 5220.22-M, afin que vous soyez certain que, une fois supprimées avec SDelete, vos données de fichier ont disparu pour toujours.
3.1 Réduire au minimum le stockage des données des titulaires de carte en mettant en œuvre des politiques, des procédures et des processus de conservation et d'élimination des données qui incluent au moins les éléments suivants pour le stockage de toutes les données des titulaires de carte (CHD) :
  • Limiter la quantité de données stockées et la durée de conservation à ce qui est requis pour les exigences légales, réglementaires et commerciales.
  • Processus de suppression sécurisée des données lorsqu'elles ne sont plus nécessaires.
  • Exigences spécifiques de conservation pour les données des titulaires de carte.
  • Un processus trimestriel permettant d'identifier et de supprimer en toute sécurité les données des titulaires de carte stockées qui dépassent la durée de conservation définie.

Avec votre administrateur de base de données, vous pouvez établir une planification pour supprimer les anciennes données de paiement avec l'utilitaire DBClean.

3.2 Ne stockez pas de données d'authentification sensibles après autorisation (même si elles sont chiffrées). Si des données d'authentification sensibles sont reçues, restituez toutes les données irrécupérables à la fin du processus d'autorisation.

Les données d'authentification sensibles incluent les données citées dans les exigences 3.2.1 à 3.2.3 suivantes :

3.2.1 Ne stockez pas l'intégralité du contenu d'une piste (qu'elle soit issue de la bande magnétique située au dos d'une carte ou de données équivalentes contenues sur une puce ou ailleurs). Ces données sont alternativement appelées données de piste complètes, de piste, de piste 1, de piste 2 et de bande magnétique.

HCL Commerce par défaut, n'utilise ni ne prend en charge aucun dispositif de lecture de cartes.

3.2.2 Ne stockez pas le code ou la valeur de vérification de la carte (numéro à trois ou quatre chiffres imprimé sur le devant ou au dos d'une carte de paiement) servant à vérifier les transactions sans présentation de la carte.

HCL Commerce stocke temporairement le code de validation de la carte avant l'autorisation du paiement dans les tables ORDPAYINFO et PPCEXTDATA, puis le supprime de la base de données une fois le processus d'autorisation terminé. Si vous autorisez la modification des données existantes du protocole d'instructions de paiement, assurez-vous d'avoir appliqué le correctif APAR JR50683 si vous disposez du groupe de correctifs 8 ou antérieur.

Si vous devez modifier ce comportement, définissez neverPersist sur true dans le fichier PaymentSystemPluginMapping.xml. Cette option capture les données CVV et les envoie pour autorisation de paiement dans une seule transaction. Cela élimine l'étape consistant à stocker temporairement les données CVV dans la base de données.

La configuration de l'option neverPersist dans ce fichier est décrite dans le sujet suivant :
Notes:
  1. Collecter l'authentification sensible uniquement lorsque nécessaire pour résoudre un problème spécifique
  2. Stocker ces données uniquement dans des endroits spécifiques et connus avec un accès limité
  3. Recueillir uniquement la quantité limitée de données nécessaires pour résoudre un problème spécifique
  4. Chiffrer les données d'authentification sensibles stockées
  5. Supprimer ces données immédiatement après leur utilisation.
  6. Il est absolument nécessaire, à des fins de conformité PCI, que vous supprimiez les données historiques stockées par les versions précédentes de HCL Commerce. HCL Commerce utilisant une base de données pour le stockage des données, vous devez utiliser un outil de suppression sécurisé (SDelete ou SRM) pour supprimer vos anciens fichiers de base de données.

3.2.3 Ne stockez pas le numéro d'identification personnel (PIN) ou le bloc PIN chiffré.

HCL Commerce n’enregistre ni ne stocke les numéros PIN.

3.3 Masquer PAN lorsqu'il est affiché (les six premiers et les quatre derniers chiffres sont le nombre maximum de chiffres à afficher), afin que seul le personnel ayant un besoin professionnel légitime puisse voir le PAN complet.
Notes:
  • Cette exigence ne s'applique pas aux employés et aux autres parties ayant un besoin professionnel légitime de voir le PAN complet.
  • Cette exigence ne remplace pas les exigences plus strictes en place pour l'affichage des données des titulaires de carte, pour les reçus de point de vente (POS) par exemple.

HCL Commerce masque les numéros de compte lorsqu'ils sont affichés dans les magasins type, dans Centre de ventes IBM et dans la plupart des panneaux de HCL Commerce Accelerator. Dans certains cas, le PAN est affiché en texte clair pour le personnel administratif autorisé. Si vous avez personnalisé votre vitrine, vos outils d'administration, ou les deux, assurez-vous qu'ils se conforment à l'exigence.

Par défaut, les 5 derniers chiffres du numéro de compte sont affichés en texte brut dans les magasins type. Pour être conforme à PCI, vous devez réduire ce chiffre aux 4 derniers chiffres du numéro de compte. Pour modifier cette valeur, ouvrez le Fichier XML PaymentSystemPluginMapping et faites passer la valeur de l'attribut plain sur l'élément <Keyword name="account" de -5 à -4.

3.4 Rendre le PAN illisible partout où il est stocké (y compris sur les supports numériques portables, les supports de sauvegarde et dans les journaux) en utilisant l'une des approches suivantes :
  • Hachages à sens unique basé sur une cryptographie forte, (le hachage doit concerner l'ensemble du PAN)
  • Troncation (le hachage ne peut pas être utilisé pour remplacer le segment tronqué de PAN)
  • Caractères de remplissage et jetons d'index (les caractères de remplissage doivent être stockés en toute sécurité)
  • Cryptographie robuste avec les processus et procédures de gestion des clés associés.
Note: Il est relativement facile pour une personne malveillante de reconstituer les données originales d'un PAN si elle a accès à la fois à la version tronquée et à la version hachée d'un PAN. Lorsque des versions hachées et tronquées du même PAN sont présentes dans l'environnement d'une entité, des contrôles supplémentaires doivent être mis en place pour garantir que les versions hachées et tronquées ne peuvent pas être corrélées pour reconstruire le PAN d'origine.
HCL Commerce utilise l'algorithme de chiffrement AES-128 bits pour chiffrer les données PAN dans la base de données.
Note: Assurez-vous que l'indicateur PDIEncrypt est activé (il est activé par défaut) dans le fichier de configuration HCL Commerce :

WAS_profiledir/installedApps/instance_name_cell/instance_name.ear/xml/config/wc-server.xml

3.4.1 Si le chiffrement de disque est utilisé (plutôt que le chiffrement de base de données au niveau des fichiers ou des colonnes), l'accès logique doit être géré séparément et indépendamment des mécanismes d'authentification et de contrôle d'accès du système d'exploitation natif (par exemple, en n'utilisant pas les bases de données locales de comptes d'utilisateurs ou les informations d'identification générales de connexion réseau). Les clés de déchiffrement ne doivent pas être associées aux comptes d'utilisateurs..

HCL Commerce n'utilise pas le chiffrement de disque : l'application chiffre les données avant qu'elles soient stockées dans la base de données.

3.5 Documenter et mettre en œuvre des procédures pour protéger les clés utilisées afin de sécuriser les données des titulaires de carte stockées contre la divulgation et l'utilisation abusive :
Note: Cette exigence s'applique aux clés utilisées pour chiffrer les données des titulaires de carte stockées, ainsi qu'aux clés de chiffrement de clés utilisées pour protéger les clés de chiffrement des données.

Le commerçant définit la clé de chiffrement lors de la création de l'instance.

En outre, chaque instance de paiement HCL Commerce nécessite un mot de passe afin de pouvoir déchiffrer toutes les données sensibles stockées dans la base de données. La protection de ce mot de passe est donc essentielle à la protection de la sécurité de vos données de paiement.

Note: Il est absolument nécessaire pour la conformité PCI que vous supprimiez en toute sécurité les anciens fichiers de clés à l'aide d'un outil de suppression sécurisé (SDelete ou SRM).

3.5.1 Restreignez l'accès aux clés cryptographiques au plus petit nombre de dépositaires nécessaire.

Le commerçant est responsable de limiter le nombre de dépositaires.

3.5.2 Stocker les clés secrètes et privées utilisées pour chiffrer/déchiffrer les données des titulaires de carte sous l'une (ou plusieurs) des formes suivantes en tout temps :
  • Chiffrées avec une clé de chiffrement de clés qui est au moins aussi forte que la clé de chiffrement des données, et qui est stockée séparément de la clé de chiffrement des données
  • Dans un périphérique cryptographique sécurisé (tel qu'un module de sécurité hôte - HSM - ou un périphérique de point d'interaction approuvé par PTS)
  • En tant que deux composants (au minimum) de clés complets ou parties de clés, conformément à une méthode acceptée par le secteur
Note: Il n'est pas nécessaire que les clés publiques soient stockées sous l'une de ces formes.

Key Locator Framework (KLF) peut être configuré pour stocker la clé de commerçant (utilisée pour le chiffrement de base de données) dans un fichier externe ou un autre emplacement sécurisé. Une clé de chiffrement de clés peut également être spécifiée pour chiffrer la clé de commerçant dans son emplacement de stockage. Chaque fichier doit être protégé par la protection du système de fichiers et tout autre moyen jugé nécessaire. Pour plus d'informations sur KLF, voir 3.6.6.

3.5.3 Stockez les clés cryptographiques dans le moins d'emplacements possibles.

Il incombe au commerçant de stocker les clés cryptographiques dans le moins d'endroits possible.

3.6 Documenter et implémenter entièrement tous les processus et toutes les procédures de gestion des clés pour les clés cryptographiques utilisées pour le chiffrement des données des titulaires de carte, y compris les éléments suivants :
Note: Les nombreuses normes du secteur pour la gestion des clés sont disponibles à partir de diverses ressources, y compris NIST.

3.6.1 Génération de clés cryptographiques fortes

HCL Commerce utilise le chiffrement AES-128 bits pour chiffrer les données PAN dans la base de données. La clé de chiffrement est fournie par le client et se compose de 32 caractères hexadécimaux. Cette clé de chiffement est appelée « clé de commerçant ». Il est fortement recommandé au commerçant de fournir une clé de commerçant sécurisée en suivant les instructions ci-dessous :

  • Nombre hexadécimal à 16 chiffres
  • Une suite de 32 nombres hexadécimaux est aussi prise en charge.
  • Au moins un caractère alphanumérique (a à f)
  • Au moins un caractère numérique (0 à 9)
  • Impossible d'entrer le même caractère plus de 4 fois d'affilée

Avec l'aide de Key Locator Framework (KLF), la clé peut être stockée dans un fichier. Ce fichier doit être protégé au moyen d'autorisations de fichier appropriées. Un logiciel tiers tel que TripWire peut être utilisé pour surveiller les modifications apportées à ce fichier.

Pour répondre à la norme, vous devez utiliser le plug-in WCExternalFileMerchantKeyImpl fourni par Key Locator Framework. Ce plug-in permet à l'organisation commerciale de partager la connaissance de la clé entre deux dépositaires. Aucun dépositaire de clés ne connaîtra toute la clé de commerçant. Les détails sont documentés dans le lien suivant :

Le plug-in WCExternalFileMerchantKeyImple peut également utiliser une clé de chiffrement pour chiffrer la clé de commerçant. Bien qu'il s'agisse par défaut d'un paramètre facultatif, vous devez spécifier une clé de chiffrement de clés pour répondre aux exigences de PCI DSS. La clé de chiffrement de clés est aussi importante que la clé de commerçant. Lorsqu'une clé de chiffrement de clés est spécifiée, elle doit être aussi forte que la clé de chiffrement. En outre, il est fortement recommandé de fournir une clé de chiffrement de clés qui suit les instructions ci-dessous :

  • Nombre hexadécimal à 16 chiffres
  • Une suite de 32 nombres hexadécimaux est aussi prise en charge.
  • Au moins un caractère alphanumérique (a à f)
  • Au moins un caractère numérique (0 à 9)
  • Impossible d'entrer le même caractère plus de 4 fois d'affilée

3.6.2 Distribution sécurisée des clés cryptographiques

HCL Commerce ne distribue pas ses clés sécurisées dans un environnement non clusterisé. Pour délivrer les clés entre les membres du groupe dans un environnement en cluster, la clé de commerçant et la clé de chiffrement doivent être transférées par deux administrateurs différents, à l'aide d'un programme de transmission sécurisé (tel que SFTP) pour maintenir le contrôle à double clé.
Important: N'utilisez jamais de transmission non sécurisée, comme le FTP, pour transmettre du matériel cryptographique ou d'autres données importantes.

3.6.3 Stockage sécurisé des clés cryptographiques

Configurez KLF pour stocker la clé de commerçant (au format chiffré) dans un fichier externe. Spécifiez une clé de chiffrement dans un fichier distinct, qui est utilisé pour chiffrer la clé de commerçant. Chaque fichier doit être protégé par la protection du système de fichiers. Pour plus d'informations sur KLF, voir 3.6.6.

3.6.4 Modifications des clés cryptographiques pour les clés ayant atteint la fin de leur cryptopériode (par exemple, passé un certain délai défini et/ou après qu'une certaine quantité de texte chiffré a été produite par une clé donnée), comme le définit le fournisseur d'applications associé ou le propriétaire des clés, et conformément aux meilleures pratiques et directives du secteur (par exemple, NIST Special Publication 800-57).

Lorsque des personnes qui connaissent la clé quittent votre organisation de site commerçant, ou si vous soupçonnez qu'une clé a été compromise, HCL Commerce dispose d'un utilitaire pour prendre en charge les changements de clé. Pour plus d'informations, consultez la rubrique utilitaire MigrateEncryptedInfo

Vous pouvez utiliser un nouveau paramètre -interactive pour indiquer que chaque moitié de la clé doit être entrée par un administrateur différent. Cela renforce encore l'exigence en matière de connaissance des clés partagées.

3.6.5 Retrait ou remplacement (par exemple, archivage, destruction et/ou révocation) des clés lorsque cela est jugé nécessaire quand l'intégrité de la clé a été affaiblie (par exemple, le départ d'un employé connaissant un composant de clé en texte clair), ou en cas de soupçon de compromission des clés.
Note: Si les clés cryptographiques retirées ou remplacées doivent être conservées, elles doivent être archivées en toute sécurité (par exemple, à l'aide d'une clé de chiffrement de clés). Les clés cryptographiques archivées ne doivent être utilisées qu'à des fins de déchiffrement/vérification.
La clé est remplacée si vous utilisez l'utilitaire MigrateEncryptedInfo tel que décrit au point 3.6.4.
Note: Utilisez un outil de suppression sécurisé (SDelete ou SRM) pour supprimer du matériel cryptographique ancien ou suspect.
3.6.6 Si des opérations manuelles de gestion des clés cryptographiques en texte clair sont utilisées, ces opérations doivent être gérées à l'aide d'une connaissance fractionnée et d'un double contrôle.
Note: Les exemples d'opérations manuelles de gestion des clés comprennent, sans s'y limiter : la génération, la transmission, le chargement, le stockage et la destruction des clés.

Conformément aux normes de sécurité des données PCI (Payment Card Industry), Key Locator Framework a été intégré pour permettre le stockage et l'extraction d'une clé de chiffrement (par exemple, la clé de commerçant et le mot de passe d'une instance Payments) sur un support configurable, comme un périphérique externe plus sécurisée.

Key Locator Framework offre la souplesse nécessaire pour définir plusieurs clés de chiffrement utilisables par le système et pour extraire chaque clé de chiffrement d'un fournisseur différent. Quatre fournisseurs de clés de chiffrement sont définis par défaut, deux pour la clé de commerçant et deux pour le mot de passe de l'instance Payments.

Pour plus de détails, consultez le manuel Key Locator Framework (KLF)

Pour obtenir un contrôle à double clé, la clé de chiffrement de clés doit être spécifiée et conservée dans un système de fichiers distinct de celui de la clé du commerçant. Aucun utilisateur ne peut avoir accès aux deux systèmes de fichiers où la clé de chiffrement et la clé de commerçant sont stockées. A titre d'exemple, la clé de chiffrement doit être stockée dans un support amovible et le dépositaire du support amovible n'a pas accès au système de fichiers où la clé de commerçant est stockée.
Important: Utilisez les groupes de contrôle d'accès au système d'exploitation pour protéger l'accès aux fichiers de clés et au fichier clé de chiffrement de clés.

3.6.7 Prévention de la substitution non autorisée des clés cryptographiques

Pour empêcher la substitution non autorisée des clés :
  • Veillez à ce que les deux fichiers que vous avez utilisés pour stocker les clés avec Key Locator Framework sont protégés avec les autorisations de fichier appropriées
  • Assurez-vous que les fichiers clés de commerçant sont surveillés par le système de surveillance de l'intégrité des fichiers.

3.6.8 Obligation pour les dépositaires de clés cryptographiques de certifier officiellement qu'ils comprennent et acceptent leurs responsabilités en leur qualité de dépositaires de clés.

Si vous soupçonnez qu'une clé a été compromise, vous devez la modifier comme décrit dans le point 3.6.4.

3.7 Veillez à ce que les politiques de sécurité et les procédures opérationnelles de protection des données des titulaires de cartes stockées soient documentées, utilisées et connues par toutes les parties concernées.

Le commerçant est responsable de la documentation et de la communication des politiques de sécurité et des procédures opérationnelles adressée à toutes les parties concernées.