Modèle d‘administration

L‘administration des sujets est une tâche bien souvent perçue comme pénible, chronophage, voire incompréhensible par leurs utilisateurs. La déclaration des sujets et leur maintenance

102 doit donc être le plus automatisée possible pour garantir une adoption sans effort du modèle. Cela ne doit cependant pas nuire au respect de la vie privée, le propriétaire devant toujours être capable d‘affiner sa propre politique en intervenant à souhait sur les permissions générées qu‘il doit pouvoir visualiser.

Nous commençons par présenter la notion de rule consistency qui concrétise le fait que la production de chaque règle de partage peut être visualisée. Puis, nous montrons comment un système d‘exceptions permet de supporter la politique de vie privée spécifique du propriétaire, sans introduire de complexité. Enfin, nous expliquons comment l‘administration des sujets peut être réalisée de façon transparente, comme partie intégrante des règles de partage.

4.4.1 Rules consistency

Une règle SWYSWYK est dite bien formée si et seulement si elle ne produit que des ACL impliquant des documents visualisables, partagés avec des sujets indentifiables. De nouvelles notations sont ici introduites, liées à l‘administration SWYSWYK.

DV D : le sous-ensemble des documents visualisables, dans le sens interprétable, par le propriétaire. De façon plus formelle, DV = {dD / Viewer(d)}, avec Viewer une application en laquelle le propriétaire a pleine confiance. Elle pourrait typiquement être certifiée par une autorité de confiance ou une communauté d‘utilisateurs. Cette application doit être capable d‘afficher une vue interprétable du document au propriétaire, par exemple, transformer un binaire en une image.

DS  DV : ensemble des documents interprétables caractérisant un sujet unique. Par exemple, une fiche contact, un CV, une carte d‘identité, etc.

DI  D : ensemble des documents contenant des traits d‘identification de sujets (ou

identifiees). Par exemple une entrée d‘agenda, une photo de groupe, un compte-rendu de réunion, etc.

SR : ensemble des règles de partage activées par le propriétaire.

A partir de ces notations, on définit qu‘une règle SWYSWYK est bien formée, si et seulement si :

103

srSR, aclACL, acl.dDV  acl.sDS

N‘importe quelle aclACL qui ne satisfait pas à cette condition sera automatiquement filtrée.

4.4.2 Exceptions

Dans ce chapitre, nous avons acté comme hypothèse que l‘on ne considérait qu‘une politique fermée, avec uniquement des règles positives, c‘est-à-dire qui génèrent des autorisations.

Nous faisons le choix d‘exclure les règles négatives, c‘est-à-dire qui génèrent des interdictions. En effet, nous pensons que l‘utilisateur lambda ne peut pas appréhender aisément une politique mêlant des autorisations et des interdictions, parfois en conflit, ce qui peut devenir un enfer, même pour des administrateurs aguerris [Bertino 1993].

Appliqué à notre contexte, cette complexité introduirait un coût cognitif préjudiciable au principe d’empowerment éclairé car l‘utilisateur ne peut alors plus appréhender les effets concrets du modèle. Enfin, cela casserait également le principe de sécurité par construction. En effet, comme discuté au chapitre précédent, la logique du moniteur de référence doit être également compréhensible par le propriétaire. Cela est rendu possible par la simplicité du contrôle d‘accès qui se résume à vérifier l‘existence d‘un sujet, document, action dans l‘ensemble des ACL. L‘introduction de règles négatives complexifierait de façon répréhensible cette logique et pourrait potentiellement empêcher l‘implémentation du moniteur de référence dans du matériel sécurisé, comme ceux discutés dans la section 3.6. Ainsi, plutôt que d‘enrichir la sémantique des règles pour tenter de capturer tous les cas de figures possibles, nous introduisons le principe d‘exceptions qui permettent au propriétaire de filtrer certaines permissions qui lui sembleraient inadéquates avec sa politique de partage.

Afin de supporter des règles à base de prédicats pouvant souffrir d‘exceptions, mais sans introduire de négation, nous utilisons l‘interface d‘administration, l‘Administration GUI, présentée avec l‘architecture qui permet au propriétaire d‘interagir avec l‘ensemble des ACL considérées comme suspectes et filtrer les indésirables, considérées alors comme des exceptions et stockées dans ACL^-.

104 Pour rappel, seul l‘ensemble ACL⁺ est pris en compte lors de l‘évaluation du contrôle d‘accès par la fonction Allowed. La matérialisation de l‘ensemble des ACL^- permet à la fois au propriétaire de visualiser les exceptions qu‘il a établies et à la fonction Resolve de l‘utiliser dans le calcul de distance. A noter que le propriétaire peut à tout moment annuler une exception pour la faire passer en ACL⁺, la rendant ainsi active pour le contrôle d‘accès.

4.4.3 Administration des sujets

La versatilité des sujets rend leur administration ardue, et nécessite des mises à jour régulières, des ajouts, des suppressions, etc. L‘objectif ici est de rendre cette tâche la plus transparente possible en extrayant la définition des sujets directement depuis les documents du Cloud personnel, et ce via les règles de partage.

Tout d‘abord, nous détaillons la structure de S qui peut être représentée sous forme de table, avec le schéma suivant :

Sid: S, Did: Ƥ(DS), It: Ƥ(IT), [Ct: CONTACT], [Auth: {(AUTH, credential)}]

Sid est l‘identifiant unique du sujet. Did est l‘ensemble des identifiants qui référencent des documents représentant de façon unique ce sujet. It est l‘ensemble des traits d‘identification du sujet. Ct et Auth sont optionnels et dépendant de la plateforme de Cloud personnel. Ils permettent respectivement de notifier et authentifier le sujet. Typiquement, la notification peut se faire par e-mail qui est le moyen interopérable le plus répandu pour contacter des sujets et l‘authentification peut être réalisée par un des protocoles décrits dans la section 2.2.1.

La fonction IsS(d), brièvement évoquée dans la section 4.3.1 est utilisée pour enregistrer de nouveaux sujets dans S. En réalité, il s‘agit d‘un effet de bord de la fonction, dont le rôle premier est de retourner le sujet sS associé au document dD. Nous présentons l‘algorithme de IsS ci-dessous, en Figure 15.

Fonction IsS

Entrée: d  D

105

1. if  s  S / MatchS(DI(d), SI(s)) then 2. s.It  s.It  DI(d)

3. else if RegistrationAgreement() then 4. s  NewSid()

5. S  < s, d, DI(d), [Ct(s)], [Auth(s)] >

6. DS  d 7. else s  

8. return s

Figure 15. Fonction IsS

IsS est automatiquement appelée (1) chaque fois qu‘un document d  DS est créé ou mis à jour dans le Cloud personnel, par exemple une fiche contact, et (2) chaque fois qu‘une règle de partage est créée. Les documents considérés comme faisant partie de l‘ensemble DS

sont à la discrétion de la plateforme de Cloud personnel.

Si au moins un trait d‘identification présent dans un document d correspond à un sujet s

existant, s est retourné et s.It potentiellement enrichi avec les autres traits d‘identification présents dans d. Si aucune correspondance n‘est trouvée, le propriétaire peut être notifié pour accepter l‘enregistrement du nouveau sujet à partir du contenu de d. Autrement, IsS

échoue et retourne.

Ainsi, l‘ensemble des sujets grossit automatiquement au fil des insertions des documents et des déclarations de règles, en minimisant autant que possible les interactions avec le propriétaire.

Ce dernier pourrait cependant vouloir désambiguïser de temps en temps le contenu de S à travers l‘interface d‘administration. Par exemple, fusionner des situations telles que 'John Doe's.It et 'john@doe.io's'.It. C‘est un problème fréquemment rencontré dans les applications de contacts et résolu de façon semi-automatique dans la plupart d‘entre elles par des heuristiques simples. Il est par exemple possible de calculer des similarités textuelles par la méthodes de Jaccard [Tan 2006] ou la distance de Levenshtein [Navarro 2001]. Ce n‘est donc à priori pas un challenge de l‘intégrer dans l‘Administrative GUI.

En complément de cette mécanique, des systèmes plus poussés pourraient être utilisés pour créer et mettre à jour automatiquement les sujets, se reposant par exemple sur l‘ontologie FOAF et l‘utilisation de profils publics ou privés. Dans ce cas de figure, chaque sujet est

106 responsable de la création et la maintenance de ses propres attributs d‘identification depuis sa page personnelle. Chaque Cloud personnel peut alors automatiquement requêter cette page pour récupérer les attributs accessibles. L‘intégration d‘un tel système, présenté dans [Van Kleek 2012] est remis à des travaux futurs.