Conception d'une hiérarchie CA

Vous pouvez ainsi créer une hiérarchie d'autorités de certification comportant jusqu'à cinq niveaux. Autorité de certification privée AWS L'autorité de certification racine, située en haut d'une arborescence hiérarchique, peut avoir un nombre quelconque de branches. L'autorité de certification racine peut avoir jusqu'à quatre niveaux d'autorité de certification subordonnées sur chaque branche. Vous pouvez également créer plusieurs hiérarchies, chacune ayant sa propre racine.

Une hiérarchie d'autorité de certification bien conçue offre les avantages suivants :

• Contrôles de sécurité précis adaptés à chaque autorité de certification

• Répartition des tâches administratives pour un meilleur équilibrage de la charge et une meilleure sécurité

• Utilisation des autorités de certification dont la confiance est limitée et révocable pour les opérations quotidiennes

• Périodes de validité et limites de chemin de certificat

Le diagramme suivant illustre une hiérarchie d'autorité de certification simple à trois niveaux.

Chaque autorité de certification de l'arborescence est soutenue par un certificat X.509 v3 doté d'une autorité de signature (symbolisée par l' pen-and-paper icône). Cela signifie qu'en tant qu'autorités de certification, elles peuvent signer d'autres certificats qui leur sont subordonnés. Lorsqu'une autorité de certification signe le certificat d'une autorité de certification de niveau inférieur, elle confère un pouvoir limité et révocable au certificat signé. L'autorité de certification racine du niveau 1 signe les certificats d'une autorité de certification subordonnée de haut niveau au niveau 2. Ces autorités de certification signent à leur tour des certificats pour les autorités de certification de niveau 3 qui sont utilisés par les administrateurs de l'infrastructure à clé publique (PKI) qui gèrent les certificats d'entité finale.

La sécurité dans une hiérarchie d'autorité de certification doit être configurée pour être la plus forte en haut de l'arborescence. Cette disposition protège le certificat d'une autorité de certification racine et sa clé privée. L'autorité de certification racine ancre la confiance pour toutes les autorités de certification subordonnées et les certificats d'entité finale en dessous. Bien que des dommages localisés puissent résulter de la compromission d'un certificat d'entité finale, la compromission de la racine détruit la confiance dans l'ensemble de la PKI. Les autorités de certification racine et subordonnées de haut niveau ne sont utilisées que rarement (généralement pour signer d'autres certificats d'autorité de certification). Par conséquent, ils sont étroitement contrôlés et vérifiés afin de réduire le risque de compromis. Aux niveaux inférieurs de la hiérarchie, la sécurité est moins restrictive. Cette approche permet les tâches administratives courantes consistant à émettre et à révoquer des certificats d'entité finale pour les utilisateurs, les hôtes d'ordinateur et les services logiciels.

Note

L'utilisation d'une autorité de certification racine pour signer un certificat subordonné est un événement rare qui se produit dans une poignée de circonstances :

• Lorsque la PKI est créée

• Lorsqu'une autorité de certification de haut niveau doit être remplacée

• Lorsqu'un répondeur de liste de révocation de certificats (CRL) ou OCSP (Online Certificate Status Protocol) doit être configuré

Les autorités de certification racine et d'autres autorités de certification de haut niveau nécessitent des processus opérationnels hautement sécurisés et des protocoles de contrôle d'accès.

Validation des certificats d'entité finale

Les certificats d'entité finale dérivent leur confiance d'un chemin de certification menant à l'autorité de certification subordonnée à une autorité de certification racine. Lorsqu'un navigateur web ou un autre client est présenté avec un certificat d'entité finale, il tente de construire une chaîne de confiance. Par exemple, il peut vérifier que le nom distinctif de l'émetteur et le nom distinctif de l'objet du certificat correspondent aux champs correspondants du certificat d'une autorité de certification émettrice. La correspondance se poursuivrait à chaque niveau successif jusqu'à ce que le client atteigne une racine de confiance contenue dans son magasin de confiance.

Le magasin de confiance est une bibliothèque d'autorités de certification approuvées que contient le navigateur ou le système d'exploitation. Pour une PKI privée, le service informatique de votre organisation doit s'assurer que chaque navigateur ou système a précédemment ajouté l'autorité de certification racine privée à son magasin de confiance. Sinon, le chemin de certification ne peut pas être validé, ce qui entraîne des erreurs client.

Le diagramme suivant montre le chemin de validation suivi par un navigateur lorsqu'il est présenté avec un certificat X.509 d'entité finale. Notez que le certificat d'entité finale n'a pas le pouvoir de signature et sert uniquement à authentifier l'entité qui le possède.

Le navigateur inspecte le certificat d'entité finale. Le navigateur trouve que le certificat offre une signature de l'autorité de certification subordonnée (niveau 3) comme informations d'identification d'approbation. Les certificats des autorités de certification subordonnées doivent être inclus dans le même fichier PEM. Alternativement, ils peuvent également se trouver dans un fichier séparé contenant les certificats qui composent la chaîne d'approbation. En les trouvant, le navigateur vérifie le certificat d'une autorité de certification subordonnée (niveau 3) et trouve qu'il offre une signature de l'autorité de certification subordonnée (niveau 2). À son tour, l'autorité de certification subordonnée (niveau 2) offre une signature de l'autorité de certification racine (niveau 1) comme informations d'identification d'approbation. Si le navigateur trouve une copie du certificat d'une autorité de certification racine privée préinstallée dans son magasin de confiance, il valide le certificat d'entité finale comme approuvé.

En règle générale, le navigateur vérifie également chaque certificat par rapport à une liste de révocation de certificats (CRL). Un certificat expiré, révoqué ou mal configuré est rejeté et la validation échoue.

Planification de la structure d'une hiérarchie d'autorités de certification

En général, votre hiérarchie d'autorité de certification doit refléter la structure de votre organisation. Optez pour une longueur de chemin (c'est-à-dire le nombre de niveaux d'autorité de certification) qui ne soit pas supérieure à ce qui est nécessaire pour déléguer les rôles d'administration et de sécurité. L'ajout d'une autorité de certification à la hiérarchie implique l'augmentation du nombre de certificats dans le chemin de certification, ce qui augmente le temps de validation. Le fait de maintenir la longueur du chemin au minimum réduit également le nombre de certificats envoyés par le serveur au client lors de la validation d'un certificat d'entité finale.

En théorie, une autorité de certification racine, qui n'a aucun pathLenConstraintparamètre, peut autoriser des niveaux illimités d'autorités de certification subordonnées. Une autorité de certification subordonnée peut avoir autant d'autorités de certification subordonnées enfants que le permet sa configuration interne. Autorité de certification privée AWS les hiérarchies gérées prennent en charge les parcours de certification CA jusqu'à cinq niveaux de profondeur.

Les structures de CA bien conçues présentent plusieurs avantages :

• Contrôles administratifs distincts pour différentes unités organisationnelles

• La possibilité de déléguer l'accès aux autorités de certification subordonnées

• Une structure hiérarchique qui protège les autorités de certification de niveau supérieur avec des contrôles de sécurité supplémentaires

Deux structures de CA communes accomplissent tout cela :

• Deux niveaux d'autorité de certification : autorité de certification racine et autorité de certification subordonnée

  Il s'agit de la structure d'autorité de certification la plus simple qui permet des stratégies d'administration, de contrôle et de sécurité distinctes pour l'autorité de certification racine et une autorité de certification subordonnée. Vous pouvez maintenir des contrôles et des stratégies restrictifs pour votre autorité de certification racine tout en autorisant un accès plus permissif à l'autorité de certification subordonnée. Cette dernière est utilisée pour la délivrance en bloc de certificats d'entité finale.

• Trois niveaux de CA : CA racine et deux couches de CA subordonnée

  Similaire à ce qui précède, cette structure ajoute une couche d'autorité de certification supplémentaire pour séparer davantage l'autorité de certification racine des opérations d'autorité de certification de bas niveau. La couche d'autorité de certification intermédiaire est utilisée uniquement pour signer les autorités de certification subordonnées qui effectuent l'émission de certificats d'entité finale.

Les structures de CA moins courantes sont les suivantes :

• Quatre niveaux de CA ou plus

  Bien qu'elles soient moins courantes que les hiérarchies à trois niveaux, les hiérarchies de CA comportant quatre niveaux ou plus sont possibles et peuvent être nécessaires pour permettre la délégation administrative.

• Un niveau d'autorité de certification : CA racine uniquement

  Cette structure est couramment utilisée pour le développement et les tests lorsqu'une chaîne complète de confiance n'est pas requise. Utilisée en production, elle est atypique. En outre, elle va à l'encontre de la bonne pratique qui consiste à maintenir des stratégies de sécurité distinctes pour l'autorité de certification racine et les autorités de certification qui émettent des certificats d'entité finale.

  Toutefois, si vous émettez déjà des certificats directement depuis une autorité de certification racine, vous pouvez effectuer la migration vers Autorité de certification privée AWS. Cela offre des avantages en termes de sécurité et de contrôle par rapport à l'utilisation d'une autorité de certification racine gérée avec OpenSSL ou un autre logiciel.

Exemple de PKI privé pour un fabricant

Dans cet exemple, une société de technologie hypothétique fabrique deux produits de l'Internet des objets (IoT), une ampoule intelligente et un grille-pain intelligent. Au cours de la production, chaque appareil reçoit un certificat d'entité finale afin qu'il puisse communiquer en toute sécurité sur Internet avec le fabricant. La PKI de la société sécurise également son infrastructure informatique, y compris le site web interne et divers services informatiques auto-hébergés qui gèrent les opérations financières et commerciales.

Par conséquent, la hiérarchie de CA modélise étroitement ces aspects administratifs et opérationnels de l'entreprise.

Cette hiérarchie contient trois racines, une pour les opérations internes et deux pour les opérations externes (une autorité de certification racine pour chaque ligne de produits). Il illustre également la longueur de plusieurs parcours de certification, avec deux niveaux de CA pour les opérations internes et trois niveaux pour les opérations externes.

L'utilisation d'autorités de certification racines séparées et de couches d'autorités de certification subordonnées supplémentaires du côté des opérations externes est une décision de conception répondant aux besoins commerciaux et de sécurité. Avec plusieurs arborescences de CA, la PKI est à l'épreuve de l'avenir contre les réorganisations, les dessaisissements ou les acquisitions d'entreprises. Lorsque des modifications se produisent, une hiérarchie d'autorité de certification racine entière peut se déplacer proprement avec la division qu'elle sécurise. Et avec deux niveaux de CA subordonnées, les CA racine ont un niveau élevé d'isolement par rapport aux CA de niveau 3 qui sont responsables de la signature en bloc des certificats pour des milliers ou des millions d'articles manufacturés.

Sur le plan interne, les opérations web et informatiques internes de l'entreprise complètent une hiérarchie à deux niveaux. Ces niveaux permettent aux administrateurs web et aux ingénieurs des opérations de gérer indépendamment l'émission de certificats pour leurs propres domaines de travail. La compartimentalisation de la PKI en domaines fonctionnels distincts est une bonne pratique en matière de sécurité et protège chacun contre un compromis susceptible d'affecter l'autre. Les administrateurs web émettent des certificats d'entité finale à utiliser par les navigateurs web dans toute l'entreprise, pour authentifier et chiffrer les communications sur le site web interne. Les ingénieurs des opérations émettent des certificats d'entité finale qui authentifient les hôtes de centre de données et les services informatiques les uns auprès des autres. Ce système permet de sécuriser les données sensibles en les chiffrant sur le réseau local.

Définition des contraintes de longueur sur le parcours de certification

La structure d'une hiérarchie d'autorité de certification est définie et appliquée par l'extension de contraintes de base que chaque certificat contient. L'extension définit deux contraintes :

• cA— Si le certificat définit une autorité de certification. Si cette valeur est false (valeur par défaut), le certificat est un certificat d'entité finale.

• pathLenConstraint— Le nombre maximum d'autorités de certification subordonnées de niveau inférieur pouvant exister dans une chaîne de confiance valide. Le certificat d'entité finale n'est pas pris en compte car il ne s'agit pas d'un certificat CA.

Un certificat d'une autorité de certification racine nécessite une flexibilité maximale et n'inclut pas de contrainte de longueur de chemin. Cela permet à la racine de définir un chemin de certification de n'importe quelle longueur.

Note

Autorité de certification privée AWS limite le parcours de certification à cinq niveaux.

Les autorités de certification subordonnées ont des valeurs pathLenConstraint égales ou supérieures à zéro, en fonction de l'emplacement dans la hiérarchie et des entités souhaitées. Par exemple, dans une hiérarchie avec trois autorités de certification, aucune contrainte de chemin n'est spécifiée pour l'autorité de certification racine. La première autorité de certification subordonnée a une longueur de chemin égale à 1 et peut donc signer des autorités de certification enfants. Chacune de ces autorités de certifications enfants doit nécessairement avoir une valeur pathLenConstraint de zéro. Cela signifie qu'elles peuvent signer des certificats d'entité finale, mais ne peuvent pas émettre de certificats d'une autorité de certification supplémentaires. Limiter le pouvoir de créer de nouvelles autorités de certification est un contrôle de sécurité important.

Le diagramme suivant illustre cette propagation de l'autorité limitée vers le bas de la hiérarchie.

Dans cette hiérarchie à quatre niveaux, la racine est sans contrainte (comme toujours). Mais la première autorité de certification subordonnée a une valeur pathLenConstraint de 2, ce qui empêche ses autorités de certification enfants d'aller plus de deux niveaux plus loin. Par conséquent, pour un chemin de certification valide, la valeur de contrainte doit être décrémentée à zéro dans les deux niveaux suivants. Si un navigateur web rencontre un certificat d'entité finale de cette branche dont la longueur de chemin est supérieure à quatre, la validation échoue. Un tel certificat peut être le résultat d'une autorité de certification créée accidentellement, d'une autorité de certification mal configurée ou d'une émission non autorisée.

Gestion de la longueur des chemins à l'aide de modèles

Autorité de certification privée AWS fournit des modèles pour l'émission de certificats d'entité racine, subordonnée et finale. Ces modèles encapsulent les bonnes pratiques pour les valeurs de contraintes de base, y compris la longueur du chemin d'accès. Les modèles incluent les éléments suivants :

• RootCACertificate/V1

• Certificat CA subordonné _ 0/V1 PathLen

• Certificat CA subordonné _ 1/V1 PathLen

• Certificat CA subordonné _ 2/V1 PathLen

• Certificat CA subordonné _ 3/V1 PathLen

• EndEntityCertificate/V1

L'API IssueCertificate renvoie une erreur si vous tentez de créer une autorité de certification avec une longueur de chemin supérieure ou égale à la longueur de chemin de son certificat d'une autorité de certification émettrice.

Pour de plus amples informations sur les modèles de certificats, veuillez consulter Comprendre les modèles de certificats.

Automatiser la configuration de la hiérarchie CA avec AWS CloudFormation

Une fois que vous avez défini une conception pour votre hiérarchie d'autorité de certification, vous pouvez la tester et la mettre en production à l'aide d'un AWS CloudFormation modèle. Pour obtenir un exemple de modèle de ce type, veuillez consulter Déclaration d'une hiérarchie d'autorité de certification privée dans le Guide de l'utilisateur AWS CloudFormation .