FAQ sur AWS CloudHSM

Des frais horaires vous seront facturés pour chaque heure (ou heure partielle) où un HSM est alloué à un cluster AWS CloudHSM. Un cluster qui ne contient pas de HSM ne sera pas facturé tout comme vous ne serez pas facturé pour le stockage automatique que nous faisons des sauvegardes chiffrées. Pour plus d'informations, veuillez consulter la page Tarification d'AWS CloudHSM. Notez que les transferts de données réseau vers et depuis vos HSM sont facturés séparément. Pour plus d'informations, consultez les informations relatives à la tarification du transfert de données pour EC2.

Non, il n'existe pas d'offre gratuite disponible pour AWS CloudHSM.

Non. Le tarif horaire, qui varie selon la région, ne dépend pas du volume d'utilisation de votre HSM.

Non, nous ne proposons pas une tarification d'instance réservée pour AWS CloudHSM.

Oui. Pour commencer à utiliser AWS CloudHSM, vous devez disposer de plusieurs éléments, dont notamment un Cloud privé virtuel (VPC) dans la région où vous souhaitez bénéficier du service AWS CloudHSM. Pour en savoir plus, consultez le Guide de l'utilisateur AWS CloudHSM.

Non. AWS gère le microprogramme du matériel. La maintenance du microprogramme est effectuée par un tiers et la conformité à la norme FIPS 140-2 niveau 3 de chaque microprogramme doit être évaluée par le NIST (National Institute of Standards and Technology, l'institut américain des normes et de la technologie). Seuls les microprogrammes qui ont été signés de manière chiffrée à l'aide d'une clé FIPS (à laquelle AWS n'a pas accès) peuvent être installés.

AWS vous recommande fortement d'utiliser au moins deux HSM dans deux zones de disponibilité différentes pour toute charge de travail de production. Pour les charges de travail stratégiques, nous vous recommandons au moins trois HSM dans au moins deux zones de disponibilité différentes. Le client CloudHSM gérera automatiquement toute défaillance d'un HSM et équilibrera les charges vers deux ou plusieurs HSM de manière transparente dans votre application.

AWS effectue quotidiennement des sauvegardes chiffrées automatiques de votre cluster CloudHSM. AWS effectue des sauvegardes supplémentaires lorsque des événements du cycle de vie d'un cluster se produisent (comme l'ajout ou la suppression d'un HSM). Pour la période de 24 heures entre chaque sauvegarde, vous êtes uniquement responsable de la durabilité des éléments de clé créés ou importés vers votre cluster. Nous vous recommandons fortement de vous assurer que chacune des clés créées est synchronisée vers au moins deux HSM dans deux zones de disponibilité différentes pour assurer la durabilité de vos clés. Consultez le Guide de l'utilisateur AWS CloudHSM pour plus d'informations sur la vérification de la synchronisation des clés.

La haute disponibilité est fournie automatiquement lorsque vous possédez au moins deux HSM répartis sur deux zones de disponibilité dans votre cluster CloudHSM. Aucune configuration supplémentaire n'est requise. Dans le cas d'une défaillance d'un HSM dans votre cluster, celui-ci sera remplacé automatiquement et tous les clients seront mis à jour pour refléter la nouvelle configuration sans interrompre toute opération en cours. Des HSM supplémentaires peuvent être ajoutés au cluster via l'API ou le SDK AWS afin d'augmenter la disponibilité sans interrompre votre application.

Un cluster CloudHSM peut contenir jusqu'à 28 HSM, selon les limites de service du compte. Découvrez-en davantage sur les limites de service et sur la façon de demander une augmentation de la limite, consultez notre documentation en ligne.

AWS effectue quotidiennement une sauvegarde de votre cluster CloudHSM. Les clés peuvent également être exportées (« emballées ») hors de votre cluster et stockées sur site tant qu'elles n'ont pas été générées en tant que « non exportables ».

Oui. Vous trouverez l'accord de niveau de service (SLA) pour AWS CloudHSM ici.

Non. Dans le cadre du service, vous obtenez un accès unique à votre HSM. Le matériel sous-jacent peut être partagé avec d'autres utilisateurs, mais l'HSM n'est accessible que par vous.

La séparation des responsabilités et le contrôle d'accès basé sur des rôles sont deux concepts qui ont guidé la conception d'AWS CloudHSM. AWS dispose d'informations d'identification limitées au HSM qui nous permettent de surveiller et de maintenir la santé et la disponibilité du HSM, d'effectuer des sauvegardes chiffrées et d'extraire et de publier des journaux d'audit dans vos CloudWatch Logs. AWS n'a accès à aucune clé ou donnée de votre cluster CloudHSM et ne peut exécuter aucune autre opération que celles autorisées pour un utilisateur d'appliance HSM.

Consultez le guide de l'utilisateur AWS CloudHSM pour de plus amples informations sur la séparation des responsabilités ainsi que sur les possibilités que chaque classe d'utilisateur possède sur le HSM.

Oui. AWS CloudHSM publie différentes mesures Amazon CloudWatch pour les clusters CloudHSM et les HSM individuels. Vous pouvez utiliser la console, l'API ou le SDK Amazon CloudWatch pour consulter ou être alerté de ces mesures.

Chaque HSM dispose d'un générateur déterministe de bits aléatoires (DRBG) alimenté par un générateur de nombres réellement aléatoires (TRNG) au sein du module matériel HSM conforme à la norme SP800-90B.

AWS CloudHSM possède des systèmes de détection des atteintes physiques et logiques et des mécanismes de réponse qui déclenchent la suppression des clés (abrogation) de l'appliance. Le matériel est conçu pour détecter une atteinte si sa barrière physique est rompue. Les HSM sont également protégés contre les tentatives de connexion par force brute. Après un certain nombre d'échecs de tentatives d'accès à un HSM avec des informations d'identification d'administrateur ou de responsable de chiffrement (CO), l'HSM verrouille le CO. De la même manière, après un nombre déterminé de tentatives infructueuses d'accéder à un HSM à l'aide des informations d'identification d'utilisateur de chiffrement (CU), l'utilisateur sera bloqué et devra être débloqué par un CO ou administrateur.

Amazon assure la surveillance et la maintenance de la disponibilité et des conditions d'erreur du HSM et du réseau. Si un HSM rencontre une défaillance ou perd la connectivité au réseau, le HSM sera remplacé automatiquement. Vous pouvez vérifier l'état d'un HSM spécifique par le biais de l'API AWS CloudHSM, des kits SDK ou des outils d'interface de ligne de commande, ainsi que l'état général du service, à tout moment, par le biais d'AWS Service Health Dashboard.

Si votre cluster AWS CloudHSM ne dispose que d'un seul HSM, oui, il est possible de perdre les clés créées depuis la dernière sauvegarde quotidienne. Les clusters AWS CloudHSM comprenant deux ou plusieurs HSM, idéalement dans des zones de disponibilité distinctes, ne perdront pas de clés en cas de défaillance d'un seul HSM. Consultez nos bonnes pratiques pour plus d’informations.

Non. Amazon n'a pas accès à vos clés ni à vos informations d'identification, et ne peut donc pas récupérer vos clés en cas de perte de vos informations d'identification.

AWS CloudHSM repose sur un matériel validé par la norme FIPS (Federal Information Processing Standard) 140-2 de niveau 3. Vous trouverez des informations sur le profil de sécurité FIPS 140-2 pour le matériel utilisé par CloudHSM et le micrologiciel qu’il exécute, sur notre page relative à la conformité.

Oui, CloudHSM fournit des HSM validés par la norme FIPS 140-2 de niveau 3. Vous pouvez suivre la procédure décrite dans le manuel CloudHSM User Guide, à la sectionVerify the Authenticity of Your HSM afin de confirmer que vous disposez d'un HSM authentique sur le même modèle de matériel précisé dans le lien vers la politique de sécurité du NIST figurant ci-dessus.

AWS CloudHSM se trouve toujours en mode FIPS 140-2. Vous pouvez vérifier cette option en utilisant les outils d'interface de ligne de commande (CLI) comme cela est décrit dans le manuel CloudHSM User Guide en exécutant la commande getHsmInfo, qui vous indiquera le statut du mode FIPS.

Oui. AWS CloudTrail enregistre les appels d’API AWS sur votre compte. L'historique des appels d'API AWS généré par AWS CloudTrail vous permet de réaliser une analyse de sécurité, un suivi des modifications au niveau des ressources, ainsi que des audits de conformité. Pour en savoir plus sur AWS CloudTrail, consultez la page de présentation d'AWS CloudTrail et, pour l'activer, utilisez la Console de gestion AWS de CloudTrail.

AWS CloudTrail n'inclut ni les appareils HSM ni les journaux d'accès. Ceux-ci apparaissent directement dans votre compte AWS via les AWS CloudWatch Logs. Pour en savoir plus, consultez Guides de l'utilisateur AWS CloudHSM.

Reportez-vous au site Conformité AWS pour en savoir plus sur les programmes de conformité couvrant CloudHSM. Contrairement aux autres services AWS, les exigences de conformité concernant AWS CloudHSM sont souvent remplies directement par la validation FIPS 140-2 niveau 3 du matériel lui-même plutôt qu'en tant que programme d'audit séparé.

La certification FIPS 140-2 niveau 3 est exigée dans certains cas d'utilisation, notamment la signature de documents, le paiement ou lorsque vous utilisez HSM comme autorité de certification publique pour des certificats SSL.

Pour voir quels rapports de conformité couvrent le service AWS CloudHSM, consultez les données sur la page Services AWS concernés par le programme de conformité. Pour créer des rapports de conformité à la demande, en libre-service et gratuits, utilisez AWS Artifact.

Si vous êtes simplement intéressé par la validation FIPS pour les HSM fournis par AWS CloudHSM, consultez Validation FIPS.

Les performances peuvent varier en fonction de la configuration, de la taille des données et de la charge applicative supplémentaire sur vos instances EC2. Pour améliorer les performances, vous pouvez ajouter des instances HSM supplémentaires à vos clusters. Nous vous encourageons à tester la charge de votre application afin de déterminer les besoins de mise à l'échelle.

Pour plus de détails, consultez la page sur les performances du guide de l'utilisateur d'AWS CloudHSM.

Pour plus d'informations sur le stockage des clés et la capacité du cluster, consultez la section Quotas AWS CloudHSM.

Pas directement. Vous devez utiliser AWS Key Management Service avec le stockage de clés personnalisé pour sécuriser les données Amazon RDS à l'aide des clés générées et stockées dans votre cluster CloudHSM.

Plusieurs fournisseurs tiers prennent en charge AWS CloudHSM en tant que racine de confiance. Vous pouvez donc utiliser une solution logicielle de votre choix tout en créant et en stockant les clés sous-jacentes dans votre cluster CloudHSM.

Le client AWS CloudHSM est un package logiciel fourni par AWS qui permet à vous et à vos applications d'interagir avec les clusters CloudHSM.

Non. Toutes les communications entre le client et votre HSM sont chiffrées de bout en bout. AWS ne peut pas voir ni intercepter ces communications, et n'a pas non plus de visibilité sur vos identifiants d'accès au cluster.

Pour le découvrir, consultez le Guide de l'utilisateur CloudHSM.

Non. Les outils CloudHSM communiquent directement avec votre cluster CloudHSM par l'intermédiaire de la bibliothèque du client CloudHSM sur un canal sécurisé à authentification mutuelle. AWS ne peut observer aucune communication entre le client, les outils et le HSM. Il est chiffré de bout en bout.

Vous trouverez une liste complète des systèmes d'exploitation pris en charge dans notre documentation en ligne.

L'hébergeur sur lequel vous exécutez la bibliothèque du client CloudHSM et/ou utilisez les outils CLI doit disposer de l'accessibilité au réseau pour l'ensemble des HSM de votre cluster CloudHSM.

Vous pouvez créer, modifier, supprimer et obtenir le statut des clusters CloudHSM et des HSM. Les tâches que vous pouvez effectuer avec l'API AWS CloudHSM sont limitées par les opérations qu'AWS peut réaliser avec son accès restreint. L'API ne peut pas accéder aux contenus du HSM ou modifier tout utilisateur, stratégie ou tout autre réglage. Pour plus d’informations sur l’API, consultez la documentation CloudHSM. Pour plus d’informations sur le kit SDK, consultez la page Outils pour Amazon Web Services.

Commencez par veiller à ce que les algorithmes et modes nécessaires soient pris en charge par AWS CloudHSM. Votre responsable de compte peut nous envoyer des demandes de fonctionnalités si besoin. Ensuite, déterminez votre stratégie de rotation de clés. Nous avons également publié un guide de migration approfondi pour AWS CloudHSM. Vous êtes désormais prêt à démarrer avec AWS CloudHSM.

Votre stratégie de rotation dépendra du type d'application. Voici quelques exemples courants.

• Clés privées pour la signature : en général, une clé privée sur le HSM correspond à un certificat intermédiaire à son tour signé par une racine d'entreprise hors ligne. Vous procéderez à la rotation des clés en émettant un nouveau certificat intermédiaire. Créez une nouvelle clé privée et générez le CSR correspondant à l'aide d'OpenSSL sur AWS CloudHSM. Ensuite, signez le CSR avec la même racine d'entreprise hors ligne. Il se peut que vous ayez à enregistrer ce nouveau certificat avec des partenaires qui ne vérifient pas automatiquement la totalité de la chaine de certificat. En poursuivant, vous signerez toutes les nouvelles demandes (pour des documents, du code ou d'autres certificats, par exemple) avec la nouvelle clé privée qui correspondra au nouveau certificat. Vous pouvez continuer de vérifier des signatures à partir de la clé privée originale avec la clé publique correspondante. Aucune révocation n'est nécessaire. Ce processus est analogue à celui qu'il faut suivre pour retirer ou archiver un clé de signature.
• Chiffrement transparent des données Oracle : vous pouvez transférer votre portefeuille en passant d'abord d'un magasin de clés matériel (votre HSM d'origine) à un magasin de clés logiciel, puis en revenant à un magasin de clés matériel (AWS CloudHSM). Remarque : si vous utilisez Amazon RDS, consultez les FAQ ci-dessus concernant la question « AWS CloudHSM prend-il en charge Amazon RDS Oracle TDE ? »
• Clé symétrique pour le chiffrement d'enveloppes : le chiffrement d'enveloppes fait référence à l'architecture de clés dans laquelle une clé du HSM chiffre/déchiffre plusieurs clés de données sur l'hôte de l'application. Vous disposez certainement déjà d'un processus de rotation de clés pour le transfert et le déchiffrement de clés de données avec l'ancienne clé d'assemblage, ainsi que pour leur rechiffrement avec la nouvelle clé d'assemblage. La seule différence lors de la migration résidera dans la nouvelle clé d'assemblage qui sera créée et utilisée sur AWS CloudHSM et non sur le HSM d'origine. Si vous n'avez pas déjà d'outil ou de processus de rotation de clés, vous devrez en créer un.

Chaque application et chaque cas d'utilisation sont différents. Vous trouverez des solutions aux scénarios les plus courants dans le guide de migration de CloudHSM. Si vous avez d'autres questions, ouvrez un cas d'assistance en indiquant les détails de votre application, le type de HSM que vous utilisez actuellement, le type de clés que vous utilisez et si ces clés peuvent être exportées ou non. Nous vous aiderons à déterminer une voie de migration appropriée.

Non, mais il est possible qu'AWS doive effectuer une maintenance en cas de mises à jour nécessaires ou de matériel défectueux. Nous ferons tout notre possible pour vous informer à l'avance, par le biais du Personal Health Dashboard, des éventuelles répercussions.

Notez qu'il est de votre responsabilité de concevoir votre cluster pour assurer une haute disponibilité. AWS vous recommande fortement d'utiliser des clusters CloudHSM comportant deux HSM, voire plus, dans des zones de disponibilité séparées. Reportez-vous aux bonnes pratiques recommandées de notre documentation en ligne.

Vous pouvez trouver des solutions aux problèmes courants dans notre guide de dépannage. Si votre problème persiste, contactez AWS Support.