Surveillance de la sécuritéDéploiement d'une PKI globalement fiable

John Morello

Cette rubrique inclut des données de versions préliminaires susceptibles d'être modifiées.

Une Public Key Infrastructure (infrastructure de clé publique) ou PKI, est un élément essentiel à la construction de la confiance entre des applications, des systèmes d'exploitation et des domaines d'identité divers. Elle est construite sur un modèle hiérarchique fiable dans lequel les entités de fin font confiance à une clé commune au niveau le plus élevé de la racine et par conséquent, toutes les autres clés signées par cette racine sont implicitement fiables.

Grâce à cette structure, une PKI bien conçue peut être aisément améliorée par l'ajout de CA (autorités de certification) supplémentaires, sans introduire de modifications aux entités de fin.

Il existe généralement deux façons d'implémenter les PKI. L'approche la plus commune est d'acheter les certificats nécessaires auprès de l'un des fournisseurs de racines globales implicitement fiables, tels que Cybertrust ou VeriSign. Ces certificats sont souvent utilisés pour sécuriser les flux sur les sites Web mais peuvent également être utilisés pour crypter des VPN (réseaux privés virtuels), signer des courriers électroniques et effectuer d'autres tâches de ce type. Puisque ces racines globales sont intégrées à tous les navigateurs Web et à tous les systèmes d'exploitation modernes, cette méthode peut aisément déployer une relation de confiance au-delà des limites de l'organisation. Cependant, puisque ces certificats sont achetés en fonction des besoins, un large déploiement de cette approche dans une organisation de grande taille peut être coûteux.

Récemment, le modèle de PKI interne s'est répandu. Comme son nom l'indique, une PKI interne n'est fiable que dans le réseau propre à une organisation. Ce modèle permet à une organisation de fournir des services à chaque utilisateur et à chaque système informatique sur son réseau à un moindre coût grâce à l'utilisation de certificats. Cette approche est souvent utilisée pour faciliter des technologies telles que la connexion d'une carte à puce, l'EFS (Encrypting File System) et pour sécuriser la mise en réseau sans fil. Ces certificats ne sont pas adaptés aux applications externes puisqu'ils ne sont pas globalement fiables. C'est là l'inconvénient. Ainsi, la plupart des organisations qui ont déployé des PKI internes adoptent généralement une approche hybride, achetant des certificats pour des applications publiques à une racine globalement fiable.

Et que diriez-vous si vous pouviez obtenir le meilleur des deux approches ? Que se passerait-il si votre organisation pouvait exécuter sa propre PKI (avec la réduction des coûts induite par l'émission de certificats internes) et fournir des certificats publiquement fiables et tout cela depuis votre propre système local ? Une telle solution offrirait les avantages d'une PKI interne (comme l'intégration, l'auto-inscription et le support informatique localisé Active Directory®) tout en fournissant l'avantage majeur d'une racine globalement fiable. La Louisiana State University (LSU) est équipée de ce système. Dans cette partie de Surveillance de la sécurité, je passe en revue la solution que nous avons implémentée à la LSU, en abordant sa conception technique et en mettant en évidence les bonnes pratiques à utiliser lors du déploiement d'un système similaire. Il convient de noter que la solution que je m'apprête à décrire est l'une de celles qui répondent à nos besoins spécifiques compte tenu de notre environnement, de nos ressources et de nos exigences. Il vous est recommandé d'évaluer tous les aspects de votre entreprise au préalable afin de déterminer le type de solution qui vous convient.

Comment la LSU crée la PKI

La LSU est une université de recherche importante dont la population composée d'étudiants, de professeurs et d'autres personnels dépasse les 40 000 personnes. Elle possède de nombreux sites Web publics et nombre d'entre eux requièrent l'utilisation de Transport Layer Security (SSL) - le terme adéquat pour les certificats SSL.. La LSU avait l'habitude de dépenser des milliers de dollars chaque année pour l'achat de certificats provenant de fournisseurs de racines globalement fiables.

En outre, la LSU avait d'autres objectifs en matière de sécurité informatique pour lesquels une PKI interne bien conçue présentait des avantages évidents. Étant donné les objectifs et les exigences de la LSU, vous auriez pu vous attendre à ce que nous choisissions un modèle hybride. Mais au lieu de cela, nous nous sommes décidés pour une approche qui nous a semblé plus innovante.

Nous avons travaillé avec l'une des racines globalement fiables, Cybertrust, pour déployer une CA sur le site de la LSU, subordonné à une CA racine Cybertrust (voir figure 1). Cybertrust propose ce service dans son programme OmniRoot. Dans ce scénario, la LSU construit et fait fonctionner une CA qui s'exécute localement sur un équipement appartenant à la LSU. Cependant, contrairement au modèle interne abordé plus haut, la CA de la LSU n'est pas auto-signée et sa clé (avec celles qu'elle signe) est implicitement fiable dans pratiquement tous les systèmes d'exploitation et les navigateurs modernes. Techniquement, cette conception est une extension logique de l'ouverture des standards x.509. Une PKI étant construite sur ces standards, il est possible de raccorder des systèmes créés par différents fournisseurs dans une même hiérarchie globale. Ceci dit, les conditions d'utilisation de la solution OmniRoot sont particulièrement intéressantes.

Figure 1** Certificat racine global de Cybertrust **(Cliquer sur l'image pour l'agrandir)

Le service OmniRoot est conçu de manière spécifique pour le type de déploiement de la PKI que nous avons implémentée à la LSU. Dans le programme OmniRoot, les organisations paient une taxe annuelle fixe à Cybertrust pour pouvoir participer au programme et paient une taxe par certificat uniquement pour les certificats créés pour une utilisation publique. En d'autres termes, la LSU peut émettre autant de certificats que nécessaire pour une utilisation interne, sans avoir à se préoccuper des taxes supplémentaires par certificat qui seraient à payer. En outre, le coût des certificats publics est aujourd'hui nettement moins élevé que celui payé par l'université lorsqu'elle achetait des certificats en fonction de ses besoins.

En fait, les certificats internes et les certificats publics sont identiques d'un point de vue technique. Ils sont émis par la même chaîne de CA, possèdent la même efficacité cryptographique et sont fournis par le même système d'autorité d'enregistrement. Les termes de la licence constituent la seule différence.

Au final, nous avons pu développer et améliorer la plate-forme de sécurité informatique de la LSU à un coût moindre. Cette réalisation a constitué une application commerciale intéressante pour ce type de solution PKI à la LSU. Examinons à présent les aspects plus techniques du déploiement.

Hiérarchie de l'objet PKI

La hiérarchie de l'objet PKI de la LSU est basée sur une conception à deux niveaux, dont le niveau racine est géré par Cybertrust et une CA émettant en ligne, s'exécutant à la LSU (voir figure 2). Le niveau racine constitue le point d'ancrage permettant d'établir la fiabilité de la hiérarchie. En d'autres termes, la relation de confiance de tous les certificats émis par une CA quelconque dans la hiérarchie est soumise à la CA racine (voir figure 3). Ainsi, la CA racine constitue le lien commun à toutes les CA, les certificats et les entités de fin dans la hiérarchie. Comme la racine globale Cybertrust est déjà construite dans Windows® et sur tout autre système informatique récent, ce lien commun s'étend automatiquement au-delà du réseau de la LSU.

Figure 2 Hiérarchie PKI à deux niveaux

Figure 3** Certificat émis par la CA émettrice CA de la LSU **(Cliquer sur l'image pour l'agrandir)

Cybertrust gère la CA racine sur une de ses structures d'hébergement sécurisées. La structure d'hébergement utilise des contrôles de sécurité matériels très efficaces, comprenant des sas, des verrous biométriques et un local de stockage complètement gainé de cuivre. Cybertrust émet des certificats uniquement à l'attention des CA des organisations qui ont démontré qu'elles respectaient ses stratégies de sécurité et de certification.

La CA émettrice de la LSU est un système interface/entités de fin en charge de la fourniture des certificats aux utilisateurs et aux ordinateurs de la LSU. Son certificat est signé par la CA de Cybertrust qui se trouve à un niveau supérieur dans la hiérarchie et elle émet des certificats qui sont reliés à la CA racine de Cybertrust (voir figure 3).

Système d'exploitation et matériel d'émission

La LSU utilise Windows Server® 2003 Édition Entreprise Pack 1 pour sa CA émettrice. Le service d'autorité de certification Windows Server 2003 propose de nombreuses fonctionnalités nouvelles, dont un archivage de clés, des CRL delta (listes de révocation des certificats) et des modèles "version 2". L'instance de Windows utilisée en tant que CA émettrice est construite en fonction de la stratégie standard de construction Windows Server de la LSU. Elle est actualisée avec toutes les mises à jour de sécurité pertinentes et gérée à l'aide des méthodes de gestion de modifications standard de la LSU et des outils d'inventaire logiciel et de mise à jour. En résumé, alors que certains aspects de la gestion du service de CA lui-même sont uniques, le matériel et le système d'exploitation du serveur de base sont eux facilement intégrés aux opérations informatiques courantes de l'organisation.

En plus de se conformer aux bonnes pratiques standard de la LSU pour l'installation du serveur, nous avons pu profiter de l'Assistant de Configuration de la sécurité (SCW), disponible dans Windows Server 2003 Service Pack 1. Le SCW utilise une base de données qui contient des matrices de dépendance des diverses charges de travail qui peuvent être exécutées sur Windows Server et le paramètre de sécurité que ces charges de travail requièrent. Cette base de données comprend les deux rôles primaires que fournira la CA - le service CA lui-même et l'IIS (qui fournit le site Web libre-service de l'objet).

En utilisant le SCW, nous avons facilement créé un modèle de sécurité qui désactivait tous les services autres que ceux requis pour exécuter ces charges de travail. Nous avons également renforcé la pile réseau du serveur. Nous avons ensuite utilisé la commande scwcmd.exe pour transformer ce modèle en un Objet de stratégie de groupe (GPO) afin de pouvoir l'appliquer au serveur au niveau de l'unité d'organisation. Cette approche simplifie l'amélioration et la récupération après incident puisque la configuration de sécurité basée sur les rôles pour une CA LSU est maintenant stockée dans Active Directory plutôt que d'être spécifique à une machine.

La CA émettrice de la LSU est construite sur un serveur IBM xSeries 346, avec deux processeurs Intel Xeon 3.2GHz, 4 Go de RAM et cinq disques durs SCSI de 146 Go. Vu les exigences de performance du service de CA et le fait que la LSU utilise un module de sécurité matérielle, cette plate-forme devrait permettre une longévité importante et procurer de l'espace pour la croissance.

Nous nous sommes conformés aux bonnes pratiques standard pour séparer les bases de données et les fichiers journaux en deux groupes physiquement séparés en créant deux systèmes RAID 1. Le cinquième disque dur est gardé comme disque de rechange activable et disponible pour ces deux systèmes au choix. Nous avons installé le premier système comme étant notre volume système, où nous conservons la base de données CA. Le deuxième système est utilisé pour les fichiers journaux et d'autres fichiers de données divers, tels que les CRL. La base de données de la CA est basée sur la même technologie Jet que l'on trouve dans d'autres parties de Windows, comme Active Directory, c'est pourquoi les mêmes bonnes pratiques de maintenance et de configuration de disques pour d'autres solutions de stockage basées sur Jet s'appliquent ici.

Un module de sécurité physique (HSM) est un périphérique matériel dédié qui est géré séparément du système d'exploitation. Les HSM se présentent généralement sous la forme de cartes PCI mais sont aussi disponibles sous la forme de périphériques basés sur le réseau. Ces modules fournissent un lieu de stockage matériel sécurisé pour les clés CA, ainsi qu'un processeur cryptographique dédié pour accélérer la signature et le cryptage des opérations. Windows utilise le HSM via les interfaces CryptoAPI - le HSM est considéré comme un périphérique fournissant des services cryptographiques (cryptographic service provider ou CSP). Le programme OmniRoot nécessite que chaque CA utilise au moins un HSM certifié niveau 3 FIPS 140-2 (les périphériques niveau 4 sont plutôt rares) pour la génération et le stockage de clés. En tant que périphérique unique et très sûr, un HSM nécessite un investissement financier important. Les prix concernant les HSM basés sur PCI se situent généralement entre 10 000 et 15 000 $.

Dans la conception de la LSU, un nCipher nShield 500 TPS (modèle 500 transactions par seconde) est utilisé comme HSM lié directement. ("Lié directement" signifie qu'il est interne au serveur et ne peut être utilisé que par le serveur, plutôt que d'être un HSM basé sur le réseau qui peut être partagé par des hôtes multiples.) Le HSM est un périphérique FIPS 140-2 de niveau 3 et il fournit une protection K de N de l'élément de mise à clé. Le HSM fournit une protection importante contre la violation de la sécurité des clés privées - un pirate aurait besoin de posséder le stockage du HSM et un certain nombre de jetons d'accès et de codes PIN associés pour accéder à la clé.

Il est très important de noter que les HSM sont conçus pour empêcher leur contenu d'être violé par des tiers malveillants. Ainsi, les HSM appliquent une limite stricte aux tentatives d'ouverture de session consécutives ayant échoué. Dans la conception de la LSU, le stockage est irrévocablement effacé après 10 tentatives consécutives ayant échoué.

Notre installation ne comporte qu'une seule CA, de sorte que le supplément de prix pour un HSM basé sur le réseau ne se justifie pas Cependant, si une organisation envisage d'implémenter deux CA ou plus, cela peut s'avérer nettement moins coûteux d'acheter un seul HSM basé sur le réseau et de le partager entre les CA. Cette approche facilite également la gestion des jetons, puisque tout le stockage de clés peut être protégé par le même jeu de jetons.

Active Directory et inscription

L'un des avantages principaux de la solution PKI basée sur Windows est que la fourniture de certificats est effectuée sans avoir à installer de logiciel supplémentaire sur les entités qui participent au PKI. En fait, en associant inscription et stratégie de groupe, la plus grande partie de la fourniture de certificats peut se gérer de manière autonome, de manière transparente pour l'utilisateur final. La LSU utilise cette technologie pour distribuer automatiquement des certificats machines aux ordinateurs membres de son Active Directory. Et nous utilisons un site Web personnalisé pour fournir des fonctionnalités de demande de certificats en libre-service pour les hôtes non Windows.

Comme mentionné plus haut, le programme OmniRoot fait la distinction entre les certificats utilisés publiquement et ceux utilisés en interne. Les certificats sont considérés comme publics s'ils sont utilisés par des systèmes et des utilisateurs qui ne font pas partie de l'organisation LSU (par exemple, lorsqu'un éventuel futur étudiant soumet un formulaire d'admission via un site Web sécurisé SSL). Les certificats utilisés à l'intérieur de l'organisation LSU (tels que ceux utilisés pour crypter les données sur les serveurs LSU) sont considérés comme internes.

Puisque le coût du programme OmniRoot est basé sur le nombre de certificats publics, nous devons être capables de savoir le nombre de certificats publics émis et leurs destinataires. Ainsi, pour tout certificat destiné à être public, le nom distinctif du modèle commence par "PublicCertificate" et le nom complet par "Public Certificate". Par exemple, le modèle de certificat externe TLS de la LSU est basé sur le modèle de serveur Web Windows par défaut et est appelé Serveur Web certificat public LSU. Pour les serveurs Web utilisés en interne, il existe un second modèle appelé Serveur Web certificat interne LSU. Techniquement, les deux modèles sont identiques. La différenciation d'appellation sert uniquement à faciliter la comptabilité.

Pour des besoins d'inscription massive - tels que l'inscription de départements entiers pour des certificats devant être utilisés avec IPSec - nous comptons sur l'auto-inscription. Il s'agit d'un outil simple et très efficace construit dans Windows. Du point de vue d'un administrateur PKI, la seule action nécessaire est de modifier la liste de contrôle d'accès sur le modèle, accordant à n'importe quel groupe d'utilisateurs ou d'ordinateurs ayant besoin de certificats le droit de s'auto-inscrire. Ces entités vérifieront alors automatiquement Active Directory, dénombreront les modèles auxquels ils ont un accès en auto-inscription, trouveront les CA avec ces modèles et procéderont à une inscription automatique pour obtenir les certificats. De plus, la fonctionnalité d'auto-inscription garantira que les certificats sont remplacés si un modèle est remplacé et renouvelé automatiquement avant expiration.

Pour des besoins plus réduits, comme la fourniture de certificats aux serveurs Web, nous utilisons un site Web en libre-service qui permet aux utilisateurs de demander des certificats via un navigateur Web. Ce site est une version personnalisée des pages d'inscription Web fournies avec Windows Server 2003 (le répertoire virtuel /certsrv). Notre implémentation inclut l'homologation Web standard LSU et préremplit les entrées par défaut appropriées sur la page de la demande. Nous utilisons également le module de sortie par défaut dans le service CA de Windows pour automatiquement envoyer un courrier électronique à notre équipe d'administration PKI lorsqu'une demande envoyée via ce site nécessite une approbation.

Révocation

Chaque certificat a une durée de vie limitée. De temps à autre, la LSU doit invalider certains certificats avant la fin de la période de validité (par exemple, si un employé a reçu un certificat avec une période de validité qui expire en mai 2007, mais que cet employé quitte la LSU en janvier 2007). Ce type de révocation est effectué avec des CRL, qui sont des fichiers contenant une liste de numéros de série de certificats signés par une CA. Les numéros de série présents dans la CRL se réfèrent aux certificats dont la durée de validité n'a pas expiré, mais que la LSU ne considère plus comme fiables. Les clients peuvent alors télécharger cette CRL et la vérifier pour déterminer la validité des certificats.

N'importe quel certificat x.509 v3 (sauf le certificat de CA racine lui-même) devrait avoir un pointeur sur une CLR valide. Ce pointeur est connu comme point de distribution CRL ou CDP. Ce point de distribution CRL est inclus dans le certificat lui-même (voir figure 4) et ne peut être modifié après l'émission d'un certificat. La CRL est un élément essentiel pour assurer la validité des certificats d'une CA. De cette manière, nous nous assurons que les CLR LSU sont redondantes physiquement, complètement disponibles et accessibles par des parties externes.

Figure 4** Point de distribution CLR de la LSU **(Cliquer sur l'image pour l'agrandir)

Une CA basée sur Windows Server intégrée à Active Directory (comme celle de la LSU) publie automatiquement sa CLR dans Active Directory, la rendant accessible via le protocole LDAP (Lightweight Directory Access Protocol). L'emplacement de publication par défaut est le conteneur CDP (voir figure 5) dans le conteneur Public Key Services de la forêt. Cet emplacement de publication est une excellente option : il fournit une réplication automatique, une tolérance par défaut et un emplacement pour des recherches CDP.

Figure 5** Conteneur CDP **(Cliquer sur l'image pour l'agrandir)

Dans la conception LSU, cependant, il existe de nombreux ordinateurs non Windows et non Active Directory qui utilisent la PKI. Et bien que la LSU soit une organisation de grande taille, la grande majorité de ses utilisateurs se situent sur le même réseau de campus, avec une dorsale de 10 Gbps, minimisant les avantages de la publication CDP basée sur Active Directory.

Nous publions donc notre CRL uniquement sur un chemin HTTP, facilitant ainsi la construction d'une plate-forme d'hébergement redondante (notre principal site Web est en miroir). Cela supprime également les difficultés éventuelles associées à la possibilité de recherches LDAP client. Nous publions notre CRL tous les jours et publions les CLR delta toutes les heures.

Fonctions avancées

Alors que notre PKI en cours fournit une très bonne solution de sécurité pour la communauté universitaire, nous envisageons de renforcer ses fonctionnalités. Windows Vista™ et la prochaine version de Windows Server (nom de code "Longhorn") fourniront de nombreuses fonctionnalités de gestion nouvelles que nous prévoyons d'approfondir. Nous sommes particulièrement intéressés par les fonctionnalités client et répondeur OCSP (Online Certificate Status Protocol) attendues, la prise en charge d'Elliptic Curve Cryptography et les algorithmes SHA-256 et l'interface d'inscription automatique améliorée. De plus, Windows XP Service Pack 3 est programmé pour inclure une fonction connue sous le nom d'itinérance des informations d'identification, ce qui permettra une itinérance sécurisée des paires de clés sans la surcharge associée aux profils itinérants. Au final, nous nous intéressons à l'utilisation de Certificate Lifecycle Manager (disponible actuellement en version bêta) afin d'améliorer nos fonctionnalités de reporting et de gestion.

En résumé, la PKI de la LSU équipe l'université d'un service de sécurité fondamental utilisé pour de nombreuses fonctions informatiques critiques. En utilisant le service Omniroot de Cybertrust, nous pouvons exécuter une PKI qui est bien intégrée aux autres systèmes informatiques de la LSU mais dont la confiance se déploie globalement. De plus, en construisant la solution sur le service CA de Windows, nous obtenons des fonctionnalités efficaces de fourniture et de gestion de certificats, ainsi qu'une excellente intégration à notre répertoire existant et à notre système de gestion des identités. En résumé, la sécurité très élevée et la fiabilité transparente voulues pour la PKI sont déjà une réalité à la LSU.

John Morello a obtenu une mention très bien à la Louisiana State University et a passé six ans chez Microsoft en tant que consultant senior pour Microsoft Consulting Services (MCS). Chez MCS, il a élaboré des PKI pour des clients stratégiques tels que Deloitte, GE et diverses organisations fédérales. Il est maintenant Chef de la sécurité informatique (CISO) à la Louisiana State University (LSU).

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.