Synthèse et perspectives

Pour conclure, Netconf a potentiellement un champ d'action susamment grand (BGP, VoIP, etc...) pour justier un tel découpage en rôle des responsabilités. Il nous semble être une bonne pratique d'adopter une démarche similaire à celle de Webmin en commençant par dénir une permission par module de MIB, ce qui revient à un modèle à grain moyen puis de spécialiser ces permissions plus nement lorsque cela est nécessaire. Ces permissions plus nes portent sur des sous-parties d'un même module. Cela crée une double granularité probablement susante pour la majorité des cas. Cette façon de faire ne change en rien le modèle décrit jusqu'ici puisque le n÷ud représentant un module s'exprime toujours par une expression XPath.

La meilleure réponse au choix entre une dénition des permissions par module ou par ex-pressions XPath libres ne peut venir que par l'expérience d'un déploiement à grande échelle des agents Netconf, chacun mettant à disposition un nombre important de modules. Dans un tel contexte, il est probable que la dénition des permissions penche vers l'option module plutôt que vers l'option XPath.

1 <?xml version="1.0" encoding="UTF-8"?> 2 <rbac xmlns="urn:loria:madynes:ensuite:yencap:module:RBAC:1.0" 3 xmlns:ycp="urn:loria:madynes:ensuite:yencap:1.0" 4 xmlns:bgp="urn:loria:madynes:ensuite:yencap:module:BGP:1.0" 5 xmlns:rip="urn:loria:madynes:ensuite:yencap:module:RIP:1.0"> 6 <users> 7 <user id="1"> 8 <login>Alice</login> 9 <password>Alice</password> 10 </user> 11 <user id="2"> 12 <login>Bob</login> 13 <password>Bob</password> 14 </user> 15 <user id="3"> 16 <login>Tom</login> 17 <password>Tom</password> 18 </user> 19 </users> 20 <roles> 21 <role id="1"> 22 <name>ManagerRoutage</name> 23 </role> 24 <role id="2"> 25 <name>ManagerRoutageInterne</name> 26 <junior-roles> 27 <junior-role roleRef="1"/> 28 </junior-roles> 29 </role> 30 <role id="3"> 31 <name>ManagerRoutageExterne</name> 32 <junior-roles> 33 <junior-role roleRef="1"/> 34 </junior-roles> 35 </role> 36 <role id="4"> 37 <name>ManagerSécurité</name> 38 <junior-roles> 39 <junior-role roleRef="1"/> 40 </junior-roles> 41 </role> 42 <role id="5"> 43 <name>SuperManager</name> 44 <junior-roles> 45 <junior-role roleRef="2"/> 46 <junior-role roleRef="3"/> 47 <junior-role roleRef="4"/> 48 </junior-roles> 49 </role> 50 </roles>

1 <permissions>

2 <permission id="1" op="r">

3 <scope>/ycp:netconf/ycp:routing</scope> 4 </permission>

5 <permission id="2" op="w">

6 <scope>/ycp:netconf/ycp:routing/bgp:bgp</scope> 7 </permission>

8 <permission id="3" op="w">

9 <scope>/ycp:netconf/ycp:routing/rip:rip</scope> 10 </permission>

11 <permission id="4" op="w">

12 <scope>/ycp:netconf/ycp:routing/sec:acl</scope> 13 </permission>

14 <permission id="5" op="w">

15 <scope>/ycp:netconf/ycp:routing</scope> 16 </permission>

17 </permissions> 18 <user-assignements>

19 <user-assignement roleRef="2" userRef="1" id="1"/> 20 <user-assignement roleRef="3" userRef="2" id="2"/> 21 <user-assignement roleRef="5" userRef="3" id="3"/> 22 </user-assignements>

23 <permission-assignements>

24 <permission-assignement roleRef="1" permRef="1" id="1"/> 25 <permission-assignement roleRef="2" permRef="3" id="2"/> 26 <permission-assignement roleRef="3" permRef="2" id="3"/> 27 <permission-assignement roleRef="4" permRef="4" id="4"/> 28 <permission-assignement roleRef="5" permRef="5" id="5"/> 29 </permission-assignements>

30 </rbac>

Il est prudent de se poser la question de la dénition des permissions en fonction des seules opérations de lecture ("r") et d'écriture ("w"). Le privilège de vérouiller/dévérouiller une con-guration devrait aussi être pris en considération car il empêche toute intervention durant la durée de possession de ce verrou. Dans le futur, d'autres types d'opération pourraient apparaître. Par exemple, nous avons développé un mécanisme de déploiement et de chargement à chaud de mo-dules sous la forme d'archives compressées. Ce type d'opération n'entre pas dans le cadre d'une opération de type "r" ou "w". Cette remarque s'applique aussi pour les notications qui sont en cours de spécication par le groupe de travail Netconf. Donc, notre approche doit rester souple pour supporter les évolutions futures du protocole Netconf.

Les principales diérences, par rapport au modèle de contrôle d'accès basé sur les vues de SNMPv3, sont les suivantes : il n'y a pas de possibilité de spécier l'inclusion ou l'exclusion d'une resource car on ne spécie que des permissions positives, d'où la disparition des conits. On ne fait plus intervenir le modèle de sécurité sous-jacent, ce qui divise la complexité par le nombre de modèles de sécurité possibles. On ne fait plus intervenir non plus les services de sécurité utilisés, ce qui divise la complexité par trois, car il y a trois niveaux possibles (noauthnopriv, authnopriv et authpriv). Ici, on est favorisé par le contexte, car on suppose que tous les protocoles sous-jacents fournissent les mêmes services de sécurité (SOAP/HTTPS, SSH, BEEP/SSL). Une vue (ensemble de resources protégées) est exprimée avec une seule expression XPath au lieu d'un ensemble de couple (OID, masque). Les rôles sont organisés dans une hiérarchie alors que les groupes ne l'étaient pas. Tous ces changements font que la politique de sécurité est plus simple à gérer, tout en étant plus puissante.