TAFIM Besoins Modele de reference technique Vol 2

Transcription

1 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 Introduction Le modele L'entite logicielle applicative (ASE) L' "Application Program Interface" (API) L'entite applicative de la plate-forme (APE) L'environnement externe (EEI) Le modele detaille Presentation de l'architecture Les dierents modeles sous l'angle du traitement de l'information Le modele client/serveur Le modele base sur un serveur Le modele Ma^tre/Esclave etlemodele hierarchique Le modele "peer-to-peer" Le modele de gestion d'objets distribues Les dierents modeles sous l'angle de la gestion de l'information Le modele de gestion d'objets distribues Les dierents modeles sous l'angle de la gestion de l'information Le systeme de gestion des donnees

2 CONTENTS L'annuaire des donnees La securite des donnees Les dierents modeles sous l'angle de la securite Concepts de base Architecture generique de securite Sollicitation de services de securite Les services du systeme d'exploitation Les services reseaux Les services d'administration Guide d'implementation de TAFIM 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 Le modele de securite cible du DoD (La DGSA) Types d'architectures Architecture abstraite Architecture generique Architecture logique Architecture specique Processus de developpement de la DGSA Besoins en securite Perspectives d'architecture cible et d'evolution Concepts de securite Concepts de securite ES et RS Architecture de securite des ES Description de l'architecture de securite des ES Administration de la securite Relations entre les concepts de la DGSA et la gestion de la securite L'ISO et les concepts de securite de la DGSA Outils d'administration de la securite Standardisation des fonctions de securite

3 LIST OF FIGURES Systeme de transfert Contexte de securite distribuee Support du TS Inconvenients du TS Doctrine de securite Les services de securite Doctrine pour les services de securite Glossaire 32 9 Documents de reference 33 List of Figures 1 Vue d'ensemble de TAFIM Modele POSIX P 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 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.

4 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, 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 : d'information; suite des explications sur les dierents modeles d'organisation d'un systeme 26 mars 1997 : suite des travaux, mise a jour du document, 9avril 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.

5 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 Guide de planification Vol 4 - entreprise - mission - fonction - application Plan de soutien Vol 5 Guide Securite Vol 6 Plans de reutilisation 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 Composants communs Fournit des composants utilises pour developper conduit a Conception du systeme 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 dedepart le prol de portabilite des applications (NIST Application Portability Prole - APP) publie en L'APP denit un modele de reference et liste un certain nombre de specications (standards)

6 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 < Ces reexions ont m^uri au travers du document P valide par l'ieee. Le P est maintenant une norme de modelisation des systemes ouverts. Le P denit trois classes d'entites et deux types d'interfaces comme le montre le schema ci-dessous. Application Software Entity API Application Program Interface (API) Application Platform Entity EEI External Environment Interface (EEI) External Environment Figure 2: Modele POSIX P Il s'agit de

7 5. Le modele de reference de TAFIM 7 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). Nous allons maintenant presenter ces dierents elements, car ils interviennent dans TAFIM L'entite logicielle applicative (ASE) L'Application Software Entity est une application. Celle-ci repose sur des services du systeme d'exploitation, des bibliotheques, 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 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 API) comprenant les API des services reseau (API for Network ), les API des services d'information (Information API) comprenant les API pour la gestion des donnees et les services d'echange (APIs for Data Management and Data Interchange ), les API de services de communication Homme/Machine (Human/Computer Interaction API) comprenant les APIs pour les services d'interface avec l'utilisateur et les services graphiques (APIs for User Interface and Graphic ) 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.

8 5. Le modele de reference de TAFIM L'environnement externe (EEI) L'interface vers l'environnement externe (External EnvironmentInterface - 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 EEI (interface physique : clavier, souris, ecrans, micros, HP,...), Information EEI (interfaces avec les moyens de sauvegarde, formats assurant la portabilite et l'interoperabilite des donnees) Communications 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, af- chage 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, graphismes,...), des 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,

9 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 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.

10 5. Le modele de reference de TAFIM 10 "Mission Areas" Applications Support Applications Multi Média Communications Business Processing Environment Management Database Utilities Engineering Support System Communications Information Human/Computer Interaction Application Program Interface (API) Software Engineering Languages & Bindings CASE Environment & Tools Kernel Operation User Interface Graphical Client-Server Object Def & Management Window Management Dialogue Spt Application Platform Data Management Data Dictionary/ Directory DBMS Data Interchange Document Product Data Electronic Data Graphics Graphics Data Operating System Graphical Object Management Network Data Comm PC Support Shell and Utilities Internationalization Security System Management Distributed Computing External Environment Interface (EEI) Communications Information Human/Computer Interaction Communications Information Interchange 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

11 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 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. architecture est un mainframe avec son ensemble de terminaux. La conguration typique d'une telle 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.

12 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 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

13 5. Le modele de reference de TAFIM Le modele "peer-to-peer" Peer-to-Peer (égal à égal) Plate-forme Données Gestion Présentation Plate-forme Données 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 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".

14 5. Le modele de reference de TAFIM 14 Gestion distribuée des objets Distributed Object Management Plate-forme Données Gestion Présentation Interface Standard Plate-forme Données Gestion Présentation 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 peuventrealiser 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 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.

15 5. Le modele de reference de TAFIM 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 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 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) 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,...

16 5. Le modele de reference de TAFIM 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 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 Architecture generique de securite Le schema ci-dessous reprend l'architecture d'un systeme d'information au plan de la securite. LSE LSE ES LCS RS CN LSE RS CN LCS ES ES Environnement ES 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,...).

17 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 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 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 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

18 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.

19 7. Le modele de securite cible du DoD (La DGSA) 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.

20 7. Le modele de securite cible du DoD (La DGSA) 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 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 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 oudeladegradation du niveau de securite qu'ils impliquent doit ^etre citee dans les recommandations pour l'application du document 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 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 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,

21 7. Le modele de securite cible du DoD (La DGSA) 21 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). 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 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.

22 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 lasociete. 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 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.

23 7. Le modele de securite cible du DoD (La DGSA) 23 Les niveaux d intégration de TAFIM Intégration Personnelle Intégration Applicative Intégration Fonctionnelle Intégration par Mission Intégration d Entreprise Les éléments spécifiques de la gestion de l information pour l intégration Elements spécifiques au système pour la gestion de l information qui permettent de remplir les zones fonctionnelles de l intégration. Elements de la gestion de l information nécessaires pour atteindre les besoins fonctionnels qui permettent de réaliser la mission. Elements de la gestion de l information nécessaires permettant de réaliser un besoin au sein d un des domaines d une mission. 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. Environnement Opérationnel Conceptions spécifiques Guides Généraux IM : Information Management (gestion de l information) Figure 12: Les niveaux d'integration 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 lacharge 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.