Pular para o conteúdo principal

Entendendo o Cisco SUDI: Identidade de Dispositivo Baseada em Hardware no Controle de Acesso à Rede

Este guia detalha a arquitetura técnica do Cisco SUDI, explicando como a identidade ancorada em hardware protege o controle de acesso à rede. Ele fornece etapas práticas de implementação para líderes de TI implantarem a autenticação 802.1X EAP-TLS e automatizarem o Zero Touch Provisioning em locais corporativos.

📖 6 min de leitura📝 1,276 palavras🔧 2 exemplos práticos3 questões práticas📚 8 definições principais

Ouça este guia

Ver transcrição do podcast
Entendendo o Cisco SUDI: Identidade de Dispositivo Baseada em Hardware no Controle de Acesso à Rede Um Briefing Técnico da Purple - Roteiro Completo do Podcast (aprox. 10 minutos) --- SEGMENTO 1: INTRODUÇÃO E CONTEXTO (aprox. 1 minuto) Olá e boas-vindas a um briefing técnico da Purple. Vou passar os próximos dez minutos explicando o Cisco SUDI - Secure Unique Device Identifier - o que ele realmente é, como ele se encaixa na sua arquitetura de controle de acesso à rede e o que você precisa fazer a respeito se estiver operando uma infraestrutura Cisco em grande escala. Este conteúdo é voltado para arquitetos de rede, gerentes de TI e CTOs de estabelecimentos - hotéis, redes de varejo, estádios, centros de convenções - qualquer lugar onde você opere WiFi corporativo e precise ter certeza de que o hardware na sua rede é exatamente o que afirma ser. Vamos começar com o problema que o SUDI resolve. Em qualquer rede de grande porte, você tem dezenas ou centenas de pontos de acesso, switches e controladores. A pergunta da qual depende a sua postura de segurança é: como você sabe que cada um desses dispositivos é um produto Cisco genuíno e não modificado - e não uma falsificação, uma unidade comprometida ou um dispositivo que foi violado em trânsito? Essa é a lacuna que o SUDI preenche. --- SEGMENTO 2: MERGULHO TÉCNICO PROFUNDO (aprox. 5 minutos) SUDI significa Secure Unique Device Identifier. É um certificado X.509 versão 3 - o mesmo formato de certificado usado em HTTPS e TLS - mas, em vez de ser emitido para uma pessoa ou um servidor, ele é emitido para uma peça específica de hardware durante a fabricação. Ele contém o identificador do produto e o número de série do dispositivo, e está enraizado na própria infraestrutura de chaves públicas da Cisco. Aqui está o que diferencia o SUDI de um certificado de software que você mesmo instalaria. O certificado SUDI, junto com seu par de chaves associado, reside dentro de um chip resistente a violações chamado módulo Trust Anchor, ou TAm. A chave privada é gerada dentro desse chip e nunca sai dele. Você não pode exportá-la. Você não pode cloná-la. Se alguém violar fisicamente o chip, a chave é destruída. Essa é a raiz de confiança baseada em hardware. O SUDI é a implementação da Cisco do padrão IEEE 802.1AR - o padrão da indústria para Identificadores de Dispositivos Seguros, ou DevIDs. Sob o 802.1AR, a credencial instalada pelo fabricante é chamada de Identificador de Dispositivo Inicial, ou IDevID. O SUDI da Cisco é exatamente isso - um IDevID que a Cisco instala na fábrica. Você pode complementá-lo com um Identificador de Dispositivo Localmente Significativo, ou LDevID, que sua própria PKI emite para políticas de autorização locais. Agora, como isso se conecta ao controle de acesso à rede? O ponto de integração mais comum é o IEEE 802.1X - o padrão de controle de acesso à rede baseado em porta. Quando um ponto de acesso ou switch Cisco entra em operação, ele pode apresentar seu certificado SUDI a um servidor RADIUS - normalmente o Cisco ISE, Identity Services Engine - usando EAP-TLS, que é o Extensible Authentication Protocol com Transport Layer Security. O servidor RADIUS valida o certificado em relação à autoridade de certificação pública da Cisco, confirma que o dispositivo é original e, em seguida, aplica a política de rede apropriada. Isso é significativamente mais forte do que o bypass de endereço MAC, que é a alternativa que a maioria das redes usa para dispositivos de infraestrutura. Os endereços MAC podem ser falsificados em menos de um minuto. Um certificado vinculado ao hardware em um chip resistente a violações não pode ser falsificado sem destruir fisicamente o dispositivo. No contexto de um local de evento, isso importa por três motivos. Primeiro, elimina o risco de pontos de acesso não autorizados se conectarem à sua rede. Um dispositivo falsificado ou não autorizado simplesmente não consegue apresentar um SUDI válido. Segundo, permite o provisionamento automatizado Zero Touch - um novo dispositivo é enviado ao seu local, liga, apresenta seu SUDI e seu sistema de gerenciamento o verifica em relação ao seu inventário antes de enviar a configuração. Sem intervenção manual. Terceiro, fornece uma trilha de auditoria criptograficamente verificável. Cada dispositivo que se autenticou em sua rede fez isso com um certificado que prova que se trata de um produto Cisco específico e nomeado. Deixe-me falar sobre o módulo Trust Anchor com um pouco mais de detalhes, porque ele é a base sobre a qual tudo o mais se apoia. O TAm é um chip proprietário da Cisco que fornece três coisas: armazenamento seguro não volátil para o SUDI e chaves, serviços criptográficos incluindo geração de números aleatórios e identificação por impressão digital de hardware. Vale a pena notar este último ponto - a Cisco identifica os componentes críticos de hardware de um dispositivo no momento da fabricação e armazena essa impressão digital no TAm. Quando o dispositivo inicializa, ele verifica a impressão digital de hardware observada em relação à armazenada. Se não coincidirem, o dispositivo não inicializa. Isso detecta violações de hardware em trânsito - uma preocupação real para implantações em grandes locais de eventos, onde o hardware pode passar por várias mãos antes da instalação. Um problema operacional com o qual você precisa estar atento: os certificados SUDI emitidos antes de maio de 2019 expiram dez anos após a data de fabricação ou em 14 de maio de 2029, o que ocorrer primeiro. A Cisco resolveu isso com uma nova geração de certificados chamada SUDI-2099, válida até dezembro de 2099. Se você estiver executando hardware da série Catalyst 9000 fabricado antes de 2019, precisa verificar as datas de expiração do seu SUDI agora. O comando é show crypto pki certificate no IOS-XE. Procure pelo trustpoint CISCO_IDEVID_SUDI e verifique a data de término. Se você estiver no Catalyst 9200, atualize para o IOS-XE 17.12.2 ou posterior para garantir que está usando o certificado 2099 correto. --- SEGMENTO 3: RECOMENDAÇÕES DE IMPLEMENTAÇÃO E ARMADILHAS (aprox. 2 minutos) Deixe-me apresentar o cenário prático de implementação. Se você está implantando a autenticação baseada em SUDI em um ambiente de estabelecimento, aqui está a sequência que funciona. Comece com sua infraestrutura RADIUS. O Cisco ISE é a escolha natural se você já estiver no ecossistema Cisco, mas qualquer servidor RADIUS que suporte EAP-TLS e possa validar em relação a uma CA externa funcionará. Você precisa importar a CA raiz da Cisco e os certificados ACT2 SUDI CA para o seu repositório de confiança RADIUS. Eles estão disponíveis publicamente no portal PKI da Cisco. Em seguida, configure sua política 802.1X para exigir autenticação baseada em certificado para dispositivos de infraestrutura. Separe isso da sua política de autenticação de usuário final — os fluxos de autenticação de funcionários e convidados são diferentes e devem estar em conjuntos de políticas diferentes no ISE. Para novas implantações, habilite o Zero Touch Provisioning. Seu sistema de gerenciamento de rede — Cisco DNA Centre ou Catalyst Centre — pode usar o SUDI para verificar a identidade do dispositivo antes de enviar a configuração. Isso elimina o processo de preparação manual e reduz o tempo de provisionamento de horas para minutos por dispositivo. Agora, as armadilhas. A mais comum que vejo é misturar a autenticação SUDI com o bypass de endereço MAC na mesma porta. Se você recorrer ao MAB quando o SUDI falhar, você comprometeu o modelo de segurança. Defina uma política clara: dispositivos compatíveis com SUDI devem se autenticar via SUDI, ponto final. Dispositivos não compatíveis com SUDI vão para uma VLAN de quarentena aguardando revisão manual. A segunda armadilha é a expiração do certificado. Configure o monitoramento para datas de expiração do SUDI em toda a sua infraestrutura agora. Não espere por uma interrupção do serviço para descobrir que seus pontos de acesso não conseguem mais se autenticar. A plataforma da Purple se integra ao Cisco Meraki e a outros fornecedores de hardware para exibir sinais de integridade do dispositivo — incluindo o status de autenticação — em um único painel, o que torna esse tipo de monitoramento proativo prático em escala. A terceira armadilha é o desvio de escopo. O SUDI autentica o dispositivo de hardware. Ele não autentica o usuário que se conecta por meio desse dispositivo. Você ainda precisa de uma camada de identidade separada para convidados, funcionários e residentes. É aí que entra uma plataforma como a Purple — nós cuidamos da camada de identidade humana, da captura de consentimento, da atribuição de VLAN para tráfego de convidados e das análises, enquanto o SUDI cuida da camada de infraestrutura subjacente. --- SEGMENTO 4: PERGUNTAS E RESPOSTAS RÁPIDAS (aprox. 1 minuto) Deixe-me responder a três perguntas que recebo regularmente. O SUDI substitui minha PKI existente? Não. O SUDI é um IDevID instalado pelo fabricante. Ele prova que o dispositivo é um hardware Cisco original. Sua PKI corporativa emite LDevIDs e certificados de usuário para todo o resto. Eles funcionam em paralelo. Posso usar o SUDI em hardware que não seja da Cisco? Não. O SUDI é específico da Cisco. A HPE Aruba possui um equivalente chamado certificados de provisionamento IAP. A Ruckus e a Juniper Mist têm seus próprios mecanismos de identidade de dispositivo. O padrão subjacente — IEEE 802.1AR — é neutro em relação ao fornecedor, mas cada fabricante o implementa de maneira diferente. O que acontece quando um certificado SUDI expira? Os serviços que dependem do SUDI para autenticação - HTTPS, SSH com autenticação de certificado, Zero Touch Provisioning - falharão. O dispositivo em si continua a funcionar, mas não consegue mais provar sua identidade criptograficamente. É por isso que a migração do SUDI-2099 é importante. --- SEGMENTO 5: RESUMO E PRÓXIMOS PASSOS (aprox. 1 minuto) Para resumir: o Cisco SUDI oferece uma identidade de dispositivo baseada em hardware que não pode ser falsificada, clonada ou exportada. É a base de uma camada de infraestrutura confiável. Combinado com o IEEE 802.1X e uma política RADIUS bem configurada, ele elimina o risco de dispositivos invasores e permite o provisionamento automatizado em escala. Suas três ações imediatas: uma, auditar seu parque Cisco para verificar as datas de expiração do SUDI usando show crypto pki certificate. Duas, importar a CA raiz da Cisco para o seu repositório de confiança RADIUS e configurar políticas EAP-TLS para dispositivos de infraestrutura. Três, separar sua política de autenticação de infraestrutura da sua política de autenticação de usuário final - elas servem a propósitos diferentes e devem ser gerenciadas de forma independente. Se você quiser se aprofundar em como a Purple se integra com a Cisco Meraki e outros fornecedores de hardware para fornecer segmentação de rede baseada em identidade para convidados, funcionários e residentes, visite purple.ai ou leia os guias relacionados vinculados abaixo deste episódio. Obrigado por ouvir. Vejo você no próximo briefing. --- FIM DO ROTEIRO

📚 Parte da nossa série principal: Enterprise WiFi Security Guide

header_image.png

Executive Summary

Hardware authentication secures the physical foundation of enterprise networks. The Cisco Secure Unique Device Identifier (SUDI) provides an immutable, cryptographically verifiable identity for infrastructure devices, embedded directly into a tamper-resistant chip during manufacturing. For IT leaders managing large-scale deployments across hospitality, retail, and public sectors, SUDI eliminates the risk of rogue hardware and enables automated Zero Touch Provisioning.

This guide details the technical architecture of Cisco SUDI, its integration with IEEE 802.1X Network Access Control (NAC), and the operational steps required to deploy and maintain hardware-based identity at scale. You will learn how to transition from weak MAC address bypass to robust EAP-TLS authentication, manage the SUDI-2099 certificate lifecycle, and align infrastructure security with user identity management platforms like Purple.

Technical Deep-Dive

The Architecture of Hardware Identity

The Cisco Secure Unique Device Identifier (SUDI) is an X.509v3 certificate that provides a permanent identity for network devices. Unlike software certificates that IT teams generate and deploy, Cisco injects the SUDI certificate and its associated key pair into the device during the manufacturing process.

The certificate is securely stored in the Trust Anchor module (TAm), a proprietary, tamper-resistant chip. The TAm generates the private key internally, ensuring it can never be exported or cloned. This hardware root of trust guarantees that if a device successfully authenticates using its SUDI, it is a genuine Cisco product.

SUDI implements the IEEE 802.1AR standard for Secure Device Identifiers. Under this standard, the manufacturer-provided certificate is known as an Initial Device Identifier (IDevID). Organisations can supplement the IDevID with a Locally Significant Device Identifier (LDevID) issued by their own enterprise Public Key Infrastructure (PKI).

sudi_architecture_overview.png

Integration with Network Access Control

In an enterprise environment, SUDI integrates with Network Access Control (NAC) systems primarily through IEEE 802.1X port-based authentication. When a Cisco access point or switch connects to the network, it acts as a supplicant and presents its SUDI certificate to a RADIUS server, such as Cisco Identity Services Engine (ISE).

The authentication process uses Extensible Authentication Protocol with Transport Layer Security (EAP-TLS). The RADIUS server validates the SUDI certificate against the Cisco Public Key Infrastructure. Once validated, the RADIUS server authorises the device and assigns it to the correct VLAN based on the network access policy.

This approach replaces MAC Address Bypass (MAB), a legacy method that relies on easily spoofed MAC addresses. MAB provides zero cryptographic assurance of device identity, leaving networks vulnerable to rogue access points.

Hardware Fingerprinting and Tamper Detection

The Trust Anchor module provides more than secure storage. It actively protects the device against physical tampering during transit or deployment.

During manufacturing, Cisco records a cryptographic fingerprint of the critical hardware components, such as CPUs and ASICs. This fingerprint is permanently stored in the TAm. When the device boots, the UEFI firmware calculates a new fingerprint of the observed hardware and compares it to the master fingerprint in the TAm. If the fingerprints do not match, the device halts the boot process. This mechanism ensures that hardware deployed in a hotel or retail store has not been compromised between the factory and the installation site.

Implementation Guide

Deploying SUDI-based authentication requires coordination between your switching infrastructure, your RADIUS server, and your network management platform. Follow these steps to implement hardware identity.

Step 1: Configure RADIUS Trust

Your RADIUS server must trust the Cisco Certificate Authority that issued the SUDI.

  1. Download the Cisco Root CA and the ACT2 SUDI CA certificates from the Cisco PKI portal.
  2. Import these certificates into the trusted certificate store of your RADIUS server (e.g., Cisco ISE).
  3. Configure the RADIUS server to use these certificates for EAP-TLS authentication.

Step 2: Define 802.1X Policies

Create specific authentication policies for infrastructure devices, separate from user authentication policies.

  1. Create a policy set in Cisco ISE that matches the SUDI certificate attributes (e.g., matching the Subject Alternative Name against expected device PIDs).
  2. Assign successful authentications to the infrastructure management VLAN.
  3. Configure a quarantine VLAN for devices that fail SUDI authentication. Do not configure a fallback to MAB for infrastructure ports.

Step 3: Enable Zero Touch Provisioning

Use SUDI to automate device onboarding.

  1. Configure your network management system (such as Cisco Catalyst Center) to act as the ZTP server.
  2. When a new device connects, it presents its SUDI certificate.
  3. The management system verifies the certificate, confirms the device serial number against the inventory database, and pushes the initial configuration.

sudi_lifecycle_diagram.png

Step 4: Manage the SUDI-2099 Migration

SUDI certificates issued before May 2019 expire either 10 years from the date of manufacture or on 14 May 2029, whichever is earlier. When a SUDI expires, features that rely on it, including HTTPS, SSH, and Zero Touch Provisioning, will fail.

Cisco has introduced SUDI-2099 certificates, which remain valid until December 2099. To ensure continuity:

  1. Audit your inventory using the show crypto pki certificate command on IOS-XE devices. Check the end date of the CISCO_IDEVID_SUDI trustpoint.
  2. Upgrade affected hardware to the recommended software releases. For example, Catalyst 9200 switches require IOS-XE 17.12.2 or later to correctly handle the 2099 expiry date.

Best Practices

To maximise the security benefits of hardware identity, adhere to these vendor-neutral principles.

  1. Enforce Strict EAP-TLS: Require EAP-TLS for all infrastructure devices. Do not permit weaker EAP methods like PEAP for device authentication.
  2. Isolate Infrastructure Identity from User Identity: SUDI authenticates the hardware, not the user. Use a dedicated platform to manage human identity. For example, use Purple to handle guest authentication, consent capture, and first-party data collection, while relying on SUDI to secure the underlying Cisco Meraki or HPE Aruba hardware.
  3. Automate Certificate Monitoring: Implement monitoring tools to track certificate expiry dates across your entire estate. Proactive monitoring prevents sudden authentication failures.
  4. Implement Micro-segmentation: Use the identity verified by SUDI to assign devices to strictly controlled VLANs. An access point should only have network reachability to its controller and management systems, nothing else.

Troubleshooting & Risk Mitigation

When deploying SUDI-based authentication, prepare for these common failure modes.

Failure Mode Root Cause Mitigation Strategy
EAP-TLS Authentication Fails RADIUS server lacks the correct Cisco Root or Intermediate CA certificates. Verify that the complete Cisco trust chain is installed in the RADIUS server's trusted store.
Device Refuses to Boot The hardware fingerprint calculated at boot does not match the master fingerprint in the TAm. Treat the device as compromised. Return the hardware to the vendor via the RMA process.
Management Access Fails The SUDI certificate has expired, breaking HTTPS and SSH certificate authentication. Upgrade the device firmware to a release that supports SUDI-2099, or deploy an LDevID using your enterprise PKI.
Rogue Device Gains Access The switch port is configured to fall back to MAC Address Bypass (MAB) if 802.1X fails. Remove MAB fallback configurations from infrastructure ports. Enforce strict 802.1X policy.

ROI & Business Impact

Implementing hardware-based device identity delivers measurable business value across three areas.

1. Reduced Provisioning Costs Zero Touch Provisioning secured by SUDI eliminates manual staging. Instead of an engineer spending 45 minutes pre-configuring an access point before shipping it to a retail store, the device ships directly from the distributor. It authenticates securely upon connection and downloads its configuration automatically. For a 500-site retail deployment, this saves approximately 375 engineering hours.

2. Eliminated Rogue Device Risk By deprecating MAC Address Bypass in favour of cryptographic hardware identity, you eliminate the risk of an attacker connecting a rogue device to an infrastructure port. This directly supports compliance with PCI DSS and ISO 27001 requirements for network access control.

3. Clear Identity Boundaries Deploying SUDI establishes a clean architectural boundary. The hardware layer authenticates itself cryptographically, allowing you to focus your resources on the user identity layer. When you integrate a platform like Purple to manage Guest WiFi and WiFi Analytics , you do so on top of a verifiable, secure infrastructure foundation.

Definições principais

SUDI (Secure Unique Device Identifier)

Um certificado X.509v3 e chave privada associada incorporados em um dispositivo Cisco durante a fabricação para fornecer uma identidade de hardware imutável.

Usado por equipes de TI para verificar criptograficamente se um dispositivo que se conecta à rede é um produto Cisco autêntico.

TAm (Trust Anchor module)

Um chip de hardware proprietário e resistente a violações que armazena com segurança o certificado SUDI, gera chaves criptográficas e gerencia a identificação por impressão digital do hardware.

Fornece a raiz de confiança do hardware. Se o TAm for comprometido, o dispositivo falhará ao inicializar ou autenticar.

IDevID (Initial Device Identifier)

O identificador de dispositivo seguro instalado pelo fabricante, definido pelo padrão IEEE 802.1AR. O Cisco SUDI é uma implementação de um IDevID.

Fornece a identidade fundamental para um dispositivo antes de ele ser integrado ao ambiente de PKI da própria organização.

LDevID (Locally Significant Device Identifier)

Um certificado de dispositivo emitido pela própria Infraestrutura de Chaves Públicas corporativa de uma organização, complementando o IDevID do fabricante.

Usado quando as equipes de TI exigem que os dispositivos se autentiquem usando certificados emitidos por sua CA corporativa interna, em vez da CA do fornecedor.

IEEE 802.1X

O padrão IEEE para controle de acesso à rede baseado em porta, fornecendo um mecanismo de autenticação para dispositivos que desejam se conectar a uma LAN ou WLAN.

O principal protocolo usado para aplicar a segurança de rede, garantindo que apenas dispositivos e usuários autorizados possam enviar tráfego por meio de uma porta de switch.

EAP-TLS (Extensible Authentication Protocol-Transport Layer Security)

Um protocolo de autenticação altamente seguro que exige que tanto o cliente quanto o servidor de autenticação comprovem suas identidades usando certificados digitais.

O método específico usado no 802.1X para validar o certificado SUDI entre o dispositivo de rede e o servidor RADIUS.

Zero Touch Provisioning (ZTP)

Um processo automatizado que permite que os dispositivos de rede sejam provisionados e configurados automaticamente, sem intervenção manual.

O SUDI protege o ZTP garantindo que o sistema de gerenciamento envie configurações apenas para hardware verificado e autêntico.

MAC Address Bypass (MAB)

Um método de autenticação legado no qual um switch usa o endereço MAC do dispositivo de conexão como sua credencial de identidade.

Um método de fallback inseguro que deve ser eliminado e substituído pela autenticação 802.1X baseada em SUDI.

Exemplos práticos

Um hotel de 400 quartos está atualizando sua infraestrutura de rede e precisa implantar 250 novos pontos de acesso Cisco Catalyst. A equipe de TI deseja evitar a configuração manual de cada dispositivo antes da instalação, garantindo ao mesmo tempo que nenhum dispositivo não autorizado possa ingressar na VLAN de gerenciamento.

  1. A equipe de TI configura o Cisco ISE com a Cisco Root CA para confiar nos certificados SUDI.
  2. Eles criam uma política 802.1X no ISE que atribui dispositivos que apresentam um SUDI válido a uma VLAN de provisionamento restrita.
  3. Os pontos de acesso são enviados diretamente para o hotel e conectados aos switches PoE.
  4. Cada AP inicializa, apresenta seu SUDI via EAP-TLS e é autenticado pelo ISE.
  5. O sistema de gerenciamento (Catalyst Center) verifica o número de série, provisiona o AP e o ISE altera a porta para a VLAN de gerenciamento de produção.
Comentário do examinador: Esta abordagem utiliza o Zero Touch Provisioning protegido por identidade de hardware. Ela elimina os custos de preparação manual e evita que dispositivos não autorizados explorem portas de provisionamento abertas. O uso de Change of Authorization (CoA) para mover o dispositivo de uma VLAN de provisionamento para uma VLAN de produção demonstra uma forte segmentação de rede.

Uma rede varejista nacional com 1.200 lojas descobre que seus switches legados usam MAC Address Bypass (MAB) para autenticar pontos de acesso. Eles precisam migrar para um padrão seguro sem causar interrupções nas lojas.

  1. A equipe de rede audita o inventário de switches para confirmar se todos os dispositivos suportam 802.1X e SUDI.
  2. Eles implantam os certificados Cisco CA em sua infraestrutura RADIUS.
  3. Eles configuram as portas dos switches em 'modo de monitoramento' (autenticação aberta), permitindo que os dispositivos tentem o 802.1X EAP-TLS usando SUDI enquanto recorrem ao MAB em caso de falha, registrando os resultados em log.
  4. Após verificar nos logs do RADIUS que todos os APs legítimos estão se autenticando com sucesso via SUDI, eles alteram as portas para o 'modo fechado', aplicando o 802.1X estrito e desativando o MAB.

Questões práticas

Q1. Você está implantando 50 novos switches Cisco Catalyst em um ambiente de estádio. A política de segurança exige autenticação 802.1X estrita para todos os dispositivos de infraestrutura. Durante os testes, os switches falham ao se autenticar no servidor Cisco ISE. Qual é a causa mais provável?

Dica: Considere a cadeia de confiança necessária para a autenticação EAP-TLS.

Ver resposta modelo

O servidor Cisco ISE não possui os certificados Cisco Root CA ou ACT2 SUDI CA em seu repositório de certificados confiáveis. Sem eles, o ISE não pode validar o certificado SUDI apresentado pelos switches. Você deve baixar os certificados do portal Cisco PKI e importá-los para o ISE.

Q2. Um engenheiro de rede propõe configurar as portas do switch para tentar a autenticação 802.1X primeiro, mas recorrer ao MAC Address Bypass (MAB) se o dispositivo não tiver um certificado válido. Por que você deve rejeitar essa proposta para portas de infraestrutura?

Dica: Avalie a força de segurança do mecanismo de fallback.

Ver resposta modelo

O fallback para MAB enfraquece todo o modelo de segurança. Um invasor pode simplesmente conectar um dispositivo não autorizado, aguardar o timeout do 802.1X e falsificar o endereço MAC de um access point legítimo para obter acesso à VLAN de infraestrutura. As portas de infraestrutura devem impor 802.1X estrito com SUDI, e os dispositivos não compatíveis devem ser colocados em uma VLAN de quarentena restrita.

Q3. Você está auditando uma rede de switches Catalyst 9200 implantados em 2018. Você executa o comando 'show crypto pki certificate' e percebe que o trustpoint CISCO_IDEVID_SUDI expira em maio de 2029. Que ação você deve tomar para evitar interrupções futuras?

Dica: Revise os requisitos de migração do SUDI-2099 para hardware legado.

Ver resposta modelo

Você deve atualizar o software IOS-XE nos switches Catalyst 9200 para a versão 17.12.2 ou posterior. Essa atualização garante que o hardware suporte adequadamente a extensão de certificado SUDI-2099, estendendo a identidade válida do dispositivo até dezembro de 2099 e evitando falhas de autenticação para serviços como HTTPS e ZTP.