modèles de contrôle d’accès application à xml · 2003. 6. 11. · a.gabillon 13 modèles...
TRANSCRIPT
-
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
Modèles de contrôle d’accès
• Les sujets: entités actives– Utilisateurs
- Ordinateurs
- Processus
• Les objets: entités passives – Données
– Programmes
-
A.Gabillon 6
Modèles de contrôle d’accès
• Les actions– Lecture
- Ecriture
- Exécution
- Création
- Suppression
-
A.Gabillon 7
Modèles de contrôle d’accès
• 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
Modèles de contrôle d’accès
• 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
Modèles Discrétionnaires
• 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
Modèles Discrétionnaires
• 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
Modèles Obligatoires
• 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
Modèles Obligatoires
S
ProcessS
P
S
Read Write
P
Read
-
A.Gabillon 15
Modèles Obligatoires
• 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
Modèles Obligatoires
• 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
Modèles à base de rôles
• 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
Modèles à base de rôles
• 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
Définition du règlement de sécurité
• 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
Définition du règlement de sécurité
• 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
Définition du règlement de sécurité
• 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
Définition du règlement de sécurité
• 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
Définition du règlement de sécurité
• 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
Définition du règlement de sécurité
• 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
Définition du règlement de sécurité
• 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
Définition du règlement de sécurité
• 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églementation médicale
• 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
Réglementation médicale
• 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
Réglementation médicale
• Création des Rôles– CREATE ROLE Medecin;
– CREATE ROLE Infirmiere;
– CREATE ROLE Secretaire;
– CREATE ROLE Malade;
-
A.Gabillon 39
Réglementation médicale
• 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
Réglementation médicale
• 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
Réglementation médicale
• 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
Réglementation obligatoire
• 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
Réglementation obligatoire
• Table PubliqueUNCLASSIFIED_AIRCRAFT
2000 Km2000 Km
Mach 2.5Mach 2Mach 2.5
SupersonicSupersonicSupersonic
F16MirageRaffale
RangeSpeedTypeName
-
A.Gabillon 45
Réglementation obligatoire
• Table PubliqueUNCLASSIFIED_AIRCRAFT
• RESTRICTED signifie niveau d’habilitation insuffisant pour connaître la valeur
2000 Km2000 Km
RESTRICTED
Mach 2.5Mach 2Mach 2.5
SupersonicSupersonicSupersonic
F16MirageRaffale
RangeSpeedTypeName
-
A.Gabillon 46
Réglementation obligatoire
• Table ConfidentielleCONFIDENTIAL_AIRCRAFT
2000 Km2000 Km4000 Km6000 Km
Mach 2.5Mach 2Mach 2.5
SupersonicSupersonicSupersonic
F16MirageRaffaleFirefox
RangeSpeedTypeName
-
A.Gabillon 47
Réglementation obligatoire
• 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
F16MirageRaffaleFirefox
RangeSpeedTypeName
-
A.Gabillon 48
Réglementation obligatoire
• Table SecrèteSECRET_AIRCRAFT
NONOYESYES
2000 Km2000 Km4000 Km6000 Km
Mach 2.5Mach 2Mach 2.5Mach 6
SupersonicSupersonicSupersonicHypersonic
F16MirageRaffaleFirefox
Nuclear_bombRangeSpeedTypeName
-
A.Gabillon 49
Réglementation obligatoire
• 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églementation obligatoire
• 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églementation obligatoire
• 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
Règles d’autorisation
• 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
Règles d’autorisation
-
A.Gabillon 60
Règles d’autorisation
-
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
Implantation du modèle
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
Implantation du modèle
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é