Conception d'une hiérarchie CA

Avec Autorité de certification privée AWS, vous pouvez créer une hiérarchie d'autorités de certification comportant jusqu'à cinq niveaux. 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 de subordonnés CAs 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 CAs avec une confiance 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-papericône). Cela signifie qu'CAsils 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. Ceux-ciCAs, à leur tour, signent des CAs certificats de niveau 3 qui sont utilisés par les administrateurs PKI (infrastructure à clé publique) 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 tous les certificats subordonnés CAs et les certificats d'entité finale situés en dessous. Alors que des dommages localisés peuvent résulter de la compromission d'un certificat d'entité finale, la compromission de la racine détruit la confiance dans l'ensemblePKI. Le root et le subordonné de haut niveau ne CAs sont utilisés que rarement (généralement pour signer d'autres certificats CA). 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 le PKI est créé

• 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 de protocole d'état des certificats en ligne (OCSP) doit être configuré

Le root et les autres systèmes de haut niveau CAs nécessitent des processus opérationnels et des protocoles de contrôle d'accès hautement sécurisés.

Valider les certificats d'entité finale

Les certificats d'entité finale tirent leur confiance d'un processus de certification remontant par l'intermédiaire de l'autorité de certification subordonnée CAs à 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 trust store est une bibliothèque de fichiers fiables CAs que contient le navigateur ou le système d'exploitation. Pour un compte privéPKI, le service informatique de votre entreprise doit s'assurer que chaque navigateur ou système a préalablement 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 du subordonné CAs doivent être inclus dans le même PEM fichier. 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é.

Généralement, le navigateur compare également chaque certificat à une liste de révocation de certificats (CRL). Un certificat expiré, révoqué ou mal configuré est rejeté et la validation échoue.

Planifier la structure d'une hiérarchie de CA

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 de subordonnés. CAs Une autorité de certification subordonnée peut avoir autant de subordonnés enfants CAs 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

• Possibilité de déléguer l'accès à un subordonné CAs

• Une structure hiérarchique qui protège le niveau supérieur grâce à des contrôles CAs 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 intermédiaire de l'autorité de certification est uniquement utilisée pour signer les subordonnés CAs chargés de l'émission des 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, cela enfreint les meilleures pratiques qui consistent à maintenir des politiques de sécurité distinctes pour l'autorité de certification racine et pour l'autorité de certification CAs qui délivre les 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 Open SSL ou un autre logiciel.

Exemple de contrat privé PKI 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. L'entreprise sécurise PKI é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 de couches racine séparées CAs et de couches CA 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 arbres de CA, elle PKI est à l'épreuve du temps contre les réorganisations, les cessions 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 d'autorité de certification subordonnée, les racines CAs sont très isolées du niveau 3, CAs qui est chargé de signer en masse les certificats de milliers ou de 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. Le cloisonnement PKI en domaines fonctionnels distincts est une bonne pratique en matière de sécurité et protège chacun d'une compromission 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 protéger les données sensibles en les cryptant sur leLAN.

Définissez 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 de subordonnés de niveau inférieur CAs 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.

CAsLes pathLenConstraint valeurs des subordonnées sont égales ou supérieures à zéro, en fonction de leur emplacement dans le placement hiérarchique et des fonctionnalités souhaitées. Par exemple, dans une hiérarchie à troisCAs, aucune contrainte de chemin n'est spécifiée pour l'autorité de certification racine. Le premier CA subordonné a une longueur de chemin de 1 et peut donc signer un enfantCAs. Chacun de ces enfants CAs doit obligatoirement avoir une pathLenConstraint valeur 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 d'en créer de nouvelles CAs constitue 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 le premier CA subordonné a une pathLenConstraint valeur de 2, ce qui empêche son enfant CAs d'approfondir de plus de deux niveaux. 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.

Gérez la longueur du chemin à 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 :

• ootCACertificateR/V1

• ubordinateCACertificatePathLenS_0/V1

• ubordinateCACertificatePathLenS_1/V1

• ubordinateCACertificatePathLenS_2/V1

• S ubordinateCACertificate _ PathLen 3/V1

• EndEntityCertificate/V1

Un message d'erreur IssueCertificate API sera renvoyé si vous tentez de créer une autorité de certification dont la longueur de chemin est supérieure ou égale à celle du certificat d'autorité de certification qui l'a émise.

Pour de plus amples informations sur les modèles de certificats, veuillez consulter Utiliser des modèles de AWS Private CA certificats.

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

Lorsque 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 .