Cinq erreurs courantes à éviter dans le cadre du projet "DIY PKI".

In the 12+ years that CSS has been helping organizations deploy Public Key Infrastructures, we frequently run into situations where PKI components are already present in the environment. Often it’s an older PKI that someone new to the organization has inherited and wants help evaluating; sometimes it’s a “temporary” deployment that an organization is looking to improve upon. In others, it may simply be a PKI design that a customer wants us to review and provide feedback before deployment. In any case, these “Do-It-Yourself” installations, like any PKI, can create problems, headaches, and occasionally even more serious issues if mistakes are made during the design, deployment, or operation of the PKI. And while it’s often quite easy to deploy PKI components, PKI does tend to be one of those technologies where you have exactly one chance to get it right: at install time. After that, many parameters are more or less set in stone, and a re-deployment becomes the only way to fix a mistake.

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

With many IT systems, a picture truly is worth a thousand words, and a diagram of the architecture’s “boxes and lines” makes up a majority of the design. This is the case for network diagrams, web/database application architectures, directory structures, and many other IT components. Following this mindset, many first-time PKI architects focus almost exclusively on the hierarchy of CAs: the makeup of Offline Root(s), Policy/Intermediate CAs, and Online Issuing CAs that will comprise the PKI.

However, while the CA hierarchy of a PKI is important to the design, it’s not the whole story. In fact, it’s usually not even the majority of the story, when it comes to scalability, availability, usability, or longevity. The “boxes and lines” get all the attention, but there are SO many other design decisions that are of equal or greater importance. Policies, security controls, CRL and revocation planning, algorithms and key sizes, and validity periods are some examples of areas that can have a more significant, lasting impact on PKI usefulness than the hierarchy of CAs.

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 enjoys a well-defined structure for policy and practices definition, in the form of Certificate Policy (CP) and Certification Practices Statements (CPS). These are excellent frameworks for defining the requirements governing a PKI, and the means by which an implementation would meet those requirements. Creating these documents can be a daunting task. However, it’s important to note that simply copying someone else’s set of CP/CPS documents verbatim will not suffice; these tools only have value if they truly represent your organization’s PKI requirements and operational processes.

Absence de planification du cycle de vie des certificats

Developing an issuance process – which is also secure — can take a significant amount of planning. And if the PKI is being used for embedded systems or network-enabled products or devices (the so-called “Internet of Things”), developing a secured, high-volume issuance process is also critical.

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.

This concern isn’t exclusively tied to certificate expiration, either. Depending on the application involved, planning for other certificate lifecycle events such as revocation or key archival and recovery processes can be even more important than certificate renewal planning.

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.

Despite this distinction, there is often still more focus on CA availability than CRL or OCSP availability, which are always at least as important. If your CRLs or OCSP servers are not available, all of your certificates can become unusable. Creating additional issuing CAs “for backup” sometimes solves a problem that doesn’t need to be solved, while placing a bigger burden on CRL and OCSP availability.

Les "gabarits du destin" (Templates of Doom)

La plupart des informations contenues dans ce blog s'appliquent à presque toutes les PKI, quel que soit le software AC utilisé.
Ce dernier point, cependant, s'applique plus directement aux AC basées sur Microsoft. Nous constatons que la majorité de nos clients utilisent des AC Microsoft comme élément de base de l'PKI , d'une part en raison des fonctionnalités et des capacités du 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.