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 bonnes pratiques en matière d'intégration d'applications

Suivez les bonnes pratiques décrites dans cette section pour optimiser l'intégration de votre application à votre AWS CloudHSM cluster.

Démarrez votre SDK client

Avant que votre SDK client puisse se connecter à votre cluster, il doit être amorcé. Lorsque vous initialisez les adresses IP de 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 avoir à suivre chaque adresse individuelle. Cela renforce la résilience de l'initialisation de votre application en cas de maintenance d'un HSM ou lors 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 son mode de commande unique ou son mode interactif. 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 d'environnement CLOUDHSM_ROLE etCLOUDHSM_PIN. Pour plus de détails à ce sujet, reportez-vous àMode commande unique. AWS CloudHSM recommande de stocker en toute sécurité vos informations d'identification HSM lorsqu'elles ne sont pas utilisées par votre application.

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 que d'un seul C_Login par emplacement (cluster). Une fois connecté avec succès, vous pouvez ouvrir des sessions supplémentaires à l'aide de C_ OpenSession sans avoir à effectuer d'opérations de connexion supplémentaires. Pour des exemples d'authentification auprès de PKCS #11, consultez. Exemples de code pour la bibliothèque PKCS #11 pour AWS CloudHSM SDK client 5

Authentifiez-vous auprès de 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érera 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 via des variables d'environnement. AWS CloudHSM recommande de stocker en toute sécurité vos informations d'identification HSM lorsqu'elles ne sont pas utilisées par votre application. Si 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. Installez le moteur dynamique OpenSSL pour AWS CloudHSM SDK client 5

Authentification auprès de 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  : lorsque vous générez 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 accomplir leur tâche. Par exemple, une clé AES utilisée pour le chiffrement ne doit pas également être autorisée à encapsuler des clés hors 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.

Pour des performances optimales, AWS recommande de n'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) qu'une seule fois lors du démarrage de votre 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 devriez le récupérer dans votre cache au lieu de rechercher cet objet pour chaque opération, ce qui augmenterait considérablement les performances.

Lisez les attributs des objets en un minimum d'appels

La lecture des attributs envoie des requêtes à votre cluster, et le nombre de demandes dépend du SDK que vous utilisez :

Dans les deux cas, mettez les valeurs en cache dans votre application et réutilisez-les jusqu'à ce que quelque chose change l'objet.

Utiliser le multithreading

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 (en appelantC_Initialize) qu'une seule fois. Chaque thread doit se voir attribuer sa propre session (C_OpenSession). Il n'est pas recommandé d'utiliser la même session dans plusieurs fils de discussion.

Avec JCE, le AWS CloudHSM fournisseur ne doit être initialisé qu'une seule fois. Ne partagez pas d'instances d'objets SPI entre les threads. Par exemple, Cipher, Signature, Digest, Mac KeyFactory ou les KeyGenerator objets ne doivent être utilisés que dans le contexte de leur propre fil de discussion.

Gérer les erreurs d'étranglement

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 charger le test dans votre environnement avec le pic de trafic attendu.

Intégrer 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, AWS recommande d'implémenter une logique de nouvelle tentative côté client sur toutes les opérations qui sont acheminées vers votre cluster. Les nouvelles tentatives sur des opérations ayant échoué en raison de remplacements devraient aboutir.

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 entier. 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 VPC Peering Guide. Une fois que vous avez établi vos connexions d'appairage et configuré correctement vos groupes de sécurité, 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 l'interface de ligne de commande CloudHSM du SDK client 5 prennent en charge la connexion à plusieurs clusters depuis 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 depuis 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 d'une sauvegarde d'un cluster existant. Pour de plus amples informations, veuillez consulter Sauvegardes en cluster dans AWS CloudHSM.

Étalez le déploiement de votre application

Suivez des stratégies de déploiement échelonnées telles que les déploiements progressifs basés sur les vagues, les déploiements tout-en-un et les déploiements continus pour les déploiements et les redémarrages de vos applications clientes. Cette approche minimise l'impact potentiel des modifications tout en garantissant une capacité suffisante pour répondre au trafic de production pendant le déploiement.