Questions fréquentes

Les questions que vous vous posez

Ce qui revient le plus souvent avant de se décider. Si la vôtre n'y est pas, écrivez-nous votre situation - le type d'équipement, le réseau, où vous pouvez héberger, qui doit accéder - et nous répondrons dessus.

Déploiement

Ce qu'il faut pour que ça tourne chez vous, et ce qu'il ne faut pas.

PipeLinker, c'est une passerelle ou un bastion ?

Les deux, et ce sont deux fonctions distinctes plutôt que deux produits. La passerelle rassemble : l'agent posé sur une machine IT, OT ou IoT appelle le hub en sortant, remonte son état et rend joignable ce qui vit derrière lui. Le bastion contrôle : qui entre, sur quelle cible, avec quels droits, et ce qu'il en reste au journal. Le hub porte les deux, et c'est pour cela qu'il n'y a pas de port à ouvrir : ce qui relie et ce qui contrôle sont au même endroit. Le mot que l'industrie emploie aujourd'hui pour la seconde moitié est ZTNA, accès réseau Zero Trust ; la question « Est-ce du ZTNA ? » dit ce qu'il recouvre ici, et où il s'arrête.

Faut-il ouvrir un port sur le site distant ?

Non. L'agent établit lui-même une connexion sortante et chiffrée vers le hub, et tout passe dedans : télémétrie, commandes, mises à jour, accès distant. Aucun port entrant à ouvrir, aucune règle de pare-feu à obtenir, aucune adresse fixe à demander à l'opérateur.

Où sont stockées les données ?

Chez vous. PipeLinker Hub est auto-hébergé : un binaire et une base PostgreSQL, sur la machine de votre choix. Vos procédures de sauvegarde et de supervision PostgreSQL s'appliquent telles quelles.

Le produit fonctionne-t-il sans accès à Internet ?

Oui. Rien n'appelle un service extérieur pour fonctionner : un réseau totalement isolé convient, ce qui est le cas courant en milieu industriel. Les binaires des agents et des applications se déposent alors à la main sur le hub.

Combien de temps prend l'installation ?

Une adresse publique, deux noms qui y pointent - la console et la porte des agents -, un certificat qui les porte, une base PostgreSQL, et le paquet Debian du hub, qui pose le reste en sept questions. Une équipe qui tient déjà un serveur le fait seule, avec la documentation ; la mise en service que nous proposons s'achète pour aller vite et l'esprit tranquille, pas parce qu'elle est indispensable.

Comment le hub et les agents se mettent-ils à jour ?

Les agents se mettent à jour depuis le hub, par un déploiement progressif que vous déclenchez : un canari, un groupe de test, puis le reste, et chaque binaire est signé avant d'être accepté. Le hub, lui, peut aller chercher les versions sur notre portail si vous l'activez - c'est un réglage, désactivé au départ, quatre vérifications par jour que vous pouvez régler - ou recevoir les fichiers que vous déposez vous-même.

Pourquoi PostgreSQL seul, et pas TimescaleDB ?

Parce que les fonctionnalités de TimescaleDB qui justifieraient de l'adopter ne sont pas sous licence libre, et qu'un produit livré chez vous vous imposerait alors ses conditions d'emploi. Nous sommes restés sur PostgreSQL nu, avec nos propres tables d'agrégation.

Compatibilité

Les machines, les systèmes, et ce qui vit derrière l'agent.

Sur quels systèmes l'agent fonctionne-t-il ?

Linux et Windows, en x64 comme en ARM64, avec le même binaire natif et le même protocole - systèmes embarqués compris. Et Android, en ARM 32 et 64, x86 et x64, pour les appareils à fonction dédiée : bornes, terminaux durcis, tablettes de production.

Que fait l'agent Android, et que ne fait-il pas ?

Il porte la télémétrie, l'inventaire des applications, les commandes, les mises à jour signées, un terminal, les fichiers et les tunnels vers les équipements du réseau local - dans les limites qu'Android laisse à une application non rootée : le terminal tourne sous l'identité de l'agent, dans son bac à sable, et les fichiers sont les dossiers que l'appareil a accordés. Il ne sert pas son propre écran - c'est une autorisation qu'on ne lui demande pas -, mais l'écran d'un équipement derrière lui s'atteint par le tunnel, comme depuis n'importe quel agent. Le tableau de la page des agents le dit case par case.

Peut-on atteindre l'interface web d'un équipement situé derrière l'agent ?

Oui. Le hub ouvre l'IHM web de l'équipement dans votre navigateur, à travers la connexion de l'agent, sans VPN et sans client à installer. L'accès est authentifié par le hub et tracé comme le reste.

Et les automates qui ne peuvent pas porter d'agent ?

Un agent posé sur une machine du même réseau leur sert de passerelle. On déclare le service dans la console - son adresse, son port, son protocole - et il devient joignable à travers l'agent : interface web, SSH, SFTP, VNC, RDP, ou un port brut. Rien à installer sur l'automate, et rien d'ouvert sur le site.

Peut-on garder nos logiciels habituels, client d'automate ou bureau distant ?

Oui, avec PipeLinker Desktop sur le poste de travail. Il ouvre un mandataire local pour votre navigateur et redirige un port local vers un service déclaré : votre client d'automate, votre client de base de données ou l'outil du constructeur joignent l'équipement par son nom, sans qu'on réécrive une adresse. Un bureau distant s'ouvre dans le client du poste, en un bouton.

Y a-t-il une application mobile ?

Oui, PipeLinker Mobile, sur Android : la flotte, la carte et les trajets, les alertes. Et sur une machine, un terminal, les fichiers, un écran VNC, un bureau RDP, les pages web internes. Elle s'inscrit par un code à usage unique obtenu dans la console ; le mot de passe du hub n'y entre jamais. Android seulement, pour l'instant.

Sécurité

Qui entre, avec quoi, et ce qu'il en reste.

Comment un appareil s'authentifie-t-il ?

Par un certificat client qui lui est propre, jamais par une clé d'API partagée par tout le parc. La clé privée est engendrée sur l'appareil et n'en sort pas. La révocation est individuelle et immédiate.

Où vit la clé privée ?

Dans le meilleur abri que la machine offre. Sur le poste de travail, dans le TPM - par le magasin de clés sous Windows, par /dev/tpmrm0 sous Linux -, puis à défaut le magasin logiciel et un fichier scellé par DPAPI, ou un fichier lisible par le compte seul. Sur Android, dans le Keystore, lié au déverrouillage. Sur l'agent, un fichier créé avec ses droits restreints dès l'écriture. Une sauvegarde restaurée ailleurs ne transporte aucune identité.

Que se passe-t-il si une machine est compromise ?

On révoque son certificat depuis la console, et le hub la refuse à la poignée de main TLS, avant qu'un octet ne soit lu. Les autres machines n'ont rien en commun avec elle : chacune a sa propre identité, et chaque parc sa propre autorité de certification, ce qui fait échouer une identité d'un parc sur un autre.

Où sont conservés les identifiants des machines ?

Dans le hub, et scellés. Un service déclaré - SSH, RDP, VNC, une interface web - porte son identifiant et son mot de passe, que le hub chiffre avec une clé qui vit dans sa configuration et jamais dans la base. Le sceau est lié à sa ligne : la table, la colonne et la clé primaire entrent dans le calcul, donc recopier un secret scellé d'un parc vers un autre ne l'ouvre pas. L'intervenant, lui, reçoit le droit d'ouvrir la session, pas le mot de passe de la machine. Ce que cela protège : une base volée, une réplique, une sauvegarde prise par un tiers, une base infogérée. Ce que cela ne protège pas, et il vaut mieux le dire : root sur le hub, ou du code qui tourne sous son identité, lisent la configuration comme lui.

Les sessions sont-elles enregistrées ?

Les sessions de terminal et d'écran s'enregistrent et se rejouent, avec un curseur de temps. Un bureau distant décodé par le hub peut être enregistré ou donné en mode supervisé, en lecture seule. Le reste - fichiers, commandes, accès web - entre au journal d'audit : qui, quoi, sur quelle machine, quand, combien de temps.

Est-ce du ZTNA, Zero Trust Network Access ?

Sur le principe oui, sur toute son étendue non, et la nuance se dit plutôt qu'elle ne se laisse deviner. Ce qui y est : personne n'atteint le réseau, seulement un service déclaré, cible par cible ; l'agent appelle en sortant, rien n'écoute sur le site ; chaque machine et chaque appareil porte son propre certificat, la clé privée ne sort pas de l'abri matériel où elle est née, et le hub refuse une chaîne pourtant valide dont l'autorité n'est pas celle du parc auquel l'agent appartient ; les droits se donnent par rôle, par parc et par cible, avec un second facteur exigible par rôle, et se retirent en un geste. Ce qui n'y est pas : le hub ne juge pas l'état du poste depuis lequel on se connecte. Ni son chiffrement, ni son niveau de correctif, ni son antivirus, et il ne réévalue rien pendant la session. Il sait en revanche où vit la clé du poste - puce de sécurité ou simple fichier -, si le déverrouillage biométrique y est actif et quelle version y tourne : il enregistre ces faits, il n'en fait pas une condition d'entrée. Un ZTNA qui juge la posture réclame un agent sur le poste de l'intervenant, y compris celui du prestataire que vous n'administrez pas. Nous avons choisi l'identité et le cloisonnement plutôt que la posture.

Qui a le droit de faire quoi ?

Les droits se donnent par rôle et par parc, à des personnes nommées : voir, ouvrir une session, envoyer une commande, déployer une mise à jour, administrer. Un second facteur peut être exigé par rôle. Un accès est limité à une destination et à une durée, et se retire en un geste.

Peut-on donner un accès à un prestataire pour la durée du chantier ?

Oui. Le compte porte une date de fin : passée l'échéance il n'ouvre plus rien, et la session déjà ouverte se ferme dans l'heure - sans ce balayage, une échéance à midi voudrait dire à midi, ou au prochain redémarrage de son navigateur. Échu n'est pas désactivé : reculer la date suffit à le faire rentrer, sans rien d'autre à défaire. L'exploitation est prévenue avant l'échéance, sept jours par défaut et réglable, et le message part à ceux qui peuvent prolonger plutôt qu'à celui qui perd l'accès. Un administrateur, lui, ne peut pas porter de date : c'est une règle de la base et non de la console, pour qu'un hub ne se retrouve jamais sans personne pour y entrer.

Le produit aide-t-il à répondre au Cyber Resilience Act ?

Sur la partie que le parc doit savoir dire, oui : inventaire des paquets installés avec un identifiant normalisé, export CycloneDX par machine, recherche d'un paquet dans tout le parc, mises à jour signées et journal d'audit. Il ne produit pas le SBOM de votre propre logiciel et ne fait pas lui-même le rapprochement avec les bases de vulnérabilités.

Licence

Ce qu'on compte, ce qu'on ne compte pas, et ce qui se passe à l'échéance.

Que compte la licence ?

Des équipements - une machine où l'agent est installé -, des comptes, des parcs isolés et des services déclarés. Jamais les sessions, les connexions ni les minutes : ouvrez dix terminaux ou deux cents, la facture ne bouge pas. Tout le hub est dans chaque offre ; ce qui varie, c'est la taille, et les deux applications, Desktop et Mobile.

Faut-il une licence par site, ou par client ?

Non. Une seule instance, une seule licence, et un parc par site ou par client à l'intérieur : chacun a ses gestionnaires, ses droits, ses agents, et ne voit pas les autres. Le nombre de parcs est un plafond de la licence, comme les équipements et les comptes - deux, trois ou dix selon l'offre, autant que de clients au sur mesure. Il est large à chaque palier parce qu'un parc est une cloison logique que le hub porte de toute façon : ce qui fait le prix, ce sont les machines et les comptes, pas les cloisons entre elles.

Que se passe-t-il si la licence expire ?

Le hub continue de tourner, et il ne refuse jamais de démarrer. Les agents restent connectés, la télémétrie remonte, les alertes fonctionnent, la console s'ouvre et le parc se consulte. Ce qui s'arrête, c'est ce qui touche à une machine : ouvrir une session, envoyer une commande, enrôler un appareil. La console vous prévient trente jours avant.

Une question qui n'est pas là ? Posez-la nous