Résumé

  • Le post-mortem de RIPE NCC attribue l’interruption du 27 mai 2026 à l’intervention d’un technicien d’un fournisseur sur une autre fibre, dans la même chambre, qui a affecté la fibre de RIPE NCC pendant quelques minutes.
  • Après le retour de la liaison, tout s’est rétabli automatiquement, mais l’opération complète a demandé environ trente minutes. RIPE Access, le tableau de bord RPKI et d’autres services dépendant de la connexion étaient touchés.
  • Un plan du troisième trimestre, mis à jour plus tard, mentionne des sauvegardes régulières de Keycloak et des routes différentes entre le SSO et Keycloak. Rien ne prouve que ces travaux aient été décidés à cause de l’incident.
  • Un reçu de continuité limité pourrait horodater le retour du transport, la santé du SSO, une transaction représentative et un essai de restauration de l’état, sans publier de topologie sensible.

Une coupure brève, une reprise en plusieurs temps

Le journal d’incident de RIPE NCC commence par une disponibilité intermittente de RIPE Access, du tableau de bord RPKI et d’autres services nécessitant une connexion. Une mise à jour mentionne un problème de fibre entre les centres de données. Le post-mortem précise ensuite qu’un technicien d’un fournisseur travaillait sur une autre fibre dans la même chambre et a affecté celle de RIPE NCC. La déconnexion n’aurait duré que quelques minutes. API de statut RIPE NCC Page de l’incident

La phrase suivante mérite d’être conservée entière. Après le rétablissement de la fibre, tout a récupéré automatiquement, mais il a fallu environ trente minutes pour terminer. Dire cela n’équivaut pas à reconnaître l’échec de l’automatisation. Au contraire, RIPE NCC affirme qu’elle a fonctionné. La question est de savoir ce que recouvre le mot « tout » et quel événement ferme chacune des horloges.

Une liaison peut de nouveau transporter des paquets avant qu’un service d’identité, ses dépendances et ses applications clientes aient tous retrouvé un état opérationnel. Une page de connexion peut répondre sans qu’une action privilégiée aboutisse déjà. Le transport, le SSO et la transaction métier sont donc trois objets de preuve. Les réunir sous une seule heure de fin ferait perdre l’information que le post-mortem a justement préservée.

Cette lecture reste volontairement étroite. Le document ne signale ni perte de données, ni compromission de compte, ni échec du second facteur, ni action RPKI manquée, ni mise à jour non autorisée de la base RIPE. Il n’attribue pas le délai à Keycloak. Il ne publie pas non plus la succession interne des étapes de reprise.

La meilleure explication n’est pas l’absence de contrôle

Il est tout à fait plausible que RIPE NCC dispose déjà de journaux précis, d’essais de bascule et de procédures de restauration. Un service d’identité n’a pas intérêt à exposer publiquement ses chemins, ses seuils, ses adresses ou le détail de ses sauvegardes. Une page de statut doit informer sans devenir une carte d’exploitation.

La classification interne publiée va dans ce sens. RIPE NCC évalue la disponibilité d’Access comme élevée, et sa confidentialité ainsi que son intégrité comme très élevées. La prudence sur les détails est donc cohérente avec la criticité annoncée. Criticité des services RIPE NCC

Il ne s’agit pas de réclamer les schémas de cluster ou les journaux bruts. Le manque est plus petit : le lecteur public ne peut pas associer les trente minutes à des jalons nommés. Un reçu limité peut remplir ce vide tout en laissant les preuves sensibles dans un canal restreint.

Le plan de juin ne réécrit pas l’incident de mai

Le plan Business Applications du troisième trimestre, mis à jour le 11 juin, comporte un chantier « SSO Improvements ». RIPE NCC y indique travailler sur des sauvegardes régulières de Keycloak et sur des routes de trafic différentes entre le SSO et Keycloak afin de réduire les délais d’attente. Le statut est « In progress ». Plan trimestriel Business Applications

Quinze jours séparent l’incident de cette mise à jour. Ce voisinage ne suffit pas à établir une cause. La nouvelle route peut viser un autre problème de timeout. Le programme de sauvegarde peut être antérieur. Surtout, une route répond à la question de la joignabilité, tandis qu’une sauvegarde répond à celle de l’état à restaurer. Une fibre sectionnée et une base à restaurer ne sont pas le même scénario.

Les plans archivés montrent une trajectoire plus longue : travaux sur la criticité d’Access en 2023, migration vers Keycloak et évolution des parcours de connexion en 2024, puis travaux de surveillance et d’alerte dont les priorités ont changé en 2025. C’est un programme vivant, pas une liste de corrections que l’on pourrait raccorder mécaniquement à chaque incident. Archives Business Applications

La bonne comparaison est donc une comparaison de catégories. L’incident révèle une durée de reprise. Le plan nomme un contrôle de chemin et un contrôle d’état. Il manque le document public qui précise le périmètre testé de chacun, leur date et leur durée de validité.

La route n’emporte pas l’état avec elle

RIPE NCC a expliqué qu’en 2023 l’ancien backend d’authentification avait été remplacé par Keycloak sur AWS EKS. Le projet principal s’est achevé en juillet 2023, tandis que des travaux d’intégration et d’adoption de fonctions natives restaient à mener. Cette histoire situe Keycloak dans l’architecture, mais ne révèle pas la configuration actuelle et ne prouve pas son rôle dans l’incident de mai. RIPE Labs sur l’évolution d’Access

La documentation amont aide à nommer les différences. Keycloak traite séparément la multiplicité des instances, la détection de disponibilité et l’importance de la base. Sa documentation d’import-export avertit qu’un export de royaume n’est pas une sauvegarde complète et cohérente par définition : événements, sessions persistantes, états de workflow et jetons révoqués peuvent en être absents. Configuration de production Keycloak Base de données Keycloak Import et export Keycloak

Ces textes ne décrivent pas l’installation de RIPE NCC. De même, la résilience du plan de contrôle EKS documentée par AWS ne garantit pas celle d’une application, de ses données ou de ses routes. Résilience et reprise après sinistre d’AWS EKS

Ils permettent néanmoins de formuler une règle saine. Une route alternative doit prouver la continuité de transport contre un domaine de panne défini. Une restauration doit prouver quelles données et quels états reviennent, à quel point de reprise et dans quel délai. L’un ne remplace pas l’autre.

Une passerelle vers des actes qui comptent

RIPE Access dessert le portail LIR et le tableau de bord RPKI. La politique d’authentification et de clés de sécurité de RIPE NCC cadre cette surface membre. Politique RIPE Access, ripe-843

Le CPS RPKI actuel indique que l’Online CA dépend du mécanisme SSO du portail LIR pour identifier les demandeurs autorisés. La documentation de la base RIPE précise aussi que les identifiants SSO gérés par Access peuvent autoriser des mises à jour web d’objets protégés. CPS RPKI, ripe-851 Modèle d’autorisation de la base RIPE

Ces dépendances ne prouvent pas qu’une ROA, une route ou un objet ait été affecté le 27 mai. Elles expliquent pourquoi un simple ping ne suffit pas comme preuve de reprise. Le reçu devrait inclure une transaction représentative, sans prétendre couvrir toutes les opérations de tous les membres.

Le reçu minimal

Le document peut tenir sur une page. Il identifie l’incident et sépare quatre heures : détection de la dégradation physique, restauration du transport, santé du SSO et succès d’une transaction dépendante choisie à l’avance. Si les applications reviennent à des moments différents, elles gardent des lignes distinctes.

Pour la route, il indique le domaine de panne visé, le signal de santé, le déclencheur de bascule, le caractère automatique ou manuel, le temps observé et le test sûr. Pour l’état, il indique les classes de données couvertes, la fréquence, la rétention, le chiffrement à un niveau publiable, la date du dernier essai de restauration, le logiciel testé, le RPO et le RTO mesurés, ainsi que les exclusions.

Enfin viennent l’auteur de chaque affirmation, la provenance, les inconnues, la date d’expiration et les liens de correction ou de remplacement. « Détails sous accès restreint » est une valeur honnête. Elle vaut mieux qu’une assurance générale sans identité de test.

Ce reçu ne transforme pas RIPE NCC en autorité sur les systèmes de ses membres. Il ne certifie pas chaque action RPKI. Il donne seulement à une équipe la possibilité de comprendre ce qui a été rétabli, quand et sur quelle preuve.

Sources

  1. API de statut RIPE NCC : incident du 27 mai 2026
  2. Page de statut RIPE NCC : disponibilité intermittente d’Access
  3. Plan trimestriel Business Applications
  4. Archives des plans Business Applications
  5. Criticité des services RIPE NCC
  6. RIPE Labs : évolution de RIPE Access
  7. Politique RIPE Access, ripe-843
  8. CPS RPKI de RIPE NCC, ripe-851
  9. Modèle d’autorisation de la base RIPE
  10. Configuration de production Keycloak
  11. Documentation de la base Keycloak
  12. Import et export Keycloak
  13. Reprise et résilience d’AWS EKS