Automatizando a Revogação de Certificados com OCSP e CRL em um Ambiente NAC

Automatizando a Revogação de Certificados com OCSP e CRL em um Ambiente NAC Um Informativo Técnico da Purple - Aproximadamente 10 Minutos --- INTRODUÇÃO E CONTEXTO - aproximadamente 1 minuto Boas-vindas à série de Informativos Técnicos da Purple. Sou o seu anfitrião e hoje vamos nos aprofundar nos mecanismos de automação de revogação de certificados - especificamente como OCSP e CRL funcionam dentro de um ambiente de Controle de Acesso à Rede (NAC), e por que acertar nisso é uma das decisões de segurança mais negligenciadas em implantações de WiFi corporativo. Se você gerencia uma rede de hotéis, propriedades de varejo, um estádio ou uma rede do setor público com centenas ou milhares de dispositivos conectados, o gerenciamento do ciclo de vida dos certificados não é apenas algo bom de se ter. É a diferença entre uma rede que aplica políticas em tempo real e outra que abriga silenciosamente credenciais revogadas de dispositivos que deveriam ter sido desconectados semanas atrás. Abordaremos a arquitetura técnica, passaremos por dois cenários reais de implantação e encerraremos com as perguntas que sua equipe deve fazer antes de iniciar qualquer implementação em produção. Vamos começar. --- IMERSÃO TÉCNICA - aproximadamente 5 minutos Primeiro, vamos definir o problema que estamos resolvendo. Em qualquer rede autenticada por IEEE 802.1X - que é o padrão que sustenta o WiFi corporativo, o NAC cabeado e a maioria das arquiteturas modernas de acesso de visitantes - os dispositivos se autenticam usando credenciais ou certificados. Os certificados são preferíveis porque não dependem de segredos compartilhados, são vinculados ao dispositivo e se integram perfeitamente com plataformas MDM por meio de protocolos como SCEP. Mas os certificados possuem um ciclo de vida. Eles expiram, são comprometidos e os dispositivos são desativados. Quando qualquer uma dessas coisas acontece, você precisa de um mecanismo para informar à sua infraestrutura de rede: este certificado não é mais válido, pare de confiar nele. Esse mecanismo se apresenta de duas formas: CRL, que significa Lista de Revogação de Certificados, e OCSP, que significa Protocolo de Status de Certificado Online. Vamos começar com a CRL. Uma Lista de Revogação de Certificados é exatamente o que o nome sugere - uma lista assinada, publicada pela sua Autoridade Certificadora (CA), contendo o número de série de cada certificado que foi revogado. Sua infraestrutura NAC - normalmente um servidor RADIUS como FreeRADIUS, Cisco ISE ou Aruba ClearPass - baixa essa lista periodicamente de um Ponto de Distribuição de CRL, que é apenas um endpoint HTTP ou LDAP. O servidor RADIUS armazena a lista localmente em cache e compara os números de série dos certificados recebidos com ela durante o handshake EAP-TLS. A vantagem operacional da CRL é a simplicidade e a resiliência offline. Uma vez baixada a lista, a verificação de revogação funciona mesmo se a sua CA estiver inacessível. A desvantagem é a latência. Se você revogar um certificado às 9h e o intervalo de atualização da sua CRL for de 24 horas, esse dispositivo ainda poderá se autenticar até o próximo download programado. Em um ambiente de alta segurança - um hospital, o back office de serviços financeiros, uma rede governamental - essa janela de vulnerabilidade é inaceitável. O OCSP resolve o problema de latência. Em vez de manter uma lista local em cache, seu servidor RADIUS envia uma consulta em tempo real para um OCSP Responder - um serviço que fica à frente da sua CA - para cada certificado que precisa validar. O responder retorna uma de três respostas: Bom, Revogado ou Desconhecido. Toda a troca acontece inline, durante o handshake EAP-TLS, normalmente em menos de 100 milissegundos em uma infraestrutura bem dimensionada. A desvantagem do OCSP é a dependência de disponibilidade. Se o seu OCSP Responder ficar indisponível, ou se o seu servidor RADIUS não conseguir alcançá-lo devido a uma partição de rede, você terá uma decisão de política a tomar: você falha aberto - permitindo que a autenticação prossiga - ou falha fechado - negando o acesso até que o responder esteja acessível? Falhar aberto mantém o tempo de atividade, mas cria uma lacuna de segurança. Falhar fechado mantém a postura de segurança, mas pode bloquear usuários legítimos durante um incidente de infraestrutura. Existe uma terceira opção que vale a pena conhecer: o OCSP Stapling. Neste modelo, o portador do certificado - o dispositivo cliente - busca periodicamente uma resposta OCSP assinada do responder e a anexa ao handshake TLS. O servidor RADIUS valida a resposta grampeada (stapled) em vez de fazer sua própria consulta OCSP. Isso reduz a carga no OCSP Responder, elimina a preocupação com a privacidade de expor os seriais dos certificados a um serviço externo e melhora a resiliência. A desvantagem é que nem todos os suplicantes EAP suportam o stapling, por isso você precisa verificar a compatibilidade do cliente antes de confiar nele. Agora, como isso se encaixa em uma arquitetura NAC? Seu mecanismo de política NAC - seja ele Cisco ISE, Aruba ClearPass, Juniper Mist ou uma pilha de código aberto baseada em FreeRADIUS e PacketFence - fica entre o suplicante e a rede. Quando um dispositivo tenta se conectar, o servidor RADIUS recebe o Access-Request, realiza a negociação EAP-TLS, valida a cadeia de certificados do cliente, verifica o status de revogação via OCSP ou CRL e, em seguida, emite um Access-Accept com uma atribuição de VLAN ou um Access-Reject. A parte de automação entra em dois níveis. Primeiro, na camada de emissão de certificados: sua plataforma MDM - Jamf, Intune, Workspace ONE - usa SCEP para provisionar automaticamente certificados para dispositivos gerenciados. Quando um dispositivo é desvinculado ou desativado, o MDM aciona uma chamada de revogação para a CA, que atualiza a CRL e notifica o OCSP Responder. Segundo, na camada de aplicação do NAC: seu servidor RADIUS é configurado para consultar o OCSP ou atualizar seu cache de CRL em um cronograma definido, garantindo que as decisões de revogação se propaguem para a política de acesso sem intervenção manual. O ponto crítico de integração aqui é o pipeline de comunicação CA para NAC. Em uma implantação bem projetada, a revogação é uma cadeia totalmente automatizada: o MDM desativa o dispositivo, aciona a revogação da CA, a CA atualiza o OCSP Responder e publica uma nova CRL, o servidor RADIUS detecta a alteração - seja imediatamente via OCSP ou dentro da próxima janela de atualização da CRL - e o dispositivo tem o acesso negado em sua próxima tentativa de autenticação. --- RECOMENDAÇÕES DE IMPLEMENTAÇÃO E ERROS COMUNS - aproximadamente 2 minutos Deixe-me dar as orientações práticas que evitam que as implantações deem errado. Primeiro: defina sua tolerância de latência de revogação antes de escolher seu mecanismo. Se você estiver operando uma rede WiFi de convidados em um hotel onde o risco primário é um dispositivo de funcionário desativado, um intervalo de atualização de CRL de 4 horas provavelmente é aceitável. Se você estiver operando uma rede de saúde onde um dispositivo comprometido pode acessar dados de pacientes, você precisará de OCSP com política de fail-closed e um cluster de responder altamente disponível. Segundo: não execute um único OCSP Responder em produção. Implante no mínimo dois, atrás de um balanceador de carga, com monitoramento de integridade. Uma interrupção do OCSP Responder que cause um comportamento fail-closed gerará chamados de suporte mais rápido do que quase qualquer outra falha de infraestrutura. Terceiro: fique atento ao tamanho da sua CRL. Em grandes implantações - estamos falando de dezenas de milhares de certificados - os arquivos CRL podem crescer para vários megabytes. Um servidor RADIUS baixando uma CRL de 5 MB a cada hora através de um link WAN é um problema de throughput prestes a acontecer. Considere CRLs delta, que contêm apenas alterações desde a última CRL completa, ou migre para OCSP para ambientes de alto volume. Quarto: teste seu pipeline de revogação regularmente. Não basta configurar o OCSP e assumir que funciona. Automatize um teste mensal: emita um certificado, revogue-o, tente a autenticação, verifique a rejeição. Se o seu monitoramento não detectar um OCSP Responder quebrado, seu mecanismo de revogação é apenas figurativo. Quinto: alinhe os períodos de validade dos seus certificados com sua estratégia de revogação. Certificados de curta duração - de 24 a 72 horas - reduzem a janela de exposição de credenciais comprometidas e podem reduzir totalmente a sua dependência da infraestrutura de revogação. Essa é a direção para a qual o setor está se movendo, e vale a pena avaliar para novas implantações. --- PERGUNTAS E RESPOSTAS RÁPIDAS - aproximadamente 1 minuto Pergunta: Posso usar OCSP e CRL simultaneamente? Sim. A maioria das implementações RADIUS suporta uma cadeia de fallback: tente o OCSP primeiro, mude para a CRL se o responder estiver inacessível. Isso oferece verificação em tempo real sob condições normais e resiliência offline durante interrupções. Pergunta: A plataforma de WiFi de convidados do Purple integra-se com NAC baseado em certificado? A plataforma da Purple opera na camada de acesso de visitantes, lidando com a autenticação de Captive Portal, captura de dados e analytics. Para redes corporativas de funcionários executando 802.1X com autenticação por certificado, a Purple se integra à infraestrutura de rede subjacente - os access points, controladoras e servidores RADIUS - em vez de substituir a pilha de gerenciamento de certificados. As redes de visitantes e de funcionários são normalmente segmentadas, com mecanismos de autenticação diferentes e apropriados para cada uma. Pergunta: Qual é o aspecto de conformidade? O PCI-DSS 4.0 exige que o acesso a ambientes de dados de portadores de cartão utilize autenticação forte. O GDPR exige medidas técnicas adequadas para proteger os dados pessoais. Ambos os frameworks são atendidos pelo 802.1X baseado em certificado com revogação automatizada - desde que você possa demonstrar que a revogação é oportuna e testada. Sua trilha de auditoria precisa mostrar quando os certificados foram revogados e quando essa revogação se propagou para a aplicação na rede. --- RESUMO E PRÓXIMOS PASSOS - aproximadamente 1 minuto Para resumir: automatizar a revogação de certificados em um ambiente NAC é um problema de três camadas. Você precisa de uma CA que suporte gatilhos de revogação automatizados, um OCSP Responder ou CRL Distribution Point altamente disponível e dimensionado corretamente, e um servidor RADIUS configurado para aplicar o status de revogação como parte de sua política de acesso. A escolha entre OCSP e CRL não é binária - é uma decisão de tolerância a riscos que deve ser tomada no contexto dos requisitos de segurança do seu ambiente, da topologia de rede e da maturidade operacional. Se você está criando ou revisando uma implantação de NAC e quer entender como a plataforma de WiFi de visitantes e analytics da Purple se encaixa na arquitetura de rede mais ampla, os links nas notas do programa o levarão aos guias técnicos relevantes. Obrigado por ouvir. Nos vemos no próximo briefing. --- FIM DO ROTEIRO