Como implementar SCEP para registro automatizado de certificados WiFi
Este guia explica como implementar o SCEP (Simple Certificate Enrollment Protocol) para registro automatizado de certificados WiFi em locais corporativos. Ele abrange o projeto arquitetônico completo - desde o design de PKI e integração com MDM até a sequência obrigatória de implantação em três etapas - e mostra aos gerentes de TI e arquitetos de rede como eliminar credenciais compartilhadas, automatizar o gerenciamento do ciclo de vida dos certificados e atender aos requisitos do PCI DSS e GDPR em escala.
Ouça este guia
Ver transcrição do podcast
Resumo executivo
Para operadores de locais que oferecem Guest WiFi em hotéis, redes de varejo, estádios e centros de convenções, depender de chaves pré-compartilhadas ou de Captive Portals básicos para o acesso à rede da equipe é uma vulnerabilidade de segurança. A arquitetura de rede moderna exige autenticação 802.1X usando EAP-TLS (Extensible Authentication Protocol - Transport Layer Security), garantindo que cada dispositivo seja verificado criptograficamente antes de tocar a rede. O desafio é a distribuição: como implantar certificados de cliente exclusivos em milhares de dispositivos Windows, iOS e Android sem sobrecarregar seu suporte?
A resposta é o SCEP - o Simple Certificate Enrollment Protocol. Formalizado pela IETF como RFC 8894 em 2020, o SCEP automatiza o registro de certificados em frotas de dispositivos gerenciados. Quando integrado a uma plataforma MDM, como o Microsoft Intune ou o Jamf, o SCEP oferece provisionamento de certificados sem toque (zero-touch): os dispositivos solicitam, recebem e renovam seus próprios certificados sem qualquer intervenção de TI. A chave privada é gerada localmente no dispositivo e nunca é transmitida pela rede - uma vantagem de segurança fundamental em relação à entrega baseada em PKCS.
Este guia aborda todo o fluxo de trabalho de implementação do SCEP: arquitetura de PKI, configuração do gateway NDES, a sequência obrigatória de implantação do MDM em três etapas e os controles operacionais - particularmente a verificação de CRL e o direcionamento de grupo - que determinam se uma implantação terá sucesso ou será interrompida. Dois cenários do mundo real ilustram a abordagem em ambientes de hotelaria e varejo. A Purple opera em mais de 80.000 locais ativos e atende a 350 milhões de usuários únicos; os padrões descritos aqui refletem o que funciona nessa escala.
Mergulho técnico
O que o SCEP realmente faz
O SCEP fica entre sua plataforma MDM e sua Autoridade de Certificação (CA). Ele fornece um mecanismo padronizado baseado em HTTP para que os dispositivos solicitem, recebam e renovem certificados X.509 sem exigir uma credencial associada ao domínio ou envolvimento manual do administrador. O protocolo foi desenvolvido originalmente no início dos anos 2000 e ganhou ampla adoção em ambientes de MDM corporativos antes de a IETF publicá-lo formalmente como RFC 8894.
O fluxo de registro em seis etapas funciona da seguinte forma. Primeiro, o dispositivo gerenciado se conecta à URL do gateway SCEP pré-configurada em seu perfil de MDM. Segundo, o dispositivo gera um par de chaves privada/pública localmente e cria uma Solicitação de Assinatura de Certificado (CSR). Terceiro, o gateway SCEP valida a autorização do dispositivo usando uma senha de desafio ou OTP incorporada na política do MDM. Quarto, o gateway encaminha a CSR validada para a CA. Quinto, a CA assina o certificado e o devolve ao gateway. Sexto, o gateway entrega o certificado assinado ao dispositivo. As renovações futuras seguem o mesmo caminho automatizado - o dispositivo se registra novamente antes da expiração, sem qualquer ação do usuário ou do administrador.
SCEP vs PKCS: a decisão que importa
O Microsoft Intune e a maioria das plataformas MDM suportam dois mecanismos de entrega de certificados: SCEP e PKCS. A distinção é arquitetônica, não cosmética.
Com o SCEP, a chave privada é gerada no dispositivo e permanece lá. A CA nunca a vê. O TPM do dispositivo (no Windows) ou o Secure Enclave (no iOS/macOS) protege a chave no nível do hardware. Com o PKCS, a CA gera o par de chaves centralmente e o transmite ao dispositivo pela rede. A CA retém uma cópia, permitindo o depósito de chaves - o que é útil para criptografia de e-mail S/MIME, mas introduz riscos desnecessários para a autenticação de rede.
Para autenticação WiFi 802.1X, use SCEP. A chave privada nunca sai do dispositivo. Essa é a regra.
| Critério | SCEP | PKCS |
|---|---|---|
| Chave privada gerada no | Dispositivo | CA (centralmente) |
| Chave privada transmitida pela rede | Nunca | Sim |
| Suporta TPM / Secure Enclave | Sim | Não |
| Recomendado para autenticação WiFi | Sim | Não |
| Recomendado para criptografia de e-mail (S/MIME) | Não | Sim |
| Depósito de chaves possível | Não | Sim |
802.1X e EAP-TLS: a estrutura de autenticação
O IEEE 802.1X é o padrão de controle de acesso à rede baseado em porta que sustenta a segurança do WiFi corporativo. Ele define três funções: o suplicante (o dispositivo cliente), o autenticador (o ponto de acesso - Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme ou Fortinet) e o servidor de autenticação (um servidor RADIUS como Microsoft NPS, FreeRADIUS ou Cisco ISE).
O EAP-TLS é o método EAP mais seguro para o 802.1X. Ambos os lados apresentam certificados: o servidor RADIUS apresenta seu certificado ao cliente, e o cliente apresenta seu certificado provisionado por SCEP ao servidor RADIUS. Nenhum dos lados pode se passar pelo outro sem um certificado válido e não revogado da hierarquia de CA confiável. Esse modelo de autenticação mútua elimina o roubo de credenciais, ataques de Evil Twin e riscos de pontos de acesso não autorizados em uma única decisão arquitetônica.
O EAP-TLS atende ao Requisito 8.6 do PCI DSS 4.0 para autenticação multifator na camada de rede. Ele é obrigatório para implantações WPA3 Enterprise de 192 bits (Suite B). Para qualquer rede sem fio no escopo do processamento de dados de titulares de cartão - varejo ponto de venda, recepção de hotel, bilheteria de estádio - o EAP-TLS é a escolha correta.
Para uma análise mais aprofundada da arquitetura de WiFi seguro e de como a autenticação baseada em certificado se encaixa em uma postura de segurança mais ampla, consulte nosso guia essencial.
Guia de implementação
A sequência de implantação é inegociável. O Intune e o Jamf resolvem as dependências de perfil em ordem: o perfil de WiFi depende do perfil SCEP, que por sua vez depende do perfil de Raiz Confiável (Trusted Root). Se implantados fora de sequência, a aplicação do perfil de WiFi falhará.
Passo 1: Projete sua PKI
Antes de tocar em um console MDM, projete sua hierarquia de certificados. Uma PKI de duas camadas é o padrão: uma CA raiz offline e uma CA emissora online. A chave privada da CA raiz é a âncora de confiança mestre para toda a sua infraestrutura de certificados - mantenha-a isolada (air-gapped). A CA emissora lida com a emissão diária de certificados e publica a Lista de Revogação de Certificados (CRL) e o respondedor OCSP.
Para a maioria das implantações em locais corporativos, o Microsoft Active Directory Certificate Services (AD CS) executado no Windows Server fornece a CA emissora. Serviços de PKI hospedados na nuvem de provedores como SCEPman ou SecureW2 eliminam completamente o requisito de infraestrutura local e valem a pena ser avaliados para implantações distribuídas em grupos hoteleiros, redes de varejo ou organizações do setor público com vários locais.
Passo 2: Implante o servidor NDES (ou gateway SCEP na nuvem)
O NDES (Network Device Enrollment Service) é a função do Microsoft Windows Server que atua como o gateway SCEP entre seu MDM e sua CA. Requisitos de configuração principais:
- Publique a URL do NDES externamente via Azure AD Application Proxy (or proxy reverso equivalente). Isso permite que dispositivos remotos se registrem antes de chegarem ao local, sem abrir portas de firewall de entrada.
- A conta de serviço do NDES requer permissões de Leitura e Registro (Read and Enroll) no modelo de certificado da CA.
- Configure o modelo de certificado com o Uso de Chave (Key Usage) definido como Assinatura Digital (Digital Signature) e Criptografia de Chave (Key Encipherment), e Uso Avançado de Chave (Extended Key Usage) definido como Autenticação de Cliente (Client Authentication) (OID: 1.3.6.1.5.5.7.3.2).
- Defina um período de validade de certificado apropriado. Um ano é o padrão para certificados de cliente; dois anos é aceitável para certificados de dispositivo em frotas estáveis.
Se preferir evitar a infraestrutura NDES local, os gateways SCEP na nuvem se integram diretamente ao Intune e à sua CA via API, removendo totalmente a dependência do IIS.
Passo 3: Implante o perfil de Certificado de Raiz Confiável
Em sua plataforma MDM, crie um perfil de Certificado Confiável e carregue seu certificado de CA Raiz (e quaisquer certificados de CA Intermediária) como arquivos .cer. Implante este perfil nos seus grupos de dispositivos de destino antes de qualquer outro perfil de certificado ou WiFi. Sem esta etapa, os dispositivos não conseguirão validar o certificado do servidor RADIUS durante o handshake EAP-TLS e não poderão confiar na CA emissora ao solicitar seu próprio certificado SCEP.
Regra geral: Sempre direcione para o mesmo grupo do Azure AD (seja Usuários ou Dispositivos) em todos os três perfis relacionados. Uma incompatibilidade aqui é a causa mais comum de falhas na implantação de perfis de WiFi.
Passo 4: Configure o perfil de Certificado SCEP
Crie um perfil de configuração de certificado SCEP no seu MDM:
- Formato do nome do assunto (Subject name format): Para autenticação baseada em usuário, use
CN={{UserPrincipalName}}. Para autenticação de dispositivo (recomendado para dispositivos compartilhados e IoT), useCN={{AAD_Device_ID}}. - Uso de chave (Key usage): Assinatura Digital (Digital Signature), Criptografia de Chave (Key Encipherment).
- Uso avançado de chave (Extended key usage): Autenticação de Cliente (Client Authentication) (OID: 1.3.6.1.5.5.7.3.2).
- URL do servidor SCEP: A URL do NDES publicada externamente.
- Certificado raiz: Vincule ao perfil de Raiz Confiável do Passo 3.
- Período de validade do certificado: Deve corresponder ao modelo configurado na CA.
Passo 5: Implante o perfil de WiFi 802.1X
Crie um perfil de configuração de WiFi:
- SSID: Insira o nome da rede exatamente como transmitido pelos seus pontos de acesso.
- Tipo de segurança: WPA2-Enterprise ou WPA3-Enterprise.
- Tipo de EAP: EAP-TLS.
- Certificado de autenticação de cliente: Selecione o perfil de certificado SCEP do Passo 4.
- Validação de servidor: Especifique o certificado de Raiz Confiável do Passo 3 e insira o nome do servidor RADIUS esperado. Isso evita que os dispositivos se conectem a pontos de acesso invasores que apresentem certificados fraudulentos.
Melhores práticas
Imponha a verificação estrita de CRL no seu servidor RADIUS
A revogação de certificados é o controle operacional que elimina a lacuna entre desativar uma conta e bloquear o acesso à rede. Quando um dispositivo é perdido, roubado ou um funcionário sai da empresa, desative a conta do AD e revogue o certificado na CA. Seu servidor RADIUS deve ser configurado para verificar a CRL a cada tentativa de autenticação. Se a CRL estiver indisponível — porque o CDP (Ponto de Distribuição de CRL) está inacessível —, a maioria dos servidores RADIUS, por padrão, permite o acesso (fail open), o que representa um risco de segurança. Certifique-se de que seus CDPs tenham alta disponibilidade e que seu servidor RADIUS esteja configurado para bloquear o acesso (fail closed) caso a CRL não possa ser obtida.
Para revogação em tempo real, configure o OCSP (Online Certificate Status Protocol) além da CRL. O OCSP fornece respostas de status por certificado sem exigir que o servidor RADIUS baixe e analise toda a CRL.
Use certificados de dispositivo para dispositivos compartilhados e IoT
Para dispositivos compartilhados — tablets de governança de hotéis, terminais de PDV de varejo, leitores de controle de acesso de estádios —, use certificados de dispositivo em vez de certificados de usuário. Os certificados de dispositivo estão vinculados à identidade da máquina, não a uma conta de usuário. Isso significa que o dispositivo se autentica independentemente de qual usuário esteja conectado, e a revogação fica vinculada ao registro do dispositivo, em vez de à saída de um funcionário.
Para implantações no varejo , os certificados de dispositivo em hardware de PDV também atendem ao requisito do PCI DSS para identidade de dispositivo na camada de rede, sem introduzir a complexidade de credenciais de usuário no ponto de venda.
Automatize a renovação de certificados
O SCEP suporta renovação automática: o MDM instrui o dispositivo a se registrar novamente antes que o certificado expire. Configure seu perfil SCEP para acionar a renovação em 20% do período de validade restante do certificado. Para um certificado de um ano, a renovação começa aproximadamente 73 dias antes da expiração. Essa janela oferece tempo suficiente para resolver quaisquer falhas de renovação antes que o certificado expire e os dispositivos percam o acesso à rede.
Certificados expirados que causam falhas de autenticação em massa são o incidente operacional mais comum em implantações 802.1X. A renovação automatizada via SCEP elimina esse risco por completo.
Segmentar redes por atributo de certificado
Os servidores RADIUS podem ler atributos de certificado - Subject, SAN ou OIDs personalizados - e usá-los para atribuir dispositivos a VLANs dinamicamente. Um tablet de governança com um certificado emitido a partir do modelo HousekeepingDevices vai para a VLAN de governança. Um terminal de PDV com um certificado do modelo RetailPOS vai para a VLAN de escopo PCI. Essa é uma segmentação de rede aplicada criptograficamente - muito mais confiável do que abordagens baseadas em SSID ou MAC.
Para operadores de hospitalidade que executam Guest WiFi junto com Staff WiFi na mesma infraestrutura física, a atribuição de VLAN por meio de atributos de certificado garante que os convidados e a equipe estejam sempre em segmentos de rede separados, independentemente de qual SSID o dispositivo se conecte.
Solução de problemas e mitigação de riscos
Perfil de WiFi mostra 'Erro' ou 'Não aplicável' no Intune
Causa raiz: Incompatibilidade de direcionamento de grupo. O perfil SCEP está atribuído a um grupo diferente do perfil de WiFi. O Intune não consegue resolver a dependência do certificado.
Correção: Audite todos os três perfis (Trusted Root, SCEP, WiFi). Certifique-se de que todos estejam atribuídos exatamente ao mesmo grupo do Azure AD. Se você estiver implantando para Usuários, todos os três perfis devem ter como alvo um grupo de Usuários. Se estiver implantando para Dispositivos, todos os três devem ter como alvo um grupo de Dispositivos.
NDES retorna erros HTTP 403
Causa raiz: A conta de serviço do Intune Certificate Connector não possui permissões de Leitura ou Inscrição (Read ou Enroll) no modelo de certificado da CA, ou o filtro de URL do firewall está bloqueando as query strings do SCEP.
Correção: Verifique se a conta do conector possui permissões de Leitura e Inscrição (Read e Enroll) no modelo no console da CA. Verifique os logs do firewall para solicitações bloqueadas contendo ?operation=GetCACaps ou ?operation=PKIOperation. Essas query strings devem passar sem modificação.
Os dispositivos não conseguem renovar os certificados antes da expiração
Causa raiz: A janela de renovação do SCEP é muito curta ou o servidor NDES está inacessível no momento da renovação.
Correção: Defina o limite de renovação para 20% da validade do certificado. Certifique-se de que a URL do NDES seja publicada por meio de um proxy reverso de alta disponibilidade. Monitore os logs do IIS do NDES para falhas de solicitação de renovação e gere alertas proativamente.
O RADIUS rejeita certificados válidos
Causa raiz: O repositório de CA confiável do servidor RADIUS não inclui o certificado da CA emissora, ou a CRL está desatualizada.
Correção: Importe a cadeia de CA completa (Root CA + Issuing CA) para o repositório confiável do servidor RADIUS. Verifique se a CRL está sendo obtida com sucesso e se a URL do CDP está acessível a partir do servidor RADIUS. Verifique o carimbo de data/hora de próxima atualização da CRL — se já tiver passado, a CA precisará publicar uma nova CRL.
Para considerações mais amplas sobre o desempenho da rede juntamente com a segurança, consulte nosso guia de gerenciamento de largura de banda .
ROI e impacto nos negócios
O caso de negócios para a inscrição de certificados baseada em SCEP é simples. O WiFi baseado em senha gera um volume previsível de chamados de suporte: expirações de senha, bloqueios, funcionários compartilhando credenciais com convidados e fricção no onboarding de novos colaboradores. A autenticação baseada em certificado é invisível para o usuário final. Os dispositivos se conectam automaticamente. Não há senhas para expirar, compartilhar ou esquecer.
As organizações que migram do WiFi baseado em senha para o EAP-TLS com SCEP normalmente relatam uma redução de 70 a 80% nos chamados de suporte relacionados ao WiFi (dados internos da Purple, 2024, com base em implantações em propriedades de hospitalidade e varejo). A economia apenas com o suporte frequentemente justifica o custo de implementação logo no primeiro ano.
O impacto na conformidade é igualmente concreto. O EAP-TLS atende ao Requisito 8.6 do PCI DSS 4.0 para autenticação multifator na camada de rede. Para ambientes de saúde , ele se alinha com os requisitos de salvaguarda técnica da HIPAA para acesso à rede sem fio. Para organizações do setor público, ele apoia os requisitos de certificação NCSC Cyber Essentials Plus para controle de acesso à rede.
Para operadores de transporte — concessionárias ferroviárias, operadores aeroportuários, redes de ônibus — a autenticação baseada em certificado nos dispositivos dos funcionários garante que as redes operacionais que transportam dados críticos de segurança fiquem isoladas do WiFi dos passageiros e protegidas contra ataques baseados em credenciais.
A plataforma WiFi Analytics da Purple se integra a redes protegidas por 802.1X para fornecer insights de dados primários (first-party) sem comprometer a postura de segurança da infraestrutura subjacente. Os 29 bilhões de pontos de dados coletados na rede da Purple demonstram que segurança e analytics são objetivos complementares, não concorrentes.
Para gerenciamento de feedback e experiência juntamente com a implantação de sua rede segura, consulte nosso playbook de feedback do local .
Definições principais
SCEP (Simple Certificate Enrollment Protocol)
Um protocolo padronizado pela IETF (RFC 8894) que automatiza o registro de certificados X.509 para dispositivos gerenciados. O dispositivo gera sua própria chave privada localmente e envia apenas uma Solicitação de Assinatura de Certificado (CSR) para a CA por meio de um gateway. A chave privada nunca sai do dispositivo.
As equipes de TI encontram o SCEP ao configurar plataformas MDM (Intune, Jamf) para implantar certificados de autenticação WiFi em escala. É o mecanismo recomendado para implantações 802.1X EAP-TLS porque a chave privada é protegida por hardware no endpoint.
EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)
O método de autenticação 802.1X mais seguro. Tanto o dispositivo cliente quanto o servidor RADIUS apresentam certificados X.509. Nenhum dos lados pode se autenticar sem um certificado válido e não revogado da hierarquia de CA confiável.
O EAP-TLS é o protocolo de autenticação de destino que a implantação de certificados SCEP possibilita. Ele atende ao Requisito 8.6 do PCI DSS 4.0 e é necessário para implantações WPA3 Enterprise de 192 bits (Suite B).
PKCS (Public Key Cryptography Standards)
Um mecanismo de entrega de certificado onde a CA gera o par de chaves pública e privada centralmente e as transmite para o endpoint. A CA retém uma cópia da chave privada, permitindo o depósito de chaves.
As equipes de TI escolhem entre SCEP e PKCS ao configurar perfis de certificado no Intune. O PKCS é apropriado para criptografia de e-mail S/MIME onde o depósito de chaves é necessário. Não é recomendado para autenticação WiFi porque a chave privada é transmitida pela rede.
NDES (Network Device Enrollment Service)
Uma função do Microsoft Windows Server que atua como o gateway SCEP entre uma plataforma MDM e uma Autoridade de Certificação (CA). Ele valida as solicitações de registro de dispositivos e encaminha as CSRs para a CA.
O NDES é um componente de infraestrutura necessário para implantações SCEP locais com o Microsoft Intune. Ele deve ser publicado externamente por meio de um proxy de aplicativo para permitir que dispositivos remotos se registrem. Os gateways SCEP em nuvem são uma alternativa que elimina a dependência do NDES local.
CRL (Certificate Revocation List)
Uma lista publicada pela CA contendo os números de série dos certificados que foram revogados antes da data de expiração. Os servidores RADIUS verificam a CRL para garantir que dispositivos com certificados revogados não possam se autenticar.
A verificação de CRL é o controle operacional que impõe a revogação de certificados. As equipes de TI devem configurar seu servidor RADIUS para verificar a CRL em cada tentativa de autenticação e garantir que o Ponto de Distribuição de CRL (CDP) seja altamente disponível.
802.1X
Um padrão IEEE para controle de acesso à rede baseado em porta. Ele define a estrutura de autenticação de três partes (suplicante, autenticador, servidor de autenticação) usada em redes WiFi corporativas e cabeadas.
O 802.1X é a estrutura dentro da qual o EAP-TLS e o SCEP operam. As equipes de TI o encontram ao configurar SSIDs WPA2-Enterprise ou WPA3-Enterprise e ao definir políticas de servidor RADIUS.
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. Em implantações 802.1X, o servidor RADIUS valida os certificados dos clientes e impõe políticas de atribuição de VLAN.
O servidor RADIUS é o ponto de decisão de autenticação em toda implantação 802.1X. As implementações comuns incluem Microsoft NPS, FreeRADIUS e Cisco ISE. Ele deve ser configurado com a cadeia de CA confiável e verificação estrita de CRL ou OCSP.
CSR (Certificate Signing Request)
Um bloco de texto codificado gerado por um dispositivo que contém a chave pública e as informações de identidade do dispositivo. O dispositivo envia a CSR para a CA (via gateway SCEP) para solicitar um certificado assinado. A chave privada correspondente é gerada e retida no dispositivo.
A CSR é o artefato principal no fluxo de registro SCEP. As equipes de TI configuram o formato da CSR (nome do assunto, uso da chave, EKU) no perfil de certificado SCEP dentro de sua plataforma MDM.
PKI (Public Key Infrastructure)
A combinação de hardware, software, políticas e procedimentos necessários para criar, gerenciar, distribuir e revogar certificados digitais. Uma PKI corporativa padrão consiste em uma CA raiz offline e uma CA emissora online.
A PKI é o pré-requisito para qualquer implantação EAP-TLS. As equipes de TI devem projetar e implantar uma hierarquia de CA de duas camadas antes de configurar o SCEP. Os serviços de PKI hospedados na nuvem reduzem a carga de infraestrutura para implantações em propriedades distribuídas.
VLAN (Virtual Local Area Network)
Um segmento de rede lógico que isola o tráfego na Camada 2. Em implantações 802.1X, os servidores RADIUS atribuem dispositivos a VLANs dinamicamente com base nos atributos do certificado, identidade do usuário ou política.
A atribuição de VLAN via RADIUS é o mecanismo que impõe a segmentação de rede no WiFi corporativo. As equipes de TI o utilizam para separar dispositivos POS em VLANs de escopo PCI, dispositivos de hóspedes em VLANs apenas de internet e dispositivos de funcionários em VLANs corporativas - tudo a partir de uma única infraestrutura física.
Exemplos práticos
Uma propriedade Premier Inn de 200 quartos precisa implantar WiFi seguro para 150 dispositivos iOS de governança. Atualmente, a equipe compartilha uma senha WPA2-Personal com os hóspedes, criando um risco operacional e de conformidade. O Diretor de TI precisa eliminar a senha compartilhada sem interromper as operações diárias.
O Diretor de TI implementa uma implantação SCEP orientada pelo Jamf em três fases. Fase um: o certificado Root CA é enviado para todos os 150 dispositivos iOS por meio de um perfil Jamf Trusted Certificate, direcionado ao grupo inteligente 'Housekeeping Devices'. Fase dois: um perfil de certificado SCEP é implantado, direcionando os dispositivos para um servidor NDES publicado pelo Azure AD App Proxy. O nome do assunto usa CN={{SERIALNUMBER}} para vincular o certificado ao hardware do dispositivo. Fase três: um perfil de WiFi WPA2-Enterprise é enviado, especificando EAP-TLS e vinculando-o ao certificado SCEP. Os dispositivos se autenticam silenciosamente. O SSID de senha compartilhada é desativado. O servidor RADIUS é configurado com verificação estrita de CRL e atribuição de VLAN: os dispositivos de governança entram na VLAN 20 (operações), os dispositivos de hóspedes na VLAN 10 (apenas internet).
Uma rede de varejo com 500 locais precisa proteger o WiFi corporativo para tablets POS Windows que executam software de processamento de pagamentos. A conformidade com o PCI DSS 4.0 exige autenticação multifator na camada de rede. A configuração atual do WPA2-Personal falha na avaliação do Requisito 8.6 do PCI DSS.
O arquiteto de rede implanta EAP-TLS via Microsoft Intune e SCEP em todos os 500 locais. A implantação usa certificados de dispositivo com CN={{AAD_Device_ID}} como o nome do assunto, vinculando cada certificado ao registro do dispositivo no Intune. A sequência de três perfis (Trusted Root, SCEP, WiFi) é implantada no grupo do Azure AD 'POS Devices' - o mesmo grupo em todos os três perfis. O servidor RADIUS atribui os dispositivos POS a uma VLAN dedicada de escopo PCI (VLAN 100) com base no modelo de emissão do certificado. A CRL é publicada em um endpoint hospedado em CDN de alta disponibilidade com uma janela de validade de quatro horas. O OCSP está habilitado para verificação de revogação em tempo real. A implantação é validada em relação ao Requisito 8.6 do PCI DSS 4.0 pelo QSA.
Questões práticas
Q1. Você implantou perfis de certificado Trusted Root e SCEP no grupo de usuários 'All Staff' no Intune. Em seguida, implantou o perfil de WiFi no grupo de dispositivos 'Corporate Devices'. Os dispositivos recebem os certificados, mas o perfil de WiFi mostra 'Erro' no console do Intune. Qual é a causa mais provável e como você corrige isso?
Dica: Considere como o Intune resolve as dependências entre perfis e o que acontece quando os perfis são direcionados a diferentes tipos de grupos.
Ver resposta modelo
A causa raiz é uma incompatibilidade de direcionamento de grupo. O perfil de WiFi depende do perfil SCEP, que por sua vez depende do perfil Trusted Root. O Intune não consegue resolver essas dependências quando os perfis são direcionados a diferentes tipos de grupos (Usuários vs Dispositivos). Correção: reimplante todos os três perfis no mesmo grupo. Se o perfil de WiFi for direcionado a 'Corporate Devices' (um grupo de dispositivos), os perfis SCEP e Trusted Root também deverão ser direcionados a 'Corporate Devices'. Como alternativa, mova os três para um grupo de usuários se a autenticação baseada em usuário for necessária.
Q2. O iPad de um funcionário da governança do hotel é relatado como roubado. Você desativa imediatamente a conta do Active Directory do funcionário. Na manhã seguinte, o iPad roubado ainda está se conectando à rede WPA2-Enterprise do hotel. Por que isso acontece e quais duas ações você toma para evitar isso?
Dica: Pense no que o servidor RADIUS realmente valida durante a autenticação EAP-TLS e quais controles governam a validade do certificado.
Ver resposta modelo
Desativar a conta do AD não revoga o certificado de cliente armazenado no iPad. O servidor RADIUS valida o certificado, não o status da conta do AD, durante a autenticação EAP-TLS. As duas ações necessárias são: (1) revogar o certificado do dispositivo na CA - isso adiciona o número de série do certificado à CRL; (2) garantir que o servidor RADIUS esteja configurado com verificação estrita de CRL para que ele busque a CRL atualizada e rejeite o certificado revogado na próxima tentativa de autenticação. Para uma revogação mais rápida, configure o OCSP no servidor RADIUS para verificações de status de certificado em tempo real.
Q3. Uma rede de varejo está implantando WiFi 802.1X em 500 locais de POS. O arquiteto de segurança propõe o uso da entrega de certificados PKCS em vez do SCEP para evitar a implantação de um servidor NDES. O QSA que analisa a avaliação do PCI DSS 4.0 levanta uma preocupação. Qual é a preocupação e qual é a recomendação correta?
Dica: Considere o que o PCI DSS diz sobre o manuseio de chaves privadas e o que o PKCS faz com a chave privada durante a entrega.
Ver resposta modelo
A preocupação do QSA é que o PKCS transmite a chave privada pela rede, da CA para o dispositivo. O Requisito 3.5 do PCI DSS 4.0 exige que as chaves privadas usadas para autenticação sejam protegidas contra divulgação. Transmitir a chave privada pela rede - mesmo criptografada - introduz um risco que o SCEP elimina inteiramente. A recomendação correta é usar o SCEP, onde a chave privada é gerada no dispositivo POS e nunca sai dele. Para evitar a infraestrutura NDES local, o arquiteto deve avaliar um serviço de gateway SCEP em nuvem que se integre diretamente com o Intune e a CA via API.
Q4. Você está projetando uma rede WiFi para um grande centro de convenções que hospeda mais de 50 eventos por ano. Os dispositivos da equipe precisam estar em uma rede 802.1X segura. Você deseja garantir que, se o dispositivo de um prestador de serviços for comprometido, ele possa ser isolado da rede em até 15 minutos. Qual mecanismo de revogação de certificado você configura e por quê?
Dica: Compare CRL e OCSP em termos de latência de revogação e o que determina a rapidez com que um servidor RADIUS atua em uma revogação.
Ver resposta modelo
Configure o OCSP (Online Certificate Status Protocol) no servidor RADIUS. A revogação baseada em CRL tem uma latência determinada pelo período de validade da CRL - normalmente de uma a 24 horas - o que significa que um certificado revogado ainda pode ser autenticado até que o servidor RADIUS busque a próxima CRL. O OCSP fornece respostas de status por certificado em tempo real: quando um certificado é revogado na CA, o respondente OCSP retorna imediatamente um status 'revogado' na próxima consulta. Com o OCSP configurado no servidor RADIUS, um certificado de prestador de serviços revogado é bloqueado na próxima tentativa de autenticação, normalmente em segundos. Garanta que o respondente OCSP seja altamente disponível - se ele estiver inacessível e o servidor RADIUS estiver configurado para falhar fechado (fail closed), todas as autenticações falharão.
Continue a ler esta série
How to Set Up a Captive Portal on Starlink: A Guide for Remote & Maritime Venues
Este guia detalha como ignorar o hardware nativo do Starlink e integrar um Captive Portal gerenciado na nuvem usando equipamentos de roteamento corporativos. Você aprenderá como superar a limitação de CGNAT, aplicar a segmentação de VLAN, gerenciar restrições de largura de banda de satélite e garantir a conformidade regulatória.
Hotel Guest WiFi Management: Integrating PMS, Portals, and Brand Standards
Este guia técnico detalha como arquitetar redes WiFi de hotéis de nível empresarial, com foco na segmentação de VLAN, integração de PMS para gerenciamento automatizado de sessões e otimização de Captive Portal para captura de dados em conformidade com a GDPR.
Captive Portal Best Practices: Designing for High Conversion and Compliance
Este guia técnico oferece a gerentes de TI, arquitetos de rede e diretores de operações de locais um blueprint completo para implantar captive portals que equilibram a segurança da rede com uma alta conversão de usuários. Ele abrange toda a arquitetura, desde a segmentação de VLAN e autenticação RADIUS até o design de consentimento em conformidade com a GDPR e a seleção do método de autenticação. Extraído da experiência operacional da Purple em mais de 80.000 locais e 440 milhões de logins em 2024, cada recomendação é baseada em dados reais de implantação.