Modèles de Contrôle d’Accès Application à XML · 2003. 6. 11. · A.Gabillon 13 Modèles Obligatoires • Bell & LaPadula ont montré que les 2 règles suivantes étaient nécessaires

Modèles de Contrôle d’Modèles de Contrôle d’AccèsAccèsApplication à XMLApplication à XML

Alban GabillonLaboratoire Informatique de l’Université de Pau

IUT de Mont de MarsanEquipe CSySEC

http://csysec.univ-pau.fr

A.Gabillon 2

Plan

• Modèle de contrôle d’accès– Modèle discrétionnaire

– Modèle obligatoire

– Modèle à base de rôles

• Conception d’un modèle de contrôle d’accès

• Application à XML

• Futurs modèles

Modèles de contrôle d’accèsModèles de contrôle d’accès

A.Gabillon 4

Modèles de contrôle d’accès

• Un Modèle de contrôle d’accès inclut:– Des sujets

– Des objets

– Des actions

– Un règlement de sécurité

A.Gabillon 5


• Les sujets: entités actives– Utilisateurs

- Ordinateurs

- Processus

• Les objets: entités passives – Données

– Programmes

A.Gabillon 6


• Les actions– Lecture

- Ecriture

- Exécution

- Création

- Suppression

A.Gabillon 7


• Le règlement de sécurité– Ensemble de Permissions

• Ex: Le sujet s a la permission (droit, privilège) d’effectuer l’action a sur l’objet o

• Un système est sûr si et seulement si le règlement ne peut être violé– Toute opération effectuée doit être permise

A.Gabillon 8


• Implantation– Le plus souvent au moyen d’un noyau de sécurité

– Le noyau de sécurité contrôle les accès

A.Gabillon 9

Modèles Discrétionnaires

• Les plus anciens

• Règlement défini de façon discrétionnaire pour chaque utilisateur

• Le règlement de sécurité s’exprime sous la forme d’une matrice A.– A(s,o) correspond à l’ensemble des actions que s a la

permission de réaliser sur l’objet o

A.Gabillon 10


• Notion de droit propriétaire – Chaque objet a un propriétaire qui décide quels sont les

autres sujets qui ont accès à cet objet.

• Sujets peuvent être structurés en groupe– La structuration des sujets en groupes simplifie

l’expression de la politique de sécurité.

A.Gabillon 11


• Avantages – Modèles simples

– Souvent implantés (UNIX, SQL92 …)

• Inconvénients– Adaptés à des règlements de sécurité simples

– Vulnérables aux chevaux de Troie

– Problème de la fuite des droits

A.Gabillon 12

Modèles Obligatoires

• Appelés aussi modèles de sécurité multi-niveaux(sécurité militaire)

• Chaque sujet reçoit un niveau d’habilitation• Chaque objet reçoit un niveau de classification• Règlement de sécurité obligatoire

– Si l’habilitation d’un sujet est supérieure ou égale à la classification de l’objet alors ce sujet a la permission de prendre connaissance de l’information véhiculée par l’objet.

→ Objectif de confidentialité

A.Gabillon 13


• Bell & LaPadula ont montré que les 2 règles suivantes étaient nécessaires pour garantir le règlement de sécurité: – No Read Up: Si l’habilitation d’un sujet est supérieure

ou égale à la classification de l’objet alors ce sujet a la permission de lire l’information contenue dans l’objet.

– No Write Down: Si l’habilitation d’un sujet est inférieure ou égale à la classification de l’objet alors ce sujet a la permission de modifier l’information contenue dans l’objet.

A.Gabillon 14


S

ProcessS

P

S

Read Write

P

Read

A.Gabillon 15


• Les 2 règles du modèle de Bell & LaPadula sont mises en œuvre par des contrôles d’accès

• Ces 2 règles ne sont pas suffisantes pour garantir le règlement de sécurité multi-niveaux– Un utilisateur peut accéder à de l’information sensible

par le biais d’autres moyens que de simples opérations de lecture/écriture: canaux cachés

– Ex: Canaux d’inférence

A.Gabillon 16


• Avantages – Procurent un niveau de sécurité supérieur aux modèles

discrétionnaires

• Inconvénients– Assez rigides

– Limités à des usages militaires

A.Gabillon 17

Modèles à base de rôles

• Un rôle est une collection de droits

• Les droits sont assignés aux rôles

• Les rôles sont assignés aux utilisateurs

• Un utilisateur peut recevoir plusieurs rôles

• L’utilisateur choisit dans ses rôles celui (ou ceux) qu’il veut jouer– Les privilèges de l’utilisateurs sont les privilèges du

(des) rôle(s) qu’il a activé(s)

A.Gabillon 18


• Les rôles sont organisés hiérarchiquement

• Les rôles offrent une grande souplesse dans l’expression du règlement de sécurité

• Bien adaptés aux applications commerciales– 1 fonction professionnelle => 1 rôle

A.Gabillon 19


• Avantages– Plus puissants que les modèles discrétionnaires

– Plus polyvalents que les modèles multi-niveaux

– A la mode et de plus en plus implantés (SQL-ORACLE)

• Inconvénients– Niveau de sécurité des modèles discrétionnaires

– Nécessité de mettre en place une procédure d’administration des rôles

Conception d’un modèle de contrôle Conception d’un modèle de contrôle d’accèsd’accès

A.Gabillon 21

Identification des sujets

• Les sujets sont:– Utilisateurs

– Ordinateurs

– Processus

– Le système

• Les sujets sont les entités actives qui seront référencées dans le règlement de sécurité

A.Gabillon 22

Identification des objets

• Tâche parfois complexe

• Problème du niveau de granularité– SGBDR: tuple ? table ?

– SGBD à objets: objet ? Attribut ?

– SQL: Table

– UNIX: fichier

• Les objets sont les granules d’information qui seront référencés dans le règlement

A.Gabillon 23

Identifications des actions

• Recenser les actions de base qu’il est nécessaire de contrôler– SQL: SELECT, UPDATE, DELETE, INSERT, EXECUTE

– UNIX: READ, WRITE, EXECUTE

• Chacune de ces actions sera contrôlée par le noyau de sécurité

A.Gabillon 24

Définition du règlement de sécurité

• Identification des rôles

• Droits et devoirs des rôles

• Assignation des rôles aux utilisateurs

• Définition d’un méta règlement contraignant l’assignation et l’activation des rôles

A.Gabillon 25


• Identification des rôles– Identification des tâches/fonctions

– 1 tâche = 1 rôle

– Création d’une hiérarchie de rôles

médecin

cardiologue radiologue

A.Gabillon 26


• Droits et devoirs des rôles– Définition des règles d’autorisation

• Permissions

• [Interdictions]

• Obligations

– Ecriture du règlement à l’aide d’un langage formel

A.Gabillon 27


• Pourquoi des interdictions ?– Ce qui n’est pas permis est interdit

– Dans l’absolu on a pas besoin des interdictions mais:• On exprime en général des permissions génériques

• On a besoin des interdictions pour pouvoir tenir compte des exceptions.

– Ex: • Un patient a le droit de consulter son dossier médical

• Patricia Franck a l’interdiction de consulter son dossier

A.Gabillon 28


• Les obligations– Il n’est pas possible de mettre en place un contrôle

d’accès pour forcer un sujet à faire quelque chose sauf si:

• Le sujet est le système lui-même– Ex: Toute opération doit être journalisée

• L’obligation est une obligation de ne pas faire c’est-à-dire une interdiction

– Le concept d’obligation n’a de sens que dans le cadre d’une action provisionnelle

A.Gabillon 29


• Action provisionnelle– Une action provisionnelle est une action qui doit être

réalisée afin d’obtenir un privilège

– Ex:• Les utilisateurs doivent s’authentifier avant de pouvoir

accéder au système

• Un médecin doit mettre à jour le dossier médical d’un patient avant de pouvoir lui délivrer une ordonnance

A.Gabillon 30


• Conflits entre les règles– Les conflits entre les règles d’autorisation doivent être

gérées par une politique de résolution des conflits,• fondée sur des priorités

• fondée sur des principes du type le plus spécifique l’emporte

A.Gabillon 31


• Assignation des rôles– Un utilisateur peut recevoir plusieurs rôles

– Un utilisateur peut activer à un instant donné plusieurs de ses rôles

– L’assignation et l’activation des rôles peut néanmoins obéir à un méta règlement d’assignation et d’activation des rôles.

A.Gabillon 32


• Meta règlement– Il est possible de définir des rôles mutuellement

exclusifs– Le rôle A et le rôle B ne peuvent être assignés à un

même utilisateur• Séparation des tâches statique

– Un même utilisateur n’a pas le droit d’activer en même temps le rôle A et le rôle B

• Séparation des tâches dynamique

– Ex: Un même utilisateur ne peut autoriser un paiement et effectuer un paiement

A.Gabillon 33

Administration de la sécurité

• Le modèle doit prévoir qui a le droit d’administrer le règlement de sécurité– Un seul officier de sécurité

– Plusieurs administrateurs de sécurité• Modèle à base de rôles pour gérer les rôles

– Délégations possibles ou pas

A.Gabillon 34

Implantation du modèle

• Ex Nihilo– Module d’administration de la sécurité

• Module permettant de spécifier et interpréter le règlement

– Mécanismes de contrôles d’accès …

• Utilisation des primitives de sécurité de la couche inférieure

A.Gabillon 35

Réglementation médicale

• Patient

• Diagnostic

FM

6035

PatriciaMartin

FranckRobert

PfranckMrobert

SexeAgePrenomNomLogin

UlcerePneumonie

asthme

PfranckMrobertMrobert

MaladieLogin

A.Gabillon 36


• Règlement de sécurité– Les médecins ont la permission de consulter et modifier

les deux tables sans restriction

– Les secrétaires ont la permission de voir la table patient

– Les infirmières ont la permission de voir les deux tables

– Les patients ont la permission de voir les informations qui les concernent

A.Gabillon 37


• Sujets– Les médecins, les infirmières, les secrétaires et les

patients

• Objets– Les 2 tables

– Les tuples de chaque table

• Actions– SELECT, INSERT, UPDATE, DELETE

A.Gabillon 38


• Création des Rôles– CREATE ROLE Medecin;

– CREATE ROLE Infirmiere;

– CREATE ROLE Secretaire;

– CREATE ROLE Malade;

A.Gabillon 39


• Droits associés à chaque rôle– GRANT ALL ON Patient TO Medecin;

– GRANT ALL ON Diagnostic TO Medecin;

– GRANT SELECT ON Patient TO Infirmiere;

– GRANT SELECT ON Diagnostic TO Infirmiere;

– GRANT SELECT ON Patient TO Secrétaire;

• Problème pour la dernière règle car le niveau de granularité du modèle de sécurité de SQL est la table et non le tuple

A.Gabillon 40


• Création de 2 vues– CREATE VIEW Vpatient AS

SELECT * FROM Patient where Login=user;

– CREATE VIEW Vdiagnostic AS SELECT * FROM Diagnostic where Login=user;

– GRANT SELECT ON Vpatient to Malade;

– GRANT SELECT ON Vdiagnostic to Malade;

A.Gabillon 41


• Assignation des rôles aux utilisateurs– GRANT Medecin TO …

– GRANT Infirmiere TO …

– GRANT Secretaire TO …

– GRANT Malade TO pfranck;

– GRANT Malade TO mrobert;

A.Gabillon 42

Réglementation obligatoire

• Implantation d’un règlement multi-niveaux– Table multi-niveauxAIRCRAFT

– Niveau de granularité : valeur d’attribut• Données publiques• Données confidentielles• Données secrètes

NONOYESYES

2000 Km2000 Km4000 Km6000 Km

Mach 2.5Mach 2Mach 2.5Mach 6

SupersonicSupersonicSupersonicHypersonic

F16MirageRaffaleFirefox

Nuclear_bombRangeSpeedTypeName

A.Gabillon 43


• Décomposition en 3 tables mono-niveau– Tout ce qui est classifié Public se retrouve dans la

table publique, la table confidentielle et la table secrète

– Tout ce qui est classifié Confidentiel se retrouve dans la table confidentielle et la table secrète

– Tout ce qui est Secret se retrouve dans la table secrète

A.Gabillon 44


• Table PubliqueUNCLASSIFIED_AIRCRAFT

2000 Km2000 Km

Mach 2.5Mach 2Mach 2.5

SupersonicSupersonicSupersonic

F16MirageRaffale

RangeSpeedTypeName

A.Gabillon 45


• Table PubliqueUNCLASSIFIED_AIRCRAFT

• RESTRICTED signifie niveau d’habilitation insuffisant pour connaître la valeur

2000 Km2000 Km

RESTRICTED



F16MirageRaffale

RangeSpeedTypeName

A.Gabillon 46


• Table ConfidentielleCONFIDENTIAL_AIRCRAFT

2000 Km2000 Km4000 Km6000 Km




RangeSpeedTypeName

A.Gabillon 47


• Table ConfidentielleCONFIDENTIAL_AIRCRAFT

• La valeur de speed et de range pour le Firefoxsont des mensonges destinés à cacher l’existence de valeurs secrètes

2000 Km2000 Km4000 Km6000 Km

Mach 2.5Mach 2Mach 2.5Mach 2.5

SupersonicSupersonicSupersonicSupersonic


RangeSpeedTypeName

A.Gabillon 48


• Table SecrèteSECRET_AIRCRAFT

NONOYESYES

2000 Km2000 Km4000 Km6000 Km

Mach 2.5Mach 2Mach 2.5Mach 6

SupersonicSupersonicSupersonicHypersonic


Nuclear_bombRangeSpeedTypeName

A.Gabillon 49


• Implantation du règlement multi-niveaux– No Read-Up

– No Write-Down

• Idée: Créer un rôle Public, un rôle confidentiel et un rôle Secret– CREATE ROLE PUBLIC;

– CREATE ROLE CONFIDENTIEL;

– CREATE ROLE SECRET;

A.Gabillon 50


• Rôle Public– GRANT ALL ON UNCLASSIFIED_AIRCRAFT TO

PUBLIC;

• Rôle Confidentiel– GRANT SELECT ON UNCLASSIFIED_AIRCRAFT TO

CONFIDENTIEL;

– GRANT ALL ON CONFIDENTIAL_AIRCRAFT TO CONFIDENTIEL;

A.Gabillon 51


• Rôle Secret– GRANT SELECT ON UNCLASSIFIED_AIRCRAFT TO

SECRET;

– GRANT SELECT ON CONFIDENTIAL_AIRCRAFT TO SECRET;

– GRANT ALL ON SECRET_AIRCRAFT TO SECRET;

• Mécanismes de réplication d’un niveau bas vers un niveau haut assurés par des TRIGGERS

Modèle de contrôle d’accès pour Modèle de contrôle d’accès pour XMLXML

A.Gabillon 53

Document XML

A.Gabillon 54

Document XML

• XML est devenu un standard pour structurer l’information sur Internet

• Les serveurs WEB actuels ont des mécanismes de contrôle d’accès au niveau du fichier

• Un document XML peut contenir des données de sensibilités variées

• Besoin d’un modèle de contrôle d’accès qui permette d’adresser des parties de document XML

A.Gabillon 55

Document XML

• Arbre XPath

Text()Martin Robert

/name

Text()Pneumonia

/item

/diagnosis @id="mrobert"

/record

...

/record

/database

A.Gabillon 56

Identification des objets et actions

• Objet = nœud d’un arbre XPath– Chaque nœud peut faire l’objet d’un règlement de

sécurité

• Action = READ– Extension en cours: INSERT, DELETE, UPDATE

A.Gabillon 57

Règles d’autorisation

• Une règle d’autorisation est un tuple de la forme

– set-of-subjects est un ensemble de sujets– set-of-objects est un ensemble de noeuds– access est GRANT ou DENY– priority est optionnel et sert à assigner une priorité à

la règle (priorité par défaut = 0)

A.Gabillon 58


• La sémantique d’une règle d’autorisation est unique quel que soit le type de noeud protégé(élément, attribut, texte)– Si l’accès au noeud n est accordé à l’utilisateur u

alors u a la permission de voir tout le sous arbre dont n est la racine

– Si l’accès au noeud n est refusé à l’utilisateur u alors u a l’interdiction de voir tout le sous arbre dont n est la racine

A.Gabillon 59


A.Gabillon 60


A.Gabillon 61

Résolution des conflits

• Il y a un conflit entre une permission et une interdiction pour un noeud n et un utilisateur u si u appartient aux deux set-of-subjects et nappartient aux deux set-of-objects

• La politique de résolution des conflits est fondée sur les priorités

A.Gabillon 62


xas2xsl.XSL

Doc.XSLDoc.XASXSLT

processorXMLparser

Apache Web Server

Servlet engine (Tomcat)

Cocoon

Step 1 : XAS to XSLT

Doc.XML

View.XML

Subjects.XSSUser_id Doc.XSL

XSLTprocessor

XMLparser

Apache Web Server

Servlet engine (Tomcat)

Cocoon

Step 2 : Document to View

A.Gabillon 63


http://wwwmdm.univ-pau.fr:8081/XML_security

Internet

http://www. www.your.site.org

Your_doc.xmlYour_doc.xasYour_doc.xss

https://www.your.site.org/Your_doc.xml

A.Gabillon 64

Futurs modèles

• Modèles qui prennent en compte les obligations

• Modèles qui permettent l’écriture de permissions contextuelles– Temps– Urgence

• Modèles qui supportent des organisations distribuées mettant en oeuvre plusieurs règlements de sécurité

Documents

Modèles de Contrôle d’Accès Application à XML · 2003. 6. 11. · A.Gabillon 13 Modèles Obligatoires • Bell & LaPadula ont montré que les 2 règles suivantes étaient nécessaires