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

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