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

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 :

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 :

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.

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.

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.

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.

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.

Processus de développement de la DGSA

Le développement de la DGSA est réalisé à l'aide d'un processus itératif :

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

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 :

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 besoins de sécurité de la DGSA

Ces besoins dérivent des quatre points précédents.

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.

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.

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.

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.

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

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

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

Concepts de sécurité

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

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.

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.

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.

Concepts de sécurité

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.

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.

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.

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.

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

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.

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.

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.

Description de l'architecture de sécurité des ES

Définitions :

Les différents points de cette architecture sont décrits ci-après.

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.

Contextes de sécurité

Les mécanismes de sécurité suivant sont nécessaires pour assurer le cloisonnement de ces contextes :

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

Fonctions de sécurité critique

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.

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.

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.

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.

Fonction de gestion de périphérique et gestionnaire de périphérique

On compte parmi ces fonctions de contrôle :

Fonctions liées à la sécurité

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

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.

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é

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 :

Les règles de sécurité font partie des SMIB. Chaque SMIB est accédée par un administrateur à l'aide d'une SMAP.

L'ISO 7498-2 et les concepts de sécurité de la DGSA

Outils d'administration de la sécurité

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.

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.

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.

Standardisation des fonctions de sécurité

Les domaines dans lesquels la standardisation est nécessaire pour offrir l'interopérabilité entre SMAP sont :

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.

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.

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.

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.

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

Support du TS

Des fonctions doivent s'ajouter au SMAP pour remplir les activités suivantes :

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 :

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.

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.

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.

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.


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