APPLICATION INFORMATIQUE .

Domaine de 1 ' 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écessite 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 et de ce fait les mots de passe restent statiques et inchangés, ce qui crée des failles de sécurité.

Par conséquent, les pouvoirs restent inchangés, ce 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 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 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 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 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 contexte permanent ou session, un contexte est créé avec chaque invocation d'une application à une autre. 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 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

— 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 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 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. 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 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. 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 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 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 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 :

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 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 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) 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 à 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 d'initialisation et à déchiffrer ledit fichier crédentiel avec 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,

b3-l) à 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

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 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,

b4-l) à 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 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

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.

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 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 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. Selon une troisième variante, l'empreinte et les données extraites du coffre-fort sont enregistrées dans une mémoire permanente locale sous forme cryptée dans un cache local .

Selon un mode de mise en œuvre particulier, 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 calculs récursifs. 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. 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 à la revendication 1 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

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ù : — la figure 1 représente une vue schématique fonctionnelle du contexte de l'invention

— la figure 2 représente une vue schématique fonctionnelle du processus d'initialisation

— la figure 3 représente une vue schématique fonctionnelle de l'invention.

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 telle qu'une base de données. 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 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 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 besoin à une application ou une base de données (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 connexion à n'importe quelle base 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

Un client Java pur (14) peut se connecter directement au conteneur EJB (13) en utilisant les protocoles EMI/IIOP.

L'application (1) exécutée sur un serveur distant (10) lit les informations dans un fichier de configuration (2) 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 . Schéma de fonctionnement

Le procédé d'accès selon l'invention se décompose en trois parties :

- un processus d'initialisation

- 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 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 à 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 données d ' authentification aux ressources hébergées auxquelles l'application du serveur Websphère (nom commercial) doit accéder. Le coffre-fort numérique est enregistré sur un équipement distant, par exemple un boîtier physique ou virtuel .

La commande (6) récupère la ou les données d ' authentification et les chiffre en appliquant un algorithme cryptographique .

A cet effet, la commande déclenche le calcul d'une clé transitoire utilisant des paramètres correspondant à des données invariantes caractérisant l'environnement d'exécution de la commande. Il s'agit par exemple : - du nom ou l'identifiant de l'ordinateur sur lequel est exécutée la commande

- du nom de la commande

- du condensât du code exécutable de cette 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 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 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 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 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 (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. 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).

Accès ultérieur à la ressource hébergée

Les accès ultérieurs mettent en œuvre les mêmes étapes, à l'exception de l'étape précédant l'étape (14). L'empreinte de l'application (12) étant déjà enregistrée dans 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.

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) 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.