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.

Publicado Atualizado
📖 6 min de leitura1,217 palavras2 exemplos práticos3 perguntas de prática8 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.

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

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

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 Empresarial do SCEP: Implementar o Simple Certificate Enrollment Protocol para Segurança Automatizada de WiFi em Camp…

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 Empresarial do SCEP: Implementar o Simple Certificate Enrollment Protocol para Segurança Automatizada de WiFi em Camp…

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 espaços. Agende uma chamada de 20 minutos e mostraremos como outros profissionais na sua área 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 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

Como Segmentar Redes WiFi de Colaboradores e de Convidados com Segurança: Melhores Práticas para LANs Empresariais

Este guia fornece aos gestores de TI e arquitetos de rede um modelo técnico e neutro em termos de fornecedor para proteger LANs empresariais através da segmentação correta do tráfego WiFi de colaboradores e convidados. Abrange a autenticação 802.1X, RADIUS na nuvem, isolamento de VLAN e a gestão do ciclo de vida das credenciais necessária para eliminar palavras-passe partilhadas e proteger os ativos corporativos.

Ler o guia →

Melhor filtragem DNS: um guia completo para empresas

Este guia de referência técnica explica como a filtragem DNS empresarial protege as redes públicas bloqueando domínios maliciosos na camada de resolução - antes de uma ligação ser estabelecida. Oferece aos diretores de TI, arquitetos de rede e equipas de operações de locais a arquitetura de implementação, configuração de firewall e contexto de conformidade necessários para proteger o Guest WiFi em ambientes de hotelaria, retalho e setor público. O Purple Shield bloqueia malware, botnets e conteúdos inadequados ao nível do DNS em mais de 80.000 locais ativos.

Ler o guia →

Compreender o Cisco SUDI: Identidade Ancorada em Hardware no Controlo de Acesso Seguro à Rede

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

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 espaços. Agende uma chamada de 20 minutos e mostraremos como outros profissionais na sua área o resolveram.