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).


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

ModeloSimplicidadeEscalabilidadeComplexidade de gestão
Certificado multiuso por nóAltaBoaMédia
Certificados por serviçoBaixaAltaAlta
Certificado Único em Todos os PSNsMuito altaAltaBaixa

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érioCA PúblicaCA 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 usoWildcard é 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 = CompliantPosture 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:

  1. Verifique se o atributo Department foi mapeado na integração com o AD.
  2. Vá em Policy > Policy Sets > Authorization Policy
  3. 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

  1. Acesse o menu de dicionários:
    No ISE 3.1 ou superior, vá em:
    Policy > Policy Elements > Dictionaries > RADIUS > RADIUS Vendors
  2. Clique em “Add” (Adicionar)
  3. 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
  4. 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.
  5. 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

  1. Como funciona a lógica “IF → THEN” (SE → ENTÃO)
  2. Como o ISE aplica ações como VLAN, ACL, SGT
  3. 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çãoExemplos
VLAN AssignmentVLAN 10 para TI, VLAN 30 para visitantes
SGT (TrustSec)SGT Admin, HR, Printer – para microsegmentação
ACL/DACLDownloadable ACLs com restrições de acesso
RedirecionamentoPara portal de convidados, posture, BYOD, etc.
Autorização negativaVLAN 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.

Entendendo as Personas no Cisco ISE: Guia Completo

No mundo digital de hoje, onde ameaças cibernéticas evoluem constantemente, proteger sua rede não é apenas uma opção—é uma necessidade. O Cisco Identity Services Engine (ISE) é uma ferramenta poderosa que ajuda as organizações a controlar quem e o que está acessando seus recursos de rede. Mas como o ISE consegue fazer isso de forma tão eficaz? A resposta está nas suas personas.

As personas no Cisco ISE representam diferentes papéis ou funções que os nós podem desempenhar dentro do sistema, trabalhando em conjunto para fornecer uma solução completa de segurança e gerenciamento de acesso. Vamos explorar por que elas são tão importantes.

Neste artigo vamos falar sobre como é essa estrutura de Personas existente no Cisco Identity Service Engine (ISE). Existem quatro tipos principais de personas: Admin, Policy Service Node (PSN), Monitoring and Troubleshooting (MnT) e Platform Exchange Grid (pxGrid), vamos entender o papel de cada um.

Entendendo o papel de cada Persona

Administration Persona (Policy Administration Node – PAN):

A persona de Admin fornece as interfaces de gerenciamento, tanto a interface gráfica baseada na web (GUI) quanto a interface de linha de comando (CLI), para configurar e administrar todo o sistema do Cisco ISE.

Funções Principais:

  • Configuração do Sistema: Permite aos administradores definir configurações globais, como políticas de autenticação, autorização e perfilamento.
  • Gerenciamento de Políticas: Criação e gerenciamento de políticas de acesso à rede, incluindo regras de segurança e conformidade.
  • Administração de Certificados: Gerencia certificados digitais para comunicação segura entre nós e dispositivos.
  • Gerenciamento de Nós: Adiciona, remove e gerencia outros nós e personas dentro da implantação do ISE.

Em um ambiente de implementação distribuído é possível pode ter um máximo de dois nós rodando a função de Administration Persona. O Administration Persona pode ser aplicado em um servidor standalone ou em ambiente distribuído.

Persona de Serviço (Policy Service Node – PSN)

Conhecido como Nó de Serviço, o PSN é responsável por aplicar as políticas definidas e fornecer serviços de acesso à rede, como autenticação, autorização, perfilamento e avaliação de postura.

Funções Principais:

  • Processamento AAA: Lida com solicitações de Autenticação, Autorização e Contabilização (AAA) de dispositivos de rede.
  • Serviços RADIUS e TACACS+: Fornece protocolos para autenticar usuários e dispositivos que tentam acessar a rede.
  • Perfilamento de Dispositivos: Identifica e classifica dispositivos na rede com base em características observadas.
  • Avaliação de Postura: Verifica se os dispositivos estão em conformidade com as políticas de segurança antes de conceder acesso.

Persona de Monitoramento e Solução de Problemas (Monitoring and Troubleshooting – MnT)

A persona MnT coleta, armazena e analisa logs e dados operacionais do Cisco ISE, fornecendo ferramentas para monitoramento, relatórios e solução de problemas.

Funções Principais:

  • Coleta de Logs: Agrega logs de autenticação, autorização, contabilização e eventos do sistema de todos os nós PSN.
  • Relatórios e Dashboards: Oferece relatórios predefinidos e personalizados, além de painéis para visualizar o status do sistema e tendências.
  • Análise e Solução de Problemas: Auxilia na identificação e resolução de problemas relacionados ao acesso à rede e desempenho do sistema.
  • Alertas e Notificações: Configura alertas baseados em eventos ou condições específicas para proatividade na gestão da rede.

Persona Platform Exchange Grid (pxGrid)

Descrição: O pxGrid é uma plataforma que permite a integração e o compartilhamento seguro de informações contextuais entre o Cisco ISE e outras soluções de segurança de rede.

Funções Principais:

  • Integração de Sistemas: Conecta o ISE a produtos de segurança de terceiros, como firewalls, sistemas de prevenção de intrusões e SIEMs.
  • Compartilhamento de Contexto: Distribui informações sobre usuários, dispositivos, sessões e políticas para melhorar a inteligência de segurança.
  • Automação de Respostas: Permite que sistemas conectados tomem ações baseadas em políticas, como isolamento de dispositivos comprometidos.
  • Escalabilidade e Flexibilidade: Utiliza um modelo de publicação/assinatura para troca eficiente de informações em grandes ambientes.

Resumo Geral:

  • Admin: Centraliza a configuração e o gerenciamento da aplicação do ISE.
  • PSN (Service Node): Executa as políticas de segurança, processando solicitações de acesso à rede.
  • MnT: Fornece visibilidade e insights operacionais por meio de monitoramento e relatórios.
  • pxGrid: Facilita a colaboração e integração com outras soluções de segurança, ampliando a capacidade de resposta a ameaças.

Agora que entendemos como cada persona funciona, vamos entender os dois modos de implementação possíveis do ISE, Standalone e Distributed.

Modo Standalone

No modo Standalone, toda a funcionalidade do Cisco ISE é executada em um único nó ou servidor. Este nó único incorpora todas as personas (Admin, Policy Service Node – PSN, Monitoring and Troubleshooting – MnT e pxGrid) em uma única instalação.

Funcionamento

  • Implementação Simples: Ideal para ambientes menores ou de teste, onde a carga de trabalho é limitada e a alta disponibilidade não é um requisito crítico.
  • Todas as Personas em um Único Nó: O servidor Standalone lida com a administração, processamento de políticas, monitoramento e integração com outros sistemas, tudo a partir de um único ponto.
  • Facilidade de Gerenciamento: Com apenas um nó para gerenciar, a configuração e manutenção são simplificadas.

Cenários de Uso

  • Ambientes de Laboratório ou Teste: Onde o objetivo é avaliar ou demonstrar as capacidades do Cisco ISE.
  • Pequenas Empresas: Com um número limitado de usuários e dispositivos, onde a carga não excede a capacidade de um único servidor.
  • Implementações Temporárias: Situações onde uma solução rápida é necessária sem a complexidade de uma arquitetura distribuída.

Vantagens e Limitações

  • Vantagens:
    • Implementação e configuração rápidas.
    • Menor custo inicial de hardware e licenciamento.
    • Simplicidade na gestão diária.
  • Limitações:
    • Escalabilidade Limitada: Não adequado para grandes ambientes ou crescimento futuro.
    • Ausência de Redundância: Se o nó único falhar, todos os serviços do ISE ficam indisponíveis.
    • Desempenho: Pode sofrer com lentidão se sobrecarregado.

Modo Distribuído

No modo Distributed, o Cisco ISE é implementado em múltiplos nós, distribuindo as diferentes personas entre eles. Isso permite escalabilidade, redundância e melhor desempenho, atendendo às necessidades de redes de médio a grande porte.

Funcionamento

  • Segregação de Personas: As diferentes funções (Admin, PSN, MnT, pxGrid) são atribuídas a nós dedicados ou compartilhadas conforme a necessidade.
  • Escalabilidade Horizontal: Novos nós podem ser adicionados para suportar cargas de trabalho crescentes.
  • Alta Disponibilidade: Implementação de nós redundantes para evitar pontos únicos de falha.
  • Sincronização e Replicação: Os dados de configuração e políticas são sincronizados entre os nós Admin, enquanto os dados operacionais são agregados pelos nós MnT.

Vantagens

  • Escalabilidade: Capacidade de adicionar mais nós para suportar aumento de carga.
  • Redundância: Múltiplos nós evitam pontos únicos de falha, aumentando a resiliência.
  • Desempenho Otimizado: Distribuição da carga de trabalho melhora a eficiência do sistema.
  • Flexibilidade: Permite customizar a implantação de acordo com as necessidades específicas da rede.

Cenários de Uso

  • Médias e Grandes Empresas: Onde há um grande número de usuários, dispositivos e solicitações de autenticação.
  • Ambientes que Exigem Alta Disponibilidade: Redes críticas que não podem tolerar tempo de inatividade.
  • Ambientes Distribuídos Geograficamente: Onde os PSNs podem ser posicionados próximos aos usuários para reduzir a latência.

Considerações

  • Complexidade: Requer planejamento cuidadoso e conhecimento para implementar e gerenciar.
  • Custo: Investimento maior em hardware, licenças e manutenção.
  • Gerenciamento Centralizado: Necessidade de sincronização entre nós e monitoramento constante.

Comparação entre Standalone e Distributed

  • Escalabilidade:
    • Standalone: Limitada, adequado para pequenas cargas.
    • Distributed: Altamente escalável, suporta crescimento da rede.
  • Redundância:
    • Standalone: Não possui; falha do nó resulta em perda total de serviço.
    • Distributed: Suporta alta disponibilidade com nós redundantes.
  • Complexidade de Implementação:
    • Standalone: Simples e rápido de configurar.
    • Distributed: Mais complexo, requer planejamento e recursos adicionais.
  • Desempenho:
    • Standalone: Pode ser afetado sob carga pesada.
    • Distributed: Desempenho otimizado através da distribuição de carga.
  • Custo:
    • Standalone: Menor investimento inicial.
    • Distributed: Maior investimento, mas necessário para ambientes críticos.

A escolha entre os modos Standalone e Distributed do Cisco ISE depende das necessidades específicas da organização:

  • Modo Standalone é ideal para ambientes menores, onde simplicidade e baixo custo são prioridades, e os requisitos de desempenho e disponibilidade são modestos.
  • Modo Distributed é necessário em ambientes maiores ou críticos, onde a escalabilidade, redundância e desempenho são essenciais para suportar uma grande quantidade de usuários e dispositivos, além de garantir a continuidade do serviço.

Ambos os modos oferecem as funcionalidades completas do Cisco ISE, mas o modo Distributed permite uma abordagem mais robusta e flexível, alinhada com as demandas de redes corporativas modernas e complexas.

Conclusão

Em suma, o Cisco ISE, com suas personas interconectadas e modos de operação adaptáveis, oferece uma solução abrangente que capacita as organizações a alcançar excelência em segurança de rede e eficiência operacional. É uma ferramenta essencial para navegar no complexo panorama da segurança cibernética atual, garantindo que sua rede permaneça segura, eficiente e preparada para o futuro.

Links de referência

Para aprofundar ainda mais seu conhecimento no Cisco ISE, compartilho alguns links úteis:

https://www.cisco.com/c/en/us/td/docs/security/ise/3-0/install_guide/b_ise_InstallationGuide30/b_ise_InstallationGuide30_chapter_1.html

https://www.cisco.com/c/en/us/td/docs/security/ise/performance_and_scalability/b_ise_perf_and_scale.html

Qualidade de Serviço (QoS) em Redes de Dados: Conceitos e Importância

Qualidade de Serviço (QoS), refere-se a um conjunto de técnicas e políticas utilizadas para gerenciar o tráfego em uma rede de dados de forma a garantir um desempenho satisfatório para os diferentes tipos de aplicações e serviços.

A importância do QoS é evidente em ambientes onde vários tipos de tráfego compartilham a mesma infraestrutura de rede, como em redes corporativas, provedores de serviços de Internet (ISPs) e ambientes de nuvem. Sem um mecanismo de QoS adequado, os dados podem ser tratados de forma igual, o que pode levar a problemas de desempenho e latência para serviços que exigem uma entrega rápida e consistente.

A função principal do QoS em uma rede de campus é gerenciar a perda de pacotes.

Alguns dos principais conceitos do QoS são:

  1. Classificação de Tráfego:
    • A primeira etapa é classificar o tráfego em diferentes categorias com base em critérios como tipo de aplicação, protocolo, portas, endereços IP, etc. Por exemplo, o tráfego de voz sobre IP (VoIP) pode ser classificado de forma diferente do tráfego de navegação web.
  2. Marcação de Pacotes:
    • Após a classificação, os pacotes são marcados com informações que indicam sua prioridade. Isso é feito através de campos nos cabeçalhos dos pacotes, como o campo DiffServ em pacotes IP.
  3. Políticas de Filtragem e Marcação:
    • As políticas de QoS definem como os roteadores e switches devem tratar os pacotes marcados. Isso pode incluir a definição de prioridades, largura de banda mínima garantida, limites de taxa máxima, entre outros.
  4. Gerenciamento de Largura de Banda:
    • O QoS permite a alocação de largura de banda com base nas necessidades das aplicações. Por exemplo, aplicações críticas como VoIP podem receber uma alocação de largura de banda prioritária para garantir uma comunicação sem interrupções.
  5. Buffering e Escalonamento de Pacotes:
    • Os dispositivos de rede podem usar técnicas como filas de prioridade e escalonamento de pacotes para dar tratamento diferenciado aos pacotes de acordo com suas marcações de QoS.
  6. Monitoramento e Medição:
    • É importante monitorar o desempenho da rede para garantir que as políticas de QoS estejam sendo efetivamente aplicadas e que os níveis de serviço estejam sendo atendidos.
  7. Resiliência e Redundância:
    • Em ambientes críticos, podem ser implementadas estratégias de redundância para garantir a continuidade do serviço mesmo em caso de falhas na rede.
  8. Priorização de Aplicações:
    • As aplicações são priorizadas com base em sua importância para o negócio. Por exemplo, tráfego de VoIP pode ter prioridade sobre tráfego de download de arquivos não essenciais.
  9. Controle de Congestionamento:
    • O QoS pode ser usado para controlar a forma como a rede responde a situações de congestionamento, evitando perdas de pacotes críticos.

Oversubscription em rede de dados

Oversubscription em uma rede de dados é uma prática comum na engenharia de redes e data centers onde a largura de banda disponível para um determinado segmento da rede é maior do que a capacidade de saída agregada dessa rede. Em outras palavras, oversubscription ocorre quando a demanda potencial de largura de banda dos dispositivos conectados excede a capacidade total de transmissão da rede.

Exemplo de oversubscription em um rede de dados

Como Funciona o Oversubscription

Imagine um cenário simples: em um switch de rede, vários dispositivos estão conectados a ele. Cada dispositivo pode ter uma conexão de 1 Gbps ao switch, mas o link do switch para o roteador central pode ser de apenas 10 Gbps. Se 20 dispositivos estiverem conectados a esse switch, a demanda potencial total seria de 20 Gbps, mas o link de saída suporta apenas 10 Gbps. Assim, a razão de oversubscription seria 2:1 (20 Gbps de demanda potencial para 10 Gbps de capacidade).

Por Que Oversubscription é Utilizado

1. Custo-Efetividade: Prover a capacidade total para cada dispositivo é frequentemente caro e desnecessário, pois os dispositivos nem sempre utilizam a capacidade total simultaneamente.

    2. Planejamento de Capacidade: As redes são planejadas com base no comportamento típico dos usuários e aplicativos, onde a demanda máxima simultânea raramente ocorre.

    3. Eficiência de Recursos: Oversubscription permite um uso mais eficiente dos recursos de rede, já que a capacidade ociosa é minimizada.

    Implicações e Desafios

    1. Desempenho: Durante picos de utilização, a oversubscription pode causar congestionamento e degradação de desempenho, já que a capacidade disponível pode não ser suficiente para atender a todos os dispositivos simultaneamente.

    2. Qualidade de Serviço (QoS): Para mitigar os impactos negativos, técnicas de QoS são implementadas para priorizar tráfego crítico e garantir que serviços importantes mantenham desempenho aceitável.

    3. Monitoramento e Ajustes: É essencial monitorar a utilização da rede e ajustar a oversubscription conforme necessário para balancear custo e desempenho.

    Determinando a relevância do Negócio

    O primeiro passo antes de aplicarmos políticas de QoS inicia-se identificando os objetivos do negócio, como por exemplo:

    • Garantir a qualidade das ligações (VoIP);
    • Garantir uma alta qualidade de experiência para aplicações que utilizam vídeo;
    • Melhorar a produtividade minimizando os tempos de respostas da rede;
    • Gerenciar as aplicações do negócio;
    • Identificar e NÃO priorizar aplicações que não fazem parte do negócio da empresa;

    Para atingir todos esses pontos, podemos classificar as aplicações em basicamente três tipos sendo elas:

    • Relevante: RFC 4594
      • Estas aplicações atendem diretamente aos negócios da empresa;
      • As aplicações devem ser classificadas, marcadas e tratadas de acordo com os padrões de melhores práticas recomendadas.
    • Default: RFC 2474
      • Estas aplicações devem ou não atender aos negócios da empresa (ex: HTTP/ HTTPS/ SSL)
      • Aplicações deste tipo devem ser tratadas com a classe default de encaminhamento.
    • Irrelevante: RFC 3662
      • Estas aplicações não suportam aos objetivos da empresa.
      • Essas aplicações devem ser tratadas com a classe de menor importância.

    PHB, DSCP e CoS

    PHB (Per-Hop Behavior):

    O PHB define o comportamento que um roteador deve aplicar a um pacote com base na marcação DSCP. Em outras palavras, é a forma como um roteador trata um pacote com um determinado valor DSCP. Existem quatro classes de PHBs definidas na RFC 4594:

    1. Expedited Forwarding (EF): É usado para tráfego de alta prioridade, geralmente associado a aplicações sensíveis à latência, como VoIP.
    2. Assured Forwarding (AF): Oferece uma garantia de encaminhamento com algumas opções de queda. É dividido em quatro subgrupos (AF1, AF2, AF3, AF4) com diferentes níveis de prioridade.
    3. Best Effort (BE): É o comportamento padrão para tráfego que não possui marcação DSCP específica. Recebe tratamento padrão, sem garantias de prioridade.
    4. Class Selector (CS): Inclui as classes CS1, CS2, CS3, CS4, CS5 e CS6. Cada uma delas é uma categoria geral que pode ser usada para definir classes de serviço específicas.

    DSCP (Differentiated Services Code Point):

    O DSCP (Differentiated Services Code Point) e o CoS (Class of Service) são dois mecanismos distintos, mas relacionados, usados para implementar a Qualidade de Serviço (QoS) em redes de dados. Ambos são métodos para classificar e priorizar o tráfego em uma rede, mas são utilizados em diferentes camadas e tecnologias.

    DSCP (Differentiated Services Code Point):

    • Camada de Operação: O DSCP opera na camada 3 do modelo OSI (Camada de Rede). É uma marcação no cabeçalho IP dos pacotes, onde são especificados os níveis de serviço que o pacote deve receber.
    • Campo de Marcação: O DSCP é um campo de 6 bits no cabeçalho IP, localizado na parte de ToS (Type of Service) ou DS (Differentiated Services).
    • Valores DSCP: Existem 64 valores DSCP possíveis, variando de 0 a 63. Esses valores são agrupados em diferentes classes, que indicam diferentes níveis de prioridade para o tráfego.
    • Tratamento de Pacotes: Roteadores e switches podem usar a marcação DSCP para tomar decisões sobre o tratamento e a priorização dos pacotes.

    CoS (Class of Service):

    • Camada de Operação: O CoS opera na camada 2 do modelo OSI (Camada de Enlace). Ele é mais frequentemente associado ao protocolo IEEE 802.1Q, que é usado para marcação de tráfego em redes Ethernet.
    • Campo de Marcação: O CoS é um campo de 3 bits dentro do cabeçalho Ethernet, conhecido como campo “Priority Code Point” (PCP).
    • Valores CoS: Existem 8 valores CoS possíveis, variando de 0 a 7. Assim como o DSCP, esses valores indicam diferentes níveis de prioridade para o tráfego.
    • Tratamento de Pacotes: Dispositivos como switches Ethernet utilizam o CoS para decidir como tratar os pacotes em uma rede local.

    Relação entre PHB, DSCP e CoS: A relação entre PHB, DSCP e CoS é estabelecida através de um mapeamento. Em muitos cenários, quando o tráfego passa de uma rede IP para uma rede Ethernet, o DSCP é mapeado no CoS. Isso é importante para garantir que as políticas de QoS sejam mantidas em toda a rede.

    Tabela de Mapeamento – Exemplo:

    PHBDSCP RangeCoS Value
    Expedited Forwarding465
    Assured Forwarding10-132
    Best Effort00
    Class Selector (CS1)81
    Class Selector (CS2)162
    Class Selector (CS3)243
    Class Selector (CS4)324
    Class Selector (CS5)405
    Class Selector (CS6)486

    Parâmetros Bandwidth e Priority

    Dentro de uma política de QoS podemos trabalhar com dois parâmetros, bandwidth e priority. Eles são usados para controlar o tráfego em uma rede e garantir a entrega de serviços com diferentes requisitos de performance. No entanto, eles têm propósitos e comportamentos distintos:

    Bandwidth (Largura de Banda):

    1. Definição:
      • O parâmetro de largura de banda em uma política de QoS especifica a quantidade mínima de largura de banda que uma classe de tráfego deve receber. Ou seja, ele reserva uma parte da largura de banda total disponível para garantir que certos tipos de tráfego tenham uma alocação mínima.
    2. Comportamento:
      • Se a largura de banda disponível não estiver sendo totalmente utilizada, a classe com a configuração de largura de banda garantida poderá usar o excesso de largura de banda. No entanto, se a largura de banda estiver congestionada, a classe garantida terá a sua alocação protegida, e outras classes podem sofrer redução de largura de banda.
    3. Exemplo de Uso:
      • Alocar uma largura de banda mínima para tráfego de Voz sobre IP (VoIP) para garantir que as chamadas de voz tenham uma qualidade aceitável, mesmo em momentos de congestionamento de rede.

    Priority (Prioridade):

    1. Definição:
      • A configuração de prioridade em uma política de QoS indica que uma determinada classe de tráfego tem prioridade sobre todas as outras classes. Pacotes nesta classe serão processados antes de qualquer outra, independentemente da situação de congestionamento.
    2. Comportamento:
      • Quando a configuração de prioridade está em vigor, os pacotes da classe priorizada serão enviados imediatamente, sem serem adiados por outros pacotes. Isso significa que, em momentos de congestionamento, a classe priorizada pode consumir toda a largura de banda disponível.
    3. Importante Considerar:
      • Ao configurar prioridade, é crucial ter em mente que, se uma classe de tráfego com prioridade estiver usando toda a largura de banda disponível, outras classes podem experimentar atrasos significativos ou até mesmo perda de pacotes.

    Diferença Chave:

    • Bandwidth: Garante uma alocação mínima de largura de banda para uma classe de tráfego, mas permite que a largura de banda não utilizada seja usada por outras classes.
    • Priority: Dá prioridade absoluta a uma classe de tráfego sobre todas as outras, o que significa que ela sempre será tratada primeiro, independentemente da situação de congestionamento. Isso pode potencialmente afetar outras classes de tráfego.

    Classificação e Marcação do Tráfego

    A partir das definições do modelo de negócio, temos a identificação dos seguintes tipos de tráfego a serem classificados e marcados.

    Campus Qos Design Melhores Práticas

    • Sempre execute QoS em hardware em vez de software quando houver escolha;
    • Classifique e marque aplicações tão próximos de suas fontes quanto tecnicamente e administrativamente possível;
      • Aplique políticas para o tráfego indesejado o mais próximo possível de suas fontes;
      • Habilite políticas de enfileiramento em todos os nós onde existe potencial de congestionamento.

    Breve exemplo de Plano de QoS para ambientes com utilização de VoIP

    Em ambientes que utilizam VoIP é importante que a classificação e marcação dos pacotes seja realizada nos equipamentos de camada 2 e 3. Nos equipamentos de camada 2, o telefone IP marca o CoS para Voz e Sinalização, já o switch de rede fica responsável por fazer o mapeamento de CoS para DSCP.

    Marcação de CoS (Layer 2):

    O CoS é marcado no nível Layer 2 usando o campo PCP (Priority Code Point) no cabeçalho Ethernet. Para configurar isso, você pode utilizar o comando mls qos

    ! configure terminal
    mls qos

    mls qos map cos-dscp 0 8 16 24 32 46 48 56
    !
    interface GigabitEthernet0/1
    mls qos trust cos

    Marcação de DSCP (Layer 3):

    • Agora, vamos configurar a marcação de DSCP. O DSCP é aplicado no cabeçalho IP dos pacotes. Para marcar os pacotes VoIP com DSCP EF (Expedited Forwarding), por exemplo:
    configure terminal
    class-map match-any VOIP
    match access-group name VOIP_ACL

    !
    policy-map MARK_DSCP
    class VOIP
    set dscp ef

    Crie uma Access Control List (ACL) para identificar o tráfego VoIP:

    ip access-list extended VOIP_ACL
    permit udp any any range 16384 32767

    Em seguida, aplique o policy-map nas interfaces relevantes (onde o tráfego VoIP ingressa na rede):

    interface GigabitEthernet0/0
    service-policy input MARK_DSCP

    Conclusão

    QoS é uma ferramenta essencial no design de redes de dados modernas, permitindo que os administradores de rede priorizem tráfego, garantam desempenho e otimizem a utilização de recursos para suportar uma variedade de aplicações e serviços críticos.