Como Configurar SCEP para Cadastro Automatizado de Certificados WiFi Corporativos
Este guia explica como configurar o SCEP (Simple Certificate Enrollment Protocol) para cadastro automatizado de certificados WiFi corporativos, cobrindo toda a arquitetura desde PKI e NDES até a implantação de perfil MDM e validação RADIUS. É voltado para gerentes de TI, arquitetos de rede e CTOs em hotéis, redes de varejo, estádios, centros de convenções e organizações do setor público que precisam ir além das chaves pré-compartilhadas e implementar a autenticação 802.1X EAP-TLS escalável e baseada em identidade. A plataforma de sobreposição em nuvem da Purple, independente de hardware, integra-se diretamente com essa arquitetura, fornecendo a camada de WiFi para convidados e BYOD que opera em conjunto com a sua rede de funcionários autenticada por certificado.
Video overview
Ouça este guia
Ver transcrição do podcast
Parte da nossa série principal: Guia de Segurança de WiFi Corporativo →
Resumo executivo
Para espaços empresariais - quer se trate de um hotel de 200 quartos, de uma rede de varejo com 50 localizações ou de um grande centro de convenções - depender de chaves pré-compartilhadas para o WiFi dos funcionários é um risco de segurança e um gargalo operacional. Uma única senha vazada expõe toda a rede. A autenticação baseada em certificados via IEEE 802.1X e EAP-TLS (Extensible Authentication Protocol - Transport Layer Security) elimina totalmente esse risco. Cada dispositivo prova sua identidade de forma criptográfica antes que o ponto de acesso conceda acesso à rede.
O desafio reside na distribuição. Implementar manualmente certificados de cliente exclusivos em milhares de dispositivos Windows, iOS e Android não é viável. O SCEP (Simple Certificate Enrollment Protocol), formalizado como RFC 8894 pela IETF em 2020, resolve este problema. Ele automatiza o processo de solicitação, emissão e instalação de certificados digitais em dispositivos gerenciados através de sua plataforma MDM - sem qualquer interação do usuário.
Este guia abrange toda a arquitetura: o que o SCEP faz, como se integra com o Microsoft Intune, Jamf e outras plataformas MDM, a sequência exata de implementação que a maioria das equipes erra e as armadilhas operacionais que causam interrupções de serviço. Também abordamos dois cenários reais de implementação em hotelaria e varejo, e explicamos onde a plataforma de Guest WiFi da Purple se enquadra ao lado da sua rede de funcionários autenticada por certificado.
Ouça o podcast informativo complementar:
Análise técnica detalhada: SCEP, PKI e 802.1X
O que o SCEP realmente faz
O SCEP não substitui a sua PKI (Public Key Infrastructure). É a camada de registro automatizada que se posiciona sobre ela. A sua PKI - normalmente uma hierarquia de dois níveis com uma CA raiz offline e uma CA emissora online - continua a ser a âncora de confiança. O SCEP automatiza a etapa em que um dispositivo solicita um certificado a essa CA, eliminando a necessidade de geração manual de CSR e instalação de certificados.
No contexto da autenticação WiFi, o protocolo de destino é o EAP-TLS. Este é o método de autenticação 802.1X que exige que tanto o dispositivo cliente como o servidor RADIUS apresentem certificados X.509 válidos. Nenhuma das partes confia na outra sem prova criptográfica. Esse modelo de autenticação mútua elimina o roubo de credenciais e protege contra ataques de "evil twin", em que um atacante cria um ponto de acesso falso para colher nomes de usuário e senhas.
Para uma análise detalhada do handshake EAP-TLS, consulte o nosso guia sobre WiFi Certificate Authentication: Secure Network Access.
O fluxo de registro SCEP, passo a passo
A cadeia de registro completa funciona da seguinte forma. A sua plataforma MDM - Microsoft Intune, Jamf ou outro MDM - envia um payload SCEP para um dispositivo gerenciado. Esse payload contém duas coisas: o URL do SCEP que aponta para o seu servidor NDES (Network Device Enrollment Service) ou gateway SCEP na nuvem, e uma senha de desafio ou segredo compartilhado.
O dispositivo gera o seu próprio par de chaves pública e privada localmente. Esta é a propriedade de segurança crítica do SCEP: a chave privada é gerada no dispositivo, armazenada no enclave seguro ou chip TPM, e nunca é transmitida pela rede. O dispositivo cria então um Certificate Signing Request (CSR) e envia-o para o gateway SCEP. O gateway valida a senha de desafio, encaminha o CSR para a sua Autoridade de Certificação (CA), e a CA assina-o e devolve o certificado público ao dispositivo.
A partir desse momento, quando o dispositivo se conecta ao seu SSID de WiFi, apresenta esse certificado ao servidor RADIUS. O servidor RADIUS valida o certificado em relação à sua cadeia de confiança da CA, verifica a Lista de Revogação de Certificados (CRL) para confirmar que o certificado não foi revogado e, se tudo estiver correto, envia uma mensagem Access-Accept para o ponto de acesso. O dispositivo está na rede. Todo o processo é invisível para o usuário.
SCEP vs. PKCS: qual utilizar para WiFi
As plataformas MDM como o Intune suportam dois mecanismos de entrega de certificados: SCEP e PKCS (Public Key Cryptography Standards). A diferença arquitetônica é significativa.
Com o SCEP, a chave privada é gerada no dispositivo e nunca sai dele. Com o PKCS, a Autoridade de Certificação gera a chave pública e a privada centralmente, e o conector de certificados envia o par de chaves para o dispositivo através da rede. Isso significa que a chave privada é transmitida, o que introduz uma superfície de ataque teórica.
O PKCS é adequado para casos de uso em que a custódia de chaves é necessária, como a criptografia de e-mail S/MIME. Para a autenticação WiFi, o SCEP é a escolha correta. A chave privada permanece no dispositivo.
| Propriedade | SCEP | PKCS |
|---|---|---|
| Geração de chave privada | No dispositivo (TPM/Secure Enclave) | Centralizada (CA) |
| Transmissão de chave privada | Nunca | Através da rede |
| Servidor NDES necessário | Sim (ou gateway na nuvem) | Não |
| Recomendado para WiFi | Sim | Não |
| Recomendado para S/MIME | Não | Sim |
Compatibilidade de hardware
O SCEP e o EAP-TLS são normas independentes de fornecedor. Funcionam em pontos de acesso Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. A sua configuração RADIUS - quer seja Windows NPS, FreeRADIUS ou um serviço RADIUS na nuvem - é onde define a política de validação de certificados e a atribuição dinâmica de VLAN.
A atribuição dinâmica de VLAN é a forma como segmenta a rede através da identidade do dispositivo. Um dispositivo de um funcionário recebe a VLAN 10 com acesso a sistemas internos. O dispositivo de um prestador de serviços recebe a VLAN 20 apenas com acesso à internet. Um terminal de ponto de venda recebe a VLAN 30 apenas com acesso a sistemas de processamento de pagamentos. Tudo isto é gerido por atributos de certificado e pela política RADIUS, sem qualquer intervenção manual por dispositivo.
Para saber mais sobre como o WiFi Analytics se integra com a segmentação de rede baseada em identidade, consulte a nossa visão geral da plataforma de analytics.
Guia de implementação: a sequência de implementação
A configuração bem-sucedida do SCEP para WiFi empresarial exige a adesão estrita a uma sequência de implementação específica. As plataformas MDM impõem dependências de perfil: um perfil de WiFi que faça referência a um certificado SCEP não pode ser aplicado até que esse certificado exista no dispositivo. A violação desta sequência é a causa mais comum de falhas na implementação.
A sequência é: primeiro a Raiz de Confiança (Trusted Root), segundo o perfil SCEP, terceiro o perfil WiFi. Esta ordem não é negociável.
Passo 1: implantar o perfil de Certificado de Raiz de Confiança (Trusted Root)
Antes que qualquer dispositivo possa solicitar um certificado de cliente ou confiar no seu servidor RADIUS, ele deve confiar na Autoridade de Certificação (CA) emissora. Exporte o seu certificado de CA Raiz - e quaisquer certificados de CA Intermediária - como arquivos .cer. No seu centro de administração MDM, crie um perfil de Certificado de Confiança, faça o upload do arquivo .cer e implante-o no seu grupo de dispositivos de destino.
Se você tiver uma hierarquia PKI de dois níveis (recomendado), precisará implantar tanto o certificado da CA raiz quanto o da CA emissora como perfis de Certificado de Confiança separados, ou como uma cadeia em um único perfil, dependendo da sua plataforma MDM.
Passo 2: configurar o perfil de Certificado SCEP
Assim que a confiança estiver estabelecida, configure o perfil SCEP para instruir os dispositivos sobre como obter o seu certificado de cliente.
Crie um novo perfil de configuração e selecione o tipo de perfil de certificado SCEP. Configure o formato do Nome do Requerente (Subject name). Para autenticação baseada no usuário, CN={{UserPrincipalName}} é o padrão. Para autenticação de dispositivos (dispositivos compartilhados, IoT, terminais POS), use CN={{AAD_Device_ID}}. Defina a Utilização da chave (Key usage) para Assinatura digital e Cifragem de chave. Defina a Utilização de Chave Estendida (Extended Key Usage) para Autenticação de Cliente (OID: 1.3.6.1.5.5.7.3.2). Associe este perfil ao perfil de certificado de Raiz de Confiança criado no Passo 1. Forneça o URL externo do seu servidor NDES. Para o Microsoft Intune especificamente, o servidor NDES deve ser publicado por meio do Azure AD Application Proxy para permitir que os dispositivos remotos se registrem antes de chegarem ao local. Não exponha o NDES diretamente à internet.
Passo 3: implantar o perfil de WiFi 802.1X
O passo final é enviar a configuração de WiFi que associa os certificados ao SSID da rede. Crie um perfil de configuração de WiFi. Insira o Nome da rede (SSID) exatamente como é transmitido pelos seus pontos de acesso. Selecione WPA2 ou WPA3 como o tipo de segurança. Defina o tipo de EAP para EAP-TLS. Nas configurações de autenticação, selecione o perfil de certificado SCEP criado no Passo 2 como o certificado de autenticação do cliente. Especifique o certificado Trusted Root para validação do servidor - isso garante que o dispositivo apenas se conecte ao seu servidor RADIUS legítimo e não a um ponto de acesso não autorizado.
Integração do provedor de identidade
Os atributos do certificado SCEP - especificamente o Subject Alternative Name (SAN) - podem conter o nome principal do usuário do Microsoft Entra ID, Okta ou Google Workspace. Isto associa o certificado a uma identidade específica. Quando desativa uma conta no Entra ID e o MDM remove o registro do dispositivo, o certificado é revogado e o acesso ao WiFi é cortado automaticamente. Essa revogação automatizada é a história de segurança que as chaves pré-compartilhadas não conseguem igualar.
Para saber mais sobre EAP Method WiFi: A Guide to Secure Network Access, incluindo caminhos de migração PEAP-MSCHAPv2, consulte o nosso guia dedicado.
-
Tem dúvidas sobre a sua configuração específica?
A nossa equipa trabalha com operadores de espaços, gestores de TI e engenheiros de rede em 80.000 locais. Agende uma chamada de 20 minutos e mostraremos como outros profissionais na sua situação o resolveram.
Boas práticas e padrões da indústria
Posicionamento do servidor NDES
O servidor NDES deve estar acessível a partir da internet para que os dispositivos se possam registrar antes de chegarem ao local. Publique o URL do NDES através do Azure AD Application Proxy. Isto fornece um acesso remoto seguro sem abrir portas de firewall de entrada e permite-lhe aplicar políticas de Acesso Condicional ao fluxo de registro. Nunca exponha o NDES diretamente à internet.
Para redes com mais de 500 dispositivos gerenciados, considere um gateway SCEP na nuvem em vez de um NDES local. Os gateways na nuvem eliminam o ponto único de falha do NDES, escalam horizontalmente e, normalmente, integram-se diretamente com serviços RADIUS na nuvem.
Disponibilidade da CRL
O seu servidor RADIUS verifica a Lista de Revogação de Certificados (CRL) sempre que um dispositivo se autentica. Se o seu Ponto de Distribuição de CRL (CDP) estiver indisponível - porque um servidor está inoperante ou o URL mudou - a autenticação falha para todos os dispositivos na rede simultaneamente. Configure o seu servidor NPS ou RADIUS para impor uma verificação rigorosa da CRL e torne os seus endpoints de CRL altamente disponíveis. Teste a revogação antes de entrar em produção.
O Requisito 8.6 do PCI-DSS 4.0 exige autenticação multifator na camada de rede para ambientes de dados de titulares de cartões. O EAP-TLS com certificados provisionados por SCEP satisfaz este requisito para redes sem fios em ambientes de Retail e Hospitality.
Compatibilidade com WPA3
O EAP-TLS é totalmente compatível com o WPA3-Enterprise. O WPA3-Enterprise com a suíte de segurança de 192 bits (Suite B) exige o EAP-TLS e é a combinação recomendada pela Wi-Fi Alliance para redes governamentais, financeiras e de saúde. Se está a implementar em ambientes de Saúde ou Transportes com requisitos de conformidade rigorosos, o WPA3-Enterprise com EAP-TLS é a arquitetura-alvo correta.
BYOD e WiFi de convidados
O SCEP requer o registro no MDM para enviar o payload do certificado. Não abrange dispositivos BYOD não gerenciados ou convidados. Para esses casos de uso, você precisa de um SSID separado com um Captive Portal e verificação de identidade. A plataforma da Purple lida com essa camada de forma limpa, coexistindo com a sua rede de funcionários autenticada por certificado. A nossa plataforma de Guest WiFi suporta opt-ins de escolha consciente, captura de dados primários (first-party) e integração com o Microsoft Entra ID, Okta e Google Workspace para verificação de identidade. - - - ## Resolução de problemas e mitigação de riscos ### Falha na aplicação do perfil de WiFi Sintoma: O dispositivo recebe os certificados Trusted Root e SCEP, mas o perfil de WiFi é apresentado como Erro ou Não Aplicável no MDM. Causa raiz: Incompatibilidade de segmentação de grupo. Se o perfil SCEP se destinar a um grupo de Usuários e o perfil de WiFi se destinar a um grupo de Dispositivos, o MDM não consegue resolver a dependência. Solução: Audite as suas atribuições. Certifique-se de que os perfis Trusted Root, SCEP e WiFi se destinam todos exatamente ao mesmo grupo de diretório. ### Erros NDES 403 Forbidden Sintoma: Os dispositivos não conseguem obter o certificado SCEP. Os registros do IIS do NDES mostram erros HTTP 403. Causa raiz: A conta de serviço do MDM Certificate Connector não tem permissões de Leitura e Registro (Read and Enroll) no modelo de certificado, ou a filtragem de URLs do firewall está bloqueando os parâmetros de query string do SCEP. Solução: Verifique se a conta do conector tem permissões de Leitura e Registro no modelo da CA. Verifique os registros do firewall para garantir que os URLs que contêm ?operation=GetCACaps não estão bloqueados. ### Falha de autenticação em massa após expiração da CRL Sintoma: Todos os dispositivos na rede falham a autenticação em simultâneo. Causa raiz: A CRL expirou ou o URL do CDP está inacessível. O servidor RADIUS não consegue confirmar se os certificados são válidos e falha por omissão (fails closed). Solução: Configure a monitoração e alertas de CRL. Publique as CRLs com um período de validade significativamente superior ao intervalo de publicação. Teste a acessibilidade do CDP a partir do servidor RADIUS antes do lançamento. ### Expiração de certificado causando falhas silenciosas Sintoma: Dispositivos individuais falham a conexão de forma intermitente, sem um padrão claro. Causa raiz: Os certificados de cliente expiraram e o MDM não os renovou com sucesso. Solução: Configure a renovação do certificado para ser acionada a 80% do tempo de vida do certificado. Monitorize os relatórios de status de registro do MDM para dispositivos com erros de certificado. Defina períodos de validade de certificado adequados ao ciclo de atualização dos seus dispositivos - normalmente um a dois anos para endpoints geridos. - - - ## ROI e impacto empresarial
A transição para a autenticação por certificado 802.1X baseada em SCEP proporciona retornos mensuráveis em termos de segurança, operações e conformidade.
Redução de chamados de suporte: O WiFi baseado em senha gera um volume significativo de chamados de suporte - expiração de senhas, bloqueios e erros de digitação. A autenticação baseada em certificado é invisível para o usuário. As organizações registram tipicamente uma redução de 70 - 80% no volume de suporte relacionado com WiFi após a migração.
Postura de segurança: O EAP-TLS elimina a coleta de credenciais e os ataques Man-in-the-Middle. Isto apoia diretamente a conformidade com a norma PCI-DSS 4.0 para redes de varejo e hotelaria, bem como os requisitos do Artigo 32.º do GDPR para medidas técnicas de segurança adequadas.
Revogação automatizada: Quando um colaborador sai da empresa, a desativação da sua conta no Microsoft Entra ID aciona a revogação automática do certificado e a desassociação do MDM. O acesso ao WiFi é cortado sem qualquer intervenção manual por parte da equipe de rede.
Segmentação de rede: A atribuição dinâmica de VLAN através de atributos de certificado RADIUS oferece a você uma segmentação de rede aplicada de forma criptográfica. Os dispositivos entram no segmento de rede correto com base nas propriedades do certificado, e não na seleção de SSID ou na filtragem de endereços MAC - ambas facilmente contornáveis.
A Purple opera em mais de 80.000 locais ativos com 99,999% de tempo de atividade, e a nossa plataforma possui as certificações ISO 27001, GDPR, CCPA e Cyber Essentials. A nossa sobreposição de nuvem agnóstica em termos de hardware integra-se com Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet - para que a sua rede de colaboradores autenticada por certificado e a nossa camada de WiFi de convidados funcionem a partir da mesma infraestrutura.
Para saber mais sobre como a análise comportamental (Behavioral Analytics: Insights for WiFi Networks) pode complementar a sua implementação de rede segura, consulte o nosso guia de análise.
Referências
[1] RFC 8894: Simple Certificate Enrollment Protocol - IETF [2] Configure infrastructure to support SCEP with Intune - Microsoft Learn [3] PCI DSS Wireless Guidelines - PCI Security Standards Council
Definições principais
SCEP (Simple Certificate Enrollment Protocol)
Um protocolo formalizado na RFC 8894 que permite que dispositivos gerenciados solicitem e recebam automaticamente certificados digitais X.509 de uma Autoridade de Certificação via HTTP, usando uma senha de desafio compartilhada para autenticação inicial. A chave privada é gerada no dispositivo e nunca é transmitida.
O mecanismo padrão usado por plataformas MDM como Microsoft Intune e Jamf para implantar certificados de autenticação WiFi em endpoints gerenciados em escala.
EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)
O método de autenticação 802.1X mais seguro, que exige que tanto o dispositivo cliente quanto o servidor RADIUS apresentem certificados X.509 válidos. A autenticação mútua significa que nenhum dos lados confia no outro sem prova criptográfica.
O protocolo de autenticação de destino para WiFi empresarial. Obrigatório ou fortemente recomendado pelo PCI DSS 4.0, WPA3-Enterprise de 192 bits (Suite B) e HIPAA para redes sem fio que lidam com dados confidenciais.
NDES (Network Device Enrollment Service)
Uma função do Microsoft Windows Server que atua como uma Autoridade de Registro (RA) entre dispositivos habilitados para SCEP e uma Autoridade de Certificação. Ele valida senhas de desafio e encaminha CSRs para a CA em nome de dispositivos que não possuem credenciais de domínio.
Infraestrutura necessária para implantação de SCEP com o Microsoft Intune. Deve ser publicado por meio do Azure AD Application Proxy em vez de ser exposto diretamente à internet.
PKI (Public Key Infrastructure)
A hierarquia de Autoridades de Certificação, políticas e procedimentos usados para emitir, gerenciar e revogar certificados digitais. Uma PKI de duas camadas consiste em uma CA raiz offline (a âncora de confiança mestre) e uma CA emissora online (que lida com a emissão diária de certificados).
O pré-requisito não negociável para a implantação de EAP-TLS e SCEP. A CA raiz deve ser mantida isolada; sua chave privada é a base de toda a sua cadeia de confiança de certificados.
CSR (Certificate Signing Request)
Uma mensagem gerada por um dispositivo contendo sua chave pública e informações de identidade, enviada a uma Autoridade de Certificação para solicitar um certificado digital assinado. No SCEP, o CSR é gerado no dispositivo e encapsulado em um envelope PKCS antes da transmissão.
Gerado automaticamente pelo dispositivo durante o fluxo de registro SCEP. A chave privada usada para assinar o CSR nunca sai do dispositivo.
CRL (Certificate Revocation List)
Uma lista publicada pela Autoridade Certificadora que contém os números de série dos certificados que foram revogados antes da data de expiração. Os servidores RADIUS verificam o CRL em todas as tentativas de autenticação para garantir que os certificados revogados não possam acessar a rede.
A disponibilidade do CRL Distribution Point (CDP) é crítica. Se o servidor RADIUS não conseguir alcançar o CRL, ele falha fechado e nega todas as autenticações - causando uma interrupção em toda a rede.
RADIUS (Remote Authentication Dial-In User Service)
Um protocolo de rede que fornece Autenticação, Autorização e Contabilização (AAA) centralizadas para acesso à rede. No WiFi 802.1X, o servidor RADIUS valida os certificados dos clientes, verifica o CRL e retorna uma mensagem de Access-Accept ou Access-Reject para o ponto de acesso.
O servidor de autenticação no modelo de suplicante-autenticador-servidor do 802.1X. Implementações comuns incluem Windows NPS, FreeRADIUS e serviços de cloud RADIUS.
Atribuição dinâmica de VLAN
Um recurso de RADIUS que coloca um dispositivo autenticado em uma VLAN específica com base nos atributos do certificado ou na associação a grupos de diretório, em vez de depender da seleção de SSID ou filtragem de endereço MAC. Aplica a segmentação de rede por identidade de dispositivo.
Permite que um único SSID atenda a múltiplos tipos de dispositivos com diferentes níveis de acesso à rede. Um dispositivo de funcionário recebe a VLAN 10 (acesso interno); o dispositivo de um prestador de serviços recebe a VLAN 20 (apenas internet); um terminal PDV recebe a VLAN 30 (apenas sistemas de pagamento).
MDM (Mobile Device Management)
Software utilizado pelas equipes de TI para registrar, configurar, proteger e gerenciar smartphones, tablets e laptops. Plataformas de MDM como o Microsoft Intune e o Jamf usam perfis SCEP para enviar instruções de registro de certificados para dispositivos gerenciados sem a interação do usuário.
O pré-requisito para a implantação de certificados baseados em SCEP. Os dispositivos devem estar registrados no MDM antes de poderem receber perfis de SCEP e WiFi. Dispositivos BYOD não gerenciados exigem uma abordagem de integração separada.
Exemplos práticos
Uma propriedade de 200 quartos do Premier Inn precisa proteger o WiFi dos funcionários para tablets de ponto de venda e smartphones da equipe de governança. Atualmente, eles usam uma chave pré-compartilhada que foi vazada para prestadores de serviços. Eles gerenciam os dispositivos via Microsoft Intune e possuem uma mistura de dispositivos iOS e Android. A propriedade utiliza pontos de acesso HPE Aruba.
- Implante uma PKI interna do Microsoft AD CS em duas camadas. Configure o NDES em um Windows Server dedicado e publique-o via Proxy de Aplicativo do Azure AD.
- No Intune, crie um perfil de Certificado de Raiz Confiável contendo os certificados da CA Raiz e da CA Emissora. Implante para um grupo do Azure AD de 'Dispositivos de Funcionários da Propriedade'.
- Crie um perfil de Certificado SCEP no Intune apontando para a URL externa do NDES. Defina o formato do Nome do Assunto como CN={{AAD_Device_ID}}, já que estes são dispositivos compartilhados. Defina o Uso de Chave como Assinatura Digital e Criptografia de Chave, e o Uso Avançado de Chave como Autenticação de Cliente. Implante para 'Dispositivos de Funcionários da Propriedade'.
- Crie um perfil de Wi-Fi para o SSID dos funcionários, configurando WPA2-Enterprise e EAP-TLS. Selecione o perfil SCEP para autenticação de cliente e a CA Raiz para validação de servidor. Implante para 'Dispositivos de Funcionários da Propriedade'.
- Configure as definições de RADIUS do HPE Aruba para apontar para o NPS do Windows. No NPS, configure uma Política de Rede que exija EAP-TLS e atribua a VLAN 10 para os dispositivos dos funcionários.
- Assim que os dispositivos receberem os perfis e se conectarem com sucesso, rotacione a PSK no SSID antigo e agende sua desativação.
Uma rede de varejo com 50 filiais deseja implantar o 802.1X para laptops corporativos em todas as unidades. Eles usam pontos de acesso Cisco Meraki e Microsoft Intune. Eles não querem implantar e manter servidores NDES locais ou infraestrutura AD CS em cada local ou em seu data center.
- Implemente um serviço de gateway SCEP e PKI baseado em nuvem que se integre ao Intune por meio do protocolo SCEP. A CA de nuvem emite certificados; o gateway SCEP de nuvem lida com a validação de CSR.
- Configure o serviço RADIUS de nuvem (fornecido pelo fornecedor de PKI) no painel do Cisco Meraki em Wireless > Controle de Acesso para o SSID corporativo. Defina a segurança para WPA2-Enterprise e aponte o RADIUS para o serviço de nuvem.
- No Intune, crie um perfil de Certificado de Raiz Confiável contendo o certificado raiz da CA de nuvem. Implante no grupo de dispositivos 'Laptops Corporativos'.
- Crie um perfil de Certificado SCEP apontando para a URL do gateway SCEP de nuvem. Defina o Nome do Assunto como CN={{UserPrincipalName}} para autenticação base de usuário. Implante em 'Laptops Corporativos'.
- Crie um perfil de Wi-Fi para o SSID corporativo com EAP-TLS, referenciando o perfil SCEP e a raiz da CA de nuvem. Implante em 'Laptops Corporativos'.
- Quando os laptops são registrados no Intune, eles solicitam automaticamente certificados da CA de nuvem por meio do gateway SCEP de nuvem. Nenhuma infraestrutura local é necessária em nenhum dos 50 locais.
Questões práticas
Q1. Sua organização está migrando do PEAP-MSCHAPv2 para o EAP-TLS. Você implantou com sucesso os perfis de Trusted Root e SCEP para o seu grupo do Azure AD 'Corporate Users' no Intune. Você implanta o perfil de WiFi para 'All Corporate Devices'. Os usuários relatam que não conseguem se conectar e o perfil de WiFi é exibido como Não Aplicável.
Dica: Verifique as dependências de perfil e as regras de direcionamento de grupo. O Intune resolve as dependências de perfil com base no grupo atribuído.
Ver resposta modelo
O problema é uma incompatibilidade de direcionamento de grupo. O perfil de WiFi depende do perfil SCEP, que foi direcionado a um grupo de Usuários ('Corporate Users'). O perfil de WiFi foi direcionado a um grupo de Dispositivos ('All Corporate Devices'). O Intune não consegue resolver a dependência entre tipos de grupos diferentes. A solução é alterar as atribuições de todos os três perfis - Trusted Root, SCEP e WiFi - para direcionar ao mesmo grupo. Decida se usará um grupo de Usuários ou um grupo de Dispositivos com base no seu modelo de autenticação (baseado em usuário vs baseado em dispositivo) e aplique isso de forma consistente em todos os três perfis.
Q2. Uma auditoria de segurança revela que, quando um funcionário é desligado e sua conta do Microsoft Entra ID é desativada, seu smartphone corporativo ainda consegue se conectar à rede WiFi da equipe por até uma semana após o desligamento.
Dica: Considere como o servidor RADIUS determina se um certificado ainda é válido após a conta ser desativada. Qual é o mecanismo para comunicar o status de revogação?
Ver resposta modelo
O servidor RADIUS não está realizando a verificação estrita da Lista de Revogação de Certificados (CRL) ou a CRL é publicada com pouca frequência. Quando um funcionário é desligado, o MDM deve desvincular o dispositivo e a CA deve revogar o certificado. No entanto, se o servidor RADIUS não estiver verificando a CRL a cada tentativa de autenticação - ou se a CRL for publicada apenas semanalmente - o certificado revogado continuará sendo aceito. A correção envolve três etapas: configurar o servidor RADIUS para impor a verificação estrita de CRL em todas as autenticações; configurar a CA para publicar a CRL em um intervalo menor (diariamente ou com maior frequência); e garantir que o MDM esteja configurado para acionar a revogação do certificado quando um dispositivo for desvinculado.
Q3. Você precisa fornecer acesso WiFi seguro para dispositivos IoT headless (termostatos inteligentes, players de sinalização digital) que não podem executar um agente MDM e não podem exibir um Captive Portal. Você pode usar SCEP para esses dispositivos e, se não, qual é a alternativa recomendada?
Dica: Considere os pré-requisitos para o registro SCEP e quais alternativas existem para dispositivos que não podem ser registrados via MDM ou interagir com um navegador.
Ver resposta modelo
O SCEP não pode ser usado para esses dispositivos. O SCEP requer um agente MDM para receber a URL de registro e a senha de desafio, gerar o par de chaves e instalar o certificado resultante. Dispositivos IoT headless que não conseguem executar um agente MDM não podem participar do fluxo de registro SCEP. As alternativas recomendadas são: (1) MAC Authentication Bypass (MAB) combinado com segmentação estrita de VLAN - o servidor RADIUS permite o dispositivo com base em seu endereço MAC e o coloca em uma VLAN de IoT isolada, sem acesso aos sistemas corporativos; (2) se o dispositivo for compatível, o EST (Enrolment over Secure Transport, RFC 7030) pode provisionar certificados para dispositivos que suportam HTTPS, mas não MDM; (3) para dispositivos com uma interface de gerenciamento, alguns fabricantes suportam o registro SCEP diretamente através do firmware do dispositivo, sem a necessidade de um agente MDM. Em todos os casos, os dispositivos IoT devem ser isolados em uma VLAN dedicada, independentemente do método de autenticação utilizado.
Continue a ler esta série
Como Segmentar Redes WiFi de Funcionários e Convidados com Segurança: Melhores Práticas para LANs Corporativas
Este guia fornece aos gerentes de TI e arquitetos de rede um modelo técnico e neutro em relação a fornecedores para proteger LANs corporativas por meio da segmentação adequada do tráfego WiFi de funcionários e convidados. O conteúdo aborda autenticação 802.1X, RADIUS em nuvem, isolamento de VLAN e o gerenciamento do ciclo de vida de credenciais necessário para eliminar senhas compartilhadas e proteger os ativos corporativos.
Best DNS filtering: a comprehensive guide for businesses
Este guia de referência técnica explica como o DNS filtering empresarial protege redes públicas bloqueando domínios maliciosos na camada de resolução - antes mesmo que uma conexão seja estabelecida. Ele fornece a diretores de TI, arquitetos de rede e equipes de operações de locais a arquitetura de implantação, configuração de firewall e contexto de conformidade que precisam para proteger o Guest WiFi em ambientes de hospitalidade, varejo e setor público. O Purple Shield bloqueia malware, botnets e conteúdo inadequado no nível de DNS em mais de 80.000 locais ativos.
Entendendo o Cisco SUDI: Identidade Ancorada em Hardware no Controle de Acesso a Redes Seguras
Este guia explica como o Cisco SUDI fornece uma identidade criptograficamente segura e ancorada em hardware para a infraestrutura de rede corporativa. Saiba como substituir endereços MAC clonáveis por certificados 802.1AR imutáveis para proteger o controle de acesso à rede do seu local.
Tem dúvidas sobre a sua configuração específica?
A nossa equipa trabalha com operadores de espaços, gestores de TI e engenheiros de rede em 80.000 locais. Agende uma chamada de 20 minutos e mostraremos como outros profissionais na sua situação o resolveram.