Outline I- Introduction II- Definitions

Outline I- Introduction II- Definitions
III- Common vulnerabilities and threats IV- Authentication V- Access control

V- Access control Definitions
Concepts for Access Control Subjects = active entities in the IS Users, user processes, threads Objects = passive entities in the IS Contain information under protection (files, relation in a relational database, directory, memory cell…) Operations = allow the subject to act on objects Reading of a file, deletion of a directory, request in a database A subject has permissions to carry out operations on objects Carries out Acts on Un sujet peut être un objet dans une requête donnée. Permet de distinguer entre rôle actif/passif. On peut spécifier : - soit ce ce qui peut être fait avec un objet (point de vue OS où l’on manipule des fichiers) - soit ce que peux faire un sujet (point de vue gestion de base de données où l’on offre un service à l’utilisateur) Subject Operation Object

V- Access control Definitions
Generic access control models [Lampson, 74] « Reference Monitor » : Decision procedure that filters the acces request Enforces an access control policy Access denied Reference Monitor Operation (acces request) Subject Object Identification/Authentication Authorization

V- Access control Access control paradigms
Mandatory Access Control (MAC) The system decides to accept or deny an access request to an object, and a subject cannot modify this decision Based on rules describing the conditions to accept an access request Example : Multi-level security models Subjects Objects Authorized read access Subject 1 “Top Secret” Server 1 “Top Secret” Subject 2 “Top Secret” Top Secret > Secret > Confidential Un sujet possède des permissions (droits) de réaliser des actions sur des objets Un sujet peut transmettre des droits à un autre sujet pour les objets qu’il possède. Un utilisateur peut définir son propre règlement de sécurité Server 2 “Secret” Subject 3 “Confidential” Subject 4 “Confidential” Serveur 3 “Confidential” Rule: a subject can read an object if its security level is greater than the security level of the object

Discretionary Access Control (DAC) A subject can decide to accept or deny an access request to an object that he owns Access permissions are defined, deleted, modified, or handed over at the discretion of the owner of the object Based on the identity of the subject requesting the access and on access permissions defined on objects The organization delegate a part of its rights to each user (the way according to which a user delegates his rights may be controlled) Example : Access control to files and directories in Unix Subjects Objects r, w, x s1 File 1: owner s1 rwx I --- I --- Group 1 r, w s2 r, w r File 2: owner s2 rw- I rw- I r-- Group 2 s3

DAC: context of application Do not satisfy the least privilege principle: a user may give more permissions than necessary A permission on an object may be handed over without its owner knowing: A gives a read right on one of its files to B, B copies this file, B being the owner of this copy can hand over his read right to C A must trust B Trust is not always enough: A owns a sensitive file f, B has no permission to read it B implements a Trojan, and succeeds in persuading A to execute it When A execute the Trojan, it runs with A’s permissions, and is able to copy f Not suited to environment dealing with very sensitive information

MAC: context of application Objective: Control the information flow without trusting the environment Ensure a partitioning between different kind of information Principles: Based on the content of the information, i.e. its sensitivity A sensitivity level (label) is attached to each object A subject must obtain a mandate (authorization) to access to a sensitive information These mandates are distributed by the organization In practical: Most widespread model: multi-level security in the military domain Bell LaPadula model

Role Based Access Control (RBAC) Access to an object is accepted or denied depending on the role of the subject Example: a role of a subject corresponds to its function in an organization May be implemented as a set of privilege Subjects Roles Operations Role 1 Role 2 Role 3 Op 1 Op 2 Les sujets changent fréquemment mais pas les rôles. Op 3

V- Access control Access operations
Access modes Observation: examine the content of an object Alteration: modify the content of an object Access permission (right, attribute) Example: permissions in Bell-LaPadula model exec (e) write (w) read (r) append (a) observe x x x x alter

V- Access control Access operations
Access permission in Multics Permissions are different depending on the system and on the objects Access permission in Unix Access permission in Windows 2000 Full Control, Modify, Read & Execute, Read, and Write + Special permissions File permissions Directory permissions read status execute modify read & write append write search Effect on file Effect on directory r read list content w write create or rename a file Unix : Fichier : read = lecture, … Répertoire : read = liste le contenu, write=créer ou renomme un répertoire, execute = chercher le répertoire Unix gère la création, effacement de fichier en contrôlant les accès sur les répertoires Windows NT : NTFS (New technology File System) Read, write, execute, delete, change permission, change ownership Changement de droits d’accès (modifier par une tierce partie grant, revoke, modification par l’utilisateur, assert, deny) Intéressant pour les politique de délégation : un objet invoque un autre objet, quels droits possède ce dernier objet ? e execution search

V- Access control Access control structures
Access control matrix S set of subjects s, O set of objects o D set of permissions M is a matrix whose lines (resp. columns) are indexed with subjects (resp. objects): the cell M[s,o] contains the access permissions of s on o Example: the modelled system contains 3 processes (s1, s2, and s3), 3 files (o1 et o2, and o3), 3 permissions (r=read, w=write, e=execute) objects o1 o2 o3 s1 r,w r,e s2 r,w,e s3 w subjects

Other interpretations of Access Control Matrix Modelling of a programming language Subjects = procedures/modules Objects = procedures/variables Permissions = ability to execute some functions Modelling of a LAN Subjets = host stations Objects = host stations Permissions = protocols Other notions of permissions Evaluation of a boolean expression Contextual information Access based on the history of previous access Compt Inc_ctr Dcr_ctr + - Manager call Hôtes Station1 Station2 Station3 ftp ftp,mail ftp,nfs mail

Implement a matrix is costly, in practical: Use of access control list, or Use of capacities Access control list (ACL) : column representation Each object comes with a list specifying all subjects (or user group) and their permissions Used in Multics, Windows 2000 To know the permissions of a specific user (in case of a revocation): it is necessary to scan all ACLs s1 r,w o1 s2 r,w,e o2 s3 w o3 r,e Gestion d’acl compliquée car basée sur des sujets individuels, d’ou les bits de protection. ACL Adaptés pour des OS gérant des accès à des objets Capacités : difficile de voir qui a les permissions pour un objet donné

Capacities: line representation Use of tickets t=(o,P), where o is an object, and P a set of permissions: a subject holding t can access to o with permissions in P A subject holding a capacity must not be able to modify it, or to build a new capacity A subject may transfer the capacity to another subject Used in micro-kernel L4, Capsicum, … For a specific object it is difficult to know the set of subjects that can access to it Requires mechanisms to revoke capacities o2 r,w,e s2 o3 w s3 r,e s1 o1 r,w Il y a un regain d’intérêt dans l’utilisation de capacités avec le besoin de politiques de sécurité prenant en compte des utilisateurs itinérants.

Protection bits Column representation with a structuration into groups Impossible to specify the access permissions of a particular user Interdiction (negative permission) Define which subject cannot access to an object If added to protections: permits to refine permissions Protection ring Each subject and object is associated with a ring number, n°0 corresponds to the strongest protection Access control is decided according to a comparison of ring numbers of subject and object Used in Multics, intel80386/80486 processors Privilege set of permissions focuses on the operations (system administrator, …) 1 2 3 Anneaux de protection : -utilisés pour l’intégrité unix utilise deux niveaux avec le système dans l’anneau 0 et les processus utilisateurs dans l’anneau 3 QNX/Neutrino utilise 3 niveaux, avec le micro-noyau Neutrino dans l’anneau 0, le gestioonair de processus dans l’anneau 1, et tous les autres programmes dans l’anneau 3. Les zones mémoires contant des données sensitives, comme le code de l’OS

IV- Fonctions de sécurité 2
IV- Fonctions de sécurité 2. Contrôle d’accès Contrôle d’accès multi-niveaux Contrôle d’accès multi-niveaux Pour certaines politiques de sécurité, il est nécessaire de considérer différents « niveaux » de sécurité Niveaux de sécurité Niv ensemble des niveaux : les objets sont classifiés en fonction de leur sensibilité : Exemples Niv est complètement ordonné, T>S>C>NC et R>Prop>Sens>Pub Top Secret (T) Secret (S) Confidentiel (C) Non Classifié (NC) Restreint (R) Propriétaire (Prop) Sensible (Sens) Publique (Pub) Domaine militaire Domaine commercial

IV- Fonctions de sécurité 2. Contrôle d’accès Contrôle d’accès multi-niveaux Catégories de sécurité Cat : ensemble des catégories, permet de partitionner les objets de manière non hiérarchique Principe du besoin d’en savoir (« need to know ») : l’information n’est tranférée qu’aux sujets qui en ont besoin Exemples Ensemble non ordonné Les parties de Cat sont partiellement ordonnées par  Dept. A Dept. B Dept. C US EUR Domaine militaire Domaine commercial ASIE

IV- Fonctions de sécurité 2. Contrôle d’accès Contrôle d’accès multi-niveaux Labels de sécurité L’ensemble des labels de sécurité : LS=NivP(Cat) Exemple de label : (T,{US,EUR}) Relation d’ordre partielle induite : dom (« domine ») (niv1,ens_cat1) dom (niv2,ens_cat2) ssi niv1  niv2 et ens_cat2  ens_cat1 Exemple : (T,{US,EUR}) dom (S,{US}) (LS,dom) est un treillis (dom est une relation d’ordre partielle et il existe une borne inf et une borne sup pour chaque couple (l1,l2) de LS) Exercice : construire le treillis pour Niv={C,S} et Cat={US,EUR} Relation d’ordre partielle : réflexive, transitive, antisymétrique

Exemple : Niv={C,S}, Cat={US,EUR}
IV- Fonctions de sécurité 2. Contrôle d’accès Contrôle d’accès multi-niveaux Treillis des labels de sécurité Exemple : Niv={C,S}, Cat={US,EUR} (S,{US,EUR}) (S,{US}) (C,{US,EUR}) (S,{EUR}) (C,{US}) (C,{EUR}) (S,) (C,)

IV- Fonctions de sécurité 2. Contrôle d’accès Contrôle d’accès multi-niveaux Habilitation : label de sécurité associé à un sujet Classification : label de sécurité associé à un objet Les sujets sont habilités à un niveau de sécurité pour un ensemble de catégories donné Les sujets sont classifiés selon un niveau de sécurité et un ensemble de catégories donné Sécurité multi-niveaux : permet de définir des politiques MAC en compartimentant l’information.

Catégories de sécurité
IV- Fonctions de sécurité 2. Contrôle d’accès Contrôle d’accès multi-niveaux Implémentation des labels dans Unix System V/MLS Nombre fixe de labels de sécurité et ensemble fixe de catégories Administration des labels, catégories et labels par l’administrateur système Sujets = processus UNIX, objets= fichiers et répertoires UNIX Implémentation des labels : initialement utilisation de bits de l’identifiant de groupe, GID, codé sur 16 bits (versions suivantes : GID pointeur vers une structure contenant notamment les labels, insertion des labels dans les structures de nœuds d’indexes ou i-node) Chaque utilisateur a un label défini au login, les processus associés héritant de ce label. Une commande permet à l’utilisateur de changer explicitement son label Labels flottants : plage de label Label de sécurité Catégories de sécurité GID Bits 12 - 9 8 - 0

IV- Fonctions de sécurité 2. Contrôle d’accès Contrôle d’accès multi-niveaux Multi-niveaux sans distinction niveaux/catégories Exemple : labels pour un firewall Séparation stricte entre « l’intérieur » et « l’extérieur » d’un réseau Privé Interne Externe Publique

IV- Fonctions de sécurité 3. Modèles de contrôle d’accès Modèle de Bell LaPadula Historique BLP : modèle basé sur une machine à état conçu au MITRE [BLP73] Sous contrat avec l’ « Air Force » Dans le cadre du développement de l’OS Multics Un des modèles de sécurité les plus influents depuis 30 ans La politique du modèle BLP avait été intégrée dans les critères TSECs Caractéristiques Capture les aspects confidentialité du contrôle d’accès Modèle multi-niveaux : l’information ne peut circuler d’un niveau donné à un niveau inférieur BLP et Matrice de contrôle d’accès : BLP utilise une matrice de contrôle d’accès pour décrire les contrôles d’accès discrétionnaires.

IV- Fonctions de sécurité 3. Modèles de contrôle d’accès Modèle de Bell LaPadula Principe : Modèle = machine à états éléments de base (sujets, objets, permissions, labels de sécurité) état composé : d’une matrice des permissions d’accès d’un ensemble des accès en cours d’un ensemble d’affectations de labels de sécurité pour chaque sujet et objet (calculées avec les fonctions de niveaux détaillées dans la suite) la sécurité est définie par un ensemble de propriétés sur les états: SS-property + *-property + ds-property (+ tranquility) ensemble de règles : règles de transition sur les états

IV- Fonctions de sécurité 3. Modèles de contrôle d’accès Modèle de Bell LaPadula Model elements: Set of subjects S, set of objects O Set of permission P Observation without altération : read (r) Observation and alteration : write (w) Alteration without observation : append (a) No observation, no altération : execute (e) An access control matrix built from S, O and P Set of labels L with a partial order dom

IV- Fonctions de sécurité 3. Modèles de contrôle d’accès Modèle de Bell LaPadula Model elements Label function l l : S U O  L , assigns a label to each subject and object F, set of couples (s,l(s)) and (o,l(o)) for every subject s and object o Set of current access, CA whose elements are triplets (s,o,p) with s a subject, o an object and p a permission States of the model : CA  M  F A state of the model is described by the set of current access, an access control matrix and the assignment of labels to subject and object

IV- Fonctions de sécurité 3. Modèles de contrôle d’accès Modèle de Bell LaPadula MAC policy in BLP Simple security property (ss): a state of the model satisfies the property (ss) if for every current access (s,o,p) in AC with p {r,w} (observation) then l(s) dom l(o) no read-up A Trojan may still be able to copy the content of a sensitive file in a file with a lower label that a malicious user with a lower label can read it Hence the following property *-property (star-property, confinement property): a state of the model satisfies the *-property, if for every current access (s,o,p) in AC with p {w,a} (alteration) then l(o) dom l(s) no write down Modifeir propriété * et supprime le corollaire.

IV- Fonctions de sécurité 3. Modèles de contrôle d’accès Modèle de Bell LaPadula BLP MAC policy Label L1 (L1 dom L2) Label L2 O2 O1 S1 S2 obs alt obs,alt O3 Label L3 (L3 non comparable with L1 nor L2) S3 No direct information flow from a higher object (o1) to a lower object (o2)!

IV- Fonctions de sécurité 3. Modèles de contrôle d’accès Modèle de Bell LaPadula BLP DAC policy The third proprerty deals with discretionary access ds-property: a state of the model satisfies the property (ds) if for every current access (s,o,p) in AC, p appears in the cell [s,o] of access control matrix M. Basic security theorem A state is secure if properties (ss), (*), and (ds) are satistfied. A transition from a state e1 to e2 is secure if e1 and e2 are secure Theorem: if the initial state of a system is secure, and if each of its transitions is also secure, then all reachable state is secure. Proof: induction on the sequence of transition Independent from BLP properties Le théorème de sécurité basique est un artefact de la modélisation sous forme d’automate, Pas une conséquence du choix des propriétés de sécurité.

IV- Fonctions de sécurité 3. Modèles de contrôle d’accès Modèle de Bell LaPadula Un sujet s1 de label l1 ne peut pas envoyer de message à un sujet s2 de label l2 inférieur à l1 ! Solution : on distingue deux habilitations pour les sujets fm : S  LS , détermine l’ « habilitation maximale » d’un sujet fc : S  LS , détermine l’« habilitation courante » d’un sujet (fc(s)  fm(s)) Deux interprétations on diminue temporairement le label de s1 on considère que les connaissances d’un sujet se limitent à l’état courant si le sujet est un processus (sans mémoire), il ne peut accéder à un niveau supérieur on identifie un sous-ensemble de sujets de confiance de S qui peuvent violer la propriété * cette approche est plus adaptée si les sujets sont des personnes physiques (avec une mémoire) un sujet de confiance s peut se connecter avec une habilitation fc(s) La première solution implique que lors de la diminution temporaire, le sujet oublie ses connaissances du plus haut niveau : peu réaliste pour un humain, possible dans le cas d’un processus qui n’a pas de mémoire propre, leur seule connaissance étant le contenu de l’objet qu’ils observent. Dans la deuxieme solution : les utilisateurs de confiance peuvent se connecter avec des droits inférieurs A leur niveau de sécurité. fc retourne alors le niveau de sécurité auquel ils se sont connectés.

IV- Fonctions de sécurité 3. Modèles de contrôle d’accès Modèle de Bell LaPadula BLP initialement conçu pour des transitions ne modifiant pas les labels de sécurité Une transition diminuant le label de sécurité d’un objet viole la propriété de confinement (propriété *) -> pb de la déclassification : définir un ensemble d’entité de confiance qui suppriment les informations sensibles avant de déclassifier Propriété de tranquillité forte : les labels de sécurité ne changent pas Autre possibilité : les labels de sécurité ne peuvent être diminués

IV- Fonctions de sécurité 3. Modèles de contrôle d’accès Modèle de Bell LaPadula BLP a joué un rôle important dans la conception d’OS sécurisés Used in Security-Enhanced Linux (SELinux), set of Kernel modifications and user-space tools that can be added to various Linux distributions Limitations Ne traite pas d’intégrité (choix) Modèle rigide L’organisation garde une forte emprise sur le contrôle et la distribution de l’information Beaucoup d’opérations sûres ne sont pas permises Reste vulnérable aux canaux cachés Covert channel: information flow that is not controlled by any security mechanism Canal de stockage / canal temporel Exple : noms d’objets, attaque par DPA (differential power analysis) DERA = Defence Evaluation and Research Agency Wrapper MLS qui enveloppe Windows NT =agence du ministere de la défense au Royaume-Uni Introduction d’autre structures : si les sujets accèdent à un objet via un programme SxSxO Un sujet de bas niveau créé un objet canal.obj à son propre niveau Un complice de haut niveau soit augmente le niveau de canal.obj soit le laisse inchangé Ensuite le sujet de bas niveau essaie de relire le fichier: Succes -> bit 1 Echec -> bit 0 Il ne suffit pas de cacher le contenu d’un objet, il faut parfois egalement cacher l’existence de l’objet lui-meme.

IV- Fonctions de sécurité 3. Modèles de contrôle d’accès Modèle de Bell LaPadula Covert channel in BLP Subject s2 wants to read the content of object o1 such that l(o1) dom l(s2) Assume that s2 succeeded in installing a Trojan s1 with label l(s1)=l(o1), with s1 and s2 synchronized Direct access forbidden in BLP For each bit of o1 Trojan s1 reads the bit, and if bit=0, S1 does nothing, otherwise S1 creates a special file “Bit” with label l(s1) Subject s2 tries to read the file Bit ; if s2 receives a message “no such file” s2 records 0, otherwise s2 receives a message “access forbidden” and records 1 s1 et s2 iterate n times s1 can send to s2, n bits of information contained in o1 Informing a subject that an operation is forbidden is an information flow!

IV- Fonctions de sécurité 3. Modèles de contrôle d’accès Modèle de Biba
Modèle multi-niveaux pour l’intégrité : éviter la contamination d’entités « saines » d’un niveau donné, par des entités « corrompues » de niveaux inférieurs L’information ne peut s’écouler que du haut vers le bas Treillis de labels d’intégrité (NI, domine) fs et fo assignent les labels d’intégrité resp. à un sujet et à un objet Les droits d’accès sont : read, write et execute Notion de confiance implicite Plus haut est le label d’intégrité d’un sujet, plus on accorde de la confiance dans le bon déroulement de son exécution Un objet avec un label d’intégrité donné est plus fiable qu’un objet avec un label inférieur

Plusieurs politiques Politique d’intégrité stricte (duale de BLP) : labels statiques Propriété d’intégrité simple : un sujet s peut modifier un objet o ssi fs(s) domine fo(o) Propriété d’intégrité * : un sujet s peut observer un objet o ssi fo(o) domine fs(s) Formulation alternative de la propriété d’intégrité * Propriété d’intégrité * (faible): un sujet s peut observer un objet o ssi pour tout objet o’ qu’il est en train modifier fo(o) domine fo(o’) Politique « Ligne de flottaison basse » : labels dynamiques Propriété Low watermark object : si un sujet s modifie un objet o alors le label d’intégrité de o devient inf(fs(s),fo(o)) Propriété Low watermark subject : si un sujet observe un objet o alors le label d’intégrité de s devient inf(fs(s),fo(o)) 1. Prévient contre modification directe (écrire) aussi bien qu’indirecte (lire) de l’information Un sujet corrompu ne peut ecrire dans un objet sain Un sujet peut lire tout objet à condition qu’il ne puisse corrompre un objet avec ses informations c. Evite qu’un sujet corrompu utilise un outil sain pour contaminer un objet sain. 2 Ligne de flottaison basse : Prévient contre modification directe (écrire) aussi bien qu’indirecte (lire) de l’information Le sujet se repose sur une donnée moins fiable que lui-meme, ce qui abaisse sa crédibilité Propriété * alternative : un s peut lire un objet s’il n’est pas en train d’ecrire en meme temps dans un objet de niveau supérieur

Chemin de transfert d’information : séquence d’objets o1, …, on+1, et de sujets s1, …, sn, tels que si r oi et si w oi+1 (1≤i≤n) Succession de read et de write permettant de transférer une donnée d’un objet o1 dans un objet on+1 Théorème : s’il existe un chemin de transfert d’information entre des objets o1 et on+1, alors les deux politiques précédentes garantissent que f(o1) domine f(on+1) (pour n > 1).

Propriété d’invocation : opération entre sujets un sujet s peut exécuter un sujet s’ ssi fs(s) domine fs(s’) Ajoutée aux 2 premières politiques d’intégrité : un sujet contaminé ne peut accèder indirectement à un objet sain en invoquant un sujet sain Politique « en anneau » : Propriété simple : un sujet s peut écrire dans un objet o ssi fs(s) domine fo(o) Propriété * : tout sujet s peut lire tout objet, indépendamment des labels d’intégrité Propriété d’invocation : un sujet s exécuter un sujet s’, ssi fs(s’) domine fo(s) Inverse de la propriété d’invocation : le sujet invoqué devra effectuer des vérifications de consistence afin de s’assurer qu’il reste sain exemples : LOMAC dans Free Bsd (module implémentant la politique « Ligne de flottaison basse ») Un sujet ne peut invoquer que des outils qui sont à un niveau inférieur : sinon un sujet contaminé pourrait utiliser un outil propre pour contaminer un objet Un sujet contaminé peut modifier un objet sain, mais uniquement s’il utilise un outil propre qui effectuera un ensemble de vérifications de consistence sur l’objet pour s’assurer qu’il reste sain. Par contre un sujet propre ne peut invoquer un outil contaminé Ne previent pas contre une modification indirecte de l’information LOMAC : le système comporte deux niveaux haut et bas Des qu’un programme, par exemple un démon, reçoit du trafic en provenance d’internet, son niveau est automatiquement degrade a Low; Meme si le trafic contient une attaque permettant de créer un shell root, ce shell ne pourra pas par exemple ecrire dans le fichier de mots de passe Le code malicieux ne peut obtenir les droits root, mais peut contaminer le niveau low et peut l’utiliser pour contaminer d’autres machine

IV- Fonctions de sécurité 3. Modèles de contrôle d’accès RBAC
Principe Se base sur le fait que les utilisateurs jouent un rôle précis dans l’organisation dont on peut déduire les permissions (privilèges) Permet de représenter la structure d’une organisation sous-forme hiérarchique Modèle RBAC = Role-Based Access Control Premiers travaux : NIST, 1992 Modèle de base : RBAC96 Modèle d’administration des rôles : ARBAC97 NIST : US National Institute of Standards and Technology

Eléments du modèle U : ens. d’utilisateurs R : rôles (fonctionnel, organisationnel, event participation à un projet) P : permissions S : sessions (les utilisateurs doivent toujours commencer par activer une session), activée par un seul utilisateur, qui peut activer plusieurs rôles AU : affectation des utilisateurs aux rôles (relation plusieurs-à-plusieurs) AP : affection des permissions aux rôles (relation plusieurs-à-plusieurs)

Permissions Users AU Rôles AP Opérations Objets AS (plusieurs à plusieurs) User <-> Sessions (un à plusieurs) Sessions

Hiérarchie de rôles Calquée sur la hiérarchie de l’organisation Héritage des permissions d’un rôle vers les rôles séniors écriture rapide de la politique de contrôle d’accès Plusieurs interprétations : spécialisation/généralisation : Ingénieur-> Ingénieur qualité ou Ingénieur production hiérarchie organisationnelle : Directeur, Chef de projet, Ingénieur hiérarchie fonctionnelle : Ingénieur, ingénieur Devlpt, Employé

Personnel Personnel administratif Personnel enseignant Personnel recherche Secrétaire Chargé d’enseignement Ingénieur de recherche Maître de conférences Professeur Chef de département

Contraintes Ajout de contraintes (expressions logiques) sur les affectations Contraintes sur AU (utilisateurs <-> rôles) Un utilisateur ne peut cumuler certains rôles (séparation des fonctions ou des pouvoirs) Contraintes de cardinalité Contraintes sur AP (rôles <-> permissions) Certaines permissions ne peuvent être affectées à certains rôles (interdictions) Certaines permissions ne peuvent être affectées à plusieurs rôles Un rôle ne peut pas cumuler certaines permissions (séparation des tâches) Contraintes sur AS (sessions <-> rôles) Contraintes sur l’activation des roles Contraintes sur la hiérarchie de rôle

ARBAC = administrative RBAC Définit les règles et mécanismes pour gérer RBAC Auto-administration Une autorité centrale définit la hiérarchie de rôles, les permissions associées aux rôles les contraintes L’affectation des utilisateurs aux rôles est décentralisée On ajoute RA : rôles administratifs, RAR= PA : permissions administratives, PAP= Administration de l’affection des rôles aux utilisateurs, et des permissions aux rôles Remarques Modélisation partielle de l’organisation La notion de rôle n’est pas clairement définie Les rôles restent internes à une organisation La hiérarchie de rôle n’est pas clairement définie ARBAC97ne prend pas en compte tous les aspects de l’administration Création des utilisateurs, rôles et permissions Gestion des contraintes Aucun mécanisme de délégation

On peut simuler les modèles DAC et MAC dans RBAC Gestion des autorisations souple : Assignement des rôles aux utilisateurs Assignement des autorisations d’accès aux objets, aux rôles Principe du moins privilège Séparation des fonctions et des tâches Modélisation partielle de l’organisation Les rôles restent internes à une organisation Aucun mécanisme de délégation

IV- Fonctions de sécurité 3. Modèles de contrôle d’accès Conclusion
Autres modèles : modèles pour les politiques de sécurité dans le monde médical modèles pour la disponibilité Aucun modèle unique permettant d’exprimer toutes les exigences que peut contenir une politique de sécurité Modélisation de l’organisation Structuration des utilisateurs Séparation des tâches et des fonctions Délégation et transfert de droits Administration de la politique de sécurité … Besoin de nouveaux modèles de sécurité plus « dynamiques » : configurables et personnalisables suivant des profils d’utilisateurs, des flux dépendant du contexte, de la localisation, … Contrôle d’usage (UCON) : obligations

Outline I- Introduction II- Definitions

Présentations similaires

Présentation au sujet: "Outline I- Introduction II- Definitions"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back

Entrer

S'autoriser via un réseau social:

Outline I- Introduction II- Definitions

Présentations similaires

Présentation au sujet: "Outline I- Introduction II- Definitions"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back