Les articles de l’équipeAutres articles

Qu’est-ce que le risque lié à la gouvernance d’Internet ? Guide pratique

Partez d’un service qu’utilisent vos clients. Identifiez qui contrôle ses noms, ses adresses et son routage, puis testez ce qui se passe lorsqu’une dépendance fait défaut.

Sommaire

Une main tient une loupe au-dessus d’un câble reliant une boutique miniature à un serveur ; un registre et des clés sont posés à proximité.

Partez d’un service qu’utilisent vos clients. Retracez ses noms, ses adresses, ses connexions et ses enregistrements, puis testez ce qui se passe lorsqu’une dépendance fait défaut.

Le risque lié à la gouvernance d’Internet désigne la possibilité que des décisions ou des défaillances touchant les institutions, les règles et les services dont dépend votre organisation perturbent sa capacité à exercer ses activités en ligne.

Le point de départ le plus simple tient en une question : si un acteur extérieur ne pouvait plus remplir son rôle demain, qu’est-ce qui cesserait de fonctionner pour vos clients ?

Partez d’un service que les gens utilisent

Choisissez quelque chose de concret : un accès à un espace client, une connexion à un service de paiement, une API ou la connexion d’un bureau. Notez ce dont un utilisateur a besoin pour y accéder. Cela peut comprendre un nom de domaine, un service DNS, des adresses IP, une connexion réseau et un hébergeur.

Un nom de domaine est le nom lisible par un humain que les gens utilisent. Le DNS permet de résoudre ce nom pour obtenir les informations nécessaires à l’accès à un service. Les adresses IP et le routage interviennent à une autre étape du parcours. Perdre le contrôle d’un compte de gestion de domaine, changer d’adresse IP et perdre une connexion réseau sont des défaillances distinctes.

Déterminez qui peut modifier chaque élément dont le service dépend

Pour chaque composante du service, identifiez à la fois l’organisation qui la fournit et la personne qui peut effectuer une modification essentielle. Un compte au nom d’un ancien salarié constitue un type de risque. Un fournisseur qui peut seul mettre à jour votre autorisation de routage en constitue un autre.

  • Noms : qui contrôle le compte de gestion du domaine, son renouvellement et les enregistrements DNS ?
  • Numéros : qui figure dans les registres comme détenteur des ressources, et qui peut demander des modifications ?
  • Routage : quel réseau annonce les adresses, et qui peut modifier cette organisation ?
  • Attestations de sécurité : qui tient à jour les enregistrements servant à vérifier que le routage est autorisé ?
  • Dépendances des clients : quels partenaires ou clients ont enregistré vos adresses actuelles dans leurs propres systèmes ?

Par exemple, une autorisation d’origine de route, ou ROA pour Route Origin Authorization, indique quel numéro de système autonome est autorisé à être à l’origine de l’annonce d’un préfixe IP. Un préfixe est un bloc d’adresses ; un numéro de système autonome identifie un réseau dans le routage entre réseaux. La spécification des ROA définit cette autorisation limitée. Elle ne constitue pas une garantie générale d’acheminement du trafic ni de sécurité de l’intégralité d’une route.

Distinguez les défaillances auxquelles vous devez vous préparer

Une défaillance de service signifie qu’un élément est indisponible : un fournisseur, un compte ou une fonction administrative nécessaire. Demandez-vous ce qui continue de fonctionner et quelles modifications deviennent impossibles.

Un changement de conditions ou de politique signifie que la relation existe toujours, mais que ses modalités ont changé. Demandez-vous quel service effectif ou quelle transaction prévue est touché, au lieu de supposer que toutes les propositions ont les mêmes conséquences.

Une obligation légale découle des lois qui s’appliquent à vos activités. C’est une question distincte de ce qu’une institution technique revendique au titre de ses politiques. Dans la Note 4, consacrée à la souveraineté des données, Lu Heng distingue les capacités techniques de l’autorité juridique. Le seul fait d’installer un serveur dans un pays ne règle pas toutes les questions d’accès, de contrôle ou de compétence juridictionnelle.

Testez la procédure de rétablissement

Choisissez une interruption et passez en revue la réponse avec les personnes qui seraient chargées de la mettre en œuvre. Si un fournisseur fait défaut, pouvez-vous déplacer le service ? Si les adresses IP doivent changer, quels clients doivent intervenir ? Si les mises à jour des enregistrements sont indisponibles, de quelles preuves et de quelles dispositions opérationnelles auriez-vous besoin ?

Consignez les étapes effectivement suivies, les dépendances à l’égard d’autres parties et le temps qu’a pris l’exercice. Une procédure documentée mais jamais testée n’est pas équivalente à une procédure que votre équipe sait exécuter.

Certaines lacunes relèvent de votre contrôle : un accès manquant à un compte, un renouvellement non documenté ou un changement de fournisseur non testé. D’autres sont structurelles. Ne présentez pas le remplacement d’un registre comme une possibilité disponible au seul motif que vous souhaiteriez qu’elle existe.

Tirez de l’exercice une question plus précise

Lu Heng propose que la coordination nécessaire reste circonscrite et remplaçable. La même question peut guider votre examen : ce dispositif aide-t-il un réseau à poursuivre son activité, ou le rend-il dépendant d’un administrateur qu’il ne peut pas quitter ?

L’exercice est achevé lorsque vous pouvez nommer la dépendance, expliquer son effet sur un client et identifier une réponse testée — ou une lacune précise à laquelle il reste à remédier. C’est plus utile qu’une promesse générale de suivre les politiques d’Internet.

Lisez les droits proposés par Lu Heng pour la couche de coordination pour comprendre le changement plus large auquel cette démarche conduit. Pour une introduction au débat, revenez à l’importance de la décentralisation.