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 Bem-vindo à série de Informativos Técnicos da Purple. Sou o seu anfitrião e hoje vamos nos aprofundar na mecânica da automatização da revogação de certificados — especificamente como o OCSP e a 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, uma rede 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 é um recurso opcional. É 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 terminaremos com as perguntas que sua equipe deve fazer antes de chegar perto de uma implantação em produção. Vamos começar. --- APROFUNDAMENTO TÉCNICO — aproximadamente 5 minutos Primeiro, vamos estabelecer 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 convidados —, 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 o SCEP. Mas os certificados têm 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 dizer à sua infraestrutura de rede: este certificado não é mais válido, pare de confiar nele. Esse mecanismo vem em duas variantes: 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 parece — uma lista assinada, publicada pela sua Autoridade Certificadora (CA), de cada número de série de 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 verifica os números de série dos certificados recebidos em relação a 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, um back office de serviços financeiros, uma rede governamental —, essa janela de tempo é 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: Good (Bom), Revoked (Revogado) ou Unknown (Desconhecido). Toda a troca ocorre 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á que tomar uma decisão de política: você opta pelo fail open — permitindo que a autenticação prossiga — ou pelo fail closed — negando o acesso até que o responder esteja acessível? O fail open mantém o tempo de atividade, mas cria uma brecha de segurança. O fail closed 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. Nesse 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 números de série dos certificados a um serviço externo e melhora a resiliência. O ponto negativo é que nem todos os suplicantes EAP suportam o stapling, portanto, você precisa verificar a compatibilidade do cliente antes de depender dele. Agora, como isso se encaixa em uma arquitetura NAC? O 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 de 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 de integração crítico 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 — imediatamente via OCSP ou dentro da próxima janela de atualização da CRL — e o acesso do dispositivo é negado em sua próxima tentativa de autenticação. --- RECOMENDAÇÕES DE IMPLANTAÇÃO E ARMADILHAS — 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 hóspedes de hotel onde o risco principal é um dispositivo de funcionário desativado, um intervalo de atualização de CRL de 4 horas provavelmente é adequado. 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 de fail-closed gerará chamados de suporte mais rápido do que quase qualquer outra falha de infraestrutura. Terceiro: preste atenção 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 5MB a cada hora através de um link WAN é um problema de taxa de transferência prestes a acontecer. Considere delta CRLs, 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 presumir 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 teatro. Quinto: alinhe os períodos de validade dos seus certificados com sua estratégia de revogação. Certificados de curta duração — 24 a 72 horas — reduzem a janela de exposição para credenciais comprometidas e podem reduzir totalmente a sua dependência da infraestrutura de revogação. Esta é 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: tenta o OCSP primeiro, recorre à 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 guest WiFi da Purple se integra com NAC baseado em certificado? A plataforma da Purple opera na camada de acesso de visitantes, lidando com a autenticação do Captive Portal, captura de dados e analytics. Para redes corporativas de funcionários que executam 802.1X com autenticação por certificado, a Purple se integra à infraestrutura de rede subjacente — os pontos de acesso, controladores 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 é a perspectiva de conformidade? O PCI DSS 4.0 exige que o acesso aos 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 que seja 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 ao risco que deve ser tomada no contexto dos requisitos de segurança, topologia de rede e maturidade operacional do seu ambiente. Se você está construindo ou revisando uma implantação de NAC e deseja entender como a plataforma de guest WiFi 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