Brevet FR2869490A1 — publié le 20051028

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, 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 à jour de logiciels, de transfert 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 mutualiser la compétence informatique rare et chère d'opérateurs qualifiés, diminuer 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é, ou dans le cas d'organisations possédant de multiples succursales ou agences géographiquement dispersées. 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 oeuvre facile et souple y compris dans des environnements informatiques hétérogènes, et être économiques, particulièrement lors de la mise en oeuvre et l'exploitation, spécialement dans le cas d'interventions longues ou sur des sites géographiquement éloignés. Il 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 chers; laisser sur chaque site client une machine disposant d'un accès entrant ouvert depuis l'Internet est très dangereux sans une excellente compétence informatique locale pour le protéger et éviter les intrusions, etc. Un procédé atteignant partiellement ces objectifs a été développé par NETFISH TECHNOLOGIES INC (WO 01 73522 A, 2001-10-04), mais ce procédé nécessite obligatoirement l'utilisation d'un protocole type question / réponse (par exemple HTTP) dans lequel sont encapsulées les données, et ne permet pas de transmettre sans artifices lourds et complexes des flux de données continus, qui sont produits lors de l'affichage d'écrans et de prise de contrôle à distance de systèmes informatiques, par exemple lors de 1 utilisation du logiciel VNC ou de ses dérivés. En pratique, la majorité des systèmes de téléintervention utilisent deux modes d'accès: - Soit 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 nombreux désavantages, en particulier un débit de données 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, en particulier à cause des frais téléphoniques. Soit un accès depuis l'Internet, ce qui oblige à ouvrir un port TCP du site client à l'extérieur, et donc re paramétrer le pare-feu du site, opération complexe, dangereuse à cause des risques de piratage et donc le plus souvent interdite par le règlement de sécurité de l'entreprise. Le procédé objet de l'invention permet de réaliser de tels accès sans les inconvénients indiqués. Il permet en particulier d'accéder aux sites clients depuis l'Internet sans ouverture sur le site client de ports TCP entrants ou sortants, ni re paramétrage des systèmes de sécurité (parefeu, proxy...) du site client. Il permet donc à des opérateurs extérieurs d'accéder a un ou des clients protégés via un ou des sites centraux ( les serveurs). On appelle unité d'exécution (UE) un objet exécutant une suite d'instructions sur une machine; cela correspond physiquement, selon les environnements, à un processus, une tâche, un thread, un démon, etc. On appelle serveur informatique (en abrégé : serveur ) une UE qui reçoit des requêtes et renvoie des réponses à travers un ou plusieurs canaux de communication. Un protocole informatique est la définition précise (nature, syntaxe, etc.) des requêtes et des réponses possibles. On appelle proxy (pluriel: proxies ) un serveur informatique situé entre une UE client et un autre serveur, qui intercepte toutes les requêtes de l'UE client vers cet autre serveur et renvoie les réponses à l'UE client. Soit le proxy possède déjà la réponse en cache, soit il fait suivre la requête à l'autre serveur et renvoie à l'UE client la réponse reçue. Il existe des proxies pour chaque protocole informatique (HTTP, FTP, SOAP...). On utilise en général un proxy pour des raisons de performance ou de sécurité (filtrage et audit des requêtes). Typiquement, le site client est installé de manière à permettre à ses utilisateurs de surfer sur le WEB, via les protocoles H11 P et HTTPS. Pour cela, les requêtes vers le WEB émises par la machine à laquelle on cherche à accéder transitent le plus souvent à travers un proxy HTTP, puis un routeur effectuant souvent une translation d'adresses TCP/IP, puis un pare-feu qui en général interdit tous les accès entrants (pas de port ouvert vers l'extérieur) et n'autorise les accès sortants que s'ils sont originaires de ce proxy. Le site serveur (à partir duquel on désire accéder à la machine cliente) 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/IP. Pour réaliser l'accès objet de l'invention, l'UE client à laquelle on veut accéder va établir avant toute opération un tunnel permettant de faire librement circuler des données de et vers le site serveur. Pour cela, elle établit une connexion TCP/IP vers un port TCP/IP de la machine serveur, par l'intermédiaire de la commande CONNECT d'un ou plusieurs proxy HTTP, qui sont paramétrés pour autoriser les accès demandés. Dans le cas de plusieurs proxy chaînés, il est possible d'utiliser des numéros de port différents à chaque étape. La commande CONNECT d'un proxy HTTP est décrite dans un mémo IETF écrit en août 1998 par Ari Luotonen, et est implémentée selon cette description dans tous les principaux proxy HT1'P du marché, avec un paramétrage par défaut autorisant l'accès au port 443 (HTTPS) et 563 (NNTPS) . L'existence de cette commande et l'autorisation de l'utiliser pour accéder au port 443 d'un serveur sont absolument nécessaires pour permettre aux utilisateurs du site client de se connecter à des sites WEB sécurisés (URL de forme https:// , en respectant le modèle de sécurité de bout en bout utilisé par le protocole SSL/TLS. C'est le cas en pratique sur tous les sites et donc la connexion est quasiment toujours possible vers le port 443. Cette observation fait qu'il est très judicieux (bien que non nécessaire) d'utiliser le port 443, le port 563 ou tout autre port pour lequel la commande CONNECT du ou des proxies du site client est autorisée par défaut, afm de ne pas avoir à modifier le paramétrage de celui-ci, opération souvent impossible pour des raisons administratives. Le serveur comporte une UE serveur qui est en écoute et accepte des connexions sur au moins le port accédé par l'UE client. Le résultat net de ces opérations est de créer un tunnel transparent (puisque censé faire transiter des flux de données encryptés par le protocole SSL/TLS) bidirectionnel (ladite liaison TCP/IP) entre l'UE serveur et l'UE cliente. Par ailleurs, il peut être nécessaire aux UE client et serveur de simuler ou réaliser effectivement sur ce tunnel juste après son établissement les étapes de négociation du protocole SSL/TLS, afin de faire croire au(x) proxy(ies) qu'il s'agit réellement d'une liaison SSL/TLS, le tunnel ne devenant transparent qu'à l'issue de cette simulation. En effet, pour améliorer la sécurité, certains proxy peuvent contrôler cette étape. Il peut être intéressant de rajouter un proxy coté serveur, afm de permettre à un site serveur ne possédant qu'une seule adresse IP sur l'Internet de pouvoir servir aussi de serveur HTTPS traditionnel, tout en redirigeant les requêtes de l'UE client vers un autre port et/ou une autre machine sur lequel écoute l'UE serveur. Il se peut aussi que le site client ne comporte pas de proxy; dans ce cas l'établissement du tunnel devient trivial: en effet, la connexion créée par l'UE client vers l'UE serveur est d'origine un 30 tunnel. Typiquement l'UE client et l'UE serveur sont situées sur des machines distinctes reliées par l'Internet, mais, pour des besoins particuliers, elles peuvent être sur la même machine, ou sur des machines reliées entre elles par un réseau TCP/IP au moins partiellement privé. De même, les sites client et serveur sont en général différents, sans que cela soit une obligation. Ainsi on a réalisé un tunnel bidirectionnel entre l'UE cliente et l'UE serveur à l'initiative de l'UE cliente, vu du réseau et des systèmes de sécurité du site client comme une communication sortante habituelle. Ce tunnel peut être maintenu ouvert pendant de longues périodes en y faisant transiter des données de remplissage (keepalive data) afin de réinitialiser les chiens de garde (timeouts) des couches inférieures des protocoles réseau. Si, pour une raison quelconque, par exemple à cause d'une trop grande période d'inactivité, le tunnel se ferme, l'UE client s'en aperçoit, et en recrée 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 tunnel actif. Il est possible, en particulier pour des raisons de redondance, d'établir pour une même UE client plusieurs tunnels indépendants vers la même UE serveur actifs simultanément, en particulier en procédant à des moments judicieusement choisis de sorte qu'il y en ait toujours au moins un disponible. Tant que le site central ne désire pas se connecter, le serveur ne répond pas. Quand le site central désire se connecter au client, l'UE serveur envoie la requête désirée sur au moins un tunnel établi. L'UE client, sur réception de cette requête, la traite en local et/ou la transmet à une autre UE capable d'y répondre, et récupère sa réponse. L'UE client renvoie alors la réponse par l'intermédiaire d'un tunnel actif. Il est à noter qu'il n'existe aucune contrainte sur la nature, la forme, la taille, le sens ou le protocole des données transitant par ces tunnels. On a réalisé ainsi une connexion créée physiquement à l'initiative du site client, mais logiquement à l'initiative du site central. Une même UE serveur peut de plus maintenir des tunnels ouverts vers plusieurs UE clientes simultanément. De même, une même UE client peut maintenir simultanément ou non plusieurs tunnels ouverts sur plusieurs UE serveur. Ces tunnels peuvent transmettre l'information en clair ou de manière encryptée, après une éventuelle authentification, et une éventuelle signature numérique grâce par exemple à l'utilisation de protocoles et algorithmes à clé publique ou privée, et/ou de certificats, et/ou de tiers certificateurs, et/ou de signatures numériques. En général, les requêtes ne sont pas originaires de l'UE serveur, mais proviennent d'un opérateur, ou d'une autre UE (UE opérateur). Dans le cas d'un opérateur, celui-ci dialogue avec une UE qui jouera le rôle d'UE opérateur. Des exemples d'UE opérateur sont les consoles d'administration système, les programmes de transmission de données, les clients SOAP des services WEB, les programmes de surveillance, télé-collecte, etc. L'UE demandeur peut aussi être ou faire partie d'un proxy pour un protocole informatique, tel que HTTP, SOAP, FTP, TELNET, VNC ou autre. Par exemple, l'utilisation du procédé pour réaliser un proxy HTTP permet d'émettre de l'extérieur des requêtes HTTP qui seront exécutées par un serveur WEB installé sur le site client, le résultat étant renvoyé à l'extérieur. Pour réaliser cela, l'UE serveur est capable d'accepter les requêtes par un moyen quelconque, en particulier de la mémoire partagée, des ports TCP, des files de messages, des sockets locaux, etc. L'UE serveur reconnaît la requête (par exemple selon sa provenance, ou suivant un protocole d'authentification de l'émetteur), peut optionnellement vérifier que l'émetteur est habilité, et la transmet après traitement éventuel (conversion de protocole, mise en forme, etc.), via un ou plusieurs tunnels disponibles, à ou aux UE client concernées, qui la traite. L'UE serveur récupère alors la ou les réponses sur un ou plusieurs tunnels disponibles, et les retransmet après traitement éventuel à ou aux UE demandeur concernées. L'UE serveur et l'UE client peuvent donc effectuer un routage et/ou un multiplexage de données en provenance et/ou à destination de dispositifs et/ou systèmes et/ou UE et/ou opérateurs humains. Il est de même possible de réaliser un tunnel entre une UE demandeur et une UE cliente, ce qui permet en particulier d'y encapsuler de manière transparente d'autres protocoles, tels que VNC, permettant le transport performant d'images d'écran et d'actions utilisateur pour des applications de prise de main à distance, ou 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, et/ou la transmission d'informations de toute nature (par exemple audio ou vidéo) entre les sites; ceci rends le procédé très bien adapté à la réalisation de proxies pour ces protocoles. Pour cela, l'UE serveur, après avoir optionnellement authentifié et vérifié les habilitations, route de manière transparente ou après traitement éventuel les données reçues de l'UE demandeur vers l'UE client, et en retour les données de cette dernière vers l'UE demandeur. Ceci est très difficilement faisable avec le procédé de NETFISH TECHNOLOGIES cité ci-dessus. De même les unités d'exécution client et/ou serveur peuvent jouer un rôle d'aiguilleurs en routant et/ou multiplexant / démultiplexant les requêtes et/ou données reçues vers et/ou depuis un opérateur et/ou des dispositifs quelconques (à titre non limitatif: caméras, microphones, capteurs, actionneurs, systèmes d'acquisition / restitution du son, de l'image ou de la vidéo...) et/ou autres unités de traitement et/ou 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 manuelle d'un opérateur du site client. Il est possible de redonder les connexions et/ou unités d'exécution, coté client et/ou serveur, afin de se prémunir d'éventuels dysfonctionnements et améliorer la disponibilité et/ou les performances de l'ensemble. Dans ce cas, selon un mode préférentiel d'exécution de l'invention, I'ensemble est judicieusement agencé de manière qu'en cas d'unité et/ou de connexion défaillante, une autre unité et/ou une autre connexion prenne le relais, afin de maintenir et/ou rétablir la liaison. En particulier, l'organisation suivante est possible: Un petit nombre d'UE serveur, situées de préférence sur des sites distincts Un grand nombre d'UE client, chaque UE client maintenant au moins un tunnel sur chaque UE serveur Lorsque une UE opérateur désire se connecter à une UE client, elle dispose de plusieurs possibilités, et choisit l'UE serveur relais en fonction de critères tels que le bon fonctionnement de celle-ci, l'équilibrage de charge, la bande passante disponible, le temps de transfert dans le réseau, la qualité de la liaison, le coût, etc. Le procédé objet de l'invention 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 d'une connexion entrante. Le site central doit accepter 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 et la qualité de la liaison. Lorsque aucune utilisation du procédé n'est en cours, les ressources machine utilisées par les tunnels sont très faibles, et la totalité de la 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 à effectuer. De plus, très fréquemment, une liaison Internet permanente existe déjà sur le site client, et peut être utilisée pour réaliser le procédé, supprimant ainsi tous investissements et dépenses télécoms supplémentaires liées à l'utilisation de ce procédé. 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ébit, 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. Un exemple non limitatif de mise en oeuvre de l'invention est représenté sur la figure 1). Le site client (9) comprend la machine cliente (10) sur lequel tourne un agent client (11) connectée au réseau Internet (2) via un proxy HTTP (12) attendant les connexions sur le port 8080, et configuré pour n'autoriser la commande CONNECT que vers le port 443 (paramétrage par défaut) et un routeur/pare-feu (13) effectuant la translation d'adresses, et interdisant toute connexion entrante. La machine Serveur (14) est connectée au réseau Internet (2) à l'adresse www.monserveur.com par un routeur et un pare-feu non représentés. Sur cette machine tournent: Un serveur WEB Apache (4) équipé du module de proxy HTTP mod_proxy (7). Ce module est configuré de manière à attendre des connexions sur le port 443, et autoriser la commande 10 CONNECT vers le port 3000 de la machine locale. Un démon (6), jouant le rôle de l'UE serveur décrite ci-dessus, attendant des connexions Client sur le port 3000, et des connexions de requêtes sur le port 2000. Au démarrage de (10), l'agent (11) crée un tunnel vers le démon (6) au moyen des actions et échanges suivants: 1) Etablissement par (11) d'une liaison TCP/IP vers Proxy_HTTP:8080 2) Envoi par (11) sur la liaison de: CONNECT www.monserveur.com:443 HTTP/1.0 3) Réponse de (12) sur la liaison: HTTP/1.0 200 Connexion established . A partir de ce moment, toutes les données envoyées par (11) sur la liaison arrivent à (7). 4) Envoi par (Il) sur la liaison de: CONNECT 127.1:3000 HTTP/1.0 5) Réponse de (7) sur la liaison: HTTP/1.0 200 Connexion established . A partir de ce moment, un tunnel est établi entre (11) et (6). Après un certain temps, l'Opérateur (1) envoie une requête H'1"lP (3) vers (4) ; (4) est configuré de manière à activer le script CGI (5) sur réception de (3). (5) met en forme la requête, et l'envoie à (6) via le port 2000. (6) transmet la requête à (11) via le tunnel, et récupère la réponse de (11) qu'il renvoie à (5). (5) met en forme cette réponse au sein d'une page HTML qu'il renvoie à (1). Le résultat net de ces opérations est que l'opérateur a pu accéder au client, malgré que celui-ci soit derrière un pare-feu, sans aucune modification apportée à la configuration du site client. 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é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, ainsi que dans la réalisation de proxies pour tous protocoles. -8 REVENDICATIONS 1) Procédé d'accès selon les protocoles de l'Internet à une unité d'exécution (UE) cliente située sur une machine cliente dans un site client par une UE serveur située sur une machine serveur dans un site serveur, lesdits sites et machines pouvant être ou non confondus, caractérisé en ce que avant toute opération l'UE cliente se connecte par une liaison TCP/IP a un port TCP/IP de ladite machine serveur soit directement si cela est possible, soit en utilisant judicieusement les commandes CONNECT d'un ou plusieurs proxies HTTP chaînés entre eux qui, dans ce cas sont paramétrés pour autoriser cette liaison, que l'UE serveur est en écoute au moins sur ce port, qu'un tunnel bidirectionnel est créé sur cette liaison TCP/IP, et que l'UE serveur accède à l'UE cliente à travers ce tunnel pour envoyer et/ou recevoir tous types de données. 2) Procédé d'accès selon les protocoles de l'Internet à une unité d'exécution (UE) cliente située sur une machine cliente dans un site client par une UE serveur située sur une machine serveur dans un site serveur, lesdits sites et machines pouvant être ou non confondus, caractérisé en ce que l'unité cliente initialise par le procédé décrit à la revendication précédente plusieurs tunnels et que l'UE serveur accède à l'UE cliente à travers au moins un de ces tunnels pour envoyer et/ou recevoir tous types de données. 3) Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le port utilisé pour sortir d'au moins un proxy Hl 1P est un port pour lequel la commande CONNECT de ce proxy est autorisée par le paramétrage existant et/ou par défaut de celui-ci, en particulier le port 443 ou 563, ce qui permet de ne pas avoir à en modifier le paramétrage. 4) Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que, juste après l'établissement du tunnel, l'UE client et l'UE serveur simulent ou réalisent effectivement les étapes d'établissement d'une liaison SSL ou TLS. 5) Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que tout ou partie 25 des données transitant dans le ou les susdits tunnels est encrypté et/ou authentifié et/ou signé numériquement. 6) Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que les données transitant dans les susdits tunnels sont organisées de manière à multiplexer plusieurs flux d'information entrants et/ou sortants. 7) Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que l'UE serveur et/ou l'UE 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 UE et/ou opérateurs humains. 8) Procédé d'accès à une UE client située sur une machine client dans un site client par une UE opérateur située sur une machine opérateur dans un site opérateur à travers une ou plusieurs UE serveur situées sur une ou plusieurs machines serveur dans un ou plusieurs sites serveurs, les machines et sites opérateur, client et serveur pouvant ou non être confondus, caractérisé en ce que au moins une UE serveur accède à PUE client par un procédé selon l'une quelconque des revendications précédentes, que l'UE opérateur se connecte à au moins une UE serveur connectée à PUE client, et que la ou les UE serveur font suivre après traitement éventuel vers l'UE client les données reçues de l'UE opérateur, et renvoient vers l'UE opérateur après traitement éventuel les données reçues de l'UE client. 9) Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il est utilisé dans des logiciels, solutions et systèmes de télémaintenance, télé exploitation, transfert de fichiers, télé administration, prise de main à distance, télésurveillance, télédiffusion, 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, et/ou pour la réalisation de proxies pour tous types de protocoles informatiques, en particulier HTTP, SOAP, FTP et TELNET.