Compreender o Cisco SUDI: Identidade de Dispositivo Baseada em Hardware no Controlo de Acesso à Rede

Este guia detalha a arquitetura técnica do Cisco SUDI, explicando como a identidade ancorada em hardware protege o controlo de acesso à rede. Fornece passos de implementação práticos para líderes de TI implementarem a autenticação 802.1X EAP-TLS e automatizarem o Zero Touch Provisioning em espaços empresariais.

📖 6 min de leitura📝 1,346 palavras🔧 2 exemplos práticos❓ 3 perguntas de prática📚 8 definições principais

Ouça este guia

Ver transcrição do podcast

Compreender o Cisco SUDI: Identidade de Dispositivo Baseada em Hardware no Controlo de Acesso à Rede
Uma Sessão Técnica da Purple - Transcrição Completa do Podcast (aprox. 10 minutos)

---

SEGMENTO 1: INTRODUÇÃO E CONTEXTO (aprox. 1 minuto)

Olá e bem-vindo a uma sessão técnica da Purple. Vou passar os próximos dez minutos a explicar-lhe o Cisco SUDI - Secure Unique Device Identifier - o que é na realidade, como se enquadra na sua arquitetura de controlo de acesso à rede e o que precisa de fazer em relação a isso se estiver a gerir infraestrutura Cisco em grande escala.

Isto destina-se a arquitetos de rede, gestores de TI e CTOs em espaços físicos - hotéis, superfícies comerciais, estádios, centros de conferências - qualquer local onde tenha WiFi empresarial e precise de ter a certeza de que o hardware na sua rede é exatamente o que afirma ser.

Comecemos pelo problema que o SUDI resolve. Em qualquer rede de um grande espaço, existem dezenas ou centenas de pontos de acesso, switches e controladores. A questão da qual depende a sua postura de segurança é: como 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 adulterado em trânsito? É essa a lacuna que o SUDI preenche.

---

SEGMENTO 2: ANÁLISE TÉCNICA DETALHADA (aprox. 5 minutos)

SUDI significa Secure Unique Device Identifier. É um certificado X.509 versão 3 - o mesmo formato de certificado utilizado em HTTPS e TLS - mas, em vez de ser emitido para uma pessoa ou um servidor, é emitido para uma peça de hardware específica durante o fabrico. Contém o identificador de produto e o número de série do dispositivo, e está enraizado na própria infraestrutura de chaves públicas da Cisco.

Eis o que torna o SUDI diferente de um certificado de software que instalaria por si próprio. O certificado SUDI, juntamente com o seu par de chaves associado, reside dentro de um chip inviolável chamado módulo Trust Anchor, ou TAm. A chave privada é gerada dentro desse chip e nunca sai dele. Não é possível exportá-la. Não é possível cloná-la. Se alguém adulterar 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. Ao abrigo do 802.1AR, a credencial instalada pelo fabricante é designada por Initial Device Identifier, ou IDevID. O SUDI da Cisco é exatamente isso - um IDevID que a Cisco instala na fábrica. Pode complementá-lo com um Locally Significant Device Identifier, ou LDevID, que a sua própria PKI emite para políticas de autorização locais.

Agora, como é que isto se liga ao controlo de acessos à rede? O ponto de integração mais comum é o IEEE 802.1X - o padrão de controlo de acessos à rede baseado em portas. Quando um ponto de acesso ou switch Cisco fica online, pode apresentar o seu certificado SUDI a um servidor RADIUS - normalmente o Cisco ISE, Identity Services Engine - utilizando EAP-TLS, que é o Extensible Authentication Protocol com Transport Layer Security. O servidor RADIUS valida o certificado face à autoridade de certificação pública da Cisco, confirma que o dispositivo é genuíno e, em seguida, aplica a política de rede adequada.

Isto é significativamente mais forte do que o bypass de endereço MAC, que é a alternativa que a maioria das redes utiliza para dispositivos de infraestrutura. Os endereços MAC podem ser falsificados em menos de um minuto. Um certificado associado ao hardware num chip resistente a adulterações não pode ser falsificado sem destruir fisicamente o dispositivo.

No contexto de um espaço físico, isto é importante por três razões. Primeiro, elimina o risco de pontos de acesso não autorizados se juntarem à sua rede. Um dispositivo falsificado ou não autorizado simplesmente não consegue apresentar um SUDI válido. Segundo, permite o aprovisionamento automatizado e Zero Touch - um novo dispositivo é enviado para o seu espaço, liga-se, apresenta o seu SUDI e o seu sistema de gestão verifica-o face ao seu inventário antes de enviar a configuração. Sem intervenção manual. Terceiro, fornece-lhe um registo de auditoria criptograficamente verificável. Cada dispositivo que se autenticou na sua rede fê-lo com um certificado que prova que se trata de um produto Cisco específico e identificado.

Deixe-me falar sobre o módulo Trust Anchor com um pouco mais de detalhe, porque é a base sobre a qual tudo o resto assenta. 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 a geração de números aleatórios, e recolha de impressões digitais de hardware. Vale a pena notar este último ponto - a Cisco recolhe as impressões digitais dos componentes de hardware críticos de um dispositivo no momento do fabrico e armazena essa impressão digital no TAm. Quando o dispositivo arranca, verifica a impressão digital de hardware observada face à armazenada. Se não coincidirem, o dispositivo não arranca. Isto deteta a adulteração de hardware em trânsito - uma preocupação real para implementações em grandes espaços onde o hardware pode passar por várias mãos antes da instalação.

Uma questão operacional de que deve estar ciente: os certificados SUDI emitidos antes de maio de 2019 expiram dez anos após a data de fabrico ou a 14 de maio de 2029, o que ocorrer primeiro. A Cisco resolveu este problema com uma nova geração de certificados chamada SUDI-2099, válida até dezembro de 2099. Se estiver a executar hardware da série Catalyst 9000 fabricado antes de 2019, precisa de verificar as suas datas de expiração do SUDI agora. O comando é show crypto pki certificate no IOS-XE. Procure o trustpoint CISCO_IDEVID_SUDI e verifique a data de fim. Se estiver no Catalyst 9200, atualize para o IOS-XE 17.12.2 ou posterior para garantir que está a utilizar o certificado 2099 correto.

---

SEGMENTO 3: RECOMENDAÇÕES DE IMPLEMENTAÇÃO E ARMADILHAS (aprox. 2 minutos)

Deixe-me dar-lhe uma perspetiva prática de implementação. Se está a implementar a autenticação baseada em SUDI num ambiente de recinto, eis a sequência que funciona.

Comece com a sua infraestrutura RADIUS. O Cisco ISE é a escolha natural se já estiver no ecossistema Cisco, mas qualquer servidor RADIUS que suporte EAP-TLS e que possa validar contra uma CA externa funcionará. Precisa de importar a CA raiz da Cisco e os certificados ACT2 SUDI CA para o seu repositório de confiança RADIUS. Estes estão publicamente disponíveis no portal PKI da Cisco.

Em seguida, configure a sua política 802.1X para exigir autenticação baseada em certificado para dispositivos de infraestrutura. Separe isto da sua política de autenticação de utilizador 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 implementações, ative o Zero Touch Provisioning. O seu sistema de gestão de rede - Cisco DNA Centre ou Catalyst Centre - pode utilizar o SUDI para verificar a identidade do dispositivo antes de enviar a configuração. Isto elimina o processo de preparação manual e reduz o tempo de aprovisionamento 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 recorrer ao MAB quando o SUDI falha, comprometeu o modelo de segurança. Defina uma política clara: os dispositivos compatíveis com SUDI devem autenticar-se via SUDI, ponto final. Os dispositivos não-SUDI vão para uma VLAN de quarentena a aguardar revisão manual.

A segunda armadilha é a expiração do certificado. Configure a monitorização para as datas de expiração do SUDI em todo o seu parque informático agora. Não espere por uma interrupção de serviço para descobrir que os seus pontos de acesso já não se conseguem autenticar. A plataforma da Purple integra-se com a Cisco Meraki e outros fornecedores de hardware para apresentar sinais de integridade dos dispositivos - incluindo o estado de autenticação - num único painel, o que torna este tipo de monitorização proativa prático à escala.

A terceira armadilha é o desvio de âmbito. O SUDI autentica o dispositivo de hardware. Não autentica o utilizador que se liga através desse dispositivo. Continua a precisar de uma camada de identidade separada para convidados, funcionários e residentes. É aí que se posiciona uma plataforma como a Purple - nós tratamos da camada de identidade humana, da recolha de consentimento, da atribuição de VLAN para tráfego de convidados e da análise de dados, enquanto o SUDI trata da camada de infraestrutura subjacente.

---

SEGMENTO 4: PERGUNTAS E RESPOSTAS RÁPIDAS (aprox. 1 minuto)

Deixe-me responder rapidamente a três perguntas que me fazem regularmente.

O SUDI substitui a minha PKI existente? Não. O SUDI é um IDevID instalado pelo fabricante. Prova que o dispositivo é hardware genuíno da Cisco. A sua PKI empresarial emite LDevIDs e certificados de utilizador para tudo o resto. Funcionam em paralelo.

Posso utilizar o SUDI em hardware que não seja da Cisco? Não. O SUDI é específico da Cisco. A HPE Aruba tem um equivalente chamado certificados de aprovisionamento IAP. A Ruckus e a Juniper Mist têm os seus próprios mecanismos de identidade de dispositivos. O padrão subjacente - IEEE 802.1AR - é neutro em termos de fornecedor, mas cada fabricante implementa-o de forma diferente.

O que acontece quando um certificado SUDI expira? Os serviços que dependem do SUDI para autenticação - HTTPS, SSH com autenticação por certificado, Zero Touch Provisioning - irão falhar. O dispositivo em si continua a funcionar, mas já não consegue provar a sua identidade de forma criptográfica. É por isso que a migração para o SUDI-2099 é importante.

---

SEGMENTO 5: RESUMO E PRÓXIMOS PASSOS (aprox. 1 minuto)

Para concluir: o Cisco SUDI oferece-lhe uma identidade de dispositivo enraizada no hardware que não pode ser falsificada, clonada ou exportada. É a base de uma camada de infraestrutura fiável. Combinado com o IEEE 802.1X e uma política RADIUS bem configurada, elimina o risco de dispositivos não autorizados e permite o aprovisionamento automatizado à escala.

As suas três ações imediatas: primeiro, audite o seu parque de equipamentos Cisco para verificar as datas de expiração do SUDI utilizando o comando "show crypto pki certificate". Segundo, importe a CA raiz da Cisco para o seu repositório de fidedignidade RADIUS e configure políticas EAP-TLS para dispositivos de infraestrutura. Terceiro, separe a sua política de autenticação de infraestrutura da sua política de autenticação de utilizadores finais - estas servem propósitos diferentes e devem ser geridas de forma independente.

Se quiser aprofundar a forma como a Purple se integra com a Cisco Meraki e outros fornecedores de hardware para disponibilizar segmentação de rede baseada em identidade para convidados, funcionários e residentes, visite purple.ai ou leia os guias relacionados com hiperligação abaixo deste episódio.

Obrigado por ouvir. Vemo-nos no próximo briefing.

---
FIM DO SCRIPT

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

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.

Download the Cisco Root CA and the ACT2 SUDI CA certificates from the Cisco PKI portal.
Import these certificates into the trusted certificate store of your RADIUS server (e.g., Cisco ISE).
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.

Create a policy set in Cisco ISE that matches the SUDI certificate attributes (e.g., matching the Subject Alternative Name against expected device PIDs).
Assign successful authentications to the infrastructure management VLAN.
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.

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

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:

Audit your inventory using the show crypto pki certificate command on IOS-XE devices. Check the end date of the CISCO_IDEVID_SUDI trustpoint.
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.

Enforce Strict EAP-TLS: Require EAP-TLS for all infrastructure devices. Do not permit weaker EAP methods like PEAP for device authentication.
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.
Automate Certificate Monitoring: Implement monitoring tools to track certificate expiry dates across your entire estate. Proactive monitoring prevents sudden authentication failures.
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 a respetiva chave privada associada, incorporados num dispositivo Cisco durante o fabrico para fornecer uma identidade de hardware imutável.

Utilizado pelas equipas de TI para verificar criptograficamente que um dispositivo que se liga à rede é um produto Cisco genuíno.

TAm (Trust Anchor module)

Um chip de hardware proprietário e resistente a adulterações que armazena de forma segura o certificado SUDI, gera chaves criptográficas e gere a impressão digital do hardware.

Fornece a raiz de confiança do hardware. Se o TAm for comprometido, o dispositivo não conseguirá arrancar ou autenticar-se.

IDevID (Initial Device Identifier)

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

Fornece a identidade fundamental para um dispositivo antes de este ser integrado no ambiente PKI próprio de uma organização.

LDevID (Locally Significant Device Identifier)

Um certificado de dispositivo emitido pela infraestrutura de chaves públicas (PKI) empresarial de uma organização, complementando o IDevID do fabricante.

Utilizado quando as equipas de TI exigem que os dispositivos se autentiquem utilizando certificados emitidos pela sua CA corporativa interna, em vez da CA do fornecedor.

IEEE 802.1X

A norma IEEE para controlo de acesso à rede baseado em portas, fornecendo um mecanismo de autenticação para dispositivos que pretendem ligar-se a uma LAN ou WLAN.

O protocolo principal utilizado para aplicar a segurança de rede, garantindo que apenas dispositivos e utilizadores autorizados podem enviar tráfego através 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 como o servidor de autenticação provem as suas identidades utilizando certificados digitais.

O método específico utilizado no âmbito do 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 gestão apenas envia configurações para hardware verificado e genuíno.

MAC Address Bypass (MAB)

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

Um método de contingência 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á a atualizar a sua infraestrutura de rede e precisa de implementar 250 novos pontos de acesso Cisco Catalyst. A equipa de TI quer evitar a configuração manual de cada dispositivo antes da instalação, garantindo ao mesmo tempo que nenhum dispositivo não autorizado se possa juntar à VLAN de gestão.

A equipa de TI configura o Cisco ISE com a Cisco Root CA para confiar nos certificados SUDI.
Cria uma política 802.1X no ISE que atribui os dispositivos que apresentem um SUDI válido a uma VLAN de aprovisionamento restrita.
Os pontos de acesso são enviados diretamente para o hotel e ligados aos switches PoE.
Cada AP arranca, apresenta o seu SUDI via EAP-TLS e é autenticado pelo ISE.
O sistema de gestão (Catalyst Center) verifica o número de série, aprovisiona o AP e o ISE altera a porta para a VLAN de gestão de produção.

Comentário do Examinador: Esta abordagem utiliza o Zero Touch Provisioning protegido por identidade de hardware. Elimina os custos de preparação manual e impede que dispositivos não autorizados explorem portas de aprovisionamento abertas. A utilização de Change of Authorization (CoA) para mover o dispositivo de uma VLAN de aprovisionamento para uma VLAN de produção demonstra uma forte segmentação de rede.

Uma cadeia de retalho nacional com 1.200 lojas descobre que os seus switches antigos utilizam MAC Address Bypass (MAB) para autenticar pontos de acesso. Precisam de migrar para um padrão seguro sem causar interrupções nas lojas.

A equipa de rede audita o inventário de switches para confirmar que todos os dispositivos suportam 802.1X e SUDI.
Implementa os certificados Cisco CA na sua infraestrutura RADIUS.
Configura as portas dos switches em 'modo de monitorização' (autenticação aberta), permitindo que os dispositivos tentem o 802.1X EAP-TLS utilizando o SUDI, recorrendo ao MAB em caso de falha, mas registando os resultados.
Após verificar nos registos do RADIUS que todos os APs legítimos se estão a autenticar com sucesso via SUDI, altera as portas para 'modo fechado', impondo o 802.1X estrito e desativando o MAB.

Comentário do Examinador: A migração faseada utilizando o modo de monitorização é a abordagem operacional correta para uma grande rede de retalho. Permite à equipa validar a cadeia de confiança PKI e a validade dos certificados sem correr o risco de isolamento de rede para os pontos de acesso. A remoção total do MAB é o passo final necessário para proteger o ambiente.

Perguntas de Prática

Q1. Está a implementar 50 novos switches Cisco Catalyst num ambiente de estádio. A política de segurança exige uma autenticação 802.1X rigorosa para todos os dispositivos de infraestrutura. Durante os testes, os switches não conseguem autenticar-se no seu 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 tem os certificados Cisco Root CA ou ACT2 SUDI CA no seu repositório de certificados fidedignos. Sem estes, o ISE não consegue validar o certificado SUDI apresentado pelos switches. Deve descarregar 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 primeiro a autenticação 802.1X, mas reverter para MAC Address Bypass (MAB) se o dispositivo não tiver um certificado válido. Por que razão deve rejeitar esta proposta para portas de infraestrutura?

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

Ver resposta modelo

A reversão para MAB compromete todo o modelo de segurança. Um atacante pode simplesmente ligar um dispositivo não autorizado, aguardar pelo 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 rigoroso com SUDI, e os dispositivos não conformes devem ser colocados numa VLAN de quarentena restrita.

Q3. Está a auditar uma rede de switches Catalyst 9200 implementados em 2018. Executa o comando 'show crypto pki certificate' e nota que o trustpoint CISCO_IDEVID_SUDI expira em maio de 2029. Que ação deve tomar para evitar futuras interrupções de serviço?

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

Ver resposta modelo

Deve atualizar o software IOS-XE nos switches Catalyst 9200 para a versão 17.12.2 ou posterior. Esta atualização garante que o hardware suporta corretamente a extensão de certificado SUDI-2099, prolongando a identidade válida do dispositivo até dezembro de 2099 e evitando falhas de autenticação em serviços como HTTPS e ZTP.

Continue a ler esta série

Como Segregar com Segurança Redes WiFi de Funcionários e Convidados

Este guia técnico de referência fornece aos líderes de TI estratégias práticas para segregar com segurança redes WiFi de funcionários, convidados e IoT utilizando VLANs e 802.1X. Detalha como proteger a infraestrutura empresarial, manter a conformidade com o PCI-DSS e potenciar Captive Portals para recolher dados primários (first-party data).

Melhor filtragem DNS: um guia completo para empresas

Este guia de referência técnica explica como a filtragem DNS empresarial protege as redes públicas bloqueando domínios maliciosos na camada de resolução - antes de uma ligação ser estabelecida. Oferece aos diretores de TI, arquitetos de rede e equipas de operações de locais a arquitetura de implementação, configuração de firewall e contexto de conformidade necessários para proteger o Guest WiFi em ambientes de hotelaria, retalho e setor público. O Purple Shield bloqueia malware, botnets e conteúdos inadequados ao nível do DNS em mais de 80.000 locais ativos.

How to Configure SCEP for Automated Enterprise WiFi Certificate Enrollment

Este guia explica como configurar o SCEP (Simple Certificate Enrollment Protocol) para a atribuição automatizada de certificados WiFi empresariais, cobrindo toda a arquitetura desde PKI e NDES até à implementação de perfis MDM e validação RADIUS. Destina-se a gestores de TI, arquitetos de rede e CTOs em hotéis, cadeias de retalho, estádios, centros de conferências e organizações do setor público que necessitam de ir além das chaves pré-partilhadas e implementar uma autenticação 802.1X EAP-TLS escalável e baseada em identidade. A plataforma de sobreposição na nuvem da Purple, independente de hardware, integra-se diretamente com esta arquitetura, fornecendo a camada de WiFi para convidados e BYOD que coexiste com a sua rede de colaboradores autenticada por certificado.