Quand on lit le récit des évènement, aujourd'hui accessible en cache, le tort de Journalspace a été d'avoir trop fait confiance à un administrateur aux compétences douteuses et à la respectabilité incertaine. Ce qui les a conduit à compter sur un RAID1 comme solution de backup. Détail futile que j'abordais rapidement après la fin de mes déboires mi-2007 :

Et pour ceux qui confondent sauvegarde et RAID, sachez que 
sont deux choses différentes et l'un ne doit pas empêcher 
l'autre. Le RAID est une solution de disponibilité, la 
sauvegarde une solution de réponse à incident. En particulier, 
le RAID ne vous protège pas de l'effacement "involontaire" de 
données. Il se trouve d'ailleurs qu'une bonne partie du revenu 
des sociétés de récupération de données provient de grappes 
RAID, nettement plus fastidieuses, donc chères, à traiter. 
Comme quoi...

Il est vrai que ce discours passe mieux avec quelques exemples bien choisis, mais quand ces derniers font les manchettes de Slashdot, le message passe un peu mieux. Encore que...

Depuis, le domaine a été racheté et un service est à nouveau disponible. Espérons que les nouveaux gestionnaires retiendront quelque chose de cet incident...

Sur SecurityVibes, Jérôme Saiz aborde cette histoire sous l'angle de la séparation de privilèges. Point de vue intéressant, mais qui ne concerne malheureusement que les structures qui peuvent se le permettre, ce qui ne me semble pas avoir été le cas de Journaspace. Car s'il y a effectivement pléthore de privilèges à distribuer, ce sont plus généralement les individus à qui les donner qui manquent et risque de rendre contre-productives ce genre de mesures. En outre, il ne faut pas perdre de vue que d'un point de vue technique, l'opérateur de sauvegarde a un pouvoir loin d'être négligeable que j'illustrerai par un vieil audit mené dans une autre vie.

Nous avions à l'époque travaillé sur une appliance qui proposait une séparation des privilèges d'administration assez impressionnante, en particulier du point de vue de la granularité. Le constructeur ayant mis l'accent sur la sécurité physique, obtenir les droits super-utilisateur en console était un des objectifs majeurs. Outre l'exploitation de quelques bévues de débutant sur la gestion du boot d'un système Linux, une des méthodes d'escalade de privilèges s'appuyait justement sur les backups, ou plus précisément leur modification conduisant, lorsque réinstallés sur la boîte, à la compromission de l'équipement. Problème d'intégrité diront certains, qui implique des signatures, donc des clés, donc d'autres privilèges à distribuer, encore et toujours. Pas simple tout ça, même si pas forcément très compliqué, en tout cas pas totalement immédiat...

Dommage qu'on n'ait pas pensé, chez Journalspace, à lancer un challenge portant sur la récupération de leurs données...


Plus intéressant, je trouve, cette malheureuse histoire qui frappe les clients de FictionWise, un vendeur d'ebooks. Point de backup inexistant, perdu, oublié ou inopérant. Pas de disque dur en carafe, pas plus que de méchant administrateur à l'esprit revanchard. Un bête problème de... DRM...

Fictionwise est en fait un espèce d'aggrégateur qui vend des contenus en provenance de différents fournisseurs. L'un d'entre eux, Overdrive semble avoir annoncé qu'il arrêterait de fournir à FictionWise l'accès à son service. Conséquence ? À partir du 1er février prochain, les ebooks acheté sur Overdrive via FictionWise ne seront plus accessibles.

Jusque là, on pourrait penser qu'il n'y a pas de quoi fouetter un chat. Il suffit, comme l'indique la FAQ publiée par FictionWise, de télécharger une dernière fois tous vos achats et de les garder bien au chaud. Sauf que ce n'est pas aussi simple, puisque cette autorisation semble être liée à un lecteur physique, ce qui implique qu'un changement de lecteur ferme également l'accès au contenu.

D'où la solution de la conversion de format proposée, à savoir récupérer les contenus au format eReader pour garantir un accès plus pérenne au contenu. Sauf que ce n'est pas manifestement pas possible pour l'intégralité du catalogue concerné : environ 20% des titres impactés ne sont en effet pas disponibles dans un autre format. Et comme FictionWise n'est pas maître du système de protection, ils ne peuvent pas faire cette conversion eux-même. Ils sont donc condamnés à passer outre Overdrive et aller voir les éditeurs concernés pour obtenir les titres dans un format sinon ouvert, tout de moins plus accessible.

Tout recul pris, il est clair que la situation n'est pas aussi catastrophique qu'on veut bien le dire. Cependant, elle suscite un malaise bien compréhensible chez les acheteurs. Enfin... Les acheteurs... C'est vite dit, puisqu'à y regarder de plus près, on n'achète pas vraiment un ebook. On souscrit plutôt un droit d'accès à son contenu, dans des conditions relativement restreintes, pour rester dans l'euphémisme. En fait, une lecture plus approfondie de la FAQ donne des signes de l'étendue de la problématique. En particulier le passage dans lequel on vous explique de Fictionwise fait de son mieux pour garantir l'accès aux contenus, mais que bon c'est pas facile, et puis que le client devrait s'estimer heureux parce d'autres éditeurs n'ont pas la même diligence...


Même si ce n'est pas la catastrophe Journalspace, ce dernier incident nous rappelle un autre aspect de la conservation des données : la capacité à en lire le contenu. C'est un des arguments de poids à mon avis en faveur de l'abandon des DRM, comme on vient de le voir. Exemple tout bête : comment garantir à l'utilisateur que lorsque l'œuvre qu'il a achetée tombera dans le domaine public, il pourra en réaliser des copies et les distribuer librement ? Pour autant qu'il soit encore capable d'y accéder soixante-dix ans après l'achat...

Car cet accès pérenne aux données est également l'argument majeur, je pense, en faveur des formats ouverts. Qu'il s'aggisse d'abandon de format ou de sociétés qui disparaissent, les cas de bases documentaires devenues partiellement ou totalement inaccessibles sont légions, en particulier dans le cas d'applications métier très ciblées. J'ai eu l'occasion de constater les dégâts dans une autre vie sur un logiciel de GEIDE qui a apparemment disparu définitivement du marché[1]...

Dans ce cas, la problématique était double. D'abord, le logiciel ne fournissait qu'un accès extrêmement restreint aux données en base[2] et donc limitant quant à leur exploitation. Rien que penser à des recherches croisées vous collait un mal de crâne à réconforter un jeune motivé après le social event du SSTIC. Ensuite, et surtout, il y avait l'ultimatum posé par l'éditeur : arrêt du support de la version utilisée au profit de la version supérieure, la version Plus. Nous aurions tout de même bénéficié d'un tarif spécial. Monsieur est trop bon... Pour autant que je me souvienne, ça s'est fini par la mise en place d'une seule licence avec support ODBC pour convertir puis sucer l'intégralité de la base et l'injecter dans une vraie base SQL. Puis remplacement, avant abandon total, du-dit logiciel par une interface web en PHP bridée pour ne pas bousculer les habitudes des utilisateurs. Et je ne parle même pas de l'économie réalisée sur le prix prohibitif des licences...


Bref, la conservation des données sur de longues durées est un réel problème qui soulève tout un tas de questions. Exemple parmi tant d'autres : les relevés de compte en ligne. Ma banque me propose l'accès à mes relevés de compte sous forme électronique, à télécharger sur leur site. Bien. Comme on doit conserver un relevé pendant une durée de dix ans, la banque est en quelque sorte tenue de me garantir l'accès pendant cette période. Ce qu'elle s'engage à faire, à moins que... je passe à la concurrence. Auquel cas, j'ai intérêt à m'y prendre un peu à l'avance et faire mouliner l'imprimante à fond les ballons...

Mais plus intéressant que la conservation, la disponibilité et la mise à disposition de ces relevés, il y a la garantie de leur intégrité. Ce qui peut se régler, par exemple, à grands coups de signature numérique. Soit. Mais les clés utilisées pour de telles opérations ont-elles une durée de validité couvrant l'intégralité de la période considérée ? Probablement pas. Qu'est-ce qui se passe quand ces clés expirent ? Comment gérer les incidents, genre des révocations de clé ? Comment gérer un évènement majeur comme l'obsolescence d'un système de signature ? Parce que dix ans, ce n'est certes pas l'éternité, mais à l'échelle de temps de l'informatique, c'est sacrément long... Il peut s'en passer des choses, en dix ans...

Notes

[1] Comme quoi, le darwinisme arrive encore à s'appliquer de temps en temps...

[2] Pour peu qu'on puisse appeler un fichier à plat une base...