Infrastructure de clé publique (PKI)

de puissants services d’authentification et de canal sécurisé (c’est-à -dire de type SSL et TLS) aux utilisateurs qui accèdent à  vos sites Web.

La mise en place de PKI dans une infrastructure .NET telle que celle qui est illustrée figure 1, peut être complexe. Dans ce scénario, PKI est constitué de quatre composants majeurs : un CA racine offline, un CA subordonné online, un site Web de certification (certificate enrollment) s’exécutant sur la ferme de serveurs Web (pour les utilisateurs Internet) et un ensemble de clients, de machines et d’applications qualifiés pour PKI. Les utilisateurs et applications PKI dans la zone de confiance obtiennent leurs certificats directement du CA émetteur online. Dans cette situation, on est une fois de plus confronté au problème des RPC et des pare-feu – le site Web d’enrollment utilise des RPC pour communiquer avec le CA émetteur online.

Les architectes d’infrastructure .NET doivent répondre à  trois questions cruciales concernant le PKI. Premièrement, à  quoi ressemblera le modèle de confiance PKI ? Un modèle de confiance PKI définit les relations de confiance entre le CA et entre les CA et les entités qualifiées pour PKI. Etablir un modèle de confiance peut être très ardu si l’on implique des CA commerciaux ou des partenaires externes ayant déjà  un PKI en place. Un modèle de confiance doit pouvoir répondre aux questions : quels CA sont dignes de confiance ? et, plus important, quels certificats et clés publiques sont dignes de confiance ? Bien que l’on puisse utiliser la technologie cryptographique pour vérifier la plupart des relations de confiance PKI, on ne pourra pas vérifier les relations de confiance entre les entités qualifiées pour PKI et les points d’ancrage de confiance des CA. La notion de confiance entre des entités qualifiées pour PKI et des points d’ancrage de confiance CA est comparable à  la confiance humaine. Vous faites confiance à  quelqu’un parce que vous le connaissez et que vous pensez qu’il agira correctement. De même, vous pensez qu’un point d’ancrage de confiance CA émettra des certificats dignes de confiance parce que vous savez que l’entreprise qui gère les services CA jouit d’une bonne réputation en la matière, ou parce qu’un représentant de l’entreprise du CA vous a convaincu que le CA est digne de confiance.

Deuxième question : Allez-vous déployer un PKI de provenance interne, externe ou hybride ? Si vous comptez sur des CA du commerce, vous en deviendrez extrêmement tributaire (tout simplement parce que vous avez confié le management d’une partie de votre infrastructure de sécurité à  une société externe). Si la PKI est chargée de protéger des applications qui contiennent des informations très confidentielles, une telle dépendance peut être inacceptable.

Troisième question : Comment échanger des certificats et des listes de révocation de certificats entre les entités qualifiées pour PKI ? Il faut décider comment établir le PKI pour mettre les certificats et les listes de révocation de certificats (CRL, certificate revocation lists) à  la disposition de toutes les entités qualifiées pour PKI. Dans un petit environnement, on peut utiliser un répertoire accessible par LDAP, comme votre AD Win2K interne. Mais les choses se compliquent avec des répertoires multiples (par exemple, les vôtres et un pour chaque partenaire de votre solution .NET).

Bien qu’il reste beaucoup d’autres défis à  relever lors de la mise en place de PKI dans votre infrastructure .NET, ces questions abordent les sujets les plus importants. Il faut se préparer et savoir que concevoir votre PKI ne sera pas aussi simple qu’exécuter le programme de configuration CA (CA setup) dans Win2K.