Passer au contenu principal

Automatisation de la sécurité WiFi d'entreprise : le guide de déploiement des certificats SCEP

Ce guide technique explique comment automatiser la sécurité WiFi d'entreprise en utilisant le déploiement de certificats SCEP. Il fournit un plan architectural détaillé et les étapes de mise en œuvre pour déployer l'authentification 802.1X EAP-TLS sur les réseaux d'entreprise et invités.

📖 5 min de lecture📝 1,248 mots🔧 2 exemples concrets3 questions d'entraînement📚 8 définitions clés

Écouter ce guide

Voir la transcription du podcast
Bienvenue dans ce briefing technique. Je suis ravi de vous présenter notre dernier guide : Automatiser la sécurité WiFi d'entreprise, en se concentrant spécifiquement sur le déploiement de certificats SCEP. Si vous gérez des réseaux pour des hôtels, des chaînes de vente au détail ou des lieux publics, vous savez déjà que s'appuyer sur des clés pré-partagées ou de simples Captive Portals pour l'accès du personnel est une vulnérabilité de sécurité massive. Aujourd'hui, nous parlons de la référence absolue : l'authentification 802.1X utilisant EAP-TLS. Plongeons dans l'architecture. Le défi principal avec l'EAP-TLS n'est pas le protocole lui-même ; c'est la logistique d'obtention de certificats clients uniques sur des milliers d'appareils - qu'il s'agisse d'ordinateurs portables Windows, d'iPads ou de tablettes de point de vente. C'est là que les plateformes de gestion des terminaux mobiles (MDM), comme Microsoft Intune ou Jamf, entrent en jeu. Mais comment distribuer ces certificats en toute sécurité ? Vous avez généralement deux options : PKCS ou SCEP. Laissez-moi être absolument clair sur ce point : pour l'authentification WiFi, vous voulez SCEP. C'est le Simple Certificate Enrolment Protocol. Voici pourquoi c'est important. Avec SCEP, le MDM demande à l'appareil de générer sa propre clé privée localement. Cette clé reste verrouillée dans le matériel sécurisé de l'appareil. Elle ne transite jamais sur le réseau. L'appareil envoie simplement une demande de signature de certificat à votre autorité de certification via une passerelle, généralement un serveur NDES. Comparez cela avec PKCS, où l'autorité de certification génère la clé privée de manière centralisée et la pousse sur le réseau vers l'appareil. Bien que le PKCS ait sa place - par exemple pour le chiffrement des e-mails où vous avez besoin d'un séquestre de clés - transmettre des clés privées sur le réseau est un risque que vous n'avez tout simplement pas besoin de prendre pour l'authentification réseau. Gardez les clés sur l'appareil. Utilisez SCEP. Parlons maintenant de la mise en œuvre. Si vous devez retenir une seule chose de ce briefing, c'est cette règle d'or : la confiance avant l'authentification. Vous ne pouvez pas simplement pousser un profil WiFi et espérer que cela fonctionne. Il y a une séquence de déploiement stricte en trois étapes que vous devez suivre. Étape 1 : Déployer le certificat racine de confiance. Avant qu'un appareil ne puisse demander un certificat client ou faire confiance à votre serveur RADIUS, il doit faire confiance à l'autorité de certification émettrice. Poussez ce profil en premier. Étape 2 : Configurer et pousser le profil de certificat SCEP. Cela indique à l'appareil comment communiquer avec la passerelle SCEP, quel format utiliser pour son nom de sujet, et à quoi sert réellement le certificat - dans ce cas, l'authentification client. Vous devez lier ce profil à la racine de confiance déployée à l'étape 1. Étape 3 : Déployer le profil WiFi 802.1X. C'est ici que vous assemblez le tout. Vous spécifiez l'SSID, sélectionnez WPA3-Enterprise, définissez le type d'EAP sur EAP-TLS, et le pointez vers le certificat SCEP pour l'authentification client. Voici un piège majeur que nous voyons tout le temps. Un client nous appelle et dit : "Les certificats sont sur l'appareil, mais le profil WiFi affiche une erreur dans Intune." Presque à chaque fois, il s'agit d'une incompatibilité de ciblage de groupe. Si vous attribuez le profil SCEP à un groupe "Utilisateurs", mais attribuez le profil WiFi à un groupe "Appareils", l'MDM ne peut pas résoudre la dépendance. Faites correspondre exactement vos cibles sur les trois profils. Regardons un scénario du monde réel. Imaginez un hôtel de 200 chambres. Ils disposent de 150 appareils iOS managés pour le personnel de ménage. Actuellement, ils utilisent un réseau avec mot de passe standard, et le personnel ne cesse de partager ce mot de passe avec les clients. C'est un cauchemar. En migrant vers le WPA2-Enterprise avec EAP-TLS via SCEP, le Directeur IT élimine complètement le mot de passe. Les appareils iOS s'authentifient silencieusement en arrière-plan à l'aide de leurs certificats. Mais que se passe-t-il si un employé perd un appareil ou quitte l'entreprise ? Désactiver son compte Active Directory ne suffit pas, car le certificat sur cet appareil est toujours cryptographiquement valide. Cela nous amène à un contrôle de sécurité critique : la vérification stricte de la CRL. Vous devez configurer votre serveur RADIUS pour vérifier la liste de révocation des certificats (CRL). Si un appareil disparaît, vous révoquez le certificat au niveau de la CA. Le serveur RADIUS constate la révocation sur la CRL et bloque immédiatement l'accès au réseau. Sans une vérification stricte de la CRL, votre posture de sécurité est incomplète. Pour conclure, la transition vers le déploiement automatisé de certificats SCEP offre un retour sur investissement massif. Vous constaterez une réduction de 70 à 80 % des tickets de support liés au WiFi car les utilisateurs ne se retrouvent plus bloqués et ne saisissent plus de mots de passe incorrects. Plus important encore, vous éliminez le risque de vol d'identifiants, garantissant ainsi votre conformité avec les cadres réglementaires tels que PCI DSS et GDPR. Automatiser la sécurité WiFi d'entreprise ne consiste pas seulement à verrouiller les accès ; il s'agit de faire de la voie sécurisée la voie la plus simple pour vos utilisateurs. Merci de votre écoute, et n'hésitez pas à consulter le guide écrit complet pour obtenir tous les détails de configuration étape par étape.

header_image.png

Résumé exécutif

Pour les entreprises de l'hôtellerie, du commerce de détail et du secteur public, s'appuyer sur des clés pré-partagées ou un simple Captive Portal pour l'accès au réseau introduit de graves vulnérabilités de sécurité. L'architecture réseau moderne exige une authentification 802.1X via EAP-TLS, garantissant que chaque appareil est vérifié par cryptographie avant d'accéder au réseau. Pour les responsables informatiques et les architectes réseau, le défi consiste à déployer efficacement des certificats clients uniques sur des milliers d'appareils Windows, iOS et Android.

Ce guide fournit le schéma d'architecture définitif et la stratégie de mise en œuvre étape par étape pour le déploiement automatisé de certificats WiFi à l'aide du protocole SCEP (Simple Certificate Enrolment Protocol). En intégrant votre plateforme de gestion des appareils mobiles (MDM) à une passerelle SCEP et à une autorité de certification (CA), vous pouvez pousser de manière transparente des certificats racines et clients approuvés vers les terminaux gérés. Nous explorons les différences critiques entre SCEP et PKCS, détaillons la séquence précise des étapes requises pour un déploiement réussi, et présentons des stratégies pratiques de l'atténuation des risques pour maintenir votre réseau WiFi sécurisé et performant.

Écoutez le briefing podcast d'accompagnement :

Analyse technique approfondie : Architecture SCEP et EAP-TLS

Lors de la conception d'une stratégie de déploiement de certificats WiFi d'entreprise, la décision architecturale fondamentale concerne la méthode de livraison sécurisée des certificats. La norme de l'industrie pour ce processus est SCEP. SCEP automatise le processus d'enrôlement de certificats, permettant aux appareils de demander des certificats en toute sécurité à une autorité de certification via un protocole standardisé.

Les avantages de SCEP par rapport à PKCS

Bien que des plateformes telles que Microsoft Intune prennent en charge à la fois SCEP et PKCS, leurs mécanismes de fonctionnement sont fondamentalement différents. Dans le flux de travail SCEP, le service MDM demande au terminal de générer sa propre paire de clés privée et publique. L'appareil crée ensuite une demande de signature de certificat (CSR) et l'envoie à votre autorité de certification via un serveur NDES (Network Device Enrolment Service). L'autorité de certification signe la demande et renvoie le certificat de clé publique à l'appareil.

L'avantage clé de SCEP en matière de sécurité réside dans le fait que la clé privée ne quitte jamais l'appareil. Elle est générée localement et stockée dans l'enclave sécurisée de l'appareil. Cela fait de SCEP la méthode fortement recommandée pour l'authentification 802.1X. En revanche, avec PKCS, l'autorité de certification génère les deux clés de manière centralisée et les transmet via le réseau. PKCS est plus adapté aux cas d'usage nécessitant le dépôt de clés (comme le chiffrement des e-mails S/MIME) plutôt qu'à l'authentification réseau.

scep_vs_pkcs_comparison.png

Authentification 802.1X et EAP-TLS

La norme IEEE 802.1X fournit le cadre pour la gestion centralisée des accès réseau. Elle définit la manière dont les paquets EAP (Extensible Authentication Protocol) sont transportés sur le LAN (EAPoL) afin de permettre l'authentification entre le client, le point d'accès et le serveur d'authentification - généralement un serveur RADIUS.

EAP-TLS est le protocole d'authentification le plus sécurisé pour les réseaux 802.1X. Il nécessite une authentification mutuelle : le client valide le certificat du serveur RADIUS, et le serveur RADIUS valide le certificat du client. Ce processus de validation rigoureux garantit que seuls les utilisateurs authentifiés et autorisés sur des appareils enregistrés accèdent au réseau, protégeant ainsi ce dernier contre des menaces telles que les attaques de type Evil Twin.

Guide de mise en œuvre : La séquence de déploiement

La configuration réussie du déploiement automatisé de certificats pour le 802.1X nécessite le respect strict d'une séquence spécifique. Les dépendances de profil imposent que la confiance soit établie avant que l'authentification ne soit configurée. Cela s'applique que vous utilisiez Microsoft Intune, Jamf ou une autre plateforme MDM.

Étape 1 : Déployer le certificat racine de confiance

Avant qu'un appareil ne puisse demander un certificat client ou faire confiance à votre serveur RADIUS, il doit faire confiance à l'autorité de certification qui émet les certificats.

  1. Exportez votre certificat de CA racine et tous les certificats de CA intermédiaires.
  2. Dans votre plateforme MDM, créez un profil de certificat de confiance.
  3. Téléversez les fichiers de certificat et déployez ce profil sur vos groupes d'appareils cibles.

Étape 2 : Configurer le profil de certificat SCEP

Une fois la confiance établie, configurez le profil SCEP pour indiquer aux appareils comment obtenir leurs certificats clients.

  1. Créez un nouveau profil de configuration de certificat SCEP.
  2. Configurez le format du nom de l'objet. Pour l'authentification basée sur l'utilisateur, utilisez le nom principal de l'utilisateur (UPN). Pour l'authentification de l'appareil, utilisez l'identifiant de l'appareil.
  3. Définissez l'utilisation de la clé sur la signature numérique et le chiffrement de la clé.
  4. Spécifiez l'authentification du client pour l'utilisation étendue de la clé.
  5. Liez ce profil au profil de certificat racine de confiance créé à l'Étape 1.
  6. Indiquez l'URL externe de votre passerelle SCEP ou de votre serveur NDES.

Étape 3 : Déployer le profil WiFi 802.1X

La dernière étape consiste à pousser la configuration WiFi qui associe le certificat au SSID du réseau.

  1. Créez un profil de configuration WiFi.
  2. Saisissez l'SSID exactement tel qu'il est diffusé par vos points d'accès.
  3. Sélectionnez WPA2-Enterprise ou WPA3-Enterprise comme type de sécurité.
  4. Définissez le type EAP sur EAP-TLS.
  5. Sélectionnez le profil de certificat SCEP créé à l'étape 2 pour l'authentification client.
  6. Spécifiez le certificat racine de confiance pour la validation du serveur, afin de garantir que les appareils se connectent uniquement à votre serveur RADIUS légitime.

scep_architecture_overview.png

Bonnes pratiques pour les environnements d'entreprise

Lors de la mise en œuvre du déploiement de certificats SCEP, suivez ces bonnes pratiques indépendantes des fournisseurs pour garantir la conformité et la fiabilité.

Sécuriser la passerelle SCEP

La passerelle SCEP ou le serveur NDES doit être accessible depuis Internet afin que les appareils distants puissent provisionner les certificats avant leur arrivée sur site. Cependant, l'exposition directe d'un serveur interne à Internet présente un risque de sécurité important. Publiez l'URL à l'aide d'un proxy d'application. Cela fournit un accès distant sécurisé sans ouvrir de ports de pare-feu entrants et vous permet d'appliquer des politiques d'accès conditionnel au flux d'enrôlement.

Imposer une vérification stricte de la CRL

Le déploiement de certificats ne représente que la moitié de l'équation de sécurité ; la révocation est tout aussi essentielle. Si un employé s'en va, la désactivation de son compte d'annuaire peut ne pas révoquer immédiatement son accès WiFi si son certificat client reste valide. Configurez votre serveur RADIUS pour imposer une vérification stricte de la liste de révocation de certificats (CRL). Assurez-vous que vos points de distribution CRL sont hautement disponibles ; si le serveur RADIUS ne peut pas accéder à la CRL, l'authentification échouera, entraînant une interruption généralisée du service.

Intégration du matériel

Assurez-vous que votre infrastructure réseau prend en charge les protocoles requis. Purple s'intègre parfaitement au matériel Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks et Fortinet. Configurez ces systèmes pour transférer les demandes d'authentification vers votre infrastructure RADIUS centralisée.

Dépannage et atténuation des risques

Même avec une planification minutieuse, les déploiements de certificats peuvent rencontrer des problèmes. Vous trouverez ci-dessous les modes de défaillance courants et les stratégies d'atténuation.

Échecs de dépendance

Un problème courant est qu'un appareil reçoit la racine de confiance et les certificats SCEP, mais que le profil WiFi ne s'applique pas. Cela est presque toujours causé par un ciblage de groupe incorrect au sein du MDM. Si le profil SCEP est attribué à un groupe d'utilisateurs alors que le profil WiFi est attribué à un groupe d'appareils, le MDM ne peut pas résoudre la dépendance. Auditez vos attributions et assurez-vous que tous les profils associés sont déployés sur les mêmes groupes d'annuaire.

Erreurs d'enrôlement

Si les appareils ne parviennent pas à récupérer les certificats SCEP et que les journaux de la passerelle affichent des erreurs HTTP 403, le compte de service manque peut-être des autorisations nécessaires sur le modèle de certificat, ou le filtrage d'URL sur le pare-feu bloque peut-être les paramètres de chaîne de requête spécifiques utilisés par SCEP. Vérifiez que le compte du connecteur dispose des autorisations de lecture et d'inscription sur le modèle d'autorité de certification (CA), et vérifiez les journaux du pare-feu pour vous assurer que l'URL SCEP n'est pas bloquée.

ROI et impact commercial

La transition vers un déploiement automatisé de certificats 802.1X offre des rendements mesurables tant sur le plan de la sécurité que des opérations.

Le WiFi basé sur mot de passe génère un volume important de tickets d'assistance en raison de l'expiration des mots de passe, des verrouillages et des erreurs de saisie. L'authentification basée sur certificat est invisible pour l'utilisateur et réduit généralement le volume de tickets d'assistance liés au WiFi de 70% à 80%.

De plus, EAP-TLS élimine le risque de vol d'identifiants et d'attaques de type man-in-the-middle. Cela est essentiel pour la conformité avec des cadres tels que PCI-DSS et GDPR. Pour les opérations de vente au détail multi-sites ou les grandes chaînes hôtelières, l'automatisation de ce processus garantit une expérience de provisionnement cohérente et sans contact dès le premier jour, sécurisant le périmètre du réseau tout en réduisant considérablement les coûts opérationnels.

Définitions clés

SCEP

Simple Certificate Enrolment Protocol. Un protocole qui automatise le processus de demande et d'installation de certificats numériques sur les appareils, où la clé privée est générée localement.

La méthode recommandée pour déployer des certificats d'authentification WiFi à grande échelle via des plateformes MDM.

PKCS

Public Key Cryptography Standards. Une méthode de déploiement dans laquelle l'Autorité de Certification génère à la fois les clés publiques et privées et les transmet au point de terminaison.

Souvent utilisé pour le chiffrement des e-mails S/MIME mais moins idéal pour le WiFi en raison de la transmission de la clé privée sur le réseau.

802.1X

Une norme IEEE pour le contrôle d'accès réseau basé sur les ports qui fournit un mécanisme d'authentification aux appareils souhaitant se connecter à un LAN ou un WLAN.

La base obligatoire pour la sécurité WiFi d'entreprise, remplaçant les clés pré-partagées vulnérables.

EAP-TLS

Extensible Authentication Protocol - Transport Layer Security. Un protocole d'authentification qui exige que le client et le serveur présentent tous deux des certificats numériques valides.

Considéré comme la méthode d'authentification la plus sécurisée pour les réseaux 802.1X, éliminant les vulnérabilités liées aux mots de passe.

NDES

Network Device Enrolment Service. Un rôle de serveur qui agit comme une passerelle, permettant aux appareils sans identifiants de domaine d'obtenir des certificats via SCEP.

Un composant d'infrastructure requis lors de l'implémentation du déploiement de certificats SCEP avec Microsoft Intune.

RADIUS

Remote Authentication Dial-In User Service. Un protocole réseau qui fournit une gestion centralisée de l'authentification, de l'autorisation et de la traçabilité.

Le serveur qui valide les certificats clients par rapport à l'annuaire et autorise l'accès au réseau.

CRL

Certificate Revocation List. Une liste publiée par l'Autorité de Certification contenant les numéros de série des certificats qui ont été révoqués.

Les serveurs RADIUS doivent vérifier la CRL pour s'assurer qu'un certificat présenté est toujours valide et n'a pas été compromis.

CSR

Certificate Signing Request. Un bloc de texte encodé transmis à une Autorité de Certification lors de la demande d'un certificat SSL/TLS.

Généré par l'appareil lors du processus d'enrôlement SCEP pour demander un certificat signé.

Exemples concrets

Un hôtel de 200 chambres doit déployer un WiFi personnel sécurisé pour 150 appareils iOS gérés utilisés par le personnel d'entretien et de maintenance. Ils utilisent actuellement un réseau WPA2-PSK, mais le personnel continue de partager le mot de passe avec les clients. Comment le directeur informatique doit-il mettre en œuvre une solution sécurisée et automatisée ?

Le directeur informatique doit migrer le WiFi personnel vers WPA2-Enterprise en utilisant l'authentification 802.1X EAP-TLS. Il doit configurer son MDM (par exemple, Jamf) pour pousser une charge utile SCEP vers les appareils iOS. La séquence de déploiement est la suivante : 1) Pousser le certificat de l'Autorité de Certification (CA) racine afin que les appareils fassent confiance au réseau. 2) Pousser le profil SCEP, demandant aux appareils de réclamer un certificat client à la CA via la passerelle SCEP. 3) Pousser le profil WiFi configuré pour WPA2-Enterprise et EAP-TLS, en le liant au certificat SCEP. Les points d'accès réseau (par exemple, HPE Aruba) sont configurés pour authentifier les clients auprès d'un serveur RADIUS central. Lorsque le personnel arrive, ses appareils s'authentifient automatiquement à l'aide du certificat, sans qu'aucun mot de passe ne soit requis.

Commentaire de l'examinateur : Cette approche élimine entièrement la vulnérabilité liée au partage de mot de passe. En utilisant SCEP et EAP-TLS, l'hôtel s'assure que seuls les appareils gérés et autorisés peuvent accéder au WiFi personnel. Les clés privées restent sécurisées sur les appareils iOS, et si un appareil est perdu ou si un membre du personnel s'en va, le certificat peut être révoqué de manière centralisée via la CRL, coupant immédiatement l'accès au réseau.

Une chaîne de vente au détail déploie de nouvelles tablettes de point de vente (POS) dans 50 points de vente. Pour se conformer aux exigences PCI-DSS, les tablettes doivent se connecter à un réseau sans fil sécurisé. L'architecte réseau prévoit d'utiliser Microsoft Intune pour le déploiement. Quels choix architecturaux garantissent la conformité et la sécurité ?

Pour répondre aux exigences PCI-DSS en matière de cryptographie et d'authentification fortes, l'architecte doit déployer 802.1X EAP-TLS. En utilisant Microsoft Intune, il doit sélectionner SCEP plutôt que PKCS pour le déploiement des certificats. Cela garantit que la clé privée est générée sur le TPM de la tablette POS et n'est jamais transmise sur le réseau. Il doit configurer un serveur NDES publié de manière sécurisée via Azure AD Application Proxy. Enfin, il doit configurer le serveur RADIUS pour imposer une vérification stricte de la CRL, garantissant que si une tablette POS est compromise, son certificat peut être révoqué et l'accès au réseau bloqué immédiatement.

Commentaire de l'examinateur : Choisir SCEP plutôt que PKCS est la décision critique ici pour la conformité PCI-DSS, car cela empêche la transmission de la clé privée. La publication du serveur NDES via un proxy d'application sécurise l'infrastructure d'enrôlement. Une vérification stricte de la CRL est obligatoire ; sans elle, un certificat révoqué pourrait encore permettre à un appareil compromis d'accéder au réseau de paiement.

Questions d'entraînement

Q1. Vous déployez un nouveau réseau WiFi 802.1X pour un campus d'entreprise à l'aide de Microsoft Intune. Vous avez configuré le profil de racine approuvée (Trusted Root), le profil SCEP et le profil WiFi. Cependant, lors des tests, les appareils reçoivent les certificats mais le profil WiFi affiche "Erreur" dans la console Intune. Quelle en est la cause la plus probable ?

Conseil : Considérez la manière dont le MDM résout les dépendances entre les profils.

Voir la réponse type

La cause la plus probable est une incohérence dans le ciblage des groupes. Intune exige que les profils dépendants soient attribués exactement au même groupe Azure AD. Si le profil SCEP est attribué à un groupe d'utilisateurs et le profil WiFi à un groupe d'appareils, Intune ne peut pas résoudre la dépendance, ce qui entraîne une erreur.

Q2. Une entreprise de vente au détail souhaite automatiser le déploiement de certificats pour les tablettes des directeurs de magasin. Elle hésite entre l'utilisation de SCEP ou de PKCS. La sécurité est leur préoccupation principale, en particulier la protection des clés privées. Quel protocole doivent-ils choisir et pourquoi ?

Conseil : Pensez à l'endroit où la clé privée est générée dans chaque protocole.

Voir la réponse type

Ils doivent choisir SCEP. Dans un flux de travail SCEP, la clé privée est générée localement sur la tablette et stockée dans son enclave sécurisée ; elle ne quitte jamais l'appareil. Avec PKCS, l'Autorité de Certification génère la clé privée et la transmet à l'appareil via le réseau, ce qui introduit une vulnérabilité de sécurité potentielle.

Q3. Un employé quitte l'entreprise et son compte Active Directory est désactivé. Cependant, l'équipe informatique remarque que l'appareil de l'employé est toujours connecté au réseau WiFi de l'entreprise. Le réseau utilise l'authentification EAP-TLS. Quelle configuration manque-t-il sur le serveur RADIUS ?

Conseil : La désactivation d'un compte n'invalide pas automatiquement un certificat précédemment émis.

Voir la réponse type

Il manque au serveur RADIUS une vérification stricte de la liste de révocation de certificats (CRL). Même si le compte de l'annuaire est désactivé, le certificat client reste cryptographiquement valide jusqu'à ce qu'il expire ou soit explicitement révoqué. Le serveur RADIUS doit être configuré pour vérifier la CRL afin de garantir que l'accès au réseau soit refusé aux certificats révoqués.

Continuer la lecture de cette série

Comment segmenter en toute sécurité les réseaux WiFi des employés et des invités

Ce guide technique de référence fournit aux responsables informatiques des stratégies exploitables pour segmenter en toute sécurité les réseaux WiFi des employés, des invités et de l'IoT à l'aide de VLAN et du protocole 802.1X. Il détaille comment sécuriser l'infrastructure d'entreprise, maintenir la conformité PCI-DSS et exploiter les portails captifs pour capturer des données de première main.

Lire le guide →

Le meilleur filtrage DNS : un guide complet pour les entreprises

Ce guide de référence technique explique comment le filtrage DNS d'entreprise sécurise les réseaux publics en bloquant les domaines malveillants au niveau de la couche de résolution - avant même qu'une connexion ne soit établie. Il fournit aux directeurs informatiques, architectes réseau et équipes d'exploitation des sites l'architecture de déploiement, la configuration du pare-feu et le contexte de conformité nécessaires pour protéger le WiFi invité dans les secteurs de l'hôtellerie, du commerce de détail et du secteur public. Purple Shield bloque les logiciels malveillants, les botnets et les contenus inappropriés au niveau DNS sur plus de 80 000 sites actifs.

Lire le guide →

Comprendre Cisco SUDI : L'identité ancrée dans le matériel pour le contrôle d'accès réseau sécurisé

Ce guide explique comment Cisco SUDI fournit une identité sécurisée par cryptographie et ancrée dans le matériel pour l'infrastructure réseau d'entreprise. Découvrez comment remplacer les adresses MAC falsifiables par des certificats 802.1AR immuables afin de sécuriser le contrôle d'accès réseau de votre site.

Lire le guide →