Chaque tunnel TLS qu'Access Gate construit, et chaque certificat de confiance qu'il présente au lieu d'un certificat auto-signé déclenchant un avertissement du navigateur, repose sur une PKI (infrastructure à clés publiques). La PKI est la chaîne de confiance qui permet à un client de vérifier qu'il parle bien au Gate, et qui permet au Gate d'émettre des certificats pour les actifs qu'il protège. Cette page explique pourquoi cela compte, pourquoi la PKI est généralement la partie difficile, et les deux façons de la déployer avec Access Gate.
Pourquoi une PKI compte
Un certificat ne prouve rien en lui-même ; ce qui le rend digne de confiance, c'est l'autorité qui l'a signé. Une PKI est cette autorité et tout ce qui l'entoure : elle émet des certificats, se porte garante d'eux via une chaîne de signature, et donne à chaque partie un moyen de vérifier qu'un certificat remonte jusqu'à une racine en laquelle elle a confiance.
Sans elle, il vous reste à gérer manuellement des certificats auto-signés, équipement par équipement. Chaque nouvel équipement signifie un certificat non approuvé de plus, un avertissement du navigateur de plus, et un opérateur de plus formé à ignorer l'avertissement censé bloquer une attaque de l'homme du milieu. Une PKI remplace cela par un point d'ancrage de confiance unique : faites confiance à la racine une fois, et chaque certificat situé en dessous est approuvé automatiquement.
Pourquoi la PKI est difficile
La cryptographie n'est pas le problème. C'est le cycle de vie. Un déploiement réel doit résoudre tous ces points en même temps :
- Émission et distribution. Chaque point de terminaison a besoin du bon certificat, et chaque client doit faire confiance à l'émetteur. Acheminer le bon matériel au bon endroit, à grande échelle, représente l'essentiel du travail.
- Listes de confiance. Les deux côtés doivent faire confiance à la chaîne. Un seul certificat intermédiaire manquant ou une racine non approuvée, et la connexion est rejetée, souvent avec une erreur opaque.
- Rotation et expiration. Les certificats expirent par conception. Un certificat expiré est une panne, et renouveler les certificats à la main sur tout un parc est lent et sujet aux erreurs, donc cela traîne.
- Révocation. Quand une clé est compromise, il vous faut un moyen de retirer la confiance accordée à son certificat avant que l'attaquant ne l'utilise.
- Échelle en OT. Les équipements de terrain ne peuvent souvent pas exécuter d'agent de certificats, ou ne peuvent pas être touchés du tout. Une PKI par équipement est tout simplement impraticable pour le matériel qui en a le plus besoin.
C'est pourquoi tant d'installations sous-déploient le chiffrement. Non pas parce que TLS est difficile, mais parce que la prise en charge du cycle de vie des certificats pour des centaines d'équipements l'est.
Comment fonctionne la PKI d'Access Gate
Access Gate exécute une PKI par défaut et utilise un modèle de certificats à deux niveaux qui déplace le cycle de vie hors des équipements, vers le Gate :
- Un certificat intermédiaire, signé par votre autorité de certification, qui ne quitte jamais l'équipement.
- Des certificats terminaux, générés à la volée à partir de l'intermédiaire et remis aux actifs et aux clients pour établir chaque tunnel sécurisé.
Comme les certificats terminaux sont émis à la demande au niveau du Gate, vous ne provisionnez pas les certificats équipement par équipement. Le Gate devient le point d'émission, et les actifs hérités situés derrière lui restent intacts. C'est ce basculement qui rend la PKI praticable dans un parc OT.
L'émission est reliée à votre configuration. Les réseaux (vnets) que vous définissez dans les paramètres d'Access Gate, ainsi que leurs sous-domaines, sont utilisés nativement pour nommer et signer les certificats terminaux que le Gate génère, de sorte qu'il n'y a pas d'étape distincte pour indiquer à la PKI les noms pour lesquels émettre. C'est intégré.
Déploiement : deux options
Choisissez selon la racine à laquelle le parc doit faire confiance.
Option 1 : utiliser la PKI native d'Access Gate
La PKI interne d'Access Gate est une PKI complète que le Gate construit et entretient lui-même : il est la racine et l'autorité de certification, générant et maintenant toute la chaîne sans aucune dépendance externe. Rendez-vous dans Settings → PKI Management et cliquez sur Download TLS certificate. Installez ce certificat sur les machines clientes afin qu'elles fassent confiance aux tunnels sécurisés que le Gate établit.
À utiliser pour les sites qui n'ont aujourd'hui aucun chiffrement et qui veulent la voie la plus simple : vous faites confiance à la racine propre du Gate une fois, et la PKI s'occupe du reste. Idéal pour les laboratoires, les pilotes et les sites autonomes.
Option 2 : chaîner à votre propre autorité de certification
L'option intermédiaire intègre Access Gate à une PKI existante. Au lieu d'être sa propre racine, le Gate se chaîne à l'autorité de certification de votre organisation, de sorte qu'il émet sous une confiance que votre parc reconnaît déjà. Access Gate gère la liste à deux niveaux décrite ci-dessus : l'intermédiaire est signé par votre AC et ne quitte jamais l'équipement, et les certificats terminaux sont générés à la volée à partir de lui.
Les tunnels TLS sont activés dans la page Settings → Networking. Cliquez sur Generate CSR (CSR = demande de signature de certificat) pour obtenir le document de signature, signez-le avec votre autorité racine, puis téléversez le certificat intermédiaire obtenu via Upload SCA.
À utiliser en production et dans les environnements réglementés où les certificats doivent se chaîner à une racine d'entreprise ou de conformité.
Rotation et cycle de vie des certificats
Le modèle à deux niveaux est ce qui rend la rotation gérable :
- Les certificats terminaux effectuent leur propre rotation. Ils sont à courte durée de vie et émis à la demande, de sorte que le Gate les réémet automatiquement. Il n'y a rien à renouveler par actif, ce qui élimine le mode de défaillance à l'origine de la plupart des pannes de certificats.
- L'intermédiaire est le seul certificat que vous possédez. Donnez-lui, ainsi qu'à la racine qui le signe, une validité suffisante (une racine de signature est souvent valide pendant environ 10 ans) et re-signez ou renouvelez l'intermédiaire avant son expiration.
- Surveillez l'expiration de l'intermédiaire et de la racine. Un certificat de signature expiré empêche l'émission de nouveaux certificats terminaux, ce qui casse discrètement les nouveaux tunnels même si ceux qui existent déjà survivent.
- Attention aux paramètres de l'AC. L'AC de signature a besoin d'une profondeur de chaîne suffisante pour émettre un intermédiaire qui émet à son tour des certificats terminaux (profondeur d'au moins 2). Si vous utilisez des restrictions de nom ou de domaine sur l'AC, une bonne pratique, assurez-vous qu'elles couvrent les noms de vnets pour lesquels le Gate émettra.
Pour savoir comment imposer TLS sur une enclave une fois la PKI en place, voir Configurer le chiffrement TLS.
Récapitulatif
Vous avez soit utilisé la PKI native d'Access Gate (téléchargez son certificat et faites-lui confiance sur les clients), soit chaîné le Gate à votre propre AC (générez une CSR, signez-la avec votre racine, et téléversez l'intermédiaire). Dans les deux cas, le Gate émet des certificats terminaux à la volée et enveloppe les actifs dans un TLS de confiance, de sorte que vous gérez un seul intermédiaire au lieu d'un certificat par équipement.
À privilégier avant d'imposer TLS sur les enclaves, lorsque vous avez besoin de certificats de confiance sur tout le parc sans mettre en place et maintenir manuellement un certificat sur chaque équipement.