Brevet FR2827104A1 — publié le 20030110

La présente invention concerne un procédé pour le contrôle d'échanges de données entre deux applications, respectivement de type client et de type serveur, selon un protocole de type FTP de TCP/IP (RFC 959 1579) ou analogue, étant entendu que : - TCP/IP ("Transmission Control Protocol")/ ("Internet Protocol") est un ensemble de protocoles de transmission utilisé sur le réseau Internet, - FTP ("File Transfert Protocol") est un protocole de transfert de fichiers de TCP/IP utilisé aussi bien sur Internet que sur des réseaux TCP/IP d'entreprise Intranet dont le protocole de réseau est TCP/IP, - RFC ("Request for comments") est une nomination des protocoles TCP/IP, les applications serveur et client sont spécifiques du protocole FTP ou ont la capacité de générer un flux de données compatibles avec ce protocole. L'invention a plus particulièrement pour objet, mais non exclusivement, un procédé mettant en oeuvre une application Hyperserveur qui s'exécute sur une plateforme hôte et qui joue le rôle d'intermédiaire entre deux applications dont l'une est de type FTP tandis que l'autre est soit une application de type FTP, soit une application compatible, pour conduire les négociations protocolaires de transferts ainsi que les transferts de données elles-mêmes. Indépendamment de l'environnement d'exécution de ces applications, l'application Hyperserveur est dotée de moyens lui permettant d'avoir la visibilité et la faculté d'une interprétation et d'une traduction des informations échangées. Cette position de l'application Hyperserveur lui permet, non seulement de suivre les échanges de façon passive, mais aussi de les contrôler en interférant dans ces échanges en fonction des règles de contrôle, qui lui seront imposées et définies dans ses bases de données des annuaires des applications-partenaires et des profils de transfert. Pour renforcer et élargir ces capacités de suivi et de contrôle au-delà de sa propre plateforme d'exécution, le procédé selon l'invention peut comprendre des applications agents sur les plateformes d'exécution des applications de type FTP (ou compatibles). En fonction des règles de contrôle et du déploiement des applications agents, tout ou seulement une partie de la population des applications de type FTP (ou compatible) peut être pleinement contrôlée. Cette population (ou partie de population) sera appelée ci-après "population contrôlée". L'ensemble des applications de type FTP (ou compatible) ne bénéficiant pas du contrôle de l'application Hyperserveur est dénommé population banalisée dans la suite de cette présentation. Les deux populations peuvent faire partie d'un même réseau IP ou appartenir à deux réseaux différents et, dans le deuxième cas, l'application Hyperserveur devra résider dans le réseau de la population contrôlée et être accessible par les applications de la population banalisée. S'exécutant sur un hôte Intranet et étant le point de passage unique et obligatoire dans les échanges Intra/Intemet, le procédé selon l'invention permet d'effectuer les transferts en assurant la sécurité et la confidentialité des données abritées dans le réseau Intranet. Il assure par ailleurs les fonctionnalités d'un puissant moniteur d'exécution centralisé d'échanges de fichiers ou autres objets transférables. Les applications de type FTP (ou compatibles) du réseau Intranet constituent dans ce cas-là la population contrôlée et les partenaires Internet jouent le rôle de la population banalisée. Dans cet environnement, la sécurité et la confidentialité de l'ensemble du réseau Intranet peuvent être préservées par le procédé selon l'invention puisque les noms des hôtes de ce réseau, les annuaires de fichiers (ou autres objets transférables) et leurs noms physiques peuvent rester invisibles pour les partenaires extérieurs du réseau Intranet. En fonction des règles d'attribution de noms physiques des fichiers (objets transférables) et des hôtes serveurs de type FTP ou compatibles FTP, les partenaires extérieurs n'ont besoin de connaître que les identificateurs des entrées de la base de données des profils de transfert de fichiers et des profils de connexion, définie ci-dessous et, parmi ces identificateurs, seulement ceux accessibles au demandeur identifié et authentifié. L'application Hyperserveur est une application intermédiaire qui a la visibilité et le contrôle complet de toutes les données de négociations protocolaires et des fichiers (ou autres objets transférables) échangées par les applications qui communiquent entre-elles. De ce fait, et indépendamment de l'environnement de son exécution, l'application Hyperserveur a toutes les informations nécessaires pour assurer les fonctions d'un moniteur telles que le suivi, les statistiques et les interactions avec des opérateurs ou d'autres applications. D'une façon plus précise, le procédé selon l'invention pourra mettre en oeuvre : - une population banalisée des hôtes résidant dans un réseau IP ayant accès à l'application Hyperserveur et hébergeant : - des applications de type FTP ou capables de générer un flux de données compatibles avec le protocole FTP, - des fichiers ou autres objets transférables identifiables et visibles pour ces applications, - une application Hyperserveur s'exécutant sur un hôte ayant accès aux applications de type FTP ou compatibles mentionnées ci-dessus et disposant de : - une base de données d'annuaire des hôtes contrôlés et banalisés désignant les applications communicantes avec leurs adresses IP et des listes des utilisateurs autorisés à y accéder ainsi que les attributs d'autorisation, si nécessaire (BDH), - une base de données d'annuaire des profils de transfert de fichiers ou autres objets transférables (BDP), - un fichier"LOG"central de l'application Hyperserveur (LGH), contenant les enregistrements de suivi de transferts, - un fichier journal central de l'application Hyperserveur (JRH), contenant les enregistrements récapitulatifs des transferts, - une population contrôlée d'hôtes résidant dans un réseau IP et hébergeant : - des applications de type FTP ou capables de générer un flux de données compatible avec le protocole FTP, - des fichiers ou autres objets transférables identifiables et visibles pour ces applications, - des applications agents de l'application Hyperserveur disposant éventuellement de leurs propres fichiers"LOG"et journal. Il convient de noter que la population contrôlée des hôtes avec celui hébergeant l'application Hyperserveur peut être un ensemble d'ordinateurs et de fichiers d'une entreprise constituant un réseau Intranet. La base BDP de profil des transferts de fichiers avec les applications FTP ou compatibles constituent pour l'application hyperserveur le système d'accès aux fichiers aux termes du modèle de FTP. La population banalisée peut être, dans ce cas-là, l'ensemble des ordinateurs accédant via le réseau Internet à l'application Hyperserveur pour transférer des fichiers avec les hôtes de l'entreprise sous son contrôle. La base de données BDH contient toutes les informations nécessaires à l'application Hyperserveur pour : - identifier et/ou authentifier chaque demandeur de transfert, - identifier et/ou accéder à l'application destinatrice en respectant ses règles d'authentifications, - déterminer éventuellement les règles de cryptage à utiliser en fonction des demandeurs et des destinataires identifiés, - identifier et localiser l'application agent de l'application Hyperserveur assignée pour la partie de la connexion dans l'environnement contrôlé, - identifier éventuellement les processus à exécuter au début et/ou à la fin de la connexion, etc... La base de données BDP définit les profils et scénarios des transferts de fichiers ou autres objets transférables à l'aide des attributs suivants, notamment : - l'emplacement des fichiers ou autres objets à émettre ou recevoir, et/ou - leur nom ou leur méthode de dénomination, et/ou - leur méthode d'accès, et/ou le type de données et/ou le code, et, éventuellement : - les processus et scénarios à exécuter au début et/ou pendant et/ou à la fin des transferts et/ou leur lieu d'exécution, et/ou - les critères et attributs d'autorisation d'accès au fichier ou objets à transférer. Il est à noter que, à part des applications de type FTP qui sont les partenaires des échanges, la seule application ayant accès aux données de fichiers (autre objet) transférés est l'application Hyperserveur. Cette capacité lui permet d'agir éventuellement sur ces données en exécutant des processus en cours de transfert. La mise en place d'un agent de l'application Hyperserveur sur chaque hôte de la population contrôlée permet d'effectuer un suivi local des transferts des fichiers. Les applications agents pourvues d'une interface de communication avec l'application Hyperserveur peuvent récupérer les informations concernant les transferts de fichiers de leur lieu d'exécution et/ou de recevoir de l'application Hyperserveur un ordre de lancer sous leur propre contrôle les processus en début ou en fin de ces transferts. Dans une version préférée de l'invention, les bases de données BDH et BDP peuvent constituer les annuaires locaux de type LDAP ("Lightweight Directory Access Protocol") du réseau de la population contrôlée. LDAP est un protocole ouvert et largement diffusé qui permet d'accéder à ces annuaires sans un développement supplémentaire pour les applications s'exécutant dans un environnement fortement hétérogène. A titre d'exemple, la présentation qui suit décrit les déroulements des opérations de transfert de fichiers dans l'environnement Intranet/Intemet où l'application Hyperserveur assure le suivi et le"monitoring"des transferts de fichiers côté Intranet. Rien n'empêche par ailleurs d'imaginer une autre application Hyperserveur située sur le réseau Internet générant le flux compatible à FTP et contrôlant des transferts de fichiers de sa population d'hôtes. Dans cet environnement, le déroulement des opérations lors d'une demande de transfert à partir du réseau Internet est le suivant : - l'application de type FTP du client demandeur côté Internet ouvre, grâce à un jeu de commandes d'ouverture de connexion, la connexion avec l'application Hyperserveur en spécifiant son nom d'utilisateur, son mot de passe et éventuellement ses données d'authentification comme avec un serveur FTP classique, en fonction de règles définies dans l'annuaire BDH, les informations échangées pendant cette phase de la négociation avec le client FTP peuvent être suffisantes pour déterminer l'entrée de cet annuaire définissant les attributs de connexion avec l'application visée côté Intranet (sinon, une commande supplémentaire, par exemple SITE de FTP, peut être utilisée pour l'identifier), la corrélation entre le client demandeur et le serveur visé permet à l'application Hyperserveur de rechercher dans la base de données BDH toutes les informations concernant les droits d'accès du demandeur, le cryptage éventuel et ses clés, ainsi que le protocole éventuel de négociation et les modalités de la connexion avec le serveur visé, dès que le protocole et les modalités de connexion sont connus, l'application Hyperserveur peut ouvrir la connexion avec l'application destinatrice visée et entamer l'échange de commandes éventuellement prévues par le protocole, la poursuite de la négociation et le contenu d'une des commandes de transfert FTP du type"store","store unique","retrive"etc.. reçu par l'application Hyperserveur doivent lui permettre d'identifier un profil de transfert de fichier ou d'autres objets transférables qui constitue une entrée dans l'annuaire BDP, la définition du profil déterminé permet à l'application Hyperserveur de vérifier le sens de transfert, d'identifier le fichier à transférer, ses attributs, les processus éventuels à exécuter au début, pendant et à la fin du transfert ainsi que la désignation des applications sous contrôle desquelles leurs exécutions doivent avoir lieu, - qu'ayant achevé les éventuelles négociations de transfert induites par le profil de transfert avec l'application visée, l'application Hyperserveur pourra acquitter la demande du transfert reçu du client, - deux connexions"DATA"au sens FTP seront ouvertes : une, entre client FTP et application Hyperserveur et l'autre entre l'application Hyperserveur et l'application visée ; les données reçues par l'application Hyperserveur sur une connexion seront envoyées sur l'autre en subissant éventuellement le traitement du processus"pendant le transfert", - l'exécution des éventuels processus au début et/ou à la fin du transfert s'effectuera sous le contrôle de l'agent de l'application Hyperserveur de l'hôte de l'application visée en synchronisme avec le dialogue entre cette application et l'application Hyperserveur à l'ordre de ce dernier, les enregistrements LOG (fichiers dans lesquels sont enregistrés tous les événements des connexions, des négociations et des transferts) et journal (fichier de statistiques) générés par l'application Hyperserveur seront effectués dans des fichiers LGH et JRH et leurs copies seront envoyées vers l'agent de l'application Hyperserveur concerné pour être mises dans les fichiers"LOG"et journal locaux. Dans le cas où une demande de transfert provient d'un hôte du réseau Intranet donc de la population contrôlée, le déroulement de la procédure de transfert peut s'effectuer de manière symétrique. On sait cependant que la négociation d'un transfert entre l'application client et l'application serveur FTP ne laisse pas passer au serveur le nom de fichier à transmettre utilisé côté client. Lorsque la demande provient donc d'une application client FTP côté Intranet, cette particularité du protocole FTP réduit les possibilités de supervision des échanges de fichiers qui peuvent être demandées à l'application Hyperserveur, puisqu'il ne dispose d'aucune information concernant le fichier (ou l'objet à transmettre) de son propre domaine de contrôle. Il est préférable, dans ce cas, d'utiliser un dispositif du procédé selon l'invention, dénommé"Demande Directe de Transfert". Dans ce fonctionnement, lorsqu'une Demande Directe de Transfert est déposée par un utilisateur auprès de l'application Hyperserveur, le déroulement des opérations est le suivant : - la demande doit contenir toutes les informations nécessaires pour déterminer aussi bien l'entrée de l'annuaire BDH que celui de BDP, - en utilisant les informations trouvées dans l'entrée BDH déterminée, l'application Hyperserveur initialisera, en tant que client, deux connexions : une avec le serveur de type FTP (ou une application compatible) côté Intranet et une avec le serveur de type FTP côté Internet, - il va négocier deux transferts selon les informations trouvées dans le (s) entrée (s) BDP et dans la demande elle-même ; un des transferts sera une réception et l'autre une émission de fichiers (ou d'un autre objet transférable), - l'application Hyperserveur acheminera les données du fichier, de son origine à sa destination à travers deux connexions de type DATA au sens FTP ou compatibles entre elles-mêmes et deux applications serveurs, - le (s) profil (s) de transfert et autres paramètres de la Demande Directe de Transfert permettra à l'application Hyperserveur de déterminer les noms de fichiers des deux côtés et tous les attributs du transfert ainsi que les processus à déclencher au début, pendant et à la fin du transfert. Revendications 1. Procédé pour le contrôle d'échanges de fichiers ou autres objets transférables entre deux applications, respectivement de type client et de type serveur, selon un protocole de type FTP de TCP/IP ou analogue, l'une des deux applications étant de type FTP, tandis que l'autre est soit une application de type FTP, soit une application compatible, caractérisé en ce qu'il met en oeuvre une application Hyperserveur qui s'exécute sur une plateforme hôte et qui joue le rôle d'intermédiaire entre les deux applications dans des négociations protocolaires de transferts ainsi que dans des transferts de fichiers ou autres objets transférables eux-mêmes. 2. Procédé selon la revendication 1, caractérisé en ce que l'application Hyperserveur comprend des moyens permettant d'effectuer une interprétation et/ou une traduction des informations échangées, indépendamment de l'environnement d'application des deux susdites applications. 3. Procédé selon l'une des revendications 1 et 2, caractérisé en ce que l'application Hyperserveur comprend des moyens de contrôler les échanges entre les deux susdites applications en interférant dans ces échanges en fonction de règles de contrôle qui lui sont imposées et définies dans ses bases de données des annuaires des applications partenaires et des profils de transferts. 4. Procédé selon l'une des revendications précédentes, caractérisé en ce que des applications agents disposant éventuellement de leurs propres fichiers"LOG"et journal sont mises en oeuvre sur les plateformes d'exécution des susdites applications de type FTP (ou compatibles) de manière à pouvoir contrôler tout ou partie de la population des applications de type FTP ou compatibles, la population des applications de type FTP (ou compatible) contrôlée et la population de l'ensemble des applications de type FTP (ou compatible) ne bénéficiant pas du contrôle de l'application Hyperserveur pouvant faire partie d'un même réseau IP ou appartenir à deux réseaux différents, l'application Hyperserveur résidant alors dans le réseau de la population contrôlée et être accessible par les applications de la population banalisée, les applications agents étant pourvues d'une interface de communication avec l'application Hyperserveur pour récupérer les informations concernant les transferts de fichiers de leur lieu d'exécution et/ou de recevoir de l'application Hyperserveur un ordre de lancer sous leur propre contrôle les processus en début ou en fin de ces transferts. 5. Procédé selon la revendication 4, caractérisé en ce que les applications de type FTP (ou compatibles) du réseau Intranet constituent la population contrôlée et les partenaires du réseau Internet jouent le rôle de la population banalisée. 6. Procédé selon la revendication 5, caractérisé en ce que l'application Hyperserveur s'exécute sur un hôte d'un réseau Intranet, et en ce qu'il constitue le point de passage unique et obligatoire entre ce réseau Intranet et le réseau Internet. 7. Procédé selon la revendication 6, caractérisé en ce que la susdite application Hyperserveur comprend des moyens rendant invisible l'identification des hôtes du réseau Intranet ainsi que ses annuaires de fichiers et tout autre objet transférable aux partenaires extérieurs du réseau Intranet, chaque utilisateur n'ayant à connaître que les identificateurs des entrées de la base de données des profils de transfert de fichiers et des profils de connexion de l'application Hyperserveur et, parmi ces identificateurs, uniquement ceux accessibles au demandeur identifié et authentifié. 8. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'il met en oeuvre : - une population banalisée des hôtes résidant dans un réseau IP ayant accès à l'application Hyperserveur et hébergeant : - des applications de type FTP ou capables de générer un flux de données compatibles avec le protocole FTP, - des fichiers ou autres objets transférables identifiables et visibles pour ces applications, - une application Hyperserveur s'exécutant sur un hôte ayant accès aux applications de type FTP ou compatibles mentionnées ci-dessus et disposant de : - une Base de Données d'annuaire des Hôtes contrôlés et banalisés (BDH) désignant les applications communicantes avec leurs adresses IP et des listes des utilisateurs autorisés à y accéder ainsi que les attributs d'autorisation, si nécessaire, - une Base de Données d'annuaire des Profils de transferts de fichiers ou autres objets transférables (BDP), - un fichier"LOG"central de l'application Hyperserveur (LGH), contenant les enregistrements de suivi de transferts, - un fichier journal central de l'application Hyperserveur (JRH), contenant les enregistrements récapitulatifs des transferts, - une population contrôlée d'hôtes résidant dans un réseau IP et hébergeant : des applications de type FTP ou capables de générer un flux de données compatible avec le protocole FTP, - des fichiers ou autres objets transférables identifiables et visibles pour ces applications, - des applications agents de l'application Hyperserveur disposant éventuellement de leurs propres fichiers"LOG"et journal. 9. Procédé selon la revendication 8, caractérisé en ce que la base de données BDH contient toutes les informations nécessaires à l'application Hyperserveur pour : - identifier et/ou authentifier chaque demandeur de transfert, et/ou - identifier et/ou accéder à l'application destinatrice en respectant ses règles d'authentification, et/ou - déterminer éventuellement les règles de cryptage à utiliser en fonction des demandeurs et des destinataires identifiés, et/ou - identifier et localiser l'application agent de l'application Hyperserveur assignée pour la partie de la connexion dans l'environnement contrôlé, et/ou - identifier éventuellement les processus à exécuter au début et/ou à la fin de la connexion. 10. Procédé selon l'une des revendications 8 et 9, caractérisé en ce que la base de données BDP définit les profils et scénarios des transferts de fichiers ou autres objets transférables à l'aide des attributs suivants : - l'emplacement des fichiers ou autres objets à émettre ou recevoir, et/ou - leur nom ou leur méthode de dénomination, et/ou - leur méthode d'accès, et/ou le type de données et/ou le code, et, éventuellement : - les processus et scénarios à exécuter au début et/ou pendant et/ou à la fin des transferts et/ou leur lieu d'exécution, et/ou - les critères et attributs d'autorisation d'accès au fichier ou objets à transférer. 11. Procédé selon la revendication 8, caractérisé en ce que les bases de données BDP constituent des annuaires locaux de type LDAP ("Lightweight Directory Access Protocol") du réseau de la population contrôlée. 12. Procédé selon la revendication 8, caractérisé en ce que, dans le cas d'une demande de transfert à partir du réseau Internet, il comprend la séquence opératoire suivante : - l'ouverture par le client demandeur du réseau Internet de la connexion avec l'application Hyperserveur grâce à un jeu de commandes d'ouverture d'une connexion comprenant un nom d'utilisateur, un mot de passe et éventuellement des données d'authentification, la détermination de l'entrée de l'annuaire définissant les attributs de connexion avec l'application visée du réseau Intranet dans le cas où lesdites informations sont suffisantes compte tenu des règles définies dans l'annuaire BDH, sinon l'utilisation d'une commande FTP supplémentaire pour permettre de le faire, - la recherche par l'application Hyperserveur, dans la base de données BDH de toutes les informations concernant les droits d'accès du demandeur, le protocole de transfert ainsi que les modalités de connexion avec le serveur visé, l'ouverture par l'application Hyperserveur de la connexion avec l'application destinatrice et l'échange de commandes éventuellement prévu dès que celui-ci ainsi que les modalités de connexion sont connus, l'identification par l'application Hyperserveur d'un profil de transfert de fichier ou d'autre objet transférable qui constitue une entrée dans l'annuaire BDP, à la suite de la réception par l'application Hyperserveur d'une commande de transfert, la vérification par l'application Hyperserveur du sens de transfert, de même que l'identification par celle-ci du fichier à transférer, de ses attributs, des processus éventuels à exécuter au début, pendant et à la fin du transfert ainsi que la désignation des applications sous contrôle desquelles leurs exécutions doivent avoir lieu, grâce à la définition du profil déterminé, - l'acquittement, par l'application Hyperserveur, de la demande du transfert reçu du client à la fin des éventuelles négociations de transferts induites par le profil de transfert avec l'application visée, - l'ouverture de deux connexions"DATA"au sens FTP à savoir : une connexion entre client FTP et l'application Hyperserveur, et l'autre connexion entre l'application Hyperserveur et l'application visée, les données reçues par l'application Hyperserveur sur une connexion étant ensuite envoyées sur l'autre application en subissant éventuellement un traitement pendant le transfert, - l'exécution d'éventuels processus au début et/ou en fin de transfert sous le contrôle de l'agent de l'application Hyperserveur de l'hôte de l'application visée en synchronisme avec le dialogue entre cette application et l'application Hyperserveur, - l'enregistrement des événements apportés au cours de la séquence dans des fichiers correspondants (fichier LOG) ainsi que les informations de statistiques dans le fichier journal de l'application Hyperserveur et la transmission des copies de ces enregistrements à l'agent de l'application Hyperserveur concerné pour enregistrement dans des fichiers locaux appropriés. 13. Procédé selon la revendication 8, caractérisé en ce que dans le cas d'une demande de transfert provenant d'un hôte du réseau Intranet, la demande contient toutes les informations nécessaires pour déterminer les entrées aussi bien l'annuaire BDH que celui de 3DP, et en ce qu'il comprend la séquence opératoire suivante : - l'initialisation par l'application Hyperserveur en tant que client, de deux connexions à savoir : une première connexion avec le serveur de type FTP (ou une application compatible) du réseau Intranet et une deuxième connexion avec un serveur de type FTP situé sur le réseau Internet, cette initialisation utilisant les informations trouvées dans l'entrée BDH déterminée, - la négociation de deux transferts FTP selon les informations trouvées dans le (s) entrée (s) BDP et dans la demande elle-même, l'un des transferts étant une réception et l'autre une émission de fichiers ou d'un autre objet transférable, - l'acheminement par l'application Hyperserveur des données de fichier, de son origine à sa destination, à travers deux connexions de type DATA au sens FTP ou compatibles, entre l'application Hyperserveur et deux applications serveurs, la détermination par l'application Hyperserveur, des noms de fichiers des deux côtés et de tous les attributs du transfert ainsi que les processus à déclencher au début, pendant et à la fin du transfert, grâce au profil de transfert et autres paramètres de la demande.