Propriété du site, nom de domaine et hébergement : les sécuriser avec une agence éloignée
Confier la création ou la maintenance d’un site à une agence située dans une autre ville, une autre région ou un autre pays ne pose pas, en...
Koxin
Confier la création ou la maintenance d’un site à une agence située dans une autre ville, une autre région ou un autre pays ne pose pas, en soi, de problème technique. La difficulté apparaît lorsque les comptes essentiels sont créés, conservés ou administrés par le prestataire sans organisation claire. Le propriétaire du site peut alors perdre l’accès au nom de domaine, à l’hébergement, aux boîtes mail, aux sauvegardes ou aux outils de mesure d’audience.
La sécurité repose donc sur une distinction fondamentale : l’agence peut disposer d’un accès de travail, mais elle ne doit pas devenir la seule détentrice des accès qui déterminent l’existence du site. Cette règle concerne aussi bien un site vitrine qu’une boutique en ligne, un extranet ou une application web.
Avant de signer une prestation, il faut identifier quatre éléments différents : le titulaire du nom de domaine, le propriétaire des comptes techniques, la personne qui contrôle les données et la personne qui peut modifier la configuration DNS. Ces rôles peuvent être assumés par une même structure, mais ils doivent être documentés et récupérables.
Le mot « site » désigne plusieurs composants qui ne sont pas soumis aux mêmes règles d’accès. Une page web est composée de fichiers, de bases de données, de contenus, de réglages et parfois de services externes. Chaque composant peut être hébergé ou administré dans un environnement différent.
Cette séparation permet de repérer les dépendances. Une agence peut héberger les fichiers, tandis que le domaine reste enregistré au nom du client. Dans une autre configuration, le domaine et l’hébergement peuvent être regroupés chez un même fournisseur. Dans les deux cas, les responsabilités et les procédures de récupération doivent être écrites.
Le titulaire d’un nom de domaine n’est pas nécessairement la personne qui a payé la facture ou qui a conçu le site. Lors de l’enregistrement, les informations du titulaire et du contact administratif ont une importance particulière. Si une agence utilise ses propres coordonnées, une relation de dépendance peut se créer au moment d’un changement de prestataire.
Le compte du domaine devrait être ouvert avec une adresse électronique contrôlée par le propriétaire du projet. Cette adresse doit rester accessible même si l’agence cesse son activité ou si la collaboration prend fin. Il faut aussi vérifier que le moyen de paiement et les notifications de renouvellement ne dépendent pas exclusivement du prestataire.
Une vérification utile consiste à relever les éléments suivants :
Le verrouillage du domaine, lorsqu’il est proposé par le bureau d’enregistrement, limite les transferts non autorisés. Il ne remplace pas l’authentification multifacteur, la surveillance des notifications et la conservation des codes de récupération. Les changements de titulaire ou de coordonnées peuvent aussi déclencher des procédures de vérification. Il est prudent de connaître ces conditions avant une urgence.
Un hébergement peut être administré par une interface web, un accès SSH, un compte FTP ou SFTP, une console de gestion de base de données et des clés d’API. Ces portes d’entrée n’ont pas toutes le même niveau de risque. Un compte partagé entre plusieurs intervenants rend les actions difficiles à attribuer et complique la révocation des droits.
Le propriétaire doit demander une liste des comptes actifs et de leurs permissions. Un développeur chargé du code n’a pas forcément besoin d’un accès à la facturation. Une personne qui intervient sur le contenu n’a pas besoin de pouvoir modifier les enregistrements DNS. Cette séparation applique le principe du moindre privilège : chaque compte dispose des droits nécessaires à sa mission, pendant la durée utile.
Les points à documenter comprennent :
Une sauvegarde visible dans une interface ne constitue pas une garantie suffisante. Elle doit pouvoir être téléchargée ou recopiée dans un environnement indépendant, puis restaurée selon une procédure connue. Une copie stockée sur le même compte que le site peut disparaître avec lui après une compromission ou une erreur de configuration.
Certains comptes donnent un contrôle transversal : bureau d’enregistrement, hébergeur, gestionnaire DNS, fournisseur de messagerie, dépôt de code, solution de paiement ou plateforme de sauvegarde. Ils doivent être identifiés comme des comptes maîtres. L’agence peut recevoir un compte nominatif ou un rôle délégué, mais la personne responsable du projet doit conserver un accès administrateur de secours.
Pour chaque compte maître, il faut appliquer une méthode homogène :
Le partage d’un mot de passe par courrier électronique ou messagerie instantanée doit être proscrit. Lorsqu’un accès doit être transmis, la création d’un compte individuel et temporaire offre une meilleure traçabilité. Les droits peuvent ensuite être retirés sans modifier le compte principal.
La sécurité technique ne compense pas une relation contractuelle imprécise. Le contrat ou le devis détaillé doit indiquer qui ouvre les comptes, au nom de qui ils sont enregistrés, qui paie les renouvellements et qui conserve les sauvegardes. Il doit aussi prévoir la restitution des éléments nécessaires en cas de fin de mission.
Une clause de réversibilité peut couvrir les points suivants :
Les droits sur le code, les textes, les images et les éléments graphiques méritent également une formulation précise. La propriété intellectuelle d’un livrable peut dépendre du contrat, de la nature de l’œuvre et des droits préexistants. Une licence d’utilisation, une cession de droits ou l’emploi de composants sous licence libre ne produisent pas les mêmes effets. Le document contractuel doit éviter les formulations générales qui laissent cette question ouverte.
Lorsque des données personnelles sont traitées, les responsabilités relatives à la protection des données doivent aussi être clarifiées. La CNIL recommande d’encadrer les relations avec les sous-traitants et de définir les mesures de sécurité, les instructions et les conditions de restitution ou de suppression des données.
Une agence éloignée a besoin d’accéder à certains outils pour corriger une anomalie, publier une évolution ou surveiller un service. Le bon réflexe consiste à organiser cet accès plutôt qu’à le refuser ou à transmettre les identifiants principaux.
Les accès distants devraient respecter plusieurs règles :
Pour les accès SSH ou aux bases de données, les clés individuelles sont préférables à un mot de passe partagé. La clé publique peut être ajoutée au serveur et retirée sans changer les autres accès. Les comptes techniques destinés aux déploiements automatisés doivent disposer de permissions réduites et de secrets stockés dans un coffre prévu à cet effet.
Un environnement de préproduction réduit aussi les risques. Une modification peut être vérifiée sur une copie avant sa mise en ligne. Les données de production ne doivent pas être recopiées vers un environnement de test sans analyse préalable, car elles peuvent contenir des informations personnelles ou confidentielles.
La gestion du nom de domaine ne se limite pas au renouvellement. Les enregistrements DNS contrôlent l’emplacement du site, les serveurs de messagerie et certaines validations de propriété. Une modification frauduleuse d’un enregistrement peut rediriger les visiteurs, interrompre les courriels ou permettre une attaque contre un service.
Un inventaire daté des enregistrements utiles doit être conservé. Il peut inclure les enregistrements A, AAAA, CNAME, MX, TXT et ceux dédiés à des services particuliers. Chaque entrée devrait avoir une justification compréhensible : site web, messagerie, validation, outil de diffusion ou service technique. Les entrées oubliées constituent un risque, notamment lorsqu’elles pointent vers une ressource supprimée.
La messagerie liée au domaine doit être traitée comme un compte critique. La perte de cette messagerie peut empêcher la récupération des autres comptes. Il est pertinent d’activer les protections disponibles contre l’usurpation, notamment les mécanismes SPF, DKIM et DMARC, après vérification de leur configuration. Une modification DNS doit être planifiée, documentée et contrôlée après propagation.
Le certificat TLS protège les échanges entre le navigateur et le serveur, mais sa présence ne prouve pas que le site est correctement administré. Il faut savoir qui le renouvelle, où sont conservées les clés privées et quelle alerte est déclenchée en cas d’échec. Les certificats et les clés ne doivent pas être envoyés dans des canaux non sécurisés.
Une stratégie de sauvegarde utile répond à trois questions : quoi sauvegarder, où placer les copies et comment restaurer le service. Les fichiers du site, les bases de données, les configurations DNS, les contenus déposés et les éléments indispensables au déploiement doivent être inventoriés.
La sauvegarde doit être indépendante du compte administré par l’agence. Une copie hors ligne ou isolée limite l’impact d’un rançongiciel, d’une suppression accidentelle ou d’une compromission des accès. Les accès au stockage des sauvegardes doivent être distincts de ceux de la production, avec des droits en écriture limités.
Une procédure de restauration peut être documentée sous forme de checklist :
Un test de restauration révèle les dépendances invisibles : clé d’API absente, version logicielle incompatible, certificat non disponible ou procédure connue par une seule personne. La fréquence du test dépend du niveau de criticité du site, de la fréquence des changements et de la tolérance à l’interruption.
La transition doit être préparée avant qu’un désaccord ou un incident ne survienne. Une réunion de sortie ne doit pas constituer le premier inventaire des accès. Le propriétaire peut conserver un registre indiquant le service, l’adresse de connexion, le responsable, le niveau de privilège, la méthode d’authentification et la date du dernier contrôle.
Lors d’un changement de prestataire, l’ordre des opérations compte :
Le renouvellement des mots de passe ne suffit pas si des clés SSH, des jetons d’API, des applications d’authentification ou des règles de transfert de messagerie restent actifs. L’inventaire doit couvrir ces mécanismes moins visibles. Une vérification des boîtes mail permet aussi de repérer les redirections automatiques et les délégations oubliées.
Une perte d’accès au site ou au domaine doit être traitée comme un incident, même si elle semble liée à une erreur de mot de passe. La priorité consiste à préserver les preuves et à reprendre le contrôle des comptes maîtres, sans multiplier les modifications non documentées.
Une séquence de réaction peut être organisée ainsi :
La CNIL rappelle que les violations de données personnelles doivent être analysées et, dans certaines situations, notifiées dans les délais prévus par le règlement général sur la protection des données. Cette évaluation doit s’appuyer sur les faits disponibles et sur les responsabilités définies dans le contrat.
| Élément | Contrôle à effectuer | Mesure attendue |
|---|---|---|
| Nom de domaine | Titulaire, adresse de récupération, expiration et verrouillage | Compte principal contrôlé par le propriétaire, renouvellement surveillé |
| DNS | Liste des enregistrements et responsables des modifications | Inventaire daté, accès limités et changements documentés |
| Hébergement | Comptes, rôles, consoles et accès techniques | Comptes individuels, moindre privilège et révocation possible |
| Code et contenus | Emplacement des sources, licences et exports | Copie exploitable détenue par le propriétaire |
| Sauvegardes | Fréquence, emplacement et restauration | Copie indépendante et test périodique |
| Messagerie | Comptes, redirections et récupération | Protection multifacteur et surveillance des règles |
| Contrat | Propriété, données, restitution et fin de mission | Clause de réversibilité détaillée |
Ce tableau peut servir de support lors d’un rendez-vous de lancement, d’une revue annuelle ou d’une transition. Chaque ligne devrait être associée à un responsable et à une date de vérification. La sécurité devient alors une activité suivie, plutôt qu’une vérification réalisée uniquement lors d’un incident.
Dans la plupart des projets, le titulaire doit être la personne ou la structure qui exploite réellement le site. Les informations exactes dépendent du contexte juridique et des règles du bureau d’enregistrement. Le point déterminant est de conserver un accès administratif indépendant du prestataire et de vérifier les données enregistrées.
Oui, si les responsabilités sont définies et si le propriétaire dispose d’une copie des données, d’une documentation suffisante et d’une procédure de sortie. L’hébergement chez le prestataire ne doit pas empêcher le transfert des fichiers, de la base et des réglages nécessaires.
La création d’un compte nominatif avec un rôle limité est la méthode à privilégier. Pour une intervention ponctuelle, l’accès peut être activé pour une durée déterminée, puis supprimé. L’authentification multifacteur et les journaux d’activité renforcent le contrôle.
Il faut demander les exports du site, les sauvegardes, la documentation, la liste des comptes, les réglages DNS, les éléments de licence et les procédures de restauration. Après validation du fonctionnement, les accès de l’ancien prestataire doivent être révoqués et les secrets sensibles renouvelés.
Non. Une sauvegarde doit être accessible depuis un compte indépendant, protégée contre la suppression et testée par une restauration. Sans procédure vérifiée, une copie peut être inutilisable ou incomplète au moment où elle devient nécessaire.
