Brevet FR2802662A1 — publié le 20010622

PROCEDE ET DISPOSITIF DE CONFIGURATION CENTRALISEE DE PARE-FEU DANS UN SYSTEME INFORMATIQUE présente invention concerne le domaine de pare-feu dans un système informatique, et plus particulièrement de la configuration de pare- feu. L'art antérieur pare-feu est une machine ou groupes de machines permettant sécuriser la jonction entre un réseau intérieur et un réseau extérieur qu'Internet contre des intrusions non autorisées, voire malveillantes. Il rappele qu'Internet consiste en un ensemble de réseaux et machines interconnectés dans le monde entier, permettant à des utilisateurs quatre coins de la terre de partager des informations. terme machine dans la présente description représente une unité conceptuelle très large, de nature matériel et/ou logiciel. Les machines peuvent être très diverses, telles que des stations de travail, serveurs, routeurs machines spécialisées et passerelles entre réseaux. Tous les messages transitant entre le réseau intérieur et extérieur doivent passer par le pare-feu qui examine chaque message et bloque ceux qui ne répondent pas à des règles de sécurité déterminées. Le pare-feu est un élément d'une politique globale de sécurité, intégré dans un environnement applicatif de plus en plus riche et destiné à protéger des ressources d'information. pare-feux sont utilisés notamment pour empêcher les utilisateurs d'Internet non autorisés d'accéder à des réseaux internes connectés à Internet, pour donner à un utilisateur d'un réseau interne l'accès à Internet de manière sûre, pour séparer les machines publiques d'une entreprise permettant l'accès à Internet de son réseau interne, pour réaliser un cloisonnement à l'intérieur d'un réseau donné, pour protéger les segments de réseaux internes cloisonnés. Le pare- est matérialisé par exemple par une machine dédiée qui contrôle l'accès différentes machines d'un réseau intérieur déterminé. Pour ce faire, le pare-feu contrôle quelles machines et/ou quels utilisateurs et/ou quels services ou applications d'un réseau intérieur peuvent accéder quelle machine et/ou quels utilisateurs et/ou quels services ou applications d'un réseau extérieur et inversement. Les machines appartenant au réseau Internet utilisent le protocole TCP/IP. Le pare feu effectue des filtrages des communications TCPAP. Le pare-feu manipule des données applicatives, informations transmises dans la partie réservée aux données dans les en-têtes des paquets TCP/IP. Un paquet TCPAP une unité d'information constituée d'une suite d'éléments binaires définies par le protocole TCP/IP. Les critères de filtrage du pare-feu sont par exemple de manière non limitative: # l'adresse appelante, # l'adresse appelée, # l'application appelée. Pour configurer plusieurs pare-feu, et a fortiori dans le cas d'un grand nombre de pare-feu (quelques dizaines, voire une centaine ou plus), l'administrateur se heurte aux difficultés suivantes -. a Appréhender la complexité de la configuration en terme de nombre de règles de sécurité. La taille importante des réseaux comportant un grand nombre (à partir d'une centaine) de stations de travail, de serveurs, d'utilisateurs, voire d'applications obligent très souvent au déploiement de nombreux pare-feu. Il en résulte une politique de sécurité complexe comportant grand nombre de règles de sécurité définissant les autorisations d'accès ressources. La complexité de configuration des pare-feu d'un système donné se multiplie avec le nombre croissant de pare-feu à prendre considération. *Assurer la cohérence de configuration entre les différents pare-feu. Dans le contexte d'un grand réseau mettant en #uvre un nombre important pare-feu, la plupart des communications traversent plusieurs pare-feu. ne suffit pas de configurer tous les pare-feu indépendamment les uns des autres ; il faut les configurer de manière coherente. Pour une communication donnée, les pare-feu ne doivent pas appliquer des décisions contradictoires, l'un autorisant un accès alors que simultanément, un autre pare-feu refuse. Lors de la configuration d'un grand nombre pare-feu, la combinatoire pour assurer cette cohérence devient très rapidement trop grande pour pouvoir être appréhendée manuellement par administrateur. e Appréhender la topologie du réseau. Dans le cadre d'un grand réseau, dans lequel un nombre important de pare-feu est déployé, une connexion entre deux machines susceptible de traverser plusieurs pare-feu. Dans ces conditions, et dans but d'assurer une configuration cohérente de l'ensemble du système, il est nécessaire de connaître, pour toutes les connexions que l'on veut autoriser ou interdire, la liste de tous les pare-feu que la dite connexion traverse afin de pouvoir configurer lesdits pare-feu en conséquence. constitution d'un grand réseau, son découpage en différents segments, la manière dont il est cloisonné et les emplacements des pare- feu, constituent un problème compliqué en soit. Appréhender le problème de la constitution à chaque fois que l'on configure une règle sécurité, pour définir quels pare-feu ladite règle s'applique, est problème trop compliqué à gérer pour un administrateur. e Transférer les règles de sécurité sur chacun des pare-feu. transfert des règles est une opération qui peut rapidement s'avérer très longue à réaliser manuellement lorsque le nombre de pare-feu est important. Au cours de cette phase de transfert et de prise en compte des règles par chacun des pare-feu, les configurations pare-feu sont incohérentes entre elles: une partie des pare-feu opère avec l'ancienne configuration alors que l'autre partie opère avec la nouvelle. Dans le cas d'un grand nombre de pare-feu, la convergence vers un état stable de la configuration des pare-feu peut donc être très difficile et très longue à atteindre et la situation devient très vite impossible à gérer pour l'administrateur. Dans le cadre de la configuration d'un grand nombre de pare-feu, toutes les difficultés énumérées ci-dessus rendent humainement impossible à mettre en pratique une démarche de configuration qui consiste de près ou de loin en une simple répétition de la méthode de configuration d'un seul pare-feu, La simplification de la configuration est un objectif prioritaire d'un administrateur de pare-feu. Les solutions courantes connues pour tenter de résoudre le problème de complexité de configuration sont les suivantes. On connaît un dispositif commercialisé sous l'appellation Net Partitioner produit par la Société Solsoft. Le dispositif Net Partitioner permet à l'administrateur de représenter graphiquement l'ensemble de son réseau, avec l'implantation pare-feu, ainsi que différents serveurs et des stations de travail qui font partie. Les machines sont représentées par des icônes et leur interconnexion par des traits les reliant. L'administrateur définit également sous forme de flèches la manière dont les machines peuvent accéder à d'autres machines et aux applications qu'elles hébergent. La description du système (à savoir l'ensemble des machines présentées sous forme d'icônes et leur interconnexion sous forme de traits) et la spécification des règles appliquées au système et représentées sous forme de flèches sont combinées sur une même interface graphique. Plus le système comprend de machines et plus les connexions entre ces machines sont nombreuses, plus il est difficile pour l'administrateur de décrire le système et les règles d'accès à partir de l'interface. De plus, seul un filtrage IP est possible à savoir un filtrage sur l'adresse appelante et appelée et sur l'application appelée uniquement. Il n'est pas possible d'effectuer des filtrages plus fins comme par exemple un filtrage sur l'utilisateur appelant. Par ailleurs, le dispositif Net Partitioner ne prévoit aucun transfert règles depuis ledit dispositif vers les pare-feu concernés et aucune prise compte de la nouvelle politique de sécurité. L'administrateur doit lui-même configurer chacun des pare-feu à partir des résultats procurés par le dispositif Net Partitioner, Cette solution ne permet donc pas de simplifier la procédure de configuration pare-feu. Un but la présente invention est de simplifier la configuration grand nombre de pare-feu. Résumé de l'invention Dans ce contexte, la présente invention propose un procédé configuration de pare-feu dans un système informatique comportant des objets, les objets participant à une politique de contrôle d'accès étant appelés ressources, caractérisé en ce qu'il sépare la description du système de la spécification de la politique de contrôle d'accès sous forme d'au moins une règle de contrôle d'accès entre une ressource d'origine et une ressource de destination. La présente invention concerne également le système de mise en #uvre dudit procédé. Présentation des figures D'autres caractéristiques et avantages de l'invention apparaîtront à lumière de la description qui suit, donnée à titre d'exemple illustratif et limitatif de la présente invention, en référence aux dessins annexés dans lesquels: *la figure 1 est une vue schématique du système selon une forme de réalisation de l'invention; ela figure 2 est une copie d'écran d'une interface graphique présentant des pare-feu du système selon la figure 1 ; *la figure 3 est une copie d'écran d'une interface graphique présentant des ressources du système selon la figure 1 ; *la figure 4 est une copie d'écran d'une interface graphique présentant des groupes de ressources du système selon la figure 1 ; *la figure 5 est une copie d'écran d'une interface graphique présentant des règles de sécurité établies dans le système selon figure 1. Description d'une forme de réalisation de l'invention Comme le montrent les figures 1 à 5, la présente invention se rapporte à procédé et un dispositif 1 de configuration de pare-feu 2 ou équivalent dans un système informatique 3. Le système informatique 3 est distribué et comprend des objets 4, des utilisateurs les pare-feu 2. Un objet 4 est une unité conceptuelle très large, de nature matérielle et/ou logicielle. Les objets 4 peuvent être très divers, tels que des réseaux, des sous-réseaux, des stations de travail, des serveurs, des routeurs, des machines spécialisées et passerelles entre réseaux, des applications, des services. Seuls les composants objets 4 du système 3 caractéristiques de la présente invention seront décrits, les autres composants étant connus de l'homme du métier. Le système informatique 3 comprend une machine 5 de configuration centrale à partir de laquelle un administrateur 6 définit et met en place une politique de sécurité globale pour protéger des objets 4 du système informatique 3. Les objets 4 entre lesquels des règles de contrôle d'accès constituant la politique de sécurité du système 3 sont definies par l'administrateur, sont appelés ressources 7. Comme montré sur la figure 1, la machine 5 de configuration centrale comporte les modules suivants: eune interface 8 graphique qui permet à l'administrateur de décrire le système et notamment les pare-feu 2 et ressources 7, ainsi que la politique de contrôle d'accès à des ressources 7 du système 3; *un moteur 9 de compilation qui traduit les informations saisies par l'administrateur au moyen de l'interface 8 graphique en règles de contrôle d'accès assimilables par les pare-feu 2 et cohérentes entre elles et calcule leur répartition sur les pare-feu 2 appropriés ; eun module 10 de téléchargement et de synchronisation destiné à assurer le transfert des différentes règles créées sous forme fichiers par le moteur 9 de compilation vers les pare-feu appropriés, communiquer à l'ensemble des pare-feu l'instant auquel les fichiers de règles nouvellement transférés doivent être pris en compte et appliqués. L'administrateur 6 commande la machine 5 de configuration centrale au moyen d'un clavier et d'une souris ou de tout autre moyen de saisie équivalent. L'administrateur 6 décrit au moyen de la machine 5 de configuration centrale et plus particulièrement de l'interface 8 graphique le système 3 et notamment la liste des pare-feu contrôlés par le dispositif 1. La figure 2 montre un exemple de forme de réalisation de l'interface 8 offerte à l'administrateur 6. L'interface 8 comprend : *une barre 11 de menu contenant les menus classiques pour la manipulation de fichiers, l'impression et l'accès aux caractéristiques de l'interface 8 ; *une barre 12 d'outils offrant des raccourcis aux menus; *une fenêtre 13 d'objets présentant les ressources 7, les pare feu 2 et des critères particuliers susceptibles d'être utilisés pour créer des règles de contrôle d'accès. Les ressources 7, pare-feu 2 et critères sont classés par onglets 14 : l'onglet 14a utilisateur désigné par Users représente les utilisateurs du système 3 susceptibles d'être utilisés comme critère dans les règles contrôle d'accès ; l'onglet 14b période désigné par ValidityPeriods représente des périodes de validité, à savoir des restrictions en temps susceptibles d'être appliquées aux règles de contrôle d'accès telles que par exemple une restriction sur une date ou heure d'accès; l'onglet 14c ressource désigné par Ressources représente les ressources 7 du système 3 ; l'onglet 14d zone désigné par Zones représente des zones 15 de cloisonnement entre pare-feu 2 du système 3 décrites plus loin, les zones étant créés par l'administrateur et utilisées comme critère pour les règles de contrôle d'accès; l'onglet 14e pare-feu désigné Netwalls représente les pare-feu 2 du système 3 ; l'onglet 14f service désigné par Services représente les services du système tels que par exemple le service ftp, telnet, auxquels les règles de contrôle d'accès peuvent restreindre l'opération de filtrage. @une fenêtre 16 d'attributs présentant des caractéristiques des ressources pare-feu 2 et critères sélectionnés dans la fenêtre 13 ainsi que les règles de contrôle d'accès à différentes ressources 7 du système 3 correspondant à l'élément sélectionné. Les caractéristiques sont classés par onglets 17 ; dans l'exemple illustré sur les figures 2 à 5, lorsqu'un pare-feu 2 est sélectionné dans la fenêtre 13 d'objets, la fenêtre 16 offre notamment un onglet 17a propriété désigné par Properties . Lorsque l'onglet 17a propriétés est sélectionné, la fenêtre 16 d'attributs affiche les attributs et propriétés du pare-feu sélectionné dans la fenêtre 13 d'objets. Le contenu de la fenêtre d'attributs est adapté automatiquement pour prendre en compte les paramètres requis pour le type particulier de ressources, pare-feu ou critères sélectionnés dans la fenêtre d'objets. *une fenêtre 18 de règles permettant de composer des règles contrôle d'accès. Le procédé selon l'invention consiste à configurer, depuis la machine 5 de configuration centrale, de manière globale et cohérente, de nombreux pare-feu répartis dans le système 3 comportant un grand nombre ressources 7, Le procédé selon l'invention consiste à définir la politique de sécurité indépendamment de la constitution du système 3, des pare-feu 2 et de la manière dont les pare-feu sont répartis dans le système. Le procédé consiste à masquer à l'administrateur 6 l'opération de configuration des pare-feu, telle qu'on l'entend habituellement dans configuration d'un seul pare-feu, et de séparer rigoureusement : ela description du système et des pare-feu à configurer, description qui est réduite au strict minimum, puisque seules les relations d'adjacence entre les pare-feu sont renseignées, ela spécification de la politique de sécurité, qui représente l'objectif premier l'administrateur de pare-feu, la configuration des pare-feu n'étant qu'un moyen d'atteindre cet objectif. Dans le procédé de configuration selon la présente invention, description du système 3 se résume à la liste des pare-feu 2 et aux relations d'adjacence entre lesdits pare-feu : à l'aide de l'interface 8, l'administrateur décrit la liste des pare-feu qui sont contrôlés par le dispositif 1. L'administrateur 6 indique, pour chaque pare-feu, quels sont le ou les pare- feu avec lesquels il est voisin et définit les zones 15 de cloisonnement. Une zone 15 de cloisonnement est une partie du système 3 séparé du reste celui-ci par un ou plusieurs pare-feu. Les zones 15 sont séparées par un plusieurs pare-feu 2. Chaque pare-feu 2 délimite une ou plusieurs zones 15. Les pare-feu 2 comprennent des interfaces 19 réseau avec les zones 15. Dans la forme de réalisation illustrée sur la figure 1, le système 3 comporte quatre pare-feu 2 NW1, .... NW4. En sélectionnant l'onglet 14e pare-feu de la fenêtre 13 d'objets de l'interface 8 graphique comme le montre la figure 2, les différents pare-feu du système sont saisis puis affichés: NWI à NW4. L'administrateur 6 enregistre les propriétés des pare- feu dans la fenêtre 16 d'attributs (onglet 17a propriétés) : il sélectionne un pare-feu, NW1 dans l'exemple illustré sur la figure 2, dans la fenêtre d'objets. Le nom du pare-feu est inscrit dans une fenêtre 17b de saisie intitulée Name de la fenêtre 16 d'attributs. L'administrateur saisit les relations d'adjacence du pare-feu NW1. Il définit les zones 15 de cloisonnement délimitées par le pare-feu NW1 dans un tableau 20 de zones appelé Zones : la zone 11, la zone DIVIZ1, la zone dorsale (en anglais backbone) (dans l'exemple illustré Internet). Les dites zones sont mentionnées dans la colonne 17c Zone du tableau 20. Les noms indiqués dans la colonne 17d Name du tableau 20 de zones designent les interfaces 19 réseau du pare-feu avec les zones concernées. La colonne 17e appelée Address indiquent les adresses réseaux des interfaces 19 réseaux de la ligne correspondante du tableau 20. La description du système 3 est réduite aux pare-feu 2 et zones les séparant. La description est simple, Dans la présente forme de réalisation illustrée sur la figure 1, les zones 15 comprennent des réseaux ou sous-réseaux 21. Le pare- NWI connecté à un sous-réseau 22 interne li, à un sous-réseau 23 de type zone démilitarisée DMZ,, et au réseau 24 Internet. Un sous-réseau de type zone démilitarisée est un sous-réseau tampon, réalisant une sorte de sas entre un réseau interne et externe pour en renforcer la protection. Le pare-feu NW2 est connecté à un sous-réseau 23 de type zone démilitarisée DMZ2, et au réseau 24 Internet. Le pare-feu NW3 est connecté à un sous-réseau 22 interne 13 et au réseau Internet. Le pare-feu NW4 est connecté à un sous-réseau 22 interne 14, à un sous réseau 25 de liaison NW4-NW3 et à un sous-réseau 23 DMZ2. Dans l'exemple de forme de réalisation illustré sur figure 1, les sous réseaux 11, 13, 14 comprennent des stations de travail, respectivement par exemple les stations de travail Cl, C3, C4. Les sous-réseaux DMZ1, comprennent des serveurs, respectivement par exemple les serveurs SI, S2. Le sous-réseau de liaison NW3-NW4 ne comporte aucune machine. Le réseau Internet comprend la machine 5 de configuration centrale. Comme le montre la figure 3, l'administrateur saisit les propriétés des ressources 7 et dans le cas présent, du serveur SI. L'administrateur 6 indique à quelles zones 15 les ressources 7 appartiennent. L'administrateur sélectionne l'onglet Ressource dans la fenêtre 13 d'objets et le serveur SI dans la liste des ressources affichées. Dans la fenêtre 16 d'attributs, l'administrateur entre l'adresse du serveur SI, 123.0.0.202, dans la fenêtre de saisie intitulée Address et la zone 15 de cloisonnement à laquelle il appartient, DMZ1, dans la fenêtre appelée Zone . L'administrateur manipule au moyen de l'interface 8 graphique les ressources 7 du système 3. L'administrateur détermine au moyen de l'interface 8 graphique la politique de sécurité et plus précisément la politique d'autorisation ou d'interdiction d'accès pour l'ensemble des ressources 7 du système. procédé et le dispositif selon l'invention reposent sur la séparation entre description du système 3 considéré et la spécification d'une politique de sécurité globale. dispositif selon l'invention permet de créer, modifier, supprimer, gérer contrôles d'accès des objets du système, de manipuler la politique du réseau. L'administrateur 6 est susceptible à l'aide du dispositif 1 de regrouper des ressources 7 dans des groupes de ressources pour lesquels une même politique de sécurité est appliquée. Les groupes sont appelés classes. Dans l'exemple illustré sur la figure 4, l'administrateur définit classes représentées dans la fenêtre 13 d'objets : la classe G_ regroupe l'ensemble des zones comportant des sous-réseaux de type démilitarisés. La classe G-1 regroupe l'ensemble des zones comportant sous-réseaux internes. La classe G-L regroupe l'ensemble des zones comportant des sous-réseaux de liaison. La fenêtre 16 d'attribut affiche informations (onglet Properties ) sur les classes créées : il est indiqué dans illustré le nom Name de la classe G-DMZ. Dans la fenêtre appelee Comment , des commentaires peuvent être inscrits: la classe G_ regroupe l'ensemble des sous-réseaux DMZ. L'administrateur 6 définit des règles de contrôle d'accès dans fenetre 18 de règles. Lorsque les règles composées dans la fenêtre 18 sont validées (bouton OK), elles sont affichées dans la fenêtre 16 d'attributs lorsque l'onglet Rules est sélectionné comme le montre la figure 5. dispositif applique automatiquement la règle de contrôle d'accès à chaque ressource de la classe concernée. Dans l'exemple illustré sur la figure 5, l'administrateur a défini une règle autorisant l'accès depuis la classe G-1 vers la classe DMZ Il est à souligner que la saisie de la description du système et la saisie des règles de contrôle d'accès sont complètement séparées. La fenêtre 18 de règles contient un tableau 26 de règles. Le tableau 26 de règles comprend une colonne 27 Name pour identifier la règle de sécurité, une colonne 28 Source pour désigner la classe d'origine la relation, une colonne 29 Destination pour désigner la classe destination de la relation. Le dispositif 1 peut prendre en compte des critères particuliers pour les règles de contrôle d'accès. Le dispositif 1 est susceptible d'utiliser services simples courants tels que ftp ou telnet mais également des services à propriétés étendues tels que par exemple le service ftp filtrant. Le tableau 26 propose colonne 30 Services identifiant de manière optionnelle un service : l'opération de filtrage définie par la règle utilise le service mentionné dans ladite colonne. Le critère étant optionnel, la valeur défaut est ANY à savoir tous les services disponibles dans le système 3. Le dispositif peut appliquer au contrôle d'accès des critères de niveau applicatif supplémentaires compte-tenu des services à propriétés étendues susceptibles d'être utilisés. Le dispositif prend en compte comme critère supplémentaire de filtrage l'utilisateur appelant. Le tableau 26 de règles comprend une colonne 31 User identifiant de manière optionnelle un ou plusieurs utilisateurs : seul le ou les utilisateurs mentionnés peuvent accéder à la ressource de destination. Le critère étant optionnel, la valeur par défaut est ANY à savoir tous les utilisateurs. D'autres critères sont susceptibles d'être appliqués aux règles contrôle d'accès. Dans la forme de réalisation illustrée, le tableau 26 de règles comprend les autres critères suivants. tableau 26 de règles comprend une colonne 32 Auth définissant de manière optionnelle un type d'authentification pour la règle en question : par exemple si une authentification par carte à puce est requise, l'utilisateur doit s'authentifier avec une carte à puce pour obtenir l'accès contrôlé par la règle concernée, Le critère étant optionnel, la valeur défaut No Auth à savoir qu'aucune authentification n'est requise. Le tableau 26 de règles comprend une colonne 33 Period limitant de manière optionnelle la période d'application de la règle en question. liste des périodes possibles est donnée dans la fenêtre d'objets sélectionnant l'onglet 14b période. Le critère étant optionnel, la valeur par défaut est No Period à savoir qu'aucune période n'est imposée, la règle s'applique en permanence. Le tableau 26 de règles comprend une colonne 34 Log définissant de manière optionnelle une inscription au journal pour la règle en question : par exemple si un log de type Summary est requis, le début, la fin, la reconnexion et la fermeture d'une connexion sont inscrits au journal pour la règle concernée. Le critère étant optionnel, la valeur par défaut est No Log savoir qu'aucune trace n'est conservée de la connexion filtrée par la règle question. Le tableau 26 de règles comprend une colonne 35 Alert permettant d'associer une action particulière à un événement particulier. Pour utiliser critère, l'administrateur doit définir un log, un événement provoquant l'alerte et une action à exécuter lors d'une alerte. Le tableau 26 de règles comprend une colonne 36 Comment dans laquelle l'administrateur apporte des commentaires sur la règle concernée. L'administrateur définit une portée aux règles saisies. La portée de la règle est définie dans la colonne 37 Scope du tableau 26 règles et peut prendre valeurs LOCAL pour une portée locale ou GLOBAL pour une portée globale. Pour définir une portée locale, le procédé consiste à définir des domaines 38 de protection. La figure 1 montre l'exemple d'un domaine 38 de protection appelé Dl. Chaque pare-feu assure protection d'un domaine intérieur par rapport à un domaine extérieur. Le domaine intérieur de protection représente ce que l'administrateur souhaite protéger à l'aide d'un pare-feu donné par rapport à ce dont il veut le protéger, à savoir le domaine extérieur. Un domaine regroupe plusieurs zones 15. Le domaine Dl (figure 1) regroupe les zones Il et DMZ1. Si une règle est de portée locale, elle est appliquée entre une ressource d'origine et une ressource de destination uniquement si les ressources d'origine et de destination appartiennent au même domaine 38. Si une règle est de portée globale, elle est appliquée entre toutes les ressources d'origine et toutes les ressources destination. Le principe de délimiter une portée à la règle de contrôle d'accès est développé en détail dans la demande de brevet déposée le même jour que la présente par le présent déposant et dont le titre est Procédé et dispositif de configuration de pare-feu dans un système informatique . Un exemple de règles, la règle appelée 1-vers-DMZ, est illustré sur la figure 5 : Les ressources de la classe G_l peuvent accéder par tout type de service aux ressources de la classe G-DMZ sans authentification No Auh si les dites ressources appartiennent au même domaine LOCAL . Ainsi, l'administrateur n'a pas à connaître la constitution du système pour définir règles de contrôle d'accès. La définition des règles s'effectue indépendamment des pare-feu sur lesquels ces règles sont appliquées. L'administrateur peut également imposer un chemin pour le passage d'une communication entre une ressource d'origine et de destination en fonction des critères variés mentionnés ci-dessus. Comme le montre la figure 5, une colonne 39 RZone est prévue dans le tableau 26 de règles, colonne dans laquelle la ou lesdites zones 15 par lesquelles ne doit pas passer la communication sont indiquées. Les interfaces 19 réseaux associées découlent de la ou des zones interdites imposées. Le procédé permet donc contrôler la commutation des communications dans le système 3 imposant le passage d'une communication entre une ressource 7 d'origine et une ressource 7 de destination, par une ou plusieurs zones 15 et donc par une ou plusieurs interfaces 19 réseau déterminée pare-feu traversés, le choix de l'interface réseau etant effectué en fonction de critères variés. Le principe du contrôle de la commutation est décrit en détail dans la demande brevet déposé le même jour que la présente demande le présent déposant et dont le titre est Procédé et dispositif de configuration de commutation d'informations dans un système informatique . L'administrateur déclenche, en sélectionnant dans la barre 1 de menu la commande de compilation, la compilation de la politique de sécurité qu'il a spécifié de la manière décrite ci-dessus: le moteur 9 de compilation calcule automatiquement des règles de contrôle d'accès qui doivent être appliquées sur chacun des pare-feu sur la base des informations fournies par l'administrateur. Le moteur 9 de compilation calcule des configurations différenciées et propres à chaque pare-feu 2, ainsi que liste des ressources 7 contrôlées par ledit pare-feu. La compilation terminée, l'interface 8 graphique l'indique à l'administrateur. La compilation détermine pour chaque règle quels sont pare-feu du système 3 qui doivent recevoir cette règle. moteur 9 de compilation commence par ordonner règles définies l'administrateur 6 dans l'ordre exact dans lequel les pare-feu les appliquent. Les règles sont ordonnées par niveau de précision. L'administrateur, au travers de l'interface 8 graphique ne donne d'ordre dans les regles de sa politique de sécurité; l'ordre est déduit en fonction de la précision de chaque règle. Une règle d'ordre de précision est definie et un opérateur est-plus-précis-que ordonne automatiquement les règles entre elles. Le tri des règles se fait en fonction du niveau de précision des éléments (ressources, critères) qui composent la règle et dans l'ordre suivant : Utilisateur Ressource d'origine Ressource de destination Service Zone Période de validité Portée (GLOBAL/LOCAL) Niveau d'authentification IP Niveau de Log Alerte Nom de la règle. De manière générale, un élément simple est plus précis qu'un groupe d'éléments; un groupe est plus précis qu'un groupe contenant plus d'éléments que celui-ci. règles de précision dépendent du type d'éléments qui composent la règle: Pour des utilisateurs : utilisateur est plus précis qu'un groupe d'utilisateurs (comme mentionné plus haut dans la règle générale sur les groupes). Pour des ressources : adresse IP d'une machine est plus précise qu'une adresse de réseau ; adresse de réseau est plus précise que le mot clé ANYzone qui désigne l'ensemble des adresses susceptibles de se connecter par une interface pare-feu ; clé ANYzone est plus précis que le mot clé ANY. Pour services : service simple est plus précis qu'une plage de service ; service sans proxy est plus précis qu'un service avec proxy service avec proxy sans contrôle d'accès est plus précis service avec proxy et contrôle d'accès ; service avec proxy et contrôle d'accès est plus précis service avec proxy et plus de contrôle d'accès. Pour les zones : Une zone est plus précise qu'un groupe de zones (comme mentionné plus haut dans la règle générale sur les groupes). Pour les périodes de validité: La précision est inversement proportionnelle à la taille de la période de temps définie. Pour la portée: Une règle LOCAL est plus précise qu'une règle GLOBAL. Pour authentifications : Une authentification est plus précise qu'aucune authentification Une authentification IP est plus précise qu'une authentification par carte à puce. Pour niveau de log: Un niveau de log est plus précis qu'aucun niveau de log Un ordre de précision est défini suivant les types de log prévus. Pour l'alerte: Une regle avec une alerte est plus précise qu'une règle sans alerte Un ordre de précision est défini suivant les types d'alerte prévus. Pour le nom de la règle L'ordre de précision est obtenu par tri alphabétique sur le nom de la règle. Une fois les règles de contrôle d'accès ordonnées précision décroissante, le moteur 9 de compilation calcule leur répartition chaque pare-feu. Pour connaître sur quel pare-feu chaque règle doit être appliquée, le moteur de compilation construit une matrice d'adjacence des zones 15 de cloisonnement constituant une représentation logique des pare-feu, de leurs interconnexions et zones de rattachement. La matrice d'adjacence représente, au niveau du moteur 9 de compilation, les pare-feu et les zones de cloisonnement auxquelles sont connectés, sous la forme d'un graphe non orienté, dans lequel les sont les pare-feu et les n#uds sont les zones de cloisonnement. Pour chaque règle, le moteur 9 de compilation analyse de quelle zone de cloisonnement font partie les ressources définies comme origine et destination dans la règle, dans le but de déterminer quels sont les pare-feu concernés la règle. Il cherche ensuite à déterminer quels sont les différents chemins possibles pour aller de la zone d'origine (zone dans laquelle se trouve la ressource d'origine) à la zone destination (zone dans laquelle se trouve la ressource de destination), et par voie de conséquence, quels pare- peuvent potentiellement être traversés conformément à la règle. L'algorithme de recherche des pare-feu traversés se résume la manière suivante: *si la zone d'origine et la zone de destination sont adjacentes, on ne tient compte que du (des) pare-feu réalisant l'adjacence ; esi la zone d'origine et la zone de destination ne sont pas adjacentes, il est nécessaire d'effectuer un parcours du graphe en partant n#ud représentant la zone d'origine et en cherchant tous les arcs permettant de mener à la zone de destination . C'est un parcours de graphe en profondeur par inondation où les cul de sac c'est à dire les zones finales ne participant à un chemin sont éliminées. L'ensemble des arcs lequel le parcours passé représente l'ensemble des pare-feu traversés par un chemin allant de la zone d'origine à la zone destination. Ledit ensemble est mémorisé car il peut être réutilisé pour les chemins allant d'une zone adjacente à la zone d'origine vers une zone adjacente à la zone de destination. C'est l'ensemble des pare-feu situés sur les différents chemins possibles trouvés que la règle est appliquée. Le moteur de compilation crée pour chaque pare-feu des fichiers de règles de controle d'accès différents, et identifie pour chaque fichier de regle sur quel pare feu le fichier doit être transféré. Après calcul, l'opération suivante consiste pour l'administrateur 6 à déclencher transfert des fichiers de règles de contrôle d'accès sur chaque pare-feu. L'administrateur déclenche le transfert des règles en sélectionnant dans la barre 1 de menu la commande de transfert. Le module 10 de téléchargement et de synchronisation transfert les règles de contrôle d'accès sur les pare-feu 2 concernés. L'ensemble pare-feu compris dans l'ensemble des chemins de tous les couples (zone d'origine, zone de destination) d'une règle reçoivent les fichiers correspondant dans leur système de configuration. Le module 10 assure dans un premier temps, le transfert des fichiers de règles créés par moteur de compilation vers les pare-feu appropriés, et dans un deuxième temps, ordonne à l'ensemble des pare-feu la prise en compte des fichiers de règles transférés. Comme décrit ci-dessus, le moteur de compilation détermine sur quel(s) pare- chaque règle doit être appliquée : les fichiers contenant les règles de contrôle d'accès sont personnalisés pour chaque pare-feu (un fichier de règle différent pour chaque pare-feu). Le moteur de compilation identifié pour chaque fichier de règle à quel pare-feu il est destiné. Le module 10 de téléchargement et de synchronisation assure donc dans un premier temps la distribution vers chaque pare-feu du fichier règle qui lui est destiné. L'administrateur est averti de la fin du transfert. Les règles transférées, l'administrateur, dans un deuxième temps, déclenche la prise en compte de la nouvelle politique de sécurité, c'est dire des nouvelles configurations de contrôle d'accès, par tous les pare-feu contrôlés le dispositif. L'administrateur effectue le déclenchement lorsqu'il le souhaite. Par exemple, l'administrateur peut prévoir le transfert des règles deux jours avant la date à laquelle la nouvelle politique doit être mise en place; à la date prévue, il déclenche la prise en compte. Ainsi, il dispose deux jours si tout type de problèmes intervenait lors du transfert. Le module de téléchargement et de synchronisation assure la synchronisation des pare-feu avec la nouvelle configuration. Lorsque l'administrateur déclenche la prise en compte à partir du dispositif , le module de téléchargement et de synchronisation assure l'envoi à chaque pare-feu d'un ordre de prise en compte du dernier fichier règle qui a été transféré. Cette prise en compte conduit à l'application par chaque pare feu des nouvelles règles transférées, et donc de la nouvelle politique de contrôle d'accès au niveau global du réseau contrôlé, Le dispositif et le procédé selon l'invention répondent aux problèmes évoqués précédemment dans la mesure où: *la complexité en terme de nombre de règles, vue de l'administrateur est uniquement liée à la politique de contrôle d'accès et ne dépend pas de du nombre pare-feu à configurer. La complexité induite par le nombre de pare-feu à configurer est totalement prise en charge par le dispositif ; *la cohérence de contrôle d'accès de l'ensemble de pare-feu est assurée par le dispositif, puisque les règles découlent d'une même politique globale. cohérence n'a pas à être assurée par l'administrateur; @il 'est plus nécessaire d'appréhender la totalité du système à chaque fois que l'administrateur configure une règle. Les informations sur le système sont renseignées séparément et réduites aux relations d'adjacence entre les pare-feu ; *le transfert des règles de contrôle d'accès sur les pare-feu est assuré par le dispositif, qui transfert sur chaque pare-feu uniquement les règles qui l'intéressent ; *la cohérence lors du transfert de la nouvelle politique sécurité dans l'ensemble des pare-feu est assurée par une prise compte simultanée par les pare-feu de ladite politique, la simultanéité étant assurée par le dispositif central de configuration ; dispositif peut non seulement réaliser un filtrage IP mais également un filtrage applicatif à l'aide des services offerts par dispositif et offre ainsi la possibilité d'établir des règles de contrôle d'accès avec de multiples critères. présente invention concerne le procédé de configuration de pare- feu 2 dans le système 3 informatique caractérisé en ce qu'il sépare la description du système 3 de la spécification de la politique contrôle d'accès sous forme d'au moins une règle de contrôle d'accès entre une ressource 7 d'origine et une ressource 7 de destination. De manière avantageuse, le procédé limite la description système 3 à la désignation de zones 15 de cloisonnement entre lesdits pare-feu 2. Le procédé indique dans quels zones 15 de cloisonnement se trouvent les ressources 7 du système 3. Le procédé constitue un graphe non orienté dans lequel les arcs sont les pare-feu 2 et les noeuds sont les zones de cloisonnement 15. Les règles de contrôle d'accès sont réparties sur chaque pare-feu en effectuant un parcours de graphe permettant de retrouver l'ensemble des arcs menant de la zone 15 d'origine dans laquelle se trouve la ressource d'origine à la zone 15 de destination dans laquelle se trouve la ressource de destination l'ensemble des arcs à savoir des pare-feu retrouvés étant ceux auxquels s'appliquent la règle. Le procédé utilise des services à propriétés étendues pour permettre d'ajouter des critères de filtrage applicatifs aux règles de contrôle d'accès. Les criteres de filtrage supplémentaires sont l'utilisateur appelant, type d'authentification, une période d'application, un niveau de journalisation et/ou une alerte constituée par une action particulière associée à événement particulier. Selon développement de l'invention, le procédé définit une portee aux règles de contrôle d'accès. Selon un autre développement de l'invention, le procédé permet des restrictions sur la commutation des communications. Le procédé crée des fichiers de règles différents pour chaque pare- feu et identifie, pour chaque fichier de règles, sur quel pare-feu le fichier doit être transféré. Le procédé transfère les fichiers créés de règles de contrôle d'accès sur les pare-feu concernés. Le procédé ordonne à l'ensemble des pare-feu la prise en compte des fichiers des regles transférés. La présente invention concerne également le dispositif susceptible de mettre en #uvre le procédé décrit ci-dessus. Le présente invention se rapporte au dispositif de configuration pare-feu 2 dans le système 3 informatique comprenant au moins ressource 7, caractérisé en ce qu'il comprend la machine 5 de configuration centrale comportant : # l'interface graphique permettant de décrire le système 3 et la politique de contrôle d'accès aux ressources 7 ; # le moteur 9 de compilation qui traduit les informations saisies au moyen de l'interface 8 en règles de contrôle d'accès ; # le module 10 de téléchargement et de synchronisation destiné à assurer le transfert des règles créées par le moteur 9 vers les pare-feu appropriés. Le module 10 communique à l'ensemble des pare-feu l'instant auquel les fichiers de règles nouvellement transférés doivent être pris en compte et appliqués. REVENDICATIONS 1. Procédé de configuration de pare-feu (2) dans un système (3) informatique comportant une pluralité de ressources informatiques matérielles et/ou logicielles participant à une politique contrôle d'accès caractérisé en que le procédé comprend : étape de description de chaque ressource (7) du système (3) informatique, par l'intermédiaire d'une interface (8) graphique et de moyens de saisie, - une étape de description, par l'intermédiaire de l'interface graphique et de moyens de saisie, d'au moins une règle de contrôle d'accès entre une ressource d'origine et une ressource de destination permettant de définir une politique de contrôle d'accès entre ces deux ressources, - les deux étapes étant réalisées de manière indépendante. 2. Procédé selon la revendication 1, caractérisé en ce que l'étape de description de chaque ressource consiste en : - une étape de définition, pour chaque pare-feu et par l'intermédiaire l'interface graphique (8) et de moyens de saisie, d'une zone de cloisonnement comprenant au moins une ressource, - étape de désignation de toutes les zones de cloisonnement adjacentes à la zone de cloisonnement de chaque pare-feu, par l'intermédiaire de l'interface graphique (8) et de moyens de saisie. 3. Procédé selon la revendication 2, caractérisé en ce que le procédé comprend : - une étape de construction par l'intermédiaire de l'interface graphique (8), à partir de la définition des zones de cloisonnement et de l'étape de désignation des zones de cloisonnement adjacentes, d'une matrice d'adjacence représentée sous forme d'un graphe non orienté dans lequel les arcs sont les pare-feu et les n#uds sont les zones de cloisonnement, - une étape de recherche des pare-feu auxquels s'applique chaque règle contrôle d'accès, comprenant pour chaque règle une étape de parcours graphe pour déterminer l'ensemble des arcs menant d'une zone d'origine dans laquelle se trouve la ressource d'origine à une zone destination dans laquelle se trouve la ressource de destination, les graphes trouvés correspondant aux pare-feu auxquels s'appliquent la règle. 4. Procédé selon l'une des revendications 1 à 3, caractérisé en que l'étape description d'au moins une règle de contrôle d'accès comprend la sélection d'au moins un service à propriétés étendues permettant d'ajouter des critères de filtrage applicatifs aux règles de contrôle d'accès. 5. Procédé selon la revendication 4, caractérisé en ce que les critères de filtrage comprennent l'utilisateur appelant et/ou un type d'authentification et/ou une période d'application et/ou un niveau journalisation et/ou une alerte constituée par une action particulière associée à un événement particulier. 6. Procédé selon l'une des revendications 1 à 5, caractérisé en que l'étape description d'au moins une règle de contrôle d'accès comprend la définition d'une portée comportant au moins une zone cloisonnement. 7. Procédé selon l'une des revendications 1 à 6, caractérisé en que l'étape de description d'au moins une règle de contrôle d'accès comprend la définition d'au moins une restriction sur la commutation communications. 8. Procédé selon l'une des revendications 1 à 7, caractérisé ce que le procédé comprend, pour chaque règle de contrôle d'accès, une étape de création et de mémorisation d'un fichier correspondant à une règle à appliquer, le fichier comprenant au moins une identification d'un pare auquel s'applique la règle pour déterminer sur quels pare-feu doivent etre transféré le fichier de règles. 9. Procédé selon la revendication 8, caractérisé en ce que le procédé comprend une étape de transfert, puis de mémorisation de tous les fichiers de règles sur les pare-feu correspondant aux identifications contenues dans chaque fichier de règles. 1O.Procédé selon la revendication 9, caractérisé en ce le procédé comprend une étape d'envoi d'une information vers tous pare- feu pour provoquer, à un instant déterminé, l'application règles contenues dans le dernier fichier de règles reçu par le pare-feu. 11. Dispositif susceptible de mettre en #uvre le procédé selon l'une des revendications 1 à 10. 12.Dispositif de configuration de pare-feu (2) dans un système (3) informatique comprenant au moins une ressource, caractérisé en qu'il comprend une machine (5) de configuration centrale comportant: - une interface (8) graphique permettant de décrire le système et la politique contrôle d'accès aux ressources (7); - moteur (9) de compilation qui traduit les informations saisies au moyens de l'interface (8) en règles de contrôle d'accès; - un module de téléchargement et de synchronisation destiné à assurer le transfert des règles crées par le moteur (9) vers les pare-feu appropriés. 13.Dispositif selon la revendication 12, caractérisé en ce le module (10) communique à l'ensemble des pare-feu, l'instant auquel les fichiers de règles nouvellement transférés doivent être pris en compte et appliqués.