Resumen

  • El informe posterior de RIPE NCC dice que un técnico de un proveedor, mientras trabajaba en otra fibra de la misma arqueta, afectó la fibra de RIPE NCC y la desconectó durante un par de minutos el 27 de mayo de 2026.
  • Tras restaurarse la conexión, todo se recuperó automáticamente, aunque completar el proceso llevó unos treinta minutos. El incidente afectó RIPE Access, el panel de RPKI y otros servicios dependientes del inicio de sesión.
  • Un plan del tercer trimestre, actualizado después, menciona copias periódicas de Keycloak y rutas distintas entre SSO y Keycloak. La documentación no vincula causalmente ese trabajo con el incidente.
  • Un recibo de continuidad puede separar el retorno del transporte, la salud de SSO, una transacción representativa y la restauración probada del estado, sin exponer una arquitectura sensible.

«Todo» no tiene por qué volver al mismo tiempo

RIPE NCC abrió el incidente por disponibilidad intermitente de Access, del panel RPKI y de otros servicios que requieren autenticación. Durante la investigación señaló un problema de fibra entre sus centros de datos. El postmortem añadió el detalle físico: un técnico externo trabajaba en otra fibra de la misma arqueta y afectó la de RIPE NCC. La desconexión duró un par de minutos. Registro JSON del incidente Página de estado

La recuperación automática comenzó cuando volvió la conexión, pero tardó unos treinta minutos en completarse. El texto no identifica qué componente ocupó ese intervalo. Tampoco dice que Keycloak causara la avería o que una copia de seguridad participara en la recuperación. No documenta pérdida de datos, cuentas comprometidas, fallos de 2FA, acciones RPKI fallidas ni cambios no autorizados en la base RIPE.

Lo que sí permite afirmar es más útil que una conjetura: el hito físico no cerró por sí solo el hito operativo. En un sistema compartido de identidad, la red puede estar disponible mientras se reconectan dependencias, se reevalúan comprobaciones de salud o las aplicaciones consumidoras recuperan sus propias sesiones. Incluso una pantalla de acceso funcional no demuestra que una operación privilegiada termine correctamente.

Por eso conviene preguntar qué reloj se detuvo. El de la fibra responde cuándo volvió el transporte. El del SSO responde cuándo el servicio de identidad aceptó una prueba segura. El de la aplicación responde cuándo una acción representativa produjo el resultado esperado. Si se conserva un único final, alguien terminará atribuyendo al nivel equivocado una promesa que nunca hizo.

La defensa razonable es la prudencia operacional

RIPE NCC puede tener internamente una cronología mucho más detallada. Publicar rutas, umbrales, distribución de instancias o contenido de copias puede ser contraproducente para una plataforma de identidad. El objetivo no debería ser obligarla a entregar un plano del servicio.

Su tabla de criticidad explica esa cautela. Access recibe una valoración alta en disponibilidad y muy alta en confidencialidad e integridad. Es lógico que la evidencia operativa completa permanezca restringida. Criticidad de los servicios de RIPE NCC

Además, la organización sí publicó tres datos incómodos de forma clara: la intervención de un proveedor, la brevedad de la desconexión y la mayor duración de la recuperación. La petición proporcionada no es «más transparencia» en abstracto. Es una etiqueta fiable para cada hito ya comunicado y un enlace a la prueba bajo el nivel de acceso adecuado.

Junio no explica automáticamente mayo

El plan vigente de Business Applications, actualizado el 11 de junio, incluye mejoras de SSO. El texto habla de copias regulares de Keycloak y de rutas de tráfico diferentes entre SSO y Keycloak para reducir timeouts. El trabajo figura como «In progress». Plan trimestral de Business Applications

Es fácil convertir la secuencia de fechas en una historia: incidente a finales de mayo, remedio a mediados de junio. La fuente no hace ese enlace. Las rutas distintas pueden responder a otra clase de timeout. Las copias periódicas pueden formar parte de un programa previo. Una ruta alternativa y una restauración de estado tampoco reparan el mismo tipo de fallo.

Los planes archivados muestran trabajos anteriores sobre criticidad, migración a Keycloak, flujos de inicio de sesión, monitorización y alertas. Algunas prioridades cambiaron. Eso describe una cartera continua, no una confesión codificada de causas pasadas. Archivo de planes de Business Applications

La comparación legítima es otra: el incidente hace visible un intervalo; el plan nombra dos familias de control. Un recibo debería decir qué escenario cubre cada una y cuándo fue ensayada, sin afirmar que una deriva de la otra.

Cambiar el camino no restaura la memoria

RIPE NCC contó que la reimplantación de 2023 sustituyó el backend anterior por Keycloak sobre AWS EKS. El proyecto principal terminó en julio, mientras continuaban la integración y el aprovechamiento de funciones nativas. Es evidencia de la elección tecnológica, no de la topología actual ni de la causa del incidente de 2026. RIPE Labs sobre los cambios de Access

La documentación genérica de Keycloak ayuda a no mezclar conceptos. La disponibilidad de varias instancias, el enrutamiento según estado y la base de datos son asuntos distintos. La guía de importación y exportación advierte que exportar un realm no equivale a una copia íntegra y consistente: puede omitir eventos, sesiones persistentes, estado de workflows y tokens revocados. Configuración de producción de Keycloak Base de datos de Keycloak Importación y exportación de Keycloak

Nada de eso prueba cómo configuró RIPE NCC su servicio. La documentación de resiliencia del plano de control de EKS tampoco certifica una aplicación concreta, sus datos ni sus dependencias. Resiliencia y recuperación de AWS EKS

Sí permite fijar una frontera analítica. Una ruta protege la capacidad de llegar. Una copia protege la capacidad de recuperar estado. Puede haber conectividad hacia una base incompleta, o una base correcta sin ruta útil. Llamar «redundancia» a ambos controles no basta para decidir si una operación puede reanudarse.

Una dependencia con efectos, no una prueba de daño

La política de RIPE Access incluye el portal LIR y el panel RPKI. Política de autenticación de Access, ripe-843 El CPS vigente de RPKI dice que la CA en línea depende del SSO del portal LIR para identificar a solicitantes autorizados. CPS RPKI, ripe-851 El modelo de autorización de la base RIPE también permite que credenciales SSO gestionadas por Access autoricen actualizaciones web de objetos protegidos. Modelo de autorización de la base RIPE

Estas relaciones explican la importancia de una prueba transaccional. No permiten sostener que el incidente modificara una ruta, una ROA o un objeto. Una dependencia amplía lo que debe verificarse; no convierte una posibilidad en un suceso.

La prueba pública puede ser deliberadamente segura. No necesita ejecutar una transferencia real ni publicar una identidad. Puede usar una transacción sintética o una comprobación previamente definida que recorra autenticación, autorización y respuesta sin cambiar recursos.

Un recibo que cabe en la operación existente

La primera parte registra cuatro tiempos: detección física, transporte restaurado, SSO saludable y transacción dependiente confirmada. Cada aplicación conserva su propia hora si vuelve de forma escalonada. La palabra «completo» queda ligada a una lista, no a una intuición.

La segunda parte describe el ensayo de ruta: dominio de fallo, señal de salud, disparador, modo automático o manual, tiempo observado y transacción de verificación. «Ruta independiente» solo se usa cuando la independencia frente al fallo nombrado fue comprobada.

La tercera describe el ensayo de restauración: clases de estado cubiertas, frecuencia, retención, cifrado a nivel publicable, fecha, versión, límites, RPO y RTO medidos. Un trabajo de backup no se marca como restauración hasta que una restauración haya producido el estado esperado.

Finalmente se anotan autoridad, procedencia, revisión, incógnitas, caducidad y correcciones. Los detalles delicados pueden aparecer como restringidos. El público necesita conocer la identidad y el resultado del ensayo, no las credenciales ni el plano.

Este mecanismo no centraliza decisiones de los miembros. RIPE NCC afirma solo sobre su servicio. El proveedor responde por su superficie. Cada miembro decide cuándo continuar sus operaciones. El recibo impide que una capa hable sin querer por todas las demás.

Fuentes

  1. API de estado de RIPE NCC: incidente del 27 de mayo
  2. Página del incidente de RIPE Access
  3. Plan trimestral de Business Applications
  4. Planes archivados de Business Applications
  5. Criticidad de servicios de RIPE NCC
  6. RIPE Labs: evolución de RIPE Access
  7. Política de RIPE Access, ripe-843
  8. CPS de RPKI, ripe-851
  9. Modelo de autorización de la base RIPE
  10. Configuración de producción de Keycloak
  11. Guía de base de datos de Keycloak
  12. Importación y exportación de Keycloak
  13. Recuperación y resiliencia de AWS EKS