Brevet FR2912583A1 — publié le 20080815

ACCES SECURISE A UN RESEAU A PARTIR D'UN AUTRE RESEAU Dans des installations d'entreprises, des réseaux d'ordinateurs peuvent être divisés en des sections distinctes multiples, par exemple un "Réseau Général" qui s'étend sur toute l'entreprise dans de nombreuses zones et un "Réseau de Gestion" qui est réservé principalement pour la gestion et l'administration et dessert des ordinateurs personnels dans des bureaux d'administration. Seul du personnel d'administration ou de gestion gradé a généralement l'autorisation d'avoir accès à ces ordinateurs. Il serait avantageux de manière significative pour du personnel non gradé au niveau du site d'avoir accès au réseau d'administration pour obtenir un domaine sélectif spécifiquement limité de données. Le personnel serait capable d'enregistrer directement des données qui sont critiques du point de vue du temps et d'envoyer des données en ligne, et de recevoir et d'envoyer des e- mails/messages. Il pourrait faire cela en utilisant les ordinateurs personnels (PC) ou des ordinateurs portables au niveau de l'entreprise qui sont connectés aux réseaux généraux Wi-Fi sans fil ou Ethernet. Les écoles et les collèges sont des exemples 25 spécifiques d'entreprises de ce genre qui ont besoin d'un accès sécurisé d'un réseau à un autre. Dans le cas d'une école, ces deux réseaux comportent généralement un "réseau de programme d'étude" qui s'étend vers les salles de classe dans toute l'école 30 et un "réseau d'administration" qui est réservé principalement pour l'administration et dessert des ordinateurs personnels (PC) dans des bureaux de l'école. De nouveau, il serait très utile pour des enseignants dans les salles de classe dans l'école d'avoir accès au réseau d'administration pour obtenir des données sur les étudiants, qu'il s'agisse de données relatives à la présence, des notes, du comportement ou des détails de contact, etc. Des enseignants seraient capables d'enregistrer directement des absences/présences, récupérer et envoyer des notes en ligne et des données de comportement, et recevoir et envoyer des e- mails/messages. Ils pourraient faire cela en utilisant les PC ou les ordinateurs portables dans la salle de classe, qui sont: connectés aux réseaux Wi-Fi sans fil ou Ethernet de programme d'étude. Un procédé de ce genre pour traiter des données d'étudiants est non seulement utile d'un point de vue économique, mais également très intéressant d'un point de vue fonctionnel. Cependant, de nombreuses autorités locales/administrations scolaires et d'écoles ne permettent pas cela car il y a une inquiétude que le système d'administration ou de gestion soit particulièrement vulnérable à des accès non autorisés et à des violations par des étudiants ou par quelqu'un d'autre. Dans un établissement d'éducation, la pénétration par effraction dans le réseau d'administration dans des buts malhonnêtes serait vraisemblablement la plus grande inquiétude. La source du risque est le fait que les logiciels actuels d'administration des écoles nécessitent que, sur le serveur d'administration, de nombreux services (et ports) soient laissés ouverts, en incluant, par exemple, le serveur de base de données ou même des services d'annuaire de réseau. Classiquement, pour que des ordinateurs portatifs ou des PC sur le réseau de programme d'étude soient capables d'envoyer des données et d'avoir accès à des données sur le réseau d'administration, tous les ports de ce genre doivent être ouverts entre les deux réseaux. Cela à son tour laisse les données d'administration dans une position de vulnérabilité totale, et c'est pourquoi il existe une règle suivant laquelle de nombreuses écoles conservent les réseaux de programme d'étude et d'administration isolés l'un de l'autre. La présente invention a pour objectif, par conséquent, de fournir l'installation qui permettra à des ordinateurs portables et à des PC sur le réseau de programme d'étude d'être utilisés par des enseignants pour la récupération d'un large domaine de données sur les élèves d'un point de vue administratif, sans compromettre l'intégrité ou la sécurité. Par conséquent, la présente invention vise un système de réseau d'ordinateur sécurisé pour des établissements d'éducation, comportant un premier réseau pour des données d'éducation ("réseau de programme d'étude") et un deuxième réseau distinct pour l'administration et d'autres données confidentielles ("réseau d'administration"), les deux réseaux étant connectés par un pare-feu comportant une protection NAT et également un système d'inspection de paquets sensible au contexte, qui fait passer uniquement des paquets de contenu déterminé à l'avance. Il est par conséquent capable de fournir une solution sûre, fiable et résistant à la violation pour donner accès aux enseignants à des données dans la salle de classe. Cette solution n'utilise ni des ports 13xx ni des ports 80, par exemple, et en aucun cas ne permet que soient effectuées des demandes directes dans la base de données MIS de l'école. A cette fin, la présente invention prévoit que la liaison entre le réseau de programme d'étude et le serveur de classe (avec un nom d'identification unique) ou un autre serveur de réseau d'administration se fait par l'intermédiaire d'un pare-feu/routeur restreint de manière élevée. Ce filtre de sécurité est placé entre les deux réseaux et bloque tout accès autre que des appels de service très spécifiques du logiciel de client du serveur de classe qui fonctionne sur le PC/ordinateur portable (laptop) de programme d'étude vers le serveur d'administration. Avec cette technique, il est possible d'obtenir une sécurité inhérente à l'encontre de violations dans le réseau d'administration, tout en déployant des protocoles de mise en réseau standard dans l'industrie, supportés par tous les réseaux. Un mode de réalisation de l'invention va maintenant être décrit en référence aux dessins annexés dans lesquels la Figure 1 est une représentation schématique d'un réseau d'école et la Figure 2 est une illustration sous la forme d'un diagramme d'une transaction DPM (DPM pour Data Processing Module ou module de traitement de données). En se référant à la Figure 1, il est illustré un réseau d'école comportant une première section (2) qui comporte un "réseau d'administration" et une deuxième section (4) distincte comprenant un "réseau de programme d'étude". La première section (2) achemine des données sensibles qui sont disponibles uniquement à des utilisateurs "administratifs", par exemple le PC (6), et sont mémorisées sur un serveur (8) d'administration. Un "serveur de classe" (10) est également connecté au même réseau et est utilisé pour des requêtes de service provenant du côté du "réseau de programme d'étude" du système d'une manière qui va être décrite ci-dessous. La deuxième section (4) comporte un "serveur de programme d'étude" (12) pour des données qui sont purement d'éducation (telles qu'opposées à administratives) et servent directement les PC (14) de client sur un réseau câblé, par exemple dans les salles de classe, ainsi que des points (18) d'accès sans fil pour des ordinateurs portatifs, tels que des laptops (16). Les deux sections sont interconnectées par un pare-feu/routeur (20) qui permet uniquement à des "clients enseignants" de communiquer avec le serveur (10) de classe en utilisant un protocole privé ; aucun autre équipement ou interface standard ne sont visibles. Les transactions échangées entre l'application du client enseignant et le serveur de classe peuvent être, en outre, cryptées si on pense qu'il est nécessaire d'ajouter une autre couche de protection. Le pare-feu/routeur fourni comporte toutes les options et est à base de règles, fournissant une protection bien plus élevée que la transposition d'adresse de réseau de base (NAT). De cette manière, le pare-feu/routeur (20) fournit une liaison restreinte entre les deux segments LAN, dans ce cas les réseaux d'administration (2) et de programme d'étude (4). Le pare-feu est configuré pour permettre uniquement que des requêtes de clients d'enseignants (sur un port spécifique) soient transmises au serveur de classe et ainsi il permet uniquement un trafic de clients enseignants entre les réseaux. Avantages . • L'adresse IP de destination est cachée du réseau de programme d'étude. Des détails du réseau d'administration ne peuvent pas être déterminés par des utilisateurs sur le réseau de programme d'étude même si le 10 15 20 25 30 trafic est intercepté. Ceci est l'extension normale de la protection NAT mais le pare-feu évolué fournit également une inspection de paquets sensible au contexte, empêchant des paquets d'usurpation de passer. • La seule route dans le réseau d'administration allant du réseau de programme d'étude est par l'intermédiaire d'un port spécifique, qui est uniquement utilisé par l'application du client enseignant. Ce n'est pas un port qui sera utilisé par les services de système d'exploitation standard, tel qu'un serveur de web, ou un RDBMS, tel qu'un serveur SQL Microsoft, IBM DB2 ou Oracle, par exemple. • Seul l'administrateur, en utilisant un câble série connecté physiquement à un port série du dispositif pare-feu/routeur, peut changer la configuration. Il ne peut pas être violé à partir d'un autre réseau. • Seul le serveur (10) de classe peut être accédé. Même des clients enseignants sont empêchés de communiquer avec un autre équipement sur le côté protégé du réseau (2) • Le serveur (10) de classe et les applications de clients répondent uniquement à leur propre type de transaction défini à l'avance, non générique, et ne fournissent pas une route vers des données à l'extérieur de ce mécanisme. • Si on le souhaite, le routeur peut également être configuré pour permettre un accès au réseau de programme d'étude à partir d'un PC de client sur le réseau d'administration. Un protocole extrêmement efficace envoie uniquement les données qui sont nécessitées, mettant en paquet les données en un paquet et les envoyant en une transmission, en le faisant très vite et en conservant le trafic réseau à un minimum. Pour un transfert de données comparable, le trafic de données total peut être réduit par un facteur 100. La description qui suit décrit la mise en œuvre à l'échelle de cette solution. Le logiciel qui fonctionne sur le serveur de classe est appelé le module de traitement de données (DPM). DPM est désigné comme étant "proxy" (ou 15 mandataire) de la base de données et isole la base de données des utilisateurs. Le DPM reçoit des requêtes entrantes et les met en mémoire tampon pour les traiter de manière plus efficace. La mise en tampon des requêtes diminue également le nombre de connexions ouvertes dans 20 le serveur de classe. Le DPM fournit des services d'accès aux données pour des logiciels de "Client enseignant" qui fonctionnent sur des PC et des laptops. La communication entre le client enseignant et le DPM est fondée sur un ensemble défini à l'avance de transactions. Ces 25 transactions sont des instructions de très haut niveau et sont entièrement indépendantes de l'environnement de logiciel et de matériel. Ceci est opposé au logiciel de serveur de réseau tel que Novell ou le serveur Microsoft 2005 ou des 30 serveurs SQL, par exemple Microsoft SQL 2005. Dans ces systèmes, l'accès aux données nécessite des noms de postes de disque dur et des noms de fichiers et des enregistrements d'index et analogues. Le DPM est un service Windows qui reçoit des 10 requêtes de transaction des clients enseignants. Les seules autres communications du DPM sont avec des bases de données de serveur SQL et il exécute des procédures mémorisées dans ces serveurs SQL afin d'extraire les données qui sont nécessitées. Comme illustré à la Figure 2, des requêtes de transaction de DPM produites par un client (22) enseignant arrivent à un serveur de classe avec un ensemble de paramètres d'entrée. Le DPM (24) dessert ces requête en référence à la base de données (26) et renvoie une sortie qui est reçue par le client (22) enseignant d'origine. Des exemples du type de requêtes de transaction qui sont permises sont listés ci-dessous. 1. Requête de configuration de site 2. Le dossier requiert une configuration de client enseignant 3. Envoie une page de configuration de dossier (au client enseignant) 4. Transmet des données au client enseignant (vers le RTU) 5. Demande de registre 6. Envoie la liste de classes au client enseignant 7. Sauvegarder les présences 8. Transactions ayant fait défaut 9. Formes virtuelles (pour des requêtes de feuilles EGB et EMB) 10. Sous-type de formes virtuelles, envoie des 30 descriptions de feuilles 11. Sous-type de formes virtuelles, envoie des données de groupe à f avec un bloc de données comprimées 12. Sous-type de formes virtuelles, envoie des 5 10 15 20 2530 données de groupe vers f avec un bloc de données non comprimées 13. Sous-type de formes virtuelles, message d'erreur 14. Requête de mise à jour de boîte email 15. Le client enseignant envoie un message 16. Requête de formes virtuelles 17. Requête de formes virtuelles 18. Requête de pager 19. Accusé de réception de message de pager 20. Envoie groupe d'exercice au client enseignant 21. Le client enseignant passe en mode pager 22. Le client enseignant demande son message pager 23. Requête de bouton panique 24. Le client enseignant demande le groupe exercice 25. Alarme de surveillance 26. Envoie page navigateur au client enseignant 27. Client enseignant demande page navigateur 28. Client enseignant demande une transaction à but général 29. Envoie au client enseignant une transaction à but général 30. Envoie au client enseignant un accusé de réception 31. Nouvelle instruction d'enveloppe pour le client enseignant (v3) • Transaction de piste de vérification de client enseignant 1. Le client enseignant envoie sa piste de vérification 2. Le client enseignant envoie registre (pour FE) • Transactions étendues à but général 1. Le client enseignant "X" demande une transaction à 2. Le client date/l'heure 3. Le DPM envoie 4. Le client but général étendue enseignant demande la la date/l'heure enseignant demande des 10 15 20 25 détails de directeur d'étude 5. Le DPM envoie des détails de directeur d'étude 6. Le client enseignant demande des détails de directeur d'étude 7. Le DPM envoie des détails de directeur d'étude 8. Le client enseignant demande des détails de directeur d'étude 9. Le DPM envoie des détails de directeur d'étude 10. Le client enseignant demande des détails de directeur d'étude 11. Le DPM envoie des détails de directeur d'étude 12. Le client enseignant demande une photo d'étudiant 13. Le DPM envoie une photo d'étudiant En utilisation, chaque transaction sera identifiée par un numéro de code déterminé à l'avance en même temps qu'un ou plusieurs paramètres d'entrée, tels 30 qu'un identifiant spécifique de classe. Dans le cas spécifique d'un établissement d'éducation, le système fonctionne comme suit : Surveillance fonctionnelle du client enseignant - serveur de classe : 5 15 20 25 30 A. L'interaction centrale du client enseignant et du serveur de classe se fait par l'intermédiaire d'un téléchargement et de chargement de la "liste d'étudiants" avec des données d'étudiants. Le type de données d'étudiants qui accompagne la transaction est fonction du type de transaction et peut être la présence, les notes, le comportement ou une combinaison de ceux-ci. Des listes d'étudiants discrètes sont préparées par le serveur de classe et téléchargées et chargées entre le serveur de classe et le PC/laptop de client enseignant. Le PC/laptop du client enseignant sait comment interpréter le "paquet de serveur de classe" conformément à un format de données déterminé à l'avance. B. Un protocole à niveau élevé est utilisé pour desservir les transactions et les paquets de données de serveur de classe sont noyés à l'intérieur des paquets TCP/IP. C. Le logiciel de serveur de classe fait fonctionner le DPM et est étendu pour recevoir et envoyer des paquets de données de serveur de classe par l'intermédiaire du créneau TCP/IP. Pour plus d'efficacité et de rendement, le DPM met en tampon des requêtes en tant que tâche prioritaire. Le PC/laptop du client enseignant ne voit pas la base de données sur le serveur de classe et, par conséquent, des clients enseignants ne se connectent pas à la base de données de quelque manière que ce soit et ils ont accès uniquement à des paquets de données de 10 15 20 25 30 serveur de classe. Le DPM est vraiment un "proxy de base de données". D. Le PC/laptop du client enseignant n'a pas à être connecté en permanence à la base de données du serveur ou au réseau pour être fiable d'une manière classique, c'est-à-dire 100 % en ligne. Ceci est très différent des systèmes client serveur classiques et est significativement avantageux du point de vue de l'utilisation de largeur de bande/réseau. Dans des systèmes de serveur de client classiques, une application de client conserve un tampon temporel pour chaque écriture de base de données qui est transmise vers le serveur central et est également tamponnée temporellement dans les fichiers de données locaux, ce qui permet d'identifier les données à interchanger entre le client et le serveur facilement, avec de simples états SQL. D'autre part, l'application de l'invention (client serveur - serveur de classe) utilise des calculs de vérification de somme pour filtrer des quantités de données à interchanger entre le client enseignant et le DPM. De nouveau, la technique précédente, bien qu'elle soit facile à mettre en oeuvre, simple à maintenir, nécessite de mémoriser et transmettre des tampons temporels pour chaque enregistrement de données individuel ; tandis que le client enseignant est optimisé pour consommer la largeur de bande minimum. En raison de la petite dimension d'empreinte du programme et des faibles exigences de largeur de bande, le logiciel "client enseignant" permet à un PC, même à un modèle ancien à faible spécification ayant des faibles vitesses de réseau, de devenir un client, fonctionnant de la même manière, de manière remarquable, avec des vitesses très satisfaisantes. La manière suivant laquelle le système "client enseignant" fonctionne est maintenant décrite plus en détail. Installation Un programme d'installation exécutable unique est exécuté sur le poste de travail du client qui installe le logiciel client enseignant localement, en même temps que des raccourcis appropriés. Configuration Chaque enseignant est configuré sur le serveur en tant qu'un utilisateur client enseignant et reçoit un numéro d'identification personnel (PIN) qui est envoyé avec chaque transaction allant du client enseignant vers le serveur de classe et est validé chaque fois. Le nom d'utilisateur et le PIN peuvent être complètement indépendants des noms d'utilisateurs et mots de passe du domaine des utilisateurs et indépendants du domaine dans lequel ils se connectent (programme d'étude ou administratif) ou être liés au nom d'utilisateur de réseau et au mot de passe. L'utilisateur introduit alors l'adresse de réseau du serveur dans un écran de configuration et demande et charge un paquet de configuration d'informations spécifiques au site, telles que la liste des repères de présence possibles à utiliser dans un registre à cette école et le nombre de périodes dans une journée, par l'intermédiaire d'un TCP/IP sur un port spécifique à utilisateur. Comme le paquet TCP/IP est envoyé à une adresse IP spécifique sur un port spécifique et n'accède à aucune ressource réseau, cela n'a aucune importance que l'utilisateur soit connecté sur les domaines de réseau de programme d'étude ou administratif. La requête en configuration est authentifiée au niveau du serveur et une réponse est envoyée au PC/laptop du client, en incluant l'information de configuration nécessaire par l'intermédiaire du TCP/IP vers l'adresse IP spécifique du PC/laptop sur le même port. Les paquets envoyés par l'intermédiaire du protocole TCP/IP sont toujours identiques aux paquets envoyés entre des machines de serveur et du client. Ils sont simplement cassés en des paquets plus petits et enveloppés dans une enveloppe adresse qui donne l'adresse de l'envoyeur et l'adresse de destination et le port utilisé pour la communication. Au niveau du logiciel DPM de destination sur le serveur de classe et le client enseignant sur le PC/laptop du client, les paquets sont automatiquement sortis de leur enveloppe et réassemblés en le paquet de communication. Fonctionnement L'utilisateur charge le logiciel par l'intermédiaire d'une instruction ou d'un raccourci de bureau précréé sur le poste de travail du client. Le poste de travail du client charge alors le logiciel à partir du PC local ou du laptop local. Aucun accès réseau n'est initié à ce point. L'enseignant introduit son nom ou son code personnel et le PIN et sélectionne le module d'enregistrement pour demander un registre de classe. Après avoir tapé un nom de classe, la date et le numéro de la leçon, l'enseignant demande le registre de classe au serveur. Si le registre, pour ces nom, date et numéro de leçon, existe déjà localement, alors on demande à l'utilisateur s'il souhaite utiliser la copie locale ou demander une nouvelle copie au serveur (qui peut contenir plus d'informations mises à jour). Si une classe doit être demandée, un paquet de requêtes d'enregistrement est préparé et envoyé directement au serveur par l'intermédiaire du TCP/IP. Le TCP/IP peut être utilisé en tant que le protocole de transmission de réseau parce qu'il est un protocole pouvant être acheminé (contrairement à NetBEUI, il peut être acheminé d'un segment de réseau à un autre) et n'est pas un protocole de "transmission" (contrairement à IPX/SPX, des paquets uniques sont envoyés à un instant à une adresse spécifique par l'intermédiaire d'un chemin unique). Le logiciel DPM qui fonctionne sur le serveur assemble le paquet et valide le nom et le PIN de l'enseignant. Le DPM, alors, s'il y a validation, envoie un registre préparé à l'avance en retour au client enseignant sur le PC/laptop par l'intermédiaire du processus inverse. Le paquet de registre est reçu, réassemblé et interprété par le client enseignant, et est affiché sous la forme de colonnes de noms et de repères (incluant des repères précédentes introduites pour cette leçon/jour/classe). A ce point, le laptop/PC peut se déconnecter du réseau et l'enseignant peut marquer le registre à loisir sans créer des inconvénients aux autres utilisateurs, puisque toutes les données sont mémorisées localement. Une fois que le registre est terminé, l'enseignant peut choisir s'il veut sauvegarder le registre localement pour l'envoyer en retour plus tard ou envoyer le registre immédiatement en utilisant le même processus que détaillé ci-dessus dans la section Configuration. Sur un grand réseau, des centaines d'utilisateurs pourraient utiliser le logiciel client enseignant simultanément pour lire et écrire des données liées à la présence/absence sans aucun blocage ou ralentissement d'application/ réseau du client appréciable puisqu'un seul programme (DPM) a l'accès exclusif aux fichiers de base de données et met simplement sous la forme de files d'attente, toutes les requêtes de lecture/écriture de registre à très grande vitesse (car les paquets de registre sont préparés à l'avance), même sur un serveur à faible spécification. Chaque requête et transaction de réponse entre le client enseignant et le serveur de classe met en jeu la réception et l'envoi de petits paquets d'information et prend une fraction de seconde. Les utilisateurs client enseignant qui sont déjà en train de prendre ou de modifier un registre ne subiront pas d'inconvénient ni de perte d'aucun travail effectué si la liaison réseau vers le serveur est déconnectée alors qu'ils ne sont pas en train de communiquer avec le serveur à cet instant. Fonctionnements du côté du serveur Certains fonctionnements du côté du serveur, tels que des sauvegardes de fichiers de base de données ou des mises à jour d'emploi du temps du client enseignant à partir d'un paquet d'emploi du temps, demandent un accès exclusif aux fichiers de base de données. Ceci signifie que seul le DPM doit être temporairement stoppé sur le serveur parce qu'il a un accès exclusif à la base de données et aucun utilisateur n'a besoin d'être déconnecté de son utilisation du système. Bien que l'invention se fonde sur un ensemble privé de transactions, l'une de ses particularités clés est qu'elle préserve la compatibilité avec les communications standards dans l'industrie sur n'importe quel réseau en insérant la transaction et des données entre le serveur de classe et le client enseignant directement dans des paquets TCP/IP. De cette manière, l'invention est capable de fonctionner sur tout type de réseau, par exemple LAN, WLAN et différents types de porteurs, par exemple Ethernet, WiFI et GSM/GRP, c'est-à-dire fondamentalement tout support qui accepte TCP/IP. Perfectionnements supplémentaires : L'invention peut également être étendue par les particularités suivantes supplémentaires : Carte réseau supplémentaire dans le serveur de 15 classe : En ajoutant une connexion réseau distincte, telle qu'une deuxième carte réseau, dans le serveur de classe, le serveur de classe peut, en outre, isoler le réseau de programme d'étude et le réseau administration. 20 Une carte réseau est connectée au réseau de programme d'étude par l'intermédiaire du routeur et du pare-feu et l'autre carte réseau est connectée au réseau d'administration. Ceci fournit une double couche de sécurité à l'encontre d'un accès non autorisé à partir du 25 réseau de programme d'étude. Cryptage des paquets TCP/IP : Des perfectionnements de sécurité supplémentaires peuvent être obtenus en cryptant tous les paquets TCP/IP entre le serveur de classe et les clients 30 enseignants et vice versa. Diverses techniques de cryptage standard dans l'industrie sont disponibles pour cela. Compression de paquets TCP/IP : En outre, un rendement supplémentaire peut être obtenu en comprimant tous les paquets TCP/IP entre le serveur de classe et les clients enseignants et vice versa. Diverses techniques de compression standard dans l'industrie sont disponibles pour cela. Utilisation de GPRS pour utilisation dans des bâtiments de l'école à l'extérieur : En se fondant simplement sur une couche de communication TCP/IP, l'invention peut facilement être adaptée pour utiliser le système d'infrastructure de transmission de communication par téléphone cellulaire/mobile public et la connexion Internet à l'école pour fournir un paquet de logiciel client enseignant complet sur un téléphone cellulaire/mobile faisant tourner le logiciel enseignant client adapté à un système d'exploitation de téléphone cellulaire/mobile, tel que Symbian, Microsoft Mobile, ou par l'intermédiaire de Java. Ceci étend l'utilisation des clients enseignants au-delà des paramètres des bâtiments des écoles pour utilisation par des enseignants PE, par exemple sur des terrains de sport, des centres de loisirs publics et même pendant des voyages. Il y a également une tendance des écoles à inclure des places de travail en tant que parties à vocation du programme d'étude hebdomadaire, par exemple la mécanique auto, la coiffure, la boulangerie, etc. Des écoles peuvent permettre que l'on puisse accéder à des registres de classes d'école à partir de telles places de travail par l'intermédiaire du téléphone cellulaire/mobile, de manière à fournir une prise de présence/absence instantanée et intégrée des étudiants à des cours à vocation de ce genre. De préférence le réseau d'administration comporte au moins un serveur debase de données pour des données d'administration, et un serveur dédié distinct agissant en tant que proxy ("serveur de classe") pour desservir des requêtes en provenance du réseau de programme d'étude. De préférence, une connexion de réseau distincte est fournie pour connecter le serveur de classe au réseau de programme d'étude par l'intermédiaire d'un routeur/pare-feu, la connexion de réseau distincte isolant en outre le réseau d'administration du réseau de programme d'étude pour desservir des requêtes en provenance du réseau de programme d'étude. De préférence, les échanges de données entre le serveur de classe et un demandeur client sont agencés de sorte qu'aucun nom de fichier n'est nécessité comme la source de donnée exigée soit par le serveur de classe, soit par le demandeur client. De préférence, des requêtes en provenance du réseau de programme d'étude vers le réseau d'administration sont limitées à des paquets de réseau comportant des types de transactions identifiées par une série de numéros de code déterminés à l'avance en même temps que des paramètres d'entrée correspondants pour indiquer l'article spécifique pertinent d'intérêt. De préférence, les données à échanger entre les réseaux sont mises en paquet sous la forme d'une liste d'articles de données et de paramètres pertinents d'une manière prescrite en un paquet unique, le serveur et le client pouvant à la fois désassembler le paquet, manipuler les données et les remettre en paquet et les renvoyer si nécessaire, de manière à fournir un degré élevé de mise à l'échelle dans le nombre de clients qui peuvent être desservis en un court espace de temps, les paquets étant cryptés pour une sécurité supplémentaire et comprimés pour un rendement supplémentaire. De préférence, le client comporte un système de dictionnaire de données, de sorte qu'il peut manipuler les données dans le paquet reçu dans un état hors ligne et renvoyer ensuite les données manipulées chaque fois qu'il est de nouveau en ligne, si nécessité. De préférence, chaque client reçoit un numéro 5 d'identification personnel (PIN) unique qui doit être inclus dans chaque transaction. REVENDICATIONS 1. Système de réseau d'ordinateur sécurisé pour des établissements d'éducation, comportant un premier réseau pour des données d'éducation ("réseau de programme d'étude") et un deuxième réseau distinct pour des données administratives et d'autres données confidentielles ("réseau d'administration"), caractérisé en ce que les deux réseaux sont connectés par un pare-feu comportant une protection NAT et également un système d'inspection de paquets sensible au contexte, qui ne laisse passer que des paquets d'un contenu déterminé à l'avance. 2. Système de réseau sécurisé suivant la revendication 1, caractérisé en ce que le réseau d'administration comporte au moins un serveur de base de données pour des données d'administration, et un serveur dédié distinct agissant en tant que proxy ("serveur de classe") pour desservir des requêtes en provenance du réseau de programme d'étude. 3. Système de réseau sécurisé suivant la revendication 2, caractérisé en ce qu'une connexion de réseau distincte est fournie pour connecter le serveur de classe au réseau de programme d'étude par l'intermédiaire d'un routeur/pare-feu, la connexion de réseau distincte isolant en outre le réseau d'administration du réseau de programme d'étude pour desservir des requêtes en provenance du réseau de programme d'étude. 4. Système de réseau sécurisé suivant la revendication 2 ou la revendication 3, caractérisé en ce que les échanges de données entre le serveur de classe et un demandeur client sont agencés de sorte qu'aucun nom de fichier n'est nécessité comme la source de donnée exigée soit par le serveur de classe, soit par le demandeur client. 5. Système de réseau sécurisé pour des établissements d'éducation suivant l'une quelconque des revendications précédentes, caractér=_sé en ce que des requêtes en provenance du réseau de programme d'étude vers le réseau d'administration sont limitées à des paquets de réseau comportant des types de transactions identifiées par une série de numéros de code déterminés à l'avance en même temps que des paramètres d'entrée correspondants pour indiquer l'article spécifique pertinent d'intérêt. 6. Système de réseau sécurisé suivant l'une quelconque des revendications précédentes, caractérisé en ce que les données à échanger entre les réseaux sont mises en paquet sous la forme d'une liste d'articles de données et de paramètres pertinents d'une manière prescrite en un paquet unique, le serveur et le client pouvant à la fois désassembler le paquet, manipuler les données et les remettre en paquet et les renvoyer si nécessaire, de manière à fournir un degré élevé de mise à l'échelle dans le nombre de clients qui peuvent être desservis en un court espace de temps, les paquets étant cryptés pour une sécurité supplémentaire et comprimés pour un rendement supplémentaire. 7. Système de réseau sécurisé suivant la revendication 5 ou la revendication 6, caractérisé en ce que le client comporte un système de dictionnaire de données, de sorte qu'il peut manipuler les données dans le paquet reçu dans un état hors ligne et renvoyer ensuite les données manipulées chaque fois qu'il est de nouveau en ligne, si nécessité. 8. Système de réseau sécurisé suivant l'une quelconque des revendications 4 à 7, caractérisé en ce que chaque client reçoit un numéro d'identification personnel (PIN) unique qui doit être inclus dans chaque 23transaction.