j'ai fait beaucoup de 802.1x projets ces derniers temps. Et par beaucoup, je veux dire beaucoup. Des solutions telles que le moteur de services d'identité de Cisco, Packetfence et notre ancien serveur de stratégie réseau préféré de Microsoft deviennent rapidement la pierre angulaire de l'accès au réseau filaire plutôt qu'un cas particulier intéressant pour seulement le le plus soucieux de la sécurité.
Pour moi, les plus grands défis n'ont pas été les politiques, les intégrations ou les licences (ne me lancez pas sur les licences). Le plus grand défi du déploiement du 802.1x sur un réseau câblé a été l'incroyable ennui de découverte du réseau et avoir à configurer chaque port de commutation dans la couche d'accès.
Normalement, nous nous connectons à notre ordinateur joint au domaine et nous nous authentifions avec un nom d'utilisateur et un mot de passe auprès d'un annuaire LDAP tel que Microsoft Active Directory. Cela contrôle l'accès aux ressources réseau telles que les partages de fichiers, les applications et les imprimantes réseau. Cependant, l'utilisation de l'authentification et de l'autorisation 802.1x nous permet d'amener la sécurité du réseau à un tout autre niveau.
Une solution 802.1x telle que Cisco ISE peut utiliser la même base de données LDAP principale pour accorder ou refuser l'accès au réseau lui-même. En d'autres termes, le switchport ne transmettra même pas le trafic si un utilisateur final ne parvient pas à s'authentifier. Et plutôt que d'utiliser uniquement un nom d'utilisateur et un mot de passe, une solution d'accès réseau robuste peut examiner plusieurs conditions afin d'accorder l'accès.
Le plus grand défi du déploiement de 802.1x sur un réseau câblé a été l'incroyable ennui de la découverte du réseau et la configuration de chaque port de commutation dans la couche d'accès.
Aujourd'hui, de nombreuses organisations vont encore plus loin et utilisent cette méthode pour attribuer dynamiquement des ACL et des VLAN à un port de commutation particulier en fonction de l'identité de l'utilisateur, de l'identité de l'ordinateur, du type de périphérique, de la santé de l'ordinateur ou d'une combinaison de ces facteurs et d'autres. Ceci est très puissant, car il donne aux administrateurs réseau un contrôle beaucoup plus granulaire sur l'accès au réseau, en particulier lorsqu'il s'agit de BYOD, d'espaces de travail partagés et d'utilisateurs invités.
J'ai travaillé sur un projet ISE pour une organisation mondiale avec plusieurs centaines de milliers d'employés, des districts scolaires avec un millier de membres du personnel et des milliers d'étudiants, et de petites entreprises avec seulement quelques centaines d'employés au total. Le back-end est toujours à peu près le même : quelques contrôleurs de domaine, peut-être dans un cluster ou peut-être pas, quelques serveurs ISE, également éventuellement dans un cluster, et des politiques très similaires. La différence, cependant, est le nombre de commutateurs que je dois examiner et le nombre de ports que je dois toucher.
NetBrain détecte automatiquement plus de 2,000 XNUMX appareils par heure - des centaines de modèles parmi des dizaines de fournisseurs.
C'est là que ça devient intéressant. Cisco ISE n'agit pas seul. Le commutateur auquel un périphérique se branche est en fait un proxy qui parle au serveur Cisco ISE au nom du client. Par conséquent, la version matérielle et logicielle du commutateur doit être compatible avec la version d'ISE utilisée.
Afin de déployer Cisco ISE avec succès, vous devez inventorier toute votre couche d'accès pour voir s'il y a des commutateurs qui doivent être remplacés ou mis à niveau. Dans une grande organisation, cela peut prendre littéralement des semaines à une petite équipe.
Même avec des diagrammes de réseau comme aide, l'exploration d'un grand réseau pour obtenir des versions matérielles et logicielles spécifiques du commutateur est extrêmement fastidieuse. Pour un projet en particulier, il m'a fallu plusieurs mois de découverte manuelle quotidienne avec afficher les voisins cdp et afficher la version.
Une fois la compatibilité traitée et les serveurs ISE configurés, un ingénieur doit configurer chaque commutateur avec quelques lignes de configuration dot1x globale, puis configurer chaque port individuel avec la configuration dot1x appropriée également.
S'il y a jamais eu un cas pour l'automatisation du réseau, c'est bien celui-là.
NetBrainLa fonction de découverte automatisée de crée un Dynamic Map, ou en d'autres termes, une topologie de réseau en temps réel qui peut se mettre à jour périodiquement. Cela fournit aux ingénieurs une carte précise du réseau en quelques minutes plutôt qu'en heures, jours ou semaines que cela pourrait prendre manuellement, et ce n'est pas un avantage négligeable. NetBrain peut découvrir des milliers d'appareils en une heure, y compris des centaines de modèles à travers des dizaines de fournisseurs. Certaines versions de Cisco ISE ne fonctionneront tout simplement pas avec des plates-formes matérielles ou logicielles particulières. Par conséquent, pour qu'une implémentation 802.1x filaire fonctionne, une découverte de réseau n'est pas seulement utile, elle est essentielle.
Pour qu'une implémentation 802.1x filaire fonctionne, une découverte de réseau n'est pas seulement utile, elle est essentielle.
Après la mise à niveau du matériel et des logiciels vers les versions correctes, l'étape suivante consiste à activer globalement 802.1x sur chaque commutateur et à ajouter la configuration de port de commutation appropriée à chaque port de commutation. Les configurations elles-mêmes ne sont pas difficiles, mais faites le calcul. . . .
Même une organisation de taille moyenne peut avoir des centaines de commutateurs. Et même après avoir pris en compte les serveurs et les ports de jonction, cela pourrait encore signifier des dizaines de milliers de ports de commutation.
D'après mon expérience, le déploiement du 802.1x filaire se fait par phases. En règle générale, c'est emplacement par emplacement, en utilisant une stratégie d'ouverture en cas de problème au cas où les choses tourneraient mal lors d'un basculement. Cependant, la majeure partie de la fenêtre de modification concerne la configuration des appareils. Certaines configurations peuvent être prédéfinies, telles que les commandes 802.1x globales, mais beaucoup se situent au niveau du port et prennent effet dès qu'elles sont ajoutées.
Après avoir coupé un site, le dépannage commence. Il y a toujours au moins un périphérique qui ne se connecte tout simplement pas, et il s'agit de rechercher le commutateur et le port sur lequel le périphérique est branché et de vérifier la configuration. Cependant, lorsque nous parlons de nombreux commutateurs, c'est rarement un seul appareil qui a des problèmes.
Après un post-cutover Dynamic Map est créé, NetBrain's Exécutable Runbooks peut rechercher par programmation des anomalies de configuration ou, dans notre exemple, dépanner une grande implémentation câblée 802.1x, en quelques clics seulement. Il s'agit d'un outil incroyablement puissant lorsque tant d'appareils sont intégrés dans une solution d'authentification globale.
Gardez à l'esprit que pour moi, les plus grands défis auxquels j'ai été confronté lors du déploiement de 802.1x sur un réseau câblé n'ont pas été les politiques du serveur d'accès réseau que j'utilisais. Le plus grand défi consiste à étudier l'ensemble du réseau avec précision et rapidité afin de déployer de nombreuses lignes de configurations sur presque tous les commutateurs de la couche d'accès.
La découverte et le dépannage manuels sont une perte de temps totale - je le sais parce que j'y suis allé. Automatiser ces tâches banales avec NetBrain assure une vue beaucoup plus précise du réseau ainsi qu'un moyen beaucoup plus efficace de dépanner un grand nombre d'appareils à la fois.