Liez l’accès au bureau à l’identité, pas au port du commutateur

Deux conceptions sont sur la table. L’une garde les employés dans des VLAN fondés sur les rôles et modifie les ports du commutateur quand les gens bougent. L’autre authentifie la session et laisse la politique décider de ce qu’elle peut atteindre. Le choix ne porte pas sur la modernité ; il porte sur la question de savoir si trois conditions tiennent dans votre bâtiment. Si l’une d’elles échoue, la conception par port n’est pas stupide, c’est celle que vous pouvez réellement exploiter.

Les trois conditions sont l’applicabilité, la qualité de l’identité et le comportement en cas de défaillance.

Condition 1 : les équipements d’accès peuvent-ils appliquer une politique renvoyée

802.1X est une relation entre un supplicant sur le poste, un authentificateur dans le commutateur ou la borne et un serveur d’authentification joint par RADIUS. Le serveur peut renvoyer un VLAN ou un autre résultat de politique, et la RFC 3580 décrit cette signalisation. Le commutateur doit tout de même mettre en œuvre le résultat sur lequel vous comptez.

Demandez une capacité, pas un protocole : affectation dynamique de VLAN, ACL téléchargeables ou redirection vers un portail d’enregistrement.

Condition 2 : la source d’identité est-elle faisant autorité et rapide à modifier

L’appartenance à un groupe dans l’annuaire n’aide que si c’est le champ que l’entreprise modifie déjà quand un rôle change. Si l’attribution des rôles vit dans un tableur copié dans les groupes chaque mois, l’accès fondé sur l’identité automatise simplement une entrée périmée. Vérifiez aussi la latence, car un nouvel arrivant qui ne peut pas travailler pendant une journée est un résultat pire qu’un changement de port manuel. L’authentification de l’appareil, celle de l’utilisateur et les deux ensemble sont des choix distincts, et les imprimantes ont besoin d’un modèle explicite plutôt que d’un contournement inexpliqué.

Écrivez la correspondance : quel groupe accorde quelle politique, et qui peut la modifier.

Condition 3 : décidez le comportement en cas de défaillance avant le pilote

Chaque déploiement a un état non authentifié et un état de serveur indisponible, et la politique des deux est une décision de sécurité. Un repli silencieux vers un segment de confiance ruine la conception ; une défaillance dure bloque le travail pendant une panne. Le juste milieu habituel est un segment restreint avec un accès limité à internet et un chemin clair vers le service d’assistance. Testez le repli sur le commutateur ou la plateforme sans fil réels, car les valeurs par défaut des fournisseurs diffèrent.

Si personne ne peut décrire le repli en une phrase, la conception n’est pas terminée.

Où se situe le VPN

Un VPN authentifie l’accès sur un chemin non fiable, et l’exiger aussi sur le LAN du bureau peut être une décision de confiance délibérée. Il ne supprime pas le besoin de correspondance de groupes ni l’autorisation propre au serveur de fichiers. Il ajoute aussi de la capacité de passerelle, un logiciel client et la gestion des sessions à la charge d’exploitation.

Un VPN acheté pour éviter de modifier des VLAN a résolu le mauvais problème et en a ajouté deux nouveaux.

Le tableau, et la seule chose à conserver

Gardez des segments pour les serveurs, les invités, les appareils et la technologie opérationnelle. Ces frontières concernent le trafic et non les intitulés de poste, et elles survivent à toute réorganisation. Placez les droits des employés dans la politique d’identité, où un changement de rôle est une seule modification, et utilisez le mécanisme de déconnexion pris en charge quand le retrait doit être rapide.

Le test de la conception est un déménagement de bureau : il doit déplacer une personne et son matériel, pas reconstruire ses permissions autour d’une autre prise.