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.

AWS CloudHSM meilleures pratiques en matière d'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 Connectez-vous à un HSM à l'aide de la CLI CloudHSM 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 pour le SDK AWS CloudHSM client 5

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, consultezÉtape 2 : Fournissez les 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 AWS CloudHSM dynamique OpenSSL pour le SDK client 5

Authentification avec KSP : vous pouvez vous authentifier auprès du fournisseur de stockage de clés (KSP) à l'aide du gestionnaire d'informations d'identification Windows ou de variables d'environnement, voir. Installation du fournisseur de stockage de clés (KSP) pour le SDK AWS CloudHSM client 5

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 le client suivant SDKs :

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.

Pour des performances optimales, il est AWS recommandé d'utiliser les commandes de recherche de touches (comme Rechercher des AWS CloudHSM clés par attributs à l'aide de KMU etRépertorier les clés d'un utilisateur avec la CLI CloudHSM) 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 :

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 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 de plus amples informations, veuillez consulter Sauvegardes en cluster dans AWS CloudHSM.