FR 3063822 A1 20180914 FR 1752004 A 20170310 - 1 - Procédé d'accès à une ressource informatique sécurisée par une application informatique. Domaine de l'invention La présente invention concerne le domaine de l'accès à une ressource informatique sécurisée par une application informatique dépourvue d'interaction homme-machine et plus particulièrement la gestion des mots de passe d'application à application. Elle concerne par exemple l'accès à des applications informatiques hébergées sur une plate-forme applicative de type "WebSphere Application Server" (nom commercial). A titre d'exemple, il s'agit de l'accès à des applications hébergées sur une plate-forme WebSphere (nom commercial d'IBM) proposant un ensemble de solutions développées qui permettent de développer, de déployer et d'utiliser des applications d'entreprise, même dans des cas complexes faisant appel à des applications et des matériels hétérogènes. Beaucoup d'applications, de services Web et de solutions logicielles requièrent l'accès à des ressources telles que des bases de données ou des serveurs de fichiers par exemple. L'accès à ces ressources nécessitent une authentification, le plus souvent au moyen d'un nom de compte et d'un mot de passe. Pour automatiser un tel processus de communication, une solution consiste à inclure les informations d'identification de l'application en texte clair dans les fichiers de configuration et les scripts. Les administrateurs ont généralement de la difficulté à identifier, modifier et gérer ces mots de passe 3063822 -2 - et de ce fait les mots de passe restent statiques et inchangés, ce qui créent des failles de sécurité. Par conséquent, les pouvoirs restent inchangés, ce 5 qui peut conduire à un accès non autorisé aux systèmes sensibles. Ainsi, les références de codage dur peuvent rendre les travaux des techniciens plus faciles, mais c'est aussi un point de lancement facile pour les pirates informatiques. Etat de la technique 10 Différentes solutions ont été proposées dans l'art antérieur, pour automatiser la gestion des mots de passe dans des contextes « application vers application ». Le brevet américain US7823192 décrit une solution qui permet aux applications sécurisées disparates de 15 communiquer directement avec autre application dans un environnement applicatif hétérogène, en prévoyant la création de jetons qui peuvent être transmis entre les applications sans intervention humaine. Dans ce document de l'art antérieur, les 20 informations de sécurité sont passées entre les applications sous la forme d'un jeton avec un type de données chaîne qui peut être reconnu par un grand nombre d'applications. Le jeton n'a pas d'entête et donc aucune configuration d'en-tête spécifique à l'application, ce qui en fait une plate-forme 25 indépendante. Ceci élimine la nécessité d'une conversion d'informations de sécurité entre les différents formats. L'utilisation de jetons élimine également la nécessité d'une demande d'authentification et d'autorisation à chaque fois qu'il envoie un message à une autre application. Au lieu d'un 30 contexte permanent ou session, un contexte est créé avec chaque invocation d'une application à une autre. 3063822 - 3 - On connaît aussi la demande de brevet européen EP2122526 décrivant une autre solution pour gérer des justificatifs d'identité, comprenant : - un module d'interception configuré pour 5 intercepter un processus de justificatifs d'identité lors de la réception de la demande par une application - un module de configuration/paramétrage configuré pour lire des configurations et paramétrages de système afin de gérer des justificatifs d'identité d'application 10 - un module d'association de justificatifs d'identité configuré pour appliquer une logique d'association de justificatifs d'identité sur la base des configurations et paramétrages du système. Le brevet américain US9160545 décrit une autre 15 solution d'accès sécurisé « applications à application » (A2A) et « application de base de données (A2DB) ». Ce procédé prévoit la réception d'une requête d'enregistrement à un premier dispositif numérique d'une première demande, la réception d'un premier facteur de 20 programme associé à la première application, ce qui confirme le premier élément de programme, la génération d'un premier mot de passe pour une seconde application à base d'au moins sur la confirmation du premier élément de programme, et fournir le premier mot de passe à un second élément numérique. 25 Inconvénients de l'art antérieur Les solutions de l'art antérieur ne sont pas totalement satisfaisantes. La solution proposée par le brevet US7823192 présente l'inconvénient de devoir modifier l'ensemble des 30 applications informatiques cibles hébergées, ce qui souvent n'est pas possible, notamment lorsqu'on ne dispose pas du code source de l'application hébergée. 3063822 - 4 - Ces solutions sont par ailleurs partielles car elles ne proposent pas de solutions pour protéger les données de connexion et d'authentification. Enfin, la solution proposée par le brevet US9160545 5 prévoit calcule une clé chiffrée transmise à l'application hébergée cible. Cette solution ne prévoit pas la sécurisation de la clé d'authentification originelle, ce qui implique une grande complexité d'administration, notamment en cas de changement de clé d'authentification de l'application 10 hébergée, par exemple en cas de modification de l'application cible hébergée ou d'installation sur le serveur d'une nouvelle version de l'application. Solution apportée par l'invention Afin de remédier à ces inconvénients, l'invention 15 concerne selon son acception la plus générale un procédé d'accès à une ressource informatique sécurisée par une application informatique dépourvue d'interaction homme-machine pour la saisie d'une information d'authentification, comportant : 20 a) une première étape d'initialisation comprenant : al) la création d'une clé cryptographique transitoire (non enregistrée dans une mémoire permanente) consistant à appliquer un traitement cryptographique à une pluralité d'informations invariantes dans le temps, et 25 représentatives de l'environnement informatique d'exécution de ladite application et à enregistrer le résultat de ce traitement a2) le chiffrement avec la clé ainsi calculée les données d'authentification d'un compte autorisé à accéder à un 30 coffre-fort à mots de passe a3) l'enregistrement dans une mémoire permanente associée à l'application le résultat de ce chiffrement (Fichier crédentiel) 3063822 - 5 - b) des étapes d'accès automatique par ladite application à ladite ressource informatique sécurisée consistant à : bl) Créer une clé cryptographique transitoire (non 5 enregistrée dans une mémoire permanente) consistant à appliquer un traitement cryptographique à ladite pluralité d'informations invariantes dans le temps, et représentatives de l'environnement informatique d'exécution de ladite application et à enregistrer le résultat de ce traitement 10 b2) lire le fichier crédentiel créé lors de l'étape d'initialisation et à déchiffrer ledit fichier crédentiel avec ladite clé cryptographique transitoire calculée à l'étape précédente et 15 b3) lors de la première exécution du procédé après l'étape d'initialisation, b3-1) à requérir auprès dudit coffre-fort par une identification à partir dudit fichier crédentiel, pour extraire les informations d'authentification nécessaire à 20 l'accès à ladite ressource informatique b3-2) à calculer une empreinte du contexte d'appel de l'application en fonction de données invariantes représentatives de ce contexte b3-3) à enregistrer ladite empreinte sous une forme 25 chiffrée dans une mémoire permanente associée à l'application le résultat de ce calcul b3-4) à transférer à l'application appelante les données provenant de ladite ressource informatique b4) lors des exécutions suivantes, 30 b4-1) à requérir auprès dudit coffre-fort par une identification à partir dudit fichier crédentiel, pour extraire les informations d'authentification nécessaire à l'accès à ladite ressource informatique 3063822 - 6 - b4-2) à calculer une empreinte du contexte d'appel de l'application en fonction de données invariantes représentatives de ce contexte b4-3) comparer l'empreinte calculée avec 5 l'empreinte enregistrée dans la mémoire locale et b4-4a) en cas de différence, refuser le transfert des données à l'application appelante b4-4b) en cas de conformité, à transférer à l'application appelante les données provenant de ladite 10 ressource informatique. Selon une première variante, ladite empreinte est calculée en fonction de données numériques comprenant le chemin d'accès à l'exécutable de l'application, le hash du 15 code binaire de l'exécutable, l'identité sous laquelle tourne le processus de l'application, Selon une deuxième variante, l'application est exécutée par un interpréteur ou une machine virtuelle, et en 20 ce que ladite empreinte est calculée en fonction de données obtenues par l'analyse de la ligne de commande du process et recherche du fichier correspondant au script ou au pseudo-code de l'application et le calcul du hash dudit pseudo-code. 25 Selon une troisième variante, l'empreinte et les données extraites du coffre-fort sont enregistrée dans une mémoire permanente locale sous forme cryptée dans un cache local. Selon un mode de mise en oeuvre particulier, 30 l'empreinte et les données extraites du coffre-fort numérique sont protégées par une technique d'offuscation. Selon une première variante, la technique d'offuscation statique consiste à supprimer le registre frame pointer ou à remplacer des constantes du programme par des 35 calculs récursifs. 3063822 - 7 - Selon une deuxième variante, la technique d'offuscation dynamique consiste à bloquer l'accès en cas de détection d'une opération de débogage. 5 L'invention concerne aussi un procédé d'initialisation d'un processus d'accès à une ressource informatique sécurisée par une application informatique dépourvue d'interaction homme-machine pour la saisie d'une information d'authentification, conforme au procédé d'accès 10 précité ainsi qu'un procédé d'accès automatique par ladite application à ladite ressource informatique sécurisée conforme au procédé d'accès précité. Description détaillée d'un exemple non limitatif de réalisation 15 La présente invention sera mieux comprise à la lecture de la description détaillée d'un exemple non limitatif de l'invention qui suit, se référant aux dessins annexés où : 20 la figure 1 représente une du contexte de l'invention vue schématique schématique schématique fonctionnelle la figure 2 représente une du processus d'initialisation vue fonctionnelle 25 fonctionnelle la figure 3 représente une de l'invention. vue Contexte de l'invention La figure 1 représente une vue schématique du fonctionnement d'une solution d'accès par des applications hébergées par WebSphere (nom commercial) à des ressources 30 telle qu'une base de données. 3063822 - 8 - Un ordinateur client (11) sur lequel est installée une application de type navigateur internet communique avec un serveur Web externe (10) (Apache, Nginx, IHS ..) en utilisant le protocole de communication de base HTTP(S) afin d'envoyer 5 des requêtes (connexion au serveur, page d'accueil..). Ces requêtes sont dirigées vers le serveur Web interne (12) d'un serveur d'application (1) et ce dernier les dirige vers un conteneur Web (13). Le navigateur (11) peut se connecter directement au serveur interne. Dans l'exemple 10 décrit, le serveur d'application (1) est isolé et les connexions se font à travers le serveur Web externe (10). Le conteneur Web (14) contient les Servlets et les JSPs (JPS contient les pages Web dynamique, Et Servlets pour créer dynamiquement des données) et se connecter quand il en a 15 besoin à une application ou une base de donnée (3). Les composants logiciels EJB qui sont dans le conteneur (13) peuvent communiquer avec la base de données (3) afin de récupérer, modifier, supprimer des données, etc ... L'interface JDBC assure la connection à n'importe quelle base 20 de données Oracle, Mysql, .... Les clients Webservice comme les applications mobiles/tablettes peuvent accéder au serveur d'application en utilisant le protocole SOAP encapsulé dans le protocole HTTP et passé directement à travers le serveur HTTP interne 25 Un client Java pur (14) peut se connecter directement au conteneur EJB (13) en utilisant les protocoles EMI/II0P. L'application (1) exécutée sur un serveur distant (10) lit les informations dans un fichier de configuration (2) 30 qui est enregistré sur le même serveur distant, pour se connecter à une base de données (3) locale, ou distante sur le même serveur ou un serveur tiers. 3063822 - 9 - Schéma de fonctionnement Le procédé d'accès selon l'invention se décompose en trois parties : - un processus d'initialisation 5 - un processus d'accès lors d'une première exécution - un processus d'accès pour les exécutions suivantes. Processus d'initialisation 10 Ce processus illustré par la figure 2 consiste à calculer clé cryptographique transitoire par l'exécution d'un code informatique sur le serveur Websphère hébergeant la ressource cible, par exemple une application hébergée. L'utilisateur (4) lance la commande correspondant à 15 l'exécution du procédé objet de l'invention. Cette exécution commande l'étape d'initialisation. Cette étape consiste à demander à l'utilisateur de saisir les données d'authentification nécessaire pour l'accès à un coffre-fort numérique dans lequel sont enregistrées les 20 données d'authentification aux ressources hébergées auxquelles l'application du serveur Websphere (nom commercial) doit accéder. Le coffre-fort numérique est enregistré sur un équipement distant, par exemple un boîtier physique ou virtuel. 25 La commande (6) récupère la ou les données d'authentification et les chiffrent en appliquant un algorithme cryptographique. A cet effet, la commande déclenche le calcul d'une clé transitoire utilisant des paramètres correspondant à des 30 données invariantes caractérisant l'environnement d'exécution de la commande. Il s'agit par exemple : 3063822 - 10 - - du nom ou l'identifiant de l'ordinateur sur lequel est exécutée la commande - du nom de la commande - du condensat du code exécutable de cette 5 commande - de l'identifiant du propriétaire de l'exécutable - Les données d'authentification sont chiffrées avec la clé transitoire ainsi calculée, et enregistrées sur le 10 serveur WebSphere dans un fichier crédentiel (5). Premier accès à la ressource hébergée La figure 3 illustre le processus d'accès à la ressource hébergée. Le lancement de la commande (6) par le serveur 15 Websphre en mode de premier accès provoque l'exécution d'une étape de récupération dans le fichier crédentiel (5) des données d'authentification permettant d'accéder à la ressource, sous une forme chiffrée. La commande (6) lance ensuite une étape de 20 déchiffrement (8) des données d'authentification chiffrées par l'algorithme de déchiffrement basé sur les mêmes paramètres invariants que ceux qui ont permis le calcul de la clé de chiffrement lors de l'étape d'initialisation. La commande lance ensuite une étape (9) d'accès au 25 coffre numérique (10) contenant les données d'authentification à la ressource distante (11) et de calcul de l'empreinte de l'application (12) appelante. On chiffre ensuite les données d'authentification à la ressource distante (11) et l'empreinte de l'application 30 (12) appelante avec la clé utilisée pour le chiffrement du fichier crédentiel, et en enregistre les données ainsi chiffrées dans une mémoire locale (13) sur l'ordinateur sur lequel est exécutée l'application Websphère. 3063822 La dernière étape (14) consiste à fournir les données d'authentification (11) à l'application (12), pour permettre l'accès (16) à la ressource distante (15). 5 Accès ultérieur à la ressource hébergée Les accès ultérieurs mettent en oeuvre les mêmes étapes, à l'exception de l'étape précédent l'étape (14). L'empreinte de l'application (12) étant déjà enregistrée dans 10 la mémoire locale (13) lors de l'accès initial, on compare cette empreinte déjà enregistrée avec celle nouvellement calculée. Si les deux empreintes diffèrent, le traitement est interrompu et envoie un message d'erreur. 15 Sinon, le processus se poursuit par l'étape (14) consistant à fournir les données d'authentification (11) à l'application (12), pour permettre l'accès (16) à la ressource distante (15). Indisponibilité du coffre fort (10) 20 Dans le cas où l'accès au coffre-fort (10) n'est pas possible, on utilise les données d'authentification déjà enregistrées dans la mémoire locale (13) sans mise à jour. REVENDICATIONS1 - Procédé d'accès à une ressource informatique sécurisée (3) par une application informatique (1) dépourvue d'interaction homme-machine pour la saisie d'une information 5 d'authentification, comportant : a) une première étape d'initialisation comprenant : al) la création d'une clé cryptographique transitoire (non enregistrée dans une mémoire permanente) consistant à appliquer un traitement cryptographique à une 10 pluralité d'informations invariantes dans le temps, et représentatives de l'environnement informatique d'exécution de ladite application et à enregistrer le résultat de ce traitement a2) le chiffrement avec la clé ainsi calculée les 15 données d'authentification d'un compte autorisé à accéder à un coffre-fort à mots de passe a3) l'enregistrement dans une mémoire permanente associée à l'application le résultat de ce chiffrement (Fichier crédentiel) 20 b) des étapes d'accès automatique par ladite application à ladite ressource informatique sécurisée consistant à : bl) Créer une clé cryptographique transitoire (non enregistrée dans une mémoire permanente) consistant 25 à appliquer un traitement cryptographique à ladite pluralité d'informations invariantes dans le temps, et représentatives de l'environnement informatique d'exécution de ladite application et à enregistrer le résultat de ce traitement b2) lire le fichier crédentiel créé lors de l'étape 30 d'initialisation et à déchiffrer ledit fichier crédentiel avec ladite clé cryptographique transitoire calculée à l'étape précédente et 3063822 - 13 - b3) lors de la première exécution du procédé après l'étape d'initialisation, b3-1) à requérir auprès dudit coffre-fort par une identification à partir dudit fichier crédentiel, pour 5 extraire les informations d'authentification nécessaire à l'accès à ladite ressource informatique b3-2) à calculer une empreinte du contexte d'appel de l'application en fonction de données invariantes représentatives de ce contexte 10 b3-3) à enregistrer ladite empreinte sous une forme chiffrée dans une mémoire permanente associée à l'application le résultat de ce calcul b3-4) à transférer à l'application appelante les données provenant de ladite ressource informatique 15 b4) lors des exécutions suivantes, b4-1) à requérir auprès dudit coffre-fort par une identification à partir dudit fichier crédentiel, pour extraire les informations d'authentification nécessaire à l'accès à ladite ressource informatique 20 b4-2) à calculer une empreinte du contexte d'appel de l'application en fonction de données invariantes représentatives de ce contexte b4-3) comparer l'empreinte calculée avec l'empreinte enregistrée dans la mémoire locale et 25 b4-4a) en cas de différence, refuser le transfert des données à l'application appelante b4-4b) en cas de conformité, à transférer à l'application appelante les données provenant de ladite ressource informatique. 30 2 - Procédé selon la revendication 1 caractérisé en ce que ladite empreinte est calculée en fonction de données numériques comprenant le chemin d'accès à l'exécutable de l'application, le hash du code binaire de l'exécutable, 35 l'identité sous laquelle tourne le processus de l'application, 3063822 - 14 - 3 - Procédé selon la revendication 1 caractérisé en ce que l'application est exécutée par un interpréteur ou une machine virtuelle, et en ce que ladite empreinte est calculée en fonction de données obtenues par l'analyse de la ligne de commande du process et recherche du fichier correspondant au script ou au pseudo-code de l'application et le calcul du hash dudit pseudo-code. 4 - Procédé selon la revendication 1 caractérisé en ce que l'empreinte et les données extraites du coffre-fort numérique sont protégées par une technique d'offuscation. 5 - Procédé selon la revendication 4 caractérisé en ce que 15 la technique d'offuscation statique consiste à supprimer le registre frame pointer. 6 - Procédé selon la revendication 4 caractérisé en ce que la technique d'offuscation statique consiste à remplacer des 20 constantes du programme par des calculs récursifs. 7 - Procédé selon la revendication 5 caractérisé en ce que la technique d'offuscation dynamique consiste à bloquer l'accès en cas de détection d'une opération de débogage. 25 8 - Procédé d'initialisation d'un processus d'accès à une ressource informatique sécurisée par une application informatique dépourvue d'interaction homme-machine pour la saisie d'une information d'authentification, conforme à la 30 revendication 1, caractérisé en ce qu'il comporte : a) une première étape d'initialisation comprenant : al) la création d'une clé cryptographique transitoire (non enregistrée dans une mémoire permanente) consistant à appliquer un traitement cryptographique à une 35 pluralité d'informations invariantes dans le temps, et 3063822 - 15 - représentatives de l'environnement informatique d'exécution de ladite application et à enregistrer le résultat de ce traitement a2) le chiffrement avec la clé ainsi calculé les 5 données d'authentification d'un compte autorisé à accéder à un coffre-fort à mots de passe a3) l'enregistrement dans une mémoire permanente associée à l'application le résultat de ce chiffrement (Fichier crédentiel). 10 9 - Procédé d'accès automatique par ladite application à ladite ressource informatique sécurisée conforme à la revendication 1, caractérisé en ce qu'il comporte : b) des étapes d'accès automatique par ladite 15 application à ladite ressource informatique sécurisée consistant à : bl) Créer une clé cryptographique transitoire (non enregistrée dans une mémoire permanente) consistant à appliquer un traitement cryptographique à une pluralité 20 d'informations invariantes dans le temps, et représentatives de l'environnement informatique d'exécution de ladite application et à enregistrer le résultat de ce traitement b2) lire le fichier crédentiel créé lors de l'étape d'initialisation et à déchiffrer ledit fichier crédentiel avec 25 ladite clé cryptographique transitoire calculée à l'étape précédente et b3) lors de la première exécution du procédé après l'étape d'initialisation, 30 b3-1) à requérir auprès dudit coffre-fort par une identification à partir dudit fichier crédentiel, pour extraire les informations d'authentification nécessaire à l'accès à ladite ressource informatique 3063822 - 16 - b3-2) à calculer une empreinte du contexte d'appel de l'application en fonction de données invariantes représentatives de ce contexte b3-3) à enregistrer ladite empreinte sous une forme 5 chiffrée dans une mémoire permanente associée à l'application le résultat de ce calcul b3-4) à transférer à l'application appelante les données provenant de ladite ressource informatique. 10 10 - Procédé d'accès automatique par ladite application à ladite ressource informatique sécurisée conforme à la revendication 1, caractérisé en ce qu'il comporte : b) des étapes d'accès automatique par ladite 15 application à ladite ressource informatique sécurisée consistant à : bl) Créer une clé cryptographique transitoire (non enregistrée dans une mémoire permanente) consistant à appliquer un traitement cryptographique à une pluralité 20 d'informations invariantes dans le temps, et représentatives de l'environnement informatique d'exécution de ladite application et à enregistrer le résultat de ce traitement b2) lire le fichier crédentiel créé lors de l'étape d'initialisation et à déchiffrer ledit fichier crédentiel avec 25 ladite clé cryptographique transitoire calculée à l'étape précédente et lors des exécutions, b4-1) à requérir auprès dudit coffre-fort par une identification à partir dudit fichier crédentiel, pour 30 extraire les informations d'authentification nécessaire à l'accès à ladite ressource informatique b4-2) à calculer une empreinte du contexte d'appel de l'application en fonction de données invariantes représentatives de ce contexte 3063822 - 17 - b4-3) comparer l'empreinte calculée avec l'empreinte enregistrée dans la mémoire locale et b4-4a) en cas de différence, refuser le transfert des données à l'application appelante 5 b4-4b) en cas de conformité, à transférer à l'application appelante les données provenant de ladite ressource informatique.