Les certificats clients ou utilisateurs peuvent être comme un mauvais vin : une véritable migraine !
06 Feb ‘25

La mise en œuvre de certificats clients ou utilisateurs au sein d’un système d’Infrastructure à Clé Publique (PKI) offre des avantages de sécurité robustes, mais s’accompagne de défis significatifs, notamment à grande échelle. De nombreux spécialistes PKI rencontrent des obstacles lors du déploiement, de la gestion et de l’engagement des utilisateurs. Dans cet article, nous examinerons les défis associés à la mise en œuvre de certificats clients, en mettant l’accent sur les problèmes liés à l’émission et à la distribution, à l’expiration et au renouvellement, à la révocation, à la scalabilité et à l’interopérabilité, à la sécurité, à la complexité, aux coûts et à l’expérience utilisateur. Des exemples concrets illustreront chaque défi pour fournir des idées pratiques sur la gestion de la PKI

Émission et distribution

L’émission et la distribution de certificats clients sont essentielles mais s’avèrent souvent difficiles en raison de la nécessité d’une authentification sécurisée, de l’intégration aux systèmes de gestion des identités et des méthodes de distribution efficaces. L’émission implique généralement la génération d’une paire de clés, la création d’une demande de signature de certificat (CSR) et sa signature par une Autorité de Certification (AC). Par exemple, considérons une institution financière qui émet des certificats à ses employés pour accéder à des applications sécurisées. Avant d’émettre, l’institution doit avoir une méthode pour vérifier l’identité de chaque employé, ce qui est souvent réalisé par l’intégration à un système de gestion des identités et des accès (IAM) tel qu’Active Directory.

La distribution sécurisée peut être particulièrement difficile. Certaines organisations utilisent des jetons matériels ou des cartes à puce pour renforcer la sécurité, mais celles-ci nécessitent une distribution physique, ce qui entraîne des coûts logistiques et temporels. D’un autre côté, les méthodes de distribution basées sur des logiciels, bien que plus rapides, exigent un stockage sécurisé des clés sur les appareils. Par exemple, un prestataire de soins de santé distribuant des certificats clients à des cliniciens peut utiliser un outil basé sur un logiciel pour installer les certificats sur chaque appareil, mais garantir que la clé privée est stockée en toute sécurité dans le Trusted Platform Module (TPM) de l’appareil peut s’avérer difficile sur des appareils plus anciens ou non conformes.

Un processus de distribution rationalisé est essentiel mais difficile à réaliser. Les organisations doivent également créer des processus de récupération en cas de certificats perdus ou compromis, ce qui complique encore la distribution.

Expiration et renouvellement

Gérer l’expiration et le renouvellement des certificats est vital pour éviter les interruptions de service et les risques de sécurité. Contrairement aux mots de passe, les certificats opèrent souvent en arrière-plan, ce qui rend facile pour les utilisateurs d’oublier leur existence jusqu’à leur expiration. Une expiration inattendue peut perturber les flux de travail, comme cela a été observé dans une grande organisation de vente au détail où des certificats ont expiré simultanément pour plusieurs systèmes de point de vente (POS), entraînant une panne temporaire mais coûteuse.

L’automatisation aide à atténuer ces problèmes, mais elle est complexe à mettre en œuvre, surtout si différents systèmes ne prennent pas en charge les protocoles de renouvellement automatisés. Par exemple, l’utilisation du protocole Automated Certificate Management Environment (ACME) a rationalisé le renouvellement des certificats serveur mais reste un défi pour les certificats utilisateurs nécessitant une vérification d’identité. Une agence gouvernementale dont les employés utilisent des certificats sur des appareils mobiles pourrait trouver difficile d’automatiser les renouvellements sur des appareils plus anciens ou multiplateformes, car les systèmes d’exploitation mobiles varient dans leur prise en charge des normes PKI.

Les organisations doivent également rappeler aux utilisateurs les dates d’expiration imminentes, ce qui nécessite souvent des notifications personnalisées. Les institutions financières, par exemple, pourraient envoyer des rappels via des systèmes de messagerie sécurisés, intégrant les notifications dans leurs plateformes de gestion du travail pour réduire le risque de renouvellements manqués.

Révocation

La révocation est essentielle pour atténuer les risques si un certificat est compromis ou n’est plus nécessaire, mais sa gestion à grande échelle présente de multiples défis. La révocation implique la publication d’une Liste de Révocation de Certificats (CRL) ou l’utilisation du Protocole d’État de Certificat en Ligne (OCSP). Le défi s’aggrave avec la taille des CRL ; si trop de certificats sont révoqués, les CRL deviennent volumineuses, consommant des ressources réseau et ralentissant le processus. Une entreprise de télécommunications mettant en œuvre des certificats clients sur des appareils de terrain, par exemple, pourrait rencontrer des retards dans la distribution de CRLs mises à jour, rendant les techniciens de terrain incapables d’authentifier leurs appareils en temps réel.

L’OCSP offre une solution plus évolutive en permettant aux clients de vérifier le statut de révocation en temps réel, mais cela nécessite une infrastructure supplémentaire pour maintenir les répondants OCSP. Un prestataire de soins de santé avec des centaines d’appareils mobiles ferait face à des défis pour s’assurer que chaque appareil vérifie le statut de révocation, surtout s’ils sont parfois hors ligne. Pour atténuer l’impact, certaines organisations mettent en œuvre le stapling OCSP, permettant aux serveurs de mettre en cache et de mettre à jour périodiquement les réponses OCSP, mais cela ajoute également de la complexité aux configurations de serveur et au dépannage.

Assurer la compréhension par les utilisateurs finaux du processus de révocation est tout aussi difficile. Par exemple, dans une entreprise de fabrication, les utilisateurs pourraient résister aux procédures de révocation s’ils estiment que leur certificat devrait encore être valide, en particulier si la révocation perturbe l’accès à des applications essentielles.

Scalabilité et Interopérabilité

La scalabilité devient une question centrale à mesure que les organisations étendent leurs mises en œuvre PKI à travers des départements, des emplacements géographiques ou des bases de clients. De nombreux systèmes PKI ne sont pas optimisés pour l’émission et la distribution à grande échelle. Considérons une entreprise de logistique internationale avec des milliers d’appareils répartis dans le monde entier ; élargir la capacité de leur AC pour gérer des millions de certificats signifie aborder la latence réseau et l’équilibrage de charge.

L’interopérabilité ajoute une autre couche de difficulté. Les organisations ont souvent des systèmes divers — divers systèmes d’exploitation, applications et dispositifs réseau qui doivent tous interagir de manière transparente au sein de la PKI. Par exemple, une entreprise multinationale peut déployer des certificats clients sur un mélange de systèmes mobiles, de bureau et anciens, chacun prenant en charge différents algorithmes cryptographiques. Lorsque ces systèmes plus anciens interagissent avec de nouveaux déploiements PKI, des incompatibilités dans le support des protocoles ou la force cryptographique peuvent poser des problèmes de compatibilité, certaines appareils pouvant ne pas prendre en charge les derniers protocoles ou algorithmes.

Les spécialistes PKI ont besoin d’une connaissance approfondie des normes telles que X.509 et PKCS pour les interfaces de jetons cryptographiques. Même dans ce cas, assurer l’interopérabilité dans un environnement mixte peut être exigeant en ressources. Des tests sont nécessaires pour identifier et résoudre les problèmes de compatibilité, nécessitant souvent des correctifs personnalisés ou des mises à niveau de systèmes anciens.

Préoccupations de sécurité

Les préoccupations de sécurité sous-tendent chaque aspect de la PKI, mais elles sont particulièrement pertinentes dans les mises en œuvre de certificats clients, où compromettre une clé privée peut compromettre l’intégrité de l’ensemble du système. Sécuriser les clés privées sur les appareils clients reste un défi. Par exemple, une entreprise de services financiers utilisant des certificats clients pour l’authentification sur les ordinateurs portables des employés peut exiger des solutions de stockage de clés basées sur du matériel telles que des TPM ou des modules de sécurité matériels (HSM). Ces solutions sécurisent efficacement les clés mais ajoutent des coûts et des exigences logistiques significatifs, car les TPM peuvent ne pas être disponibles sur tous les appareils ou peuvent ne pas supporter les mêmes configurations de sécurité.

Les attaques de phishing et l’ingénierie sociale posent également des risques, car les attaquants pourraient essayer de tromper les utilisateurs pour qu’ils révèlent des informations sur les certificats. Une grande entreprise, par exemple, pourrait être confrontée à des campagnes de phishing ciblant les employés pour accéder à leurs certificats, surtout si ces certificats sont utilisés pour des applications privilégiées. Former les employés à identifier les tentatives de phishing est essentiel mais difficile, car tous les utilisateurs ne comprennent pas les complexités techniques de la PKI, les rendant vulnérables à l’ingénierie sociale.

Établir des processus de sauvegarde et de récupération sécurisés est essentiel pour gérer les appareils perdus ou endommagés, mais cela ajoute encore une autre couche de complexité à la sécurité. Le processus n’est pas seulement un défi technique ; il exige également le développement de politiques et de protocoles pour garantir que les certificats perdus sont remplacés sans exposer le système à un accès non autorisé.

Complexité

La complexité inhérente de la PKI est un autre obstacle, car elle exige une expertise en cryptographie, gestion des identités et infrastructure réseau. Par exemple, considérons un système hospitalier tentant d’intégrer des certificats clients dans son réseau pour une communication sécurisée. Coordonner les politiques d’émission et d’utilisation avec différents départements, de l’administration aux opérations cliniques de terrain, implique une collaboration étendue et une application des politiques. Les politiques PKI doivent tenir compte de la durée de vie des certificats, des critères de révocation, des restrictions d’utilisation et des procédures de renouvellement, chacune nécessitant une configuration précise sur une variété d’appareils et de systèmes.

Même avec une expertise technique, la coordination entre les départements requise pour établir et faire respecter les politiques PKI peut être exigeante. De plus, des configurations strictes pour faire respecter les politiques de sécurité peuvent dégrader l’expérience utilisateur. Des restrictions excessives ou des procédures d’installation trop complexes peuvent mener à la frustration des utilisateurs finaux, comme observé dans les établissements d’enseignement où les étudiants ont du mal à accéder aux ressources réseau en raison d’exigences de certificats complexes sur les appareils mobiles.

Coûts

La mise en œuvre de la PKI est gourmande en ressources, tant en termes d’infrastructure que de capital humain. Établir une PKI avec des certificats clients nécessite une Autorité de Certification dédiée, des points de distribution de CRL potentiellement redondants, des répondants OCSP et potentiellement des modules de sécurité matériels. Par exemple, une agence gouvernementale mettant en œuvre la PKI pour l’authentification des employés peut investir massivement dans l’infrastructure AC, ainsi que dans des HSM pour sécuriser des certificats de grande valeur, sans compter les coûts associés à l’entretien de la redondance réseau.

Les coûts opérationnels augmentent également la charge financière. Les spécialistes PKI sont hautement qualifiés, et leur expertise a un coût. De plus, la formation et le soutien aux utilisateurs finaux contribuent aux dépenses continues. Une entreprise qui introduit des certificats clients peut nécessiter une équipe de support à temps plein pour gérer les problèmes liés aux certificats, augmentant ainsi le coût total de possession. Avec chaque couche de complexité ajoutée – comme le développement personnalisé, les tests d’interopérabilité ou les améliorations de sécurité – les coûts de mise en œuvre augmentent.

En plus des coûts d’infrastructure et de personnel, il existe des dépenses indirectes liées à l’indisponibilité des utilisateurs si la PKI n’est pas gérée efficacement. Par exemple, si l’expiration d’un certificat affecte l’accès du PDG à une application critique, la perte de productivité qui en résulte se traduit par un impact financier au-delà des dépenses directes de la PKI.

Expérience utilisateur

L’expérience utilisateur (UX) est souvent un aspect négligé de la mise en œuvre de la PKI. Cependant, elle impacte directement l’adoption et le succès global du système PKI. Le cycle de vie du certificat comprend l’émission, l’installation, le renouvellement et parfois la révocation – tous des points de contact que les utilisateurs doivent naviguer. Si l’expérience est complexe, les utilisateurs peuvent résister ou ne pas terminer les tâches, entraînant ainsi des pertes de productivité et des équipes de support frustrées.

Considérons un cabinet d’avocats mettant en œuvre des certificats clients pour ses employés afin d’accéder à des documents clients sécurisés. Si le processus nécessite une installation manuelle de certificats, les avocats ayant des compétences techniques limitées peuvent faire face à des défis, créant une frustration et, potentiellement, une résistance au système. Dans ce cas, l’installation automatisée pour les appareils gérés, combinée à un soutien clair et accessible, peut réduire les perturbations pour les utilisateurs et améliorer la conformité. Les notifications concernant les expirations à venir doivent être claires et fournir des étapes exploitables ; sinon, le cabinet risque que ses avocats soient incapables d’accéder à des fichiers essentiels lorsque les certificats expirent.

Une autre considération UX critique consiste à gérer l’expérience des utilisateurs non techniques. Par exemple, une entreprise de fabrication qui émet des certificats clients à des travailleurs de première ligne pour l’authentification des appareils doit équilibrer le besoin de sécurité avec une interface intuitive. Former les employés à utiliser des certificats sans les surcharger de détails techniques est essentiel. Des supports de formation utilisateur adaptés à divers niveaux de compétence peuvent aider à l’adoption mais nécessitent un temps de développement et des ressources supplémentaires.

Quelques obstacles que KeyTalk a dû surmonter avec ses clients

Les solutions de Gestion des Dispositifs Mobiles (MDM) préfèrent souvent des protocoles plus anciens comme NDES/SCEP pour demander des certificats clients. Cependant, des solutions modernes comme Microsoft Intune ne prennent pas en charge le protocole SCEP « standard ». Au lieu de cela, Microsoft a développé une variante dans laquelle le défi SCEP est vérifié par Intune et non par le serveur SCEP. Par conséquent, KeyTalk CKMS a dû être mis à jour pour prendre en charge les deux variantes du protocole SCEP. Cette mise à jour permet aux solutions MDM utilisant l’implémentation SCEP originale, comme JAMF, d’être soutenues tout en accommodant également Intune.

Un autre défi que nous avons rencontré était une exigence d’un client concernant des certificats clients machines sur des systèmes Linux, où le TPM était utilisé pour sécuriser la clé privée du certificat. Étant donné qu’aucune solution existante n’était disponible, KeyTalk a répondu à ce besoin en étendant nos agents Linux pour prendre en charge le TPM 2.0 et en permettant l’authentification à l’aide de jetons Kerberos. Cette approche déclenche le processus de signature CSR pour obtenir le certificat client machine.

Un proxy SCEP est une méthode où un point d’extrémité demande un certificat en utilisant le protocole SCEP via un serveur intermédiaire qui agit comme le serveur SCEP mais relaie simplement la demande SCEP au véritable serveur SCEP. Pour activer la fonctionnalité de proxy, KeyTalk a veillé à ce que notre solution prenne en charge la traduction de la confiance de l’AC, évitant ainsi toute rupture du protocole SCEP.

Conclusion

La mise en œuvre de certificats clients dans des environnements PKI apporte de forts avantages en matière de sécurité mais également de nombreux défis techniques et opérationnels. Les spécialistes PKI doivent aborder l’émission, la distribution, l’expiration et la révocation des certificats tout en gérant la scalabilité et l’interopérabilité. Les préoccupations de sécurité, telles que la protection des clés privées et la lutte contre les risques de phishing, ajoutent à la complexité, et l’expertise requise peut faire grimper les coûts, rendant la PKI un investissement considérable.

Pour optimiser les bénéfices, les organisations devraient prioriser l’automatisation, la distribution conviviale et l’interopérabilité. Le renouvellement automatisé et des orientations claires pour les utilisateurs peuvent aider à réduire les frictions, rendant la PKI à la fois sécurisée et pratique. Se tenir informé des nouveaux protocoles et aligner les objectifs de sécurité sur les besoins opérationnels sont essentiels à un déploiement PKI réussi.

KeyTalk CKMS étend encore ces capacités en offrant des possibilités supplémentaires :

Intégration flexible avec les solutions MDM : KeyTalk CKMS prend en charge une intégration fluide avec les plateformes MDM populaires comme Microsoft Intune et JAMF, garantissant un déploiement sécurisé et automatisé des certificats à travers des écosystèmes de dispositifs divers.
Protection avancée des clés : En intégrant le soutien TPM 2.0 pour les systèmes Linux et un stockage sécurisé des clés privées, KeyTalk garantit que les clés sensibles sont bien protégées, même dans des environnements complexes.
Fonctionnalité de Proxy SCEP : KeyTalk CKMS peut agir en tant que proxy SCEP, simplifiant les demandes de certificats provenant des points d’extrémité et garantissant une traduction de confiance sans perturber le protocole SCEP. Cela améliore la scalabilité et la flexibilité dans les déploiements à grande échelle.
Modèles de certificats personnalisables : Les organisations peuvent définir et gérer plusieurs modèles de certificats adaptés à leurs besoins de sécurité uniques, de l’authentification des utilisateurs à cryptage des emails S/MIME et à l’identité machine.
Contrôle d’accès basé sur les rôles (RBAC) granulaire : Avec le RBAC, les administrateurs peuvent déléguer des tâches spécifiques de gestion PKI de manière sécurisée, maintenant l oversight tout en permettant une efficacité opérationnelle.
Rapports complets et journaux d’audit : KeyTalk CKMS fournit des journaux détaillés et des rapports pour la conformité et les audits de sécurité, offrant aux organisations une visibilité complète sur les activités des certificats.
Améliorations de protection contre le phishing : En tirant parti de la PKI pour le cryptage des emails et les signatures numériques, KeyTalk aide à atténuer les risques de phishing en garantissant l’authenticité et l’intégrité des emails.

En tirant parti de ces fonctionnalités, les organisations peuvent réaliser un environnement PKI plus sécurisé, efficace et prêt pour l’avenir qui s’aligne sur leurs objectifs opérationnels et de sécurité.

—

Curieux de savoir ce que les certificats d’authentification clients ou utilisateurs peuvent signifier pour votre organisation ? Contactez-nous en remplissant le formulaire de contact ci-dessous pour plus d’informations et découvrez comment nous pouvons optimiser la gestion de vos certificats.

L’équipe KeyTalk