FR 3152690 A1 20250307 FR 2309050 A 20230829 L’invention concerne un procédé d’interception, par un module d’analyse, d’un flux de communication à destination d’une application exécutée dans un conteneur sur un environnement hôte comprenant un système d’exploitation, le procédé comprenant une étape (301) de configuration au cours de laquelle on associe un ensemble d’instructions de code à un point d’exécution particulier d’un appel système de transfert de données, et une étape d’exécution (303) dudit ensemble d’instructions dans l’espace du noyau du système d’exploitation de l’environnement hôte lorsqu’un appel système déclenché depuis l’au moins un conteneur atteint (302) le point d’exécution, l’exécution dudit ensemble d’instruction comprenant au moins la recopie (304) du contenu d’une zone mémoire de l’espace noyau modifiée par l’appel système vers une zone mémoire de l’espace utilisateur. Figure 3. Procédé d’interception d’un flux de communication chiffré L’invention appartient au domaine des communications et concerne plus particulièrement un procédé pour intercepter un flux de communication chiffré dans un environnement d’exécution virtualisé basé sur des conteneurs. Art antérieur Les réseaux de communication modernes s’appuient de plus en plus souvent sur des mécanismes de virtualisation. La virtualisation permet de faire fonctionner plusieurs systèmes ou applications sur un même système physique en définissant des environnements d’exécution isolés les uns des autres appelés conteneurs. La virtualisation peut être complète ou partielle. En cas de virtualisation complète, les applications s’exécutent sur des machines virtuelles dont les interfaces d’entrée/sorties sont des abstractions des interfaces physiques correspondantes fournies par un hyperviseur. Autrement dit, la machine hôte émule une machine sur laquelle s’exécute un système d’exploitation complet et les applications souhaitées. Les applications s’exécutent alors dans un environnement complet, qui peut être d’un type différent de celui du système hôte. En cas de virtualisation partielle, seules les ressources nécessaires à son l’exécution sont mises à disposition d’une application. On parle alors de conteneurisation. Ce mode de virtualisation nécessite généralement moins de ressources que la virtualisation complète, car les applications s’exécutant dans les conteneurs utilisent l'interface d'appel système native du système d'exploitation. Aucune émulation n’est alors nécessaire. La virtualisation apporte une grande souplesse et une flexibilité particulièrement appréciée dans le domaine des plateformes de service et des réseaux. Les réseaux de communication 5G s’appuient par exemple sur la virtualisation des fonctions réseaux VNF (pour Virtual Network Function en anglais, par exemple Pare-feu, DNS, NAT, Authentification...), permettant ainsi de décorréler une fonction réseau de l’équipement physique qui lui correspond ou de définir des tranches réseau (Network slices). La nature isolée des conteneurs limite toutefois les possibilités d’analyse et d’introspection des systèmes virtualisés. Par exemple, il peut être fastidieux, voire impossible pour un opérateur d’un réseau de communication virtualisé de déployer des sondes dans les différents conteneurs qui implémentent les fonctions réseaux. Par exemple, les fonctions réseaux peuvent être fournies par différents fournisseurs sous la forme de « boites noires » sans possibilité d’instrumentation. Dans une telle situation, l’opérateur du réseau virtualisé peut rencontrer des difficultés pour sécuriser et surveiller son réseau. En particulier, l’opérateur peut rencontrer des difficultés pour accéder au contenu des communications chiffrées échangées par les fonctions réseaux, par exemple au contenu de messages de signalisation, pouvant conduire à des problèmes de sécurité ou de qualité de service. Il existe par conséquent un besoin pour une solution permettant d’intercepter des communications chiffrées à destination d’applications exécutées dans des conteneurs sans qu’il soit nécessaire d’intervenir sur les conteneurs eux-mêmes. A cet effet, selon un premier aspect de l’invention, il est proposé un procédé d’interception, par un module d’analyse, d’un flux de communication à destination d’une application exécutée dans un conteneur sur un environnement hôte comprenant un système d’exploitation, le procédé comprenant les étapes suivantes : Une étape de configuration au cours de laquelle un ensemble d’instructions de code est associé à un point d’exécution particulier d’un appel système de transfert de données, Une étape d’exécution dudit ensemble d’instructions dans l’espace du noyau du système d’exploitation de l’environnement hôte lorsqu’un appel système de transfert de données déclenché depuis l’au moins un conteneur atteint le point d’exécution, l’exécution dudit ensemble d’instruction comprenant au moins la recopie du contenu d’une zone mémoire de l’espace noyau modifiée par l’appel système vers une zone mémoire de l’espace utilisateur. Des instructions de programme sont ainsi injectées dans le noyau de système d’exploitation hôte afin d’être exécutées dans l’espace du noyau lors de l’exécution d’un appel système. Ainsi, lorsqu’une application s’exécutant dans un conteneur particulier effectue un appel au système d’exploitation hôte pour recevoir ou transmettre des données, les instructions de programme injectées sont exécutées lorsque que le point d’exécution particulier auquel elles sont associées est atteint. Parce que les instructions de code sont exécutées dans le noyau, il est possible d’accéder à la mémoire tampon utilisée par le système d’exploitation pour la réception ou la transmission de données réseau, sans qu’il soit nécessaire d’agir sur les conteneurs destinataires ou à l’origine de ces communications. Il n’est plus nécessaire d’installer des sondes dans les conteneurs pour observer le trafic chiffré. De cette façon, un module d’analyse s’exécutant sur la machine hôte peut accéder aux messages destinés aux applications s’exécutant dans des conteneurs, sans qu’il soit nécessaire de les modifier. Selon une réalisation particulière, le procédé comprend une étape préalable de détermination qu’une fonction de déchiffrement des communications est réalisée par le noyau, l’exécution de l’ensemble d’instructions de code étant conditionné au résultat de ladite étape de détermination, la zone mémoire de l’espace noyau modifiée comprenant des données déchiffrées par le noyau. De cette façon, l’instrumentation de l’appel système n’est réalisé que si cela est nécessaire, par exemple lorsque le noyau met en œuvre les fonctions de chiffrement et déchiffrement. Par exemple, un noyau Linux peut être configuré pour mettre en œuvre le protocole TLS afin de limiter les copies mémoire et améliorer les performances. Lorsqu’une telle configuration est déterminée, les appels systèmes relatifs à la réception de données chiffrées peuvent être instrumentées par des instructions de code adaptées pour accéder aux données déchiffrées depuis le noyau. Selon un mode particulier de réalisation, le procédé comprend en outre une étape de détection d’une attaque à partir des données interceptées. Dans un mode de réalisation particulier, le procédé est tel que l’étape de configuration comprend l’association d’un premier ensemble d’instructions de code à un premier point d’exécution dans l’espace du noyau du système d’exploitation et d’un deuxième ensemble d’instructions de code à un deuxième point d’exécution dans l’espace du noyau du système d’exploitation, le premier point d’exécution étant un point d’entrée de l’appel système et le deuxième point d’exécution étant un point de sortie dudit appel système, le premier ensemble d’instructions de code étant configuré pour obtenir une adresse d’une mémoire tampon dans l’espace du noyau et mémoriser cette adresse dans une structure de données mémorisée dans l’espace noyau, le deuxième ensemble d’instructions étant configuré pour obtenir l’adresse mémorisée et copier des données depuis un emplacement pointé par ladite adresse vers une mémoire tampon accessible depuis l’espace utilisateur. Selon un autre aspect, l’invention concerne un dispositif d’interception d’un flux de communication à destination d’une application exécutée dans un conteneur sur un environnement hôte comprenant un système d’exploitation, le dispositif comprenant un processeur couplé à une mémoire dans laquelle sont enregistrées des instructions de programme d’ordinateur configurées pour mettre en œuvre les étapes suivantes : Une étape de configuration au cours de laquelle un ensemble d’instructions de code est associé à un point d’exécution particulier d’un appel système de transfert de données, Une étape d’exécution dudit ensemble d’instructions dans l’espace du noyau du système d’exploitation de l’environnement hôte lorsqu’un appel système de transfert de données déclenché depuis l’au moins un conteneur atteint le point d’exécution, l’exécution dudit ensemble d’instruction comprenant au moins la recopie du contenu d’une zone mémoire de l’espace noyau modifiée par l’appel système vers une zone mémoire de l’espace utilisateur. L’invention concerne aussi un serveur comprenant un dispositif d’interception tel que décrit ci-dessus. Dans un mode particulier de réalisation, les différentes étapes du procédé d’interception sont déterminées par des instructions de programmes d’ordinateurs. En conséquence, l’invention vise aussi un programme d’ordinateur comportant des instructions adaptées à la mise en œuvre des étapes d'un procédé d’interception tel que décrit ci-dessus, lorsque le programme est exécuté par un processeur. Ce programme 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. L’invention vise aussi un support d’information lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes d'un procédé d’interception tel que décrit ci-dessus. Le support d'informations peut être n'importe quelle entité ou 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, une mémoire flash, ou encore un moyen d'enregistrement magnétique, comme 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é via 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 de type Internet. 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. Les différents modes ou caractéristiques de réalisation précités peuvent être ajoutés indépendamment ou en combinaison les uns avec les autres, aux étapes du procédé d’interception. Les dispositifs, serveurs, programmes et supports d’information présentent des avantages analogues à ceux du procédé auquel ils correspondent. Brève description des figures D'autres caractéristiques et avantages apparaîtront à la lecture d’un mode de réalisation préféré décrit en référence aux dessins annexés parmi lesquels : La FIG. 1 est un diagramme représentant une architecture dans laquelle des fonctions cryptographiques sont mises en œuvre dans l’espace utilisateur d’un système hôte, La FIG. 2 est un diagramme représentant une architecture dans laquelle des fonctions cryptographiques sont mises en œuvre dans l’espace noyau d’un système hôte, La FIG. 3 est un ordinogramme montrant les principales étapes d’un procédé d’interception selon un mode particulier de réalisation, et La FIG. 4 illustre une architecture d’un dispositif adapté pour mettre en œuvre un procédé d’interception selon une réalisation particulière. Description détaillée TLS est un protocole de communication largement répandu pour sécuriser les communications numériques. Par exemple, TLS est utilisé pour sécuriser les connexions à un serveur http ou chiffrer des contenus vidéo à la demande, mais aussi pour le chiffrement des données de signalisation réseau, par exemple pour sécuriser le trafic de contrôle entre les entités implémentant les différentes fonctions d’un réseau 5G. De manière classique, le protocole TLS peut être implémenté dans une application sous la forme d’une librairie. On connaît pour cela des librairies open-source, par exemple openssl. Dans un tel cas de figure, une application s’exécutent dans un conteneur d’un environnement hôte utilise les services d’une librairie pour chiffrer et déchiffrer le trafic dans l’espace utilisateur. Dans la description qui suit, l’espace utilisateur fait référence à un espace d’adressage mémoire utilisé pour stocker et exécuter les programmes utilisateurs. Cet espace d’adressage mémoire est distinct de l’espace noyau, qui est utilisé pour stocker le code et les données du système d’exploitation. L’espace utilisateur fournit un environnement isolé qui protège le système contre des programmes malveillants. Ainsi, les possibilités d’accès à la mémoire sont limitées dans l’espace utilisateur, ainsi que les instructions autorisées. La FIG. 1 illustre une implémentation d’un système de chiffrement des communications utilisant une librairie. Une application 100 s’exécute dans un conteneur 101 d’un environnement hôte 102. L’application 100 utilise les services d’une librairie TLS 103 dans l’espace utilisateur pour établir la connexion TLS, réaliser l’authentification et chiffrer/déchiffrer les données. Ainsi, pour transmettre des données chiffrées vers un destinataire, l’application 100 chiffre un paquet de données à l’aide de la librairie TLS 103 et effectue un appel système 104 pour commander au noyau l’envoi des données chiffrées. Le noyau utilise une pile protocolaire 105 pour transmettre les données. Dans une telle configuration, les données transitant entre l’espace utilisateur et l’espace noyau via les appels systèmes sont chiffrées. La FIG. 2 illustre un deuxième mode d’implémentation du protocole TLS. Dans ce deuxième mode, la mise en œuvre du protocole TLS est partagée entre d’une part l’application 100 qui utilise une librairie TLS 103 uniquement pour l’établissement de la communication et d’autre part le noyau qui utilise un module KTLS 106 dédié au chiffrement/déchiffrement des communications ainsi qu’à l’authentification. Dans cette deuxième configuration, les données qui transitent entre l’espace utilisateur et l’espace noyau via les appels systèmes ne sont pas chiffrées. La FIG. 3 est un ordinogramme illustrant les principales étapes d’un procédé d’interception mis en œuvre, selon une réalisation particulière, par un module d’analyse dans un environnement d’exécution hôte sur lequel s’exécute au moins une application dans un conteneur. Le procédé comprend une première étape optionnelle 300 au cours de laquelle l’environnement est testé afin de déterminer si des fonctions cryptographiques nécessaires à l’établissement de communications sécurisées sont mises en œuvre dans le noyau du système d’exploitation hôte ou bien si ces fonctions sont mises en œuvre dans l’espace utilisateur. Pour cela, selon un mode de réalisation particulier, le module d’analyse instrumente un appel système destiné à configurer les fonctions réseau utilisées par les applications s’exécutant dans un ou plusieurs conteneurs afin d’identifier les applications qui sollicitent l’utilisation de fonctions cryptographiques dans le noyau. Plus précisément, le module d’analyse associe une séquence d’instructions particulières à un point d’exécution particulier d’un appel système destiné à configurer l’accès aux couches de communications réseau du système d’exploitation de l’environnement hôte. Cette séquence d’instructions est configurée pour mémoriser dans une structure de données du noyau des identifiants de processus, des identifiants de points d’accès aux services de transport réseau et la configuration demandée par l’application, en particulier la configuration relative à l’utilisation ou non de fonctions cryptographiques fournies par le noyau. Par exemple, sur un système hôte de type Posix, l’étape 300 peut instrumenter l’appel système « setsockopt » pour que la séquence d’instructions soit exécutée à chaque fois qu’une application s’exécutant dans un conteneur configure un accès réseau. Les instructions de la séquence associée à l’appel système comprennent notamment un test permettant de déterminer si l’application cherche à configurer l’utilisation de fonctions cryptographiques dans le noyau, par exemple en déterminant si l’option TLS_RX est demandée par l’application. Si tel est le cas, les instructions sont configurées pour mémoriser l’identifiant du processus (pid, pour process identifier dans un système Posix) en association avec l’identifiant de la socket concernée. Cette association est mémorisée dans une structure de données dans noyau. L’instrumentation des appels système peut être réalisée de différentes manières. Par exemple, il est possible d’utiliser une machine virtuelle BPF (pour Berkley Packet Filter en anglais) ou eBPF (pour Extended BPF). eBPF est une technologie du noyau Linux qui permet aux programmes d'être exécutés dans l’espace noyau sans devoir modifier le code source du noyau ni ajouter de modules supplémentaires. Il s'agit d'une machine virtuelle possédant un nombre limité d’instructions, sur laquelle les développeurs peuvent exécuter un programme utilisant des ressources spécifiques du noyau. Lorsqu’il est déterminé, à l’issue de l’étape 300, que les fonctions cryptographiques nécessaires à l’établissement de communications sécurisées sont mises en œuvre dans le noyau, le module d’analyse met en œuvre une étape 301 au cours de laquelle au moins un ensemble d’instructions de programme est associé à un point d’exécution d’appel système relatif à un transfert de données réseau. Plus précisément, des instructions particulières sont injectées dans le noyau du système d’exploitation, par exemple au moyen d’une technologie eBPF, et une ou plusieurs fonctions systèmes de réception et/ou d’envoie de données sur un réseau sont instrumentées de sorte que les instructions injectées sont exécutées lorsque lesdites fonctions systèmes sont appelées par une application s’exécutant dans l’espace utilisateur. Par exemple, sur un système de type Posix, les fonctions sendmsg, sendto, recvmsg et/ou recvfrom peuvent être instrumentées de la sorte, de manière que chaque appel à l’une de ces fonctions par une application déclenche l’exécution d’une séquence d’instructions injectées dans le noyau par le module d’analyse. A l’étape 302, un appel système instrumenté lors de l’étape 301 est invoqué par une application s’exécutant dans un conteneur sur la machine hôte. Il s’agit par exemple d’un appel système destiné à recevoir des données transmises par un dispositif à destination de l’application, par exemple des données de signalisation. Lorsque l’appel système atteint un point d’exécution particulier auquel a été associé une séquence d’instructions lors de l’étape de configuration 301, le procédé d’interception comprend une étape 303 au cours de laquelle la séquence d’instructions est exécutée dans l’espace noyau. Lorsque l’appel système invoqué à l’étape 302 concerne la réception de données chiffrées, l’étape d’exécution 303 comprend une sous étape 304 d’accès à une zone mémoire du noyau du système d’exploitation dans laquelle sont mémorisées temporairement les données qui ont été reçues par l’interface réseau et déchiffrées par les fonctions cryptographiques du noyau, et de recopie du contenu de cette zone mémoire vers une autre zone mémoire, par exemple une mémoire tampon circulaire allouée dans l’espace utilisateur. Lorsque l’appel système invoqué concerne l’envoi de données vers un dispositif, l’étape 304 est une étape d’accès à une zone mémoire du noyau du système d’exploitation dans laquelle sont mémorisée temporairement les données que l’application en question souhaite envoyer, avant que celles-ci aient soit transformées par les fonctions cryptographiques du noyau, et de recopie du contenu de cette zone mémoire vers une autre zone mémoire, par exemple une mémoire tampon circulaire allouée dans l’espace utilisateur. Dans un mode particulier de réalisation, l’accès à la zone mémoire du noyau contenant les données non chiffrées est réalisé en deux temps. Dans un tel cas, une première séquence d’instructions est injectée dans le noyau et associée à l’entrée d’un appel système de réception ou de transmission réseau, et une deuxième séquence d’instructions est associée à la sortie de l’appel système. Autrement dit, un premier « hook » est configuré à un point d’exécution localisé au début de l’appel système instrumenté, c’est-à-dire après que l’appel système soit invoqué par l’application mais avant qu’il ne soit effectivement exécuté. Ce premier « hook » est associé à des instructions de code configurées pour obtenir l’adresse de la zone mémoire du noyau dans laquelle sont écrites les données non chiffrées, reçues ou à transmettre, et pour mémoriser cette adresse de la zone mémoire obtenue dans une structure de données du noyau, par exemple une table ou un dictionnaire, en association avec un identifiant de l’appel système concerné par l’appel système, par exemple un identifiant de socket. Une deuxième séquence d’instructions est injectée dans le noyau et associée à la sortie de l’appel système. Cette deuxième séquence comprend des instructions configurées pour obtenir l’adresse de la mémoire tampon qui a été mémorisée dans la structure de données lors de l’exécution des instructions injectées à l’entrée de l’appel système, et pour recopier le contenu de cette zone mémoire dans une mémoire allouée dans l’espace utilisateur, par exemple une mémoire tampon circulaire. Les données non chiffrées interceptées sont ainsi accessibles par un module d’analyse s’exécutant dans l’espace utilisateur de l’environnement hôte. Le procédé comprend enfin une étape 305 d’analyse des données interceptées. L’étape d’analyse comprend par exemple l’application d’un modèle prédictif aux données interceptées. Le modèle prédictif peut être un réseau de neurones artificiels entrainé au préalable à partir de messages caractéristiques d’une cyber-attaque, d’une intrusion ou d’une défaillance d’un équipement réseau. Bien que la description qui a été faite du procédé se base sur une technologie eBPF, d’autres technologies peuvent être utilisées pour mettre en œuvre le procédé. Par exemple, l’invention peut être mise en œuvre par un module dédié chargé dans le noyau, ou bien par des instructions introduites dans le noyau lors de sa compilation. La FIG. 4 représente une architecture d’un dispositif 400 adapté pour mettre en œuvre le procédé d’interception selon un mode particulier de réalisation de l’invention. Le dispositif 400 comprend un module de traitement de données comprenant un espace de stockage 401, par exemple une mémoire (MEM), une unité de traitement 402, équipée par exemple d'un microprocesseur (PROC), et pilotée par un programme d'ordinateur (PGR) 403 dont les instructions sont configurées pour mettre en œuvre le procédé d’interception tel que décrit précédemment en relation avec la FIG. 3 . A l'initialisation, les instructions de code du programme d'ordinateur 403 sont par exemple chargées dans la mémoire 401 avant d'être exécutées par le processeur de l'unité de traitement 402. Le microprocesseur de l'unité de traitement 402 met en œuvre, selon les instructions du programme d'ordinateur 403, les étapes du procédé d’interception décrites ci-avant en référence à la FIG. 3 . Pour cela, le dispositif 400 comprend des moyens de communication 404, par exemple une carte réseau, permettant au dispositif de se connecter à un réseau de communication et échanger des données avec d’autres dispositifs. Les moyens de communication 404 sont contrôlés par un système d’exploitation du dispositif offrant notamment des fonctions cryptographiques permettant de chiffrer et déchiffrer des communications dans l’espace noyau au profit d’applications s’exécutant dans un espace utilisateur, par exemple dans des conteneurs. Le dispositif comprend également un module de configuration 405 adapté pour instrumenter au moins une fonction réseau du système d’exploitation en associant un ensemble d’instructions à un point d’exécution particulier de ladite fonction. Pour cela, le module de configuration peut être mis en œuvre par des instructions de programme d’ordinateur et utiliser des fonctions eBPF pour injecter des instructions de code dans le noyau et associer l’exécution de ces instructions à l’entrée et/ou la sortie d’un appel système particulier. Le dispositif 400 comprend aussi un module 406 d’interception de données réseau. Le module est par exemple mis en œuvre par une séquence d’instructions de code injectée dans le noyau et associée à un point d’exécution particulier d’un appel système. La séquence d’instructions en question est configurée pour accéder à une zone mémoire allouée dans l’espace noyau destinée à mémoriser temporairement des données échangées par une application locale avec un ou plusieurs dispositifs distants, notamment des messages de signalisation échangés entre différentes fonctions réseau. Les données contenues dans la zone mémoire sont des données déchiffrées par des fonctions cryptographiques du noyau du système d’exploitation ou des données en attente de chiffrement par les fonctions cryptographiques. Autrement dit, le module d’interception est configuré pour accéder aux données en clair, c’est-à-dire non chiffrées, mémorisées dans une zone mémoire du système d’exploitation qui n’est pas directement accessible par les applications s’exécutant dans l’espace utilisateur du système d’exploitation. Le module d’interception comprend en outre des instructions configurées pour copier les données de la zone mémoire allouée dans l’espace noyau vers une zone mémoire accessible depuis l’espace utilisateur. Le dispositif comprend enfin un module 407 de diagnostic adapté pour lire les données recopiées dans la zone mémoire accessible depuis l’espace utilisateur par le module d’interception 406 et analyser ces données pour déterminer si elles sont ou non caractéristiques d’une cyber-attaque ou une défaillance. Pour cela, le module 407 peut mettre en œuvre un modèle d’analyse prédictive comme un réseau de neurones artificiels, un modèle de régression, de classification ou encore un arbre de décision. Le modèle d’analyse peut être entrainé au préalable à partir de messages caractéristiques de cyber-attaques ou de défaillances et de message caractéristique d’un fonctionnement nominal. Selon un mode particulier de réalisation, le dispositif 400 est intégré dans un serveur d’un réseau de communication. Procédé d’interception, par un module d’analyse, d’un flux de communication à destination d’une application exécutée dans un conteneur sur un environnement hôte comprenant un système d’exploitation, le procédé comprenant les étapes suivantes : Une étape de configuration au cours de laquelle un ensemble d’instructions de code est associé à un point d’exécution particulier d’un appel système de transfert de données, Une étape d’exécution dudit ensemble d’instructions dans l’espace du noyau du système d’exploitation de l’environnement hôte lorsqu’un appel système de transfert de données est déclenché depuis l’au moins un conteneur atteint le point d’exécution, l’exécution dudit ensemble d’instruction comprenant au moins la recopie du contenu d’une zone mémoire de l’espace noyau modifiée par l’appel système vers une zone mémoire de l’espace utilisateur. Procédé selon la revendication 1 tel qu’il comprend en outre une étape préalable de détermination qu’une fonction de déchiffrement des communications est réalisée par le noyau, l’exécution de l’ensemble d’instructions de code étant conditionné au résultat de ladite étape de détermination, la zone mémoire de l’espace noyau modifiée comprenant des données déchiffrées par le noyau. Procédé selon l’une quelconque des revendications précédentes tel qu’il comprend en outre une étape de détection d’une attaque à partir des données interceptées. Procédé selon l’une quelconque des revendications précédentes dans lequel l’étape de configuration comprend l’association d’un premier ensemble d’instructions de code à un premier point d’exécution dans l’espace du noyau du système d’exploitation et d’un deuxième ensemble d’instructions de code à un deuxième point d’exécution dans l’espace du noyau du système d’exploitation, le premier point d’exécution étant un point d’entrée de l’appel système et le deuxième point d’exécution étant un point de sortie dudit appel système, le premier ensemble d’instructions de code étant configuré pour obtenir une adresse d’une mémoire tampon dans l’espace du noyau et mémoriser cette adresse dans une structure de données mémorisée dans l’espace noyau, le deuxième ensemble d’instructions étant configuré pour obtenir l’adresse mémorisée et copier des données depuis un emplacement pointé par ladite adresse vers une mémoire tampon accessible depuis l’espace utilisateur. Dispositif d’interception d’un flux de communication à destination d’une application exécutée dans un conteneur sur un environnement hôte comprenant un système d’exploitation, le dispositif comprenant un processeur couplé à une mémoire dans laquelle sont enregistrées des instructions de programme d’ordinateur configurées pour mettre en œuvre les étapes suivantes : Une étape de configuration au cours de laquelle un ensemble d’instructions de code est associé à un point d’exécution particulier d’un appel système de transfert de données, Une étape d’exécution dudit ensemble d’instructions dans l’espace du noyau du système d’exploitation de l’environnement hôte lorsqu’un appel système de transfert de données est déclenché depuis l’au moins un conteneur atteint le point d’exécution, l’exécution dudit ensemble d’instruction comprenant au moins la recopie du contenu d’une zone mémoire de l’espace noyau modifiée par l’appel système vers une zone mémoire de l’espace utilisateur. Serveur comprenant un dispositif d’interception selon la revendication 5. Programme d’ordinateur comprenant des instructions adaptées à la mise en œuvre des étapes d'un procédé selon l’une quelconque des revendications 1 à 4, lorsque le programme est exécuté par un processeur. Support d’information lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes d'un procédé d’interception selon l’une quelconque des revendications 1 à 4.