Concepts pour le contrôle de flux

Présentation au sujet: "Concepts pour le contrôle de flux"— Transcription de la présentation:

1 Concepts pour le contrôle de flux
INF 6153

2 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: INF 6153

3 Concepts DE BASE INF 6153

4 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

5 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

6 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

7 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

8 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

9 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

10 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

11 = 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

12 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

13 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

14 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

15 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

16 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

17 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

18 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

19 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

20 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

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

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

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

24 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

25 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

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

27 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

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

29 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

30 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

31 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

32 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

33 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

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

35 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)

36 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

37 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: INF 6153

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

39 É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

40 É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

41 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

42 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

43 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

44 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

45 Changements d’étiquettes DANS MAC
INF 6153

46 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

47 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

48 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

49 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

50 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

51 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

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

53 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

54 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

55 CW: Supposons l’état initial suivant
INF 6153

56 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

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

58 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!

59 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

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

61 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

62 É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

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

64 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

65 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

66 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 entités Sans considérer les complexités qui pourraient être créées par des hiérarchies de rôles complexes INF 6153

67 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

68 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

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

70 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

71 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

72 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

73 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

74 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

75 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