AWS - CloudHSM Enum
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Cloud HSM est un dispositif matériel validé FIPS 140 niveau deux pour le stockage sécurisé des clés cryptographiques (notez que CloudHSM est un appareil matériel, ce n'est pas un service virtualisé). C'est un appareil SafeNetLuna 7000 avec 5.3.13 préchargé. Il existe deux versions de firmware et le choix dépend vraiment de vos besoins exacts. L'une est pour la conformité FIPS 140-2 et il y avait une version plus récente qui peut être utilisée.
La caractéristique inhabituelle de CloudHSM est qu'il s'agit d'un dispositif physique, et donc il n'est pas partagé avec d'autres clients, ou comme on l'appelle couramment, multi-locataire. C'est un appareil dédié à un seul locataire exclusivement mis à disposition pour vos charges de travail.
Typiquement, un dispositif est disponible dans les 15 minutes, à condition qu'il y ait de la capacité, mais dans certaines zones, cela pourrait ne pas être le cas.
Puisqu'il s'agit d'un dispositif physique dédié à vous, les clés sont stockées sur le dispositif. Les clés doivent soit être répliquées sur un autre dispositif, sauvegardées sur un stockage hors ligne, ou exportées vers un appareil de secours. Ce dispositif n'est pas soutenu par S3 ou tout autre service d'AWS comme KMS.
Dans CloudHSM, vous devez scaler le service vous-même. Vous devez provisionner suffisamment de dispositifs CloudHSM pour gérer vos besoins de cryptage en fonction des algorithmes de cryptage que vous avez choisis d'implémenter pour votre solution. Le service de gestion des clés est évolué par AWS et s'adapte automatiquement à la demande, donc à mesure que votre utilisation croît, le nombre d'appareils CloudHSM requis peut également augmenter. Gardez cela à l'esprit lorsque vous évoluez votre solution et si votre solution a un auto-scaling, assurez-vous que votre échelle maximale est prise en compte avec suffisamment d'appareils CloudHSM pour servir la solution.
Tout comme le scaling, la performance dépend de vous avec CloudHSM. La performance varie en fonction de l'algorithme de cryptage utilisé et de la fréquence à laquelle vous devez accéder ou récupérer les clés pour chiffrer les données. La performance du service de gestion des clés est gérée par Amazon et s'adapte automatiquement à la demande. La performance de CloudHSM est obtenue en ajoutant plus d'appareils et si vous avez besoin de plus de performance, vous ajoutez des dispositifs ou modifiez la méthode de cryptage vers l'algorithme qui est plus rapide.
Si votre solution est multi-région, vous devriez ajouter plusieurs appareils CloudHSM dans la deuxième région et établir la connectivité inter-régionale avec une connexion VPN privée ou une méthode pour garantir que le trafic est toujours protégé entre l'appareil à chaque couche de la connexion. Si vous avez une solution multi-région, vous devez réfléchir à la manière de répliquer les clés et de configurer des dispositifs CloudHSM supplémentaires dans les régions où vous opérez. Vous pouvez rapidement vous retrouver dans un scénario où vous avez six ou huit dispositifs répartis sur plusieurs régions, permettant une redondance complète de vos clés de cryptage.
CloudHSM est un service de classe entreprise pour le stockage sécurisé des clés et peut être utilisé comme un racine de confiance pour une entreprise. Il peut stocker des clés privées dans PKI et des clés d'autorité de certification dans des implémentations X509. En plus des clés symétriques utilisées dans des algorithmes symétriques tels que AES, KMS stocke et protège physiquement uniquement les clés symétriques (ne peut pas agir en tant qu'autorité de certification), donc si vous devez stocker des clés PKI et CA, un ou deux ou trois CloudHSM pourraient être votre solution.
CloudHSM est considérablement plus coûteux que le service de gestion des clés. CloudHSM est un appareil matériel, donc vous avez des coûts fixes pour provisionner le dispositif CloudHSM, puis un coût horaire pour faire fonctionner l'appareil. Le coût est multiplié par le nombre d'appareils CloudHSM nécessaires pour atteindre vos exigences spécifiques. De plus, une considération croisée doit être faite lors de l'achat de logiciels tiers tels que les suites logicielles SafeNet ProtectV et le temps et l'effort d'intégration. Le service de gestion des clés est basé sur l'utilisation et dépend du nombre de clés que vous avez et des opérations d'entrée et de sortie. Comme la gestion des clés fournit une intégration transparente avec de nombreux services AWS, les coûts d'intégration devraient être considérablement inférieurs. Les coûts devraient être considérés comme un facteur secondaire dans les solutions de cryptage. Le cryptage est généralement utilisé pour la sécurité et la conformité.
Avec CloudHSM, vous seul avez accès aux clés et sans entrer dans trop de détails, avec CloudHSM, vous gérez vos propres clés. Avec KMS, vous et Amazon co-gestionez vos clés. AWS a de nombreuses protections politiques contre les abus et ne peut toujours pas accéder à vos clés dans l'une ou l'autre solution. La principale distinction est la conformité en ce qui concerne la propriété et la gestion des clés, et avec CloudHSM, il s'agit d'un appareil matériel que vous gérez et maintenez avec un accès exclusif à vous et seulement à vous.
Déployez toujours CloudHSM dans une configuration HA avec au moins deux appareils dans des zones de disponibilité séparées, et si possible, déployez un troisième soit sur site soit dans une autre région chez AWS.
Faites attention lors de l'initialisation d'un CloudHSM. Cette action détruira les clés, donc soit ayez une autre copie des clés, soit soyez absolument sûr que vous n'en aurez pas besoin pour déchiffrer des données.
CloudHSM ne supporte que certaines versions de firmware et de logiciels. Avant d'effectuer une mise à jour, assurez-vous que le firmware et/ou le logiciel est supporté par AWS. Vous pouvez toujours contacter le support AWS pour vérifier si le guide de mise à niveau n'est pas clair.
La configuration réseau ne doit jamais être changée. Rappelez-vous, c'est dans un centre de données AWS et AWS surveille le matériel de base pour vous. Cela signifie que si le matériel échoue, ils le remplaceront pour vous, mais seulement s'ils savent qu'il a échoué.
Le SysLog forward ne doit pas être supprimé ou modifié. Vous pouvez toujours ajouter un forwarder SysLog pour diriger les journaux vers votre propre outil de collecte.
La configuration SNMP a les mêmes restrictions de base que le réseau et le dossier SysLog. Cela ne doit pas être changé ou supprimé. Une configuration SNMP supplémentaire est acceptable, assurez-vous simplement de ne pas changer celle qui est déjà sur l'appareil.
Une autre bonne pratique intéressante d'AWS est de ne pas changer la configuration NTP. Il n'est pas clair ce qui se passerait si vous le faisiez, donc gardez à l'esprit que si vous n'utilisez pas la même configuration NTP pour le reste de votre solution, vous pourriez avoir deux sources de temps. Soyez simplement conscient de cela et sachez que le CloudHSM doit rester avec la source NTP existante.
Le coût initial de lancement pour CloudHSM est de 5 000 $ pour allouer l'appareil matériel dédié à votre usage, puis il y a un coût horaire associé à l'exécution de CloudHSM qui est actuellement de 1,88 $ par heure de fonctionnement, ou environ 1 373 $ par mois.
La raison la plus courante d'utiliser CloudHSM est les normes de conformité que vous devez respecter pour des raisons réglementaires. KMS n'offre pas de support de données pour les clés asymétriques. CloudHSM vous permet de stocker des clés asymétriques en toute sécurité.
La clé publique est installée sur l'appareil HSM lors du provisionnement afin que vous puissiez accéder à l'instance CloudHSM via SSH.
Un module de sécurité matérielle (HSM) est un dispositif cryptographique dédié qui est utilisé pour générer, stocker et gérer des clés cryptographiques et protéger des données sensibles. Il est conçu pour fournir un niveau élevé de sécurité en isolant physiquement et électroniquement les fonctions cryptographiques du reste du système.
Le fonctionnement d'un HSM peut varier en fonction du modèle et du fabricant spécifiques, mais généralement, les étapes suivantes se produisent :
Génération de clés : Le HSM génère une clé cryptographique aléatoire à l'aide d'un générateur de nombres aléatoires sécurisé.
Stockage de clés : La clé est stockée en toute sécurité dans le HSM, où elle ne peut être accessible que par des utilisateurs ou des processus autorisés.
Gestion des clés : Le HSM fournit une gamme de fonctions de gestion des clés, y compris la rotation des clés, la sauvegarde et la révocation.
Opérations cryptographiques : Le HSM effectue une gamme d'opérations cryptographiques, y compris le chiffrement, le déchiffrement, la signature numérique et l'échange de clés. Ces opérations sont effectuées dans l'environnement sécurisé du HSM, ce qui protège contre l'accès non autorisé et la falsification.
Journalisation des audits : Le HSM enregistre toutes les opérations cryptographiques et les tentatives d'accès, qui peuvent être utilisées à des fins de conformité et d'audit de sécurité.
Les HSM peuvent être utilisés pour une large gamme d'applications, y compris les transactions en ligne sécurisées, les certificats numériques, les communications sécurisées et le chiffrement des données. Ils sont souvent utilisés dans des secteurs qui nécessitent un niveau élevé de sécurité, tels que la finance, la santé et le gouvernement.
Dans l'ensemble, le niveau élevé de sécurité fourni par les HSM rend très difficile l'extraction de clés brutes, et tenter de le faire est souvent considéré comme une violation de la sécurité. Cependant, il peut y avoir certaines situations où une clé brute pourrait être extraite par du personnel autorisé à des fins spécifiques, comme dans le cas d'une procédure de récupération de clés.
Apprenez et pratiquez le hacking AWS :HackTricks Formation Expert Red Team AWS (ARTE) Apprenez et pratiquez le hacking GCP : HackTricks Formation Expert Red Team GCP (GRTE)