Sécurité des systèmes d'information (Traité IC2, série Réseaux et télécoms)

-

Livres
385 pages
Lire un extrait
Obtenez un accès à la bibliothèque pour le consulter en ligne
En savoir plus

Description

Cet ouvrage constitue un complément au précédent traité IC2 sur la sécurité des réseaux et systèmes répartis. Sont successivement abordés, en 11 chapitres, les domaines importants de la sécurité que sont : les politiques et modèles de sécurité classiques , la protection de la vie privée sur Internet , la détection d'intrusions , les protocoles IPSec et TLS, les pare-feux , les vers et virus informatiques , la gestion de clés cryptographiques et les infrastructures sous-jacentes , la problématique de la sécurité et de la mobilité , les cartes à puce , la biométrie , la tolérance aux intrusions.
Avant-propos -L. Mé, Y. Deswarte. Les modèles de sécurité -F. Cuppens, N. Cuppens-Boulahia. Technologie de protection de la vie privée sur Internet -Y. Deswarte, C. Aguilar Melchor. Détection d'intrusions : état de l'art, faiblesses et problèmes ouverts -M. Dacier. Les protocoles IPSec et TLS -R. Molva. Les pare-feu -O. Paul. Virus et vers informatiques -E. Filiol. Infrastructure de gestion de clés -P. Chour. Sécurité et mobilité -C. Bidan. Carte à puce -J.-L. Lanet, P. Girard. Authentification biométrique -J. Czyz, L. Vandendorpe. Tolérance aux intrusions sur Internet -Y. Deswarte, V. Nicomette, A. Saidane.

Sujets

Informations

Publié par
Date de parution 16 juin 2006
Nombre de visites sur la page 188
EAN13 9782746237575
Langue Français

Informations légales : prix de location à la page 0,0938 €. Cette information est donnée uniquement à titre indicatif conformément à la législation en vigueur.

Signaler un problème








Sécurité des systèmes d'information




































© LAVOISIER, 2006
LAVOISIER
11, rue Lavoisier
75008 Paris

www.hermes-science.com
www.lavoisier.fr

ISBN 2-7462-1259-5


Le Code de la propriété intellectuelle n'autorisant, aux termes de l'article L. 122-5, d'une part,
que les "copies ou reproductions strictement réservées à l'usage privé du copiste et non
destinées à une utilisation collective" et, d'autre part, que les analyses et les courtes citations
dans un but d'exemple et d'illustration, "toute représentation ou reproduction intégrale, ou
partielle, faite sans le consentement de l'auteur ou de ses ayants droit ou ayants cause, est
illicite" (article L. 122-4). Cette représentation ou reproduction, par quelque procédé que ce
soit, constituerait donc une contrefaçon sanctionnée par les articles L. 335-2 et suivants du
Code de la propriété intellectuelle.
Tous les noms de sociétés ou de produits cités dans cet ouvrage sont utilisés à des fins
d’identification et sont des marques de leurs détenteurs respectifs.


Printed and bound in England by Antony Rowe Ltd, Chippenham, May 2006.







Sécurité


des systèmes


d'information





sous la direction de

Ludovic Mé et Yves Deswarte



















Il a été tiré de cet ouvrage
30 exemplaires hors commerce réservés
aux membres du comité scientifique,
aux auteurs et à l’éditeur
numérotés de 1 à 30
Sécurité des systèmes d'information
sous la direction de Ludovic Mé et Yves Deswarte
fait partie de la série RÉSEAUX ET TÉLÉCOMS dirigée par Guy Pujolle




TRAITE IC2 INFORMATION – COMMANDE – COMMUNICATION
sous la direction scientifique de Bernard Dubuisson

Le traité Information, Commande, Communication répond au besoin
de disposer d'un ensemble complet des connaissances et méthodes
nécessaires à la maîtrise des systèmes technologiques.
Conçu volontairement dans un esprit d'échange disciplinaire, le traité
IC2 est l'état de l'art dans les domaines suivants retenus par le comité
scientifique :
Réseaux et télécoms
Traitement du signal et de l'image
Informatique et systèmes d'information
Systèmes automatisés et productique
Management et gestion des STICS
Cognition et traitement de l’information
Chaque ouvrage présente aussi bien les aspects fondamentaux
qu'expérimentaux. Une classification des différents articles contenus dans
chacun, une bibliographie et un index détaillé orientent le lecteur vers ses
points d'intérêt immédiats : celui-ci dispose ainsi d'un guide pour ses
réflexions ou pour ses choix.
Les savoirs, théories et méthodes rassemblés dans chaque ouvrage ont
été choisis pour leur pertinence dans l'avancée des connaissances ou pour
la qualité des résultats obtenus dans le cas d'expérimentations réelles. Liste des auteurs


Carlos AGUILAR MELCHOR Pierre GIRARD
LAAS-CNRS Gemplus
Toulouse Gémenos

Christophe BIDAN Jean-Louis LANET
Supélec Gemplus
Rennes Gémenos

Pascal CHOUR Ludovic MÉ
DCSSI Supélec
Paris Rennes

Frédéric CUPPENS Refik MOLVA
ENST Bretagne Eurécom
Rennes Sophia-Antipolis

Nora CUPPENS-BOULAHIA Vincent NICOMETTE
ENST Bretagne LAAS-CNRS
Rennes Toulouse

Jacek CZYZ Olivier PAUL
Université catholique de Louvain INT
Louvain-la-Neuve Evry
Belgique
Ayda SAIDANE
Marc DACIER LAAS-CNRS
Eurécom Toulouse
Sophia-Antipolis
Luc VANDENDORPE
Yves DESWARTE Université catholique de Louvain
LAAS-CNRS Louvain-la-Neuve
Toulouse Belgique

Eric FILIOL
ESAT
Rennes
Table des matières
Avant-propos ....................................... 11
Ludovic MÉ et Yves DESWARTE
Chapitre 1. Les modèles de sécurité ......................... 13
Frédéric CUPPENS et Nora CUPPENS-BOULAHIA
1.1. Introduction ................................... 13
1.2. Contrôle d’accès ................................ 15
1.2.1. Modèle I-BAC .............................. 15
1.2.2. Modèle R-BAC 17
1.2.3. Modèle T-BAC 18
1.2.4. Modèle V-BAC 18
1.2.5. Modèle T-MAC ............................. 19
1.2.6. Modèle Or-BAC 20
1.2.7. Modèles d’autorisations dynamiques et contextuelles ....... 22
1.2.8. Modèles d’autorisations positives et négatives ........... 23
1.3. Contrôle de flux ................................. 25
1.3.1. Modèle de Bell et LaPadula . ...................... 26
1.3.2. Modèle de non-interférence 28
1.3.3. Modèle de Bell et LaPadula étendu .................. 29
1.3.4. Modèle de causalité ........................... 31
1.3.5. Modèles d’intégrité 32
1.3.6. Vers des modèles d’intégrité et de confidentialité : modèle DTE . . 33
1.4. Administration 36
1.4.1. Modèle DAC ............................... 36
1.4.2. Modèle TAM 38
1.4.3. Modèle ARBAC ............................. 39
1.4.4. Modèle AdOr-BAC 40
1.4.5. Administration dans les modèles de type MAC ........... 40
1.5. Synthèse et perspectives ............................ 42
1.5.1. Synthèse du contrôle d’accès ...................... 42
1.5.2. Synthèse du contrôle de flux 42




















6 Sécurité des SI

1.5.3. Vers le contrôle d’usage ......................... 43
1.6. Bibliographie .................................. 44
Chapitre 2. Technologie de protection de la vie privée sur Internet....... 49
Yves DESWARTE et Carlos AGUILAR MELCHOR
2.1. Introduction ................................... 49
2.2. Gestion des identités .............................. 51
2.3. Communications IP anonymes ........................ 52
2.3.1. Définitions et exemples ......................... 52
2.3.2. Les MIX et les réseaux de MIX .................... 53
2.3.3. Autres approches ............................. 57
2.4. Accès anonymes aux services 58
2.5. Autorisation préservant la vie privée 59
2.5.1. Schémas d’autorisation équilibrés ................... 61
2.5.2. Exemples de garanties anonymes 62
2.5.3. Monnaie électronique (e-Cash) .................... 64
2.6. Gestion des données personnelles ...................... 65
2.6.1. Minimisation des données personnelles ............... 66
2.6.2. Autodétermination des données personnelles ............ 67
2.7. Conclusion .................................... 69
2.8. Bibliographie .................................. 70
Chapitre 3. Détection d’intrusions : état de l’art, faiblesses
et problèmes ouverts 73
Marc DACIER
3.1. Introduction ................................... 73
3.2. Définitions 74
3.3. Taxonomie 76
3.3.1. Paradigme de détection ......................... 77
3.3.2. Méthode de détection .......................... 78
3.3.3. Fréquence d’utilisation 82
3.3.4. Sources d’informations 83
3.3.5. Comportement après détection ..................... 84
3.4. Rappel historique ................................ 85
3.4.1. Les dix premières années ........................ 85
3.4.2. Les premiers produits 89
3.4.3. Les tendances actuelles ......................... 91
3.5. Problèmes fondamentaux ........................... 91
3.5.1. Volatilité du problème .......................... 91
3.5.2. Complexité algorithmique ....................... 92
3.5.3. Réactivité ................................. 92
3.5.4. Evaluation 93
3.6. Conclusion .................................... 93
3.7. Bibliographie .................................. 94




























Table des matières 7
Chapitre 4. Les protocoles IPSec et TLS ..................... . 101
Refik MOLVA
4.1. Introduction ................................... 101
4.2. Mécanismes de sécurité dans le protocole IP ................ 102
4.2.1. Mécanisme d’authentification dans IP 104
4.2.2. Mécanisme de confidentialité dans IP 107
4.2.3. Calcul des données d’authentification 109
4.2.4. Associations de sécurité ......................... 111
4.2.5. Scénarios de déploiement d’IPsec ................... 112
4.3. Gestion des clés ................................. 114
4.3.1. ISAKMP .................................. 116
4.3.2. Protocole Oakley ............................. 119
4.4. Sécurité dans la couche transport ....................... 121
4.4.1. La couche d’enregistrement de TLS ................. 122
4.4.2. La couche Handshake de TLS ..................... 123
4.5. Conclusion .................................... 125
4.6. Bibliographie 127
Chapitre 5. Les pare-feu ................................ 129
Olivier PAUL
5.1. Introduction ................................... 129
5.1.1. Une définition des pare-feu ....................... 129
5.1.2. Un petit peu d’histoire .......................... 130
5.1.3. Le service de contrôle d’accès ..................... 132
5.2. Le contrôle d’accès au niveau réseau .................... 133
5.2.1. Politiques de filtrage ........................... 134
5.2.2. Exemple d’implantation ......................... 146
5.3. Le contrôle d’accès au niveau circuit 147
5.3.1. Politiques de filtrage 148
5.3.2. Exemple d’implantation 159
5.4. Le contrôle d’accès au niveau applicatif .................. 163
5.4.1. Politiques de contrôle d’accès ..................... 166
5.4.2. Exemple d’implantation 173
5.5. Architectures à base de pare-feu ....................... 177
5.5.1. Architectures simples .......................... 178
5.5.2. Architectures étendues ......................... 180
5.6. Bibliographie .................................. 184
Chapitre 6. Virus et vers informatiques ...................... 187
Eric FILIOL
6.1. Introduction ................................... 187
6.2. Définitions de base et taxonomie virale ................... 189
6.2.1. Définitions et concepts de base .................... 189



































8 Sécurité des SI

6.2.2. Taxonomie des infections virales ................... 190
6.3. Les grandes fonctions virales ......................... 195
6.3.1. Diagramme fonctionnel d’un virus ou d’un ver ........... 195
6.3.2. Modes d’infection ............................ 196
6.3.3. Virus par accompagnement de code .................. 200
6.3.4. Techniques d’antidétection ....................... 202
6.4. La lutte antivirale ................................ 204
6.4.1. Les techniques antivirales ........................ 204
6.5. Conclusion .................................... 210
6.6. Annexe : code source du virus Timid .................... 211
6.7. Bibliographie .................................. 218
Chapitre 7. Infrastructure de gestion de clés ................... 221
Pascal CHOUR
7.1. Introduction ................................... 221
7.2. Public visé et prérequis ............................ 223
7.2.1. Ce qui est supposé connu ........................ 223
7.2.2. Ce que l’on ne trouve pas dans ce document ............ 224
7.3. Bonnes pratiques ................................ 224
7.3.1. Contraintes réglementaires et légales ................. 225
7.3.2. Contraintes liées aux brevets ...................... 225
7.3.3. Algorithmes et règles d’usages ..................... 226
7.3.4. Cryptopériode des clés ......................... 226
7.3.5. Contraintes sur les mécanismes de base ............... 228
7.3.6. Résistance aux attaques 228
7.3.7. Intégrité et secret des algorithmes ................... 230
7.3.8. Génération de clés, génération d’aléas ................ 231
7.3.9. Séquestre, sauvegarde, restauration des clés ............. 233
7.3.10. Séparation du rôle des clés ...................... 234
7.3.11. Architecture de clés, diversification des clés ............ 234
7.3.12. Antirejeu ................................. 240
7.3.13. Mise à la clé ............................... 240
7.3.14. Zoom sur les infrastructures à clé publique (ICP) ......... 242
7.3.15. Signature électronique ......................... 243
7.3.16. Aspects organisationnels ....................... 244
7.3.17. Spécification techniques d’un cryptosystème ........... 246
7.3.18. Efficacité, conformité, confiance ................... 247
7.3.19. Internalisation/externalisation .................... 248
7.3.20. Points à vérifier auprès des fournisseurs .............. 248
7.3.21. Cartes à puce .............................. 249
7.4. Conclusion .................................... 251
7.5. Bibliographie .................................. 252






































Table des matières 9
Chapitre 8. Sécurité et mobilité ........................... 255
Christophe BIDAN
8.1. Mobilité et nomadisme ............................. 256
8.1.1. Nomadisme : problèmes et solutions ................. 256
8.1.2. Téléphonie mobile : problèmes et solutions ............. 258
8.1.3. Mobilité dans le nomadisme ...................... 260
8.2. Sécurité ...................................... 263
8.2.1. Sécurité et nomadisme .......................... 263
8.2.2. Sécurité et téléphonie mobile 268
8.2.3. Sécurité et mobilité ........................... 270
8.3. Conclusion .................................... 275
8.4. Bibliographie .................................. 276
Chapitre 9. Carte à puce ................................ 279
Jean-Louis LANET et Pierre GIRARD
9.1. Cartes à puce et nouveaux défis ....................... 279
9.1.1. Fonctionnalités de la carte à puce ................... 280
9.1.2. Les applications ............................. 281
9.2. Technologies de la carte à puce ........................ 283
9.2.1. Cartes à mémoire et cartes à microprocesseur ............ 284
9.2.2. Communication entre la carte et le monde extérieur ........ 284
9.2.3. Les cartes classiques ou « fermées » ................. 286
9.2.4. Java Card ................................. 288
9.3. Sécurité physique ................................ 291
9.3.1. Les attaques invasives .......................... 291
9.3.2. Les attaques non invasives ....................... 292
9.4. Sécurité logique 293
9.4.1. Eviter les vulnérabilités ......................... 295
9.4.2. Méthodes formelles ........................... 295
9.4.3. Description du vérifieur 296
9.4.4. Modélisation du vérifieur ........................ 299
9.4.5. Conclusions 311
9.5. Conclusion .................................... 312
9.6. Bibliographie .................................. 313
Chapitre 10. Authentification biométrique .................... 315
Jacek CZYZ et Luc VANDENDORPE
10.1. Introduction 315
10.1.1. Vue d’ensemble ............................. 316
10.1.2. Authentification et identification ................... 318
10.1.3. Biométrie et sécurité .......................... 318
10.2. Survol des principales modalités ...................... 319
10.2.1. La parole ................................. 319



































10 Sécurité des SI

10.2.2. Le visage ................................. 320
10.2.3. L’iris ................................... 320
10.2.4. Les empreintes digitales ........................ 321
10.2.5. Biométrie multimodale 323
10.3. Eléments de la théorie de la décision .................... 324
10.3.1. Règle de décision pour l’erreur minimale .............. 324
10.3.2. Le score 326
10.3.3. Règle de décision du risque minimal ................ 326
10.3.4. Règle de décision du minimax 328
10.4. Evaluation des performances d’un système d’authentification .... 329
10.4.1. Taux de faux rejet et fausse acceptation .............. 329
10.4.2. Courbe caractéristique ......................... 330
10.4.3. Données et protocole de validation ................. 332
10.4.4. Intervalles de confiance ........................ 333
10.5. Conclusion ................................... 335
10.6. Bibliographie .................................. 335
Chapitre 11. Tolérance aux intrusions sur Internet ............... 339
Yves DESWARTE, Vincent NICOMETTE, Ayda SAIDANE
11.1. La sécurité des systèmes connectés à l’Internet ............. 339
11.1.1. Internet est vulnérable ......................... 339
11.1.2. Les techniques classiques de sécurité sont insuffisantes ..... 341
11.2. La tolérance aux intrusions 343
11.2.1. La tolérance aux fautes ........................ 343
11.2.2. Vulnérabilités, attaques, intrusions ................. 345
11.3. Un exemple d’architecture tolérant les intrusions : le projet DIT . . . 347
11.3.1. Les mandataires ............................. 348
11.3.2. Les mécanismes de détection ..................... 348
11.3.3. Le gestionnaire d’alertes 352
11.3.4. La redondance adaptative : les régimes de fonctionnement . . . 354
11.3.5. L’adaptation pour serveurs à contenu dynamique ......... 355
11.3.6. Description d’une exécution 358
11.3.7. Discussion sur la capacité à résister aux attaques 360
11.3.8. Mesures de performance ........................ 361
11.4. Conclusion ................................... 366
11.5. Bibliographie .................................. 366































Avant-propos
Ce traité sur la sécurité des systèmes d’information constitue le complément
naturel du traité IC2 sur la sécurité des réseaux et systèmes répartis. Nous présentons ici
des aspects importants de la sécurité qui n’avaient pu être abordés précédemment.
Le chapitre 1, rédigé par Frédéric Cuppens et Nora Cuppens-Boulahia, présente les
modèles et politiques de sécurité. Les grands modèles classiques de contrôle d’accès
et de contrôle de flux sont présentés et une synthèse est proposée.
Dans le chapitre 2, Yves Deswarte et Carlos Aguilar Melchor traitent de la
protection de la vie privée sur Internet. Les différentes technologies qui contribuent à cette
protection sont présentées : gestion des identités, communications IP anonymes,
accès anonymes aux services, autorisation préservant la vie privée, gestion des données
personnelles.
Le chapitre 3, rédigé par Marc Dacier, constitue une introduction au domaine de
la détection d’intrusions. Après un état de l’art, sont présentés les faiblesses des outils
actuels et les problèmes ouverts du domaine.
Les protocoles IPSec et TLS sont présentés dans le chapitre 4, rédigé par Refik
Molva. Il s’agit de deux protocoles majeurs pour la confidentialité, l’intégrité et
l’authenticité des échanges sur Internet.
Le chapitre 5, rédigé par Olivier Paul, traite des pare-feu, outils essentiels à la
sécurité des réseaux. Les niveaux réseau, circuit et applicatif sont détaillés et des
architectures possibles de pare-feu sont décrites.
Eric Filliol présente dans le chapitre 6 les vers et virus informatiques. Il s’agit là
de problèmes de sécurité qui touchent le plus grand nombre. Les grandes fonctions
virales sont détaillées et la lutte anti-virale est bien sûr abordée.12 Sécurité des SI
Le chapitre 7, rédigé par Pascal Chour, aborde le problème de la gestion de clés
cryptographiques et des infrastructures sous-jacentes. Ce chapitre aborde les points
sur lesquels il est nécessaire de s’interroger et d’apporter une réponse avant de rédiger
la spécification technique ou organisationnelle d’un crypto-système.
Dans le chapitre 8, Christophe Bidan aborde la problématique de la sécurité et de la
mobilité. Ce chapitre s’intéresse particulièrement à la convergence entre la téléphonie
mobile et les réseaux informatiques, qui devrait permettre une connexion permanente
des utilisateurs. Ce chapitre présente les problèmes de sécurité spécifiques à un tel
contexte, en insistant particulièrement sur ceux qui restent sans réelles solutions à ce
jour.
Le chapitre 9, rédigé par Jean-Louis Lanet et Pierre Girard, présente les cartes à
puce et traite particulièrement de leur sécurité, physique et logique, notamment pour
les cartes ouvertes basées sur des technologies issues de l’informatique classique (java
cards). Du point de vue logiciel, on s’intéresse en particulier aux défauts résiduels qui
pourraient être exploités par une application malveillante. L’objectif est de garantir au
minimum le même niveau de sécurité qu’avant l’avènement des cartes ouvertes. Les
outils à la disposition des concepteurs et des évaluateurs vont de l’audit traditionnel
de code jusqu’à la modélisation mathématique.
Le chapitre 10, rédigé par Jacek Czyz et Luc Vandendorpe, aborde un thème
important pour l’authentification : la biométrie. Les principales modalités (parole, visage,
iris, empreintes digitales) sont présentées, ainsi que les techniques de décision et les
performances des systèmes d’authentification biométriques.
Enfin, le chapitre 11, rédigé par Yves Deswarte, Vincent Nicomette et Ayda
Saidane, propose une approche complémentaire aux techniques classiques de la sécurité,
la tolérance aux intrusions.
Nous vous souhaitons une bonne lecture.
Ludovic MÉ
Yves DESWARTEChapitre 1
Les modèles de sécurité
1.1. Introduction
Le début des années 1970 a vu la définition des premiers modèles de sécurité :
modèle de contrôle d’accès [LAM 71] et de contrôle de flux [BEL 75]. Depuis, de
nombreux modèles de sécurité ont été définis. L’objectif de ce chapitre est de faire
le point sur les principaux travaux menés sur ce sujet au cours des trente dernières
années.
Dans ce chapitre, nous ne considérons pas les modèles conçus pour analyser les
protocoles de sécurité, en particulier les protocoles cryptographiques. Ces modèles
ont été proposés pour analyser des propriétés telles que l’authentification, la
nonrépudiation ou la fraîcheur d’une information.
Dans la suite, nous nous intéressons d’abord aux modèles de contrôle d’accès
proposés pour modéliser des politiques d’autorisation. Dans ce contexte, l’un des
premiers modèles est celui de Harrison, Ruzzo et Ullman (HRU, voir [HAR 76]). HRU
a deux composantes : un modèle de contrôle d’accès et un modèle d’administration.
Le modèle de contrôle d’accès repose sur l’identité des entités, d’où le nom de I-BAC
(identity based access control) pour désigner cette partie du modèle HRU.
L’administration est dite discrétionnaire, d’où le nom de modèle discrétionnaire (ou DAC,
discretionary access control) que l’on a tendance à utiliser pour désigner l’ensemble
du modèle HRU.
Chapitre rédigé par Frédéric CUPPENS et Nora CUPPENS-BOULAHIA.14 Sécurité des SI
Le modèle I-BAC présente plusieurs limites. En particulier, le manque de
structuration de ce modèle rend complexe l’expression et la gestion d’une politique
d’autorisation. De nombreux autres modèles ont ensuite été proposés. Ces modèles ont
introduit de nombreux concepts pour davantage structurer l’expression de la politique
d’autorisation : rôles, tâches, vues, équipes. Le modèle Or-BAC (organization based
access control, voir [KAL 03]) permet de structurer l’expression de la politique
d’autorisation en utilisant l’ensemble de ces concepts.
Des modèles à base de règles (Rule-BAC, voir par exemple [BER 03, JAJ 01])
ont été proposés pour exprimer des politiques d’autorisation incluant des règles de
contrôles d’accès dynamiques. L’expression de ce besoin dans le modèle Or-BAC est
également possible grâce à l’introduction du concept de contexte.
Les premiers modèles de contrôle d’accès ne permettaient d’exprimer que des
autorisations positives ou permissions. Les modèles plus récents offrent également la
possibilité d’exprimer des autorisations négatives ou interdictions. Ces modèles
facilitent l’expression de règles de contrôles d’accès présentant des exceptions mais posent
le problème de la gestion des conflits entre permissions et interdictions. Nous
examinerons, au paragraphe 1.2.8, les principales stratégies de résolution de conflits qui ont
été proposées dans la littérature.
On sait depuis la définition du modèle de Bell et LaPadula [BEL 75] que les
modèles de contrôle d’accès ne permettent pas de prendre en compte le problème des
applications piégées, encore appelées chevaux de Troie. Bell et LaPadula ont ainsi
défini le premier modèle de contrôle de flux (ou de type MAC, mandatory access
control). Cependant, ce premier modèle ne résout pas tous les problèmes, en
particulier la possibilité pour un cheval de Troie de transmettre illégalement des informations
via un canal caché. Le modèle de non-interférence [GOG 84] permet de traiter ce
problème mais conduit à un cloisonnement strict dû à l’hypothèse extrême que toutes
les applications peuvent être piégées par un cheval de Troie. Dans la pratique, le
modèle de non-interférence s’avère difficilement applicable. Des modèles plus récents
permettant d’assouplir les hypothèses trop pessimistes du modèle de non-interférence
ont ainsi été proposés. Nous présenterons en particulier dans ce chapitre les modèles
de Bell et LaPadula étendu [BEL 86], causalité [BIE 91] et DTE [BAD 95].
Tous ces modèles de sécurité doivent inclure un modèle d’administration pour
exprimer qui peut définir et mettre à jour une politique d’autorisation représentée dans
ces modèles. Le premier modèle d’administration est le modèle de type
discrétionnaire proposé par HRU [HAR 76]. Ce premier modèle permet d’administrer une
politique d’autorisation exprimée dans le modèle I-BAC. De très nombreux autres
modèles d’administration discrétionnaire ont ensuite été définis et le modèle TAM (typed
access matrix, voir [SAN 92]) est peut-être le plus abouti dans ce domaine. Mais,
l’expression d’une politique d’administration dans ces modèles reste limitée. Plus
récemment, de nouveaux modèles adaptés aux modèles R-BAC (role based access control)Les modèles de sécurité 15
et Or-BAC ont été définis. Ce dernier modèle est autoadministré, c’est-à-dire que la
politique d’administration s’exprime en utilisant les mêmes concepts que ceux utilisés
pour exprimer la politique d’autorisation. Nous verrons également comment exprimer
les besoins d’administration dans les modèles de contrôle de flux de type MAC en
administrant la déclassification.
Enfin, dans les nouvelles applications plus ouvertes ne reposant plus
nécessairement sur une architecture client-serveur, les modèles de contrôle d’accès ou de
contrôle de flux ne sont plus complètement adaptés. De nouveaux modèles voient
le jour pour répondre aux besoins de contrôle d’usage (voir par exemple, le modèle
ABC [PAR 04]). Ces modèles ne limitent plus la politique de sécurité à l’expression
de permissions et d’interdictions mais introduisent également le concept d’obligation.
Ces nouveaux modèles devraient, par exemple, être mis en œuvre dans les applications
de gestion des droits électroniques (DRM) ou les services web.
Le plan de ce chapitre est le suivant. Les sections 2 et 3 sont respectivement
consacrées aux modèles de contrôle d’accès et de contrôle de flux. La section 4 s’intéresse
aux modèles d’administration. Enfin, la section 5 propose une synthèse et ouvre des
perspectives sur les nouveaux modèles de contrôle d’usage.
1.2. Contrôle d’accès
1.2.1. Modèle I-BAC
Nous désignons par I-BAC (identity based access control) le premier modèle de
contrôle d’accès proposé dans la littérature (voir [LAM 71]). Ce modèle introduit les
concepts fondamentaux de sujet, d’action et d’objet :
– le sujet est l’entité active du SI. Il désigne le plus souvent un utilisateur ou une
application s’exécutant pour le compte d’un utilisateur ;
– l’objet est l’entité passive du SI. Il désigne une information ou une ressource à
laquelle un sujet peut accéder pour réaliser une action ;
– l’action désigne l’effet recherché lorsqu’un sujet accède à un objet. On peut par
exemple souhaiter lire ou mettre à jour l’information contenue dans un objet ou bien
recopier le contenu d’un objet dans un autre objet.
L’objectif du modèle I-BAC est de contrôler tout accès direct des sujets aux objets
via l’utilisation des actions. Ce contrôle est basé sur l’identité du sujet et
l’identificateur de l’objet, ce principe de contrôle d’accès donnant son nom au modèle I-BAC.
Le modèle I-BAC introduit ensuite le concept de politique d’autorisation. Dans
I-BAC, une politique d’autorisation correspond à l’expression d’un ensemble
d’autorisations positives (ou permissions) ayant le format suivant : un sujet a la
permission de réaliser une action sur un objet. La possibilité de spécifier dans un modèle16 Sécurité des SI
de contrôle d’accès des autorisations négatives (ou interdictions) ne sera offerte que
beaucoup plus récemment. Nous examinons les modèles offrant cette possibilité dans
le paragraphe 1.2.8. En fait, dans I-BAC, on suppose implicitement que la politique
de contrôle d’accès est fermée, c’est-à-dire par défaut tous les accès sont interdits. La
politique d’autorisation spécifie donc des permissions et on refusera l’accès si la
politique d’autorisation ne permet pas de dériver que cet accès est explicitement permis.
Pour représenter une politique d’autorisation, le modèle proposé dans [LAM 71]
introduit également un autre concept fondamental, celui de matrice de contrôle
d’accès qui sera ensuite repris dans plusieurs autres modèles (voir par exemple [HAR 76]).
Dans une matrice de contrôle d’accès, les lignes et colonnes de la matrice
correspondent respectivement à l’ensemble des sujets et des objets du SI. Les « cases » de
la matrice représentent l’ensemble des permissions qu’un sujet donné possède sur un
objet donné.
Le modèle de type I-BAC est aujourd’hui implanté dans la plupart des systèmes
d’exploitation actuels, tels que Windows, Unix ou Linux. Pour mettre en œuvre un tel
modèle dans un SI, on n’implante pas directement la matrice de contrôle d’accès. Il
existe en fait deux grandes approches possibles suivant que l’implantation repose sur
une décomposition en lignes ou en colonnes de la matrice.
La décomposition en colonnes consiste à associer, à chaque objet, un descripteur
appelé liste de contrôle d’accès, qui représente l’ensemble des sujets ayant des accès
sur l’objet considéré avec, pour chaque sujet, l’ensemble des actions que ce sujet peut
réaliser sur cet objet.
La décomposition en ligne consiste à associer, à chaque sujet, un ensemble de
capacités, représentant l’ensemble des objets auxquels le sujet peut accéder avec, pour
chaque objet, l’ensemble des actions que le sujet peut réaliser sur cet objet.
A l’usage, une limite importante du modèle I-BAC est apparue : la politique
d’autorisation devient rapidement complexe à exprimer et administrer. Il est en effet
nécessaire d’énumérer les autorisations pour chaque sujet, action et objet. En particulier,
lorsqu’un nouveau sujet ou objet est créé, il est nécessaire de mettre à jour la politique
d’autorisation pour définir les nouvelles permissions associées à ce sujet ou objet.
Pour pallier ce problème, des modèles ont plus récemment été définis. Tous ces
modèles ont en commun de proposer une expression plus structurée de la politique
d’autorisation. Nous présentons dans les paragraphes suivants, les modèles proposant
respectivement une structuration des sujets, des actions et des objets.Les modèles de sécurité 17
1.2.2. Modèle R-BAC
Le modèle RBAC (role based access control, voir [SAN 96]) propose de structurer
l’expression de la politique d’autorisation autour du concept de rôle. Un rôle est un
concept organisationnel : des rôles sont affectés aux utilisateurs conformément à la
fonction attribuée à ces utilisateurs dans l’organisation.
Le principe de base du modèle R-BAC est de considérer que les autorisations sont
directement associées aux rôles. Dans R-BAC, les rôles reçoivent donc des
autorisations de réaliser des actions sur des objets. Comme I-BAC, le modèle R-BAC ne
considère que des autorisations positives (permissions) et fait donc l’hypothèse que la
politique est fermée.
Un autre concept introduit par le modèle R-BAC est celui de session. Pour pouvoir
réaliser une action sur un objet, un utilisateur doit d’abord créer une session et, dans
cette session, activer un rôle qui a reçu l’autorisation de réaliser cette action sur cet
objet. Si un tel rôle existe et si cet utilisateur a été affecté à ce rôle, alors cet utilisateur
aura la permission de réaliser cette action sur cet objet une fois ce rôle activé.
Lorsqu’un nouveau sujet est créé dans le SI, il suffit d’affecter des rôles au sujet
pour que ce sujet puisse accéder au SI conformément aux permissions accordées à cet
ensemble de rôles. Comparé au modèle I-BAC, la gestion de la politique d’autorisation
s’en trouve simplifiée puisqu’il n’est plus nécessaire de mettre à jour cette politique
chaque fois qu’un nouveau sujet est créé.
Dans le cas général, n’importe quel ensemble de rôles peut être affecté à un
utilisateur et un utilisateur peut activer dans une session n’importe quel sous-ensemble des
rôles qui lui ont été affectés. Le modèle R-BAC introduit la notion de contrainte pour
spécifier des politiques d’autorisation incluant des situations plus restrictives. Ainsi,
une contrainte de séparation statique spécifie que certains rôles, par exemple médecin
et infirmier, ne peuvent pas être simultanément affectés à un utilisateur. Une contrainte
de séparation dynamique spécifie que, même si certains rôles peuvent être affectés à
un même utilisateur, par exemple médecin libéral et chirurgien, ces rôles ne peuvent
pas être activés simultanément dans une même session.
Dans R-BAC, il est également possible d’organiser les rôles de façon hiérarchique.
Les rôles héritent des autorisations des autres rôles qui leur sont hiérarchiquement
inférieurs. Lorsqu’un rôle r est hiérarchiquement supérieur à un rôle r , on dit que1 2
r est un rôle senior der .1 2
Le modèle R-BAC constitue aujourd’hui un standard [FER 01]. De nombreux SI
mettent en œuvre ce standard, par exemple Unix Solaris à partir de la version 8 ou
l’API Authorization Manager RBAC de Windows Server 2003.18 Sécurité des SI
1.2.3. Modèle T-BAC
Dans les modèles I-BAC et R-BAC, les actions correspondent généralement à des
commandes élémentaires, comme la lecture du contenu d’un objet ou l’écriture dans
un objet.
Dans les applications récentes, le besoin apparaît de contrôler la réalisation
d’actions composites, appelées tâches ou activités. Par exemple, dans une agence de voyage,
la tâche d’achat d’un billet d’avion se décompose en plusieurs actions plus
élémentaires telles que la réservation du billet, le paiement du billet et l’édition d’une facture.
Le besoin de contrôle sur des activités composites est en particulier présent dans les
applications de type workflow [ATL 96].
Le modèle T-BAC (task based access control, voir [THO 97a]) fut le premier
modèle à introduire le concept de tâche. D’autres modèles ont ensuite été développés
pour contrôler l’exécution des activités dans un workflow (voir [BER 99, ATL 00]).
En particulier, l’utilisateur ne doit obtenir une permission que lorsque c’est nécessaire
pour poursuivre l’exécution de l’activité considérée (just in time permission). Ainsi,
dans l’exemple d’achat d’un billet d’avion, la permission d’éditer une facture ne doit
être activée qu’après la réservation et l’achat du billet.
Il est parfaitement possible de combiner les concepts de rôle et de tâche pour
spécifier une politique d’autorisation et obtenir ainsi un modèle que l’on peut appeler
TR-BAC (task and role based access control). Dans ce cas, les permissions affectées
aux rôles portent sur la réalisation des tâches [BER 97]. Diverses contraintes peuvent
être spécifiées pour par exemple spécifier qu’un même sujet doit intervenir dans
certaines actions nécessaires à la réalisation de la tâche (éventuellement avec des rôles
différents).
1.2.4. Modèle V-BAC
Les modèles R-BAC et T-BAC ont respectivement introduit les concepts de rôle
et de tâche pour structurer les sujets et les actions. Pour faciliter l’expression et la
gestion d’une politique d’autorisation, nous avons également besoin d’un concept pour
structurer les objets.
Parmi les modèles de contrôle d’accès proposant une telle structuration des
objets, on peut citer le modèle de sécurité proposé par SQL pour les bases de données
relationnelles. L’expression d’une politique de sécurité en SQL repose sur le concept
de vue. Nous désignerons donc par V-BAC (view based access control) ce type de
modèle de contrôle d’accès.
Intuitivement, dans une base de données relationnelle, une vue correspond au
résultat d’une requête SQL auquel on a donné un nom. Ce concept de vue est ensuiteLes modèles de sécurité 19
utilisé pour structurer l’expression d’une politique d’autorisation à l’aide des
instructions GRANT (qui permet d’accorder une nouvelle permission à un utilisateur) et
REVOKE (qui permet de supprimer une permission que possédait un utilisateur). Une
vue constitue donc un moyen efficace pour accorder un accès à l’ensemble des objets
contenus dans la vue. Noter que ces objets sont parfois virtuels dans la mesure où une
vue SQL n’est pas matérialisée.
SQL/3 [LEN 04], qui correspond à la dernière évolution de la norme SQL, propose
d’étendre le modèle V-BAC en combinant les concepts de vue et de rôle pour structurer
les objets et les sujets. On peut ainsi définir le modèle VR-BAC (view and role based
access control).
Le concept de vue ne se limite pas au modèle relationnel. On pourrait aussi
l’utiliser dans un système d’exploitation. Actuellement, la plupart des systèmes
d’exploitation ne proposent que le concept de répertoire pour structurer l’expression de la
politique d’autorisation. En utilisant le concept de vue, on pourrait par exemple
définir une vue contenant l’ensemble des objets ayant pour suffixe .doc et appartenant au
répertoire /pierre/projet1 et utiliser cette vue dans l’expression de la politique
d’autorisation du système d’exploitation. Dans ce cas, une syntaxe reposant sur XPath pourrait
être proposée pour exprimer la politique d’autorisation. C’est déjà l’approche utilisée
pour spécifier une politique d’autorisation pour documents XML (voir par exemple
[BER 00, GAB 04]).
1.2.5. Modèle T-MAC
Dans les applications récentes, il est souvent nécessaire de considérer plusieurs
organisations simultanément. Par exemple, dans les applications de services web, un
utilisateur d’une certaine organisation peut souhaiter accéder aux données appartenant à
une autre organisation. Une organisation est une entité structurée. Par exemple, un
hôpital correspond à une organisation qui se décompose en plusieurs sous-organisations :
les différents départements de l’hôpital, les différents services de ces départements,
etc. Chaque organisation gère en général sa propre politique d’autorisation. Certaines
organisations peuvent également être créées dynamiquement en fonction des activités
que doit prendre en charge l’hôpital. Par exemple, une équipe de soins peut être créée
pour prendre en charge un patient particulier. Cette organisation pourra ensuite être
dissoute une fois les activités réalisées.
Remarquons que les autorisations d’un sujet dépendent non seulement du rôle du
sujet mais également de l’organisation dans laquelle ce sujet exerce son rôle. Ce
problème a été identifié dans le modèle T-MAC.
Le modèle T-MAC (team based access control, voir [THO 97b]) introduit la
notion d’équipe. Dans T-MAC, des autorisations sont associées aux rôles ainsi qu’aux20 Sécurité des SI
équipes. Les autorisations que possède un sujet résultent de la combinaison des
autorisations associées aux rôles exercés par le sujet et des autorisations associées à
l’équipe à laquelle est affecté le sujet. Plusieurs combinaisons (par exemple, l’union
des autorisations) sont envisagées.
En fait, le modèle T-MAC est incorrect car il introduit deux relations binaires :
rôle-autorisation et équipe-autorisation. Si l’on introduit la notion d’équipe, il est en
fait nécessaire de considérer une relation ternaire équipe-rôle-autorisation pour
spécifier que les autorisations dépendent non seulement du rôle mais aussi de l’équipe
dans laquelle est exercé ce rôle. A l’aide d’une telle relation ternaire, on pourra ainsi
facilement spécifier que les autorisations du rôle médecin changent suivant qu’il s’agit
d’un médecin dans une équipe de garde ou d’un médecin dans une équipe d’urgence.
Cette imperfection du modèle T-MAC a été corrigée dans le modèle Or-BAC, que
nous allons présenter dans la section ci-après.
1.2.6. Modèle Or-BAC
Le modèle Or-BAC (organization based access control, voir [KAL 03]) reprend
les concepts de rôle, d’activité, de vue et d’organisation introduits respectivement
dans les modèles R-BAC, T-BAC, V-BAC et T-MAC. Dans Or-BAC (voir figure 1.1),
l’expression d’une politique d’autorisation est centrée sur le concept d’organisation
(contrairement à R-BAC où la politique d’autorisation est centrée sur le concept de
rôle).
Les concepts de rôles, de vues et d’activités sont des concepts organisationnels.
Chaque organisation définit ainsi les rôles, les activités et les vues dont elle souhaite
réglementer l’accès en appliquant une politique d’autorisation. Le modèle Or-BAC
introduit donc trois relations relevant-role, relevant-activity et relevant-view pour
spécifier respectivement les rôles, les activités et les vues gérés par l’organisation.
Ensuite, chaque organisation spécifie les affectations des sujets aux rôles en
utilisant la relation ternaire empower. On peut remarquer que cette modélisation permet,
par exemple, de considérer qu’un même sujet est affecté à des rôles différents suivant
l’organisation considérée. De façon similaire, deux autres relations ternaires consider
et use permettent de respectivement spécifier, pour chaque organisation, les relations
entre action et activité d’une part, et entre objet et vue d’autre part.
Le modèle Or-BAC offre également la possibilité de spécifier des role-definition,
view-definition et activity-definition. Une role-definition est une condition logique qui,
si elle est satisfaite, permet de conclure qu’un sujet se trouve automatiquement affecté
au rôle correspondant à la role-definition. De façon similaire, une view-definition et
une activity-definition correspondent à des conditions logiques pour gérer
respectivement les vues et les activités.Les modèles de sécurité 21


Activity Context
Role View Permission
Consider
Organization Empower Use

Action
Subject Is_permitted Object
Figure 1.1. Le modèle Or-BAC
Une politique d’autorisation s’exprime en spécifiant, pour chaque organisation
considérée, les activités que les rôles ont la permission de réaliser sur les vues. La
politique d’autorisation s’exprime donc de façon complètement indépendante des
ensembles de sujets, actions et objets gérés par le SI. On parle ainsi de politique
d’autorisation organisationnelle.
Le modèle propose une règle de passage pour dériver automatiquement, d’une
politique d’autorisation organisationnelle, les permissions concrètes s’appliquant aux
sujets, actions et objets. Cette règle spécifie que, dans une organisation donnée, si un
sujet est affecté à un certain rôle, un objet est utilisé dans une certaine vue, une action
implante une certaine activité et si la politique d’autorisation de cette organisation
spécifie que ce rôle a la permission de réaliser cette activité sur cette vue, alors on
peut dériver que ce sujet a la permission de réaliser cette action sur cet objet.
Dans Or-BAC, on peut également définir des hiérarchies de rôles (comme dans
RBAC), mais aussi d’activités, de vues et d’organisations. Chacune de ces hiérarchies
est associée à un mécanisme d’héritage des permissions (voir [CUP 04a] pour plus de
détail). La définition de ces hiérarchies permet une expression plus modulaire de la
politique d’autorisation organisationnelle.22 Sécurité des SI
Le modèle Or-BAC a été utilisé pour exprimer des politiques de sécurité réseau et
générer des règles de configuration de pare-feu, les composants de sécurité réseau qui
mettent en œuvre cette politique [CUP 04b].
1.2.7. Modèles d’autorisations dynamiques et contextuelles
Dans la pratique, de nombreuses autorisations ne sont pas statiques mais dépendent
de conditions qui, si elles sont satisfaites, permettent d’activer dynamiquement les
autorisations. Dans ce cas, on parle souvent d’autorisations contextuelles.
Ainsi, les autorisations peuvent dépendre de contextes temporels (par exemple
permission pendant les heures de travail), contextes géographiques (par exemple,
permission à l’intérieur de l’enceinte sécurisée de l’entreprise), de contextes
provisionnels (permission si d’autres actions ont au préalablement été réalisées comme dans le
cas d’un workflow). D’autres types de contextes peuvent également être définis (voir
[CUP 03b] pour une proposition de taxonomie).
Pour représenter ces autorisations contextuelles, plusieurs modèles de contrôle
d’accès à base de règles ont été proposés (modèles de type Rule-BAC, voir [BER 03,
JAJ 01]). Dans ces modèles, une politique d’autorisation correspond à un ensemble de
règles de la formecondition→ permission qui spécifient qu’une permission peut
être dérivée lorsqu’une certaine condition est satisfaite.
Les modèles de type Rule-BAC reposent sur la logique du premier ordre qui est,
dans le cas général, indécidable. Face à ce problème, la plupart de ces modèles
proposent d’utiliser Datalog pour avoir une procédure de décision en temps polynomial
à condition que les règles respectent certaines restrictions syntaxiques (voir [ULL 89]
pour plus de détail).
Comparés aux modèles présentés dans les sections précédentes, les modèles
RuleBAC présentent une expressivité plus grande, utile pour spécifier des autorisations
contextuelles. En contrepartie, on perd malheureusement la structuration de la
politique d’autorisation que permettaient l’introduction des concepts de rôle, d’activité,
de vue et d’organisation.
Le modèle Or-BAC offre également la possibilité d’exprimer des autorisations
contextuelles. Pour cela, le concept de contexte est explicitement introduit dans le
modèle. La définition d’un contexte correspond à une condition logique qui permet de
conclure que l’on se trouve dans le contexte lorsque cette condition est satisfaite.
Remarquons que chaque organisation définit ses contextes, ce qui permet de modéliser
que la définition d’un contexte tel que heure de travail peut varier d’une organisation
à une autre.Les modèles de sécurité 23
En fait, dans le paragraphe 1.2.6, nous avons volontairement simplifié l’expression
d’une politique d’autorisation organisationnelle en Or-BAC. Dans le cas général, une
autorisation spécifie qu’un rôle a la permission de réaliser une activité sur une vue dans
un contexte particulier. La règle de passage pour dériver les permissions concrètes
s’appliquant aux sujets, actions et objets est aussi légèrement plus complexe que celle
présentée au paragraphe 1.2.6 puisqu’une permission ne doit être activée que lorsque
la condition contextuelle correspondante est satisfaite (voir [CUP 03b]).
Pour conclure cette section, remarquons qu’Or-BAC introduit les mêmes
contraintes syntaxiques que celles imposées par Datalog de manière à conserver une procédure
de décision calculable en temps polynomial même lorsque l’on considère des
autorisations contextuelles. Le modèle Or-BAC offre donc une expressivité comparable à celle
des autres modèles de type Rule-BAC tout en proposant une expression très structurée
de la politique d’autorisation.
1.2.8. Modèles d’autorisations positives et négatives
Initialement, les modèles de contrôle d’accès ne permettaient que d’exprimer des
autorisations positives (permissions). Récemment, des modèles offrant également la
possibilité d’exprimer des autorisations négatives (interdictions) ont été proposés,
comme [BEN 03, BER 99, JAJ 01].
Combiner des autorisations positives et négatives dans une politique d’autorisation
est intéressant pour plusieurs raisons :
– certaines politiques d’autorisation sont plus faciles à décrire en termes
d’interdictions que de permissions. Par exemple, considérer une règle spécifiant que l’accès
à une certaine vidéo est interdite aux personnes de moins de 12 ans ;
– lorsque la politique d’autorisation doit être mise à jour, il est parfois plus simple
d’insérer une interdiction que de supprimer une permission existante ;
– la combinaison des permissions et interdictions constitue un moyen simple pour
exprimer des règles présentant des exceptions. Par exemple, on peut considérer les
règles suivantes : (1) les infirmiers ont l’interdiction d’accéder au dossier médical des
patients, mais (2) en situation d’urgence, les infirmiers ont la permission d’accéder au
dossier médical du patient concerné par l’urgence. Dans ce cas, la règle (2) doit être
interprétée comme une exception de la règle (1).
Dans la suite, on dira que la politique d’autorisation est mixte lorsqu’elle inclut des
autorisations positives et négatives. Remarquons que dans une politique d’autorisation
mixte, on peut faire l’hypothèse que la politique est ouverte ou fermée. Une politique
ouverte considère qu’un accès est accepté si la politique d’autorisation ne permet pas
de dériver que l’accès est explicitement interdit. Il s’agit de l’hypothèse inverse de
celle de politique fermée introduite au paragraphe 1.2.1.24 Sécurité des SI
Un nouveau problème apparaît lorsque l’on considère des politiques d’autorisation
mixtes : celui de la gestion des conflits entre les autorisations positives et négatives.
En effet, pour un sujet, une action et un objet donnés, il est possible que la politique
d’autorisation permette de dériver que l’accès est à la fois permis et interdit.
Pour résoudre ces situations de conflits, plusieurs stratégies ont été proposées dans
la littérature. Certaines approches (voir par exemple [JAJ 01]) ne considèrent que
des stratégies simples, telles que les interdictions l’emportent toujours sur les
permissions, ou les permissions l’emportent toujours sur les interdictions. Ces stratégies
ne conviennent pas pour traiter le problème des exceptions. En effet, si une
interdiction agit comme exception à une permission, alors cette interdiction doit l’emporter
sur cette permission. Mais, dans le cas contraire, c’est-à-dire si une permission agit
comme exception à une interdiction, alors c’est la permission qui doit l’emporter sur
l’interdiction.
Pour rendre compte de stratégies plus élaborées permettant de gérer les exceptions,
plusieurs modèles [BEN 03, CUP 03a] ont proposé d’introduire des priorités entre les
règles de la politique d’autorisation.
La plupart des pare-feu donnent des exemples représentatifs de mise en œuvre de
ce type de stratégies. En effet, on peut interpréter les règles de filtrage d’un pare-feu
comme un ensemble d’autorisations positives (dans le cas où la décision de la règle
de filtrage est d’accepter le paquet) ou négatives (dans le cas où la décision est de
rejeter le paquet). La priorité entre règles de filtrage correspond en général à l’ordre
dans lequel les règles ont été écrites. Ainsi, lorsque plusieurs règles s’appliquent sur
un même paquet, la décision finale correspond à celle de la première règle applicable
(stratégie dite du first matching).
L’ordonnancement des règles constitue donc un moyen simple, mais efficace pour
résoudre les conflits dans une politique d’autorisation mixte. Cependant, cette
ordonnancement rend la politique d’autorisation plus complexe à exprimer et à mettre à
jour. En effet, d’autres problèmes peuvent apparaître : le masquage (shadowing) et la
redondance. L’anomalie de masquage apparaît lorsqu’une règle devient inapplicable
car des règles plus prioritaires seront systématiquement appliquées avant elle.
L’anomalie de redondance existe lorsqu’une règle peut être supprimée sans que cela change
la politique d’autorisation. Par exemple, si l’on considère les deux règles suivantes :
(1) l’accès à la vidéo V est interdit aux personnes de moins de 12 ans, (2) l’accès
à la vidéo V est interdit aux personnes de moins de 16 ans. Alors la règle (1) est
redondante.
Détecter ces anomalies dans une politique d’autorisation est important car (1) elles
sont souvent révélatrices d’erreur dans l’expression de la politique d’autorisation, (2)
même si elles ne correspondent pas à des erreurs, l’élimination de ces anomalies
permet de réduire le nombre de règles.Les modèles de sécurité 25
Dans le cas des pare-feu, [ALS 04] propose un algorithme pour détecter certaines
anomalies dans un ensemble de règles de filtrage. Cet algorithme n’étant
malheureusement pas complet, un autre algorithme permettant de détecter et éliminer toutes les
anomalies a ensuite été proposé dans [CUP 05a].
1.3. Contrôle de flux
Pour bien comprendre l’intérêt des modèles de contrôle de flux, il faut d’abord
revenir sur le concept de sujet introduit dans le paragraphe 1.2.1. Nous avons
indiqué qu’un sujet correspondait à un utilisateur ou une application s’exécutant pour le
compte d’un utilisateur.
Dans le cas d’un utilisateur, on suppose que celui-ci peut essayer de violer la
politique d’autorisation en accédant illégalement à des objets. Mais s’il obtient
légalement une information, on suppose également qu’il ne va pas volontairement
transmettre cette information à un autre utilisateur qui n’aurait pas le droit de connaître
cette information. Par exemple, on suppose qu’un médecin ne va pas volontairement
transmettre le contenu du dossier médical d’un de ses patients à une personne non
autorisée. Il faut naturellement que l’organisation mette en place des procédures pour
que cette hypothèse soit justifiée (par exemple l’habilitation, le serment d’Hippocrate
mais aussi la sensibilisation des utilisateurs aux risques informatiques).
En revanche, on ne peut pas toujours faire les mêmes hypothèses si le sujet est une
application s’exécutant pour le compte d’un utilisateur. En effet, certaines applications
peuvent être piégées. On parle alors de cheval de Troie. Un cheval de Troie peut avoir
divers objectifs malveillants visant à porter atteinte à la confidentialité, à l’intégrité
ou bien à la disponibilité des informations du SI. Dans le cas de la confidentialité,
l’objectif de l’application est d’accéder à des informations et de volontairement
transmettre ces informations vers un utilisateur qui n’a pas la permission d’y accéder. Cet
utilisateur est le bénéficiaire du piège ; il peut s’agir par exemple du concepteur de
l’application, d’un agent chargé de sa maintenance ou d’un utilisateur qui a réussi à
remplacer l’application légitime par une application piégée.
Pour illustrer ce problème, considérons un médecin qui utilise son SI pour
consulter les dossiers médicaux de ses patients. Supposons également que ce médecin puisse
utiliser son SI pour consulter un dictionnaire médical via Internet et que ce médecin
utilise une seule application pour à la fois consulter les dossiers médicaux et accéder
au dictionnaire médical. Si cette application est piégée, alors il est possible que cette
application utilise la connexion Internet pour transmettre, à l’insu du médecin, des
informations contenues dans les dossiers médicaux.
Les modèles de contrôle d’accès présentés dans la section 1.2 ne permettent pas
d’empêcher les actions malveillantes d’une telle application piégée. En effet, cette26 Sécurité des SI
dernière peut réaliser son attaque sans violer la politique d’autorisation : elle consulte
légitimement les dossiers médicaux et ensuite utilise l’accès Internet qui permet
d’accéder au dictionnaire médical pour transmettre les dossiers médicaux vers le
bénéficiaire du piège. Cela ne veut pas dire que ces modèles de contrôle d’accès sont inutiles.
Mais, si l’on veut empêcher les attaques par chevaux de Troie, il faut seulement utiliser
ces modèles pour définir la politique d’autorisation des utilisateurs et des applications
de confiance, c’est-à-dire des applications que l’on peut garantir sans piège.
Pour contrôler l’exécution des applications qui ne sont pas de confiance, d’autres
modèles, appelés modèles de contrôle de flux (ou MAC, mandatory access control),
ont été définis. L’objectif de ces modèles est précisément d’assurer le confinement
des applications pour empêcher les attaques par chevaux de Troie. Comme plusieurs
modèles de type MAC pour la confidentialité ont été définis, nous présentons ici les
principaux : modèle de Bell et LaPadula, non-interférence, Bell et LaPadula étendu
et causalité. Nous présentons ensuite les modèles de type MAC pour l’intégrité. Les
modèles de contrôle de flux pour la confidentialité et l’intégrité sont complémentaires :
ils doivent être combinés pour garantir ces deux propriétés de sécurité dans le SI.
1.3.1. Modèle de Bell et LaPadula
Le modèle de Bell et LaPadula [BEL 75] fut le premier modèle de type MAC
proposé. L’objectif de ce modèle est de définir des contraintes pour contrôler l’exécution
des applications de manière à empêcher les attaques par chevaux de Troie contre la
confidentialité.
Le modèle de Bell et LaPadula considère des politiques de sécurité de type MAC
particulière, dite politique de sécurité multiniveaux. Dans ce type de politique
d’autorisation, on introduit un ensemble partiellement ordonné de niveaux de sécurité, par
exemple non-classifié (NC), confidentiel (C) et secret (S). Tous les utilisateurs doivent
avoir reçu un tel niveau de sécurité pour pouvoir accéder au SI ; il s’agit du niveau
d’habilitation de l’utilisateur. On affecte également un niveau de sécurité à tous les
objets gérés par le SI ; il s’agit du niveau de classification de l’objet.
La politique d’autorisation associée aux utilisateurs est simple : un utilisateur n’a
la permission de lire un objet que si son niveau d’habilitation est supérieur ou égal
au niveau de classification de l’objet lu. Sinon, l’utilisateur a l’interdiction de lire cet
objet. On appelle habituellement cette condition no read up.
En revanche, on suppose que les applications peuvent être piégées. Une application
travaille pour le compte d’un utilisateur. Le niveau d’exécution, encore appelé niveau
courant, d’une application est choisi par l’utilisateur mais doit être inférieur ou égal
au niveau d’habilitation de cet utilisateur.6

Les modèles de sécurité 27



Figure 1.2. Passage d’une politique I-BAC vers une politique MAC
Pour empêcher une application de lire des objets interdits, on impose qu’une
application ne peut lire un objet que si son niveau courant est supérieur au niveau de
classification de l’objet. On appelle également cette condition no read up. Comme le
niveau courant d’une application est toujours inférieur ou égal au niveau d’habilitation
de l’utilisateur exécutant l’application, la condition de no read up sur les applications
implique la condition de no read up sur les utilisateurs.
Mais, dans le modèle de Bell et LaPadula, on souhaite également empêcher qu’un
cheval de Troie puisse transmettre le contenu d’un objet lu vers un utilisateur u qui
aurait l’interdiction de lire cet objet. Dans ce modèle, on suppose que le cheval de
Troie effectuera cette transmission illégale en recopiant le contenu de l’objet lu dans
un autre objet queu pourra lire. Pour interdire ce flux illégal, on impose qu’une
application ne peut écrire dans un objet que si le niveau courant de l’application est
inférieur ou égal au niveau de classification de l’objet. On appelle cette condition no
write down ou propriété étoile.
Le but unique de la condition de no write down est d’empêcher un cheval de Troie
de réaliser une attaque contre la confidentialité. Elle n’empêche pas une attaque contre
l’intégrité au cours de laquelle une application tenterait de modifier illégalement des
objets. Ce n’est pas l’objectif du modèle de Bell et LaPadula d’empêcher ce type
d’attaque. Des modèles ont été définis pour cela (voir paragraphe 1.3.5).
Le passage d’une politique d’autorisation de type I-BAC vers une politique
multiniveaux de type MAC est toujours possible. A titre d’exemple, considérons le schéma
de la figure 1.2. Z1, Z2 et Z3 sont trois ensembles d’objets et l’on suppose que
Z1∩Z2 =∅, Z1∩Z3 =∅ et Z3⊂ Z2. On suppose que le système est utilisé
par quatre utilisateurss1,s2,s3 ets4. Supposons par exemple, que dans une politique
d’autorisation de type I-BAC,Z1 est l’ensemble des objets accessibles en lecture par
s1, Z2 est celui accessible en lecture par s2 et Z3 celui accessible par s3 et s4 (on
suppose ques3 ets4 ont les mêmes droits d’accès en lecture).28 Sécurité des SI
Dans ce cas, on introduit quatre niveaux de sécuritéL1,L2,L3 etL4, avecL3<
L2,L4 < L1 etL4 < L2.s1 est habilité au niveauL1,s2 au niveauL2 et,s3 ets4
au niveauL3. Les objets reçoivent les classifications suivantes :
– objets deZ1−Z2 classésL1 ;
– objets deZ2−(Z1∪Z3) classésL2 ;
– objets deZ3 classésL3 ;
– objets deZ1∩Z2 classésL4.
Soit par exemple une application exécutée par s1 au niveau L1. Ce programme
pourra lire l’ensemble des objets de Z1. En revanche, il ne pourra pas écrire dans
Z1∩ Z2 pour éviter un éventuel flux vers s2 (dans l’hypothèse où le programme
serait piégé).
On peut remarquer que le passage I-BAC à MAC est faisable mais peut générer
dans la pratique un grand nombre de niveaux.
Certaines tentatives de mise en œuvre du modèle de Bell et LaPadula ont réussi à
voir le jour. Parmi elles, on peut citer des systèmes d’exploitation tels que Multics et
Scomp et des systèmes de gestion de bases de données tels que Trusted Oracle.
1.3.2. Modèle de non-interférence
Dès la définition de leur modèle, Bell et LaPadula avaient observé que celui-ci ne
permettait de contrôler que les chevaux de Troie qui essayent de transmettre
illégalement des informations par recopie dans un fichier. D’autres moyens de transmettre
illégalement des informations existent que peut exploiter un cheval de Troie. Ces
moyens sont connus sous le nom de canaux cachés. Le principe général d’un canal
caché consiste à transmettre des informations de façon codée sous forme de 0 et de 1
en frappant aux murs.
Traditionnellement, on distingue deux types de canaux cachés : canaux cachés de
stockage et canaux temporels. Un canal de stockage utilise une ressource non
protégée du système (par exemple, en bloquant/débloquant l’accès à un registre) pour
transmettre des informations. Un canal temporel exploite une ressource temporelle
(par exemple, en faisant varier le temps d’exécution d’une application).
Plusieurs modèles de contrôle de flux ont été proposés pour prendre en compte
les canaux cachés [JOH 88, NEU 80, SUT 86]. Le plus connu est le modèle de
noninterférence [GOG 84, FIN 89, HAI 86]. Ce modèle permet de renforcer le modèle
de Bell et LaPadula en empêchant les attaques des chevaux de Troie contre la
confidentialité, même via des canaux cachés de stockage. En revanche, le modèle de
noninterférence ne contrôle pas les canaux cachés temporels.Les modèles de sécurité 29
Le principe du modèle est le suivant. Soient A et A deux applications s’exé-1 2
cutant respectivement aux niveaux L et L . Si L = L , alors A et A peuvent1 2 1 2 1 2
s’échanger des informations. SiL > L , alors le flux d’informations deA versA1 2 2 1
est autorisé. En revanche, tout flux de A vers A est interdit. Enfin si L et L ne1 2 1 2
sont pas comparables, aucun flux entreA etA n’est autorisé.1 2
Plusieurs formalisations du principe de non-interférence ont été proposées. On
présente ici celle de Goguen et Meseguer [GOG 84]. SoitSI un système
d’information. CeSI permet aux utilisateurs d’exécuter des applications. SoitSeq(SI)
l’exécution d’une certaine séquence d’applications dansSI. Chaque application est exécutée
avec un certain niveau de sécurité. Si L est un certain niveau de sécurité, on définit
Purge(Seq(SI),L), l’exécution obtenue en supprimant deSeq(SI) toutes les
applications qui n’ont pas été exécutées avec un niveau inférieur ou égal àL.
Enfin, au cours de l’exécution d’une séquence d’applications, un utilisateurs
obtient certains résultats (outputs) fournis par leSI. Les résultats obtenus pars au cours
de l’exécution d’une séquenceSeq(SI) sont notésOutput(s,Seq(SI)).
On dit alors que le système satisfait la propriété de non-interférence si pour toute
séquenceSeq et pour tout utilisateurs, on a :
Output(s,Seq(SI)) =Output(s,Purge(Seq(SI),L))
oùL représente le niveau d’habilitation du sujets. Intuitivement, cette condition
exprime que, pour un utilisateur ayant un niveau d’habilitationL, tout se passe comme si
seules des applications de niveau inférieur àL avaient été exécutées dans le système.
La propriété de non-interférence est difficile à vérifier dans la pratique car elle
concerne l’exécution d’une séquence d’applications. Des conditions suffisantes, dite
de unwinding plus simples ont été proposées [GOG 84, HAI 86] pour vérifier qu’une
application particulière vérifie la condition de non-interférence. Plus récemment, les
travaux de Smith et Volpano [VOL 97] basés sur la théorie des types permettent de
vérifier que le code source d’un programme est non interférant. Ces travaux peuvent
être appliqués à l’analyse statique de codes mais les conditions à vérifier sont
pessimistes : l’exécution de certains programmes peut ne pas être interférante alors que ces
programmes seront rejetés par l’analyse statique.
1.3.3. Modèle de Bell et LaPadula étendu
La principale limite de la non-interférence est que la condition que ce modèle
1introduit est très restrictive à mettre en œuvre . Dans la pratique, elle a été uniquement
1. La même remarque est valable pour le modèle de Bell et LaPadula.6
6
30 Sécurité des SI
appliquée avec succès sur de petits systèmes, par exemple des logiciels embarqués à
bord de carte à puce. Toutes les autres tentatives d’appliquer la non-interférence à
des systèmes plus importants tels que des systèmes d’exploitation ou des systèmes de
gestion de bases de données n’ont pas abouti à des solutions commercialisables car
les solutions développées se sont avérées trop contraignantes à utiliser.
Pour de tels systèmes, le besoin de modèles de sécurité plus flexibles est évident.
Pourquoi ? Parce que la non-interférence adopte le point de vue extrême que tous les
programmes sont potentiellement malveillants et peuvent contenir un cheval de Troie
cherchant à transmettre illégalement des informations. Une telle hypothèse n’est pas
réaliste dans la pratique. Plus précisément, elle rend impossible la spécification de
certaines fonctionnalités nécessaires dans la plupart des systèmes, par exemple des
fonctions de chiffrement ou de déclassification. En effet, ces fonctions ont pour
objectif de produire en sortie des résultats qui auront un niveau de classification strictement
inférieur au niveau de classification des données fournies en entrées de ces fonctions.
Un modèle plus réaliste est le modèle de Bell et LaPadula étendu proposé dans
[BEL 86]. Au lieu d’associer un niveau courant à chaque application, ce modèle
associe un intervalle de niveaux[L ,L ] avecL ≤L . Une application peut ainsi lire tout1 2 1 2
objet dont la classification est inférieure àL et écrire dans tout objet de classification2
supérieure àL . Ceci permet la déclassification.1
Si l’on soupçonne une application de pouvoir contenir un cheval de Troie, alors
il faut imposer queL = L . L’exécution de l’application est alors contrôlée par les1 2
mêmes conditions de sécurité que le modèle de Bell et LaPadula strict.
En revanche, si L = L , alors l’application ne doit pas contenir de cheval de1 2
Troie. On dit alors que l’application est de confiance. Une fonction de déclassification
peut ainsi être implantée par une application de confiance.
Il faut empêcher qu’une application qui contient un cheval de Troie puisse
appeler une application de confiance, par exemple une fonction de déclassification, pour
transmettre illégalement des informations interdites. Pour cela, il faut imposer une
condition pour contrôler l’invocation d’une application par une autre application : si
0A et A sont deux applications associées respectivement aux intervalles [L ,L ] et1 2
0 0 0 0 0[L ,L ], alorsA peut invoquerA si et seulement siL ≤L etL ≤L . Ainsi, une1 21 2 1 2
application qui n’est pas de confiance (c’est-à-dire telle queL =L ) ne peut jamais1 2
0 0invoquer une application de confiance (c’est-à-dire telle queL =L ).1 2
Le modèle de Bell et LaPadula étendu est proche du modèle actuellement mis en
œuvre dans OLS (Oracle label security) [SEC 02], le module implantant une politique
de sécurité multiniveaux sous Oracle à partir de la version 8i. Ce modèle est beaucoup
plus flexible à mettre en œuvre que les modèles de Bell et LaPadula strict et de
noninterférence.Les modèles de sécurité 31
On peut cependant remarquer que le modèle de Bell et LaPadula étendu présente
la limite suivante : il est impossible de modéliser une application réalisant certains
transferts d’informations entre deux niveauxL etL qui ne sont pas comparables. En1 2
effet, on ne peut pas considérer une applicationA travaillant sur [L ,L ] car[L ,L ]1 2 1 2
n’est pas un intervalle siL etL ne sont pas comparables.1 2
1.3.4. Modèle de causalité
L’intérêt du modèle de Bell et LaPadula étendu est qu’il est plus souple que
noninterférence. Mais il présente aussi un inconvénient car, comme le modèle de Bell et
LaPadula strict, il ne permet pas de contrôler les canaux cachés.
Le modèle de causalité [BIE 91, BIE 92a] est un modèle de contrôle de flux basé
sur l’analyse des dépendances causales qui apporte une solution au problème des
canaux cachés (y compris temporels) et qui est plus souple à mettre en œuvre que
noninterférence. A chaque sujets, on associe un ensemble d’objets ques a le droit
d’observer noté Droit(s). On associe également à s un ensemble Obs(s) qui représente
l’ensemble des observations ques a réalisé sur le système.
La propriété de causalité est satisfaite siObs(s) dépend causalement deDroit(s)
(voir [BIE 91] pour plus de détails). En fonction des objets qui sont inclus dans
l’ensemble Droit(s), il est possible de définir plusieurs politiques de contrôle de flux
différentes :
– causalité sur les inputs [BIE 91]. Dans ce cas, on suppose, comme dans Bell
et LaPadula ou non-interférence, que seules les données introduites par les
utilisateurs sont de confiance. Toutes les données produites en exécutant des
applications dans le système ne sont pas de confiance car elles peuvent avoir été
calculées par un programme contenant un cheval de Troie. On suppose donc que
0 0Droit(s) = {In(s ) | niv(s ) ≤ niv(s)}, c’est-à-dire : s a le droit
d’obser0ver toutes les données introduites par les autres sujets s ayant un niveau
d’habilitation inférieur ou égal à s. Causalité sur les inputs est une propriété que l’on
peut comparer à non-interférence. Causalité sur les inputs présente cependant
plusieurs avantages (voir [BIE 92a]). En particulier, le modèle permet de considérer
qu’une même donnée peut être introduite par un sujet à plusieurs niveaux de sécurité
différents. Cette possibilité permet de prendre en compte une opération de
déclassification gérée à l’extérieure du SI, chose impossible avec non-interférence;
– causalité étendue. Il est possible d’ajouter àDroit(s) des données produites par
une application de confiance (par exemple, le résultat d’une opération de
déclassification) ;
– possibilité d’exprimer des politiques d’autorisation de type muraille de Chine
[CUP 92]. Dans ce type de politique d’autorisation [BRE 89], il est possible d’accéder
séparément à certaines données mais ces données ne peuvent pas être agrégées en