Le compte principal chez l'hébergeur : propriété, double authentification et accès délégués
Un serveur dédié se loue avec un compte client, pas avec un service d'exploitation. Ce compte porte le contrat, la facturation, les moyens de récupération, et la capacité de réinstaller ou de résilier la machine. Qui le détient détient le serveur, même s'il ne sait pas redémarrer un service. Ce site est indépendant : OVH SAS n'est ni partenaire, ni commanditaire, ni relecteur de ces pages ; les conditions décrites sont celles de l'hébergeur, jamais un engagement du site envers le lecteur.
Le compte chez l'hébergeur n'est pas un compte partagé
Chez un hébergeur d'infrastructure, la machine livrée est rattachée à un compte client, souvent appelé identifiant client et composé de lettres et de chiffres. Ce compte n'est pas un compte d'administration du système : il ne donne pas un shell sur le serveur. Il donne la capacité de commander, de réinstaller, de redémarrer en mode de secours, de détacher une adresse réseau ou de résilier. La différence est de nature, pas de degré. Un accès système perdu se récupère avec l'aide de l'hébergeur et des sauvegardes ; un compte client perdu se récupère par une procédure d'identité.
Le rattachement est aussi juridique. Le contrat, les factures, les notifications de renouvellement et les demandes de support passent par les coordonnées enregistrées sur ce compte. Changer de titulaire n'est pas une case à cocher : la documentation de l'hébergeur décrit une procédure de changement de titulaire et de contacts, avec vérification d'identité et validation par les parties concernées. Une entreprise qui laisse ce compte au nom d'un ancien salarié, d'un dirigeant sortant ou d'un prestataire garde donc un serveur qu'elle paie sans pouvoir en disposer librement.
Trois contacts, un utilisateur principal, des utilisateurs locaux
Sur un service donné, la documentation distingue trois rôles de contact. Le contact administrateur gère les aspects administratifs et techniques et peut modifier les autres contacts, y compris les informations du titulaire. Le contact technique gère uniquement les aspects techniques. Le contact facturation gère les prélèvements et reçoit les notifications liées au renouvellement. Chaque contact est un identifiant client distinct, et un changement de contact passe par des validations croisées par courriel : l'ancien et le nouveau titulaire doivent confirmer.
À côté des contacts, le compte peut porter des utilisateurs locaux, avec trois niveaux prévus par défaut : lecture seule sur tout l'espace client, administrateur restreint qui écrit partout sauf dans la gestion des utilisateurs, et administrateur complet. L'identifiant de l'utilisateur reprend le numéro du compte et son nom, séparés par une barre oblique. Chaque utilisateur dispose de son propre mot de passe et peut activer sa propre double authentification, ce qui évite le partage d'identifiants — pratique que la documentation de l'hébergeur écarte explicitement.
La double authentification : deux facteurs, pas deux mots de passe
L'ANSSI définit l'authentification multifacteur par la combinaison d'au moins deux facteurs de nature différente : ce que je sais, ce que je possède, ce que je suis. Elle précise que cette combinaison n'apporte une réelle sécurité que si l'authentification par simple mot de passe devient impossible et si les facteurs proviennent de canaux indépendants. Deux mots de passe mémorisés, ou un mot de passe et sa variante, ne constituent donc pas deux facteurs : c'est le même secret, exposé deux fois.
Sa recommandation R36 demande au minimum deux facteurs pour les actions d'administration, avec pour facteur de possession une carte à puce ou un jeton USB. La recommandation R37 va plus loin et préconise des certificats électroniques délivrés par un prestataire qualifié. Sur un compte client d'hébergeur, l'offre est plus modeste : la documentation décrit trois méthodes — code envoyé par SMS, application à codes à usage unique, clé de sécurité U2F — et présente la clé physique comme le niveau le plus élevé, car elle repose sur un équipement séparé de l'ordinateur et du téléphone.
Perdre le téléphone ou la clé : prévoir la sortie de secours
La documentation prévoit dix codes de secours à usage unique, affichés lors de la première configuration. Ils complètent une méthode déjà active et ne peuvent pas être activés seuls ; il est conseillé de régénérer la liste avant de l'avoir épuisée. Ces codes sont souvent la seule voie de connexion si le téléphone est perdu, remplacé ou si la clé est détruite. Les conserver dans un coffre-fort de mots de passe, et non dans la messagerie du compte, est le minimum : une boîte compromise donnerait sinon l'accès au second facteur et à la procédure de récupération dans le même mouvement.
Passé ce filet, la sortie est administrative. La désactivation de la double authentification demande l'envoi de justificatifs d'identité depuis une adresse enregistrée sur le compte, puis une intervention manuelle du support ; la documentation précise que les documents doivent venir d'une adresse figurant sur le compte. Le changement d'adresse électronique principale suit une logique voisine : un code de validation accélère l'opération, sinon la modification s'applique d'elle-même après vingt-cinq heures. Autrement dit, récupérer un compte prend des jours et suppose une identité vérifiable : cela s'anticipe, cela ne se découvre pas un dimanche soir.
Déléguer un accès sans transmettre ses identifiants
Déléguer ne veut pas dire prêter. Trois mécanismes se combinent : un utilisateur local nominatif avec un niveau de droits choisi, une politique d'accès qui restreint les actions service par service en gardant la trace de qui fait quoi, et, pour les services eux-mêmes, des contacts distincts. Le mot de passe du titulaire et les codes de double authentification ne se transmettent à personne. L'ANSSI tranche dans le même sens avec des comptes d'administration individuels et dédiés, distincts des comptes d'usage courant, et des secrets différents selon le compte utilisé.
Le principe du moindre privilège s'applique tel quel : un développeur qui doit redémarrer un service n'a besoin ni de la gestion des utilisateurs, ni de la facturation ; un comptable n'a pas besoin d'atteindre la console. La recommandation R38 ajoute une exigence souvent oubliée : l'organisation doit pouvoir bloquer un compte rapidement, sur le plus grand nombre de ressources possible, en cas de compromission soupçonnée ou avérée. Un accès qu'on ne sait pas couper n'est pas un accès délégué, c'est un accès donné.
Ce qu'un prestataire doit détenir, et ce qu'il ne doit pas
Quand l'administration est confiée à un tiers, l'ANSSI consacre un chapitre entier au risque : l'accès à distance d'un prestataire est un vecteur majeur de compromission, d'autant que ses postes de travail ne sont pas maîtrisés par le client, et que la priorité donnée au rétablissement du service en cas de panne pousse parfois à élargir les accès au-delà du besoin. La recommandation R59 est de recourir, pour l'infogérance, à un prestataire qualifié PAMS ; la recommandation R60 de faire figurer les exigences de sécurité d'accès dans le contrat.
Pour un prestataire qui n'est pas qualifié, la recommandation est de traiter l'accès comme une exception encadrée : compte nominatif, droits limités au périmètre, journalisation, procédure de révocation écrite. Appliqué au compte client de l'hébergeur, cela donne une règle simple : le prestataire ne devrait pas en être le titulaire. Il peut y disposer d'un utilisateur local avec un rôle restreint, et le contrat devrait prévoir la restitution des accès et leur suppression à la fin de la mission, avec une preuve de cette suppression.
Tenir un registre des accès, et le relire
Ce qui n'est pas écrit n'est pas su. Un registre des accès tient sur une page : qui est titulaire du compte, quelle adresse électronique et quel numéro servent à la récupération, quelles méthodes de double authentification sont actives, où sont rangés les codes de secours, quels utilisateurs locaux existent avec quel rôle, quels contacts sont déclarés sur chaque service, et à quelle date la liste a été vérifiée pour la dernière fois.
La revue a deux vertus. Elle révèle les comptes oubliés — ceux d'un stagiaire parti, d'un ancien prestataire, d'un test de migration — que personne ne désactive. Elle rend possible une réponse rapide le jour où un téléphone disparaît : savoir immédiatement quelles méthodes retirer et quels accès couper vaut mieux que reconstituer l'historique sous pression. Le guide d'hygiène de l'ANSSI demande d'identifier nommément chaque personne et de distinguer les rôles d'utilisateur et d'administrateur, de privilégier une authentification forte, et de ne pas administrer depuis un poste qui navigue sur Internet. Trois règles simples, rarement tenues ensemble.
Trois questions à poser avant de signer
Trois questions suffisent à révéler la solidité d'une organisation. Première : au nom de qui le compte client est-il ouvert, et cette personne peut-elle encore en changer les coordonnées sans passer par vous ? Deuxième : où arrive le courriel de récupération, sachant que l'hébergeur déconseille de le placer sur un domaine géré depuis ce même compte, car une panne du domaine couperait aussi les notifications ? Troisième : que se passe-t-il à la fin du contrat — quels accès sont supprimés, dans quel délai, et qui vérifie ?
Les réponses n'ont pas besoin d'être parfaites pour être utiles ; elles doivent figurer quelque part, datées, et être relues à chaque départ. Un serveur bien administré, sur un compte dont le titulaire est injoignable, reste un serveur précaire : c'est le seul point de défaillance qui n'apparaît pas dans une supervision, et celui qu'aucune alerte ne signalera avant qu'il soit trop tard.