Entendendo o Cisco SUDI: Identidade de Dispositivo Baseada em Hardware no Controle de Acesso à Rede

Entendendo o Cisco SUDI: Identidade de Dispositivo Baseada em Hardware no Controle de Acesso à Rede Um Informativo Técnico da Purple - Script Completo do Podcast (aprox. 10 minutos) --- SEGMENTO 1: INTRODUÇÃO E CONTEXTO (aprox. 1 minuto) Olá e boas-vindas a um informativo técnico da Purple. Vou passar os próximos dez minutos apresentando 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 escala. Este conteúdo é voltado para arquitetos de rede, gerentes de TI e CTOs em estabelecimentos - hotéis, complexos de varejo, estádios, centros de convenções - em qualquer lugar onde você opere WiFi corporativo e precise ter certeza de que o hardware em sua rede é exatamente o que afirma ser. Vamos começar com o problema que o SUDI resolve. Em qualquer grande rede de estabelecimento, 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? Esse é o espaço que o SUDI preenche. --- SEGMENTO 2: MERGULHO TÉCNICO PROFUNDO (aprox. 5 minutos) SUDI significa Secure Unique Device Identifier. Trata-se de 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 servidor, ele é emitido para um hardware específico 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 chave pública da Cisco. Aqui está o que torna o SUDI diferente 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 de 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 Initial Device Identifier, ou IDevID. O SUDI da Cisco é exatamente isso - um IDevID que a Cisco instala de fábrica. Você pode complementá-lo com um Locally Significant Device Identifier, ou LDevID, que sua própria PKI emite para políticas de autorização locais. Agora, como isso se integra 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 switch ou ponto de acesso Cisco fica ativo, ele pode apresentar seu certificado SUDI a um servidor RADIUS - normalmente 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 desvio 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, isso importa por três razões. 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 pode apresentar um SUDI válido. Segundo, permite o provisionamento automatizado Zero Touch - um novo dispositivo é enviado para o 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, ele fornece uma trilha de auditoria criptograficamente verificável. Cada dispositivo que se autenticou em sua rede fez isso com um certificado que prova que é 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 todo o resto 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 de hardware por impressão digital. Vale a pena notar esse último ponto - a Cisco identifica os componentes de hardware críticos de um dispositivo na fabricação e armazena essa impressão digital no TAm. Quando o dispositivo inicializa, ele verifica a impressão digital do hardware observada em relação àquela armazenada. Se não coincidirem, o dispositivo não inicializa. Isso detecta a violação de hardware em trânsito - uma preocupação real para implantações em grandes locais onde o hardware pode passar por várias mãos antes da instalação. Um problema operacional que você precisa ter em mente: 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 a implementação prática. Se você está implantando a autenticação baseada em SUDI em um ambiente físico, esta é a sequência que funciona. Comece com a 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 que 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 armazenamento confiável 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 de convidados são diferentes e devem estar em conjuntos de políticas diferentes no ISE. Para novas implantações, ative 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, os problemas comuns. O mais frequente que vejo é misturar a autenticação SUDI com o desvio de endereço MAC na mesma porta. Se você retornar 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 sem SUDI vão para uma VLAN de quarentena aguardando revisão manual. O segundo problema comum é a expiração do certificado. Configure o monitoramento para as datas de expiração do SUDI em todo o seu parque tecnológico agora. Não espere por uma interrupção de serviço para descobrir que seus pontos de acesso não conseguem mais se autenticar. A plataforma da Purple se integra com Cisco Meraki e outros fornecedores de hardware para exibir sinais de integridade dos dispositivos - incluindo o status de autenticação - em um único painel, o que torna esse tipo de monitoramento proativo prático em escala. O terceiro problema comum é o desvio de escopo. O SUDI autentica o dispositivo de hardware. Ele não autentica o usuário que se conecta através 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 o tráfego de convidados e da análise de dados, enquanto o SUDI cuida da camada de infraestrutura subjacente. - SEGMENTO 4: PERGUNTAS E RESPOSTAS RÁPIDAS (aprox. 1 minuto) Deixe-me passar por 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 restante. 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 tem um equivalente chamado certificados de provisionamento IAP. A Ruckus e a Juniper Mist têm seus próprios mecanismos de identidade de dispositivos. O padrão subjacente - IEEE 802.1AR - é neutro em relação ao fabricante, mas cada fabricante o implementa 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 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 para o SUDI-2099 é importante. - - - SEGMENTO 5: RESUMO E PRÓXIMOS PASSOS (aprox. 1 minuto) Para concluir: 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 IEEE 802.1X e uma política RADIUS bem configurada, ele elimina o risco de dispositivos não autorizados e permite o provisionamento automatizado em escala. Suas três ações imediatas: uma, audite seus ativos Cisco para verificar as datas de expiração do SUDI usando show crypto pki certificate. Duas, importe a CA raiz da Cisco para o seu repositório de confiança RADIUS e configure políticas EAP-TLS para dispositivos de infraestrutura. Três, separe 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 o Purple se integra com o 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. Nos vemos no próximo briefing. - - - FIM DO ROTEIRO