Exemples de 1) une autorité de certification intermédiaire dans une hiérarchie de confiance ouverte et 2) une hiérarchie privée isolée d'une hiérarchie ouverte avec sa propre autorité de certification racineL'infrastructure à clé publique (PKI) a toujours été hiérarchique. Dans ce document, les autorités de certification (AC) sont liées par des relations de subordination. Tous les utilisateurs font confiance à la même autorité de certification racine (tête) et chaque autorité de certification inférieure est subordonnée à une autorité supérieure dans la hiérarchie.
Mais que se passe-t-il si nous voulons créer une
infrastructure PKI privée avec notre propre autorité de certification? En effet, dans certaines situations, de telles hiérarchies intermédiaires ou partielles sont très pratiques en pratique.
Raisons typiques de la création d'une hiérarchie intermédiaire ou privée
- Authentification client
Il est pratique de faire l'authentification client avec des certificats basés sur une autorité de certification intermédiaire. Si vous disposez d'une autorité de certification subordonnée exclusive, vous pouvez limiter le nombre de certificats donnant accès au système. Dans ces cas, les hiérarchies d'approbation privées sont généralement utilisées.
- Image de marque
Pour les entreprises qui offrent des certificats à leurs clients ou les incluent dans le package de services fournis, la présence de leur propre autorité de certification dédiée vous permet d'offrir des opportunités de branding supplémentaires.
- Inspection / décryptage SSL / TLS
Pour qu'un vérificateur SSL déchiffre et rechiffre le contenu, il doit pouvoir émettre des certificats selon les besoins. Cela signifie que vous avez besoin de votre propre autorité de certification secondaire en dehors de la hiérarchie publique de confiance. Dans ce cas, l'autorité de certification racine se trouve sur GlobalSign et l'autorité de certification intermédiaire se trouve sur le périphérique de vérification des certificats du client.
- Certificats spéciaux
Les certificats émis au sein de hiérarchies privées peuvent prendre en charge les applications héritées et les configurations uniques, telles que des périodes de validité plus longues et des tailles de clé plus petites, qui ne sont pas autorisées dans les certificats de confiance publics conformément aux exigences de base du CA / Browser Forum. Cependant, si vous n'avez besoin que de certificats SSL / TLS privés, sans autorité de certification privée à part entière, vous pouvez utiliser le service IntranetSSL .
- Profils personnalisés
Vous pouvez configurer l'autorité de certification subordonnée pour des tâches spécifiques en modifiant les stratégies d'extension de clé, les stratégies de certificat, le point de distribution des listes de révocation de certificats (CRL) selon vos besoins, la création de certificats à court terme, etc.
Hébergement et soutien
Une entreprise peut héberger et gérer ses propres autorités de certification ou les externaliser. De nombreuses entreprises entreprennent elles-mêmes le déploiement de systèmes PKI à grande échelle (infogérance), sans disposer des ressources nécessaires pour cela. Étant donné que le processus nécessite des investissements, il est préférable de pré-évaluer vos ressources matérielles et vos capacités financières au moment et dans les années à venir, l'effet économique de l'utilisation de nouvelles technologies, les coûts initiaux et le coût de fonctionnement du système.
Après avoir effectué une telle évaluation, certaines organisations peuvent conclure qu'elles n'ont pas besoin d'une infrastructure à clé publique et, dans leur cas, il est préférable d'utiliser d'autres outils de sécurité: par exemple, un VPN ou des programmes de cryptage de fichiers. Au lieu de l'ensemble de l'infrastructure PKI, il est parfois plus facile de démarrer uniquement un serveur de certificats, ce qui résout les problèmes d'accès non autorisé au contenu Web (IntranetSSL, voir ci-dessus).
Hiérarchie intermédiaire ou privée
Dans une hiérarchie ouverte, toutes les autorités de certification sont subordonnées à l'autorité de certification racine, dont la clé publique est intégrée dans une application publique, telle qu'un navigateur Web. Dans ce cas, le navigateur peut vérifier automatiquement la validité des certificats émis par toutes les autorités de certification de toute la hiérarchie, ainsi que par leurs éditeurs, ce qui est un avantage incontestable.
Les hiérarchies ouvertes sont généralement utilisées dans les cas où l'échange d'informations avec des parties non affiliées ou leur authentification est requis. La troisième partie de confiance dans ce cas est l'autorité de certification externalisée.
Dans le cas d'une hiérarchie privée, l'utilisateur final ajoute manuellement la clé publique de l'autorité de certification racine d'entreprise à la liste des clés de confiance incorporées dans l'application. Dans ce cas, la responsabilité de l'utilisation de la clé incombe à l'utilisateur. Les hiérarchies privées conviennent mieux aux communautés fermées, par exemple aux utilisateurs d'un portail d'entreprise.
Exemples typiques de hiérarchie intermédiaire ou privée
- Autorité de certification racine privée et hiérarchie dédiées (PKI privée)
GlobalSign peut créer et héberger des hiérarchies privées, y compris racine et intermédiaire. Ils sont construits sur la même infrastructure sécurisée qui est utilisée pour prendre en charge leurs propres autorités de certification racine dans une hiérarchie ouverte.
- Corporate Private Intermediate CA, Centre d'émission de certificats
Les autorités de certification intermédiaires de marque sont créées spécifiquement pour un client particulier, avec une chaîne de confiance à l'autorité de certification racine dans une hiérarchie ouverte. Ces nœuds intermédiaires peuvent également être hébergés et maintenus par GlobalSign, ce qui allège le fardeau de la gestion de l'ICP et des connaissances d'experts pour les équipes internes.
- Autorité de certification racine ouverte partagée (plate-forme PKI gérée)
Bien que dans certaines situations, des autorités de certification et des hiérarchies racine dédiées soient requises, la plupart des organisations peuvent satisfaire aux exigences réglementaires en matière de certificats à l'aide de services spécialisés sur la plate-forme de gestion PKI (Managed PKI) . Le portail de gestion des certificats tout-en-un offre une facturation, une gestion des utilisateurs, des rapports et bien plus encore.
- Autorité de certification racine privée partagée (IntranetSSL)
IntranetSSL , disponible via la plate-forme de gestion PKI, fournit un moyen économique d'émettre et de gérer des certificats SSL / TLS pour les serveurs et applications internes. Ces certificats sont émis par une autorité de certification publique et non publique GlobalSign, ils peuvent donc inclure des configurations que le forum CA / Browser interdit d'utiliser dans les certificats publics (par exemple, valables plus de trois ans, noms de serveurs internes ou adresses IP réservées).
- Racine de confiance IoT
Les racines de confiance IoT ont la même flexibilité que les racines de confiance traditionnelles, mais sont adaptées aux exigences spécifiques de l'IoT. Des hiérarchies privées dédiées, des AC intermédiaires de marque accessibles au public, des centres racine dans une hiérarchie ouverte ou privée peuvent être utilisés pour protéger les appareils IoT, les plates-formes, les passerelles et les réseaux en fonction du niveau de confiance requis.
- Hiérarchie spéciale de la confiance
GlobalSign prend en charge presque toutes les configurations de hiérarchie. Si vous avez besoin d'un modèle différent de celui décrit ci-dessus, ou si vous ne savez pas immédiatement quelle architecture est la mieux adaptée à un écosystème particulier, il est préférable de discuter avec un spécialiste et un consultant pour construire une architecture de confiance qui répond à des besoins spécifiques.
Pour l'un des exemples ci-dessus, le support CA peut être externalisé. L'image de marque est toujours possible, mais les hiérarchies sont hébergées et gérées par GlobalSign dans des centres de données sécurisés avec du matériel et des logiciels éprouvés. Les scénarios non standard seront aidés par des ingénieurs d'escorte.
Il semble que donner votre hiérarchie de confiance à l'externalisation, vous abaissez le niveau de sécurité, mais dans la pratique, c'est l'inverse. Cela garantit que tous les composants CA sont correctement protégés et configurés conformément aux meilleures pratiques du secteur. Un avantage supplémentaire est l'économie de coûts et de charge de ressources sur les équipes internes pour prendre en charge l'ICP. Ce n'est que dans de rares cas (par exemple, vérification / décryptage SSL) que le lien intermédiaire doit être localisé chez le client.
