Archive for the ‘nettoyage’ Category

La sécurité des suppressions de données

Lundi, février 9th, 2015

Le piratage de Sony Pictures a provoqué une véritable onde de choc dont les ramifications sont parfois inattendues. L’article The Security of Data Deletion de Bruce Schneier fait l’apologie d’une stratégie ‘agressive’ de suppression des données obsolètes dans les entreprises. Puisqu’il n’est pas possible de garantir la confidentialité des données d’une entreprise, même une parmi les plus grosses, il est préférable de supprimer ces données lorsqu’elles sont obsolètes.

On peut aussi parler de l’intégrité puisque si un pirate a réussi à récupérer quelques téraoctets de données sans se faire prendre, il a tout aussi bien pu en altérer au passage. Si la cryptographie peut nous aider à ce niveau pour signer les données et messages, elle ne pourra pas grand chose si les postes utilisateurs, leurs programmes et donc leurs clés sont compromises…

Mais revenons à la politique de suppression des données. Parler de politique agressive est un peu exagéré. La notion d’agressivité sous-entend de supprimer dès que possible une donnée lorsqu’elle n’est plus utilisé. Il est fait référence dans l’article à ce que l’on transmettait par téléphone avant l’informatique, les informations annexes que l’on ne notaient pas finissaient par être rapidement oubliées, au pire déformées… ou au mieux sujettes à confirmation.

Si la messagerie instantanée est assez informelle, la messagerie classique est beaucoup plus formelle, surtout en entreprise. On est dans ce dernier cas assez loin de la conversation libre par téléphone.

Une entreprise ne peut pas non plus supprimer sans discernement ses données sous prétexte qu’à un instant donné elles n’ont plus d’utilité. Ces données, c’est la mémoire de l’entreprise. Les supprimer c’est supprimer la mémoire de l’entreprise, une des choses les plus importantes puisque c’est l’accumulation de son savoir faire, de son savoir sur ses clients et ses racines. Supprimer les données anciennes d’une entreprise, c’est comme supprimer la mémoire à long terme des individus, c’est catastrophique pour eux et pour la société dans son ensemble.

Ce parallèle avec l’individu n’est pas anodin. La capacité d’une entreprise c’est la somme des individus qui la composent démultiplié par le patrimoine technique.
Et le parallèle peut aller plus loin. L’individu ne retiendra pas tout d’une conversation téléphonique. Des informations annexes seront perdus parce que non mémorisées par l’un ou l’autre des interlocuteurs. Ensuite, avec le temps, chaque interlocuteur va oublier certaines informations pas très importantes, progressivement. Au final, après un grand laps de temps, il ne subsistera de la conversation téléphonique que l’essentiel de l’information. Il faut donc bien de la même façon supprimer les données éphémères d’une entreprise mais il ne faut pas tout supprimer. Avec le temps, seul doit subsister l’essentiel des informations du passé. Les idées doivent être résumées et les informations techniques doivent être épurées de leurs pré-calcul et des données annexes.
Comme fil conducteur, on peut essayer d’avoir la vision d’un historien sur le passé de l’entreprise pour savoir ce qui a de l’intérêt ou pas. Et ainsi, naturellement, toutes les conversations hors champs vont disparaitre.

Tel que déjà définit précédemment pour le projet nebule, les données doivent pouvoir être supprimer automatiquement après un certain délai ou conservées explicitement. Une pondération appliqué aux objets déterminera le délai de conservation, ou plutôt de non-suppression. Et un seuil déterminera à partir de quelle pondération un objet sera à garder définitivement. Ce seuil peut évoluer avec le temps et faire disparaitre après coup des objets qui initialement étaient au dessus du seuil de suppression. La pondération reflète l’importance des objets, positivement ou négativement.

Pour finir, n’est-il pas plus simple d’être respectueux dans ses messages même à usage interne ? A défaut d’empêcher le vol d’information, au moins on évite déjà les propos embarrassants, une charge de moins dans la réparation des dégâts. Mais quelque part, cela reflète un état d’esprit dans l’entreprise, une certaine culture des individus qui la composent… bref, pas très sain…

Nettoyage des liens – suite

Mercredi, septembre 25th, 2013

Ceci est la suite du post précédent sur le nettoyage des liens.

En cas de suppression d’un objet, quels liens doit-on garder ?

Il faut déjà évidemment garder le lien de type d, celui qui marque la suppression de l’objet. Sans ce lien, la propagation de la suppression ne sera pas assurée, et donc l’objet ne sera pas supprimé sur tous les emplacements. Si il est encore présent sur un emplacement connu, il risque d’être téléchargé de cet emplacement et donc en quelque sorte restauré. Ce lien doit être gardé « à vie ».

Il faut garder les liens de type u, c’est à dire voir quel(s) objet(s) est mise à jour l’objet supprimé. Il est préférable dans une chaîne de mises à jours de créer un nouveau lien qui court-circuite l’objet supprimé au milieu de la chaîne.

Il faut garder les liens de type e, les définitions d’équivalences.

Il faut supprimer tous les liens dont on est pas le signataire. Il n’y a pas de raison de garder les liens des autres entités. Les autres entités s’occuperont de leurs liens.

Il faut garder les liens de type k, correspondant au chiffrement. Lors du chiffrement d’un objet, on définit explicitement la suppression de l’objet originel pour ne garder que son dérivé chiffré.

Il faut supprimer les liens de type s, ce qui défini les subdivisions de l’objet. Cet objet n’est plus utilisable pour la récupération de morceaux. Et si il est recréé, les liens de type s le seront aussi naturellement, si besoin.

Jusque là, ça paraît suffisant. Mais que se passera-t-il le jour où, pour quelque raison que ce soit, l’objet venait à être réutilisé (volontairement) ?
Faut-il garder tous les liens de type l et f? Faut-il n’en garder qu’une partie?

Il faut aussi nettoyer les liens qui ont fait l’objet d’une suppression avec un lien de type x. Et il faut garder chaque derniers liens de type x. Ainsi, en cas de restauration de l’objet, les liens supprimés ne pourront être restaurés aussi.

Si c’est une suppression liée à un chiffrement, on doit garder tous les liens de type l et f. Ces liens sont nécessaires puisque l’objet à de bonnes chances d’être déchiffré un jour par le destinataire.

Dans les autres cs, c’est ambigu. Par défaut il vaut mieux garder tous les liens l et f.

Dans le cas d’un serveur que l’on ne maîtrise pas ou qui est mutualisé, la suppression d’un objet doit être marqué par toutes les entités. On ne peut pas supprimer un objet tant qu’une entité l’utilise encore. On entre là dans une forme de gestion en groupe.

Nettoyage des liens

Mardi, septembre 24th, 2013

Le nettoyage régulier des liens est quelque chose qui est connu depuis assez longtemps pour être indispensable. Si la quantité de lien que manipulent aujourd’hui les entités reste encore soutenable, nous ne sommes pas loin de gros problèmes de performances dans certains cas.
CF : Mémoire finie, Repérage chronologique.

Le nettoyage est la mise en pratique de l’oubli volontaire et maîtrisé des liens et objets.

Un premier nettoyage, assez facile à mettre en place par script notamment, est le nettoyage des liens. Suivre cette procédure :

  1. Copier tous les liens de tous les objets dans un emplacement temporaire unique. Chaque lien copié doit l’être une fois pour ne pas avoir de doublon. Il est préférable de faire une vérification des signatures des liens au moment de leur lecture. Chaque lien étant copié entre deux et trois fois en fonction du nombre d’objets concernés, la taille total de cet emplacement temporaire sera entre deux et trois fois moins volumineux que l’ensemble des liens des objets.
  2. Dans l’emplacement temporaire, trier les liens par date dans l’ordre chronologique. Ainsi, une fois remis en place, les liens seront déjà naturellement triés.
  3. Dans l’emplacement temporaire, supprimer les liens qui sont concernés par un lien de type x (suppression de lien). Garder le dernier lien de type x pour maintenir la propagation de la suppression du lien.
  4. Supprimer, ou mettre de côté, les liens de tous les objets. Ne garder que l’emplacement temporaire. Pendant ce lapse de temps, les objets restent disponibles mais sont inexploitables parce qu’ils ne seront pas accompagnés de leurs liens.
  5. Faire un import de chaque liens de l’emplacement temporaire, un par un et dans l’ordre. L’import va réattribuer les liens aux objets concernés, dans l’ordre.

Cette procédure ne tient pas compte des liens dans des objets, normalement chiffrés. Et ils ne doivent pas en tenir compte. Cela peut poser des problèmes résiduels de non suppression de liens parce que le lien de type x est non disponible au moment du nettoyage.

A noter qu’après le nettoyage, si des liens ont été marqués comme à supprimer, il doit rester le dernier lien de type x. Si ce n’était pas le cas, il pourrait y avoir des problèmes pour retransmettre la suppression de ces liens.

Tous les liens ne peuvent pas, et ne doivent pas disparaître en même temps que l’objet. Il faut en effet attendre que la suppression de l’objet, dictée par un lien de type d, soit effective partout. Sinon, cet objet va réapparaître et ses liens avec.

Pour nettoyer les objets, il manque la mise en place du système de pondération. Seule cette pondération associée à un seuil est capable de gérer l’oubli de certains objets parmi un grand volume d’objets.
La pondération sera pour plus tard.

Mémoire fini

Mardi, avril 5th, 2011

On part souvent du principe que l’on va gérer nos données en les accumulant dans le temps de façon infinie…

Mais est-ce vrai?

C’est en partie vrai.

Les capacités de stockage évoluent assez rapidement dans le temps. Nous enregistrons de nouveaux fichiers assez régulièrement dans le temps mais pas forcément de façon continu. Ici, pour la réflexion, on ne va retenir qu’une moyenne constante d’enregistrement de données.

Que se passe-t-il si on ajoute régulièrement suffisamment de capacités de stockage, suffisamment pour ne jamais arriver à saturation?
Tout se passe bien, on ne perd rien.

Et si la capacité de stockage n’augmente pas assez vite (dans le cas extrême où elle ne peut plus être augmentée) ?
C’est dans ce cas que doit être prévu un mécanisme de nettoyage (d’oubli), et donc de pertes maîtrisées.

Le stockage de données sous la forme proposée pour nebule risque dans certains cas de générer, et donc de stocker, énormément de données. On doit prévoir ce mécanisme d’oubli nativement.

La perte d’information maîtrisée impose de permettre cette gestion à la main. Mais quelle efficacité d’une gestion à la main pour plusieurs millions de fichiers?
Des mécanismes d’assistance ou d’automatisation doivent être proposés. Ils peuvent avoir plusieurs formes.

Sur quels critères déclarer un fichier périmé?
Plusieurs critères peuvent être pris en compte, et plusieurs combinaisons complexes peuvent être calculées de critères simples :
– le temps de possession de l’objet, plus il est vieux plus il a de chance d’être périmé ;
– si le fichier dispose d’une nouvelle version, il n’est peut-être plus intéressant de le conserver ;
– l’attractivité, ou un critère d’appréciation, donne de l’importance à un fichier dans le temps et doit faciliter sa conservation ;
– l’intensité de l’appréciation peut être exploitée en absolu, un fichier qui appel un très fort sentiment positif ou négatif a des chances de devoir être conservé longtemps ;
– un fichier lié à plusieurs autre fichiers jugés importants a surement besoin d’être lui aussi conservé, il va peut-être hériter par calcul d’une note d’appréciation ;
– d’autres fichiers font références à ce fichier, il faut sûrement le conserver ;
– mes amis ont gardé ce fichier, il doit être important.

Doit-on supprimer immédiatement un fichier périmé?
Celui-ci peut peut-être servir à quelqu’un d’autre? A-t-on la place de le garder en attendant? Peut-on se contenter de le supprimer lorsque l’on aura besoin de la place qu’il occupe? Doit-on les marquer périmés en attendant ou gérer une liste des objets périmés?
L’analyse des fichiers à marquer peut se faire en continu, moyennant une occupation constant et relativement importante de ressources. L’analyse peut se faire lors d’une phase de repos (activité de sommeil). Une liste peut aussi être maintenu en temps réel sans analyse, juste en classant les objets de façon croissante dans une liste et en faisant évoluer la place des objets en fonction de l’évolution de leurs paramètres.

Une fois un objet marqué comme périmé, comme propager son marquage? C’est à dire, comment vont se comporter les relais avec ces objets dits périmés?
Cette propriété de péremption doit-elle être visible des entités tierces? Ou est-elle purement interne?