Autenticação WiFi baseada em certificados: guia de EAP-TLS
Published
Alguém está a sair da empresa e a sua equipa está a decidir se deve alterar novamente a palavra-passe do WiFi para colaboradores WiFi. Alterá-la significa voltar a ligar portáteis, telemóveis, tablets da receção e equipamentos que já ninguém se lembra de ter configurado. Deixá-la como está significa aceitar que alguém fora da organização ainda sabe como se ligar.
A autenticação WiFi baseada em certificados oferece-lhe uma forma melhor de identificar dispositivos fiáveis. Mas também altera o trabalho que a sua equipa deve realizar: em vez de distribuir palavras-passe, passará a gerir cadeias de confiança, renovação de certificados, revogação e dispositivos que desaparecem em armazém durante meses. A melhoria de segurança é real. O funcionamento fiável exige mais do que selecionar EAP-TLS num perfil sem fios.
Índice
- O que significa a autenticação baseada em certificadosWiFi
- Como funciona o Handshake EAP-TLS passo a passo
- Certificados em comparação com palavras-passe partilhadas e PEAP
- Criação da CA e aprovisionamento de certificados através de MDM
- Gestão do ciclo de vida dos certificados, da emissão à renovação
- Revogação de acessos em caso de perda de dispositivos ou saída de colaboradores
- Elegibilidade dos dispositivos e planeamento de exceções
- Confirme o seu plano de certificados antes da implementação
O que significa a autenticação baseada em WiFi certificados
A autenticação WiFi baseada em certificados substitui uma palavra-passe WiFi partilhada por um certificado digital individual, que a rede verifica antes de conceder acesso. Pense na diferença entre um código de porta de escritório partilhado e um cartão de funcionário. Com o código, todos provam que conhecem o mesmo segredo. Com um cartão, a segurança pode identificar uma credencial específica e cancelá-la de forma independente.
Suponha que um portátil gerido precisa de acesso à rede de colaboradores. O seu certificado identifica o dispositivo ou o utilizador atribuído, e a sua chave privada protegida permite provar que possui essa credencial. O certificado em si não é uma palavra-passe secreta, e copiar apenas o certificado público não fornece a chave privada correspondente.
O diagrama mostra como as credenciais individuais substituem a palavra-passe comum.
Onde os componentes se enquadram
A estrutura subjacente é o IEEE 802.1X, originalmente desenvolvido para Ethernet com fios e adaptado para LANs sem fios. A visão geral da Microsoft sobre a autenticação IEEE 802.1X) descreve a estrutura e o papel da autenticação central através de RADIUS.
O ponto de acesso controla a admissão, enquanto o serviço RADIUS avalia o pedido de autenticação. O EAP-TLS é o método de autenticação baseado em certificados executado através dessa configuração. O dispositivo e o servidor de autenticação validam-se mutuamente antes de estabelecerem o material de chaveamento para a ligação.
Mantenha estes componentes distintos:
- Certificado de dispositivo: Identifica o ponto final ou utilizador e funciona com uma chave privada guardada pelo dispositivo.
- Certificado do servidor de autenticação: Permite que o dispositivo verifique se está a comunicar com um serviço de autenticação aprovado.
- Autoridade de certificação: Emite certificados que cada parte pode validar através de uma cadeia de confiança explicitamente fiável.
O dispositivo e o servidor não precisam necessariamente de certificados da mesma autoridade emissora. O que importa é que cada parte confie no emissor adequado e aplique a política de validação correta.
Regra prática: Trate os certificados como um sistema de identidade de rede e não como palavras-passe complicadas.
Essa distinção altera a forma como lida com um portátil perdido. Pode revogar a respetiva credencial sem substituir as credenciais nos equipamentos de todos os outros. No entanto, a posse de um certificado válido estabelece a identidade, não uma permissão ilimitada. A sua política de acesso ainda precisa de decidir ao que essa identidade pode aceder.
Como funciona o handshake do EAP-TLS passo a passo
Uma ligação envolve o suplicante do dispositivo, o ponto de acesso a atuar como autenticador e o servidor de autenticação. O suplicante é o componente do sistema operativo que trata da autenticação na rede empresarial.
Este fluxo simplificado mostra as principais transferências de controlo, em vez de todas as mensagens de protocolo.
Acompanhe a troca e os seus pontos de falha
A autenticação mútua e a derivação de chaves subjacentes a esta troca estão definidas na especificação EAP-TLS, RFC 5216.
O dispositivo associa-se ao ponto de acesso. Inicia a troca de autenticação empresarial e fornece uma identidade. A associação por si só não concede acesso normal à rede. Uma definição incorreta de segurança sem fios pode impedir o dispositivo de chegar sequer à autenticação por certificado.
O ponto de acesso retransmite as mensagens EAP para RADIUS. Encaminha a troca entre o ponto de extremidade e o serviço de autenticação, em vez de emitir ele próprio o certificado do dispositivo. Um problema de conectividade do RADIUS ou um ponto de acesso registado incorretamente pode interromper a troca nesta fase.
O servidor apresenta o seu certificado. O dispositivo verifica a cadeia de certificados, a validade e a identidade esperada do servidor. Um emissor não fiável, uma cadeia incompleta ou um nome de servidor inesperado devem fazer com que o dispositivo recuse a ligação.
O dispositivo apresenta o seu certificado de cliente. O servidor valida a credencial, verifica as informações de revogação aplicáveis e avalia a identidade. A falta de um certificado ou uma chave privada inacessível podem parecer uma falha genérica de ligação para o utilizador, mesmo quando os registos do servidor mostram uma causa específica.
A troca TLS estabelece material de chave partilhado. O ponto de extremidade deve demonstrar a posse da sua chave privada, e não apenas apresentar um ficheiro de certificado. Definições de criptografia incompatíveis podem impedir a conclusão, mesmo quando ambos os certificados são válidos.
RADIUS devolve o resultado da autenticação e os atributos de política. Uma aceitação pode incluir uma atribuição de VLAN ou outros atributos de autorização suportados. Uma autenticação bem-sucedida seguida de uma ligação inutilizável pode indicar um problema na VLAN ou de política a jusante, e não um problema de certificado.
Configure o cliente para verificar o servidor
No perfil do suplicante, selecione explicitamente EAP-TLS, configure a AC de confiança e especifique os nomes de servidor RADIUS esperados. Mantenha a validação do certificado do servidor ativa. Não permita que os utilizadores ignorem um aviso apenas para ficarem online.
Utilize este vídeo juntamente com o fluxo do protocolo quando discutir a troca com a sua equipa.
Cada ligação depende de as credenciais estarem presentes, acessíveis e aceitáveis no momento da autenticação. A resolução de problemas necessita, portanto, de evidências tanto do suplicante como do RADIUS, e não apenas de um painel do ponto de acesso a mostrar que um cliente não se conseguiu ligar.
Certificados comparados com palavras-passe partilhadas e PEAP
WiFi métodos de autenticação sob os mesmos critérios
| Método | Credencial no dispositivo | Âmbito de revogação | Responsabilização | Esforço de configuração |
|---|---|---|---|---|
| Frase-passe WPA2 partilhada ou WPA3 pessoal | Uma frase-passe conhecida por todos os utilizadores | Altera a chave para todos | Nenhuma a partir da própria credencial partilhada | Baixo |
| WPA2-Enterprise com PEAP-MSCHAPv2 | Nome de utilizador e palavra-passe por utilizador | Desativa uma conta | Por utilizador | Médio |
| EAP-TLS no WPA2 ou WPA3-Enterprise | Certificado de cliente e chave privada exclusivos por dispositivo | Revoga um certificado | Por dispositivo e utilizador quando mapeado | Alto, requer PKI e aprovisionamento gerido |
| WPA3-Enterprise 192 bits com EAP-TLS | Certificado que cumpre os requisitos criptográficos do perfil | Revoga um certificado | Por dispositivo e utilizador quando mapeado | Alto, acrescido de verificações de compatibilidade de cifra |
EAP-TLS não é sinónimo de WPA3. O registo de certificação da Wi-Fi Alliance identifica o EAP-TLS entre os métodos de autenticação empresarial suportados. A autenticação por certificado é uma opção de autenticação empresarial, enquanto o perfil WPA também determina os requisitos de segurança sem fios.
Compare a credencial, não apenas o rótulo
Uma frase-passe partilhada comprova o conhecimento de um segredo comum. Não estabelece qual foi o colaborador que a forneceu, embora o equipamento de rede ainda possa registar os detalhes da ligação. A saída de funcionários torna-se problemática, pois substituir a credencial significa atualizar todos os dispositivos que a utilizam.
PEAP-MSCHAPv2 passa para nomes de utilizador e palavras-passe individuais. Utiliza um túnel TLS autenticado pelo servidor para proteger a troca de autenticação interna, pelo que a validação adequada do servidor continua a ser importante. Pode fornecer registos úteis por utilizador, mas as alterações de palavras-passe e os problemas de conta continuam a fazer parte do suporte de rede sem fios.
Com o EAP-TLS, o ponto de extremidade utiliza o seu certificado e chave privada em vez de uma palavra-passe de conta durante a autenticação. Isso fornece aos administradores uma credencial específica do dispositivo para gerir, desde que o inventário associe corretamente os certificados aos pontos de extremidade e aos proprietários.
Escolha o método cujo ciclo de vida das credenciais a sua equipa consiga realmente operar, e não apenas o identificador mais forte no menu do controlador.
Corresponda o método à população
As frases de acesso partilhadas são uma opção predefinida fraca para o acesso gerido de funcionários, em que o cancelamento individual e a responsabilidade são importantes. Mesmo para convidados e equipamentos de baixo risco, uma palavra-passe comum exige uma política deliberada de distribuição e substituição.
Os certificados adaptam-se a portáteis e telemóveis geridos porque pode aprovisioná-los através de um sistema de gestão existente. O perfil empresarial de garantia mais elevada adiciona trabalho de compatibilidade; não remove quaisquer responsabilidades de ciclo de vida. O PEAP pode permanecer como uma opção de migração onde existem contas individuais mas o aprovisionamento de certificados não está pronto, em vez de ser um motivo para adiar indefinidamente um modelo de acesso baseado em identidade.
Criar a CA e aprovisionar certificados através de MDM
Uma implementação gerível começa com uma infraestrutura de chaves públicas (PKI) com uma responsabilidade clara. Uma hierarquia comum mantém uma autoridade de certificação de raiz offline e utiliza uma CA de emissão para a emissão rotineira de certificados. Um serviço de PKI gerido pode desempenhar esses papéis sem que a sua equipa tenha de operar cada componente localmente.
A AC emissora assina os certificados de servidor e de dispositivo. A RADIUS deve confiar na cadeia de certificados do cliente, enquanto os pontos de extremidade devem confiar na cadeia de servidor adequada. Não assuma que a instalação de um certificado raiz configura automaticamente o restante da política sem fios.
Escolha os perfis antes de emitir certificados
Um modelo de dispositivo necessita de utilização de autenticação de cliente, de uma identidade de dispositivo ou utilizador que a sua política consiga resolver, e de um período de validade regido pelo seu plano de renovação e recuperação.
Perfis de certificado por nível de segurança
| Perfil | Chave e algoritmo | Validade típica | Onde se adequa |
|---|---|---|---|
| Portátil ou telemóvel gerido padrão | Algoritmo aprovado pela organização e suportado em toda a frota | Definida pela política de renovação e recuperação | Frotas mistas em WPA2-Enterprise |
| Dispositivo gerido mais rigoroso | Modelo mais forte aprovado após testes no ponto final | Definida pela política e capacidade de renovação | Frotas modernas com firmware atual |
| WPA3-Enterprise de 192 bits | ECDSA P-384 ou RSA 3072 ou superior | Definida pela política e capacidade de renovação | Locais de maior garantia após testes de compatibilidade |
| Dispositivo sem ecrã (headless) ou antigo | Frequentemente não suportado | Ciclo de vida suportado pelo fornecedor ou expiração de exceção | Caminho de exceção |
O guia de implementação da WiFi Alliance especifica que o modo de 192 bits da WPA3-Enterprise restringe a autenticação a EAP-TLS e utiliza suítes AES-256-GCM com parâmetros de curva elíptica P-384 ou tamanhos de módulo RSA/DH de, pelo menos, 3072 bits. O perfil de maior garantia da tabela deve, portanto, ser verificado em relação à suíte selecionada completa, e não apenas ao rótulo da chave do certificado.
Os modelos de certificado, o software RADIUS, os suplicantes e os fornecedores criptográficos devem estar em conformidade. Um ponto final que suporte EAP-TLS normal pode ainda assim falhar com este perfil mais rigoroso.
Disponibilizar fidedignidade, credenciais e configuração em conjunto
Com o SCEP, o perfil de gestão orienta o dispositivo a gerar um par de chaves e a solicitar um certificado. A AC assina o pedido; o dispositivo mantém a sua chave privada num armazenamento protegido. Não distribua o mesmo certificado de cliente e chave privada por várias máquinas.
Implemente as dependências de forma controlada:
- Confiança em primeiro lugar: Instale os certificados CA de confiança necessários.
- Credencial em segundo lugar: Entregue a configuração SCEP e confirme a emissão com sucesso.
- Perfil sem fios em último lugar: Referencie as definições pretendidas de credencial do cliente e de validação do servidor.
Mantenha a segmentação de grupos consistente em todos os perfis dependentes. Utilize a comparação de perfis de certificados WiFi MDM para rever as diferenças de plataforma antes de padronizar a implementação. Disponibilize também uma ligação de Inscrição que não dependa do certificado que o dispositivo ainda está a tentar obter.
Gerir o ciclo de vida dos certificados, da emissão à renovação
Um portátil que se liga com sucesso hoje pode falhar após ficar num armário durante o seu período de renovação. O ponto de acesso pode estar a funcionar normalmente, a palavra-passe não mudou e o utilizador não fez nada de errado. O ponto de extremidade simplesmente já não possui uma credencial aceitável.
O guia de requisitos EAP do NIST descreve a necessidade de os certificados serem aprovisionados antes da autenticação, estarem disponíveis durante a troca e serem verificáveis, incluindo o estado de revogação. Estes requisitos tornam as dependências do ciclo de vida parte da disponibilidade da rede.
Esta cronologia é útil para atribuir a responsabilidade para além da implementação inicial.
Atribua um controlo operacional a cada etapa
| Fase | Controlo | Falha que previne |
|---|---|---|
| Registo | Monitorizar o registo no MDM e a atribuição de perfis | O dispositivo nunca recebe uma instrução de registo |
| Emissão | Validar permissões de modelos e resultados de pedidos | A CA rejeita pedidos ou emite certificados inutilizáveis |
| Implementação | Verificar a instalação e o acesso protegido à chave privada | O certificado existe, mas o suplicante não o consegue utilizar |
| Renovação | Iniciar cedo, monitorizar a conclusão e permitir uma sobreposição testada | Os dispositivos atingem a expiração sem uma substituição |
| Expiração | Alertar os responsáveis e fornecer uma rota de recuperação restrita | Os dispositivos expirados não têm forma de recuperar |
| Desativação | Retirar credenciais e remover entradas obsoletas do inventário | O equipamento desativado mantém uma identidade aceite |
A renovação necessita de prova de conclusão, não apenas de uma definição de automatização ativada. Monitorize se um certificado de substituição foi emitido, instalado e utilizado com sucesso. Durante a sobreposição, confirme que o suplicante seleciona uma credencial adequada em vez de escolher repetidamente uma obsoleta.
Planeie para dispositivos que não estão online
Defina a janela de renovação com base no comportamento real do dispositivo. Equipamentos utilizados sazonalmente ou mantidos como reserva podem precisar de um processo de recuperação diferente do de um portátil que estabelece ligação diariamente. Não assuma que um ponto de extremidade offline pode renovar o certificado apenas porque o certificado antigo continua listado no MDM.
Mantenha um inventário que associe o número de série do certificado, o identificador do ponto de extremidade, o proprietário, o emissor, a validade e o estado de renovação. Inclua a AC emissora e os certificados do servidor de autenticação, uma vez que a sua substituição pode afetar uma população muito mais vasta.
Uma tarefa de renovação executada com sucesso não é o mesmo que um dispositivo capaz de se autenticar com o seu certificado de substituição.
Testar erros de relógio, reconstruções do sistema operativo e alterações na cadeia da CA. Uma reconstrução pode remover a chave privada; um erro de relógio pode fazer com que um certificado válido pareça ainda não ser válido; uma alteração na cadeia pode deixar os pontos finais sem a confiança necessária.
Atribua responsáveis nomeados para falhas que envolvam MDM, PKI e serviços de rede. Caso contrário, cada equipa pode comunicar que o seu próprio sistema está saudável enquanto o ponto de extremidade permanece desligado. O EAP-TLS transforma o risco de inatividade num problema de inventário, automatização e gestão de dependências. Não elimina esse risco.
Revogar o acesso quando os dispositivos se perdem ou as pessoas saem
A conta de diretório de um colaborador cessante é desativada, mas o seu portátil ainda contém um certificado que não expirou. Se o dispositivo se pode voltar a ligar depende da sua integração de autorização e dos controlos de revogação. Desativar uma conta e revogar um certificado são ações diferentes, a menos que o seu fluxo de trabalho configurado as associe explicitamente.
Defina o resultado do descredenciamento em termos operacionais: as novas autenticações devem falhar, o registo não deve emitir credenciais de substituição e as sessões existentes devem ser encerradas através de um mecanismo suportado. Um pedido de RH concluído não prova nenhum desses resultados.
Compreenda as verificações de estado
Uma lista de revogação de certificados, ou CRL, publica certificados que um emissor retirou. O Online Certificate Status Protocol, ou OCSP, permite que um validador solicite o estado do certificado a um respondedor.
O componente que valida o certificado aplica a política de verificação de estado relevante. Para certificados de cliente, trata-se normalmente do serviço de autenticação e não do ponto de acesso. Se as informações de estado não estiverem disponíveis, uma política de falha fechada (fail-closed) pode bloquear dispositivos que, de outro modo, seriam válidos, enquanto uma política de falha aberta (fail-open) pode aceitar uma credencial cuja revogação não possa ser confirmada.
Torne essa escolha explícita. Inclua informações de estado em cache, atrasos de publicação e disponibilidade do respondedor nos seus testes, em vez de assumir que clicar em “revogar” altera imediatamente todas as decisões de autenticação.
Utilize um procedimento completo para dispositivos perdidos
Para um portátil perdido ou roubado, coordene as ações em vez de tratar cada uma como o passo final de uma equipa separada:
- Identificar e retirar a credencial. Associe o ponto final ao seu número de série de certificado real e revogue a respetiva credencial.
- Impedir a emissão de substituição. Desative a elegibilidade de inscrição do dispositivo e aplique o processo adequado de eliminação ou remoção de MDM.
- Terminar o acesso ativo. Utilize controlos de desconexão de sessão suportados, incluindo a Change of Authorization da RADIUS onde a infraestrutura a suportar.
- Verificar o resultado. Confirme que a sessão terminou e que uma nova tentativa de autenticação é rejeitada.
A revogação por si só não termina necessariamente uma sessão sem fios estabelecida. Em equipamentos sem um mecanismo de desligamento suportado, a sessão pode continuar até à ligação seguinte, reautenticação ou outro limite de sessão imposto. Registe essa limitação no procedimento de incidentes.
O seu registo de auditoria deve incluir:
- Identidade da credencial: Identificador do dispositivo, número de série do certificado e proprietário associado.
- Evidência de decisão: Motivo da revogação, operador e hora da ação.
- Evidência de aplicação: Hora de término da sessão e resultado de rejeição subsequente.
- Exposição pendente: Qualquer sessão que não tenha podido ser encerrada forçadamente e a ação de contenção tomada.
Agende exercícios de revogação. Execute-os após alterações na política de autenticação, bem como durante os testes operacionais de rotina, para que um incidente real de perda de dispositivo não seja a sua primeira tentativa de validar todo o processo.
Elegibilidade dos dispositivos e planeamento de exceções
Classes de dispositivos e a sua adequação com EAP-TLS
| Classe de dispositivo | Adequação ao EAP-TLS | Alternativa típica | Pergunta fundamental a fazer |
|---|---|---|---|
| Portáteis e telemóveis geridos | Elevada | Nenhuma necessária, registo em MDM | O registo no MDM é fiável? |
| Tablets corporativos e quiosques | Boa quando geridos por MDM | Chave específica de quiosque por si só SSID | A chave privada pode ficar num armazenamento seguro? |
| Sensores IoT sem interface gráfica | Fraca sem firmware adequado | Chave por dispositivo numa VLAN isolada | O firmware suporta 802.1X? |
| Sistemas de sala, AV e conferência | Suporte específico do fornecedor | SSID dedicada com chave por dispositivo | O fornecedor pode instalar e renovar certificados? |
| Dispositivos médicos | Muitas vezes limitada | Rede segmentada com método aprovado pelo fornecedor | O dispositivo está certificado para este método? |
| Endpoints com sistemas operativos legados | Não suportado quando faltam as capacidades necessárias | VLAN em quarentena com exceção temporária | Quando é que a exceção será revista? |
A limitação fundamental é que cada cliente EAP-TLS precisa do seu próprio certificado, e não apenas de confiar no servidor. O guia do NIST para redes sem fios distingue este requisito de certificado de cliente da autenticação por certificado apenas no servidor.
Portanto, um dispositivo precisa de um suplicante funcional, proteção adequada de chave privada e uma forma suportada de receber e substituir a sua credencial. Uma ficha de especificações a dizer “WiFi empresarial suportado” não é suficiente para comprovar essas capacidades.
Teste todo o ciclo de vida do dispositivo
Para um sistema de sala de conferências, peça ao fornecedor para demonstrar a instalação, renovação e recuperação do certificado após uma reposição de fábrica. Uma interface web que aceite o carregamento de um certificado pode resolver a integração sem resolver a manutenção.
Para equipamentos médicos e operacionais, mantenha os requisitos de suporte do fornecedor. Não altere o método de autenticação de um dispositivo em produção apenas porque outro produto do mesmo fabricante o suporta.
Os dispositivos pessoais precisam de uma decisão de elegibilidade separada. A sua conceção de integração BYOD deve estabelecer que gestão ou instalação de perfil é aceitável antes de exigir que os utilizadores se registem.
Defina exceções restritas e com responsabilidade atribuída
Um dispositivo que não consiga utilizar certificados não deve herdar as permissões de acesso de um portátil gerido de um funcionário. Atribua um proprietário definido à sua credencial alternativa e restrinja a rede aos destinos necessários.
Registe o seguinte para cada exceção:
- Razão técnica: A capacidade em falta ou a restrição do fornecedor, fundamentada por uma verificação de configuração.
- Controlos de compensação: Segmentação, serviços permitidos e a alternativa individualmente revogável.
- Data de revisão: Uma decisão agendada para renovar, alterar ou remover a exceção.
- Plano de substituição: A atualização de firmware, o método de integração suportado ou a substituição de hardware que a encerraria.
Evite transformar uma rede de quarentena temporária num local permanente para equipamentos não identificados. Uma exceção sem um responsável ou sem uma condição de saída torna-se numa política de acesso não documentada. A abordagem defensável não passa por ter certificados a qualquer custo; trata-se de ter uma autenticação forte de dispositivos geridos a par de alternativas deliberadamente limitadas.
Confirme o seu plano de certificados antes de avançar para a implementação
Uma demonstração bem-sucedida mostra que um portátil em bom estado se consegue ligar. Um piloto útil mostra o que acontece quando a inscrição falha, uma credencial expira, um dispositivo é retirado e uma dependência fica indisponível. Aprove o modelo operacional, não apenas o primeiro aperto de mão bem-sucedido.
Escolha um local piloto e identifique as classes de dispositivos abrangidas antes de alterar o acesso em produção. Faça o inventário das capacidades dos pontos de acesso, do comportamento dos supplicants e das versões de firmware. Onde for necessário um perfil de maior garantia, valide o modelo de certificado selecionado, as verificações da cadeia de certificados e a utilização alargada de chaves em relação a pontos finais representativos.
Torne concreta a revisão de prontidão desta semana
Utilize esta lista de verificação para expor responsáveis em falta e pressupostos não testados.
- Confirmar o suporte do dispositivo: Verifique se cada dispositivo no âmbito pode armazenar e utilizar uma chave privada protegida, e não apenas importar um certificado.
- Confirmar confiança e renovação: Atribua responsáveis para a cadeia da CA, serviço de registo, monitorização da renovação e caminho de recuperação.
- Testar a aplicação: Demonstre aceitação, rejeição, revogação e terminação de sessão ativa suportada.
- Aprovar exceções: Forneça a cada classe não suportada uma alternativa restrita, um responsável prestável e uma data de revisão.
- Definir alertas acionáveis: Encaminhe eventos de expiração iminente e de falha na renovação para alguém que os possa resolver.
Utilize um procedimento repetível de RADIUS teste de autenticação para que os engenheiros recolham evidências comparáveis. Registe o estado do cliente, o resultado previsto, o resultado real e o código de falha relevante.
Avalie o piloto com base na capacidade de suporte
Execute o caminho do certificado em paralelo com a rede existente com um procedimento de reversão definido. Inclua o registo remoto, um ponto de extremidade reconstruído, uma unidade de reserva offline e os sistemas operativos suportados pelo seu suporte técnico. Não escolha apenas portáteis aprovisionados recentemente.
Analise os pedidos do suporte técnico juntamente com os registos de autenticação. Separe as falhas de certificados da cobertura sem fios, da atribuição de endereços e de problemas de VLAN, para que a equipa não redesenhe a PKI para resolver uma falha não relacionada.
A aceitação do piloto deve significar que os dispositivos geridos se ligam normalmente sem intervenção do utilizador, que as falhas têm causas identificadas e que a remoção do acesso pode ser demonstrada. Mantenha evidências de tentativas bem-sucedidas e rejeitadas, com contexto de identidade suficiente para explicar a decisão.
Defina a data de revisão do piloto antes de este começar. Confirme o local, as classes de dispositivos, os responsáveis e os critérios de aceitação esta semana; em seguida, expanda apenas após a equipa ter resolvido as falhas e comprovado a recuperação. Uma implementação menor, com renovação e revogação fiáveis, é uma base melhor do que uma implementação abrangente que ninguém consegue reparar com confiança.
O Purple Access oferece acesso a colaboradoresWiFi baseado em certificados através de EAP-TLS fornecido por MDM, juntamente com acesso de convidados e por dispositivo nos pontos de acesso que já possui. Visite o Purple Access para planear um projeto-piloto num local, validar as vias de certificado e de exceção, e avaliar o resultado com base em pedidos de suporte e evidências de auditoria antes de alargar a implementação.
