La pregunta que un login compartido no puede responder
La mayoría de los equipos pequeños empiezan con un único juego de credenciales. Funciona hasta el primer incidente, y entonces falla de una forma muy concreta: algo cambió, el cambio es visible, y nadie puede decir quién lo hizo ni qué reemplazó.
Ese hueco cuesta más que el bochorno. Sin un registro no puedes distinguir un error de una intrusión. No puedes deshacer el cambio con confianza, porque no conoces el valor anterior. Y no puedes mejorar el proceso, porque "ten más cuidado" es la única lección disponible cuando nadie sabe qué pasó realmente.
Hay también una mirada externa. Un registro revisable de acciones administrativas y un control de acceso con sentido son expectativas estándar en cuestionarios de seguridad y en marcos como ISO 27001, y regímenes de protección de datos como el KVKK y el RGPD esperan que puedas demostrar quién tenía acceso a qué. Certifiques algo o no, el requisito describe algo que quieres tener por tu propio bien.
Qué se registra
El historial de actividad cubre los cambios que pueden afectar a lo que ve un visitante: purgas de caché, cambios de registros DNS, cambios de reglas de entrega, cambios de presets de seguridad — incluidos HSTS y las listas de bloqueo por país y ASN —, acciones sobre certificados y cambios de hostname.
Cada entrada lleva cuatro cosas que la hacen útil. Quién: la persona real, así que un sub-usuario aparece como sí mismo en lugar de como "la cuenta". Cuándo. Qué cuenta y qué ruta tocó el cambio. Y antes y después, así que el valor anterior está ahí en lugar de ser algo que reconstruyes de memoria.
Ese último campo es lo que convierte el registro de un informe en una herramienta. "Regla de entrega cambiada" te dice dónde mirar. "TTL de caché 3600 → 60" te dice qué le pasó a tu tráfico de origen en ese mismo instante.
Leerlo mientras algo está roto
Abre la barra lateral de la cuenta, luego Monitorización → Historial de actividad — /management/cdn/activities.
Durante un incidente, una secuencia que funciona: acota la ventana de tiempo que te interesa, mira la cuenta entera en lugar de solo el cambio que ya sospechas, y lee los valores antes/después en lugar de los títulos de las entradas. El cambio que rompió el sitio no suele ser el que tenías en mente, y la pista suele estar en el orden — dos entradas de personas distintas con cinco minutos de diferencia son, por lo general, toda la historia.
Filtrar por tipo de acción es lo que hace legible una cuenta con mucho movimiento. Un sitio con una purga automática en cada publicación genera muchísimas entradas que no son lo que buscas; fíltralas y el puñado de cambios de configuración que queda es lo bastante corto para leerlo entero.
Fuera de un incidente, la misma página responde a una pregunta más tranquila: ¿está cambiando algo que nadie mencionó? Eso vale cinco minutos al mes.
Acceder a él desde la API
El historial también está disponible por la API, que es lo que quieres si lo archivas, lo reenvías a tu propio sistema de logging, o simplemente guardas más del que te apetece desplazar en pantalla. action_type acepta las mismas categorías que el filtro del panel, y el endpoint solo te muestra las cuentas que tu token tiene permiso para ver.
Las últimas 25 purgas de una cuenta
curl -s -H "Authorization: Bearer $TOKEN" \
"https://cdn.com.tr/api/accounts/<account-uuid>/activities?per_page=25&action_type=purge_cache"Tres roles, y para qué sirve cada uno
Un registro te dice qué pasó. Los roles reducen qué puede pasar. Un sub-usuario en cdn.com.tr recibe uno de tres.
Visor lee todo lo que muestra la cuenta y no cambia nada salvo su propio perfil y contraseña. Es el rol correcto para un gestor que quiere los gráficos, una agencia que informa sobre rendimiento, o cualquiera que necesite mirar durante un incidente sin poder empeorarlo.
Editor hace el trabajo operativo: purgar caché, editar reglas de entrega, gestionar registros DNS, certificados y hostnames. Lo que un editor no puede hacer es cambiar la forma de la cuenta en sí — ni crear o eliminar sub-usuarios, ni facturación, ni eliminar la cuenta. Es el rol para las personas que llevan el sitio día a día.
Propietario lo hace todo, incluidas las tres cosas de las que un editor se mantiene deliberadamente alejado. Es el titular de la cuenta, y debería seguir siendo una lista muy corta.
Dos detalles que conviene saber. Si se crea un sub-usuario sin elegir un rol, se convierte en visor — el extremo seguro de la escala, así que un campo olvidado nunca puede dar más de lo que pretendías. Y los roles se aplican a los tokens de API exactamente igual que en el panel: el token de un visor puede leer y no puede escribir, así que un script ejecutado por alguien que no puede cambiar el DNS no puede cambiar el DNS.
Añadir a alguien, con el acceso que necesita
Ve a Autorización — /management/authorization — y elige Nuevo usuario. Rellena sus datos y elige el rol antes de guardar; es el campo que decide todo lo demás sobre lo que esa persona puede hacer.
Dos hábitos hacen que esto funcione en la práctica. Da a cada persona su propio login en lugar de compartir uno: el historial de actividad solo es tan útil como los nombres que contiene, y "purgado por la cuenta compartida" es el mismo callejón sin salida del que partiste. Y cuando alguien se une para un trabajo concreto — una migración, la colaboración de una agencia, un contratista —, dale el rol que ese trabajo necesita y quítaselo cuando termine. El acceso latente del que nadie responde es el hallazgo más común en cualquier revisión de accesos, y el más fácil de evitar.
Mínimo privilegio sin resultar molesto
El mínimo privilegio tiene mala fama porque suele implementarse como "pregúntame cada vez", lo que la gente acaba evitando en una semana. La versión que sobrevive al contacto con un equipo que trabaja de verdad es más simple.
Pon a todo el mundo en visor por defecto y asciende bajo petición. Cuesta un solo mensaje la primera vez que alguien necesita purgar, y significa que nadie carga con un acceso que nunca pidió.
Da el rol de editor a las personas cuyo trabajo es cambiar cosas — y fíjate en dónde está el límite: un editor puede hacer todo lo que arregla un sitio en vivo y nada que cambie quién más tiene las llaves o qué se te factura. Esa es la línea que de verdad importa, y por eso el rol no es una concesión.
Reserva el de propietario para quienes responden por la cuenta, y actúa sobre los cambios el mismo día que ocurren. El registro anota lo que se hizo, no quién debería seguir pudiendo hacerlo; esa parte sigue siendo tuya.
Las dos funciones son un único control
Es tentador tratar el registro como la función de seguridad y los roles como mera administración. Funciona al revés.
Los roles son prevención. Deciden qué es posible siquiera, que es lo único que evita un accidente antes de que lo vean tus visitantes. El registro es detección y rendición de cuentas: te dice qué se hizo, quién lo hizo y cuál era el valor anterior.
Ninguno de los dos vale mucho por separado. Roles sin registro significa confiar en un límite que nunca puedes comprobar. Un registro sin roles significa que puedes describir cada incidente a la perfección y no prevenir ninguno. Juntos responden a la pregunta que de verdad se hace después de una caída — nunca "qué es una CDN", siempre "quién cambió esto, y por qué podía hacerlo?"
Preguntas frecuentes
¿El registro muestra a cada sub-usuario o solo a la cuenta?
Individualmente. La entrada registra a la persona real que hizo el cambio, así que un sub-usuario aparece con su propio nombre en lugar de como el propietario de la cuenta. Ese es todo el sentido: un registro que dice "lo hizo la cuenta" no responde nada que no supieras ya.
¿Cómo averiguo quién purgó la caché?
Abre Monitorización → Historial de actividad en la cuenta, filtra por el tipo de acción de purga, y encuentra la entrada en el momento en cuestión. Muestra la persona, la hora exacta y la ruta o patrón que se purgó.
¿Cuál es la diferencia entre visor y editor?
Un visor puede mirar todo y solo puede cambiar su propio perfil y contraseña. Un editor puede hacer el trabajo operativo — purgar, reglas de entrega, registros DNS, certificados y hostnames — pero no puede añadir ni eliminar sub-usuarios, no puede tocar la facturación y no puede eliminar la cuenta.
¿Qué pasa si creo un sub-usuario y me olvido de elegir un rol?
Se convierte en visor. El valor por defecto es deliberadamente el extremo de solo lectura de la escala, así que un campo sin rellenar nunca concede silenciosamente más acceso del que pretendías.
¿Los roles también se aplican a los tokens de API?
Sí. La API aplica los mismos roles que el panel, así que un token bearer que pertenece a un visor puede leer y no puede escribir. El acceso lo decide quién es la persona, no por qué puerta entró.
¿Puedo guardar el historial en algún sitio propio?
Sí — el endpoint de actividades es la vía de exportación. Recórrelo página a página con un token bearer, filtrando por tipo de acción si solo quieres un subconjunto, y guarda el JSON donde lleves tus registros.