TAFIM Tristan Debeaupuis 5 mai 1997 TAFIM (Technical Architecture Framework for Information Management) est un modèle d'architecture des systèmes d'information conçu par la DISA (Defense Information Systems Agency), agence dépendant du DoD (Department of Defense of the United States). Il est obligatoire d'utiliser ce modèle au sein du DoD. Ce modèle est repris par l'X/Open comme modèle de référence des systèmes ouverts. Les seules modifications apportées par l'X/Open sont des modifications de publi­ cation, il n'y a donc pas de modification du contenu du document. Ce document est un résumé des 1500 pages qui décrivent TAFIM V2.0 avec une attention particulière pour la DGSA (DoD Goal Security Architec­ ture), l'architecture cible de sécurité choisie par le DoD. Table of Contents: 1. Introduction 2. Historique de ce document 3. Comment est organisé TAFIM ? 4. Vue d'ensemble de TAFIM 5. Le modèle de référence de TAFIM 5.1 Introduction 5.2 Le modèle 5.2.1 L'entité logicielle applicative (ASE) 5.2.2 L' "Application Program Interface" (API) 5.2.3 L'entité applicative de la plate-forme (APE) 5.2.4 L'environnement externe (EEI) 5.3 Le modèle détaillé 5.4 Présentation de l'architecture 5.5 Les différents modèles sous l'angle du traitement de l'information 5.5.1 Le modèle client/serveur 5.5.2 Le modèle basé sur un serveur 5.5.3 Le modèle Maître/Esclave et le modèle hiérarchique 5.5.4 Le modèle "peer-to-peer" 5.5.5 Le modèle de gestion d'objets distribués 5.6 Les différents modèles sous l'angle de la gestion de l'information 5.6.1 Le modèle de gestion d'objets distribués 5.7 Les différents modèles sous l'angle de la gestion de l'information 5.7.1 Le système de gestion des données 5.7.2 L'annuaire des données 5.7.3 La sécurité des données 5.8 Les différents modèles sous l'angle de la sécurité 5.8.1 Concepts de base 5.8.1.1 Définition du système d'information du point de vue de la sécurité 5.8.1.2 Domaine d'information 5.8.1.3 "Isolation stricte" 5.8.1.4 Protection absolue 5.8.2 Architecture générique de sécurité 5.9 Sollicitation de services de sécurité 5.10 Les services du système d'exploitation 5.11 Les services réseaux 5.12 Les services d'administration 6. Guide d'implémentation de TAFIM 6.1 Initialisation du projet. Trame d'architecture 6.2 Spécification d'architecture 6.3 Architecture cible 6.4 Prise en compte de l'existant 6.5 Choix de migration 6.6 Planning de déploiement 6.7 Mise en oeuvre de l'administration 7. Le modèle de sécurité cible du DoD (La DGSA) 7.1 Types d'architectures 7.1.1 Architecture abstraite 7.1.2 Architecture générique 7.1.3 Architecture logique 7.1.4 Architecture spécifique 7.1.5 Processus de développement de la DGSA 7.1.5.1 Organisation du chapître 7.1.6 Besoins en sécurité 7.1.6.1 La politique de sécurité de la DGSA 7.1.6.2 Les besoins de sécurité de la DGSA 7.1.6.2.1 Support de plusieurs politiques de sécurité 7.1.6.2.2 Mise en oeuvre des systèmes ouverts 7.1.6.2.3 Politique de sécurité appropriée 7.1.6.2.4 Gestion globale de la sécurité 7.1.6.3 Autres besoins 7.1.6.4 Vision de la DoD 7.1.7 Perspectives d'architecture cible et d'évolution 7.1.8 Concepts de sécurité 7.1.8.1 Modélisation du SI d'un point de vue sécurité. 7.1.8.2 Allocations d'un service sécurisé 7.1.8.2.1 Cas des réseaux de communication 7.1.8.2.2 Cas des LSE 7.1.9 Concepts de sécurité 7.1.9.1 Domaines d'information 7.1.9.2 Isolation stricte 7.1.9.3 Partage et échange de données entre domaines 7.1.9.4 Informations et politiques multi-domaines 7.1.9.5 Protection absolue 7.1.9.6 Accréditation uniforme 7.1.9.7 Administration de la sécurité 7.2 ES et RS 7.2.1 Architecture de sécurité des ES 7.2.2 Description de l'architecture de sécurité des ES 7.2.2.1 Noyau séparateur 7.2.2.2 Contextes de sécurité 7.2.2.3 Fonctions de sécurité critique 7.2.2.3.1 SPDF (Security Policy Decision Function) 7.2.2.3.2 Fonction d'authentification 7.2.2.3.3 Fonction d'audit 7.2.2.3.4 Fonction de scheduling 7.2.2.3.5 Fonction de gestion de périphérique et gestionnaire de périphérique 7.2.2.4 Fonctions liées à la sécurité 7.2.2.4.1 Structure résiduelle de l'OS 7.2.2.4.2 Fonction de gestion de la sécurité 7.2.2.4.3 Fonction TS (système de transfert) 7.3 Administration de la sécurité 7.3.1 Relations entre les concepts de la DGSA et la gestion de la sécurité 7.3.2 L'ISO 7498-2 et les concepts de sécurité de la DGSA 7.3.3 Outils d'administration de la sécurité 7.3.3.1 Spécification des règles d'une politique de sécurité 7.3.3.2 Catalogue des mécanismes de sécurité 7.3.3.3 Application de maintenance pour les administrateurs de la sécurité 7.3.4 Standardisation des fonctions de sécurité 7.4 Système de transfert 7.4.1 Contexte de sécurité distribuée 7.4.1.1 Contexte distribué pour les communications interactives 7.4.1.2 Contextes distribués pour les communications asynchrones 7.4.1.3 Autres aspects des contextes distribués 7.4.2 Support du TS 7.4.3 Inconvénients du TS 7.5 Doctrine de sécurité 7.5.1 Les services de sécurité 7.5.2 Doctrine pour les services de sécurité 8. Glossaire 9. Documents de référence 1. Introduction Toutes les architectures et modélisations des systèmes d'information sont souvent définies spécifiquement à un métier. L'approche du DOD est de dire que : · l'on constate qu'au sein du DoD, il y a un nombre important d'applications spécifiques à des missions, à des plates-formes et des réseaux de communication. · l'infrastructure physique du système d'information du DoD consiste en un nombre important de systèmes peu flexibles, réservés à une seule tâche. Ces systèmes ont suivi une migration vers les systèmes ouverts à chaque fois différente, chacun progressant dans ses propres choix sans prendre gâre à l'interopérabilité. · le DoD a ressenti la nécessité de posséder un modèle de référence unique qui garde le souci de s'adapter à toutes les situations, à tous les métiers du DoD. Les buts recherchés par TAFIM sont : · l'utilisation de principes communs, des assertions et des terminologies dans les définitions des composants de l'architecture technique. (au niveau des Services, Agences, et Etats-Majors). · la définition d'une structure unique pour les composants de l'infrastructure technique du DoD (composants du système) et la manière dont ils sont gérés. · le développement de systèmes d'information en accord avec les principes communs afin de permettre l'intégration et l'interopérabilité au sein du DoD. TAFIM ne définit pas une architecture spécifique à un système. Il fournit les services, standards, guides de conception, composants et configurations qui peuvent être utilisés pour guider le développement d'architectures techniques qui répondent aux besoins d'une mission. TAFIM est indépendant des applications spécifiques aux missions et de leurs données associées. Il cherche avant tout à promouvoir l'interopérabilité, la portabilité et la juste-mesure des systèmes d'information du DoD. TAFIM est un guide permettant au niveau de l'entreprise de développer des architectures techniques qui répondent à des besoins précis. L'utilisation de TAFIM peut : · promouvoir l'intégration, l'interopérabilité, la modularité et la flexibilité, · guider lors de l'achat et la réutilisation de produits du marché, · accélérer la mise en place des technologies de l'information et abaisser ses coûts. TAFIM a été choisi a posteriori par l'X/Open comme modèle pour son architecture des systèmes ouverts. Le document TAFIM devrait être publié par l'X/Open sans modifications. En général, lorsqu'un document de normalisation est repris par un autre organisme, il est réécrit, mais aucune autre modification que les erreurs de retranscriptions n'est effectuée. 2. Historique de ce document · Fin 1994 : premières discussions au sein du groupe AFNOR/POSIX autour de TAFIM; · Début 1995 : L'AFNOR mandate Tristan Debeaupuis pour étudier TAFIM et présenter bénévolement au groupe CN 22 GE POSIX TAFIM V2.0; · 16 juillet 1996 : rédaction de la première version de ce document. · 28 décembre 1996 : suite des explications sur les différents modèles d'organisation d'un système d'information; · 26 mars 1997 : suite des travaux, mise à jour du document, · 9 avril 1997 : intégration du volume 4, · 5 mai 1997 : version intégrant la DGSA, · 6 mai 1997 : présentation au groupe AFNOR/POSIX du résultat des travaux sur TAFIM, · juin 1997 : présentation au groupe OSSIR/SUR de la DGSA. 3. Comment est organisé TAFIM ? TAFIM se compose de 8 volumes. · Volume 1 : Vue d'ensemble · Volume 2 : Modèle de référence technique · Volume 3 : Concepts d'architecture et guide de conception · Volume 4 : Guide de planification de migration vers une architecture basé sur les standards du DoD. · Volume 5 : Guide d'utilisation de TAFIM lors des achats · Volume 6 : Présentation du DGSA (DoD Goal Security Architecture) qui décrit les besoins en terme de sécurité des architectures techniques. Ce guide définit un certain nombre de mécanismes et de fonctions de sécurité qui guident l'architecte dans le développement d'architectures spécifiques. · Volume 7 : Guide d'utilisation des standards. Ce volume présente un certain nombre de profils de standards utilisables au sein du DoD. · Volume 8 : Guide servant de trame à la définition d'une interface homme/machine. Ainsi, le schéma ci-après reprend la démarche et les objectifs visés par les différents documents constituant TAFIM. Vue d'ensemble de TAFIM 4. Vue d'ensemble de TAFIM TAFIM est issu d'une décision du DoD de se doter d'un modèle d'architecture technique. TAFIM a pour point de départ le profil de portabilité des applications (NIST Application Portability Profile - APP) publié en 1991. L'APP définit un modèle de référence et liste un certain nombre de spécifications (standards) qui définissent les interfaces, services, protocoles et formats de données pour l'implémentation de systèmes ouverts. En utilisant l'APP, la DISA a analysé les documents de référence du DoD, et notamment le DODIIS (DoD Intelligence Information System Reference Model), modèle de référence du système d'information de l'agence de renseignement du DoD. 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 · l'Entité logicielle applicative (Application Software Entity), · l'Interface de programmation (API), · l'Entité applicative de la plate-forme (Application Platform Entity), · enfin de l'Environnement externe (External Environment). Nous allons maintenant présenter ces différents éléments, car ils interviennent dans TAFIM. 5.2.1. 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, ... 5.2.2. 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 : · les API des services du système (System Services API) qui incluent les API pour les services de génie logiciel et les API des services du système d'exploitation, · les API des services de communication (Communications Services API) comprenant les API des services réseau (API for Network Services), · les API des services d'information (Information Services API) comprenant les API pour la gestion des données et les services d'échange (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'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. 5.2.4. 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 : · Human/Computer Interaction Services EEI (interface physique : clavier, souris, écrans, micros, HP, ...), · Information Services EEI (interfaces avec les moyens de sauvegarde, formats assurant la portabilité et l'interopérabilité des données) · Communications Services EEI (services de gestion des protocoles externes, formats d'échange de données). 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 : · le multimedia, · les services de communication, · le business-processing, · l'administration du contexte applicatif (par l'apport de mécanismes de type batch, transactions, affichage trié,...), · la gestion des données (comprenant des requêteurs, des mécanismes d'affichage des données, des annuaires, des outils d'accès aux données ou DBMS), · les services applicatifs partagés. Il s'agit là de services conçus dans le cadre d'une application et mis à disposition (dans un objectif de ré-utilisabilité) des autres applications, · les outils de programmation, · les interfaces utilisateur, · les échanges de données (on entendra par données des documents simples ou complexes, des graphismes,...), · le traitement graphique, · l'accès au réseau, · l'accès au système d'exploitation, · le support " de l'international ", ou en d'autre terme, la possibilité de supporter plusieurs langages, · les multi plates-formes (il s'agira de services capables de se dérouler sur plusieurs machines), · la gestion/administration du système comprenant la gestion de la configuration, le suivi des performances, les audits, les mécanismes de tolérance aux pannes et la sécurité, · les services distribués : le temps universel, l'accès aux données et fichiers sur toutes les machines, l'annuaire global, les échanges inter-processus et les threads, · enfin la sécurité. Le niveau de sécurité mis en place dépend, dans TAFIM, "de la valeur de la donnée". Ce dernier service est découpé en quatre méthodes : · l'authentification. Le service d'authentification peut être sollicité à l'ouverture ou durant une session, · le contrôle d'accès, · l'intégrité des données : ce service vérifie si les données n'ont pas été altérées ou détruites, · la confidentialité des données par la surveillance des accès aux ressources, · la " non-répudiation ", mécanisme d'acquittement permettant lors d'un échange de données entre deux processus de certifier que la donnée véhiculée est correcte, · la disponibilité qui s'assure que les services permanents sont disponibles. 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'informa­ tion Nous allons présenter ici les différentes manières utilisées fréquemment pour modéliser l'architecture d'un système informatique. 5.5.1. 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 : · les fonctions de l'application, · la présentation, · la gestion des données. 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 : · présentation distribuée, · présentation distante, · gestion des données distante, · fonction distribuée, · gestion des données distribuée. 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. 5.5.2. 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. 5.5.3. 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. 5.5.4. 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é. 5.5.5. 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'informa­ tion Les services de gestion de données peuvent se présenter sous plusieurs formes : · mega-centres fournissant des bases de données corporatives (orientées sur les fonctions) ayant des exigences locales et distantes, · systèmes de gestion de bases de données distribuées supportant des utilisations interactives de bases de données partitionnées et partiellement dupliquées, · systèmes de gestion de fichiers fournit par les systèmes d'exploitation qui peuvent être utilisés en interactif ou en batch. Les composants majeurs de telles architectures sont : · les systèmes de gestion de BDD, · les dictionnaires et répertoires de données, · la sécurité des données. 5.6.1. 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 · les applications et services possèdent une interface pour la gestion des messages, · un mécanisme permette la distribution des messages, · enfin, un mécanisme assure la délivrance de ces messages. 5.7. Les différents modèles sous l'angle de la gestion de l'informa­ tion 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. 5.7.1. Le système de gestion des données Un tel système · structure les données et en permet la réorganisation, · en offre un accès, · optimise la duplication, · supporte une interface de programmation · et offre des mécanismes de sécurisation et de contrôle. Le modèle logique de données en caractérise le système de gestion. Les modèles existants sont : · le modèle relationnel, qui organise des données dans des tables liées par des relations, · le modèle hiérarchique, qui struture les données dans un arbre, · le modèle réseau qui est une extension du modèle précédent permettant qu'un objet de l'arbre ait plus d'une relation avec ses branches parentes, · le modèle orienté objets, qui doit être à la fois un système de gestion de données (quel qu'en soit le type) et un système orienté objets; · les fichiers plats couplés en général avec une méthode de gestion des accès, · les SGBD distribués qui offrent la possibilité d'administrer une base de données répartie sur plusieurs plateformes, · les SGBD distribués hétérogènes, constitués d'un ensemble de bases de données hétérogènes gérées chacune par un SGBD. Des passerelles permettent de cacher cette hétérogénéité à l'utilisateur en lui donnant toujours accès à un point d'entrée unique que l'on appelera fédérateur. 5.7.2. 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). 5.7.3. 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. 5.8.1. Concepts de base 5.8.1.1. 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). 5.8.1.2. 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. 5.8.1.3. 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. 5.8.1.4. 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. 5.8.2. 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. 6. Guide d'implémentation de TAFIM La mise en oeuvre d'une architecture telle que TAFIM respecte un cycle de vie comprenant 7 étapes comme le montre le schéma ci-dessous. -> Schéma page vii volume 4 Le volume 4 de TAFIM constitue le SBA Guide, Standards-Based Architecture Planning Guide et décrit chacune de ces étapes qui sont présentemment explicitées. 6.1. Initialisation du projet. Trame d'architecture On pourrait assimiler cette étape à un schéma directeur durant lequel les processus et besoins de l'entreprise sont revus pour établir la corrélation entre le système d'information et ces processus. Les équipes projet sont identifiées et un état des lieux du système d'information existant est dressé. 6.2. Spécification d'architecture Cette étape se conclut par un schéma de l'architecture du système d'information sous trois angles différents : · (les méthodes) de travail, · l'organisation de l'entreprise, · les applications (notamment les applications métiers), · les technologies. Les spécifications détaillées de l'architecture ne sont pas réalisées durant cette étape. Celles-ci constituent un des livrables de la troisième étape. 6.3. Architecture cible Cette étape est le coeur du cycle de vie de l'architecture. Des solutions d'architecture sont comparées tout en se projettant à 5 ans dans l'avenir (l'architecture choisie doit en effet faire l'objet d'une certaine pérennité afin de ne pas "précipiter" la mise en place de l'architecture qui la suivra). Pour l'architecture retenue, on identifiera chaque composant finement et l'on précisera ses options de mise en oeuvre. 6.4. Prise en compte de l'existant Durant cette étape, l'architecture choisie sur papier est calquée à l'organisation existante afin de s'assurer des choix faits et de déceler les intérêts immédiats de l'architecture sur les métiers de l'entreprise. D'autre part, une liste des sous-projets nécessaires à la mise en application de l'architecture sur le SI est dressée. 6.5. Choix de migration Plusieurs étapes de migration peuvent être définies durant cette phase pour aboutir à l'architecture cible. On donne à chaque sous-projet déterminé précédemment une priorité afin d'établir un planning global. 6.6. Planning de déploiement Un planning fin comprenant tous les projets et sous-projets est constitué à cette étape du processus. 6.7. Mise en oeuvre de l'administration Cette étape 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 paramètres des composants qui la constituent. 7. Le modèle de sécurité cible du DoD (La DGSA) Dans ce chapitre, nous allons présenter la DGSA (Department of Defense Goal Security Architecture). Le programme américain DISSP (Defense Information System Security Program) a été lancé par l'assistant au secrétaire d'état à la Défense (Command, Control, Communication and Intelligence). La DISA et la NSA ont collaboré pour définir 8 objectifs. Les domaines suivants sont traités dans les 8 objectifs suivants : · politique de sécurité, · architecture, · standards, · protocoles, · procédures d'accréditation, · technologies, · planification des transitions, · amélioration de l'organisation, · disponibilité des produits et services. La DGSA prend en compte la protection de l'information et les avantages du système comme une partie de la vision globale des missions, des menaces, de la performance, de l'interopérabilité, de l'extensibilité, de l'utilisabilité, et des coûts de l'implémentation. La DGSA se veut, à l'image de TAFIM, assez générique pour que tous les cas particuliers puissent également être modélisés. 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 fixée pour atteindre ce but. Elle fournit également les bases pour le développement de mécanismes de sécurité qui pourraient être choisis par les ingénieurs responsables de la conception de systèmes de sécurité. La DGSA repose sur l'étude de plusieurs systèmes : · DISN : Defense Information Systems Network, · DMS : Defense Message System, · ITSDN : le réseau intégré tactique et stratégique, · MLS : DoD Multilevel Security Program. 7.1. Types d'architectures Il existe plusieurs types d'architecture pour une seule réalité. Nous allons définir ici un certain nombre d'architectures qui se différencient en fonction du niveau d'abstraction que l'on choisit. 7.1.1. Architecture abstraite La définition de l'architecture abstraite commence par la connaissance des besoins et définit les fonctions correspondantes à mettre en oeuvre. Elle définit les concepts fondamentaux qui guident la selection et l'organisation des fonctions. Les architectures abstraites édictent les principes, concepts fondamentaux et fonctions qui satisfont les besoins typiques de sécurité. Ces concepts et fonctions sont alloués aux éléments d'une définition abstraite de l'architecture du système d'information. 7.1.2. Architecture générique Le développement d'une architecture générique est basé sur les décisions prises lors de la rédaction de l'architecture abstraite. Elle définit les types généraux des composants et standards autorisés et identifie toute recommandation nécessaire pour leur application. Une architecture générique commence par définir une assignation initiale, des fonctions et services de sécurité, puis définit les types de composants et mécanismes de sécurité qui sont disponibles pour mettre en place les services de sécurité avec des niveaux de sécurité particuliers. Toute limitation dans la combinaison des composants et des mécanismes, à cause de leur incompatibilité ou de la dégradation du niveau de sécurité qu'ils impliquent doit être citée dans les recommandations pour l'application du document. 7.1.3. Architecture logique Une architecture logique est une conception qui répond à un ensemble d'exigences hypothétiques. Il sert d'exemple détaillé qui illustre les résultats de l'application d'une architecture générique dans des circonstances spécifiques. Les seules différences entre une architecture logique et une architecture spécifique sont dues au fait que les exigences spécifiques sont réelles, non hypothétiques, et parce que l'architecture logique n'est pas faite avec l'intention d'être implémentée. Elle est indépendante des coûts. Dans les architectures logiques, la conception logique est accompagnée par l'illustration de l'analyse de sécurité qui doit être réalisée dans des architectures spécifiques. 7.1.4. Architecture spécifique L'objectif de tout architecte système est de réaliser une spécification de conception de sorte que les composants puissent être achetés pour implémenter le système. L'architecture spécifique traite des composants, interfaces, standards, performances et coûts. Les architectures de sécurité spécifiques montrent tous les composants de sécurité choisis et les mécanismes, incluant les doctrines et les composants de gestion combinés pour atteindre les exigences de sécurité du système spécifique que l'on considère. 7.1.5. Processus de développement de la DGSA Le développement de la DGSA est réalisé à l'aide d'un processus itératif : · réaliser une analyse des exigences, · créer une structure pour l'architecture, · allouer les services de sécurité, · choisir les composants et les mécanismes de sécurité, · réaliser une analyse d'interdépendance (évaluation). 7.1.5.1. Organisation du chapître Après une présentation générale des besoins, les liens entre la DGSA, TAFIM et C4IFTW seront explicités. Une présentation des principales clefs de la sécurité et des principaux composants d'un système d'information suivra. Chacun d'eux sera ensuite détaillé. 7.1.6. Besoins en sécurité Chaque société a ses propres besoins en terme de sécurité qu'elle formalise sous forme de documents. Ces documents s'appliquent ensuite aux utilisateurs et à leur environnement, aux données,... Une architecture de sécurité constitue une réponse concrète à ces documents qui doit s'insérer dans le schéma d'architecture globale du système d'information. Quels que soient les besoins de l'entreprise, le processus à retenir est le suivant : · les informations "à protéger" sont identifiées, · les besoins d'accès à ces dernières sont établis, · l'importance des informations et leurs conséquences sont évaluées, · la solution de sécurité établit les protections nécessaires en fonction des risques et met en place des services sécurisés. 7.1.6.1. La politique de sécurité de la DGSA Pour comprendre la démarche retenue par la DoD, il est important de situer rapidement le contexte dans lequel elle a été pensée : · les systèmes d'informations doivent pouvoir s'adapter à différentes politiques de sécurité, · ces systèmes doivent être suffisamment protégés pour permettre la distribution des données et des traitements sur plusieurs machines, · ils doivent offrir des niveaux de sécurité différents en fonction des habilitations des utilisateurs, · enfin, il doit être possible de baser l'interconnexion des sites sur un réseau public. 7.1.6.2. Les besoins de sécurité de la DGSA Ces besoins dérivent des quatre points précédents. 7.1.6.2.1. Support de plusieurs politiques de sécurité Les utilisateurs souhaitant accéder depuis leur station à des informations éventuellement avec des droits d'accès différents à chaque application, ce besoin est important. Pour y répondre, le SI doit être capable de dissocier les utilisateurs et les informations pour les placer à différents niveaux de protection. 7.1.6.2.2. Mise en oeuvre des systèmes ouverts L'emploi de tels systèmes est indispensable dès lors qu'il doit être possible d'interconnecter les sites par différentes méthodes et assurer par ces biais des échanges de données. 7.1.6.2.3. Politique de sécurité appropriée Le choix de la solution de sécurité dépend des besoins. Une partie de cette solution est impactée par la sécurité mise en place dans les communications. Lors de l'utilisation d'un réseau public, le SI doit prendre en charge la sécurisation des données et l'opérateur se contenter d'offrir un transport fiable. 7.1.6.2.4. Gestion globale de la sécurité Une telle solution permet aux administrations d'avoir une vue globale sur la sécurité même si plusieurs politiques de sécurité sont établies. 7.1.6.3. Autres besoins Une des premières nécessités issues du souhait de supporter plusieurs politiques de sécurité provient de la capacité à répondre à l'une d'elles indépendamment des autres. L'information doit pouvoir ainsi être identifiée pour chaque politique. Ainsi toutes les références à des informations par des utilisateurs doivent passer par un moniteur de référence. Lors d'échanges distants on utilisera l'authentification mutuelle, le contrôle d'accès,... L'emploi de standards internationaux pour les protocoles d'échange assure d'autre part la possibilité aux utilisateurs de choisir sans inconvénient quelle information envoyer vers d'autres utilisateurs. Cette négociation pourrait être effectuée lors de l'initialisation de l'échange : les utilisateurs conviendraient de ce qui doit être véhiculé. D'autre part, le fait de retenir plusieurs services de sécurité implémentés dans différents mécanismes (pour répondre à des besoins diverses de protection) implique de vérifier que les mécanismes conviennent certes individuellement mais aussi une fois combinés. Les principaux éléments à administrer dans la DGSA sont les utilisateurs, les règles de sécurité, les informations, les systèmes chargés d'appliquer les règles de sécurité ainsi que les fonctions sécurisées implémentées sur ces systèmes. Pour ce faire, le format de représentation de ces objets à administrer doit être normalisé. 7.1.6.4. Vision de la DoD Le DoD pense que les constructeurs et fournisseurs de logiciels doivent de plus en plus inclure des mécanismes de sécurité au sein de leur produit car les sociétés freinent l'implémentation de ces mécanismes pour des raisons de coûts. Un des moyens de réussir pour une entreprise est de s'ouvrir grâce aux technologies communicantes. Afin de minimiser les coûts, l'utilisation des réseaux publics est nécessaire bien que cette solution accroisse les risques d'attaque. D'autre part, ce type de solution permet de réposer sur des standard en terme de transport d'information et de concentrer la réflexion d'architecture sur les couches supérieures du modèle OSI. L'entreprise doit de plus mettre à 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 à la société. Ceci pose un problème étant donné que la DGSA modèlise toutes les données et les règles de sécurité à suivre. L'utilisateur souhaite quant à lui s'abstraire des domaines de sécurité en s'appuyant sur un unique mécanisme d'authentification pour accéder à une donnée qu'elle qu'en soit le lieu d'accès. L'accrédation et la certification des produits sont des réponses aux besoins de sécurité. Afin de réduire les procédures, il doit être envisagé de créer des certificateurs et des accréditeurs de produits. Cela permettrait d'homogénéiser les certifications et d'assurer une certaine interopérabilité. 7.1.7. Perspectives d'architecture cible et d'évolution Le schéma suivant représente l'architecture retenue pour le DIS. Il tient des besoins et points de vue révélés dans TAFIM. Les niveaux d'intégration 7.1.8. Concepts de sécurité 7.1.8.1. Modélisation du SI d'un point de vue sécurité. Un premier modèle simple du SI consiste à dire que deux environnements locaux (appelés LSE, local subscriber environments) souhaitent communiquer à travers un réseau. Chaque LSE est constitué des matériels et systèmes sous le contrôle de l'utilisateur. Un LSE peut ensuite être décomposé en plusieurs éléments : des systèmes ouverts (ou "End System") car directement accessibles par les utilisateurs, des systèmes relais (RS) et des systèmes de communication locale (LCS). Enfin, le système de transfert inclut tous les protocoles inclus dans les ES et les RS ainsi qu'à l'interconnexion des LCS et du réseau de communication (CN). Les LSE vus sous l'angle de la sécurité Les CN peuvent être de deux types : privés ou publics. Dans le premier cas, l'isolement apporté par ce type de lien est dénommé TFS (complete traffic flow security). 7.1.8.2. Allocations d'un service sécurisé La DGSA compte dans les services de sécurité l'authentification, le contrôle d'accès, l'intégrité des données, la non-répudiation et la disponibilité. Nous allons examiner ces services dans les LSE et les CN. 7.1.8.2.1. Cas des réseaux de communication Les CN n'ont pas en charge d'assurer un TFS mais doivent assurer une continuité de service. Le TFS est à la charge des LSE qui doivent alors être sécurisés. L'architecture des réseaux de communication ne doit pas reposer sur la confidentialité des données mais sur la qualité de service et le besoin de reprise en cas d'incident. 7.1.8.2.2. Cas des LSE Une première protection des LSE est physique : il s'agira de la protection des locaux (identification du personnel,..). Un LSE doit pouvoir communiquer indifféremment avec un LSE sécurisé et un LSE non sécurisé. Dans ce dernier cas, le LSE sécurisé doit isoler ses informations sensibles. A l'intérieur des LSE, les LCS sont chargés d'apporter la sécurité nécessaire à la communication entre les ES et les systèmes relais internes aux LSE. Les ES et les systèmes relais apportent les autres services de sécurité (authentification de l'utilisateur, contrôle d'accès, non- répudiation, confidentialité, intégrité et disponibilité). Le TS (système de transfert) apporte un dernier niveau de sécurité tout comme les systèmes relais. Ainsi, les transferts étant protégés, les informations de type authentification, identification, politique de sécurité, droits d'accès,...peuvent être échangées. Le modèle ISO 7498-2 a été retenu pour la DGSA. Le schéma ci-dessous reprend la répartition des services de sécurité entre les différents éléments de l'architecture. 7.1.9. Concepts de sécurité 7.1.9.1. Domaines d'information Les personnes d'une entreprise manipulent des données et déterminent leurs niveaux de sécurité. Un groupe d'utilisateurs peut donc identifier ses informations et une politique de sécurité peut être connue et appliquée par tous les membres du groupe. On appelle domaine d'information le triplet (groupe d'utilisateurs, informations, politique de sécurité). Les domaines d'information ne sont pas liés de manière hiérarchique. Ils ne sont de plus pas délimités par des machines ou des réseaux mais par les informations qu'ils intègrent. Un système d'information doit donc être capable d'héberger plusieurs de ces domaines. Les règles de sécurité doivent s'appliquer de manière homogène à toutes les informations d'un domaine. 7.1.9.2. Isolation stricte Il doit être possible à un système d'isoler deux domaines d'information de manière hermétique. On parle alors d'isolation stricte. Cette politique de cloisonnement est la relation par défaut entre deux domaines. 7.1.9.3. Partage et échange de données entre domaines Deux solutions simples consistent à créer dans les domaines les utilisateurs ayant besoin d'accéder aux informations partagées ou de créer un domaine d'information avec tout ce qui doit être partagé. Le transfert répond à des règles de sécurité définies dans les domaines source et cible et est effectué par un utilisateur identifié dans ces deux-ci. Toute information copiée ou déplacée doit être re-labellisée dans son nouveau domaine d'appartenance. Les échanges inter-domaines ne se produisent qu'à l'intérieur des ES ou des RS alors que les transferts entre ES ou RS s'effectuent à travers le même domaine. 7.1.9.4. Informations et politiques multi-domaines Une information multi-domaines est un ensemble d'informations provenant de domaines différents. Une politique spécifique de sécurité s'applique à ces données. Celle-ci s'appuiera sur des politiques existantes auxquelles on ajoutera la définition de droits spécifiques. La notion de hiérarchie des droits pourra de plus s'appliquer aux informations multi-domaines. 7.1.9.5. Protection absolue Dans un environnement hétérogène, il est impossible de s'appuyer sur la sécurité physique et la cryptographie de LSE isolés. Il est nécessaire de s'appuyer sur la protection apportée par un ensemble de LSE hétérogènes. Le concept de protection absolue est défini pour offrir l'homogénéité des moyens de protection supportés dans un domaine d'information. Même si les implémentations sont différentes dans chaque LSE, elles doivent apporter la même "force de protection" donnant là une réponse homogène au besoin de sécurité. 7.1.9.6. Accréditation uniforme Les trois concepts précédents contribuent à la constitution d'une accréditation uniforme. L'objectif est d'avoir un niveau de protection équivalent dans tous les LSE qui supportent un domaine d'information. L'isolation stricte établit une indépendance basique entre les domaines supportés par un LSE ce qui permet d'utiliser pour chacun des mécanismes de sécurité différents. La protection absolue quant à elle assure que la sécurité nécessaire est implémentée uniformément entre les LSE supportant un domaine. Un acréditeur établit une évalution pour chaque LSE. 7.1.9.7. Administration de la sécurité Cette administration concerne l'intérieur des LSE ainsi que leurs liens. Un administrateur utilise une MAP (Management Application Process) pour gérer les informations d'administration ; ces dernières sont une base appelée MIB (Management Information Base). Dans le domaine de la sécurité, on parlera de SMAP et SMIB (S pour security). Tout comme les données, 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 modèle de sécurité est approprié à 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'étant le cas le plus complexe. 7.2.1. Architecture de sécurité des ES La sécurité est répartie sur le matériel et le logiciel dans ces ES. Cette répartition est fonction du type de sécurité recherché. Le premier niveau de sécurité consiste en la protection des locaux et l'identification du personnel. Le LSE protège donc le matériel. Le matériel quant à lui peut protéger le logiciel en assurant son cloisonnement et en protégeant par mot de passe les accès aux composants matériels. Le matériel sera chargé également de protéger les données des interférences radio. Des matériels à tolérance de panne pourront enrichir la sécurité. Les mécanismes de cryptographie basés sur du matériel seront mis en oeuvre si besoin est. Enfin des mécanismes matériels tels que le mapping de la mémoire contribueront à la protection des données. Enfin le logiciel protège les informations par le biais des protections mises en oeuvre dans les systèmes de transfert. Les ES supportant les TS assureront les mécanismes de sécurité de ces derniers. Les ES inclueront de plus les applications chargées de l'administration de la sécurité. L'ES sera responsable de l'authentification des utilisateurs, du contrôle des accès, de l'intégrité et du stockage des données. 7.2.2. Description de l'architecture de sécurité des ES Définitions : · un contexte de sécurité est une combinaison des LSE, matériels, logiciels, applications utilisateur et des informations d'un utilisateur au sein d'un domaine d'information. Un contexte de sécurité est différent d'un contexte utilisateur car il inclut les protections apportées par les LSE. · un noyau séparateur (separation kernel) assure les protections matérielles des ES (états de registres, mapping de la mémoire,...) pour isoler les contextes de sécurité en leur allouant des zones mémoires séparées. Ce noyau assure les communications entre les contextes de sécurité. De nombreux services s'appuient ainsi sur le noyau séparateur à l'aide l'API. Les différents points de cette architecture sont décrits ci-après. 7.2.2.1. Noyau séparateur Dans un système d'exploitation, on conçoit chaque fonction sous forme de petits codes indépendants. On suggère de plus d'isoler chaque noyau dans un processus ayant son propre espace mémoire. Un noyau séparateur est alors chargé d'assurer ce cloisonnement. Ce noyau est considéré comme le coeur de la sécurité de la DGSA. De par cette séparation, les fonctions d'attribution des droits d'accès et les fonctions de renforcement des droits sont cloisonnées ce qui permet le support de plusieurs politiques de contrôle d'accès. 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 séparateur sera l'implémentation du SPEF dans l'ES. 7.2.2.2. Contextes de sécurité Les mécanismes de sécurité suivant sont nécessaires pour assurer le cloisonnement de ces contextes : · identification unique de chaque contexte, · identification du domaine d'informations, · valeurs de registres associées au contrôle des ressources de l'ES, · authentification de l'utilisateur, · permissions de l'utilisateur, · structures de données permettant l'emploi de fonctions sécurisées. Etant donné qu'un utilisateur peut vouloir accéder à plusieurs contextes de sécurité, les transferts entre les contextes doivent être validés par la ou les politiques de sécurité du domaine d'information. Le mécanisme de login est indispensable pour reconnaître l'utilisateur et déterminer le domaine d'information sollicité. 7.2.2.3. Fonctions de sécurité critique 7.2.2.3.1. SPDF (Security Policy Decision Function) Le premier rôle du SPDF est d'isoler l'ensemble de l'ES des politiques de sécurité. A des fins de facilité, les représentations de ces politiques sont regroupées en un endroit. L'approche retenue pour le SPDF permet une implémentation indépendance de fonctions de sécurité particulière. 7.2.2.3.2. Fonction d'authentification La fonction d'authentification est l'interface qui s'appuie sur des mécanismes d'authentification employés pour la reconnaissance de l'utilisateur. Un ES supportant plusieurs domaines d'information aura peut-être besoin de solliciter des mécanismes d'authentification différents pour chacun d'eux. Le système de transfert doit protéger l'identité de l'utilisateur authentifié lors d'un accès à plusieurs domaines d'information. 7.2.2.3.3. Fonction d'audit Cette fonction reçoit des messages depuis des fonctions de l'ES en accord avec le domaine d'informations et les politiques de sécurité (provenant d'une MIB). Les messages sont envoyés vers un utilisateur pour éviter leur perte. 7.2.2.3.4. Fonction de scheduling Le scheduler doit être inclus dans les fonctions de sécurité afin qu'aucun processus ne mobilise le processeur au dépend d'autres. 7.2.2.3.5. Fonction de gestion de périphérique et gestionnaire de périphérique On compte parmi ces fonctions de contrôle : · la fonction de gestion de la mémoire, · la fonction de gestion de fichiers, · la fonction de gestion de l'affichage qui doit savoir gérer l'affichage d'informations provenant de domaines d'information différents. · la fonction de gestion des communications inter-processus, · la fonction de gestion des services de cryptographie qui peut supporter des services de confidentialité, d'intégrité de données, d'authentification de l'origine des données et enfin de non- répudiation, · enfin toutes les fonctions de gestion de périphérique. 7.2.2.4. Fonctions liées à la sécurité 7.2.2.4.1. Structure résiduelle de l'OS Il s'agira là de toutes les autres fonctions d'un système d'exploitation non citées précédemment. Etant donné que les contextes de sécurité sont indépendants, ils peuvent donc reposer sur des structures résiduelles différentes. La modularité d'un système d'exploitation permet donc d'aboutir au schéma suivant : Relations de sécurité entre les applications et le système d'exploitation 7.2.2.4.2. Fonction de gestion de la sécurité Son rôle est de contrôler les informations nécessaires aux fonctions de sécurité. Ces informations seront détaillées par la suite. 7.2.2.4.3. Fonction TS (système de transfert) Les fonctions de communication X400, les services d'annuaire X500 et les protocoles d'échanges sont considérées comme des parties non- fiables. Elles sollicitent des services de sécurité. 7.3. Administration de la sécurité 7.3.1. Relations entre les concepts de la DGSA et la gestion de la sécurité 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 sécurité. Entre autres, les éléments suivants doivent figurer dans la politique de sécurité d'un domaine d'information : · description succinte du contexte de la mission couverte par le domaine, · descriptions des informations, de leurs attributs, et leurs règles d'utilisation entre plusieurs domaines, · règles pour les transferts multi-domaines, · exigence des services de sécurité, · critères d'acceptation pour l'implémentation de ces services, · critères spécifiques de sécurité (ex : relations entre les informations d'administration et les données), · identification d'un ou plusieurs utilisateurs. Les règles de sécurité font partie des SMIB. Chaque SMIB est accédée par un administrateur à l'aide d'une SMAP. 7.3.2. L'ISO 7498-2 et les concepts de sécurité de la DGSA 7.3.3. Outils d'administration de la sécurité 7.3.3.1. Spécification des règles d'une politique de sécurité La spécification de ces règles par un outil nécessite encore des recherches, les outils existants étant des plus basiques. 7.3.3.2. Catalogue des mécanismes de sécurité Un tel catalogue permettant de choisir les mécanismes de sécurité répondant au besoin du projet n'existe pas à ce jour. 7.3.3.3. Application de maintenance pour les administrateurs de la sécurité 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 automatisées. Il doit de plus être possible d'isoler différentes fonctions d'administration pour les répartir sur plusieurs administrateurs. 7.3.4. Standardisation des fonctions de sécurité Les domaines dans lesquels la standardisation est nécessaire pour offrir l'interopérabilité entre SMAP sont : · la représentation des règles de sécurité, · les fonctions de gestion des clefs (génération, distribution et audit des clefs chiffrées), · la structure des informations d'audit, · le protocole d'échange des informations relatives à la sécurité. 7.4. Système de transfert Le système de transfert dans un ES ou un RS se limite aux applications de communication des systèmes ouverts et aux protocoles de communication. Le TS devant être administré, les SMAP et SMIB doivent prendre en compte les fonctions du TS. Le but d'un TS est d'offrir une protection des données durant un transfert afin de supporter le partage des données. Un moyen d'aboutir à cela est d'autoriser les contextes de sécurité répartis sur plusieurs ES. 7.4.1. Contexte de sécurité distribuée Deux modes de transfert doivent être considérés : le mode interactif et le mode "poste restante". Les contextes de sécurité pour ces deux types de communications sont décrits ci-après. 7.4.1.1. Contexte distribué pour les communications interactives Un tel contexte est constitué de deux contextes appartenant à chaque ES et reliés de manière sécurisée par une association sécurisée. Cette association comprend les protocoles de sécurité et de communications, les mécanismes doctrinaux, et les fonctions de sécurité décrites dans le chapître précédent. Les informations de gestion de la sécurité sont contenues dans une SMIB appelée l'ASSR (Agreed Set of Security Rules) qui contiendra entre autre les algorithmes de chiffrement et les données. Chaque ES choisit localement un identifiant pour l'association (le SAID, Security Association IDentifier) qui lie l'association à l'ASSR correspondante. L'établissement de l'association passe par des échanges entre deux SAMP des machines concernées (les ES). Tout d'abord, il s'agit d'indiquer les capacités de sécurité des deux extrémités. Ce premier échange est non chiffré. Le deuxième échange concerne l'attribut des clefs nécessaires aux mécanismes de chiffrement. D'autres contrôles de sécurité (comme les contrôles d'accès) peuvent s'effectuer durant cet échange. Enfin le troisième échange emploie les clefs et les algorithmes de chiffrement pour s'assurer de l'accord des deux extrémités. Ce dernier échange est chiffré et est éventuellement utilisé pour l'échange d'autres informations de sécurité. D'autres informations s'avèrent nécessaires parfois dans un contexte distribué comme l'idenfication et les droits d'un utilisateur que l'on peut stocker dans un certificat X509. Il est possible de coupler de nombreuses techniques de protection. 7.4.1.2. Contextes distribués pour les communications asynchrones L'information à transmettre est prise en charge par une application qui la chiffre et lance son acheminement. En principe, sa protection est entièrement prise en charge par l'application. Si ce n'est pas le cas, les systèmes de relais devront s'en charger. Une implémentation de mail électronique répondant à ce besoin existe à ce jour : le SDNS Message Security Protocol le décrit. 7.4.1.3. Autres aspects des contextes distribués Le transfert d'informations multi-domaines utilise un contexte de sécurité distribué par domaine. Des fonctions supplémentaires sont ajoutées s'il est nécessaire d'assurer la gestion d'un grand nombre de clefs (si un système interagit avec beaucoup d'autres, cette administration des contextes de sécurité est complexe). 7.4.2. Support du TS Des fonctions doivent s'ajouter au SMAP pour remplir les activités suivantes : · requêtes des applications de communications des ES, · nouveaux objets à stocker dans la SMIB, · maintenance et accès aux données de sécurité d'un annuaire X500 depuis le protocole DAP, · utilisation de MSP pour les échanges de messages, · fonctions de création et suivi du SAID et de l'ASSR ainsi que les mécanismes de gestion des associations de sécurité, · fonctions et clefs de chiffrement, · protocole de gestion pour les échanges inter-SMAP. Les SMIB intègreront de plus les informations suivantes : certificats X509, droits d'accès des utilisateurs, clefs de messages et de trafic, données d'audit. Pour les SMIB des ES, on ajoutera : · la gestion des clefs, · les identifiants des algorithmes de signature, · les données des protocoles sécurisés, · les droits d'accès à l'ES pour les traitements distribués, · les informations d'initialisation des algorithmes de chiffrement, · les données des associations de sécurité, · les interdits (ex : certificats refusés), · et enfin les règles de purge de l'ensemble de ces informations. Les protocoles de sécurité retenus pour la DGSA sont présentés dans le tableau suivant. Pour chacun d'eux, on précise les services de sécurité supportés. La mise en oeuvre de contexte de sécurité distribuée se base essentiellement sur l'utilisation de mécanismes de chiffrement. Le support par les matériels de chiffrement de plusieurs mécanismes est souhaitable pour ne pas en multiplier le nombre et accroître par ce biais les coûts. 7.4.3. Inconvénients du TS L'emploi de réseaux publics empêche l'emploi des mécanismes de gestion sécurisé du trafic (le TFS, traffic flow security) car ils interviennent sur les protocoles de couche basse. Par conséquent, il existe là une vulnérabilité. Certaines limitations sont rencontrées si des mécanismes de chiffrement sont appliqués pour des communications de type diffusion (broadcast). La solution consiste à définir une clef par diffusion et pour les informations de multi-diffusion (multicasts) une clef par mécanisme de chiffrement. Cette clef est ensuite répliquée vers les destinataires à l'aide éventuellement du protocole MSP. 7.5. Doctrine de sécurité On entend par doctrine de sécurité les règles devant être appliquées par les personnes et l'environnement pour assurer la bonne mise en oeuvre de l'architecture de sécurité. Les points principaux pour la DGSA sont présentés ci-après. 7.5.1. Les services de sécurité Ceux-ci sont concentrés essentiellement dans les LSE. Les locaux protègent ainsi les ES, les RS et les LCS. Des fonctions de protection physiques sont ajoutées parfois. 7.5.2. Doctrine pour les services de sécurité L'authentification des utilisateurs (le plus souvent par badge) est le mécanisme le plus connu pour protéger les accès. Le même principe s'applique pour l'accès au ressources logicielles (par clefs chiffrées,...). Les contrôles d'accès complètent l'authentification des utilisateurs pour l'accès aux ressources. Un deuxième niveau de sécurité s'appuie sur des bureaux fermés ou locaux sécurisés. La confidentialité peut être assurée en évitant les émanations vidéo (à l'aide de filtres) et en contrôlant les sorties sur les imprimantes. Des broyeurs de papier sont nécessaires et une protection des supports magnétiques doit être prévue. L'état du matériel se doit d'être vérifié régulièrement et des mécanismes de contrôle (check) des composants doivent être prévus. Par des techniques de redondance et de stock matériel, la disponibilité des composants du système d'information peut être assurée. 8. Glossaire Architecture La notion d'architecture a plusieurs sens dépendant du contexte. (1) La structure des composants, leurs inter-relations, et les principes et règles régissant leur conception et leur évolution dans le temps (traduction de la définition IEEE STD 610.12) (2) Structure organisationnelle d'un système ou d'un composant (IEEE STD 610.12). Infrastructure L'infrastructure est utilisée a une signification différente suivant le contexte. Le plus fréquemment, l'infrastructure désigne ou a un rapport avec le matériel mais il est à noter qu'il inclu souvent le logiciel est les télécommunications. DoD Department of Defense DISA Defense Information Systems Agency OSE Open System Environment Politique de Sécurité (security policy) est associée à une mission et est basé sur les menaces portant sur les moyens par lequels la mission réussie (est accomplie). Un politique de sécurité (ou, d'une manière plus générale, un ensemble de politiques de sécurité) documentent les besoins de sécurité qui doivent être mis en place sur les ressources par une organisation. Ces besoins de sécurité définissent, pour le personnel opérant le systèmes d'information, les besoins de protection des informations de l'utilisateur et des ressources qu'il utilise. Une architecture de sécurité définie pour une mission spécifique les services de sécurité et les mécanismes spécifiques que doivent offrir tous les composants du sytème d'information. Système d'information (information system) est un ensemble de composants de traitement de l'information et de communication, ainsi que l'environnement dans lequel il opèrent. Cet environnement peut supporter une ou plusieurs missions. TCSEC Trusted Computer System Evaluation Criteria 9. Documents de référence Application Portability Profile (APP) Profile des systèmes ouverts du gouvernement américain, Profile OSE/1, Version 2.0, NIST SP-500-210, juin 1993. DoD Intelligence Information System (DODIIS) Modèle de référence pour les années 1990, Defense Intelligence Agency, Draft, 14 mai 1991. Introduction à POSIX (P1003.0/D15) IEEE, mai 1992.