J’ai déjà abordé sur ce blog Trustsec, les Security Group Tags (SGT), les Security Group ACL (SGACLs) et depuis bien longtemps je vous avais promis de vous donner plus de détails sans succès… Michael Wolljung est venu à mon secours et vous explique enfin ci-dessous le fonctionnement théorique des SGT/SGACLs! Il vous prépare aussi quelques petites démos qui devraient vous plaire 🙂
Qui ne s’est jamais cassé la tête et noyé dans un flot monstrueux d’ACLs en voulant sécuriser l’accès à son réseau ? Et bien réjouissez-vous, le temps des listes interminables et ingérables d’ACLs est enfin révolu ! En effet, grâce aux Security Group Tags, il est dorénavant possible de mettre en place un contrôle d’accès simple, facilement modulable et indépendant de la topologie de notre réseau.
Alors comment cela fonctionne-t-il ?
En pratique, un terminal se connectant au réseau peut s’authentifier auprès de notre serveur de politique de sécurité ISE (Identity Service Engine). Celui-ci, en fonction d’une foule de paramètres que l’on va choisir (mode d’authentification, type de terminal, groupe utilisateur… pour ne citer que ceux-là), va pouvoir associer notre terminal à un groupe de sécurité. C’est entre ces groupes de sécurité que l’on va définir des règles de sécurité en non plus en fonction d’IP, VLANs ou interfaces… Notez bien que le groupe de sécurité est indépendant du VLAN!
Pour chaque groupe de sécurité un Security Group Tag (SGT) est affecté. Chaque trame émise par un terminal va être taguée par l’équipement d’accès avec ce SGT (rien ne change sur le terminal: tout se passe dans le réseau!). Ce SGT source, ainsi que le SGT associé à la destination vont pouvoir être utilisés pour réaliser des actions de filtrages, soit sur les firewalls, soit directement les équipements du réseau grâce aux Security Group ACLs (SGACLs). Ainsi on va réellement pouvoir appliquer des règles de sécurité selon le contexte de connexion et non simplement en fonction d’une adresse IP, liée bien évidemment à la topologie du réseau.
Si l’on peut configurer ces SGACLs statiquement sur les équipements, on sait aussi les administrer globalement depuis ISE et c’est ça qui est remarquable. On a ainsi un outil unique pour tout ce qui touche à la gestion de la sécurité sur le réseau. Les SGACLs sont représentées sous forme d’une matrice d’accès sur ISE ayant pour axes les SGT sources et destination et chaque cellule représentant la règle d’accès correspondante. Le travail d’admin se réduit alors à gérer cette simple matrice sur ISE qui va pousser les règles au sein du réseau. Bref on a nativement de la lisibilité et une réelle maîtrise sur nos règles de filtrage: plus besoin de sacrifier un SFP sur l’autel du dieu IP avant de changer nos règles de sécu!
Appliquer ce tag et le transporter nécessite des capacités matérielles qui ne sont pas forcément présentes sur tous les équipements du réseau. Que l’on se rassure ce n’est pas bloquant: le protocole SXP (SGT eXchange Protocol) a été conçu pour pallier ce problème. Grâce à SXP, les équipements du réseau vont pouvoir s’annoncer les correspondances (ou mappings) entre les adresses IP et les SGT. Les connexions SXP peuvent s’établir entre équipements non-adjacents: du coup il est même possible d’échanger les mappings entre un commutateur d’accès et un firexwall dans le datacenter. Quand un équipement reçoit une trame non tagguée, il peut éventuellement déterminer le tag associé en lisant l’adresse IP et sa table de correspondance reçue par SXP.
En bref
Les SGACLs définissent donc des règles d’accès basées sur le contexte de connexion (qui inclut notamment l’identité) et non plus simplement sur l’adresse IP comme cela est fait traditionnellement. Dans un contexte de mobilité, voire même de BYOD cela est essentiel puisqu’on va savoir gérer la sécurité indépendamment du VLAN. Donc que l’on soit en WiFi sur un VLAN X ou en filaire sur un VLAN Y on va pouvoir avoir un SGT unique et ne garder qu’une règle de sécurité. On a donc une meilleure cohérence dans la politique globale de sécurité du réseau. L’utilisation des SGTs et SGACLs réduit drastiquement le nombre de règles de sécurité, et toute la sécurité du réseau peut être gérée depuis un point central: ISE (identity Service Engine). Bref tout devient c’est plus simple et cela marche d’autant mieux!
Liens utiles :
– Cisco TrustSec introduction page:
http://www.cisco.com/go/trustsec
– Cisco TrustSec configuration guide : http://www.cisco.com/en/US/docs/switches/lan/trustsec/configuration/guide/arch_over.html
Un grand merci à Michael Wolljung pour son aide pour cet article et pour les démos à venir.
Authors
