Secure network: certificates, identity and PasspointAuthentication
Migrando o WiFi da equipe de uma senha compartilhada para 802.1X em uma infraestrutura multissite
Você será capaz de planejar e executar uma migração de WiFi para a equipe, de uma senha compartilhada para o IEEE 802.1X em todos os locais, sem a necessidade de uma virada de chave no fim de semana. Você pode organizar os dispositivos entre EAP-TLS, integração por Captive Portal ou chaves individuais por dispositivo...
15 min read

Execute um novo SSID WPA-Enterprise lado a lado com o SSID de senha compartilhada e migre os dispositivos em etapas. Dispositivos gerenciados recebem certificados EAP-TLS a partir do seu MDM. Telefones pessoais fazem o onboarding por meio de um Captive Portal. Dispositivos que não conseguem armazenar um certificado recebem sua própria chave em uma rede xPSK. Desative a senha compartilhada em cada local assim que o log de autenticação não mostrar mais nenhum dispositivo legado.
O que muda ao migrar o WiFi de funcionários de uma senha compartilhada para o 802.1X?
Uma senha compartilhada de funcionários é um único segredo mantido por cada colega, cada dispositivo e cada ex-funcionário. Quando alguém sai, continua com ela. Alterá-la significa inserir a chave novamente em cada caixa, tablet e notebook em todos os locais.
O requisito 2.3.2 do PCI DSS v4.0.1 transforma isso em uma obrigação. Ele engloba ambientes sem fio conectados ao ambiente de dados de portadores de cartão ou que transmitem dados de contas. Você deve alterar as chaves de criptografia sem fio sempre que alguém que as conheça sair da empresa ou da função que precisava delas. Você também deve alterá-las quando houver suspeita ou confirmação de que uma chave foi comprometida. Em uma empresa com alta rotatividade, uma leitura literal significa redefinir chaves quase todas as semanas.
O IEEE 802.1X remove o segredo compartilhado. É o padrão para controle de acesso à rede baseado em porta. Um dispositivo deve provar quem é antes que o ponto de acesso encaminhe seu tráfego. O ponto de acesso solicita a verificação via RADIUS, o protocolo que os equipamentos de rede usam para consultar um servidor de autenticação.
O EAP-TLS (Extensible Authentication Protocol com Transport Layer Security, RFC 5216) é a forma mais segura de responder a isso. O dispositivo e o servidor apresentam, cada um, um certificado. Não há senha para compartilhar, sofrer phishing ou anotar no quadro do escritório.
A identidade define então a VLAN (LAN virtual, um segmento de rede logicamente separado). O RADIUS retorna uma VLAN para cada dispositivo usando os atributos de túnel definidos no RFC 3580. Um notebook do financeiro e um tablet da cozinha podem se conectar ao mesmo SSID e ir para segmentos diferentes.
Onde isso se encaixa no Purple Access
O Purple Access executa três redes em uma única plataforma:
- Open: um Captive Portal, a página da web que um dispositivo visualiza antes de obter acesso à rede. Nesta migração, ele faz o onboarding de telefones pessoais.
- Secure: EAP-TLS, integração com provedor de identidade, Passpoint e RADIUS em nuvem. Notebooks, tablets e telefones de funcionários terminam aqui.
- xPSK: uma chave separada para cada dispositivo, chamada iPSK ou PPSK dependendo do seu fornecedor. Cada dispositivo que não pode armazenar um certificado termina aqui.
O WiFi de visitantes permanece em sua própria rede e fora deste projeto. O artigo Guest network security: A practical Guide for 2026 aborda esse aspecto. A filtragem de DNS em qualquer uma dessas redes é feita pelo Shield. Para uma visão mais ampla, consulte nosso guia sobre segurança de WiFi.
Comparativo dos modelos de credenciais
PEAP-MSCHAPv2 (Protected EAP com nome de usuário e senha) é a solução intermediária comum, por isso faz parte desta comparação.
| Modelo de credencial | O que cada dispositivo apresenta | O que uma pessoa ao sair leva consigo | Revogar uma pessoa ou dispositivo | Efeito em alterações de chave do PCI-DSS 2.3.2 | Recomendado para |
|---|---|---|---|---|---|
| PSK Compartilhada | Uma senha para todos | A chave de todos os locais | Trocar a chave de todos os dispositivos no SSID | Alterar a chave para todos sempre que a pessoa que saiu a conhecia | Um único local pequeno sem dados de cartão em WiFi |
| PEAP-MSCHAPv2 | Nome de usuário e senha pessoais | Sua própria senha até que a conta seja desativada | Desativar a conta | Sem chave compartilhada, mas as senhas podem ser capturadas se os certificados do servidor não forem validados | Locais que ainda não possuem uma autoridade certificadora |
| EAP-TLS | Um certificado por dispositivo ou pessoa | Nada utilizável após a revogação do certificado | Revogar o certificado ou desativar a identidade | Nenhuma chave compartilhada para alterar | Laptops gerenciados, tablets, dispositivos portáteis e telefones integrados |
| xPSK | Uma chave única por dispositivo | Apenas as chaves de dispositivos que ela digitou pessoalmente | Excluir a chave daquele dispositivo | Alterar apenas as chaves com as quais a pessoa que saiu teve contato | Caixas, terminais de cartão, impressoras, CFTV, sinalização digital |
O que você precisa antes de migrar uma senha compartilhada de WiFi para 802.1X?
Você não precisa de novos pontos de acesso. O Purple Access é independente de hardware e roda como uma sobreposição em nuvem para Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet. Você precisa ter seis itens prontos antes do piloto.
- Um inventário de dispositivos por local. Exporte a lista de clientes do SSID de funcionários do console de cada local, cobrindo pelo menos 14 dias. Classifique todos os dispositivos em uma de três categorias. Dispositivos gerenciados são aqueles inscritos no seu MDM (plataforma de gerenciamento de dispositivos móveis). Dispositivos pessoais são telefones de propriedade dos funcionários. Dispositivos headless são caixas, terminais de cartão, impressoras, câmeras e qualquer outro item sem um repositório de certificados.
- Um provedor de identidade com grupos organizados. Use Microsoft Entra ID, Okta ou Google Workspace. Cada grupo que precisa do seu próprio segmento se torna uma regra de VLAN. O artigo Autenticação WiFi com Okta: Etapas de Configuração, Opções e Correções detalha o lado do Okta.
- Uma autoridade certificadora que seu MDM possa consultar. Microsoft Intune, Jamf Pro e a maioria dos outros MDMs emitem certificados via SCEP (Simple Certificate Enrollment Protocol) ou perfis PKCS. Decida agora se o certificado identifica o dispositivo ou a pessoa. Tablets e dispositivos portáteis compartilhados precisam de certificados de dispositivo.
- Um plano de VLAN levado a todos os locais. Um plano típico tem cinco segmentos: funcionários, dispositivos corporativos gerenciados, dispositivos de pagamento, outros dispositivos headless e um segmento legado restrito. Confirme se o trunk do switch para cada ponto de acesso carrega cada VLAN.
- Purple Access configurado como o servidor RADIUS para o SSID seguro. Onde seu fabricante usa RADIUS para chaves por dispositivo, aponte a rede xPSK para ele também. RADIUS em nuvem significa nada para instalar, atualizar ou agrupar nos locais.
- Um responsável nomeado em cada local. Você precisa de alguém que possa identificar os dispositivos desconhecidos no inventário e aprovar o desligamento.
Como migrar o WiFi da equipe para o 802.1X sem um final de semana de transição?
Três princípios eliminam o final de semana de transição. Construa as novas redes ao lado da antiga. Mova os dispositivos por classe, não por local. Desligue local por local, com base em evidências do log de autenticação.
Você pode executar ambos os SSIDs durante a migração?
Sim, e você deve executá-los juntos durante todo o projeto. A questão real é o tempo de transmissão (airtime). Cada SSID transmitido adiciona quadros de beacon em cada rádio, portanto, os guias de design de fornecedores, como o da Cisco Meraki, recomendam manter a contagem de SSIDs baixa.
A solução ideal é transformar o SSID antigo na rede xPSK. Mantenha seu nome e modo de segurança. Adicione a senha compartilhada antiga como uma chave na lista de chaves por dispositivo, mapeada para a VLAN legada restrita. Os dispositivos que conhecem a senha antiga se reconectam sem perceber. Cada dispositivo que você move recebe sua própria chave.
Quando a chave legada não tiver mais dispositivos em um local, você a exclui. A senha compartilhada é então desativada e nenhum novo SSID é exibido. Seu estado final é de três SSIDs: visitante, equipe segura e xPSK.
Teste isso em um local primeiro. Vários fornecedores executam recursos por chave no WPA2-Personal em vez do WPA3-SAE, portanto, verifique a documentação do seu fornecedor. Se a sua plataforma não puder reter a senha antiga como uma chave, execute quatro SSIDs durante a migração e remova o SSID antigo no desligamento.
Fase 1: construa uma vez, aplique em toda a propriedade
Configure o SSID seguro e a rede xPSK uma vez e, em seguida, aplique-os a cada local a partir de um modelo. Use WPA3-Enterprise onde sua frota gerenciada for compatível, caso contrário, use um modo de transição WPA2/WPA3.
| Fornecedor | Console | Configuração de SSID seguro | Recurso de chave por dispositivo | Aplicar em todos os locais com |
|---|---|---|---|---|
| Cisco Meraki | Meraki Dashboard | Enterprise com meu servidor RADIUS | Identity PSK (iPSK) | Modelos de configuração |
| HPE Aruba | Aruba Central | Nível de segurança Enterprise | MPSK | Grupos |
| Ruckus | SmartZone ou RUCKUS One | Autenticação 802.1X EAP | Dynamic PSK (DPSK) | Zonas ou locais |
| Juniper Mist | Portal Mist | Segurança WLAN Enterprise (802.1X) | Multi PSK | Modelos de WLAN |
| Ubiquiti UniFi | UniFi Network | WPA Enterprise com um perfil RADIUS | Private Pre-Shared Keys | Configurações por local |
Rótulos mudam entre versões de firmware, portanto, siga a documentação do seu fornecedor para o caminho atual. Mais tutoriais de configuração estão disponíveis em nossos Manuais de acesso.
Fase 2: piloto em dois ou três locais representativos
Escolha locais que se diferenciem: um local grande, um pequeno e um com um modelo de switch incomum. Execute todas as fases posteriores de ponta a ponta nesses locais primeiro. O piloto existe para encontrar o trunk que não carrega uma VLAN, o caixa que aceita apenas WPA2 e o perfil MDM que se instala na ordem errada.
Fase 3: envie certificados para dispositivos gerenciados por meio do MDM
Dispositivos gerenciados evoluem mais rápido porque o MDM atinge todos os locais de uma só vez. Implante três perfis em ordem: o certificado raiz de confiança, o certificado do dispositivo e, em seguida, o perfil de WiFi. A maioria dos MDMs falha no perfil de WiFi se o certificado ao qual ele se refere estiver ausente.
O perfil de WiFi nomeia o SSID seguro, define o EAP-TLS e fixa o nome do certificado e a raiz do servidor RADIUS. Assim que um dispositivo for autenticado no SSID seguro, envie um perfil que remova a rede legada. Caso contrário, o dispositivo pode migrar de volta para o SSID antigo no qual já confia.
Fase 4: integrar telefones pessoais ao mesmo SSID
A equipe se conecta à rede aberta, geralmente escaneando um código QR fixado no escritório interno. Eles fazem login no Captive Portal com sua identidade de trabalho e recebem o perfil de rede segura. Nosso pilar de Captive portals cobre o design de portais.
Um perfil Passpoint (Hotspot 2.0) é o que mais ajuda uma propriedade com vários locais. O Passpoint permite que um telefone encontre e se conecte a uma rede por meio de sua credencial, e não pelo nome do SSID. Assim, uma única integração funciona em todos os locais. Mapeie os telefones pessoais para uma VLAN de equipe exclusiva para internet, longe dos segmentos de pagamento e do escritório interno. Execute a integração por região para que o suporte veja um fluxo constante, e não um pico.
Fase 5: mover todos os dispositivos que não podem ter um certificado para sua própria chave
Forneça a cada dispositivo headless uma chave exclusiva e mapeie as chaves por classe para as VLANs. Terminais de cartão vão para o segmento de pagamento e câmeras para o segmento de câmeras. Registre o dispositivo, endereço MAC, local, chave e a pessoa que a inseriu.
Impressoras e gravadores de câmera geralmente têm interfaces web que você pode reconfigurar a chave remotamente. Caixas e terminais podem precisar da plataforma de gerenciamento do fornecedor ou de uma visita ao local. O guia PPSK for retail store devices: a deployment checklist for tills, scanners and CCTV on Cisco Meraki and Juniper Mist cobre esta fase em detalhes.
Quanto tempo leva uma implementação 802.1X em vários locais?
Considere as durações abaixo como premissas de planejamento a serem testadas em seu piloto, e não como pontos de referência. Os dispositivos headless dão o ritmo, pois são a única classe que pode precisar de intervenção no local.
| Fase | O que acontece | Escopo | Duração do planejamento |
|---|---|---|---|
| 0. Preparar | Inventário, grupos de identidade, plano de VLAN, autoridade de certificação | Toda a propriedade, sem alterações nos dispositivos | 2 - 3 semanas |
| 1. Construir | SSID seguro e rede xPSK em modelos | Toda a propriedade | 1 semana |
| 2. Piloto | Cada fase de ponta a ponta | 2 - 3 locais | 3 - 4 semanas |
| 3. Dispositivos gerenciados | O MDM envia certificados e perfil de WiFi | Todos os locais de uma só vez | 2 semanas mais 2 semanas para atrasados |
| 4. Telefones pessoais | Integração por meio da rede aberta | 20 - 30 locais por onda | 2 semanas por onda |
| 5. Dispositivos headless | Chave exclusiva por dispositivo | Remoto ou visita ao local | Meio dia por local, executado em paralelo |
| 6. Desativação | Excluir a chave legada | Por local | Mínimo de 14 dias sem problemas por local |
As Fases 3, 4 e 5 se sobrepõem. Com base nessas premissas, planeje de 10 a 14 semanas em 50 locais e de 20 a 26 semanas em 200.
Cenário prático: um grupo de 64 hotéis usando Cisco Meraki
Valores ilustrativos. Cada hotel executava cerca de 40 dispositivos em uma única chave compartilhada de equipe. Isso significava 22 dispositivos gerenciados, seis telefones pessoais e 12 dispositivos sem tela: terminais de cartão, impressoras de recibos e players de sinalização. A equipe de governança terceirizada conhecia a chave, portanto, cada rotação de agência disparava a condição de desligamento do PCI DSS 2.3.2.
A equipe converteu o SSID legado para iPSK e manteve a senha antiga como uma chave em uma VLAN restrita. Eles criaram o SSID Enterprise em um modelo de configuração. O Intune enviou certificados para todos os 1.408 dispositivos gerenciados na terceira semana após o piloto. Os gerentes de plantão registraram 384 telefones pessoais região por região. Os engenheiros reconfiguraram as chaves dos 768 dispositivos sem tela durante as visitas de manutenção programadas.
Resultado: na nona semana, a chave mecenas mantinha apenas dispositivos sem tela. O último hotel a excluiu na semana 16, sem necessidade de uma noite de transição. Agora, o desligamento de um funcionário significa desativar uma conta, em vez de alterar as chaves de 2.560 dispositivos em 64 hotéis.
Cenário prático: um varejista de 180 lojas usando Juniper Mist
Valores ilustrativos. Cada loja executava 27 dispositivos na chave compartilhada: 12 leitores portáteis, três PCs de retaguarda, quatro impressoras de etiquetas, seis câmeras e dois telefones de gerentes. A reconfiguração de chaves após desligamentos havia parado, porque ninguém conseguia atender a todas as lojas no mesmo dia.
Leitores e PCs foram migrados para EAP-TLS por meio do MDM, totalizando 2.700 dispositivos. Impressoras e câmeras foram migradas para Multi PSK, com 1.800 chaves exclusivas mapeadas para duas VLANs. As lojas foram migradas em seis ondas de 30. O piloto identificou um formato de loja cujos switches não faziam o trunking da VLAN de câmeras. A equipe corrigiu o modelo antes da primeira onda.
Resultado: a contagem de dispositivos legados por loja chegou a zero em todas as 180 lojas até a semana 22. Nenhuma chave compartilhada de equipe existe mais em todo o parque de dispositivos.
Como você verifica se a migração funciona, local por local?
Comprove cada fase no piloto
Execute quatro testes em cada local piloto antes de expandir:
- Teste de conexão: um novo dispositivo gerenciado, um telefone registrado e um caixa com a chave reconfigurada se conectam de primeira.
- Teste de VLAN: cada dispositivo chega ao segmento que sua identidade ou chave deve definir.
- Teste de roaming: um leitor portátil mantém sua sessão ativa ao caminhar entre pontos de acesso.
- Teste de desligamento: desative uma identidade de teste e revogue seu certificado, depois confirme se a próxima autenticação é recusada.
Meça o progresso por local a partir do log de autenticação
Relate três números por local a cada semana, usando o log de autenticação e a lista de clientes do controlador:
- Dispositivos se autenticando com EAP-TLS no SSID seguro.
- Dispositivos em sua própria chave xPSK.
- Dispositivos que ainda usam a chave legada.
O progresso é o resultado dos dois primeiros divididos por todos os dispositivos de funcionários distintos detectados nos últimos 14 dias. Ordene os locais pela contagem legada e direcione o esforço para onde a contagem for mais alta. Conte os telefones pessoais por identidade, não por endereço MAC. O iOS e o Android randomizam endereços MAC por rede, portanto, um telefone pode parecer dois.
Quando desligar a senha compartilhada?
Exclua a chave legada em um local quando todas as quatro condições forem atendidas:
- A contagem legada estiver zerada por 14 dias consecutivos, cobrindo dois ciclos completos de escala.
- Cada dispositivo headless no inventário tiver sua própria chave.
- Os chamados do suporte técnico para esse local voltarem ao nível básico.
- O responsável pelo local tiver dado a aprovação final.
Registre a data. A partir de então, nenhuma chave compartilhada existirá para que a norma 2.3.2 exija alteração. Seu registro de chaves e o log de autenticação tornam-se evidências para o requisito. Se um dispositivo esquecido aparecer posteriormente, atribua a ele sua própria chave. Nunca restaure a chave compartilhada.
O que pode dar errado em uma implantação do 802.1X em múltiplos locais e como corrigir?
Dispositivos retornam ao SSID legado
Os dispositivos se lembram de ambas as redes e podem preferir a antiga. Remova a rede legada via perfil de MDM assim que o SSID seguro estiver funcionando. Nos telefones pessoais, inclua "esquecer a rede antiga" nas instruções de integração.
Dispositivos se conectam sem validar o servidor
Um perfil de WiFi que ignora a validação do certificado do servidor confiará em um ponto de acesso falso que esteja transmitindo o mesmo SSID. Fixe a raiz confiável e o nome do servidor RADIUS em todos os perfis.
Clientes se autenticam, mas não recebem endereço IP
O RADIUS atribuiu uma VLAN que o trunk do switch não carrega. Audite os trunks em cada modelo de switch no projeto piloto e, em seguida, corrija o modelo, não o local individual.
Laptops Windows falham no PEAP
A Microsoft documenta que o Windows Defender Credential Guard bloqueia o logon único do MSCHAPv2 com credenciais salvas. Mover esses laptops para o EAP-TLS remove a dependência de senhas.
Certificados expiram em toda a infraestrutura ao mesmo tempo
Certificados emitidos em um único envio expiram na mesma semana. Configure a renovação automática no MDM bem antes da expiração e escalone o envio inicial se sua autoridade certificadora permitir.
O excesso de SSIDs desacelera todas as redes
Executar SSIDs de visitantes, legados, seguros e xPSK juntos adiciona uma carga de beacon em cada rádio. Converta o SSID legado na rede xPSK, conforme descrito acima, para manter a contagem em três.
Quanto custa uma migração para 802.1X e qual é o retorno?
Os custos envolvem licenças e mão de obra, não hardware. Você paga pelo Purple Access, além do trabalho com perfis de MDM, visitas aos locais para dispositivos headless e tempo de suporte técnico durante as ondas de integração. Pontos de acesso, switches e controladores permanecem como estão.
O retorno é o que você deixa de fazer. No cenário de varejo, uma única rotação da chave compartilhada em toda a empresa significava inseri-la novamente em 4.860 dispositivos. Assumindo três minutos por dispositivo, isso representa 243 horas de trabalho da equipe por rotação. Após a migração, a saída de um funcionário significa apenas desativar uma identidade, além de alterar as chaves de quaisquer dispositivos que essa pessoa tenha configurado.
Você também obtém um log de autenticação de qual identidade ou chave se conectou a qual local e quando. Esse log é uma evidência para o PCI-DSS 2.3.2 e para revisões de direitos de acesso sob o controle 5.18 do Anexo A da ISO 27001. A Purple possui certificação ISO 27001 e Cyber Essentials e opera com 99,999% de uptime em mais de 80.000 locais ativos. Esse tempo de atividade é essencial quando o RADIUS decide se os funcionários podem trabalhar.
Perguntas frequentes
Precisamos de novos pontos de acesso para migrar o WiFi dos funcionários para 802.1X?
Não. O 802.1X e as chaves por dispositivo funcionam nos pontos de acesso que você já possui. O Purple Access é agnóstico em relação ao hardware e funciona como uma camada em nuvem sobre Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet. Você configura um SSID Enterprise apontando para o RADIUS em nuvem da Purple, além de uma rede de chaves por dispositivo usando o recurso próprio do seu fornecedor. A única verificação física é garantir que cada trunk de switch transporte as novas VLANs.
Podemos executar o SSID de senha compartilhada e o SSID 802.1X ao mesmo tempo?
Sim, e você deve fazer isso, pois executar ambos é o que elimina a necessidade de uma migração no final de semana. Onde sua plataforma permitir, converta o SSID legado na rede xPSK. Mantenha a senha antiga como uma chave em uma VLAN restrita, para que os dispositivos continuem funcionando enquanto você os migra. Exclua essa chave em cada local assim que o log de autenticação mostrar que nenhum dispositivo a utiliza por 14 dias consecutivos.
O que acontece com os dispositivos que não suportam 802.1X?
Eles são migrados para a rede xPSK, cada um com sua própria chave. Caixas registradoras, terminais de cartão, impressoras, câmeras e reprodutores de sinalização digital raramente possuem um certificado, mas quase todos aceitam uma frase secreta WPA2. Cada chave é mapeada para uma VLAN para sua classe de dispositivo, permitindo revogar um dispositivo sem afetar nenhum outro. Mantenha um registro de quem inseriu cada chave, pois o PCI-DSS 2.3.2 ainda se aplica às chaves que um ex-colaborador conhecia.
Quanto tempo leva uma migração 802.1X em vários locais?
Planeje de 10 a 14 semanas para 50 locais e de 20 a 26 semanas para 200 locais, e depois teste essas suposições em seu projeto piloto. Os dispositivos gerenciados são migrados mais rapidamente porque o MDM os envia para todos os locais de uma só vez. Dispositivos sem interface de usuário ditam o ritmo, pois alguns exigem uma visita ao local. Cada local precisa de pelo menos 14 dias sem ocorrências no log de autenticação antes de desativar a senha compartilhada.
O 802.1X torna o WiFi dos nossos funcionários em conformidade com o PCI-DSS?
Nenhum controle isolado faz isso, e o seu auditor é quem faz a avaliação. O EAP-TLS e as chaves por dispositivo fornecem evidências para o requisito 2.3.2 do PCI-DSS v4.0.1. Quando não existe mais uma chave compartilhada, o desligamento de um funcionário não força mais uma alteração de chave em toda a infraestrutura. O log de autenticação mostra qual identidade ou chave se conectou a qual local e quando, o que também dá suporte às revisões de direitos de acesso sob a ISO 27001.
Devemos usar PEAP com senhas em vez de certificados?
Use EAP-TLS sempre que possível. O PEAP-MSCHAPv2 remove a chave compartilhada, mas ainda depende de senhas. Essas senhas podem ser capturadas se um dispositivo não validar o certificado do servidor. A Microsoft também documenta que o Windows Defender Credential Guard bloqueia o logon único do MSCHAPv2 com credenciais salvas. Isso interrompe o WiFi baseado em senha em muitos notebooks Windows gerenciados. Os certificados enviados pelo seu MDM evitam ambos os problemas e não exigem nenhuma ação da equipe.
Precisamos de servidores RADIUS locais para 802.1X?
Não. O Purple Access oferece RADIUS na nuvem, portanto não há nada para instalar, aplicar patchs ou tornar resiliente em cada local. Seus pontos de acesso enviam solicitações de autenticação para o Purple. O Purple verifica o certificado ou chave, aplica regras de identidade do Microsoft Entra ID, Okta ou Google Workspace e retorna a VLAN. O Purple opera com 99,999% de disponibilidade e possui as certificações ISO 27001 e Cyber Essentials.
Os funcionários podem usar telefones pessoais no mesmo SSID 802.1X?
Sim, se sua política permitir. Os funcionários entram na rede aberta, fazem login no captive portal com sua identidade corporativa e recebem o perfil de rede seguro. Um perfil Passpoint conecta o telefone automaticamente em todos os locais da propriedade. Mapeie telefones pessoais para uma VLAN de funcionários apenas com acesso à internet, longe dos segmentos de pagamento e back-office. Teste no piloto se o seu processo de desligamento de funcionários remove o acesso deles.
Frequently asked questions
Precisamos de novos pontos de acesso para migrar o WiFi da equipe para o 802.1X?
Não. O 802.1X e as chaves por dispositivo funcionam nos pontos de acesso que você já possui. O Purple Access é agnóstico em relação ao hardware e funciona como uma camada em nuvem no Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet. Você configura um SSID Enterprise apontando para o RADIUS em nuvem do Purple, além de uma rede de chaves por dispositivo usando o recurso do próprio fornecedor. A única verificação física necessária é garantir que cada tronco do switch carregue as novas VLANs.
Podemos executar o SSID com senha compartilhada e o SSID 802.1X ao mesmo tempo?
Sim, e você deve fazer isso, pois executar ambos é o que elimina a necessidade de um final de semana de transição. Onde sua plataforma permitir, converta o SSID legado na rede iPSK. Mantenha a senha antiga como uma chave em uma VLAN restrita, para que os dispositivos continuem funcionando enquanto você os migra. Exclua essa chave em cada local assim que o log de autenticação mostrar que nenhum dispositivo a utiliza por 14 dias consecutivos.
O que acontece com os dispositivos que não suportam 802.1X?
Eles mudam para a rede xPSK, cada um com sua própria chave. Caixas registradoras, terminais de cartão, impressoras, câmeras e reprodutores de sinalização raramente possuem um certificado, mas quase todos aceitam uma frase secreta WPA2. Cada chave se mapeia para uma VLAN para sua classe de dispositivo, para que você possa revogar um dispositivo sem afetar nenhum outro. Mantenha um registro de quem inseriu cada chave, pois a PCI-DSS 2.3.2 ainda se aplica às chaves que um ex-funcionário conhecia.
Quanto tempo leva uma migração 802.1X em vários locais?
Planeje de 10 a 14 semanas para 50 locais e de 20 a 26 semanas para 200 locais e, em seguida, teste essas suposições em seu piloto. Dispositivos gerenciados mudam mais rápido porque o MDM envia as configurações para todos os locais de uma só vez. Dispositivos headless dão o ritmo, pois alguns exigem uma visita ao local. Cada local precisa de pelo menos 14 dias sem erros no log de autenticação antes de você desativar a senha compartilhada.
O 802.1X torna o nosso WiFi de funcionários em conformidade com a PCI-DSS?
Nenhum controle único faz isso isoladamente, e o seu avaliador faz o julgamento. EAP-TLS e chaves por dispositivo fornecem evidências para o requisito 2.3.2 da PCI-DSS v4.0.1. Como não existe uma chave compartilhada, o desligamento de um funcionário não força mais a alteração da chave em toda a empresa. O log de autenticação mostra qual identidade ou chave se conectou a qual local e quando, o que também apoia as revisões de direitos de acesso da ISO 27001.
Devemos usar PEAP com senhas em vez de certificados?
Use EAP-TLS sempre que puder. O PEAP-MSCHAPv2 remove a chave compartilhada, mas ainda depende de senhas. Essas senhas podem ser capturadas se um dispositivo não validar o certificado do servidor. A Microsoft também documenta que o Windows Defender Credential Guard bloqueia o logon único do MSCHAPv2 com credenciais salvas. Isso interrompe o WiFi baseado em senha em muitos notebooks gerenciados com Windows. Os certificados enviados pelo seu MDM evitam ambos os problemas e não exigem nenhuma ação dos funcionários.
Precisamos de servidores RADIUS locais para o 802.1X?
Não. O Purple Access fornece RADIUS em nuvem, portanto não há nada para instalar, atualizar ou tornar resiliente em cada local. Seus pontos de acesso enviam solicitações de autenticação para o Purple. O Purple verifica o certificado ou a chave, aplica as regras de identidade do Microsoft Entra ID, Okta ou Google Workspace e retorna a VLAN. O Purple opera com 99,999% de disponibilidade e possui as certificações ISO 27001 e Cyber Essentials.
Os funcionários podem usar telefones pessoais no mesmo SSID 802.1X?
Sim, se a sua política permitir. Os funcionários se conectam à rede aberta, fazem login no Captive Portal com sua identidade de trabalho e recebem o perfil de rede seguro. Um perfil Passpoint conecta o telefone automaticamente em todos os locais da empresa. Mapeie os telefones pessoais para uma VLAN de funcionários exclusiva para internet, longe dos segmentos de pagamento e back-office. Teste no piloto se o seu processo de desligamento de funcionários remove o acesso deles.