Concepts pour le contrôle de flux http://w3.uqo.ca/luigi/INF6153/index.html INF 6153

Motivation Ce chapitre présente une théorie schématique des concepts de contrôle de flux, développée par votre enseignant Cette théorie devrait vous aider à mieux comprendre la théorie traditionnelle, qui sera présentée dans les autres chapitres Nous reviendrons à ce chapitre périodiquement Ces diapos sont en première version, donc toute suggestion d’améliorations sera appréciés Pour plus d’informations sur cette théorie: http://www.site.uottawa.ca/~luigi/papers/17_FPS.pdf INF 6153

Concepts DE BASE INF 6153

Pourquoi Étant donné un ensemble de sujets et objets qui peuvent lire et écrire les uns sur les autre, où peuvent aboutir les données A x x B Le sujet B, peut-il arriver à connaître les données de A? question importante pour la confidentialité INF 6153

Réponse: O A x x B Le sujet B, peut-il arriver à connaître les données de A? OUI, car A peut écrire sur O et B peut lire de O, ceci crée un flux transitif de A à B. INF 6153

Pour l’intégrité Pour l’intégrité, les questions sont semblables: L’objet O peut-il arriver à stocker une information provenant d’un autre objet O’? L’objet O peut-il arriver à stocker une information provenant d’un sujet S? INF 6153

Entités et Flux de données Pour simplifier le traitement, nous oublierons pour l’instant la distinction entre sujets et object Nous parlerons simplement de ‘entités’, qui peuvent être sujets ou objets Nous utiliserons aussi une relation générique ‘CanFlow’ ou CF Nous écrivons CF(e,e’) si des données peuvent être transférées de e à e’, c.-a.-d. e est un sujet et e’ est un objet et e a la permission d’écrire dans e’ ou e’ est un sujet et e est un objet et e’ a la permission de lire de e INF 6153

Rappel de la théorie des relations Relation réflexive: Pour tout x, R(x,x) Relation symétrique: R(x,y) ssi R(y,x) Relation transitive: Si R(x,y) et R(y,z) alors R(x,z) Une relation réflexive, symétrique et transitive est une relation d’équivalence Une relation réflexive, transitive et anti-symétrique est un ordre partiel Anti-symétrique: il n’existe pas de x,y pour lesquels: R(x,y) et R(y,x) INF 6153

Exemple d’ordre partiel et non Attention: pour clarté du diagramme, les arcs de réflexivité et transitivité sons souvent omis B A B A C C D D INF 6153

Compression d’entités équivalentes Après avoir constaté que A, C et D sont équivalentes du point de vue de la relation CF, nous les compressons dans une et nous obtenons un ordre partiel B A B A’ C D INF 6153

= Détail: transitivité B A B = C C D D Noter que par transivité si on ajoute un flux DA on ajoute aussi un flux BA, aussi des autres flux deviennent bi-directionnels INF 6153

Relation CanFlow (CF) entre entités (Toujours) Réflexive: Pour toute entité e, CF(e,e) (Toujours) Transitive: Si e, e’, e’’ sont des entités. Alors: CanFlow(e,e’) et CanFlow(e’,e’’) implique CanFlow(e,e’’) (Possible) Peut être simétrique s’il y a des e, e’ tels que: CF(e,e’) et CF(e’,e) par lectures-écritures directes ou par transitivité Donc une relation CanFlow, est-elle nécessairement un ordre partiel? INF 6153

Transitivité et hypothèse pessimiste À noter que la transitivité de CF est basée sur des hypothèses pessimistes: Quand une entité est autorisée à lire d’une autre, elle peut tout lire Quand une entité est autorisée à écrire sur une autre, elle peut tout écrire Une fois qu’un transfert de données a été effectué, les données restent à la destination à jamais Ce pessimisme est justifié, mais pas strictement nécessaire dans la sécurité INF 6153

Réprésentation de CF par digraphes Digraphes: graphes dirigés  Les nœuds sont des entités: sujets ou objets Une flèche  représente une relation CanFlow Un diagramme montrant les permissions de contrôle d’accès dans une organisation. Pourrait montrer un réseau social, un réseau dans l’internet des objets, etc … Exemple adapté du livre: J. Bang-Jensen, G.Z. Gutin. Digraphs. Theory, algorithms and applications, Springer, 2010, p. 17 and Fig. 1.12 INF 6153

Question préliminaire et intuitive Dans ce réseau il y a des entités qui, par leurs connexions, peuvent arriver à savoir tout: trouvez-les intuitivement. INF 6153

Propriétés de la relation représentée dans ce digraphe Cette relation est transitive et réflexive par notre hypothèse. Mais pour clarté de dessin: Nous avons inclus seulement les flux immédiats, pas les flux vrais par transitivité (exercice: trouvez-les) Nous n’avons pas représenté les autorisations qui sont supposées exister entre une entité et soi-même (réfléxivité) Cette relation n’est pas anti-symetrique P.ex. étant donné la transitivité, toutes les entités dans l’ensemble {F,A,B.H} sont mutuellement reliées par la relation CanFlow Donc cette relation n’est pas un ordre partiel INF 6153

Composantes maximales fortement connexes Sous-graphes maximaux dans lesquels toutes les entités sont équivalents par rapport à la relation CF Elles peuvent toutes obtenir les mêmes données! {A,B} {F,G,H,I} {C,D,E} {J.K} {L,M,N} INF 6153

Construction pour obtenir un ordre partiel Étant donné un digraphe réflexif et transitif, compresser à un seul nœud toutes les composantes maximales fortement connexes Pas un ordre partiel à cause de la présence de symétries - immédiatement visibles et - par transitivité Ordre partiel! INF 6153

Preuve de cette construction Si le digraphe résultant n’était pas un ordre partiel, il devrait contenir des symétries résiduelles C.-à-d. des composantes qu’on n’aurait pas réduit à un seul nœud! INF 6153

Autre manière de comprendre Le graphe original avait des relations symétriques Ces relations symétriques ont été encapsulées dans des composantes, donc dans un seul nœud. INF 6153

Réorganiser le digraphe donné selon l’ordre partiel INF 6153

Reformulation du résultat Un digraphe pour une relation réflexive et transitive est un ordre partiel de composantes [fortement connexes] INF 6153

Pour la confidentialité Dans un graphe comme le suivant, où pourrions-nous mettre les informations les plus confidentielles? INF 6153

Pour la confidentialité Dans un graphe comme le suivant, où pourrions-nous mettre les informations les plus confidentielles? Évidemment dans les entités les plus grandes dans l’ordre partiel, car les plus haut les informations sont, le moins elles peuvent se déplacer! INF 6153

Où les données peuvent arriver Supposant que chaque entité contienne des données, où peuvent arriver ces données? Intéressant que les composantes les plus secrètes sont aussi celles qui peuvent contenir le plus de données! A,B C,E,D,J.K, F,G,H,I M,N,L A,B, C,E,D F,G,H,I C,E,DJ.K A,B C,E,D Diagramme de flux (flux refl. et transitifs impliqués) INF 6153

Un exemple aves sujets et objets: nous découvrirons son modèle à niveaux INF 6153

Même graphe, mais l’ordre partiel de composantes est explicité Développé Même graphe, mais l’ordre partiel de composantes est explicité Digraphe donné INF 6153

Les données, où peuvent-elles finir? Ordre partiel avec le contenu possible des différents niveaux INF 6153

Pratique! Étant donné un ensemble fixe de sujets et objets Et étant donné un ensemble fixe de permissions de lecture et écriture entre eux Il existe des algorithmes efficaces pour calculer l’ordre partiel impliqué Surtout breadth-first search (efficacité polynomiale) Pratique au moins jusqu’à quelques dizaines de milliers de sujets et objets Travail de doctorat de A. Stambouli INF 6153

Sujet de recherche (pour les intéressés) Ceci fonctionne bien si le graphe de flux est fixe Mais en pratique, ces graphes sont dynamiques P.ex. le flux de données peut changer d’heure à heure… Ou en général selon des conditions Booléennes Comment créer des systèmes qui sont tolérants à certains changements INF 6153

Les diagrammes de Hasse Pour votre culture: Quelques-uns des diagrammes que nous avons utilisés sont appelés ‘diagrammes de Hasse’ Ils sont des représentations visuelles de relations d’ordre Voir les informations disponibles dans la Toile INF 6153

Maintenant, le problème inverse Étant donné un problème en termes d’exigences de confidentialité Trouver un système de contrôle d’accès qui implémente les exigences L’exemple suivant pourrait être à implémenter dans l’infonuagique, entre autres INF 6153

Des exigences de flux de données We have two banks in conflict of interest, Bank1 and Bank 2. Bank1 has only one category of data, called B1. Bank 2 has public data labelled B2P that can be available to anyone, and secret data B2S that should be available only to its own employees. A Company 1 is controlled by Bank 2 and shares all its data C1 with Bank 2. Bank 2 does not want its secret data B2S to be known to Company 1. Les flux décrits: B2S B1 C1 B2P INF 6153

Obtenir le diagramme de flux correspondant B2S B1 C1 B2P INF 6153

Un réseau organisationnel correspondant Nous pouvons affecter des sujets et des objets aux différentes composantes Bank2 Secret Company 1 Bank1 Bank2 Public Étant donné le diagramme de flux à droite, il est facile de construire des matrices de contrôle d’accès ou un système RBAC (entre autres) qui le réalise À noter que nous avons omis, pour simplifier, les relations transitives (p.ex. AliceBk2)

Problème de recherche Développer une méthode pour construire les diagrammes de flux et les réseaux organisationnels à partir d’exemples d’exigences C.-à-d. rendre systématique le procédé que nous venons de voir INF 6153

Conclusion Tout flux de données qui peut être représenté comme digraphe Réalise un ordre partiel de composantes Ce dernier peut être trouvé avec des algorithmes efficaces Étant donné des exigences de sécurité qui peuvent être exprimés par un ordre partiel, il est possible de créer une structure organisationnelle correspondante Un article qui traite de ce sujet: http://www.site.uottawa.ca/~luigi/papers/17_FPS.pdf INF 6153

MODÈLES MAC Mandatory Access Control, Contrôle d’accès obligatoire INF 6153

Étiquettes Les modèles MAC sont caractérisés par le fait que les permissions sont basées sur une classifications de données, sujets et objets sur la base suivante: Les sujets sont classifiés sur la base des données qu’ils peuvent connaître S:{Secret,VW} est un sujet qui est autorisé à savoir seulement des données secrètes pertinentes à VW Les objets sont classifiés sur la base des données qu’ils peuvent contenir O:{Secret,VW} est un objet qui est autorisé à contenir seulement des données secrètes pertinentes à VW Les ensembles {…} sont appelés ‘étiquettes’, Elles décrivent les types des données et ce que les sujets peuvent savoir ou les objets peuvent contenir INF 6153

Étiquettes de sujets et objets s≤o ssi l’étiquette du sujet s est incluse dans l’étiquette de l’objet o: Tout ce que s peut savoir peut être stocké dans o o≤s ssi l’étiquette de l’objet o est incluse dans l’étiquette du sujet s: Tout ce que o peut stocker peut être connu par s P.ex.si s:{Secret,Vw} et o:{Secret,VW,Toyota} alors s≤o Si s≤o nous disons que ‘o domine s’ ou ‘o dom s’ Etc. pour les autres cas INF 6153

Règles pour les connaissances et le stockage Le contenu d’un objet peut être connu par un sujet ssi CK(s,o) ssi o≤s Ce qu’un sujet peut savoir peut être contenu dans un objet ssi CS(o,s) ssi s≤o P.ex. si O:{Secret,Vw} il peut être connu par un sujet S:{Secret,Vw,Toyota}, mais pas par un sujet S:{Secret} INF 6153

Règles pour le flux de données En général, on peut permettre un flux entre deux entités ssi l’entité d’origine est incluse dans l’entité de destination Nous considérons deux flux: CR (CanRead) CW(CanWrite) Exemples: Si O:{Secret,Vw} et S:{Secret,Vw,Toyota} Alors CR(S,O) mais pas CW(S,O) Dans le deuxième cas, O pourrait arriver à stocker des données de Toyota contrairement à son étiquette INF 6153

Revenant à l’exemple précédent Nous avons déjà introduit ces concepts dans l’exemple précédent: Observer comment les autorisations de lecture et écriture sont conformes aux règles CR, CW INF 6153

Conflit d’intérêt et étiquettes inadmissibles Nous avons aussi déjà introduit les conflits d’intérêt dans le concept d’étiquette inadmissible P.ex. toute étiquette contenant à la fois B1 et B2S est inadmissible car Aucun sujet ne peut connaître à la fois les données de B1 et B2S Aucun objet ne peut stocker à la fois les données de B1 et B2S INF 6153

Changements d’étiquettes DANS MAC INF 6153

Haute ligne de crue (high water mark) Supposons que d’une manière quelconque un sujet a acquis des données au delà des ses autorisations Étant donné qu’il connaît maintenant plus de choses, il faut augmenter son étiquette au point où il est arrivé à savoir Dont le terme ‘haute ligne de crue’ Aussi: Supposons qu’il y a raison de permettre à un sujet d’augmenter ses autorisations Il faut donc lui donner une étiquette qui est plus grande Pareillement pour les objets Ces changements sont normalement faits par les administrateurs du système INF 6153

Exemple 1 Au début, aucun sujet ne sait rien, des objets stockent des informations Carl:{} Patients: {S,C,P} Alice:{} Prescriptions: {C,P} Bob:{} Drugs: {P} INF 6153

Suite Exemple Alice demande de lire de Prescriptions, et sa demande est acceptée Son étiquette est changée Perd le droit d’écrire sur Drugs mais maintenant peut lire de Drugs Carl:{} Patients: {S,C,P} Alice:{C,P} Prescriptions: {C,P} Bob:{} Drugs: {P} INF 6153

Suite … Bob demande de lire de Drugs, ses autres droits ne changent pas Carl:{} Patients: {S,C,P} Alice:{C,P} Prescriptions: {C,P} Bob:{P} Drugs: {P} INF 6153

Etc: Modèle Bell-LaPadula Continuant comme ça, nous pouvons arriver à un modèle BLP complet: Carl:{S,C,P} Patients: {S,C,P} Alice:{C,P} Prescriptions: {C,P} Bob:{P} Drugs: {P} INF 6153

Changement des étiquettes pour les objets Pareillement, si un sujet d’haute autorisation veut devenir capable d’écrire sur un objet de basse autorisation, il doit demander à l’administrateur de hausser l’étiquette de l’objet car l’objet pourra dorénavant contenir des données de nouveau type INF 6153

Mais encore …. (exercice) Mais continuant à ajouter des autorisations comme ça, nous pourrions continuer jusqu’à quel point? INF 6153

Modèle de la Muraille de Chine Le modèle de la Muraille de Chine a le but d’éviter que un sujet ou objet, acquérant de plus en plus de données, arrive à acquérir des données en conflit INF 6153

Les Banques 1 et 2 sont en conflit d’intérêt Banque 1 est alliée avec les compagnies Co1 et Co2 Banque 2 est alliée seulement avec Co2 Banque 2 est en conflit d’intérêt avec Co1 INF 6153

CW: Supposons l’état initial suivant INF 6153

Alice lit par authorisation de Co2 Alice:{B1,C2} Bob:{B2} Bank1:{B1} Co1:{C1} Co2:{C2} Bank2:{B2} Bank1 no longer dominates Alice and Alice can no longer write on it

Alice écrit par autorisation sur Bank1 Alice:{B1,C2} Bob:{B2} Bank1:{B1,C2} Co1:{C1} Co2:{C2} Bank2:{B2}

Dynamic CW Bob écrit par aut sur Co2 Alice:{B1,C2} Bob:{B2} Bank1:{B1,C2} Co1:{C1} Co2:{C2,B2} Bank2:{B2} Alice can no longer read from Co2, nor write on it! But CanKnow Co2 data!

Alice écrit par aut sur Co1 Alice:{B1,C2} Bob:{B2} Bank1:{B1,C2} Co1:{C1, B1,C2} Co2:{C2,B2} Bank2:{B2} INF 6153

Alice lit par aut de Co1 Alice:{C1,B1,C2} Bob:{B2} Bank1:{B1,C2} Co1:{C1, B1,C2} Co2:{C2,B2} Bank2:{B2}

Bob lit par aut de Co2 Alice:{C1,B1,C2} Bob:{C2,B2} Bank1:{C1,B1,C2} Co1:{C1, B1,C2} Co2:{C2,B2} Bank2:{C2,B2} Final state No other auth are possible since any new ones would generate labels containing both B1 and B2

État final rédessiné Co2:{B1,C1,C2} Co1:{B2,C2} Bob:{B2,C2} Alice:{B1,C1, C2} Bob:{B2,C2} Bank1:{B1,C1,C2} Bank2:{B2.C2} Alice has R from Co2 and Bob from Co1. The arrows become bidirectional, and there are no other possibilities. The boxes involving C1 are not connected, because at one point Alice was able to read from Co1 so it could have obtained info from there

Contrôle de flux de Données dans RBAC INF 6153

Le problème Dans le contrôle de flux des données, on se préoccupe des effets des permissions de lecture-écriture et d’ « où peuvent finir les données » RBAC est une méthode d’accès très générale, qui s’applique à permissions de tout type Cependant, si on considère le contrôle de flux, on peut facilement voir que RBAC, contrairement à MAC, n’a aucun mécanisme pour identifier et empêcher les flux non-désirables INF 6153

Comment les données peuvent s’enfuir avec RBAC (une de plusieurs manières) Supposez que vos données sont dans O1 Supposez que Alice a un rôle de haute sécurité dans une organisation Pensez-vous que vos données sont bien protégées car elles peuvent être lues par Alice seulement?! Par son rôle, Alice peut: Lire de O1 Écrire sur O2 Par son rôle, Bob a la permission de lire de O2 Alors Bob pourrait lire indirectement les données dans O1 (hypothèse pessimiste) Etc. Alice:R1 Bob: R2 Carl: R3 … O1 O2 O3

Application à RBAC Pour appliquer ces idées à RBAC, nous n’avons qu’à rédéfinir CanWrite and CanRead: CanWrite(S,O)= R ∈ Roles(S) ((O, write) ∈ Perm(R)) CanRead(S,O)=  R ∈ Roles(S) ((O, read) ∈ Perm(R)) Donc étant donné: CanStore(O,x), nous pouvons arriver à une des conclusions: CanKnow(S,x) or ¬CanKnow(S,x) Évidemment ceci présuppose qu’on connaisse tout le réseau En effet, cette analyse est pratique pour des réseaux de plus de 100 000 entités Sans considérer les complexités qui pourraient être créées par des hiérarchies de rôles complexes INF 6153

Exemple Étant donné les roles et permissions suivants: R1 = {(A,r),(B,w)} //Role 1 peut lire de objet a et écrire sur objet b R2 = {(A,r),(B,r)} R3 = {(C,w)} aussi R3 est rôle senior de R1 et R2 R4 = {(C,r)} Aplatir les rélations d’héritage R3 = {(C,w),(A,r),(B,w),(B,r)} INF 6153

Exemple Étant donné les roles et permissions suivants: R1 = {(A,r),(B,w)} //Role 1 peut lire de objet a et écrire sur objet b R2 = {(A,r),(B,r)} R3 = {(C,w),(A,r),(B,w),(B,r)} R4 = {(C,r)} R1 A R2 B R3 R4 C INF 6153

Réorganiser pour voir les niveaux C R1 A R2 B B R3 R3 R4 C INF 6153

Simplifier par elimination de transitivité (il n’y a pas de cycles à simplifier) Area of C B B Area of B R3 R3 Area of A INF 6153

Réprésentation du flux entre objets A,B,C A,B (Bk2P,r ) (Bk2P,r ) A Donc B peut stocker tout le contenu de A C peut stocker tout le contenu de A et B INF 6153

Réprésentation du flux entre rôles Donc un sujet de rôle R2 peut savoir tout ce que un sujet de rôle R1 sait Pareillement pour un sujet de rôle R3 Un sujet de rôle R4 peut savoir tout ce que les sujets de rôle R1 et R3 peuvent savoir Les rôles de confidentialité max sont R2, R4 R4 peut aussi arriver à savoir tout INF 6153

Sujets d’exercice ou de recherche Étant donné un système de protection quelconque, caractérisé par certaines permissions, pour un objet donné O, quels sont les sujets ou données desquels le contenu de O peut provenir, directement ou indirectement? Est-ce-que le système permet à un sujet X d’arriver à connaître des données Y? Si oui ou non, quelles sont les permissions à retirer ou ajouter si on veut rendre ceci impossible ou possible? Est-ce-que le système permet à un sujet X d’arriver à connaître tant les données d’un objet X que les données d’un objet Y? Est-ce-qu’un sujet X peut arriver à stocker ses données tant sur un objet A que sur un objet B? Si ceci devrait être empêché pour une contrainte d’entreprise, quelles permissions sont à retirer pour empêcher ceci? Étant donné certaines permissions, sont-elles compatibles avec ce qui permet un système MAC donné? Etc. etc. … INF 6153

Pour construire des systèmes RBAC avec certaines garanties de sécurité Revenons à l’exemple organisationnel dévéloppé précédemment Nous pouvons facilement dériver les permissions nécessaires: Alice:{(Bk2P,r),(Bk2P,w ) (Bk1,w),(Co1,w)} Bob: {(Bk1,r),(Bk1,w)} Carla:{(Bk2P,r ),(Co1,r), (Co1,w), (Bk2S,w)} Dave:{(Co1,r),(Bk2S,r),(Bk2S,w)} (nous n’avons pas inclus les flux transitifs, que nous avons considérés redondants mais pourraient être nécessaires en pratique) INF 6153

Ingéniérie de rôles Les permissions trouvées dans ce cas sont assez disjointes donc les possibilités de grouper les permissions dans rôles et les héritages entre rôles ne paraissent pas aider beaucoup La solution la plus simple est de donner à chaque sujet son propre rôle unique avec ses propres permissions: RBAC0 On pourrait cependant introduire des solutions plus ingénieuses, comme p.ex. créer pour Alice un rôle: Bk2PRead, avec permission (Bk2P,r) qui pourrait être défini comme rôle junior par rapport à des rôles semblables de Carla et Dave Etc. INF 6153