Automatizar a Revogação de Certificados com OCSP e CRL num Ambiente NAC

Automatizar a Revogação de Certificados com OCSP e CRL num Ambiente NAC Uma Sessão Técnica da Purple — Aproximadamente 10 Minutos --- INTRODUÇÃO E ENQUADRAMENTO — aproximadamente 1 minuto Bem-vindo à série de Sessões Técnicas da Purple. Sou o vosso anfitrião e hoje vamos analisar a mecânica da automatização da revogação de certificados — especificamente como o OCSP e a CRL funcionam dentro de um ambiente de Controlo de Acesso à Rede (NAC), e por que razão acertar nisto é uma das decisões de segurança mais negligenciadas nas implementações de WiFi empresariais. Se gere uma cadeia de hotéis, uma rede de retalho, um estádio ou uma rede do setor público com centenas ou milhares de dispositivos ligados, a gestão do ciclo de vida dos certificados não é um extra opcional. É a diferença entre uma rede que aplica políticas em tempo real e outra que alberga silenciosamente credenciais revogadas de dispositivos que deveriam ter sido desligados há semanas. Iremos abordar a arquitetura técnica, analisar dois cenários reais de implementação e terminar com as perguntas que a sua equipa deve fazer antes de avançar para qualquer implementação em produção. Vamos a isso. --- ANÁLISE TÉCNICA DETALHADA — aproximadamente 5 minutos Primeiro, vamos estabelecer o problema que estamos a resolver. Em qualquer rede autenticada por IEEE 802.1X — que é a norma subjacente ao WiFi empresarial, ao NAC com fios e à maioria das arquiteturas modernas de acesso de convidados —, os dispositivos autenticam-se utilizando credenciais ou certificados. Os certificados são preferíveis porque não dependem de segredos partilhados, estão vinculados ao dispositivo e integram-se perfeitamente com plataformas MDM através de protocolos como o SCEP. Mas os certificados têm um ciclo de vida. Expiram, são comprometidos e os dispositivos são desativados. Quando qualquer uma destas coisas acontece, precisa de um mecanismo para dizer à sua infraestrutura de rede: este certificado já não é válido, pare de confiar nele. Esse mecanismo apresenta-se em duas vertentes: CRL, que significa Lista de Revogação de Certificados, e OCSP, que significa Protocolo de Estado de Certificados Online. Comecemos pela CRL. Uma Lista de Revogação de Certificados é exatamente o que parece — uma lista assinada, publicada pela sua Autoridade de Certificação (CA), de todos os números de série de certificados que foram revogados. A sua infraestrutura NAC — normalmente um servidor RADIUS como o FreeRADIUS, Cisco ISE ou Aruba ClearPass — transfere esta lista periodicamente a partir 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. Assim que a lista é transferida, a verificação de revogação funciona mesmo que a sua CA esteja inacessível. A desvantagem é a latência. Se revogar um certificado às 9:00 e o seu intervalo de atualização da CRL for de 24 horas, esse dispositivo poderá continuar a autenticar-se até à próxima transferência agendada. Num ambiente de alta segurança — um hospital, o back office de serviços financeiros, uma rede governamental —, essa janela de tempo é inaceitável. O OCSP resolve o problema da latência. Em vez de manter uma lista local em cache, o seu servidor RADIUS envia uma consulta em tempo real a um OCSP Responder — um serviço que se posiciona à frente da sua CA — para cada certificado que precisa de validar. O responder devolve uma de três respostas: Good, Revoked ou Unknown. Toda a troca ocorre inline, durante o handshake EAP-TLS, normalmente em menos de 100 milissegundos numa infraestrutura bem dimensionada. A contrapartida do OCSP é a dependência da disponibilidade. Se o seu OCSP Responder ficar indisponível, ou se o seu servidor RADIUS não o conseguir alcançar devido a uma partição de rede, terá de tomar uma decisão de política: opta por fail open — permitindo que a autenticação prossiga — ou por fail closed — negando o acesso até que o responder esteja alcançável? O fail open mantém o tempo de atividade, mas cria uma lacuna de segurança. O fail closed mantém a postura de segurança, mas pode bloquear utilizadores legítimos durante um incidente de infraestrutura. Existe uma terceira opção que vale a pena conhecer: o OCSP Stapling. Neste modelo, o titular do certificado — o dispositivo cliente — obtém periodicamente uma resposta OCSP assinada do responder e anexa-a ao handshake TLS. O servidor RADIUS valida a resposta anexada (stapled) em vez de efetuar a sua própria consulta OCSP. Isto reduz a carga no OCSP Responder, elimina a preocupação de privacidade de expor números de série de certificados a um serviço externo e melhora a resiliência. A desvantagem é que nem todos os suplicantes EAP suportam stapling, pelo que precisa de verificar a compatibilidade do cliente antes de depender dele. Agora, como é que isto se enquadra numa arquitetura NAC? O seu motor de políticas NAC — seja o Cisco ISE, Aruba ClearPass, Juniper Mist ou uma stack open-source baseada em FreeRADIUS e PacketFence — posiciona-se entre o suplicante e a rede. Quando um dispositivo tenta ligar-se, o servidor RADIUS recebe o Access-Request, realiza a negociação EAP-TLS, valida a cadeia de certificados do cliente, verifica o estado 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 componente de automatização entra em ação a dois níveis. Primeiro, na camada de emissão de certificados: a sua plataforma MDM — Jamf, Intune, Workspace ONE — utiliza SCEP para fornecer automaticamente certificados a dispositivos geridos. Quando um dispositivo é desassociado 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: o seu servidor RADIUS está configurado para consultar o OCSP ou atualizar o seu cache de CRL num agendamento definido, garantindo que as decisões de revogação se propagam 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. Numa implementação bem concebida, 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 deteta a alteração — imediatamente via OCSP ou na janela seguinte de atualização da CRL — e o acesso do dispositivo é recusado na sua próxima tentativa de autenticação. --- RECOMENDAÇÕES DE IMPLEMENTAÇÃO E ERROS COMUNS — aproximadamente 2 minutos Permita-me dar-lhe a orientação prática que evita que as implementações corram mal. Primeiro: defina a sua tolerância à latência de revogação antes de escolher o seu mecanismo. Se estiver a gerir uma rede WiFi para hóspedes de um hotel onde o principal risco é um dispositivo de funcionário desativado, um intervalo de atualização da CRL de 4 horas é provavelmente adequado. Se estiver a gerir uma rede de saúde onde um dispositivo comprometido pode aceder a dados de pacientes, vai querer 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. Implemente no mínimo dois, atrás de um balanceador de carga, com monitorização de integridade. Uma interrupção do OCSP Responder que cause um comportamento de fail-closed gerará pedidos de suporte mais rapidamente do que quase qualquer outra falha de infraestrutura. Terceiro: preste atenção ao tamanho da sua CRL. Em grandes implementações — estamos a falar de dezenas de milhares de certificados — os ficheiros CRL podem crescer para vários megabytes. Um servidor RADIUS a descarregar uma CRL de 5MB a cada hora através de uma ligação WAN é um problema de largura de banda prestes a acontecer. Considere delta CRLs, que contêm apenas as alterações desde a última CRL completa, ou migre para OCSP para ambientes de alto volume. Quarto: teste o 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 a sua monitorização não detetar um OCSP Responder avariado, o seu mecanismo de revogação é apenas teatro. Quinto: alinhe os períodos de validade dos seus certificados com a 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 se está a mover, e vale a pena avaliar para novas implementações. --- PERGUNTAS E RESPOSTAS RÁPIDAS — aproximadamente 1 minuto Pergunta: Posso utilizar OCSP e CRL em simultâneo? Sim. A maioria das implementações RADIUS suporta uma cadeia de fallback: tenta primeiro o OCSP, recorrendo à CRL se o responder estiver inacessível. Isto proporciona-lhe uma verificação em tempo real em condições normais e resiliência offline durante interrupções. Pergunta: A plataforma de guest WiFi da Purple integra-se com NAC baseado em certificados? A plataforma da Purple opera na camada de acesso de convidados, gerindo a autenticação do Captive Portal, a captura de dados e a análise analítica. Para redes de colaboradores empresariais que executam 802.1X com autenticação por certificado, a Purple integra-se com a infraestrutura de rede subjacente — os pontos de acesso, controladores e servidores RADIUS — em vez de substituir a pilha de gestão de certificados. As redes de convidados e de colaboradores são normalmente segmentadas, com diferentes mecanismos de autenticação apropriados para cada uma. Pergunta: Qual é a perspetiva de conformidade? O PCI DSS 4.0 exige que o acesso a ambientes de dados de titulares de cartões utilize autenticação forte. O GDPR exige medidas técnicas adequadas para proteger os dados pessoais. Ambos os enquadramentos são satisfeitos pelo 802.1X baseado em certificados com revogação automatizada — desde que consiga demonstrar que a revogação é oportuna e testada. O seu registo de auditoria precisa de 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 num ambiente NAC é um problema de três camadas. Precisa de uma CA que suporte gatilhos de revogação automatizados, de um OCSP Responder ou CRL Distribution Point que seja altamente disponível e devidamente dimensionado, e de um servidor RADIUS configurado para aplicar o estado de revogação como parte da 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 do seu ambiente, da topologia de rede e da maturidade operacional. Se está a construir ou a rever uma implementação de NAC e deseja compreender como a plataforma de WiFi de convidados e analítica da Purple se enquadra na arquitetura de rede mais ampla, as ligações nas notas do programa irão direcioná-lo para os guias técnicos relevantes. Obrigado por ouvir. Vemo-nos no próximo briefing. --- FIM DO SCRIPT