Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Les meilleures pratiques pour AWS CloudHSM
Appliquez les meilleures pratiques décrites dans cette rubrique pour une utilisation efficace AWS CloudHSM.
Table des matières
Gestion du cluster
Suivez les meilleures pratiques décrites dans cette section lors de la création, de l'accès et de la gestion de votre AWS CloudHSM cluster.
Adaptez votre cluster pour faire face aux pics de trafic
Plusieurs facteurs peuvent influencer le débit maximal que votre cluster peut gérer, notamment la taille de l'instance client, la taille du cluster, la topographie du réseau et les opérations cryptographiques requises pour votre cas d'utilisation.
Pour commencer, reportez-vous à la rubrique AWS CloudHSM Rendement pour obtenir des estimations de performances sur les tailles et configurations de clusters courantes. Nous vous recommandons de tester la charge de votre cluster avec le pic de charge que vous prévoyez afin de déterminer si votre architecture actuelle est résiliente et à la bonne échelle.
Concevez votre cluster pour une haute disponibilité
Ajoutez de la redondance pour tenir compte de la maintenance : vous AWS pouvez remplacer votre HSM pour une maintenance planifiée ou s'il détecte un problème. En règle générale, la taille de votre cluster doit avoir au moins +1 redondance. Par exemple, si vous avez besoin de deux HSM pour que votre service fonctionne aux heures de pointe, la taille idéale de votre cluster sera alors de trois. Si vous suivez les meilleures pratiques en matière de disponibilité, ces remplacements de HSM ne devraient pas avoir d'impact sur votre service. Cependant, les opérations en cours sur le HSM remplacé peuvent échouer et doivent être réessayées.
Répartissez vos HSM sur de nombreuses zones de disponibilité : réfléchissez à la manière dont votre service pourra fonctionner en cas de panne de zone de disponibilité. AWS vous recommande de répartir vos HSM sur autant de zones de disponibilité que possible. Pour un cluster comportant trois HSM, vous devez répartir les HSM sur trois zones de disponibilité. En fonction de votre système, il se peut que vous ayez besoin d'une redondance supplémentaire.
Disposer d'au moins trois HSM pour garantir la durabilité des clés nouvellement générées
Pour les applications qui nécessitent la durabilité des clés nouvellement générées, nous recommandons d'avoir au moins trois HSM répartis dans différentes zones de disponibilité d'une région.
Accès sécurisé à votre cluster
Utilisez des sous-réseaux privés pour limiter l'accès à votre instance : lancez vos HSM et vos instances clientes dans les sous-réseaux privés de votre VPC. Cela limite l'accès à vos HSM depuis le monde extérieur.
Utilisez des points de terminaison VPC pour accéder aux API : le plan de AWS CloudHSM données a été conçu pour fonctionner sans avoir besoin d'accéder à Internet ou aux API AWS. Si votre instance client a besoin d'accéder à l' AWS CloudHSM API, vous pouvez utiliser des points de terminaison VPC pour accéder à l'API sans avoir besoin d'un accès Internet sur votre instance client. Pour plus d’informations, consultez AWS CloudHSM et points de terminaison VPC.
Reconfigurez le protocole SSL pour sécuriser les communications client-serveur : AWS CloudHSM utilise le protocole TLS pour établir une connexion avec votre HSM. Après avoir initialisé votre cluster, vous pouvez remplacer le certificat TLS par défaut et la clé utilisés pour établir la connexion TLS externe. Pour plus d’informations, consultez Améliorez la sécurité de votre serveur Web grâce au déchargement SSL/TLS dans AWS CloudHSM.
Réduisez les coûts en adaptant vos besoins
Il n'y a aucun coût initial d'utilisation AWS CloudHSM. Vous payez un tarif horaire pour chaque HSM que vous lancez jusqu'à ce que vous mettiez fin au HSM. Si votre service ne nécessite pas une utilisation continue de AWS CloudHSM, vous pouvez réduire les coûts en réduisant (en supprimant) vos HSM à zéro lorsqu'ils ne sont pas nécessaires. Lorsque des HSM sont à nouveau nécessaires, vous pouvez restaurer vos HSM à partir d'une sauvegarde. Si, par exemple, votre charge de travail vous oblige à signer du code une fois par mois, en particulier le dernier jour du mois, vous pouvez agrandir votre cluster avant, le réduire en supprimant vos HSM une fois le travail terminé, puis restaurer votre cluster pour effectuer à nouveau les opérations de signature à la fin du mois suivant.
AWS CloudHSM effectue automatiquement des sauvegardes périodiques des HSM du cluster. Lorsque vous ajoutez un nouveau HSM à une date ultérieure, la dernière sauvegarde AWS CloudHSM sera restaurée sur le nouveau HSM afin que vous puissiez reprendre l'utilisation à l'endroit où vous l'avez laissée. Pour calculer vos coûts AWS CloudHSM d'architecture, consultez la section AWS CloudHSM Tarification
Ressources connexes :
Gestion des utilisateurs HSM
Suivez les meilleures pratiques décrites dans cette section pour gérer efficacement les utilisateurs de votre AWS CloudHSM cluster. Les utilisateurs HSM sont distincts des utilisateurs IAM. Les utilisateurs et entités IAM dotés d'une politique basée sur l'identité avec les autorisations appropriées peuvent créer des HSM en interagissant avec les ressources via l'API AWS. Une fois le HSM créé, vous devez utiliser les informations d'identification de l'utilisateur HSM pour authentifier les opérations sur le HSM. Pour un guide détaillé des utilisateurs de HSM, voirGestion des utilisateurs HSM dans AWS CloudHSM.
Protégez les informations d'identification de vos utilisateurs HSM
Il est impératif de protéger de manière sécurisée les informations d'identification de vos utilisateurs HSM, car les utilisateurs HSM sont les entités qui peuvent accéder à votre HSM et effectuer des opérations de cryptographie et de gestion sur celui-ci. AWS CloudHSM n'a pas accès à vos informations d'identification d'utilisateur HSM et ne sera pas en mesure de vous aider si vous perdez l'accès à celles-ci.
Disposer d'au moins deux administrateurs pour empêcher le verrouillage
Pour éviter d'être exclu de votre cluster, nous vous recommandons d'avoir au moins deux administrateurs au cas où un mot de passe d'administrateur serait perdu. Dans ce cas, vous pouvez utiliser l'autre administrateur pour réinitialiser le mot de passe.
Note
Dans le SDK client 5, les administrateurs sont synonymes de responsables du chiffrement (CoS) dans le SDK client 3.
Activer le quorum pour toutes les opérations de gestion des utilisateurs
Le quorum vous permet de définir un nombre minimum d'administrateurs qui doivent approuver une opération de gestion des utilisateurs avant que cette opération puisse avoir lieu. En raison des privilèges dont disposent les administrateurs, nous vous recommandons d'activer le quorum pour toutes les opérations de gestion des utilisateurs. Cela peut limiter l'impact potentiel si l'un de vos mots de passe d'administrateur est compromis. Pour plus d'informations, consultez la section Gestion du quorum.
Créez plusieurs utilisateurs de cryptomonnaies, chacun avec des autorisations limitées
En séparant les responsabilités des utilisateurs de cryptomonnaies, aucun utilisateur n'a le contrôle total de l'ensemble du système. Pour cette raison, nous vous recommandons de créer plusieurs utilisateurs de cryptomonnaies et de limiter les autorisations de chacun. Cela se fait généralement en attribuant aux différents utilisateurs de cryptomonnaies des responsabilités et des actions distinctes qu'ils exécutent (par exemple, un utilisateur de cryptographie est chargé de générer et de partager les clés avec d'autres utilisateurs de cryptomonnaies qui les utilisent ensuite dans votre application).
Ressources connexes :
Gestion des clés HSM
Suivez les meilleures pratiques décrites dans cette section lors de la gestion des clés d'entrée AWS CloudHSM.
Choisissez le bon type de clé
Lorsque vous utilisez une clé de session, vos transactions par seconde (TPS) seront limitées à un HSM où la clé existe. Des HSM supplémentaires dans votre cluster n'augmenteront pas le débit des demandes pour cette clé. Si vous utilisez une clé de jeton pour la même application, vos demandes seront équilibrées entre tous les HSM disponibles dans votre cluster. Pour plus d’informations, consultez Principaux paramètres de synchronisation et de durabilité dans AWS CloudHSM.
Gérez les limites de stockage des clés
Les HSM ont des limites quant au nombre maximum de jetons et de clés de session qui peuvent être stockés simultanément sur un HSM. Pour plus d'informations sur les limites de stockage des clés, consultezAWS CloudHSM quotas. Si votre application requiert une quantité supérieure à la limite, vous pouvez utiliser une ou plusieurs des stratégies suivantes pour gérer efficacement les clés :
Utilisez un encapsulage sécurisé pour stocker vos clés dans un magasin de données externe : grâce à l'encapsulage de clés sécurisé, vous pouvez dépasser la limite de stockage des clés en stockant toutes vos clés dans un magasin de données externe. Lorsque vous devez utiliser cette clé, vous pouvez la déballer dans le HSM en tant que clé de session, utiliser la clé pour l'opération requise, puis supprimer la clé de session. Les données clés d'origine restent stockées en toute sécurité dans votre banque de données pour être utilisées chaque fois que vous en avez besoin. L'utilisation de clés fiables pour ce faire maximise votre protection.
Répartissez les clés entre les clusters : une autre stratégie pour surmonter la limite de stockage des clés consiste à stocker vos clés dans plusieurs clusters. Dans cette approche, vous maintenez un mappage des clés stockées dans chaque cluster. Utilisez ce mappage pour acheminer les demandes de vos clients vers le cluster avec la clé requise. Pour plus d'informations sur la connexion à plusieurs clusters à partir de la même application cliente, consultez les rubriques suivantes :
Gestion et sécurisation de l'emballage des clés
Les clés peuvent être marquées comme extractibles ou non extractibles via l'attribut. EXTRACTABLE Par défaut, les clés HSM sont marquées comme extractibles.
Les clés extractibles sont des clés dont l'exportation depuis le HSM est autorisée par encapsulage de clés. Les clés encapsulées sont chiffrées et doivent être déballées à l'aide de la même clé d'encapsulation avant de pouvoir être utilisées. Les clés non extractibles ne peuvent en aucun cas être exportées depuis le HSM. Il n'existe aucun moyen de rendre extractible une clé non extractible. Pour cette raison, il est important de déterminer si vous avez besoin que vos clés soient extractibles ou non et de définir l'attribut clé correspondant en conséquence.
Si vous avez besoin d'un encapsulage de clés dans votre application, vous devez utiliser un encapsulage de clés sécurisé pour limiter la capacité de vos utilisateurs HSM à encapsuler/déballer uniquement les clés qui ont été explicitement marquées comme fiables par un administrateur. Pour plus d'informations, consultez les rubriques relatives à l'encapsulation de clés fiablesGestion des clés dans AWS CloudHSM.
Ressources connexes
Intégration d'applications
Suivez les meilleures pratiques décrites dans cette section pour optimiser la manière dont votre application s'intègre à votre AWS CloudHSM cluster.
Démarrez votre SDK client
Avant que le SDK client puisse se connecter à votre cluster, celui-ci doit être amorcé. Lorsque vous démarrez des adresses IP vers votre cluster, nous vous recommandons d'utiliser le --cluster-id paramètre dans la mesure du possible. Cette méthode remplit votre configuration avec toutes les adresses IP HSM de votre cluster sans qu'il soit nécessaire de suivre chaque adresse individuelle. Cela renforce la résilience de l'initialisation de votre application en cas de maintenance d'un HSM ou d'une panne de zone de disponibilité. Pour en savoir plus, consultez Amorcez le SDK client.
Authentifiez-vous pour effectuer des opérations
Dans AWS CloudHSM, vous devez vous authentifier auprès de votre cluster avant de pouvoir effectuer la plupart des opérations, telles que les opérations cryptographiques.
Authentification avec la CLI CloudHSM : vous pouvez vous authentifier avec la CLI CloudHSM en utilisant le mode commande unique ou le mode interactif. Utilisez la login commande pour vous authentifier en mode interactif. Pour vous authentifier en mode commande unique, vous devez définir les variables environnementales CLOUDHSM_ROLE etCLOUDHSM_PIN. Pour plus de détails sur cette procédure, reportez-vous àMode commande unique. AWS CloudHSM recommande de stocker en toute sécurité vos informations d'identification HSM lorsque votre application ne les utilise pas.
Authentifiez-vous avec PKCS #11 : Dans PKCS #11, vous vous connectez à l'aide de l'API C_Login après avoir ouvert une session à l'aide de C_. OpenSession Vous n'avez besoin d'effectuer qu'un seul C_Login par slot (cluster). Une fois connecté, vous pouvez ouvrir des sessions supplémentaires à l'aide de C_ OpenSession sans avoir à effectuer d'autres opérations de connexion. Pour des exemples d'authentification auprès de PKCS #11, consultez. Exemples de code pour la bibliothèque PKCS #11
Authentifiez-vous avec JCE : le fournisseur AWS CloudHSM JCE prend en charge les connexions implicites et explicites. La méthode qui vous convient dépend de votre cas d'utilisation. Dans la mesure du possible, nous vous recommandons d'utiliser la connexion implicite, car le SDK gère automatiquement l'authentification si votre application est déconnectée de votre cluster et doit être réauthentifiée. L'utilisation de la connexion implicite vous permet également de fournir des informations d'identification à votre application lorsque vous utilisez une intégration qui ne vous permet pas de contrôler le code de votre application. Pour en savoir plus sur les méthodes de connexion, consultezFournir des informations d'identification au fournisseur JCE.
Authentifiez-vous avec OpenSSL : avec le moteur dynamique OpenSSL, vous fournissez des informations d'identification par le biais de variables d'environnement. AWS CloudHSM recommande de stocker en toute sécurité vos informations d'identification HSM lorsque votre application ne les utilise pas. Dans la mesure du possible, vous devez configurer votre environnement pour récupérer et définir systématiquement ces variables d'environnement sans saisie manuelle. Pour plus de détails sur l'authentification avec OpenSSL, consultez. Installation du moteur dynamique OpenSSL
Gérez efficacement les clés de votre application
Utilisez les attributs clés pour contrôler ce que les clés peuvent faire : lors de la génération d'une clé, utilisez les attributs clés pour définir un ensemble d'autorisations qui autoriseront ou refuseront des types d'opérations spécifiques pour cette clé. Nous recommandons que les clés soient générées avec le moins d'attributs nécessaires pour effectuer leur tâche. Par exemple, une clé AES utilisée pour le chiffrement ne doit pas également être autorisée à extraire des clés du HSM. Pour plus d'informations, consultez nos pages d'attributs pour les SDK clients suivants :
Dans la mesure du possible, mettez en cache les objets clés pour minimiser la latence : les opérations de recherche de clés interrogeront tous les HSM de votre cluster. Cette opération est coûteuse et ne s'adapte pas au nombre de HSM de votre cluster.
Avec PKCS #11, vous pouvez trouver des clés à l'aide de l'
C_FindObjectsAPI.Avec JCE, vous trouvez les clés à l'aide du KeyStore.
Pour des performances optimales, il est AWS recommandé d'utiliser les commandes de recherche de touches (comme findKey etliste des clés) une seule fois au démarrage de l'application et de mettre en cache l'objet clé renvoyé dans la mémoire de l'application. Si vous avez besoin de cet objet clé ultérieurement, vous devez le récupérer de votre cache au lieu de demander cet objet pour chaque opération, ce qui alourdira considérablement les performances.
Utiliser le multi-threading
AWS CloudHSM prend en charge les applications multithread, mais il y a certaines choses à garder à l'esprit en ce qui concerne les applications multithread.
Avec PKCS #11, vous ne devez initialiser la bibliothèque PKCS #11 (appelC_Initialize) qu'une seule fois. Chaque fil doit se voir attribuer sa propre session (C_OpenSession). Il n'est pas recommandé d'utiliser la même session dans plusieurs threads.
Avec JCE, le AWS CloudHSM fournisseur ne doit être initialisé qu'une seule fois. Ne partagez pas les instances d'objets SPI entre les threads. Par exemple, Cipher, Signature, Digest, Mac KeyFactory ou KeyGenerator les objets ne doivent être utilisés que dans le contexte de leur propre thread.
Gérer les erreurs de régulation
Vous pouvez rencontrer des erreurs de régulation HSM dans les circonstances suivantes :
Votre cluster n'est pas correctement dimensionné pour gérer les pics de trafic.
Votre cluster n'est pas dimensionné avec une redondance +1 lors des événements de maintenance.
Les pannes de zone de disponibilité entraînent une réduction du nombre de HSM disponibles dans votre cluster.
Consultez Limitation du HSM pour plus d'informations sur la meilleure façon de gérer ce scénario.
Pour vous assurer que votre cluster est correctement dimensionné et qu'il ne sera pas limité, il est AWS recommandé de tester la charge dans votre environnement en fonction de votre pic de trafic attendu.
Intégrez les nouvelles tentatives sur les opérations du cluster
AWS peut remplacer votre HSM pour des raisons opérationnelles ou de maintenance. Afin de rendre votre application résiliente face à de telles situations, il est AWS recommandé d'implémenter une logique de nouvelle tentative côté client sur toutes les opérations acheminées vers votre cluster. Les tentatives ultérieures portant sur des opérations ayant échoué en raison de remplacements devraient réussir.
Mettre en œuvre des stratégies de reprise après sinistre
En réponse à un événement, il peut être nécessaire de déplacer votre trafic hors d'un cluster ou d'une région dans son ensemble. Les sections suivantes décrivent plusieurs stratégies pour y parvenir.
Utilisez le peering VPC pour accéder à votre cluster depuis un autre compte ou une autre région : vous pouvez utiliser le peering VPC pour accéder à votre AWS CloudHSM cluster depuis un autre compte ou une autre région. Pour plus d'informations sur la façon de configurer cela, consultez Qu'est-ce que le peering VPC ? dans le guide de peering VPC. Une fois que vous avez établi vos connexions d'appairage et configuré vos groupes de sécurité de manière appropriée, vous pouvez communiquer avec les adresses IP HSM de la même manière que vous le feriez normalement.
Connectez-vous à plusieurs clusters à partir de la même application : le fournisseur JCE, la bibliothèque PKCS #11 et la CLI CloudHSM du SDK client 5 prennent en charge la connexion à plusieurs clusters à partir de la même application. Par exemple, vous pouvez avoir deux clusters actifs, chacun situé dans des régions différentes, et votre application peut se connecter aux deux en même temps et équilibrer la charge entre les deux dans le cadre des opérations normales. Si votre application n'utilise pas le SDK client 5 (le dernier SDK), vous ne pouvez pas vous connecter à plusieurs clusters à partir de la même application. Vous pouvez également maintenir un autre cluster opérationnel et, en cas de panne régionale, transférer votre trafic vers l'autre cluster afin de minimiser les temps d'arrêt. Consultez les pages respectives pour plus de détails :
Restaurer un cluster à partir d'une sauvegarde : vous pouvez créer un nouveau cluster à partir de la sauvegarde d'un cluster existant. Pour plus d’informations, consultez Gestion des AWS CloudHSM sauvegardes.
Surveillance
Cette section décrit les différents mécanismes que vous pouvez utiliser pour surveiller votre cluster et votre application. Pour plus de détails sur la surveillance, voirSurveillance AWS CloudHSM.
Surveiller les journaux des clients
Chaque SDK client écrit des journaux que vous pouvez surveiller. Pour plus d'informations sur la journalisation des clients, consultezUtilisation des journaux du SDK client.
Sur les plateformes conçues pour être éphémères, telles qu'Amazon ECS, la collecte des journaux des clients à partir d'un fichier peut s'avérer difficile. AWS Lambda Dans ces situations, il est recommandé de configurer la journalisation de votre SDK client pour écrire des journaux sur la console. La plupart des services collecteront automatiquement ces résultats et les publieront sur Amazon CloudWatch Logs pour que vous puissiez les conserver et les consulter.
Si vous utilisez une intégration tierce en plus du SDK AWS CloudHSM client, vous devez vous assurer de configurer ce package logiciel pour qu'il enregistre également sa sortie sur la console. Dans le cas contraire, la sortie du SDK AWS CloudHSM client peut être capturée par ce package et écrite dans son propre fichier journal.
Consultez le Outil de configuration du SDK client 5 pour savoir comment configurer les options de journalisation dans votre application.
Surveiller les journaux d'audit
AWS CloudHSM publie des journaux d'audit sur votre CloudWatch compte Amazon. Les journaux d'audit proviennent du HSM et permettent de suivre certaines opérations à des fins d'audit.
Vous pouvez utiliser les journaux d'audit pour suivre toutes les commandes de gestion invoquées sur votre HSM. Par exemple, vous pouvez déclencher une alarme lorsque vous remarquez qu'une opération de gestion inattendue est effectuée.
Pour plus d’informations, consultez Fonctionnement de la journalisation d'audit HSM.
Moniteur AWS CloudTrail
AWS CloudHSM est intégré à AWS CloudTrail un service qui fournit un enregistrement des actions entreprises par un utilisateur, un rôle ou un AWS service dans AWS CloudHSM. AWS CloudTrail capture tous les appels d'API AWS CloudHSM sous forme d'événements. Les appels capturés incluent des appels provenant de la AWS CloudHSM console et des appels de code vers les opérations de l' AWS CloudHSM API.
Vous pouvez l'utiliser AWS CloudTrail pour auditer tout appel d'API envoyé au plan de AWS CloudHSM contrôle afin de vous assurer qu'aucune activité indésirable n'a lieu sur votre compte.
Consultez Travailler avec AWS CloudTrail et AWS CloudHSM pour plus de détails.
Surveillez les CloudWatch statistiques d'Amazon
Vous pouvez utiliser CloudWatch les métriques Amazon pour surveiller votre AWS CloudHSM cluster en temps réel. Les métriques peuvent être regroupées par région, ID de cluster ou ID HSM et ID de cluster.
À l'aide CloudWatch des métriques Amazon, vous pouvez configurer les CloudWatch alarmes Amazon pour vous avertir de tout problème potentiel susceptible d'avoir un impact sur votre service. Nous vous recommandons de configurer les alarmes pour surveiller les éléments suivants :
Vous vous approchez de votre limite de clés sur un HSM
Approche de la limite du nombre de sessions HSM sur un HSM
Approche de la limite du nombre d'utilisateurs HSM sur un HSM
Différences dans le nombre d'utilisateurs ou de clés HSM pour identifier les problèmes de synchronisation
HSM défectueux pour faire évoluer votre cluster jusqu'à ce que AWS CloudHSM le problème soit résolu
Pour en savoir plus, consultez Utilisation d'Amazon CloudWatch Logs et AWS CloudHSM d'Audit Logs.
