L’architecture d’aXes

aXes est habituellement installé dans les entreprises ou chez les fournisseurs de services (Service Providers). Les niveaux de sécurité de ces environnements peuvent varier : aucun pare-feu ou des pare-feux installés entre chaque couche de l’infrastructure.

Le but d’aXes est d’être suffisamment flexible pour pouvoir opérer dans tous les types d’environnements sécurisés avec le moins de changement possible dans l’infrastructure existante. Dans certains cas, les dispositifs clients seront basés sur des sites distants qui ne seront pas gérés par l’entité qui aura en charge aXes. Pour accéder à des serveurs sur Internet, les postes clients devront traverser des routeurs, pare-feux et/ou autres serveurs proxy. Les règles de sécurité de certains sites pourront par exemple autoriser le trafic sur ou à partir de certains ports spécifiques. Le challenge pour les utilisateurs sera d’accéder à leurs applications métier depuis Internet, sans corrompre la sécurité de leur entreprise. Tout logiciel ou matériel opérant dans une entreprise ou chez un fournisseur de service, au travers d’accès Internet, doit répondre à ces challenges. aXes dépasse ces contraintes sans affecter l’utilisateur final, sans compromettre les règles de sécurité, et sans corrompre l’infrastructure et sans nécessiter de couteuses alternatives, telles que les VPN (Virtual Private Network).

aXes embarque son propre serveur d’application, avec son propre serveur HTTP pour IBM i (System i, iSeries, AS/400), rapide et sécurisé, avec sa propre technologie d’accélération de site Web. En utilisant le serveur d’application d’aXes, les temps de chargements sont réduits, les temps de réponses Web sont améliorés et la qualité de service plus facilement planifiable et managée.

Pare-feux, serveurs cache et serveurs proxy

Des pare-feux sont déployés dans les entreprises et chez les fournisseurs de services comme une mesure de contrôle d’accès au réseau. Si le périphérique client et le serveur d’application aXes sont derrière le même pare-feu, le client devra se connecter directement au aXes Application Server. Ce sera le cas si le client est sur le même Intranet que l’ aXes Application Server, utilisant une méthode d’accès comme le VPN ou un mode « dial-up » - ces connexions étant dans ce cas « apparemment » locales. Dans une autre configuration, le périphérique client se trouve en dehors du site où se trouve l’aXes Application Server, en dehors du pare-feu. Alors le client se connectera directement sur Internet via le pare-feu jusqu’au aXes Application Server, ou sera routé au travers du pare-feu de son propre site afin d’atteindre Internet et de se connecter au Axes Application Server.

L’aXes Application Server fournit des entêtes HTTP explicites conforme à version HTTP 1.1 du serveur proxy sans cache des transaction aXes. Le serveur proxy ne mettra pas les transactions aXes en cache, chaque transaction aXes ayant un URL unique. Les autres transactions HTTP d’aXes Application Server seront « cachées » normalement, à travers un serveur proxy.

Pour plus d’information sur les pare-feux et les serveurs proxy, veuillez visiter :

Les ports aXes

L’aXes Application Server utilise les protocoles HTTP ou HTTPS. Chacun de ces types de connexion est servi par processus écoutant sur un port particulier de l’aXes Application Server. Les ports utilisés par défaut sont :

  • Port 80 HTTP
  • Port 443 HTTPS

Les protocoles peuvent être cryptés ou non, en fonction des paramètres de sécurités fixes par l’utilisateur.

Typiquement, les utilisateurs accèdent aux applications via aXes Application Server en tapant un URL dans leur navigateur, par exemple https://www.axeslive.com/. La connexion initiale à aXe Application Server est toujours réalisée soit via http, soit HTTPS. L’aXes Application Server répond aux requêtes HTTP ou HTTPS et présente un écran de login à l’utilisateur. Le trafic Internet généré lorsque l’utilisateur se connecte, lance et répond aux applications.

Pour travailler dans un environnement sécurisé, il est préférable de crypter le trafic Internet. Dans ce cas, on utilisera de préférence HTTPS. Si aXes Application Server (HTTPS) écoute sur le port 443, alors ce port doit être accessible au trafic entrant. Ceci étant dit, le port doit être accessible au travers du pare-feux au site de l’aXes Application Server. Si le site client comporte aussi un pare-feu ou un serveur proxy, le trafic doit être autorisé sur le port 443.

Si le périphérique client est placé dans un environnement sécurisé, le firewall et/ou le serveur proxy situé de son côté peuvent permettre un trafic sortant uniquement sur le port 443 du serveur de destination. Dans cette situation, le trafic Web trafic doit passer sur le port 443.

aXes et Telnet

aXes n’utilise pas Telnet. Aucun des protocoles, Telnet ou le serveur Telnet du serveur IBM i n’a besoin d’être actif pendant l’exécution d’aXes.

La plupart des solutions basées sur Telnet (clients riche ou léger) ouvrent deux ports (port 23 et port 292) quand l’aXes Application Server écoutera sur le port par défaut pour les applications HTTP (port 80) ou un port utilisateur spécifique.

Une question que l’on se pose souvent est : "Est-ce-qu’utiliser des solutions de passerelles basées sur Telnet ou utilisant Telnet pour accéder à des applications IBM i à partir du Web crée une brèche dans la sécurité de ce serveur ? " C’est souvent le cas lorsque certaines solutions ouvrent une combinaison de ports pour offrir des accès. Les connexions ODBC, les clients java et/ou les accès sockets directs aux serveurs d’applications et aux données.

La réponse est non, parce que – même si un pirate ou un intrus pouvaient se connecter avec succès en ouvrant une session Telnet (et se trouve sur la mire d’ouverture) - ils devraient toujours posséder un profil et un mot de passe avant de pouvoir accéder au serveur. La procédure de sécurité IBM i correcte devrait être en place pour limiter le nombre de tentatives infructueuses de signature et traquer les tentatives d’intrusion.

Les approches basées sur Telnet pour accéder aux serveurs permettent aux pirates de déterminer le type de système sur lesquels ils pourraient ouvrir une session. C’est parce que la session affichera la mire d’ouverture du serveur.

Une méthode de sécurisation classique consiste à limiter la quantité d’information mise à la disposition de pirates potentiels. aXes améliore l’approche basée sur Telnet par :

  • Ne pas utiliser Telnet (en fait, le serveur Telnet server peut être désactivé sans affecter le fonctionnement d’aXes)
  • Ne jamais afficher la mire de signature du serveur
  • Toujours crypter le profil utilisateur et le mot de aXes supporte différentes implémentation physique, chacune pouvant fournir un niveau de performance et de scalabilité différent. (même si SSL n’est pas utilisé)
  • Utiliser des ports HTTPS plutôt que des ports Telnet

Les mesures de sécurité fournies par aXes

La sécurité fait partie intégrante de la suite aXes et a été conçue pour protéger vos données et vos applications tout en rendant ces mêmes applications disponibles aux utilisateurs distants sur Internet et utilisant un navigateur. aXes supporte différentes implémentations physiques, chacune pouvant fournir un niveau de performance et de scalabilité différent. Par exemple :

  • aXes supporte les mécanismes de sécurité et d’authentification de l’IBM i jusqu’au niveau de sécurité le plus haut (niveau 50).
  • L’identification utilisateur et les mots de passe sont cryptés avant la transmission et ne peuvent pas être mis en cache dans le navigateur.
  • aXes supporte la signature à partir d’adresse IP spécifiques.
  • aXes supporte la signature depuis des noms de périphériques spécifiques.
  • aXes fournit le shadowing des sessions utilisateurs sur le serveur – un service utilisé par les administrateurs pour examiner en temps réel l’activité des personnes.
  • aXes Application Server supporte aussi bien les protocoles Secure Sockets Layer (SSL) et Transport Layer Security (TLS) qui permettent une authentification sécurisé et l’encryptage, la non-répudiation et les technologies VPN. Le SSL et les VPNs préviennent des écoutes et de l’interception du trafic réseau entre le navigateur et le serveur.

Les communications entre le navigateur et l’aXes Application Server sont compressées (GZIP), ce qui offre deux bénéfices majeurs :

  • Le trafic est plus difficile à surveiller avec des renifleurs.
  • Avec l’utilisation des technologies SSL et VPN, la quantité de données transmises entre le serveur et le navigateur est réduit avant que le cryptage et décryptage SSL et VPN opèrent.

La compression du trafic économise une quantité importante de bande passante et de cycle CPU lorsque les technologies SSL et VPN sont utilisées.

L’aXes Application Server sécurise les pages Web en requérant des droits spécifiques de lecture read (*R) d’exécution exécute (*X) sur les couches du serveur. Cela sécurise l’accès aux répertoires du serveur par notamment l’utilisation des listes de contrôle d’accès (Access Control Lists – ACL).

Haut de la page