Résumé

  • APNIC a signalé deux incidents distincts de 28 minutes les 15 et 17 septembre. Le premier suit une modification de configuration dans MyAPNIC ; le second est attribué à une base de données et a retardé les courriels vers le système de tickets.
  • La proximité et la même durée ne démontrent aucune cause commune. La question publique est de savoir si les dépendances ont été comparées et si un lien a été trouvé, écarté ou laissé indéterminé.

Le premier avis d’APNIC situe l’incident du portail membre MyAPNIC entre 13 h 58 et 14 h 26, UTC+10, le 15 septembre. Une modification de configuration apportée à un composant aurait eu un effet plus large que prévu sur d’autres fonctions de MyAPNIC. APNIC annonce un correctif destiné à limiter l’impact de changements similaires.

Le second avis couvre 14 h 50 à 15 h 18, UTC+10, le 17 septembre. Il mentionne un problème de base de données : les courriels adressés au système de tickets ont été retardés et certaines fonctions de MyAPNIC sont devenues indisponibles. APNIC prévoit d’améliorer la surveillance de la base afin d’intervenir avant un nouvel impact.

Ces explications doivent rester séparées. Le premier texte décrit la portée excessive d’un changement de configuration. Le second décrit un problème de base de données touchant deux capacités. Aucun des deux ne dit qu’un événement a causé l’autre, qu’ils partagent un composant, ni qu’il y a eu perte de données, faille de sécurité ou effet sur le routage.

Les deux débuts sont espacés de 48 heures et 52 minutes. Cette proximité justifie une vérification, pas un verdict. La durée identique peut refléter une cadence commune de détection ou de reprise ; elle peut aussi être fortuite. Les avis ne permettent pas de trancher.

Il manque donc un relevé transversal. APNIC a-t-elle comparé l’authentification, les files d’attente, les magasins de données, le chemin de déploiement, la configuration, la supervision ou les relais humains ? Le contrôle a-t-il trouvé un facteur commun, l’a-t-il écarté, ou la réponse demeure-t-elle inconnue ?

Une publication utile n’aurait pas besoin de révéler l’architecture interne. Elle pourrait nommer les deux incidents, les classes de fonctions touchées, la fenêtre d’analyse et les domaines de dépendance vérifiés. Une conclusion à trois états — lien trouvé, lien écarté, lien encore inconnu — suffirait, avec le responsable du suivi, l’état du confinement et la date du prochain examen.

Ce relevé protégerait les informations sensibles : aucun nom d’hôte, identifiant, contenu de ticket, donnée de membre ou nom d’employé n’est nécessaire. Son objet est simplement de relier deux documents déjà publics sans fusionner leurs causes.

Les remèdes annoncés sont locaux et différents. Encadrer les changements de configuration ne garantit pas la détection des défauts de base de données. Renforcer la surveillance d’une base ne réduit pas automatiquement la portée d’un changement. Si l’examen confirme l’indépendance, la publier rendra les deux actions plus crédibles. S’il identifie une surface commune, l’action transversale doit apparaître. S’il reste ouvert, « inconnu » est une information honnête.

Sources