Como Implementar SCEP para a Inscrição Automatizada de Certificados WiFi
Este guia explica como implementar o SCEP (Simple Certificate Enrollment Protocol) para a inscrição automatizada de certificados WiFi em espaços empresariais. Abrange todo o plano de arquitetura - desde o design de PKI e integração de MDM até à sequência de implementação obrigatória de três passos - e mostra aos gestores de TI e arquitetos de rede como eliminar credenciais partilhadas, automatizar a gestão do ciclo de vida dos certificados e cumprir os requisitos de PCI DSS e GDPR à escala.
Ouça este guia
Ver transcrição do podcast
Resumo executivo
Para os operadores de espaços que executam Guest WiFi em hotéis, propriedades de retalho, estádios e centros de conferências, depender de chaves pré-partilhadas ou de Captive Portals básicos para o acesso à rede dos funcionários é um risco de segurança. A arquitetura de rede moderna exige autenticação 802.1X utilizando EAP-TLS (Extensible Authentication Protocol - Transport Layer Security), garantindo que cada dispositivo é verificado criptograficamente antes de aceder à rede. O desafio é a distribuição: como implementar certificados de cliente exclusivos em milhares de dispositivos Windows, iOS e Android sem sobrecarregar o seu suporte técnico?
A resposta é o SCEP - o Simple Certificate Enrollment Protocol. Formalizado pela IETF como RFC 8894 em 2020, o SCEP automatiza a inscrição de certificados em frotas de dispositivos geridos. Quando integrado com uma plataforma MDM, como o Microsoft Intune ou o Jamf, o SCEP oferece um aprovisionamento de certificados sem toque (zero-touch): os dispositivos solicitam, recebem e renovam os 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 detalha todo o fluxo de trabalho de implementação do SCEP: arquitetura de PKI, configuração do gateway NDES, a sequência obrigatória de implementação de MDM de três passos e os controlos operacionais - particularmente a verificação de CRL e a segmentação de grupos - que determinam se uma implementação é bem-sucedida ou se fica estagnada. Dois cenários do mundo real ilustram a abordagem em ambientes de hotelaria e retalho. A Purple opera em mais de 80.000 espaços ativos e conta com 350 milhões de utilizadores únicos; os padrões aqui descritos refletem o que funciona a essa escala.
Mergulho técnico profundo
O que o SCEP realmente faz
O SCEP situa-se entre a sua plataforma MDM e a sua Autoridade de Certificação (CA). Fornece um mecanismo padronizado baseado em HTTP para os dispositivos solicitarem, receberem e renovarem certificados X.509 sem necessitarem de uma credencial associada ao domínio ou de envolvimento manual do administrador. O protocolo foi originalmente desenvolvido no início dos anos 2000 e obteve uma adoção generalizada em ambientes MDM empresariais antes de a IETF o publicar formalmente como RFC 8894.
O fluxo de inscrição de seis passos funciona da seguinte forma. Primeiro, o dispositivo gerido liga-se ao URL do gateway SCEP pré-configurado no seu perfil MDM. Segundo, o dispositivo gera localmente um par de chaves privada/pública e cria um Certificate Signing Request (CSR). Terceiro, o gateway SCEP valida a autorização do dispositivo utilizando uma palavra-passe de desafio ou OTP incorporada na política de MDM. Quarto, o gateway encaminha o CSR validado para a CA. Quinto, a CA assina o certificado e devolve-o ao gateway. Sexto, o gateway entrega o certificado assinado ao dispositivo. As renovações futuras seguem o mesmo caminho automatizado - o dispositivo volta a inscrever-se antes de expirar, sem qualquer ação do utilizador 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 é de arquitetura, 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 (em Windows) ou o Secure Enclave (em iOS/macOS) protege a chave ao nível do hardware. Com o PKCS, a CA gera o par de chaves centralmente e transmite-o ao dispositivo através da rede. A CA retém uma cópia, permitindo a custódia de chaves - o que é útil para a encriptação de e-mail S/MIME, mas introduz um risco desnecessário para a autenticação de rede.
Para autenticação WiFi 802.1X, utilize 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 encriptação de e-mail (S/MIME) | Não | Sim |
| Custódia de chaves possível | Não | Sim |
802.1X e EAP-TLS: a estrutura de autenticação
O IEEE 802.1X é a norma de controlo de acesso à rede baseada em portas que sustenta a segurança WiFi empresarial. 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 o Microsoft NPS, FreeRADIUS ou Cisco ISE).
O EAP-TLS é o método EAP mais seguro para 802.1X. Ambos os lados apresentam certificados: o servidor RADIUS apresenta o seu certificado ao cliente, e o cliente apresenta o seu certificado provisionado por SCEP ao servidor RADIUS. Nenhum dos lados se pode fazer passar pelo outro sem um certificado válido e não revogado da hierarquia de CA fidedigna. Este modelo de autenticação mútua elimina o roubo de credenciais, ataques Evil Twin e riscos de pontos de acesso não autorizados (rogue) numa única decisão de arquitetura.
O EAP-TLS cumpre o Requisito 8.6 do PCI DSS 4.0 para autenticação multifator na camada de rede. É obrigatório para implementações WPA3 Enterprise de 192 bits (Suite B). Para qualquer rede sem fios no âmbito do processamento de dados de titulares de cartões - retalho ponto de venda, receção de hotel, bilheteira 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 certificados se enquadra numa postura de segurança mais ampla, consulte o nosso guia essencial.
Guia de implementação
A sequência de implementação é não negociável. O Intune e o Jamf resolvem as dependências de perfil por ordem: o perfil de WiFi depende do perfil SCEP, que por sua vez depende do perfil Trusted Root. Se os implementar fora de sequência, a aplicação do perfil de WiFi irá falhar.
Passo 1: Desenhe a sua PKI
Antes de tocar numa consola MDM, desenhe a sua hierarquia de certificados. Uma PKI de dois níveis é 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 implementações em recintos empresariais, os Serviços de Certificados do Active Directory da Microsoft (AD CS) executados no Windows Server fornecem a CA emissora. Os serviços de PKI alojados na nuvem de fornecedores como o SCEPman ou o SecureW2 eliminam totalmente o requisito de infraestrutura local e vale a pena avaliá-los para implementações distribuídas em grupos hoteleiros, cadeias de retalho ou organizações do setor público com vários locais.
Passo 2: Implementar 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 o seu MDM e a sua CA. Requisitos de configuração principais:
- Publique o URL do NDES externamente através do Azure AD Application Proxy (ou proxy inverso equivalente). Isto permite que os dispositivos remotos se registem 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 Registo (Read and Enroll) no modelo de certificado da CA.
- Configure o modelo de certificado com a Utilização de Chave (Key Usage) definida para Assinatura Digital (Digital Signature) e Cifragem de Chave (Key Encipherment), e a Utilização de Chave Alargada (Extended Key Usage) definida para Autenticação de Cliente (Client Authentication) (OID: 1.3.6.1.5.5.7.3.2).
- Defina um período de validade de certificado adequado. 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 integram-se diretamente com o Intune e a sua CA via API, removendo totalmente a dependência do IIS.
Passo 3: Implementar o perfil de Certificado de Raiz Confiável (Trusted Root)
Na sua plataforma MDM, crie um perfil de Certificado Confiável e carregue o seu certificado de CA Raiz (e quaisquer certificados de CA Intermédia) como ficheiros .cer. Implemente este perfil nos seus grupos de dispositivos de destino antes de quaisquer outros perfis de certificado ou de WiFi. Sem este passo, os dispositivos não conseguem validar o certificado do servidor RADIUS durante o handshake EAP-TLS e não podem confiar na CA emissora ao solicitar o seu próprio certificado SCEP.
Regra geral: Direcione sempre o mesmo grupo do Azure AD (Utilizadores ou Dispositivos) em todos os três perfis relacionados. Uma incompatibilidade aqui é a causa individual mais comum de falhas na implementação de perfis de WiFi.
Passo 4: Configurar o perfil de Certificado SCEP
Crie um perfil de configuração de certificado SCEP no seu MDM:
- Formato do nome do requerente (Subject name format): Para autenticação baseada no utilizador, utilize
CN={{UserPrincipalName}}. Para autenticação de dispositivo (recomendado para dispositivos partilhados e IoT), utilizeCN={{AAD_Device_ID}}. - Utilização de chave (Key usage): Digital Signature, Key Encipherment.
- Utilização de chave alargada (Extended key usage): Client Authentication (OID: 1.3.6.1.5.5.7.3.2).
- URL do servidor SCEP: O URL do NDES publicado externamente.
- Certificado de raiz: Ligação para o perfil Trusted Root do Passo 3.
- Período de validade do certificado: Deve corresponder ao modelo configurado na CA.
Passo 5: Implementar o perfil de WiFi 802.1X
Crie um perfil de configuração de WiFi:
- SSID: Introduza 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 do servidor: Especifique o certificado Trusted Root do Passo 3 e introduza o nome do servidor RADIUS esperado. Isto evita que os dispositivos se liguem a pontos de acesso fraudulentos que apresentem certificados falsos.
Boas práticas
Impor uma verificação rigorosa de CRL no seu servidor RADIUS
A revogação de certificados é o controlo operacional que elimina o intervalo entre desativar uma conta e bloquear o acesso à rede. Quando um dispositivo é perdido, roubado ou um funcionário sai, desative a conta do AD e revogue o certificado na CA. O seu servidor RADIUS deve estar configurado para verificar a CRL em cada tentativa de autenticação. Se a CRL estiver indisponível - porque o CDP (CRL Distribution Point) está inacessível - a maioria dos servidores RADIUS falha por omissão no modo aberto (fail open), o que constitui um risco de segurança. Certifique-se de que os seus CDPs estão altamente disponíveis e que o seu servidor RADIUS está configurado para falhar no modo fechado (fail closed) se a CRL não puder ser obtida.
Para revogação em tempo real, configure o OCSP (Online Certificate Status Protocol) além da CRL. OCSP fornece respostas de estado por certificado sem exigir que o servidor RADIUS descarregue e analise toda a CRL.
Utilizar certificados de dispositivo para dispositivos partilhados e IoT
Para dispositivos partilhados - tablets de limpeza de hotéis, terminais POS de retalho, leitores de controlo de acessos de estádios - utilize certificados de dispositivo em vez de certificados de utilizador. Os certificados de dispositivo estão associados à identidade da máquina, não a uma conta de utilizador. Isto significa que o dispositivo se autentica independentemente do utilizador que iniciou sessão, e a revogação está associada ao registo do dispositivo em vez da saída de um funcionário.
Para implementações de retalho , os certificados de dispositivo em hardware POS também cumprem o requisito do PCI DSS para a identidade do dispositivo na camada de rede, sem introduzir a complexidade de credenciais de utilizador no ponto de venda.
Automatizar a renovação de certificados
O SCEP suporta a renovação automática: o MDM instrui o dispositivo a registar-se novamente antes de o certificate expires. Configure o seu perfil SCEP para acionar a renovação a 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. Esta janela oferece tempo suficiente para resolver quaisquer falhas de renovação antes que o certificado expire e os dispositivos percam o acesso à rede.
Os certificados expirados que causam falhas de autenticação em massa são o incidente operacional mais comum em implementações 802.1X. A renovação automatizada via SCEP elimina totalmente este risco.
Segmentar redes por atributo de certificado
Os servidores RADIUS podem ler atributos de certificados - Subject, SAN ou OIDs personalizados - e utilizá-los para atribuir dispositivos a VLANs de forma dinâmica. Um tablet de limpeza com um certificado emitido a partir do modelo HousekeepingDevices entra na VLAN de limpeza. Um terminal POS com um certificado do modelo RetailPOS entra na VLAN de âmbito PCI. Trata-se de uma segmentação de rede imposta criptograficamente - muito mais fiável do que as abordagens baseadas em SSID ou baseadas em MAC.
Para operadores de hospitalidade que executam Guest WiFi juntamente com Staff WiFi na mesma infraestrutura física, a atribuição de VLAN através de atributos de certificado garante que os convidados e os funcionários estejam sempre em segmentos de rede separados, independentemente do SSID ao qual um dispositivo se liga.
Resolução de problemas e mitigação de riscos
O perfil de WiFi mostra 'Erro' ou 'Não Aplicável' no Intune
Causa raiz: Incompatibilidade de segmentação 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 os três perfis (Trusted Root, SCEP, WiFi). Certifique-se de que estão todos atribuídos exatamente ao mesmo grupo do Azure AD. Se estiver a implementar para Utilizadores, os três perfis devem visar um grupo de Utilizadores. Se estiver a implementar para Dispositivos, os três devem visar um grupo de Dispositivos.
O NDES devolve erros HTTP 403
Causa raiz: A conta de serviço do Intune Certificate Connector não tem permissões de Leitura ou Inscrição (Read ou Enroll) no modelo de certificado da CA, ou a filtragem de URL do firewall está a bloquear as query strings do SCEP.
Correção: Verifique se a conta do conector tem permissões de Leitura e Inscrição (Read e Enroll) no modelo na consola da CA. Verifique os registos do firewall para pedidos bloqueados que contenham ?operation=GetCACaps ou ?operation=PKIOperation. Estas query strings devem passar sem modificações.
Os dispositivos não conseguem renovar os certificados antes da expiração
Causa raiz: A janela de renovação do SCEP é demasiado 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 o URL do NDES é publicado através de um proxy inverso de alta disponibilidade. Monitorize os registos IIS do NDES para falhas de pedidos de renovação e emita alertas proativamente.
O RADIUS rejeita certificados válidos
Causa raiz: O arquivo de CA fidedignas 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 arquivo fidedigno do servidor RADIUS. Verifique se a CRL está a ser obtida com sucesso e se o URL do CDP está acessível a partir do servidor RADIUS. Verifique o carimbo de data/hora da próxima atualização da CRL - se já tiver passado, a CA precisa de publicar uma nova CRL.
Para considerações mais amplas sobre o desempenho da rede, juntamente com a segurança, consulte o nosso guia de gestão de largura de banda .
ROI e impacto no negócio
O caso de negócio para a inscrição de certificados baseada em SCEP é simples. O WiFi baseado em palavra-passe gera um volume previsível de pedidos de suporte (tickets de helpdesk): expirações de palavras-passe, bloqueios, partilha de credenciais de funcionários com convidados e fricção no onboarding de novos colaboradores. A autenticação baseada em certificado é invisível para o utilizador final. Os dispositivos ligam-se automaticamente. Não há palavras-passe para expirar, partilhar ou esquecer.
As organizações que migram de WiFi baseado em palavra-passe para EAP-TLS com SCEP reportam tipicamente uma redução de 70-80% nos pedidos de suporte relacionados com WiFi (dados internos da Purple, 2024, com base em implementações em propriedades de hotelaria e retalho). A poupança no helpdesk por si só justifica frequentemente o custo de implementação logo no primeiro ano.
O impacto na conformidade é igualmente concreto. O EAP-TLS cumpre o Requisito 8.6 do PCI DSS 4.0 para autenticação multifator na camada de rede. Para ambientes de saúde , alinha-se com os requisitos de salvaguarda técnica da HIPAA para acesso a redes sem fios. Para organizações do setor público, apoia os requisitos de certificação Cyber Essentials Plus do NCSC para controlo de acesso à rede.
Para operadores de transportes - concessões ferroviárias, operadores aeroportuários, redes de autocarros - a autenticação baseada em certificados nos dispositivos dos funcionários garante que as redes operacionais que transportam dados críticos de segurança sejam isoladas do WiFi de passageiros e protegidas contra ataques baseados em credenciais.
A plataforma WiFi Analytics da Purple integra-se com 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 mil milhões de pontos de dados recolhidos na rede da Purple demonstram que a segurança e a análise são objetivos complementares, não concorrentes.
Para gestão de feedback e experiência juntamente com a implementação da sua rede segura, consulte o nosso manual de feedback do local .
Definições Principais
SCEP (Simple Certificate Enrollment Protocol)
Um protocolo normalizado pela IETF (RFC 8894) que automatiza a inscrição de certificados X.509 para dispositivos geridos. O dispositivo gera a sua própria chave privada localmente e envia apenas um Certificate Signing Request para a CA através de um gateway. A chave privada nunca sai do dispositivo.
As equipas de TI deparam-se com o SCEP ao configurar plataformas MDM (Intune, Jamf) para implementar certificados de autenticação WiFi à escala. É o mecanismo recomendado para implementaçõ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 como o servidor RADIUS apresentam certificados X.509. Nenhum dos lados se pode autenticar sem um certificado válido e não revogado da hierarquia de CA fidedigna.
O EAP-TLS é o protocolo de autenticação de destino que a implementação de certificados SCEP permite. Cumpre o Requisito 8.6 do PCI DSS 4.0 e é obrigatório para implementações WPA3 Enterprise de 192 bits (Suite B).
PKCS (Public Key Cryptography Standards)
Um mecanismo de entrega de certificados onde a CA gera centralmente o par de chaves pública e privada e as transmite para o endpoint. A CA retém uma cópia da chave privada, permitindo a custódia de chaves.
As equipas de TI escolhem entre SCEP e PKCS ao configurar perfis de certificado no Intune. O PKCS é adequado para encriptação de e-mail S/MIME onde é necessária a custódia de chaves (key escrow). 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 gateway SCEP entre uma plataforma MDM e uma Autoridade de Certificação. Valida os pedidos de inscrição de dispositivos e encaminha os CSRs para a CA.
O NDES é um componente de infraestrutura obrigatório para implementações SCEP locais com o Microsoft Intune. Deve ser publicado externamente através de um proxy de aplicação para permitir a inscrição de dispositivos remotos. Os gateways SCEP na nuvem são uma alternativa que elimina a dependência de NDES local.
CRL (Certificate Revocation List)
Uma lista publicada pela CA que contém os números de série dos certificados que foram revogados antes da sua data de expiração. Os servidores RADIUS verificam a CRL para garantir que os dispositivos com certificados revogados não se conseguem autenticar.
A verificação de CRL é o controlo operacional que impõe a revogação de certificados. As equipas de TI devem configurar o seu servidor RADIUS para verificar a CRL em cada tentativa de autenticação e garantir que o Ponto de Distribuição de CRL (CDP) está altamente disponível.
802.1X
Uma norma IEEE para controlo de acesso à rede baseado em portas. Define a estrutura de autenticação de três partes (suplicante, autenticador, servidor de autenticação) utilizada em redes WiFi empresariais e com fios.
O 802.1X é a estrutura dentro da qual o EAP-TLS e o SCEP operam. As equipas de TI deparam-se com ele 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 auditoria (AAA) centralizadas para acesso à rede. Em implementações 802.1X, o servidor RADIUS valida os certificados de cliente e impõe políticas de atribuição de VLAN.
O servidor RADIUS é o ponto de decisão de autenticação em todas as implementações 802.1X. As implementações comuns incluem o Microsoft NPS, FreeRADIUS e Cisco ISE. Deve ser configurado com a cadeia de CA fidedigna 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 o CSR para a CA (através do gateway SCEP) para solicitar um certificado assinado. A chave privada correspondente é gerada e retida no dispositivo.
O CSR é o artefacto central no fluxo de inscrição SCEP. As equipas de TI configuram o formato do CSR (nome do assunto, utilização de chaves, EKU) no perfil de certificado SCEP dentro da sua plataforma MDM.
PKI (Public Key Infrastructure)
A combinação de hardware, software, políticas e procedimentos necessários para criar, gerir, distribuir e revogar certificados digitais. Uma PKI empresarial padrão consiste numa CA raiz offline e numa CA emissora online.
A PKI é o pré-requisito para qualquer implementação EAP-TLS. As equipas de TI devem desenhar e implementar uma hierarquia de CA de dois níveis antes de configurar o SCEP. Os serviços de PKI alojados na nuvem reduzem a carga de infraestrutura para implementaçõ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 implementações 802.1X, os servidores RADIUS atribuem dispositivos a VLANs dinamicamente com base nos atributos do certificado, identidade do utilizador ou política.
A atribuição de VLAN via RADIUS é o mecanismo que impõe a segmentação de rede em WiFi empresarial. As equipas de TI utilizam-no para separar dispositivos POS em VLANs de âmbito 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 com 200 quartos precisa de implementar WiFi seguro para 150 dispositivos iOS de limpeza (housekeeping). Atualmente, a equipa partilha uma palavra-passe WPA2-Personal com os hóspedes, criando um risco operacional e de conformidade. O Diretor de TI precisa de eliminar a palavra-passe partilhada sem interromper as operações diárias.
O Diretor de TI implementa uma implementação SCEP baseada em Jamf em três fases. Fase um: o certificado Root CA é enviado para todos os 150 dispositivos iOS através de um perfil Jamf Trusted Certificate, visando o grupo inteligente 'Housekeeping Devices'. Fase dois: é implementado um perfil de certificado SCEP, direcionando os dispositivos para um servidor NDES publicado via Azure AD App Proxy. O nome do assunto utiliza CN={{SERIALNUMBER}} para associar o certificado ao hardware do dispositivo. Fase três: é enviado um perfil WiFi WPA2-Enterprise, especificando EAP-TLS e ligando ao certificado SCEP. Os dispositivos autenticam-se silenciosamente. O SSID de palavra-passe partilhada é desativado. O servidor RADIUS é configurado com verificação estrita de CRL e atribuição de VLAN: os dispositivos de limpeza ficam na VLAN 20 (operações), os dispositivos de hóspedes na VLAN 10 (apenas internet).
Uma cadeia de retalho com 500 localizações precisa de 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 de WPA2-Personal falha na avaliação do Requisito 8.6 do PCI DSS.
O arquiteto de rede implementa EAP-TLS via Microsoft Intune e SCEP em todas as 500 localizações. A implementação utiliza certificados de dispositivo com CN={{AAD_Device_ID}} como nome do assunto, associando cada certificado ao registo do dispositivo no Intune. A sequência de três perfis (Trusted Root, SCEP, WiFi) é implementada no grupo 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 âmbito PCI (VLAN 100) com base no modelo de emissão do certificado. A CRL é publicada num endpoint alojado em CDN de alta disponibilidade com uma janela de validade de quatro horas. O OCSP está ativado para verificação de revogação em tempo real. A implementação é validada em relação ao Requisito 8.6 do PCI DSS 4.0 pelo QSA.
Perguntas de Prática
Q1. Implementou perfis de certificado Trusted Root e SCEP no grupo de utilizadores 'All Staff' no Intune. Em seguida, implementou o perfil WiFi no grupo de dispositivos 'Corporate Devices'. Os dispositivos recebem os certificados, mas o perfil WiFi mostra 'Erro' na consola do Intune. Qual é a causa mais provável e como a resolve?
Dica: Considere como o Intune resolve dependências entre perfis e o que acontece quando os perfis visam tipos de grupo diferentes.
Ver resposta modelo
A causa raiz é uma incompatibilidade de segmentação de grupo. O perfil WiFi depende do perfil SCEP, que por sua vez depende do perfil Trusted Root. O Intune não consegue resolver estas dependências quando os perfis visam tipos de grupo diferentes (Utilizadores vs Dispositivos). Resolução: volte a implementar os três perfis no mesmo grupo. Se o perfil WiFi visar 'Corporate Devices' (um grupo de dispositivos), os perfis SCEP e Trusted Root também devem visar 'Corporate Devices'. Alternativamente, mova os três para um grupo de utilizadores se for necessária autenticação baseada no utilizador.
Q2. O iPad de um funcionário de limpeza de um hotel é reportado como roubado. Desativa imediatamente a conta de Active Directory do funcionário. Na manhã seguinte, o iPad roubado continua a ligar-se à rede WPA2-Enterprise do hotel. Porquê, e que duas ações toma para evitar isto?
Dica: Pense no que o servidor RADIUS realmente valida durante a autenticação EAP-TLS e quais os controlos que regem a validade do certificado.
Ver resposta modelo
Desativar a conta de AD não revoga o certificado de cliente armazenado no iPad. O servidor RADIUS valida o certificado, e não o estado da conta de AD, durante a autenticação EAP-TLS. As duas ações necessárias são: (1) revogar o certificado do dispositivo na CA - isto adiciona o número de série do certificado à CRL; (2) garantir que o servidor RADIUS está configurado com verificação estrita de CRL para que obtenha 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 estado do certificado em tempo real.
Q3. Uma cadeia de retalho está a implementar WiFi 802.1X em 500 localizações de POS. O arquiteto de segurança propõe a utilização de entrega de certificados PKCS em vez de SCEP para evitar a implementaçã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 manuseamento 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 utilizadas para autenticação sejam protegidas contra divulgação. Transmitir a chave privada pela rede - mesmo encriptada - introduz um risco que o SCEP elimina por completo. A recomendação correta é utilizar 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 na nuvem que se integre diretamente com o Intune e a CA via API.
Q4. Está a desenhar uma rede WiFi para um grande centro de conferências que acolhe mais de 50 eventos por ano. Os dispositivos dos funcionários precisam de estar numa rede 802.1X segura. Pretende garantir que, se o dispositivo de um prestador de serviços for comprometido, este possa ser isolado da rede em 15 minutos. Que mecanismo de revogação de certificados configura e porquê?
Dica: Compare a CRL e o OCSP em termos de latência de revogação e o que determina a rapidez com que um servidor RADIUS atua sobre 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 se pode autenticar até que o servidor RADIUS obtenha a próxima CRL. O OCSP fornece respostas de estado por certificado em tempo real: quando um certificado é revogado na CA, o respondedor OCSP devolve imediatamente um estado 'revogado' na consulta seguinte. Com o OCSP configurado no servidor RADIUS, um certificado de prestador de serviços revogado é bloqueado na tentativa de autenticação seguinte, normalmente em segundos. Garanta que o respondedor OCSP está altamente disponível - se estiver inacessível e o servidor RADIUS estiver configurado para falhar de forma fechada (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 contornar o hardware nativo da Starlink e integrar um captive portal gerido na cloud utilizando equipamento de encaminhamento empresarial. Irá aprender a superar a limitação de CGNAT, impor a segmentação de VLAN, gerir as restrições de largura de banda de satélite e garantir a conformidade regulamentar.
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, focando-se na segmentação de VLAN, integração de PMS para gestão automatizada de sessões e otimização de captive portal para captura de dados em conformidade com o GDPR.
Captive Portal Best Practices: Designing for High Conversion and Compliance
Este guia técnico oferece aos gestores de TI, arquitetos de rede e diretores de operações de espaços um plano completo para implementar captive portals que equilibram a segurança da rede com uma elevada conversão de utilizadores. Abrange toda a arquitetura, desde a segmentação de VLAN e autenticação RADIUS até ao design de consentimento em conformidade com o GDPR e à seleção do método de autenticação. Baseado na experiência operacional da Purple em mais de 80.000 espaços e 440 milhões de inícios de sessão em 2024, cada recomendação é fundamentada em dados reais de implementação.