Compreender o Cisco SUDI: Identidade Ancorada em Hardware no Controlo de Acesso Seguro à Rede

Fale em inglês britânico com um tom confiante, autoritário e de conversa - como se fosse um consultor sénior de segurança de rede a dar instruções a um cliente durante um almoço de trabalho. Ritmo medido, articulação clara, ocasional humor seco. Não é uma palestra. Não é um discurso de vendas. Uma sessão técnica peer-to-peer: Bem-vindo à série de sessões técnicas da Purple. Sou o vosso anfitrião e hoje vamos falar sobre algo que surge frequentemente em implementações de redes empresariais - o Cisco SUDI. Ou seja, o Secure Unique Device Identifier. Se tem andado à procura de uma resposta direta sobre o que isto realmente faz, como se enquadra na autenticação 802.1X e se é relevante para a sua rede de campus ou local, [curta pausa] está no sítio certo. Comecemos pelo problema central. A maioria das redes empresariais ainda depende de endereços MAC para identificar dispositivos. O MAC Authentication Bypass - ou MAB - está em todo o lado. O problema é que os endereços MAC são facilmente falsificáveis. Um atacante com um portátil e quinze minutos consegue clonar o endereço MAC de um ponto de acesso fidedigno e entrar diretamente na sua rede. Isto não é um risco teórico. É um vetor de ataque documentado, e é algo que o PCI-DSS 4.0 assinala especificamente como inadequado para ambientes de dados de titulares de cartões. Portanto, a questão passa a ser: como prova que um dispositivo é o que afirma ser? Não apenas "tem o endereço MAC correto" - mas provar genuína e criptograficamente. É aí que entra o SUDI. [curta pausa] O Secure Unique Device Identifier da Cisco é um certificado X.509 versão 3, gravado no módulo Trust Anchor do dispositivo - o chip TAm - durante o fabrico. O certificado contém o identificador do produto e o número de série, e está encadeado à Autoridade de Certificação raiz pública da Cisco. A chave privada é gerada dentro do chip TAm e nunca é exportada. Nunca. Não a consegue clonar. Não a consegue falsificar. A identidade está fisicamente ligada ao silício. Isto torna o SUDI numa implementação do IEEE 802.1AR - a norma para Secure Device Identifiers. Na terminologia 802.1AR, o SUDI é um IDevID - um Initial Device Identifier. É a identidade instalada de fábrica que prova que o dispositivo é um produto Cisco genuíno, fabricado numa instalação conhecida, com um número de série conhecido. Agora, porque é que isto importa na prática? Vamos analisar o fluxo de autenticação. Quando um dispositivo Cisco - por exemplo, um switch Catalyst ou um ponto de acesso Meraki - se liga à sua rede, pode funcionar como um suplicante 802.1X. Apresenta o seu certificado SUDI ao autenticador da rede, normalmente uma porta de switch ou controlador sem fios. O autenticador reencaminha essa credencial para um servidor RADIUS - o Cisco ISE é a escolha mais comum aqui, mas qualquer servidor RADIUS em conformidade com a RFC 2865 funciona. O servidor RADIUS valida a cadeia de certificados até à CA raiz da Cisco. Se a cadeia for válida, o dispositivo é genuíno. O acesso é concedido e a VLAN apropriada é atribuída. Todo o intercâmbio utiliza EAP-TLS - Extensible Authentication Protocol com Transport Layer Security - que é a variante de autenticação mútua. Tanto o dispositivo como a rede se autenticam mutuamente. Sem palavras-passe. Sem segredos partilhados. Sem endereços MAC. Apenas prova criptográfica. [short pause] Vamos falar sobre Zero Touch Provisioning, porque é aqui que o SUDI se torna genuinamente útil para grandes implementações. Imagine que está a implementar 200 pontos de acesso numa cadeia de hotéis, ou a instalar infraestrutura de rede em 40 locais de retalho. Tradicionalmente, isso significa um técnico em cada local, a configurar manualmente cada dispositivo. Com o ZTP baseado em SUDI, o dispositivo arranca, apresenta a sua identidade SUDI a um servidor de aprovisionamento, o servidor valida o certificado, confirma o número de série em relação ao seu inventário e envia a configuração correta - encriptada, para que apenas aquele dispositivo específico a possa desencriptar. O trabalho do técnico passa a ser apenas a instalação física. A rede trata do resto. Para operadores de hotelaria e retalho, isso representa uma poupança operacional significativa. O Premier Inn, por exemplo, opera centenas de propriedades. A capacidade de enviar hardware pré-configurado para um local e fazer com que ele se autoconfigure contra uma identidade conhecida é a diferença entre uma visita de comissionamento de dois dias e uma de duas horas. [short pause] Agora vamos entrar no ciclo de vida do certificado, porque é aqui que as equipas às vezes são apanhadas desprevenidas. Os certificados SUDI originais foram emitidos com um período de validade de dez anos a partir da data de fabrico, limitado a 14 de maio de 2029. A Cisco emitiu avisos de campo - FN 72094 e FN 72105 - que abrangem os produtos afetados. Os dispositivos fabricados após maio de 2019 têm uma janela inferior a dez anos. Quando o SUDI expira, as funcionalidades que dependem dele para TLS - interfaces de gestão HTTPS, autenticação de certificados SSH, ZTP - podem deixar de funcionar. O dispositivo em si continua a funcionar; não vai avariar permanentemente. Mas esses serviços autenticados específicos deixam de funcionar. A resposta da Cisco foi introduzir certificados SUDI-2099 em hardware mais recente, válidos até dezembro de 2099. Se estiver a adquirir infraestrutura Cisco hoje, está a obter o SUDI-2099. Se tiver equipamento mais antigo no terreno, verifique as datas de expiração com "show crypto pki certificates" no IOS ou IOS-XE. Planeie o seu ciclo de atualização em conformidade. [short pause] Certo, recomendações de implementação. Três coisas que diria a qualquer gestor de TI que esteja a implementar a autenticação baseada em SUDI. Primeiro: construa a sua política RADIUS em torno dos atributos do certificado, e não apenas da cadeia de certificados. Valide o Subject CN em relação ao seu inventário de dispositivos. Um certificado Cisco válido prova que o dispositivo é hardware Cisco genuíno - não prova que é o dispositivo específico que encomendou para aquele local. Cruze a informação do número de série na sua política de autorização RADIUS. Segundo: execute o SUDI paralelamente à sua política MAB existente, e não em vez dela, durante a migração. Utilize o profiling do Cisco ISE para identificar quais os dispositivos que suportam 802.1AR e mova-os progressivamente para a autenticação baseada em certificados. Os dispositivos IoT legados - câmaras, controladores HVAC, leitores de cartões - muitas vezes não conseguem de todo realizar 802.1X. O MAB continua a ser a alternativa de recurso para esses casos. O objetivo é eliminar primeiro o MAB nos dispositivos de infraestrutura, onde o risco é mais elevado. Terceiro: documente as datas de expiração dos seus certificados na sua CMDB. Isto parece óbvio, mas é o tipo de detalhe que costuma apanhar as equipas de surpresa. Um switch que deixa de aceitar ligações de gestão HTTPS porque o seu SUDI expirou não é um incidente agradável de diagnosticar às duas da manhã. [curta pausa] Perguntas rápidas. Vou dar-lhe as respostas curtas. O SUDI substitui o 802.1X? Não. O SUDI é a credencial. O 802.1X é a estrutura de autenticação. O SUDI é o que apresenta durante uma troca 802.1X. Posso utilizar o SUDI com servidores RADIUS que não sejam da Cisco? Sim. Qualquer servidor RADIUS que suporte EAP-TLS e consiga validar uma cadeia de certificados X.509 pode funcionar com o SUDI. Precisa de importar o certificado CA raiz da Cisco para o repositório fidedigno do seu servidor RADIUS. O Cisco Meraki suporta SUDI? Sim, para autenticação de infraestrutura. Os pontos de acesso Meraki utilizam a sua própria variante de certificados instalados pelo fabricante para a autenticação do controlador de nuvem. O painel Meraki foi atualizado para gerir a expiração do SUDI antes do prazo de 2026. E quanto ao Purple WiFi? O Purple funciona como uma sobreposição na nuvem sobre a sua infraestrutura existente - Cisco Meraki, HPE Aruba, Ruckus e outros. A camada de Identity-Based Networks do Purple situa-se acima do plano de autenticação de hardware. O SUDI protege os próprios dispositivos de infraestrutura. O Purple protege a camada de identidade de visitantes e funcionários no topo. Os dois são complementares e não concorrentes. [curta pausa] Para concluir. O Cisco SUDI proporciona-lhe uma identidade de dispositivo ancorada em hardware e criptograficamente verificável. Elimina o spoofing de MAC como vetor de ataque para dispositivos de infraestrutura. Permite o Zero Touch Provisioning em escala. Alinha-se com os requisitos de controlo do IEEE 802.1AR, PCI-DSS 4.0 e ISO 27001. E integra-se de forma limpa com qualquer infraestrutura RADIUS compatível com 802.1X e EAP-TLS. Os próximos passos práticos: audite o inventário de dispositivos Cisco para verificar as datas de expiração dos certificados SUDI, identifique quais os dispositivos a correr MAB que poderiam ser migrados para a autenticação baseada em certificados e reveja a sua política RADIUS para adicionar a validação do número de série juntamente com as verificações da cadeia de confiança. Se está a correr o Purple nos seus espaços, a nossa equipa pode explicar-lhe como o Identity-Based Networks se mapeia na sua infraestrutura Cisco existente. O link está nas notas do programa. Obrigado por ouvir. Até à próxima.