FR3136075A1 - Infrastructure de sécurité ; procédé et produit programme d’ordinateur associés. - Google Patents

Abstract

Infrastructure de sécurité  ; procédé et p roduit programme d’ordinateur associé s. Cette infrastructure pour sécuriser la connexion via l’internet entre un client (10) et un serveur (24), le serveur mettant à disposition un service (23), est une infrastructure Darknet comportant : un réseau Darknet (43) ; un agent client (41) exécuté par le client (10) et mémorisant un fichier de configuration client (T) ; un agent serveur (42) exécuté sur le serveur (24) et mémorisant un fichier de configuration serveur (F) ; et un contrôleur (44), comportant une base de données (B) stockant des informations de configuration, le contrôleur étant accessible à travers le réseau Darknet (43) par l’agent client (41), respectivement par l’agent serveur (42), pour recevoir des informations de configuration client, respectivement serveur, permettant la mise à jour du fichier de configuration client, respectivement serveur. Figure pour l'abrégé : Figure 1

Description

Infrastructure de sécurité ; procédé et produit programme d’ordinateur associés.

La présente invention concerne le domaine de la sécurité informatique des réseaux.

Internet est largement basé sur le modèle TCP/IP depuis sa création. Selon ce modèle, les services mis à disposition des utilisateurs sur internet sont « exposés » au monde entier. Comme exemples de service, on peut citer une application Web – c’est-dire une application manipulable directement en ligne grâce à un navigateur distant, une application VPN – c’est-à-dire une application permettant d’établir un tunnel de communication sécurisé, une application API – c’est-à-dire une application fournissant une fonctionnalité élémentaire à une application distante, etc.

Lorsqu’un service est exposé, il n’a d’autre choix que de « subir » les sollicitations de connexions de la part des clients.

Un service exposé sur internet est identifiable, le plus souvent, par une adresse IPv4 (4 octets) et un port (2 octets).

Il est ainsi possible de scanner l’internet pour disposer d’une cartographie de tous les services exposés.

Cela signifie que les services exposés sont trouvables par des attaquants. Les attaquants listent des services exposés d’une organisation donnée, recherche les vulnérabilités de ces services, puis lancent une attaque ciblée sur le service pour compromettre le système d’information. On constate que plus d’un tiers des compromissions de systèmes d’information sont dues à l’exploitation de vulnérabilités qui affectent un service exposé sur internet du système informatique compromis.

Différentes manières de traiter ce problème ont été proposées, comme : la mise en place de pare-feu qui filtrent les tentatives de connexion ; l’analyse en profondeur du trafic et de blocage des tentatives de compromission ; le déploiement de processus de mise à jour des services exposés (avec la correction des vulnérabilités identifiées) ; la réduction de la surface d’exposition du système d’information (en déplaçant un service exposé sur internet vers l’intérieur du système d’information, puis en le rendant accessible à travers un seul point d’exposition, le plus souvent au moyen d’un VPN) ; le transfert des services exposés vers le cloud d’un tiers, qui en prend la responsabilité et en assure la protection.

Le but de la présente invention est de résoudre ce problème, en proposant une solution alternative aux solutions connues, qui est fondée sur la suppression des points d’exposition.

Pour cela l’invention a pour objet une infrastructure de sécurité destinée à être déployée dans une architecture s’appuyant sur l’internet et comportant un client connecté à l’internet d’un côté et un serveur d’un système d’information connecté à l’internet d’un autre côté, le système d’information mettant à disposition un service, caractérisée en ce que l’infrastructure de sécurité est une infrastructure Darknet comportant : un réseau Darknet en superposition de l’internet pour cacher le service ; un agent client exécuté par le client pour accéder au service à travers le réseau Darknet, l’agent client mémorisant un fichier de configuration client ; un agent serveur exécuté sur le serveur du système d’information pour permettre un accès au service à travers le réseau Darknet, l’agent serveur mémorisant un fichier de configuration serveur ; et, un contrôleur, comportant une base de données stockant des informations de configuration, le contrôleur étant accessible à travers le réseau Darknet par l’agent client, respectivement par l’agent serveur, pour recevoir des informations de configuration client, respectivement serveur, permettant la mise à jour du fichier de configuration client, respectivement serveur, les informations de configuration client comportant au moins un adresse sur le réseau Darknet permettant au client d’accéder au service lorsque le client a effectivement le droit d’accéder au service, et les informations de configuration serveur comportant au moins des informations d’identification permettant au client de s’identifier auprès du serveur pour pouvoir accéder au service.

Suivant des modes particuliers de réalisation, l’infrastructure comporte une ou plusieurs des caractéristiques suivantes, prises isolément ou suivant toutes les combinaisons techniquement possibles :

- un agent parmi l’agent client et l’agent serveur mémorise un jeton permettant une première connexion, via le réseau Darknet, au contrôleur afin de recevoir en retour des données d’authentification, l’agent établissant ensuite une connexion avec le contrôleur en utilisant les données d’authentification.

- l’infrastructure comporte une console d’administration du contrôleur et avantageusement de l’agent serveur, la console d’administration exécutant un agent pour accéder au contrôleur et avantageusement à l’agent serveur à travers le réseau Darknet.

- l’infrastructure est fondée sur une implémentation Tor de l’infrastructure Darknet.

- le réseau Darknet est un réseau privé.

L’invention a également pour objet un procédé de connexion à un service caché mis en œuvre dans une infrastructure de sécurité conforme à l’infrastructure précédentes, consistant à : renseigner un fichier de configuration client de l’agent client et renseigner un fichier de configuration serveur de l’agent serveur par connexion au contrôleur, le fichier de configuration client comportant au moins une adresse sur le réseau Darknet du service, et le fichier de configuration serveur comportant au moins une information d’identification permettant au client de s’identifier auprès du serveur pour pouvoir accéder au service ; rendre par l’agent serveur le service disponible sur le réseau Darknet ; établir par l’agent client une connexion avec un nœud dit « point de rendez-vous » du réseau Darknet (43), en utilisant les informations contenues dans le fichier de configuration client ; demander par l’agent client un accès au service auprès du réseau Darknet en déclarant l’identifiant du nœud « point de rendez-vous » ; vérifier par l’agent serveur d’identité du client sur lequel est exécuté l’agent client en utilisant les informations d’identification contenues dans le fichier de configuration serveur ; et, en cas de vérification positive, établir par l’agent serveur une connexion avec le nœud « point de rendez-vous » du réseau Darknet ; associer les connexions de part et d’autre du nœud « point de rendez-vous » pour établir une communication entre le client et le serveur.

Suivant des modes particuliers de réalisation, le procédé comporte une ou plusieurs des caractéristiques suivantes, prises isolément ou suivant toutes les combinaisons techniquement possibles :

- le procédé consiste en outre à : établir par l’agent serveur une connexion avec le contrôleur ; communiquer par l’agent serveur au contrôleur l’adresse sur le réseau Darknet du service, ladite adresse ayant été générée par l’agent serveur ; établir par l’agent client une connexion avec le contrôleur; communiquer par le contrôleur à l’agent client l’adresse sur le réseau Darknet du service pour renseigner le fichier de configuration client.

- le procédé consiste en outre à : établir par l’agent serveur une connexion avec le contrôleur ; communiquer par le contrôleur à l’agent serveur les droits des utilisateurs sur le service pour renseigner le fichier de configuration serveur.

- pour établir par un agent parmi l’agent client et l’agent serveur une connexion avec le contrôleur, le procédé consiste, en outre, à : recevoir par l’agent un jeton de connexion indiquant une adresse sur le réseau Darknet du contrôleur et un identifiant ; établir par l’agent une connexion au contrôleur en utilisant l’adresse sur le réseau Darknet du contrôleur indiquée dans le jeton et s’identifier par l’agent auprès du contrôleur en utilisant l’identifiant indiqué dans le jeton ; fournir en réponse par le contrôleur à l’agent des données d’authentification ; et établir par l’agent une connexion au contrôleur en utilisant les données d’authentification.

L’invention a également pour objet un produit programme d’ordinateur comportant des instructions logicielles qui, lorsqu’elles sont exécutées par un client, un serveur et un contrôleur d’une infrastructure conforme à l’infrastructure précédente, mettent en œuvre un procédé conforme au procédé précédent.

L’invention et ses avantages seront mieux compris à la lecture de la description détaillée qui va suivre d’un mode de réalisation particulier, donné uniquement à titre d’exemple non limitatif, cette description étant faite en se référant aux dessins annexés sur lesquels :

La est une représentation schématique d’un mode de réalisation préféré d’une infrastructure de sécurité selon l’invention, déployée pour sécuriser une architecture informatique utilisant l’internet ;

La est une représentation sous forme de blocs d’un premier procédé mis en œuvre par l’infrastructure de sécurité de la ;

La est une représentation sous forme de blocs d’un second procédé mis en œuvre par l’infrastructure de sécurité de la ;

La est une représentation sous forme de blocs d’un troisième procédé mis en œuvre par l’infrastructure de sécurité de la ; et,

La est une représentation sous forme de blocs d’un quatrième procédé mis en œuvre par l’infrastructure de sécurité de la .

DEFINITIONS

« Utilisateur » : c’est la personne qui interagit avec un ordinateur connecté au réseau internet, dénommé « ordinateur client » ou « client », pour accéder à un service. Sauf mention contraire, on parlera ci-après indistinctement de client ou d’utilisateur.

« Application client » : c’est un logiciel exécuté par un client et devant accéder à un service pour fonctionner correctement ou offrir une fonctionnalité particulière au client ou à l’utilisateur. Sauf mention contraire, on parlera ci-après indistinctement de client ou d’application client.

« Service » : c’est une fonctionnalité mise à disposition par le système d’information d’une organisation. Ce service est accessible via un serveur connecté (directement ou indirectement par l’intermédiaire d’une passerelle) au réseau internet. Par exemple, le service est un logiciel exécuté par l’ordinateur serveur. Sauf mention contraire, on parlera ci-après indistinctement de service ou de serveur.

« Réseau Darknet » ou « Darknet » : c’est un réseau informatique pair à pair, distribué, superposé (ou réseau « overlay » en anglais) au réseau internet. Il utilise des protocoles spécifiques intégrant des fonctions d'anonymat permettant que les adresses IP des acteurs ne soient pas dévoilées publiquement.

« Infrastructure Darknet » : en plus du réseau Darknet, l’infrastructure Darknet englobe les logiciels (ou agents) exécutés sur les machines pour permettre à celles-ci d’utiliser le réseau Darknet en mettant en œuvre les protocoles adaptés.

« Implémentation Tor » (ou « technologie Tor », ou encore « logiciel Tor ») (acronyme de « The “.onion » Router » ou « le routeur “.onion » » en français) : c’est une implémentation particulière d’une infrastructure Darknet. L’implémentation Tor est un réseau informatique superposé mondial et décentralisé. Il se compose d'un certain nombre de serveurs, appelés nœuds du réseau Darknet et dont la liste est publique. Ce réseau permet d'anonymiser l'origine de connexions TCP. L’implémentation Tor est composée de logiciels libres, qui sont tenus à jour par l’organisation « The Tor Projet », dont le site internet (https://forum.torproject.net) offre différentes informations et met à la disposition de tous les versions des logiciels. Le dernière version stable de l’implémentation Tor est la version 0.4.7.7 du 27 avril 2022. Il est à noter que la présente invention s’appuie sur les fonctionnalités de base de l’implémentation Tor, que l’on retrouve d’une version à l’autre.

Adresse «.onion » : selon l’implémentation Tor, l’accès à un service caché nécessite que l’utilisateur connaisse l’adresse « .onion » de celui-ci. L’adresse « .onion » permet de négocier « un point de rendez-vous » avec l’infrastructure Darknet. Ce point de rendez-vous est un nœud du réseau Darknet utilisé comme intermédiaire de connexion entre l’utilisateur et le service. Personne ne peut négocier de point de rendez-vous avec le service caché sans connaître l’adresse « onion » de ce service. L’adresse « .onion » est générée exclusivement côté service. De plus, l’adresse « onion » d’un service est certes connue du client, mais n’est pas connue des autres machines de l’infrastructure Darknet (en utilisant des mécanismes de « cryptographie en aveugle », un service parvient à se déclarer auprès du Darknet sans avoir à révéler son adresse « .onion ». Dans la mesure où elles sont composées de 56 caractères semi-alphanumériques, il est très difficile de craquer une adresse « onion » par une attaque en force.

« Anonymat » : selon la version en vigueur de l’implémentation Tor, pour ne pas exposer l’adresse IP d’une machine, la connexion créée entre cette machine et le point de rendez-vous n’est pas directe, mais passe par un ou plusieurs nœuds relais du Darknet entre la machine et le point de rendez-vous. Ainsi, la compromission du point de rendez-vous ne permet pas d’obtenir l’adresse IP de la machine, en particulier côté service. De plus, la technologie Tor assure un chiffrement de bout en bout entre machine et point de rendez-vous. Plus précisément, les données qui transitent sont chiffrées autant de fois que le nombre de nœuds relais traversés (chiffrement dit « en oignon»), évitant ainsi que la compromission d’une partie du chemin d’accès au point de rendez-vous ne remette en cause la confidentialité des données qui transitent.

« Principe d’indirection » : il s’agit d’établir indirectement une connexion entre le client et le serveur. selon la version en vigueur de l’implémentation Tor, le client choisit le point de rendez-vous au sein du réseau Darknet, construit une connexion jusqu’à ce point de rendez-vous, puis communique l’identifiant du point de rendez-vous au service via un mécanisme spécifique de la technologie Tor qui n’est pas détaillé ici. Le service vérifie l’identité du client qui cherche à établir une connexion. Dans la technologie Tor, cette vérification est effectuée au moyen de certificats stockés localement côté service. Si le client a le droit d’établir une connexion, alors le service crée une connexion jusqu’au point de rendez-vous choisi par le client. Le service devient ainsi le dernier acteur à établir la connexion. Il passe d’un composant passif (dans TCP/IP, le service accepte une connexion émanant d’un client) à un composant actif (dans une infrastructure Darknet, le service établit la connexion vers le point de rendez-vous). De plus, les points de rendez-vous ne sont jamais les mêmes car choisis aléatoirement par les clients au sein des nœuds du réseau Darknet.

GENERALITES

L’invention consiste à sécuriser une architecture informatique s’appuyant sur internet en déployant une infrastructure Darknet adaptée, de manière à supprimer les points d’exposition des services de manière à les rendre invisibles.

L’infrastructure de sécurité selon l’invention est fondée sur l’emploie du principe d’indirection : les acteurs sensibles de la communication client - serveur n’emploient que des flux sortants. Ces flux convergent vers le réseau Darknet. En particulier, le serveur devient le dernier acteur à décider d’établir ou non une connexion avec un client. Cette décision est prise en fonction d’un certain nombre de critères, notamment les droits d’accès du client.

L’infrastructure de sécurité selon l’invention s’appuie sur le modèle « ZTNA ». Le modèle « ZTNA » (pour « Zero-Trust Network Access » ou « accès réseau zéro confiance ») est un concept de sécurité, notamment applicable aux réseaux informatiques, fondé sur la vérification systématique des droits des utilisateurs, considérant qu’il n’est pas possible de faire confiance à un utilisateur par défaut. De la sorte, la compromission d’une partie de l’architecture ne remet pas en cause la confidentialité des informations échangées entre une application client et un serveur, ne remet pas en cause l’anonymat du service, ni l’intégrité de ce service.

Dans le mode de réalisation préféré décrit ci-dessous en détails, l’infrastructure de sécurité met en œuvre l’implémentation Tor d’une infrastructure Darknet. Cependant, d’autres implémentations d’une infrastructure Darknet pourraient tout aussi bien être utilisées, notamment l’implémentation I2P (« Invisible Internet Project » ou « projet d’internet invisible »).

ARCHITECTURE

En se référant à la , l’infrastructure de sécurité selon l’invention est déployée dans une architecture comportant l’internet 30, un client 10 connecté à l’internet 30 d’un côté, et un système d’information 20 connecté à l’internet d’un autre côté.

Le système d’information 20 comporte un réseau privé 21 connecté à l’internet via une passerelle 22. Le système d’information 20 met à disposition un service 23 à un ensemble d’utilisateurs distants. Le service 23 est par exemple exécuté sur un ordinateur serveur 24. Le service 23 est par exemple une application web.

Le client 10 est un ordinateur (comme un ordinateur personnel, un téléphone mobile, etc.) qui exécute une application 12 ayant besoin d’accéder au service 23 pour que l’utilisateur 1 du client 10 bénéficie pleinement de la fonctionnalité associée à l’exécution de l’application 12. L’application 12 est par exemple un navigateur internet.

L’infrastructure de sécurité (référencée de manière générale par le chiffre 40 sur la ) comporte :

- un réseau Darknet 43 ;

- un agent côté client (ou agent client) 41;

- un agent côté service (ou agent serveur) 42;

- un contrôleur 44 ; et, de préférence,

- une console d’administration 46.

L’infrastructure de sécurité 40 est une infrastructure Darknet, conforme à l’implémentation Tor sauf mention contraire.

Réseau Darknet 43

Le réseau Darknet 43 est un réseau composé d’une pluralité de nœuds en superposition de l’internet 30. Sur la , on a référencé des nœuds par les chiffres 51 et 52, 61, 62 et 63, et 71 et 72.

Le réseau Darknet 43 est avantageusement déployé sur plusieurs réseaux « en nuage » (« cloud » en anglais), gérés par des fournisseurs différents. Ainsi, sur la , on a représenté les nœuds du réseau Darknet 43 comme appartenant à trois réseaux en nuage différents, respectivement 50, 60 et 70. Les fournisseurs sont avantageusement des entités différentes de l’organisation gérant le système d’information 20 ou du prestataire fournissant la présente solution de sécurisation. La distribution du réseau Darknet 43 sur une pluralité de réseaux en nuage permet d’assurer une résilience suffisante, ainsi qu’une couverture géographique étendue (par exemple mondiale).

Sur la , est représenté de manière schématique le système de gestion 45 du réseau Darknet 43. Ceci n’est qu’une représentation, dans la mesure où les fonctions de gestion sont en fait réparties au sein du réseau Darknet 43 lui-même entre les nœuds le composant.

Avantageusement, dans la présente implémentation, le réseau Darknet 43 est privé et non pas public (comme dans l’implémentation Tor). Cela signifie qu’il n’est pas possible d’ajouter un nœud au réseau Darknet 43 sans y être autorisé. Outre certains problèmes de sécurité que cela peut engendrer, l’ajout de nœuds malveillants peut poser des problèmes de performances si la bande passante des nœuds ajoutés n’est pas maîtrisée.

Selon l’implémentation Tor, un nœud candidat se rajoute au réseau en se déclarant auprès de nœuds du réseau Darknet ayant un niveau hiérarchique élevé, aussi dénommés nœuds « autorités ». Pour ce faire, le nœud candidat communique un document de description de routeur (ou « Router Descriptor ») aux nœuds « autorités ». Les nœuds « autorités » incluent les informations contenues dans le document de description de routeur au sein d’un document de consensus, lors d’un vote qui a lieu à intervalle régulier. Le document de consensus est un document public produit régulièrement par le réseau Darknet et qui donne la liste de tous les nœuds qui le composent, ainsi que les informations cryptographiques associées à chacun de ces nœuds. Le document de consensus est notamment utilisé par les processus de l’implémentation Tor pour construire les chemins (aussi dénommé « circuit » dans l’implémentation Tor) jusqu’aux points de rendez-vous, comme cela sera décrit ci-dessous.

Selon l’invention, afin d’éviter que le document de description de routeur d’un nœud non autorisé soit accepté par les nœuds « autorités », un certificat supplémentaire est intégré au sein des documents de description de routeur valides. Ce certificat est signé par une autorité de confiance et chaque nœud « autorité » détient le certificat d’autorité lui permettant de valider le document de description de routeur d’un nœud candidat en vérifiant sa signature. Le nom commun (« Common Name ») du certificat d’autorité d’un nœud candidat spécifie l’adresse IP publique du nœud candidat et permet ainsi aux nœuds « autorités » de vérifier la légitimité du nœud candidat demandant son intégration au réseau Darknet 43. Ainsi, le réseau Darknet 43 a la capacité de refuser les nœuds candidats ne disposant pas d’un certificat valide et signé par l’autorité de confiance.

En cela, le réseau Darknet 43 est une altération de l’implémentation Tor telle que définie par la version actuelle du standard.

Agent client 41

L’agent client 41, qui s’installe et s’exécute sur un ordinateur, comme le client 10 de l’utilisateur 1, permet d’accéder aux services dissimulés par l’infrastructure de sécurité 40.

L’agent client 41 mémorise un fichier de configuration client T.

Le fichier T comporte des données d’authentification du client 10, comme par exemple une clé privée, une clé publique et un certificat associé à la clé publique pour la connexion au contrôleur 44.

Le fichier T mémorise également les adresses « .onion » des services cachés pour lesquels l’utilisateur 1 du client 10 a des droits d’accès.

Avantageusement, le fichier T associe chaque adresse « .onion » d’une part, à une adresse IP et/ou un nom de domaine d’autre part.

L’agent client 41 mémorise avantageusement un jeton J1 pour permettre une première connexion au contrôleur 44.

L’agent client 41 est composé de deux processus.

Le premier processus 411 est un processus Tor. Il s’agit d’un mandataire local (aussi appelé «.Onion Proxy » - OP) en écoute sur la boucle locale. Ce premier processus 411 accepte les connexions depuis le protocole SOCKS. Le premier processus 411 redirige les paquets de données provenant de l’application client 12 vers les services cachés par le réseau Darknet 43. Le protocole SOCKS est un protocole standard, employé dans l’implémentation Tor pour fournir aux applications exécutées sur une machine, une manière standard d’accéder au Darknet. Dans la présente implémentation, au lieu de configurer les applications pour qu’elles utilisent le mandataire SOCKS local de Tor, c’est l’agent qui se charge de négocier une connexion SOCKS avec le mandataire local à chaque fois qu’une connexion avec un service caché est nécessaire.

Ce premier processus 411 est similaire au mandataire local de l’implémentation Tor, mais est avantageusement modifié pour assurer la création de circuits directs vers un point de rendez-vous de façon à supprimer l’anonymat du client. La suppression de l’anonymat des utilisateurs permet à l’administrateur des services cachés de connaître les véritables adresses IP des utilisateurs. Ainsi, la connexion entre l’agent client 41 et le point de rendez-vous est directe et n’emploie aucun nœud relai intermédiaire du réseau Darknet 43. Les services cachés restent quant à eux anonymes. La levée de l’anonymat du client permet également d’augmenter la performance du réseau Darknet, en réduisant les étapes de relai et de chiffrement des flux côté client.

Le second processus 412 est spécifique à la présente infrastructure de sécurité. Il établit et maintient une connexion vers le contrôleur 44, en s’appuyant sur le premier processus 411.

Ce second processus 412 est propre à se connecter au contrôleur 44 pour récupérer tout ou partie des informations du fichier de configuration T.

Lorsqu’il détecte une requête générée par l’application 12, exécutée sur le client 10, à destination d’un nom de domaine ou d’une adresse IP mentionné dans le fichier T, le second processus 412 modifie cette requête en substituant l’adresse « .onion» associée à ce nom de domaine ou à cette adresse IP, et redirige la requête modifiée vers le réseau Darknet et le service caché, via le premier processus 411.

Plus précisément, le second processus 412 intercepte les requêtes DNS de l’application 12 lorsque celles-ci comportent un nom de domaine du fichier T. Le second processus forge une réponses DNS contenant une « fausse » adresse IP associée à ce nom de domaine (cette « fausse » adresse IP est soit indiquée dans le fichier T soit une adresse par défaut attribuée par le second processus). Lorsque le second processus 412 détecte une requête à destination de cette « fausse » adresse IP, il redirige le paquet vers le proxy local Tor avec l’adresse « .onion » correspondante.

Cette fonctionnalité du second processus 412 n’est pas essentielle à l’invention, mais elle permet de rendre la solution proposée plus simple d’emploi pour l’utilisateur, qui ne manipule pas des adresses « .onion » mais des adresses IP ou des noms de domaine, comme il en a l’habitude lorsqu’il utilise l’internet. Mais le processus 412 lui-même est essentiel, notamment pour communiquer avec le contrôleur et recevoir les informations sur les services accessibles.

Agent serveur 42

L’agent serveur 42 s’installe et s’exécute sur une machine du système d’information 20, afin de dissimuler tel ou tel service du système d’information. Par exemple, l’agent serveur 42 est exécuté par le serveur 24 pour dissimuler le service 23. L’agent serveur 42 permet alors de rendre le service accessible à travers l’infrastructure de sécurité 40.

L’agent serveur 42 mémorise un fichier de configuration serveur F.

Le fichier F comporte des données d’authentification du serveur 24, comme par exemple une clé privée, une clé publique et un certificat associé à la clé publique, pour la connexion au contrôleur 44.

La fichier F mémorise également les informations d’identification associées aux utilisateurs pouvant accéder au service 23. Ces informations d’identification comportent de préférence des données d’authentification de chaque client et les droits d’accès associés à ce client.

L’agent serveur 42 mémorise un jeton J2 pour permettre une première connexion au contrôleur 44.

L’agent serveur 42 est composé de deux processus.

Le premier processus 421 est un processus Tor. Il permet de générer les adresses « .onion » des services à dissimuler et de déclarer ces derniers auprès du système de gestion 45 du réseau Darknet 43 pour les rendre accessibles aux utilisateurs autorisés via le Darknet [A VERIFIER : il y a bien communication des adresses « .onion » au Darknet]. Pour ce faire, le premier processus 421 lit le fichier de configuration F détenant ces informations. Tout comme pour l’agent client 41, ce premier processus 421 exécute un mandataire local pour permettre d’accéder au réseau Darknet 43. Ce premier processus 421 est conforme au proxy local selon l’implémentation Tor.

Le second processus 422 est spécifique à la présente invention. Il permet à un administrateur 28 du système d’information 20 de dialoguer avec le premier processus 421 afin de configurer les services. Avantageusement, l’administrateur 28 accède au second processus 422 comme à un service caché du Darknet.

Le second processus 422 permet également d’établir et maintenir une connexion avec le contrôleur 44 pour recevoir des informations permettant de mettre à jour le fichier de configuration F.

Contrôleur 44

Le contrôleur 44 est une machine connectée à l’internet.

Le contrôleur 44 comporte une base de données B. Celle-ci contient les informations permettant de mettre à jour les fichiers de configuration client et serveur. La base de données B référence par exemple les utilisateurs, les services et les droits d’accès de ces services par les utilisateurs.

Le contrôleur 44 agit comme un service caché par le réseau Darknet 43.

Le contrôleur 44 est avantageusement hébergé dans un système d’information différent du système d’information à sécuriser et géré par le fournisseur de cette solution de sécurisation.

Alternativement, il est hébergé directement sur le système d’information de l’organisation qui souhaite utiliser la présente solution de sécurisation afin d’avoir un contrôle optimal de ses données.

Avantageusement, il existe autant de contrôleurs que d’organisations dont on cherche à sécuriser le système d’information afin que les services de ces différentes organisations ne soient pas référencés au sein d’un même contrôleur. Ce partitionnement entre organisations permet d’accroître la sécurité.

Le contrôleur 44 exécute un processus 441 et deux services du type application réseau 442 et 443. Ces deux applications agissent comme des services cachés par le réseau Darknet 43. Ils sont eux-mêmes renseignés au sein du contrôleur 44 et est administrable comme n’importe quel autre service caché.

Le processus 441 est un processus Tor, du type mandataire local. Le processus 441 permet de générer les deux adresses « .onion » des deux services 442 et 443 pour rendre ces services accessibles aux agents distants, clients des services du contrôleur, au travers du réseau Darknet 43.

La première application 442 écoute un premier port sur la boucle locale pour permettre aux agents de se connecter, s’authentifier et recevoir les informations qui les intéressent, comme par exemple, les adresses « .onion » des services ouverts à l’utilisateur pour l’agent client 41, ou les noms de domaine et/ou adresses IP pour l’agent client 41, ou encore les identités des utilisateurs autorisés pour l’agent serveur 42.

De préférence, le contrôleur 44 est administrable au travers de la seconde application 443 qui est une application web accessible via un second port, distinct du premier port. L’administrateur 28 de l’infrastructure de sécurité connaît l’adresse « .onion » lui permettant d’accéder à la seconde application 443 du contrôleur 44 et de gérer les utilisateurs, les services et les droits d’accès associés, c’est-à-dire de mettre à jour le contenu de la base de données B.

Console d’administration 46.

L’administrateur 28 accède au service d’information 20 et au contrôleur 44 au moyen d’une console 46. La console 46 est un client, similaire au client 10 présenté ci-dessus. Il exécute une application 12’ d’administration du système d’information 20 et du contrôleur 44 pouvant se connecter à travers le réseau Darknet 43 en exécutant un agent client 41’ (comportant un premier processus 411’ et un second processus 412’) en utilisant les informations regroupées dans un fichier de configuration T’.

PROCEDES

Procédé de connexion à un service caché

En se référant à la , un procédé de connexion 100 est mis en œuvre pour établir une connexion (par exemple la connexion 101 de la ) entre une application d’un client enregistré, comme l’application 12 du client 10, et un service caché, comme le service 23 du serveur 24.

Etape 110 : lorsqu'un utilisateur 1 cherche à utiliser un service caché 23, l’agent client 41 lit le fichier de configuration client T pour extraire l’adresse « .onion » du service auquel il veut accéder. Il établit une connexion avec un point de rendez-vous du Darknet, par exemple le nœud 61. Pour ce faire, l’agent client 41 choisit arbitrairement ce nœud parmi la liste des nœuds qui composent le réseau Darknet 43, cette liste étant publiquement disponible par exemple en interrogeant le système de gestion 45. L’agent client 41 établit ensuite une connexion avec le nœud de rendez-vous choisi. Dans la présente implémentation, cette connexion est avantageusement directe. C’est à dire qu’il n’existe aucun nœud relai du réseau Darknet 43 entre le client 10 et le point de rendez-vous choisi et ce pour permettre de casser l’anonymat du client 10.

Etape 120 : une fois la connexion au réseau Darknet établie, l’agent client 41 demande un accès au service 24 et déclare son point de rendez-vous auprès du système de gestion 45, qui se charge de communiquer à l’agent serveur 42 associé au service demandé, la demande de connexion de la part de l’agent client 41 et l’emplacement du point de rendez-vous choisi. Ce processus, spécifique à l’implémentation Tor n’est pas décrit plus en détails ici.

Etape 130 : lors de la réception d’une demande de connexion au service 23, l’agent serveur 42 vérifie l’identité du client 10 en consultant le fichier de configuration serveur F.

Etape 140 : après vérification positive de l’identité du client ayant initié une demande de connexion, l’agent serveur 42 initie une connexion TCP auprès d’un premier nœud du réseau Darknet, par exemple le nœud 52. Puis l'agent serveur 42 étend la connexion préalablement établie en indiquant au premier nœud relai 52 du circuit d’établir une connexion TCP vers un second nœud relai, choisi par le premier nœud relai, par exemple le nœud 71. Enfin, l’agent serveur 42 étend la connexion une fois de plus, jusqu’au point de rendez-vous 61. En variante, le circuit entre le système d’information 20 et le point de rendez-vous peut avoir un autre nombre de sauts (au moins deux pour masquer l’IP du serveur 24).

Etape 150 : les connexions de part et d’autre du point de rendez-vous sont associées par le point de rendez-vous pour permettre à l’agent client 41 et à l’agent serveur 42 d’établir un tunnel sécurisé, et de permettre à l’application 12 exécutée sur le client 10 et au service 23 exécutée par le serveur 24 de communiquer. Le client 10 ne connaît pas l’adresse IP effective du service 23, tandis que le service 23 connaît celle du client qui lui est transmise par le point de rendez-vous.

On constate que le service étant le dernier à établir la connexion, il choisit si oui, ou non, il doit procéder à l’établissement de la connexion jusqu’au point de rendez-vous en fonction de l’identité de l’utilisateur : c’est le principe d’indirection.

Procédé de mise à jour des droits d’un utilisateur et communication de l’adresse d’un service caché

En se référant à la , les étapes du procédé 200 sont avantageusement mises en œuvre pour renseigner les fichiers de configuration client T et serveur F.

Dans une étape 210, l'administrateur 28 se connecte au contrôleur 44 des identités et des accès. Il ajoute à la base de données B un droit au client 10 de l’utilisateur 1 pour permettre l’accès au service caché 23. Pour ce faire, la console 46 en tant que client et le contrôleur 44 en tant que serveur d’un service caché réalisent les étapes du procédé de connexion 100 pour établir la liaison 401. Une fois cette connexion établie, la seconde application 443 permet à l’administrateur d’avoir la main sur la base de données B.

Dans une étape 220, le contrôleur 44 communique l’identité de l’utilisateur et ses droits à l’agent serveur 42. Cette étape est par exemple exécutée sur requête de l’agent serveur 42 lorsqu’il doit vérifier une demande de connexion (étape 130 du procédé 100). Ainsi, l’agent serveur 42 sait qu’il peut autoriser l’établissement d’une connexion jusqu’au point de rendez-vous pour répondre à une demande de connexion du client 10. La communication de cette information est réalisée au moyen d’une connexion 301 à travers le Darknet préalablement établie et maintenu entre l’agent serveur 42, en tant que client, et la première application 442, du contrôleur 44 (circuit 301 sur la ).

Dans une étape 230, le contrôleur 44 communique l’adresse « .onion » du service 23 à l’agent client 41. Cette communication est réalisée via un tunnel sécurisé préalablement établi et maintenu entre l’agent client 10 de l’utilisateur 1, en tant que client, et la première application 442 du contrôleur, en tant que service caché (circuit 201 de la ).

Une fois qu’il dispose de l’adresse « .onion » du service 23 cible, le client 10 peut alors établir un tunnel sécurisé jusqu’à ce service et l’agent serveur 42 peut vérifier l’identité du client et établir la connexion jusqu’au point de rendez-vous conformément au procédé 100.

Procédé d’a uthentification d’un client auprès d’un agent serveur

Afin de s’assurer que la seule connaissance d’une adresse « .onion » ne soit pas suffisante pour réaliser une connexion avec un service caché, on prévoit avantageusement la mise en œuvre des étapes du procédé 300 pour permettre l’authentification d’un client 10 par l’agent serveur 42 associé au service 23 (étape 130 du procédé 100).

Ce procédé élémentaire 300 est illustré par la .

Dans une étape 310, l’agent serveur 42 rend disponible le service 23 sur le Darknet 43, en générant une adresse « .onion » pour le service 23, et enregistre le service 23 auprès du système 45 du réseau Darknet 43. Cette fonctionnalité est native à l’implémentation Tor selon la version en vigueur et n’est pas modifiée ici.

Dans une étape 320, l’agent serveur 42 établit et maintient une connexion 301 à travers le réseau Darknet 43 avec la première application 442 du contrôleur 44 des accès et identités.

Dans l’étape 330, l’agent serveur 42 communique également au contrôleur 44 l’adresse « .onion » qu’il a générée pour le service 23.

Dans l’étape 340, le contrôleur 44 communique à l’agent serveur 42 l’ensemble des identités des utilisateurs ayant le droit d’établir une connexion avec le service 23 (ceci correspond à l’étape 220 du procédé de la ). A chaque modification de droit dans la base de données B, le contrôleur 44 avertit l’agent serveur 42.

Dans une étape 350, lors d’une tentative de connexion de la part de l’agent client 41, l’agent serveur 42 vérifie que le client 10 détient effectivement le droit de se connecter. Si oui, il établit une connexion vers le point de rendez-vous choisi par ce dernier, en suivant le principe d’indirection (étape 140 du procédé de la ).

Il est à souligner que l’étape 330 permet de centraliser les adresses « .onion » des services d’une organisation donnée au sein de la base de données B mémorisée par le contrôleur 44. Le contrôleur 44 référence ainsi les utilisateurs de l’organisation, les services et les droits d’accès. Cela permet au contrôleur 44 d’indiquer aux clients les adresses « .onion » des services accessibles, comme cela est décrit en référence à la . Au contraire, dans l’implémentation Tor selon la version en vigueur, les adresses « .onion » sont considérées comme des informations hors du cadre du standard, qu’il est de la responsabilité des administrateurs de services de communiquer à leurs utilisateurs.

Première connexion par jeton

Etant donné que les agents client 41 et serveur 43 ont besoin de connaître l’adresse « .onion » de la première application 442 du contrôleur 44, ils doivent détenir certaines informations de configuration initiale, comme un certificat, une clé et l’adresse « .onion » du contrôleur 44.

Afin de faciliter le dépôt de ces informations de configuration initiale sur la machine sur laquelle l’agent est exécuté, l’agent peut avantageusement récupérer ces informations directement auprès du contrôleur 44 en mettant en œuvre les étapes du procédé 400 de la .

Dans une étape 410, l’utilisateur (respectivement l’administrateur du service à cacher) reçoit un jeton d’initialisation. Celui-ci est par exemple composé de l’adresse « .onion »du contrôleur 44 et d’un identifiant unique. Ce couple d’informations est par exemple généré par le contrôleur 44 sur demande de l’administrateur 28. Ce couple d’informations est communiqué à l’utilisateur 1 (ou à l’administrateur du service à cacher) par un moyen de communication annexe avec le niveau de sécurité adapté, par exemple par la transmission d’un courrier électronique crypté comportant le jeton.

Dans une étape 420, au moyen de ce jeton, l’agent client 41 (respectivement l’agent serveur 42) se connecte au contrôleur 44. Il lit l’adresse « .onion » du contrôleur 4 indiquée par le jeton, se connecte au contrôleur 44 et transmet au contrôleur 44 l’identifiant unique indiqué par le jeton.

En retour, dans une étape 430, le contrôleur 44 génère un certificat et une clé et transmet ces données d’authentification à l’agent client (ou à l’agent serveur). Le jeton est alors « consommé » (invalidé) par le contrôleur 44. Un jeton n’est valide que pendant une durée limitée et n’est utilisable qu’une seule fois pour garantir la sécurité.

Par la suite, dans une étape 440, grâce à ces informations de configuration, qui sont mémorisées dans le fichier T (respectivement dans le fichier F), l’agent client 41 (respectivement l’agent serveur 42) a la possibilité d’établir une nouvelle connexion avec le contrôleur 44 et de s’authentifier auprès du contrôleur 44 en utilisant les informations du fichier T (respectivement dans le fichier F). De préférence, un agent maintient cette connexion avec le contrôleur.

Dans une étape 450, l’agent client 41 récupère des informations de configuration générales comme les adresses « .onion » des services cachés qui lui sont ouverts. Il stocke ces informations dans le fichier T. L’agent serveur 42 récupère les informations de configuration générales comme l’identification de chaque utilisateurs. Il stocke ces informations dans le fichier F.

Enfin, dans une étape 460, le client 10 accède au service caché désiré en utilisant son adresse « .onion », en négociant un point de rendez-vous avec le réseau Darknet, puis en établissant une connexion avec le service caché via le processus usuel de l’implémentation Tor (mise en œuvre du procédé 100).

Avec le procédé 400, les agents client et serveur connaissent l’adresse « .onion » du contrôleur 44.

À tout moment, dès qu’une modification est réalisée sur des droits d’accès dans la base de données B, le contrôleur 44 indique cette modification aux clients concernés : une nouvelle adresse « .onion » est disponible, qu’une adresse « .onion » doit être invalidée, un utilisateur a droit d’accéder à tout ou partie d’un service caché ou au contraire n’a plus le droit d’accéder à tout ou partie d’un service caché.

AVANTAGES

L’invention porte donc sur une infrastructure fondée sur un réseau Darknet privé permettant de supprimer l’exposition des services sur internet.

L’implémentation Tor d’une infrastructure Darknet est modifiée, notamment pour supprimer l’anonymat des utilisateurs, tout en gardant celui des services cachés. Elle est également modifiée pour Rendre le réseau darknet privé, c’est-à-dire empêcher d’autres acteurs que l’administrateur d’y ajouter des machines.

Les agents client permettent avantageusement aux utilisateurs d’accéder aux services cachés comme s’ils accédaient à des services exposés sur internet.

L’infrastructure proposée présente les propriétés suivantes :

- Il est techniquement impossible pour quiconque ayant accès à une partie ou à l’intégralité des machines de l’infrastructure d’établir une connexion avec les services cachés sans détenir les droits sur ces machines spécifiés dans la base de données de management de l’organisation.

- Il est impossible de déterminer les adresses IP publiques des services cachés.

- La console d’administration n’est plus exposée sur l’Internet et utilise elle-même l’infrastructure pour se dissimuler.

Ces propriétés font que l’infrastructure est une infrastructure respectant le modèle ZTNA.

Claims (10)

1. Infrastructure de sécurité destinée à être déployée dans une architecture s’appuyant sur l’internet et comportant un client (10) connecté à l’internet (30) d’un côté et un serveur (24) d’un système d’information (20) connecté à l’internet d’un autre côté, le système d’information (20) mettant à disposition un service (23),
   caractérisée en ce que l’infrastructure de sécurité est une infrastructure Darknet comportant :
   - un réseau Darknet (43) en superposition de l’internet (30) pour cacher le service (23) ;
   - un agent client (41) exécuté par le client (10) pour accéder au service (23) à travers le réseau Darknet (43), l’agent client mémorisant un fichier de configuration client (T) ;
   - un agent serveur (42) exécuté sur le serveur (24) du système d’information (20) pour permettre un accès au service (23) à travers le réseau Darknet (43), l’agent serveur mémorisant un fichier de configuration serveur (F) ; et,
   - un contrôleur (44), comportant une base de données (B) stockant des informations de configuration, le contrôleur étant accessible à travers le réseau Darknet (43) par l’agent client (41), respectivement par l’agent serveur (42), pour recevoir des informations de configuration client, respectivement serveur, permettant la mise à jour du fichier de configuration client, respectivement serveur,
   les informations de configuration client comportant au moins un adresse sur le réseau Darknet permettant au client d’accéder au service (23) lorsque le client a effectivement le droit d’accéder au service, et les informations de configuration serveur comportant au moins des informations d’identification permettant au client de s’identifier auprès du serveur pour pouvoir accéder au service (23).
2. Infrastructure selon la revendication 1, dans laquelle un agent parmi l’agent client et l’agent serveur mémorise un jeton (J1, J2) permettant une première connexion, via le réseau Darknet (23), au contrôleur (44) afin de recevoir en retour des données d’authentification, l’agent établissant ensuite une connexion avec le contrôleur en utilisant les données d’authentification.
3. Infrastructure selon l’une quelconque des revendications 1 à 2, comportant une console d’administration (46) du contrôleur (44) et avantageusement de l’agent serveur (42), la console d’administration exécutant un agent pour accéder au contrôleur et avantageusement à l’agent serveur à travers le réseau Darknet (43).
4. Infrastructure selon l’une quelconque des revendications précédentes, fondée sur une implémentation Tor de l’infrastructure Darknet.
5. Infrastructure selon l’une quelconque des revendications précédentes, dans laquelle le réseau Darknet est un réseau privé.
6. Procédé de connexion à un service caché mis en œuvre dans une infrastructure de sécurité selon l’une quelconque des revendications 1 à 5, consistant à :
   - renseigner (230) un fichier de configuration client (T) de l’agent client et renseigner (220) un fichier de configuration serveur (F) de l’agent serveur par connexion au contrôleur (44), le fichier de configuration client comportant au moins une adresse sur le réseau Darknet du service (23), et le fichier de configuration serveur comportant au moins une information d’identification permettant au client de s’identifier auprès du serveur pour pouvoir accéder au service (23) ;
   - rendre par l’agent serveur (42) le service disponible sur le réseau Darknet (43) ;
   - établir (110) par l’agent client (41) une connexion avec un nœud dit « point de rendez-vous » du réseau Darknet (43), en utilisant les informations contenues dans le fichier de configuration client ;
   - demander (120) par l’agent client (41) un accès au service (23) auprès du réseau Darknet (43) en déclarant l’identifiant du nœud « point de rendez-vous » ;
   - vérifier (130) par l’agent serveur (42) d’identité du client (10) sur lequel est exécuté l’agent client (41) en utilisant les informations d’identification contenues dans le fichier de configuration serveur ; et, en cas de vérification positive,
   - établir (140) par l’agent serveur (42) une connexion avec le nœud « point de rendez-vous » du réseau Darknet (43) ;
   - associer (150) les connexions de part et d’autre du nœud « point de rendez-vous » pour établir une communication (101) entre le client et le serveur.
7. Procédé selon la revendication 6, dans lequel, le procédé consiste en outre à :
   - établir (320) par l’agent serveur (42) une connexion avec le contrôleur (44) ;
   - communiquer (330) par l’agent serveur (42) au contrôleur (44) l’adresse sur le réseau Darknet du service (23), ladite adresse ayant été générée par l’agent serveur ;
   - établir par l’agent client (41) une connexion avec le contrôleur (44) ;
   - communiquer par le contrôleur à l’agent client l’adresse sur le réseau Darknet du service (23) pour renseigner le fichier de configuration client.
8. Procédé selon la revendication 6 ou la revendication 7, dans lequel le procédé consiste en outre à :
   - établir (320) par l’agent serveur (42) une connexion avec le contrôleur (44) ;
   - communiquer (340) par le contrôleur à l’agent serveur les droits des utilisateurs sur le service (23) pour renseigner le fichier de configuration serveur.
9. Procédé selon l’une quelconque des revendications 6 à 8, dans lequel, pour établir par un agent parmi l’agent client et l’agent serveur une connexion avec le contrôleur (44), le procédé consiste, en outre, à :
   - recevoir (410) par l’agent un jeton de connexion indiquant une adresse sur le réseau Darknet du contrôleur et un identifiant ;
   - établir (420) par l’agent une connexion au contrôleur en utilisant l’adresse sur le réseau Darknet du contrôleur indiquée dans le jeton et s’identifier par l’agent auprès du contrôleur en utilisant l’identifiant indiqué dans le jeton ;
   - fournir (430) en réponse par le contrôleur à l’agent des données d’authentification ; et
   - établir (440) par l’agent une connexion au contrôleur en utilisant les données d’authentification.
10. Produit programme d’ordinateur comportant des instructions logicielles qui, lorsqu’elles sont exécutées par un client (10), un serveur (24) et un contrôleur (44) d’une infrastructure selon l’une quelconque des revendications 1 à 5, mettent en œuvre un procédé selon l’une quelconque des revendications 6 à 9.