Como Configurar WiFi Enterprise em Dispositivos Android com a EAP-TLS

O Android liga-se a um WiFi empresarial com EAP-TLS quando se verificam três condições. O dispositivo possui o seu próprio certificado de cliente. Confia na CA de raiz que assinou o seu certificado de servidor RADIUS. O seu perfil WPA2 ou WPA3-Enterprise utiliza o método EAP TLS, com um Domínio correspondente a esse certificado de servidor. Envie os três elementos a partir do seu MDM para configurar frotas inteiras sem tocar num único dispositivo.

O que faz realmente o EAP-TLS num dispositivo Android?

O IEEE 802.1X é o padrão para controlo de acesso à rede baseado em portas. No WiFi, o ponto de acesso não transfere tráfego de um dispositivo até que um servidor de autenticação o aprove. Esse servidor é um servidor RADIUS, o serviço que aceita ou rejeita cada pedido de ligação. O dispositivo Android é o suplicante, o ponto de acesso é o autenticador e o RADIUS é o servidor de autenticação.

O EAP-TLS (Extensible Authentication Protocol with Transport Layer Security, definido no RFC 5216) é a forma como ambas as partes provam quem são. Utiliza certificados X.509 e não palavras-passe. A verificação ocorre em ambas as direções:

1. O servidor RADIUS apresenta o seu certificado. O Android verifica se este se encadeia numa autoridade de certificação (CA) de raiz de confiança. Também verifica se o nome do certificado corresponde ao Domínio no perfil WiFi.
2. O dispositivo Android apresenta o seu próprio certificado de cliente. O RADIUS verifica se foi emitido pela sua CA, se está dentro da validade e se não foi revogado.

Como não existe palavra-passe, não há nada para ser alvo de phishing, reutilizado ou redefinido. O PEAP (Protected EAP) com MSCHAPv2 funciona de forma diferente: envia um nome de utilizador e palavra-passe dentro de um túnel TLS. Uma palavra-passe PEAP roubada funciona em qualquer dispositivo. A chave privada de um certificado de cliente permanece no dispositivo para o qual foi emitida.

Comportamentos do Android que surpreendem as equipas

Quatro comportamentos do Android moldam qualquer implementação:

• A validação do servidor é obrigatória. A partir do Android 11, a Google removeu a opção de ignorar a validação do certificado de servidor em redes empresariais. Todos os perfis precisam de um certificado CA e de um Domínio, caso contrário o dispositivo não se ligará.
• A utilização expandida da chave é importante. O certificado do servidor RADIUS necessita da utilização expandida da chave (EKU) Server Authentication, OID 1.3.6.1.5.5.7.3.1. Emita certificados de cliente com Client Authentication, OID 1.3.6.1.5.5.7.3.2.
• As instalações manuais requerem PKCS#12. O Android exige o certificado de cliente e a chave privada agrupados num único ficheiro .p12 ou .pfx.
• Os endereços MAC são aleatórios. Desde o Android 10, os dispositivos utilizam por predefinição um endereço MAC aleatório por rede. Nunca crie identidades ou políticas de acesso com base em endereços MAC.

Como se compara o EAP-TLS com as alternativas

O que precisa antes de configurar Android para EAP-TLS?

Garanta estes seis elementos antes de mexer num dispositivo. A maioria das implementações mal-sucedidas deve-se à falta de um deles.

• Uma infraestrutura de chaves públicas (PKI). Precisa de uma CA para emitir certificados de cliente. Se já opera uma CA interna, como o Microsoft Active Directory Certificate Services, esta pode emitir certificados de servidor e de cliente.
• Um certificado de servidor RADIUS criado para Android. Necessita de um Subject Alternative Name (SAN) com um nome DNS. Também precisa do EKU de Autenticação de Servidor e de uma cadeia até à raiz que irá distribuir. Configure o RADIUS para enviar a cadeia completa, incluindo os intermediários.
• RADIUS configurado para EAP-TLS. Deve confiar na CA que emite os certificados de cliente. Também deve verificar a revogação através de uma lista de revogação de certificados (CRL) ou OCSP (Online Certificate Status Protocol).
• Um SSID Enterprise nos seus pontos de acesso. Defina WPA2-Enterprise ou WPA3-Enterprise e aponte para o RADIUS. Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet suportam 802.1X.
• Um MDM inscrito através do Android Enterprise. A gestão de dispositivos móveis (MDM) é a única forma prática de emitir e renovar certificados para além de um projeto-piloto. Ligue-o à sua CA com SCEP, o protocolo de pedido de certificado definido na RFC 8894.
• Um plano de atribuição de nomes e VLAN. Decida que identidade é incluída em cada certificado de cliente, como o ID do dispositivo ou o nome de início de sessão do funcionário. Depois, decida a que VLAN (VLAN, um segmento de rede logicamente separado) se junta cada grupo de dispositivos.

Como configurar EAP-TLS no Android?

Tem dois caminhos. A configuração manual valida o seu projeto num número reduzido de dispositivos. Os perfis distribuídos por MDM aplicam-no a toda a infraestrutura.

Opção 1: configuração manual para projetos-piloto e pequenos grupos

Os caminhos dos menus variam entre versões do Android e fabricantes, pelo que deve seguir as etiquetas dos campos em vez de um caminho fixo.

1. Entregue os ficheiros em segurança. O dispositivo precisa do certificado da CA raiz e de um ficheiro .p12 com o seu certificado de cliente e chave privada. Envie a palavra-passe do .p12 através de um canal separado.
2. Instale os certificados. Abra o instalador de certificados nas definições de segurança do dispositivo. Instale a CA raiz como um certificado WiFi, depois instale o ficheiro .p12 e introduza a respetiva palavra-passe.
3. Adicione a rede. Nas definições de WiFi, adicione uma rede manualmente e introduza o SSID exatamente como definido.
4. Escolha a segurança Enterprise. Selecione a opção WPA2-Enterprise ou WPA3-Enterprise. As etiquetas variam consoante a versão.
5. Defina o método EAP para TLS.
6. Defina o certificado CA. Selecione a raiz que instalou. Se uma CA pública tiver emitido o seu certificado RADIUS, escolha a opção de certificados do sistema.
7. Defina o estado do certificado online. "Solicitar estado do certificado" pede ao RADIUS o estado OCSP do seu próprio certificado.
8. Defina o Domínio. Insira o nome DNS a partir do SAN do certificado RADIUS. Este é o campo em que a maioria das equipas erra.
9. Selecione o certificado de cliente. Escolha o certificado instalado a partir do ficheiro .p12.
10. Defina a Identidade. Utilize o nome constante no certificado de cliente, como o ID do dispositivo, e nunca um endereço MAC.

A configuração manual tem um custo oculto. Todos os certificados expiram e cada dispositivo precisará novamente do mesmo trabalho manual.

Opção 2: Perfis enviados via MDM através do Android Enterprise

O Android Enterprise é a estrutura da Google para gerir dispositivos Android. Três dos seus modos são relevantes aqui:

• Totalmente gerido adequado para telemóveis e tablets da empresa.
• Perfil de trabalho isola aplicações e certificados corporativos em dispositivos pessoais.
• Dedicado adequado para dispositivos portáteis de utilização única, quiosques e terminais POS.

A ordem de criação é a mesma no Microsoft Intune, Workspace ONE e na maioria das outras plataformas MDM:

1. Ligue o MDM à sua CA. Instale o conector SCEP para que o MDM possa intermediar os pedidos de certificados.
2. Envie um perfil de certificado fidedigno. Este distribui a sua CA raiz, e quaisquer intermediárias, para todos os dispositivos.
3. Envie um perfil de certificado SCEP. O dispositivo gera a sua própria chave privada e solicita um certificado de cliente. Defina o assunto ou SAN a partir de uma variável do dispositivo. Defina também a EKU de Autenticação do Cliente, o período de validade e o limite de renovação.
4. Envie o perfil de WiFi. Defina o SSID, a segurança Enterprise e o tipo EAP TLS. Selecione o perfil SCEP como o certificado de cliente. Para a confiança no servidor, selecione o perfil de CA raiz e insira o nome do servidor RADIUS a partir do seu SAN.
5. Atribua primeiro a um grupo piloto. Analise os registos RADIUS durante vários dias antes de alargar a atribuição.

Com o SCEP, a chave privada nunca sai do dispositivo. O MDM renova os certificados antes de expirarem, mantendo os dispositivos ligados sem necessidade de criar um pedido de suporte. Para obter instruções passo a passo com capturas de ecrã, consulte a documentação do seu fornecedor de MDM.

Qual é o método adequado para o seu parque informático?

Como é o aspeto prático de uma implementação de EAP-TLS em Android?

Cenário prático: um hotel com 200 quartos a descontinuar uma palavra-passe de funcionários partilhada

Situação. As equipas de limpeza, manutenção e receção partilhavam 60 dispositivos Android. Todos ligados a uma rede WPA2-Personal cuja palavra-passe não mudava desde a abertura. Antigos funcionários ainda a sabiam. Alterá-la significava reconfigurar 60 dispositivos manualmente.

O que foi feito. A equipa de TI registou os dispositivos como dispositivos Android Enterprise totalmente geridos. O MDM enviou a AC raiz, um certificado de cliente SCEP válido por 12 meses e um perfil de WiFi EAP-TLS. O RADIUS colocou todos os dispositivos aceites na VLAN de operações. Os hóspedes permaneceram numa rede de Guest WiFi separada com o seu próprio Captive Portal, a página de início de sessão apresentada antes do acesso à internet.

Resultado. A palavra-passe partilhada foi descontinuada nos 60 dispositivos. Um dispositivo perdido agora custa apenas a revogação de um certificado; os outros 59 dispositivos não são afetados. Os funcionários não têm qualquer palavra-passe de WiFi para esquecer, pelo que as reposições de palavras-passe de WiFi param por completo. Mais sobre o setor em Hotéis.

Cenário prático: uma cadeia de retalho com 150 lojas no âmbito do PCI DSS

Situação. Cada loja operava quatro terminais de inventário e dois tablets POS em Android: 900 dispositivos no total. O WiFi das lojas transmitia tráfego de pagamentos, colocando-o no âmbito do PCI DSS. O Requisito 4.2.1.2 do PCI DSS v4.0 exige criptografia forte para autenticação e transmissão sem fios. Uma chave partilhada rotacionada loja a loja era difícil de comprovar.

O que foi feito. A equipa de TI registou cada dispositivo como um dispositivo Android Enterprise dedicado. O perfil SCEP escreveu a função de cada dispositivo no seu certificado. O RADIUS correspondeu a esse campo e devolveu uma VLAN utilizando os atributos de túnel do RFC 3580. Os tablets POS juntaram-se à VLAN de pagamentos; os terminais portáteis juntaram-se à VLAN de inventário. Os clientes utilizaram um SSID de Guest WiFi separado, com o WiFi Analytics a gerar relatórios apenas sobre essa rede.

Resultado. Todos os 900 dispositivos foram registados sem que um colega de loja tivesse de introduzir uma credencial. A rotação de chaves em 150 lojas terminou. Cada ligação aparece agora nos registos RADIUS associada ao certificado de um dispositivo identificado, fornecendo ao auditor evidências por dispositivo. Mais sobre o setor em Retalho.

Como verificar se o Android se está a autenticar com EAP-TLS?

Um ícone de ligado apenas prova que o dispositivo se ligou a algo. Verifique três camadas e, em seguida, comprove que os controlos falham em modo fechado.

• No dispositivo. Os detalhes da rede mostram o SSID ligado e um endereço IP da VLAN esperada.
• No servidor RADIUS. O registo mostra um Access-Accept, o tipo de EAP TLS e o assunto do certificado de cliente apresentado.
• No controlador WiFi ou painel de controlo. O registo do cliente mostra 802.1X com WPA2 ou WPA3-Enterprise, juntamente com a VLAN atribuída pelo RADIUS.

Em seguida, execute quatro testes negativos num dispositivo piloto:

1. Revogue o seu certificado, publique a CRL e volte a ligar. Deve esperar um Access-Reject.
2. Altere o domínio do perfil para um nome incorreto. O Android deve recusar o servidor.
3. Instale um certificado de cliente de uma CA diferente. Espere um Access-Reject.
4. Emita um certificado de curta duração. Confirme que o MDM o renova sem que o dispositivo perca a ligação.

Se todos os quatro se comportarem como esperado, o seu projeto é sólido.

O que corre mal com o EAP-TLS em Android e como pode resolver?

A maioria das falhas reside na cadeia de certificados ou no perfil, não na rádio.

Onde se enquadra a Purple ao lado do EAP-TLS?

O EAP-TLS é o controlo certo para os dispositivos que possui e gere. O seu espaço também acolhe pessoas cujos dispositivos nunca irá gerir.

• WiFi de convidados num SSID próprio. O WiFi de convidados oferece a visitantes, clientes e passageiros um Captive Portal personalizado com consentimentos de escolha consciente. Isto recolhe dados de primeira entidade em conformidade com o GDPR. O WiFi Analytics gera relatórios sobre essa rede, mantida separada do tráfego EAP-TLS.
• WiFi de funcionários para dispositivos sem MDM. As Redes Baseadas em Identidade da Purple, incluindo o SecurePass e iPSK, dão a cada pessoa a sua própria credencial. O acesso liga-se ao Microsoft Entra ID, Okta ou Google Workspace, para que as entradas, alterações e saídas sejam geridas a partir do seu diretório.
• O hardware que já possui. A Purple é uma sobreposição na nuvem agnóstica de hardware para Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. Não é necessária qualquer substituição de equipamento.

A divisão funciona em todos os setores. Na Saúde, os dispositivos Android clínicos utilizam EAP-TLS, enquanto os pacientes e visitantes utilizam WiFi de convidados. Nos Comboios, os tablets da tripulação utilizam EAP-TLS e os passageiros utilizam WiFi de convidados. A Purple opera em mais de 80 000 locais ativos em mais de 90 países (dados da Purple) e possui as certificações ISO 27001 e Cyber Essentials.

Quanto custa o EAP-TLS no Android e qual é o retorno?

O que paga

• PKI. Uma CA interna existente acrescenta custos reduzidos. Sem uma, terá de criar uma CA ou subscrever uma PKI na nuvem.
• Licenças de MDM. Se a sua frota Android já estiver inscrita, este custo já está pago.
• RADIUS. Precisa de suporte a EAP-TLS, verificação de revogação e um certificado de servidor corretamente construído.
• Tempo de engenharia. Orçamente o piloto, a criação do perfil e a implementação faseada.

O que recebe em troca

• Uma única revogação em vez de uma rotação em toda a frota. No cenário do hotel, um telemóvel perdido afeta um dispositivo, não 60.
• Sem redefinições de palavras-passe de WiFi. Os certificados substituem as palavras-passe, pelo que essa categoria de pedidos de suporte desaparece.
• Resistência à recolha ilícita de credenciais. Um ponto de acesso falso não ganha nada. O Android rejeita o seu certificado e não há palavra-passe para capturar.
• Evidências de conformidade. Os registos de RADIUS por dispositivo suportam o requisito 4.2.1.2 do PCI DSS, o Artigo 32 do GDPR e o controlo de acessos ISO 27001.
• Um caminho para o WPA3. O modo de 192 bits do WPA3-Enterprise, suportado a partir do Android 10, é construído em torno do EAP-TLS. O seu trabalho com certificados é aproveitado para o futuro.

A regra de decisão é simples. Se gere mais do que um punhado de dispositivos Android através de um MDM, faça do EAP-TLS a sua opção predefinida. Coloque os dispositivos de colaboradores não geridos em Redes Baseadas em Identidade e os visitantes no WiFi para visitantes.

Perguntas frequentes

O EAP-TLS funciona em todos os dispositivos Android que é provável termos?

Sim. Qualquer dispositivo Android que seja provável gerir hoje suporta EAP-TLS no WPA2-Enterprise, e o Android 10 e posterior adicionam WPA3-Enterprise. O que mudou foi a validação do servidor. A partir do Android 11, todos os perfis empresariais precisam de um certificado de CA e de um Domínio, pelo que os guias mais antigos que ignoram a validação já não funcionam. Os nomes das opções e os caminhos dos menus também diferem entre fabricantes, o que é mais uma razão para distribuir perfis a partir de um MDM.

Precisamos de um MDM para implementar o EAP-TLS no Android?

Não, mas precisará de um para ir além de um piloto. A configuração manual funciona para um punhado de dispositivos. No entanto, cada dispositivo precisa de 10 passos de configuração, uma chave privada copiada e renovação manual a cada expiração. Um MDM inscrito através do Android Enterprise gera chaves no dispositivo e renova certificados automaticamente. Se já tiver licenças do Microsoft Intune ou do Workspace ONE para Android, o custo extra é maioritariamente tempo de configuração.

Os colaboradores podem utilizar o EAP-TLS em telemóveis Android pessoais?

Sim, através de um perfil de trabalho do Android Enterprise, que mantém os certificados e aplicações corporativos separados dos dados pessoais. O MDM instala o certificado e o perfil de WiFi apenas dentro do perfil de trabalho. Alguns colaboradores irão recusar a inscrição em telemóveis pessoais. Para esses dispositivos, o Purple Staff WiFi dá a cada pessoa a sua própria credencial iPSK ou SecurePass, associada ao seu fornecedor de identidade, sem necessidade de gestão do dispositivo.

O EAP-TLS vai funcionar nos nossos pontos de acesso existentes?

Sim. O EAP-TLS é um método 802.1X, e a Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet suportam todas o 802.1X. O ponto de acesso apenas retransmite a troca de dados. As verificações do certificado ocorrem entre o Android e o seu servidor RADIUS. Configura um SSID Enterprise a apontar para o RADIUS e, se segmentar o tráfego, ativa as VLANs atribuídas por RADIUS.

Como é que o EAP-TLS se compara com o PEAP-MSCHAPv2 para Android?

O EAP-TLS é mais forte, porque não existe qualquer palavra-passe para roubar. O PEAP-MSCHAPv2 envia um nome de utilizador e uma palavra-passe dentro de um túnel TLS, pelo que uma palavra-passe obtida por phishing funciona a partir de qualquer dispositivo. O EAP-TLS precisa de um certificado cuja chave privada permanece no dispositivo emitido. O PEAP é mais rápido de iniciar porque não necessita de PKI. Muitas empresas utilizam o PEAP enquanto constroem a infraestrutura de certificados de que o EAP-TLS necessita.

O EAP-TLS ajuda no cumprimento do PCI-DSS e do GDPR?

Sim, fornece controlos e evidências para ambos. O requisito 4.2.1.2 do PCI-DSS v4.0 exige criptografia forte para autenticação sem fios onde os dados do titular do cartão trafegam. Os certificados por dispositivo registados pelo RADIUS mostram que dispositivo se conetou e quando. O Artigo 32.º do GDPR exige uma segurança adequada para os dados pessoais, a qual é suportada pela autenticação mútua. O EAP-TLS não o torna em conformidade por si só; a segmentação, os registos e as políticas continuam a aplicar-se.

Como migramos dispositivos Android de uma palavra-passe de WiFi partilhada para EAP-TLS?

Execute ambas as redes em paralelo e, em seguida, desative a antiga. Crie o SSID EAP-TLS e envie a AC raiz, o certificado SCEP e os perfis de WiFi para um grupo piloto. Confirme que os testes negativos passam e, depois, alargue a atribuição por fases enquanto a rede de chave partilhada permanece ativa. Assim que os registos do RADIUS mostrarem que a infraestrutura se está a autenticar com certificados, remova o perfil antigo e desligue o SSID de chave partilhada.

Qual é o papel da Purple se os dispositivos dos nossos colaboradores usarem EAP-TLS?

A Purple cobre todas as ligações que o EAP-TLS não cobre. O WiFi de convidados serve os visitantes num SSID separado com um Captive Portal, adesões por escolha consciente e WiFi Analytics. O WiFi de colaboradores utiliza Redes Baseadas em Identidade para dar aos dispositivos não geridos dos colaboradores as suas próprias credenciais. A Purple funciona como uma sobreposição na nuvem nos pontos de acesso que já possui, em mais de 80 000 locais ativos em mais de 90 países (dados da Purple).