Page Précédente Page Suivante Table des matières

5. Le modèle de référence de TAFIM

5.1 Introduction

TAFIM cherche à atteindre plusieurs buts. Tout d'abord, permettre d'avoir au niveau des agences du DoD, le même vocabulaire, la même représentation d'un système d'information, même si les systèmes sont différents. Le modèle de référence technique a pour but de bien représenter le système d'information afin d'identifier les problèmes et les solutions que l'on peut apporter en matière de portabilité des applications, mais aussi la juste-mesure et leur interopérabilité.

Le modèle de référence technique n'est pas une représentation d'un seul système d'information, mais un certain nombre de termes communs, d'interfaces communes au sein des différents éléments du système d'information.

Les profils de standards identifient les standards et les règles à suivre en terme de services et interfaces du modèle de référence. Cette liste de standards peut être allongée ou réduite pour répondre aux besoins spécifiques d'une mission. Le modèle de référence technique (TRM - Technical Reference Model) a pour but de faciliter l'interopérabilité entre des plates-formes spécifiques au sein de mêmes catégories de missions, mais également entre les catégories de missions différentes. Le but de TAFIM est de réduire les coûts.

5.2 Le modèle

TAFIM prend comme point de départ les réflexions qui ont été menées par les groupes POSIX. Ces réflexions ont mûri au travers du document P1003.0 validé par l'IEEE. Le P1003.0 est maintenant une norme de modélisation des systèmes ouverts. Le P1003.0 définit trois classes d'entités et deux types d'interfaces comme le montre le schéma ci-dessous.

Modèle POSIX P1003.0

Il s'agit de

Nous allons maintenant présenter ces différents éléments, car ils interviennent dans TAFIM.

L'entité logicielle applicative (ASE)

L'Application Software Entity est une application. Celle-ci repose sur des services du système d'exploitation, des bibliothèques, ...

L' "Application Program Interface" (API)

Les APIs sont définies comme étant les interfaces entre les applicatifs logiciels et la plate-forme supportant l'application sur laquelle les services sont présents. Originellement, il est défini comme support à la portabilité des applications, mais l'interopérabilité des applications et des plates-formes se fait également au niveau des API de communication. Les API définissent un jeu complet d'interfaces entre les applications et les plates-formes qui les accueillent. Ils peuvent être découpés en plusieurs groupes :

L'entité applicative de la plate-forme (APE)

L'entité "Plate-forme applicative" est définie comme un ensemble de ressources qui supportent les services sur lesquels les applications vont reposer. Il fournit également des interfaces qui permettent, autant que faire se peut, de rendre les caractéristiques de l'implémentation de la plate-forme transparentes à l'application logicielle.

Cette entité assure l'intégrité et gère les accès simultanés qui pourraient être concurrents. Toutes les applications doivent accéder aux ressources aux travers de ces API. Les services de l'entité "plate-forme" peuvent contenir un noyau système, un moniteur temps réel et tous les pilotes des périphériques.

Le concept de la plate-forme de l'application n'est pas lié à une implémentation de la plate-forme. La plate-forme peut être un seul processeur, un système distribué avec toutes les applications dédiées à un seul processeur.

L'environnement externe (EEI)

L'interface vers l'environnement externe (External Environment Interface - EEI) est l'interface entre la plate-forme de l'application et l'environnement extérieur avec lequel sont échangées des informations.

Originellement, il est défini comme étant le support de l'interopérabilité système et applicative. La portabilité des utilisateurs et des données est directement fournie par l'EEI.

Au sein de l'EEI, il est défini trois groupes :

TAFIM a pour axiome le principe suivant : un système d'information est constitué de services locaux à une machine ou distribués qui sont mis à disposition des applications et utilisateurs aux profils divers. TAFIM a regroupé les services offerts en plusieurs catégories. Leur somme constituent le potentiel mis à disposition des applications.

Les services répertoriés par TAFIM sont donc :

De cette liste, il en ressort le modèle TAFIM suivant : Modèle TAFIM

Modèle TAFIM

C'est à partir de cette vue de synthèse que le modèle détaillé va être décliné.

5.3 Le modèle détaillé

Le modèle est découpé en catégories de services en fonction des besoins des différents métiers.

5.4 Présentation de l'architecture

Il existe plusieurs manières de modéliser un système informatique. Chaque représentation est différente car la vue du système est différente pour l'observateur. Un administrateur système ne modèlisera pas de la même manière un système d'information qu'un architecte des données.

5.5 Les différents modèles sous l'angle du traitement de l'information

Nous allons présenter ici les différentes manières utilisées fréquemment pour modéliser l'architecture d'un système informatique.

Le modèle client/serveur

Dans le modèle client/serveur, le client a en charge d'effectuer les traitements de demande d'un service, et le serveur a en charge de répondre au client en lui fournissant le service. Le client et le serveur peuvent être sur la même plate-forme ou sur des plates-formes différentes.

Le modèle client/serveur est un type particulier de modèle de traitement distribué car il désigne un traitement coopératif. En effet, le client et le serveur effectuent des traitements dans le cadre de l'application complète (présentation, traitement fonctionnel et gestion des données).

Modèle client/serveur

Une application peut être considérée comme composée de trois parties différentes :

L'assignation de ces différents éléments au client ou au serveur permet d'avoir plusieurs configurations possibles pour une application client/serveur. On trouve le plus souvent cinq types de répartitions :

Ces cinq catégories sont basées sur un rapport du Gartner Group et sont citées fréquemment dans la littérature.

On trouve également un autre type d'architecture, qui est l'architecture multi-niveaux.

Le modèle basé sur un serveur

Modèle basé sur un serveur

Ce modèle concentre tous les traitements sur une seule machine. La configuration typique d'une telle architecture est un mainframe avec son ensemble de terminaux.

Le modèle Maître/Esclave et le modèle hiérarchique

Modèle Maître/Esclave

Modèle hiérarchique

Dans ce modèle, les serveurs esclaves sont attachés à un ordinateur maître. En terme de distribution, ce modèle est un pas supplémentaire vers le réparti par rapport au modèle basé sur une machine. L'ordinateur esclave n'effectue des traitements que lorsque l'ordinateur maître lui demande. Une configuration typique de ce type est un mainframe auquel est connecté un ensemble de PC fonctionnant en tant que terminaux passifs.

Le modèle hiérarchique est une extension de ce modèle sur plusieurs niveaux.

Le modèle "peer-to-peer"

Modèle peer-to-peer

Dans le modèle "peer-to-peer" ou "d'égal à égal", tous les ordinateurs sont à la fois serveurs et clients. Il y a des traitements coordonnés. Des fonctions sont rédondantes de chaque côté.

Le modèle de gestion d'objets distribués

Modèle Objet Distribué

Modèle Objet Distribué
Dans ce modèle, les appels aux procédures distantes utilisées typiquement pour la communication client/serveur et autres modèles de traitements distribués sont remplacés par des messages envoyés à des objets. Les services fournis par les systèmes sur un réseau sont traités comme des objets.

Le demandeur doit connaître la manière dont doit être configuré l'objet.

L'approche nécessite

  1. un mécanisme pour répartir les messages,
  2. un mécanisme pour coordonner la répartition des messages
  3. et les applications et services qui supportent une interface par envoi de messages.
Cette approche ne contraste par avec les modèles client serveur et "peer-to-peer" mais spécifie une interface homogène avec des plates-formes coopérantes. Il est considéré par certains comme une implémentation des modèles client/serveur et "peer-to-peer".

L'OMG (Object Management Groupe) a développé CORBA (Common Object Request Brocker Architecture) qui spécifie le protocole qu'une application cliente doit utiliser pour communiquer avec un (ORB) Object Request Brocker qui fournit le service. L'ORB spécifie la manière dont les objets peuvent réaliser des requêtes transparentes et recevoir des réponses. OLE (Microsoft Object Linking and Embedding), standard Microsoft sous Windows est un exemple de l'implémentation d'une gestion d'objets distribués par laquelle toutes les applications OLE peuvent travailler avec toutes les applications compatibles OLE.

5.6 Les différents modèles sous l'angle de la gestion de l'information

Les services de gestion de données peuvent se présenter sous plusieurs formes :

Les composants majeurs de telles architectures sont :

Le modèle de gestion d'objets distribués

Dans ce modèle, les RPC sont remplacés par des messages envoyés à des objets. Les services sont considérés comme des objets. Pour fonctionner, il est nécessaire que

5.7 Les différents modèles sous l'angle de la gestion de l'information

Afin d'aboutir à l'architecture de TAFIM, des solutions d'architecture intermédiaires seront mis en oeuvre. Le choix du système de gestion des données est un composant important tout comme l'annuaire des données et la sécurité de ces dernières. Ces trois composants vont de fait être détaillés.

Le système de gestion des données

Un tel système

Le modèle logique de données en caractérise le système de gestion. Les modèles existants sont :

L'annuaire des données

Il est constitué d'outils et de systèmes permettant d'une part de décrire les données stockées par l'un des systèmes précités et d'autre part de stocker des données concernant les données de la ou les bases (appelées métadonnées).

La sécurité des données

Ce composant assure la protection des données notamment par le refus d'accéder à celles-ci si l'utilisateur n'y est pas habilité. Il permet de placer des droits d'accès tels la lecture, l'écriture, la suppression,...

5.8 Les différents modèles sous l'angle de la sécurité

De plus amples explications seront apportées en ce qui concerne la sécurité dans le modèle TAFIM. Le présent chapitre en présente les principales caractéristiques.

Concepts de base

Définition du système d'information du point de vue de la sécurité

Un système d'information est constitué d'un réseau de communication et d'environnements locaux ou mobiles (appelés LSE).

Domaine d'information

Un tel domaine est constitué d'utilisateurs et de leurs données et d'une politique de sécurité. Cette politique définit les droits de chacun au sein du domaine. Dans un environnement important, on sera amené à constituer plusieurs domaines afin que la politique de sécurité s'adapte au mieux.

La politique mise en oeuvre devra tenir compte des "frontières" entre deux domaines.

"Isolation stricte"

Ce choix permet d'isoler hermétiquement l'information contenue dans un domaine vis à vis d'un autre. L'échange d'informations entre les deux domaines sera validé par des règles.

On définit de même des informations multi-domaines utilisables par un ensemble de domaines.

Protection absolue

Ce concept est mis en oeuvre dans des systèmes ayant plusieurs domaines ayant des politiques de sécurité très différentes. Cette protection a en charge d'homogénéiser les choix de sécurité afin d'éviter tout problème à l'interconnexion des domaines.

Architecture générique de sécurité

Le schéma ci-dessous reprend l'architecture d'un système d'information au plan de la sécurité.

Vue de l'architecture générique de sécurité

Dans ce schéma, un système de relais, RS, représente un composant permettant l'accès indirect à des informations par les utilisateurs (ex : un routeur, un hub,...).

Le système de communication local, LCS, est un réseau chargé des échanges entre deux LSE ou à l'intérieur d'un LSE.

Le réseau de communication, CN, assure les échanges entre les LSE mais est indépendant d'eux.

5.9 Sollicitation de services de sécurité

Un plus grand niveau de sécurité doit être instauré sur les composants d'extrémité et les systèmes de relais. De plus, le composant d'extrémité sera peut-être à la frontière de plusieurs domaines d'informations.

La majorité des mécanismes de sécurité peuvent être implémentés dans les services du système d'exploitation, les services réseaux, et enfin les services d'administration du système.

5.10 Les services du système d'exploitation

On peut assimiler l'environnement de protection d'une information à un espace d'environnement utilisateur. Chaque processus d'échange d'information, d'accès,... du système d'exploitation doit être le plus monolithique possible et les échanges bilatéraux entre ces processus doivent être connus.

Par l'utilisation d'espaces mémoire distincts, l'OS est capable de maintenir ce cloisonnement entre deux contextes de sécurité différents.

5.11 Les services réseaux

Pour des échanges entre deux ES, un "accord de sécurité" est convenu entre les deux entités. Cet accord met en oeuvre des protocoles, des procédures sécurisées.

Pour des échanges asynchrones, on utilisera une technique d'encapsulation des données, en ajoutant à celles-ci des attributs permettant un transfert sécurisé. On complètera ce mécanisme par la technique précédente si cela est jugé nécessaire.

5.12 Les services d'administration

La sécurité doit intervenir lors de l'installation, du paramétrage et l'utilisation des informations et de leurs domaines d'appartenance.

Ces services contrôlent les informations nécessaires à l'OS.

D'autre part, ces services ont besoin de mécanismes d'interruption ("handling"), d'audit et de restauration de contexte. La standardisation des protocoles et mécanismes de sécurité (appelé SMAP Security Management Application Processes) permettra la coopération des services de sécurité à travers différentes plate-formes. Les SMAP seront mis en oeuvre lors des échanges entre deux ES. Chaque ES s'appuie sur un SMAP qui mettra en oeuvre un protocole sécurisé pour les échanges dénommé SAMP (Security Association Management Protocol). Cf Chapitre 7.


Page Précédente Page Suivante Table des matières
© 1997 Tristan Debeaupuis - Hervé Schauer Consultants