FR3042362A1 - Moyens de gestion d'acces a des donnees - Google Patents
Moyens de gestion d'acces a des donnees Download PDFInfo
- Publication number
- FR3042362A1 FR3042362A1 FR1559605A FR1559605A FR3042362A1 FR 3042362 A1 FR3042362 A1 FR 3042362A1 FR 1559605 A FR1559605 A FR 1559605A FR 1559605 A FR1559605 A FR 1559605A FR 3042362 A1 FR3042362 A1 FR 3042362A1
- Authority
- FR
- France
- Prior art keywords
- module
- communication network
- data
- access
- communication
- 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.)
- Granted
Links
Classifications
-
- 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/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/2854—Wide area networks, e.g. public data networks
- H04L12/2856—Access arrangements, e.g. Internet access
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer And Data Communications (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
La présente invention se rapporte à des moyens pour transmettre, un ensemble de données accessible par un module de gestion sur un premier réseau, à un module d'accès couplé à un deuxième réseau. Le premier et deuxième réseau est couplé par un troisième réseau. Un module de communication est couplé au troisième réseau de communication et configuré pour permettre l'établissement d'un canal de communication bidirectionnel entre le module de gestion et le module d'accès. Une première requête, transmise par le module de communication et générée par le module d'accès, est reçue par le module de gestion. La première requête comporte des informations permettant au module de gestion de déterminer que le module d'accès demande un accès à l'ensemble de données. Le premier ensemble de données est enregistré dans un emplacement sur le troisième réseau décrit par une première adresse. Le module de gestion transmet une première réponse au module de communication à destination du module d'accès ; la première réponse comportant la première adresse.
Description
Moyens de gestion d'accès à des données
Introduction
La présente invention se rapporte à des moyens de gestion de données, aptes à être employés par des utilisateurs, notamment en situation de mobilité. Plus particulièrement, l'invention a trait à un procédé et un système aptes à permettre une sauvegarde automatisée de données à partir d'une pluralité de dispositifs, une duplication de données sauvegardées sur divers dispositifs couplés à un ou plusieurs réseaux, un partage sécurisé de données sécurisé avec une pluralité d'utilisateur, et un accès distant aux données de chaque utilisateur, y compris lorsque ledit utilisateur est en situation de mobilité.
Art antérieur
Il existe aujourd'hui divers systèmes de gestions de données permettant à un groupe d'utilisateur de gérer des données, à des fins de sauvegarde, de partage, de duplication ou encore d'accès distant. Ainsi, il est connu de déployer des moyens de stockage centralisés, accessibles par l'intermédiaire d'un réseau local, à un groupe d'utilisateur. Pour accéder, gérer et/ou sauvegarder des données, chaque utilisateur peut utiliser une application dédiée, exécutée sur un dispositif tel un ordinateur ou un téléphone, lui-même connecté au réseau local. Or, il est également souhaitable de proposer des fonctionnalités similaires aux utilisateurs lorsque ces derniers sont en situation de mobilité. Un dispositif mobile exécutant une application dédiée peut être employé à cette fin, le dispositif mobile n'étant pas connecté directement au réseau local, mais à Internet. Il est alors nécessaire que le dispositif mobile puisse échanger des requêtes et des données, avec le système de gestions de données, par l'intermédiaire d'Internet, en voix montante - c'est-à-dire depuis le dispositif mobile jusqu'au système de gestions de données -, et en voix descendante - c'est-à-dire depuis le système de gestions de données vers le dispositif mobile.
Pour permettre au système de gestion de données d'être accessible depuis Internet par le dispositif mobile, il est connu d'employer, dans le réseau local, un équipement de terminaison de réseau couplé à Internet. L'équipement de terminaison de réseau possède généralement une adresse publique - par exemple une adresse désignée par l'acronyme anglo-saxon "IP" pour "Internet Protocol", représentant un point d’entrée accessible par internet, vers le réseau local. L'équipement de terminaison de réseau est généralement couplé à un dispositif pare-feu gérant les connexions entrantes et sortantes vers les terminaux connectés au réseau local. Typiquement, le dispositif pare-feu est configuré pour autoriser les connexions sortantes utilisant le protocole de transfert hypertexte - plus généralement désigné par l'acronyme anglo-saxon "HTTP" pour "HyperText Transfer Protocol" - ou les connexions sortantes utilisant le protocole de transfert hypertexte sécurisé, plus généralement désigné par l'acronyme anglo-saxon "HTTPS" pour "HyperText Transfer Protocol Secure". C'est pourquoi, le système de gestion de données peut transmettre des requêtes et des données vers le dispositif mobile connecté à Internet, en utilisant des moyens usuels, par exemple en utilisant le protocole HTTP ou HTTPS. En revanche, le dispositif pare-feu est généralement configuré pour bloquer les connexions entrantes utilisant le protocole HTTP ou HTTPS vers les terminaux connectés au réseau local. La transmission de requêtes et de données depuis le dispositif mobile connecté à Internet vers le système de gestions de données, requiert donc la mise en place de solutions spécifiques.
Une première solution consiste à modifier manuellement les règles mises en œuvre par le dispositif pare-feu de sorte à autoriser les connexions entrantes vers le système de gestion de données depuis le dispositif mobile. Toutefois cette solution s'avère peu pratique et difficile à mettre en œuvre car elle requiert de la part de l'utilisateur une étape supplémentaire de configuration de l'équipement de terminaison de réseau, ce qui peut s'avérer difficile pour un utilisateur peu expérimenté, complexe et fastidieux si de nombreux terminaux doivent être autorisés.
Une deuxième solution consiste à utiliser un protocole de configuration automatique, compatible avec l'équipement de terminaison de réseau. Parmi les protocoles de configuration automatique, on peut notamment citer le protocole UPnP IGD (acronyme anglo-saxon pour "Universal Plug and Play Internet Gateway Device"), le protocole PCP (acronyme anglo-saxon pour "Port Control Protocol") ou encore le protocole NAT Port Mapping Protocol (acronyme anglo-saxon pour "Network Address Translation Port Mapping Protocol"). Or, l'équipement de terminaison de réseau n'est pas nécessairement compatible avec les protocoles de configuration automatique cités, ou n'être disponible qu'après une phase de configuration et d'activation. Aussi, pour faire face à la situation où l'équipement de terminaison de réseau ne gère que certains protocoles de configuration automatique, il est nécessaire de tester l'un après l'autre les protocoles pour définir ceux compatibles avec l'équipement de terminaison de réseau auquel le système de gestion de données est connecté. Par exemple, le système de gestion de données doit tester le support du protocole UPnP IGD, puis, si ce dernier n'est pas supporté, le protocole PCP, etc. jusqu'à trouver un protocole supporté. Cette solution s'avère donc complexe car elle nécessite la mise en œuvre de divers protocoles de configuration automatique par le système de gestion de données. En outre, pour être accessible par Internet, chaque système de gestion de données doit disposer travers une adresse URL (acronyme anglo-saxon pour "Uniform Resource Locator") qui lui est propre. Cette adresse URL doit donc être configurée pour pointer sur l’adresse IP publique de l'équipement de terminaison de réseau, ce qui pose divers problèmes de sécurité en exposant le réseau local à différents types d’attaques comme des attaques de dénis de service, ou de dévoiement (plus généralement désigné par le terme anglo-saxon "pharming"), etc. De plus, l'utilisation d'un protocole de configuration automatique peut engendrer des conflits avec d'autres terminaux couplés au réseau local susceptible d'utiliser les mêmes options de configuration que le système de gestion de données. C'est pourquoi il existe encore un besoin pour un système de gestion de données, couplé à un réseau local pourvu d'un équipement de terminaison de réseau lui-même couplé à un réseau externe, le système de gestion de données étant accessible par un terminal connecté indifféremment soit au réseau local soit au réseau externe, sans nécessiter une étape de configuration préalable par un utilisateur de l'équipement de terminaison de réseau.
Un des objets de l’invention est de fournir des moyens efficaces de gestion de données, couplés à un réseau local pourvu d'un équipement de terminaison de réseau lui-même couplé à un réseau externe, le système de gestion de données étant accessible par un terminal connecté indifféremment soit au réseau local soit au réseau externe, sans nécessiter une étape de configuration préalable par un utilisateur de l'équipement de terminaison de réseau. Un autre objet de l’invention est de fournir des moyens efficaces de gestion de données, garantissant un niveau de sécurité élevé, notamment en garantissant l'accès aux données aux seuls utilisateurs autorisés. Un autre objet de l'invention est de permettre l'utilisation de moyens fiables, peu coûteux et largement répandus, sans nécessiter l'utilisation de protocoles peu répandus ou d'infrastructures techniques spécifiques ou dédiées. Un autre objet de l'invention est de permettre l'accès aux données par un utilisateur, lorsque ce dernier est en situation de mobilité.
Un ou plusieurs de ces objets sont remplis par le procédé et le système selon les revendications indépendantes. Les revendications dépendantes fournissent en outre des solutions à ces objets et/ou d’autres avantages.
Plus particulièrement, selon un premier aspect, l’invention se rapporte à un procédé pour transmettre, un premier ensemble de données accessible par un module de gestion sur un premier réseau de communication, à un module d'accès couplé à un deuxième réseau de communication. Le premier réseau de communication et le deuxième réseau de communication sont couplés par l'intermédiaire d'un troisième réseau de communication. Un module de communication est couplé au troisième réseau de communication et configuré pour permettre l'établissement d'un canal de communication bidirectionnel entre le module de gestion et le module d'accès. Le procédé comporte : • une première étape au cours de laquelle une première requête, transmise par le module de communication et générée par le module d'accès, est reçue par le module de gestion, la première requête comportant des informations permettant au module de gestion de déterminer que le module d'accès demande un accès au premier ensemble de données ; • une deuxième étape au cours de laquelle le premier ensemble de données est enregistré dans un emplacement sur le troisième réseau décrit par une première adresse ; • une troisième étape au cours de laquelle le module de gestion transmet une première réponse au module de communication à destination du module d'accès ; la première réponse comportant la première adresse.
Avantageusement, au cours de la deuxième étape, le module de gestion peut transmettre le premier ensemble de données à un module de stockage couplé au troisième réseau de communication. L'emplacement sur le troisième réseau décrit par la première adresse peut alors être déterminé par le module de stockage, le premier ensemble de données étant alors stocké par le module de stockage à l'emplacement sur le troisième réseau décrit par la première adresse, la première adresse étant alors transmise par le module de stockage au module de gestion.
Dans un mode de réalisation, au cours de la deuxième étape, le module de gestion transmet, le premier ensemble de données au module de stockage, sous une forme cryptée apte à garantir un accès aux données du premier ensemble aux seules entités ayant connaissance d'au moins un premier élément de sécurité, le premier ensemble de données dans sa forme cryptée étant alors stocké par le module de stockage à l'emplacement sur le troisième réseau décrit par la première adresse. L'élément de sécurité est par exemple un mot de passe, un certificat ou tout élément cryptographique adapté pour permettre de crypter le premier ensemble de données.
Le module de gestion peut transmettre le premier ensemble de données au module de stockage, par l'intermédiaire d'un canal de communication sécurisé, par exemple en utilisant le protocole de transfert hypertexte sécurisé HTTPS.
Avantageusement, le module de stockage peut effacer le premier ensemble de données à l'emplacement sur le troisième réseau décrit par la première adresse, une fois écoulé un laps de temps prédéterminé après le stockage du premier ensemble de données à l'emplacement décrit par la première adresse.
Dans un mode de réalisation, la troisième étape est mise en oeuvre seulement si un utilisateur à l'origine de la transmission de la première requête a été préalablement authentifié et/ou dispose de droits nécessaires et suffisants pour accéder au premier ensemble de données. Un procédé d'authentification utilisant des jetons d'authentification, plus généralement désignés par le terme anglo-saxon "token", peut être employé à cet fin. L’invention se rapporte à un module de gestion, et optionnellement un module de stockage, adapté(s) à mettre en oeuvre le procédé selon le premier aspect.
Selon un deuxième aspect, l’invention se rapporte à un procédé pour recevoir, sur un module d'accès couplé à un deuxième réseau de communication, un premier ensemble de données accessible par un module de gestion sur un premier réseau de communication. Le premier réseau de communication et le deuxième réseau de communication sont couplés par l'intermédiaire d'un troisième réseau de communication. Un module de communication est couplé au troisième réseau de communication et configuré pour permettre l'établissement d'un canal de communication bidirectionnel entre le module de gestion et le module d'accès. Le procédé comporte : • une première étape au cours de laquelle le module d’accès transmet, au module de communication, une première requête, à destination du module de gestion, comportant des informations indiquant que le module d'accès demande un accès au premier ensemble de données ; • une deuxième étape au cours de laquelle le module d'accès reçoit une première réponse, transmise par le module de communication et générée par le module de gestion en réponse à la première requête, la première réponse comportant une première adresse désignant un emplacement sur le troisième réseau de communication où le premier ensemble de données est stocké ; le premier ensemble de données étant alors obtenu par le module d'accès au moyen de la première adresse.
Au cours de la deuxième étape, le module d'accès peut obtenir le premier ensemble de données en transmettant une requête de téléchargement du premier ensemble de données à un module de stockage couplé au troisième réseau de communication, la requête de téléchargement comportant comportant la première adresse, l'emplacement sur le troisième réseau décrit par la première adresse étant alors utilisé par le module de stockage pour accéder au premier ensemble de données, le premier ensemble de données étant ensuite transmis par le module de stockage au module d'accès. L’invention se rapporte également à un module d'accès et optionnellement un module de stockage, adapté(s) à mettre en oeuvre le procédé selon le deuxième aspect.
Selon un troisième aspect, l’invention se rapporte à un procédé d'interconnexion, par un module de communication couplé à un troisième réseau de communication, apte à permettre la réception, sur un module d'accès couplé à un deuxième réseau de communication, d'un premier ensemble de données accessible par un module de gestion sur un premier réseau de communication. Le premier réseau de communication et le deuxième réseau de communication sont couplés par l'intermédiaire du troisième réseau de communication. Le module de communication est configuré pour permettre l'établissement d'un canal de communication bidirectionnel entre le module de gestion et le module d'accès. Le procédé comporte : • une première étape de transmission, au module de gestion, d'une première requête, émise par le module d'accès et comportant des informations indiquant que le module d'accès demande un accès au premier ensemble de données ; • une deuxième étape de transmission, au module d'accès, d'une première réponse, émise par le module de gestion en réponse à la première requête, la première réponse comportant une première adresse désignant un emplacement sur le troisième réseau de communication où le premier ensemble de données est stocké. L’invention se rapporte également à un module de communication adapté à mettre en oeuvre le procédé selon le troisième aspect.
Selon un quatrième aspect, l’invention se rapporte à un procédé pour recevoir un deuxième ensemble de données accessible par un module d'accès sur un deuxième réseau de communication, sur un module de gestion couplé à un premier réseau de communication, le premier réseau de communication et le deuxième réseau de communication étant couplés par l'intermédiaire d'un troisième réseau de communication. Un module de communication est couplé au troisième réseau de communication et configuré pour permettre l'établissement d'un canal de communication bidirectionnel entre le module de gestion et le module d'accès. Le procédé comporte : • une première étape au cours de laquelle le module de gestion reçoit une deuxième requête, transmise par le module de communication et générée par le module d'accès, la deuxième requête comportant une deuxième adresse désignant un emplacement sur le troisième réseau de communication où le deuxième ensemble de données est stocké ; le deuxième ensemble de données étant alors obtenu par le module de gestion au moyen de la deuxième adresse.
Avantageusement, au cours de la première étape, le module de gestion peut obtenir le deuxième ensemble de données en transmettant une requête de téléchargement du deuxième ensemble de données à un module de stockage couplé au troisième réseau de communication, la requête de téléchargement comportant comportant la deuxième adresse, l'emplacement sur le troisième réseau décrit par la deuxième adresse étant alors utilisé par le module de stockage pour accéder au deuxième ensemble de données, le deuxième ensemble de données étant ensuite transmis par le module de stockage au module d'accès. L’invention se rapporte également à un module de gestion, et optionnellement un module de stockage, adapté(s) à mettre en oeuvre le procédé selon le quatrième aspect.
Selon un cinquième aspect, l’invention se rapporte à un procédé pour transmettre un deuxième ensemble de données accessible par un module d'accès sur un deuxième réseau de communication, à un module de gestion couplé à un premier réseau de communication. Le premier réseau de communication et le deuxième réseau de communication sont couplés par l'intermédiaire d'un troisième réseau de communication. Un module de communication est couplé au troisième réseau de communication et configuré pour permettre l'établissement d'un canal de communication bidirectionnel entre le module de gestion et le module d'accès. Le procédé comporte : • une première étape au cours de laquelle le deuxième ensemble de données est enregistré dans un emplacement sur le troisième réseau décrit par une deuxième adresse ; • une deuxième étape au cours de laquelle le module d’accès transmet, au module de communication, une deuxième requête, à destination du module de gestion, comportant la deuxième adresse et des informations indiquant que le module d'accès souhaite transmettre le deuxième ensemble de données au module de gestion.
Avantageusement, au cours de la première étape, le module d'accès peut transmettre le deuxième ensemble de données à un module de stockage couplé au troisième réseau de communication. L'emplacement sur le troisième réseau décrit par la deuxième adresse peut alors être déterminé par le module de stockage, le deuxième ensemble de données étant alors stocké par le module de stockage à l'emplacement sur le troisième réseau décrit par la deuxième adresse, la deuxième adresse étant alors transmise par le module de stockage au module d'accès.
Dans un mode de réalisation, au cours de la première étape, le module d'accès transmet, le deuxième ensemble de données au module de stockage, sous une forme cryptée apte à garantir un accès aux données du deuxième ensemble aux seules entités ayant connaissance d'au moins un deuxième élément de sécurité, le deuxième ensemble de données dans sa forme cryptée étant alors stocké par le module de stockage à l'emplacement sur le troisième réseau décrit par la deuxième adresse. L'élément de sécurité est par exemple un mot de passe, un certificat ou tout élément cryptographique adapté pour permettre de crypter le premier ensemble de données.
Le module d'accès peut transmettre le deuxième ensemble de données au module de stockage, par l'intermédiaire d'un canal de communication sécurisé, par exemple en utilisant le protocole de transfert hypertexte sécurisé HTTPS.
Avantageusement, le module de stockage peut effacer le deuxième ensemble de données à l'emplacement sur le troisième réseau décrit par la deuxième adresse, une fois écoulé un laps de temps prédéterminé après le stockage du deuxième ensemble de données à l'emplacement décrit par la deuxième adresse.
Dans un mode de réalisation, la deuxième étape est mise en oeuvre seulement si un utilisateur à l'origine de la transmission de la deuxième requête a été préalablement authentifié et/ou dispose de droits nécessaires et suffisants pour demander le transfert du deuxième ensemble de données au module de gestion. Un procédé d'authentification utilisant des jetons d'authentification, plus généralement désignés par le terme anglo-saxon "token", peut être employé à cet fin. L’invention se rapporte également à un module d'accès, et optionnellement un module de stockage, adapté(s) à mettre en oeuvre le procédé selon le cinquième aspect.
Selon un sixième aspect, l’invention se rapporte à un procédé d'interconnexion, par un module de communication couplé à un troisième réseau de communication, apte à permettre la réception, sur un module de gestion couplé à un premier réseau de communication, d'un deuxième ensemble de données accessible par un module d'accès sur un deuxième réseau de communication. Le premier réseau de communication et le deuxième réseau de communication sont couplés par l'intermédiaire du troisième réseau de communication, le module de communication étant configuré pour permettre l'établissement d'un canal de communication bidirectionnel entre le module de gestion et le module d'accès. Le procédé comporte : • une première étape de transmission, au module de gestion, d'une deuxième requête, émise par le module d'accès à destination du module de gestion, la deuxième requête comportant la deuxième adresse et des informations indiquant que le module d'accès souhaite transmettre le deuxième ensemble de données au module de gestion. L’invention se rapporte également à un module de communication adapté à mettre en oeuvre le procédé selon le sixième aspect.
Selon un septième aspect, l’invention se rapporte à un programme d’ordinateur comportant des instructions pour l’exécution des étapes du procédé selon le premier aspect, selon le deuxième aspect, selon le troisième aspect, selon le quatrième aspect, selon le cinquième aspect, ou selon le sixième aspect, lorsque ledit programme est exécuté par un processeur.
Chacun de ces programmes peut utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable. □ En particulier, il est possible d’utiliser des langages de script, tels que notamment tel, javascript, python, péri qui permettent une génération de code « à la demande » et ne nécessitent pas de surcharge significative pour leur génération ou leur modification.
Selon un huitième aspect, l’invention se rapporte à un support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur comprenant des instructions pour l’exécution des étapes du procédé selon le premier aspect, selon le deuxième aspect, selon le troisième aspect, selon le quatrième aspect, selon le cinquième aspect, ou selon le sixième aspect.
Le support d’informations peut être n’importe quelle entité ou n’importe quel dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu’une ROM, par exemple un CD-ROM ou une ROM de circuit microélectronique, ou encore un moyen d’enregistrement magnétique, par exemple une disquette ou un disque dur. D’autre part, le support d’informations peut être un support transmissible tel qu’un signal électrique ou optique, qui peut être acheminé par un câble électrique ou optique, par radio ou par d’autres moyens. Le programme selon l’invention peut être en particulier téléchargé sur un réseau Internet ou Intranet. Alternativement, le support d’informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l’exécution du procédé en question.
Selon un neuvième aspect, l'invention se rapporte également à un système comportant: au moins un module de gestion selon le premier et/ou quatrième aspect, couplé à un premier réseau de communication; au moins un module d'accès selon le deuxième et/ou cinquième aspect, couplé à un deuxième réseau de communication ; au moins un module de communication selon le troisième et/ou sixième aspect, couplé à un troisième réseau de communication; au moins un module de stockage, selon le premier et/ou deuxième aspect, couplé au troisième réseau de communication.
Brève description des figures D’autres particularités et avantages de la présente invention apparaîtront, dans la description ci-après de modes de réalisation, en référence aux dessins annexés, dans lesquels : la figure 1 est un schéma d’architecture d’un système d'accès distant à des données, selon un mode de réalisation de l’invention ; la figure 2 est un schéma d'un module de gestion selon un mode de réalisation de l'invention ; la figure 3 est un schéma d'un module d'accès selon un mode de réalisation de l'invention ; la figure 4 est un synoptique des étapes d'un procédé d’accès à des données par un module d'accès, selon un mode de réalisation ; la figure 5 est un synoptique des étapes d'un procédé de sauvegarde de données, accessibles depuis le module d'accès pour ordinateur, selon un mode de réalisation ; la figure 6a est un synoptique des étapes d'un procédé d'authentification d'un utilisateur auprès du module de gestion, selon un mode de réalisation ; la figure 6b est un synoptique des étapes d'un procédé de demande de service, formulée par un utilisateur authentifié, auprès du module de gestion, selon un mode de réalisation.
Description détaillée
La figure 1 est un schéma d’architecture d’un système d'accès distant à des données, selon un mode de réalisation de l’invention. Le système comporte un module de gestion 12, un module de communication 14, un module de stockage 16, et au moins un module d'accès 18, 20, 22.
Comme illustré sur la figure 2, le module de gestion 12 comporte un dispositif de traitement 32 muni d'une unité de calcul central (plus généralement désigné par l'acronyme anglo-saxon "CPU" pour "Central Processing Unit") et de mémoires vives (plus généralement désigné par l'acronyme anglo-saxon "RAM" pour "Random-Access Memory"). Le module de gestion 12 est adapté pour exécuter un jeu d'instructions formant un logiciel, afin de mettre en œuvre les étapes du procédé devant être exécutées par le module de gestion 12 et décrites ci-après en regard des figures 4, 5, 6a et 6b. Le module de gestion 12 comporte encore une interface de communication 34, couplée au dispositif de traitement 32, adaptée pour permettre l'accès à un réseau local Rd de communication. Le réseau local Rd est interconnecté à un réseau 10 de sorte à permettre au module de gestion 12 d'échanger des données avec les dispositifs couplés au réseau local Rd ou au réseau 10 de communication. Par exemple, le réseau local Rd est un réseau domestique, interconnecté par l'intermédiaire d'un équipement de terminaison de réseau (non représenté sur les figures), à Internet. Le module de gestion 12 comporte encore des moyens de stockage 36, par exemple un disque dur et/ou un disque électronique (plus généralement désigné par l'acronyme anglo-saxon "SSD" pour "solid-state drive"). Les moyens de stockage 36 permettent de stocker des données et d'autoriser le module d'accès à lire et/ou écrire lesdites données. Le module de gestion 12 peut être mis en œuvre sur un dispositif autonome. Alternativement, le module de gestion 12 peut être mis en œuvre sur un dispositif ayant d'autres fonctionnalités, par exemple un serveur applicatif domestique, un équipement de terminaison de réseau ou encore un ordinateur. Ledit au moins un module d'accès peut être un module d'accès pour dispositif mobile 18, un v, ou un module d'accès pour navigateur Web 22. Le système peut comporter plusieurs modules, chaque module d'accès pouvant être d'un des trois types présentés ci-avant. Comme illustré sur la figure 3, le module d'accès comporte un dispositif de traitement 42 muni d'une unité de calcul central (plus généralement désigné par l'acronyme anglo-saxon "CPU" pour "Central Processing Unit") et de mémoires vives (plus généralement désigné par l'acronyme anglo-saxon "RAM" pour "Random-Access Memory"). Le module d'accès est adapté pour exécuter un jeu d'instructions formant un logiciel, afin de mettre en oeuvre les étapes du procédé devant être exécutées par le module d'accès et décrites ci-après en regard des figures 4, 5, 6a et 6b. Le module d'accès comporte des moyens de stockage 44, par exemple un disque dur et/ou un disque électronique (plus généralement désigné par l'acronyme anglo-saxon "SSD" pour "solid-state drive"). Les moyens de stockage 44 permettent de stocker des données et d'autoriser le module d'accès à lire et/ou écrire lesdites données. Le module d'accès comporte encore une interface de communication 46, couplée au dispositif de traitement 42, adaptée pour permettre l'accès à un réseau Rext externe de communication. Le réseau Rext externe est interconnecté au réseau 10 de sorte à permettre au module d'accès d'échanger des données avec les dispositifs couplés au réseau local Rd ou au réseau 10 de communication. Le réseau Rext externe peut être un réseau accessible à un utilisateur en situation de mobilité, typiquement par l'intermédiaire d'un accès sans fil, et interconnecté à Internet. Le module d'accès comprend également une interface utilisateur 48, munie par exemple de moyens de saisie et d'affichage. L'interface de communication 46 peut également être adaptée pour permettre l'accès au réseau local Rd, de sorte que le module d'accès puisse être utilisé en situation de mobilité mais également en situation locale. Le module d'accès pour dispositif mobile 18 peut être mis en œuvre sur un dispositif de type téléphone mobile ou tablette, muni d'une application adaptée pour mettre en œuvre les étapes du procédé devant être exécutées par le module d'accès et décrites ci-après en regard des figures 4, 5, 6a et 6b. Le module d'accès pour ordinateur 20 peut être mis en œuvre sur un dispositif de type ordinateur de bureau ou ordinateur portable, muni d'une application adaptée pour mettre en œuvre les étapes du procédé devant être exécutées par le module d'accès et décrites ci-après en regard des figures 4, 5, 6a et 6b. Le module d'accès pour navigateur Web 22 peut être mis en œuvre sur tout dispositif adapté à exécuter un navigateur Web, et muni d'une application Web adaptée pour mettre en œuvre les étapes du procédé devant être exécutées par le module d'accès et décrites ci-après en regard des figures 4, 5, 6a et 6b.
Le module de stockage 16 est couplé au réseau 10 de communication. Le module de stockage 16 est configuré pour recevoir des données de terminaux connectés au réseau 10, pour stocker lesdites données et pour transmettre aux terminaux connectés au réseau 10 lesdites données. Le module de stockage 16 est par exemple un serveur de fichiers couplé à Internet. En particulier, le module de stockage 16 est accessible par le module d'accès pour dispositif mobile 18, par le module d'accès pour ordinateur 20, et par le module d'accès pour navigateur Web 22, lorsque le module d'accès est couplé au réseau local Rd ou au réseau Rext externe.
Le module de communication 14 est couplé au réseau 10 de communication. Le module de communication 14 est configuré pour permettre l'échange bidirectionnel, par l'intermédiaire du réseau 10 de communication, de requêtes et/ou de données entre le module de gestion 12, le module de stockage 16, et le/les module(s) d'accès 18, 20, 22. En particulier, le module de communication 14 est configuré pour établir des canaux de communication bidirectionnelle (ou "full-duplex" en anglais) en mode connecté utilisant le protocole de contrôle de transmissions - plus généralement désigné par l'acronyme anglo-saxon "TCP" pour "Transmission Control Protocol", adapté aux navigateurs et serveurs Web. Plus particulièrement, le module de communication 14 est configuré pour permettre la mise en œuvre du protocole WebSocket, standard du Web désignant un protocole réseau de la couche application et une interface de programmation du World Wide Web. Le protocole WebSocket est décrit notamment dans le document Request For Comments 6455 (http://tools.ietf.org/html/rfc6455). L’utilisation du module de communication mettant en œuvre le protocole WebSocket permet notamment d'échanger des messages, entre les entités du système d'accès selon l'invention, de façon bidirectionnelle, sans qu'il soit nécessaire qu'une requête préalable ait été émise par une des entités du système pour qu'une autre entité du système ait le droit de lui transmettre un message : ainsi toutes les entités du système peuvent envoyer directement une requête aux autres entités.
Les canaux de communication employés pour échanger des informations entre d'une part le module de gestion 12, le module de stockage 16, et le/les module(s) d'accès 18, 20, 22 et d'autre part le module de communication 14 peuvent être sécurisés, par exemple en employant le protocole HTTPS. En outre, les messages échangés entre le module de gestion 12, le module de stockage 16, le/les module(s) d'accès 18, 20, 22 et le module de communication 14 peuvent être dans un format de données structurées, par exemple le format JSON (de l'anglais "Javascript Object Notation"), décrit notamment dans le document Request For Comments 7159. Chaque module d'accès 18, 20, 22 est configuré pour accéder au module de communication 14 et, par l'intermédiaire de ce dernier, pour échanger des messages avec le module de gestion 12, le module de stockage 16, et optionnellement avec les autres modules d'accès 18, 20, 22.
Alternativement au protocole WebSocket, le module de communication 14 peut être configuré pour utiliser un procédé d’attente active, plus généralement désigné par le terme anglo-saxon de "polling" : le module de communication 14 peut ainsi envoyer à chaque entité du système selon l'invention, à intervalles réguliers, une requête HTTP et recevoir immédiatement une réponse. Cette dernière est par la suite utilisée par le module de communication 14 pour transférer un message, dès que ladite entitée envoie au module de communication 14 une requête.
Alternativement au protocole WebSocket, le module de communication 14 peut être configuré pour utiliser un procédé de diffusion, plus généralement désigné par le terme anglo-saxon de "streaming" : Chaque module d'accès 18, 20, 22 envoie une requête complète au module de communication 14. Ce dernier renvoie et maintient une réponse ouverte, mise à jour de manière continue. Le module de communication 14 peut alors répondre audit module d'accès 18, 20, 22 avec un message, sans pour autant clôturer la réponse, de sorte que la connexion entre le module de communication 14 et le module d'accès reste ouverte, pour les futurs échanges.
Les étapes du procédé décrit ci-après en regard des figures 4, 5, 6a et 6b peuvent être mises en œuvre dans un logiciel par l'exécution d'un jeu d'instructions ou d'un programme par un dispositif de traitement programmable, tel un ordinateur personnel, un processeur de traitement du signal et/ou un microcontrôleur ; ou alternativement de manière matérielle par une machine ou un composant dédié, tel un circuit logique programmable - par exemple de type couramment désigné par l'acronyme anglo-saxon "FPGA" pour "Field-Programmable Gâte Array", ou un circuit intégré propre à une application désigné plus couramment par l'acronyme anglo-saxon "ASIC" pour "Application-Specific Integrated Circuit'.
En référence à la figure 6a, un procédé d'authentification d'un utilisateur auprès du module de gestion 12, selon un mode de réalisation, va maintenant être décrit. L’exemple qui suit décrit le cas où un utilisateur souhaite s'authentifier auprès du module de gestion 12, à l’aide du module d'accès pour navigateur Web 22. Le procédé d'authentification pourrait être mis en œuvre par l'utilisateur en utilisant le module d'accès pour dispositif mobile 18 ou le module d'accès pour ordinateur 20.
Dans une première étape 310, après saisie par l'utilisateur, des informations d'authentification AUTH, aptes à permettre l'authentification de l'utilisateur par le module de gestion 12, sont reçues par le module d'accès pour navigateur Web 22. Les informations d'authentification AUTH sont par exemple un identifiant et un mot de passe. Le module d'accès pour navigateur Web 22 transmet alors, au module de communication 14, une requête Rauth à destination du module de gestion 12 pour authentifier l'utilisateur. La requête R1 comporte par exemple les éléments suivant : • les informations d'authentification AUTH ; • un élément d'identification pour permettre de déterminer de l'émetteur de la requête, dans le cas présent le module d’accès pour navigateur Web 22 ; • une description des actions demandées par l'émetteur, dans le cas présent authentifier l'utilisateur.
Dans une deuxième étape 320, après réception de la requête Rauth, le module de communication 14 transmet la requête Rauth au module de gestion 12.
Dans une troisième étape 330, après réception de la requête Rauth transmises par le module de communication 14, le module de gestion 12 vérifie la validité des informations d'authentification AUTH. Par exemple, le module de gestion 12 peut s'assurer que les informations d'authentification AUTH reçues correspondent à celles d'un des utilisateurs d'une liste d'utilisateurs autorisés à accéder au module de gestion 12.
Au cours de la troisième étape 330, si les informations d'authentification AUTH sont considérées comme valide par le module de gestion 12, ce dernier génère un jeton d'authentification TOK, propre à l'utilisateur, plus généralement désigné par le terme anglo-saxon "token". Le jeton de sécurité est utilisé pour prouver une identité par voie électronique (comme un client tentant d'accéder à son compte en banque). Le module de gestion 12 transmet alors, au module de communication 14, une réponse RPauth à destination du module d’accès pour navigateur Web 22. La réponse RPauth comporte par exemple les éléments suivant : • le jeton d'authentification TOK ; • une information indiquant que l'authentification de l'utilisateur a réussi.
Au cours de la troisième étape 330, si les informations d'authentification AUTH ne sont pas considérées comme valide par le module de gestion 12, ce dernier transmet alors, au module de communication 14, une réponse RPauth à destination du module d’accès pour navigateur Web 22. La réponse RPauth comporte par exemple les éléments suivant : • le jeton d'authentification TOK ; • une information indiquant que l'authentification de l'utilisateur a échoué.
Dans une quatrième étape 340, après réception de la réponse RPauth, le module de communication 14 transmet la réponse RPauth au module d'accès pour navigateur Web 22.
Dans une cinquième étape 350, après réception de la réponse RPauth transmise par le module de communication 14, le module d’accès pour navigateur Web 22 enregistre, pour une utilisation ultérieure, le jeton d'authentification TOK compris dans la réponse RP2, et peut afficher et/ou enregistrer l'information du succès de l'authentification, ou afficher, le cas échéant, un message d'erreur indiquant que l'authentification a échoué.
En référence à la figure 6b, un procédé de demande de service, formulée par un utilisateur authentifié, auprès du module de gestion 12, selon un mode de réalisation, va maintenant être décrit. L’exemple qui suit décrit le cas où un utilisateur a préalablement été authentifié, par exemple suite à la mise en oeuvre du procédé illustré sur la figure 6a. Le procédé de demande de service pourrait être mis en œuvre par l'utilisateur en utilisant le module d'accès pour dispositif mobile 18 ou le module d'accès pour ordinateur 20.
Dans une première étape 360, le module d'accès pour navigateur Web 22 transmet, au module de communication 14, une requête R3 à destination du module de gestion 12 pour demander un service. Dans l'exemple qui suit, le service correspond à une demande d'obtention d'une liste d'images accessibles par l'intermédiaire du module de gestion 12. La requête R3 comporte par exemple les éléments suivant : • le jeton d'authentification TOK ; • un élément d'identification pour permettre de déterminer de l'émetteur de la requête, dans le cas présent le module d’accès pour navigateur Web 22 ; • une description des actions demandées par l'émetteur, dans le cas présent obtenir une liste d'images accessibles par l'intermédiaire du module de gestion 12.
Dans une deuxième étape 370, après réception de la requête R3, le module de communication 14 transmet la requête R3 au module de gestion 12.
Dans une troisième étape 380, après réception de la requête R3 transmises par le module de communication 14, le module de gestion 12 vérifie la validité du jeton d'authentification TOK. Par exemple, le module de gestion 12 peut s'assurer que le jeton d'authentification TOK correspond bien à un jeton qu'il a préalablement généré, et/ou si le jeton d'authentification TOK est encore valable.
Au cours de la troisième étape 380, si le jeton d'authentification TOK est considéré comme valide par le module de gestion 12, ce dernier exécute les actions demandées dans la requête R3, dans le présent exemple, déterminer une liste d'images accessibles. Le module de gestion 12 transmet alors, au module de communication 14, une réponse RP3 à destination du module d’accès pour navigateur Web 22. La réponse RP3 comporte la liste d'images accessibles.
Au cours de la troisième étape 380, si le jeton d'authentification TOK n'est pas considéré comme valide par le module de gestion 12, le module de gestion 12 transmet alors, au module de communication 14, une réponse RP3 à destination du module d’accès pour navigateur Web 22. La réponse RP3 comporte une information indiquant que les actions demandées ne peuvent être exécutées car l'utilisateur n'a pas été authentifié.
Dans une quatrième étape 390, après réception de la réponse RP3, le module de communication 14 transmet la réponse RP3 au module d'accès pour navigateur Web 22.
Dans une cinquième étape 350, après réception de la réponse RP3 transmise par le module de communication 14, le module d’accès pour navigateur Web 22 peut afficher et/ou enregistrer la liste des d'images accessibles ou afficher, le cas échéant le message indiquant que les actions demandées ne peuvent être exécutées car l'utilisateur n'a pas été authentifié.
En référence à la figure 4, un procédé d’accès à des données par un module d'accès, selon un mode de réalisation, va maintenant être décrit. Les données peuvent être de diverses natures, par exemple des images, des documents, des vidéos, etc. Les données sont accessibles par le module de gestion 12. Les données peuvent être par exemple stockées sur des moyens de stockage, couplés au réseau local Rd, auxquels le module de gestion 12 peut accéder. L’exemple qui suit décrit le cas où un utilisateur souhaite accéder à un fichier F1, accessible par le module de gestion 12, à l’aide du module d'accès pour dispositif mobile 18. Le procédé pourrait être appliqué indifféremment avec le module d'accès pour ordinateur 20 ou le module d'accès pour navigateur Web 22.
Dans une première étape 110, le module d’accès pour dispositif mobile 18 transmet, au module de communication 14, une requête R1 à destination du module de gestion 12 pour obtenir le fichier F1. La requête R1 comporte par exemple les éléments suivant : • un élément d'identification pour permettre de déterminer de l'émetteur de la requête, dans le cas présent le module d’accès pour dispositif mobile 18 ; • une description de la ressource à laquelle l'émetteur de la requête souhaite accéder, par exemple le nom du fichier F1 ; • une description des actions demandées par l'émetteur, dans le cas présent obtenir le fichier F1.
Dans une deuxième étape 120, le module de communication 14 transmet la requête R1 au module de gestion 12.
Dans une troisième étape 130, le module de gestion 12 reçoit la requête R1 et transfère le fichier F1 au module de stockage 16. Avantageusement, afin d'améliorer le niveau de sécurité, le module de gestion 12 peut crypter le fichier F1 avant de le transmettre au module de stockage 16. Ainsi le fichier F1 arrive sur le module de stockage sous forme cryptée et est stocké ainsi. En outre, le module de gestion 12 peut encore utiliser un canal de communication sécurisé vers le module de stockage 16, par exemple en transférant le fichier F1 à l'aide du protocole HTTPS.
Dans une quatrième étape 140, après réception du fichier F1, le module de stockage 16 détermine une adresse A1, par exemple une adresse URL, à l'aide de laquelle les terminaux connectés au réseau 10 de communication peuvent atteindre l'emplacement sur le module de stockage 16 où le fichier F1 est stocké. Le module de stockage 16 transmet alors ladite adresse A1 au module de gestion 12.
Dans une cinquième étape 150, après la fin de la transmission du fichier F1 au module de stockage 16, le module de gestion 12 transmet une réponse RP1 au module de communication 14 à destination du module d’accès pour dispositif mobile 18. La réponse RP1 comporte par exemple les éléments suivant : • l'adresse A1 du fichier F1 sur le module de stockage 16 ; • des éléments de sécurité permettant de décrypter le fichier F1, si le fichier F1 a été transmis par le module de gestion 12 sous forme cryptée au module de stockage 16.
Dans une sixième étape 160, le module de gestion 12 reçoit la réponse RP1, puis transmet la réponse RP1 au module d’accès pour dispositif mobile 18.
Dans une septième étape 170, le module d’accès pour dispositif mobile 18 reçoit la réponse RP1. Après extraction de l'adresse A1 de la réponse RP1, le module d’accès pour dispositif mobile 18 télécharge le fichier F1 à l'adresse A1, sur le module de stockage 16. Pour cela, le module de gestion 12 peut envoyer, au module de stockage 16, une requête de téléchargement du fichier F1 comportant I l'adresse A1. Une fois téléchargé, si le fichier F1 est sous forme cryptée, le module d’accès pour dispositif mobile 18 peut décrypter le fichier F1 à l'aide des éléments de sécurité reçus dans la réponse RP1. Le fichier F1 peut alors être sauvegardé ou affiché.
Avantageusement, une fois le fichier F1 téléchargé par le module d’accès pour dispositif mobile 18, le module de stockage 16 peut stocker le fichier F1 pendant une période prédéterminée - typiquement quelques minutes -au cours de laquelle le fichier F1 pourrait être à nouveau téléchargé, puis automatiquement supprimé. Ainsi, le module de stockage efface le fichier F1 à l'adresse F1, une fois écoulé un lapse de temps prédéterminé - typiquement quelques minutes - après la fin de l'exécution de la quatrième étape 140.
Dans un mode de réalisation, le procédé d’accès à des données décrit à la figure 4, requiert l'authentification préalable de l'utilisateur du module d’accès pour dispositif mobile 18 pour télécharger le fichier F1. Pour cela, le procédé d'authentification d'un utilisateur auprès du module de gestion 12, décrit par la figure 6a, peut être utilisé, à l'issue duquel l'utilisateur dispose d'un jeton d'authentification TOK. Le procédé de demande de service, illustré sur la figure 6b, peut alors être mis en œuvre, le service correspondant alors à l'accès au fichier F1. En particulier, la requête R1 comportera encore le jeton d'authentification TOK, et la troisième étape 130, quatrième étape 140, et cinquième étape 150 ne sont exécutées que si le module de gestion considère le jeton d'authentification TOK reçu dans la requête R1 comme valide. En outre, le procédé d’accès à des données peut également nécessiter que l'utilisateur du module d'accès dispose de droits nécessaires et suffisants pour télécharger le fichier F1.
En référence à la figure 5, un procédé de sauvegarde de données, accessibles depuis le module d'accès pour ordinateur 20, selon un mode de réalisation, va maintenant être décrit. Les données peuvent être de diverses natures, par exemple des images, des documents, des vidéos, etc. Les données sont accessibles par le module d'accès pour ordinateur 20. Les données peuvent être par exemple stockées sur les moyens de stockage 44 du module d'accès pour ordinateur 20. L’exemple qui suit décrit le cas où un utilisateur souhaite sauvegarder un fichier F2, à l'aide du module d'accès pour ordinateur 20. Le procédé pourrait être appliqué indifféremment à l'aide du module d'accès pour dispositif mobile 20 ou le module d'accès pour navigateur Web 22.
Dans une première étape 210, le module d’accès pour ordinateur 20 transmet le fichier F2 au module de stockage 16. Avantageusement, afin d'améliorer le niveau de sécurité, le module d’accès 12 peut crypter le fichier F2 avant de le transmettre au module de stockage 16. Ainsi le fichier F2 arrive sur le module de stockage sous forme cryptée et est stocké ainsi. En outre, le module d’accès pour ordinateur 20 peut encore utiliser un canal de communication sécurisé vers le module de stockage 16, par exemple en transférant le fichier F2 à l'aide du protocole FITTPS.
Dans une deuxième étape 220, après réception du fichier F2, le module de stockage 16 détermine une adresse A2, par exemple une adresse URL, à l'aide de laquelle les terminaux connectés au réseau 10 de communication peuvent atteindre l'emplacement sur le module de stockage 16 où le fichier F2 est stocké. Le module de stockage 16 transmet alors ladite adresse A2 au module d’accès pour ordinateur 20.
Dans une troisième étape 230, le module d’accès pour ordinateur 20 reçoit l'adresse A2 et transmet au module de communication 14, une requête R2 à destination du module de gestion 12 pour sauvegarder le fichier F2. La requête R2 comporte par exemple les éléments suivant : • un élément d'identification pour permettre de déterminer de l'émetteur de la requête, dans le cas présent le module d’accès pour ordinateur 20 ; • l'adresse A2 ; • une description des actions demandées par l'émetteur, dans le cas présent sauvegarder le fichier F2.
Dans une quatrième étape 240, après réception de la requête R2, le module de communication 14 transmet la requête R2 au module de gestion 12.
Dans une cinquième étape 250, le module de gestion 12 reçoit la requête R2. Après extraction de l'adresse A2 de la requête R2, le module de gestion 12 télécharge le fichier F2 depuis l'adresse A2, sur le module de stockage 16. Pour cela, le module de gestion 12 peut envoyer, au module de stockage 16, une requête de téléchargement du fichier F2 comportant I l'adresse A2. Une fois téléchargé, le fichier F2 peut alors être sauvegardé par le module de gestion 12, par exemple en utilisant des moyens de sauvegarde et/ou de stockage connecté au réseau local RD. Si le fichier F2 a été crypté, le module de gestion 12 peut sauvegarder le fichier F2 sous une forme cryptée. Si le fichier F2 n'a pas été préalablement crypté, le module de gestion 12 peut sauvegarder le fichier F2 sous une forme cryptée.
Avantageusement, une fois le fichier F2 téléchargé par le module de gestion 12, le module de stockage 16 peut stocker le fichier F2 pendant une période prédéterminée - typiquement quelques minutes - au cours de laquelle le fichier F2 pourrait être à nouveau téléchargé, puis automatiquement supprimé.
Au cours de la cinquième étape 250, après la fin de la sauvegarde du fichier F2, le module de gestion 12 transmet une réponse RP2 au module de communication 14 à destination du module d’accès pour ordinateur 20. La réponse RP2 comporte par exemple une confirmation que le fichier F2 a été sauvegardé avec succès ou, le cas échéant, un message d'erreur si l'opération de sauvegarde n'a pu aboutir.
Dans une sixième étape 260, le module de communication 14 reçoit la réponse RP2, puis transmet la réponse RP2 au module d’accès pour ordinateur 20.
Dans une septième étape 270, le module d’accès pour ordinateur 20 reçoit la réponse RP2, et peut afficher et/ou enregistrer l'information du succès de la sauvegarde du fichier F2 ou afficher, le cas échéant le message d'erreur.
Dans un mode de réalisation, le procédé de sauvegarde de données requiert l'authentification préalable de l'utilisateur du module d’accès pour ordinateur 20 pour sauvegarder le fichier F2. Pour cela, le procédé d'authentification d'un utilisateur auprès du module de gestion 12, décrit par la figure 6a, peut être utilisé, à l'issue duquel l'utilisateur dispose d'un jeton d'authentification TOK. Le procédé de demande de service, illustré sur la figure 6b, peut alors être mis en œuvre, le service correspondant alors à la sauvegarde du fichier F2. En particulier, la requête R2 comportera encore le jeton d'authentification TOK, et la troisième étape 230, quatrième étape 240, et cinquième étape 250 ne sont exécutées que si le module de gestion considère le jeton d'authentification TOK reçu dans la requête R2 comme valide.
Claims (15)
- REVENDICATIONS1. Procédé pour transmettre, un premier ensemble de données accessible par un module de gestion (12) sur un premier réseau de communication (Rd), à un module d'accès (18, 20, 22) couplé à un deuxième réseau de communication (Rext), le premier réseau de communication et le deuxième réseau de communication étant couplés par l'intermédiaire d'un troisième réseau de communication (10), un module de communication (14) étant couplé au troisième réseau de communication et configuré pour permettre l'établissement d'un canal de communication bidirectionnel entre le module de gestion et le module d'accès, caractérisé en ce qu'il comporte : • une première étape (130) au cours de laquelle une première requête (R1), transmise par le module de communication et générée par le module d'accès, est reçue par le module de gestion, la première requête comportant des informations permettant au module de gestion de déterminer que le module d'accès demande un accès au premier ensemble de données ; • une deuxième étape (140, 150) au cours de laquelle le premier ensemble de données est enregistré dans un emplacement sur le troisième réseau décrit par une première adresse (A1) ; • une troisième étape (160) au cours de laquelle le module de gestion transmet une première réponse au module de communication à destination du module d'accès ; la première réponse comportant la première adresse.
- 2. Procédé selon la revendication 1, dans lequel, au cours de la deuxième étape, le module de gestion transmet le premier ensemble de données à un module de stockage (16) couplé au troisième réseau de communication (10), l'emplacement sur le troisième réseau décrit par la première adresse étant alors déterminé par le module de stockage (16), le premier ensemble de données étant alors stocké par le module de stockage (16) à l'emplacement sur le troisième réseau décrit par la première adresse, la première adresse étant alors transmise par le module de stockage au module de gestion.
- 3. Procédé selon la revendication 2, dans lequel, au cours de la deuxième étape, le module de gestion transmet, le premier ensemble de données au module de stockage (16), sous une forme cryptée apte à garantir un accès aux données du premier ensemble aux seules entités ayant connaissance d'au moins un premier élément de sécurité, le premier ensemble de données dans sa forme cryptée étant alors stocké par le module de stockage (16) à l'emplacement sur le troisième réseau décrit par la première adresse.
- 4. Procédé selon la revendication 2 ou 3, dans lequel, au cours de la deuxième étape, le module de gestion transmet le premier ensemble de données au module de stockage (16), par l'intermédiaire d'un canal de communication sécurisé.
- 5. Procédé selon l'une quelconque des revendications 2 à 4, dans lequel le module de stockage efface le premier ensemble de données à l'emplacement sur le troisième réseau décrit par la première adresse, une fois écoulé un laps de temps prédéterminé après le stockage du premier ensemble de données à l'emplacement décrit par la première adresse.
- 6. Procédé selon l'une quelconque des revendications 1 à 5, dans lequel la troisième étape (160) est mise en oeuvre seulement si un utilisateur à l'origine de la transmission de la première requête (R1) a été préalablement authentifié et/ou dispose de droits nécessaires et suffisants pour accéder au premier ensemble de données.
- 7. Procédé pour recevoir, sur un module d'accès (18, 20, 22) couplé à un deuxième réseau de communication (Rext), un premier ensemble de données accessible par un module de gestion (12) sur un premier réseau de communication (RD), le premier réseau de communication et le deuxième réseau de communication étant couplés par l'intermédiaire d'un troisième réseau de communication (10), un module de communication (14) étant couplé au troisième réseau de communication et configuré pour permettre rétablissement d'un canal de communication bidirectionnel entre le module de gestion et le module d'accès, caractérisé en ce qu'il comporte : • une première étape (110) au cours de laquelle le module d’accès transmet, au module de communication, une première requête (R1), à destination du module de gestion, comportant des informations indiquant que le module d'accès demande un accès au premier ensemble de données ; • une deuxième étape (170) au cours de laquelle le module d'accès reçoit une première réponse (RP1), transmise par le module de communication et générée par le module de gestion en réponse à la première requête, la première réponse comportant une première adresse (A1) désignant un emplacement sur le troisième réseau de communication où le premier ensemble de données est stocké ; le premier ensemble de données étant alors obtenu par le module d'accès au moyen de la première adresse.
- 8. Procédé selon la revendication 7, dans lequel, au cours de la deuxième étape, le module d'accès obtient le premier ensemble de données en transmettant une requête de téléchargement du premier ensemble de données à un module de stockage (16) couplé au troisième réseau de communication (10), la requête de téléchargement comportant la première adresse, l'emplacement sur le troisième réseau décrit par la première adresse étant alors utilisé par le module de stockage (16) pour accéder au premier ensemble de données, le premier ensemble de données étant ensuite transmis par le module de stockage au module d'accès.
- 9. Procédé d'interconnexion, par un module de communication (14) couplé à un troisième réseau de communication (10), apte à permettre la réception, sur un module d'accès (18, 20, 22) couplé à un deuxième réseau de communication (Rext), d'un premier ensemble de données accessible par un module de gestion (12) sur un premier réseau de communication (Rd), le premier réseau de communication et le deuxième réseau de communication étant couplés par l'intermédiaire du troisième réseau de communication (10), le module de communication (14) étant configuré pour permettre l'établissement d'un canal de communication bidirectionnel entre le module de gestion et le module d'accès, caractérisé en ce qu'il comporte : • une première étape (120) de transmission, au module de gestion, d'une première requête (R1), émise par le module d'accès et comportant des informations indiquant que le module d'accès demande un accès au premier ensemble de données ; • une deuxième étape (160) de transmission, au module d'accès, d'une première réponse (RP1), émise par le module de gestion en réponse à la première requête, la première réponse comportant une première adresse (A1) désignant un emplacement sur le troisième réseau de communication où le premier ensemble de données est stocké.
- 10. Procédé pour recevoir un deuxième ensemble de données accessible par un module d'accès (18, 20, 22) sur un deuxième réseau de communication (Rext), sur un module de gestion (12) couplé à un premier réseau de communication (Rd), le premier réseau de communication et le deuxième réseau de communication étant couplés par l'intermédiaire d'un troisième réseau de communication (10), un module de communication (14) étant couplé au troisième réseau de communication et configuré pour permettre l'établissement d'un canal de communication bidirectionnel entre le module de gestion et le module d'accès, caractérisé en ce qu'il comporte : • une première étape (250) au cours de laquelle le module de gestion reçoit une deuxième requête (R2), transmise par le module de communication et générée par le module d'accès, la deuxième requête comportant une deuxième adresse (A2) désignant un emplacement sur le troisième réseau de communication où le deuxième ensemble de données est stocké ; le deuxième ensemble de données étant alors obtenu par le module de gestion au moyen de la deuxième adresse.
- 11. Procédé pour transmettre un deuxième ensemble de données accessible par un module d'accès (18, 20, 22) sur un deuxième réseau de communication (Rext), à un module de gestion (18, 20, 22) couplé à un premier réseau de communication (RD), le premier réseau de communication et le deuxième réseau de communication étant couplés par l'intermédiaire d'un troisième réseau de communication (10), un module de communication (14) étant couplé au troisième réseau de communication et configuré pour permettre l'établissement d'un canal de communication bidirectionnel entre le module de gestion et le module d'accès, caractérisé en ce qu'il comporte : • une première étape (210) au cours de laquelle le deuxième ensemble de données est enregistré dans un emplacement sur le troisième réseau décrit par une deuxième adresse (A2) ; • une deuxième étape (230) au cours de laquelle le module d’accès transmet, au module de communication, une deuxième requête (R2), à destination du module de gestion, comportant la deuxième adresse et des informations indiquant que le module d'accès souhaite transmettre le deuxième ensemble de données au module de gestion.
- 12. Procédé d'interconnexion, par un module de communication (14) couplé à un troisième réseau de communication (10), apte à permettre la réception, sur un module de gestion (12) couplé à un premier réseau de communication (Rd), d'un deuxième ensemble de données accessible par un module d'accès (18, 20, 22) sur un deuxième réseau de communication (Rext), le premier réseau de communication et le deuxième réseau de communication étant couplés par l'intermédiaire du troisième réseau de communication (10), le module de communication (14) étant configuré pour permettre l'établissement d'un canal de communication bidirectionnel entre le module de gestion et le module d'accès, caractérisé en ce qu'il comporte : • une première étape (240) de transmission, au module de gestion, d'une deuxième requête (R2), émise par le module d'accès à destination du module de gestion, la deuxième requête comportant la deuxième adresse et des informations indiquant que le module d'accès souhaite transmettre le deuxième ensemble de données au module de gestion.
- 13. Système comportant : au moins un module de gestion,, couplé à un premier réseau de communication (Rd), adapté pour permettre la mise en oeuvre des étapes des procédés selon les revendications 1 à 6 et/ou 10 ; au moins un module d'accès, couplé à un deuxième réseau de communication (Rext), adapté pour permettre la mise en oeuvre des étapes des procédés selon l'une quelconque des revendications 7 à 8 et/ou 11 ; au moins un module de communication, couplé à un troisième réseau de communication (10), adapté pour permettre la mise en oeuvre des étapes des procédés selon les revendications 9 et/ou 12 ; au moins un module de stockage (16), couplé au troisième réseau de communication, adapté pour permettre la mise en oeuvre des étapes des procédés selon les revendications 2 à 6 et/ou 8.
- 14. Programme d’ordinateur comportant des instructions pour l’exécution des étapes d'un des procédés selon l’une quelconque des revendications 1 à 12, lorsque ledit programme est exécuté par un processeur.
- 15. Support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur comprenant des instructions pour l’exécution des étapes des procédés selon l’une quelconque des revendications 1 à 12.
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
FR1559605A FR3042362B1 (fr) | 2015-10-09 | 2015-10-09 | Moyens de gestion d'acces a des donnees |
PCT/FR2016/052563 WO2017060624A1 (fr) | 2015-10-09 | 2016-10-05 | Moyens de gestion d'accès à des données |
EP16793941.2A EP3360293A1 (fr) | 2015-10-09 | 2016-10-05 | Moyens de gestion d'accès à des données |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
FR1559605A FR3042362B1 (fr) | 2015-10-09 | 2015-10-09 | Moyens de gestion d'acces a des donnees |
Publications (2)
Publication Number | Publication Date |
---|---|
FR3042362A1 true FR3042362A1 (fr) | 2017-04-14 |
FR3042362B1 FR3042362B1 (fr) | 2017-12-01 |
Family
ID=55361614
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
FR1559605A Expired - Fee Related FR3042362B1 (fr) | 2015-10-09 | 2015-10-09 | Moyens de gestion d'acces a des donnees |
Country Status (3)
Country | Link |
---|---|
EP (1) | EP3360293A1 (fr) |
FR (1) | FR3042362B1 (fr) |
WO (1) | WO2017060624A1 (fr) |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP2273761A1 (fr) * | 2009-06-26 | 2011-01-12 | France Telecom | Accès à un contenu d'un système de stockage distribué |
EP2466849A1 (fr) * | 2010-12-20 | 2012-06-20 | France Telecom | Distribution selective d'un flux multicast |
-
2015
- 2015-10-09 FR FR1559605A patent/FR3042362B1/fr not_active Expired - Fee Related
-
2016
- 2016-10-05 EP EP16793941.2A patent/EP3360293A1/fr not_active Withdrawn
- 2016-10-05 WO PCT/FR2016/052563 patent/WO2017060624A1/fr active Application Filing
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP2273761A1 (fr) * | 2009-06-26 | 2011-01-12 | France Telecom | Accès à un contenu d'un système de stockage distribué |
EP2466849A1 (fr) * | 2010-12-20 | 2012-06-20 | France Telecom | Distribution selective d'un flux multicast |
Also Published As
Publication number | Publication date |
---|---|
EP3360293A1 (fr) | 2018-08-15 |
WO2017060624A1 (fr) | 2017-04-13 |
FR3042362B1 (fr) | 2017-12-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP3008872B1 (fr) | Procédé d'authentification d'un terminal par une passerelle d'un réseau interne protégé par une entité de sécurisation des accès | |
EP1909462B1 (fr) | Procédé de mise à disposition cloisonnée d'un service électronique | |
EP3032799B1 (fr) | Procédé d'authentification d'un utilisateur, serveur, terminal de communication et programmes correspondants | |
FR2951897A1 (fr) | Dispositif et procede de gestion des droits d'acces a un reseau sans fil | |
FR2923337A1 (fr) | Procede et systeme d'echange de donnees entre serveurs distants. | |
FR2997525A1 (fr) | Procede de fourniture d’un service securise | |
FR3013541A1 (fr) | Procede et dispositif pour la connexion a un service distant | |
EP3588903A1 (fr) | Procédé, dispositif et serveur de distribution sécurisée d'une configuration à un terminal | |
EP1737191B1 (fr) | Procédé de création d'un terminal éclaté entre un terminal de base et des équipements connectés en serie | |
EP1762037A2 (fr) | Procede et systeme de certification de l'identite d'un utilisateur | |
EP3667530B1 (fr) | Accès sécurise à des données chiffrées d'un terminal utilisateur | |
WO2017060624A1 (fr) | Moyens de gestion d'accès à des données | |
WO2005079038A1 (fr) | Procede, terminal mobile, systeme et equipement pour la fourniture d’un service de proximite accessible par l’intermediaire d’un terminal mobile | |
FR3105696A1 (fr) | Procédé d’obtention d’une commande relative à un profil d’accès réseau d’un module de sécurité de type eUICC | |
WO2012156365A1 (fr) | Procede de securisation d'une platforme d'authentification, dispositifs materiels et logiciels correspondants | |
EP2525525B1 (fr) | Procédé, programme d'ordinateur et dispositif de cooptation permettant à un abonné d'un service de partager ce service avec un autre utilisateur | |
WO2022096824A1 (fr) | Procede de delegation d'acces a une chaine de blocs | |
EP4362391A1 (fr) | Procédé de gestion d'accès d'un utilisateur à au moins une application, programme d'ordinateur et système associés | |
FR3112053A1 (fr) | Procédé de gestion d’une phase d’appairage entre dispositifs de traitement de données. | |
EP2400726A1 (fr) | Procédé d'identification d'un réseau local identifié par une adresse IP publique | |
FR3076638A1 (fr) | Procede de gestion d'un acces a une page web d'authentification | |
EP3643035A1 (fr) | Procédé de contrôle de l'obtention par un terminal d'un fichier de configuration | |
EP3224994A1 (fr) | Procédé de notification de messages | |
FR2888437A1 (fr) | Procede et systeme de controle d'acces a un service d'un fournisseur d'acces implemente sur un serveur multimedia, module, serveur, terminal et programmes pour ce systeme | |
FR3031609A1 (fr) | Procede de traitement d'une transaction a partir d'un terminal de communication |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PLFP | Fee payment |
Year of fee payment: 2 |
|
PLSC | Publication of the preliminary search report |
Effective date: 20170414 |
|
PLFP | Fee payment |
Year of fee payment: 3 |
|
PLFP | Fee payment |
Year of fee payment: 4 |
|
ST | Notification of lapse |
Effective date: 20200910 |