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 ENQUADRAMENTO (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 é realmente, como se enquadra na sua arquitetura de controlo de acesso à rede e o que precisa de fazer a esse respeito se gere infraestruturas Cisco em grande escala. Isto destina-se a arquitetos de rede, gestores de TI e CTOs de grandes espaços - hotéis, complexos comerciais, estádios, centros de conferências - qualquer local onde opere 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 grande rede de um espaço, existem dezenas ou centenas de pontos de acesso, switches e controladores. A questão de que 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 tenha sido 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. Trata-se de 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 servidor, é emitido para um componente de hardware específico durante o fabrico. Contém o identificador de produto e o número de série do dispositivo e está ancorado na própria infraestrutura de chaves públicas da Cisco. Eis o que diferencia o SUDI de um certificado de software que instalaria por si mesmo. O certificado SUDI, juntamente com o seu par de chaves associado, reside no interior de um chip resistente a adulterações chamado Trust Anchor module, 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 do hardware. O SUDI é a implementação da Cisco do padrão IEEE 802.1AR - a norma do setor para Secure Device Identifiers, ou DevIDs. Ao abrigo da norma 802.1AR, a credencial instalada pelo fabricante chama-se 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 acesso à rede? O ponto de integração mais comum é o IEEE 802.1X - o padrão de controlo de acesso à rede baseado em portas. Quando um ponto de acesso ou switch Cisco entra online, pode apresentar o seu certificado SUDI a um servidor RADIUS - tipicamente 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 local, isto é importante por três razões. Primeiro, elimina o risco de pontos de acesso falsos se juntarem à sua rede. Um dispositivo contrafeito ou não autorizado simplesmente não consegue apresentar um SUDI válido. Segundo, permite o aprovisionamento automatizado Zero Touch - um novo dispositivo é enviado para o seu local, liga-se, apresenta o seu SUDI e o seu sistema de gestão verifica-o em relação ao seu inventário antes de enviar a configuração. Sem intervenção manual. Terceiro, oferece-lhe um registo de auditoria criptograficamente verificável. Cada dispositivo que se autenticou na sua rede fê-lo com um certificado que prova que é um produto Cisco específico e nomeado. Permitam-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 geração de números aleatórios, e identificação digital de hardware (fingerprinting). Este último ponto merece destaque - a Cisco regista a impressão digital dos componentes de hardware críticos de um dispositivo na altura do fabrico e armazena essa impressão digital no TAm. Quando o dispositivo arranca, compara a impressão digital do hardware observada com a 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 locais onde o hardware pode passar por várias mãos antes da instalação. Um problema operacional que deve ter em conta: 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 esta questão 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 ERROS COMUNS (aprox. 2 minutos) Deixe-me dar-lhe a imagem da implementação prática. Se está a implementar a autenticação baseada em SUDI num ambiente de espaço físico, 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 AC externa funcionará. Precisa de importar a AC raiz da Cisco e os certificados da AC ACT2 SUDI para o armazenamento de fidedignidade do seu RADIUS. Estes estão disponíveis publicamente 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 esta da sua política de autenticação de utilizador final - os fluxos de autenticação de funcionários e de 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 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 a exclusão 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 sem SUDI vão para uma VLAN de quarentena a aguardar revisão manual. A segunda armadilha é a expiração do certificado. Configure já a monitorização das datas de expiração do SUDI em todo o seu parque de dispositivos. Não espere por uma interrupção do 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 do â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 reside 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, 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 dispositivo. A norma subjacente - IEEE 802.1AR - é neutra em termos de fornecedor, mas cada fabricante implementa-a de forma diferente. O que acontece quando um certificado SUDI expira? Os serviços que dependem de SUDI para autenticação - HTTPS, SSH com autenticação de certificado, Zero Touch Provisioning - irão falhar. O próprio dispositivo continua a funcionar, mas já não consegue provar a sua identidade criptograficamente. É por isso que a migraçã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 IEEE 802.1X e uma política RADIUS bem configurada, elimina o risco de dispositivos não autorizados e permite o aprovisionamento automatizado em escala. As suas três ações imediatas: primeiro, audite o seu parque de equipamentos Cisco para verificar as datas de expiração de SUDI usando o comando "show crypto pki certificate". Segundo, importe a root CA da Cisco para o seu repositório de confiança 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 utilizador final - servem propósitos diferentes e devem ser geridas de forma independente. Se quiser aprofundar como o 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 com ligação abaixo deste episódio. Obrigado por ouvir. Vemo-nos no próximo briefing. --- FIM DO SCRIPT