¿Cuáles son las principales diferencias entre ISE 3.2 y 3.4 para el diseño de políticas?

Cisco ISE 3.4 introduce una mayor fiabilidad del Messaging Service, soporte expandido para SAML 2.0 para proveedores de identidad en la nube y opciones más granulares de evaluación de postura en comparación con 3.2. También refuerza la seguridad al desaprobar protocolos más antiguos e inseguros por defecto.

¿Cómo minimizo la latencia en la evaluación de políticas de ISE?

Las implementaciones a gran escala deben utilizar Grupos de Dispositivos y atributos basados en la Ubicación en las políticas de selección de servicios para mantener los Policy Sets individuales enfocados y con menos de 100 reglas cada uno. Utilice la lógica de evaluación de arriba hacia abajo para colocar el tráfico más frecuente (dot1x) por encima del tráfico menos frecuente (Invitado/CWA).

¿Sigue siendo viable MAB (MAC Authentication Bypass) en un entorno Zero Trust?

MAB siempre debe combinarse con el perfilado DHCP y HTTP. Nunca confíe solo en una OUI MAC. En entornos de alta seguridad, los dispositivos MAB desconocidos deben ser puestos en cuarentena utilizando un SGT y escaneados con NMAP antes de concederles acceso limitado.

¿Por qué debería usar SGTs en lugar de VLANs para la segmentación?

Los SGTs (Security Group Tags) de TrustSec permiten una segmentación basada en la identidad que es independiente de la topología VLAN/IP subyacente. Esto reduce la complejidad de los conjuntos de reglas de firewall y previene el 'VLAN sprawl' en grandes redes de campus.

¿Cómo soluciono los errores de 'EAP Session Timed Out'?

Verifique 'Operations > RADIUS > Live Logs' y busque el Error 5411. Esto generalmente indica una brecha de comunicación entre el suplicante y ISE, a menudo causada por un tiempo de espera en el switch de red o la configuración EAP del endpoint.

¿Cuál es el hardware recomendado para una implementación global de ISE 3.4?

Para implementaciones a gran escala, utilice un par de appliances de la serie 3700 o VMs equivalentes por región. Asegúrese de que haya una latencia de ida y vuelta inferior a 300ms entre los PSN y el PAN primario para la sincronización de la base de datos. Utilice un Load Balancer con persistencia de sesión para el tráfico EAP.

Diseño Empresarial: Dominando los Policy Sets de Cisco ISE 3.4 para 2026

Cisco Identity Services Engine (ISE) 3.4 ya no es solo un servidor RADIUS; es el motor de políticas para la red programable. Si todavía está implementando ISE con una lista plana de Policy Sets con lógica pesada o confiando en una lógica "hit-first" obsoleta sin segmentación contextual, está construyendo un castillo de naipes que colapsará bajo el peso de la proliferación de IoT y los requisitos de Zero Trust en 2026. El cambio de ISE 2.x a 3.x introdujo matices arquitectónicos que muchos ingenieros ignoran, lo que lleva a la degradación del rendimiento y a una "saturación de políticas" (policy bloat) que convierte la resolución de problemas en una pesadilla.

La Arquitectura de los Policy Sets Modernos

Para diseñar ISE a escala, debemos alejarnos del enfoque de "silo heredado". En una empresa global, los Policy Sets deben estructurarse por tipo de sitio o unidad de negocio, en lugar de por tipos de dispositivos globales. ISE 3.4 procesa las políticas de arriba hacia abajo, pero la velocidad de evaluación depende en gran medida del número de condiciones dentro de cada conjunto. Utilizamos la jerarquía de Policy Sets para minimizar la ruta de evaluación.

Un "Estándar de Oro" para una estructura de Policy Set lista para 2026 se ve así:

Infraestructura Global: (TACACS+ para administradores de red)
Inalámbrico - Corporativo: (802.1X, EAP-TLS, dispositivos gestionados)
Inalámbrico - Invitados: (WebAuth, CWA)
Cableado - Dot1X: (802.1X estricto para estaciones de trabajo)
Cableado - MAB/IoT: (Gran dependencia del perfilado para dispositivos headless)
VPN/ZTNA: (AnyConnect/Secure Client con integración SAML 2.0 / Azure AD)

Al separar la red cableada e inalámbrica a nivel de Policy Set (nivel superior), se reduce el número de reglas de autorización que el motor debe verificar para cada solicitud de MAC authentication bypass (MAB). Si su escáner de IoT está llegando al mismo Policy Set que el iPad de su CEO, su diseño es defectuoso.

Condiciones Avanzadas: Más allá de los Atributos RADIUS Básicos

En ISE 3.4, aprovechamos las Smart Conditions. Deje de codificar direcciones IP o IDs de Switch específicos en su política. En su lugar, utilice Grupos de Dispositivos y jerarquías de Ubicación. Si tiene 500 oficinas, use el atributo DEVICE:Device-Location. Esto le permite escalar a más de 100,000 endpoints sin agregar una sola línea a su lógica de política cuando se abre una nueva sucursal.

Condition: Wired_Auto_Condition
Logic: Radius:Service-Type EQUALS Framed-User 
AND Cisco-VPN-3000:CVPN3000-User-Group CONTAINS 'Finance'
AND DEVICE:Device-Location STARTSWITH 'Americas#West'

La introducción de PassiveID y la profunda integración con Microsoft Azure AD (Entra ID) significa que sus condiciones ahora deberían utilizar frecuentemente AzureAD:ExternalGroups. Sin embargo, un error común es la latencia introducida por múltiples llamadas a la API REST a la nube. En 3.4, asegúrese de utilizar el ISE Messaging Service para manejar la obtención de atributos de alta frecuencia de sus conectores AD para evitar tiempos de espera de autenticación (Error 5411).

Perfiles de Autorización e Integración con TrustSec (SGT)

La segmentación tradicional basada en VLAN está obsoleta. Es demasiado frágil. En un entorno moderno de Cisco DNA Center o VXLAN/EVPN manual, sus perfiles de autorización deben enviar Security Group Tags (SGTs). El SGT es la "etiqueta de identidad" que permanece con el paquete, independientemente de dónde se mueva el usuario en el campus.

Al configurar sus perfiles de autorización en ISE 3.4, siempre debe devolver:

VLAN ID/Name: Como respaldo para switches no conscientes de SGT.
SGT (Security Group Tag): Para la aplicación basada en hardware en la serie Catalyst 9k.
Voice Domain Permission: Necesario para implementaciones multi-auth en un solo puerto.

Por ejemplo, un perfil "Developer_Access" debe devolver SGT 15. La política en su ASA/FTD o Catalyst Core luego maneja la lógica real de permitir/denegar 15 -> 20 (DB_Servers). Esto elimina el "VLAN Sprawl" que ha afectado a las redes de campus durante la última década.

MAB vs. Dot1X: El Conflicto de Zero Trust

La industria está impulsando "Dot1X en todas partes", pero la realidad de 2026 es una explosión de IoT no gestionado. MAC Authentication Bypass (MAB) es inherentemente inseguro; las direcciones MAC son fáciles de suplantar. Para mitigar esto en ISE 3.4, utilizamos Profiling + Probing. No permita que un dispositivo MAB acceda a la red basándose únicamente en que su dirección MAC esté en una lista.

Utilice la siguiente jerarquía de sondeos para un perfilado de alta fidelidad:

Sondeo DHCP: Captura las cadenas Option 55 y Option 60 (más precisas para la detección de SO).
Sondeo HTTP: Captura la cadena User-Agent del navegador.
Consulta SNMP: Utilizado para switches industriales heredados.
Escaneo NMAP: Activado como un CoA (Change of Authorization) cuando un dispositivo es "Unknown".

El refinamiento de estos sondeos le permite escribir una política que dice: "Identificar esto como una impresora HP solo si la MAC está registrada OUI a HP Y la Opción 60 de DHCP coincide con 'HP-JetDirect'". Si el SO cambia a 'Kali Linux', ISE envía un CoA Disconnect inmediato.

Evaluación de Postura en 3.4: El Cumplimiento es Innegociable

ISE 3.4 maneja la postura a través de AnyConnect/Cisco Secure Client. En un mundo híbrido post-COVID, el estado de la máquina es tan importante como las credenciales del usuario. La lógica de su Policy Set para los activos corporativos siempre debe incluir tres estados:

Desconocido: VLAN temporal / SGT limitado. Redirigir al portal de aprovisionamiento de clientes para descargar el agente.
No conforme: Redirigir a la remediación (WSUS/gestión de parches). SGT de alto riesgo aplicado.
Conforme: SGT de acceso completo aplicado.

Consulte nuestra inmersión profunda sobre la optimización de los módulos de postura de Secure Client para más detalles. Recomendamos utilizar la Re-evaluación Periódica (PRA) cada 4 a 8 horas para objetivos de alto valor (controladores financieros, roles de administrador) para asegurar que no hayan deshabilitado su EDR/AV después del inicio de sesión inicial.

Resolución de Problemas de ISE 3.4: La Realidad de la Ingeniería

Cuando un usuario no puede conectarse, deje de mirar primero la CLI del Switch. Vaya directamente a Operations > RADIUS > Live Logs. En ISE 3.4, la sección "Steps" del informe detallado es su hoja de ruta. Busque 'Step 11001: Received RADIUS Access-Request' y sígalo hasta 'Step 15008: Evaluating Service Selection Policy'.

Fallos comunes que vemos en el campo:

11507 Ext-ID Store failure: Sus nodos ISE no pueden contactar a los Domain Controllers. Verifique la latencia; si es >200ms, la autenticación fallará.
5411 EAP Session Timed Out: Generalmente causado por el endpoint esperando que un usuario ingrese credenciales, o el switch agotando el tiempo de espera demasiado pronto. Aumente el dot1x timeout tx-period en sus puertos Catalyst.
12511 Unexpected Certificate in EAP-TLS: El cliente está presentando un certificado no firmado por una CA en su almacén de Certificados Confiables o la verificación de CRL falló.

Utilice la herramienta TCP Dump integrada en el nodo Cisco ISE (Operations > Troubleshoot > Diagnostic Tools) para capturar el tráfico directamente en la interfaz Gi0 del Policy Service Node (PSN). Esto suele ser más rápido que configurar un RSPAN en el switch.

Escalando la Implementación: Grupos de PSN y Balanceo de Carga

No utilice solo un balanceador de carga round-robin. Para implementaciones de ISE a gran escala (más de 50,000 endpoints), utilice Persistent Sessions en su F5 o Citrix ADC. Si un endpoint inicia una secuencia EAP con PSN-01, debe terminarla con PSN-01. Si el balanceador de carga cambia el medio de una transacción a PSN-02, la sesión fallará porque el estado EAP es local para el nodo.

Diseñe sus nodos PSN en pares por región geográfica. Un solo appliance 3695 (grande) puede manejar aproximadamente 50,000 sesiones concurrentes, pero recomendamos limitar esto a 30,000 para dejar margen para picos de MAB con alto perfilado durante cortes de energía (cuando 5,000 impresoras intentan reconectarse a la vez).

En resumen, Cisco ISE 3.4 es el cerebro de su red. Trate sus Policy Sets con el rigor del código. Cada condición debe tener un propósito, y cada regla debe acercarle a un entorno macro-segmentado y basado en SGT. Para obtener ayuda práctica con su diseño de ISE o una auditoría de seguridad completa, visítenos en techleague.io.