Tres roles no son un modelo de acceso.
Muchas plataformas de entrega ofrecen una lista corta de roles — administrador, operador, solo lectura — y todo lo que no encaja acaba siendo administrador. El equipo de certificados obtiene permisos completos sobre el tráfico porque los certificados viven bajo el tráfico. La integración de monitorización recibe un token de administrador porque no existe uno menor.
El resultado es previsible: una auditoría pregunta quién pudo hacer un cambio y la respuesta honesta es «casi toda la consola». La separación de funciones existe en el organigrama, no en el producto.
El segundo fallo es la deriva entre superficies. Un permiso que se aplica en la interfaz pero no en la API no es un permiso, es una sugerencia.
Nuestro enfoque
El rol nombra el trabajo. El alcance nombra el radio de impacto. Ambos se aplican en cada superficie.
Dieciséis roles, no tres
Los roles siguen las líneas por las que los equipos se dividen realmente: tráfico, WAF, red, GTM, certificados y monitorización, con variante de gestor y de usuario donde esa distinción importa, más roles de solo lectura y solo frontend para quienes deben ver sin tocar.
Alcance por encima del rol
El rol dice qué tipo de objeto puede tocar un usuario. El alcance dice cuáles: direcciones frontend permitidas, redes backend permitidas, vServices y vDevices asignados. Dos Traffic Manager administran dos infraestructuras distintas en un mismo equipo sin ver los servicios del otro.
Un modelo de permisos en interfaz, CLI y API
La CLI interactiva aplica el mismo rol que la interfaz — un Network Manager ve comandos de red y nada más — y el acceso REST se filtra por área y por campo con el mismo modelo. Los tokens de API persistentes están ligados al rol.
Cada superficie escribe en la misma pista de auditoría
Un cambio hecho con un clic, con un comando o con una llamada a la API queda en una única pista de auditoría con diffs de antes y después sin pérdida. La pregunta del auditor tiene una sola respuesta.
Capacidades
Qué cubre el modelo de roles y qué se apoya sobre él.
Dieciséis roles administrativos con nombre
El conjunto completo: Admin (super-admin) · Traffic Manager · Traffic User · Traffic+WAF Manager · Traffic+WAF User · WAF Manager · WAF User · WAF Read-Only · Network Manager · Network User · GTM User · Certificate Manager · Monitor User · Read-Only User · Frontend User · Client. Las variantes de gestor y usuario separan el derecho a configurar del derecho a operar.
Alcance de red — direcciones frontend y redes backend permitidas
El alcance de un usuario se limita por dirección, no solo por tipo de objeto, de modo que un error se queda dentro del segmento del que es responsable.
Alcance de recursos — vServices y vDevices asignados
A los usuarios se les asignan los servicios publicados y los vDevices concretos que les pertenecen. El resto no está en solo lectura para ellos: es invisible.
Derechos sobre certificados: gestión frente a selección
El derecho a elegir un certificado para un servicio y el de gestionar la biblioteca de certificados son distintos. Un equipo de aplicación publica con el certificado correcto sin poder exportar, sustituir o borrar la clave.
Acceso a shell como interruptor por usuario
CLI por SSH y CLI en el navegador son dos interruptores independientes, cada uno con un máximo de sesiones. A un operador se le puede dar la consola del navegador sin que exista una cuenta SSH para él.
Cuotas por usuario: ancho de banda, CPU y conexiones
Un rol puede llevar un techo de recursos además de un conjunto de permisos, para que un administrador de inquilino no consuma el equipo en nombre de todos.
Autorización de API por campo
El acceso REST se filtra por área y por campo con el mismo modelo que la interfaz. Un rol que no ve un campo en la consola tampoco lo lee por la API.
Administradores desde el directorio y autenticación fuerte
Los administradores se autentican contra cuentas locales, LDAP y Active Directory, RADIUS o TACACS+ con accounting. Doble factor por código de un solo uso por SMS o correo, tokens de recuperación y acceso con certificado cliente mTLS emitido por la PKI interna de TR7.
Las preferencias de puesto acompañan al usuario
Idioma, tema y disposición de la barra superior se guardan por usuario, así la consola se ve igual en cualquier nodo del clúster.
Profundidad operativa
Las partes que deciden si un modelo de acceso supera una auditoría.
Separación de funciones expresada, no prometida
Como WAF, tráfico, red, GTM y certificados son familias de roles separadas, el requisito habitual de los sectores regulados — quien cambia la política de seguridad no es quien cambia la ruta del tráfico — se convierte en configuración y no en un procedimiento que alguien deba recordar.
Roles de solo lectura que de verdad son de solo lectura
Read-Only User, WAF Read-Only y Monitor User existen para que auditores, personal de NOC y paneles no necesiten un rol capaz de cambiar algo.
Roles Frontend User y Client para acceso delegado
Frontend User cubre a quienes trabajan con servicios publicados sin tocar la plataforma. Client cubre el caso de cliente en la nube, donde la cuenta pertenece al consumidor del servicio y no a su operador.
Defensa contra fuerza bruta en el plano de gestión
Se exige complejidad de contraseña y los inicios fallidos se limitan con presupuestos que caducan por IP y por IP más nombre de usuario, respaldados por el CAPTCHA integrado.
Servicios de gestión enlazados y acotados por separado
HTTPS, SSH, FTP y SNMP se enlazan cada uno a una dirección y puerto elegidos y llevan su propia lista de redes permitidas, su certificado y sus versiones TLS mínima y máxima. La consola puede exigir TLS 1.3 mientras una integración más antigua alcanza otro servicio con TLS 1.2.
Cuentas de transferencia de ficheros con propósito acotado
La transferencia de ficheros no pasa por una cuenta compartida. Cuentas separadas cubren la exportación de registros, la copia de configuración, la entrega sin conexión de la base de reputación IP y los paquetes de actualización sin conexión, y cada una ve solo su directorio.
Cuándo usarlo
Separación de funciones regulada
Un banco necesita que el responsable de la política WAF y el del tráfico sean personas distintas, y demostrarlo. WAF Manager y Traffic Manager son roles separados con pistas de auditoría separadas: la prueba es un informe, no una entrevista.
Equipos de aplicación que publican sus propios servicios
Cada equipo recibe un rol Traffic User acotado a sus vServices y sus redes backend. Publican y operan sin petición de cambio y sin alcanzar los servicios de otros.
Tokens de pipeline y monitorización
Un pipeline de CI/CD recibe un token de API persistente ligado a un rol estrecho y un sistema de monitorización uno ligado a Monitor User. Ninguno lleva permisos de administrador.
Un equipo de certificados que no posee el tráfico
Certificate Manager administra la biblioteca de claves y las renovaciones; los equipos de aplicación eligen de ella. La clave privada nunca se entrega al equipo que publica el servicio.
Preguntas frecuentes
¿Cuántos roles administrativos trae TR7?
¿La CLI está sujeta a los mismos permisos que la interfaz?
¿Pueden dos administradores gestionar servicios distintos en un equipo sin verse?
¿Se puede limitar un token de API a menos que un administrador?
¿RBAC requiere una licencia adicional?
¿Cómo se autentican los administradores?
Dieciséis roles, acotados por usuario, aplicados en cada superficie
Repasemos el modelo de roles frente a sus propios requisitos de separación de funciones.