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 : Planification d’une hiérarchie d’autorités de certification

 

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

La planification de la hiérarchie de certificats est un des aspects les plus importants de la conception d’une infrastructure à clé publique, car la conception a une incidence sur la manière dont les certificats sont validés et utilisés par les solutions dans lesquelles l’infrastructure à clé publique est activée. Cette section présente un certain nombre de recommandations concernant la conception d’une hiérarchie de certificats qui peut être utilisée pour répondre aux besoins urgents actuels des entreprises, ainsi qu’aux besoins futurs qui n’ont peut-être pas encore été identifiés.

Une infrastructure à clé publique peut être implémentée soit dans le cadre de l'infrastructure informatique soit à l'aide d’autorités de certification commerciales externes. En règle générale, les options suivantes sont disponibles pour la conception d’une infrastructure à clé publique :

  • Implémenter une infrastructure à clé publique entièrement autogérée au sein de votre organisation qui contient des autorités de certification internes chaînées à une autorité de certification racine interne située en haut de la chaîne

  • Acheter un certificat d’autorité de certification à partir d’une autorité de certification commerciale et émettre des certificats au sein de l'organisation à partir d'autorités de certification internes autogérées qui sont chaînées à l'autorité de certification racine externe

  • Acheter des certificats auprès d'une autorité de certification commerciale chaînés à une autorité de certification racine publique (de préférence membre du programme de certificat racine Microsoft) qui sont automatiquement distribués aux clients qui utilisent des plateformes Microsoft Windows®.

Si les solutions de sécurité prises en charge par l'infrastructure à clé publique ne requièrent pas de parties externes pour approuver les certificats émis et n’en auront jamais besoin, vous pouvez opter pour une infrastructure à clé publique autogérée qui utilise une autorité de certification racine interne comme ancre d'approbation de l'infrastructure à clé publique. L’utilisation d'une autorité de certification racine interne vous permet de maintenir un contrôle direct sur ses stratégies de sécurité et d'aligner sa stratégie de certificat avec la stratégie de sécurité globale. Par conséquent, vous utiliserez des autorités de certification internes pour émettre des certificats aux utilisateurs finaux, ordinateurs et services. Ces autorités de certification internes peuvent être étendues pour inclure des fonctionnalités supplémentaires, telles que la prise en charge de nouveaux types de certificat, à un coût inférieur à celui de l'achat de certificats externes.

Dans une infrastructure à clé publique hiérarchique (déploiement classique), il existe généralement trois types de hiérarchie : à un niveau, à deux niveaux et à trois niveaux.

Figure 1

Hiérarchie à un niveau

  • Hiérarchie à un niveau : inclut une seule autorité de certification. L'autorité de certification est considérée comme l’autorité de certification racine et l’autorité de certification émettrice. Une autorité de certification racine est le point d'ancrage d’approbation de l'infrastructure à clé publique. Aussi, une clé publique d'autorité de certification racine sert de point de départ des chemins d’accès à l’approbation d’un domaine de sécurité. Les applications, les utilisateurs ou les ordinateurs qui approuvent l'autorité de certification racine approuvent également tous les certificats émis par la hiérarchie d’autorités de certification. L'autorité de certification émettrice est une autorité de certification qui émet des certificats aux entités finales.

    Cette hiérarchie à un niveau est déconseillée pour les scénarios de production, car la compromission de cette seule autorité de certification équivaut à la compromission de l’ensemble de l'infrastructure à clé publique. Pour des raisons de sécurité, les autorités de certification émettrices et racines sont normalement séparées, car il est généralement très difficile de distribuer rapidement un nouveau certificat d'autorité de certification racine pour remplacer une autorité de certification compromise. Cela est particulièrement vrai lorsque l'environnement comprend des ordinateurs non joints aux appareils ou domaine de gestion où un processus spécial est nécessaire pour approvisionner le certificat d'autorité de certification racine. Pour cette raison, une hiérarchie à un seul niveau n’est suffisante que pour des implémentations simples où la facilité de gestion et les coûts réduits l'emportent sur des niveaux plus élevés de sécurité ou de flexibilité.

    Dans les évaluations d’infrastructures à clé publique, il est courant de voir que certaines organisations installent une autorité de certification pour prendre en charge un projet majeur qui aurait pu en avoir besoin. Il peut s’agir d'une installation de System Center Configuration Manager, de la protection d’un réseau sans fil ou d’une autre technologie faisant appel à une infrastructure à clé publique pour lesquels une seule ligne du planification du projet est dédiée à l'installation de l'autorité de certification. Au fil du temps, cette autorité de certification unique fait l’objet d’une utilisation intensive, car elle est de plus en plus exploitée à d'autres fins que celles définies à l'origine. Soudain, il est nécessaire de mettre en place une infrastructure à clé publique appropriée et les administrateurs sont confrontés à des questions complexes :

    • Puis-je installer plusieurs infrastructures à clé publique dans ma forêt sans qu’elles interfèrent les unes avec les autres ?

    • Comment configurer correctement ma nouvelle infrastructure à clé publique afin qu'elle soit évolutive et facile à gérer ?

    • Comment puis-je supprimer mon ancienne autorité de certification sans que cela entraîne l’interruption de mon activité ?

    • La configuration de cette autorité de certification pose-t-elle un risque de sécurité pour l'entreprise ?

    Il existe donc plusieurs risques de sécurité lors de l’utilisation d’une hiérarchie à un seul niveau. Votre unique autorité de certification est en ligne et donc plus susceptible d’être compromise et vous ne pouvez pas la révoquer si elle a été compromise. Cette hiérarchie est également plus difficile à étendre pour prendre en charge d'autres scénarios. Si vous êtes en mesure de passer à la conception de hiérarchie d'autorités de certification recommandée, reportez-vous à l’article Déplacement de votre organisation d'une autorité de certification Microsoft unique à l’infrastructure à clé publique Microsoft recommandée.

Figure 2

Hiérarchie à trois niveau

  • Hiérarchie à trois niveaux : dans ce type de hiérarchie, il existe un niveau d'autorité de certification racine (hors connexion), un niveau d'autorités de certification émettrices (généralement en ligne) et un niveau intermédiaire. Le placement de cette autorité de certification intermédiaire peut avoir lieu pour plusieurs raisons. La première raison est l’utilisation du deuxième niveau d’autorité de certification comme autorité de certification de stratégie. Par exemple, une des autorités de certification de stratégie émet des certificats qui exigent qu'un utilisateur soit présent physiquement et une autre autorité de certification émet des certificats aux utilisateurs d’entreprise authentifiés. En d'autres termes, l’autorité de certification de stratégie est configurée pour émettre des certificats à l'autorité de certification émettrice qui est limitée concernant le type des certificats qu'elle émet. L’autorité de certification de stratégie peut également servir de limite d'administration. Autrement dit, vous émettez uniquement certains certificats à partir des subordonnés de l'autorité de certification de stratégie et vous effectuez un certain niveau de vérification avant d'émettre des certificats, mais la stratégie est appliquée uniquement du point de vue administratif et non technique.

    Voici une autre raison pour ajouter le deuxième niveau : vous devez révoquer plusieurs autorités de certification en raison d'une clé compromise et pour ce faire, vous utilisez le deuxième niveau en laissant les autres branches disponibles. Il convient de noter que les autorités de certification de second niveau dans cette hiérarchie doivent, comme l’autorité de certification racine, être conservées hors connexion.

    Suivant le paradigme, la sécurité augmente avec l'ajout d'un niveau et la flexibilité et l'extensibilité augmentent en raison des options de conception supplémentaires. En revanche, la facilité de gestion augmente, car il y a un plus grand nombre d'autorités de certification à gérer dans la hiérarchie et les coûts augmentent.

    Notez que la réalisation de la génération de chaîne de certificats sur les clients de solutions d’infrastructures à clé publique implique une augmentation du nombre de niveaux, car les clients d’une hiérarchie à trois niveaux doivent vérifier le certificat et les informations d'état associées aussi bien pour les autorités de certification émettrices que pour les autorités de certification de stratégie. Un autre élément à prendre en compte sont les exigences de limite d'administration ou de stratégie, car une hiérarchie à trois niveaux augmente les coûts d'exploitation. Notez également que si vous ne souhaitez pas implémenter des limites de stratégie ou d’administration, le niveau intermédiaire n'est pas utilisé et n'est donc pas nécessaire. Pour cette raison, les hiérarchies d'autorités de certification à trois niveaux ne sont généralement pas recommandées (à l'exception de quelques cas uniques). En fait, le service informatique de Microsoft a fait évolué sa conception vers une hiérarchie d'autorités de certification à deux niveaux pour son infrastructure à clé publique interne. Voir Déploiement et gestion de l’infrastructure à clé publique au sein de Microsoft pour plus d'informations.

Figure 3

Hiérarchie à deux niveaux

  • Hiérarchie à deux niveaux : cette conception répond aux besoins de la plupart des entreprises. À certains égards, elle sert de compromis entre la hiérarchie à un niveau et la hiérarchie à trois niveaux. Dans cette conception, il existe une autorité de certification racine hors connexion et une autorité de certification émettrice secondaire en ligne. Le niveau de sécurité augmente, car les rôles de l'autorité de certification racine et de l'autorité de certification émettrice sont séparés. Mais plus important encore, l'autorité de certification racine est hors connexion. Par conséquent, la clé privée de l'autorité de certification racine est mieux protégée contre une possible compromission. La hiérarchie à deux niveaux augmente également l'extensibilité et la flexibilité du fait que plusieurs autorités de certification émettrices peuvent être subordonnées à l'autorité de certification racine. Cela permet aux autorités de certification d’exister dans différents emplacements géographiques, ainsi qu'avec différents niveaux de sécurité. La facilité de gestion est améliorée, car l’autorité de certification racine doit être mise en ligne pour signer des listes de révocation de certificats. Le coût augmente légèrement, car il vous suffit juste d'un autre serveur ou d’un ordinateur virtuel. La hiérarchie à deux niveaux est la conception recommandée pour la plupart des solutions d'infrastructure à clé publique.

    Une autre idée recommandée est de restreindre les certificats des autorités de certification émettrices secondaires de manière à limiter leur impact sur la hiérarchie d’autorités de certification afin que les autorités de certification secondaires ne puissent pas émettre de certificats non autorisés qui pourraient être utilisés à des fins non prévues. C’est un élément important à prendre en compte lorsque vous avez des hiérarchies de certificats plus complexes. Le cas le plus évident se produit lorsqu'une autorité de certification émettrice est gérée par différentes parties d'une organisation mais que, même pour les autorités de certification émettrices internes, il puisse être judicieux de limiter la portée des certificats émis. Vous souhaitez limiter les certificats émis pour un scénario spécifique (par exemple, l'authentification de serveur) afin qu’une autorité de certification n'affecte pas les autres (par exemple, l'émission de certificats pour les cartes à puce) en cas de violation de la sécurité. La meilleure façon d'accomplir cette tâche consiste à implémenter la contrainte de longueur de chemin d'accès et de limiter les utilisations améliorées de la clé pour le certificat de l'autorité de certification émettrice comme décrit dans la section Sécurisation d’infrastructure à clé publique : Planification des algorithmes de certificat et de leurs utilisations. Veuillez noter qu'il existe de nombreux éléments partagés issus de plusieurs autorités de certification subordonnées d’entreprise dans un environnement Active Directory® (par exemple, les modèles de certificat). Cette restriction ne doit don pas être la seule prévention.

Pour obtenir une liste complète des recommandations concernant la planification d’une hiérarchie d’autorités de certification, ainsi que pour connaître le niveau d’impact sur l’activité auquel vous devez envisager de les mettre en œuvre, reportez-vous à 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 : 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 : Protection des clés et des artefacts critiques de l’autorité de certification
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: