nShield Security World

Alors que les équipes de sécurité s’adaptent à l’évolution des mandats de conformité et des exigences en matière de protection des données, l’utilisation du chiffrement continue son accélération. 

Les HSM sont à la base de l’infrastructure informatique moderne. Ils permettent la génération, le stockage et la gestion sécurisés des clés pour les opérations de chiffrement. Mais les cas d’utilisation du chiffrement se multipliant, les entreprises doivent faire évoluer leurs environnements HSM sans augmenter leurs coûts ou la complexité opérationnelle.

Les HSM nShield, qui s’appuient sur l’architecture Security World, fournissent les outils nécessaires pour évoluer tout en optimisant la sécurité et la rentabilité.

Security World permet de gérer les clés d’application sur plusieurs HSM, en alignant de manière cohérente les politiques sans compromettre la sécurité des clés.

Figure 1 : Dans un déploiement Security World, les équipes de sécurité peuvent gérer uniformément des groupes logiques de HSM.

Créer et gérer un Security World

Un domaine Security World est initialisé sur un HSM nShield, qui génère une clé principale et crée un ensemble de cartes à puce connu sous le nom de Set de cartes de l’administrateur (ACS, Administrator Card Set).

L’ACS permet de programmer cette clé principale dans d’autres HSM nShield, les inscrivant ainsi dans le même domaine Security World. Cela permet aux équipes de sécurité :

• d’augmenter la capacité de traitement cryptographique ;
• de remplacer ou de redéployer les HSM si nécessaire.

Ces opérations sensibles nécessitent une autorisation basée sur un quorum par les agents de sécurité munis des identifiants ACS.

L’architecture Security World est dédiée à la sécurité des clés sensibles, y compris les clés utilisées dans les applications des utilisateurs. Les clés d’application peuvent comprendre les éléments suivants :

• Clés de signature privées (ex. : les applications de facturation électronique)
• Clés de protocole TLS/SSL
• Clés de chiffrement symétriques (ex. : le chiffrement des cartes de crédit)
• Clés de racine de confiance Root of Trust (ex. : le chiffrement des bases de données, les autorités de certification PKI)
• Identités des machines
• Clés de gestion des accès privilégiés

Le jeton de clé d’application comprend les catégories de composants suivantes :

Clé

La clé se compose de la clé d’application chiffrée (avec AES 256 bits). Les utilisateurs peuvent choisir la clé de chiffrement à utiliser, ce qui détermine la méthode d’autorisation de la clé d’application.

Certificats et registres d’État

Lorsque les HSM produisent une clé, un certificat de génération de clé est créé et inclus dans le jeton de clé d’application, de même que la clé publique utilisée pour signer le certificat de génération de clé.

Au moment où le HSM génère la clé, son état est enregistré, ce qui permet un enregistrement granulaire du contrôle et de la propriété. Les informations relatives à l’état fournissent une image complète du HSM qui a généré la clé, y compris son identité et sa provenance.

Chaque HSM nShield possède une clé fixe à long terme générée lors de la fabrication du HSM et qui ne changera pas durant toute la durée de vie du HSM. Cette clé signe le message d’état et comprend un certificat ou « mandat » signé par Entrust. La clé qui signe le mandat reste sous le contrôle exclusif d’Entrust, attestant que le HSM qui a généré la clé est un véritable HSM nShield.

Listes de contrôle d’accès (ACL)

Les listes de contrôle d’accès sont un élément essentiel des métadonnées incluses dans le jeton de clé d’application. Dans Security World, plusieurs mécanismes garantissent l’intégrité et la sécurité des listes de contrôle d’accès.

Lorsqu’une clé est générée, la liste de contrôle d’accès associée est encapsulée avec la clé, ce qui garantit qu’elle reste aussi sûre que la clé elle-même. Cette liste de contrôle d’accès reste associée à la clé tout au long de sa durée de vie, ce qui permet une application cohérente de la politique, quel que soit l’endroit où la clé est utilisée.

Il est important de noter que l’application attribue l’ACL au moment de la génération de la clé, et que cette attribution est une opération unique. Une copie chiffrée de la clé à inclure dans le jeton ne peut être créée qu’une seule fois, au cours de la session générant la clé, contribuant ainsi à renforcer la sécurité.

Les ACL définissent ce qu’une clé est autorisée à faire. Ces capacités peuvent comprendre :

• Si la clé peut chiffrer ou déchiffrer
• Si la clé peut encapsuler d’autres clés ou être encapsulée
• Quel est le niveau d’autorisation requis pour des opérations spécifiques

Les listes de contrôle d’accès (ACL) peuvent également être plus ou moins complexes :

• Dans des scénarios simples, elles peuvent permettre des opérations de base telles que le chiffrement des données.
• Dans les configurations avancées, elles peuvent régir les relations hiérarchiques entre les clés, lorsque plusieurs clés doivent être chargées via leurs jetons respectifs avant que certaines opérations ne soient autorisées.

En outre, les listes de contrôle d’accès peuvent imposer des contraintes d’utilisation, telles que :

• des délais d’exécution des opérations ;
• une limitation du nombre d’opérations autorisées.

Grâce aux listes ACL, Security World permet un contrôle granulaire et une sécurité précise sur la façon dont les clés sont utilisées, partagées et gérées.

Jetons d’autorisation

Dans les environnements Security World, les jetons d’autorisation sont utilisés pour contrôler l’accès à des clés d’application spécifiques. Lorsqu’une clé d’application est générée, elle peut être associée à un jeton d’autorisation. Par conséquent, cette clé ne peut être chargée sur un HSM que si le jeton d’autorisation correct est présenté et validé avec succès.

Trois types de jetons d’autorisation existent dans Security World :

1. Jeux de cartes à puce : les jeux de cartes à puce permettent une autorisation multifactorielle basée sur le quorum. Les équipes de sécurité peuvent définir le nombre de cartes à puce nécessaires dans un jeu et combien sont requises pour approuver des actions spécifiques.

Par exemple, dans un environnement comportant cinq cartes à puce d’administrateur, les administrateurs peuvent exiger qu’au moins trois cartes soient présentées pour autoriser l’ajout d’un nouveau HSM au domaine Security World.

Il existe deux catégories de jeux de cartes à puce dans un domaine Security World :

• Sets de cartes de l’administrateur (ACS) : utilisés pour autoriser les tâches administratives, telles que les opérations de reprise après sinistre.
• Sets de cartes de l’opérateur (OCS) : utilisés pour autoriser les HSM à accéder aux clés d’application et à les utiliser.

2. Cartes logicielles : les cartes logicielles sont des jetons basés sur des logiciels qui offrent une autorisation à facteur unique. Elles sont particulièrement utiles dans les environnements où l’accès physique aux lecteurs de cartes à puce HSM n’est pas pratique.

3. Clés protégées par le module : cette option est pratique si vous souhaitez utiliser le HSM pour protéger vos clés. Elle convient aux applications qui doivent fonctionner 24 h/24 et être automatisées, car aucune intervention humaine n’est nécessaire pour utiliser les clés d’application.

Le choix de la méthode d’autorisation des clés (carte à puce, carte logicielle ou clé protégée par un module) s’effectue lors de la création et du stockage de la clé dans Security World.

Politiques d’autorisation personnalisables

Security World offre aux administrateurs une grande souplesse dans la mise en œuvre des politiques d’autorisation d’utilisation des clés :

• Ils peuvent choisir entre la protection OCS et les cartes logicielles pour chaque clé d’application
• Lorsqu’ils utilisent OCS, les administrateurs peuvent configurer :
  • le nombre de cartes dans le set ;
  • les exigences de quorum (combien de cartes doivent être présentes pour autoriser une opération) ;
  • les phrases secrètes pour chaque carte, ou la nécessité d’en exiger ;
  • si les cartes doivent rester insérées dans les lecteurs de cartes à puce des HSM nShield ou si elles peuvent être retirées après utilisation.

Ces fonctionnalités offrent un cadre extrêmement polyvalent et sécurisé pour la mise en œuvre des politiques d’accès aux clés de chiffrement, en conciliant facilité d’utilisation, conformité et contrôles de sécurité rigoureux.

Grâce aux capacités décrites ci-dessus, les clés d’application peuvent être chiffrées, distribuées et stockées en toute sécurité en dehors du HSM, même sur plusieurs HSM, sans compromettre leur sécurité.

En s’appuyant sur des contrôles de politiques robustes, tels que les cartes à puce, les politiques au niveau du HSM, les listes de contrôle d’accès et d’autres mécanismes intégrés, les équipes de sécurité peuvent appliquer des politiques de sécurité uniformes dans l’ensemble de leur environnement, tout en conservant la flexibilité d’appliquer des contrôles granulaires à des HSM, des piles technologiques ou des groupes d’utilisateurs spécifiques, et plus encore.

Dans les environnements Security World, la clé brute reste systématiquement protégée par des HSM nShield certifiés. Lorsque les jetons de clés d’application sont enregistrés sur un support extérieur au HSM, ils peuvent être sauvegardés et restaurés en toute sécurité à l’aide des procédures de sauvegarde standard.

Les applications clientes autorisées peuvent ensuite charger ces jetons sur n’importe quel HSM du même domaine Security World pour effectuer des opérations de chiffrement, ce qui garantit la sécurité, la portabilité et la continuité des opérations.