AAA: autenticación, autorización y accounting
AAA separa tres preguntas: quién eres, qué puedes hacer y qué actividad debe registrarse. Autenticación valida una identidad; autorización decide privilegios o servicios; accounting registra eventos de sesión, comandos o consumo según el sistema. Separar estas funciones ayuda a construir administración de red auditable.
Un switch o router puede usar usuarios locales, pero centralizar AAA facilita revocar acceso, aplicar políticas comunes y conservar trazabilidad. El diseño debe incluir un plan de fallback para no perder acceso administrativo cuando los servidores centrales estén temporalmente inaccesibles.
RADIUS: acceso de red y servicios centralizados
RADIUS está definido inicialmente por RFC 2865 para autenticación/autorización y se complementa con especificaciones de accounting. Se utiliza ampliamente para acceso de usuarios y dispositivos, por ejemplo Wi-Fi empresarial, VPN y 802.1X. El Network Access Server actúa como cliente RADIUS y consulta a un servidor central.
RADIUS transporta atributos que describen la petición y la respuesta. Puede devolver aceptación, rechazo y parámetros de autorización. Históricamente utiliza UDP y secretos compartidos para proteger partes del intercambio; en diseños modernos conviene evaluar transportes protegidos y las recomendaciones de seguridad de la plataforma.
TACACS+ para administración de dispositivos
TACACS+ está documentado por RFC 8907 y se usa ampliamente para administración de dispositivos de red. Permite separar autenticación, autorización y accounting y es especialmente útil cuando quieres controlar qué comandos puede ejecutar un operador en routers, switches o firewalls.
No debe asumirse que TACACS+ y RADIUS son intercambiables sólo porque ambos centralizan AAA. RADIUS tiene un papel muy extendido en network access; TACACS+ se asocia habitualmente con device administration. La elección depende de caso de uso y soporte del fabricante.
802.1X y AAA en el acceso a la LAN/WLAN
802.1X controla el acceso a un puerto o WLAN antes de permitir tráfico normal. En un despliegue típico, el cliente es el supplicant, el switch/AP actúa como authenticator y un servidor RADIUS valida credenciales o certificados. AAA central permite asignar VLAN, políticas u otros atributos según identidad.
Esto conecta seguridad de identidad con seguridad de Capa 2 y Wi-Fi. Un fallo de autenticación puede deberse a credenciales, certificados, reachability del servidor o configuración del authenticator.
Autorización por rol y mínimo privilegio
Autenticar correctamente a un administrador no significa concederle todos los comandos. La autorización debe mapear identidades o grupos a privilegios alineados con la función. Operaciones de lectura, cambios de configuración y acciones destructivas pueden requerir niveles diferentes.
En acceso de usuarios, autorización puede seleccionar VLAN, ACL dinámica o perfil. Mantén la política en grupos y roles cuando sea posible en lugar de crear excepciones por persona difíciles de auditar.
Accounting y trazabilidad
Accounting registra quién inició una sesión, cuándo terminó y, según el protocolo/plataforma, qué comandos o recursos utilizó. Es valioso para investigación de incidentes y control de cambios, pero debe sincronizarse con una fuente de tiempo fiable para correlacionar eventos.
Integra AAA con NTP y logging central. Un registro sin hora coherente o sin identificador de dispositivo reduce mucho su utilidad. Define además retención y protección de logs.
Redundancia, timeouts y fallback
Los clientes AAA deberían conocer varios servidores cuando la plataforma lo permita. Define timeouts y orden de consulta para evitar que un servidor caído provoque esperas excesivas. El fallback local para administración de emergencia debe existir, pero estar protegido y probado.
No diseñes un círculo de dependencias: si acceder al equipo para reparar routing exige un servidor AAA que sólo es alcanzable a través del routing averiado, necesitas una vía de recuperación. Redes de gestión y cuentas break-glass deben documentarse con controles estrictos.
Protección del plano AAA
AAA controla accesos privilegiados, por lo que sus servidores y secretos son activos críticos. Limita qué dispositivos pueden consultarlos, protege las rutas de gestión, rota credenciales y utiliza mecanismos criptográficos modernos cuando estén disponibles. Un secreto compartido débil o reutilizado amplía el impacto de una exposición.
El firewall puede restringir clientes y puertos hacia los servidores AAA. La guía de firewalls ayuda a convertir esta dependencia en una política explícita en lugar de permitir tráfico de administración desde cualquier segmento.
Troubleshooting de RADIUS y TACACS+
Primero separa reachability de autenticación. Comprueba DNS si se usa nombre, routing, puerto, firewall y reloj/certificados si aplica. Después revisa que cliente y servidor compartan la misma definición de secreto o trust, que el usuario llegue al backend correcto y que la política devuelva autorización válida.
- ¿La petición llega al servidor AAA?
- ¿El servidor identifica correctamente al NAS/dispositivo cliente?
- ¿Falla autenticación o autorización posterior?
- ¿Existe accounting para correlacionar el intento?
- ¿El fallback local funciona de manera controlada?
Ejemplo de AAA para administrar switches y Wi-Fi
Una organización puede usar TACACS+ para que administradores de red entren en switches y routers con su identidad corporativa y queden registrados los comandos relevantes. Paralelamente, RADIUS puede autenticar usuarios de Wi-Fi mediante 802.1X y devolver atributos que asignan un perfil o VLAN. Son dos flujos de AAA con objetivos diferentes aunque compartan directorio de identidades.
Si los servidores centrales fallan, los dispositivos conservan una cuenta local de emergencia protegida y monitorizada. El diseño evita usar esa cuenta en operación normal y prueba periódicamente que el procedimiento de recuperación funciona sin convertir el fallback en una puerta trasera permanente.
Identidades humanas, cuentas de servicio y red de gestión
En producción también conviene separar las identidades humanas de las cuentas usadas por automatización. Un pipeline o sistema de backup no debería compartir la misma credencial que un administrador. Cuando la plataforma lo permita, utiliza cuentas de servicio, scopes limitados y rotación independiente. Así puedes revocar o investigar una automatización sin afectar al acceso de las personas.
La autorización debe considerar además desde dónde se administra. Una red de gestión dedicada, una VPN administrativa o una VRF reducen la superficie desde la que pueden alcanzarse los puertos AAA y de gestión. Esa segmentación no reemplaza AAA, pero añade otra barrera si una credencial se ve comprometida.