Surveiller le DNS d'un grand portefeuille de domaines

Les équipes responsables de nombreux domaines (une entreprise avec des dizaines de sites régionaux, une équipe de sécurité qui suit une longue liste de surveillance, une agence qui gère l'infrastructure de ses clients) se heurtent à un problème que les contrôles ponctuels ne résolvent pas à grande échelle : revérifier manuellement chaque domaine à intervalles réguliers est assez fastidieux pour que cela cesse d'être fait de façon fiable, jusqu'au jour où un changement passe inaperçu plus longtemps qu'il ne le devrait.

Ce qui vaut vraiment la peine d'être surveillé

Rendre la surveillance durable

La solution pratique consiste à transformer la vérification en quelque chose qui s'exécute selon son propre calendrier, plutôt qu'en une tâche dont une personne doit se souvenir. Une tâche récurrente qui résout de nouveau tout le portefeuille à intervalle fixe (toutes les heures, tous les jours, selon la cadence qui correspond à la fréquence attendue des changements significatifs) et ne fait ressortir que ce qui a changé depuis la dernière fois, fait d'une corvée manuelle facile à sauter un filet de sécurité passif. L'associer à des résultats exportables (CSV ou JSON) permet de comparer simplement une exécution à la précédente et de détecter automatiquement la dérive, plutôt que de passer en revue à l'œil une longue liste.

Le risque précis que cela détecte : le DNS orphelin à grande échelle

Un grand portefeuille de domaines accumule de vieux sous-domaines comme toute base de code accumule du code mort : le sous-domaine de la page d'atterrissage d'une campagne marketing, un environnement de préproduction désactivé, un CNAME vers un essai SaaS jamais renouvelé. Chacun est une cible potentielle de détournement de sous-domaine si le service vers lequel il pointait devient disponible pour que quelqu'un d'autre le réclame. La surveillance planifiée, à l'échelle du portefeuille, est l'un des rares moyens pratiques de repérer ce type de dérive avant qu'un attaquant le fasse : un sous-domaine qui se résolvait proprement et qui renvoie maintenant une erreur, ou qui se résout vers un fournisseur inconnu, est exactement le signal qui mérite un second regard.

Qui en est responsable, sur le plan organisationnel

La surveillance DNS à l'échelle d'un portefeuille tombe souvent dans un interstice entre les équipes : les équipes d'infrastructure possèdent les domaines qui correspondent aux services qu'elles exploitent, les équipes marketing ou de croissance créent des sous-domaines de campagne sans forcément en informer l'infrastructure, et les équipes de sécurité veulent une visibilité sur l'ensemble sans forcément disposer d'un accès en écriture pour modifier quoi que ce soit. Un schéma viable consiste à traiter la tâche de surveillance elle-même comme un service partagé en lecture seule, dont la sécurité ou l'ingénierie de plateforme est propriétaire et qu'elle exécute selon un calendrier, avec des alertes acheminées vers l'équipe dont les domaines ont réellement changé, plutôt que d'attendre qu'une seule équipe pense à revérifier manuellement un portefeuille dont personne n'a une vision complète et à jour de la propriété.

Partir d'un inventaire, pas d'une supposition

L'étape qui tend à être négligée consiste à dresser la liste des domaines qui valent la peine d'être surveillés. Les tableaux de bord des registraires et des fournisseurs DNS affichent tous les domaines d'un compte donné, mais une grande organisation possède souvent des domaines dispersés chez plusieurs registraires et fournisseurs, accumulés au fil des années d'acquisitions, de campagnes et d'achats au niveau des équipes que personne ne suivait de manière centralisée. Rassembler cet inventaire complet une fois (même imparfaitement) et s'en servir comme liste de départ pour la surveillance continue est plus précieux qu'une configuration de surveillance techniquement sophistiquée qui ne couvre que le sous-ensemble de domaines dont quelqu'un se souvenait de l'existence.