Toi tu fais la tuyauterie, toi tu gères la sécurité, et moi je m’occupe des apps!
Une solution SD-WAN va regrouper derrière un seul portail de management diverses fonctions qui tournaient préalablement sur des appliances différentes (routeur, optimisation applicative, firewall, IPS…) afin de fournir une expérience utilisateur optimale et sécurisée, bien au-delà d’un simple connectivité réseau. On comprend tout de suite l’importance d’avoir un minimum de contrôle dans ce que pourront faire les différents acteurs qui seront amenés à configurer tout cela! Si l’on rajoute le besoin de pouvoir éventuellement faire une co-gestion de réseau avec un opérateur (ou intégrateur), et de pouvoir gérer des réseaux complexes et segmentés, on comprend que pouvoir gérer des droits différenciés (multi-tenancy et RBAC) est une autre composante importante attendue d’une solution SD-WAN. C’est pour cela que la solution Cisco SD-WAN (anciennement connue sous le nom de Viptela) intègre de nombreux mécanismes pour garantir la capacité d’opérer simplement le réseau et ses services tout en prenant en compte certaines réalités opérationnelles.
Le premier point à souligner est la capacité de déployer le portail de management en mode multi-tenant. Si ce mode est surtout pensé pour permettre à un service provider de pouvoir opérer les réseaux de plusieurs clients depuis le même vManage, on voit parfois cette nécessité chez quelques clients avec des réseaux très cloisonnés (avec différentes entités qui ne veulent rien partager en commun). Dans un mode multi-tenant, les différents tenants sont des réseaux complètement disjoints (les infras sont dissociées). On pourra ainsi créer des droits complètement distincts pour chacun d’entre eux. Un administrateur assigné à un tenant ne verra même pas que d’autres tenants existent! On ne partage ici que le vManage pour éviter d’avoir à déployer autant de consoles de management que de tenants.
Dans chaque tenant on va ensuite avoir une granularité très importante dans la gestion des droits. Par exemple:
- Une équipe d’architectes réseau pourra se charger de définir les templates de connexion au réseau en fonction des typologies de site
- Une équipe opérationnelles réseau pourra configurer les équipements sur les sites à partir des templates définis
- Une équipe d’architectes sécurité pourra définir des politiques de sécurité (firewall, IPS/IDS, URL filtering, anti malware…)
- Une équipe opérationnelle de sécurité pourra configurer et monitorer ces fonctions de sécurité
- Une équipe applicative pourra gérer les politiques d’accès au cloud (en fonction des applications)
- Une nouvelle équipe SD-WAN pourra définir les topologies réseau, et les règles applicatives (routage intelligent, packet duplication, traffic etc.)
- Une autre équipe pourra s’assurer des upgrades logiciels pour vous permettre de bénéficier régulièrement des innovations très nombreuses…
Je laisse votre imagination compléter, ce ne sont pas moins de 23 privilèges différents qui peuvent être aujourd’hui associés à des groupes d’administrateurs:
- Certificates
- Cloud OnRamp
- Cluster
- Device Inventory
- Device Monitoring
- Device Reboot
- Events
- Interface
- Manage Users
- Network Hub
- Policy
- Policy Configuration
- Policy Deploy
- Routing
- Security
- Security Policy Configuration
- Settings
- Software Upgrade
- System
- Template Configuration
- Template Deploy
- Tools
- vAnalytics
Vous allez pouvoir définir vos propres groupes d’utilisateurs et leurs assigner les droits en lecture/écriture désirés parmi ceux listés précédemment. Ci-dessous je définis un groupe reseauxblog qui pourra définir des policies et règles de sécurité (sans pour autant avoir le droit de les appliquer)
On peut ensuite évidemment définir autant d’utilisateurs que l’on veut dans les différents groupes. Et si besoin on peut faire du SSO via intégration SAML (ADFS, Okta…) et pourquoi pas intégrer Duo pour faire du Two-factor authentication!
Mais ce n’est pas tout! La solution Cisco SD-WAN offre des capacités uniques de segmentation, en permettant de créer un très grand nombre de VPN dans chaque tenant. Un VPN dans la terminologie SD-WAN correspond à une VRF, et permet de faire sur un même réseau une segmentation forte. Au sein du vManage, on va pouvoir faire des configurations différenciées pour chaque VPN.
- L’entité ABC pourra par exemple être en regional mesh et vouloir répliquer les flux voix Jabber sur tous les liens pour ne jamais perdre de paquets
- L’entité XYZ pourra elle être en full mesh et voudra router les flux de téléprésence sur les liens les plus performants.
Ces deux entités partageant le même réseau, on va avoir besoin d’un arbitrage central pour avoir un minimum de cohérence sur l’ensemble des règles appliquées. Imaginons que chacune de ces deux entités souhaite router tous ses paquets sur le lien le plus performant uniquement, il peut y avoir un petit problème au final. Allez-vous laisser l’administrateur d’un de ces 2 VPN faire un upgrade logiciel et reloader le routeur? Lui laisseriez-vous le loisir de pouvoir déployer n’importe quel fonction à n’importe quel moment au risque de créer un problème global sur le routeur SD-WAN? (saturation de la mémoire, boucle de routage, ou même un bug sur une nouvelle fonctionnalité non éprouvée?) Laisserez-vous l’administrateur du VPN ABC mettre en place ses règles de routage au risque d’absorber un jour 500.000 routes dans son VPN et écrouler un petit routeur qui ne les supporterait pas? Et laisserez-vous l’administrateur du VPN ABC faire ses maintenances entre 6H et 8H alors que c’est l’heure choisie par le VPN XYZ pour upgrader ses terminaux monétiques? Il convient avant tout de s’assurer que le réseau WAN soit stable et d’être pragmatique.
Pour ce use case, on va surtout chercher aujourd’hui à offrir des dashboards différenciés par VPN en lecture. Chacun pourra vérifier le bon fonctionnement de son réseau virtuel et de ses applications, et éventuellement demander des ajustements de policy à l’entité en charge du SD-WAN, qui s’assurera d’une cohérence de toutes les règles pour offrir le meilleur service à tous. J’ai créé ci-dessous un VPN-group pour le VPN 123 et associé au user group reseauxblog.
Tout administrateur dans le User group reseauxblog pourra alors accéder à toutes les infos relatives au VPN 123. Vous pourrez voir ci-dessous un exemple de dashboard associé pour un VPN.
Ces principes évidents de contrôle d’accès ont permis à nos clients de déployer des réseaux complexes très important (parfois près de 10.000 routeurs!) et ce de manière stable.
Et si vous souhaitez déléguer certains droits plus précisément, rappelez vous que l’ouverture du vManage via des API REST permet d’intégrer ce dernier dans un portail de demande de service qui serait orienté business! Plusieurs opérateurs par exemple ont déjà réalisé ce type d’intégration pour permettre à leurs clients de faire des demandes de changement automatiquement. Dans ce cas il s’assure dans son implémentation que les requêtes respectent certains critères dans l’intérêt général de tous les clients!
L’architecture multi-tenant Cisco SD-WAN et son RBAC permettent de répondre de manière efficace aux besoins prédominants d’administration des réseaux SD-WAN, et ce de manière pragmatique. Nul doute qu’avoir plus est toujours tentant. Mais il faut revenir aux réalités opérationnelles et ne pas oublier que la configuration d’un routeur (SD-WAN ou non) n’est jamais à prendre à la légère. Aussi vous ne laisserez pas chaque entité gérer leur propre VRF et activer n’importe quel service n’importe quand. Tous les VPN partagent le même hardware, la même mémoire, la même CPU… et il faut donc avoir un peu de cohérence sur l’ensemble.
Tags:
