Opérations internes

Cette rubrique décrit les exigences internes mises en œuvre par le service pour sécuriser les clés des clients et les opérations cryptographiques dans le cadre d'un service de cryptographie et de gestion des clés de paiement évolutif et distribué à l'échelle mondiale.

Spécifications et cycle de vie du HSM

AWS La cryptographie des paiements utilise une flotte de HSM disponibles dans le commerce. Les HSM sont validés par la norme FIPS 140-2 de niveau 3 et utilisent également les versions du microprogramme et la politique de sécurité répertoriée sur la liste des périphériques PCI PTS approuvés par le PCI Security Standards Council en tant que conformes à la norme PCI HSM v3. La norme PCI PTS HSM inclut des exigences supplémentaires pour la fabrication, l'expédition, le déploiement, la gestion et la destruction du matériel HSM, qui sont importantes pour la sécurité et la conformité des paiements, mais qui ne sont pas traitées par la norme FIPS 140.

Tous les HSM fonctionnent en mode PCI et sont configurés selon la politique de sécurité PCI PTS HSM. Seules les fonctions nécessaires pour prendre en charge les cas d'utilisation de la cryptographie des AWS paiements sont activées. AWS La cryptographie des paiements ne permet pas d'imprimer, d'afficher ou de renvoyer des codes PIN en texte clair.

Sécurité physique des appareils HSM

Seuls les HSM dont les clés d'appareil sont signées par une autorité de certification (CA) de cryptographie des AWS paiements (CA) par le fabricant avant la livraison peuvent être utilisés par le service. La cryptographie des AWS paiements est une sous-autorité de certification de l'autorité de certification du fabricant qui est à l'origine de la confiance en ce qui concerne les certificats des fabricants et des appareils HSM. L'autorité de certification du fabricant met en œuvre la norme ANSI TR 34 et a attesté la conformité à l'annexe A de sécurité du code PIN PCI et à l'annexe A de la norme PCI P2PE. Le fabricant vérifie que tous les HSM dotés de clés d'appareil signées par l'autorité de certification de chiffrement des AWS paiements sont expédiés au destinataire désigné par AWS.

Conformément à la norme PCI PIN Security, le fabricant fournit une liste de numéros de série via un canal de communication différent de celui utilisé pour l'expédition du HSM. Ces numéros de série sont vérifiés à chaque étape du processus d'installation du HSM dans les centres de données AWS. Enfin, les opérateurs de chiffrement des AWS paiements valident la liste des HSM installés par rapport à la liste du fabricant avant d'ajouter le numéro de série à la liste des HSM autorisés à recevoir des clés de chiffrement des AWS paiements.

Les HSM sont stockés de manière sécurisée ou font l'objet d'un double contrôle à tout moment, ce qui inclut :

• Expédition par le fabricant vers une installation d'assemblage de racks AWS.

• Pendant le montage du rack.

• Expédition depuis l'installation d'assemblage des racks vers un centre de données.

• Réception et installation dans la salle de traitement sécurisée d'un centre de données. Les racks HSM assurent un double contrôle avec des serrures à accès contrôlé par carte, des capteurs de porte avec alarme et des caméras.

• Pendant les opérations.

• Lors de la mise hors service et de la destruction.

Un compte rendu complet chain-of-custody, assorti d'une responsabilité individuelle, est maintenu et contrôlé pour chaque HSM.

Initialisation du HSM

Un HSM n'est initialisé dans le cadre de la flotte de cryptographie des AWS paiements qu'une fois que son identité et son intégrité ont été validées par des numéros de série, des clés de périphérique installées par le fabricant et une somme de contrôle du microprogramme. Une fois l'authenticité et l'intégrité d'un HSM validées, celui-ci est configuré, notamment en activant le mode PCI. Ensuite, les clés principales de la région de cryptographie des AWS paiements et les clés principales du profil sont établies et le HSM est mis à la disposition du service.

Service et réparation du HSM

Les HSM comportent des composants réparables qui ne nécessitent pas de violation de la limite cryptographique de l'appareil. Ces composants incluent les ventilateurs de refroidissement, les blocs d'alimentation et les batteries. Si un HSM ou un autre périphérique du rack HSM a besoin d'être réparé, le double contrôle est maintenu pendant toute la période d'ouverture du rack.

Mise hors service du HSM

La mise hors service est due à une défaillance end-of-life ou à une défaillance d'un HSM. Les HSM sont logiquement mis à zéro avant d'être retirés de leur rack, s'ils sont fonctionnels, puis détruits dans les salles de traitement sécurisées des centres de données AWS. Ils ne sont jamais renvoyés au fabricant pour réparation, utilisés à d'autres fins ou retirés d'une salle de traitement sécurisée avant d'être détruits.

Mise à jour du microprogramme HSM

Les mises à jour du microprogramme HSM sont appliquées lorsque cela est nécessaire pour maintenir l'alignement avec les versions répertoriées PCI PTS HSM et FIPS 140-2 (ou FIPS 140-3), si une mise à jour est liée à la sécurité ou s'il est déterminé que les clients peuvent bénéficier des fonctionnalités d'une nouvelle version. AWS Les HSM de chiffrement des paiements exécutent le off-the-shelf microprogramme correspondant aux versions répertoriées par PCI PTS HSM. L'intégrité des nouvelles versions du microprogramme est validée avec les versions de microprogramme certifiées PCI ou FIPS, puis leur fonctionnalité est testée avant d'être déployées sur tous les HSM.

Accès de l'opérateur

Les opérateurs peuvent accéder au HSM sans console à des fins de dépannage dans de rares cas où les informations recueillies auprès du HSM au cours des opérations normales ne sont pas suffisantes pour identifier un problème ou planifier une modification. Les étapes suivantes sont exécutées :

• Les activités de dépannage sont développées et approuvées et la session hors console est planifiée.

• Un HSM est supprimé du service de traitement des clients.

• Les touches principales sont supprimées, sous double contrôle.

• L'opérateur est autorisé à accéder au HSM sans console pour effectuer des activités de dépannage approuvées, sous double contrôle.

  • Après la fin de la session hors console, le processus de provisionnement initial est effectué sur le HSM, en renvoyant le microprogramme et la configuration standard, puis en synchronisant la clé principale, avant de renvoyer le HSM au service des clients.

  • Les enregistrements de la session sont enregistrés dans le suivi des modifications.

  • Les informations obtenues lors de la session sont utilisées pour planifier les modifications futures.

Tous les enregistrements d'accès hors console sont examinés pour vérifier la conformité des processus et les modifications potentielles apportées à la surveillance du HSM, au processus de non-console-access gestion ou à la formation des opérateurs.

Gestion des clés

Tous les HSM d'une région sont synchronisés avec une clé principale de région. Une clé principale de région protège au moins une clé principale de profil. Une clé principale de profil protège les clés des clients.

Toutes les clés principales sont générées par un HSM et distribuées par distribution de clés symétrique à l'aide de techniques asymétriques, conformément à la norme ANSI X9 TR 34 et à l'annexe A du code PIN PCI.

Rubriques

• Génération
• Synchronisation des touches principales de la région
• Rotation des clés principales de la région
• Synchronisation des touches principales du profil
• Rotation de la clé principale du profil
• Protection
• Durabilité
• Sécurité des communications
• Gestion des clés clients
• Journalisation et surveillance

Génération

Les clés principales AES 256 bits sont générées sur l'un des HSM fournis pour le parc de services HSM, à l'aide du générateur de nombres aléatoires PCI PTS HSM.

Synchronisation des touches principales de la région

Les clés principales de la région HSM sont synchronisées par le service sur l'ensemble de la flotte régionale avec les mécanismes définis par la norme ANSI X9 TR-34, notamment :

• Authentification mutuelle à l'aide de clés et de certificats de l'hôte de distribution de clés (KDH) et du dispositif de réception de clés (KRD) pour garantir l'authentification et l'intégrité des clés publiques.

• Les certificats sont signés par une autorité de certification (CA) qui répond aux exigences de l'annexe A2 du code PIN PCI, à l'exception des algorithmes asymétriques et des points forts de clé appropriés pour protéger les clés AES 256 bits.

• Identification et protection des clés symétriques distribuées conformément à la norme ANSI X9 TR-34 et à l'annexe A1 du code PIN PCI, à l'exception des algorithmes asymétriques et des atouts de clé appropriés pour protéger les clés AES 256 bits.

Les clés principales de région sont établies pour les HSM qui ont été authentifiés et approvisionnés pour une région par :

• Une clé principale est générée sur un HSM de la région. Ce HSM est désigné comme hôte de distribution des clés.

• Tous les HSM approvisionnés dans la région génèrent un jeton d'authentification KRD, qui contient la clé publique du HSM et des informations d'authentification non rejouables.

• Les jetons KRD sont ajoutés à la liste d'autorisation du KDH une fois que le KDH a validé l'identité et l'autorisation du HSM de recevoir des clés.

• Le KDH produit un jeton de clé principale authentifiable pour chaque HSM. Les jetons contiennent des informations d'authentification KDH et une clé principale cryptée qui ne peut être chargée que sur un HSM pour lequel elle a été créée.

• Chaque HSM reçoit le jeton de clé principal conçu pour lui. Après avoir validé les propres informations d'authentification du HSM et les informations d'authentification KDH, la clé principale est déchiffrée par la clé privée KRD et chargée dans la clé principale.

Dans le cas où un seul HSM doit être resynchronisé avec une région :

• Il est revalidé et approvisionné avec le microprogramme et la configuration.

• S'il s'agit d'un nouveau produit dans la région :

  • Le HSM génère un jeton d'authentification KRD.

  • Le KDH ajoute le jeton à sa liste d'autorisations.

  • Le KDH génère un jeton de clé principal pour le HSM.

  • Le HSM charge la clé principale.

  • Le HSM est mis à la disposition du service.

Cela garantit que :

• Seul le HSM validé pour le traitement AWS de cryptographie des paiements dans une région peut recevoir la clé principale de cette région.

• Seule une clé principale provenant d'un HSM de chiffrement des AWS paiements peut être distribuée à un HSM de la flotte.

Rotation des clés principales de la région

Les clés principales des régions font l'objet d'une rotation à l'expiration de la période de chiffrement, dans le cas peu probable d'une compromission présumée de la clé, ou après des modifications du service dont il est établi qu'elles ont un impact sur la sécurité de la clé.

Une nouvelle clé principale de région est générée et distribuée comme lors du provisionnement initial. Les clés principales du profil enregistrées doivent être converties en la clé principale de la nouvelle région.

La rotation des principales clés de la région n'a aucune incidence sur le traitement des clients.

Synchronisation des touches principales du profil

Les clés principales du profil sont protégées par les clés principales des régions. Cela limite un profil à une région spécifique.

Les clés principales du profil sont configurées en conséquence :

• Une clé principale de profil est générée sur un HSM dont la clé principale de région est synchronisée.

• La clé principale du profil est stockée et cryptée avec la configuration du profil et d'autres contextes.

• Le profil est utilisé pour les fonctions cryptographiques des clients par n'importe quel HSM de la région doté de la clé principale de région.

Rotation de la clé principale du profil

Les clés principales du profil font l'objet d'une rotation à l'expiration de la période de chiffrement, en cas de suspicion de compromission de la clé ou après des modifications du service dont il est établi qu'elles ont un impact sur la sécurité de la clé.

Étapes de rotation :

• Une nouvelle clé principale de profil est générée et distribuée en tant que clé principale en attente, comme lors du provisionnement initial.

• Un processus d'arrière-plan traduit les informations clés du client de la clé principale du profil établie à la clé principale en attente.

• Lorsque toutes les clés du client ont été chiffrées avec la clé en attente, la clé en attente est promue clé principale du profil.

• Un processus en arrière-plan supprime le contenu clé du client protégé par la clé expirée.

La rotation des clés principales du profil n'a aucune incidence sur le traitement des clients.

Protection

Les clés ne dépendent que de la hiérarchie des clés pour la protection. La protection des clés principales est essentielle pour éviter la perte ou la compromission de toutes les clés des clients.

Les clés principales de région peuvent être restaurées à partir d'une sauvegarde uniquement vers un HSM authentifié et provisionné pour le service. Ces clés ne peuvent être stockées que sous forme de jetons de clé principale chiffrés et authentifiables mutuellement provenant d'un KDH spécifique pour un HSM spécifique.

Les clés principales du profil sont stockées avec la configuration du profil et les informations contextuelles chiffrées par région.

Les clés client sont stockées dans des blocs de clés, protégés par une clé principale de profil.

Toutes les clés existent exclusivement dans un HSM ou sont stockées protégées par une autre clé de puissance cryptographique égale ou supérieure.

Durabilité

Les clés client pour la cryptographie des transactions et les fonctions commerciales doivent être disponibles même dans des situations extrêmes susceptibles de provoquer des pannes. AWS La cryptographie des paiements utilise un modèle de redondance à plusieurs niveaux dans les zones de disponibilité et les régions. AWS Les clients qui exigent une disponibilité et une durabilité des opérations cryptographiques de paiement supérieures à celles fournies par le service doivent mettre en œuvre des architectures multirégionales.

L'authentification HSM et les jetons de clé principale sont enregistrés et peuvent être utilisés pour restaurer une clé principale ou synchroniser avec une nouvelle clé principale, dans le cas où un HSM doit être réinitialisé. Les jetons sont archivés et utilisés uniquement sous double contrôle lorsque cela est nécessaire.

Sécurité des communications

Externe

AWS Les points de terminaison de l'API de cryptographie des paiements répondent aux normes de AWS sécurité, notamment le protocole TLS 1.2 ou supérieur et la version 4 de Signature pour l'authentification et l'intégrité des demandes.

Les connexions TLS entrantes sont interrompues sur les équilibreurs de charge réseau et transmises aux gestionnaires d'API via des connexions TLS internes.

Internal (Interne)

Les communications internes entre les composants de service et entre les composants de service et les autres services AWS sont protégées par le protocole TLS à l'aide d'une cryptographie renforcée.

Les HSM se trouvent sur un réseau privé non virtuel accessible uniquement à partir de composants de service. Toutes les connexions entre le HSM et les composants de service sont sécurisées par le protocole TLS mutuel (mTLS), égal ou supérieur au protocole TLS 1.2. Les certificats internes pour TLS et MTL sont gérés par Amazon Certificate Manager à l'aide d'une autorité de certification privée AWS. Les VPC internes et le réseau HSM sont surveillés pour détecter les activités non exceptées et les modifications de configuration.

Gestion des clés clients

Chez AWS, la confiance du client est notre priorité absolue. Vous gardez le contrôle total des clés que vous téléchargez ou créez dans le service sous votre compte AWS et vous êtes responsable de la configuration de l'accès aux clés.

AWS Payment Cryptography est entièrement responsable de la conformité physique du HSM et de la gestion des clés pour les clés gérées par le service. Cela nécessite la propriété et la gestion des clés principales du HSM et le stockage des clés clients protégées dans la base de données de clés AWS de cryptographie des paiements.

Séparation de l'espace clé pour le client

AWS La cryptographie des paiements applique des politiques relatives aux clés pour toutes les utilisations des clés, notamment en limitant les principaux au compte propriétaire de la clé, sauf si une clé est explicitement partagée avec un autre compte.

Sauvegarde et restauration

Les clés et les informations clés d'une région sont sauvegardées dans des archives cryptées par AWS. Les archives nécessitent un double contrôle par AWS pour être restaurées.

Blocs clés

Toutes les clés sont stockées dans des blocs de touches au format ANSI X9 TR-31.

Les clés peuvent être importées dans le service à partir de cryptogrammes ou d'autres formats de blocs de clés pris en charge par ImportKey. De même, les clés peuvent être exportées, si elles sont exportables, vers d'autres formats de blocs de clés ou cryptogrammes pris en charge par les profils d'exportation de clés.

Utilisation des clés

L'utilisation des clés est limitée à celle configurée KeyUsage par le service. Le service échouera à toute demande impliquant une utilisation de clé, un mode d'utilisation ou un algorithme inappropriés pour l'opération cryptographique demandée.

Principales relations d'échange

Les normes PCI PIN Security et PCI P2PE obligent les entreprises qui partagent des clés chiffrant des codes PIN, y compris le KEK utilisé pour partager ces clés, à ne pas les partager avec d'autres organisations. Il est recommandé que les clés symétriques ne soient partagées qu'entre deux parties, y compris au sein d'une même organisation. Cela permet de minimiser l'impact des compromissions présumées qui obligent à remplacer les clés concernées.

Même les analyses de rentabilisation qui nécessitent le partage de clés entre plus de deux parties devraient limiter le nombre de parties au minimum.

AWS La cryptographie des paiements fournit des balises clés qui peuvent être utilisées pour suivre et appliquer l'utilisation des clés conformément à ces exigences.

Par exemple, les clés KEK et BDK de différentes installations d'injection de clés peuvent être identifiées en définissant un « KIF » = « PosStation » pour toutes les clés partagées avec ce fournisseur de services. Un autre exemple serait de marquer les clés partagées avec les réseaux de paiement avec « Network » = « PayCard ». Le balisage vous permet de créer des contrôles d'accès et de créer des rapports d'audit pour appliquer et démontrer vos principales pratiques de gestion.

Suppression de la clé

DeleteKey marque les clés de la base de données en vue de leur suppression après une période configurée par le client. Passé ce délai, la clé est irrémédiablement supprimée. Il s'agit d'un mécanisme de sécurité destiné à empêcher la suppression accidentelle ou malveillante d'une clé. Les touches marquées pour suppression ne sont disponibles que pour aucune action, sauf RestoreKey.

Les clés supprimées restent dans les sauvegardes du service pendant 7 jours après leur suppression. Ils ne sont pas restaurables pendant cette période.

Les clés appartenant à des comptes AWS fermés sont marquées pour suppression. Si le compte est réactivé avant la fin de la période de suppression, toutes les clés marquées pour suppression sont restaurées, mais désactivées. Vous devez les réactiver pour pouvoir les utiliser pour des opérations cryptographiques.

Journalisation et surveillance

Les journaux de service internes incluent :

• CloudTrail journaux des appels de service AWS effectués par le service

• CloudWatch journaux des deux événements directement enregistrés dans les CloudWatch journaux ou des événements depuis HSM

• Fichiers journaux provenant du HSM et des systèmes de service

• Archives du journal

Toutes les sources de journaux surveillent et filtrent les informations sensibles, y compris celles relatives aux clés. Les journaux sont systématiquement revus pour s'assurer qu'ils ne contiennent pas d'informations sensibles sur les clients.

L'accès aux journaux est limité aux personnes nécessaires pour remplir les rôles professionnels.

Tous les journaux sont conservés conformément aux politiques de conservation des journaux d'AWS.