Une infrastructure tenue par une seule personne

Éditorial

Une infrastructure autohébergée tenue par une seule personne n'a pas de faiblesse technique plus grave que cette personne elle-même. Sauvegardes, mises à jour, surveillance et documentation ne valent que si elles survivent à son absence, qu'elle dure une semaine ou toujours.

Mis à jour le 25 septembre 2026~24 min de lecture13 sections

papy cyber

→ Lire l’explication complète de la marmotte

Le serveur dans le placard

Il existe, dans un nombre croissant de foyers, d’associations et de petites structures, un objet discret qui ronronne dans un placard, sous un bureau ou derrière une box. Il héberge la messagerie, les photos de famille, les documents comptables, le site de l’association, le gestionnaire de mots de passe, parfois la domotique, et souvent une demi-douzaine de services dont on a oublié à quoi ils servaient mais qu’on n’ose plus éteindre. Il fonctionne. Il fonctionne même très bien, et depuis longtemps.

Derrière lui, il y a une personne. Une seule. Elle l’a installé, elle le met à jour, elle sait où sont les sauvegardes, elle connaît les mots de passe, elle a en tête la raison pour laquelle telle règle de pare-feu est écrite ainsi et pas autrement. Elle est à la fois l’architecte, l’exploitant, le support, le responsable de la sécurité et le directeur des achats. Elle cumule ces fonctions avec une aisance qui ferait pâlir un organigramme, et sans la moindre ligne de budget.

Cet éditorial ne conteste pas l’intérêt de cet objet. L’autohébergement a d’excellentes raisons d’exister, et ce site lui-même, sa page de présentation le dit sans détour, est tenu par une seule personne. Je m’abstiendrai donc de toute leçon de haut : je parle depuis l’intérieur du problème, et je ne prétendrai pas l’avoir résolu. Ce serait une anecdote, et elle serait peut-être fausse.

La thèse est simple et peu confortable : dans une infrastructure tenue par une seule personne, le composant le moins redondant, le moins documenté et le moins surveillé est la personne. Tous les efforts techniques (disques en miroir, sauvegardes chiffrées, mises à jour automatiques) protègent l’infrastructure contre les défaillances du matériel. Presque aucun ne la protège contre la défaillance de celui qui la tient. Et cette défaillance-là n’est pas une hypothèse d’école : elle est, à terme, la seule certitude de l’éditorial.

Ce qu’on achète en s’hébergeant soi-même

On s’autohéberge pour de bonnes raisons : garder la maîtrise de ses données, ne pas dépendre d’un fournisseur dont les conditions changent au gré des trimestres, apprendre, et parfois économiser. On s’autohéberge aussi pour de moins bonnes raisons, comme le plaisir de posséder un objet qui clignote, mais la morale n’a pas à trancher entre les deux.

Ce qu’on achète réellement est moins souvent formulé. On devient son propre prestataire, sans contrat, sans astreinte, et sans successeur. Tout ce qu’un fournisseur de service fait en coulisse (surveiller, corriger, sauvegarder, renouveler, documenter, remplacer l’employé malade) devient une tâche personnelle. La liberté est réelle ; elle se paie en travail, et ce travail a la particularité de n’être visible que lorsqu’il n’est pas fait.

Le mouvement dit local-first a le mérite de poser correctement la question de la propriété des données. Il ne dispense personne de la question suivante, qui est celle de leur continuité : posséder ses données, c’est aussi posséder la responsabilité de leur survie, y compris à soi-même.

Il faut aussi admettre qu’une infrastructure personnelle a une tendance naturelle à grossir. On installe un service pour un besoin, puis un second parce que la machine a de la place, puis un troisième parce qu’un article l’a recommandé. Chaque ajout est raisonnable. L’ensemble finit par former un système dont une seule personne connaît la totalité, et encore, à condition qu’elle ait bonne mémoire. La complexité d’une infrastructure personnelle ne se mesure pas au nombre de services, mais au nombre de choses qu’il faudrait expliquer à quelqu’un d’autre. Ce nombre croît sans bruit, et personne ne le compte.

Les sauvegardes, ou l’art de ne pas savoir

Tout le monde sauvegarde. C’est du moins ce que tout le monde dit, avec la sincérité de celui qui a configuré un jour une tâche planifiée et n’y a plus touché depuis.

La règle dite du 3-2-1 est connue : trois copies des données, sur deux supports différents, dont une hors du site. Elle est bonne. Elle a toutefois le défaut de décrire des copies, pas des restaurations, et c’est la seconde chose qui compte. Une sauvegarde qu’on n’a jamais restaurée n’est pas une sauvegarde : c’est une hypothèse. Elle peut être incomplète, corrompue, chiffrée avec une clé perdue, faite depuis un répertoire vide depuis le dernier changement de chemin. On ne le saura que le jour où l’on en aura besoin, ce qui est, de tous les jours possibles, le plus mal choisi pour l’apprendre.

Il faut ensuite distinguer trois menaces contre lesquelles une sauvegarde protège, parce qu’elles n’appellent pas la même réponse.

La panne matérielle. Un disque meurt, une alimentation grille. Contre elle, presque tout fonctionne, y compris une simple copie sur un autre disque de la même machine. C’est la menace à laquelle tout le monde pense, et la moins intéressante.

L’erreur humaine. On efface le mauvais répertoire, on écrase un fichier, une mise à jour corrompt une base. Contre elle, une copie synchronisée ne sert à rien, puisqu’elle réplique fidèlement l’erreur, avec un zèle digne d’une meilleure cause. Il faut des versions : pouvoir revenir à l’état d’hier, de la semaine dernière, du mois dernier.

La compromission. Un logiciel de rançon chiffre les données, et avec elles toutes les sauvegardes qu’il peut atteindre. Or il peut atteindre tout ce que la machine compromise peut écrire. Contre lui, il faut au moins une copie que la machine sauvegardée ne peut pas modifier : hors ligne, ou sur un stockage qui refuse l’effacement pendant une durée donnée, ou tirée par un système distant plutôt que poussée par la machine source. Une sauvegarde que l’attaquant peut effacer avec les droits dont il dispose est une sauvegarde qu’il effacera.

Ces trois menaces se traitent ensemble, et la continuité d’activité d’une grande organisation ne pose pas d’autres questions ; elle a seulement plus de monde pour y répondre.

Reste la vérification, qu’on peut mener en lecture seule avec la plupart des outils de sauvegarde courants. À titre d’exemple, et en adaptant à l’outil réellement utilisé :

# Lister les instantanés disponibles et leur date (lecture seule)
restic snapshots
# ou, pour Borg
borg list /chemin/vers/le/depot

# Vérifier la cohérence du dépôt (lecture seule ; peut être long)
restic check
borg check /chemin/vers/le/depot

Ces commandes disent que les sauvegardes existent et sont cohérentes. Elles ne disent pas qu’elles contiennent ce qu’il faut. Pour cela, il n’y a qu’un moyen : restaurer, régulièrement, dans un répertoire temporaire ou sur une autre machine, et vérifier qu’on retrouve un fichier précis, une base qui démarre, un service qui répond. Le reste est de la foi, et la foi est une vertu théologale, pas une stratégie de continuité.

Les secrets n’ont rien à faire dans les sauvegardes

Une infrastructure contient des secrets : clés privées, jetons d’accès, mots de passe de bases, clés d’API des services externes. Une sauvegarde complète les contient aussi, et c’est là que commence un paradoxe que la plupart des installations résolvent par l’oubli.

Le premier réflexe est de tout sauvegarder, secrets compris, puisqu’on en aura besoin pour restaurer. Le résultat est qu’une copie de toutes les clés de l’infrastructure dort sur un disque externe, chez un hébergeur de stockage, ou sur la machine d’un proche, avec une protection égale à celle de ce support, c’est-à-dire variable. Quiconque obtient la sauvegarde obtient l’infrastructure, et les sauvegardes sont, par construction, l’objet qu’on copie le plus et qu’on range le plus loin.

Le second réflexe est de chiffrer les sauvegardes. C’est indispensable, et les principes du chiffrement des données au repos s’y appliquent entièrement. Mais cela déplace la question sans la résoudre : où est la clé de chiffrement des sauvegardes ? Si elle est dans la sauvegarde, elle ne protège rien. Si elle est seulement sur la machine sauvegardée, elle disparaît avec elle, le jour exact où l’on en a besoin. C’est l’une des manières les plus élégantes de perdre ses données : les avoir parfaitement sauvegardées, parfaitement chiffrées, et parfaitement illisibles.

La réponse tient en une séparation. Les données se sauvegardent ; les secrets se gèrent. Les secrets de fonctionnement (jetons, mots de passe de services) ont vocation à être régénérés plutôt que restaurés quand c’est possible, et à vivre dans un coffre dédié plutôt que dans des fichiers de configuration dispersés ; les pages sur l’exploitation des clés et des secrets décrivent ce cycle de vie. La clé des sauvegardes, elle, est le secret racine : elle doit exister hors de l’infrastructure, sous une forme qui survive à la perte totale de celle-ci, par exemple sur papier dans un lieu sûr, ou dans un coffre de mots de passe distinct dont l’accès ne dépend pas du serveur.

Il faut le dire clairement : cette séparation a un coût. Elle oblige à tenir un inventaire des secrets, à savoir lesquels se régénèrent et lesquels ne se régénèrent pas, et à tester qu’une restauration fonctionne sans avoir accès à la machine d’origine. C’est précisément ce test qui révèle, en général, qu’on avait oublié un secret quelque part. Mieux vaut l’apprendre un dimanche tranquille qu’un lundi dévasté.

Les mises à jour, ce contrat qu’on a signé sans le lire

Chaque service installé est un contrat implicite avec le temps. Il faudra le mettre à jour, parce que des vulnérabilités y seront découvertes, régulièrement, pendant toute sa vie. Personne ne signe ce contrat en connaissance de cause ; on le découvre en cours d’exécution, comme la plupart des contrats d’assurance.

Pour une personne seule, la tension est connue. Mettre à jour automatiquement, c’est risquer qu’une mise à jour casse un service pendant la nuit. Ne pas mettre à jour, c’est risquer qu’une vulnérabilité soit exploitée pendant qu’on dort. Le premier risque est visible, bruyant et immédiat ; le second est silencieux, et c’est pour cela qu’on le préfère, à tort.

L’équilibre raisonnable me semble être le suivant. Les correctifs de sécurité du système de base s’appliquent automatiquement : les distributions courantes proposent ce mécanisme (sur Debian et ses dérivées, le paquet unattended-upgrades), et il est conçu pour ne toucher qu’à ce qui est jugé sûr. Les applications exposées sur Internet se mettent à jour vite, à la main s’il le faut, en suivant leurs annonces de sécurité. Le reste se met à jour selon un calendrier fixe, un jour choisi, avec une sauvegarde vérifiée juste avant.

# Ce qui attend une mise à jour (lecture seule, Debian et dérivées)
apt list --upgradable 2>/dev/null
# Les tâches planifiées qui tournent réellement, dont les mises à jour automatiques
systemctl list-timers --all

Il y a surtout une règle qui vaut plus que toutes les autres : chaque service installé doit avoir une raison d’exister, et ceux qui n’en ont plus doivent être éteints. Le correctif le plus sûr est celui qu’on n’a pas besoin d’appliquer parce que le logiciel n’est plus là. Une infrastructure personnelle gagne presque toujours à perdre du poids, et presque jamais à en prendre. On entretient un jardin en arrachant autant qu’en plantant ; on entretient un serveur de la même manière, avec moins de ronces mais autant d’épines.

Une surveillance à la mesure d’une seule paire d’yeux

La surveillance d’une infrastructure personnelle tombe presque toujours dans l’un de deux excès. Soit il n’y en a pas, et l’on découvre les pannes quand un proche signale que « le site ne marche plus » depuis une semaine. Soit il y en a trop, et l’on reçoit tant de notifications qu’on a fini par les ignorer toutes, ce qui revient au même avec plus d’efforts. Ce second travers a fait l’objet d’un éditorial entier, et sa conclusion vaut ici au centuple, puisqu’il n’y a personne d’autre pour lire.

Une surveillance minimale tient en peu de conditions, et elles sont presque toujours les mêmes.

Les sauvegardes ont-elles tourné et réussi cette nuit ? C’est la seule alerte qui mérite d’être lue le matin même.

Les services exposés répondent-ils ? Vérifié de l’extérieur, pas depuis la machine elle-même, qui aura toujours une excellente opinion de sa propre disponibilité.

Les certificats et les noms de domaine expirent-ils bientôt, et leur renouvellement automatique a-t-il échoué ? Deux échéances qui ne pardonnent pas, parce qu’elles surviennent à date fixe et que leur échec est total.

Les disques sont-ils sains et suffisamment libres ? Avec un seuil qui laisse le temps d’agir, pas un seuil qui prévient que c’est trop tard.

Le système de surveillance lui-même est-il vivant ? C’est la condition qu’on oublie toujours. Une surveillance tombée en panne ne dit rien, et le silence ressemble à s’y méprendre à la bonne santé. La seule parade est un signal de vie : un message attendu à intervalle régulier, reçu par un service extérieur, et dont l’absence déclenche l’alerte.

# Date d'expiration d'un certificat local (lecture seule)
openssl x509 -enddate -noout -in /chemin/vers/certificat.pem
# Date d'expiration d'un nom de domaine, selon ce que publie le registre
whois example.org | grep -iE 'expir|paid-till'

Tout le reste relève du rapport périodique, lu à tête reposée, et non de l’alerte. Et si ce rapport n’est jamais lu, il faut avoir l’honnêteté de s’en apercevoir, puis de le supprimer ou de le raccourcir jusqu’à ce qu’il le soit. Quant aux journaux, ils servent à comprendre après coup ce que la surveillance a signalé ; ils ne remplacent pas la surveillance, et la question de savoir s’ils répondraient vraiment à une enquête est traitée dans un autre dossier.

Documenter pour l’inconnu qu’on sera

La personne qui tient une infrastructure seule croit souvent qu’elle n’a pas besoin de documentation, puisqu’elle sait. C’est vrai le jour où elle installe. C’est déjà moins vrai six mois plus tard, et c’est tout à fait faux trois ans après, quand il faut migrer un service configuré un soir de fatigue selon un tutoriel disparu depuis.

La première personne qui lira votre documentation, c’est vous, dans l’état où vous serez ce jour-là. Pas vous au sommet de votre forme, reposé, le contexte en tête : vous pressé, inquiet, peut-être malade, en train de réparer quelque chose qui vient de casser. Écrire pour ce lecteur-là change tout. On cesse de noter ce qui paraît évident, parce que l’évidence ne survit pas au temps. On note les raisons autant que les commandes, parce qu’une commande sans sa raison ne dit pas si elle est encore valable.

Une documentation utile pour une personne seule n’a pas besoin d’être longue. Elle a besoin de répondre à quelques questions dans l’ordre où on les pose en situation de crise.

Qu’est-ce qui tourne, où, et pourquoi ? L’inventaire des machines, des services et de leur raison d’être. Ce qui n’a pas de raison écrite est un candidat à l’extinction.

Comment on restaure ? Pas « les sauvegardes sont sur tel support » : la procédure, pas à pas, depuis une machine vierge. Et la date de la dernière fois qu’elle a été suivie pour de vrai.

Où sont les secrets, et qui peut y accéder ? Pas les secrets eux-mêmes, évidemment : leur emplacement, la manière d’y accéder, ce qui dépend de quoi.

Qu’est-ce qui dépend de l’extérieur ? Nom de domaine et registraire, hébergeur éventuel, fournisseur d’accès, service de messagerie de secours, moyens de paiement associés, échéances. C’est la partie la plus souvent absente, et celle qui provoque les pannes les plus sottes.

Que faut-il faire si je ne suis pas là ? Nous y venons.

Cette documentation doit vivre hors de l’infrastructure qu’elle décrit. Une procédure de restauration stockée uniquement sur le serveur à restaurer est un chef-d’œuvre d’ironie, mais c’est le seul usage qu’on puisse lui trouver. Une copie imprimée, rangée avec la clé racine, est une technologie ancienne, robuste et remarquablement peu sensible aux pannes de courant.

Le facteur d’autobus égal à un

Le facteur d’autobus d’un projet désigne, avec la délicatesse habituelle des informaticiens, le nombre de personnes qui devraient disparaître brusquement pour que le projet ne puisse plus continuer. Dans une infrastructure tenue par une seule personne, il vaut un. C’est sa définition même, et aucune technique ne le fera passer à deux ; seule une autre personne le peut.

L’autobus, heureusement, est rarement un autobus. Les absences ordinaires sont bien plus fréquentes que les tragédies, et c’est par elles qu’il faut commencer. Une hospitalisation de quelques semaines. Un séjour loin de tout réseau. Un changement de vie qui fait qu’on n’a plus ni le temps ni l’envie. Une fatigue qui fait qu’on laisse filer. Dans chacun de ces cas, l’infrastructure continue de tourner quelque temps sur son élan, puis quelque chose arrive à échéance : un certificat, un disque, un nom de domaine, une carte bancaire. Et personne d’autre ne sait quoi faire.

Il faut regarder en face ce qui se passe ensuite, parce que le scénario est d’une banalité administrative accablante.

Le nom de domaine arrive à expiration et n’est pas renouvelé ; après un délai qui varie selon les registres et les registraires, il peut être racheté par n’importe qui, y compris par quelqu’un qui recevra désormais le courrier adressé à l’ancien propriétaire. La carte bancaire associée à l’hébergement expire, et le service est suspendu. La messagerie tombe, et avec elle la possibilité de réinitialiser les mots de passe de tous les comptes qui y étaient rattachés. Les photos de famille sont sur un disque chiffré dont la clé était dans une tête. Rien de tout cela n’est une attaque. C’est simplement ce que fait une infrastructure quand plus personne ne la tient : elle s’éteint, dans un ordre qu’aucun plan n’a prévu.

On ne peut pas supprimer ce risque. On peut le transformer en procédure.

Nommer quelqu’un. Une personne de confiance, pas nécessairement technicienne, qui sait que l’infrastructure existe, ce qu’elle contient d’important, et où trouver les instructions. Ce n’est pas un administrateur de secours ; c’est un exécuteur, au sens le plus littéral.

Écrire la lettre. Un document court, en langage courant, qui dit ce qui compte (les photos, les documents, la messagerie, le site de l’association), ce qui peut être abandonné sans regret, et comment récupérer le premier avant d’éteindre le second. Il ne s’agit pas de transmettre l’exploitation : il s’agit de permettre une extinction ordonnée, ou une transmission à quelqu’un de compétent. Dans la plupart des cas, la bonne décision pour ceux qui restent sera de migrer les données vers un service tenu par d’autres, et c’est très bien ainsi.

Rendre les secrets accessibles, mais pas trop. C’est la partie délicate, parce qu’un secret accessible à un proche est aussi un secret accessible à quiconque accède à ce proche. Plusieurs mécanismes existent : une enveloppe scellée chez un tiers de confiance ; les fonctions d’accès d’urgence que proposent certains gestionnaires de mots de passe, qui ouvrent l’accès après un délai pendant lequel le titulaire peut encore s’y opposer ; ou le partage de secret à seuil, qui découpe la clé en fragments dont un nombre minimal doit être réuni pour la reconstituer, de sorte qu’aucun détenteur isolé ne puisse agir seul. Aucun n’est parfait. Tous sont meilleurs que la mémoire d’une seule personne.

Penser au droit. Le droit français permet, à ma connaissance, de laisser des directives sur le sort de ses données personnelles après son décès, et les grands services en ligne proposent souvent leurs propres mécanismes de gestion des comptes inactifs ou de contact légataire. Le détail juridique évolue et dépasse ma compétence : c’est à vérifier auprès des sources officielles et, pour les situations qui le justifient, auprès de gens dont c’est le métier.

Tester, encore. Une procédure de succession qu’on n’a jamais essayée vaut une sauvegarde jamais restaurée. On peut demander à la personne désignée de suivre la lettre, un après-midi, jusqu’au point où elle retrouverait les photos. Elle butera sur quelque chose. C’est le but.

Le meilleur argument contre

La thèse adverse est simple, et elle a le mérite de la cohérence : si le problème est la personne unique, la solution est de ne pas s’autohéberger. Confier sa messagerie, ses fichiers et son site à des fournisseurs professionnels, c’est acheter précisément ce qui manque à l’infrastructure personnelle : des équipes, des astreintes, des procédures, de la redondance humaine. Le facteur d’autobus d’un grand fournisseur n’est pas un. Ses sauvegardes sont testées par des gens payés pour cela. Ses mises à jour ne dépendent pas de la santé d’un individu. Et le jour où le titulaire disparaît, ses proches ont affaire à un service client, ce qui est rarement une partie de plaisir, mais reste une procédure existante.

L’argument est fort, et pour beaucoup de gens, il est juste. Je ne conseillerais pas à quelqu’un qui n’a ni le goût ni le temps de tenir une infrastructure de s’y mettre par principe. La souveraineté qu’on n’a pas les moyens d’entretenir est une fragilité qu’on s’offre.

Il déplace pourtant le risque plus qu’il ne le supprime. Le fournisseur a un facteur d’autobus élevé, mais un facteur de politique commerciale que personne ne maîtrise : il peut changer ses tarifs, fermer un service, suspendre un compte sur décision automatique sans recours clair, ou disparaître. Le titulaire unique d’un compte chez un grand fournisseur est lui aussi un point de défaillance unique : ses proches n’auront pas plus accès à ce compte qu’au serveur du placard, si rien n’a été prévu. L’identifiant, le second facteur, le téléphone qui le reçoit : tout cela est aussi personnel qu’une clé de chiffrement.

La conclusion honnête est que la question de la succession se pose dans les deux cas, sous des formes différentes. L’autohébergement la rend plus visible, parce qu’on voit la machine ; la délégation la rend plus discrète, parce qu’on ne voit qu’un écran de connexion. Dans les deux cas, il faut une lettre, un inventaire et quelqu’un qui sait. La vraie différence est ailleurs : chez un fournisseur, la continuité technique est assurée par d’autres ; chez soi, elle ne l’est par personne tant qu’on ne l’a pas organisée. Un compromis fréquent, et raisonnable, consiste à autohéberger ce qu’on peut perdre sans drame et à déléguer ce qui ne supporte aucune interruption, en commençant souvent par la messagerie, parce qu’elle est la clé de tout le reste.

Ce que je ne sais pas

Je ne sais pas comment faire passer le facteur d’autobus à deux sans une seconde personne compétente et motivée. Toutes les mesures décrites ici réduisent les dégâts d’une absence ; aucune ne remplace un second exploitant. Pour la plupart des infrastructures personnelles, ce second exploitant n’existe pas, et je n’ai pas de solution à proposer, seulement des manières de mourir, si l’on ose dire, plus proprement.

Je ne sais pas quelle est la bonne fréquence des tests. Restaurer une fois par an, relire la lettre une fois par an, faire l’exercice de l’absence une fois par an : ce sont des conventions, pas des résultats. Elles dépendent de la vitesse à laquelle l’infrastructure change, et je n’ai aucune mesure qui permette de les fixer mieux.

Je ne connais pas bien le droit applicable. J’ai mentionné l’existence de directives sur les données après décès et de mécanismes proposés par les services en ligne. Je ne sais pas précisément comment ils s’articulent avec des données autohébergées, chiffrées, dont la clé est détenue par un tiers. C’est une question pour des juristes, et je la leur laisse volontiers.

Je ne sais pas si l’automatisation aide ou aggrave. Décrire l’infrastructure en fichiers de configuration reproductibles facilite la reconstruction par quelqu’un de compétent. Elle rend aussi le système plus opaque pour quelqu’un qui ne l’est pas. Pour un successeur technicien, c’est un cadeau ; pour un héritier qui veut seulement récupérer des photos, c’est un grimoire. Je penche pour l’automatisation accompagnée d’une lettre en français courant, sans être certain que ce soit le bon équilibre.

Ce qui reste

Une infrastructure tenue par une seule personne peut être remarquablement fiable, bien conçue, bien sauvegardée, bien mise à jour. Elle reste suspendue à un fil, et ce fil est une vie humaine, avec ses absences, ses fatigues et sa fin.

Trois choses me semblent acquises. Que les sauvegardes, les mises à jour et la surveillance ne valent que testées, et que le test doit inclure le cas où l’on n’a plus accès à la machine d’origine. Que les secrets se gèrent à part des données, et que la clé racine doit survivre à la fois à l’infrastructure et à celui qui l’a créée. Et que le jour où la personne n’est plus là n’est pas une hypothèse à écarter mais une échéance à préparer, comme on prépare le renouvellement d’un certificat, avec moins de régularité mais plus de conséquences.

Le reste est une affaire de modestie. Documenter pour l’inconnu qu’on sera. Éteindre ce qui ne sert plus. Écrire la lettre. Désigner quelqu’un. Accepter que la meilleure issue, pour ceux qui restent, soit peut-être d’éteindre proprement ce qu’on a mis des années à construire.

On passe beaucoup de temps à rendre une infrastructure résistante aux pannes. On en passe très peu à la rendre résistante à son propre auteur, qui est pourtant le seul composant dont la fin de support soit certaine, à défaut d’être datée.

🐝 Ce qui arrive si on s’en passe

Laisser une infrastructure reposer sur une seule personne sans rien préparer produit un effet particulier pendant ses absences : la sécurité se fige à la date du départ. Une application exposée à Internet reste dans la version de ce jour-là pendant que ses vulnérabilités sont publiées, et les alertes, s’il y en a, arrivent dans une boîte que personne ne lit. Une compromission survenue dans l’intervalle n’est constatée par personne ; au retour, impossible de dater l’intrusion, donc de savoir quelle sauvegarde est saine et laquelle contient déjà l’intrus. Restaurer devient alors un pari, ce qui est une manière coûteuse de découvrir que la documentation se trouvait sur le serveur compromis.

🦫 Explication de la marmotte 🍫

Certaines personnes font fonctionner chez elles, ou pour une association, un ordinateur allumé en permanence qui garde la messagerie, les photos, les documents ou un site. Une seule personne l’installe, le répare et connaît ses mots de passe. Le texte décrit quatre tâches et ce qui se passe quand elles ne sont pas faites. Les sauvegardes doivent exister en plusieurs copies, conserver d’anciennes versions pour réparer une erreur, et inclure une copie qu’un programme malveillant ne peut pas effacer ; surtout, il faut régulièrement essayer de restaurer pour vérifier qu’elles contiennent bien les données. Elles sont chiffrées, et la clé de ce chiffrement doit être rangée en dehors de la machine, sinon elle disparaît avec elle. Les mises à jour corrigent les failles découvertes ; sans elles, un service visible depuis Internet devient attaquable. La surveillance vérifie chaque jour que les sauvegardes ont réussi, que les services répondent, que les certificats des sites et le nom de domaine ne vont pas expirer, et qu’elle-même fonctionne encore. Enfin, si la personne disparaît ou s’absente longtemps, des échéances tombent : le nom de domaine expire et peut être racheté, l’hébergement est suspendu, la messagerie s’arrête, et une clé connue d’elle seule rend les données illisibles. Il faut donc une documentation rangée hors de la machine, une personne de confiance désignée, une lettre simple et des secrets accessibles sous conditions.

Pages voisines

La citent

Une infrastructure tenue par une seule personne

Elle cite

: les deux pages se citent l’une l’autre.

Une infrastructure tenue par une seule personne

Le serveur dans le placard

Ce qu’on achète en s’hébergeant soi-même

Les sauvegardes, ou l’art de ne pas savoir

Les secrets n’ont rien à faire dans les sauvegardes

Les mises à jour, ce contrat qu’on a signé sans le lire

Une surveillance à la mesure d’une seule paire d’yeux

Documenter pour l’inconnu qu’on sera

Le facteur d’autobus égal à un

Le meilleur argument contre

Ce que je ne sais pas

Ce qui reste

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines