Le contrôle d’accès au réseau (802.1X, authentification par adresse MAC, accès invité, etc.) et la gestion des autorisations réunissent souvent plusieurs éléments d’un réseau Wi-Fi ou filaire, ainsi que différentes solutions de sécurité. Cisco propose une architecture de sécurité avancée, appelée TrustSec, mise en œuvre grâce à un ou plusieurs composants réseau, qui se décline avec des options « overlay », donc superposées, sans changer complétement les déploiements existants, et qui permet de décorréler les politiques de filtrage de l’adressage IP des terminaux.
Cisco TrustSec se base en premier sur la notion de SGT (Security Group Tag). Ceci est à l’origine un numéro, ou « tag », transporté dans un champ optionnel de l’entête d’une trame Ethernet, le champ CMD : CTS (Cisco TrustSec) Meta Data. On parle dans ce cas de propagation, ou transport, du SGT de type « inline », c’est-à-dire directement dans les options des trames Ethernet.
Tout équipement réseau supportant le champ optionnel SGT peut lire le « tag » du trafic d’un terminal et, par exemple, appliquer des listes d’accès sur la base du « tag » au lieu que sur la base de l’adresse IP. Ces listes d’accès sont appelées SGACL (Security Group Access Control List) et sont supportées sur des switch Cisco Catalyst et Nexus, des pare-feu Cisco ASA, ou encore des contrôleurs Wi-Fi Cisco.
De cette façon l’on peut décorréler les politiques de filtrage des plages d’adresses IP et traiter de manière différente des terminaux qui partagent le même réseau IP, mais avec des profils ou des contextes différents.
Les équipements Cisco ne sont pas les seuls à supporter la notion de SGT pour l’application des politiques de filtrage. D’autres constructeurs de solutions de sécurité (par exemple, Bayshore Networks) supportent aujourd’hui le protocole SXP pour la réception des tags SGT à travers du niveau L3.
Pour une infrastructure réseau dans laquelle pas tous les équipements supportent les tags SGT dans les trames Ethernet, Cisco a également introduit le protocole SXP (SGT eXchange Protocol), aujourd’hui publiquement disponible dans ce draft IETF.
Un équipement réseau d’accès (switch, AP, WLC, etc.) affecte de manière statique ou dynamique (cf. paragraphes suivants) un tag SGT à un terminal. Ce même équipement réseau, ayant également une visibilité sur l’adresse IP du terminal, construit ensuite un tableau d’associations IP-SGT. Comme ultérieure étape, l’équipement réseau d’accès peut communiquer ces associations IP-SGT des terminaux vers d’autres équipements réseau, à travers une connexion TCP sur le port 64999, sécurisée en MD5 : cette connexion TCP permettant l’échange des associations IP-SGT est appelée SXP.
On parle dans ce cas de transport, ou propagation, des tags SGT à travers du niveau L3.
L’équipement source d’une connexion SXP est dit « SXP speaker » et l’équipement destination de cette même communication est appelé « SXP listener ». Le même équipement peut également être à la fois SXP « speaker » et « listener », dans le cas où il recevrait des associations IP-SGT en provenance de certains équipements pour les redistribuer vers d’autres équipements (on parle par exemple de « hub » SXP).
Un équipement recevant les informations sur le SGT et l’IP d’un terminal, dès qu’il voit du trafic en provenance de telle adresse IP, peut ensuite appliquer des politiques de sécurité (filtrage, inspection du trafic, etc.) basées sur le SGT source du terminal et éventuellement le SGT (ou l’IP) destination d’une autre ressource réseau.
L’affectation d’un tag SGT à un terminal peut être faite de manière statique ou dynamique.
Une affectation statique consiste à configurer un binôme IP-SGT directement dans l’équipement d’accès, en déclarant à la main l’adresse IP (ou même le réseau / port / VLAN / etc.) qui doit être toujours associée à un certain SGT.
Une affectation dynamique se fait par attribut RADIUS, à l’issue d’une authentification 802.1X, par adresse MAC, par portail captif, etc. Cette technique ressemble à l’affectation dynamique de VLAN, mais elle se révèle beaucoup plus puissante car les tags SGT s’appliquent et peuvent être transporté sur du niveau L3, alors que les VLAN restent au niveau L2.
L’affectation d’un tag SGT suite à une authentification peut se baser sur tout type de paramètre : le groupe AD d’un utilisateur, l’attribut du certificat machine, l’état de conformité du terminal, l’enregistrement de la tablette à une solution MDM, etc. Grâce à cela on peut commencer à parler de sécurité contextuelle.
Un exemple rapide d’application de Cisco TrustSec dans la vraie vie pourrait être le suivant :
- Une entreprise souhaite déployer un réseau Wi-Fi invité, avec un VLAN unique pour tous les visiteurs.
- Le portail captif du réseau Wi-Fi doit supporter l’authentification des visiteurs avec des comptes invité permettant la différenciation des accès à certaines ressources. Par exemple, des invités « standard » avec accès à Internet uniquement et des invités « premium » pouvant aussi se connecter en VPN pour vérifier leurs emails.
- Des ACL classiques basées sur les adresses IP ne répondraient pas à ce besoin, car les différentes populations de visiteurs, « standard » et « premium », partagent la même plage d’adressage.
- A l’issue de l’authentification par portail captif, en affectant un SGT spécifique aux visiteurs « standard » et un autre SGT spécifique aux visiteurs « premium », cette entreprise peut différencier les politiques d’accès en appliquant des SGACL ou autres options de contrôle des flux basées sur les SGT, tout en gardant les deux populations d’utilisateurs sur le même réseau.
Depuis la version 7.2MR1 les contrôleurs Wi-Fi Cisco ont toujours supporté l’affectation dynamique des SGT par attribut RADIUS et l’échange des associations IP-SGT par SXP.
A partir de la version 8.4, prévue pour avril / mai 2017, les solutions Wi-Fi Cisco supportent également les échanges SXP depuis les APs, le transport « inline » des tags SGT, ainsi que le filtrage par SGACL directement au niveau du WLC ou des APs.
Les échanges SXP depuis les APs directement permettent d’élargir les cas d’usage de propagation des SGT à travers du niveau L3 aux déploiements FlexConnect, où les flux des terminaux Wi-Fi doivent être commutés localement sur un site distant et pas remontés jusqu’au WLC et où les politiques de sécurité par tags SGT pourraient être également gérées par des équipements locaux sur chaque site distant.
De manière similaire à la propagation des tags SGT par SXP, les contrôleurs et les APs Cisco supportent également le transport des SGT « inline », à travers les champs optionnels de l’entête Ethernet, dans le cas où d’autres équipements réseau supporteraient cette technique de propagation.
Une option supportée ultérieurement consiste à appliquer les SGACL directement au niveau du WLC ou des APs.
Cette fonction permet de déployer la solution TrustSec directement dans l’infrastructure Wi-Fi Cisco, sans besoin de supporter les SGT, SXP ou les SGACL sur d’autres équipements réseau Cisco et non.
Comme dernière alternative, pour les déploiements ne disposant pas d’un réseau d’accès qui supporte l’affectation des SGT et les échanges SXP, le serveur RADIUS de contrôle d’accès Cisco ISE (Identity Services Engine) peut également être configuré en tant que SXP « speaker ».
Lors de l’authentification d’un terminal ou d’un utilisateur, Cisco ISE y associe un SGT, qui en revanche n’est pas compris par l’équipement réseau d’accès si cet équipement ne le supporte pas et qui reste donc local à ISE lui-même. D’un autre côté, grâce au trafic de RADIUS Accounting, l’équipement d’accès communique à ISE l’adresse IP du terminal. A partir de ce moment ISE connaît l’association complète IP-SGT relative au terminal et peut la communiquer en SXP à d’autres équipements capables d’appliquer des politiques de sécurité basées sur les SGT.
Les options décrites dans cet article permettent de déployer Cisco TrustSec sur des réseaux existants aussi, Cisco et non, et de bénéficier d’une solution de contrôle d’accès contextuelle, appliquée à un tag propre à l’utilisateur ou au terminal et qui suit cet utilisateur ou ce terminal à travers le réseau et ses points d’application des politiques de sécurité.
Plus d’informations sur TrustSec, SGT et SXP dans une infrastructure Wi-Fi Cisco sont disponibles dans le guide suivant :
http://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-4/b_wireless_trustsec_deployment_guide.html
L’exemple de configuration suivant démontre également comment déployer Cisco ISE en tant que SXP speaker :
http://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/200278-Configure-ISE-2-0-TrustSec-SXP-Listener.html
Authors