Saltar para o conteúdo principal

O Guia Empresarial do SCEP: Implementar o Simple Certificate Enrollment Protocol para Segurança Automatizada de WiFi em Campus

Este guia de referência técnica fornece um modelo arquitetónico definitivo e uma estratégia de implementação passo a passo para a implementação de certificados de WiFi empresariais utilizando SCEP. Abrange as diferenças críticas entre SCEP e PKCS, a sequência exata de implementação necessária para o sucesso e estratégias reais de mitigação de riscos para líderes de TI.

📖 6 min de leitura📝 1,270 palavras🔧 2 exemplos práticos3 perguntas de prática📚 8 definições principais

Ouça este guia

Ver transcrição do podcast
Bom dia. Se gere uma infraestrutura de WiFi num grupo hoteleiro, numa rede de retalho, num estádio ou num campus universitário, este briefing é para si. Vamos abordar o SCEP - Simple Certificate Enrollment Protocol - e, especificamente, como este resolve uma das dores de cabeça mais persistentes no WiFi empresarial: colocar certificados em milhares de dispositivos de forma automática, sem que o seu helpdesk fique afogado em pedidos de suporte. [short pause] Deixe-me enquadrar a situação. Decidiu - e bem - que as chaves pré-partilhadas já não são aceitáveis para o WiFi dos funcionários. Uma única palavra-passe comprometida expõe todo o seu segmento de rede. Já mudou, ou está a mudar, para a autenticação 802.1X. Essa é a norma IEEE que exige que cada dispositivo prove a sua identidade antes de obter acesso à rede. A variante mais segura do 802.1X é o EAP-TLS - Extensible Authentication Protocol com Transport Layer Security - que utiliza certificados digitais em vez de palavras-passe. Os certificados são criptograficamente exclusivos por dispositivo, não podem ser partilhados e podem ser revogados instantaneamente se um dispositivo for perdido ou se um funcionário sair. [short pause] Até aqui, tudo bem. O problema é a distribuição. Como colocar um certificado exclusivo em cada portátil, telemóvel ou tablet do seu parque informático - em Windows, iOS, Android, macOS - sem que um técnico tenha de tocar em cada dispositivo? É precisamente isso que o SCEP resolve. [medium pause] O SCEP foi formalizado pela Internet Engineering Task Force no RFC 8894 em 2020, embora já seja utilizado em ambientes empresariais desde o início dos anos 2000. É um protocolo que permite a um dispositivo gerido solicitar o seu próprio certificado diretamente à sua Autoridade de Certificação, utilizando um URL pré-configurado e uma palavra-passe de desafio. O ponto de segurança crítico aqui: a chave privada é gerada no próprio dispositivo, armazenada no enclave seguro do dispositivo - que é o chip TPM nos dispositivos Windows, ou o Secure Enclave no hardware Apple - e nunca viaja pela rede. O dispositivo gera um Pedido de Assinatura de Certificado, envia-o para o gateway SCEP, o gateway valida o desafio, encaminha o pedido para a sua Autoridade de Certificação, a CA assina-o e o certificado assinado regressa ao dispositivo. Todo o processo é invisível para o utilizador final. [short pause] Agora, num ambiente Microsoft, o gateway SCEP é normalmente o NDES - Network Device Enrollment Service - uma função do Windows Server que atua como intermediária entre a sua plataforma MDM e a sua CA. O Microsoft Intune envia o perfil SCEP para os dispositivos geridos, indicando-lhes o URL do NDES e a palavra-passe de desafio. Os dispositivos tratam do resto automaticamente. [medium pause] Deixe-me explicar como é uma implementação real. Pense num grupo hoteleiro com 150 propriedades - imagine à escala da Premier Inn. Têm uma mistura de portáteis Windows para o pessoal da receção, dispositivos iOS para os supervisores de limpeza e tablets Android no ponto de venda do restaurante. Antes do SCEP, utilizavam WPA2-Personal com uma palavra-passe partilhada rodada trimestralmente. Cada rotação gerava uma vaga de chamadas para o helpdesk. Com o SCEP e o Intune, implementam três perfis em sequência. Primeiro, o perfil de Certificado de Raiz Confiável - este diz a cada dispositivo para confiar na Autoridade de Certificação da empresa. Segundo, o perfil de Certificado SCEP - este instrui os dispositivos a recolherem o seu certificado de cliente exclusivo. Terceiro, o perfil de WiFi - este configura o SSID, define o tipo de segurança para WPA2-Enterprise ou WPA3-Enterprise e aponta para o certificado SCEP para autenticação. Implemente esses três perfis no mesmo grupo de dispositivos no Intune, e cada dispositivo gerido liga-se ao SSID corporativo automaticamente, com um certificado exclusivo, sem necessidade de qualquer interação do utilizador. [short pause] O servidor RADIUS - normalmente o Microsoft NPS ou um serviço RADIUS na nuvem - recebe o pedido de autenticação EAP-TLS, valida o certificado em relação à CA, verifica a Lista de Revogação de Certificados e concede ou nega o acesso. Se um funcionário for desligado, revoga o seu certificado na CA. O seu dispositivo perde o acesso ao WiFi no ciclo de autenticação seguinte. Sem necessidade de redefinir palavras-passe. Sem esperar por uma rotação trimestral. [medium pause] Agora, as pessoas perguntam frequentemente sobre a diferença entre SCEP e PKCS - Public Key Cryptography Standards. Ambos funcionam com o Intune. A principal diferença reside no local onde a chave privada é gerada. Com o SCEP, é gerada no dispositivo. Com o PKCS, a CA gera ambas as chaves de forma centralizada e envia a chave privada para o dispositivo. Isso significa que a chave privada viaja pela rede, o que introduz um risco teórico de interceção. O PKCS tem o seu lugar - é mais adequado para encriptação de e-mail S/MIME, onde a custódia de chaves (key escrow) é importante. Para autenticação WiFi, o SCEP é la escolha certa. Sempre. [short pause] Deixe-me dar-lhe um segundo cenário - uma rede de retalho. Imagine um retalhista de moda com 200 lojas em todo o Reino Unido, cada uma com pontos de acesso Cisco Meraki. Os seus sistemas de ponto de venda são baseados em Windows, geridos através do Intune. Necessitam de conformidade com o PCI DSS, o que significa segmentação de rede e autenticação forte para qualquer dispositivo que lide com dados de titulares de cartões. O EAP-TLS baseado em SCEP oferece-lhes autenticação ao nível do dispositivo no SSID dos funcionários, com a atribuição de VLAN gerida pela política RADIUS. Os terminais POS entram automaticamente na VLAN de âmbito PCI. O Guest WiFi - gerido separadamente através de uma plataforma como a Purple - funciona num SSID completamente isolado com o seu próprio fluxo de autenticação. As duas redes nunca se tocam. Os auditores ficam satisfeitos. A equipa de segurança dorme melhor. [medium pause] Muito bem, vamos falar sobre as armadilhas, porque existem algumas que costumam surpreender as equipas. [short pause] O modo de falha mais comum são as incompatibilidades de direcionamento de grupos no Intune. O seu perfil de Raiz Confiável, o seu perfil SCEP e o seu perfil de WiFi devem todos direcionar-se ao mesmo grupo do Azure AD. Se o perfil SCEP se direcionar a um grupo de Utilizadores e o perfil de WiFi a um grupo de Dispositivos, o Intune não conseguirá resolver a dependência e o perfil de WiFi apresentará um erro. Verifique primeiro as suas atribuições - é quase sempre aí que reside o problema. [short pause] Segunda armadilha: disponibilidade do servidor NDES. O seu servidor NDES precisa de estar acessível a partir da internet para que os dispositivos remotos se possam registar antes de chegarem ao local. A forma segura de o fazer é através do Azure AD Application Proxy, que lhe concede acesso remoto sem abrir portas de firewall de entrada. Não exponha o NDES diretamente à internet. [short pause] Terceira: disponibilidade da CRL. O seu servidor RADIUS verifica a Lista de Revogação de Certificados sempre que um dispositivo se autentica. Se o Ponto de Distribuição da CRL estiver inacessível - talvez um servidor esteja em baixo ou uma regra de firewall tenha mudado - a autenticação falha para todos. Torne os seus endpoints de CRL altamente disponíveis e teste-os regularmente. [short pause] Quarta: permissões do modelo de certificado. Se a conta de serviço do seu conector NDES não tiver permissões de Leitura e Inscrição (Read and Enroll) no modelo de certificado, os dispositivos recebem erros HTTP 403 quando tentam recolher o seu certificado. É uma correção simples de permissões, mas é fácil de esquecer durante a configuração inicial. [medium pause] Agora, uma ronda de perguntas rápidas. [short pause] O SCEP pode funcionar com MDMs que não sejam da Microsoft? Sim - o Jamf para frotas de dispositivos Apple, o VMware Workspace ONE e a maioria das plataformas MDM empresariais suportam perfis SCEP. O protocolo é neutro em termos de fornecedor. [short pause] O SCEP funciona com PKI na nuvem? Sim. A própria PKI na nuvem da Microsoft no Intune Suite elimina completamente a necessidade de um servidor NDES local. Fornecedores de PKI na nuvem de terceiros, como o SecureW2 e o Keyfactor, também oferecem endpoints SCEP na nuvem. [short pause] E quanto ao WPA3-Enterprise? O WPA3-Enterprise utiliza a mesma pilha de autenticação 802.1X e EAP-TLS. Os certificados emitidos por SCEP funcionam de forma idêntica. A atualização ocorre na camada do protocolo sem fios, não na camada do certificado. [short pause] Quanto tempo duram os certificados? Normalmente um ano, embora possa configurar períodos de validade mais curtos. O Intune trata da renovação automática antes da expiração, pelo que os utilizadores nunca sofrem interrupções. [medium pause] Em resumo. O SCEP automatiza a distribuição de certificados em escala, eliminando a sobrecarga manual da implementação de PKI em grandes frotas de dispositivos. A chave privada permanece no dispositivo - essa é a base de segurança do EAP-TLS. Implemente em sequência: primeiro a Raiz Confiável, segundo o perfil SCEP, terceiro o perfil de WiFi, todos direcionados ao mesmo grupo. Publique o seu endpoint NDES de forma segura através do Application Proxy. Mantenha os seus endpoints de CRL altamente disponíveis. E se estiver a começar do zero, avalie a PKI na nuvem para remover totalmente a dependência do NDES local. [short pause] Para o WiFi de convidados - a rede separada e voltada para os visitantes - a autenticação baseada em certificados não é o modelo adequado. Os convidados não possuem dispositivos geridos. É aí que uma plataforma como a Purple gere o fluxo de autenticação: Captive Portal, login social, recolha de e-mails ou verificação por SMS, tudo alimentando uma camada de dados primários (first-party data) que a sua equipa de marketing pode realmente utilizar. As duas abordagens complementam-se: SCEP para o seu parque de dispositivos geridos de funcionários, Purple para a sua rede de convidados. Ambas a funcionar no mesmo hardware, segmentadas de forma limpa por VLAN. [short pause] Este é o seu briefing sobre a integração de WiFi empresarial com SCEP. O guia escrito completo, com diagramas de arquitetura, configuração passo a passo do Intune e exemplos práticos, está disponível no website da Purple. Obrigado por nos ouvir.

header_image.png

Resumo Executivo

Para espaços empresariais, quer se trate de um ambiente hoteleiro movimentado, de uma operação de retalho multilocalização ou de um campus corporativo moderno, depender de chaves pré-partilhadas ou de Captive Portals básicos para o WiFi dos funcionários é uma vulnerabilidade de segurança e um estrangulamento operacional. A arquitetura de rede moderna exige autenticação 802.1X utilizando EAP-TLS, garantindo que cada dispositivo seja verificado criptograficamente antes de aceder à rede.

O desafio reside na distribuição: como implementar certificados de cliente exclusivos em milhares de dispositivos Windows, iOS e Android sem afogar o seu helpdesk em pedidos de suporte? O Microsoft Intune e outras plataformas MDM resolvem este problema através da gestão automatizada do ciclo de vida dos certificados. Ao implementar perfis de Simple Certificate Enrollment Protocol (SCEP), as equipas de TI enviam certificados de raiz confiáveis e de cliente de forma silenciosa para os endpoints geridos.

Este guia fornece um modelo arquitetónico definitivo e uma estratégia de implementação passo a passo para a implementação de certificados de WiFi empresariais. Exploramos as diferenças críticas entre SCEP e PKCS, detalhamos a sequência exata de implementação necessária para o sucesso e delineamos estratégias reais de mitigação de riscos para garantir que o seu WiFi de Convidados e as redes corporativas permaneçam seguros e eficientes.

Ouça o Briefing

Análise Técnica Detalhada: Arquitetura SCEP

Ao conceber a sua estratégia de implementação de certificados de WiFi empresariais, a primeira decisão arquitetónica é selecionar o mecanismo de entrega de certificados. As plataformas de gestão de dispositivos móveis suportam tanto o SCEP como o PKCS, mas funcionam de forma fundamentalmente diferente.

Simple Certificate Enrollment Protocol (SCEP)

O SCEP é o padrão da indústria para o registo de dispositivos empresariais. Num fluxo de trabalho SCEP, o serviço de gestão instrui o endpoint a gerar o seu próprio par de chaves privada e pública. O dispositivo cria um Pedido de Assinatura de Certificado (CSR) e envia-o através de um servidor Network Device Enrollment Service (NDES) para a sua Autoridade de Certificação (CA). A CA assina o pedido e devolve o certificado público ao dispositivo.

A vantagem crítica de segurança do SCEP é que a chave privada nunca sai do dispositivo. É gerada localmente, armazenada no enclave seguro do dispositivo (como o TPM em Windows ou o Secure Enclave em iOS), e nunca é transmitida pela rede. Isto torna o SCEP a abordagem fortemente recomendada para a autenticação 802.1X.

scep_architecture_overview.png

Public Key Cryptography Standards (PKCS)

Por outro lado, com o PKCS, a Autoridade de Certificação gera as chaves pública e privada de forma centralizada. O conector de certificados exporta este par de chaves de forma segura e envia-o para o dispositivo de destino.

Embora o PKCS elimine a necessidade de implementar e manter um servidor NDES, simplificando a pegada da infraestrutura, introduz um risco teórico de segurança porque a chave privada é transmitida pela rede. O PKCS é geralmente mais adequado para casos de utilização onde a custódia de chaves (key escrow) é necessária, como a encriptação de e-mail S/MIME, em vez da autenticação de rede.

scep_vs_pkcs_comparison.png

Guia de Implementação: A Sequência de Implementação

A configuração bem-sucedida de um perfil de WiFi gerido para 802.1X requer a adesão estrita a uma sequência de implementação específica. As dependências de perfil ditam que a confiança deve ser estabelecida antes que a autenticação possa ser configurada.

Passo 1: Implementar o Perfil de Certificado de Raiz Confiável

Antes que qualquer dispositivo possa solicitar um certificado de cliente ou confiar no seu servidor RADIUS, deve confiar na Autoridade de Certificação emissora.

  1. Exporte o seu certificado de CA de Raiz e quaisquer certificados de CA Intermédia como ficheiros .cer.
  2. Na sua consola MDM, crie um novo perfil de configuração.
  3. Selecione a plataforma de destino e escolha o tipo de perfil de certificado confiável.
  4. Carregue o ficheiro .cer e implemente este perfil nos seus grupos de dispositivos de destino.

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.

  1. Crie um novo perfil de configuração e selecione o certificado SCEP.
  2. Configure o formato do nome do assunto (subject name). Para autenticação baseada no utilizador, CN={{UserPrincipalName}} é o padrão. Para autenticação de dispositivo, utilize CN={{AAD_Device_ID}}.
  3. Defina a utilização da chave para assinatura digital e cifragem de chave (key encipherment).
  4. Em utilização avançada da chave (extended key usage), especifique a autenticação do cliente (OID: 1.3.6.1.5.5.7.3.2).
  5. Associe este perfil ao perfil de certificado de raiz confiável criado no Passo 1.
  6. Forneça o URL externo do seu gateway SCEP ou servidor NDES.

Passo 3: Implementar o Perfil de WiFi 802.1X

O passo final é enviar a configuração de WiFi que associa os certificados ao SSID da rede.

  1. Crie um perfil de configuração de WiFi.
  2. Introduza o nome da rede exatamente como é transmitido pelos seus pontos de acesso sem fios.
  3. Selecione WPA2-Enterprise ou WPA3-Enterprise como o tipo de segurança.
  4. Defina o tipo de EAP para EAP-TLS.
  5. Nas definições de autenticags, select the SCEP certificate profile created in Step 2 as the client authentication certificate.
  6. Specify the trusted root certificate for server validation to ensure the device only connects to your legitimate RADIUS server.

Best Practices & Industry Standards

When implementing SCEP certificate deployment, adhere to the following vendor-neutral best practices to ensure compliance and reliability.

SCEP Gateway Placement and Security

The SCEP gateway must be accessible from the internet to allow remote devices to provision certificates before arriving on-site. Exposing an internal server directly to the internet is a significant security risk. Publish the SCEP URL using an application proxy or reverse proxy. This provides secure remote access without opening inbound firewall ports and allows you to apply conditional access policies to the enrollment flow.

RADIUS and CRL Checking

Certificate deployment is only half the security equation; revocation is equally critical. If an employee is terminated, disabling their directory account may not immediately revoke their WiFi access if their client certificate remains valid and the RADIUS server is not strictly checking the Certificate Revocation List (CRL).

Configure your RADIUS server to enforce strict CRL checking. Ensure your CRL distribution points are highly available; if the RADIUS server cannot reach the CRL, authentication will fail, causing a widespread outage.

For broader considerations on modern connectivity, review our guidance on Bandwidth Management: A Practical Guide for 2026 .

Troubleshooting & Risk Mitigation

Even with meticulous planning, certificate deployment can encounter issues. Here are common failure modes and mitigation strategies.

WiFi Profile Fails to Apply

The device receives the trusted root and SCEP certificates, but the WiFi profile shows as an error or not applicable in the MDM console. This is almost always caused by a mismatch in group targeting. If the SCEP profile is assigned to a user group, but the WiFi profile is assigned to a device group, the MDM cannot resolve the dependency. Audit your assignments. Ensure the trusted root, SCEP, and WiFi profiles are all deployed to the exact same group.

Gateway 403 Forbidden Errors

Devices fail to retrieve the SCEP certificate, and the gateway logs show HTTP 403 errors. The connector service account lacks the necessary permissions on the certificate template, or the URL filtering on your firewall is blocking the specific query string parameters used by SCEP. Verify that the connector account has read and enroll permissions on the CA template. Check firewall logs to ensure URLs containing ?operation=GetCACaps are not being blocked.

ROI & Business Impact

Transitioning to SCEP-driven 802.1X certificate deployment delivers measurable returns across security and operations.

  1. Helpdesk Ticket Reduction: Password-based WiFi generates a significant volume of support tickets regarding password expirations, lockouts, and typos. Certificate-based authentication is invisible to the user, typically reducing WiFi-related helpdesk volume by 70%.
  2. Enhanced Security Posture: EAP-TLS eliminates the risk of credential harvesting and Man-in-the-Middle attacks. This is critical for compliance with frameworks like PCI DSS and GDPR, particularly in Retail and Healthcare environments.
  3. Seamless Onboarding: Integrating certificate deployment with existing MDM workflows ensures a unified, zero-touch provisioning experience from day one.

While SCEP secures your managed corporate devices, guest and visitor networks require a different approach. For unmanaged devices, a captive portal with social login or SMS verification feeds into a first-party data layer, giving you actionable insights. Explore our WiFi Analytics platform to see how this data drives revenue.

Definições Principais

SCEP (Simple Certificate Enrollment Protocol)

Um protocolo que permite aos dispositivos solicitar certificados digitais a uma Autoridade de Certificação, onde a chave privada é gerada e armazenada de forma segura no próprio dispositivo.

O método recomendado para implementar certificados de autenticação WiFi devido à sua elevada segurança e escalabilidade em frotas empresariais.

PKCS (Public Key Cryptography Standards)

Um conjunto de normas onde as chaves pública e privada são geradas pela Autoridade de Certificação e, em seguida, entregues de forma segura ao endpoint.

Frequentemente utilizado para encriptação de e-mail S/MIME, mas menos ideal para autenticação WiFi devido à transmissão da chave privada pela rede.

NDES (Network Device Enrollment Service)

Uma função do Microsoft Windows Server que atua como uma ponte, permitindo que dispositivos sem credenciais de domínio obtenham certificados via SCEP.

Um componente de infraestrutura obrigatório ao implementar a distribuição de certificados SCEP com PKI local da Microsoft.

EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)

O método de autenticação 802.1X mais seguro, que exige que tanto o servidor como o cliente apresentem certificados digitais válidos.

O protocolo de autenticação de destino que os perfis de WiFi e de certificado de MDM são concebidos para ativar, eliminando o acesso baseado em palavra-passe.

CRL (Certificate Revocation List)

Uma lista publicada pela Autoridade de Certificação que contém os números de série dos certificados que foram revogados antes da sua data de expiração programada.

Os servidores RADIUS devem verificar a CRL durante a autenticação para garantir que funcionários desligados não consigam aceder à rede utilizando um certificado anteriormente válido.

CSR (Certificate Signing Request)

Um bloco de texto codificado fornecido a uma Autoridade de Certificação ao solicitar um certificado SSL/TLS, contendo a chave pública e informações de identidade.

Gerado localmente pelo dispositivo gerido durante o fluxo SCEP para solicitar a sua credencial de identidade exclusiva.

802.1X

Uma norma IEEE para controlo de acesso à rede baseado em portas que fornece um mecanismo de autenticação para dispositivos que desejam ligar-se a uma LAN ou WLAN.

A estrutura fundamental que impõe o requisito de validação de certificado EAP-TLS antes de conceder acesso à rede.

RADIUS (Remote Authentication Dial-In User Service)

Um protocolo de rede que fornece gestão centralizada de autenticação, autorização e faturação (accounting) para utilizadores que se ligam e utilizam um serviço de rede.

O servidor que avalia o certificado de cliente em relação à CA e à CRL para tomar a decisão final de permitir ou negar o acesso WiFi.

Exemplos Práticos

Um grupo hoteleiro com 150 propriedades precisa de proteger a rede dos seus funcionários num ecossistema misto de portáteis Windows para a receção, dispositivos iOS para o serviço de quartos e tablets Android para o ponto de venda do restaurante. Atualmente, utilizam WPA2-Personal com uma palavra-passe partilhada rodada trimestralmente, gerando um volume massivo de pedidos de suporte.

O grupo hoteleiro implementa três perfis do Intune em sequência num grupo de dispositivos unificado. Primeiro, um perfil de Certificado de Raiz Confiável estabelece a confiança com a CA corporativa. Segundo, um perfil de Certificado SCEP instrui os dispositivos a solicitar um certificado de cliente exclusivo. Terceiro, um perfil de WiFi configura o SSID corporativo com WPA3-Enterprise e EAP-TLS, apontando para o certificado SCEP para autenticação. O servidor RADIUS impõe uma verificação rigorosa de CRL para revogar o acesso instantaneamente após a rescisão de um funcionário.

Comentário do Examinador: Esta abordagem elimina a sobrecarga da rotação trimestral de palavras-passe e protege a rede contra a partilha de credenciais. O SCEP é escolhido em detrimento do PKCS para garantir que a chave privada nunca sai dos dispositivos individuais, mantendo uma postura de zero-trust em diversos hardwares.

Um retalhista de moda com 200 lojas necessita de conformidade com o PCI DSS para os seus sistemas de ponto de venda baseados em Windows geridos através do Intune. Devem garantir uma autenticação forte e uma segmentação de rede rigorosa para qualquer dispositivo que lide com dados de titulares de cartões.

O retalhista implementa EAP-TLS baseado em SCEP para autenticação ao nível do dispositivo no SSID dos funcionários. A política RADIUS orienta a atribuição de VLAN, colocando automaticamente os terminais POS autenticados numa VLAN estritamente isolada e no âmbito do PCI. O Guest WiFi é gerido num SSID completamente separado com o seu próprio fluxo de autenticação de Captive Portal, garantindo que as duas redes nunca se cruzem.

Comentário do Examinador: Ao associar a segmentação de rede diretamente à autenticação baseada em certificados, o retalhista cumpre os requisitos do PCI DSS sem configuração de rede manual por loja. A separação física da rede de convidados utilizando uma plataforma como a Purple evita o aumento do âmbito da auditoria PCI.

Perguntas de Prática

Q1. A sua implementação do Intune mostra os perfis de Raiz Confiável e SCEP aplicados com sucesso ao portátil de um utilizador, mas o perfil de WiFi mostra um estado de 'Erro'. O utilizador não consegue ligar-se ao SSID corporativo. Qual é a causa arquitetónica mais provável?

Dica: Considere como as plataformas MDM resolvem as dependências entre perfis de configuração relacionados.

Ver resposta modelo

Uma incompatibilidade no direcionamento de grupos. O perfil SCEP está provavelmente atribuído a um grupo de Utilizadores, enquanto o perfil de WiFi está atribuído a um grupo de Dispositivos (ou vice-versa). O Intune não consegue resolver a dependência entre diferentes tipos de grupos, fazendo com que a implementação do perfil de WiFi falhe. Audite as atribuições e garanta que os três perfis se direcionam exatamente ao mesmo grupo do Azure AD.

Q2. Uma subsidiária recém-adquirida exige autenticação 802.1X para os dispositivos dos seus funcionários. A sua equipa de segurança exige que as chaves privadas nunca atravessem a rede e sejam geradas dentro do TPM de hardware do endpoint. Qual método de implementação de certificado deve utilizar?

Dica: Compare onde a chave privada é gerada no fluxo de trabalho SCEP versus o fluxo de trabalho PKCS.

Ver resposta modelo

Deve utilizar o SCEP (Simple Certificate Enrollment Protocol). Num fluxo de trabalho SCEP, o dispositivo gera o seu próprio par de chaves privada e pública localmente dentro do seu enclave seguro (TPM) e envia apenas um Pedido de Assinatura de Certificado (CSR) através da rede. O PKCS gera a chave privada centralmente na CA e transmite-a pela rede, o que viola a exigência da equipa de segurança.

Q3. Um funcionário é desligado e a sua conta do Active Directory é desativada. No entanto, o seu portátil permanece ligado à rede WiFi corporativa durante várias horas antes de perder o acesso. Como resolve esta lacuna de segurança?

Dica: Desativar uma conta não invalida um certificado existente. Que mecanismo utiliza o servidor RADIUS para verificar a validade do certificado?

Ver resposta modelo

Deve configurar o servidor RADIUS para impor uma verificação rigorosa da Lista de Revogação de Certificados (CRL). Quando um funcionário é desligado, o seu certificado deve ser explicitamente revogado na Autoridade de Certificação. O servidor RADIUS irá então verificar a CRL durante o próximo ciclo de autenticação e negar imediatamente o acesso, independentemente do estado da conta do Active Directory.

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.

Ler o guia →

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.

Ler o guia →

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.

Ler o guia →