Le dimos permisos de administrador. Siguió sin poder entrar.

Estábamos sacando a una empresa manufacturera de un servicio de red privada que se les había vuelto inadministrable, hacia otro. La infraestructura ya estaba probada. Faltaba lo fácil: meter a la primera persona.

Diez minutos, calculamos. Fue una hora. Y de esa hora salieron dos lecciones: una técnica, y otra que preferiríamos no haber tenido que aprender.

Acto primero: el reflejo#

La persona —del área de contabilidad, trabajando desde su casa— instala el cliente, escribe el nombre de la organización, y recibe esto:

Cloudflare Access
────────────────────────────────
That account does not have access.

Sign in with:
  [ Cloudflare ]

El reflejo, y lo tuvimos: «dale permisos de administrador».

Se los dimos. Siguió sin poder entrar.

Y ahí está la primera lección, que es la incómoda: los privilegios y el acceso son dos sistemas distintos. El administrador maneja túneles, DNS y políticas. Quién entra a la red lo decide la política de inscripción de dispositivos, y esa política no mira si eres administrador. Mira una lista.

Vale la pena decir qué le habíamos dado sin querer. Con ese rol, ella —o quien le tomara la cuenta— podía borrar el túnel por el que entra toda la empresa, cambiar el DNS del dominio, o abrir la red a cualquiera. Lo que necesitaba era alcanzar una sola dirección.

Esto no es una anécdota nuestra: es el fallo de seguridad más común que existe en una empresa chica. No un ataque. Alguien con prisa subiéndole el permiso a un compañero un viernes para desatorarlo. Y casi siempre funciona, que es lo peor — porque entonces nadie se entera de que quedó abierto.

Aquí no funcionó. Es la única razón por la que lo descubrimos el mismo día.

Acto segundo: el código que nunca llegó#

Con eso claro, revisamos por qué le pedía cuenta en vez de mandarle un código. La respuesta estaba en la aplicación de inscripción:

Accept all available identity providers        OFF

Choose available identity providers:
  (vacío)

Lo activamos. Ella escribe su correo. Y entonces:

A code has been emailed to
<su correo>.  It expires in 10 minutes.

Didn't get the code?   Resend

Nunca llegó ninguno.

Descartamos lo obvio, en este orden: el buzón funcionaba —le mandamos un correo normal y llegó—, no era correo no deseado, y no era el proveedor de correo de la empresa, porque la dirección era personal.

Lo que en realidad pasaba#

El sistema no estaba enviando nada. Y decía que sí.

Cloudflare no manda el código si la dirección no está autorizada por alguna política. Pero la pantalla igual dice «te lo enviamos».

No es un error. Es a propósito, y está bien hecho: si contestara «ese correo no pertenece a esta organización», cualquiera podría escribir direcciones una por una hasta armar la lista completa de quién trabaja ahí. La pantalla dice siempre lo mismo justamente para no filtrar nada.

Ahí está la tensión que hace interesante este caso: la medida que los protege es la misma que nos escondió la causa durante una hora. Y no queremos que la quiten. El trabajo de ese sistema no es ayudarnos a diagnosticar; es no soltar información. Cumplió.

El error fue nuestro, y fue de método: le seguimos preguntando a un sistema que, por diseño, no puede contestar.

La prueba de control#

Lo que resolvió la hora fueron veinte segundos.

Abrimos la misma pantalla en nuestro propio navegador y pedimos el código con una dirección que sabíamos autorizada — la nuestra, que ya tenía un dispositivo inscrito. Luego con la de ella.

correo propio (autorizado)      "código enviado"   →  llegó en 4 s
correo de la persona            "código enviado"   →  nunca llegó

Ésa es la regla que sacamos, y sirve mucho más allá de este caso: cuando un sistema no puede decirte la verdad, no le insistas. Compáralo contra algo que sabes que funciona.

Un control conocido convierte una pantalla ambigua en un dato. Sin él, íbamos a seguir reenviando códigos toda la tarde, culpando al correo.

Lo que hicimos#

1. Le quitamos el permiso de administrador. No servía para lo que se le dio, y sí abría lo que no debía.

2. Dejamos un solo método de entrada: código al correo. Quitamos la opción de cuenta de Cloudflare, que era la que producía el error del principio. Una puerta que nadie puede usar solo confunde a quien la toca.

3. Su correo en las reglas de la política. Que es lo único que hacía falta desde el minuto uno.

4. La verificamos con trabajo real, no con un ping. Entró desde su casa, con su usuario, a trabajar en el sistema administrativo de la empresa.

La verificación, y la trampa que casi nos come#

La dirección del servidor es privada — del tipo 192.168.x.x, las que el estándar reserva para redes internas. Esas direcciones no se enrutan por internet. Ningún proveedor las lleva a ningún lado.

Entonces, si desde su casa esa dirección abrió, solo pudo llegar por el túnel. No hay otra explicación. Eso es una prueba, no una impresión.

Pero hubo que descartar algo antes, y por poco no lo hacemos: el puerto viejo seguía abierto a internet. Si su acceso directo hubiera apuntado ahí en vez de a la dirección privada, habría funcionado igual de bien sin el túnel — y nos habríamos ido a dormir creyendo que la migración estaba probada.

Una prueba que pasa por la razón equivocada es peor que una que falla. La que falla te avisa.

Lo que queda como regla#

Privilegios y acceso son sistemas distintos. Subirle el permiso a alguien para desatorarlo casi nunca resuelve el bloqueo, y siempre deja una puerta abierta que nadie va a recordar cerrar.

Cuando un sistema calla por seguridad, no lo interrogues: compáralo. Una identidad que sabes que funciona convierte veinte minutos de suposiciones en veinte segundos de dato.

Y verifica por dónde entró, no solo que haya entrado. Mientras el camino viejo siga abierto, cualquier prueba puede estar pasando por él.

Caso real de una empresa manufacturera. Se omitieron nombres de personas, correos, cuentas y direcciones internas. Los rangos de direcciones mencionados son los que define el estándar para redes privadas y no identifican a nadie.