[go: up one dir, main page]

WO2020141277A1 - Procédé de connexion d'une application informatique à une ressource informatique sécurisée - Google Patents

Procédé de connexion d'une application informatique à une ressource informatique sécurisée Download PDF

Info

Publication number
WO2020141277A1
WO2020141277A1 PCT/FR2019/053299 FR2019053299W WO2020141277A1 WO 2020141277 A1 WO2020141277 A1 WO 2020141277A1 FR 2019053299 W FR2019053299 W FR 2019053299W WO 2020141277 A1 WO2020141277 A1 WO 2020141277A1
Authority
WO
WIPO (PCT)
Prior art keywords
resource
client program
computer
safe
application
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/FR2019/053299
Other languages
English (en)
Inventor
Serge Adda
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Wallix SARL
Original Assignee
Wallix SARL
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Wallix SARL filed Critical Wallix SARL
Priority to CA3121595A priority Critical patent/CA3121595A1/fr
Priority to US17/418,717 priority patent/US12047364B2/en
Priority to EP19848991.6A priority patent/EP3906635A1/fr
Publication of WO2020141277A1 publication Critical patent/WO2020141277A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/08—Protocols specially adapted for terminal emulation, e.g. Telnet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/141—Setup of application sessions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0872—Generation of secret information including derivation or calculation of cryptographic keys or passwords using geo-location information, e.g. location data, time, relative position or proximity to other entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0866—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving user or device identifiers, e.g. serial number, physical or biometrical information, DNA, hand-signature or measurable physical characteristics

Definitions

  • This model of network architecture includes a set of technologies having in common a centralized control of network resources, a centralized orchestration and a virtualization of physical resources.
  • Devops is a movement in computer engineering and a technical practice aimed at the unification of software development (dev) and administration of IT infrastructures (ops), including system administration.
  • the secure IT resource has no human-computer interaction for entering authentication information.
  • the proposed method comprises a) a first initialization step comprising the creation of a transient cryptographic key consisting in applying a cryptographic processing to a plurality of information invariant in time and in encrypting with the transient cryptographic key thus calculated data d authentication of an account authorized to access a password safe and b) steps for automatic access by the application to the secure computer resource consisting in creating a transient cryptographic key consisting in applying cryptographic processing to the plurality of information invariant in time, to read the credential file, for English credential, created during the initialization step and to decrypt the credential file with the transient cryptographic key calculated in the previous step and then to transfer data from the IT resource to the calling application.
  • An object of the invention is in particular to remedy all or part of the aforementioned drawbacks.
  • a method is proposed for connecting a computer application to a computer resource secured by a facade control.
  • the computer application is initially configured to establish a connection to the secure resource using a client program and configuration parameters.
  • the client program implements a client part of a communication protocol and is configured to receive authentication data as input.
  • the computer application is of the devops type, that is to say a computer application configured for the remote management of resources.
  • the computer application can be configured to be able to configure the remote resource without human-machine interaction for entering authentication information. According to one possibility, the computer application is devoid of human-computer interaction for entering authentication information.
  • the present description relates for example to the SSH protocol, for Secure SHell.
  • client program By client program implementing a client part of a communication protocol, the present description relates for example to the client program also known as SSH.
  • connection method may include an initial step of interposing a facade command between the computer application and the client program, such as the SSHPASS command (https: //sourceforge.net/ p / sshpass), which is used only to allow the password to be passed on the command line, which the SSH client does not allow natively for security reasons.
  • SSHPASS command https: //sourceforge.net/ p / sshpass
  • connection method according to the first aspect of the invention comprises:
  • a password vault also designated by the term vault e n English, relates to a software module which stores a certain number of passwords in a secure digital location. By encrypting password storage, the password vault provides users with the ability to use a single master password to access a number of different passwords used for different websites or services.
  • the step of establishing a connection between the front panel control and the secure IT resource may include a modification of the configuration parameters received and an injection of the modified configuration parameters in the client program.
  • the configuration parameters retrieved can be modified, for example in order to adapt to the type of connection data extracted from the vault. For example, when the computer application is Ansible, the latter supposes the use of SSH keys and the parameters received thus comprise parameters of the SSH command with a view to using an SSH key. However, it can happen that the authentication data are of password type in which case it is necessary to modify the parameters before their injection into the SSH command.
  • the front control can include a step of modifying the authentication data by the vault later on receipt of the notification of end of use.
  • the method may include, subsequent to the step of receiving authentication data for access to the secure computer resource, and prior to the step of establishing a connection between the front control and the computer resource secure, the following steps:
  • the method may include a prior step of recording an encrypted fingerprint in the permanent memory, the encrypted borrowing resulting from the encryption of the encryption of a fingerprint of the call context of the client program as a function of invariant data representative of this context.
  • the transient cryptographic key being determined by calculation from the application of a cryptographic processing to a plurality of information invariant in time, and representative of the computer environment for execution of said application.
  • a fingerprint of the call tree of the client program is determined.
  • the facade command can comprise, before determining the imprint of the call tree, a waiting step which s 'ends when the client program process code has a code identical to the client program code.
  • the fingerprint and data retrieved from the vault are stored in local permanent memory in encrypted form in a local cache.
  • the fingerprint and the data extracted from the digital safe are protected by an obfuscation technique.
  • the obfuscation technique is static consists in removing the register register pointer or in replacing constants of the program by recursive computations.
  • the dynamic obfuscation technique is to block access if a debugging operation is detected.
  • FIG. 2 represents a functional schematic view of an initialization process of the method described in FIG. 1,
  • FIG. 3 represents a functional schematic view of part of the method for accessing the computer resource described in FIG. 1,
  • FIG. 4 represents a schematic view of a chain of treatments in an access method according to the invention
  • FIG. 5 represents a schematic view of a diagram of a call tree of the access method according to the invention
  • FIG. 6 represents is a pseudo-code of a waiting loop implemented by the access precedent according to the invention. Description of embodiment
  • variants of the invention comprising only a selection of described characteristics, subsequently isolated from the other described characteristics, if this selection of characteristics is sufficient to confer a technical advantage or to differentiate the invention from the state of the prior art.
  • This selection includes at least one characteristic, preferably functional, without structural details, or with only part of the structural details if this part only is sufficient to confer a technical advantage or to differentiate the invention from the state of the prior art. .
  • the object of the method according to the prior art is to allow an application 12, devoid of human-machine interaction, to access a secure resource 15, such as a database.
  • the application can receive authentication data to the secure resource 15 from a safe 10, stored on a remote device, for example a physical or virtual box.
  • the method for accessing the secure computer resource 15, according to the prior art, is broken down into three parts:
  • This execution controls the initialization step.
  • This step consists in asking the user to enter the authentication data necessary for access to the digital safe 10 in which the authentication data is stored at the secure resource 15 to which the application 12 must access.
  • the digital safe 10 includes several authentication data, for access to several secure resources.
  • Command 6 retrieves the authentication data or data and the figures by applying a cryptographic algorithm.
  • the command triggers the calculation of a transient cryptographic key using parameters corresponding to invariant data characterizing the environment for executing the command.
  • the transient cryptographic key is never saved to a ROM.
  • Invariant data can include:
  • FIG. 3 illustrates the process of access by the application 12 to the hosted resource 15.
  • the launching 7 of the command 6 by the application 12 in first access mode causes the execution of a recovery step 8 in the credential file 5 of the encrypted authentication data (recorded during the initialization process) allowing d '' access the safe 10.
  • the command 6 then launches a step of decrypting the authentication data implementing the aforementioned cryptographic algorithm, which uses a transient cryptographic key which is again calculated from the above invariant data.
  • the command then launches a step 9 of access to the digital safe 10 containing the authentication data 1 1 to the secure resource 15 to receive the authentication data 1 1.
  • the access step 9 can implement an API authentication programming interface, for the English application programming interface, to identify itself with the safe 10 and receive said authentication data 1 1. Furthermore, the command 6 performs the calculation of the fingerprint of the application 12 having launched the command 6. The calculated fingerprint is recorded in a local memory on the server 18 on which the application 12 is executed. The calculation of the impression can be made before or after step 9, but always before step 13 which is now described.
  • the command 6 then encrypts the authentication data 11 and the fingerprint calculated with the transient cryptographic key used for the decryption of the credential file, and records, during a step 13, the encrypted authentication data as well as the encrypted fingerprint in local memory.
  • the last step 14 for the command 6 consists in providing the calling application 12 with the authentication data 11, to allow access 16 to the remote resource 15.
  • the authentication data is supplied in clear to the application 12.
  • Subsequent accesses implement the same steps, with the exception of the step for determining the fingerprint calculation of the application 12 (and the step for recording the calculated footprint).
  • the fingerprint of the application 12 is already recorded in encrypted form in the local memory 13 during the first access to the secure resource, the recorded fingerprint is compared with a new calculation of the footprint of the calling application.
  • a transient cryptographic key is again calculated from of the above invariant data.
  • the encrypted fingerprint is decrypted by implementing the aforementioned cryptographic algorithm with the transient cryptographic key. If the two fingerprints differ, the processing is interrupted and sends an error message.
  • step 9 a new implementation of step 9 is provided to receive, from the safe 10, new authentication data 11, and on the other hand a new recording of the encryption, with the cryptographic key. transient used implementing the aforementioned cryptographic algorithm, new authentication data 1 1.
  • the authentication data 11 is determined by decryption implementing the aforementioned cryptographic algorithm, which uses the calculated transient cryptographic key.
  • step 14 consisting in supplying the authentication data 11 to the application 12, to allow access 16 to the secure resource 15.
  • the method according to the prior art allows an application to implement a method, implemented in the form of a command, for recovering authentication data in a safe for access to a secure resource.
  • the present invention aims to further secure the access of a computer application A, for example Ansible, to a secure resource D, by not providing the authentication data to the application.
  • a computer application A for example Ansible
  • the application implements a process, implemented in the form of command B, creating a connection to the shared resource.
  • the authentication data can be passwords or private keys.
  • the method comprises an initial step E1 of interposing a facade command B according to the invention between the computer application A and the client program F.
  • Another solution may include modifying the IT environment variable called PATFI.
  • the following steps to access the IT resource include:
  • step E3 comprising:
  • the front control B can notify the safe C, using its API, that the connection data does not are used more, ending the exclusivity of their uses, allowing, if necessary the rotation thereof.
  • a call tree of a facade process pB is described, associated with the facade control B according to the invention.
  • a process pA associated with the computer application A can comprise one or more child processes, for example a child process pN. These processes form a first level N1.
  • the child process pN comprises the call of a facade process pB associated with the facade command B. This process forms a second level N2.
  • the pB facade process involves the creation of a pF client program process associated with the F client program, as previously described. This process forms a third level N3.
  • Unix-like systems such as Linux, use a particular sequence to start a sub-process.
  • the parent process begins by duplicating itself with an operation initiated using a primitive called fork.
  • the child process inherits the code from the parent process.
  • the sub-process known as the child process, must make a call to a primitive to replace the code it inherited from the parent process with that of the desired command.
  • Several primitives can be called, such as the execl, execv, execle, execve, execlp, and execvp primitives.
  • the code for the pF customer order process corresponds to the code for the customer order F.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Health & Medical Sciences (AREA)
  • Storage Device Security (AREA)
  • Computer And Data Communications (AREA)
  • Communication Control (AREA)

Abstract

Procédé de connexion d'une application (A) à une ressource (D) par une commande (B), l'application étant prévue pour configurer la ressource par une connexion à la ressource au moyen d'un programme (F) et de paramètres de configurations, le programme implémentant une partie client d'un protocole de communication, le procédé comportant une exécution de la commande lors d'un appel du programme par ladite application, la commande étant interposée entre l'application et le programme; une réception de données d'authentifications pour l'accès à la ressource, par interrogation d'un coffre-fort (C), à partir de paramètres de configurations; un établissement d'une connexion entre la commande et la ressource par exécution du programme, dans lequel sont injectés en entrée les données d'authentification pour l'accès à la ressource, et les paramètres de configuration récupérés; un établissement d'une connexion directe entre l'application et la ressource.

Description

Procédé de connexion d’une application informatique à une ressource
informatique sécurisée
Domaine technique
La présente invention se rapporte au domaine du DevOps, qui est la concaténation des trois premières lettres du mot anglais development qui vise le développement logiciel, et de l’abréviation usuelle ops du mot anglais operations, qui vise l’administration des infrastructures informatiques, et notamment l’administration système.
État de la technique antérieure
Selon le modèle d’architecture réseau SDN, pour l’anglais software-defined networking, les administrateurs de réseaux peuvent gérer les services de réseaux par abstraction de fonctionnalités. Ce modèle d’architecture réseau comporte un ensemble de technologies ayant pour point commun un contrôle centralisé des ressources réseau, une orchestration centralisée et une virtualisation des ressources physiques.
Avec le développement du modèle d’architecture réseau SDN, les nouvelles structures informatiques sont de plus en plus gérées à l’aide de concepts provenant du domaine du DevOps. Le devops est un mouvement en ingénierie informatique et une pratique technique visant à l’unification du développement logiciel (dev) et de l’administration des infrastructures informatiques (ops), notamment l’administration système.
Au début, cela concernait principalement les nuages publics, pour l’anglais public cloud, comme AWS, pour Amazon Web Services, qui vise des services d’informatique en nuage, pour l’anglais cloud computing, à la demande pour les entreprises et particuliers, ou encore Azuré, qui est la plate-forme applicative développée par Microsoft. Cependant, ces concepts se répandent rapidement sur tous les types d’infrastructures.
L’un des principaux atouts de ces technologies est l’automatisation des tâches de gestion. Pour ce faire, des outils spécifiques ont été développés, tels que Ansible (plate-forme logicielle libre pour la configuration et la gestion des ordinateurs), Puppet (logiciel libre permettant la gestion de la configuration de serveurs esclaves) ou Chief (logiciel libre de gestion de configuration).
Ces outils permettent d’automatiser l’exécution de tâches sur un ensemble de ressources. Pour ce faire, ils s’appuient fortement sur des protocoles tels que SSH pour se connecter, déployer et exécuter des scripts sur les ressources. L’exécution de ces scripts nécessite un accès aux informations d’identification sans interaction humaine.
Ce besoin est déjà résolu en utilisant les concepts de plug-in (module d’extension informatique) configuré pour extraire d’un coffre-fort des informations d’identification. À cet effet, on pourra utilement se reporter à la demande internationale de la demanderesse, publiée sous le numéro WO 2018/162810, qui propose un procédé d’accès à une ressource informatique sécurisée par une application informatique.
La ressource informatique sécurisée est dépourvue d’interaction homme-machine pour la saisie d’une information d’authentification. Le procédé proposé comporte a) une première étape d’initialisation comprenant une création d’une clé cryptographique transitoire consistant à appliquer un traitement cryptographique à une pluralité d’informations invariantes dans le temps et à chiffrer avec la clé cryptographique transitoire ainsi calculée des données d’authentification d’un compte autorisé à accéder à un coffre-fort à mots de passe et b) des étapes d’accès automatique par l’application à la ressource informatique sécurisée consistant à créer une clé cryptographique transitoire consistant à appliquer un traitement cryptographique à la pluralité d’informations invariantes dans le temps, à lire le fichier crédentiel, pour l’anglais credential, créé lors de l’étape d’initialisation et à déchiffrer le fichier crédentiel avec la clé cryptographique transitoire calculée à l’étape précédente puis à transférer à l’application appelante les données provenant de la ressource informatique.
Il serait possible de mettre en œuvre le procédé d’accès selon l’art antérieur pour fournir le mot de passe aux outils spécifiques ont été développés, tels que Ansible. Cependant, la surface d’attaque entre l’extraction des informations d’identification et leur utilisation par l’outil d’accès sous-jacent (principalement le client SSH) offre toujours une grande opportunité pour un attaquant de voler les informations d’identification. Exposé de l’invention
Un but de l’invention est notamment de remédier à tout ou partie des inconvénients précités.
Selon un premier aspect de l’invention, il est proposé un procédé de connexion d’une application informatique à une ressource informatique sécurisée par une commande de façade.
L’application informatique est initialement configurée pour établir une connexion à la ressource sécurisée au moyen d’un programme client et de paramètres de configuration.
Le programme client implémente une partie client d’un protocole de communication et est configuré pour recevoir en entrée des données d’authentification.
Selon une particularité, l’application informatique est de type devops, c’est-à-dire une application informatique configurée pour la gestion à distance de ressources.
L’application informatique peut être configurée pour pouvoir configurer la ressource distance sans interaction homme-machine pour la saisie d’une information d’authentification. Selon une possibilité, l’application informatique est dépourvue d’interaction homme-machine pour la saisie d’une information d’authentification.
Par protocole de communication, la présente description vise par exemple le protocole SSH, pour Secure SHell.
Par programme client implémentant une partie client d’un protocole de communication, la présente description vise par exemple le programme client aussi connu sous le terme SSH.
Le procédé de connexion selon le premier aspect de l’invention peut comporter une étape initiale d’interposition d’une commande de façade entre l’application informatique et le programme client, telle que la commande SSHPASS (https ://sourceforge.net/p/sshpass), qui est utilisé uniquement pour permettre de passer le mot de passe sur la ligne de commande, ce que ne permet pas le client SSH nativement pour des raisons de sécurité.
Le procédé de connexion selon le premier aspect de l’invention comporte :
- une étape d’exécution de la commande de façade lors d’un appel du programme client par l’application informatique, la commande de façade étant interposée entre l’application informatique et le programme client, - une étape de récupération, par la commande de façade, desdits paramètres de configuration,
- une étape de réception de données d’authentifications pour l’accès à la ressource informatique, par la commande façade, par interrogation d’un coffre-fort, à partir des paramètres récupérés,
- une étape d’établissement d’une connexion entre la commande de façade et la ressource sécurisée par exécution du programme client, dans lequel sont injectés en entrée, d’une part les données d’authentification pour l’accès à la ressource informatique, et d’autre part des paramètres récupérés,
- une étape d’établissement d’une connexion directe entre l’application et la ressource informatique sécurisée.
Dans la présente description, un coffre-fort de mot de passe, aussi désigné par le terme vault e n anglais, vise un module logiciel qui conserve un certain nombre de mots de passe dans un emplacement numérique sécurisé. En cryptant le stockage de mot de passe, le coffre-fort de mot de passe offre aux utilisateurs la possibilité d'utiliser un seul mot de passe principal pour accéder à un certain nombre de mots de passe différents utilisés pour différents sites Web ou services.
L’étape d’établissement d’une connexion entre la commande de façade et la ressource informatique sécurisée peut comporter une modification des paramètres de configuration reçus et une injection des paramètres de configuration modifiés dans le programme client. Les paramètres de configuration récupérés peuvent être modifiés, par exemple dans le but de s’adapter au type de données de connexions extraites du coffre-fort. Par exemple, lorsque l’application informatique est Ansible, cette dernière suppose l’utilisation de clés SSH et les paramètres reçus comportent ainsi des paramètres de la commande SSH en vue d’une utilisation de clé SSH. Pourtant, il peut arriver que les données d’authentification soient de type mot de passe auquel cas il est nécessaire de modifier les paramètres avant leur injection dans la commande SSH. L’étape d’exécution de la commande de façade peut comporter, ultérieurement à la fin de la connexion directe entre l’application et la ressource informatique sécurisée, un envoi d’une notification de fin d’utilisation des données d’authentification par la commande de façade à destination du coffre-fort. Aussi, si les données d’authentification ont été extraites du coffre en en demandant l’exclusivité, la notification de la fin de l’utilisation desdites données d’authentification met fin à l’exclusivité de leurs utilisations, permettant, si nécessaire la rotation de celles-ci.
À cet effet, la commande de façade peut comporter une étape de modification par le coffre-fort des données d’authentification ultérieurement à la réception de la notification de fin d’utilisation.
En outre, le processus de façade peut comporter une étape de réception par le coffre- fort d’une requête d’exclusivité des données d’authentification antérieurement à l’étape de réception des données d’authentifications ou implicite lors de celle-ci.
L’étape d’interrogation du coffre-fort à partir des paramètres de configurations récupérés peut comporter l’envoi au coffre-fort de données d’authentifications pour l’accès au coffre-fort, les données d’authentifications pour l’accès au coffre-fort étant obtenues par déchiffrement par une clé cryptographique transitoire de données d’authentifications chiffrées pour l’accès au coffre-fort, les données d’authentifications chiffrées pour l’accès au coffre-fort étant enregistrées dans une mémoire permanente associée à la commande de façade.
Le procédé peut comporter une étape préalable d’enregistrement de données d’authentifications chiffrées pour l’accès au coffre-fort dans la mémoire permanente, les données d’authentifications chiffrées résultant du chiffrement de données d’authentification d’un compte autorisé à accéder au coffre-fort avec une clé cryptographique transitoire, la clé cryptographique transitoire étant déterminée par calcul à partir de l’application d’un traitement cryptographique à une pluralité d’informations invariantes dans le temps, et représentatives de l’environnement informatique d’exécution de ladite application.
Le procédé peut comporter, ultérieurement à l’étape de réception de données d’authentifications pour l’accès à la ressource informatique sécurisée, et antérieurement à l’étape étape d’établissement d’une connexion entre la commande de façade et la ressource informatique sécurisée, les étapes suivantes :
- calcul d’une empreinte du contexte d’appel du programme client en fonction de données invariantes représentatives de ce contexte,
- comparaison de l’empreinte calculée avec une empreinte enregistrée dans une mémoire permanente associée à la commande de façade, et a) en cas de différence, ne pas mettre en œuvre étape d’établissement de la connexion entre la commande de façade et la ressource informatique sécurisée,
b) en cas de conformité, mettre en œuvre étape d’établissement de la connexion entre la commande de façade et la ressource informatique sécurisée.
Le procédé peut comporter une étape préalable d’enregistrement d’une empreinte chiffrée dans la mémoire permanente, l’emprunte chiffrée résultant du chiffrement du chiffrement d’une empreinte du contexte d’appel du programme client en fonction de données invariantes représentatives de ce contexte, la clé cryptographique transitoire étant déterminée par calcul à partir de l’application d’un traitement cryptographique à une pluralité d’informations invariantes dans le temps, et représentatives de l’environnement informatique d’exécution de ladite application.
Bien entendu, les données d’authentification chiffrées ainsi que l’empreinte chiffrée peuvent être enregistrées dans un même fichier, aussi appelé fichier crédentiel.
Selon un mode de réalisationune empreinte de l’arbre d’appel du programme client est déterminée.
Selon une possibilité, la commande de façade est exécutée au sein d’un processus de façade et le programme client peut être exécuté au sein d’un processus de programme client, le processus de programme client étant un processus fils du processus de façade. Le processus client peut par exemple être créé par appel de la primitive fork() par le processus de façade (pB).
Lorsque les données invariantes comportent une empreinte de l’arbre d’appel du processus de programme client, la commande de façade peut comporter, préalablement à la détermination de l’empreinte de l’arbre d’appel, une étape d’attente qui s’achève lorsque le code du processus de programme client présente un code identique au code du programme client.
Selon une 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’obfuscation. Selon une première possibilité, la technique d’obfuscation est statique consiste à supprimer le registre frame pointer ou à remplacer des constantes du programme par des calculs récursifs.
Selon une autre possibilité, la technique d’obfuscation est dynamique consiste à bloquer l’accès en cas de détection d’une opération de débogage.
Selon un autre aspect de l’invention, il est proposé un produit programme d’ordinateur, téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, et chargeable dans une mémoire interne d’une unité de calcul, comportant des instructions de code de programme qui, lorsqu’elles sont exécutées par l’unité de calcul, mettent en œuvre les étapes d’un procédé de connexion selon le premier aspect de l’invention, ou l’un ou plusieurs de ses perfectionnements.
Description des figures
D’autres avantages et particularités de l’invention apparaîtront à la lecture de la description détaillée de mises en œuvre et de modes de réalisation nullement limitatifs, au regard de dessins annexés sur lesquels :
• La figure 1 représente une vue schématique fonctionnelle d’un procédé d’accès à une ressource informatique sécurisée par une application informatique,
• La figure 2 représente une vue schématique fonctionnelle d’un processus d’initialisation du procédé décrit à la figure 1 ,
• La figure 3 représente une vue schématique fonctionnelle d’une partie du procédé d’accès à la ressource informatique décrit à la figure 1 ,
• La figure 4 représente une vue schématique d’un enchaînement de traitements dans un procédé d’accès selon l’invention,
• La figure 5 représente une vue schématique d’un diagramme d’un arbre d’appel du procédé d’accès selon l’invention,
• La figure 6 représente est un pseudo-code d’une boucle d’attente mise en œuvre par le précédé d’accès selon l’invention. Description de mode de réalisation
Les modes de réalisation décrits ci-après n’étant nullement limitatifs, on pourra notamment considérer des variantes de l’invention ne comprenant qu’une sélection de caractéristiques décrites, par la suite isolées des autres caractéristiques décrites, si cette sélection de caractéristiques est suffisante pour conférer un avantage technique ou pour différencier l’invention par rapport à l’état de la technique antérieure. Cette sélection comprend au moins une caractéristique, de préférence fonctionnelle sans détails structurels, ou avec seulement une partie des détails structurels si cette partie uniquement est suffisante pour conférer un avantage technique ou pour différencier l’invention par rapport à l’état de la technique antérieure.
Sur les figures, un élément apparaissant sur plusieurs figures conserve la même référence.
Contexte de l’art antérieur
Comme illustré par la figure 1 , l’objet du procédé selon l’art antérieur est de permettre à une application 12, dépourvue d’interaction homme-machine, d’accéder à une ressource sécurisée 15, telle qu’une base de données.
À cet effet, il est proposé que l’application puisse recevoir d’un coffre-fort 10, enregistré sur un équipement distant, par exemple un boîtier physique ou virtuel, les données d’authentification à la ressource sécurisée 15.
Schéma de fonctionnement
Le procédé d’accès à la ressource informatique sécurisée 15, selon l’art antérieur, 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 3, comporte le calcul d’une clé cryptographique transitoire par l’exécution d’un code informatique par l’application 12, qui est hébergée sur un serveur 18, par exemple par un serveur d’application WebSphere (nom commercial). Un administrateur 4 de l’application 12 lance sur le serveur 18 une commande 6 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 au coffre-fort numérique 10 dans lequel sont enregistrées les données d’authentification à la ressource sécurisée 15 à laquelle l’application 12 doit accéder.
Plus généralement, le coffre-fort numérique 10 comporte plusieurs données d’authentifications, pour l’accès à plusieurs ressources sécurisées.
La commande 6 récupère la ou les données d’authentification et les chiffres en appliquant un algorithme cryptographique.
À cet effet, la commande déclenche le calcul d’une clé cryptographique transitoire utilisant des paramètres correspondant à des données invariantes caractérisant l’environnement d’exécution de la commande. La clé cryptographique transitoire n’est jamais enregistrée sur une mémoire morte. Les données invariantes peuvent comprendre :
- le nom et/ou l’identifiant de l’ordinateur sur lequel est exécutée la commande,
- le nom de la commande,
- un condensât du code exécutable de cette commande,
- l’identifiant du propriétaire de l’exécutable.
Les données d’authentification sont chiffrées avec la clé cryptographique transitoire ainsi calculée puis enregistrées, sous forme chiffrée, sur le serveur 18 dans un fichier crédentiel 5.
Premier accès à la ressource hébergée
La figure 3 illustre le processus d’accès par l’application 12 à la ressource hébergée 15.
Le lancement 7 de la commande 6 par l’application 12 en mode de premier accès provoque l’exécution d’une étape de récupération 8 dans le fichier crédentiel 5 des données d’authentification chiffrées (enregistrées lors du processus d’initialisation) permettant d’accéder au coffre-fort 10.
La commande 6 lance ensuite une étape de déchiffrement des données d’authentification mettant en œuvre l’algorithme cryptographique précité, lequel utilise une clé cryptographique transitoire qui est à nouveau calculée à partir des données invariantes précitées.
La commande lance ensuite une étape 9 d’accès au coffre numérique 10 contenant les données d’authentification 1 1 à la ressource sécurisée 15 pour recevoir les données d’authentification 1 1 .
L’étape 9 d’accès peut mettre en œuvre une interface de programmation d’authentification API, pour l’anglais application programming interface, pour s’identifier auprès du coffre-fort 10 et recevoir lesdites données d’authentification 1 1 . Par ailleurs, la commande 6 effectue le calcul de l’empreinte de l’application 12 ayant lancé la commande 6. L’empreinte calculée est enregistrée dans une mémoire locale sur le serveur 18 sur laquelle est exécutée l’application 12. Le calcul de l’empreinte peut être réalisé antérieurement ou ultérieurement à l’étape 9, mais toujours antérieurement à l’étape 13 qui est maintenant décrite.
La commande 6 chiffre ensuite les données d’authentification 1 1 et l’empreinte calculée avec la clé cryptographique transitoire utilisée pour le déchiffrement du fichier crédentiel, et enregistre, au cours d’une étape 13, les données d’authentification chiffrées ainsi que l’empreinte chiffrée dans la mémoire locale.
La dernière étape 14 pour la commande 6 consiste à fournir à l’application 12 appelante les données d’authentification 1 1 , pour permettre l’accès 16 à la ressource distante 15. Les données d’authentifications sont fournies en clair à l’application 12.
Accès ultérieur à la ressource sécurisée
Les accès ultérieurs mettent en œuvre les mêmes étapes, à l’exception de l’étape de détermination de calcul de l’empreinte de l’application 12 (et de l’étape d’enregistrement de l’empreinte calculée).
L’empreinte de l’application 12 étant déjà enregistrée sous forme chiffrée dans la mémoire locale 13 lors du premier accès à la ressource sécurisée, on compare l’empreinte enregistrée avec un nouveau calcul de l’empreinte de l’application appelante.
Aussi, il est nécessaire de déchiffrer l’empreinte chiffrée enregistrée dans la mémoire locale. À cet effet, une clé cryptographique transitoire est à nouveau calculée à partir des données invariantes précitées. L’empreinte chiffrée est déchiffrée par mise en œuvre de l’algorithme cryptographique précité avec la clé cryptographique transitoire. Si les deux empreintes diffèrent, le traitement est interrompu et envoie un message d’erreur.
Puis, optionnellement, il est prévu une nouvelle mise en œuvre de l’étape 9 pour recevoir, du coffre-fort 10, de nouvelles données d’authentification 1 1 , et d’autre part un nouvel enregistrement du chiffrement, avec la clé cryptographique transitoire utilisée mettant en œuvre l’algorithme cryptographique précité, des nouvelles données d’authentification 1 1 .
Alternativement à ladite option, les données d’authentification 1 1 sont déterminées par déchiffrement mettant en œuvre l’algorithme cryptographique précité, lequel utilise la clé cryptographique transitoire calculée.
Enfin, le processus se poursuit par l’étape 14 consistant à fournir les données d’authentification 1 1 , à l’application 12, pour permettre l’accès 16 à la ressource sécurisée 15.
Indisponibilité du coffre-fort
Dans le cas où l’accès au coffre-fort 10 n’est pas possible, les données d’authentification chiffrées enregistrées lors du premier accès, ou d’un accès subséquent, à la ressource sécurisée, sont utilisées, après déchiffrement par une étape de déchiffrement mettant en œuvre l’algorithme cryptographique précité, lequel utilise une clé cryptographique transitoire qui est à nouveau calculée à partir des données invariantes précitées.
Proposition de procédé d’accès à une ressource informatique
Ainsi qu’il a été vu, le procédé selon l’art antérieur permet à une application de mettre en œuvre un procédé, implémenté sous forme de commande, de récupération des données d’authentification dans un coffre-fort en vue d’un accès à une ressource sécurisée.
En référence à la figure 4, la présente invention a pour objectif de sécuriser encore l’accès d’une application informatique A, par exemple Ansible, à une ressource sécurisée D, en ne fournissant pas les données d’authentification à l’application. À cet effet, il est proposé que l’application mette en œuvre un procédé, implémenté sous forme de commande B, créant une connexion à la ressource partagée.
Dans le cas d’une automatisation complète de l’application informatique A, cette- dernière est dépourvue d’interaction homme-machine pour la saisie d’une information d’authentification.
En référence à la figure 1 , l’application A est initialement configurée pour établir une connexion à ladite ressource sécurisée D au moyen d’un programme client F (non représenté sur les figures) implémentant une partie client, par un exemple un client SSH, d’un protocole de communication, tel que le protocole SSH, ledit programme client utilisant des données d’authentification.
Bien entendu, les données d’authentifications peuvent être des mots de passe ou des clés privées.
Etape initiale d’interposition d’un processus de façade
Selon l’invention, le procédé comporte une étape initiale E1 d’interposition d’une commande de façade B selon l’invention entre l’application informatique A et le programme client F.
Par commande de façade, la présente description vise une commande exposant une interface similaire à celle du programme client F (ici SSFI) utilisée normalement par l’application informatique A afin de s’interposer naturellement entre l’application informatique A et le programme client F.
Plusieurs solutions techniques peuvent être envisagées à cet effet.
Il est par exemple possible, le cas échéant, d’éditer un fichier de configuration de l’application informatique A, pour indiquer un chemin d’appel de la commande de façade B en lieu et place d’un chemin d’appel du programme client F.
Une autre solution peut comporter de modifier la variable d’environnement informatique appelée PATFI.
Étapes suivantes d’accès à la ressource informatiques
Les étapes suivantes d’accès à la ressource informatiques comportent :
- une étape E1 d’appel d’exécution de la commande de façade B par l’application A, l’application A exécutant la commande de façade en croyant appeler le programme client F dont la façade est émulée par la commande de façade, - une étape E2 comportant :
- une étape de réception de paramètres passés par l’application A au programme client F,
- une étape de réception de données d’authentifications chiffrées, par la commande de façade, auprès d’un coffre-fort C,
- une étape E3 comportant :
• une étape d’établissement d’une connexion directe entre l’application A et la ressource sécurisée D au moyen du programme client F par injection dans le programme client F des données d’authentification reçues ainsi que des paramètres récupérés et modifiés si nécessaire, par exemple pour s’adapter au type de données de connexions extraites du coffre-fort C,
• à la fin de la connexion, si les données de connexion ont été extraites du coffre en en demandant l’exclusivité, la commande de façade B peut notifier le coffre-fort C, au moyen de son API, que les données de connexion ne sont plus utilisées, mettant fin à l’exclusivité de leurs utilisations, permettant, si nécessaire la rotation de celle-ci.
En référence à la figure 5, il est décrit un arbre d’appel d’un processus de façade pB, associé à la commande de façade B selon l’invention.
Un processus pA associé à l’application informatique A peut comporter un ou plusieurs processus enfant, par exemple un processus enfant pN. Ces processus forment un premier niveau N1 .
Le processus enfant pN comporte l’appel d’un processus de façade pB associé à la commande de façade B. Ce processus forme un deuxième niveau N2.
Le processus de façade pB comporte la création d’un processus de programme client pF associé au programme client F, tel que précédemment décrit. Ce processus forme un troisième niveau N3.
Parmi les données invariantes caractérisant l’environnement d’exécution de la commande, il est proposé d’intégrer une empreinte de l’arbre d’appel du programme client. Attente de la terminaison du démarrage du processus de programme client
Les systèmes de type Unix, comme Linux, utilisent une séquence particulière pour démarrer un sous-processus.
Le processus parent commence par se dupliquer par une opération initiée à l’aide d’une primitive appelée fork.
Lors de la création d’un processus-fils par la primitive fork, le processus-fils hérite du code du processus père.
Aussi, le sous-processus, dit processus fils, doit effectuer un appel à une primitive pour remplacer le code qu’il a hérité du processus père par celui de la commande désirée. Plusieurs primitives peuvent être appelées, telles que les primitives execl, execv, execle, execve, execlp, et execvp.
Tant que la fonction de remplacement de code n’est pas terminée, le sous-processus enfant est vu comme exécutant le code du processus parent.
Aussi, l’utilisation d’une emprunte de l’application appelante qui comporterait des données invariantes comportant l’arbre d’appel, préalablement à un déchiffrement des données d’authentification chiffrées mettant en œuvre l’arbre d’appel, ne pourrait pas se faire car ce n’est pas le bon code qui serait pris en compte.
Aussi, il est proposé, comme représenté par le pseudo-code de la figure 6, de ne déterminer l’empreinte de l’application appelante, qui contient des données invariantes telles que l’arbre d’appel, qu’après avoir attendu la terminaison du processus de démarrage de la commande appelée à l’étape E4 d’établissement d’une connexion entre le processus de façade et la ressource sécurisée au moyen du programme client F.
Plus précisément, l’attente de la terminaison du processus de démarrage de la commande il est attendu que le code du processus de commande client pF corresponde au code de la commande client F.
Bien sûr, l’invention n’est pas limitée aux exemples qui viennent d’être décrits et de nombreux aménagements peuvent être apportés à ces exemples sans sortir du cadre de l’invention. De plus, les différentes caractéristiques, formes, variantes et modes de réalisation de l’invention peuvent être associés les uns avec les autres selon diverses combinaisons dans la mesure où ils ne sont pas incompatibles ou exclusifs les uns des autres.

Claims

Revendications
1 ) Procédé de connexion d’une application informatique (A) à une ressource informatique sécurisée (D) par une commande de façade (B), ladite application informatique étant configurée pour configurer la ressource informatique sécurisée sans interaction homme-machine, ladite application informatique étant initialement configurée pour établir une connexion à ladite ressource sécurisée au moyen d’un programme client (F) et de paramètres de configurations, ledit programme client implémentant une partie client d’un protocole de communication et étant configuré pour recevoir en entrée des données d’authentification, ledit procédé comportant les étapes suivantes :
- une étape (E1 ) d’exécution de la commande de façade lors d’un appel dudit programme client par ladite application informatique, ladite commande de façade étant interposée entre l’application informatique et le programme client,
- une étape de récupération, par ladite commande de façade, desdits paramètres de configuration,
- une étape (E3) de réception, par la commande de façade, de données d’authentifications pour l’accès à la ressource informatique, par interrogation (E2) d’un coffre-fort (C), à partir des paramètres de configurations récupérés,
- une étape (E4) d’établissement d’une connexion entre la commande de façade et la ressource sécurisée par exécution dudit programme client, dans lequel sont injectés en entrée d’une part les données d’authentification pour l’accès à la ressource informatique, et d’autre part les paramètres de configuration récupérés,
- une étape (E5, E6) d’établissement d’une connexion directe entre ladite application informatique et ladite ressource informatique sécurisée.
2) Procédé d’accès selon la revendication précédente, comportant une étape initiale d’interposition d’une commande de façade (B) entre l’application informatique (A) et le programme client (F). 3) Procédé de connexion selon l’une quelconque des revendications précédentes, dans lequel les paramètres de configuration reçus sont modifiées puis injectées dans ledit programme client (F).
4) Procédé de connexion selon l’une quelconque des revendications précédentes, comportant en outre une étape ultérieure à la terminaison de la connexion directe entre l’application informatique (A) et la ressource informatique sécurisée (D) dans laquelle une notification d’utilisation des données d’authentification est envoyée par la commande de façade (B) à destination du coffre-fort (C).
5) Procédé de connexion selon la revendication précédente, comportant en outre une étape de modification par le coffre-fort (C) des données d’authentification ultérieurement à la réception de la notification d’utilisation.
6) Procédé de connexion selon la revendication précédente, comportant en outre une étape (E2) de réception par le coffre-fort (C) d’une requête d’exclusivité des données d’authentification antérieurement à l’étape (E3) de récupération des données d’authentifications chiffrées.
7) Procédé de connexion selon l’une quelconque des revendications précédentes, dans lequel l’étape d’interrogation (E2) du coffre-fort (C) à partir des paramètres de configurations récupérés comporte l’envoi au coffre-fort de données d’authentifications pour l’accès au coffre-fort, les données d’authentifications pour l’accès au coffre-fort étant obtenues par déchiffrement par une clé cryptographique transitoire de données d’authentifications chiffrées pour l’accès au coffre-fort, les données d’authentifications chiffrées pour l’accès au coffre-fort étant enregistrées dans une mémoire permanente associée à la commande de façade (B).
8) Procédé de connexion selon la revendication précédente, comprenant une étape préalable d’enregistrement de données d’authentifications chiffrées pour l’accès au coffre-fort (C) dans la mémoire permanente, lesdites données d’authentifications chiffrées résultant du chiffrement de données d’authentification d’un compte autorisé à accéder au coffre-fort avec une clé cryptographique transitoire, la clé cryptographique transitoire étant déterminée par calcul à partir de l’application d’un traitement cryptographique à une pluralité d’informations invariantes dans le temps, et représentatives de l’environnement informatique d’exécution de ladite application.
9) Procédé de connexion selon l’une quelconque des revendications précédentes comportant en outre, ultérieurement à l’étape (E3) de réception de données d’authentifications pour l’accès à la ressource informatique sécurisée (D), et antérieurement à l’étape étape (E4) d’établissement d’une connexion entre la commande de façade (B) et la ressource informatique sécurisée, les étapes suivantes :
- calcul d’une empreinte du contexte d’appel du programme client (F) en fonction de données invariantes représentatives de ce contexte,
- comparaison de l’empreinte calculée avec une empreinte enregistrée dans une mémoire permanente associée à la commande de façade, et
i) en cas de différence, ne pas mettre en œuvre étape (E4) d’établissement de la connexion entre la commande de façade et la ressource informatique sécurisée,
ii) en cas de conformité, mettre en œuvre étape (E4) d’établissement de la connexion entre la commande de façade et la ressource informatique sécurisée.
10) Procédé de connexion selon la revendication précédente, comportant une étape préalable d’enregistrement d’une empreinte chiffrée dans la mémoire permanente, ladite empreinte chiffrée résultant du chiffrement du chiffrement d’une empreinte du contexte d’appel du programme client (F) en fonction de données invariantes représentatives de ce contexte, la clé cryptographique transitoire étant déterminée par calcul à partir de l’application d’un traitement cryptographique à une pluralité d’informations invariantes dans le temps, et représentatives de l’environnement informatique d’exécution de ladite application.
11 )Procédé de connexion selon l’une quelconque des revendications 7 à 10, dans lequel une empreinte de l’arbre d’appel du programme client est déterminée. )Procédé de connexion selon la revendication précédente, dans lequel la commande de façade (B) est exécutée au sein d’un processus de façade (pB) et le programme client est exécuté au sein d’un processus de programme client (pF), le processus de programme client étant un processus fils du processus de façade (pB), la commande de façade comportant en outre, préalablement à l’étape de détermination de l’empreinte de l’arbre d’appel, une étape d’attente qui s’achève lorsque le code du processus de programme client présente un code identique au code du programme client. )Produit programme d’ordinateur, téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, et chargeable dans une mémoire interne d’une unité de calcul, caractérisé en ce qu’il comporte des instructions de code de programme qui, lorsqu’elles sont exécutées par l’unité de calcul, mettent en œuvre les étapes d’un procédé de connexion selon l’une quelconque des revendications précédentes.
PCT/FR2019/053299 2019-01-04 2019-12-26 Procédé de connexion d'une application informatique à une ressource informatique sécurisée Ceased WO2020141277A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CA3121595A CA3121595A1 (fr) 2019-01-04 2019-12-26 Procede de connexion d'une application informatique a une ressource informatique securisee
US17/418,717 US12047364B2 (en) 2019-01-04 2019-12-26 Method for connecting a computer application to a secure computer resource
EP19848991.6A EP3906635A1 (fr) 2019-01-04 2019-12-26 Procédé de connexion d'une application informatique à une ressource informatique sécurisée

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1900092A FR3091601B1 (fr) 2019-01-04 2019-01-04 Procédé de connexion d’une application informatique à une ressource informatique sécurisée
FR1900092 2019-01-04

Publications (1)

Publication Number Publication Date
WO2020141277A1 true WO2020141277A1 (fr) 2020-07-09

Family

ID=67107629

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2019/053299 Ceased WO2020141277A1 (fr) 2019-01-04 2019-12-26 Procédé de connexion d'une application informatique à une ressource informatique sécurisée

Country Status (5)

Country Link
US (1) US12047364B2 (fr)
EP (1) EP3906635A1 (fr)
CA (1) CA3121595A1 (fr)
FR (1) FR3091601B1 (fr)
WO (1) WO2020141277A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11729163B2 (en) * 2021-03-19 2023-08-15 The Toronto-Dominion Bank System and method for establishing secure communication between applications
US20250080537A1 (en) * 2023-09-04 2025-03-06 Zscaler, Inc. Systems and methods for pause and resume functionality for shared Privileged Remote Access (PRA) sessions

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160315970A1 (en) * 2011-09-29 2016-10-27 Oracle International Corporation Privileged account manager, dynamic policy engine
WO2018162810A1 (fr) 2017-03-10 2018-09-13 Wallix Procede d'acces a une ressource informatique securisee par une application informatique

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10636084B2 (en) * 1996-10-31 2020-04-28 Citicorp Credit Services, Inc. (Usa) Methods and systems for implementing on-line financial institution services via a single platform
US6499036B1 (en) * 1998-08-12 2002-12-24 Bank Of America Corporation Method and apparatus for data item movement between disparate sources and hierarchical, object-oriented representation
US7000235B2 (en) * 2001-10-30 2006-02-14 Sun Microsystems, Inc. Method and apparatus for managing data services in a distributed computer system
US7043738B2 (en) * 2002-03-05 2006-05-09 Sun Microsystems, Inc. Method and apparatus for managing a data imaging system using CIM providers in a distributed computer system
US7167862B2 (en) * 2003-03-10 2007-01-23 Ward Mullins Session bean implementation of a system, method and software for creating or maintaining distributed transparent persistence of complex data objects and their data relationships
US10049335B1 (en) * 2009-10-06 2018-08-14 EMC IP Holding Company LLC Infrastructure correlation engine and related methods
US8806481B2 (en) * 2010-08-31 2014-08-12 Hewlett-Packard Development Company, L.P. Providing temporary exclusive hardware access to virtual machine while performing user authentication
US20140129457A1 (en) * 2012-11-02 2014-05-08 Stroz Friedberg, LLC An interactive organizational decision-making and compliance facilitation portal
US11551195B2 (en) * 2017-07-18 2023-01-10 Tata Consultancy Services Limited Systems and methods for providing services to smart devices connected in an IoT platform
US10812581B2 (en) * 2018-10-12 2020-10-20 Bank Of America Corporation Heterogeneous distributed ledger data curator

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160315970A1 (en) * 2011-09-29 2016-10-27 Oracle International Corporation Privileged account manager, dynamic policy engine
WO2018162810A1 (fr) 2017-03-10 2018-09-13 Wallix Procede d'acces a une ressource informatique securisee par une application informatique

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
ANONYMOUS: "Checking out a credential or credential pool", 25 October 2012 (2012-10-25), XP055635839, Retrieved from the Internet <URL:https://www.ibm.com/support/knowledgecenter/SSRMWJ_7.0.1.8/com.ibm.isim.doc/scenarios/tsk/tsk_ic_scenar_user_sharedaccount_checkout.htm> [retrieved on 20191024] *
ANONYMOUS: "Rotate Privileged Credentials Using BeyondTrust Vault for Privileged Remote Access", 18 December 2018 (2018-12-18), XP055635833, Retrieved from the Internet <URL:https://www.beyondtrust.com/docs/privileged-remote-access/how-to/vault/rotation.htm> [retrieved on 20191024] *
ANONYMOUS: "sshpass(1) - Linux man page", 21 December 2018 (2018-12-21), XP055635803, Retrieved from the Internet <URL:https://web.archive.org/web/20181221052026/https://linux.die.net/man/1/sshpass> [retrieved on 20191024] *

Also Published As

Publication number Publication date
CA3121595A1 (fr) 2020-07-09
EP3906635A1 (fr) 2021-11-10
US20220078176A1 (en) 2022-03-10
FR3091601A1 (fr) 2020-07-10
US12047364B2 (en) 2024-07-23
FR3091601B1 (fr) 2023-12-15

Similar Documents

Publication Publication Date Title
JP7554380B2 (ja) 異なるネットワークにわたって資産を転送するためのセキュアかつ信頼できるブリッジ
JP7516691B1 (ja) 異なるデータアーキテクチャを有するネットワークにわたって資産を転送するためのセキュアかつ信頼できるブリッジ
EP3055965B1 (fr) Procede et dispositif d&#39;authentification et d&#39;execution securisee de programmes
US20070254631A1 (en) Secure Multi-Entity Access to Resources on Mobile Telephones
EP2614458B1 (fr) Procede d&#39;authentification pour l&#39;acces a un site web
EP3732818A1 (fr) Procédé et système d&#39;activation cryptographique d&#39;une pluralité d&#39;équipements
CN113609514A (zh) 一种云硬盘加解密方法、装置、系统及可读存储介质
US20190297112A1 (en) Securely Establishing Key-Based SSH Communications Between Virtual Machines During Cloud Marketplace Provisioning
WO2021035295A1 (fr) Environnement sécurisé pour la génération de clé cryptographique
EP3906635A1 (fr) Procédé de connexion d&#39;une application informatique à une ressource informatique sécurisée
CN114640445A (zh) Hsm密钥管理系统及方法、设备及存储介质
FR2974207A1 (fr) Procede et systeme de securisation d&#39;un logiciel
US20240281798A1 (en) Multi-party computation self-custody wallet
EP3593270B1 (fr) Procédé d&#39;accès a une ressource informatique sécurisée par une application informatique
US20250047477A1 (en) Using device-specific key for derivation
US20250106019A1 (en) System and method for privately hosting machine learning models and collaborative computations
US20240281795A1 (en) Multi-party computation self-custody wallet
WO2014064096A1 (fr) Procédé de téléchargement d&#39;au moins un composant logiciel dans un appareil informatique, produit programme d&#39;ordinateur, appareil informatique et système informatique associés
US20250379724A1 (en) Password hardening for elliptic curve integrated encryption schemes
US20250378181A1 (en) Techniques for storing key backups
EP3948596B1 (fr) Procédé d&#39;exécution de code sécurisé, dispositifs, système et programmes correspondants
FR3124285A1 (fr) procédé d’authentification, dispositif et programme correspondant.
EP3825882A1 (fr) Procede et systeme pour le provisionnement ou remplacement securise d&#39;un secret dans au moins un dispositif de communication portable
WO2020128215A1 (fr) Réinitialisation d&#39;un secret applicatif au moyen du terminal
CH716292A2 (fr) Procédé de signature décentralisée, sous contrôle biométrique et sous condition de géolocalisation, d&#39;une transaction destinée à une blockchain.

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19848991

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 3121595

Country of ref document: CA

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2019848991

Country of ref document: EP

Effective date: 20210804