© 2022 ECSA.MONDE
Conception de site Web

Conception d'une solution PKI

Au cours des derniers jours, j'ai eu un certain nombre de recruteurs qui m'ont approché au sujet d'un contrat qu'ils cherchaient à remplir pour la conception d'une solution PKI. Même si j'ai déjà fait de la conception de PKI et que je suis intéressé à refaire de la conception de PKI, je constate que de plus en plus de recruteurs essaient de me rabaisser pour ce que je fais et, compte tenu de la valeur que j'accorde à mon temps, je commence résister à répondre à ces recruteurs. Cela, combiné au fait que je suis passé au modèle commercial à frais fixes et architecture de sécurité en tant que service, me rend de moins en moins attrayant de passer par des recruteurs. Je préfère de loin travailler avec des partenaires (REMARQUE: Approcher RedBud Cyber si vous recherchez un bon recruteur en cybersécurité. Ils sont un de mes partenaires et revendent mon architecture de sécurité en tant que service).

Cela dit, il y a beaucoup de choses que les gens devraient comprendre sur la conception de solutions PKI et, puisqu'on me demande de remplir un contrat, j'ai pensé que je donnerais quelques réflexions à ceux d'entre vous qui étudient les conceptions PKI. Et si vous cherchez à concevoir une infrastructure à clé publique, faites-le moi savoir et nous pourrons nous asseoir et discuter.

Lorsque vous concevez une solution PKI, ce n'est pas aussi simple que d'installer les services de certificats Windows sur votre serveur Windows. En fait, avec la PKI, l'une des pires choses que vous puissiez faire est de simplement la considérer d'un point de vue technologique. N'oubliez pas que votre solution PKI détiendra les clés de votre royaume. Vous devez donc examiner de manière très professionnelle et détaillée la manière dont vous allez gérer vos certificats et vos paires de clés publiques/privées.

Pour commencer, rappelez-vous que toutes les solutions ont 3 composants de base ; Personnes, processus et technologie. Ceux d'entre vous qui me connaissent comprennent que je crois en fait qu'il y a un 4ème composant et c'est la Gouvernance. Mais je laisserai Gouvernance en dehors de cet article, sinon cet article deviendra un livre.

Une fois que vous avez rassemblé vos exigences pour votre solution (et celles-ci doivent provenir du niveau métier et non du niveau technique), commencez à examiner les couches de vos architectures. Je commencerai par l'architecture métier car elle contiendra à la fois les architectures des personnes et des processus.

Avec l'architecture des personnes, vous allez vouloir créer un RACI pour toutes les personnes impliquées dans votre solution PKI. Il n'y a pas que les administrateurs qui doivent être impliqués. Certains des autres rôles auxquels vous devez penser sont :

  • Demandeur de certificat/clé – Il s'agit de la personne qui a besoin de la sortie de la solution PKI. S'ils sont laissés à eux-mêmes, ils finiront par utiliser des certificats auto-signés et, une fois ceux-ci expirés, vous finirez par résoudre les raisons de l'échec des solutions. Assurez-vous donc de comprendre qui est votre demandeur et comment il va faire ses demandes.
  • Approbateur – Ce n'est pas parce que quelqu'un veut un certificat qu'il doit en obtenir un. Ceci est généralement lié à la gouvernance de vos certificats et clés. Il peut même être propriétaire de la solution PKI.
  • Auditeurs – Certains rôles devront auditer votre système pour garantir l'intégrité de la solution PKI. Peut-être n'avez-vous pas besoin d'un haut niveau d'intégrité – si c'est le cas, peut-être que ce rôle n'est pas trop important. Mais si vous envisagez PCI ou si vous êtes dans le secteur financier (ou si vous traitez avec une infrastructure critique), vous voudrez vous assurer que l'audit est en cours.
  • Analystes de sécurité – Pendant que les administrateurs s'occupent de l'entretien et de l'alimentation du système, vos analystes de sécurité sont généralement l'utilisateur final de la solution PKI. Comprenez comment ils interagiront avec votre solution et quels processus ils utiliseront pour répondre aux demandes.

Ce ne sont là que quelques-uns des rôles auxquels vous devez penser. Et chaque rôle aura ses propres processus qu'il devra gérer (dont certains sont suggérés uniquement dans les descriptions que j'ai fournies).

Puisque nous parlons d'architecture métier, assurez-vous de bien comprendre le modèle financier pris en charge par la solution PKI. Quels sont les volumes de certificats ou de clés à gérer ? S'ils sont d'un volume suffisamment élevé, vous voudrez peut-être remplacer les rôles humains énumérés ci-dessus par une sorte de système automatisé comme ce que fournit Venafi (pas une approbation de Venafi). Ou souhaitez-vous faire appel à un fournisseur de services tiers tel qu'Entrust ou Verasign ? Parfois, vous voudrez avoir un tiers de confiance pour vérifier une partie d'une paire de clés publique/privée. Mais il y a des coûts associés à cela, alors équilibrez les coûts d'utilisation des certificats auto-signés, des tiers de confiance (c'est-à-dire des fournisseurs de services cloud) ou de la construction vous-même. Ce sont les clés de vos principaux atouts, alors prenez la décision judicieusement.

Bon, passons aux composants techniques. Les solutions PKI sont construites autour d'un concept appelé « autorité de certification ». L'autorité de certification (ou CA) est un point central de gestion des certificats et des clés d'une entreprise. Sans l'autorité de certification, vous ne seriez pas en mesure de suivre efficacement tous les certificats ou clés mis en œuvre, vous ne seriez pas en mesure d'assurer une relation de confiance avec les paires de clés publiques/privées, et vous ne seriez pas en mesure de garantir le chiffrement au sein de l'entreprise. est appliqué conformément à vos normes de sécurité.

Il existe généralement 4 composants dans une hiérarchie CA ; l'autorité de certification racine, l'autorité de certification intermédiaire subordonnée, l'autorité de certification émettrice subordonnée et le certificat. Ceux-ci sont illustrés dans le diagramme suivant (tiré du TechNet de Microsoft):

Les certificats numériques créés par une autorité de certification (CA) d'infrastructure à clé publique (PKI) sont vérifiés à l'aide d'une chaîne de confiance. L'ancre de confiance pour le certificat numérique est l'autorité de certification racine (CA), et toute autorité de certification (CA) qui relève de l'autorité de certification racine (CA racine) est connue sous le nom d'autorité de certification (CA) subordonnée. La figure suivante montre la hiérarchie des autorités de certification.

Autorité de certification racine :Une autorité de certification racine est l'autorité de certification (CA) la plus élevée dans une hiérarchie d'autorité de certification (CA). Chaque hiérarchie d'autorité de certification (CA) commence par l'autorité de certification racine et plusieurs branches d'autorité de certification à partir de cette autorité de certification racine dans une relation parent-enfant. Toutes les autorités de certification enfants doivent être certifiées par l'autorité de certification parente correspondante à l'autorité de certification racine. L'autorité de certification racine est conservée dans une zone sécurisée et il s'agit généralement d'une autorité de certification hors ligne autonome (pour en faire l'autorité de certification la plus sécurisée). L'autorité de certification racine fournit des certificats pour les autorités de certification intermédiaires. Les certificats peuvent être révoqués s'ils sont compromis. Je vous recommande de garder l'autorité de certification racine hors ligne, si possible.

CA intermédiaires : Une autorité de certification (CA) intermédiaire est une autorité de certification subordonnée à une autre autorité de certification (autorité de certification racine ou une autre autorité de certification intermédiaire) et délivre des certificats à d'autres autorités de certification dans la hiérarchie de l'autorité de certification. Les autorités de certification intermédiaires sont généralement des autorités de certification hors ligne autonomes telles que les autorités de certification racine.

AC émettrices : Les autorités de certification émettrices sont utilisées pour fournir des certificats aux utilisateurs, aux ordinateurs et à d'autres services. Il peut y avoir plusieurs autorités de certification émettrices, et une autorité de certification émettrice peut être utilisée pour générer des certificats d'ordinateur et une autre peut être utilisée pour générer des certificats d'utilisateur.

Il existe également trois autres composants clés à connaître dans une solution PKI (certaines personnes peuvent en dire plus, mais je suis simpliste pour les besoins de cet article. Il s'agit de votre Active Directory (pour les rôles qui interagissent avec la solution PKI ainsi que l'endroit où vous pouvez stocker vos certificats/clés), vos pare-feu (pour protéger les autorités de certification) et votre HSM (stockage des clés). BTW, configurez votre HSM pour qu'il ait une partition pour chaque sous-autorité de certification.

Une recommandation que je suggérerais est que vous ayez une SubCA (émission) pour chaque domaine. Cela vous permet d'établir des relations de confiance en utilisant l'échange de clés si vous êtes impliqué dans des niveaux de sécurité plus élevés.

Si vous configurez un serveur de certificats basé sur Windows, vous pouvez utiliser des modèles de certificats. Ce sont des modèles qui vous permettent de dupliquer le paramètre des certificats et des clés chaque fois que vous avez besoin d'un nouvel ensemble de certificats. Il existe une liste standard disponible via Windows Server que vous pouvez utiliser si vous le souhaitez.

Lorsque vient le temps d'examiner les algorithmes approuvés, je vous recommande fortement de tirer parti du travail effectué par le NIST. De cette façon, vous n'avez pas à vous tenir au courant des différents algorithmes - laissez le NIST le faire pour vous. Vous pouvez vérifier les algorithmes approuvés sur cette page du NIST.

Il y a un dernier ensemble de détails que vous devez déterminer dans le cadre de votre conception (il y a BEAUCOUP de choses à gérer, alors ne laissez pas cet article vous tromper en pensant que c'est tout ce que vous avez à gérer). Les choses que vous voulez considérer sont :

  • Longueur de la clé - généralement, elle sera définie sur 2048, mais plus elle est longue, mieux c'est (par exemple, 4096 bits)
  • Période de validité – combien de temps les certificats ou les clés seront valides. Cela dépend du type d'autorité de certification effectuant l'émission. Vous voudriez que les certificats de l'autorité de certification racine soient beaucoup plus longs que les autorités de certification émettrices (généralement le double de la durée) et dépendent de la durée pendant laquelle l'équipement qui utilise les certificats/clés sera en place. Les services publics, par exemple, mettront en place des compteurs intelligents avec des durées de vie de +30 ans pour que les clés/certificats soient au moins aussi longs.
  • Point de distribution CRL - vous devez être en mesure de pointer vers l'endroit où la liste de révocation de certificats (CRL) est stockée. Il s'agit généralement de votre Active Directory, mais il peut s'agir de n'importe quel emplacement accessible par les appareils recevant les certificats/clés.
  • Stratégie de sauvegarde et de DR – Vos autorités de certification sont extrêmement importantes pour votre organisation. Vous devez donc être très clair sur la façon dont vous allez sauvegarder les serveurs CA eux-mêmes et sur la stratégie DR pour eux.

Comme je l'ai dit plus tôt, il s'agit d'un article très simpliste sur un sujet complexe. Assurez-vous d'avoir pleinement pris en compte tous les domaines associés à votre certificat et à la gestion des clés. Et si vous avez besoin d'aide, assurez-vous de demander à quelqu'un qui l'a déjà fait.

J'espère que cela t'aides …

Neil