Les questions que vous vous posez

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 - ou la pile Docker Compose publiée avec chaque version. 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.

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

Linux et Windows, en x64 et en ARM64 - et Linux aussi en ARM 32 bits, pour les cartes industrielles -, avec le même binaire natif et le même protocole. Et Android, en ARM 32 et 64, x86 et x64, pour les appareils à fonction dédiée : bornes, terminaux durcis, tablettes de production. Et pour un microcontrôleur, une bibliothèque en C qui parle le même contrat, fournie sur devis et intégrée au firmware de la carte.

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 : SSH, Telnet, SFTP, FTP et FTPS, VNC, RDP, interfaces web, SNMP v2c et v3, caméras RTSP et ONVIF, et tout port TCP déclaré. 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. Avec le réseau PipeLinker, c'est n'importe quel programme du poste qui joint un équipement déclaré par son nom, en TCP comme en UDP : éteint par défaut, il ne résout que les noms déclarés, et chaque programme nouveau est soumis à la personne. 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.

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é porte son identifiant - un mot de passe, une clé, une communauté ou des clés SNMP -, 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. Une session en cours se regarde aussi depuis la console, par une personne qui ne peut rien envoyer, et celle qui est regardée le sait. Un bureau distant supervisé, que le hub décode, s'enregistre et se donne en lecture seule, dans le navigateur comme dans le client RDP du poste ; un bureau relayé, dont le hub ne transporte que les octets, ne s'enregistre pas. Le reste - fichiers, commandes, accès web - entre au journal d'audit : qui, quoi, sur quelle machine, quand, combien de temps.

Peut-on envoyer les journaux dans notre SIEM ?

Oui. Chaque décision d'accès - ouverture, refus, coupure, fin - est un événement daté qui dit qui, depuis quel appareil et avec quelle preuve, vers quelle cible, et pourquoi. Il part en syslog (RFC 5424, en CEF ou en JSON, sur TCP ou TLS), vers Splunk, Microsoft Sentinel ou OpenTelemetry, à plusieurs destinations à la fois, et une destination injoignable reçoit ce qui l'attendait quand elle revient. Le hub signale aussi les anomalies, compte par compte et contre son propre historique : une heure inhabituelle, une adresse ou un pays jamais vus, un appareil nouveau, un volume anormal de sessions ou de refus. Dans chaque offre, sans supplément.

Peut-on se connecter avec notre annuaire, Entra ID ou Google ?

Oui, par OIDC : Entra ID, Google, Keycloak, ou tout fournisseur qui publie son document de découverte, dans chaque offre et sans supplément, sur la console comme dans PipeLinker Desktop et Mobile. Le fournisseur dit qui vous êtes, le hub décide de ce que vous pouvez faire : seuls les comptes déclarés dans le hub entrent, et leurs rôles restent ceux du hub. Quand l'annuaire ferme une session ou désactive un compte, le hub coupe aussitôt ce que la personne tenait ouvert, par la déconnexion côté serveur d'OpenID Connect ou par les signaux partagés CAEP. Un compte administrateur local reste la voie de secours, et chaque connexion par ce chemin est consignée. Pas de SAML pour l'instant, et les comptes ne se créent pas tout seuls depuis l'annuaire.

Les clés FIDO2 et les passkeys sont-elles prises en charge ?

Oui : une YubiKey, la clé intégrée au poste ou la passkey d'un téléphone, en second facteur à la place du code, ou seule, sans mot de passe, sur la console - et en second facteur sur PipeLinker Desktop et Mobile, en USB, en NFC ou par la passkey du téléphone. Un rôle peut l'exiger, les administrateurs aussi. Un geste sensible - changer un droit, toucher au coffre - redemande la clé. Le hub ne garde que la clé publique, et refuse une clé dont le compteur recule : c'est le signe d'une clé clonée, et il est consigné.

Est-ce du ZTNA, Zero Trust Network Access ?

Oui. Personne n'atteint le réseau, seulement un service déclaré, cible par cible, et l'agent appelle en sortant : rien n'écoute sur le site. Chaque accès est jugé sur trois preuves - l'identité, par votre annuaire ou une clé FIDO2 ; un certificat par machine et par appareil ; l'état de l'appareil, prouvé par son TPM ou par sa puce - et sur la sensibilité de la cible. La vérification est continue : ce qui cesse d'être conforme est coupé, et chaque décision part au journal des accès et à votre SIEM. Ce qui reste déclaré : l'antivirus et le chiffrement LUKS ; et le navigateur ne mesure rien.

L'accès Zero Trust en détail

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, et une clé de sécurité aussi. Un accès est limité à une destination et à une durée, et se retire en un geste, qui coupe aussitôt ce qu'il permettait. Une cible peut être marquée sensible ou critique, et exiger alors une clé, un appareil attesté, l'enregistrement de la session ou une approbation ; des plages horaires et des règles d'origine s'y ajoutent. Une revue des accès, trimestrielle par défaut, fait reconfirmer les droits permanents par leurs responsables. Deux rôles sont livrés pour les cas courants : « Intégrateur », qui déclare les services des machines qui lui sont confiées sans pouvoir élargir ce qu'elles autorisent, et « Sécurité », qui lit et acquitte les alertes, et rien d'autre.

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

Oui, de deux façons. Le droit lui-même peut avoir une durée - une heure, une journée, jusqu'à une date - ou une fenêtre à venir, comme un permis de travail : « demain de 8 h à 12 h », sessions enregistrées, et il se retire seul. Le prestataire peut aussi le demander, et un responsable l'approuve, depuis la console ou depuis son téléphone. Et 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 la minute. É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.

Que compte la licence ?

Des agents installés - une machine qui porte l'agent -, des utilisateurs, des parcs isolés et des services - ce qu'on ouvre à travers un agent, sur la machine ou sur un équipement derrière elle. 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 - selon l'offre, et 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.