Certificados no Cisco ISE: Entenda seu Papel e Importância

Quando falamos em segurança com o Cisco ISE (Identity Services Engine), estamos falando sobre confiança. E em um ambiente digital, a confiança é estabelecida por certificados digitais, que validam identidades e garantem comunicações criptografadas.

Neste artigo, vamos explorar por que os certificados são essenciais no Cisco ISE, quais tipos existem, como configurá-los corretamente e como evitar os erros mais comuns.

Por que o Cisco ISE depende de certificados?

O Cisco ISE é uma plataforma central de controle de acesso à rede, onde múltiplos elementos se comunicam: endpoints, switches, controladoras wireless, servidores, navegadores, AD, MDM, etc.

Para que todas essas comunicações ocorram com segurança e confiança, é necessário:

Provar a identidade das partes envolvidas (ex: o servidor ISE precisa provar que é legítimo)
Garantir que a comunicação seja confidencial (criptografia de dados)
Assegurar a integridade das mensagens (nada foi alterado no caminho)

Essas três propriedades são garantidas por certificados digitais baseados em criptografia de chave pública (PKI).

Fonte: How To Implement Digital Certificates in ISE

Principais tipos de certificados no Cisco ISE

1. Certificado do Servidor ISE (EAP/HTTPS)

Esse é o certificado mais crítico do ISE. Ele é apresentado:

Durante a autenticação 802.1X com EAP-TLS, PEAP ou EAP-FAST
Na interface de administração web (https://ise.company.com)
Em portais como Guest, BYOD e Self-Service

Impactos práticos:

Se o certificado estiver expirado, o processo de autenticação falha
Se o nome no certificado não corresponder ao FQDN do servidor, o navegador exibirá erros
Se o certificado for autoassinado e não confiável, os endpoints rejeitarão a conexão (a não ser que confiem na raiz manualmente)

Dica prática: Use um certificado de CA interna para EAP, e um certificado de CA pública para portais.

A figura abaixo descreve o processo de criptografia quando há comunicação com o portal de Admin.

Já a figura abaixo, apresenta o processo de criptografia para cada possível processo EAP.

PEAP
EAP-TLS
EAP-TTLS
EAP-FAST
TEAP

Com métodos EAP tunelados, como PEAP e FAST, o protocolo TLS (Transport Layer Security) é usado para proteger a troca de credenciais. Assim como ao acessar um site HTTPS, o cliente estabelece a conexão com o servidor, que apresenta seu certificado ao cliente. Se o cliente confiar no certificado, o túnel TLS é formado. As credenciais do cliente não são enviadas ao servidor até que esse túnel seja estabelecido, garantindo assim uma troca segura. Em uma implantação de Acesso Seguro, o cliente é um solicitante e o servidor é um nó do ISE Policy Services.

2. Certificados para Portais Web (Guest, BYOD)

Os portais web hospedados pelo ISE (como guest.company.com) exigem certificados válidos e confiáveis para HTTPS.

Recomendado:

Usar certificados wildcard públicos (*.company.com)
Configurar um nome DNS válido e resolvível para o portal
Garantir que o navegador do usuário confie na CA emissora

Evite o uso de certificados autoassinados para portais, pois geram alertas nos navegadores e criam desconfiança no usuário final.

3. Certificados internos para comunicação entre nós ISE

O Cisco ISE pode ser composto por vários nós com funções distintas:

Admin Node
Policy Service Node (PSN)
Monitoring Node
pxGrid Node

A comunicação entre esses nós é autenticada via certificados. Esses certificados também são usados em:

Sincronização de dados
Replicação de logs
pxGrid (publish/subscribe)

Boas práticas:

Use certificados válidos com FQDN correto
Use uma CA corporativa e renove antes da expiração
Certifique-se de que a cadeia de certificados está completa (raiz + intermediária)

4. Quais valores de certificado devem ser usados em uma implantação do ISE?

Aqui vamos abordar os três modelos recomendados para uso de certificados em um ambiente ISE distribuído.

Modelo 1: Um certificado por nó (multiuso)

Descrição: Cada nó do ISE (PAN, PSN, MnT) usa um único certificado para múltiplos serviços — administração, EAP, portal e pxGrid.
Requisitos do certificado:
- CN (Common Name): deve ser o FQDN do nó (ex: psn1.company.com).
- SAN (Subject Alternative Name): incluindo:
  - FQDN do próprio nó
  - FQDN dos portais (guest, sponsor, mydevices) servidos por esse nó
- Deve incluir extensões EKU (Extended Key Usage) para:
  - Server Authentication (todos os nodes)
  - Client Authentication (fundamental para uso em pxGrid)
Vantagens: simplifica o gerenciamento, pois utiliza apenas um certificado multiuso por nó.

Modelo 2: Certificados separados por serviço, por nó

Descrição: Cada serviço (Admin, EAP, Portal, pxGrid) em um nó tem seu próprio certificado.
Requisitos do certificado:
- Admin: CN = FQDN do nó.
- EAP: CN pode ser o nome do nó ou um nome genérico, como eap.company.com.
- Portal (Sponsor / MyDevices / Guest): CN = nome específico do portal (sponsor.company.com).
- pxGrid: deve ter EKUs para Server e Client Authentication.
Vantagens: oferece maior isolamento entre serviços, útil para cenários que exigem segregação de funções ou políticas distintas.

Modelo 3: Certificado Único em Todos os PSNs

Este método utiliza o mesmo par de chaves pública e privada em todos os nós ISE. Geralmente, é usado em ambientes com muitos dispositivos do tipo BYOD. O principal motivo para seguir este modelo é garantir que o mesmo certificado seja usado em todas as PSNs; assim, os dispositivos BYOD já confiarão em qualquer servidor EAP no qual precisem se autenticar.
Para realizar este método, gere uma solicitação de assinatura de certificado (CSR) em um único nó ISE. Após vincular o certificado assinado à chave privada, exporte o par de chaves resultante e importe-o em todos os outros nós. Configure o certificado único para:
1. O CN do Certificado conterá um único FQDN, como ise.company.com
2. O Subject Alternate Name do Certificado conterá:
  - O Subject CN, como ise.company.com
  - FQDN real de cada nó ISE como entradas SAN
  - Nome amigável para o Sponsor Portal
  - Nome amigável para o Mydevices Portal

Comparativo entre os modelos

Modelo	Simplicidade	Escalabilidade	Complexidade de gestão
Certificado multiuso por nó	Alta	Boa	Média
Certificados por serviço	Baixa	Alta	Alta
Certificado Único em Todos os PSNs	Muito alta	Alta	Baixa

Autoridades Certificadoras: CA Pública x CA Interna

O certificado do ISE deve ser confiável pelo cliente — isso exige que a CA que o emitiu esteja no repositório de confiança do sistema cliente (Windows, macOS, Android, etc.).

Comparativo:

Critério	CA Pública	CA Interna
Reconhecida por padrão	✅ Sim	❌ Não (precisa importar a raiz)
Ideal para portais web	✅ Sim	⚠️ Pode gerar alerta no navegador
Ideal para EAP-TLS	✅ Sim (mas caro)	✅ Sim (usado via GPO ou MDM)
Custo	$ (certificados pagos)	Grátis, mas requer gerenciamento

O que é um certificado wildcard?

Um certificado wildcard é um tipo de certificado digital SSL/TLS que utiliza um caractere curinga (*) no campo Common Name (CN) ou no Subject Alternative Name (SAN). Ele é utilizado para proteger múltiplos subdomínios dentro de um mesmo domínio principal.

🔹 Exemplo prático:

CN: *.empresa.com
Este certificado é válido para:
- guest.empresa.com
- sponsor.empresa.com
- mydevices.empresa.com
- ise1.empresa.com
- vpn.empresa.com

Mas não é válido para:

sub.guest.empresa.com (nível adicional de subdomínio)
empresa.net (domínio diferente)

Uso de certificados wildcard no Cisco ISE

No Cisco ISE, os certificados wildcard são comumente usados para proteger portais web, como:

Guest Portal
BYOD Portal
Self-Service/MyDevices Portal
Portais de Sponsor

Isso porque esses portais geralmente operam em subdomínios como guest.empresa.com, sponsor.empresa.com, etc.

Vantagens:

Simplifica o gerenciamento: apenas um certificado cobre todos os portais
Reduz custos: ao invés de emitir múltiplos certificados por subdomínio
Flexibilidade: ao adicionar novos portais ou PSNs, o mesmo certificado pode ser reaproveitado

Limitações e recomendações:

EAP-TLS e certificados wildcard:
Alguns clientes (como Windows e certos supplicants) podem não aceitar certificados wildcard durante a negociação EAP, especialmente em ambientes mais restritivos ou quando o nome do servidor precisa ser validado contra o CN exato.
Uso em pxGrid:
pxGrid exige que o certificado tenha o nome exato do host (FQDN) no CN ou no SAN. Certificados wildcard não são recomendados para pxGrid.
Associação correta no ISE:
O certificado deve ser associado ao serviço de portal web, não ao EAP ou pxGrid.

Resumo — Quando usar certificado wildcard no ISE?

Caso de uso	Wildcard é recomendado?
Portais Web (Guest, BYOD)	✅ Sim
Interface de Admin (HTTPS)	⚠️ Sim, mas com atenção
EAP (PEAP, EAP-TLS)	⚠️ Depende do supplicant
pxGrid	❌ Não recomendado

Gerenciamento de Certificados no ISE

Onde gerenciar:

Administration > System > Certificates

Você pode:

Gerar CSR para envio à CA
Importar certificados assinados (usando o CSR anterior)
Importar cadeias completas (Root + Intermediate)
Associar certificados a serviços específicos, como EAP Authentication, Admin Portal, pxGrid, etc.
Monitorar a expiração automática com alertas de renovação

Boas práticas:

Tenha um plano de renovação periódica (scriptado ou manual)
Use nomes FQDN corretos nos certificados
Certifique-se de que o campo SAN contenha o nome DNS correto
Evite reusar o mesmo certificado para múltiplos serviços (a não ser que seja wildcard)

Conclusão

O Cisco ISE é uma solução poderosa e flexível de controle de acesso à rede — mas sua segurança e funcionalidade dependem fortemente de uma infraestrutura de certificados digitais bem planejada.

Ao longo deste artigo, vimos que os certificados não são apenas um requisito técnico, mas um pilar fundamental para garantir identidade, confiança e comunicação segura entre o ISE, os dispositivos de rede, os usuários e os sistemas externos.

Seja na autenticação EAP-TLS, no acesso aos portais Guest/BYOD, na integração via pxGrid, ou na administração web — tudo passa pela confiança em certificados válidos, corretamente emitidos, distribuídos e associados.

A escolha entre um certificado por nó, por serviço ou compartilhado deve ser guiada pelo equilíbrio entre simplicidade operacional, escalabilidade e segurança. O uso de certificados wildcard pode facilitar o gerenciamento de portais web, mas deve ser feito com cuidado em cenários que envolvam autenticação EAP ou integração com pxGrid.

Caso queira entender mais a fundo sobre os certificados no ISE, recomendo a leitura do seguinte material:

https://community.cisco.com/t5/security-knowledge-base/how-to-implement-digital-certificates-in-ise/ta-p/3630897

Como Utilizar Dicionários no Cisco ISE para Políticas Eficazes

Ao trabalhar com políticas no Cisco ISE, é comum utilizar atributos como grupos de usuários, SSID, tipos de dispositivos ou status de postura. Mas o que poucos administradores compreendem a fundo é de onde vêm esses atributos e como o ISE os organiza.

A resposta está nos dicionários do Cisco ISE — componentes essenciais que estruturam toda a lógica de decisão da plataforma. Neste artigo, você vai entender o que são esses dicionários, como utilizá-los e por que dominá-los torna a administração do ISE muito mais eficiente e segura.

O que são dicionários no Cisco ISE?

No Cisco ISE, um dicionário é uma coleção de atributos relacionados a uma fonte específica de dados, como o RADIUS, Active Directory, posture ou profiling. Esses dicionários são usados para criar condições em regras de autenticação, autorização, perfil de dispositivos e outras funcionalidades da plataforma.

Você pode pensar em um dicionário como uma “tabela de atributos” que o ISE consulta para entender o contexto da conexão ou a identidade do usuário/dispositivo.

Tipos de Dicionários no Cisco ISE

1. System Dictionary

Contém atributos internos do próprio ISE, como ISE Device, EndPointPolicy, AuthenticationStatus, entre outros. São amplamente usados para condições administrativas e controle interno.

2. RADIUS Dictionary

Lista atributos padrão definidos pelo protocolo RADIUS, como:

Radius:Calling-Station-ID
Radius:NAS-Port-Type
Radius:Framed-IP-Address

Esses atributos são usados frequentemente em políticas que analisam dados de portas, switches, SSIDs, entre outros.

3. Active Directory / LDAP Dictionaries

Quando o ISE se integra com um diretório externo (como o AD), ele importa um conjunto de atributos, como:

AD:MemberOf (grupo de segurança)
AD:sAMAccountName
AD:Department
LDAP:Title, LDAP:Manager

Esses atributos permitem decisões baseadas em identidade corporativa.

4. Posture and AnyConnect Dictionaries

Utilizados quando o ISE trabalha com avaliação de postura (NAC), especialmente com o agente Cisco AnyConnect. Exemplos:

Posture:Status
Cisco-AV-Pair: posture-token
ClientVersion, OS, AVCompliance

5. Profiling Dictionary

Contém atributos coletados automaticamente pelo mecanismo de profiling do ISE, como:

DeviceType
DeviceFamily
Manufacturer
OperatingSystem

Usados para identificar e classificar dispositivos conectados (impressoras, IP phones, câmeras, etc.).

6. Custom Dictionaries (Personalizados)

O administrador pode criar dicionários personalizados para suportar atributos específicos de aplicações ou extensões externas via pxGrid, scripts, APIs ou integração com firewalls.

Como os dicionários são usados nas políticas?

Os atributos presentes nos dicionários são utilizados ao criar condições dentro das Authentication ou Authorization Policies. Veja alguns exemplos práticos:

Exemplo de condição (IF)	Fonte do atributo
`Radius:Calling-Station-ID = "Corp-WiFi"`	RADIUS Dictionary
`AD:MemberOf = "TI"`	Active Directory Dictionary
`Posture:Status = Compliant`	Posture Dictionary
`Endpoint:DeviceType = "Smartphone"`	Profiling Dictionary
`LDAP:Department = "Financeiro"`	LDAP Dictionary

Essas condições permitem ações como: atribuir VLANs, aplicar SGTs, redirecionar para portais, bloquear acesso ou enviar CoA (Change of Authorization).

Onde visualizar e gerenciar dicionários no ISE?

Você pode acessar os dicionários e seus atributos em:

Menu:
Policy > Policy Elements > Dictionaries

Nessa tela é possível:

Explorar todos os dicionários disponíveis
Ver os atributos disponíveis (nome, tipo, permissões)
Adicionar dicionários personalizados
Mapear novos atributos de um AD/LDAP

Importante: Nem todos os atributos são editáveis. A maioria dos dicionários padrão é de leitura apenas, mas os personalizados permitem configuração total.

Exemplos práticos

1. Usando um dicionário AD em uma regra

Objetivo: aplicar uma VLAN específica para usuários cujo campo Department no AD seja igual a “Segurança”.

Passo a passo:

Verifique se o atributo Department foi mapeado na integração com o AD.
Vá em Policy > Policy Sets > Authorization Policy
Crie uma condição: IF AD:Department EQUALS "Segurança" THEN Apply VLAN 60 + SGT “Security”

Simples e altamente eficaz. Você está aplicando segmentação baseada em um campo organizacional real, sem depender de múltiplos grupos de AD.

2. Adicionando um Dicionário RADIUS de um Fabricante Externo no Cisco ISE

Em muitos cenários de integração — como com firewalls Palo Alto, Fortinet, F5, Aruba, etc. — é comum que esses dispositivos utilizem atributos RADIUS proprietários ou Vendor-Specific Attributes (VSAs) para enviar dados adicionais em pacotes RADIUS.

Por padrão, o Cisco ISE reconhece os atributos mais comuns do protocolo. No entanto, se você quiser consumir atributos personalizados de outro fabricante, precisará importar ou criar um dicionário RADIUS específico para esse vendor.

Exemplo de uso:

Você deseja criar uma regra no ISE baseada em um atributo específico enviado por um firewall Palo Alto, como PaloAlto-User-Group.

Passo a passo: como adicionar um dicionário RADIUS personalizado

Acesse o menu de dicionários:
No ISE 3.1 ou superior, vá em:
Policy > Policy Elements > Dictionaries > RADIUS > RADIUS Vendors
Clique em “Add” (Adicionar)
Preencha os campos principais:
- Vendor Name: nome do fabricante (ex: PaloAlto)
- Vendor ID: o ID atribuído pelo IANA (ex: 25461 para Palo Alto)
- Vendor Type: selecione RADIUS
- Clique em Submit
Adicione os atributos específicos do vendor:
Após criar o dicionário, clique sobre ele e vá em “Attributes” > “Add”. Exemplo de atributo:
- Name: PaloAlto-User-Group
- Attribute ID: conforme a documentação do fabricante (ex: 1)
- Data Type: String, Integer, Boolean, etc.
- Length: se necessário
- Direction: geralmente “Input” (se o ISE vai ler esse valor)
Clique em Submit para salvar o atributo.
Usar o novo atributo em políticas:
Agora que o atributo faz parte de um dicionário válido, você pode utilizá-lo em condições dentro de Authorization Policies, exatamente como faria com um atributo RADIUS nativo.

Onde obter os detalhes dos atributos?

Consulte a documentação oficial do fabricante (Palo Alto, Fortinet, etc.) para obter:

O Vendor ID (IANA)
A lista de atributos disponíveis
Os Vendor-Specific Attribute IDs e seus tipos

Exemplo:
O Vendor ID da Palo Alto Networks é 25461. Um dos atributos mais usados é o PaloAlto-User-Group, que pode ser utilizado para segmentação baseada em grupos de usuários na rede.

Benefícios dessa integração

Facilita a integração com soluções de segurança de terceiros em ambientes heterogêneos

Permite que o ISE reconheça e atue com base em atributos personalizados enviados por firewalls, proxies ou NACs externos

Expande a capacidade de decisões contextuais com dados além do AD ou RADIUS padrão

Conclusão

Os dicionários no Cisco ISE são mais do que uma lista de atributos — eles são a base para políticas inteligentes, dinâmicas e contextuais.
Ao dominar seu uso, você:

Cria regras mais precisas e alinhadas ao negócio
Reduz erros ao aplicar permissões
Ganha flexibilidade para integrações com AD, firewalls, posture e profiling
Torna sua rede mais segura e automatizada

Entendendo os Policy Sets no Cisco ISE

Imagine que o Cisco ISE (Identity Services Engine) é como o controle de acesso de um prédio inteligente. Quando alguém tenta entrar, o sistema verifica quem é e decide aonde essa pessoa pode ir, com base em regras pré-definidas. Esse é o papel das políticas no ISE: verificar e decidir.

Neste artigo, vamos explorar:

O que são os Policy Sets no ISE

Como funciona a lógica “IF → THEN” (SE → ENTÃO)
Como o ISE aplica ações como VLAN, ACL, SGT
Exemplos práticos e dicas para aplicar no seu ambiente

1. O que são os Policy Sets no Cisco ISE?

Os Policy Sets são o ponto de entrada da lógica de decisão do ISE. Eles funcionam como grandes agrupadores de políticas que separam diferentes contextos de acesso, como:

Acesso cabeado com 802.1X
Dispositivos legados via MAB (MAC Authentication Bypass)
Visitantes usando WebAuth
Conexões VPN, SSID específicos, etc.

O ISE analisa os Policy Sets de cima para baixo, e entra no primeiro que corresponder à requisição recebida (com base em atributos como protocolo, switch, SSID, porta, etc).

IF protocolo = EAP-TLS AND NAS-Port-Type = Ethernet THEN usar o Policy Set “Acesso Corporativo”

Cada Policy Set contém:

Authentication Policy (quem está se conectando?)
Authorization Policy (o que esse usuário/dispositivo pode fazer?)

2. Como funciona a lógica IF → THEN no ISE

O motor de decisão do Cisco ISE é baseado em estruturas condicionais, muito semelhantes à lógica de programação:

IF [Condição for verdadeira] THEN [Aplique determinada ação]

Essa lógica é aplicada em três níveis principais:

a) Policy Set Selection

IF protocolo = EAP THEN usar o Policy Set "Acesso Wireless"

b) Authentication Policy

IF método = EAP-PEAP AND origem = Switch 01 THEN verificar credencial no Active Directory

c) Authorization Policy

IF grupo_AD = "TI" AND tipo_dispositivo = Laptop THEN aplicar VLAN 10 + SGT Admin + ACL liberada

Essas regras são sempre avaliadas de cima para baixo, e o ISE aplica a primeira regra que for compatível com os atributos da sessão.

3. Ações aplicadas pelo ISE (o “THEN”)

Depois que o ISE entende quem está se conectando e com quais atributos, ele aplica uma série de ações que definem o comportamento de rede para aquele dispositivo:

Tipo de ação	Exemplos
VLAN Assignment	VLAN 10 para TI, VLAN 30 para visitantes
SGT (TrustSec)	SGT Admin, HR, Printer – para microsegmentação
ACL/DACL	Downloadable ACLs com restrições de acesso
Redirecionamento	Para portal de convidados, posture, BYOD, etc.
Autorização negativa	VLAN de quarentena ou DACL “deny-all”

4. Exemplo prático de fluxo de decisão

Cenário:

Funcionário do RH acessando via 802.1X em switch
Impressora HP conectada via MAB
Visitante acessando via WebAuth

Como o ISE decide:

IF autenticação via 802.1X AND grupo AD = "RH" THEN aplicar VLAN 20 + SGT RH

IF autenticação via MAB AND perfil do endpoint = Printer THEN aplicar VLAN 40 + SGT Printer

IF autenticação via WebAuth THEN aplicar VLAN 30 + ACL restritiva

E se nada for compatível?

IF nenhuma condição for satisfeita THEN aplicar VLAN de quarentena + DACL deny-all

Diagrama simplificado da lógica

flowchart TD A[Solicitação de conexão] --> B{Policy Set Match?} B -- Sim --> C[Authentication Policy] C --> D{Autenticação válida?} D -- Sim --> E[Authorization Policy] E --> F{Grupo = TI?} --> G[Aplique VLAN 10 + SGT Admin] F --> H{Dispositivo = Impressora?} --> I[Aplique VLAN 40 + ACL] D -- Não --> Z[Aplicar VLAN de quarentena ou negar acesso]

Conclusão

O Cisco ISE não é uma “caixa preta”. Ele funciona com base em lógica condicional simples, clara e previsível. Entendendo os blocos de decisão (Policy Set, AuthZ/AuthC) e como as regras “IF → THEN” se aplicam, você consegue:

Criar políticas mais seguras e granulares
Automatizar respostas com base em contexto
Reduzir ACLs e VLANs fixas, com TrustSec (SGTs)
Melhorar a experiência do usuário com decisões inteligentes

Perguntas Frequentes sobre Políticas no Cisco ISE (FAQ)

1. O que acontece se nenhuma regra for compatível com a sessão?

O ISE aplica a última regra default (geralmente negativa), como uma VLAN de quarentena ou uma DACL com bloqueio total. Isso evita acessos não autorizados.

2. Qual a diferença entre Authentication e Authorization Policy?

Authentication verifica quem é o usuário/dispositivo e se as credenciais são válidas.
Authorization decide o que ele pode fazer na rede, como VLAN, ACL ou SGT.

3. Posso usar atributos de dispositivos (profiling) nas regras de autorização?

Sim. O ISE permite usar atributos de profiling, como tipo de sistema operacional ou fabricante, para criar regras mais granulares.

4. O ISE avalia todas as regras de Authorization ou só a primeira compatível?

O ISE avalia as regras de cima para baixo e aplica apenas a primeira que for compatível. A ordem das regras é extremamente importante.

5. É possível usar grupos do Active Directory como condição de autorização?

Sim. O ISE pode integrar-se ao AD e utilizar grupos de segurança como parte da lógica condicional (ex: grupo = “Financeiro”).

6. Posso aplicar múltiplas ações (ex: VLAN + ACL + SGT) ao mesmo tempo?

Sim. Uma única regra de autorização pode combinar várias ações de controle de acesso de forma simultânea, dependendo da infraestrutura de rede compatível.