Brevet FR3033434A1 — publié le 20160909

- 1 - Transfert sécurisé d'information d'authentification Domaine de l'invention La présente invention concerne le domaine des serveurs d'application, et plus particulièrement des procédés et des systèmes d'accès à des ressources applicatives hébergées sur un ou plusieurs serveurs, par un utilisateur. Etat de la technique On connaît en particulier dans l'état de la technique la demande de brevet internationale WO 2014064686 décrivant un système et procédé d'authentification sécurisée basée sur une passerelle mandataire. Ce document divulgue un système et un procédé d'authentification sécurisée facilitant l'amélioration de la sécurité d'une authentification entre un client et une cible au moyen d'un module d'authentification innovant sur une passerelle mandataire. Selon l'invention, le client peut se connecter à la passerelle mandataire au moyen d'un protocole natif et fournit des informations d'identification d'utilisateur à la passerelle mandataire. L'invention facilite la connexion entre le client et la cible de sorte qu'il est inutile, pour l'utilisateur, d'être en possession des informations d'identification d'accès de cible. La passerelle mandataire peut éventuellement être connectée à un système de gestion d'accès privilégié qui peut fournir et/ou stocker des informations d'identification d'accès de cible. Les informations d'identification d'accès de cible fournies par la passerelle mandataire facilitent la prévention contre une faille dans la sécurité du client qui expose les informations d'identification d'accès de cible. 3033434 - 2 - Inconvénients de l'art antérieur La solution proposée par la demande W02014064686 ne concerne pas explicitement un procédé d'accès sécurisé à des applications mais seulement à des ressources d'infrastructure 5 telles qu'un serveur ou un routeur. Cette demande concerne l'accès à une cible, correspondant expressément à un serveur et non pas une application hébergée par un serveur. Solution apportée par l'invention L'objet de la présente invention n'est pas 10 seulement de sécuriser l'accès à un serveur, mais plus précisément de sécuriser l'accès à des applications hébergées sur un serveur, afin de permettre par exemple l'utilisation à un compte partagé par plusieurs utilisateurs en gardant l'imputabilité des actions opérées sous ce compte. 15 A cet effet, l'invention concerne selon son acception la plus générale un procédé de connexion sécurisée à une application exécutée sur un serveur depuis un équipement informatique client, par un utilisateur ne disposant pas des données d'authentification du compte déclaré dans ladite 20 application, ledit compte comprenant au moins une identité et des données d'authentification associées, IDproxy, application mettant en oeuvre un proxy [passerelle mandataire] comprenant une mémoire pour l'enregistrement, pour chaque utilisateur déclaré par un compte primaire comprenant au moins une 25 identité IDutilisateur f ressources, comptes de la liste des cibles C il a accès, le procédé comprenant les étapes suivantes : - ouverture par l'utilisateur d'une connexion à un proxy au moyen d'un protocole d'administration natif multicanal [SSH, RDP ou ICA,...], avec une première identité IDutilisateur 30 pour l'ouverture d'une session multicanale primaire - définition simultanée [dans les paramètres de connexion] ou séquentielle [sélection après ouverture de la auquel 3033434 - 3 connexion parmi une liste proposée par le proxy] de l'application (cible). - connexion du proxy au serveur d'hébergement de ladite application sélectionnée au moyen du même protocole 5 d'administration natif multicanal [SSH, RDP ou ICA,...] avec une seconde identité ID pour ouvrir une proxy, serveur .._ session multicanal secondaire - enregistrement temporaire d'une information Irelai correspondant au lien entre ladite session primaire et 10 ladite session secondaire - exécution sur le serveur d'un code informatique [script] ouvrant un canal entre ledit serveur et ledit proxy, dans le cadre de ladite session secondaire, - envoie par ledit code sur ledit canal d'une requête 15 demandant, pour ladite application et ledit compte, les données d'authentification [password] - en réponse à cette requête, transmission par le proxy de ces données d'authentification si la cible définie par ladite application et ledit compte appartient à la liste 20 des cibles Cressources, comptes enregistrées pour ledit utilisateur - et exécution de ladite application et transmission à ladite application par ledit code des données utilisateurs ou notification d'erreur si le compte 25 n'appartient pas à ladite liste. Un des avantages de ce procédé est que l'application peut ensuite être utilisée grâce à la même connexion que celle ayant servie à l'accès à la passerelle. Avantageusement, le procédé comporte en outre une 30 étape de sélection d'un serveur d'application parmi une pluralité de serveur hébergeant la même application. Selon un mode de mise en oeuvre particulier, ledit code informatique est enregistré sur le serveur d'application. 3033434 - 4 De préférence, ledit code informatique est enregistré par le proxy sur ledit serveur d'application avec un nom à usage unique. 5 Selon une variante, ledit code informatique enregistré sur le serveur d'application contient un jeton à usage unique transmis avec ladite requête. De préférence, l'application peut être utilisée par 10 deux utilisateurs différents ayant pour identités ID utilisateur A et ID utilisateur 13' Pour cela, chacune des sessions secondaires est exécutée avec une identité différente (IDproxy,serveur A et IDproxy, serveur B). Ces identités sont choisies automatiquement par le proxy parmi les identités configurées de façon à ne jamais avoir au 15 même moment deux sessions secondaires avec la même identité. Description détaillée d'un exemple non limitatif de réalisation 20 La présente invention sera mieux comprise à la lecture de la description qui suit, se référant à des exemples non limitatifs de réalisation, illustrés par les dessins annexés où : - la figure 1 représente un schéma de l'architecture 25 fonctionnelle de l'invention - la figure 2 représente un schéma de l'architecture fonctionnelle d'une variante de réalisation de l'invention - la figure 3 représente une vue schématique des données 30 échangées entre les différentes ressources informatiques. 3033434 - 5 - Architecture fonctionnelle L'utilisateur est un administrateur de ressources d'un système d'information (SI) (serveurs, applications, 5 routeurs...) disposant de droits limités d'administrateur, pour un ensemble de ressources dont il a la charge. Il dispose d'un terminal (100) communiquant avec la passerelle mandataire (300) (ou « passerelle d'administration ») par l'intermédiaire d'un canal (201) d'une 10 connexion (200) selon un protocole par exemple SSH (« secure shell ») ou RDP (« remote desktop protocol»). La connexion entraîne la création d'une session primaire (301) sur la passerelle (300). L'utilisateur est identifié par des identifiants 15 numériques qui lui sont propres, et définissant ses droits, ainsi que l'imputation des actions qu'il effectue. La passerelle (300) comporte une base de données (302) dans laquelle sont enregistrés les identifiants des utilisateurs autorisés ainsi que les droits associés, 20 définissant les cibles (comptes et équipements) sur lesquelles l'utilisateur est en droit d'agir. Lors de la connexion, deux modes de sélection de la ressource sont possibles : - selon le premier mode, l'utilisateur précise, lors de la 25 connexion, la cible à laquelle il veut accéder. Dans ce cas la passerelle vérifie si l'utilisateur identifié par son identifiant dispose des autorisations nécessaires pour accéder à cette cible, en fonction des informations enregistrées dans la base de données (302). 30 - Selon le deuxième mode, la passerelle transmet à l'utilisateur la liste des cibles correspondant aux données enregistrées dans la base de données (302) en relation avec l'identifiant transmis, pour permettre à l'utilisateur de sélectionner l'une des cibles proposées. 3033434 - 6 - L'étape suivante consiste à ouvrir une connexion (400), généralement avec le même protocole SSH ou RDP, ou encore avec un deuxième protocole avec le compte associé à la cible sélectionnée. Cette connexion ouvre une session 5 secondaire (501) sur la cible. Lorsque la cible est une application (504), la passerelle (300) choisi le serveur (500) adéquat à l'exécution de ladite application. A cet effet, la base de données (302) comprend une liste des applications et des serveurs hébergeant 10 chacune desdites applications, ainsi que les comptes permettant de se connecter à ces serveurs. Lorsque plusieurs serveurs hébergent une même application, la passerelle réalise une balance des charges en fonction du nombre de connexions déjà ouvertes vers chacun des 15 serveurs, et sélectionne pour la nouvelle requête le serveur le moins sollicité. De même, en absence de réponse par un serveur hébergeant une application, la passerelle recherche successivement les autres serveurs hébergeant la même 20 application, pour sélectionner une cible disponible. L'étape suivante consiste à exécuter un code informatique (502) pour : - interroger la passerelle (requête 402) en vue d'obtenir les informations d'authentification correspondant au 25 compte de l'application, c'est-à-dire l'identifiant I Dproxy , application ainsi que les données d'authentification associées à ce compte, par exemple un mot de passe ou cryptographique, ou un ticket Kerberos. Ces renvoyées par la passerelle (réponse 403). La 30 réponse sont effectuées dans un canal ouvert à le code informatique. - injecter ces données (503) dans un certificat données sont requête et la cet effet par l'application (504) afin d'ouvrir une session applicative et permettre à l'utilisateur d'utiliser ladite application. 35 Ce code peut être : 3033434 - 7 - - installé sur le serveur (500) de manière permanente. Dans ce cas, le chemin d'accès à ce code est défini dans la base de données (302) - ou transmis transitoirement, par un canal dédié (401) 5 prévu dans le protocole multicanal, pour être exécuté transitoirement sur le serveur (500). Le nom de ce code peut être généré de manière unique, afin de rendre plus difficile l'altération de ce code pendant l'exécution de l'application, par une attaque 10 informatique. Ce code installé transitoirement peut également comporter un jeton unique afin de réduire les risques d'accès non autorisé aux données enregistrées dans la base (302), au moyen de la session ouverte, par un attaquant ayant accès au 15 serveur (500). Accès concurrent à des applications sur un même serveur par plusieurs utilisateurs. 20 La figure 2 représente un schéma fonctionnel d'une solution permettant à plusieurs utilisateurs d'accès à des applications hébergées sur un même serveur. Le but est d'éviter les interférences entre les sessions primaires (200 et 250), et de les rendre étanches en termes de sécurité. 25 A cet effet, lorsqu'un second utilisateur (150) cherche à exécuter une application hébergée sur le même serveur (500) qu'une application exécutée pour un premier utilisateur (100), la passerelle (300) inhibera les données de la base (302) relatives au compte utilisé par le premier 30 utilisateur (100), sur le serveur (500). Elle n'autorisera l'exécution d'une application sur ce même serveur (500) que si un compte reste disponible pour un second utilisateur (150). Données échangées entre les ressources informatiques 35 3033434 - 8 - La figure 3 représente une vue schématique des données échangées entre les différentes ressources informatiques. Lors de la connexion par un utilisateur, le 5 terminal (100) transmet à la passerelle mandataire (300) les données d'authentification numériques suivantes : - IDutilisateur _ Mot de passe 10 Ces données d'authentification peuvent être constituées, à la place du mot de passe, d'un ticket Kerberos ou d'un certificat X509). Ces données d'authentification sont vérifiées par la passerelle (300), en fonction des informations enregistrées 15 dans sa base de données (302). En cas de validation, la passerelle (302) transmet la liste des cibles autorisées. Chaque cible correspond à un couple : - application 20 - compte associé à l'application. Le compte comprend : - une information d'identification - une information d'authentification, telle qu'un mot de passe. 25 La passerelle transmet à l'utilisateur (100), pour chacune des cibles autorisées, seulement la désignation de l'application et la désignation de l'identifiant du compte, mais pas l'information d'authentification, sous la forme de chaines de caractères désignant les couples 30 application/compte. L'utilisateur (100) sélectionne l'une des cibles proposées et en transmet l'identifiant à la passerelle (300). La passerelle (300) choisit un serveur, et un compte pour ouvrir une session sur ledit serveur (500) selon 3033434 - 9 - le processus de sélection du serveur et du compte préalablement décrit. Elle ouvre ainsi une session secondaire, sur le serveur, en exécutant le code informatique correspondant à 5 l'application. Ce code demande à la passerelle l'identifiant du compte de l'application ainsi que les données d'authentification associées à ce compte. Le code informatique transmet alors ces informations à l'application pour commander l'exécution de 10 l'application. L'invention permet au code informatique d'interroger la passerelle sans nécessiter de nouvelle authentification par l'utilisateur, car il le fait par le 15 biais d'une connexion déjà authentifiée. REVENDICATIONS1 - Procédé de connexion sécurisé à une application exécutée sur un serveur depuis un équipement informatique 5 client, par un utilisateur ne disposant des données d'authentification du compte déclaré dans ladite application, ledit compte comprenant au moins une identité IDproxy,application et des données d'authentification associées, mettant en oeuvre un proxy [passerelle mandataire] comprenant une mémoire pour 10 l'enregistrement, pour chaque utilisateur déclaré par un compte primaire comprenant au moins une identité IDutilisateur/ de la liste des cibles C ressources, comptes auquel il a accès, le procédé comprenant les étapes suivantes : - ouverture par l'utilisateur d'une connexion avec un proxy 15 au moyen d'un protocole d'administration natif multicanal [SSH, RDP ou ICA,...], avec une première identité ID utilisateur pour l'ouverture d'une session multicanale primaire - définition simultanée [dans les paramètres de connexion] ou séquentielle [sélection après ouverture de la 20 connexion parmi une liste proposée par le proxy] de l'application - connexion du proxy au serveur d'hébergement de ladite application sélectionnée au moyen du même protocole d'administration natif multicanal [SSH, RDP ou ICA,...] 25 avec une seconde identité ID pour ouvrir une IDproxy,serveur .._ p session multicanal secondaire - enregistrement temporaire d'une information Irelai correspondant au lien entre ladite session primaire et ladite session secondaire 30 - exécution sur le serveur d'un code informatique [script] ouvrant un canal entre ledit serveur et ledit proxy, dans le cadre de ladite session secondaire, 3033434 - envoie par ledit code sur ledit canal d'une requête demandant, pour ladite application et ledit compte, les données d'authentification [password] - en réponse à cette requête, transmission par le proxy de ces données d'authentification si la cible définie par ladite application et ledit compte appartient à la liste des cibles Cressources, comptes / associées à un identifiant Ipproxy, application / enregistrée pour ledit utilisateur - et exécution de ladite application et transmission à ladite application par ledit code des données utilisateurs ou notification d'erreur si le compte n'appartient pas à ladite liste. 2 - Procédé de connexion sécurisée à une application selon la revendication 1 caractérisé en ce qu'il comporte en outre une étape de sélection d'un serveur d'application parmi une pluralité de serveur hébergeant la même application. 3 - Procédé de connexion sécurisée à une application selon la revendication 1 caractérisé en ce que ledit code informatique est enregistré sur le serveur d'application. 4 - Procédé de connexion sécurisé à une application selon la revendication 3 caractérisé en ce que ledit code informatique est enregistré par le proxy sur ledit serveur d'application avec un nom à usage unique. 5 - Procédé de connexion sécurisé à une application selon la revendication 3 ou 4 caractérisé en ce que ledit code informatique enregistré sur le serveur d'application contient un jeton à usage unique transmis avec ladite requête. 3033434 - 12 - 6 - Procédé de connexion sécurisé à une application selon la revendication 3 ou 4 caractérisé en ce que l'application peut être utilisée par deux utilisateurs différents ayant pour identités IDutilisateur A et I Dutilisateur B - Pour 5 cela, chacune des sessions secondaires est exécutée avec une identité différente (IDproxy, /serveur Alesdits et IDproxy, serveur B ) 1 identités étant choisies automatiquement par le proxy parmi les identités configurées de façon à ne jamais avoir au même moment deux sessions secondaires avec la même identité. 10