Créée en 1991 par l’OMG (Object Management Group), la norme Corba (Common Object Request Broker Architecture) définit la manière dont les applications utilisent les services des composants dans une architecture distribuée. Dans un tel environnement, constitué de clients légers et de serveurs de données et d’applications hétérogènes, une infrastructure est en effet nécessaire pour que les programmes et les différents composants (objets) répartis puissent communiquer entre eux. Corba répond à cette demande grâce à un bus d’objets répartis, appelé également ORB (Object Request Broker). Alors que la version 1.1 du standard ne s’appliquait qu’à un seul ORB, la seconde (1994) a permis d’étendre la communication entre ORB issus de différents vendeurs, en introduisant le protocole GIOP (General Inter-ORB Protocol), dont l’implémentation sur IP se nomme IIOP (Internet Inter-ORB Protocol). Mais, pour assurer leur sécurité, toutes les entreprises ont placé des coupe-feu sur les points d’entrée de leur réseau. Or, il n’existait pas de normes permettant à un tel équipement d’identifier et de contrôler les flux IIOP. Pas moyen donc de sécuriser simplement et efficacement un réseau Corba.
INFORMER, CHIFFRER ET RAPPELER
Avec la version 3 de cette norme, le coupe-feu sait désormais déterminer si un flux donné est bien IIOP. Il peut également différencier le trafic IIOP autorisé à pénétrer dans une enclave (voir infographie) de celui qui ne l’est pas. Étant donné que IIOP constitue une implémentation sur IP, il n’a pas été nécessaire de modifier ce protocole. Corba 3 définit de nouveaux éléments, lesquels fournissent l’information requise pour le contrôle du trafic aux clients, aux serveurs et aux coupe-feu. Il s’agit, d’une part, de l’ajout de nouveaux champs dans les IOR (Interoperable Object References). Ces IOR contiennent des informations (adresse de l’ordinateur de destination par exemple) utilisées par la couche transport pour accéder à l’objet. Grâce à ce nouveau format, trois types de coupe-feu sont supportés : TCP, Socks Proxy et GIOP. Ils s’assurent que le trafic qui doit être IIOP l’est effectivement. D’autre part, Corba 3 offre de nouvelles méthodes d’utilisation de SSL (Secure Socket Layer) pour protéger les communications IIOP. Ce standard, créé par Netscape, sert à chiffrer les échan-ges sur le Web avec des clés publiques. Enfin, cette dernière version apporte une solution au call-back. Il arrive en effet fréquemment qu’un objet situé sur un serveur doive rappeler (call-back) l’application qui l’a invoqué. Pour cela, il doit initier une autre connexion TCP. Or, un coupe-feu surveille rarement le trafic qui sort d’un serveur et se dirige vers une station de travail (seul le trafic inverse est protégé). Corba 3 permet de résoudre ce problème en rendant le protocole GIOP bidirectionnel. Le serveur réutilise ainsi la connexion TCP pour transporter le flux IIOP vers le client.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
