Brevet FR3012900A1 — publié le 20150508

PROCEDE DE PROTECTION DE METADONNEES DOMAINE TECHNIQUE DE L'INVENTION Le domaine technique de l'invention est celui des procédés de protection de métadonnées. ARRIERE-PLAN TECHNOLOGIQUE DE L'INVENTION Dans un domaine de stockage, les données sont globalement divisées en deux 10 sous-ensembles : - les données en tant que telles, « réelles », par exemple le contenu binaire d'un fichier comme une image ou un texte. Ces données sont également appelées « data » dans le présent document ; - les métadonnées, qui définissent un certain nombre de caractéristiques 15 relatives aux données « data » du fichier, comme par exemple : o la date de création du fichier, o la date de dernière modification du fichier, o le nom « visuel » du fichier, o les droits - c'est-à-dire qui peut lire, écrire, modifier le fichier, 20 o ainsi que, à un niveau plus fin, l'endroit où le fichier se trouve physiquement sur un support de stockage, tel qu'un disque dur ou un serveur. Les métadonnées sont également appelées « metadata » dans le présent document. 25 La corruption des données au sens large est un problème connu. Pour s'en prémunir, l'état de l'art propose généralement l'utilisation d'une technique RAID (de l'anglais « Redundant Array of Independant Disks ») qui, en répartissant les données sur plusieurs espaces de stockage, permet d'en garantir l'intégrité par 30 rapport à un problème matériel. Cependant, ce type de technique ne couvre pas les risques de corruption, volontaire ou involontaire, liés par exemple à une attaque informatique. La modification des données et la détection de modification non désirées sont un sujet complexe. Concernant l'aspect « data », une première solution réellement plausible est de prendre une référence, c'est-à-dire réaliser une opération mathématique de type « somme » permettant d'identifier un contenu de manière non-répudiable. Des algorithmes de hashage cryptographique comme MD5 (« Message Digest 5 ») ou SHA (« Secure Hash Algorithm ») permettent de calculer à un instant TO, à partir d'une donnée initiale fournie en entrée, une somme servant à identifier rapidement la donnée initiale. On peut ainsi typiquement vérifier, à un instant T1>TO, si la somme est toujours similaire et donc si la donnée est toujours intègre. Une deuxième solution, complémentaire de la première, est la sauvegarde de manière régulière des données sur différents supports pour archivage. Ces deux éléments de solution restent valables pour les « metadata ». La problématique est cependant différente, surtout dans le cadre d'un système de fichiers réparti/distribué, comme on peut en trouver dans un contexte de calcul haute performance. Dans un tel environnement, un ensemble de serveurs est chargé de fournir l'accès aux « data » : les serveurs E/S. Un ensemble d'autres serveurs est chargé de fournir les informations de type « metadata » : les serveurs de métadonnées. Une corruption physique, telle qu'un disque en panne, peut être gérée via des mécanismes de type RAID ou plus généralement via une redondance physique. Cependant, si l'information stockée, « écrite », est remplacée par une valeur invalide, un système de redondance se contentera de « recopier » la valeur invalide, porteuse d'une mauvaise information. Ces systèmes s'avèrent donc notamment inutiles face à une attaque sur des métadonnées. En l'absence d'une attaque, les métadonnées - tout comme les données d'une manière générale - sont également susceptibles de subir une corruption silencieuse (« silent data corruption »), c'est-à-dire une corruption indétectée. Une telle corruption peut par exemple être liée à une erreur lors d'un processus d'écriture sur un disque de stockage. Dans le cas où l'information de métadonnée d'un fichier est corrompue, par exemple si l'information de taille ou de localisation physique dudit fichier est erronée, l'accès audit fichier peut être irrémédiablement perdu. En effet, sans les métadonnées, il est impossible pour les clients d'un système de fichiers réparti d'accéder aux données elles-mêmes. Les figures la à ld illustrent un procédé 100 d'accès à un système de fichiers distribué selon l'art antérieur. Le système de fichiers distribué comporte dans l'exemple représenté aux figures laàld: - un serveur de métadonnées S _MD et une baie de stockage B_MD du serveur de métadonnées S_MD ; - un premier serveur de données S_D1 et une première baie de stockage B _D1 du premier serveur de données S_D1 ; - un deuxième serveur de données S_D2 et une deuxième baie de stockage B _D2 du deuxième serveur de données S_D2 ; - un dispositif client C, le dispositif client C pouvant communiquer avec le serveur de métadonnées S _MD et les premier et deuxième serveurs de données S_D1 et S_D2 grâce à un réseau NWK. Les figures la à ld montrent également un fichier f du système de fichiers distribué, le fichier f comportant : - des données, une première partie Df_l desdites données étant stockée sur la première baie de stockage B_D1 et une deuxième partie Df_2 desdites données étant stockée sur la deuxième baie de stockage B_D2 ; - des métadonnées MD_f stockées sur la baie de stockage B_MD du serveur de métadonnées S_MD. La figure 1 a montre une étape, dans le procédé 100, d'obtention des métadonnées MD_f du fichier f par le client C. Un utilisateur réalise par exemple une instruction de type : fd = open(MonFichier) ; « MonFichier » étant le nom du fichier f. Suite à cette instruction de l'utilisateur, le client C envoie un premier message 1 au serveur de métadonnées S_MD via le réseau NWK afin d'obtenir les métadonnées MD_f du fichier f, qui comportent notamment l'emplacement de stockage des 5 données du fichier f. Le serveur de métadonnées S MD envoie un deuxième _ message 2 au client C avec les métadonnées MD_f du fichier f dont l'emplacement de stockage des données du fichier f. En l'occurrence, l'emplacement de stockage des données du fichier f est le suivant : la première partie Df_l des données est stockée sur la première baie de stockage B_D1 du 10 premier serveur de données S_D1, et la deuxième partie Df_2 des données est stockée sur la deuxième baie de stockage B_D2 du deuxième serveur de données S D2. La figure 1 b montre une étape, dans le procédé 100, d'accès aux données du 15 fichier f. Le client C envoie, après réception du deuxième message 2 : - un troisième message 3 au premier serveur de données S_D1 via le réseau NWK pour l'accès à la première partie Df_l des données. Le premier serveur de données S_D1 va alors chercher la première partie Df_l des données sur la première baie de stockage B_D1 et transmet ladite première 20 partie Df _1 des données au client C ; - un quatrième message 4 au deuxième serveur de données S_D2 pour l'accès à la deuxième partie Df_2 des données. Le deuxième serveur de données S_D2 va alors chercher la deuxième partie Df_2 des données sur la deuxième baie de stockage B_D2 et transmet ladite deuxième partie 25 Df 2 des données au client C. _ Les données et les métadonnées du fichier f se trouvent désormais sur le client C, qui peut accéder effectivement aux données du fichier f et réaliser des opérations qui modifient le fichier f. Ces opérations peuvent modifier : - uniquement les métadonnées MDJ, par exemple dans le cas d'un accès 30 de type open(), où la date de dernier accès au fichier est mise à jour dans les métadonnées MDJ, ou - les données et les métadonnées MDJ, par exemple dans le cas d'un ajout de données. La figure 1c montre une étape, dans le procédé 100, de modification du fichier f par l'utilisateur du client C et de mise à jour des données du fichier f. L'utilisateur réalise par exemple les instructions suivantes : f cl = open(MonFichier); read(f cl, data, size); write (f cl, data, size); close(f cl); chmod(MonFichier, mode); Dans l'exemple considéré, le client C accède donc au fichier f, lit le fichier f, écrit dans le fichier f et ajoute donc des données supplémentaires dans le fichier f, ferme le fichier f et change les droits du fichier f. On se place dans le cas où l'opération d'écriture entraîne la création d'une troisième partie Df_3 des données du fichier f. Le client C envoie alors un cinquième message 5 au serveur de métadonnées S_MD via le réseau NWK afin de savoir où ajouter la troisième partie Df_3 des données du fichier f : le client C demande une allocation d'espace au serveur de métadonnées S_MD. Le serveur de métadonnées S_MD répond par un sixième message 6 au client C via le serveur NWK et indique par exemple au client C d'ajouter la troisième partie Df_3 des données du fichier f sur un troisième serveur de données S_D3. Le troisième serveur de données S_D3 est associé à une troisième baie de stockage B_D3. Le client C envoie alors un septième message 7 au troisième serveur de données S_D3 via le réseau NWK pour l'écriture de la troisième partie Df_3 des données du fichier f sur la troisième baie de stockage B_D3. Suite à cette mise à jour des données du fichier f, le système de fichiers distribué procède à la mise à jour des métadonnées MD_f du fichier f. La figure 1d montre une étape, dans le procédé 100, de mise à jour des métadonnées MD_f du fichier f. Le client C envoie un huitième message 8 au serveur de métadonnées S_MD via le réseau NWK pour la mise à jour des métadonnées MD _f afin de prendre en compte l'ajout de données, la nouvelle taille du fichier f, la localisation de chaque partie des données, les nouvelles permissions, l'heure de modification, l'heure d'accès, etc. Ainsi, dans le procédé 100 d'accès au système de fichiers distribué selon l'art antérieur, si le serveur de métadonnées S_MD est corrompu, les métadonnées MD_f permettant d'accéder aux données du fichier f ne seront plus valides et l'accès au fichier f sera invalide, c'est-à-dire qu'on accèdera par exemple aux données d'un autre fichier que le fichier f, ou impossible, c'est-à-dire qu'on n'accèdera à aucune donnée. EXPOSE DE L'INVENTION L'invention offre une solution aux problèmes évoqués précédemment, en proposant un procédé de protection de métadonnées contre une corruption silencieuse ou contre une attaque malveillante. L'invention concerne donc essentiellement un procédé de protection de métadonnées, lesdites métadonnées décrivant un fichier dans un système de stockage et étant enregistrées sur un serveur principal, le procédé de protection étant caractérisé en ce que lesdites métadonnées sont enregistrées sur un serveur secondaire et en ce que le procédé comporte les étapes suivantes : - un client obtient un identifiant du serveur principal ; - le client émet une requête vers le serveur principal afin d'obtenir les métadonnées décrivant le fichier, la requête comprenant un identifiant du fichier ; - le serveur principal émet une réponse vers le client, la réponse comportant les métadonnées décrivant le fichier ; - le client émet un message vers le serveur principal pour la mise à jour des métadonnées sur le serveur principal, et le client émet un message vers le serveur secondaire pour la mise à jour des métadonnées sur le serveur secondaire, le client ayant préalablement obtenu un identifiant du serveur secondaire. Grâce à l'invention, on assure, dans un système de stockage, une duplication sur un serveur principal et sur au moins un serveur secondaire des métadonnées de chaque fichier stocké dans le système de stockage. C'est le client, et non pas le serveur principal, qui envoie un message vers le serveur secondaire pour la mise à jour des métadonnées sur le serveur secondaire. Le procédé selon l'invention permet ainsi de s'affranchir d'une éventuelle défaillance ou corruption du serveur principal ou du serveur secondaire, en considérant que le client est fiable. Outre les caractéristiques qui viennent d'être évoquées dans le paragraphe précédent, le procédé de protection de métadonnées selon l'invention peut présenter une ou plusieurs caractéristiques complémentaires parmi les suivantes, considérées individuellement ou selon toutes les combinaisons techniquement possibles : - Dans un premier mode de fonctionnement, le client obtient l'identifiant du serveur secondaire en même temps qu'il obtient l'identifiant du serveur principal. - Dans un deuxième mode de fonctionnement, la réponse émise par le serveur principal vers le client comporte : - les métadonnées décrivant le fichier, et - une liste comprenant l'identifiant du serveur secondaire. Le client obtient donc, dans ce deuxième mode de fonctionnement, l'identifiant du serveur secondaire après avoir interrogé le serveur principal. - Dans le deuxième mode de fonctionnement, la liste est avantageusement protégée par une technique de cryptage, l'accès à ladite liste nécessitant une clé de décryptage. Ainsi, on améliore la robustesse du dispositif de protection de métadonnées en sécurisant l'accès à l'identifiant du serveur secondaire, par exemple dans le cas où la réponse émise par le serveur principal vers le client est interceptée par un dispositif malveillant. - La clé de décryptage est avantageusement inconnue du serveur principal. Ainsi, on contribue à améliorer la robustesse du dispositif de protection de métadonnées en sécurisant l'accès à l'identifiant du serveur secondaire dans le cas où le serveur principal est corrompu. La clé de décryptage est avantageusement connue uniquement du client, le client étant réputé fiable. - Dans le premier ou dans le deuxième mode de fonctionnement, le client procède à la mise à jour des métadonnées sur le serveur principal et sur le serveur secondaire suivant un ordre de mise à jour prédéfini. - La mise à jour des métadonnées du fichier par le client est avantageusement validée lorsque tous les serveurs sont mis à jour. Ainsi, on maximise la sécurité et la protection des métadonnées. - Alternativement, la mise à jour des métadonnées du fichier par le client est avantageusement validée lorsqu'au moins un serveur est mis à jour. Ainsi, on améliore la rapidité d'exécution du procédé de protection de métadonnées du point de vue du client. - L'invention concerne également un procédé dans lequel les métadonnées sont enregistrées sur une pluralité de serveurs secondaires et comportant les étapes suivantes : - un client obtient un identifiant du serveur principal ; - le client émet une requête vers le serveur principal afin d'obtenir les métadonnées décrivant le fichier, la requête comprenant un identifiant du fichier ; - le serveur principal émet une réponse vers le client, la réponse comportant les métadonnées décrivant le fichier ; - le client émet un message vers le serveur principal pour la mise à jour des métadonnées sur le serveur principal, et le client émet un message vers chaque serveur secondaire de la pluralité de serveurs secondaires pour la mise à jour des métadonnées sur la pluralité de serveurs secondaires, le client ayant préalablement obtenu un identifiant de chaque serveur secondaire de la pluralité de serveurs secondaires. L'invention et ses différentes applications seront mieux comprises à la lecture de la description qui suit et à l'examen des figures qui l'accompagnent. BREVE DESCRIPTION DES FIGURES Les figures sont présentées à titre indicatif et nullement limitatif de l'invention. - La figure 1 a montre une étape d'obtention des métadonnées d'un fichier dans un procédé d'accès à un système de fichiers distribué de l'art antérieur. - La figure 1 b montre une étape d'accès aux données du fichier dans le procédé de la figure 1 a. - La figure 1 c montre une étape de modification du fichier et de mise à jour des données du fichier f dans le procédé de la figure 1 a. - La figure ld montre une étape de mise à jour des métadonnées du fichier dans le procédé de la figure 1 a. - La figure 2a montre une deuxième étape d'un procédé de protection de métadonnées selon un mode de réalisation de l'invention. - La figure 2b montre une troisième étape du procédé de protection de métadonnées de la figure 2a. - La figure 2c montre une quatrième étape du procédé de protection de métadonnées de la figure 2a. - La figure 3 est un diagramme de l'organisation des étapes du procédé de protection de métadonnées de la figure 2a. DESCRIPTION DETAILLEE D'AU MOINS UN MODE DE REALISATION DE L'INVENTION Sauf précision contraire, un même élément apparaissant sur des figures différentes présente une référence unique. Le procédé 200 de protection de métadonnées est mis en oeuvre dans une infrastructure de système de fichiers distribué représentée aux figures 2a à 2c et comportant les éléments suivants : - un serveur principal de métadonnées S_MD1 et une baie de stockage principale B_MD1 du serveur principal de métadonnées S_MD1 ; - un serveur secondaire de métadonnées S_MD2 et une baie de stockage secondaire B_MD2 du serveur secondaire de métadonnées S_MD2 ; - un premier serveur de données S_D1 et une première baie de stockage B _D1 du premier serveur de données S_D1 ; - un deuxième serveur de données S_D2 et une deuxième baie de stockage B_D2 du deuxième serveur de données S_D2 ; - un troisième serveur de données S _D3 et une troisième baie de stockage B_D3 du troisième serveur de données S_D3 ; - un dispositif client C pouvant communiquer avec le serveur principal de métadonnées S_MD1, le serveur secondaire de métadonnées S_MD2 et les premier, deuxième et troisième serveurs de données S_D1, S_D2 et S _D3 grâce à un réseau NWK. Les figures 2a à 2c montrent également un fichier f du système de fichiers distribué, le fichier f comportant : - des données, une première partie Df_1 desdites données étant stockée sur la première baie de stockage B_D1, une deuxième partie Df_2 desdites données étant stockée sur la deuxième baie de stockage B_D2 et une troisième partie Df_3 desdites données étant stockée sur la troisième baie de stockage B_D3 ; - des métadonnées MD_f stockées sur la baie de stockage principale B_MD1 du serveur principal de métadonnées S_MD1 et sur la baie de stockage secondaire B_MD2 du serveur secondaire de métadonnées S_MD2. Les métadonnées MD _f du fichier f sont ainsi dupliquées en deux endroits différents du système de fichiers distribué, sur la baie de stockage principale B_MD1 contrôlée par le serveur principal de métadonnées S_MD1 et sur la baie de stockage secondaire B_MD2 contrôlée par le serveur secondaire de métadonnées S_MD2. 3012 900 11 Le procédé 200 de protection de métadonnées intervient notamment lors de la mise à jour des métadonnées MD_f du fichier f, consécutive à une modification desdites métadonnées MD J. Une telle modification des métadonnées MDJ du 5 fichier f survient typiquement lorsque le client C accède au fichier f, par exemple suite à une instruction de l'utilisateur de type : f cl = open(MonFichier); « MonFichier » étant le nom du fichier f. 10 Lors d'une première étape 201 d'initialisation du procédé 200 de protection de métadonnées, le client C obtient, par exemple grâce à un fichier de configuration locale ou via un mécanisme similaire au protocole DHCP ou l'utilisation d'options spécifiques du protocole DHCP, l'adresse du serveur principal de métadonnées S_MD1 ainsi que, dans un premier mode de fonctionnement, l'adresse du serveur 15 secondaire de métadonnées S_MD2. La première étape 201 est représentée à la figure 3. La figure 2a montre une deuxième étape 202 du procédé 200 de protection de métadonnées. Selon cette deuxième étape 202, le client C émet une première 20 requête 11 vers le serveur principal de métadonnées S_MD1 par l'intermédiaire du réseau NWK afin d'obtenir les métadonnées MD_f du fichier f. La première requête 11 comprend pour ce faire un identifiant du fichier f. La figure 2b montre une troisième étape 203 du procédé 200 de protection de 25 métadonnées. Selon cette troisième étape 203, le serveur principal de métadonnées S_MD1 émet une réponse 12 vers le client C par l'intermédiaire du réseau NWK, la réponse 12 comportant les métadonnées MD_f du fichier f. Une fois les métadonnées MD_f du fichier f obtenues, le client C peut effectivement accéder au fichier f et, en fonction des instructions d'un utilisateur du 30 client C, réaliser une pluralité d'opérations sur le fichier f, comme par exemple lire le fichier f et/ou écrire dans le fichier f, puis fermer le fichier f et éventuellement changer les droits d'accès du fichier f. 3012 900 12 Lorsque le client C a terminé de réaliser cette pluralité d'opérations sur le fichier f, le client C procède à la mise à jour des données du fichier f et à la mise à jour des métadonnées du fichier f. Lors de la mise à jour des données du fichier f, une ou plusieurs parties Df_1 à Df_3 des données du fichier f peuvent être modifiées ou 5 supprimées, et de nouvelles parties des données du fichier f peuvent être ajoutées. Le client C demande une allocation d'espace au serveur principal de métadonnées S_MD1 afin de savoir où et comment stocker les données mises à jour du fichier f, c'est-à-dire comment découper les données mises à jour en plusieurs parties, et vers quel serveur de données envoyer chaque partie. Dans 10 l'exemple représenté à la figure 2b, on considère un cas où, à l'issue de la mise à jour des données du fichier f, on a toujours les première, deuxième et troisième parties Df_1, Df_2 et Df_3 des données respectivement stockées par les premier, deuxième et troisième serveurs de données S D1, S D2 et S D3. Ce cas _ S_D2 _ correspond par exemple à un accès au fichier f de type open(). Une fois les 15 données du fichier f mises à jour, le client C procède à la mise à jour des métadonnées MDJ du fichier f. La figure 2c montre une quatrième étape 204 du procédé 200 de protection de métadonnées. Selon cette quatrième étape 204, le client C émet un message 13 20 vers le serveur principal de métadonnées S_MD1 via le réseau NWK pour la mise à jour des métadonnées MD_f sur le serveur principal S_MD1, et le client C émet un message 14 vers le serveur secondaire de métadonnées S_MD2 pour la mise à jour des métadonnées MD_f sur le serveur secondaire de métadonnées S_MD2. Le serveur secondaire de métadonnées S_MD2 est préférentiellement intégré à 25 bas niveau via un protocole d'accès et de modification des métadonnées afin de diminuer le risque d'une attaque sur ledit serveur secondaire de métadonnées S_MD2. Grâce au procédé 200 de protection de métadonnées de l'invention, si le serveur principal de métadonnées S_MD1 subit une attaque et/ou une corruption de ses informations, le serveur secondaire de métadonnées S_MD2 pourra 30 prendre le relai, avec des informations valides. On a précédemment décrit le premier mode de fonctionnement selon lequel le client C obtient l'identifiant du serveur secondaire de métadonnées S_MD2 simultanément à l'identifiant du serveur principal de métadonnées S_MD1 lors de la première étape 201, par exemple dans une phase d'initialisation du client C. Selon un deuxième mode de fonctionnement, le client C peut obtenir uniquement l'identifiant du serveur principal de métadonnées S_MD1 lors de la première étape 201, et obtenir l'identifiant du serveur secondaire de métadonnées S_MD2 lors de la troisième étape 203. Dans ce deuxième mode de fonctionnement, la réponse 12 comporte, outre les métadonnées MD_f du fichier f, une liste comprenant un identifiant du serveur secondaire de métadonnées S_MD2. Le client C obtient donc l'identifiant du serveur secondaire de métadonnées S_MD2 après avoir interrogé le serveur principal de métadonnées S_MD1, dont il connaissait l'identifiant à l'issue de la première étape 201. Le deuxième mode de fonctionnement permet avantageusement que l'identifiant du serveur secondaire de métadonnées S_MD2 ne soit transmise au client C que lorsque le client C accède à des métadonnées. On a décrit en lien avec les figures 2a à 2c un mode de réalisation du procédé 200 de protection de métadonnées mettant en oeuvre un seul serveur secondaire de métadonnées. Néanmoins, le procédé 200 de protection de métadonnées pourrait tout à fait, dans un deuxième mode de réalisation, mettre en oeuvre une pluralité de serveurs secondaires de métadonnées. Les premier et deuxième modes de fonctionnement précédemment décrits sont compatibles avec le deuxième mode de réalisation. Ainsi, le client C peut obtenir l'identifiant de chaque serveur de la pluralité de serveurs secondaires de métadonnées : - soit, dans le premier mode de fonctionnement, lors de la première étape 201 durant laquelle le client C obtient également l'identifiant du serveur principal de métadonnées S_MD1, - soit, dans le deuxième mode de fonctionnement, lors de la troisième étape 203, après avoir interrogé le serveur principal de métadonnées S_MD1 à la deuxième étape 202. La liste de la réponse 12 envoyée par le serveur principal de métadonnées S_MD1 vers le client C à l'étape 203 comporte alors l'identifiant de chaque serveur de la pluralité de serveurs secondaires de métadonnées.5 REVENDICATIONS1. Procédé (200) de protection de métadonnées (MDJ), lesdites métadonnées (MD_f) décrivant un fichier (f) dans un système de stockage et étant enregistrées sur un serveur principal (S_MD1), le procédé de protection (200) étant caractérisé en ce que lesdites métadonnées (MD_f) sont enregistrées sur un serveur secondaire (S_MD2) et en ce que le procédé (200) comporte les étapes suivantes : - un client (C) obtient un identifiant du serveur principal (S_MD1) ; - le client (C) émet une requête (11) vers le serveur principal (S_MD1) afin d'obtenir les métadonnées (MD_f) décrivant le fichier (f), la requête (11) comprenant un identifiant du fichier (f) ; - le serveur principal (S_MD1) émet une réponse (12) vers le client (C), la réponse (12) comportant les métadonnées (MD_f) décrivant le fichier (f) ; - le client (C) émet un message (13) vers le serveur principal (S_MD1) pour la mise à jour des métadonnées (MD_f) sur le serveur principal (S_MD1), et le client (C) émet un message (14) vers le serveur secondaire (S_MD2) pour la mise à jour des métadonnées (MD_f) sur le serveur secondaire (S_MD2), le client (C) ayant préalablement obtenu un identifiant du serveur secondaire (S_MD2). 2. Procédé (200) selon la revendication précédente caractérisé en ce que le client (C) obtient l'identifiant du serveur secondaire (S_MD2) en même temps qu'il obtient l'identifiant du serveur principal (S_MD1). 3. Procédé (200) selon la revendication 1 caractérisé en ce que la réponse (12) émise par le serveur principal (S_MD1) vers le client (C) comporte : - les métadonnées (MD_f) décrivant le fichier (f), et - une liste comprenant l'identifiant du serveur secondaire (S_MD2). 4. Procédé (200) selon la revendication précédente caractérisé en ce que la liste est protégée par une technique de cryptage, l'accès à ladite liste nécessitant une clé de décryptage. 5. Procédé (200) selon la revendication précédente caractérisé en ce que la clé de décryptage est inconnue du serveur principal. 6. Procédé (200) selon l'une quelconque des revendications précédentes caractérisé en ce que le client (C) procède à la mise à jour des métadonnées (MD_f) sur le serveur principal (S_MD1) et sur le serveur secondaire (S_MD2) suivant un ordre de mise à jour prédéfini. 7. Procédé (200) selon l'une quelconque des revendications précédentes caractérisé en ce que la mise à jour des métadonnées (MD_f) du fichier (f) par le client (C) est validée lorsque tous les serveurs (S_MD1, S_MD2) sont mis à jour. 8. Procédé (200) selon l'une quelconque des revendications 1 à 6 caractérisé en ce que la mise à jour des métadonnées (MD_f) du fichier (f) par le client (C) est validée lorsqu'au moins un serveur (S_MD1, S_MD2) est mis à jour. 9. Procédé (200) selon l'une quelconque des revendications précédentes caractérisé en ce que les métadonnées (MD_f) sont enregistrées sur une pluralité de serveurs secondaires et en ce que le procédé (200) comporte les étapes suivantes : - un client (C) obtient un identifiant du serveur principal (S_MD1) ; - le client (C) émet une requête (11) vers le serveur principal (S_MD1) afin d'obtenir les métadonnées (MD_f) décrivant le fichier (f), la requête (11) comprenant un identifiant du fichier (f) ; - le serveur principal (S_MD1) émet une réponse (12) vers le client (C), la réponse (12) comportant les métadonnées (MD_f) décrivant le fichier (f) ; - le client (C) émet un message (13) vers le serveur principal (S_MD1) pour la mise à jour des métadonnées (MD_f) sur le serveur principal (S_MD1), et le client (C) émet un message vers chaque serveur secondaire de la pluralité de serveurs secondaires pour la mise à jour des métadonnées (MD_f) sur la pluralité de serveurs secondaires, le client (C) ayant préalablement obtenu un identifiant de chaque serveur secondaire de lapluralité de serveurs secondaires.