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,346 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

header_image.png

Resumo Executivo

A autenticação de hardware protege a base física das redes corporativas. O Cisco Secure Unique Device Identifier (SUDI) fornece uma identidade imutável e criptograficamente verificável para dispositivos de infraestrutura, incorporada diretamente em um chip resistente a adulterações durante a fabricação. Para líderes de TI que gerenciam implantações em larga escala nos setores de hotelaria, varejo e setor público, o SUDI elimina o risco de hardware não autorizado e permite o Zero Touch Provisioning automatizado.

Este guia detalha a arquitetura técnica do Cisco SUDI, sua integração com o Network Access Control (NAC) IEEE 802.1X e as etapas operacionais necessárias para implantar e manter a identidade baseada em hardware em escala. Você aprenderá como fazer a transição do bypass de endereço MAC fraco para a autenticação EAP-TLS robusta, gerenciar o ciclo de vida do certificado SUDI-2099 e alinhar a segurança da infraestrutura com plataformas de gerenciamento de identidade de usuários como a Purple.

Aprofundamento Técnico

A Arquitetura da Identidade de Hardware

O Cisco Secure Unique Device Identifier (SUDI) é um certificado X.509v3 que fornece uma identidade permanente para dispositivos de rede. Ao contrário dos certificados de software que as equipes de TI geram e implantam, a Cisco injeta o certificado SUDI e seu par de chaves associado no dispositivo durante o processo de fabricação.

O certificado é armazenado com segurança no módulo Trust Anchor (TAm), um chip proprietário e resistente a adulterações. O TAm gera a chave privada internamente, garantindo que ela nunca possa ser exportada ou clonada. Essa raiz de confiança de hardware garante que, se um dispositivo for autenticado com sucesso usando seu SUDI, ele é um produto Cisco genuíno.

O SUDI implementa o padrão IEEE 802.1AR para Identificadores de Dispositivos Seguros. Sob este padrão, o certificado fornecido pelo fabricante é conhecido como Initial Device Identifier (IDevID). As organizações podem complementar o IDevID com um Locally Significant Device Identifier (LDevID) emitido por sua própria Infraestrutura de Chaves Públicas (PKI) corporativa.

sudi_architecture_overview.png

Integração com Network Access Control

Em um ambiente corporativo, o SUDI se integra aos sistemas de Network Access Control (NAC) principalmente por meio da autenticação baseada em porta IEEE 802.1X. Quando um ponto de acesso ou switch Cisco se conecta à rede, ele age como um suplicante e apresenta seu certificado SUDI a um servidor RADIUS, como o 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

Passo 4: Gerenciar a Migração do SUDI-2099

Os certificados SUDI emitidos antes de maio de 2019 expiram 10 anos após a data de fabricação ou em 14 de maio de 2029, o que ocorrer primeiro. Quando um SUDI expira, os recursos que dependem dele, incluindo HTTPS, SSH e Zero Touch Provisioning, falharão.

A Cisco introduziu os certificados SUDI-2099, que permanecem válidos até dezembro de 2099. Para garantir a continuidade:

  1. Audite seu inventário usando o comando show crypto pki certificate em dispositivos IOS-XE. Verifique a end date do trustpoint CISCO_IDEVID_SUDI.
  2. Atualize o hardware afetado para as versões de software recomendadas. Por exemplo, os switches Catalyst 9200 exigem o IOS-XE 17.12.2 ou posterior para lidar corretamente com a data de expiração de 2099.

Boas Práticas

Para maximizar os benefícios de segurança da identidade baseada em hardware, siga estes princípios neutros de fornecedor.

  1. Impor EAP-TLS Estrito: Exija EAP-TLS para todos os dispositivos de infraestrutura. Não permita métodos EAP mais fracos, como PEAP, para autenticação de dispositivos.
  2. Isolar a Identidade da Infraestrutura da Identidade do Usuário: O SUDI autentica o hardware, não o usuário. Use uma plataforma dedicada para gerenciar a identidade humana. Por exemplo, use a Purple para lidar com a autenticação de convidados, captura de consentimento e coleta de dados primários, enquanto conta com o SUDI para proteger o hardware subjacente Cisco Meraki ou HPE Aruba.
  3. Automatizar o Monitoramento de Certificados: Implemente ferramentas de monitoramento para rastrear as datas de expiração dos certificados em todo o seu parque de dispositivos. O monitoramento proativo evita falhas repentinas de autenticação.
  4. Implementar Micro-segmentação: Use a identidade verificada pelo SUDI para atribuir dispositivos a VLANs estritamente controladas. Um ponto de acesso deve ter alcançabilidade de rede apenas para seu controlador e sistemas de gerenciamento, nada mais.

Resolução de Problemas e Mitigação de Riscos

Ao implantar a autenticação baseada em SUDI, prepare-se para estes modos de falha comuns.

Modo de Falha Causa Raiz Estratégia de Mitigação
Falha na Autenticação EAP-TLS O servidor RADIUS não possui os certificados Cisco Root ou Intermediate CA corretos. Verifique se a cadeia de confiança completa da Cisco está instalada no repositório confiável do servidor RADIUS.
Dispositivo Recusa a Inicializar A assinatura de hardware calculada na inicialização não corresponde à assinatura mestre no TAm. Trate o dispositivo como comprometido. Devolva o hardware ao fornecedor por meio do processo de RMA.
Falha no Acesso de Gerenciamento O certificado SUDI expirou, quebrando a autenticação de certificado HTTPS e SSH. Atualize o firmware do dispositivo para uma versão que suporte SUDI-2099 ou implante um LDevID usando a PKI da sua empresa.
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 & Impacto nos Negócios

A implementação da identidade de dispositivo baseada em hardware entrega valor de negócio mensurável em três áreas.

1. Redução de Custos de Provisionamento O Zero Touch Provisioning protegido por SUDI elimina a preparação manual. Em vez de um engenheiro gastar 45 minutos pré-configurando um access point antes de enviá-lo para uma loja de varejo, o dispositivo é enviado diretamente do distribuidor. Ele se autentica com segurança ao se conectar e baixa sua configuração automaticamente. Para uma implantação de varejo em 500 locais, isso economiza aproximadamente 375 horas de engenharia.

2. Eliminação do Risco de Dispositivos Não Autorizados Ao descontinuar o MAC Address Bypass em favor da identidade criptográfica de hardware, você elimina o risco de um invasor conectar um dispositivo não autorizado a uma porta de infraestrutura. Isso apoia diretamente a conformidade com os requisitos do PCI DSS e ISO 27001 para controle de acesso à rede.

3. Limites de Identidade Claros A implantação do SUDI estabelece um limite arquitetônico limpo. A camada de hardware se autentica criptograficamente, permitindo que você concentre seus recursos na camada de identidade do usuário. Quando você integra uma plataforma como a Purple para gerenciar o Guest WiFi e o WiFi Analytics , você o faz sobre uma base de infraestrutura verificável e segura.

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.

Continue a ler esta série

Como Configurar o SCEP para Registro Automatizado de Certificados de WiFi Corporativo

Este guia explica como configurar o SCEP (Simple Certificate Enrollment Protocol) para o registro automatizado de certificados de WiFi corporativo, cobrindo toda a arquitetura, desde PKI e NDES até a implantação de perfis MDM e validação RADIUS. Destina-se a gerentes de TI, arquitetos de rede e CTOs de hotéis, redes de varejo, estádios, centros de convenções e organizações do setor público que precisam ir além das chaves pré-compartilhadas e implementar a autenticação 802.1X EAP-TLS escalável e baseada em identidade. A plataforma de sobreposição em nuvem da Purple, independente de hardware, integra-se diretamente a essa arquitetura, fornecendo a camada de WiFi para convidados e BYOD que opera em conjunto com a rede de funcionários autenticada por certificado.

Ler o guia →

O Guia Corporativo para SCEP: Implantando o Simple Certificate Enrollment Protocol para Segurança Automatizada de WiFi em Campus

Este guia de referência técnica fornece um modelo arquitetônico definitivo e uma estratégia de implementação passo a passo para a implantação de certificados WiFi corporativos usando SCEP. Ele aborda as diferenças críticas entre SCEP e PKCS, a sequência exata de implantação necessária para o sucesso e estratégias reais de mitigação de riscos para líderes de TI.

Ler o guia →

Como implementar SCEP para registro automatizado de certificados WiFi

Este guia explica como implementar o SCEP (Simple Certificate Enrollment Protocol) para registro automatizado de certificados WiFi em locais corporativos. Ele abrange o projeto arquitetônico completo - desde o design de PKI e integração com MDM até a sequência obrigatória de implantação em três etapas - e mostra aos gerentes de TI e arquitetos de rede como eliminar credenciais compartilhadas, automatizar o gerenciamento do ciclo de vida dos certificados e atender aos requisitos do PCI DSS e GDPR em escala.

Ler o guia →