Principes de base de SWYSWYK

Comme dit précédemment, l‘objectif ici n‘est pas de présenter un nouveau modèle de contrôle d‘accès. Nous faisons l‘hypothèse que la politique de partage est définie par le modèle fourni par la plateforme de Cloud personnel utilisée. Ainsi, n‘importe quel modèle cité dans le Chapitre 2 pourrait être utilisé, à condition de respecter les trois prérequis suivants :

1. Visualisation des documents. La granularité du partage est au niveau du document et n‘importe quel document partagé doit être visualisable par le propriétaire. Cela implique qu‘il existe une ou plusieurs applications de visualisation, appelées Viewer,

capables d‘interpréter chaque document partagé et de le rendre visualisable par un humain. Ainsi, même si un partage est le résultat d‘un traitement complexe sur un ensemble de documents, ce traitement doit produire un document visualisable et compréhensible par le propriétaire. Par exemple, un calcul d‘agrégation sur une série temporelle provenant d‘un compteur électrique connecté pourra être rendu sous la forme d‘une courbe de consommation. Nous n'envisageons pas une granularité plus fine que celle du document car cela pourrait rendre l‘interprétation difficile pour les

Viewers. Cette limitation peut néanmoins être facilement contournée, en générant un nouveau document depuis un sous-ensemble d‘un ou plusieurs autres documents. Ceci, toujours à la condition de pouvoir le visualiser.

2. Représentation des sujets. Chaque sujet avec qui le propriétaire veut interagir doit également correspondre à un document visualisable qui représente le sujet de façon unique. Nous ne posons aucune limitation sur le type de ces documents qui peut être une fiche contact, un CV, une entrée de carnet d‘adresse e-mail, etc. Le propriétaire doit pouvoir à tout moment identifier aisément les destinataires de ses partages. 3. Matérialisation des permissions. La politique de contrôle d‘accès est matérialisée

par un ensemble d‘ACL (Access Control List), qui représentent les permissions sous la forme de triplets < s, d, a >, où s et d désignent respectivement un sujet et un document stockés dans le Cloud personnel, et a l‘action accordée au sujet s sur le document d. Le propriétaire a la possibilité de vérifier ces ACL et supprimer celles qu‘il considère comme pouvant porter atteinte à sa vie privée. Il n‘est pas attendu de sa part de vérifier toutes les ACL, ce qui serait beaucoup trop fastidieux, mais simplement de valider celles identifiées comme suspectes grâce à des outils d‘administration décrits plus loin dans ce chapitre.

62 Matérialiser toutes les permissions, les rendre visualisables par le propriétaire et lui laisser la possibilité de filtrer les indésirables : voilà les principes fondamentaux de Share What You See with Whom You Know (SWYSWYK), littéralement : partage ce que tu vois avec qui tu connais.

Ce principe est en totale opposition avec les approches traditionnelles où les politiques de partage sont souvent définies par un ensemble potentiellement complexe de règles évaluées à la volée par un moniteur de référence opaque, pour accorder ou refuser l‘accès aux documents. En effet, nous ne croyons pas qu‘un individu lambda soit en mesure de comprendre le résultat d‘un solveur complexe prenant en entrée un ensemble potentiellement conflictuel de règles de partage positives ou négatives. Comme dit en introduction de ce chapitre, les approches traditionnelles peuvent ainsi contribuer à l‘opacité de la gestion du contrôle d‘accès des Cloud personnels, casser le principe d‘empowerment

de l‘utilisateur et finalement aboutir à l‘exact opposé du but recherché, c‘est-à-dire pousser les utilisateurs à définir des politiques de partage trop permissives ou les amener à déléguer le contrôle de leur plateforme à un tiers.

L‘hypothèse de confiance faite par SWYSWYK peut être résumée de la façon suivante :

n’accordez pas une confiance aveugle dans les règles de partage, mais faites confiance à votre moniteur de référence pour examiner et ajuster les permissions produites, et les appliquer correctement.

La logique du contrôle d‘accès de SWYSWYK appliquée par le moniteur de référence se veut donc triviale et peut être comprise par n‘importe qui : l‘opération a sur d est accordée à

s si et seulement si (s,d,a)  ACL. Dit autrement, une demande d‘accès n‘est accordée que si elle apparaît explicitement dans les permissions. Cette logique contribue à la propriété d‘empowerment éclairé et permet au propriétaire de garder la maîtrise de sa politique de partage.

Les règles de partage ne peuvent être considérées comme totalement de confiance, car elles peuvent typiquement être fournies par des tiers (une entreprise, une association, des développeurs indépendants, etc) via des applications. La confiance accordée dans ces tiers est variable, et la qualité et l‘honnêteté des règles également. Il est donc nécessaire de contrôler la production de ces règles, c'est-à-dire les permissions, potentiellement suspectes. Dans SWYSWYK, cela est réalisé via une phase de validation utilisateur et un

63 processus d‘assainissement sur les ACL. A noter que cela ne compromet pas la solidité du modèle de partage du Cloud personnel. En effet, le modèle reste cohérent par construction (la décision est unique), complet (la décision existe toujours) et peut être évalué dans un

temps logarithmique sur les ACL matérialisées. Ces trois principes étant généralement considérés comme les fondamentaux nécessaires pour tout modèle de contrôle d‘accès [Bertino 2005].

Le point sensible du paradigme de SWYSWYK réside ainsi dans la détection et la validation des ACL suspectes. Le processus global de validation des ACL est le suivant, résumé par la Figure 5 :

1. La politique de partage est traduite en un ensemble d‘ACL dites candidates, appelées ACL^*.

2. Depuis ACL^*, les ACL suspectées de ne pas respecter la politique de vie privée du propriétaire sont détectées et placées en quarantaine dans un ensemble appelé

ACL^?. Elles sont alors dans l‘attente d‘une validation manuelle du propriétaire. Les ACL non suspectes sont placées dans un ensemble appelé ACL⁺, l‘unique ensemble pris en considération par le moniteur de référence pour accorder les accès aux documents. Aucune ACL suspecte n‘est donc prise en compte dans l‘évaluation du contrôle d‘accès.

3. Le propriétaire assainit ACL^?, l‘ensemble des ACL suspectes, au cas par cas. Pour cela, il tire parti de la propriété de visualisation de SWYSWYK, en vérifiant quel document pourrait être partagé avec qui. Pour chaque ACL suspecte, il décide soit de la valider s‘il la considère légitime, soit de la refuser. L‘ACL est alors déplacée dans

ACL⁺ pour le premier cas et dans ACL^- pour le second. La matérialisation des ACL

-permet d‘éviter de stocker dans ACL^? des ACL dont la décision a déjà été prise par le passé, et ainsi éviter une vérification superflue du propriétaire. Cela lui permet également de se rétracter et de revalider une permission précédemment refusée. Nous proposons deux mécanismes pour détecter automatiquement les ACL suspectes et remplir ACL^? depuis le contenu d‘ACL^*. Le premier mécanisme se repose sur un processus de recommandation, appelé Advisor. Il identifie les éléments d‘ACL^* qui sont contradictoires avec des décisions passées, c'est-à-dire similaires à des ACL précédemment classées dans

64 politique de partage relativement stable et cohérente au cours du temps, comme cela est montré par [Roth 2010] et [De Choudhury 2010] .

Figure 5. Production des ACL.

Le deuxième mécanisme permet au propriétaire de définir des garde-fous, appelés

watchdog triggers, qui font ressortir des ACL sur lesquelles une attention particulière doit être portée, du fait de la sensibilité des sujets et/ou des documents impliqués. Dit autrement, ces triggers permettent de désigner des documents, sujets ou association des deux comme étant sensibles et de les placer préventivement dans ACL^?.

Advisor et les watchdog triggers sont complémentaires et permettent au propriétaire d‘assainir ses ACL. Nous détaillons ces deux mécanismes ci-dessous.

ACL

Policy

Translator

Admin. console

ACL

ACL

ACL

65