Autenticação WiFi baseada em certificado: guia do EAP-TLS
Published
Alguém está saindo da empresa, e sua equipe está decidindo se altera a senha do WiFi WiFi para colaboradores novamente. Alterá-la significa reconectar laptops, telefones, tablets da recepção e equipamentos que ninguém lembra ter configurado. Deixá-la como está significa aceitar que alguém fora da organização ainda sabe como se conectar.
A autenticação baseada em certificado WiFi oferece a você uma maneira melhor de identificar dispositivos confiáveis. Mas ela também altera o trabalho que sua equipe deve realizar: em vez de distribuir senhas, você gerenciará cadeias de confiança, renovação de certificados, revogação e dispositivos que desaparecem no armazenamento por meses. A melhoria de segurança é real. Uma operação confiável exige mais do que selecionar EAP-TLS em um perfil sem fio.
Sumário
- O que significa a autenticação baseada em certificadoWiFi
- Como funciona o handshake de EAP-TLS passo a passo
- Comparativo de certificados com senhas compartilhadas e PEAP
- Criação da CA e provisionamento de certificados via MDM
- Gerenciamento do ciclo de vida do certificado da emissão à renovação
- Revogação de acesso em caso de perda de dispositivos ou desligamento de pessoas
- Elegibilidade de dispositivos e planejamento de exceções
- Confirme seu plano de certificados antes da implantação
O que significa a autenticação baseada em certificados WiFi
A autenticação baseada em certificado WiFi substitui uma senha compartilhada de WiFi por um certificado digital individual, que a rede verifica antes de conceder acesso. Pense nisso como a diferença entre um código de porta de escritório compartilhado e um crachá de funcionário. Com o código, todos provam que conhecem o mesmo segredo. Com um crachá, a equipe de segurança pode identificar uma credencial específica e cancelá-la de forma independente.
Suponha que um notebook gerenciado precise de acesso à rede de funcionários. Seu certificado identifica o dispositivo ou seu usuário atribuído, e sua chave privada protegida permite provar que ele possui essa credencial. O certificado em si não é uma senha secreta, e copiar apenas o certificado público não fornece a chave privada correspondente.
O diagrama mostra como as credenciais individuais substituem a senha comum.
Onde os componentes se encaixam
A estrutura subjacente é o IEEE 802.1X, desenvolvido originalmente para Ethernet cabeada e adaptado para LANs sem fio. A visão geral da Microsoft sobre a autenticação IEEE 802.1X descreve a estrutura e a função da autenticação centralizada por meio do RADIUS.
O ponto de acesso controla a admissão, enquanto o serviço RADIUS avalia a solicitação de autenticação. EAP-TLS é o método de autenticação baseado em certificado realizado por meio desse arranjo. O dispositivo e o servidor de autenticação validam um ao outro antes de estabelecer o material de chaveamento para a conexão.
Mantenha estes componentes distintos:
- Certificado do dispositivo: Identifica o ponto de extremidade ou o usuário e funciona com uma chave privada mantida pelo dispositivo.
- Certificado do servidor de autenticação: Permite que o dispositivo verifique se está se comunicando com um serviço de autenticação aprovado.
- Autoridade de certificação: Emite certificados que cada parte pode validar por meio de uma cadeia de certificados explicitamente confiá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 apropriado 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 senhas complicadas.
Essa distinção muda a forma como você lida com um laptop perdido. Você pode revogar a credencial dele sem substituir as credenciais no equipamento de todos os outros. No entanto, a posse de um certificado válido estabelece a identidade, não uma permissão ilimitada. Sua política de acesso ainda precisa decidir o que essa identidade pode alcançar.
Como funciona o handshake do EAP-TLS passo a passo
Uma conexão envolve o suplicante do dispositivo, o ponto de acesso atuando como autenticador e o servidor de autenticação. O suplicante é o componente do sistema operacional que lida com a autenticação de rede corporativa.
Este fluxo simplificado mostra as principais transferências, em vez de todas as mensagens do protocolo.
Acompanhe a troca e seus pontos de falha
A autenticação mútua e a derivação de chave que fundamentam essa troca estão definidas na especificação EAP-TLS, RFC 5216.
O dispositivo se associa ao ponto de acesso. Ele inicia a troca de autenticação corporativa e fornece uma identidade. A associação por si só não concede acesso normal à rede. Uma configuração incorreta de segurança sem fio pode impedir totalmente que o dispositivo alcance a autenticação por certificado.
O ponto de acesso retransmite mensagens EAP para o RADIUS. Ele repassa a troca entre o endpoint e o serviço de autenticação, em vez de emitir o próprio certificado do dispositivo. Um problema de conectividade do RADIUS ou um ponto de acesso registrado incorretamente pode interromper a troca nesta etapa.
O servidor apresenta seu certificado. O dispositivo verifica a cadeia de certificados, a validade e a identidade esperada do servidor. Um emissor não confiável, uma cadeia incompleta ou um nome de servidor inesperado devem fazer com que o dispositivo recuse a conexão.
O dispositivo apresenta seu certificado de cliente. O servidor valida a credencial, verifica as informações de revogação aplicáveis e avalia a identidade. A ausência de um certificado ou uma chave privada inacessível pode parecer uma falha genérica de conexão para o usuário, mesmo quando os logs do servidor indicam uma causa específica.
A troca TLS estabelece o material de chaveamento compartilhado. O endpoint deve demonstrar a posse de sua chave privada, e não apenas apresentar um arquivo de certificado. Configurações criptográficas incompatíveis podem impedir a conclusão, mesmo quando ambos os certificados forem válidos.
O RADIUS retorna 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 por uma conexão inutilizável pode indicar um problema de VLAN ou de política downstream, em vez de um problema de certificado.
Configure o cliente para verificar o servidor
No perfil do suplicante, selecione explicitamente o EAP-TLS, configure a AC confiável e especifique os nomes de servidor RADIUS esperados. Mantenha a validação do certificado do servidor ativada. Não permita que os usuários ignorem um aviso apenas para se conectarem.
Use este vídeo juntamente com o fluxo do protocolo ao discutir a troca com sua equipe.
Toda conexão depende de as credenciais estarem presentes, acessíveis e aceitáveis no momento da autenticação. Portanto, a solução de problemas exige evidências tanto do suplicante quanto do RADIUS, e não apenas um painel de ponto de acesso mostrando que um cliente falhou ao se conectar.
Comparativo de certificados com senhas compartilhadas e PEAP
WiFi métodos de autenticação com base nos mesmos critérios
| Método | Credencial no dispositivo | Escopo de revogação | Responsabilização | Esforço de configuração |
|---|---|---|---|---|
| Senha compartilhada do WPA2 ou WPA3-Personal | Uma senha conhecida por todos os usuários | Altera a chave para todos | Nenhuma a partir da própria credencial compartilhada | Baixo |
| WPA2-Enterprise com PEAP-MSCHAPv2 | Nome de usuário e senha por usuário | Desativa uma conta | Por usuário | Médio |
| EAP-TLS no WPA2 ou WPA3-Enterprise | Certificado de cliente e chave privada exclusivos por dispositivo | Revoga um certificado | Por dispositivo e usuário quando mapeado | Alto, requer PKI e provisionamento gerenciado |
| WPA3-Enterprise 192 bits com EAP-TLS | Certificado que atende aos requisitos criptográficos do perfil | Revoga um certificado | Por dispositivo e usuário quando mapeado | Alto, além de verificações de compatibilidade de ciphers |
EAP-TLS não é sinônimo de WPA3. O registro de certificação da Wi-Fi Alliance identifica EAP-TLS entre os métodos de autenticação corporativa suportados. A autenticação por certificado é uma escolha de autenticação corporativa, enquanto o perfil WPA também determina os requisitos de segurança sem fio.
Compare a credencial, não apenas o rótulo
Uma frase-passe compartilhada comprova o conhecimento de um segredo comum. Ela não estabelece qual funcionário a forneceu, embora os equipamentos de rede ainda possam registrar detalhes da conexão. As saídas de funcionários tornam-se complicadas porque substituir a credencial significa atualizar todos os dispositivos que a utilizam.
PEAP-MSCHAPv2 passa para nomes de usuário e senhas individuais. Ele usa um túnel TLS autenticado pelo servidor para proteger a troca de autenticação interna, portanto, a validação adequada do servidor ainda importa. Ele pode fornecer registros úteis por usuário, mas as alterações de senha e os problemas de conta continuam fazendo parte do suporte sem fio.
Com o EAP-TLS, o ponto de extremidade usa seu certificado e chave privada em vez de uma senha de conta durante a autenticação. Isso fornece aos administradores uma credencial específica do dispositivo para gerenciar, desde que o inventário mapeie corretamente os certificados para os pontos de extremidade e proprietários.
Escolha o método cujo ciclo de vida de credenciais sua equipe pode realmente operar, e não simplesmente a opção mais forte no menu do controlador.
Adeque o método ao público
Frases secretas compartilhadas são uma opção padrão ruim para acesso gerenciado de funcionários, onde a revogação individual e a responsabilidade são importantes. Mesmo para convidados e equipamentos de baixo risco, uma senha comum precisa de uma política deliberada de distribuição e substituição.
Os certificados são adequados para notebooks e telefones gerenciados porque você pode provisioná-los por meio de um sistema de gerenciamento existente. O perfil corporativo de garantia mais elevada adiciona trabalho de compatibilidade; ele não remove nenhuma responsabilidade do ciclo de vida. PEAP pode continuar sendo uma opção de migração onde existem contas individuais, mas o provisionamento de certificados ainda não está pronto, em vez de ser uma razão para adiar indefinidamente um projeto de acesso baseado em identidade.
Criação da CA e provisionamento de certificados por meio do MDM
Uma implantação gerenciável começa com uma infraestrutura de chaves públicas, ou PKI, cuja propriedade seja clara. Uma hierarquia comum mantém uma autoridade certificadora raiz offline e usa uma AC emissora para a emissão rotineira de certificados. Um serviço gerenciado de PKI pode cumprir essas funções sem que sua equipe precise operar cada componente localmente.
A AC emissora assina os certificados de dispositivo e de servidor. RADIUS deve confiar na cadeia de certificados do cliente, enquanto os endpoints devem confiar na cadeia de servidores apropriada. Não presuma que a instalação de um certificado raiz configura automaticamente o restante da política sem fio.
Escolha os perfis antes de emitir os certificados
Um modelo de dispositivo precisa de uso de autenticação de cliente, uma identidade de dispositivo ou usuário que sua política possa resolver e um período de validade regido pelo seu projeto de renovação e recuperação.
Perfis de certificado por nível de segurança
| Perfil | Chave e algoritmo | Validade típica | Onde se aplica |
|---|---|---|---|
| Notebook ou telefone gerenciado padrão | Algoritmo aprovado pela organização e suportado em toda a frota | Definida por política de renovação e recuperação | Frotas mistas no WPA2-Enterprise |
| Dispositivo gerenciado mais restrito | Modelo mais forte aprovado após testes no endpoint | Definida por 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 por política e capacidade de renovação | Locais de maior nível de garantia após testes de compatibilidade |
| Dispositivo sem tela (headless) ou legado | Muitas vezes não suportado | Ciclo de vida suportado pelo fornecedor ou expiração da exceção | Caminho de exceção |
O guia de implantação da Wi-Fi Alliance especifica que o modo de 192 bits do WPA3-Enterprise restringe a autenticação ao EAP-TLS e usa 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. Portanto, o perfil de maior garantia da tabela deve ser verificado em relação à suíte selecionada completa, e não apenas pelo rótulo da chave do certificado.
Os modelos de certificado, softwares de RADIUS, suplicantes e provedores criptográficos devem estar em conformidade. Um ponto de extremidade que suporta EAP-TLS comum ainda pode falhar sob este perfil mais rigoroso.
Forneça confiança, credenciais e configuração em conjunto
Com o SCEP, o perfil de gerenciamento orienta o dispositivo a gerar um par de chaves e solicitar um certificado. A AC assina a solicitação; o dispositivo mantém sua chave privada em um armazenamento protegido. Não distribua o mesmo certificado de cliente e chave privada para várias máquinas.
Implante as dependências em uma ordem controlada:
- Confiança em primeiro lugar: Instale os certificados de CA confiáveis necessários.
- Credencial em seguida: Entregue a configuração SCEP e confirme a emissão bem-sucedida.
- Perfil sem fio por último: Referencie a credencial de cliente pretendida e as configurações de validação do servidor.
Mantenha o direcionamento de grupos consistente em perfis dependentes. Use a comparação de perfis de certificado MDM WiFi para analisar as diferenças de plataforma antes de padronizar a implantação. Além disso, forneça uma conexão de registro que não dependa do certificado que o dispositivo ainda está tentando obter.
Gerenciamento do ciclo de vida do certificado, da emissão à renovação
Um laptop que se conecta com sucesso hoje pode falhar após ficar guardado em um armário durante o período de renovação. O ponto de acesso pode estar funcionando perfeitamente, a senha não mudou e o usuário não fez nada de errado. O ponto de extremidade simplesmente não possui mais uma credencial aceitável.
O guia de requisitos EAP do NIST's descreve a necessidade de os certificados serem provisionados antes da autenticação, estarem disponíveis durante a troca e serem verificáveis, incluindo o status de revogação. Esses requisitos tornam as dependências de ciclo de vida parte da disponibilidade da rede.
Esta cronologia é útil para atribuir a responsabilidade além da implantação inicial.
Atribua um controle operacional a cada etapa
| Etapa | Controle | Falha que previne |
|---|---|---|
| Inscrição | Monitorar o registro do MDM e o direcionamento de perfis | O dispositivo nunca recebe uma instrução de inscrição |
| Emissão | Validar permissões de modelos e resultados de solicitações | A AC rejeita solicitações ou emite certificados inutilizáveis |
| Implantação | Verificar a instalação e o acesso protegido à chave privada | O certificado existe, mas o suplicante não consegue usá-lo |
| Renovação | Iniciar antecipadamente, monitorar a conclusão e permitir sobreposição testada | Os dispositivos atingem a expiração sem uma substituição |
| Expiração | Alertar proprietários e fornecer uma rota de recuperação restrita | Dispositivos expirados não têm forma de recuperação |
| Desativação | Revogar credenciais e remover entradas obsoletas do inventário | O equipamento desativado mantém uma identidade aceita |
A renovação precisa de comprovação de conclusão, e não apenas de uma configuração de automação ativada. Acompanhe se um certificado de substituição foi emitido, instalado e usado com sucesso. Durante a sobreposição, confirme se o suplicante seleciona uma credencial adequada em vez de escolher repetidamente uma obsoleta.
Planeje para dispositivos que não estão online
Defina a janela de renovação de acordo com o comportamento real do dispositivo. Equipamentos usados sazonalmente ou mantidos como reserva podem precisar de um processo de recuperação diferente daquele de um laptop que se conecta diariamente. Não presuma que um endpoint offline possa ser renovado apenas porque seu certificado antigo continua listado no MDM.
Mantenha um inventário vinculando o número de série do certificado, o identificador do ponto de extremidade, o proprietário, o emissor, a expiração e o status de renovação. Inclua os certificados da AC emissora e do servidor de autenticação, pois a substituição deles pode afetar uma população muito maior.
Um trabalho de renovação executado com sucesso não é o mesmo que um dispositivo capaz de se autenticar com seu certificado de substituição.
Testa erros de relógio, recriações de sistemas operacionais e alterações na cadeia de AC. Uma recriaçã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 de extremidade sem a confiança necessária.
Atribua responsáveis nomeados para falhas envolvendo MDM, PKI e serviços de rede. Caso contrário, cada equipe pode relatar que seu próprio sistema está saudável enquanto o ponto de extremidade permanece desconectado. O EAP-TLS transforma o risco de interrupção em um problema de inventário, automação e gerenciamento de dependências. Ele não elimina esse risco.
Revogação do acesso quando dispositivos são perdidos ou pessoas se desligam
A conta de diretório de um ex-funcionário é desativada, mas seu notebook ainda possui um certificado que não expirou. A possibilidade de reconexão depende de sua integração de autorização e dos controles de revogação. Desativar uma conta e revogar um certificado são ações diferentes, a menos que seu fluxo de trabalho configurado as conecte explicitamente.
Defina o resultado do desligamento (offboarding) em termos operacionais: novas autenticações devem falhar, a integração não deve emitir credenciais de substituição e as sessões existentes devem ser encerradas por meio de um mecanismo suportado. Um chamado do RH concluído não comprova nenhum desses resultados.
Compreenda as verificações de status
Uma lista de revogação de certificados, ou CRL, publica os certificados que um emissor retirou. O Online Certificate Status Protocol, ou OCSP, permite que um validador solicite o status do certificado a um respondedor.
O componente que valida o certificado aplica a política de verificação de status relevante. Para certificados de cliente, esse componente normalmente é o serviço de autenticação, e não o ponto de acesso. Se as informações de status estiverem indisponíveis, uma política fail-closed poderá bloquear dispositivos válidos, enquanto uma política fail-open poderá aceitar uma credencial cuja revogação não pode ser confirmada.
Torne essa escolha explícita. Inclua informações de status em cache, atrasos na publicação e disponibilidade do respondedor nos seus testes, em vez de presumir que clicar em "revogar" altera imediatamente todas as decisões de autenticação.
Utilize um procedimento completo para dispositivos perdidos
Para um notebook ausente, coordene as ações em vez de tratar cada uma como a etapa final de uma equipe separada:
- Identifique e revogue a credencial. Associe o endpoint ao seu número de série de certificado real e revogue a credencial correspondente.
- Impeça a emissão de substituição. Desative a elegibilidade de registro do dispositivo e aplique o processo apropriado de remoção ou desativação no MDM.
- Encerre o acesso ativo. Use controles de desconexão de sessão suportados, incluindo Alteração de Autorização (CoA) do RADIUS onde a infraestrutura for compatível.
- Verifique o resultado. Confirme se a sessão foi encerrada e se uma nova tentativa de autenticação é rejeitada.
A revogação por si só não encerra necessariamente uma sessão sem fio estabelecida. Em equipamentos sem um mecanismo de desconexão compatível, a sessão pode continuar até a reconexão, reautenticação ou outro limite de sessão imposto. Registre essa limitação no procedimento de incidentes.
Seu registro de auditoria deve incluir:
- Identidade da credencial: Identificador do dispositivo, número de série do certificado e proprietário associado.
- Evidência da decisão: Motivo da revogação, operador e horário da ação.
- Evidência de aplicação: Horário de término da sessão e resultado de rejeição subsequente.
- Exposição remanescente: Qualquer sessão que não pôde ser encerrada forçadamente e a ação de contenção realizada.
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 dispositivo perdido não seja sua primeira tentativa de comprovar todo o fluxo.
Planejamento de elegibilidade e exceções de dispositivos
Classes de dispositivos e sua adequação com EAP-TLS
| Classe de dispositivo | Adequação ao EAP-TLS | Alternativa típica | Pergunta-chave a fazer |
|---|---|---|---|
| Laptops e celulares gerenciados | Forte | Nenhuma necessária, inscrição via MDM | A inscrição via MDM é confiável? |
| Tablets corporativos e quiosques | Boa quando gerenciados por MDM | Chave específica para quiosque por si só SSID | A chave privada pode ficar em um armazenamento seguro? |
| Sensores IoT sem interface (headless) | Fraca sem um firmware adequado | Chave por dispositivo em uma VLAN isolada | O firmware suporta o 802.1X? |
| Sistemas de sala, AV e videoconferência | Suporte específico do fornecedor | SSID dedicada com chave por dispositivo | O fornecedor consegue instalar e renovar certificados? |
| Dispositivos médicos | Frequentemente limitado | Rede segmentada com método aprovado pelo fornecedor | O dispositivo é certificado para este método? |
| Endpoints com sistemas operacionais legados | Sem suporte quando os recursos necessários estão ausentes | VLAN de quarentena com exceção com prazo definido | Quando a exceção será revisada? |
A limitação fundamental é que cada EAP-TLS cliente precisa de seu próprio certificado, e não apenas de confiança no servidor. O guia de rede sem fio do NIST's distingue esse requisito de certificado do cliente da autenticação por certificado exclusiva do servidor.
Portanto, um dispositivo precisa de um suplicante funcional, proteção adequada de chave privada e uma maneira suportada de receber e substituir sua credencial. Uma folha de especificações dizendo “WiFi corporativo suportado” não é suficiente para estabelecer esses recursos.
Teste todo o ciclo de vida do dispositivo
Para um sistema de sala de conferências, solicite ao fornecedor a demonstração da instalação, renovação e recuperação de certificados após uma redefinição de fábrica. Uma interface web que aceita o envio de certificados 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.
Dispositivos pessoais precisam de uma decisão de elegibilidade separada. O seu projeto de integração BYOD deve estabelecer qual gerenciamento ou instalação de perfil é aceitável antes de solicitar que os usuários se inscrevam.
Defina exceções de forma restrita e responsável
Um dispositivo que não pode usar certificados não deve herdar as permissões de acesso do notebook de um funcionário gerenciado. Atribua um proprietário definido à sua credencial alternativa e restrinja a rede aos destinos necessários.
Registre o seguinte para cada exceção:
- Razão técnica: A capacidade ausente ou restrição do fornecedor, fundamentada por uma verificação de configuração.
- Controles compensatórios: 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, método de integração (onboarding) suportado ou substituição de hardware que encerraria a exceção.
Evite transformar uma rede de quarentena temporária em um local permanente para equipamentos não identificados. Uma exceção sem um proprietário ou condição de saída torna-se uma política de acesso não documentada. A abordagem defensável não são certificados a qualquer custo; é uma autenticação forte de dispositivos gerenciados ao lado de alternativas deliberadamente restritas.
Confirme seu plano de certificados antes da implementação
Uma demonstração bem-sucedida mostra que um laptop íntegro consegue se conectar. 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 handshake bem-sucedido.
Escolha um local piloto e identifique as classes de dispositivos no escopo antes de alterar o acesso de produção. Mapeie os recursos do ponto de acesso, o comportamento do suplicante e as versões de firmware. Onde um perfil de maior garantia for necessário, valide o modelo de certificado selecionado, as verificações da cadeia de certificados e o uso estendido de chave em relação aos endpoints representativos.
Torne concreta a revisão de prontidão desta semana
Use esta lista de verificação para expor proprietários ausentes e suposições não testadas.
- Confirmar suporte do dispositivo: Verifique se cada dispositivo no escopo pode armazenar e usar uma chave privada protegida, e não apenas importar um certificado.
- Confirmar confiança e renovação: Atribua proprietários para a cadeia da AC, serviço de inscrição, monitoramento de renovação e caminho de recuperação.
- Testar imposição: Demonstre aceitação, rejeição, revogação e encerramento de sessão ativa com suporte.
- Aprovar exceções: Forneça a cada classe sem suporte uma alternativa restrita, um proprietário responsável e uma data de revisão.
- Definir alertas acionáveis: Direcione eventos de expiração iminente e falhas de renovação para alguém que possa resolvê-los.
Utilize um procedimento repetível de RADIUS teste de autenticação para que os engenheiros coletem evidências comparáveis. Registre a condição do cliente, o resultado esperado, o resultado real e o código de falha relevante.
Avalie o piloto com base na capacidade de suporte
Execute o caminho do certificado ao lado da rede existente com um procedimento de reversão definido. Inclua inscrição remota, um ponto de extremidade recriado, uma reserva offline e os sistemas operacionais aos quais seu suporte oferece assistência. Não escolha apenas laptops provisionados recentemente.
Revise os chamados do suporte técnico ao lado dos logs de autenticação. Separe as falhas de certificado da cobertura sem fio, alocação de endereços e problemas de VLAN, para que a equipe não precise redimensionar a PKI para resolver uma falha não relacionada.
A aceitação do piloto deve significar que os dispositivos gerenciados normalmente se conectam sem a intervenção do usuário, as falhas têm causas identificadas e a revogaçã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 do início. Confirme o local, as classes de dispositivos, os proprietários e os critérios de aceitação esta semana e, em seguida, expanda somente após a equipe ter resolvido as falhas e comprovado a recuperação. Uma implantação menor com renovação e revogação confiáveis é uma base melhor do que uma implantação ampla que ninguém consegue reparar com confiança.
O Purple Access oferece acesso para colaboradores WiFi baseado em certificado por meio de EAP-TLS fornecido via MDM, além de acesso para convidados e por dispositivo nos pontos de acesso que você já possui. Visite o Purple Access para planejar um projeto piloto em uma unidade, validar o certificado e os caminhos de exceção e avaliar o resultado nos chamados de suporte e evidências de auditoria antes de expandir a implantação.
