Accès à l'interface de l'hébergeur : qui détient le compte, et ce qui bloque quand personne ne l'a
Un serveur dédié tombe un dimanche, un reverse est mal réglé, une pièce doit être commandée : les trois gestes passent par le même endroit, l'interface du fournisseur de la machine. Si le compte qui l'ouvre appartient à quelqu'un qui n'est plus là, rien ne se fait, et le diagnostic technique tourne à vide pendant des heures.
Ce que root ne peut pas faire
Un accès administrateur à la machine ne donne pas accès à tout. Il permet d'installer, de configurer, de redémarrer un service ; il ne permet ni de modifier l'enregistrement inverse d'une adresse IP, ni d'ouvrir une console lorsque le réseau ne répond plus, ni de commander un disque, ni de changer une adresse, ni de régler le filtrage d'une attaque volumétrique. Ces gestes appartiennent au fournisseur de la machine, et passent par son interface.
La panne typique commence donc ailleurs que sur le serveur. Un reverse mal réglé fait rejeter les courriels ; une machine inaccessible par le réseau exige une console ; un disque mort exige une commande. Dans les trois cas, quelqu'un doit ouvrir une session sur un site web, s'authentifier, et parler au nom du contrat. Si ce quelqu'un n'existe pas, l'incident technique devient une négociation administrative.
C'est aussi ce qui sépare constater et agir. L'exploitant qui n'a pas le compte peut diagnostiquer, documenter, prévenir ; il ne peut ni déclencher le remplacement, ni obtenir la console, ni faire modifier le reverse. Le délai de remplacement d'une pièce dépend alors d'un tiers qui n'est pas dans la boucle, et personne ne peut le relancer.
À lire aussi : le délai de remplacement d'une pièce.
Trois rôles derrière un identifiant
Derrière un identifiant unique se cachent en réalité trois fonctions distinctes, qu'il vaut mieux séparer. Le titulaire est celui qui a signé : il porte la facturation, l'engagement et la propriété du contrat. L'administrateur dispose des droits techniques : commandes, console, réseau. Le contact d'urgence, enfin, est la personne qu'on appelle quand plus rien ne fonctionne, et qui doit être joignable autrement que par le service concerné.
Confondre les trois dans une seule personne produit une dépendance invisible. Un départ, une maladie, un changement de prestataire, et l'ensemble des droits disparaît avec l'adresse électronique associée au compte. Le cas classique est celui du compte ouvert par celui qui a vendu la machine, avec une adresse de messagerie hébergée sur cette même machine : le serveur tombe, la boîte tombe, la réinitialisation du mot de passe n'arrive plus.
La sortie de cette impasse ne s'improvise pas pendant l'incident. Elle se prépare : un second administrateur nommé, une adresse de secours hors du domaine concerné, et une procédure écrite de récupération, testée avant d'être nécessaire. Le reste relève du contrat, et des trois responsabilités superposées qu'il doit nommer.
À lire aussi : les trois responsabilités superposées.
Un compte par personne, pas un compte pour tous
La CNIL demande un identifiant unique par utilisateur et recommande de désactiver les comptes définis par défaut. Elle rappelle que l'authentification multifacteur protège mieux qu'un mot de passe seul, et fixe une entropie minimale de 80 bits par défaut, soit douze caractères mêlant majuscules, minuscules, chiffres et caractères spéciaux, avec un renouvellement périodique pour les administrateurs.
Ces règles ne sont pas de la paperasse : elles rendent l'incident lisible. Un compte partagé ne dit pas qui a commandé la réinstallation, qui a modifié le reverse, qui a ouvert le ticket. Le jour où une manipulation casse la production, personne ne peut reconstituer la séquence, et le doute se porte sur tout le monde. Un compte par personne, avec des rôles limités, transforme le journal en récit.
Le guide d'hygiène de l'ANSSI range ces mesures dans un socle de quarante-deux pratiques, et les présente comme un minimum. Sur un serveur dédié, ce minimum se traduit par deux administrateurs au moins, un second facteur pour chacun, et une liste de qui peut faire quoi. La commande de pièce mérite sa propre ligne : un droit technique n'implique pas un droit de dépense.
Le domaine n'est pas le serveur
Le serveur n'est pas le seul objet à détenir. Le nom de domaine s'enregistre chez un bureau d'enregistrement, avec son propre compte, son propre contact et son propre renouvellement. La zone DNS peut vivre chez ce bureau, chez l'hébergeur, ou chez un troisième acteur. Trois comptes, trois détenteurs possibles, et un seul point de rupture : celui qui a disparu.
L'annuaire public aide à savoir où l'on se trouve, mais pas qui détient le compte. Une requête RDAP renvoie le bureau d'enregistrement, les serveurs de noms et des entités de contact ; elle ne dit pas qui possède l'identifiant client, ni qui peut demander un code de transfert. Cette information n'existe que dans la relation commerciale, donc dans le contrat et dans la boîte électronique du titulaire.
Perdre la main sur le domaine coupe plus large que perdre un serveur : messagerie, sous-domaines, jetons de vérification chez des tiers, redirections, certificats. Un domaine qui expire parce que la carte bancaire du titulaire n'était plus valide ne se répare pas par un redémarrage, et le délai de récupération dépend d'une procédure qui n'appartient pas au client.
Le reverse DNS, cas d'école
Le reverse DNS est l'exemple parfait, parce qu'il reste invisible jusqu'au jour où il casse. L'enregistrement inverse ne se trouve pas dans la zone du domaine : il vit dans une zone construite à partir de l'adresse IP, et administrée par celui à qui l'espace d'adresses a été attribué. Le client qui loue une machine n'en est pas propriétaire, même s'il en paie l'usage.
La délégation de ces zones a ses contraintes. Le RFC 2317 décrit comment déléguer un espace plus petit qu'un bloc complet ; il rappelle surtout qu'une zone ne peut être déléguée qu'une seule fois. Autrement dit, soit le fournisseur garde la main et modifie les enregistrements sur demande, soit il délègue et le client administre. Il n'y a pas de troisième voie.
Sans délégation, chaque changement passe par l'interface, donc par le compte. Un envoi depuis une adresse sans reverse cohérent finit filtré, et le symptôme est déroutant : le serveur fonctionne, le message part, il n'arrive pas. La question à poser au contrat n'est pas seulement qui modifie l'enregistrement, mais en combien de temps et par quel canal, y compris un jour non ouvré.
La liste à écrire avant d'en avoir besoin
La liste utile tient sur une page et se remplit à froid. Adresse de l'interface, identifiant du titulaire, second administrateur, adresse de secours hors du domaine, codes de récupération du second facteur conservés hors ligne. Puis le bureau d'enregistrement, le contact de renouvellement, le code de transfert, et l'endroit où vit la zone DNS.
Vient ensuite ce qui se teste. Ouvrir réellement la console de secours sur la machine, redémarrer par ce canal, demander une modification de reverse et mesurer le délai, vérifier qu'un ticket matériel peut être ouvert par une deuxième personne. Un droit non exercé n'est pas un droit acquis : il se découvre inopérant le jour précis où il faudrait l'appliquer.
Reste la sortie. Une clause de fin de contrat utile ne parle pas seulement de données : elle prévoit le transfert de la propriété du compte, la remise des accès, la conservation du reverse et de la zone pendant la transition. Dans un contexte insulaire, ces démarches prennent des jours ; les écrire évite qu'elles se transforment en semaines, faute de savoir qui doit signer.