CA2221881C - Procede de securisation des acces d'une station a au moins un serveur et dispositif mettant en oeuvre le procede - Google Patents

Abstract

La présente invention concerne un procédé de sécurisation des accès à des serveurs et le dispositif mettant en oeuvre le procédé. Le procédé de sécurisation des accès à au moins un serveur (30) est caractérisé en ce qu'il permet de sécuriser les accès en provenance de stations (2) d'utilisateur et à destination d'au moins un serveur d'application à travers un réseau (42) utilisant un protocole de télécommunication multi sessions et multi ports, ledit procédé consiste en une étape: d'établissement systématique d'une session de sécurité en parallèle entre la station d'utilisateur (2) et un processeur de sécurité (1) interposé entre la station d'utilisateur à protéger pendant le déroulement des sessions d'applications et le ou les serveurs (30) à protéger et une étape de déclenchement cyclique de session de sécurité.

Description

#'ROCEDE DE SECtIRISATION DES ACCES D°UNE STATION A AO
SOINS tTN 8ERVE~R ET DISPOSITIF METTANT EN OEUVRE L8 PROCEDE
La prsente invention concerne un procd de scurisation des accs d'une station au moins un serveur et le dispositif mettant en oeuvre le procd.

I1 est connu dans les rseaux de communication entre serveurs et stations de chercher scuriser les communications surtout lorsque celles-ci mettent en jeu 1o des informations sensibles pour les applications excutes sur la station avec le concours du serveur.

Jusqu' prsent le principe de scurisation consistait rajouter entre l'application et les couches des protocoles de communication du rseau une partie de programme de scurisation. Cette couche de programme tait implante 1a fois sur le terminal et sur le serveur. L'inconvnient d'une telle mthode est quelle ncessite la modification des applications ou des couches de tlcommunication et une partie de programmation 2o ralisant l'interface entre le programme scuritaire proprement dit et l'application spcifique. Pour chaque application il est donc ncessaire de dvelopper une interface de programme spcifique. Par ailleurs chaque serveur dans la mesure o13 le terminal est connect sur un rseau multi serveur, doit tre scuris. Le temps de programmation ncessaire pour chaque application combin la ncessit de scuriser chaque serveur venait grever lourdement le budget ncessaire pour scuriser une application.

Le but de l'invention est de proposer un procd de scurisation qui ne ncessite aucune modification des programmes d'application excuts sur les terminaux et aucune modification des serveurs.

Ce but est atteint par le fait que le procd permet de scuriser les accs en provenance de stations WO 97/33415 _ PCT/FR97/00371

2 d'utilisateur â destination d'au moins un serveur d'application relié à travers un réseau utilisant un protocole de têlécommunication multi sessions et mufti ports, ledit procédé consiste en une étape .
d'établissement systématique d'une session de sécurité en parallèle entre la station d'utilisateur et un processeur de sécurité interposé entre la station d'utilisateur â protéger pendant le déroulement des sessions d'applications et le ou les serveurs à protéger et une étape de déclenchement cyclique de session de sécurité.
Selon une autre particularité l'étape d'établissement systématique d'une session de sécurité
comporte les étapes suivantes .
transmission par la station sur le réseau d°une adresse source IP et d°au moins un numéro de port associé
â l'application demandée par la station ; ' recherche par le processeur de sécurité du scénario sécuritaire associê à l'application ;
établissement de la session de sécurité entre le processeur de sécurité et la station ; recherche par le processeur sécuritaire dans un fichier local du processeur le nom et l'adresse du serveur distant utilisé
pour l'application et ouverture d'une connexion avec le serveur distant par communication d'une adresse IP et d'un numéro de port.
Selon une autre particularitê le scénario associé a une application consiste à établir directement la liaison entre la station et le serveur distant choisi par le processeur de sécurité.
Selon une autre particularité le scênario de sécurité à mettre en oeuvre et défini dans une table mémorisée permet au choix une ou plusieurs des fonctions ci-après d'authentification de l'utilisateur, d'identification, de contrôle de ses droits, de certification, de calcul de clés de chiffrement, de WO 97/33415 _ PCTlFR97/00371

3 calculs de signature, de vérifications de profils de ' l'utilisateur pour donner un accs slectif des applications demandes sur le serveur.

' Selon une autre particularit le processeur de scurit mmorise un journal dans une mmoire de masse, comportant un numro squentiel de connexion, les dates et heures de dbut et fin de connexion, l'adresse IP

source et au moins un numro de port, l'identifiant de l'objet de scurit utilis, le nom du serveur distant 1o choisi, l'adresse IP de destination et le numro de port, les statuts d'excution.

Selon une autre particularit le processeur de scurit mmorise dans une seconde table d'une mmoire la liste des applications traites par le processeur, les traitements effectuer en fonction du type de la connexion, les scnarios de scurit mettre en oeuvre, les droits d' accs des utilisateurs par dfinition d' une liste noire, blanche et une liste d'abonns les , calendriers d'autorisation d'accs aux serveurs distants.

Un autre but de l'invention est de proposer un dispositif permettant la mise en oeuvre du procd.

Ce but est atteint par le fait que le dispositif permet la mise en oeuvre du procd entre, d'une part un terminal sur lequel est install un logiciel de scurit grant les changes avec la carte et un lecteur de carte associ au terminal ainsi que les changes avec un protocole de communication multi sessions et multi ports et d'autre part un processeur de scurit caractris en ce que le processeur de scurit comporte des moyens 3o d'tablir et de contrler les communications entre la station et un serveur choisi par le processeur en fonction de l'application demande par la station.

' selon une autre particularit les moyens d'tablir et de contrler les communications permettent soit d'instaurer une communication directe entre le terminal et le serveur, soit d'instaurer une communication entre WO 9?/33415 _ PCT/FR9?10037I

4 le terminal et le serveur après établissement d'une session de sécurité contrSlée par un dispositif sécuritaire comportant un microprocesseur équipé de mémoires nécessaires â son fonctionnement et communiquant avec des modules de contr8le de sécurité MCS permettant d'interprêter les scénarios sécuritaires décidé par un processeur principal exêcutant les programmes de serveur de communication et de moteur de sécurité.
Selon une autre particularité les moyens d'établir les communications sont constituées par deux cartes réseau local telles que, par exemple, Ethernet, anneau â
jeton (tolten ring), l'une reliée â la station, l'autre reliêe au serveur et communiquant avec la station et le serveur selon le protocole de communication mufti sessions mufti port.
D'autres particularitës et avantages de la présente invention apparaîtront plus clairement â la lecture de la description ci-aprés faite en référence aux dessins annexés dans lesquels .
la figure 1 représente une vue du schéma de principe du dispositif permettant la mise en oeuvre du procédé de sécurisation ;
la f figure 2A représente la boite de dialogue gérée par le logiciel de sécurité du terminal ;
la figure 2B représente une autre boite de dialogue signalant l'absence de lecteur ou de carte ;
la figure 2 C représente une autre boite de dialogue demandant le code porteur ;
la figure 2D reprësente une autre boite de dialogue permettant le choix du serveur destinataire ;
la figure 2E représente une autre boite de dialogue permettant une saisie d'une chafne de caractères ;
ïa figure 2F représente la fenêtre principale.
L'invention va maintenant âtre dêcrite en liaison avec les figures 1 et 2. L'invention s'implante sur un réseau constituê de terminaux (2) communiquant à travers

5 PCT/FR97/00371 un réseau constitué par des liaisons (42, 40, 41), avec un ou plusieurs serveurs (30, 31). Les terminaux peuvent tre soit connects localement sur le rseau du serveur ou peuvent tre des micro-ordinateurs portables mobiles 5 se connectant travers des rseaux de tlcommunication de tout type, rseau connect, GSM, RNIS. Sur un tel rseau fonctionnent des applications, telles qu'une application de service terminal distance, par exemple, de type Telnet ou des services de transfert de fichiers tels que, par exemple, FTP ou des protocoles utiliss par INTERNET tel que HTTP ou encore tout autre application connue actuellement. Le rseau est constitu de cartes rseau local par exemple de type Ethernet (23) sur l'ordinateur du terminal fonctionnant avec un protocole 1s de tlcommunication 24 du type multi sessions et multi ports tel que par exemple le protocole TCP/IP. Chaque serveur (30, 31) comporte galement une carte Ethernet (302, 312) et un protocole TCP/IP associ (301, 311).

Pour scuriser le rseau il suffit d' interposer, dans le cas oi3 le rseau comporte plusieurs serveurs, au noeud de jonction des serveurs situ dans la mme enceinte que les serveurs un processeur de scurit (1) qui dialogue avec un ou plusieurs terminaux (2) du rseau. Chacun des terminaux (2) est quip d'une application de scurit constitue d'un logiciel (27) et d'une liaison physique (20) avec un lecteur (21) d'objets portables (22). Ces objets portables (22) peuvent tre du type carte puce ou carte PC/MCTA.

Le processeur de scurit (1) est constitu d'une unit de traitement (14) comprenant une carte ' lectronique type PC (Personal Computer) avec les mmoires correspondantes et communique par un bus (11) ' avec une premire carte rseau type Ethernet (13) relie chacun des serveurs (30, 31) par une liaison respective (40, 41) et avec une deuxime carte rseau de type Ethernet (12) relie au terminal par une liaison (42). Le

6 bus (11) communique également avec une carte d'application sêcuritaire (15) qui comporte une unité de traitement, des mémoires non représentée, et des modules MCS (S.A.M Security Application Module) de contr8le de sécurité (151, 152). L'installation peut comporter n cartes comprenant chacune n modules de contr8le de sécurité MCS (151, 152). Ces modules MCS (151, 152) permettent de réaliser, en liaison avec le lecteur (21) et l'objet portable, des fonctions de sécurité telles que l'authentification, la certification, le calcul de clé de chiffrement, etc..., tout en assurant l'inviolabilité des clés sacrâtes de base. Ces fonctions de sécurité mettent en oeuvre également les informations contenues dans la carte à puce ou l'objet portable (22) relié par 1e lecteur (21) â l'application de sécurité (27) du terminal (2). L'unité de traitement (14) fonctionne avec un système d'exploitation (173) multitâches, par exemple, de type OS2 pour permettre au processeur sécuritaire (1) d'exécuter plusieurs tâches en parallèle. Chaque carte Ethernet (12, 13) comporte sa couche logiciel permettant de mettre en oeuvre le protocole de télécommunication propre au réseau, tel que le protocole TCP/IP (131, 121).
En plus du systême d'exploitation l'unité de traitement (14) fonctionne avec un serveur de communication (172) qui comporte une couche (1721) permettant le traitement des communications entre la première (13) et la deuxiëme (12) carte selon le protocole du réseau de type TCP/IP.
Ce serveur de communication (172) a pour rSle de déterminer si la liaison entre la deuxiéme carte Ethernet ( 12 ) et la première carte ( 13 ) reliée au serveur doit se faire en direct ou si cette liaison ne peut se faire qu'après mise en oeuvre d'une procédure sécuritaire.
Cette détermination s'effectue par la lecture d'un fichier APPLI.INI mémorisé dans une mémoire (16) et comportant une table de correspondance entre l'application et au moins le scénario sécuritaire â

7 mettre en oeuvre. Dans le cas de la mise en oeuvre ce ' serveur de communication fait appel un moteur de scurit (171) qui dclenchera le fonctionnement de la ' carte d'application scuritaire (15) du processeur de scurit (1) permettant de mettre en oeuvre les fonctions de scurit. Le moteur de scurit MS permet de configurer le rseau scuritaire, de dfinir ia liste des applications traites par le processeur de scurit, de dfinir les traitements effectus, de dfinir les scnarios de scurit mettre oeuvre, de dfinir les droits d'accs des utilisateurs et les calendriers d'autorisation. L'application de scurit (27) mise en place sur le terminal fonctionne galement avec un systme d'exploitation du type affichage fentre tel que le logiciel Windows (marque dpose). Une fois le chargement du logiciel de scurit (27) effectu sur la station, ce dernier permet l'utilisateur du terminal, par l'affichage d'une fentre principale (figure 2F) affiche aprs le lancement de l'application scuritaire, soit l'activation de la connexion de scurit soit la dsactivation de la connexion de scurit ou encore de sortir de l'application. Comme reprsent la figure 2F, la slection d'une des trois fonctions disponibles s'effectue en amenant la surbrillance sur la fonction souhaite puis en validant par un "clic" souris ou par l'action de la touche "entre" du clavier. L'utilisateur se connecte sur le rseau scuris en spcifiant l'adresse IP du processeur scuritaire (1) et le numro de port affect l'application qu'il veut utiliser (par exemple, X pour l'application scuritaire, 21 pour ' l'application FTP, 23 pour Telnet, etc...). Le processeur de scurit (1) recherche dans une table le scnario de ' scurit associ au numro de port envoy par la station et tablit ensuite une communication avec l'application 3s scuritaire (27) pour mettre en oeuvre le scnario scuritaire avec notamment authentification de l'objet

8 portable utilisateur (22) et identification de l'utilisateur par son code porteur de carte (P.I.N.). De ' façon optionnelle le processeur de sécurité (1) peut faire afficher sur la station la liste d'applications, celles utilisées par l'utilisateur définies par les listes blanches et par ïes listes noires pour celles interdites. L'utilisateur effectue ensuite par des actions sur le clavier ou la souris ia sélection d'un couple serveur appïication. Dés que le scënario l0 sécuritaire s'est déroulé normalement et l'utilisateur lance l'application choisie (Telnet, FTP, IiTTP, ...) en validant la sélection. Le processeur de sécurité (1) reçoit du terminal (2) un numéro de port correspondant à
l'application, détermine dans ses tables l'adresse IP du serveur d'application et établis la connexion vers le serveur d'application demandé. Une fois la connexion établie entre le terminal (2) et un des serveurs (30, 31), le processeur de sécurité supervise les sessions applicatives établies en effectuant des contr8les securitaires cycliques vers le terminal (2). En cas d'anomalie sêcuritaire détectée (telle que, retrait de carte, inactivité, mauvais calcul de signature,...), le processeur de sêcuritë (1) interrompt les connexions vers le serveur distant et rompt la session de sécurité.
Plusieurs scénarios de sécurité peuvent être mis en oeuvre et le choix du scénario activë se fait en fonction du numéro de port de l'application indiqué dans les , données de connexion. Ces informations de numéro de port et de scénario associé sont dans un fichier ACCUEIL.CAM
qui constitue une partie d'une table (161) de la mémoire de masse (16) du processeur de sécurité (1). L'activation d'une connexion sécuritaire met en oeuvre un scénario ' d'accueil qui permet de réaliser n'importe quel traitement parmi un ou plusieurs des traitements suivants . l'affichage et la saisie de données ; le contrSle des adresses IP source et destination ; le contrôle d'accês WO 97/33415 _ PCTlFR97/00371

9 par mot de passe ; le contr8le d'accs par carte ' microprocesseur permettant la mise en oeuvre de l'identification du porteur, de l'authentification ' partir d'un module scurit MCS, d'un chiffrement, d'une s signature, d'un calcul de certificat, d'une lecture et criture d'informations, d'un contr&le d'arrachage de cartes, la vrification du droit d'accs de l'utilisateur au serveur distant dans les listes noires, blanches, listes d'abonns. Ces droits d'accs et ces listes l0 constituant une partie de la table T (161) ; le contr8le des droits d'utilisation des diffrents services du protocole de tlcommunication TCP/IP ; la vrification de la plage horaire et calendaire autorise pour l'utilisateur ou poux l'accs de la machine choisie, 15 cette plage horaire et caiendaire autorise faisant l'objet d'une table comportant d'une part, en colonne les plages horaires et, en lignes i'identit des utilisateurs ou machines. Enfin l'affichage d'un menu personnais permet le choix d'une des applications ou serveurs 2o distants autoriss pour l'utilisateur. Le fichier APPLI.INI permet de mmoriser dans la mmoire (16), d'identifier en fonction de l'application le scnario de scurisation activer ainsi que la priode d'activation , ce qui permet selon le scnario et la priode 25 d'activation choisie de dclencher cycliquement l'activation d'un scnario en fonction de l'application du serveur distant choisi. Le scnario priodique vrifie que l'utilisateur distant est bien celui habilit en demandant la carte du terminal d'effectuer des 3o signatures lectroniques d'informations (nombre alatoire) choisies par le scnario. Le scnario ayant charge de vrifier l'aide du MCS que ces signatures ont t produites par une carte disposant des cls secrtes adquates. Ce procd permet de se prmunir notamment 35 contre le vol d'adresses IP provenant d'un dispositif intrus sur le rseau. Lorsque l'utilisateur a choisi le WO 97/33415 PCT/FR971~d1371 i0 serveur distant et l'application, le processeur de sécurité récupère le numéro de port de l'application et ' utilise un fichier local, pour ouvrir une connexion avec le serveur distant choisi par le processeur sëcuritaire. ' Ce serveur choisi par le processeur sécuritaire peut étre différent de celui indiqué par l'utilisateur.
L'utilisateur recevra simplement les communications â
travers le processeur de sécurité. Ces communications sont adressées à la station (2) grâce â son numéro de i0 port. Enfin le processeur de sécurité permet grâce au moteur de sécurité (171) de tenir dans la mémoire de masse (16) un journal (162) des connexions qui mémorise un numêro séquentiel de connexion, les dates et heures de début et fin de connexion, l'adresse IP source et le numéro de port, l'identifiant de l'objet de sécurité
utilisé, le nom du serveur distant choisit, l'adresse IP
de destination, le numëro de port, le volume de donnêes échangêes entre la station et le serveur lors de la session applicative, ie statut d'exécution. L'application de sécurité (27) comporte un module de présentation (271) qui permet d'utiliser le système d'affichage à fenëtre et boite de dialogue du système d'exploitation Windows pour permettre par l'affichage d'une premiëre boite de dialogue (figure 2A) de demander à l'utilisateur la saisie d'un mot de passe puis ensuite la validation de ce mot ou l'abandon de l'opération qui entrafne la désactivation de la connexion de sécurité. L'interface utilisateur permet également d'afficher une deuxième boite de dialogue (figure 2B) indiquant les messages "carte absente du lecteur" et "veuillez insérer votre carte SVP" ainsi qu'une troisième boite de dialogue (figure 2C) permettant de saisir le code du porteur de la carte avec des boutons de validation ou d'annulation de la procêdure. Enfin une quatrième boite de dialogue permet de sélectionner le serveur destinataire en permettant la sélection parmi une liste déroulante des WO 97/33415 _ PCT/FR97/0037I

serveurs possibles du rseau. Deux autres boites de ' dialogue permettent, l'une l'affichage de messages reus du processeur scuritaire puis une autre boite (figure ' 2E) permet la demande de saisie d'une chagne de caractres. On comprend que l'on a ainsi scuris les accs et permis de slectionner les conditions des procdures d'accs au choix de la personne charge de la scurit, de plus la priodicit des connexions scuritaires permet d'viter qu'un fraudeur se connecte un moment donn en faisant semblant de se substituer au terminal connect au rseau car s'il ne possde pas les cls d'accs au terminal, les procdures scuritaires ne l' identifient pas et interdisent la session. Enfin cette solution prsente l'avantage de rester transparente par 1s rapport au protocole des applications circulant sur la connexion. En effet l'installation du systme scuritaire se fait sans modification des applications sur les terminaux et encore moins sur les serveurs.

Lors de l'installation du logiciel scuritaire (27) et du processeur de scurit (1), l'installateur dfinit dans un fichier d'initialisation (SERVEUR.INI) un dlai de scurit qui permet au processeur (1) de fermer la . connexion de scurit tablie avec un poste client s'il n'y a pas de connexion applicative depuis le dlai dtermin et un dlai d'inactivit qui permet au processeur de fermer la connexion de scurit et Ies connexions applicatives tablies avec un poste client s'il n'y a pas de donnes changes sur les connexions applicatives depuis le dlai dtermin.

D'autres modifications la porte de l'homme de mtier font galement partie de l'esprit de l'invention.

Claims (9)

REVENDICATIONS

1. Procédé de sécurisation d'accès à au moins un serveur d'applications permettant de sécuriser des accès en provenance de stations d'utilisateur et à destination d'au moins un serveur d'applications à travers un réseau utilisant un protocole de télécommunication multi-sessions et multi-ports, au moyen d'un processeur de sécurité
interposé entre les stations d'utilisateur à protéger pendant un déroulement de sessions d'application et le au moins un serveur d'applications à protéger, caractérisé en ce qu'il comporte les étapes suivantes :
établissement systématique d'une session de sécurité
en parallèle pendant le déroulement des sessions d'application entre, d'une part, une des stations d'utilisateur et, d'autre part, le processeur de sécurité, le processeur de sécurité choisissant le au moins un serveur d'applications en fonction d'une application demandée par la station d'utilisateurs et déclenchement par le processeur de sécurité de contrôles sécuritaires cycliques avec la station d'utilisateur.

2. Le procédé de sécurisation des accès à au moins un serveur selon la revendication 1, caractérisé en ce que ladite étape d'établissement systématique d'une session de sécurité comporte les étapes suivantés :
transmission par la station d'utilisateur sur le réseau d'une adresse source IP et d'au moins un numéro de port associé à l'application demandée par la station d'utilisateur;
recherche par le processeur de sécurité d'un scénario sécuritaire associé à l'application;

établissement de la session de sécurité entre le processeur de sécurité et la station de l'utilisateur;
recherche par le processeur de sécurité dans un fichier local du processeur de sécurité d'un nom et d'une adresse du serveur d'applications utilisé pour l'application; et ouverture d'une connexion avec le serveur d'applications par communication de l'adresse IP et du numéro de port.

3. Le procédé de sécurisation des accès à au moins un serveur selon la revendication 2, caractérisé en ce que le scénario sécuritaire consiste à établir directement une liaison entre la station et le serveur d'applications choisi par le processeur de sécurité.

4. Le procédé de sécurisation des accès à au moins un serveur d'applications selon 1a revendication 2, caractérisé en ce que le scénario sécuritaire à mettre en oeuvre est défini dans une table mémorisée et permet au choix au moins une fonction d'authentification de l'utilisateur, d'identification de l'utilisateur, de contrôle de droits de l'utilisateur, de certification, de calculs de clés de chiffrement, de calculs de signatures et de vérifications de profils de l'utilisateur pour donner un accès sélectif à des applications demandées sur le serveur d'applications.

5. Le procédé de sécurisation des accès à au moins un serveur d'applications selon la revendication 2, caractérisé en ce que le processeur de sécurité mémorise un journal dans une mémoire comportant un numéro séquentiel de connexion, des dates et des heures de début et de fin de connexion, une adresse IP source et au moins un numéro de port, un identifiant d'un objet de sécurité
utilisé, un nom du serveur distant choisi, une adresse IP
de destination et un numéro de port, et des statuts d'exécution.

6. Le procédé de sécurisation des accès à au moins un serveur d'applications selon l'une quelconque des revendications 1 à 5, caractérisé en ce que le processeur de sécurité mémorise dans une table d'exploitation d'une mémoire une liste d'applications traitées par le processeur, des traitements à effectuer en fonction d'un type de connexion, des scénarios sécuritaires à mettre en oeuvre, des droits d'accès d'utilisateurs par définition et une d'une liste d'applications et d'une liste de serveurs d'applications que la station d'utilisateur est autorisée à utiliser, d'une liste d'applications et d'une liste de serveurs d'applications que la station d'utilisateur n'est pas autorisée à utiliser, et une liste d'abonnés, des calendriers d'autorisation d'accès aux serveurs d'applications.

7. Dispositif comprenant un processeur de sécurité pour sécuriser des accès en provenance d'une station d'utilisateur et à destination d'au moins un serveur d'applications à travers un réseau utilisant un protocole de télécommunication multi-sessions et multi-ports, un logiciel de sécurité étant installé sur la station d'utilisateur pour gérer des échanges avec un objet portable et un lecteur d'objet portable associé à la station d'utilisateur ainsi que des échanges avec un protocole de communication multi-sessions et multi-ports, caractérisé en ce que ledit processeur de sécurité

comporte des moyens d'établir des communications entre ladite station d'utilisateur et au moins un serveur d'applications choisi par ledit processeur en fonction d'une application demandée par ladite station d'utilisateur, ledit processeur de sécurité comportant également des moyens de contrôler les communications et d'établir systématiquement une session de sécurité avec ladite station d'utilisateur en parallèle aux sessions d'applications et des moyens de déclencher des contrôles sécuritaires cycliques.

8. Le dispositif selon la revendication 7, caractérisé
en ce que lesdits moyens d'établir et de contrôler les communications entre la station d'utilisateur et au moins un serveur d'applications permettent l'un de : instaurer une communication directe entre la station d'utilisateur et le serveur, et : instaurer une communication entre la station d'utilisateur et le serveur d'applications après établissement d'une session de sécurité contrôlée par une carte d'applications sécuritaire comportant un microprocesseur équipé de mémoires et communiquant avec des modules de contrôle de sécurité permettant d'interpréter des scénarios sécuritaires décidés par un processeur principal exécutant des programmes d'un serveur de communication et d'un moteur de sécurité.

9. Le dispositif selon l'une quelconque des revendications 7 et 8, caractérisé en ce que les moyens d'établir les communications comprennent deux cartes de télécommunication, une première étant reliée à la station d'utilisateur, une seconde étant reliée au serveur d'applications et communiquant avec la station d'utilisateur et le serveur d'applications selon le protocole de communication multi-sessions multi-ports.