Depuis plus de 12 ans que CSS aide les organisations à déployer des infrastructures de clés publiques, nous rencontrons fréquemment des situations où des composants PKI sont déjà présents dans l'environnement. Il s'agit souvent d'un ancien site PKI dont une personne nouvellement arrivée dans l'organisation a hérité et qu'elle souhaite évaluer ; il s'agit parfois d'un déploiement "temporaire" qu'une organisation cherche à améliorer. Dans d'autres cas, il peut s'agir simplement d'une conception PKI qu'un client souhaite que nous examinions et que nous lui fassions part de nos commentaires avant le déploiement. Dans tous les cas, ces installations "à faire soi-même", comme n'importe quelle installation PKI, peuvent créer des problèmes, des maux de tête et parfois même des problèmes plus graves si des erreurs sont commises lors de la conception, du déploiement ou de l'exploitation de PKI. Et bien qu'il soit souvent assez facile de déployer les composants PKI , PKI a tendance à être l'une de ces technologies pour lesquelles vous avez exactement une chance de bien faire les choses : au moment de l'installation. Après cela, de nombreux paramètres sont plus ou moins gravés dans le marbre, et un redéploiement devient le seul moyen de corriger une erreur.
Il ne s'agit donc pas d'une liste exhaustive, mais voici cinq des erreurs les plus courantes que nous constatons lorsque nous rencontrons des "bricoleurs" sur le site PKI:
Sur-architecture de la hiérarchie de l'autorité de certification
Pour de nombreux systèmes informatiques, une image vaut vraiment mille mots, et un diagramme des "boîtes et lignes" de l'architecture constitue la majeure partie de la conception. C'est le cas pour les diagrammes de réseau, les architectures d'applications web/bases de données, les structures de répertoires et de nombreux autres composants informatiques. Suivant cet état d'esprit, de nombreux architectes débutants de PKI se concentrent presque exclusivement sur la hiérarchie des autorités de certification : la composition des racines hors ligne, des autorités de certification intermédiaires/politiques et des autorités de certification émettrices en ligne qui composeront le site PKI.
Cependant, si la hiérarchie des AC d'un site PKI est importante pour la conception, elle n'explique pas tout. En fait, ce n'est généralement même pas la majorité de l'histoire, lorsqu'il s'agit d'évolutivité, de disponibilité, de convivialité ou de longévité. Les "boîtes et les lignes" retiennent toute l'attention, mais il y a TELLEMENT beaucoup d'autres décisions de conception qui sont d'une importance égale ou supérieure. Les politiques, les contrôles de sécurité, la planification des LCR et de la révocation, les algorithmes et la taille des clés, ainsi que les périodes de validité sont des exemples de domaines qui peuvent avoir un impact plus important et plus durable sur l'utilité de PKI que la hiérarchie des autorités de certification.
Une focalisation excessive sur la hiérarchie PKI peut conduire à une tendance à inclure davantage de "boîtes et de lignes", ce qui se traduit par des conceptions qui impliquent plus d'AC que nécessaire. Ces AC supplémentaires ont un coût : serveur et HSM hardware, licences de système d'exploitation, en plus des dépenses opérationnelles liées à l'augmentation du nombre de systèmes à surveiller.
Sous-architecture de tout le reste
Parfois, il est trop facile de cliquer sur "Suivant".
Malheureusement, avec PKI, il y a un grand nombre d'aspects de la conception qui, une fois configurés, ne peuvent pas être modifiés sans un redéploiement complet, et comme mentionné ci-dessus, beaucoup d'entre eux peuvent avoir un impact significatif sur l'utilité à long terme de votre PKI. Il s'agit notamment de
- Les noms des certificats de l'autorité de certification, la taille des clés et les algorithmes de signature: Ces éléments font partie du certificat de chaque autorité de certification et ne peuvent être modifiés. Et comme les composants de PKI existent depuis de nombreuses années, les ramifications des choix peuvent être très importantes.
- Points de distribution de CRL (CDP): L'emplacement des CRL est indiqué dans les certificats émis, de sorte que leur modification implique la réémission de chaque certificat.
- Politiques opérationnelles et niveaux d'assurance ciblés: Au moment où vous émettez votre premier certificat - que vous l'ayez prévu ou non - vous venez de définir la politique d'émission de votre AC. Et une fois que vous avez placé la barre à un certain niveau, vous ne pouvez plus l'abaisser.
Beaucoup trop d'ICP sont déployées avec des contrôles de sécurité inférieurs à ceux souhaités, dans le but de gagner du temps ou d'éviter des efforts opérationnels. Il est important de trouver un bon équilibre entre la facilité d'utilisation et un niveau d'assurance suffisamment élevé.
PKI bénéficie d'une structure bien définie pour la définition des politiques et des pratiques, sous la forme d'une politique de certification (CP) et d'une déclaration des pratiques de certification (CPS). Il s'agit d'excellents cadres pour définir les exigences régissant un site PKI, et les moyens par lesquels une mise en œuvre répondrait à ces exigences. La création de ces documents peut être une tâche ardue. Toutefois, il est important de noter qu'il ne suffit pas de copier mot pour mot l'ensemble des documents CP/CPS de quelqu'un d'autre ; ces outils n'ont de valeur que s'ils représentent véritablement de votre Ces outils n'ont de valeur que s'ils représentent réellement les exigences et les processus opérationnels de votre organisation ( PKI ).
Absence de planification du cycle de vie des certificats
L'élaboration d'un processus d'émission - qui soit également sécurisé - peut nécessiter une planification importante. Et si le site PKI est utilisé pour des systèmes embarqués ou des produits ou appareils connectés à un réseau (ce qu'on appelle l'"Internet des objets"), la mise au point d'un processus d'émission sécurisé et en grande quantité est également cruciale.
Cependant, une erreur fréquente lors du déploiement d'applications à base de certificats est de se concentrer uniquement sur le déploiement et sur les tâches liées au déploiement initial de l'application. Or, les certificats expirent, et si la planification n'inclut pas l'ensemble du cycle de vie des certificats, des problèmes majeurs peuvent en résulter. L'expiration inattendue et non gérée des certificats peut entraîner des pannes et des dépenses importantes.
Cette préoccupation n'est d'ailleurs pas exclusivement liée à l'expiration des certificats. En fonction de l'application concernée, la planification d'autres événements liés au cycle de vie des certificats, tels que la révocation ou les processus d'archivage et de récupération des clés, peut s'avérer encore plus importante que la planification du renouvellement des certificats.
Planification de la disponibilité déplacée
La disponibilité est un élément clé de toute conception informatique, mais d'une certaine manière, le site PKI apporte à la disponibilité une "touche" qui n'est pas toujours bien comprise. De la même manière que votre permis de conduire est toujours valide et utilisable lorsque le DMV est fermé, les certificats numériques sont toujours valides et utilisables lorsqu'une autorité de certification est en panne. La seule chose que vous ne pouvez pas faire lorsqu'une autorité de certification est en panne est d'émettre de nouveaux certificats, ce qui, pour la plupart des organisations, n'est pas aussi important que de s'assurer que les certificats existants fonctionnent toujours.
Malgré cette distinction, l'accent est souvent mis sur la disponibilité de CA plutôt que sur celle de CRL ou d'OCSP , qui sont toujours au moins aussi importantes. Si vos CRL ou vos serveurs OCSP ne sont pas disponibles, tous tous vos certificats peuvent devenir inutilisables. La création d'AC émettrices supplémentaires "pour la sauvegarde" résout parfois un problème qui n'a pas besoin d'être résolu, tout en imposant une charge plus importante sur la disponibilité des CRL et OCSP.
Les "gabarits du destin" (Templates of Doom)
La plupart des informations contenues dans ce blog s'appliquent à peu près à tous les sites PKI, quelle que soit l'autorité de certification software utilisée.
Ce dernier point, cependant, s'applique plus directement aux AC basées sur Microsoft. Nous constatons que la majorité de nos clients utilisent les AC Microsoft comme élément de base PKI , d'une part en raison des fonctionnalités et des capacités de software, et d'autre part parce qu'ils possèdent déjà les licences. Mais il y a quelques domaines, en particulier en ce qui concerne les modèles de certificats par défaut, où les utilisateurs peuvent avoir des problèmes.
Une installation "suivante, suivante, suivante" d'un site Microsoft CA aboutira à une autorité de certification déjà configurée pour émettre un certain nombre de certificats différents ; l'un de ces modèles est le "contrôleur de domaine", qui est utilisé par les contrôleurs de domaine pour authentifier les communications entre eux. Il est intéressant de noter que les contrôleurs de domaine sont spéciaux, en ce sens qu'ils sont préprogrammés pour rechercher continuellement des autorités de certification dans l'environnement qui peuvent émettre des certificats de contrôleur de domaine, et lorsqu'ils en trouvent une, ils s'y inscrivent automatiquement. Cela peut ou non poser un problème, mais ce n'est souvent pas le comportement attendu. À moins que des mesures ne soient prises pour l'éviter, après la première installation d'une autorité de certification dans une forêt Active Directory, chaque contrôleur de domaine de la forêt disposera d'un certificat dans les 90 minutes.
Un autre modèle par défaut qui peut avoir des conséquences néfastes est le modèle de certificat "Utilisateur". Le nom de ce modèle est séduisant et il est souvent configuré pour être délivré à un grand nombre d'utilisateurs de l'entreprise. Cependant, ce modèle combine un certain nombre de cas d'utilisation différents, notamment l'authentification, Microsoft EFS et le chiffrement des courriers électroniques. Ces certificats permettent aux utilisateurs de chiffrer des fichiers et des courriers électroniques, mais ne prévoient aucune disposition pour l'archivage des clés, ce qui peut exposer votre organisation à un risque de perte de données si les certificats sont ultérieurement perdus ou supprimés.
