Scenario d'utilisation

Dans cette section, nous illustrons l'intérêt de notre modèle de contrôle d'accès dans un contexte concret de supervision de réseau et en particulier de politique de routage. Considérons un fournisseur d'accès disposant d'un système autonome (AS) connecté à plusieurs autres AS. Nous supposons que ce fournisseur d'accès a mis en place une politique de routage interne basée sur RIP et une politique de routage externe basée sur BGP. Nous nous plaçons sur un routeur de bordure qui utilise donc à la fois le protocole interne IGP et le protocole externe EGP.

1 <rpc message-id="101" 2 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> 3 <rbac xmlns="urn:loria:madynes:ensuite:yencap:rbac:capability"> 4 <activate> 5 <roles> 6 <role>netAdmin</role> 7 <role>sysAdmin</role> 8 </roles> 9 </activate> 10 </rbac> 11 </rpc>

Message Netconf pour l'activation de rôles

1 <rpc message-id="101" 2 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> 3 <rbac xmlns="urn:loria:madynes:ensuite:yencap:rbac:capability"> 4 <deactivate> 5 <roles> 6 <role>sysAdmin</role> 7 </roles> 8 </deactivate> 9 </rbac> 10 </rpc>

Message Netconf pour la désactivation de rôles Fig. 6.4 Nouveaux messages Netconf pour RBAC

Ce fournisseur emploie des administrateurs ayant diverses compétences en réseau. Certains, comme Alice, sont capables de mettre en oeuvre le protocole RIP mais ne sont pas des spécialistes de BGP. D'autres, comme Bob, connaissent mieux BGP que RIP et d'autres (Tom) ont la double compétence et sont ainsi capables d'avoir une vision d'ensemble de la politique de routage, c'est-à-dire de prendre en charge les redistributions de routes apprises dynamiquement entre les protocoles.

L'intérêt du modèle RBAC ici est que nous allons dénir des rôles associés à chacune de ces fonctions de supervision et y aecter des administrateurs en fonction de leurs compétences. Nous dénissons tout d'abord un rôle générique de gestionnaire du routage : ManagerRoutage. Ce rôle a des permissions mineures qui permettent notamment de consulter la conguration liée au routage mais ne permettent pas de la modier. Ensuite, nous dénissons deux rôles senior du rôle précédant et qui sont dédiés l'un à la conguration du routage externe (ManagerRouta-geExterne) et l'autre à la conguration du routage interne (ManagerRoutageInterne). Le premier a le privilège de modier la conguration BGP alors que le second le privilège de modier la conguration RIP. Comme ce sont des rôles séniors du rôle ManagerRoutage, ils sont également capables de lire la conguration de routage en entier. Par exemple, un utilisateur, par l'inter-médiaire du rôle ManagerRoutageExterne peut lire non seulement la conguration de routage externe mais aussi la conguration du routage interne à titre informatif ou pour l'aider dans ses choix de conguration.

Enn, nous dénissons les rôles ManagerSécurité et ManagerRoot. Le premier gère la politique de sécurité via les ACL pour empêcher le routeur d'apprendre des routes issues de routeurs ayant un niveau de conance insusant. Le second, SuperManager, est dénit comme rôle sénior des trois rôles, ManagerSécurité, ManagerRoutageExterne et ManagerRoutageInterne et hérite ainsi de tous leurs privilèges. SuperManager n'est utilisé qu'en cas de problème grave, nécessitant par exemple une remise à plat de toute la conguration.

La gure 6.5 illustre la hiérarchie des rôles dénis précédemment. Notons que, dans notre exemple, le graphe des rôles est connexe mais ce n'est pas forcément le cas dans le modèle RBAC. De plus, chaque utilisateur ne sera associé directement qu'à un seul rôle. Cette propriété n'est pas forcément vraie dans le cas général. Les cinq rôles, ainsi que tous les paramètres relatifs à RBAC sont décrits dans un chier rbac.xml.

Spécions un peu plus nement les privilèges de chacun des rôles. ManagerRoutage a le privi-lège de lire la conguration donc a la permission d'exécuter la commande show running-config dans un contexte CLI. Dans notre contexte Netconf, nous pouvons spécier la permission en lec-ture sur la ressource identiée par l'expression XPath /ycp :netconf/ycp :routing, ycp étant le préxe de l'espace de noms XML. Le rôle ManagerRoutageExterne a la permission de modier la conguration BGP, identiée par l'expression XPath /ycp :netconf/ycp :routing/bgp :bgp, bgp étant le préxe de l'espace de noms du module de MIB de BGP. Entre parenthèses, on pour-rait aussi écrire //bgp :bgp ou même

//bgp:bgp/bgp:bgprouter//bgp:neighbor[@ip=⁰ 100.100.100.100⁰]

pour que ce rôle ne puisse modier que la dénition du voisin BGP ayant l'adresse IP spéciée. De façon similaire, le rôle ManagerRoutageInterne (ligne 24 à 29, Figure 6.7) a la permission (ligne 8 à 10, Figure 6.7) en écriture sur les sous-arbres dont les racines sont sélectionnées par l'expression

/ycp:netconf /ycp:routing/rip:rip

Le rôle ManagerSécurité a toutes les permissions sur les ACLs (ligne 11 à 13, Figure 6.7) iden-tiées par l'expression

ManagerSécurité

SuperManager ManagerRoutage

ManagerRoutageInterne Spécialisation

junior junior junior

senior

hiérarchie

(écriture, BGP) (écriture, RIP)

(écriture, Routage) (lecture, Routage)

(écriture, ACLs)

ManagerRoutageExterne

Fig. 6.5 Dénition des rôles pour le routeur de bordure

Enn, le rôle SuperManager a la permission en écriture sur toute la partie routage :

/ycp:netconf /ycp:routing

A titre indicatif, toutes les expressions XPath données ici correspondent au modèle de données que nous avons déni dans la plateforme EnSuite et sont donc spéciques à cette plateforme.

Les aectations des utilisateurs aux diérents rôles sont dénies comme suit : Alice est associée au rôle ManagerRoutageInterne, Bob est associé au rôle ManagerRoutageExterne, Tom est associé au rôle SuperManager. Par héritage, Tom est le seul à être aussi ManagerSécurité.

Les associations entre les privilèges et les rôles sont dénies de la ligne 23 à 29 (Figure 6.7). Des références (ou pointeurs) sont utilisées pour identier les permissions et les rôles dénis par ailleurs.