Sécurité informatique
*
* Le texte en italique correspond à des commentaires destinés à disparaître du texte final.
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
3.2.1 Confinement des domaines - Firewall 3.2.2 Rôles et responsabilités
3.2.3 Partitionnement du réseau 3.2.4 Accès externes
3.2.5 Protocoles autorisés sur le réseau inter-domaine 3.2.6 Domaine local sécurisé
3.2.7 Services offerts par la Commission sur les réseaux externes 3.2.8 Règles concernant la connexion à INTERNET
3.3 Equipements (PC/serveurs)
3.3.1 Sécurité sur le poste de travail 3.3.2 Sécurité sur le serveur
3.3.3 Intégration des services de sécurité 3.4 Systèmes d'information
3.4.1 Intégration de la sécurité 3.4.2 Systèmes de diffusion 3.4.3 Systèmes de production 4. INFRASTRUCTURES
4.1 Carte à microprocesseur 4.1.1 Type
4.1.2 Contenu de la carte
4.1.3 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
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 client- serveur, 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.
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
ARCHITECTURE
REGLES GUIDELINE
ORGANISATION /
ANALYSES DE RISQUE
SECURITE DANS LES
SYSTEME
PROCEDURES/
CONTROLES AUDITS
PLANS DE SECOURS
SENSIBILISATION FORMATION
PRODUITS
D'INFORMATION
DEVELOPPEMENTS
CONSIGNES
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
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 7498-2 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é.
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.
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.
CT
N3
N3 N4
N3
N3 N4
N4
N1 N0
Domaine interne physique Domaine externe physique
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.
N2 F W
FW: Firewall
DLE
DLE
DLI
DLI
DLI
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
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).
PdT SA
SDA S
PdT SA
SDA S
IDNet
FW SA
Réseau ext.
SDA
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 4.
PdT éloigné
C T
SA (CT) SDA (CT) (1)
(2) IDNet
SNet
SA (CT) SDA (CT) (3)
(4)
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.
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.
Règles de connexion Autorité sur le réseau Politique de sécurité réseau
Réseau
Autorité sur le réseau
Accord sur l'accès aux données Propriétaire de données
Politique de sécurité système Politique de sécurité
système
Systèmes local Système local
Données
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
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 RA, d'origine interne ou externe, a pris des mesures MA pour obtenir un niveau de sécurité SA lié aux mesures prises, SA ne doit pas être dégradé par une Direction générale B qui a un niveau de sécurité SB inférieur à SA;
2. La définition de SA, respectivement SB, est de la responsabilité de la Direction générale A, respectivement B, dans les limites des réglements de la Commission; SA, et SB, 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 SA 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 MA afin d'obtenir le niveau de sécurité SA, - Veiller à ce que SA 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é Responsabilité d'établissement
Responsabilité de mise en oeuvre Politique de sécurité du
réseau
Bureau de sécurité 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
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é.
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.
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 non- ré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é ¯
1 2 3 4 5 6 7
Authentification des
entités homologues E · R
Contrôle d'accès E · R
Confidentialité E · · E R
Secret du flux · · ·
Intégrité des données · · R
Authentification de l'origine
E · R
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.
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 ®®®® Services ¯¯¯¯
Chif- fre- ment
Signa-
ture Con- trôl d'ac-
cès
Inté-
grité Echan- ge d'au- thentif.
Bour-
rage Con- trôle routa-
ge
Trusted third party
Authentification des entités homologues
R R R R
Contrôle d'accès R R
Confidentialité R ·
Secret du flux · · ·
Intégrité des données
R R R
Authentification de
l'origine R R · R
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)
(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.
3.2 Réseau.
3.2.1 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.
F W
Domaine physique ext. 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).
· 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. § 3.3.1).
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
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.
3.2.2 Rôles et responsabilités.
La Direction informatique est responsable, sous le contrôle du Bureau de sécurité pour ce qui concerne la sécurité,
· de la gestion du réseau interdomaines IDNet, et de ses composants:
dispositifs de routage à l'intérieur et en bordure du backbone ainsi que des dispositifs qui assurent le partitionnement du réseau.
· de la connexion du réseau interne interdomaines et des réseaux externes.
Les Directions générales sont responsables de la gestion des réseaux locaux.1 La Direction informatique assure la disponibilité du réseau ainsi que l'intégrité des éléments de gestion (routeurs, etc.). Elle n'assure ni la confidentialité, ni l'intégrité des données qui sont véhiculées sauf exceptions dûment mises en place (par exemple chiffrement d'une liaison spécialisée).
Les Directions générales assurent, grâce aux outils et méthodes à leur disposition, la disponibilité, l'intégrité et la confidentialité de leurs réseaux locaux ainsi que des données qui y circulent.
Le non respect des règles peuvent conduire à la déconnexion physique ou la mise hors service de l'élément en cause.
Le Bureau de sécurité contrôle le respect des règles et est habilité à faire placer par la Direction informatique sur liste noire (verrouillage des accès, etc.), tout correspondant externe en infraction.
1 Le réseau local d'une Direction générale peut s'étaler sur plusieurs bâtiments. Les connexions inter- bâtiments sont intégrés dans IDNet.
3.2.3 Partitionnement du réseau.
Le contrôle d'accès s'appuie essentiellement sur des mécanismes placés dans les couches hautes (cf. § 3.1). Cependant, pour des raisons d'optimisation de la sécurité, certains contrôles d'accès se font sur la couche 3. Tant que le contrôle d'accès sur les couches hautes ne sera pas sûr, c'est ce second type qui est opérationnel sur les frontières sensibles des domaines. Le réseau est partitionné et il existe cinq types de frontières. La figure 7 décrit le partitionnement du réseau.
PUBLIC
CT
CA
CA
CLASSIFIE
CLASSIFIE
PUBLIC = {services informatiques "publics" + contrôle d'accès au domaine CCE}
NB: Pour les domaines "classifiés", la réglementation de type "documents classifiés"
s'applique.
CT = Centre de télécommunication assurant l'interface avec le monde extérieur CA = Système de contrôle d'accès
= Zone isolée physiquement C C
1 4
2 3
5
DOMAINE INTERNE GENERAL / LOCAL NON SENSIBLE
DOMAINE
DOMAINE LOCAL
DOMAINE LOCAL
CC = Centre de calcul
Figure 7: Partitionnement du réseau.
Les frontières sont les suivantes (se référer à la figure 7):
1. Il s'agit de la frontière normale assurée par le Centre de télécommunication à l'aide des passerelles spécialisées: FTRG, PAX400, GWI et par extension CAA, ainsi que par les filtres placés au niveau du réseau: rejet des appels non autorisés vers les systèmes locaux dans les noeuds du réseau: noeud X25, routeurs, etc. Cette frontière est placée sous la responsabilité opérationnelle de la Direction informatique et sous l'autorité du Bureau de sécurité. Elle est mise en oeuvre par un Firewall dont les spécifications sont données au point 2. Ce type de frontière doit subsister à long terme.
2. Lorsqu'un serveur public est placé physiquement dans les locaux d'une Direction générale et non au Centre de calcul ou au Centre de télécommunications, cette frontière assure l'étanchéité entre le réseau interdomaine et le sous-réseau sur lequel est connecté le serveur public en question. Cette frontière est placée sous la responsabilité opérationnelle de la Direction informatique et sous l'autorité du Bureau de sécurité. La politique de filtrage est négociée entre la Direction générale concernée, la Direction informatique et le Bureau de sécurité et les filtres mis en place par les gestionnaires du réseau IDNet/SNet de la Direction informatique. La décision fait l'objet d'une convention indiquant les moyens mis en oeuvre et
l'engagement de la Direction générale de les respecter. La décision finale revient au Bureau de sécurité. (cf. les règles de connexion au § 3.2).
3. Connexion d'un sous-réseau isolé considéré comme extension du réseau d'un domaine local. Un ensemble de segments, appelé par la suite: "sous- réseau externe" connectés directement au réseau local d'une Direction générale sans passer par le Back-bone de IDNet n'offrent pas un niveau de confiance suffisant quant à son étanchéité vis-à-vis du réseau externe. C'est le cas lorsque pour des raisons de service, les segments connectés sont placés dans un bâtiment ou dans un environnement mal contrôlable par la Commission, par exemple des experts dans un bâtiment isolé mais travaillant exclusivement pour la Commission. Ce cas est une exception qui doit être justifiée. Ce type de besoin doit être satisfait, de préférence, par une connexion via le Centre de télécommunication. Les dispositifs de contrôle d'accès mis en oeuvre à la frontière doivent garantir que seuls les utilisateurs autorisés pourront se connecter au réseau du domaine local concerné: cartes à micro processeur, chiffrement, etc. (cf. les règles de connexion au § 3.2).
Ce type de frontière devrait être supprimé et remplacé par les accès normaux via le Centre de télécommunication lorsque l'authentification et le contrôle d'accès basé sur les mécanismes de la couche 7 seront opérationnels.
4. Il s'agit de la frontière entre systèmes de diffusion et de production, placés dans les serveurs du Centre de calcul. Cette frontière doit garantir l'étanchéité entre domaine public, diffusion, et domaine interne, réseau interdomaine, dans le sens extérieur - intérieur. Elle est basée sur les protections internes aux systèmes d'exploitation ou par des mécanismes d'isolation des serveurs (voir ci-dessus type 2).
5. Il s'agit de la frontière entre systèmes de sensibilités normale et classifiée placés dans les serveurs du Centre de calcul. Même remarque que pour 4.
3.2.4 Accès externes.
Les échanges de données entre les domaines locaux et l'extérieur, transitent par le centre de télécommunication aussi bien pour les couches basses que pour les couches hautes.
La Décision C(95) 1510 du 23 novembre 1995 relative à la protection des systèmes d'information définit les responsabilités des utilisateurs statutaires (Article 5). Par extension, ces règles s'appliquent au personnel non statutaire et doivent être transcrites dans les contrats.
La protection repose sur l'identification et l'authentification des individus. Celles- ci se font par un mot de passe, ou, mieux par l'utilisation d'une carte à micro- processeur2. La responsabilité de l'utilisation de l'authentification (mot de passe ou carte) incombe à l'utilisateur et à travers lui, s'il n'est pas statutaire, à la firme à laquelle il appartient et avec laquelle la Commission a un contrat. La gestion du contrôle d'accès incombe au propriétaire du système d'information. La Commission possède des systèmes de journalisation destinés à enregistrer les actions des utilisateurs notamment au moment des connexions.
a) Utilisateur statutaire isolé.
Il s'agit d'un utilisateur isolé, statutaire, juridiquement "interne" mais travaillant hors du domaine physique interne (domicile ou mission) de la Commission.
La connexion s'établit à travers les passerelles du Centre de télécommunication. La procédure d'identification et d'authentification est réalisée par la passerelle et utilise le mécanisme de la carte à micro processeur (cf. § 3.2.1 c-dessus). L'utilisateur doit être équipé d'un poste de travail assurant au moins les fonctions de sécurités (cf. § 3.3.1 ci- après) (1), (2) par carte à microprocesseur, (5), (6) et (8). Les autres fonctions de sécurité sont mises en oeuvre en fonction des besoins de sécurité spécifiques.
b) connexions avec les prestataires.
L'utilisation d'une carte à microprocesseur permet d'imputer avec certitude les actions au personnel de la firme et d'engager juridiquement celle-ci. La mise en place de cette organisation a des implications techniques et contractuelles.
La connexion des prestataires sous contrats spécialisés, réalisant des travaux spécifiques (développement ou télémaintenance) décrits dans un contrat, s'effectue via le Centre de Télécommunication de la même façon que les utilisateurs statutaires (cf a) ci-dessus).
Les règles suivantes doivent être ajoutées au contrat. Elles stipulent:
· le personnel de la firme doit utiliser les cartes nominales fournies par la Commission;
2 Une carte à microprocesseur, gérée par le Centre de télécommunication et qui fonctionne en conjonction avec les boîtes de sécurité SIS est disponible. Celle-ci authentifie l’adresse IP. Elle pourra
· la firme doit installer à ses frais les logiciels et matériels nécessaires au contrôle d'accès et déterminés par la Commission;
· la firme s'engage à utiliser les dipositifs conformément aux règles de la Commission, notamment, celles s'appliquant aux utilisateurs de la Commission, uniquement dans le but prévu par le contrat et pour rien d'autre;
· Le contrat doit faire référence aux règles appliquables à tous les utilisateurs (cf. Décision de la Commission relative à la protection des systèmes d'information du 23 novembre 1995 C(95) 1510 - Article 5).
· la firme est responsable de la gestion interne et de l'attribution des moyens d'authentification (cartes à microprocesseur, mot de passe, etc.) fournis à son personnel;
· la firme est juridiquement et solidairement responsable des conséquences d'une mauvaise utilisation des dispositifs, notamment l'échange ou la perte des cartes ou des mots de passe et permettant l'utilisation des systèmes de la Commission par des personnes non autorisées.
· le non respect de ces règles peut entraîner la rupture du contrat sans indemnités de la part de la Commission.
c) Utilisateur dans un domaine local externe.
Si le domaine est sécurisé (voir la définition et les règles d'habilitation au § 3.2.6 ci-dessous), l'utilisateur est considéré de la même façon qu'un utilisateur appartenant à un domaine local interne.
Si le domaine n'est pas sécurisé, l'utilisateur est considéré comme un utilisateur isolé (cf. a) ci-dessus).
d) Extension de réseau local.
Les règles ci-après s'appliquent à la frontière 3 décrite au point 3.2.3.
· Si les personnels ne sont pas assujettis au statut des fonctionnaires des Communautés, Ils doivent être sous un contrat de prestation avec la Commission.
· Le sous-réseau externe ne doit être connecté à aucun autre réseau, quelqu'en soit son type (TCP/IP, X25, ISDN, Téléphonique, etc.).
· Chaque personne utilisant un poste de travail connecté au sous- réseau externe doit être identifiée et authentifiée de façon unique, si possible par carte à microprocesseur.
· Un dispositif de filtrage, géré par Direction informatique [ou la Direction générale], sous le contrôle du Bureau de sécurité, doit être installé à la frontière 3 assurant que seules les personnes dûment identifiées accèdent au réseau local interne.
· Le contrat doit contenir des clauses impliquant juridiquement la firme prestataire en cas de non respect des règles (cf. § 3.2.4 b - Règles de connexion de prestataires).
Ces règles constituent le niveau minimal requit, elles peuvent être complétées, à la demande de la Direction générale afin de limiter davantage l'accès.
3.2.5 Protocoles autorisés sur le réseau inter-domaine.
Les protocoles des couches hautes non repris dans la liste suivante sont interdits sur le réseau inter-domaine, notamment NFS sauf autorisation explicite de la Direction informatique et du Bureau de sécurité.
Liste des protocoles des couches hautes autorisés sur le réseau inter-domaine IDNET:
· Terminal:
- TELNET - http
- client-serveur - VT220
- Emulation 3270 IBM - Emulation 9750 Siemens
· Transfert de fichier - FTP
· Messagerie
- X400/TCP-IP (RFC 1016)
· RPC DCE Sur TCP
· SNMP
· SQL
· Backup à distance
3.2.6 Domaine local sécurisé.
Pour qu'un domaine local soit dit sécurisé il doit remplir toutes les conditions suivantes:
· Il ne doit pas avoir de connexion directe avec les réseaux de niveau de sécurité N0 (réseau public externe), les connexions se font via le Centre de télécommunication ou via un dispositif analogue (Firewall homologué),
· Il doit être isolé physiquement du domaine public (contrôle d'accès au bâtiment)
· Il n'a des connexions qu'avec d'autres domaines locaux sécurisés au sein d'un réseau fermé (contrôle sur adresses authentifiées: NUAcheck, etc.).
· L'ensemble des règles ci-dessous sont contrôlées par le Bureau de sécurité qui donne l'homologation ratifiée dans une convention ad hoc (cf. annexe 3).
Ces conditions sont nécessaires mais pas suffisantes. La Direction générale peut adopter des mesures plus restrictives si les enjeux définis dans une analyse de risque l'imposent.
Par construction, les domaines locaux intérieurs sont en principe sécurisés.
En ce qui concerne les domaines locaux extérieurs les conditions décrites ci- dessus doivent être remplies pour qu'il soit considéré comme sécurisé. Tout domaine local peut être homologué comme sécurisé à partir du moment où il respecte les règles. Notamment, des réseaux de prestataires peuvent être homologués.
Toute connexion directe externe avec un ordinateur se trouvant dans un domaine autre que public (N1) est règlementée et doit être approuvée par le Bureau de sécurité.
3.2.7 Services offerts par la Commission sur les réseaux externes.
Il s'agit de services informatiques gérés par la Commission ou par un sous- traitant dûment mandaté, et accessibles par des utilisateurs externes, c'est-à-dire n'ayant pas de lien juridique du type contrat de travail ou de prestation avec la Commission. Il est rappelé que la mise à disposition de services à l'extérieur est sujette à autorisation. Pour offrir ces services, Il est nécessaire:
· de limiter les connexions:
- en termes de services offerts
- en termes de configurations connectées
- en termes de connexions effectives (non permanentes)
· de différencier les services offerts par la Commission à l'extérieur, notamment sur INTERNET, des services internes, en les plaçant sur des serveurs spécialisés.
Les services offerts doivent être placés dans le domaine de sécurité public (Niveau N1) et être isolés des services internes d'une des façons suivantes:
· placés au Centre de Calcul dans des applications de Diffusion (règles de sécurité spécifiques);
· placés sur des systèmes ou sous-réseaux isolés physiquement et non connectés au réseau CCE;
· placés sur des systèmes ou sous-réseau isolés du réseau CCE par des
"valves"3 n'autorisant pas les accès extérieurs-intérieurs, mais seulement les accès intérieurs-extérieurs;
· placés au Centre de télécommunication sur les passerelles spécialisées:
PAX400, FTRG, ...;
· placés sur des serveurs externes (CompuServ, Cix, Delphi,...) accessibles depuis le réseau de la CCE dans le sens CCE-serveur externe et à l'initiative de la CCE.
· Les configurations (ordinateurs, sous-réseau, etc) doivent être reconnues comme "sûres"4 par le Bureau de Sécurité (voir le modèle de convention à l'annexe 2).
3 Une "valve" est un dispositif interceptant tout trafic dans un sens. Il peut s'agir d'un simple routeur ou de boitiers spécialisés. Le trafic dans l'autre sens peut être plus ou moins filtrés selon les besoins.
4 Configuration isolée du réseau CCE par un dispositif agréé par le Bureau de Sécurité et des règles de
3.2.8 Règles concernant la connexion à INTERNET comme utilisateur:
Il s'agit de l'accès aux services offerts par INTERNET, par des personnes appartenant à l'Institution, dûment autorisées, depuis le réseau physique intérieur. Par défaut, tout service ou protocole non explicitement autorisé est interdit.
a) Règles concernant les connexions sortantes:
· services possibles, sous réserve d'utiliser des produits autorisés:
- telnet, - ftp,
- client/ serveur,
· pour le courrier électronique, utilisation de la passerelle X400 et de smtp,
· pour le transfert de fichiers, l'utilisation de FTRG est possible mais non obligatoire,
· les protocoles NFS et X11 sont interdits.
b) Règles concernant les connexions entrantes:
· pour le transfert de fichiers, utilisation de ftp via la passerelle FTRG,
· pour le courrier électronique, utilisation de X.400 sur TCP/IP via la passerelle PAX400. La conversion smtp (RFC822) / X.400, ainsi que le cas échéant, la conversion X.400 sur TCP/IP, ainsi que, le cas échéant, la conversion X.400 / ILS, sont assurées.
· Les accès interactifs (telnet) ou client / serveur sont interdits sauf utilisation de dispositifs sûrs (carte à microprocesseur).
c) Règles d'utilisation:
· Respecter les règlements, notamment, la Décision de la Commission concernant la protection des systèmes d'information, les règles édictées par le Bureau de sécurité et les IRM.
· Ne se connecter qu'à partir de son poste de travail autorisé.
· Ne pas donner accès à une autre personne.
· Ne pas divulguer d'informations susceptibles de favoriser des tentatives d'accès non autorisées depuis l'extérieur de la Commission.
· Ne transférer aucunes données non autorisées vers l'extérieur de la Commission conformément à l'article 17 par 1. du statut des fonctionnaires.
· Ne pas importer et installer, sans autorisation préalable, de logiciels en provenance du réseau externe, notamment INTERNET.
· N'effectuer des transmissions entrantes ou sortantes que dans le strict cadre du service.
3.3 Equipements (PC/serveurs).
3.3.1 Sécurité sur le poste de travail.
Chaque poste de travail (PC Windows ou son évolution) doit disposer d'un certain nombre de fonctions de sécurité conformes au niveau C2-E2 de ITSEC.
Celles-ci sont les suivantes:
a) Identification et authentification:
(1) Identification et authentification de l'utilisateur préalable à toute utilisation du PC,
(2) Authentification par mot de passe (avec contrôle de taille, contenu, durée de validité minimum et maximum, non réutilisation) ou carte à microprocesseur quand elle sera disponible.
b) Contrôle d'accès:
(3) PC multi-users multi-comptes avec profils d'utilisateurs (PC partageable) (4) Système de protection des fichiers de type discrétionnaire permettant de
distinguer les accès: lecture, écriture, exécution et leur combinaison: R, RW, RE,E, no access.
(5) Time out en cas d'inactivité (paramétrable) avec déblocage après réauthentification (MP ou Carte à microprocesseur),
(6) Protection du boot par désactivation du disque dur en cas de chargement à partir d'une disquette (lecture et écriture impossible).
(7) Protection d'accès aux disquettes non autorisées.
c) Journalisation et audit:
(8) Enregistrement d'évènements tels que: tentative de connexion, etc.
d) Réutilisation d'objet:
(9) Effacement physique des supports, disque dur ou disquette.
e) Confidentialité:
(10) Chiffrement des fichiers avec clé sur carte à microprocesseur, si existante, board, disque dur, etc. Algorithmes échangeables et adaptés, software ou hardware.
f) Intégrité:
(11) Protection des fichiers contre les modifications non autorisées (checksum ou équivalent).
g) Sécurité des échanges:
Pour la partie client:
(12) Authentification de l'origine du message, (13) Intégrité du message,
(14) confidentialité du message,
(15) non-répudiation de l'origine du message.
(16) Deux niveaux:
· administrateur
· utilisateur.
i) Single log-on:
(17) Procédure d'authentification unique pour tous les serveurs.
3.3.2 Sécurité sur le serveur.
Les fonctions de sécurité doivent être conformes au niveau C2-E2 de ITSEC.
3.3.3 Intégration des services de sécurité5.
a) Login sur serveur avec carte à microprocesseur.
1er cas: sans modification des serveurs.
Le poste de travail (PC) est équipé d'un programme d'interface qui intercepte la demande de login en direction de l'écran et du clavier, et la redirige vers la carte à microprocesseur. Ce type d'interface n'est à développer qu'une fois pour Windows.
La carte doit contenir dans la partie réservée aux applications spécifiques des zones destinées à recevoir des couples User/id - mots de passe (un couple par serveur potentiel).
La gestion de ces couples est réalisée par l'utilisateur à l'aide d'un programme d'interface sur le poste de travail qui lui offre la modification du user/id-mot de passe simultanément sur la carte et sur le serveur. Ce programme est à réaliser une fois pour windows et, éventuellement, pour chaque type de serveur. Cependant, il est probable qu'une seule version soit possible pour tous les types de serveurs.
Le choix du mot de passe peut être assisté par un générateur de mot de passe créant des mots de passe illisibles par un humain et de longueur quelconque. En effet, ce mot de passe ne sera jamais connu par l'utilisateur mais placé sur la carte et protégé par le dispositif de contrôle d'accès à celle-ci. L'utilisateur ne doit que retenir, dans la situation actuelle, son PIN-code. Dans l'avenir, il est envisageable qu'il soit remplacé par un système bio-métrique.
Le schéma de la figure 8 montre la gestion du login.
5 Cette intégration suppose l’existence d’une carte à puce qui est en cours d’évaluation. L’intégration peut être réalisée sans carte mais au prix d’une diminution du niveau de sécurité. Dans ce second cas, les clés et les algorithmes cryptographiques sont placés sur des support matériels ou réalisés par logiciel.
...
...
USER/ID 1 MP1 Ident ...
EEPROM
Carte à microprocesseur PC SERVEUR
Demande LOGIN USER/ID?
"USER/ID"?
"USER/ID"
MP?
MP?
"MP"
Programme d'inter- ception du Login
Figure 8: Schéma de gestion d'un login serveur avec une carte à microprocesseur.
Aucune modification n'est apportée dans le serveur qui dialogue avec le PC.
2ième cas: login sur serveur avec modification du serveur:
Si on peut modifier la procédure de login sur le serveur, alors ce- dernier peut accéder directement à la carte. Celle-ci dispose d'algorithmes permettant une procédure par échange d'aléas (challenge-response). Cette procédure est plus sécurisée car elle utilise un mot de passe dynamique non rejouable. Elle ne résout toutefois pas le problème de la sécurisation des échanges de RPC.
L'interface est montrée à la figure 9.
...
Ident ...
EEPROM
Carte à microprocesseur
PC SERVEUR
Demande LOGIN
USER/ID?
"USER/ID"
Programme d'inter- ception du Login
Crypto.
ALEA
REPONSE Algorithme(ALEA)
-> REPONSE
Figure 9: Procédure de challenge-response par le serveur.
3ième cas: Sécurisation des RPC:
Cette troisième phase implique la mise en place complète de l'architecture, c'est-à-dire, celle des serveurs d'authentification.
L'interface est montrée à la figure 10.
...
Ident ...
EEPROM
Carte à microprocesseur
PC SERVEUR
Demande d'authentification
USER/ID?
"USER/ID"
Programme d'inter- ception du Login
Crypto.
ALEA
REPONSE Algorithme(ALEA)
-> REPONSE
D'AUTHENTIFICATION
TICKET TICKET
SERVEUR TICKET
TICKET
Vérif?
OK
Figure 10: Schéma du login avec serveur d'authentification.
L'interface entre les applications (login dans ce cas) et les services de sécurité, dans le serveur et dans le client, est assurée par les GSS-API (cf. annexe5).
b) Signature.
L'intégration est montrée dans le cas de Route400 à la figure 11.
CARTE A
MICROPROC. DRIVER MS-DOS LOGIN PC WINDOWS 3.1 CLIENT SERVEUR
Demande login R400
"USER/ID?"
USER/ID R400
"PASSWORD"
PW="..."
Demande signature
H CODE M
E
M E '
E
E ' = (E) RSA RSA
ENT.
(1)
(2) (3)
(4)
(6) (5)
(1) Adaptation "Login application" (par exemple: Route400): la fenêtre est remplacée par un accès à la carte à microprocesseur.
(2) Les entêtes du message doivent suivre une norme: PEM, PGP, ...
(3) Programme spécifique dialoguant avec la carte du type échange d'aléas (challenge-response) ou demande de PIN-code.
(4) Adaptation du processus client, par exemple celui de route400: fabrication empreinte, dialogue avec la carte, etc.
(5) Processus client de route400, SINCOM2, etc.
(6) Processus serveur de route400 (UA), SINCOM2, etc.
ENTÊTE
E ' + CRYPTO
TOOLKIT
(7)
(7) Algorithme de H-coding (MD5 par exemple) réalisé par logiciel.
(8)
(8) Logiciel de cryptologie assurant l'interface avec les modules de crypto: logiciel, board ou carte. API = GSS-API
Figure 11: Intégration de la signature électronique.
c) Intégration du chiffrement.
L'intégration est montrée dans le cas de Route400 à la figure 12.
CARTE A
MICROPROC. DRIVER MS-DOS LOGIN PC WINDOWS 3.1 CLIENT SERVEUR
Demande login R400
"USER/ID?"
USER/ID R400
"PASSWORD"
PW="..."
Demande chiffrement
M
M ' ENT.
(1)
(2) (3)
(4)
(6) (5)
(1) Adaptation "Login application" (par exemple: Route400): la fenêtre est remplacée par un accès à la carte à microprocesseur.
(2) Les entêtes du message doivent suivre une norme: PEM, PGP, ...
(3) Programme spécifique dialoguant avec la carte du type échange d'aléas (challenge-response) ou demande de PIN-code.
(4) Adaptation du processus client, par exemple celui de route400: fabrication empreinte, dialogue avec la carte, etc.
(5) Processus client de route400, SINCOM2, etc.
(6) Processus serveur de route400 (UA), SINCOM2, etc.
ENTÊTE CRYPTO TOOLKIT
Clé?
Clé sym
M
M ' = (M) Algo M ' Algo
(7)
(7) Algorihme de chiffrement sysmétrique par logiciel, par matériel (board).
Fabr. entête (8)
(8) Logiciel de cryptologie assurant l'interface avec les module de crypto: logiciel, board ou carte. API = GSS-API Clé Sym
RSA (Clé sym) RSA
Figure 12: Intégration du chiffrement.
