TAFIM (Technical Architecture Framework for Information

TAFIM
Tristan Debeaupuis
5 mai 1997
TAFIM (Technical Architecture Framework for Information Management) est un modele d'architecture des
systemes d'information concu par la DISA (Defense Information Systems Agency), agence dependant du DoD
(Department of Defense of the United States). Il est obligatoire d'utiliser ce modele au sein du DoD. Ce modele
est repris par l'X/Open comme modele de reference des systemes ouverts. Les seules modications apportees par
l'X/Open sont des modications de publication, il n'y a donc pas de modication du contenu du document. Ce
document est un resume des 1500 pages qui decrivent TAFIM V2.0 avec une attention particuliere pour la DGSA
(DoD Goal Security Architecture), l'architecture cible de securite choisie par le DoD.
Contents
1 Introduction
3
2 Historique de ce document
4
3 Comment est organise TAFIM ?
5
4 Vue d'ensemble de TAFIM
5
5 Le modele de reference de TAFIM
6
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Le modele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.1 L'entite logicielle applicative (ASE) . . . . . . . . . . . .
5.2.2 L' "Application Program Interface" (API) . . . . . . . . .
5.2.3 L'entite applicative de la plate-forme (APE) . . . . . . . .
5.2.4 L'environnement externe (EEI) . . . . . . . . . . . . . . .
5.3 Le modele detaille . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4 Presentation de l'architecture . . . . . . . . . . . . . . . . . . . .
5.5 Les dierents modeles sous l'angle du traitement de l'information
5.5.1 Le modele client/serveur . . . . . . . . . . . . . . . . . . .
5.5.2 Le modele base sur un serveur . . . . . . . . . . . . . . .
5.5.3 Le modele Ma^tre/Esclave et le modele hierarchique . . .
5.5.4 Le modele "peer-to-peer" . . . . . . . . . . . . . . . . . .
5.5.5 Le modele de gestion d'objets distribues . . . . . . . . . .
5.6 Les dierents modeles sous l'angle de la gestion de l'information
5.6.1 Le modele de gestion d'objets distribues . . . . . . . . . .
5.7 Les dierents modeles sous l'angle de la gestion de l'information
5.7.1 Le systeme de gestion des donnees . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
6
7
7
7
8
9
9
9
9
11
11
13
13
14
14
15
15
CONTENTS
5.8
5.9
5.10
5.11
5.12
5.7.2 L'annuaire des donnees . . . . . . . . . .
5.7.3 La securite des donnees . . . . . . . . . .
Les dierents modeles sous l'angle de la securite .
5.8.1 Concepts de base . . . . . . . . . . . . . .
5.8.2 Architecture generique de securite . . . .
Sollicitation de services de securite . . . . . . . .
Les services du systeme d'exploitation . . . . . .
Les services reseaux . . . . . . . . . . . . . . . .
Les services d'administration . . . . . . . . . . .
6 Guide d'implementation de TAFIM
6.1
6.2
6.3
6.4
6.5
6.6
6.7
2
Initialisation du projet. Trame d'architecture
Specication d'architecture . . . . . . . . . .
Architecture cible . . . . . . . . . . . . . . . .
Prise en compte de l'existant . . . . . . . . .
Choix de migration . . . . . . . . . . . . . . .
Planning de deploiement . . . . . . . . . . .
Mise en oeuvre de l'administration . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7 Le modele de securite cible du DoD (La DGSA)
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7.1 Types d'architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.1.1 Architecture abstraite . . . . . . . . . . . . . . . . . . . . . . . . . .
7.1.2 Architecture generique . . . . . . . . . . . . . . . . . . . . . . . . . .
7.1.3 Architecture logique . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.1.4 Architecture specique . . . . . . . . . . . . . . . . . . . . . . . . . .
7.1.5 Processus de developpement de la DGSA . . . . . . . . . . . . . . .
7.1.6 Besoins en securite . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.1.7 Perspectives d'architecture cible et d'evolution . . . . . . . . . . . .
7.1.8 Concepts de securite . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.1.9 Concepts de securite . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2 ES et RS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2.1 Architecture de securite des ES . . . . . . . . . . . . . . . . . . . . .
7.2.2 Description de l'architecture de securite des ES . . . . . . . . . . . .
7.3 Administration de la securite . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3.1 Relations entre les concepts de la DGSA et la gestion de la securite .
7.3.2 L'ISO 7498-2 et les concepts de securite de la DGSA . . . . . . . . .
7.3.3 Outils d'administration de la securite . . . . . . . . . . . . . . . . .
7.3.4 Standardisation des fonctions de securite . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
15
15
16
16
16
17
17
17
17
17
18
18
18
18
18
18
19
19
20
20
20
20
20
20
21
22
23
24
25
25
26
28
28
29
29
29
LIST OF FIGURES
7.4 Systeme de transfert . . . . . . . . . . . . . .
7.4.1 Contexte de securite distribuee . . . .
7.4.2 Support du TS . . . . . . . . . . . . .
7.4.3 Inconvenients du TS . . . . . . . . . .
7.5 Doctrine de securite . . . . . . . . . . . . . .
7.5.1 Les services de securite . . . . . . . .
7.5.2 Doctrine pour les services de securite .
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
29
30
30
31
31
31
32
8 Glossaire
32
9 Documents de reference
33
List of Figures
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Vue d'ensemble de TAFIM . . . . . . . . . . . . . . . . . . . . . . . . .
Modele POSIX P1003.0 . . . . . . . . . . . . . . . . . . . . . . . . . .
Modele TAFIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modele client/serveur . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modele base sur un serveur . . . . . . . . . . . . . . . . . . . . . . . .
Modele Ma^tre/Esclave . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modele hierarchique . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modele peer-to-peer . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modele Objet Distribue . . . . . . . . . . . . . . . . . . . . . . . . . .
Modele Objet Distribue . . . . . . . . . . . . . . . . . . . . . . . . . .
Vue de l'architecture generique de securite . . . . . . . . . . . . . . . .
Les niveaux d'integration . . . . . . . . . . . . . . . . . . . . . . . . .
Les LSE vus sous l'angle de la securite . . . . . . . . . . . . . . . . . .
Relations de securite entre les applications et le systeme d'exploitation
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
6
10
10
11
12
12
13
13
14
16
23
24
28
1 Introduction
Toutes les architectures et modelisations des systemes d'information sont souvent denies speciquement a
un metier. L'approche du DOD est de dire que :
l'on constate qu'au sein du DoD, il y a un nombre important d'applications speciques a des missions,
a des plates-formes et des reseaux de communication.
l'infrastructure physique du systeme d'information du DoD consiste en un nombre important de
systemes peu exibles, reserves a une seule t^ache. Ces systemes ont suivi une migration vers les
systemes ouverts a chaque fois dierente, chacun progressant dans ses propres choix sans prendre g^are
a l'interoperabilite.
2. Historique de ce document
4
le DoD a ressenti la necessite de posseder un modele de reference unique qui garde le souci de s'adapter
a toutes les situations, a tous les metiers du DoD.
Les buts recherches par TAFIM sont :
l'utilisation de principes communs, des assertions et des terminologies dans les denitions des composants de l'architecture technique. (au niveau des Services, Agences, et Etats-Majors).
la denition d'une structure unique pour les composants de l'infrastructure technique du DoD (composants du systeme) et la maniere dont ils sont geres.
le developpement de systemes d'information en accord avec les principes communs an de permettre
l'integration et l'interoperabilite au sein du DoD.
TAFIM ne denit pas une architecture specique a un systeme. Il fournit les services, standards,
guides de conception, composants et congurations qui peuvent ^etre utilises pour guider le developpement
d'architectures techniques qui repondent aux besoins d'une mission.
TAFIM est independant des applications speciques aux missions et de leurs donnees associees. Il cherche
avant tout a promouvoir l'interoperabilite, la portabilite et la juste-mesure des systemes d'information du
DoD. TAFIM est un guide permettant au niveau de l'entreprise de developper des architectures techniques
qui repondent a des besoins precis. L'utilisation de TAFIM peut :
promouvoir l'integration, l'interoperabilite, la modularite et la exibilite,
guider lors de l'achat et la reutilisation de produits du marche,
accelerer la mise en place des technologies de l'information et abaisser ses co^uts.
TAFIM a ete choisi a posteriori par l'X/Open comme modele pour son architecture des systemes ouverts.
Le document TAFIM devrait ^etre publie par l'X/Open sans modications. En general, lorsqu'un document
de normalisation est repris par un autre organisme, il est reecrit, mais aucune autre modication que les
erreurs de retranscriptions n'est eectuee.
2 Historique de ce document
Fin 1994 : premieres discussions au sein du groupe AFNOR/POSIX autour de TAFIM;
Debut 1995 : L'AFNOR mandate Tristan Debeaupuis pour etudier TAFIM et presenter benevolement
au groupe CN 22 GE POSIX TAFIM V2.0;
16 juillet 1996 : redaction de la premiere version de ce document.
28 decembre 1996 : suite des explications sur les dierents modeles d'organisation d'un systeme
d'information;
26 mars 1997 : suite des travaux, mise a jour du document,
9 avril 1997 : integration du volume 4,
5 mai 1997 : version integrant la DGSA,
6 mai 1997 : presentation au groupe AFNOR/POSIX du resultat des travaux sur TAFIM,
juin 1997 : presentation au groupe OSSIR/SUR de la DGSA.
3. Comment est organise TAFIM ?
5
3 Comment est organise TAFIM ?
TAFIM se compose de 8 volumes.
Volume 1 : Vue d'ensemble
Volume 2 : Modele de reference technique
Volume 3 : Concepts d'architecture et guide de conception
Volume 4 : Guide de planication de migration vers une architecture base sur les standards du DoD.
Volume 5 : Guide d'utilisation de TAFIM lors des achats
Volume 6 : Presentation du DGSA (DoD Goal Security Architecture) qui decrit les besoins en terme
de securite des architectures techniques. Ce guide denit un certain nombre de mecanismes et de
fonctions de securite qui guident l'architecte dans le developpement d'architectures speciques.
Volume 7 : Guide d'utilisation des standards. Ce volume presente un certain nombre de prols de
standards utilisables au sein du DoD.
Volume 8 : Guide servant de trame a la denition d'une interface homme/machine.
Ainsi, le schema ci-apres reprend la demarche et les objectifs vises par les dierents documents constituant
TAFIM.
TAFIM
Besoins
Modele
de reference
technique
Vol 2
Vue
d’ensemble
Vol 1
- entreprise
- mission
- fonction
- application
Guide
Securite
Vol 6
Plan
de soutien
Vol 5
Plans
de
reutilisation
Guide
de
planification
Vol 4
Profils
de standards
(Standards
profile)
Vol 7
Guide
sur les
concepts et
la conception
Vol 3
Guide
interface
utilisateur
Vol 8
Architectures
specifiques
- entreprises
- missions
- fonctions
- applications
Conception
du
systeme
Composants
communs
Fournit des composants
utilises pour developper
conduit a
Figure 1: Vue d'ensemble de TAFIM
4 Vue d'ensemble de TAFIM
TAFIM est issu d'une decision du DoD de se doter d'un modele d'architecture technique. TAFIM a pour
point de depart le prol de portabilite des applications (NIST Application Portability Prole - APP) publie
en 1991. L'APP denit un modele de reference et liste un certain nombre de specications (standards)
5. Le modele de reference de TAFIM
6
qui denissent les interfaces, services, protocoles et formats de donnees pour l'implementation de systemes
ouverts.
En utilisant l'APP, la DISA a analyse les documents de reference du DoD, et notamment le DODIIS (DoD
Intelligence Information System Reference Model), modele de reference du systeme d'information de l'agence
de renseignement du DoD.
5 Le modele de reference de TAFIM
5.1 Introduction
TAFIM cherche a atteindre plusieurs buts. Tout d'abord, permettre d'avoir au niveau des agences du DoD, le
m^eme vocabulaire, la m^eme representation d'un systeme d'information, m^eme si les systemes sont dierents.
Le modele de reference technique a pour but de bien representer le systeme d'information an d'identier
les problemes et les solutions que l'on peut apporter en matiere de portabilite des applications, mais aussi
la juste-mesure et leur interoperabilite.
Le modele de reference technique n'est pas une representation d'un seul systeme d'information, mais un
certain nombre de termes communs, d'interfaces communes au sein des dierents elements du systeme
d'information.
Les prols de standards identient les standards et les regles a suivre en terme de services et interfaces
du modele de reference. Cette liste de standards peut ^etre allongee ou reduite pour repondre aux besoins
speciques d'une mission. Le modele de reference technique (TRM - Technical Reference Model) a pour
but de faciliter l'interoperabilite entre des plates-formes speciques au sein de m^emes categories de missions,
mais egalement entre les categories de missions dierentes. Le but de TAFIM est de reduire les co^uts.
5.2 Le modele
TAFIM prend comme point de depart les reexions qui ont ete menees par les groupes POSIX
<http://www.hsc.fr/posix/>. Ces reexions ont m^
uri au travers du document P1003.0 valide par l'IEEE.
Le P1003.0 est maintenant une norme de modelisation des systemes ouverts. Le P1003.0 denit trois classes
d'entites et deux types d'interfaces comme le montre le schema ci-dessous.
Application
Software Entity
API
Services
Application
Program
Interface (API)
Application
Platform Entity
EEI
Services
External
Environment
Interface (EEI)
External
Environment
Figure 2: Modele POSIX P1003.0
Il s'agit de
5. Le modele de reference de TAFIM
l'Entite logicielle applicative (Application Software Entity),
l'Interface de programmation (API),
l'Entite applicative de la plate-forme (Application Platform Entity),
enn de l'Environnement externe (External Environment).
7
Nous allons maintenant presenter ces dierents elements, car ils interviennent dans TAFIM.
5.2.1 L'entite logicielle applicative (ASE)
L'Application Software Entity est une application. Celle-ci repose sur des services du systeme d'exploitation,
des bibliotheques, ...
5.2.2 L' "Application Program Interface" (API)
Les APIs sont denies comme etant les interfaces entre les applicatifs logiciels et la plate-forme supportant
l'application sur laquelle les services sont presents. Originellement, il est deni comme support a la portabilite
des applications, mais l'interoperabilite des applications et des plates-formes se fait egalement au niveau des
API de communication. Les API denissent un jeu complet d'interfaces entre les applications et les platesformes qui les accueillent. Ils peuvent ^etre decoupes en plusieurs groupes :
les API des services du systeme (System Services API) qui incluent les API pour les services de genie
logiciel et les API des services du systeme d'exploitation,
les API des services de communication (Communications Services API) comprenant les API des services
reseau (API for Network Services),
les API des services d'information (Information Services API) comprenant les API pour la gestion des
donnees et les services d'echange (APIs for Data Management Services and Data Interchange Services),
les API de services de communication Homme/Machine (Human/Computer Interaction Services API)
comprenant les APIs pour les services d'interface avec l'utilisateur et les services graphiques (APIs for
User Interface Services and Graphic Services).
5.2.3 L'entite applicative de la plate-forme (APE)
L'entite "Plate-forme applicative" est denie comme un ensemble de ressources qui supportent les services
sur lesquels les applications vont reposer. Il fournit egalement des interfaces qui permettent, autant que faire
se peut, de rendre les caracteristiques de l'implementation de la plate-forme transparentes a l'application
logicielle.
Cette entite assure l'integrite et gere les acces simultanes qui pourraient ^etre concurrents. Toutes les applications doivent acceder aux ressources aux travers de ces API. Les services de l'entite "plate-forme" peuvent
contenir un noyau systeme, un moniteur temps reel et tous les pilotes des peripheriques.
Le concept de la plate-forme de l'application n'est pas lie a une implementation de la plate-forme. La
plate-forme peut ^etre un seul processeur, un systeme distribue avec toutes les applications dediees a un seul
processeur.
5. Le modele de reference de TAFIM
8
5.2.4 L'environnement externe (EEI)
L'interface vers l'environnement externe (External Environment Interface - EEI) est l'interface entre la plateforme de l'application et l'environnement exterieur avec lequel sont echangees des informations.
Originellement, il est deni comme etant le support de l'interoperabilite systeme et applicative. La portabilite
des utilisateurs et des donnees est directement fournie par l'EEI.
Au sein de l'EEI, il est deni trois groupes :
Human/Computer Interaction Services EEI (interface physique : clavier, souris, ecrans, micros, HP,
...),
Information Services EEI (interfaces avec les moyens de sauvegarde, formats assurant la portabilite et
l'interoperabilite des donnees)
Communications Services EEI (services de gestion des protocoles externes, formats d'echange de
donnees).
TAFIM a pour axiome le principe suivant : un systeme d'information est constitue de services locaux a une
machine ou distribues qui sont mis a disposition des applications et utilisateurs aux prols divers. TAFIM
a regroupe les services oerts en plusieurs categories. Leur somme constituent le potentiel mis a disposition
des applications.
Les services repertories par TAFIM sont donc :
le multimedia,
les services de communication,
le business-processing,
l'administration du contexte applicatif (par l'apport de mecanismes de type batch, transactions, afchage trie,...),
la gestion des donnees (comprenant des requ^eteurs, des mecanismes d'achage des donnees, des annuaires, des outils d'acces aux donnees ou DBMS),
les services applicatifs partages. Il s'agit la de services concus dans le cadre d'une application et mis a
disposition (dans un objectif de re-utilisabilite) des autres applications,
les outils de programmation,
les interfaces utilisateur,
les echanges de donnees (on entendra par donnees des documents simples ou complexes, des
graphismes,...),
le traitement graphique,
l'acces au reseau,
l'acces au systeme d'exploitation,
le support " de l'international ", ou en d'autre terme, la possibilite de supporter plusieurs langages,
les multi plates-formes (il s'agira de services capables de se derouler sur plusieurs machines),
la gestion/administration du systeme comprenant la gestion de la conguration, le suivi des performances, les audits, les mecanismes de tolerance aux pannes et la securite,
5. Le modele de reference de TAFIM
9
les services distribues : le temps universel, l'acces aux donnees et chiers sur toutes les machines,
l'annuaire global, les echanges inter-processus et les threads,
enn la securite. Le niveau de securite mis en place depend, dans TAFIM, "de la valeur de la donnee".
Ce dernier service est decoupe en quatre methodes :
{ l'authentication. Le service d'authentication peut ^etre sollicite a l'ouverture ou durant une
{
{
{
{
{
session,
le contr^ole d'acces,
l'integrite des donnees : ce service verie si les donnees n'ont pas ete alterees ou detruites,
la condentialite des donnees par la surveillance des acces aux ressources,
la " non-repudiation ", mecanisme d'acquittement permettant lors d'un echange de donnees entre
deux processus de certier que la donnee vehiculee est correcte,
la disponibilite qui s'assure que les services permanents sont disponibles.
De cette liste, il en ressort le modele TAFIM suivant : Modele TAFIM
C'est a partir de cette vue de synthese que le modele detaille va ^etre decline.
5.3 Le modele detaille
Le modele est decoupe en categories de services en fonction des besoins des dierents metiers.
5.4 Presentation de l'architecture
Il existe plusieurs manieres de modeliser un systeme informatique. Chaque representation est dierente car
la vue du systeme est dierente pour l'observateur. Un administrateur systeme ne modelisera pas de la
m^eme maniere un systeme d'information qu'un architecte des donnees.
5.5 Les dierents modeles sous l'angle du traitement de l'information
Nous allons presenter ici les dierentes manieres utilisees frequemment pour modeliser l'architecture d'un
systeme informatique.
5.5.1 Le modele client/serveur
Dans le modele client/serveur, le client a en charge d'eectuer les traitements de demande d'un service, et
le serveur a en charge de repondre au client en lui fournissant le service. Le client et le serveur peuvent ^etre
sur la m^eme plate-forme ou sur des plates-formes dierentes.
Le modele client/serveur est un type particulier de modele de traitement distribue car il designe un traitement
cooperatif. En eet, le client et le serveur eectuent des traitements dans le cadre de l'application complete
(presentation, traitement fonctionnel et gestion des donnees).
Une application peut ^etre consideree comme composee de trois parties dierentes :
les fonctions de l'application,
la presentation,
la gestion des donnees.
5. Le modele de reference de TAFIM
10
"Mission Areas" Applications
Support Applications
Multi
Média
Business
Processing
Communications
System
Services
Communications
Services
Environment
Management
Database
Utilities
Information
Services
Engineering
Support
Human/Computer
Interaction Services
Software
Engineering
Services
User
Interface
Services
Data
Management
Services
Data
Interchange
Services
Languages
& Bindings
Graphical
Client-Server
Data
Dictionary/
Directory
Document
CASE
Environment
& Tools
Object Def &
Management
Graphics
Services
Network
Services
Graphical
Object
Management
Data Comm
PC Support
Product
Data
DBMS
Electronic
Data
Window
Management
Graphics
Data
Dialogue Spt
Operating System Services
Kernel Operation
Communications
Services
Shell and Utilities
Information
Services
Human/Computer
Interaction Services
External
Environment
Interface (EEI)
Information
Interchange
Communications
Users
Figure 3: Modele TAFIM
Plate-forme
Plate-forme
Requète
Client
Serveur
Réponse
Requète
Client
Serveur
Réponse
Réseau
Figure 4: Modele client/serveur
Distributed Computing
Services
Application Platform
Internationalization
Services
Security
Services
System Management
Services
Application
Program
Interface
(API)
5. Le modele de reference de TAFIM
11
L'assignation de ces dierents elements au client ou au serveur permet d'avoir plusieurs congurations
possibles pour une application client/serveur. On trouve le plus souvent cinq types de repartitions :
presentation distribuee,
presentation distante,
gestion des donnees distante,
fonction distribuee,
gestion des donnees distribuee.
Ces cinq categories sont basees sur un rapport du Gartner Group et sont citees frequemment dans la
litterature.
On trouve egalement un autre type d'architecture, qui est l'architecture multi-niveaux.
5.5.2 Le modele base sur un serveur
Le modèle basé sur un serveur
Platforme
du serveur
Gestion
des données
Fonctions de
l’application
Presentation
Réseau
Terminal
passif
Figure 5: Modele base sur un serveur
Ce modele concentre tous les traitements sur une seule machine. La conguration typique d'une telle
architecture est un mainframe avec son ensemble de terminaux.
5.5.3 Le modele Ma^tre/Esclave et le modele hierarchique
Dans ce modele, les serveurs esclaves sont attaches a un ordinateur ma^tre. En terme de distribution, ce
modele est un pas supplementaire vers le reparti par rapport au modele base sur une machine. L'ordinateur
esclave n'eectue des traitements que lorsque l'ordinateur ma^tre lui demande. Une conguration typique
de ce type est un mainframe auquel est connecte un ensemble de PC fonctionnant en tant que terminaux
passifs.
Le modele hierarchique est une extension de ce modele sur plusieurs niveaux.
5. Le modele de reference de TAFIM
12
Le modèle maitre/esclave
Plate forme
maitre
Gestion
des données
Fonctions de
l’application
Presentation
Réseau
Terminal
passif
Plate forme
esclave
Figure 6: Modele Ma^tre/Esclave
Le modèle hiérarchique
Platform
du serveur
Gestion
des données
Fonctions de
l’application
Couche 1
de la plate forme
Presentation
Réseau
Services
de comm.
et peu de
fonctions
Couche 2
de la plate forme
Réseau
Terminal
passif
Couche 3
de la plate forme
Figure 7: Modele hierarchique
5. Le modele de reference de TAFIM
13
5.5.4 Le modele "peer-to-peer"
Peer-to-Peer (égal à égal)
Plate-forme
Données
Plate-forme
Gestion
Données
Présentation
Gestion
Présentation
Plate-forme
Données
Gestion
Présentation
Figure 8: Modele peer-to-peer
Dans le modele "peer-to-peer" ou "d'egal a egal", tous les ordinateurs sont a la fois serveurs et clients. Il y
a des traitements coordonnes. Des fonctions sont redondantes de chaque c^ote.
5.5.5 Le modele de gestion d'objets distribues
Gestion distribuée des objets
Distributed Object Management
Serveur
Données
Client
Gestion
Données
Gestion
Interface
Standard
Client
Présentation
Figure 9: Modele Objet Distribue
Dans ce modele, les appels aux procedures distantes utilisees typiquement pour la communication
client/serveur et autres modeles de traitements distribues sont remplaces par des messages envoyes a des
objets. Les services fournis par les systemes sur un reseau sont traites comme des objets.
Le demandeur doit conna^tre la maniere dont doit ^etre congure l'objet.
L'approche necessite
1. un mecanisme pour repartir les messages,
2. un mecanisme pour coordonner la repartition des messages
3. et les applications et services qui supportent une interface par envoi de messages.
Cette approche ne contraste par avec les modeles client serveur et "peer-to-peer" mais specie une interface
homogene avec des plates-formes cooperantes. Il est considere par certains comme une implementation des
modeles client/serveur et "peer-to-peer".
5. Le modele de reference de TAFIM
14
Gestion distribuée des objets
Distributed Object Management
Plate-forme
Données
Plate-forme
Gestion
Données
Présentation
Gestion
Présentation
Interface
Standard
Plate-forme
Données
Gestion
Présentation
Figure 10: Modele Objet Distribue
L'OMG (Object Management Groupe) a developpe CORBA (Common Object Request Brocker Architecture)
qui specie le protocole qu'une application cliente doit utiliser pour communiquer avec un (ORB) Object
Request Brocker qui fournit le service. L'ORB specie la maniere dont les objets peuvent realiser des requ^etes
transparentes et recevoir des reponses. OLE (Microsoft Object Linking and Embedding), standard Microsoft
sous Windows est un exemple de l'implementation d'une gestion d'objets distribues par laquelle toutes les
applications OLE peuvent travailler avec toutes les applications compatibles OLE.
5.6 Les dierents modeles sous l'angle de la gestion de l'information
Les services de gestion de donnees peuvent se presenter sous plusieurs formes :
mega-centres fournissant des bases de donnees corporatives (orientees sur les fonctions) ayant des
exigences locales et distantes,
systemes de gestion de bases de donnees distribuees supportant des utilisations interactives de bases
de donnees partitionnees et partiellement dupliquees,
systemes de gestion de chiers fournit par les systemes d'exploitation qui peuvent ^etre utilises en
interactif ou en batch.
Les composants majeurs de telles architectures sont :
les systemes de gestion de BDD,
les dictionnaires et repertoires de donnees,
la securite des donnees.
5.6.1 Le modele de gestion d'objets distribues
Dans ce modele, les RPC sont remplaces par des messages envoyes a des objets. Les services sont consideres
comme des objets. Pour fonctionner, il est necessaire que
les applications et services possedent une interface pour la gestion des messages,
un mecanisme permette la distribution des messages,
enn, un mecanisme assure la delivrance de ces messages.
5. Le modele de reference de TAFIM
15
5.7 Les dierents modeles sous l'angle de la gestion de l'information
An d'aboutir a l'architecture de TAFIM, des solutions d'architecture intermediaires seront mis en oeuvre.
Le choix du systeme de gestion des donnees est un composant important tout comme l'annuaire des donnees
et la securite de ces dernieres. Ces trois composants vont de fait ^etre detailles.
5.7.1 Le systeme de gestion des donnees
Un tel systeme
structure les donnees et en permet la reorganisation,
en ore un acces,
optimise la duplication,
supporte une interface de programmation
et ore des mecanismes de securisation et de contr^ole.
Le modele logique de donnees en caracterise le systeme de gestion. Les modeles existants sont :
le modele relationnel, qui organise des donnees dans des tables liees par des relations,
le modele hierarchique, qui struture les donnees dans un arbre,
le modele reseau qui est une extension du modele precedent permettant qu'un objet de l'arbre ait plus
d'une relation avec ses branches parentes,
le modele oriente objets, qui doit ^etre a la fois un systeme de gestion de donnees (quel qu'en soit le
type) et un systeme oriente objets;
les chiers plats couples en general avec une methode de gestion des acces,
les SGBD distribues qui orent la possibilite d'administrer une base de donnees repartie sur plusieurs
plateformes,
les SGBD distribues heterogenes, constitues d'un ensemble de bases de donnees heterogenes gerees
chacune par un SGBD. Des passerelles permettent de cacher cette heterogeneite a l'utilisateur en lui
donnant toujours acces a un point d'entree unique que l'on appelera federateur.
5.7.2 L'annuaire des donnees
Il est constitue d'outils et de systemes permettant d'une part de decrire les donnees stockees par l'un des
systemes precites et d'autre part de stocker des donnees concernant les donnees de la ou les bases (appelees
metadonnees).
5.7.3 La securite des donnees
Ce composant assure la protection des donnees notamment par le refus d'acceder a celles-ci si l'utilisateur
n'y est pas habilite. Il permet de placer des droits d'acces tels la lecture, l'ecriture, la suppression,...
5. Le modele de reference de TAFIM
16
5.8 Les dierents modeles sous l'angle de la securite
De plus amples explications seront apportees en ce qui concerne la securite dans le modele TAFIM. Le
present chapitre en presente les principales caracteristiques.
5.8.1 Concepts de base
Denition du systeme d'information du point de vue de la securite Un systeme d'information est
constitue d'un reseau de communication et d'environnements locaux ou mobiles (appeles LSE).
Domaine d'information Un tel domaine est constitue d'utilisateurs et de leurs donnees et d'une politique
de securite. Cette politique denit les droits de chacun au sein du domaine. Dans un environnement
important, on sera amene a constituer plusieurs domaines an que la politique de securite s'adapte au
mieux.
La politique mise en oeuvre devra tenir compte des "frontieres" entre deux domaines.
"Isolation stricte" Ce choix permet d'isoler hermetiquement l'information contenue dans un domaine vis
a vis d'un autre. L'echange d'informations entre les deux domaines sera valide par des regles.
On denit de m^eme des informations multi-domaines utilisables par un ensemble de domaines.
Protection absolue Ce concept est mis en oeuvre dans des systemes ayant plusieurs domaines ayant des
politiques de securite tres dierentes. Cette protection a en charge d'homogeneiser les choix de securite an
d'eviter tout probleme a l'interconnexion des domaines.
5.8.2 Architecture generique de securite
Le schema ci-dessous reprend l'architecture d'un systeme d'information au plan de la securite.
LSE
LSE
ES
ES
LSE
LCS
RS
CN
ES
RS
CN
LCS
ES
Environnement
Environnement
Environnement
CN : Communication Network
ES : end system
LCS : local communication system
LSE : local subscriber environment
RS : relay system
Figure 11: Vue de l'architecture generique de securite
Dans ce schema, un systeme de relais, RS, represente un composant permettant l'acces indirect a des informations par les utilisateurs (ex : un routeur, un hub,...).
6. Guide d'implementation de TAFIM
17
Le systeme de communication local, LCS, est un reseau charge des echanges entre deux LSE ou a l'interieur
d'un LSE.
Le reseau de communication, CN, assure les echanges entre les LSE mais est independant d'eux.
5.9 Sollicitation de services de securite
Un plus grand niveau de securite doit ^etre instaure sur les composants d'extremite et les systemes de relais.
De plus, le composant d'extremite sera peut-^etre a la frontiere de plusieurs domaines d'informations.
La majorite des mecanismes de securite peuvent ^etre implementes dans les services du systeme d'exploitation,
les services reseaux, et enn les services d'administration du systeme.
5.10 Les services du systeme d'exploitation
On peut assimiler l'environnement de protection d'une information a un espace d'environnement utilisateur. Chaque processus d'echange d'information, d'acces,... du systeme d'exploitation doit ^etre le plus
monolithique possible et les echanges bilateraux entre ces processus doivent ^etre connus.
Par l'utilisation d'espaces memoire distincts, l'OS est capable de maintenir ce cloisonnement entre deux
contextes de securite dierents.
5.11 Les services reseaux
Pour des echanges entre deux ES, un "accord de securite" est convenu entre les deux entites. Cet accord
met en oeuvre des protocoles, des procedures securisees.
Pour des echanges asynchrones, on utilisera une technique d'encapsulation des donnees, en ajoutant a cellesci des attributs permettant un transfert securise. On completera ce mecanisme par la technique precedente
si cela est juge necessaire.
5.12 Les services d'administration
La securite doit intervenir lors de l'installation, du parametrage et l'utilisation des informations et de leurs
domaines d'appartenance.
Ces services contr^olent les informations necessaires a l'OS.
D'autre part, ces services ont besoin de mecanismes d'interruption ("handling"), d'audit et de restauration de
contexte. La standardisation des protocoles et mecanismes de securite (appele SMAP Security Management
Application Processes) permettra la cooperation des services de securite a travers dierentes plate-formes.
Les SMAP seront mis en oeuvre lors des echanges entre deux ES. Chaque ES s'appuie sur un SMAP qui
mettra en oeuvre un protocole securise pour les echanges denomme SAMP (Security Association Management
Protocol). Cf Chapitre 7.
6 Guide d'implementation de TAFIM
La mise en oeuvre d'une architecture telle que TAFIM respecte un cycle de vie comprenant 7 etapes comme
le montre le schema ci-dessous.
-> Schema page vii volume 4
6. Guide d'implementation de TAFIM
18
Le volume 4 de TAFIM constitue le SBA Guide, Standards-Based Architecture Planning Guide et decrit
chacune de ces etapes qui sont presentemment explicitees.
6.1 Initialisation du projet. Trame d'architecture
On pourrait assimiler cette etape a un schema directeur durant lequel les processus et besoins de l'entreprise
sont revus pour etablir la correlation entre le systeme d'information et ces processus. Les equipes projet
sont identiees et un etat des lieux du systeme d'information existant est dresse.
6.2 Specication d'architecture
Cette etape se conclut par un schema de l'architecture du systeme d'information sous trois angles dierents
:
(les methodes) de travail,
l'organisation de l'entreprise,
les applications (notamment les applications metiers),
les technologies.
Les specications detaillees de l'architecture ne sont pas realisees durant cette etape. Celles-ci constituent
un des livrables de la troisieme etape.
6.3 Architecture cible
Cette etape est le coeur du cycle de vie de l'architecture. Des solutions d'architecture sont comparees tout
en se projettant a 5 ans dans l'avenir (l'architecture choisie doit en eet faire l'objet d'une certaine perennite
an de ne pas "precipiter" la mise en place de l'architecture qui la suivra).
Pour l'architecture retenue, on identiera chaque composant nement et l'on precisera ses options de mise
en oeuvre.
6.4 Prise en compte de l'existant
Durant cette etape, l'architecture choisie sur papier est calquee a l'organisation existante an de s'assurer
des choix faits et de deceler les inter^ets immediats de l'architecture sur les metiers de l'entreprise.
D'autre part, une liste des sous-projets necessaires a la mise en application de l'architecture sur le SI est
dressee.
6.5 Choix de migration
Plusieurs etapes de migration peuvent ^etre denies durant cette phase pour aboutir a l'architecture cible.
On donne a chaque sous-projet determine precedemment une priorite an d'etablir un planning global.
6.6 Planning de deploiement
Un planning n comprenant tous les projets et sous-projets est constitue a cette etape du processus.
7. Le modele de securite cible du DoD (La DGSA)
19
6.7 Mise en oeuvre de l'administration
Cette etape permet le maintient de l'architecture en production. On s'assusera dans un premier temps
de la pertinence de l'architecture choisie et l'on adaptera au mieux les parametres des composants qui la
constituent.
7 Le modele de securite cible du DoD (La DGSA)
Dans ce chapitre, nous allons presenter la DGSA (Department of Defense Goal Security Architecture).
Le programme americain DISSP (Defense Information System Security Program) a ete lance par l'assistant
au secretaire d'etat a la Defense (Command, Control, Communication and Intelligence).
La DISA et la NSA ont collabore pour denir 8 objectifs. Les domaines suivants sont traites dans les 8
objectifs suivants :
politique de securite,
architecture,
standards,
protocoles,
procedures d'accreditation,
technologies,
planication des transitions,
amelioration de l'organisation,
disponibilite des produits et services.
La DGSA prend en compte la protection de l'information et les avantages du systeme comme une partie
de la vision globale des missions, des menaces, de la performance, de l'interoperabilite, de l'extensibilite, de
l'utilisabilite, et des co^uts de l'implementation.
La DGSA se veut, a l'image de TAFIM, assez generique pour que tous les cas particuliers puissent egalement
^etre modelises. Elle inclut les besoins de la mission commune C4IFTIW (Command, Control, Communications, Computers and Intelligence for the Warrior).
La DGSA est un but, il n'y a pas de date xee pour atteindre ce but. Elle fournit egalement les bases pour
le developpement de mecanismes de securite qui pourraient ^etre choisis par les ingenieurs responsables de la
conception de systemes de securite.
La DGSA repose sur l'etude de plusieurs systemes :
DISN : Defense Information Systems Network,
DMS : Defense Message System,
ITSDN : le reseau integre tactique et strategique,
MLS : DoD Multilevel Security Program.
7. Le modele de securite cible du DoD (La DGSA)
20
7.1 Types d'architectures
Il existe plusieurs types d'architecture pour une seule realite. Nous allons denir ici un certain nombre
d'architectures qui se dierencient en fonction du niveau d'abstraction que l'on choisit.
7.1.1 Architecture abstraite
La denition de l'architecture abstraite commence par la connaissance des besoins et denit les fonctions
correspondantes a mettre en oeuvre. Elle denit les concepts fondamentaux qui guident la selection et
l'organisation des fonctions. Les architectures abstraites edictent les principes, concepts fondamentaux et
fonctions qui satisfont les besoins typiques de securite.
Ces concepts et fonctions sont alloues aux elements d'une denition abstraite de l'architecture du systeme
d'information.
7.1.2 Architecture generique
Le developpement d'une architecture generique est base sur les decisions prises lors de la redaction de
l'architecture abstraite. Elle denit les types generaux des composants et standards autorises et identie toute recommandation necessaire pour leur application. Une architecture generique commence par
denir une assignation initiale, des fonctions et services de securite, puis denit les types de composants et
mecanismes de securite qui sont disponibles pour mettre en place les services de securite avec des niveaux
de securite particuliers. Toute limitation dans la combinaison des composants et des mecanismes, a cause
de leur incompatibilite ou de la degradation du niveau de securite qu'ils impliquent doit ^etre citee dans les
recommandations pour l'application du document.
7.1.3 Architecture logique
Une architecture logique est une conception qui repond a un ensemble d'exigences hypothetiques. Il sert
d'exemple detaille qui illustre les resultats de l'application d'une architecture generique dans des circonstances
speciques. Les seules dierences entre une architecture logique et une architecture specique sont dues au
fait que les exigences speciques sont reelles, non hypothetiques, et parce que l'architecture logique n'est pas
faite avec l'intention d'^etre implementee. Elle est independante des co^uts.
Dans les architectures logiques, la conception logique est accompagnee par l'illustration de l'analyse de
securite qui doit ^etre realisee dans des architectures speciques.
7.1.4 Architecture specique
L'objectif de tout architecte systeme est de realiser une specication de conception de sorte que les composants puissent ^etre achetes pour implementer le systeme. L'architecture specique traite des composants,
interfaces, standards, performances et co^uts. Les architectures de securite speciques montrent tous les composants de securite choisis et les mecanismes, incluant les doctrines et les composants de gestion combines
pour atteindre les exigences de securite du systeme specique que l'on considere.
7.1.5 Processus de developpement de la DGSA
Le developpement de la DGSA est realise a l'aide d'un processus iteratif :
realiser une analyse des exigences,
7. Le modele de securite cible du DoD (La DGSA)
creer une structure pour l'architecture,
allouer les services de securite,
choisir les composants et les mecanismes de securite,
realiser une analyse d'interdependance (evaluation).
21
Organisation du chap^tre Apres une presentation generale des besoins, les liens entre la DGSA, TAFIM
et C4IFTW seront explicites. Une presentation des principales clefs de la securite et des principaux composants d'un systeme d'information suivra. Chacun d'eux sera ensuite detaille.
7.1.6 Besoins en securite
Chaque societe a ses propres besoins en terme de securite qu'elle formalise sous forme de documents. Ces
documents s'appliquent ensuite aux utilisateurs et a leur environnement, aux donnees,...
Une architecture de securite constitue une reponse concrete a ces documents qui doit s'inserer dans le schema
d'architecture globale du systeme d'information.
Quels que soient les besoins de l'entreprise, le processus a retenir est le suivant :
les informations "a proteger" sont identiees,
les besoins d'acces a ces dernieres sont etablis,
l'importance des informations et leurs consequences sont evaluees,
la solution de securite etablit les protections necessaires en fonction des risques et met en place des
services securises.
La politique de securite de la DGSA Pour comprendre la demarche retenue par la DoD, il est important
de situer rapidement le contexte dans lequel elle a ete pensee :
les systemes d'informations doivent pouvoir s'adapter a dierentes politiques de securite,
ces systemes doivent ^etre susamment proteges pour permettre la distribution des donnees et des
traitements sur plusieurs machines,
ils doivent orir des niveaux de securite dierents en fonction des habilitations des utilisateurs,
enn, il doit ^etre possible de baser l'interconnexion des sites sur un reseau public.
Les besoins de securite de la DGSA Ces besoins derivent des quatre points precedents.
Support de plusieurs politiques de securite Les utilisateurs souhaitant acceder depuis leur station
a des informations eventuellement avec des droits d'acces dierents a chaque application, ce besoin est
important. Pour y repondre, le SI doit ^etre capable de dissocier les utilisateurs et les informations pour les
placer a dierents niveaux de protection.
Mise en oeuvre des systemes ouverts L'emploi de tels systemes est indispensable des lors qu'il doit
^etre possible d'interconnecter les sites par dierentes methodes et assurer par ces biais des echanges de
donnees.
7. Le modele de securite cible du DoD (La DGSA)
22
Politique de securite appropriee Le choix de la solution de securite depend des besoins. Une partie de
cette solution est impactee par la securite mise en place dans les communications. Lors de l'utilisation d'un
reseau public, le SI doit prendre en charge la securisation des donnees et l'operateur se contenter d'orir un
transport able.
Gestion globale de la securite Une telle solution permet aux administrations d'avoir une vue globale
sur la securite m^eme si plusieurs politiques de securite sont etablies.
Autres besoins Une des premieres necessites issues du souhait de supporter plusieurs politiques de securite
provient de la capacite a repondre a l'une d'elles independamment des autres. L'information doit pouvoir
ainsi ^etre identiee pour chaque politique. Ainsi toutes les references a des informations par des utilisateurs
doivent passer par un moniteur de reference. Lors d'echanges distants on utilisera l'authentication mutuelle,
le contr^ole d'acces,...
L'emploi de standards internationaux pour les protocoles d'echange assure d'autre part la possibilite aux utilisateurs de choisir sans inconvenient quelle information envoyer vers d'autres utilisateurs. Cette negociation
pourrait ^etre eectuee lors de l'initialisation de l'echange : les utilisateurs conviendraient de ce qui doit ^etre
vehicule.
D'autre part, le fait de retenir plusieurs services de securite implementes dans dierents mecanismes (pour
repondre a des besoins diverses de protection) implique de verier que les mecanismes conviennent certes
individuellement mais aussi une fois combines.
Les principaux elements a administrer dans la DGSA sont les utilisateurs, les regles de securite, les informations, les systemes charges d'appliquer les regles de securite ainsi que les fonctions securisees implementees
sur ces systemes. Pour ce faire, le format de representation de ces objets a administrer doit ^etre normalise.
Vision de la DoD Le DoD pense que les constructeurs et fournisseurs de logiciels doivent de plus en plus
inclure des mecanismes de securite au sein de leur produit car les societes freinent l'implementation de ces
mecanismes pour des raisons de co^uts.
Un des moyens de reussir pour une entreprise est de s'ouvrir gr^ace aux technologies communicantes. An
de minimiser les co^uts, l'utilisation des reseaux publics est necessaire bien que cette solution accroisse les
risques d'attaque. D'autre part, ce type de solution permet de reposer sur des standard en terme de transport
d'information et de concentrer la reexion d'architecture sur les couches superieures du modele OSI.
L'entreprise doit de plus mettre a disposition de l'utilisateur toutes les informations dont il a besoin y compris
celles qu'il doit aller chercher sur des machines n'appartenant pas a la societe. Ceci pose un probleme etant
donne que la DGSA modelise toutes les donnees et les regles de securite a suivre. L'utilisateur souhaite
quant a lui s'abstraire des domaines de securite en s'appuyant sur un unique mecanisme d'authentication
pour acceder a une donnee qu'elle qu'en soit le lieu d'acces.
L'accredation et la certication des produits sont des reponses aux besoins de securite. An de reduire les
procedures, il doit ^etre envisage de creer des certicateurs et des accrediteurs de produits. Cela permettrait
d'homogeneiser les certications et d'assurer une certaine interoperabilite.
7.1.7 Perspectives d'architecture cible et d'evolution
Le schema suivant represente l'architecture retenue pour le DIS. Il tient des besoins et points de vue reveles
dans TAFIM.
7. Le modele de securite cible du DoD (La DGSA)
23
Les niveaux d’intégration de TAFIM
Intégration Personnelle
Les éléments spécifiques de la gestion de l’information
pour l’intégration
Intégration Applicative
Elements spécifiques au système pour la gestion de l’information
qui permettent de remplir les zones fonctionnelles de l’intégration.
Intégration Fonctionnelle
Elements de la gestion de l’information nécessaires pour atteindre
les besoins fonctionnels qui permettent de réaliser la mission.
Intégration par Mission
Intégration d’Entreprise
Elements de la gestion de l’information nécessaires permettant
de réaliser un besoin au sein d’un des domaines d’une mission.
Environnement
Opérationnel
Conceptions
spécifiques
Guides Généraux
Elements de la gestion de l’information obligatoires au sein de tout
le DoD (provenant des doctrines, politiques). Ils implémentent
les standards techniques, les méthodes et outils et partagent
les services de calcul et de communication.
IM : Information Management (gestion de l’information)
Figure 12: Les niveaux d'integration
7.1.8 Concepts de securite
Modelisation du SI d'un point de vue securite. Un premier modele simple du SI consiste a dire que
deux environnements locaux (appeles LSE, local subscriber environments) souhaitent communiquer a travers
un reseau. Chaque LSE est constitue des materiels et systemes sous le contr^ole de l'utilisateur.
Un LSE peut ensuite ^etre decompose en plusieurs elements : des systemes ouverts (ou "End System")
car directement accessibles par les utilisateurs, des systemes relais (RS) et des systemes de communication
locale (LCS). Enn, le systeme de transfert inclut tous les protocoles inclus dans les ES et les RS ainsi qu'a
l'interconnexion des LCS et du reseau de communication (CN).
Les CN peuvent ^etre de deux types : prives ou publics. Dans le premier cas, l'isolement apporte par ce type
de lien est denomme TFS (complete trac ow security).
Allocations d'un service securise La DGSA compte dans les services de securite l'authentication, le
contr^ole d'acces, l'integrite des donnees, la non-repudiation et la disponibilite. Nous allons examiner ces
services dans les LSE et les CN.
Cas des reseaux de communication Les CN n'ont pas en charge d'assurer un TFS mais doivent assurer
une continuite de service. Le TFS est a la charge des LSE qui doivent alors ^etre securises. L'architecture
des reseaux de communication ne doit pas reposer sur la condentialite des donnees mais sur la qualite de
service et le besoin de reprise en cas d'incident.
Cas des LSE Une premiere protection des LSE est physique : il s'agira de la protection des locaux
(identication du personnel,..).
Un LSE doit pouvoir communiquer indieremment avec un LSE securise et un LSE non securise. Dans ce
dernier cas, le LSE securise doit isoler ses informations sensibles.
A l'interieur des LSE, les LCS sont charges d'apporter la securite necessaire a la communication entre les
ES et les systemes relais internes aux LSE.
7. Le modele de securite cible du DoD (La DGSA)
24
System
de transmission
(Transfert System)
LSE
ES
LSE
ES
LSE
LCS
RS
CN
ES
RS
CN
LCS
ES
Environnement
Environnement
Environnement
CN : Communication Network
ES : end system
LCS : local communication system
LSE : local subscriber environment
RS : relay system
Figure 13: Les LSE vus sous l'angle de la securite
Les ES et les systemes relais apportent les autres services de securite (authentication de l'utilisateur, contr^ole
d'acces, non-repudiation, condentialite, integrite et disponibilite).
Le TS (systeme de transfert) apporte un dernier niveau de securite tout comme les systemes relais. Ainsi,
les transferts etant proteges, les informations de type authentication, identication, politique de securite,
droits d'acces,...peuvent ^etre echangees.
Le modele ISO 7498-2 a ete retenu pour la DGSA.
Le schema ci-dessous reprend la repartition des services de securite entre les dierents elements de
l'architecture.
7.1.9 Concepts de securite
Domaines d'information Les personnes d'une entreprise manipulent des donnees et determinent leurs
niveaux de securite. Un groupe d'utilisateurs peut donc identier ses informations et une politique de securite
peut ^etre connue et appliquee par tous les membres du groupe. On appelle domaine d'information le triplet
(groupe d'utilisateurs, informations, politique de securite).
Les domaines d'information ne sont pas lies de maniere hierarchique. Ils ne sont de plus pas delimites par
des machines ou des reseaux mais par les informations qu'ils integrent. Un systeme d'information doit donc
^etre capable d'heberger plusieurs de ces domaines.
Les regles de securite doivent s'appliquer de maniere homogene a toutes les informations d'un domaine.
Isolation stricte Il doit ^etre possible a un systeme d'isoler deux domaines d'information de maniere
hermetique. On parle alors d'isolation stricte. Cette politique de cloisonnement est la relation par defaut
entre deux domaines.
Partage et echange de donnees entre domaines Deux solutions simples consistent a creer dans
les domaines les utilisateurs ayant besoin d'acceder aux informations partagees ou de creer un domaine
7. Le modele de securite cible du DoD (La DGSA)
25
d'information avec tout ce qui doit ^etre partage.
Le transfert repond a des regles de securite denies dans les domaines source et cible et est eectue par un
utilisateur identie dans ces deux-ci.
Toute information copiee ou deplacee doit ^etre re-labellisee dans son nouveau domaine d'appartenance.
Les echanges inter-domaines ne se produisent qu'a l'interieur des ES ou des RS alors que les transferts entre
ES ou RS s'eectuent a travers le m^eme domaine.
Informations et politiques multi-domaines Une information multi-domaines est un ensemble
d'informations provenant de domaines dierents. Une politique specique de securite s'applique a ces
donnees. Celle-ci s'appuiera sur des politiques existantes auxquelles on ajoutera la denition de droits
speciques. La notion de hierarchie des droits pourra de plus s'appliquer aux informations multi-domaines.
Protection absolue Dans un environnement heterogene, il est impossible de s'appuyer sur la securite
physique et la cryptographie de LSE isoles. Il est necessaire de s'appuyer sur la protection apportee par un
ensemble de LSE heterogenes.
Le concept de protection absolue est deni pour orir l'homogeneite des moyens de protection supportes
dans un domaine d'information.
M^eme si les implementations sont dierentes dans chaque LSE, elles doivent apporter la m^eme "force de
protection" donnant la une reponse homogene au besoin de securite.
Accreditation uniforme Les trois concepts precedents contribuent a la constitution d'une accreditation
uniforme. L'objectif est d'avoir un niveau de protection equivalent dans tous les LSE qui supportent un
domaine d'information. L'isolation stricte etablit une independance basique entre les domaines supportes
par un LSE ce qui permet d'utiliser pour chacun des mecanismes de securite dierents. La protection absolue
quant a elle assure que la securite necessaire est implementee uniformement entre les LSE supportant un
domaine. Un acrediteur etablit une evalution pour chaque LSE.
Administration de la securite Cette administration concerne l'interieur des LSE ainsi que leurs liens.
Un administrateur utilise une MAP (Management Application Process) pour gerer les informations
d'administration ; ces dernieres sont une base appelee MIB (Management Information Base). Dans le
domaine de la securite, on parlera de SMAP et SMIB (S pour security).
Tout comme les donnees, les informations d'administration doivent faire partie d'un domaine et l'on doit
s'interroger sur l'emplacement de ce domaine.
7.2 ES et RS
Un unique modele de securite est approprie a la fois pour les ES et les RS. On ne parlera donc dans ce
paragraphe que des ES. De plus, l'exemple des ordinateurs sera retenu comme ES parce qu'etant le cas le
plus complexe.
7.2.1 Architecture de securite des ES
La securite est repartie sur le materiel et le logiciel dans ces ES. Cette repartition est fonction du type de
securite recherche.
7. Le modele de securite cible du DoD (La DGSA)
26
Le premier niveau de securite consiste en la protection des locaux et l'identication du personnel. Le LSE
protege donc le materiel.
Le materiel quant a lui peut proteger le logiciel en assurant son cloisonnement et en protegeant par mot de
passe les acces aux composants materiels. Le materiel sera charge egalement de proteger les donnees des
interferences radio. Des materiels a tolerance de panne pourront enrichir la securite. Les mecanismes de
cryptographie bases sur du materiel seront mis en oeuvre si besoin est. Enn des mecanismes materiels tels
que le mapping de la memoire contribueront a la protection des donnees.
Enn le logiciel protege les informations par le biais des protections mises en oeuvre dans les systemes de
transfert. Les ES supportant les TS assureront les mecanismes de securite de ces derniers. Les ES inclueront
de plus les applications chargees de l'administration de la securite. L'ES sera responsable de l'authentication
des utilisateurs, du contr^ole des acces, de l'integrite et du stockage des donnees.
7.2.2 Description de l'architecture de securite des ES
Denitions :
un contexte de securite est une combinaison des LSE, materiels, logiciels, applications utilisateur et des
informations d'un utilisateur au sein d'un domaine d'information. Un contexte de securite est dierent
d'un contexte utilisateur car il inclut les protections apportees par les LSE.
un noyau separateur (separation kernel) assure les protections materielles des ES (etats de registres,
mapping de la memoire,...) pour isoler les contextes de securite en leur allouant des zones memoires
separees. Ce noyau assure les communications entre les contextes de securite. De nombreux services
s'appuient ainsi sur le noyau separateur a l'aide l'API.
Les dierents points de cette architecture sont decrits ci-apres.
Noyau separateur Dans un systeme d'exploitation, on concoit chaque fonction sous forme de petits codes
independants. On suggere de plus d'isoler chaque noyau dans un processus ayant son propre espace memoire.
Un noyau separateur est alors charge d'assurer ce cloisonnement. Ce noyau est considere comme le coeur de
la securite de la DGSA.
De par cette separation, les fonctions d'attribution des droits d'acces et les fonctions de renforcement des
droits sont cloisonnees ce qui permet le support de plusieurs politiques de contr^ole d'acces. L'ISO appelle ces
fonctions ADF (Access control Decision Function) et AEF (Access control Enforcement Function) reprises
sous le nom de SPEF (Security Policy Enforcement Function) et SPDF (Security Policy Decision Function)
par la DGSA. Le noyau separateur sera l'implementation du SPEF dans l'ES.
Contextes de securite Les mecanismes de securite suivant sont necessaires pour assurer le cloisonnement
de ces contextes :
identication unique de chaque contexte,
identication du domaine d'informations,
valeurs de registres associees au contr^ole des ressources de l'ES,
authentication de l'utilisateur,
permissions de l'utilisateur,
structures de donnees permettant l'emploi de fonctions securisees.
7. Le modele de securite cible du DoD (La DGSA)
27
Etant donne qu'un utilisateur peut vouloir acceder a plusieurs contextes de securite, les transferts entre les
contextes doivent ^etre valides par la ou les politiques de securite du domaine d'information.
Le mecanisme de login est indispensable pour reconna^tre l'utilisateur et determiner le domaine d'information
sollicite.
Fonctions de securite critique
SPDF (Security Policy Decision Function) Le premier r^ole du SPDF est d'isoler l'ensemble de l'ES
des politiques de securite. A des ns de facilite, les representations de ces politiques sont regroupees en un
endroit.
L'approche retenue pour le SPDF permet une implementation independance de fonctions de securite particuliere.
Fonction d'authentication La fonction d'authentication est l'interface qui s'appuie sur des
mecanismes d'authentication employes pour la reconnaissance de l'utilisateur. Un ES supportant plusieurs
domaines d'information aura peut-^etre besoin de solliciter des mecanismes d'authentication dierents pour
chacun d'eux.
Le systeme de transfert doit proteger l'identite de l'utilisateur authentie lors d'un acces a plusieurs domaines
d'information.
Fonction d'audit Cette fonction recoit des messages depuis des fonctions de l'ES en accord avec le domaine d'informations et les politiques de securite (provenant d'une MIB). Les messages sont envoyes vers un
utilisateur pour eviter leur perte.
Fonction de scheduling Le scheduler doit ^etre inclus dans les fonctions de securite an qu'aucun processus ne mobilise le processeur au depend d'autres.
Fonction de gestion de peripherique et gestionnaire de peripherique On compte parmi ces fonctions de contr^ole :
la fonction de gestion de la memoire,
la fonction de gestion de chiers,
la fonction de gestion de l'achage qui doit savoir gerer l'achage d'informations provenant de domaines d'information dierents.
la fonction de gestion des communications inter-processus,
la fonction de gestion des services de cryptographie qui peut supporter des services de condentialite,
d'integrite de donnees, d'authentication de l'origine des donnees et enn de non-repudiation,
enn toutes les fonctions de gestion de peripherique.
Fonctions liees a la securite
7. Le modele de securite cible du DoD (La DGSA)
28
Structure residuelle de l'OS Il s'agira la de toutes les autres fonctions d'un systeme d'exploitation non
citees precedemment. Etant donne que les contextes de securite sont independants, ils peuvent donc reposer
sur des structures residuelles dierentes.
La modularite d'un systeme d'exploitation permet donc d'aboutir au schema suivant :
Application
Application
Application
Application
Application
Application
Application
Partie du système d’exploitation
Interface Standard du Noyau
Noyau de séparation
Scheduler de processus
Audit
Authentification
IPC
Mémoire
Système de fichier
Visualisation
Cryptographie
Gestionnaires de périphériques
Figure 14: Relations de securite entre les applications et le systeme d'exploitation
Fonction de gestion de la securite Son r^ole est de contr^oler les informations necessaires aux fonctions
de securite. Ces informations seront detaillees par la suite.
Fonction TS (systeme de transfert) Les fonctions de communication X400, les services d'annuaire X500
et les protocoles d'echanges sont considerees comme des parties non-ables. Elles sollicitent des services de
securite.
7.3 Administration de la securite
7.3.1 Relations entre les concepts de la DGSA et la gestion de la securite
L'impact le plus important des concepts de la DGSA est le support de plusieurs domaines d'information. La
DGSA rejoint sur les autres points les besoins des architectures en terme de gestion de la securite.
Entre autres, les elements suivants doivent gurer dans la politique de securite d'un domaine d'information
:
description succinte du contexte de la mission couverte par le domaine,
7. Le modele de securite cible du DoD (La DGSA)
29
descriptions des informations, de leurs attributs, et leurs regles d'utilisation entre plusieurs domaines,
regles pour les transferts multi-domaines,
exigence des services de securite,
criteres d'acceptation pour l'implementation de ces services,
criteres speciques de securite (ex : relations entre les informations d'administration et les donnees),
identication d'un ou plusieurs utilisateurs.
Les regles de securite font partie des SMIB. Chaque SMIB est accedee par un administrateur a l'aide d'une
SMAP.
7.3.2 L'ISO 7498-2 et les concepts de securite de la DGSA
7.3.3 Outils d'administration de la securite
Specication des regles d'une politique de securite La specication de ces regles par un outil necessite
encore des recherches, les outils existants etant des plus basiques.
Catalogue des mecanismes de securite Un tel catalogue permettant de choisir les mecanismes de
securite repondant au besoin du projet n'existe pas a ce jour.
Application de maintenance pour les administrateurs de la securite Ces applications doivent
prendre en compte les SMIB (en assurant leur administration), la gestion des clefs et proposer des rapports
d'audit. De telles applications seront automatisees. Il doit de plus ^etre possible d'isoler dierentes fonctions
d'administration pour les repartir sur plusieurs administrateurs.
7.3.4 Standardisation des fonctions de securite
Les domaines dans lesquels la standardisation est necessaire pour orir l'interoperabilite entre SMAP sont :
la representation des regles de securite,
les fonctions de gestion des clefs (generation, distribution et audit des clefs chirees),
la structure des informations d'audit,
le protocole d'echange des informations relatives a la securite.
7.4 Systeme de transfert
Le systeme de transfert dans un ES ou un RS se limite aux applications de communication des systemes
ouverts et aux protocoles de communication. Le TS devant ^etre administre, les SMAP et SMIB doivent
prendre en compte les fonctions du TS.
Le but d'un TS est d'orir une protection des donnees durant un transfert an de supporter le partage des
donnees. Un moyen d'aboutir a cela est d'autoriser les contextes de securite repartis sur plusieurs ES.
7. Le modele de securite cible du DoD (La DGSA)
30
7.4.1 Contexte de securite distribuee
Deux modes de transfert doivent ^etre consideres : le mode interactif et le mode "poste restante". Les
contextes de securite pour ces deux types de communications sont decrits ci-apres.
Contexte distribue pour les communications interactives Un tel contexte est constitue de deux
contextes appartenant a chaque ES et relies de maniere securisee par une association securisee. Cette
association comprend les protocoles de securite et de communications, les mecanismes doctrinaux, et les
fonctions de securite decrites dans le chap^tre precedent.
Les informations de gestion de la securite sont contenues dans une SMIB appelee l'ASSR (Agreed Set of
Security Rules) qui contiendra entre autre les algorithmes de chirement et les donnees. Chaque ES choisit
localement un identiant pour l'association (le SAID, Security Association IDentier) qui lie l'association a
l'ASSR correspondante.
L'etablissement de l'association passe par des echanges entre deux SAMP des machines concernees (les ES).
Tout d'abord, il s'agit d'indiquer les capacites de securite des deux extremites. Ce premier echange est
non chire. Le deuxieme echange concerne l'attribut des clefs necessaires aux mecanismes de chirement.
D'autres contr^oles de securite (comme les contr^oles d'acces) peuvent s'eectuer durant cet echange. Enn
le troisieme echange emploie les clefs et les algorithmes de chirement pour s'assurer de l'accord des deux
extremites. Ce dernier echange est chire et est eventuellement utilise pour l'echange d'autres informations
de securite.
D'autres informations s'averent necessaires parfois dans un contexte distribue comme l'idencation et les
droits d'un utilisateur que l'on peut stocker dans un certicat X509. Il est possible de coupler de nombreuses
techniques de protection.
Contextes distribues pour les communications asynchrones L'information a transmettre est prise
en charge par une application qui la chire et lance son acheminement. En principe, sa protection est
entierement prise en charge par l'application. Si ce n'est pas le cas, les systemes de relais devront s'en
charger. Une implementation de mail electronique repondant a ce besoin existe a ce jour : le SDNS Message
Security Protocol le decrit.
Autres aspects des contextes distribues Le transfert d'informations multi-domaines utilise un contexte
de securite distribue par domaine.
Des fonctions supplementaires sont ajoutees s'il est necessaire d'assurer la gestion d'un grand nombre de clefs
(si un systeme interagit avec beaucoup d'autres, cette administration des contextes de securite est complexe).
7.4.2 Support du TS
Des fonctions doivent s'ajouter au SMAP pour remplir les activites suivantes :
requ^etes des applications de communications des ES,
nouveaux objets a stocker dans la SMIB,
maintenance et acces aux donnees de securite d'un annuaire X500 depuis le protocole DAP,
utilisation de MSP pour les echanges de messages,
fonctions de creation et suivi du SAID et de l'ASSR ainsi que les mecanismes de gestion des associations
de securite,
7. Le modele de securite cible du DoD (La DGSA)
fonctions et clefs de chirement,
protocole de gestion pour les echanges inter-SMAP.
31
Les SMIB integreront de plus les informations suivantes : certicats X509, droits d'acces des utilisateurs,
clefs de messages et de trac, donnees d'audit.
Pour les SMIB des ES, on ajoutera :
la gestion des clefs,
les identiants des algorithmes de signature,
les donnees des protocoles securises,
les droits d'acces a l'ES pour les traitements distribues,
les informations d'initialisation des algorithmes de chirement,
les donnees des associations de securite,
les interdits (ex : certicats refuses),
et enn les regles de purge de l'ensemble de ces informations.
Les protocoles de securite retenus pour la DGSA sont presentes dans le tableau suivant. Pour chacun d'eux,
on precise les services de securite supportes.
La mise en oeuvre de contexte de securite distribuee se base essentiellement sur l'utilisation de mecanismes
de chirement. Le support par les materiels de chirement de plusieurs mecanismes est souhaitable pour ne
pas en multiplier le nombre et accro^tre par ce biais les co^uts.
7.4.3 Inconvenients du TS
L'emploi de reseaux publics emp^eche l'emploi des mecanismes de gestion securise du trac (le TFS, trac
ow security) car ils interviennent sur les protocoles de couche basse. Par consequent, il existe la une
vulnerabilite.
Certaines limitations sont rencontrees si des mecanismes de chirement sont appliques pour des communications de type diusion (broadcast). La solution consiste a denir une clef par diusion et pour les
informations de multi-diusion (multicasts) une clef par mecanisme de chirement. Cette clef est ensuite
repliquee vers les destinataires a l'aide eventuellement du protocole MSP.
7.5 Doctrine de securite
On entend par doctrine de securite les regles devant ^etre appliquees par les personnes et l'environnement
pour assurer la bonne mise en oeuvre de l'architecture de securite.
Les points principaux pour la DGSA sont presentes ci-apres.
7.5.1 Les services de securite
Ceux-ci sont concentres essentiellement dans les LSE. Les locaux protegent ainsi les ES, les RS et les LCS.
Des fonctions de protection physiques sont ajoutees parfois.
8. Glossaire
32
7.5.2 Doctrine pour les services de securite
L'authentication des utilisateurs (le plus souvent par badge) est le mecanisme le plus connu pour proteger
les acces. Le m^eme principe s'applique pour l'acces au ressources logicielles (par clefs chirees,...).
Les contr^oles d'acces completent l'authentication des utilisateurs pour l'acces aux ressources. Un deuxieme
niveau de securite s'appuie sur des bureaux fermes ou locaux securises.
La condentialite peut ^etre assuree en evitant les emanations video (a l'aide de ltres) et en contr^olant
les sorties sur les imprimantes. Des broyeurs de papier sont necessaires et une protection des supports
magnetiques doit ^etre prevue.
L'etat du materiel se doit d'^etre verie regulierement et des mecanismes de contr^ole (check) des composants
doivent ^etre prevus.
Par des techniques de redondance et de stock materiel, la disponibilite des composants du systeme
d'information peut ^etre assuree.
8 Glossaire
Architecture
La notion d'architecture a plusieurs sens dependant du contexte. (1) La structure des composants,
leurs inter-relations, et les principes et regles regissant leur conception et leur evolution dans le temps
(traduction de la denition IEEE STD 610.12) (2) Structure organisationnelle d'un systeme ou d'un
composant (IEEE STD 610.12).
Infrastructure
L'infrastructure est utilisee a une signication dierente suivant le contexte. Le plus frequemment,
l'infrastructure designe ou a un rapport avec le materiel mais il est a noter qu'il inclu souvent le logiciel
est les telecommunications.
DoD
Department of Defense
DISA
Defense Information Systems Agency
OSE
Open System Environment
Politique de Securite
(security policy) est associee a une mission et est base sur les menaces portant sur les moyens par
lequels la mission reussie (est accomplie). Un politique de securite (ou, d'une maniere plus generale,
un ensemble de politiques de securite) documentent les besoins de securite qui doivent ^etre mis en place
sur les ressources par une organisation. Ces besoins de securite denissent, pour le personnel operant
le systemes d'information, les besoins de protection des informations de l'utilisateur et des ressources
qu'il utilise.
Une architecture de securite
denie pour une mission specique les services de securite et les mecanismes speciques que doivent
orir tous les composants du syteme d'information.
9. Documents de reference
33
Systeme d'information
(information system) est un ensemble de composants de traitement de l'information et de communication, ainsi que l'environnement dans lequel il operent. Cet environnement peut supporter une ou
plusieurs missions.
TCSEC
Trusted Computer System Evaluation Criteria
9 Documents de reference
Application Portability Prole (APP)
Prole des systemes ouverts du gouvernement americain, Prole OSE/1, Version 2.0, NIST SP-500-210,
juin 1993.
DoD Intelligence Information System (DODIIS)
Modele de reference pour les annees 1990, Defense Intelligence Agency, Draft, 14 mai 1991.
Introduction a POSIX (P1003.0/D15)
IEEE, mai 1992.