COMMISSION EUROPÉENNE

Transcription

1 COMMISSION EUROPÉENNE Bureau de sécurité Sécurité informatique * * Le texte en italique correspond à des commentaires destinés à disparaître du texte final.

2 0. RESUME 1. INTRODUCTION 2. CONCEPTS ARCHITECTURAUX DE LA SECURITE 2.1 Domaines de sécurité 2.2 Domaines intérieur et extérieur 2.3 Gestion de la sécurité 2.4 Accords sur les accès aux données 2.5 Politique de sécurité des systèmes locaux 3. MODALITES DE MISE EN OEUVRE TECHNIQUE ET REGLEMENTATION 3.1 Services et mécanismes de sécurité 3.2 Réseaux Confinement des domaines - Firewall Rôles et responsabilités Partitionnement du réseau Accès externes Protocoles autorisés sur le réseau inter-domaine Domaine local sécurisé Services offerts par la Commission sur les réseaux externes Règles concernant la connexion à INTERNET 3.3 Equipements (PC/serveurs) Sécurité sur le poste de travail Sécurité sur le serveur Intégration des services de sécurité 3.4 Systèmes d'information Intégration de la sécurité Systèmes de diffusion Systèmes de production 4. INFRASTRUCTURES 4.1 Carte à microprocesseur Type - 2 -

3 4.1.2 Contenu de la carte Organisation autour de la carte 4.2 Gestion électronique de documents 4.3 Courrier électronique sécurisé 4.4 SNET, LAN virtuel 5. ETAPES DE MISE EN PLACE 5.1 Etape 1: Mise en place de la carte à microprocesseur 5.2 Etape 2: Mise à disposition sur PC des outils de sécurité 5.3 Etape 3: Courrier électronique sécurisé 5.4 Etape 4: Single-logon sans modification des serveurs 5.5 Etape 5: Single-logon sur serveurs spécialisés 5.6 Etape 6: Généralisation de l'étape 5 à tous les serveurs 5.7 Etape 7: Généralisation de la carte à microprocesseur aux serveurs 5.8 Etape 8: Serveurs d'authentification et RPC sécurisés 6. ANNEXES 1. STANDARDS 2. CONVENTION "CONFIGURATION SURE" 3. CONVENTION "DOMAINE LOCAL SECURISE" 4. ECHELLE D'EVALUATION DE L'IMPACT DES RISQUES 5. GLOSSAIRE ET PRODUITS - 3 -

4 0. RESUME Le présent document définit les modalités techniques de mise en oeuvre de la réglementation C(95) 1510 relatif à la protection des systèmes d'information. Ce document introduit les concepts qui doivent être approuvés par l'ensemble de l'organisation informatique, de façon que chaque équipe concernée puisse mettre en oeuvre les éléments de l'architecture intégrant la sécurité en conformité avec la ligne générale. Ce document est évolutif, en particulier en ce qui concerne les mécanismes qui doivent suivre l'évolution de l'informatique. Le chapitre 2 introduit les concepts de base: le partitionnement en domaines de sécurité généraux et locaux, internes et externes, La définition des niveaux de sécurité applicables aux domaines, La gestion de la sécurité dans un contexte décentralisé et en mode clientserveur, et la répartition des responsabilités concernant l'établissement des politiques de sécurité aux niveaux général et local, Le cadre de l'établissement des règles au niveau local en ce qui concerne l'accès aux données et la politique de sécurité locale. Le chapitre 3 décrit les services de sécurité: authentification, confidentialité, intégrité, non-répudiation, etc, qui seront mis en oeuvre dans les systèmes d'information, ainsi que leur intégration dans l'architecture: réseau, postes de travail, serveurs, systèmes d'information. Le chapitre 4 décrit les infrastructures sur lesquelles s'appuieront les systèmes d'information lors de la mise en oeuvre de la sécurité: carte à microprocesseur, courrier électronique sécurisé, réseau, etc. Le chapitre 5 décrit les étapes possibles de mise en oeuvre

5 1. INTRODUCTION La sécurité des systèmes d'information repose sur un certain nombre de moyens organisationnels ou techniques. La politique générale de sécurité fait l'objet d'une décision de la Commission C(95) 1510 du 23 novembre 1995 relative à la protection des systèmes d'information. Celle-ci définit les responsabilités et les règles générales. Chaque Direction générale définit sa propre politique de sécurité et les procédures correspondantes. Afin de la mettre en oeuvre, elles disposent de moyens qui sont: la formation et la sensibilisation, les méthodes d'analyses de risque, les méthodes d'intégration de la sécurité dans la construction des systèmes d'information, les méthodes d'élaboration des plans de secours, des outils de contrôle et d'audit, des dispositifs techniques ou procéduraux, logiques ou physiques destinés à mettre en oeuvre la sécurité des systèmes d'information repris dans le Guideline. La structure de ces différents éléments est reprise à la figure 1. TRAITE STATUT REGLEMENTS POLITIQUE DE SECURITE DES SYSTEMES D'INFORMATION ORGANISATION / ARCHITECTURE PRODUITS REGLES GUIDELINE ANALYSES DE RISQUE PROCEDURES/ CONSIGNES SYSTEME D'INFORMATION SECURITE DANS LES DEVELOPPEMENTS SENSIBILISATION FORMATION CONTROLES AUDITS PLANS DE SECOURS Figure 1: Structure des moyens de sécurité. Le présent document concerne l'architecture de sécurité. Il complète, sur le plan technique, la Décision concernant la politique de sécurité et en constitue le volet - 5 -

6 technique. Il est aligné sur les principes de l'architecture de l'informatique générale. Les techniques informatiques doivent s'adapter au contexte administratif et organisationnel. Celui-ci est caractérisé par quatre concepts: décentralisation, transparence, adaptation, évolution. L'architecture décrite ci-après définit les services et mécanismes de sécurité nécessaires et suffisants pour assurer un bon niveau de sécurité à la Commission. Toutefois, si ces services doivent être disponibles, il ne sont mis en oeuvre qu'en fonction du niveau de sensibilité des systèmes d'information auxquels ils appartiennent (cf. annexe 4). L'architecture ne présuppose pas l'utilisation de produits particuliers mais propose des solutions génériques standardisées et représentatives de l'offre du marché. Une étude de faisabilité doit être menée pour valider cette architecture et vérifier l'existence de produits. Des spécifications techniques doivent être rédigées pour sélectionner les produits opérationnels. La mise en place totale de l'architecture se fera par étapes qui sont précisées au point 6. L'architecture est conforme aux standards (cf. annexe 1), notamment ISO part 2. Pour l utilisation pragmatique des standards ayant fait leurs preuves sur le marché, l architecture fait référence en priorité aux standards de droit ( de jure ) sinon aux standards de fait ( de facto ) dont la définition est de préférence dans le domaine public. Les produits utilisés sont certifiés ou au moins conformes, à ITSEC C2-E2 (TCSEC C2). La structure du document, pour la partie poste de travail et serveurs, suit la structure de ITSEC en termes de fonctions de sécurité

7 2. CONCEPTS ARCHITECTURAUX DE LA SECURITE 2.1 Domaines de sécurité. Le Domaine de la Commission est l'ensemble des ressources informatiques lui appartenant. Dans un but de gestion et de contrôle, le Domaine de la Commission est partitionné en Domaines locaux de sécurité. Un Domaine local de sécurité est un ensemble de ressources informatiques et de personnes ayant un niveau de sécurité interne homogène, appliquant la même politique de sécurité locale et représentant une entité autonome sur le plan de la sécurité. Un domaine local de sécurité peut correspondre à une Direction générale ou à un morceau de Direction générale, et par extension: une Délégation, un Bureau de presse ou même un prestataire sous certaines conditions. Les domaines sont, soit disjoints, soit imbriqués. Le niveau de sécurité ainsi que la Politique de sécurité d'un domaine local, sont définis par le Directeur général ou son représentant sur recommandation du fonctionnaire de sécurité. La mise en oeuvre de la sécurité est à la charge de l'irm et des propriétaires de service, chacun en ce qui le concerne, sous le contrôle du fonctionnaire de sécurité. Cependant, la définition du niveau de sécurité est conditionné à un ensemble de règles minima contraignantes définies par le Bureau de sécurité. Ces règles ont pout but d'éviter que les Directions générales se perturbent mutuellement. On se reportera au chapitre 3. Modalités de mise en oeuvre et règlementation. La Politique de sécurité locale est un ensemble de mesures systématiques assurant la sécurité: dispositifs, règles, procédures, etc. Elle est définie au paragraphe 2.5. Il y a quatre niveaux de sécurité pour les domaines de sécurité: N1: Public N2: Privé général correspondant au réseau interdomaine N3: Privé local de sensibilité "normale" N4: Privé local de sensibilité "classifiée" A ces quatre niveaux on ajoute le domaine public externe qui correspond à tout ce qui n'appartient pas à la Commission, soit: N0: public externe. Les éléments d'un système d'information doivent se trouver dans des domaines de sécurité de niveau correspondant à leur sensibilité. Lorsque des informations transitent dans un domaine de niveau inférieur, des moyens doivent être mis en oeuvre pour leur assurer le niveau de sécurité ad hoc, par exemple le chiffrement

8 2.2 Domaines intérieur et extérieur. Par analogie avec les bâtiments, il est intéressant de séparer les domaines physiques de façon à assouplir et simplifier la gestion de la sécurité. Dans le domaine physique intérieur, on peut gérer des sous domaines de niveau homogène, c'est-à-dire, de même sensibilité, comme un tout. Dans le domaine extérieur chaque utilisateur isolé doit être considéré comme un sous-domaine car il se trouve, par définition, dans un environnement potentiellement hostile. Si les conditions le permettent, on peut créer des sous domaines locaux extérieurs, par exemple, une délégation ou un bureau, ou un contractant. La figure 2 décrit la structure des domaines. Domaine externe physique Domaine interne physique CT DLI N3 DLE DLI N4 N3 N4 DLE N3 N0 N1 F W N2 N3 N4 DLI Légende: N0: Domaine public externe (Réseaux publics, serveurs n'appartenant pas à la Commission, etc.). N1: Domaine public interne (Bases de diffusion, Web EUROPA, etc.). N2: Domaine privé général correspondant au réseau interdomaine (IDNet). N3: Domaine local de sensibilité normale (non classifié). N4: Domaine local de sensibilité "classifiée". CT: Centre de télécommunication, interface unique entre domaines internes et externes. FW: Firewall DLE: Domaine local exterieur DLI: Domaine local intérieur Figure 2: Structure des domaines. Le réseau inter-domaine est considéré comme un medium de communication. Le contrôle sur l'accès aux données et aux autres ressources et les mesures pour protéger l'intégrité et la disponibilité des systèmes, sont mis en oeuvre sur les systèmes terminaux, soit à l'interface avec le réseau, soit dans les applications ou le système d'exploitation. Il existe deux façons de concevoir le concept d'extérieur et d'intérieur: Physiquement: les éléments des systèmes d'information (postes de travail, serveurs, noeuds de réseau, etc.) sont physiquement à l'intérieur ou à l'extérieur du domaine physique de la Commission s'ils sont, d'une part, reliés au réseau interdomaine (IDNet), et, d'autre part, placés physiquement dans un bâtiment dont l'accès est limité et sous le contrôle de la Commission. Logiquement: l'utilisateur appartient au domaine intérieur s'il a un lien juridique avec l'institution: statut, contrat, etc. Il doit pouvoir accéder, en tout sécurité, au domaine physique intérieur quelle que soit sa localisation géographique. Cette seconde acception conduit à gérer l'identification, l'authentification et le contrôle d'accès au niveau des couches hautes du modèle ISO. Il faut établir un canal sûr et indépendant du réseau, entre l'utilisateur et le système d'information

9 L'orientation prise par les réseaux ainsi que la politique immobilière de la Commission, ne permet plus d'envisager une séparation physique systématique des domaines locaux. La séparation doit se faire sur le plan logique: authentification individuelle des utilisateurs, contrôle d'accès centralisé au niveau du domaine local avec coopération entre domaines locaux, sécurisation des interactions client-serveur. Pour la sécurité client-serveur, chaque domaine est équipé d'un serveur d'authentification (SA) (voir figure 3). Celui-ci a pour fonction d'authentifier chaque utilisateur du domaine et de lui donner un jeton pour le serveur de droit d'accès. Le jeton est un message crypté qui permet d'assurer l'authentification réciproque des entités homologues, c'est-à-dire le client et le serveur, d'une part, et, d'autre part, l'intégrité et la confidentialité de chaque échange (RPC) entre eux. Chaque domaine est équipé d'un serveur de droits d'accès (SDA) dont la fonction est de vérifier les droits d'accès de chaque client à chaque serveur du domaine. Le serveur d'authentification donne un jeton pour l'accès au serveur de droit d'accès, le serveur de droits d'accès pour chaque serveur (voir figure 3). SA SDA S SA SDA S IDNet PdT PdT FW SA SDA Réseau ext. Figure 3: Architecture de sécurité des domaines L'interaction entre domaines est assurée de la façon suivante: Le serveur d'authentification et de droits d'accès du domaine émetteur donne un jeton au client pour accéder au serveur d'authentification du domaine cible. En ce qui concerne l'accès depuis l'extérieur, l'utilisateur se fait authentifier par le serveur d'authentification et reçoit un jeton du serveur de droit d'accès du Centre de télécommunication, destiné au serveur d'authentification du domaine cible souhaité. Le processus est montré à la figure

10 C T PdT éloigné (1) SA (CT) SDA (CT) (3) SA (CT) (2) IDNet SNet (4) SDA (CT) Figure 4: Chaîne d'authentification entre domaines locaux. Pendant la phase transitoire de mise en service systématique des serveurs d'authentification et de droits d'accès, le système peut fonctionner de façon dégradée en utilisant des procédures de login simple, éventuellement renforcées par des authentifications fortes: Mot de passe simple, challenge-response par logiciel, carte à microprocesseur, etc. (cf. Etapes de mise en oeuvre au chapitre 5). La protection des données est basée sur les services de sécurité suivants placés dans les couches hautes: Authentification des entités homologues, Contrôle d'accès, Confidentialité, Intégrité des données, Authentification de l'origine, Non répudiation. Les mécanismes qui mettent en oeuvre ces services sont cités au point 3.1. A ces services normaux sont adjoints des services complémentaires ponctuels mis en place sur les couches basses chaque fois que c'est plus efficace: Authentification des entités homologues: authentification de l'adresse réseau X25 ou IP, par dispositif ad hoc dans le second cas, Contrôle d'accès: contrôle d'addresse réseau X25 ou IP avec filtrage des paquets, Authentification de l'origine: authentification de l'adresse par l'utilisateur, Confidentialité: chiffrement de ligne entre deux noeuds

11 2.3 Gestion de la sécurité. A l'intérieur du cadre défini par la Décision C(95) 1510 du 23 novembre 1995 relative à la protection des systèmes d'information, ainsi que par les règlements généraux de la Commission, la sécurité doit être gérée au niveau le plus adéquat. Le schéma général des composants de la sécurité est décrit à la figure 5. Autorité sur le réseau Politique de sécurité réseau Réseau Autorité sur le réseau Règles de connexion Systèmes local Données Politique de sécurité système Propriétaire de données Accord sur l'accès aux données Système local Politique de sécurité système Responsable du système local Responsable du système local distant NB: Un système local peut être interne ou externe à la Commission. Figure 5. Schéma des composants de la sécurité. Les différents composants de la sécurité sont: Politique de sécurité du réseau: Définit les principes à adopter et les méthodes à utiliser pour la sécurité du réseau. Règles de connexion: Définissent les conditions de sécurité techniques qui doivent être remplies avant que chaque système local puisse être connecté au réseau. Accords d'accès aux données: Concernent le partage des données et sont négociés individuellement entre les propriétaires de données et les représentants des utilisateurs qui souhaitent y accéder. Peuvent y être incluses les conditions techniques telles que le chiffrement, l'authentification de l'origine, la non-répudiation, etc. Politiques de sécurité des systèmes locaux: Définissent la politique de sécurité locale spécifique. Elles dépendent des risques propres. Elles sont réalisées localement, éventuellement selon un modèle général, décrit ci-après, adapté suite à des analyses de risque spécifiques mais conforme à un niveau minimum découlant de la Décision

12 relative à la protection des systèmes d'information et notamment des articles 2, 4 et 5, ainsi que des règlements généraux de la Commission. Les rôles et les responsabilités doivent suivre le principe de subsidiarité. La responsabilité pour la sécurité repose sur les responsables des systèmes locaux sauf si une responsabilité centrale est préférable pour le bien de la communauté des utilisateurs. Par conséquent, les principes s'appliquant à l'établissement des politiques sont les suivants: 1. Si une Direction générale A a défini un niveau de risque R A, d'origine interne ou externe, a pris des mesures M A pour obtenir un niveau de sécurité S A lié aux mesures prises, S A ne doit pas être dégradé par une Direction générale B qui a un niveau de sécurité S B inférieur à S A ; 2. La définition de S A, respectivement S B, est de la responsabilité de la Direction générale A, respectivement B, dans les limites des réglements de la Commission; S A, et S B, est le résultat d'une analyse de risque; 3. Le rôle du Bureau de sécurité, avec l'aide de la Direction informatique, est de: veiller à ce que soit déterminé le niveau S A de sécurité (analyse de risque et plan de sécurité) veiller à ce que soient fournis les moyens techniques ou organisationnels, à la Direction générale A, pour qu'elle puisse réaliser les mesures M A afin d'obtenir le niveau de sécurité S A, Veiller à ce que S A soit non inférieur à la règlementation, notamment celle concernant les documents classifiés (décision de la Commission du 30 novembre 1994 C(94) 3282), empêcher que les mesures prises par la Direction générale B ne perturbe la sécurité de la Direction générale A; La répartition des responsabilités est reprise dans le tableau 3. Politique de sécurité Politique de sécurité du réseau Responsabilité d'établissement Bureau de sécurité Responsabilité de mise en oeuvre Direction informatique Règles de connexion Bureau de sécurité Direction informatique et IRM Accord d'accès aux données LISO (DG) Propriétaire de données (DG) Politique de sécurité du système local LISO (DG) IRM (DG) Tableau 3: Responsabilité dans l'établissement des politiques

13 2.4 Accords sur les accès aux données. Il s'agit d'une forme de contrat entre, d'une part, le propriétaire des données sur un système et, d'autre part, les utilisateurs se trouvant n'importe où et qui souhaitent utiliser les données. La rédaction de cet accord est à la charge des propriétaires d'information. Il doit définir formellement: les droits d'accès aux données par un utilisateur distant, la responsabilité du propriétaire des données assurant que celles-ci seront disponibles conformément aux souhaits de l'utilisateur, la responsabilité de l'utilisateur pour la sauvegarde des données auxquelles il a eu accès et qu'il a transférées dans son domaine local ou déplacées dans le domaine d'origine, l'engagement de l'utilisateur à respecter les règles de sécurité mises en place par le propriétaire des données, la répartition des responsabilités entre les deux parties, les droits d'accès octroyés par le propriétaire à l'utilisateur, les conditions spéciales attachées aux données comme le respect de législation ou de réglements internes, notamment la protection des données personnelles, une définition des limites du transfert, par l'expéditeur au récepteur, des droits de propriété ou de détention des données transmises à travers le réseau, une définition de la méthode employée pour garantir l'authentification de l'origine, la réception, la non-répudiation, etc. un engagement de l'utilisateur à accepter les audits ou les enquêtes sur des incidents de sécurité au nom du propriétaire. En vertu du principe de subsidiarité, la mise en vigueur de cette politique est de la responsabilité du propriétaire des données et non d'une quelconque autorité centrale, notamment celle assurant la politique de sécurité du réseau. La politique est contrôlée par les différents LISO (celui du propriétaire et celui de l'utilisateur) et supervisée par le Bureau de sécurité

14 2.5 Politique de sécurité des systèmes locaux. Conformément à la décision C(95) 1510, les Directions générales ont la responsabilité de la rédaction de leur politique de sécurité locale. A titre indicatif, voici les points qu'on doit trouver dans une politique de sécurité locale: Mise en place de l'organisation: Responsable local de la sécurité des systèmes d'information, Comité local de sécurité, etc. Mise en place des tâches: classement des systèmes, révision de la politique et des mesures, etc. Classement des systèmes d'information en non sensibles, sensibles, critiques ou stratégiques. Spécification des rôles et des responsabilités en matière de sécurité et notamment en ce qui concerne les personnes qui sont responsables des données et du système d'information: proprétaire et manager du service et les utilisateurs privilégiés. Spécification des utilisateurs ou groupe d'utilisateurs qui peuvent utiliser les ressources et attribution des droits. Définition des règles d'accès aux ressources et des responsabilités (dérivées de la réglementation article 5). Spécification des contrôles de sécurité. Fourniture d'un niveau de base pour le contrôle et l'audit. Sécurité physique (spécifications salles). Sécurité minimum des postes de travail (ex: mot de passe, interface PC- MCIA, etc.). Imputabilité: informations à enregistrer, politique d'archivage des journaux, etc. Plan de sauvegarde. plan de secours. Stratégie anti-virus, anti-vol, etc. Règles spécifiques à respecter, Choix et mise en oeuvre des mesures de sécurité: produits, logiciels, dispositifs, procédures, consignes, etc.) etc. et tous les éléments qui n'ont pas d'interaction avec la sécurité du réseau

15 3. MODALITES DE MISE EN OEUVRE TECHNIQUE ET REGLEMENTATION 3.1 Services et mécanismes de sécurité. Pour beaucoup de gens, une sécurité renforcée consiste en un renforcement de la gestion des mots de passe, ou un meilleur contrôle d'accès. Cependant, dans un environnement largement distribué, avec des milliers d'utilisateurs, chacun accèdant à de nombreux systèmes, la gestion des mots de passe peut devenir un problème en lui-même. Des mots de passe qui sont re-transmis régulièrement sont également extrèmement vulnérables lorsque le réseau est largement distribué à travers l'organisation, voire des pays. De plus, les mots de passe ne concernent que l'accès initial au système, ils n'assure pas la sécurité tout au long de la session, ni l'imputabilité des actions aux utilisateurs. La sécurité ne concerne pas seulement la confidentialité. Elle demande de nouveaux services tels que l'authenticité de l'origine, l'intégrité et la nonrépudiation des documents. ISO définit les services et mécanismes de sécurité, ainsi que leur place dans les couches. Compte tenu des besoins de la Commission, le Bureau de sécurité propose un choix de mise en oeuvre. Pour la Commission, le Bureau de sécurité propose les services de la façon suivante: un "" indique que le service n'est pas retenu, un "E" indique que le service est retenu d'une façon exceptionnelle, un "R" indique que le service est retenu systématiquement. La place des services de sécurité est la suivante. Couches ISO Services de sécurité Authentification des E R entités homologues Contrôle d'accès E R Confidentialité E E R Secret du flux Intégrité des données R Authentification de E R l'origine Non répudiation R Tableau 1: place des services de sécurité dans les couches ISO. Une case blanche veut dire qu'il n'y pas de service pour cette couche. Lorsque la case est occupée, cela veut dire que ISO propose un service pour cette couche. La majorité des services sont mis en oeuvre sur la couche 7. Ceci est conforme au principe de transparence et d'indépendance vis-à-vis du réseau

16 L'identification et l'authentification porte, principalement, sur l'utilisateur. La mise en oeuvre des services par les mécanismes est réalisée de la la façon montrée par le tableau 2. Un "R" indique que le mécanisme est mis en oeuvre, un "" indique que le mécanisme n'est pas mis en oeuvre. Les services correspondant aux mécanismes sont placés dans les couches selon le modèle présenté au tableau 1. Mécanismes Chiffrement Signature Contrôl d'accès Intégrité Echange d'authentif. Bourrage Contrôle routage R R R R Services Authentification des entités homologues Contrôle d'accès R R Confidentialité R Secret du flux Trusted third party Intégrité des R R R données Authentification de R R R l'origine Non répudiation R R Tableau 2: Mise en oeuvre des services par les mécanismes. Les mécanismes possibles sont les suivants: Chiffrement: Algorithmes symétriques par logiciel ou matériel: DES, IDEA,... avec clés sur carte à microprocesseur, board, disque dur ou disquette. Algorithme asymétrique par logiciel ou matériel, ou sur carte à microprocesseur: RSA; Autres algorithmes: PGP, spéciaux militaires, etc. selon les besoins, notamment pour les domaines "classifiés". Le chiffrement se fait normalement sur la couche 7 (R) (voir tableau 1). Exceptionnellement, selon les besoins, on peut recourir à un chiffrement de ligne entre deux points, sur la couche 1 ou de bout en bout sur la couche 4 (E) (voir tableau 1). Signature: Combinaison de l algorithme RSA, par logiciel ou matériel, ou inclus sur carte à microprocesseur, combiné avec algorithme de compression, sur PC ou serveur (MD5 par exemple). Echange des clés par entête (PGP, PEM, X509, X400,...). Nécessité d une autorité de certification: voir "Tiers de confiance" ci-dessous. Contrôle d'accès: Serveur de droit d'accès combiné avec le serveur d'authentification, contrôle d'accès au poste de travail (login), contrôle d'accès au serveur (login). Pour les services de contrôle d'accès sur la couche 7 (R)

17 (voir tableau 1). Firewall pour le service de contrôle d'accès sur la couche 3 (E) (voir tableau 1). Intégrité: combinée avec la signature ou mécanisme ad hoc (MD5 par exemple). Echange d'authentifications: procédure de "challenge-response" utilisant les outils cryptographiques sur PC (logiciels ou matériels) ou sur carte à microprocesseur, pour l'authentification non rejouable. Mot de passe statique avec stockage possible sur carte à microprocesseur, utilisation directe de la carte à microprocesseur par les serveurs. Tiers de confiance (Trusted third party) qui garantit le lien clé publique et utilisateur. Les mécanismes seront décrits plus en détail dans la suite du document. La cryptographie et la carte à microprocesseur constituent les éléments essentiels comme montré dans le tableau 2. Remarque importante: l'utilisation de la cryptographie et l'exportation de certains produits sont réglementés dans certains pays. En conséquence, l'utilisation de la cryptographie, notamment pour le chiffrement, doit faire l'objet d'une autorisation formelle de la part des autorités compétentes de la Commission. Les mécanismes doivent être disponibles en termes de produits et d'organisation. Le choix des produits et des méthodes d utilisation est effectué dans le cadre du product management. Le choix de mise en oeuvre revient aux IRM et aux propriétaires des systèmes. Les mécanismes peuvent être: soit non installés, soit mis en place mais d'utilisation optionnelle, l'option par défaut étant: cryptographie non activée, l utilisateur peut les activer, soit mis en place mais les options par défaut sont: cryptographie activée,, c'est à l'utilisateur de les désactiver, soit d utilisation obligatoire, l utilisateur ne peut pas les désactiver

18 3.2 Réseau Confinement des domaines - Firewall Le réseau n'offre pas, en général, les moyens pour sécuriser les données des systèmes terminaux. Cependant le réseau doit garantir la disponibilité, l'intégrité et la confidentialité de ses éléments de gestion. Le réseau assure la connexion entre entités se trouvant dans un même domaine local ou dans des domaines différents. Les services de sécurité définis ci-dessus au point 3.1 permettent d'assurer un canal sûr de niveau de sécurité jugé adequat par les responsables des domaines. Le contrôle d'accès à un domaine sécurisé depuis un autre domaine sécurisé est construit sur l'identification de l'adresse. Si les domaines sont internes, l'authentification de l'adresse est optionnelle. Si un des domaines est externe, l'authentification est obligatoire (par exemple NUA-check X25 ou mécanisme ad hoc). En revanche, le contrôle d accès à un domaine sécurisé depuis un domaine non sécurisé est basé sur l'identification et l'authentification individuelle de l'utilisateur pour tous les services qui l'exigent: Telnet, client-serveur, etc. Cette authentification doit être réalisée, si possible, au point d'entrée du domaine sécurisé. La structure des domaines physiques est montrée dans la figure 6. Domaine physique ext. F W Domaine physique int. Figure 6: Structure des domaines physiques FW est le "Firewall". Ses fonctions sont: Filtrage optionnel des paquets entrants, notamment la gestion de listes noires ou l'authentification d'un serveur. Cette fonction est indispensable à court terme tant que la fonction d'authentification de la couche 7 n'est pas sûre. Quand elle le sera, ce filtrage deviendra optionnel. Elle pourra être maintenue quand il n'y a pas d'authentification sur la couche 7 sur la passerelle, par exemple, connexion entre MTA externes et la passerelle correspondante. Aiguillage du trafic vers les passerelles spécialisées (proxy) ou les serveurs (courrier électronique, transfert de fichiers, serveur d'authentification, serveurs publics tel que le Web Europa, etc.). Authentification de la personne appelante. Le niveau de l'authentification dépend du service appelé, il va de très simple, voire nul, pour un serveur public tel que le Web Europa, jusqu à une authentification renforcée, par exemple, par carte à microprocesseur pour un accès vers un serveur interne en mode interactif ou client-serveur (voir ci-dessous les différents types d'authentification)

19 Gestion du trafic par les passerelles spécialisées, selon les services demandés: courrier, transfert de fichiers, interactif: Telnet ou client-serveur, etc. Gestion des utilisateurs externes physiquement en terme de droit d'accès au domaine physique intérieur, Journalisation, Statistiques. Le Firewall gére les utilisateurs appartenant à l'institution de la même façon, qu'ils se trouvent à l'intérieur ou à l'extérieur du domaine physique. Cela permet de dissocier les aspects logiques et physiques. En effet, une fois l'utilisateur authentifié au niveau souhaité, il entre dans le domaine intérieur et s'y trouve avec les mêmes protections que s'il se trouvait physiquement dans le domaine intérieur. Chaque sous domaine peut établir le niveau de sécurité qu'il souhaite. Ce mécanisme est parfaitement analogue à la protection des bâtiments: chaque personne qui se présente à la porte est authentifiée (carte de service ou papiers d'identité), ses droits sont vérifiés (fonctionnaire: accès libre, externe: vérification auprès de la personne visitée) et peut circuler librement dans les couloirs. Si une zone doit être plus protégée (exemple: salle d'ordinateur ou DG 17 L), on lui adjoint un second contrôle plus poussé. Les mécanismes d'authentification qu'on doit mettre en place sur le Firewall sont: Absence de mécanisme: réservé à l'accès à des serveurs publics, bien protégés du point de vue intégrité et disponibilité mais ne contenant pas d'informations confidentielles. Exemple le Web Europa ou certains services du Centre de calcul. Ces serveurs ne doivent pas permettre une intrusion à travers eux et par conséquent devraient être isolés du réseau intérieur (cf ). L'absence de mécanisme est utilisable également pour la connexion n'exigeant pas l'authentification de l'utilisateur, par exemple, la connexion entre MTA externes et la passerelle correspondante. Mot de passe simple (statique rejouable): ce mécanisme devrait disparaître ou être réservé au cas précédent, par exemple, pour permettre à un utilisateur d'être protégé contre des utilisations frauduleuses de son contrat de connexion. Ce mécanisme pourrait permettre l'accès à des domaines locaux non sensibles dans la mesure où l'accès aux domaines sensibles est systématiquement protégé. Dans le cas contraire, il est à exclure. Challenge-response par logiciel (mot de passe dynamique non rejouable): C'est une alternative plus sûre au mot de passe. Peut être utilisé pour l'accès aux domaines non sensibles intérieurs. Calculettes (Secure-id, Digipass, etc.): C'est une alternative à la carte à microprocesseur pour les accès aux domaines sensibles non classifiés. Ce mécanisme est à réserver aux utilisateurs externes à l'institution. Sa fonction est limitée au contrôle d'accès. Carte à microprocesseur: si les expériences en cours sont concluantes, ce mécanisme devrait être étendu à tout le personnel intérieur au sens logique, c'est-à-dire statutaire ou contractuel, y compris les utilisateurs extérieurs

20 ayant un lien juridique avec l'institution, par exemple firmes de développement extra-muros ou assurant la maintenance à distance. Il permet d'accéder à tout domaine local intérieur et également aux domaines dits "classifiés", pour lesquels il est le seul mécanisme admis. Il n'est pas limité au contrôle d'accès mais offre des mécanismes complémentaires: chiffrement, signature électronique et stockage sécurisé de mots de passe notamment