Pular para o conteúdo principal

O Guia Corporativo para SCEP: Implantando 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 implantação de certificados WiFi corporativos usando SCEP. Ele aborda as diferenças críticas entre SCEP e PKCS, a sequência exata de implantação necessária para o sucesso e estratégias reais de mitigação de riscos para líderes de TI.

Publicado Atualizado
📖 6 min de leitura1,217 palavras2 exemplos práticos3 questões práticas8 definições principais

Ouça este guia

Ver transcrição do podcast
Bom dia. Se você gerencia infraestrutura de WiFi em um grupo de hotéis, uma rede de varejo, um estádio ou um campus universitário, este briefing é para você. Vamos falar sobre SCEP - Simple Certificate Enrollment Protocol - e, especificamente, como ele resolve uma das dores de cabeça mais persistentes no WiFi corporativo: colocar certificados em milhares de dispositivos de forma automática, sem que seu suporte técnico fique sobrecarregado de chamados. [short pause] Deixe-me contextualizar. Você decidiu - corretamente - que chaves pré-compartilhadas não são mais aceitáveis para o WiFi da equipe. Uma única senha comprometida expõe todo o seu segmento de rede. Você migrou, ou está migrando, para a autenticação 802.1X. Esse é o padrão IEEE que exige que cada dispositivo comprove sua identidade antes de obter acesso à rede. A versão mais segura do 802.1X é o EAP-TLS - Extensible Authentication Protocol com Transport Layer Security - que utiliza certificados digitais em vez de senhas. Os certificados são criptograficamente exclusivos por dispositivo, não podem ser compartilhados e podem ser revogados instantaneamente se um dispositivo for perdido ou se um funcionário sair da empresa. [short pause] Até aí, tudo bem. O problema é a distribuição. Como você coloca um certificado exclusivo em cada notebook, cada celular, cada tablet em sua propriedade - em sistemas Windows, iOS, Android, macOS - sem que um técnico precise tocar em cada dispositivo? É exatamente isso que o SCEP resolve. [medium pause] O SCEP foi formalizado pela Internet Engineering Task Force na RFC 8894 em 2020, embora já seja utilizado em ambientes corporativos desde o início dos anos 2000. É um protocolo que permite que um dispositivo gerenciado solicite seu próprio certificado diretamente à sua Autoridade Certificadora, usando uma URL pré-configurada e uma senha de desafio. O ponto crítico de segurança aqui: a chave privada é gerada no próprio dispositivo, armazenada no enclave seguro do dispositivo - que é o chip TPM em dispositivos Windows, ou o Secure Enclave no hardware da Apple - e ela nunca trafega pela rede. O dispositivo gera uma Solicitação de Assinatura de Certificado, envia para o gateway SCEP, o gateway valida o desafio, encaminha a solicitação para a sua Autoridade Certificadora, a CA assina e o certificado assinado retorna para o dispositivo. Todo o processo é invisível para o usuário final. [short pause] Agora, em um ambiente Microsoft, o gateway SCEP é normalmente o NDES - Network Device Enrollment Service - uma função do Windows Server que atua como intermediária entre sua plataforma MDM e sua CA. O Microsoft Intune envia o perfil SCEP para os dispositivos gerenciados, informando a eles a URL do NDES e a senha de desafio. Os dispositivos fazem o resto automaticamente. [medium pause] Deixe-me orientar você sobre como é uma implantação real. Pense em um grupo hoteleiro com 150 propriedades — imagine a escala do Premier Inn. Eles têm uma mistura de laptops Windows para a equipe da recepção, dispositivos iOS para os supervisores de governança e tablets Android no ponto de venda do restaurante. Antes do SCEP, eles usavam WPA2-Personal com uma senha compartilhada rotacionada trimestralmente. Cada rotação gerava uma onda de chamadas para o suporte técnico. Com o SCEP e o Intune, eles implantam três perfis em sequência. Primeiro, o perfil de Certificado de Raiz Confiável — isso diz a cada dispositivo para confiar na Autoridade de Certificação da empresa. Segundo, o perfil de Certificado SCEP — isso instrui os dispositivos a buscarem seu certificado de cliente exclusivo. Terceiro, o perfil de WiFi — isso configura o SSID, define o tipo de segurança como WPA2-Enterprise ou WPA3-Enterprise e aponta para o certificado SCEP para autenticação. Implante esses três perfis no mesmo grupo de dispositivos no Intune, e cada dispositivo gerenciado se conectará ao SSID corporativo automaticamente, com um certificado exclusivo, sem necessidade de qualquer interação do usuário. [short pause] O servidor RADIUS — normalmente o Microsoft NPS ou um serviço de RADIUS em nuvem — recebe a solicitação 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, você revoga seu certificado na CA. O dispositivo dele perde o acesso ao WiFi no próximo ciclo de autenticação. Sem necessidade de redefinição de senha. Sem esperar por uma rotação trimestral. [medium pause] Agora, as pessoas costumam perguntar sobre a diferença entre SCEP e PKCS — Public Key Cryptography Standards. Ambos funcionam com o Intune. A principal diferença está em onde a chave privada é gerada. Com o SCEP, ela é 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 trafega pela rede, o que introduz um risco teórico de interceptação. O PKCS tem seu espaço — é mais adequado para criptografia de e-mail S/MIME, onde a custódia de chaves é importante. Para autenticação WiFi, o SCEP é a escolha certa. Sempre. [short pause] Deixe-me apresentar um segundo cenário — uma rede de varejo. Imagine uma varejista de moda com 200 lojas em todo o Reino Unido, cada uma operando com pontos de acesso Cisco Meraki. Seus sistemas de ponto de venda são baseados em Windows, gerenciados por meio do Intune. Eles precisam de conformidade com o PCI DSS, o que significa segmentação de rede e autenticação forte para qualquer dispositivo que manipule dados de portadores de cartão. O EAP-TLS baseado em SCEP oferece autenticação em nível de dispositivo no SSID da equipe, com atribuição de VLAN orientada pela política do RADIUS. Os terminais de PDV entram na VLAN do escopo PCI automaticamente. O WiFi para convidados — gerenciado separadamente por meio de uma plataforma como a Purple — funciona em um SSID completamente isolado com seu próprio fluxo de autenticação. As duas redes nunca se tocam. Os auditores ficam satisfeitos. A equipe de segurança dorme melhor. [medium pause] Certo, vamos falar sobre as armadilhas, porque existem algumas que costumam pegar as equipes de surpresa. [short pause] O modo de falha mais comum são as incompatibilidades de direcionamento de grupo no Intune. Seu perfil de Raiz Confiável, seu perfil SCEP e seu perfil de WiFi devem todos ter como alvo o mesmo grupo do Azure AD. Se o perfil SCEP for direcionado a um grupo de Usuários e o perfil de WiFi for direcionado a um grupo de Dispositivos, o Intune não conseguirá resolver a dependência e o perfil de WiFi será exibido com erro. Verifique suas atribuições primeiro - quase sempre o problema está aí. [short pause] Segundo ponto crítico: disponibilidade do servidor NDES. Seu servidor NDES precisa estar acessível pela internet para que os dispositivos remotos se registrem antes de chegarem ao local físico. A maneira segura de fazer isso é por meio do Azure AD Application Proxy, que oferece acesso remoto sem abrir portas de entrada no firewall. Não exponha o NDES diretamente à internet. [short pause] Terceiro: disponibilidade da CRL. Seu servidor RADIUS verifica a Lista de Revogação de Certificados toda vez que um dispositivo se autentica. Se o Ponto de Distribuição da CRL estiver inacessível - talvez um servidor esteja fora do ar ou uma regra de firewall tenha mudado - a autenticação falhará para todos. Torne seus endpoints de CRL altamente disponíveis e teste-os regularmente. [short pause] Quarto: permissões de 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 receberão erros HTTP 403 quando tentarem coletar seu certificado. É uma correção simples de permissões, mas fácil de passar despercebida durante a configuração inicial. [medium pause] Agora, uma rodada de perguntas rápidas. [short pause] O SCEP funciona com MDMs que não são da Microsoft? Sim - o Jamf para frotas de dispositivos Apple, o VMware Workspace ONE e a maioria das plataformas de MDM corporativas oferecem suporte a perfis SCEP. O protocolo é neutro em relação ao fornecedor. [short pause] O SCEP funciona com PKI em nuvem? Sim. A própria PKI em nuvem da Microsoft no Intune Suite elimina totalmente a necessidade de um servidor NDES local. Provedores de PKI em nuvem de terceiros, como SecureW2 e Keyfactor, também oferecem endpoints SCEP em nuvem. [short pause] E quanto ao WPA3-Enterprise? O WPA3-Enterprise usa a mesma pilha de autenticação 802.1X e EAP-TLS. Os certificados emitidos por SCEP funcionam de maneira idêntica. A atualização ocorre na camada do protocolo sem fio, não na camada do certificado. [short pause] Qual é a validade dos certificados? Normalmente um ano, embora você possa configurar períodos de validade mais curtos. O Intune gerencia a renovação automática antes do vencimento, para que os usuários nunca sofram interrupções. [medium pause] Para resumir. O SCEP automatiza a distribuição de certificados em escala, eliminando o trabalho manual de implantação de PKI em grandes frotas de dispositivos. A chave privada permanece no dispositivo - essa é a base de segurança do EAP-TLS. Implante em sequência: primeiro a Raiz Confiável, segundo o perfil SCEP, terceiro o perfil de WiFi, todos direcionados ao mesmo grupo. Publique seu endpoint NDES de forma segura via Application Proxy. Mantenha seus endpoints de CRL altamente disponíveis. E se estiver começando do zero, avalie a PKI em nuvem para remover completamente a dependência do NDES local. [short pause] Para o WiFi de visitantes - a rede separada voltada para o público - a autenticação baseada em certificado não é o modelo correto. Os visitantes não possuem dispositivos gerenciados. É aí que uma plataforma como a Purple lida com o fluxo de autenticação: Captive Portal, login social, captura de e-mail ou verificação por SMS, tudo alimentando uma camada de dados primários (first-party data) que sua equipe de marketing pode realmente usar. As duas abordagens se complementam: SCEP para o parque de dispositivos gerenciados dos seus funcionários, Purple para a sua rede de visitantes. Ambos rodando no mesmo hardware, segmentados de forma limpa por VLAN. [short pause] Esse é o seu briefing sobre integração de WiFi corporativo 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 site da Purple. Obrigado por ouvir.

Parte da nossa série principal: Enterprise WiFi Security Guide

O Guia Corporativo para SCEP: Implantando o Simple Certificate Enrollment Protocol para Segurança Automatizada de WiFi em Ca…

Executive Summary

For enterprise venues, whether a busy hospitality environment, a multi-site retail operation, or a modern corporate campus, relying on pre-shared keys or basic Captive Portals for staff WiFi is a security vulnerability and an operational bottleneck. Modern network architectures require 802.1X authentication using EAP-TLS, which ensures every device is cryptographically verified before gaining network access.

The challenge lies in distribution: how do you deploy unique client certificates to thousands of Windows, iOS, and Android devices without burying your helpdesk under support tickets? Microsoft Intune and other MDM platforms solve this through automated certificate lifecycle management. By deploying Simple Certificate Enrolment Protocol (SCEP) profiles, IT teams silently push trusted root and client certificates to managed endpoints.

This guide provides a definitive architectural blueprint and step-by-step implementation strategy for deploying enterprise WiFi certificates. We will explore the critical differences between SCEP and PKCS, detail the correct deployment sequence required for success, and outline real-world risk mitigation strategies to ensure your Guest WiFi and corporate networks remain secure and operational.

Listen to the Briefing

Technical Deep-Dive: SCEP Architecture

When designing your enterprise WiFi certificate deployment strategy, the first architectural decision is selecting the certificate delivery mechanism. Mobile Device Management (MDM) platforms support both SCEP and PKCS, but they operate fundamentally differently.

Simple Certificate Enrolment Protocol (SCEP)

SCEP is the industry standard for enterprise device enrolment. In a SCEP workflow, the management service instructs the endpoint to generate its own private and public key pair. The device generates a Certificate Signing Request (CSR) and submits it to your Certificate Authority (CA) via a Network Device Enrollment Service (NDES) server. The CA signs the request and returns the public certificate to the device.

The most critical security benefit of SCEP is that the private key never leaves the device. It is generated locally, stored in the device's secure enclave (such as TPM for Windows or Secure Enclave for iOS), and is never transmitted over the network. For this reason, SCEP is highly recommended for 802.1X authentication.

O Guia Corporativo para SCEP: Implantando o Simple Certificate Enrollment Protocol para Segurança Automatizada de WiFi em Ca…

Public Key Cryptography Standards (PKCS)

Conversely, with PKCS, the Certificate Authority generates both the public and private keys centrally. A certificate connector securely exports this key pair and pushes it to the target device.

Whilst PKCS reduces infrastructure complexity by eliminating the need to deploy and maintain an NDES server, it introduces a theoretical security risk because the private key is transmitted over the network. Rather than network authentication, PKCS is typically better suited for use cases where key escrow is required, such as S/MIME email encryption.

O Guia Corporativo para SCEP: Implantando o Simple Certificate Enrollment Protocol para Segurança Automatizada de WiFi em Ca…

Tem dúvidas sobre a sua configuração específica?

A nossa equipa trabalha com operadores de espaços, gestores de TI e engenheiros de rede em 80.000 locais. Agende uma chamada de 20 minutos e mostraremos como outros profissionais na sua situação o resolveram.

Implementation Guide: Deployment Sequence

Successfully configuring a managed WiFi profile for 802.1X requires strict adherence to a specific deployment sequence. Due to profile dependency rules, trust must be established before authentication can be configured.

Step 1: Deploying the Trusted Root Certificate Profile

Before any device can request a client certificate or trust your RADIUS server, it must trust the issuing Certificate Authority.

  1. Export your Root CA certificate and any Intermediate CA certificates as .cer files.
  2. Create a new configuration profile in your MDM console.
  3. Select the target platform and choose the Trusted Certificate profile type.
  4. Upload the .cer file and deploy this profile to your target device groups.

Step 2: Configuring the SCEP Certificate Profile

Once trust is established, configure the SCEP profile to define how devices retrieve their client certificates.

  1. Create a new configuration profile and select SCEP Certificate.
  2. Configure the Subject Name Format. For user-driven authentication, CN={{UserPrincipalName}} is standard. For device authentication, use CN={{AAD_Device_ID}}.
  3. Set the Key Usage to Digital Signature and Key Encipherment.
  4. Under Extended Key Usage, specify Client Authentication (OID: 1.3.6.1.5.5.7.3.2).
  5. Link this profile to the Trusted Root Certificate profile created in Step 1.
  6. Provide the external URL of your SCEP gateway or NDES server.

Step 3: Deploying the 802.1X WiFi Profile

The final step is to push the WiFi configuration that associates the certificates with the network SSID.

  1. Create a WiFi configuration profile.
  2. Enter the network name exactly as it is broadcast by your wireless access points.
  3. Select WPA2-Enterprise or WPA3-Enterprise as the security type.
  4. Set the EAP type to EAP-TLS.
  5. In the authentication settings, 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 and Industry Standards

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

SCEP Gateway Placement and Security

To allow remote devices to provision certificates before arriving on-site, the SCEP gateway must be accessible from the internet. Exposing an internal server directly to the internet is a major 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 enforce Conditional Access policies on the enrolment flow.

RADIUS and CRL Checking

Certificate deployment is only half of the security equation; revocation is equally critical. If an employee leaves the organisation, disabling their directory account may not immediately revoke their WiFi access if their client certificate remains valid and the RADIUS server does not strictly check 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 widespread outages.

For a more detailed consideration of modern connectivity, review our Bandwidth Management: A Practical Guide for 2026 guide.

Troubleshooting and Risk Mitigation

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

Failure to Apply WiFi Profile

The device receives the Trusted Root and SCEP certificates, but the WiFi profile shows as failed or not applicable in the MDM console. This is almost always caused by a group targeting mismatch. 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 groups.

Gateway 403 Forbidden Error

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

ROI and Business Impact

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

  1. Reduction in Helpdesk Tickets: Password-based WiFi generates a high volume of support tickets due to expired passwords, lockouts, and typos. Certificate-based authentication is invisible to the user, typically reducing WiFi-related helpdesk workloads 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, especially in Retail and Healthcare environments.
  3. Streamlined Onboarding: Integrating certificate deployment with existing MDM workflows ensures a unified, zero-touch provisioning experience from day one.

Whilst 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, providing you with 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 que os dispositivos solicitem certificados digitais de uma Autoridade Certificadora, onde a chave privada é gerada e armazenada com segurança no próprio dispositivo.

O método recomendado para implantar certificados de autenticação WiFi devido à sua alta segurança e escalabilidade em frotas corporativas.

PKCS (Public Key Cryptography Standards)

Um conjunto de padrões onde as chaves pública e privada são geradas pela Autoridade Certificadora e, em seguida, entregues com segurança ao endpoint.

Frequentemente usado para criptografia 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 implantaçã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 quanto o cliente apresentem certificados digitais válidos.

O protocolo de autenticação de destino que os perfis de certificado e WiFi de MDM são projetados para habilitar, eliminando o acesso baseado em senha.

CRL (Certificate Revocation List)

Uma lista publicada pela Autoridade Certificadora contendo os números de série dos certificados que foram revogados antes da 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 acessar a rede usando um certificado anteriormente válido.

CSR (Certificate Signing Request)

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

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

802.1X

Um padrão IEEE para controle de acesso à rede baseado em porta que fornece um mecanismo de autenticação para dispositivos que desejam se conectar a uma LAN ou WLAN.

A estrutura fundamental que impõe a exigência 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 gerenciamento centralizado de autenticação, autorização e contabilização para usuários que se conectam e utilizam um serviço de rede.

O servidor que avalia o certificado do 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 proteger a rede de seus funcionários em um ecossistema misto de laptops Windows para a recepção, dispositivos iOS para a governança e tablets Android para o ponto de venda dos restaurantes. Atualmente, eles usam WPA2-Personal com uma senha compartilhada rotacionada trimestralmente, gerando um volume massivo de chamados no suporte.

O grupo hoteleiro implanta três perfis do Intune em sequência para um grupo unificado de dispositivos. Primeiro, um perfil de Certificado 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 o desligamento de um funcionário.

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

Uma varejista de moda com 200 lojas exige conformidade com o PCI DSS para seus sistemas de ponto de venda baseados em Windows gerenciados pelo Intune. Eles devem garantir uma autenticação forte e uma segmentação de rede rigorosa para qualquer dispositivo que manipule dados de portadores de cartão.

A varejista implementa EAP-TLS baseado em SCEP para autenticação em nível de dispositivo no SSID da equipe. A política RADIUS direciona a atribuição de VLAN, colocando os terminais de PDV autenticados em uma VLAN estritamente isolada e no escopo do PCI de forma automática. O WiFi de convidados é gerenciado em um SSID completamente separado com seu próprio fluxo de autenticação por Captive Portal, garantindo que as duas redes nunca se cruzem.

Comentário do examinador: Ao vincular a segmentação de rede diretamente à autenticação baseada em certificado, a varejista atende aos requisitos do PCI DSS sem a necessidade de configuração manual de rede por loja. A separação física da rede de convidados usando uma plataforma como a Purple evita a expansão do escopo para a auditoria PCI.

Questões práticas

Q1. Sua implantação do Intune mostra os perfis de Raiz Confiável e SCEP aplicados com sucesso ao laptop de um usuário, mas o perfil de WiFi mostra um estado de 'Erro'. O usuário não consegue se conectar ao SSID corporativo. Qual é a causa arquitetônica mais provável?

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

Ver resposta modelo

Uma incompatibilidade de direcionamento de grupo. O perfil SCEP provavelmente está atribuído a um grupo de Usuários, 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 grupo, fazendo com que a implantação do perfil de WiFi falhe. Audite as atribuições e garanta que todos os três perfis tenham como alvo exatamente o mesmo grupo do Azure AD.

Q2. Uma subsidiária recém-adquirida exige autenticação 802.1X para os dispositivos de seus funcionários. A equipe de segurança deles exige que as chaves privadas nunca trafeguem pela rede e sejam geradas dentro do TPM de hardware do endpoint. Qual método de implantação de certificado você deve usar?

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

Ver resposta modelo

Você deve usar SCEP (Simple Certificate Enrollment Protocol). Em um fluxo de trabalho SCEP, o dispositivo gera seu próprio par de chaves privada e pública localmente dentro de seu enclave seguro (TPM) e envia apenas uma Solicitação de Assinatura de Certificado (CSR) pela rede. O PKCS gera a chave privada centralmente na CA e a transmite pela rede, o que viola a exigência da equipe de segurança.

Q3. Um funcionário é demitido e sua conta do Active Directory é desativada. No entanto, seu laptop permanece conectado à rede WiFi corporativa por várias horas antes de perder o acesso. Como você resolve essa lacuna de segurança?

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

Ver resposta modelo

Você deve configurar o servidor RADIUS para impor uma verificação estrita da Lista de Revogação de Certificados (CRL). Quando um funcionário é demitido, seu certificado deve ser explicitamente revogado na Autoridade Certificadora. O servidor RADIUS verificará a CRL durante o próximo ciclo de autenticação e negará o acesso imediatamente, independentemente do status da conta no Active Directory.

Continue a ler esta série

Como Segmentar Redes WiFi de Funcionários e Convidados com Segurança: Melhores Práticas para LANs Corporativas

Este guia fornece aos gerentes de TI e arquitetos de rede um modelo técnico e neutro em relação a fornecedores para proteger LANs corporativas por meio da segmentação adequada do tráfego WiFi de funcionários e convidados. O conteúdo aborda autenticação 802.1X, RADIUS em nuvem, isolamento de VLAN e o gerenciamento do ciclo de vida de credenciais necessário para eliminar senhas compartilhadas e proteger os ativos corporativos.

Ler o guia →

Best DNS filtering: a comprehensive guide for businesses

Este guia de referência técnica explica como o DNS filtering empresarial protege redes públicas bloqueando domínios maliciosos na camada de resolução - antes mesmo que uma conexão seja estabelecida. Ele fornece a diretores de TI, arquitetos de rede e equipes de operações de locais a arquitetura de implantação, configuração de firewall e contexto de conformidade que precisam para proteger o Guest WiFi em ambientes de hospitalidade, varejo e setor público. O Purple Shield bloqueia malware, botnets e conteúdo inadequado no nível de DNS em mais de 80.000 locais ativos.

Ler o guia →

Entendendo o Cisco SUDI: Identidade Ancorada em Hardware no Controle de Acesso a Redes Seguras

Este guia explica como o Cisco SUDI fornece uma identidade criptograficamente segura e ancorada em hardware para a infraestrutura de rede corporativa. Saiba como substituir endereços MAC clonáveis por certificados 802.1AR imutáveis para proteger o controle de acesso à rede do seu local.

Ler o guia →

Tem dúvidas sobre a sua configuração específica?

A nossa equipa trabalha com operadores de espaços, gestores de TI e engenheiros de rede em 80.000 locais. Agende uma chamada de 20 minutos e mostraremos como outros profissionais na sua situação o resolveram.