Brevet FR3062222A1 — publié le 20180727

PROCEDE POUR L'ACCES PAR UN EQUIPEMENT INFORMATIQUE CLIENT A UN SYSTEME DE GESTION DE BASE DE DONNEES Domaine de l'invention La présente invention concerne le domaine de l'accès par un équipement informatique client à un système de gestion de bases de données relationnelles (SGBDR) exploitable par un langage de manipulation des données et des instructions SQL. Un système de gestion de bases de données est 10 composé de plusieurs programmes informatiques : un moteur, un catalogue, un processeur de requêtes, un langage de commande, SQL en ce qui concerne la présente invention et des outils. Le moteur de base de données manipule les fichiers de la base de données, transmet les données de et vers les 15 autres programmes, et vérifie la cohérence et l'intégrité des données. Le catalogue contient la description de l'organisation de la base de données, les listes de contrôle d'accès, le nom des personnes autorisées à manipuler la base 20 de données et la description des règles de cohérence. Le processeur de requête exécute les opérations demandées. Le langage de requête permet de manipuler le contenu de la base de données. SQL est devenu le langage 25 standard. Les outils du SGBD servent à créer des comptes rendus (reports), des écrans pour la saisie des informations, importer et exporter les données de et vers la base de données, et manipuler le catalogue. Ces outils sont utilisés 3062222 2 par l'administrateur de bases de données pour effectuer des sauvegardes, des restaurations de données, autoriser ou interdire l'accès à certaines informations, et effectuer des modifications du contenu de la base de données - création, 5 lecture, modification et suppression d'informations, abrégé CRUD (anglais create, read, update, delete). Ces outils servent également à surveiller l'activité du moteur et effectuer des opérations de tuning26. Dans un SGBD relationnel, les demandes formulées au 10 SGBD sont typiquement traitées en cinq étapes : - Les logiciels clients communiquent avec le SGBD en utilisant son interface de programmation via un réseau. Un dispositif de communication du SGBD vérifie l'identité du client, puis transmet les requêtes du client vers le noyau du 15 SGBD et transmet au client les informations extraites par le SGBD ; - le SGBD crée ensuite un fil (« thread ») en vue de traiter la requête. Un programme contrôle l'ensemble des threads et décide lesquels sont exécutés immédiatement et 20 lesquels seront exécutés plus tard, en fonction de la charge de travail de l'ordinateur ; - lors de l'exécution du thread, un compilateur transforme le texte exprimé dans le langage de requête du SGBD en un plan d'exécution dont la forme imite celle d'une 25 expression algébrique utilisant l'algèbre relationnelle, puis un ensemble de programmes "opérateurs" calculent le résultat de l'expression en effectuant des opérations telles que la jointure, le produit cartésien, le tri et la sélection ; - les opérateurs font appel au moteur de base de 30 données, celui-ci exécute des algorithmes (appelés access method en anglais) en vue de retrouver les informations et entretenir les structures des fichiers de la base de données. 3062222 3 Une fois les informations obtenues par le programme de manipulation de fichiers, celles-ci sont envoyées au thread d'exécution puis au dispositif de communication qui les transmet au client. 5 Le SGDB est généralement exécuté sur un serveur informatique communiquant avec des équipements clients via un réseau informatique, principalement Internet. Ces équipements clients, autrefois essentiellement des ordinateurs, sont aujourd'hui très variés : téléphone cellulaire (smartphone), tablette, mais aussi objets communiquant parfois dépourvus d'interface homme-machine, pour échanger de manière automatique des informations entre des capteurs locaux et une base de données distante. L'invention concerne plus spécifiquement le problème technique de la communication entre l'équipement client et le serveur exécutant le code informatique du système de gestion de bases de données relationnelles, et la sécurisation de l'accès à ce serveur pour éviter des requêtes malveillantes ou provenant d'un équipement non autorisées, pouvant modifier de manière inopportunes les données enregistrées dans la base de données voire les détruire. La communication entre les deux équipements est généralement réalisée avec un protocole de communication client-serveur http utilisant une couche de transport TCP. Etat de la technique On connaît dans l'état de la technique le brevet américain US6882996 décrivant un procédé de requêtage d'un système de base de données paramétrées. Le procédé décrit dans ce document de l'art 30 antérieur est destiné à permettre à un client d'accéder à un système de base de données sur un serveur via une connexion 3062222 4 Internet à partir d'intergiciels (« middleware » en anglais) en communication avec le client et le serveur. Le langage de requête du système de base de données est SQL. Les données qui satisfont la demande sont envoyées 5 via le protocole HTTP en langage de balisage extensible (XML). L'accès au fichier est commandé en réponse à une requête client pour des données comprenant des valeurs et des méthodes spécifiques, étant préciser que cette requête n'est pas une requête SQL afin d'éviter des accès inopportuns. 10 L'intergiciel comprend un routeur qui reçoit la demande du client. Il comprend un servlet qui remplace certains paramètres dans l'instruction paramétrés avec des valeurs correspondantes de la demande du client pour établir une instruction SQL. Le servlet envoie l'instruction SQL au 15 système de base de données pour l'exécution de celui-ci. On connaît aussi dans l'art antérieur la demande de brevet européen EP07009943 décrivant un procédé et un système pour le transfert de données contenues dans un message électronique, en particulier une pièce jointe MIME (extensions 20 de courrier Internet à buts multiples), à une base de données relationnelle comportant les étapes de : - fourniture d'une séquence XML qui détermine, comment les données doivent être traitées, - exécution d'un séquenceur, qui prend le message 25 et la séquence XML comme entrée, où l'exécution de la séquence comporte l'exécution d'au moins une instruction SQL pour accéder à la base de données relationnelle. Le brevet américain U56105043 décrit un autre exemple de procédé pour la création de fichiers de langue 30 macro pour exécuter des requêtes SQL dans un système de 3062222 5 gestion de base de données relationnelle via le World Wide Web de l'Internet. Conformément à cette solution de l'art antérieur, les utilisateurs Web peuvent demander des informations à partir du logiciel SGBDR via des formulaires de 5 saisie HTML, la demande est ensuite utilisée pour créer une instruction SQL pour l'exécution par le logiciel de SGBDR. Les résultats sortis par le logiciel de SGBDR sont eux-mêmes transformés en format HTML pour la présentation à l'utilisateur Web. 10 Inconvénients de l'art antérieur Les solutions de l'art antérieur privilégient la sécurité des échanges entre le client et le SGDB en utilisant un format d'instructions excluant expressément des instructions SQL. Cela implique l'utilisation sur l'équipement 15 client d'une application dédiée, avec des inconvénients en ce qui concerne la robustesse des échanges, le temps de traitement et les ressources informatiques mise en oeuvre sur l'équipement client. Solution apportée par l'invention 20 Afin de remédier à ces inconvénients, l'invention concerne selon son acception la plus générale un procédé pour l'accès par un équipement informatique client à un système de gestion de base de données via une connexion http avec un serveur mandataire, comprenant : 25 - une étape de génération d'une requête par ledit équipement client - une étape de traitement par ledit serveur mandataire de ladite requête pour interroger ladite base de données, en fonction des paramètres contenus dans ladite 30 requête 3062222 6 caractérisé en ce que : - ladite requête est une requête SQL - ledit serveur mandataire comporte un module de sécurité paramétrable par injection de code, 5 o pour analyser le contenu de ladite requête et de ses paramètres et o assurer conditionnellement la transmission de ladite requête à un module d'extraction - ledit module d'extraction assurant la conversion 10 de la requête en instructions JDBC transmises audit système de gestion de base de données - ledit module d'extraction recevant en réponse les données au format JDBC et assurant la conversion en flux JSON 15 - le serveur mandataire transmet ledit flux JSON à l'équipement client. Avantageusement, ledit module de sécurité paramétrable comporte des moyens de limitation du nombre de lignes transmises. 20 Selon une variante particulière, ledit module de sécurité paramétrable comporte des moyens de déclenchement d'une action en fonction du de ladite requête analysée, ladite action pouvant notamment être constituée par - l'envoi d'un message de révocation d'un 25 utilisateur - l'envoi d'un message d'alerte. 3062222 7 De préférence, ledit module de sécurité paramétrable comprend un fichier de configuration par défaut. Description détaillée d'un exemple non limitatif de 5 l'invention L'invention sera mieux comprise à la lecture de la description qui va suivre, donnée uniquement à titre d'exemple, et faite en référence aux dessins en annexe dans lesquels : 10 o la figure 1 est un schéma synoptique d'un système selon un mode de réalisation de l'invention ; o la figure 2 est un schéma fonctionnel du serveur mandataire ; o la figure 3 est une représentation de 15 l'interface du module de configuration DatabaseConfigurator o la figure 4 représente un exemple de fichier de configuration par défaut. Architecture matérielle La figure 1 représente un schéma synoptique d'un 20 système selon l'invention. Les équipements clients (1 à 3) peuvent être constitués par un ordinateur (1), un téléphone cellulaire (« smartphone ») ou une tablette (2) ou encore un objet connecté (3). Les équipements clients (1 à 3) dispose d'une 25 interface de communication comprenant une couche physique, une couche de liaison de données, une couche de réseau IP, une couche de transport TCP et une couche de session http. 3062222 8 Ils sont connectés par le réseau Internet à un serveur mandataire (4) qui est lui-même connecté à un serveur (5) pour le traitement du système de base de données (6). Le serveur mandataire (4) a la possibilité de 5 maintenir une session propre à celui-ci. Il peut, par exemple, être un serveur ICAP, ou un serveur mandataire avec mémoire d'état. Ce dernier comporte de plus des modules décrits plus en détail en figure 2, pour le traitement des requêtes 10 provenant des équipements clients (1 à 3) et les échanges avec le serveur (5) pour le traitement du système de base de données (6). Le serveur mandataire (4) comporte un étage d'analyse (10) réalisant une extraction des instructions SQL 15 des données provenant du client sous forme d'une requête http, ainsi que l'identifiant de l'équipement client qui a transmis cette requête. Bien entendu, l'exemple décrit n'est pas limitatif, l'invention pouvant être mise en oeuvre avec un serveur unique, 20 regroupant les fonctionnalités du serveur mandataire (4) et du serveur (5) de traitement de la base de données (6). Ces données sont ensuite transmises à un étage de filtrage (11) paramétrable comparant les données via un programme (12) qui permet de définir des commandes autorisées 25 pour l'équipement client correspondant à l'identifiant extrait par l'étage d'analyse (10). Ce programme est modifiable par injection de code, pour adapter les commandes autorisées ou interdites en fonction des spécificités du contexte d'utilisation de la base de données concernée. Si la requête transmise par l'étage d'analyse (10) contient des commandes non autorisées, l'étage de filtrage 3062222 9 (11) renvoie à l'équipement client une notification de non traitement de la requête. Si la requête transmise par l'étage d'analyse (10) contient des commandes erronées, l'étage de filtrage (11) 5 renvoie à l'équipement client une notification d'erreur avec un code désignant la nature de l'erreur et un message. Si la requête ne contient que des commandes autorisées, l'étage de filtrage (11) transmet à un pilote JDBC constituant une passerelle pour l'accès à un système de 10 gestion (5) de base de données (6). La requête est exécutée sur le système de gestion (5) de base de données (6) et la réponse est ensuite transmise à l'équipement client (1 à 3) correspondant à l'identifiant susvisé. 15 Exemple détaillé d'implémentation La description qui suit présente des exemples de code pour une requête de connexion à une base de données selon l'invention. Une requête de connexion à la base de données 20 distante fait un appel http en GET ou en POST partir de l'équipement client. Exemple avec un appel http en GET : https://www.acme.com/aceql/userl/my_db/connect?pass word=MySecret_1234 25 Le serveur mandataire comprend que le l'identifiant de connexion (userl, MySecret_1234) veut se connecter à la base de données SQL my_db. 3062222 10 Le module de sécurité vérifie, via le code Java d'authentification injecté, si le couple (userl, MySecret_1234) a l'autorisation de se connecter. Ceci est fait via le code Java de la méthode login 5 (String username, char []) de l'instance de la classe de type DatabaseConfigurator injectée dans le module de sécurité. Si oui, un jeton de sécurité unique et à utiliser dans les envois http suivants est renvoyé comme réponse dans une enveloppe JSON : 10 f "status":"OK", "token":" qsd6bmhqnc8bosebc3crvipr81" 1 15 Si non, un statut http 401 UNAUTHORIZED est renvoyé au client. Il est à présent possible de programmer une requête SQL à partir de l'équipement client, via un appel http en GET ou en POST, en repassant le jeton d'authentification 20 https://www.acme.com/aceql/userl/qsd6bmhqnc8bosebc3 crvipr81/my_db/select avec le paramètre http : - de nom "sql" - de valeur : le contenu de la requête SQL soit 25 par exemple "select from customer" URL encode avec 3062222 11 l'encodage UTF-8. (Une instruction DELETE, INSERT, UPDATE aurait pu être aussi envoyée). L'appel http route vers le serveur mandataire la requête. Le module de sécurité via le code injecté de 5 l'instance de la classe DatabaseConfigurator vérifie que cette appel est autorisé, via plusieurs méthodes de contrôle : - verifyAuthToken Vérification que le jeton est valide/authentique et non expiré. 10 - allowStatementAfterAnalysis : Méthode qui permet d'analyser en détail la syntaxe de la requête SQL, ainsi que les paramètres passés. - allowStatementClass : Méthode qui permet d'autoriser ou non un Statement qui n'est 15 pas un PreparedStatement En cas d'échec des contrôles de sécurité, un code http 401 est renvoyé à l'équipement client. En cas de succès des contrôles de sécurité, le serveur mandataire passe alors l'ordre à la base de données 20 SQL via un appel JDBC. L'appel JDBC renvoie une réponse qui est renvoyée au serveur mandataire. Le serveur mandataire formate alors les données SQL en JSON et renvoie ce contenu JSON à l'équipement client : f 25 "status":"OK", "query_return_lines":[ 3062222 12 5 10 15 20 "row 1":[ f "col index ":1, "col name":"customer id", _ _ "col value":1111 "col index ":2, "col name":"customer name", _ _ "col value":"Smith" "col index ":3, "col name":"customer_age", _ "col value":30 } 1, "row 2":[ f "col index ":1, f 3062222 5 10 13 "col name":"customer id", _ _ "col value" :2222 "col index ":2, "col name":"customer name", _ _ "col _value":"Wesson" "col index ":3, "col name":"customer_age", _ "col value":31 15 Les ordres de modifications de la connexion SQL peuvent aussi être envoyés. Exemples : 20 Passage en mode transaction : https://www.acme.com/acegl/username/gsd6bmhgnc8bose bc3crvipr81/my_db/set_auto_commit/false 3062222 14 Validation d'une transaction en cours : https://www.acme.com/aceql/username/qsd6bmhqnc8bose bc3crvipr81/my_db/commit Annulation d'une transaction en cours : 5 https://www.acme.com/aceql/username/qsd6bmhqnc8bose bc3crvipr81/my_db/rollback Quand l'équipement client a terminé sa session, il peut par sécurité envoyer un ordre de déconnexion : https://www.acme.com/aceql/userl/ 10 qsd6bmhqnc8bosebc3crvipr81/my_db/disconnect Interface du module de configuration La figure 3 est une représentation de l'interface du module de configuration DatabaseConfigurator. 15 Le module de configuration prévoit une configuration par défaut, permettant un démarrage rapide sans nécessiter de programmation préalable. Il comporte aussi un fichier de configuration du lien JDBC avec la ou les bases de données qui pourraient être 20 accédées à partir de l'équipement client. La figure 4 représente un exemple de fichier de configuration par défaut, prévoyant la transmission de toutes les commandes, et une durée de session de 24H. REVENDICATIONS1 - Procédé pour l'accès par un équipement informatique client à un système de gestion de base de données via une connexion http avec un serveur mandataire, comprenant - une étape de génération d'une requête par ledit équipement client - une étape de traitement par ledit serveur mandataire de ladite requête pour interroger ladite base de 10 données, en fonction des paramètres contenus dans ladite requête caractérisé en ce que : - ladite requête est une requête SQL - ledit serveur mandataire comporte un module de 15 sécurité paramétrable par injection de code, o pour analyser le contenu de ladite requête et de ses paramètres et o assurer conditionnellement la transmission de ladite requête à un module d'extraction 20 - ledit module d'extraction assurant la conversion de la requête en instructions JDBC transmises audit système de gestion de base de données - ledit module d'extraction recevant en réponse les données au format JDBC et assurant la conversion en flux 25 JSON - le serveur mandataire transmet ledit flux JSON à l'équipement client. 3062 2 2 2 16 2 - Procédé pour l'accès par un équipement informatique client à un système de gestion de base de données selon la revendication 1 caractérisé en ce que ledit module de sécurité paramétrable comporte des moyens de limitation du 5 nombre de lignes transmises. 3 - Procédé pour l'accès par un équipement informatique client à un système de gestion de base de données selon la revendication 1 caractérisé en ce que ledit module de sécurité paramétrable comporte des moyens de déclenchement d'une action en fonction de ladite requête analysée. 4 - Procédé pour l'accès par un équipement informatique client à un système de gestion de base de données selon la revendication précédente caractérisé en ce que ladite action est l'envoi d'un message de révocation d'un utilisateur. 5 - Procédé pour l'accès par un équipement informatique client à un système de gestion de base de données selon la revendication 3 caractérisé en ce que ladite action est l'envoi d'un message d'alerte. 6 - Procédé pour l'accès par un équipement informatique client à un système de gestion de base de données selon la revendication 1 caractérisé en ce que ledit module de sécurité paramétrable comprend un fichier de configuration par défaut.25