Brevet FR2838593A1 — publié le 20031017

couleur. Il est fréquent d'avoir de multiples installations informatiques (appelées par la suite " sites clients ") physiquement dispersées, pouvant être de types et natures variées et appartenir à des entités administratives différentes, et qui doivent étre accédées à partir d'un ou quelques sites informatiques centraux. Ceci se produit en particulier lors de l' installation ou de la mise à j our de logiciels, de transLert de fichiers, de correction de dysfonctionnements, et plus généralement lors de toutes opérations d'administration,-maintenance, exploitation, prise de main à distance, ou autres sur les sites clients. Une opération de ce type est appelée par la suite téléintervention. Habituellement la compétence informatique est faible sur les sites clients, au moins dans le domaine concerné par l'intervention, et intervenir à distance permet en particulier de motuaIiser 0 la compétence informatique rare et chère d'opérateurs qualifiés, dirnuer les coûts et/ou procurer un meilleur service. On rencontre en particulier cette situation dans le cas de SSII et vendeurs informatiques devant fournir support et assistance à un parc installé. Les accès au site client doivent étre sécurisés, afin en particulier d'éviter les intrusions, offrir un débit de données adapté aux opérations à effectuer pour notamment fournir un bon confort - d'utilisation, être fiables et disponibles (intervention possible à toute heure, caractère d'urgence...), ne pas nécessiter d' intervention du personnel des sites clients, être d'une installation et d'une mise en _uvre facile et souple y compris dans des environnements .. informatiques hétérogénes, et être économiques, particu,iièrement lors de la mise en _uvre et l'exploitation, spécialement dans le cas d'interventions longues ou sur des sites géographiquement éloignés. - I1 n'existe pas actuellement de procédé d'accès satisfaisant pleinement ces contraintes. A titre d'exemple, un réseau privé d'entreprise n'est pas utilisable pour des entreprises -., multiples; les réseaux virtuels privés proposés par des compagnies de télécommunication sont 2s chers, laisser sur chaque site client une machine disposant d'un accès entrant ouvert depuis l'Internet est t-ès dangereux sans une excellente compétence informatique locale pour le .. protoger et éviter les intrusions, etc. En pratique, la majorité des systèmes de téléintervention utilisent le réseau téléphonique standard, avec des modems, et parfois un encryptage, des mots de passe et/ou un rappel automatique. Cette solution présente de nornbreux désavantages, en particulier un débit de donnces limité et non adaptable, une liaison peu fiable tant lors de l'établissement que dans la durée, un temps d'établissement important, une sécurité aléatoire et un coût important. Le procédé objet de l 'invention permet de réaliser de tel s accès sans les inconvénients indiqués. I1 permet de raccorder d'une manière raisonnablement sécurisoe les sites clients à 1'Internet tout en permettant aux sites centraux d'y accéder. -2 Pour cela, le site client comporte au moins une machine (le client) disposant d'un accès au moins sortant (direct ou via pare-feu, etc.) et le site central comporte une machine (le serveur) disposant d'un accès au moins entrant sur l'Internet ou un réseau ou environnement utilisant le protocole TCP/IPOn appelle unité d'exécution un objet exécutant une suite d'instructions sur une machine; cela correspond, selon les environnements, à un processus, une tâche, un ttread, un démon, etc. À l'initiative du client (au démarrage par exemple), une unité d'exécution cliente établit une connexion selon les protocoles de l'Internet vers une unité d'exécution située sur le serveur, crée un canal de communication bidirectionnel (appelé par la suite socket) entre les deux, et envoie une flux de données simulant une question. Les deux unités d'exécution peuvent être physiquement sur le méme site ou la méme machine. Ainsi, vu du réseau et des systèmes de sécurité du site client, on a affaire à une communication sortante habituelle. Tant que le site central ne désire pas se connecter, le serveur ne répond pas, ou peut aussi renvoyer périodiquement ou non des donnces de remplissage pour garder le socket ouvert. Si, pour une raison quelconque, par exemple à cause d' une trop grande période d' inactivité, le socket se ferme, le client peut en recréer un nouveau de manière identique; dans ce cas, à réception de cet appel entrant du méme client, le serveur peut fermer l'ancien, et considérer le nouveau comme étant le socket actiú Quand le s*e central désire se connecter, le serveur répond en envoyant la requete désirée sur le socket actif, en l'habillant pour qu'elle devienne, vu de l'extérieur, la charge utile de la réponse à la requete du site client. Le client répond à cette question par une réponse habillée pour étre la charge utile d'une question au sens du protocole utilisé. La suite du dialogue s'effectue soit par l'intermédiaire dudit socket resté ouvert, so* grâce à de nouveaux sockets crées de manière similaire par le client, soit par un mélange de ces méthodes. Suivant les modes de réalisation et les protocoles utilisés, certaines questions, tant réelles que au sens du protocole utilisé peuvent comporter aucune ou plusieurs réponses, et certaines questions et réponses au sens du protocole utilisé peuvent ne pas étre utilisées et ne servir que de remplissage par exemple. On réalise ainsi une connexion crcée physiquement à l' initiative du site client, mais logiquement à l' initiative du site central, dans laquelle transite des questions au sens du protocole utilisé émises par le client, dont au moins certaines comportent dans leur charge utile des réponses à des questions logées dans la charge utile de réponses au sens du protocole utilisé émises par le serveur. La première question au sens du protocole utilisé émise par le client peut comporter dans sa charge utile des informations sur l'état de l'unité d'exécution cliente et son environnement. Par ailleurs, le client peut initialiser autant de liaisons que nocessaire à des moments judicieusement choisis (par exemple et à titre non limitatif lors de la première réception de données en provenance du serveur) de sorte qu' il y ait touj ours une liaison disponible. - 3 Procéder ainsi permet notamment au site client d'interdire (via un pare-feu par exemple) toute connexion entrante sans impacter le fonctionnement du procédé, ce qui est un avantage de sécurité très important car on supprime ainsi la grande majorité des possibilités d' intrusion. Cela évite aussi toute les contraintes d'adressage, routage et résolution de noms liés à la réalisation s d'une connexion entrante. Le site central accepte les communications entrantes, mais cela ne pose pas de problèmes de sécurité cruciaux car, en général le site central dispose de compétences informatiques pour effectuer un paramétrage correct, et de plus, il est beaucoup plus facile de sécuriser un seul site qu'une multitude. Ce procédé est très économique car, contrairement au téléphone par exemple, les connexions TCP/IP ne sont habituellement tarifées ni à la durée, ni au volume, ni à la distance, ni au nombre de liaisons actives mais selon la bande passante disponible de la liaison. Lorsque aucune opération de téléintervention n'est en cours, la totalité de cette bande passante est disponible pour d'autres usages (typiquement courrier électronique et accès à la toile mondiale); en cas d'activité, la bande passante est facilement partagée sans opération particulière à effectuen De plus, très fréquemment, une liaison Internet permanente existe déjà sur le site client, et peut être utilisée par le système de téléintervention, supprimant ainsi tous investissements et dépenses télécoms supplémentaires liées à la téléintervention. Ce procèdé procure un bien meilleur confort d'utilisation que le téléphone, car, contrairement à ce dernier, les liaisons Internet sont en général permanentes, et de plus disponibles en de multiples classes de détit, permettant ainsi un ajustement souple et facile aux besoins. De plus, ces types de liaisons sont identiques au niveau mondial sans variantes ni licences spécifiques locales, contrairement aux réseaux de type téléphone ou RNIS. I1 est possible d'utiliser tout protocole sur le socket, donc en particulier des protocoles standards 2s comme par exemple HITP, HI1PS ou SOAP. Procéder ainsi permet en particulier au client grâce à l'utilisation de syntaxes, protocoles et/ou adresses judicieuses de générer des liaisons similaires à celles effectuées habituellement par le site client, et donc difficilement discernables de celles-ci, tout du moins par les dispositifs de sécurité locaux. Par exemple, il est possible de simuler le comportement d'un utilisateur ordinaire connocté à l'Intemet via son poste de travail, type de connexion quasiment toujours autorisé par les dispositifs de protection (pare feux par exemple) et le réseau informatique du site client. Ainsi, aucune modification desdits dispositifs n' est nécessaire lors de l ' installation sur le site client. De méme, les connexions peuvent être authentifiées et encryptées, grâce par exemple à l'utilisation de protocoles et algorithmes à clé publique ou privée, et/ou de certificats, et/ou de 3s tiers certificateurs, et/ou de signatures numériques. - 4 - Les connexions peuvent aussi encapsuler tout autre protocole, permettant ainsi en particulier dans la charge utile le multiplexage (cas du protocole PPP par exemple) de plusieurs flux d'informations entrants et/ou sortants, et/ou la réalisation de passerelles entre programmes, etlou la transmission d'informations de toute nature (par exemple audio ou vidéo) entre les sites. De méme les unités d'exécution client etlou serveur peuvent jouer un rôle d'aiguilleurs en routant etlou multiplexantldémultiplexant les requêtes etlou données reçues vers etlou depuis un opérateur etiou des dispositifs quelcouques (à titre non limitatif. caméras, microphones, capteurs, actionneurs, systèmes d'acquisition/restitution du son, de l'image ou de la vidéo...) etlou autres unités de traitement etlou autres systèmes, et en renvoyant les réponses vers ceux-ci. La liaison peut aussi ne pas être permanente. Dans ce cas, le client a toute latitude pour établir la liaison, par exemple selon des tranches horaires ou la survenance de tout type d'événements (alarmes, dysfonctionnements...), ou demande d'un opérateur du site client. I1 est possible de redonder les connexions etlou unités d'exécution, coté client etlou serveur, afin de se prémunir d'éventuels dysfonctionnements et améliorer la disponibilité de l' ensemble. Dans ce cas, selon un mode prétérentiel d'exécution de l'invention, I'ensemble est judicieusement agencé de manière qu'en cas d'unité etlou de connexion déLaillante, une autre unité etlou une autre connexion prenne le relais, afin de maintenir etlou rétablir la liaison. Un exemple non limitatif de mise en _uvre de l'invention est représenté sur la figure 1). Le site client comprend la machine cliente (1) connectée au réseau Internet (11) via un routeur et un pare-feu non représentés empêchant toute connexion entrante, sur lequel tourne un démon (2) activé au démarrage de la machine, supportant les protocoles SOAP et HTIP. L'opérateur (9) accède au site central via un logiciel de navigation (browser WEB) standard en utilisant les protocoles HP et HTML, à travers le réseau Internet (11). Le site central se compose d'un serveur (10) fonctionnant sous système d'exploitation multitâches connecté au réseau Internet (11) via un routeur et un pare-feu non représentés. Sur ce serveur fonctionne un serveur WEB standard (4), l'ensemble étant paramétré de sorte qu'un processus (5) soit exécuté à réception d'une requête SOAP reçue sur l'URL (3) émis par le démon (2) et que le processus (7) soit exécuté à réception d'une requête HTML reçue sur 1'URL (8) envoyée par l'opérateur (9), grâce à une interface CGI par exemple. Un démon (6) est activé sur (10) au démarrage, auquel peuvent se connocter les processus (5) et (7) par un mécanisme à base de sockets par exemple. Les étapes des échanges et actions des différents composants sont les suivantes: À Etape 1): Au démarrage, (2) envoie une requête vide SOAP (X) sur 1'URL (3) géré par le serveur WEB (4), ce qui active (5) qui se connecte à (6) via un socket, transmet la requête et 3s attend une réponse sur celui-ci. Le résultat de cette action est que (6) note dans ses tables internes les coordonnées de (2) - 5 - À Etape 2): Quelque temps après (9) envoie une requête HTML réelle (Y) sur l'URL (8) géré par 14), ce qui active (7) qui se connecte à (6) via un socket, transmet la requete et attend une réponse sur celui-ci. À Etape 3): (6) code et met en forme cette requête HTML afin qu'eile soit syntaxiquernent vue comme la réponse à la requ8te SOAP (Xj, et renvoie le résultat à (5), qui le transmet au serveur WEB (4) qui lui-méme le retransmet à (2). À Etape 4): (2) reçoit cette pseudo réponse SOAP, qui est en réalité la question contenue dans la requete HML (Y), calcule la réponse à cette question, la code et la met en forme alEin qu'elle soit syntaxiquement vue comme une requête SOAP (), et renvoie ce résultat sur 0 l'URL (3) géré par (4), ce qui active (5) qui le transmet à (6). (2) est alors dans le méme état qu'à la fin de l'étape l). À Etape 5): (6) décode et met en forme cette pseudo requete afin de fabriquer une réponse HTML qui est transmise à (4) qui la retourne à l'opérateur (9) en tant que réponse à la requête HTML (Y). Les étapes 2) à 5) peuvent être répétées indéLiniment. Les processus (4)7 (5), (6), et (7) peuvent étre implémentés de manière séparée ou non selon les environnements informatiques. Concernant les étapes l) à 5): Vu de l'opérateur, (9) a envoyé une question H1tML à (l), et reçu peu de temps après une réponse HTML. Vu du serveur WEB, (l) a envoyé une requete SOAP à (l0), a reçu une réponse SOAP peu de temps après, puis a renvoyé une autre requete SOAP qui est en attente de réponse. Vu de l'Internet, (l) n'a reçu aucun appel entrant ni requête et en a émis deux. On réalise donc l' obj et de l'invention, c' est à dire une communication physiquement à l'initiative du client, mais logiquement à l'initiative du serveur. Ce procédé peut étre utilisé en particulier dans les logiciels, solutions et systèmes de télémaintenance, télé exploitation, transfert de fichiers, télé-administration, télésurveillance, télédifusion ou télé-collecte de fichiers, logiciels ou autres, télé-mise-àjour de sites, applications ou autres, consolidation d'informations et/ou de données. -6 REVENDICATIONS 1) Procédé d'établissernent et de déroulement d'une liaison informatique selon les protocoles de l'Internet entre une unité d'exécution cliente située sur un site client et une unité d'exécution serveur située sur un site serveur, lesdites unités pouvant être physiquement sur le même site et/ou la même machine, caractérisé en ce que l'lmité cliente établit la connexion vers l'unité serveur, que l'unité cliente envoie au sens du protocole utilisé des questions et recoit au sens du protocole utilisé zéro ou plusieurs réponses à chaque question, et que la charge utile de certaines réponses au moins est en réalité une question de l'unité serveur, et la charge utile de certaines questions au moins est en réalité une réponse à une question de l'unité serveur, la première question au sens du protocole utilisé émise par 1'unité cliente servant de remplissage pour respecter le protocole utilisé. 2) Procédé selon la revendication précédente, caractérisé en ce qu'il est utilisé dans des logiciels, solutions et systèmes de télérnaintenance, téléexploitation, transtert de fichiers, télé administration, télésurveillance, télédiffusion ou télé-collecte de fichiers, logiciels ou autres, télé-mise-àjour de sites, applications ou autres, consolidation d'informations et/ou de données. 3) Procédé selon l'une quelconque des revendications précèdentes, caractérisé en ce que la charge utile de la première question au sens du protocole utilisé émise par l'unité cliente contient en réalité au moins partiellement des informations sur l'état de l'unité d'exécution cliente et de son environnement. 4) Procèdé selon l'une quelconque des revendications précèdentes, caractérisé en ce que l'unité cliente initialise plusieurs liaisons à des moments judicieusement choisis de sorte qu'il y en ait toujours au moins une disponible. ) Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que les protocoles et/ou la syntaxe et/ou les adresses utilisés rendent la liaison similaire aux autres liaisons s'effectuant habituellement sur le site client etlou diffcilement discernable de celles-ci. 6) Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que tout ou partie des données entrantes et/ou sortantes est encrypté et!ou authentifié ettou signé numériquement. 7) Procédé selon l'une quelcouque des revendications précédentes, caractérisé en ce que les charges utiles des questions et/ou des réponses au sens du protocole utilisé sont organisées de manière à multiplexer plusieurs flux d'information entrants et/ou sortants. 8) Procédé selon l'une queleanque des revendications précédentes, caractérisé en ce que l'unité de traitement serveur etlou l'unité de traitement client effectue un routage et/ou un multiplexage/démultiplexage de données en provenance et/ou à destination de dispositifs et/ou systèmes et/ou unités de traitement et/ou opérateurs humains. 9) Procédé selon l'une quelcouque des revendications précédentes, caractérisé en ce qu'il existe des unités de traitement supplémentaires sur le site client et/ou le site serveur, etlou qu'il existe plusieurs possibilités de connexion entre lesdites unités, et que l'ensemble est agency de sorte qu'en cas d'unité et/ou de connexion déLaillante, une autre unité et/ou une autre connexion