Quais são as principais diferenças entre o ISE 3.2 e o 3.4 para o design de políticas?

O Cisco ISE 3.4 introduz maior confiabilidade do Messaging Service, suporte expandido a SAML 2.0 para provedores de identidade em nuvem e opções mais granulares de avaliação de postura em comparação com o 3.2. Ele também reforça a segurança, depreciando protocolos mais antigos e inseguros por padrão.

Como posso minimizar a latência na avaliação de políticas do ISE?

Implantações em grande escala devem usar Device Groups e atributos baseados em localização nas políticas de seleção de serviço para manter os Policy Sets individuais focados e com menos de 100 regras cada. Use a lógica de avaliação de cima para baixo para colocar o tráfego mais frequente (dot1x) acima do tráfego menos frequente (Guest/CWA).

O MAB (MAC Authentication Bypass) ainda é viável em um ambiente Zero Trust?

O MAB deve sempre ser combinado com 'profiling' via DHCP e HTTP. Nunca confie apenas em um MAC OUI. Em ambientes de alta segurança, dispositivos MAB desconhecidos devem ser colocados em quarentena usando um SGT e escaneados com NMAP antes de terem acesso limitado concedido.

Por que devo usar SGTs em vez de VLANs para segmentação?

As SGTs (Security Group Tags) do TrustSec permitem a segmentação baseada em identidade que é independente da topologia de VLAN/IP subjacente. Isso reduz a complexidade dos conjuntos de regras de firewall e evita o 'VLAN sprawl' em grandes redes de campus.

Como faço o 'troubleshooting' de erros de 'EAP Session Timed Out'?

Verifique 'Operations > RADIUS > Live Logs' e procure pelo Erro 5411. Isso geralmente indica uma falha de comunicação entre o 'supplicant' e o ISE, muitas vezes causada por um 'timeout' no 'switch' de rede ou na configuração EAP do 'endpoint'.

Qual é o hardware recomendado para uma implantação global do ISE 3.4?

Para implantações em larga escala, use um par de 'appliances' da série 3700 ou VMs equivalentes por região. Garanta que haja menos de 300ms de latência de ida e volta entre os PSNs e o PAN Primário para sincronização do banco de dados. Use um Load Balancer com persistência de sessão para o tráfego EAP.

Design Corporativo: Dominando os Policy Sets do Cisco ISE 3.4 para 2026

O Cisco Identity Services Engine (ISE) 3.4 não é mais apenas um servidor RADIUS; ele é o motor de políticas para a rede programável. Se você ainda está implantando o ISE com uma lista plana de 'policy sets' com muita lógica ou dependendo da lógica desatualizada de "hit-first" sem segmentação contextual, você está construindo um castelo de cartas que ruirá sob o peso da proliferação de IoT e dos requisitos de Zero Trust em 2026. A transição do ISE 2.x para o 3.x introduziu nuances arquitetônicas que muitos engenheiros ignoram, levando à degradação de performance e ao "inchaço de políticas" que torna o 'troubleshooting' um pesadelo.

A Arquitetura dos Policy Sets Modernos

Para projetar o ISE em escala, precisamos abandonar a abordagem de "silo legada". Em uma empresa global, os Policy Sets devem ser estruturados por tipo de localidade ou unidade de negócio, em vez de tipos de dispositivos globais. O ISE 3.4 processa políticas de cima para baixo, mas a velocidade de avaliação depende fortemente do número de condições dentro de cada conjunto. Utilizamos a hierarquia de Policy Sets para minimizar o caminho de avaliação.

Um "Padrão de Ouro" para uma estrutura de Policy Set pronta para 2026 se parece com isto:

Infraestrutura Global: (TACACS+ para Administradores de Rede)
Wireless - Corporativo: (802.1X, EAP-TLS, Dispositivos Gerenciados)
Wireless - Convidado: (WebAuth, CWA)
Wired - Dot1X: (802.1X rigoroso para estações de trabalho)
Wired - MAB/IoT: (Com foco em 'profiling' para dispositivos headless)
VPN/ZTNA: (AnyConnect/Secure Client com integração SAML 2.0 / Azure AD)

Ao separar Wired e Wireless no nível de Policy Set (Top Level), você reduz o número de regras de autorização que o motor precisa verificar para cada solicitação de 'MAC authentication bypass' (MAB). Se o seu scanner de IoT está acessando o mesmo Policy Set que o iPad do seu CEO, seu design está falho.

Condições Avançadas: Indo Além dos Atributos RADIUS Básicos

No ISE 3.4, aproveitamos as Smart Conditions. Pare de codificar IPs ou IDs de 'switches' específicos em sua política. Em vez disso, use Device Groups e hierarquias de localização. Se você tem 500 escritórios, use o atributo DEVICE:Device-Location. Isso permite escalar para mais de 100.000 'endpoints' sem adicionar uma única linha à lógica de sua política quando uma nova filial é aberta.

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'

A introdução do PassiveID e a profunda integração com o Microsoft Azure AD (Entra ID) significam que suas condições agora devem usar frequentemente AzureAD:ExternalGroups. No entanto, uma armadilha comum é a latência introduzida por múltiplas chamadas de REST API para a nuvem. No 3.4, certifique-se de utilizar o ISE Messaging Service para lidar com buscas de atributos de alta frequência de seus conectores AD para evitar 'timeouts' de autenticação (Erro 5411).

Perfis de Autorização e Integração TrustSec (SGT)

A segmentação tradicional baseada em VLAN está morta. Ela é muito frágil. Em um ambiente Cisco DNA Center moderno ou VXLAN/EVPN manual, seus Perfis de Autorização devem enviar Security Group Tags (SGTs). A SGT é o "rótulo de identidade" que permanece com o pacote, independentemente de onde o usuário se mova no campus.

Ao configurar seus Perfis de Autorização no ISE 3.4, você deve sempre retornar:

VLAN ID/Nome: Como 'fallback' para 'switches' não cientes de SGT.
SGT (Security Group Tag): Para aplicação baseada em hardware na série Catalyst 9k.
Voice Domain Permission: Necessário para implantações 'multi-auth' em uma única porta.

Por exemplo, um perfil "Developer_Access" deve retornar SGT 15. A política em seu ASA/FTD ou Catalyst Core, então, lida com a lógica real de permitir/negar 15 -> 20 (DB_Servers). Isso remove a "VLAN Sprawl" que tem atormentado as redes de campus na última década.

MAB vs. Dot1X: O Conflito Zero Trust

A indústria está pressionando por "Dot1X em todos os lugares", mas a realidade de 2026 é uma explosão de IoT não gerenciada. O 'MAC Authentication Bypass' (MAB) é inerentemente inseguro — endereços MAC são facilmente falsificados. Para mitigar isso no ISE 3.4, usamos Profiling + Probing. Não permita que um dispositivo MAB entre na rede com base apenas em seu endereço MAC estar em uma lista.

Use a seguinte hierarquia de 'probes' para 'profiling' de alta fidelidade:

DHCP Probe: Captura as strings Option 55 e Option 60 (as mais precisas para detecção de OS).
HTTP Probe: Captura a string User-Agent do navegador.
SNMP Query: Usado para 'switches' industriais legados.
NMAP Scan: Acionado como um CoA ('Change of Authorization') quando um dispositivo é "Desconhecido".

O refinamento desses 'probes' permite que você escreva uma política que diz: "Identifique isso como uma impressora HP somente se o MAC for OUI-registrado para HP E a DHCP Option 60 corresponder a 'HP-JetDirect'." Se o OS mudar para 'Kali Linux', o ISE envia um CoA Disconnect imediato.

Avaliação de Postura no 3.4: Conformidade Não é Negociável

O ISE 3.4 lida com Postura através do AnyConnect/Cisco Secure Client. Em um mundo híbrido pós-COVID, o estado da máquina é tão importante quanto as credenciais do usuário. A lógica do seu Policy Set para ativos corporativos deve sempre envolver três estados:

Desconhecido: VLAN Temporária / SGT Limitada. Redirecionar para o portal de Provisionamento de Cliente para baixar o agente.
Não Conforme: Redirecionar para remediação (WSUS/gerenciamento de patch). SGT de alto risco aplicada.
Conforme: SGT de acesso total aplicada.

Confira nossa análise aprofundada sobre a otimização dos módulos de postura do Secure Client para obter mais informações sobre isso. Recomendamos o uso de Periodic Re-assessment (PRA) a cada 4 a 8 horas para alvos de alto valor (controladores financeiros, funções de administrador) para garantir que eles não desabilitaram seu EDR/AV após o login inicial.

Troubleshooting do ISE 3.4: A Realidade da Engenharia

Quando um usuário não consegue conectar, pare de olhar a CLI do 'switch' primeiro. Vá direto para Operations > RADIUS > Live Logs. No ISE 3.4, a seção "Steps" do relatório detalhado é o seu roteiro. Procure por 'Step 11001: Received RADIUS Access-Request' e siga até 'Step 15008: Evaluating Service Selection Policy'.

Falhas comuns que vemos em campo:

11507 Ext-ID Store failure: Seus nós ISE não conseguem alcançar os Domain Controllers. Verifique a latência; se >200ms, a autenticação falhará.
5411 EAP Session Timed Out: Geralmente causado pelo 'endpoint' esperando que um usuário digite credenciais, ou pelo 'switch' dando 'timeout' muito cedo. Aumente o dot1x timeout tx-period nas portas do seu Catalyst.
12511 Unexpected Certificate in EAP-TLS: O cliente está apresentando um certificado não assinado por uma CA em seu Trusted Certificates store ou a verificação de CRL falhou.

Use a ferramenta TCP Dump integrada ao nó Cisco ISE (Operations > Troubleshoot > Diagnostic Tools) para capturar tráfego diretamente na interface Gi0 do Policy Service Node (PSN). Isso geralmente é mais rápido do que configurar um RSPAN no 'switch'.

Dimensionamento da Implantação: Grupos de PSN e Balanceamento de Carga

Não use apenas um 'load balancer' 'round-robin'. Para implantações ISE de alta escala (50 mil+ 'endpoints'), use Persistent Sessions em seu F5 ou Citrix ADC. Se um 'endpoint' iniciar uma sequência EAP com PSN-01, ele deve finalizá-la com PSN-01. Se o 'load balancer' alternar no meio de uma transação para PSN-02, a sessão falhará porque o estado EAP é local ao nó.

Projete seus nós PSN em pares por região geográfica. Um único 'appliance' 3695 (grande) pode lidar com aproximadamente 50.000 sessões simultâneas, mas recomendamos limitar isso a 30.000 para deixar margem para picos de MAB com uso intensivo de 'profiling' durante quedas de energia (quando 5.000 impressoras tentam se reconectar ao mesmo tempo).

Em resumo, o Cisco ISE 3.4 é o cérebro da sua rede. Trate seus Policy Sets com o rigor de um código. Cada condição deve ter um propósito, e cada regra deve impulsioná-lo para um ambiente macro-segmentado e baseado em SGT. Para ajuda prática com o seu design de ISE ou uma auditoria de segurança completa, visite-nos em techleague.io.