Volver al Blog

Tu proveedor de identidad no es una aplicación: es infraestructura

Portal de un edificio antiguo con una única puerta acristalada, el portero automático y los buzones metálicos

Diez servicios públicos noruegos dejaron de funcionar el lunes. Varios de ellos no tenían nada roto: se había atascado el portal del edificio, y da igual que los pisos estén impecables si no puedes pasar del recibidor.

A las 03:38 del lunes 24 de agosto, hora central europea, empezó un ataque de denegación de servicio contra la infraestructura digital compartida del Estado noruego: la que sostienen la agencia de digitalización, Digdir, y Vivicta, la empresa que se la opera. Cuando escribimos esto lleva más de dos días. Llegó en oleadas —los técnicos estabilizaron la situación el lunes por la tarde y por la noche volvió a torcerse— y el portavoz de Digdir, Are Kvistad, dijo a la agencia NTB que era «dos o tres veces mayor» que el anterior. Es el tercero del verano: uno a finales de junio, otro a principios de agosto y este. La policía judicial noruega, Kripos, tiene abierta una investigación por los tres.

Diez servicios afectados, según el recuento de The Record. Los partes de Digdir nombran estos: ID-porten, MinID, Maskinporten, Altinn, eInnsyn, eFormidling, ELMA, Ansattporten, las soluciones de autoservicio, eSignering y el registro de contacto y reserva. Mientras escribimos esto, la actualización de la página de estado de la 01:42 del miércoles 26 dice que ID-porten «sigue con limitaciones», sin hora estimada de restablecimiento. Y en todos los comunicados se repite la misma frase: no hay indicios de brecha ni de datos personales comprometidos.

El servicio de firma no estaba atacado: le habían cerrado la puerta

ID-porten es la puerta única: donde los ciudadanos —más de cuatro millones y medio, según The Record— se identifican para entrar en cualquier servicio público. Y Digdir escribe en su página de estado, en noruego y con todas las letras, qué le pasó al servicio de firma electrónica: «eSignering está inaccesible a causa de las limitaciones en ID-porten. Se pueden seguir creando encargos de firma, pero es la firma en sí lo que está inaccesible».

Léelo despacio, porque ahí está todo el post. El servicio de firma no tenía nada. Sus proveedores acabaron aplicando medidas por su cuenta y lo devolvieron a la normalidad de madrugada, con ID-porten todavía limitado. Un incidente de disponibilidad en el punto de identificación no se reparte entre los servicios que dependen de él: se multiplica por ellos. Es la aritmética menos intuitiva de una arquitectura que, por lo demás, está bien hecha.

Hay una segunda lectura en esos partes que apenas se ha contado fuera de Noruega. A las 16:09 del lunes, con el ataque todavía encima, Digdir escribe: «El ataque sigue en marcha, pero las soluciones están estables con las limitaciones que se han puesto». Parte de lo que no funcionaba no lo había tirado el atacante. Lo habían apagado ellos, a propósito, para sostener el resto. Eso es un plan de degradación ejecutándose, y es la parte del incidente que mejor salió.

El inicio de sesión único sigue siendo la decisión correcta

La conclusión fácil sería que centralizar la identidad fue un error. No lo creemos, y decirlo aquí sería barato: la alternativa —cada organismo con su propio inicio de sesión, su propia gestión de contraseñas, su propio segundo factor a medio hacer y su propia manera de dar de baja al que se va— es peor en seguridad, más incómoda de usar y bastante más cara de mantener. Cuando alguien deja la administración pública noruega, la baja ocurre en un sitio. Ese es exactamente el valor que se compra con la centralización, y no es poco.

La lección del lunes es otra. Al concentrar, la puerta cambia de categoría, y casi nadie hace el papeleo de esa reclasificación.

Qué cambia cuando algo pasa a ser infraestructura

Una aplicación se compra, se instala, se parchea y se le pone una copia de seguridad. Una infraestructura se dimensiona, se enruta, se degrada con orden y se ensaya. Son dos repertorios distintos, con dos presupuestos distintos y dos conversaciones distintas con el comité. El problema es que el proveedor de identidad casi siempre entra en la casa por la primera puerta —una aplicación más del catálogo, con su licencia por usuario— y se queda ahí para siempre, aunque con los años haya acabado decidiendo quién trabaja cada mañana.

Para dar la escala: un 99,9 % de disponibilidad anual son 8,76 horas caído en todo el año. Noruega lleva más de dos días. No lo decimos como reproche —contra un ataque sostenido de esta talla el número se lo come cualquiera—, sino como la medida exacta de por qué la puerta merece otra categoría de presupuesto que la aplicación de gestión de vacaciones.

En concreto, tratarla como infraestructura significa cuatro cosas que a una aplicación no se le exigen:

  • Capacidad propia. La que necesitan a la vez todos los servicios que la usan en su peor momento, que es bastante más de lo que la puerta mueve un día normal. Dimensionarla por su propio tráfico es el error de origen.
  • Camino propio. Si entra por la misma dirección, el mismo enlace y el mismo proveedor que todo lo demás, lo que has hecho es ponerle dos etiquetas al mismo cable. Es la diferencia entre tener dos enlaces y tener dos caminos.
  • Un plan de degradación. Qué pueden seguir haciendo los servicios de detrás cuando la puerta no contesta. Sesiones que sobreviven un rato, un camino de emergencia para un puñado de cuentas críticas, una pantalla que explique qué pasa en vez de un error genérico. Los noruegos tenían algo de esto —por eso podías seguir creando un encargo de firma aunque no pudieras firmarlo— y se nota. Nada de ello es gratis, y por eso hay que decidirlo con calma y no a las cuatro de la mañana.
  • Ensayo. Apagarla a propósito, en horario de oficina, y mirar qué se cae. Es la única forma de descubrir la dependencia que nadie había documentado —normalmente hay tres— antes de que la descubra por ti alguien que ni siquiera sabía que existías.

El último punto es el que más se resiste, porque suena a temeridad y es justo lo contrario. Romper tu propio sistema a propósito, con la gente delante y el café recién hecho, es el precio de no descubrirlo a oscuras. Nosotros lo hacemos con simulacros de recuperación cronometrados: el último completo fueron catorce minutos. Es un dato interno y lo damos como lo que es —una prueba nuestra, no una garantía contractual—, pero ese número solo existe porque alguien apagó algo a propósito una mañana laborable. Lo mismo vale para la alta disponibilidad, que no evita la caída sino que la acorta: sirve en la medida en que alguien la haya probado.

Lo de menos es que fuera un DDoS

Sobre la mecánica del ataque tenemos poco nuevo que añadir: ya escribimos en julio, como operador de red, por qué un cortafuegos no para un DDoS volumétrico y por qué el blackhole del RFC 7999 no es mitigación sino rendición ordenada. Ahí está el detalle técnico y ahí sigue siendo válido.

El DDoS es solo una de las formas de atascar el portal, y ni siquiera la más frecuente. La puerta se atasca igual si el certificado caduca un domingo, si una regla de acceso condicional sale mal, si el proveedor externo de identidad tiene su propio mal día o si alguien toca una configuración un viernes por la tarde. Esa última pesa más de lo que parece: en un estudio de 2003 sobre tres grandes servicios de internet, Oppenheimer, Ganapathi y Patterson encontraron que el error de operador —en su mayoría, de configuración— era la primera causa de caída visible en dos de los tres. Y los propios autores añaden el matiz que aquí importa: el hardware falla más a menudo, pero la redundancia lo tapa. Al error humano no lo tapa nadie. El atacante es una de las maneras de que se atasque. El resto de las maneras las ponemos nosotros.

La misma geometría, con dos ceros menos

Cámbiale la escala y es tu empresa. Tu directorio decide cada mañana quién entra al correo, al ERP, al CRM, a la carpeta compartida y a la VPN. Si ese directorio vive en el mismo sitio que todo lo demás, comparte el mismo camino de red y no tiene un plan para cuando no contesta, entonces has montado la misma geometría que Noruega con dos ceros menos.

La versión que más nos encontramos: un controlador de dominio único, virtualizado en el mismo clúster que todo lo demás, cuya copia de seguridad se guarda en un servidor que, para restaurarse, necesita autenticarse contra ese mismo controlador. Ya escribimos sobre esa dependencia circular y lo que cuesta deshacerla; aquí basta con el titular: nadie la ve hasta el día que hay que usarla. La segunda versión más frecuente es la contraria y tampoco es mejor: un proveedor de identidad en la nube, impecable, del que dependen quince aplicaciones, y ni una sola cuenta local de emergencia en ningún sitio porque «eso es inseguro». Lo es. También lo es no poder entrar a apagar el fuego.

Tres preguntas que reclasifican tu puerta

  1. ¿Qué deja de funcionar si tu puerta no contesta durante seis horas? La lista completa, escrita, con nombres de aplicaciones. Casi siempre es más larga de lo que dice la memoria, y casi siempre aparece alguna sorpresa: la impresora que autentica contra el directorio, el fichaje, el portal del cliente. La versión larga de este ejercicio, aplicada a Microsoft 365, la escribimos en julio.
  2. ¿Por dónde entras tú a arreglarlo? Si tu acceso de administración depende de la misma puerta que se ha atascado, el atacante ha conseguido algo mejor que tirarte un servicio: te ha separado de tu propia infraestructura. Tiene que haber un camino distinto, con credenciales distintas, y hay que haberlo usado alguna vez para saber que funciona.
  3. ¿Cómo se llama el que dice «pasamos al plan degradado»? Un nombre y un apellido, escritos antes. Digdir puso limitaciones deliberadas el lunes por la tarde y con eso aguantó; alguien firmó esa decisión. En una empresa pequeña la firma acaba siendo por omisión del que esté de guardia a las cinco de la madrugada, que es quien menos contexto de negocio tiene para tomarla.

Las tres se contestan en una tarde y ninguna cuesta una licencia. Lo caro llega la primera vez que alguien te las hace en mitad de un incidente.

Lo que no se deduce de todo esto

Que Noruega lo hiciera mal, para empezar. Publicaron una página de estado con las horas puestas, escribieron qué sabían y qué no, y a día de hoy siguen sin dar una hora estimada de restablecimiento en vez de inventarse una para quedar bien. Es más de lo que hace mucha gente un martes cualquiera, y desde fuera es muy fácil opinar sin tener delante el registro de lo que estaba pasando.

Y que haya que comprar algo. Ninguna de las cuatro exigencias de arriba se resuelve con una caja, y tres de las cuatro son trabajo de diseño y de papel: mirar dependencias, decidir qué se sacrifica primero y escribir un nombre al lado de esa decisión. Nosotros vivimos de eso, así que tómatelo con la reserva que corresponde. Pero si al terminar de leer haces las tres preguntas dentro de tu casa y las respuestas te dejan tranquilo, has ganado una tarde y no nos debes nada.

Fuentes: hora de inicio (03:38 CEST del lunes 24 de agosto), lista de servicios nombrados, las dos citas literales en noruego —la de eSignering del 25 a las 10:33 y la de «estables con las limitaciones que se han puesto» del 24 a las 16:09— y la actualización del 26 a la 01:42 con ID-porten aún limitado y sin hora estimada — página de estado de Digdir (traducción nuestra); las oleadas y la cita de Are Kvistad («dos o tres veces mayor», a la agencia NTB) — The Local Norway, 25-ago-2026; el recuento de diez servicios, el papel de Vivicta y los más de 4,5 millones de usuarios de ID-portenThe Record, 25-ago-2026; ausencia de brecha y de datos comprometidos — BleepingComputer, 25-ago-2026; los dos días largos y la investigación de Kripos por los tres ataques del verano — digi.no, 26-ago-2026 (las fechas exactas de los dos ataques anteriores no coinciden entre fuentes, por eso aquí van sin día). El error de operador como primera causa de caída visible en dos de los tres servicios estudiados, y el matiz de que el hardware falla más pero la redundancia lo enmascara — Oppenheimer, Ganapathi y Patterson, «Why Do Internet Services Fail, and What Can Be Done About It?», USITS '03, USENIX. Los 8,76 h/año del 99,9 %, los catorce minutos del último simulacro (dato interno nuestro), la lectura de la puerta única como infraestructura y las tres preguntas son nuestros, no de las fuentes.

¿Sabes qué se cae en tu casa si la puerta no contesta?

Reclasificar tu puerta y dejar el resultado por escrito es consultoría, y la hacemos sin comisión de fabricante: no somos resellers de una plataforma concreta, así que la recomendación no depende de qué se lleve margen. La parte de identidad —MFA, acceso condicional, quién entra a qué— es Zero Trust. Si al hacer las tres preguntas te sale que ya lo tienes resuelto, te lo diremos.

Hablar con everyWAN

Etiquetas:

Compartir:

Suscríbete a nuestra newsletter

Para recibir historias del mundo IT, novedades de everyWAN y ofertas exclusivas para suscriptores, date de alta a nuestra lista de correo

everyWAN
everyWAN