Pour afficher l’article en anglais, activez la case d’option Anglais. Vous pouvez aussi afficher la version anglaise dans une fenêtre contextuelle en faisant glisser le pointeur de la souris sur le texte.
Traduction
Anglais

Sécurisation de l’infrastructure à clé publique : Protection des clés et des artefacts critiques de l’autorité de certification

 

S'applique à: Windows Server 2003 with SP2, Windows Server 2008 R2, Windows Server 2012 R2, Windows Server 2012

Le principal contrôle de sécurité dans une infrastructure PKI est la manière dont les clés privées sont stockées et gérées, en particulier pour les autorités de certification. Une stratégie de protection avec clé forte en plus d’autres contrôles physiques et logiques peut fournir une défense suffisante pour empêcher les intrus ou les menaces internes de compromettre l’intégrité de l’infrastructure PKI. En outre, une infrastructure PKI bien gérée nécessite le stockage sécurisé de plusieurs artefacts, comme des cartes ou des jetons d’activation HSM, des fichiers de sauvegarde et des documents. Tout stockage inapproprié de ces artefacts peut créer une brèche dans l’infrastructure PKI tout entière, sans qu’aucun intrus n’ait jamais à s’attaquer à aucun système de l’autorité de certification. Cette section fournit un ensemble de recommandations pour sécuriser les clés utilisées par les autorités de certification ou par d’autres systèmes critiques, ainsi que des recommandations pour stocker de façon sécurisée les autres artefacts de l’infrastructure PKI.

Lorsque vous concevez une nouvelle infrastructure PKI, une décision clé est de savoir si vous allez ou non utiliser un module de sécurité matériel (HSM) ou créer des clés stockées dans le logiciel. Les modules HSM sont disponibles dans de nombreux formats, par exemple sous forme d’équipements à monter sur rack, connectés en série ou via une connexion réseau, ou encore sous forme de plus petits appareils PCI ou USB. Ces modules sont munis d’un certain nombre de fonctionnalités d’auto-destruction et de scellés. Ils existent également avec de nombreuses options de performances et de conformité. Toutefois, l’acquisition de modules de sécurité matériels pour une infrastructure PKI peut représenter un investissement important. Pour toutes les autorités de certification utilisées pour sécuriser les ressources de l’entreprise dans un environnement de production, il est recommandé de mettre en œuvre un module de sécurité matériel dans le cadre de l’infrastructure PKI sécurisée. Voici quelques-uns des avantages à utiliser un module de sécurité matériel :

  • Les modules HSM permettent d’appliquer des contrôles supplémentaires à chaque fois que la clé de l’autorité de certification est utilisée, par exemple l’application du Application du contrôle par plusieurs personnes

  • La mise en œuvre de modules HSM garantit que la clé privée ne peut pas être utilisée sans accès à un HSM correctement configuré. En cas de problème, les dommages peuvent être limités. Avec une clé logicielle, il peut exister un grand nombre de copies de la clé, qui peuvent être utilisées à partir de n’importe quel ordinateur.

  • Les modules HSM effectuent les opérations de chiffrement sur du matériel sécurisé. Même si un ordinateur est attaqué, les clés de chiffrement ne sont pas disponibles dans la mémoire de l’ordinateur et ne peuvent pas être capturées.

  • Les modules HSM peuvent comporter des scellés ou des systèmes de résistance aux attaques physiques.

System_CAPS_noteRemarque

Le fait de marquer une clé logicielle comme « non exportable » n’est pas considéré comme une mesure de sécurité et ne doit pas être utilisé comme un moyen d’empêcher un intrus de récupérer la clé privée.

Dans une installation des services de certificats AD CS (Active Directory® Certificate Services) par défaut sans modules HSM, la clé privée de l’autorité de certification est stockée à l’aide de l’API de protection des données (DPAPI), qui chiffre cette clé avec les informations d’identification du compte de l’ordinateur local. En outre, la clé privée de l’autorité de certification est marquée par défaut comme étant exportable. Par conséquent, toute personne qui s’authentifie avec des privilèges d’administrateur local peut accéder à ces clés, les sauvegarder et les exporter selon différentes méthodes, via par exemple le composant logiciel enfichable MMC Certificats, via la fonction de sauvegarde du composant logiciel enfichable Certificate Services MMC ou encore à l’aide de certutil.exe pour les utiliser dans un autre emplacement. Utilisez des clés protégées de façon matérielle et évitez d’utiliser des clés logicielles pour les autorités de certification, à moins que l’infrastructure PKI soit considérée comme faible ou qu’elle ne soit pas utilisée pour protéger des données ou des transactions importantes (par exemple la validation d’un principe en laboratoire) ou bien encore si le recours à un module HSM n’est pas possible, soit pour des raisons de fonctionnement, soit pour des raisons fiscales.

Bien qu’il soit techniquement possible dans de nombreux cas de migrer une clé logicielle existante vers un module HSM, il ne s’agit en général pas de la meilleure approche. Un des avantages de l’utilisation d’un module HSM est de savoir que la clé n’a jamais été stockée ou utilisée en dehors du module HSM sécurisé. Avec une clé logicielle, même si aucune brèche n’est avérée ni suspectée, il n’existe aucun moyen de s’assurer réellement qu’il n’existe pas d’autres copies de la clé. Dans le cas où vous disposez déjà d’une infrastructure PKI et que vous souhaitez commencer à utiliser des modules HSM, envisagez une migration vers une nouvelle infrastructure dans laquelle les nouvelles clés sont générées dans le module HSM.

Certains modules HSM sont basés sur un réseau. Comme les autorités de certification hors connexion ne doivent pas être connectées à un réseau actif, si les modules HSM en réseau sont utilisés pour les autorités de certification hors connexion, il est recommandé de les connecter via un réseau privé qui ne contient que l’autorité de certification et les modules HSM. Par exemple, un commutateur dédié peut être utilisé pour connecter les deux modules. Évitez de connecter le réseau privé à un réseau actif.

Les modules HSM permettent d’imposer un contrôle par plusieurs personnes aux processus sensibles, par exemple la configuration d’un nouveau module HSM ou l’activation d’une clé avant son utilisation. Ceci est communément appelé « quorum ». Le principe fondamental du quorum consiste à répartir les interactions nécessaires pour accéder aux informations entre plusieurs entités. Dans le cas d’un module HSM connecté à une autorité de certification, plusieurs objets, généralement des cartes ou des jetons, doivent être connectés pour que le module HSM génère ou active l’utilisation de la clé privée de l’autorité de certification. Ces cartes ou jetons peuvent ensuite être séparés, répartis et stockés de façon sécurisée pour appliquer ces processus.

Lorsque vous déterminez le nombre de jetons nécessaires à la création et le nombre nécessaire pour les différentes tâches, il est important de prendre en compte les éléments suivants :

  • Le niveau de surveillance requis : pour une autorité de certification racine sensible, il peut être souhaitable que plusieurs organisations détiennent certaines parties des jetons d’accès, de façon à ce que plusieurs équipes puissent en assurer le contrôle avant tout travail.

  • Surcharge opérationnelle : en général, plus le niveau de protection d’une clé est élevé, plus le temps nécessaire aux tâches sur l’autorité de certification est important.

  • Sauvegarde et récupération d’urgence : créez toujours suffisamment d’objets pour que le quorum de ces objets soit disponible en cas de sinistre.

Voyez l’exemple suivant et comment il illustre ces recommandations. La clé privée peut être stockée sur un module HSM sur lequel, afin d’accéder à cette clé, trois des six objets sont nécessaires pour administrer le module HSM et trois des six objets sont nécessaires pour activer la clé privée avant son utilisation. Dans cet exemple, où le jeu opérationnel et le jeu d’administration nécessitent trois objets pour l’accès, les six objets peuvent être répartis en deux groupes : un jeu principal et un jeu de sauvegarde. Après cette répartition, les objets sont divisés en trois parties distinctes. Ces trois parties peuvent être distribuées aux représentants de différentes organisations, dans lesquelles ces représentants s’assurent que les objets ont été inventoriés, placés dans des conteneurs scellés, déposés dans des emplacements distincts et gérés de manière à en garantir la séparation.

La figure ci-dessous présente un exemple de relation entre les objets des modules HSM dans la création et la distribution.

Figure 5

Exemple de relations entre les objets HSM

Cette figure suppose qu’il y a trois entités ou organisations différentes impliquées dans ce processus. Voici quelques exemples d’organisations :

  1. Administration de l’infrastructure PKI : équipe ou organisation responsable de la maintenance et de l’entretien des serveurs de l’infrastructure PKI

  2. Sécurité des informations : équipe ou organisation responsable de la sécurité des données et des ressources, sans être responsable de l’administration

  3. Sécurité des opérations : équipe ou organisation responsable de la conception et/ou de l’application de la sécurité physique et/ou de la sécurité des processus

  4. Audit interne : équipe dont la responsabilité est de s’assurer que les stratégies, les procédures, les instructions et les normes de sécurité sont appliquées

  5. Autres intervenants : équipes ou organisations qui dépendent de l’infrastructure PKI

En garantissant l’implication des organisations au-delà de l’administration de l’infrastructure PKI, un certain niveau de vérifications et de contrôles est atteint. La coopération et l’implication continue de ces organisations sont cruciales. Dans l’idéal, aucune personne ou organisation ne contrôle seule ces ressources critiques.

Si la stratégie de l’exemple ci-dessus est de demander à ce que les trois organisations participent à chaque fois que la clé de l’autorité de certification est utilisée, d’autres contrôles doivent être mis en place. Dans cet exemple, il est possible que seulement deux organisations soient présentes si une de ces organisations obtenait à la fois son objet principal et son objet de sauvegarde. Lorsque vous concevez la séparation de ces objets critiques, assurez-vous que des contrôles techniques ou des procédures adéquats sont mis en place pour garantir qu’aucune personne ne peut accéder à un quorum de ces objets. Par exemple, vous pouvez renforcer encore plus la sécurité à l’aide des procédures d’accès au lieu de stockage. Le personnel du lieu de stockage peut vous aider en vérifiant l’identité et en appliquant la logique d’accès en exigeant plusieurs vérifications par personne ou en recourant à des conteneurs sécurisés avec plusieurs verrous. Ce processus peut également être simplifié en plaçant sur site une possibilité de stockage sécurisé sous le contrôle de l’équipe responsable de la sécurité des opérations du centre de données.

Une possibilité pour réguler l’accès aux ressources sécurisées consiste à s’assurer que deux représentants soient présents et clairement identifiés avant d’être autorisés à accéder à leurs ressources sécurisées. Par exemple, une identification par photo, par biométrie ou par tout autre moyen, peut être nécessaire avant d’obtenir l’autorisation d’accéder au lieu de stockage sécurisé ou à l’emplacement qui héberge les autorités de certification hors connexion. La figure qui suit présente un exemple de mappage d’objet, lorsque trois organisations fictives sont impliquées : administration de l’infrastructure PKI (PKIAdmin), sécurité des informations (InfoSec) et sécurité des opérations (OpsSec).

Figure 6

Exemple de mappage du stockage des objets

Dans les situations où il n’est pas possible d’utiliser un module HSM, il est essentiel de protéger et de contrôler les personnes et les comptes avec des privilèges d’administrateur local. Le contrôle par plusieurs personnes peut se faire de plusieurs manières, par exemple en ajoutant des verrous, en intégrant une authentification multifacteur et en séparant ces facteurs, ou même en demandant à plusieurs personnes de définir le mot de passe d’un compte avec élévation de privilèges : chaque personne qui définit une partie du mot de passe ne peut divulguer sa partie aux autres. Dans l’exemple ci-dessous, un mot de passe fort de 60 caractères généré de façon pseudo-aléatoire est divisé en différentes parties.

Figure 7

Exemple de séparation des parties du mot de passe

Les différentes parties du mot de passe peuvent être générées et définies séparément et aussi stockées de façon séparée, comme dans l’exemple de stockage d’objet HSM ci-dessus. La figure ci-dessous présente une solution simple pour diviser les différentes parties d’un mot de passe entre trois organisations fictives.

Figure 8

Mappage du stockage des parties du mot de passe

Si vous utilisez une méthode dans laquelle les mots de passe sont écrits ou imprimés, vous devez tout particulièrement vous assurer que les différentes parties du mot de passe sont générées de manière séparée et ne sont pas stockées sur un support électronique.

La protection de la clé privée garantit la confiance accordée à l’autorité de certification. Si la clé privée est protégée par un module HSM, considérez les cartes ou jetons HSM comme des ressources critiques. Ces objets, ainsi que toutes les autres données importantes, par exemple les disques de sauvegarde, les modules HSM au format USB, les clés sécurisées autonomes, les combinaisons écrites ou les fragments de mot de passe écrits doivent être suivis, faire l’objet d’un inventaire et doivent être vérifiés de bout en bout. Si la sécurité de ces données n’est pas correctement assurée, il est possible pour un intrus d’endommager l’infrastructure PKI sans jamais avoir à compromettre un seul ordinateur.

Il est recommandé de suivre l’utilisation de certains des éléments de l’infrastructure PKI, afin que toute utilisation non autorisée ou toute tentative d’accès soit détectable. Pour ces situations, il est recommandé d’utiliser des sachets scellés ou des conteneurs scellés pour le stockage. Par exemple, l’utilisation de sachets scellés pour les objets utilisés pour activer la clé privée de l’autorité de certification garantit que ces objets n’ont pas été utilisés ou modifiés.

Le choix d’un bon contenant scellé n’est pas une tâche aussi simple que ça. Dans l’idéal, il doit être muni d’un joint efficace, il doit présenter une bonne résistance à l’humidité, il doit porter un numéro unique gravé à l’extérieur et il doit comporter un emplacement sur lequel il est possible d’écrire les détails de la chaîne de responsabilité. Étant donné que ces objets peuvent contenir des composants électroniques, il est souhaitable qu’ils présentent de bonnes propriétés antistatiques. Certains fabricants proposent des échantillons à évaluer. Les magasins spécialisés dans les services aux institutions financières ou aux services juridiques disposent d’une offre variée en matière de conteneurs scellés.

S’il peut être judicieux d’utiliser un conteneur transparent pour les artefacts balisés pour en permettre l’identification et la vérification, vérifiez que tous les artefacts comportant des secrets, comme des parties de mot de passe, restent bien cachés, dans un conteneur scellé opaque dans une enveloppe opaque ou dans une enveloppe opaque dans un conteneur scellé transparent.

Les artefacts de l’infrastructure PKI doivent souvent être stockés pendant de longues périodes. Lorsque vous stockez les artefacts, assurez-vous qu’ils se trouvent dans un environnement climatisé, par exemple le centre de données local ou dans un coffre-fort. Vous pouvez utiliser des sachets de gel de silice pour absorber toute humidité résiduelle si les artefacts se trouvent dans des sachets de protection ou des conteneurs de stockage.

Lorsque vous utilisez une infrastructure PKI, les ressources sécurisées peuvent être déplacées ou voir leur propriété passer d’une personne à une autre, voire d’une organisation à une autre. Pour tous les actifs sécurisés, créez une chaîne de responsabilité qui suit en permanence la personne qui en est responsable. En créant cette chaîne de responsabilité, vous garantissez qu’en cas d’enquête sur l’utilisation incorrecte d’un élément, il existe une trace fiable permettant de déterminer à tout moment qui est en possession de cet élément.

Lorsque vous stockez les artefacts dans un coffre ou dans tout autre type de cellule de stockage, tenez un journal d’archivage manuel et conservez ce journal. Lors de l’extraction des artefacts, l’inventaire précédent doit être vérifié et une entrée écrite doit être ajoutée au journal des mouvements. Ce journal doit contenir des champs pour les éléments suivants :

  • Date et heure

  • Le numéro ou le code unique du conteneur scellé

  • L’identification ou l’étiquette de l’artefact qui se trouve dans le conteneur

  • L’assurance que le conteneur n’a pas été fracturé

  • La personne qui effectue l’inventaire

  • L’entrée ou la sortie

  • Un emplacement où les artefacts ont été placés ou mis en sécurité

Voici un exemple de journal des mouvements avec des entrées fictives.

Figure 9

Exemple de journal des mouvements

Régulièrement, même si les artefacts ne sont pas utilisés, effectuez un inventaire et placez une copie de cet inventaire avec les artefacts. Voici un exemple de journal avec des entrées fictives.

Figure 10

Exemple de journal d’inventaire

L’utilisation d’un module HSM pour assurer une protection renforcée des clés de l’autorité de certification ou d’autres clés de grande valeur est un des contrôles les plus efficaces pour la protection de votre infrastructure PKI. Les modules HSM peuvent vous garantir que les clés ne sont disponibles que dans les systèmes autorisés et vous aider à réduire le risque qu’un intrus ou un élément interne accède aux clés de façon non autorisée. En assurant la protection des autres éléments de l’infrastructure PKI et en menant des audits sur leur utilisation, vous avez la certitude qu’ils ne sont pas utilisés de façon non autorisée une fois qu’ils ont été créés dans le module HSM.

Pour obtenir la liste complète des recommandations pour la protection des clés de l’autorité de certification et les artefacts critiques, ainsi que le niveau auquel vous devez envisager de les mettre en œuvre, consultez Sécurisation de l’infrastructure à clé publique : Annexe F : Liste des recommandations par niveau d’impact.

Sécurisation de l'infrastructure à clé publique (PKI)
Sécurisation de l’infrastructure à clé publique : Introduction
Sécurisation de l’infrastructure à clé publique : Planification d’une hiérarchie d’autorités de certification
Sécurisation de l’infrastructure à clé publique : Contrôles physiques de sécurisation d’une infrastructure à clé publique
Sécurisation de l’infrastructure à clé publique : Sécurité des processus d’une infrastructure à clé publique
Sécurisation de l’infrastructure à clé publique : contrôles techniques de sécurisation d’une infrastructure à clé publique
Sécurisation d’infrastructure à clé publique : Planification des algorithmes de certificat et de leurs utilisations
Sécurisation de l’infrastructure à clé publique : Surveillance d’une infrastructure à clé publique
Sécurisation de l’infrastructure à clé publique : Réponse à la compromission
Sécurisation de l’infrastructure à clé publique : Annexe A : événements à analyser
Sécurisation de l’infrastructure à clé publique : Annexe B: Filtre d’audit de l’autorité de certification
Sécurisation de l’infrastructure à clé publique : Annexe C : Déléguer des autorisations d’infrastructure à clé publique à Active Directory
Sécurisation de l’infrastructure à clé publique : Annexe D : Glossaire
Sécurisation de l’infrastructure à clé publique : Annexe E : Principes fondamentaux de l’infrastructure à clé publique
Sécurisation de l’infrastructure à clé publique : Annexe F : Liste des recommandations par niveau d’impact
Sécurité et protection
Sécuriser Windows Server 2012 R2 et Windows Server 2012

Afficher: