Cuando un servicio en la nube falla, no solo se detiene una aplicación: se detienen negocios, procesos y, en muchos casos, la confianza del usuario. Eso fue exactamente lo que ocurrió con Cloudflare R2, una plataforma clave para el almacenamiento de objetos, escalable, compatible con S3 y con ventajas como recuperación de datos gratuita y replicación multirregional.
Recientemente, Cloudflare anunció que R2 y los servicios que dependen de él sufrieron una interrupción global de 1 hora y 7 minutos, entre las 21:38 UTC y las 22:45 UTC, provocando fallas de escritura del 100 % y de lectura del 35 %. La causa fue tan simple como crítica: una rotación de credenciales mal ejecutada que hizo que R2 Gateway (la interfaz API del servicio) perdiera el acceso de autenticación al almacenamiento del backend.
Lo que pasó fue básicamente un descuido bastante común: se aplicaron nuevas credenciales, pero por error se pusieron en el entorno de desarrollo en vez del de producción. Todo seguía funcionando... hasta que alguien eliminó las credenciales antiguas. Ahí fue cuando el entorno de producción se quedó sin acceso válido, y todo empezó a fallar.
¿La raíz del problema? Se olvidaron de agregar un simple parámetro en la línea de comandos: --env production. Ese detallito es el que indica que las credenciales deben ir al entorno correcto, específicamente al trabajador que maneja la puerta de enlace de R2 en producción. Sin eso, el sistema asumió que era solo para pruebas. Y ya sabes lo que pasó después.
Diagrama de autenticación de R2 Gateway Worker (Fuente: Cloudflare)
El problema no se notó de inmediato, y eso complicó aún más las cosas. Por cómo están diseñados los servicios de Cloudflare, la mala configuración no generó una alerta clara al instante, así que el equipo tardó un poco más en darse cuenta de lo que realmente estaba pasando.
Según explicó Cloudflare en su informe, la caída en la disponibilidad de R2 fue gradual, no algo que saltara a la vista enseguida. Esto se debió a que la eliminación de las credenciales tardó un poco en propagarse por toda la infraestructura de almacenamiento, lo que hizo que el impacto fuera apareciendo de a poco, en lugar de ser un fallo total desde el primer minuto.
Podría interesarte leer: Ataque DDoS Masivo de 56 Tbps Detenido por Cloudflare con Éxito
¿Qué salió mal y qué está haciendo Cloudflare para evitar que se repita?
La naturaleza del error hizo que el problema no fuera evidente de inmediato. En lugar de validar directamente qué token estaba utilizando R2 Gateway para autenticarse con la infraestructura de almacenamiento, se confió en las métricas de disponibilidad tras la actualización de credenciales. Esa omisión retrasó la detección del fallo y complicó su resolución.
A pesar del impacto, no hubo pérdida ni corrupción de datos de los clientes. Sin embargo, sí se produjo una degradación considerable del servicio en varias áreas:
-
R2: se registraron fallos en el 100 % de las escrituras y en el 35 % de las lecturas. Los objetos ya almacenados en caché siguieron siendo accesibles.
-
Cache Reserve: aumentó el tráfico hacia los orígenes debido al incremento de lecturas fallidas.
-
Cloudflare Images y Stream: todas las cargas fallaron; la entrega de imágenes cayó al 25 % y el streaming al 94 %.
-
Servicios como Email Security, Vectorize, Billing, Auditoría de claves y entrega de registros también presentaron distintos niveles de afectación.
Para prevenir que un incidente similar vuelva a ocurrir, Cloudflare ha implementado varias mejoras clave:
-
Ha reforzado el registro y la verificación de credenciales en todos los entornos.
-
Ha hecho obligatorio el uso de herramientas de implementación automatizadas, con el objetivo de reducir el margen de error humano.
-
Ha actualizado sus procedimientos operativos estándar (SOP) para exigir doble validación en tareas de alto impacto, como la rotación de credenciales.
-
Está mejorando sus controles de salud internos para detectar más rápido las causas raíz de futuros problemas.
Este incidente no fue un hecho aislado. En febrero, Cloudflare también enfrentó una interrupción de R2 causada por error humano, cuando un operador, al intentar bloquear una URL maliciosa reportada por phishing, desactivó por completo el servicio R2 Gateway. En respuesta a ese evento, Cloudflare ha comenzado a fortalecer sus procesos internos aún más, incluyendo:
-
Nuevos controles de acceso más estrictos.
-
Mejoras en el aprovisionamiento de cuentas.
-
Procesos de aprobación en dos pasos para operaciones sensibles o de alto riesgo.
Estas acciones reflejan el compromiso de Cloudflare con la mejora continua y la resiliencia de su infraestructura, priorizando siempre la seguridad, la estabilidad del servicio y la confianza de sus usuarios.