M Option Firewall Security Option

La fonctionnalité Firewall Secure permet d'exécuter ACSLS derrière un pare-feu pendant que le logiciel client effectue des demandes à travers ce pare-feu.

Elle est également offerte aux clients ACSLS, ce qui leur permet de fonctionner derrière leur propre pare-feu. Oracle la met à la disposition de ses partenaires fournisseurs de logiciels indépendants (ISV). Contactez le fournisseur de votre composant logiciel client pour prendre connaissance du dernier statut de chaque client.

Exécution d'ACSLS derrière un pare-feu

La solution Firewall Secure offre les avantages suivants :

• Permet l'exécution d'ACSLS derrière un pare-feu (c'est-à-dire, ACSLS se trouve du côté protégé du pare-feu et le client de l'autre côté).

• Permet l'exécution de clients ACSLS derrière leur propre pare-feu (c'est-à-dire, les clients se trouvent du côté protégé et ACSLS de l'autre côté du pare-feu).

  Remarque :

  Les fournisseurs ISV doit avoir mis en oeuvre les mises à jour disponibles pour leur composant logiciel côté client.

• Préserve la compatibilité avec les implémentations client ACSLS actuelles, ce qui permet à ces clients de continuer à s'exécuter avec ACSLS dans la solution de pare-feu.

• Préserve les fonctionnalités et les performances ACSAPI/Client actuelles. Cela inclut toutes les fonctionnalités disponibles dans un environnement sans pare-feu.

Une solution complète doit combiner les deux capacités ci-dessus. Cela permet à ACSLS et aux clients ACSLS de s'exécuter derrière leur pare-feu respectif (c'est-à-dire, deux pare-feu entre ACSLS et les clients), tout en continuant à bénéficier des mêmes performances de communication qu'un environnement sans pare-feu.

Traitement des aspects liés à la sécurité

ACSLS a résolu les problèmes de sécurité suivants :

RPC

Les appels de procédure distante (RPC) dans ACSLS posent problème pour certains sites lorsqu'ils tentent de s'exécuter dans un environnement équipé d'un pare-feu. L'obligation de préserver la compatibilité avec la base de clients actuellement installés exclut la possibilité de supprimer complètement RPC d'ACSLS.

La fonctionnalité Firewall Secure d'ACSLS a résolu les problèmes inhérents à RPC, à savoir :

• la nécessité de permettre à des partie extérieures (non approuvées) de se connecter à l'hôte approuvé sur une plage de ports sans restriction (1024-65535) ;

• l'exposition du mappage des services disponibles sur une plate-forme par le biais du démon portmap (ou rpcbind) exécuté sur le port 111 connu.

Sécurité

Dans une solution de pare-feu, les conditions de sécurité fondamentales reposent sur la restriction de l'accès depuis le côté non sécurisé vers le côté approuvé (sécurisé). Dans tous les cas, il convient d'accorder un accès limité et contrôlé pour effectuer les communications et permettre l'échange de données. L'objectif est d'autoriser l'échange de données dans un ensemble de points d'entrée bien défini et restreint, ce qui permet de contrôler les points d'accès et leurs communications correspondantes. La présente solution répond à cette exigence.

Remarque :

Si vous disposez d'un pare-feu de périmètre IPv4, il doit être configuré pour rejeter tous les paquets sortants 41 du protocole IPv4 et les paquets 3544 du port UDP, afin d'empêcher que des hôtes Internet utilisent du trafic transitant par des tunnels IPv6 sur IPv4 pour atteindre des hôtes internes.

Composants de communication

Les communications ACSLS/Client dépendent de deux composants d'interface réseau qui gèrent les communications réseau entre les plates-formes client et la plate-forme ACSLS. Les logiciels qui font office de client ou de serveur proxy pour ACSLS implémentent l'un de ces deux composants pour être compatibles avec les plates-formes ACSLS et les clients existants. Le composant qui réside sur la plate-forme client est appelé SSI ; celui qui réside sur la plate-forme ACSLS est appelé CSI. S'il serait préférable d'implémenter toutes les modifications d'un seul côté (par exemple, la plate-forme ACSLS), pour assurer la compatibilité des clients et offrir toutes les fonctionnalités Firewall Secure, il est nécessaire de procéder aux mêmes modifications de chaque côté pour bénéficier des avantages. L'aspect positif est que chaque côté peut implémenter les fonctionnalités de manière autonome et profiter des avantages de Firewall Secure unilatéralement (par exemple, les modifications apportées à ACSLS permettent à la plate-forme ACSLS de s'exécuter derrière un pare-feu sécurisé).

Avantages de la fonctionnalité Firewall Secure

Cette section décrit les avantages de la fonctionnalité Firewall Secure.

ACSLS côté serveur

Les modifications apportées au composant côté serveur, fournies dans la solution Firewall Secure, offrent les avantages suivants :

• Les connexions entrantes des communications ACSLS peuvent être restreintes à un seul port TCP pour tous les numéros de programme enregistrés (il existe deux numéros de programme enregistrés pour la CSI ACSLS, chacun étant traité par un port unique).

• Les utilisateurs peuvent spécifier l'identité de ce port et configurer leur pare-feu en conséquence.

• Les utilisateurs peuvent désactiver les communications ACSLS avec les ports UDP.

• Les utilisateurs peuvent désactiver toutes les communication entre le serveur ACSLS et les ports Portmapper* côté client (Port UDP/TCP 111). Portmapper doit continuer à s'exécuter sur les plates-formes client pour préserver la compatibilité avec le code côté client. Toutefois, comme il ne sera pas utilisé pour les communications réseau initiées par le serveur, les pare-feu des clients peuvent être configurés pour en refuser l'accès.

• Les connexions sortantes à partir du côté serveur d'ACSLS vers les clients n'ont pas de restriction, pour les ports côté serveur qui permettent de conserver les performances actuelles. Ceci est conforme aux pratiques largement répandues chez les spécialistes de la sécurité.

Restriction du port serveur ACSLS

Cette solution de pare-feu limite le nombre de ports entrants via lesquels une partie extérieure peut initier une communication réseau. Le nombre de ports est limité à un ou trois : le seul port spécifié par le client destiné aux demandes ACSLS entrantes, plus éventuellement les deux ports Portmapper (port TCP et UDP 111).

Remarque :

Pour refuser l'accès client au port Portmapper du serveur ACSLS, ce qui revient à refuser l'accès aux ports UDP et TCP 111, il faut modifier le composant logiciel client . Reportez-vous à la section ci-après concernant la plate-forme côté client.

Le côté serveur de la solution ci-dessus, est intégralement implémenté dans ACSLS.

Côté client (CSC)

Les modifications apportées au CSC placent sur le côté client de la plate-forme des restrictions identiques à celles décrites ci-dessus. Le CSC a ainsi la même capacité de résider derrière son propre pare-feu sécurisé. Cette solution présente les avantages suivants :

• Les connexions entrantes pour les communications (réponse) avec le CSC sont restreintes à un seul port TCP pour chaque numéro de programme enregistré. La SSI ACSLS dispose d'un numéro de programme enregistré.

• Les utilisateurs finaux peuvent spécifier l'identité du port TCP et configurer leur pare-feu de la même manière.

• Les communications côté client avec les ports UDP sont désactivées.

• Toutes les communications par le client avec le port Portmapper du serveur ACSLS (port UDP/TCP 111) sont désactivées. Portmapper doit continuer à s'exécuter sur la plate-forme ACSLS pour préserver la compatibilité avec le code ACSLS. Néanmoins, les communications réseau du client ne sont pas initiées via Portmapper. Par conséquent, le pare-feu du serveur ACSLS peut être configuré pour en refuser l'accès.

• Les connexions sortantes à partir du côté client vers le serveur ACSLS n'ont pas de restriction, pour les ports côté client qui permettent de conserver les performances actuelles.

Restriction relative aux ports clients

Cette solution limite le nombre de ports entrants via lesquels une partie extérieure peut initier une communication réseau. Le nombre de ports est limité à un ou trois : le seul port spécifié par le client destiné aux réponses entrantes du client, et éventuellement les deux ports Portmapper (port TCP et UDP 111).

Remarque :

Pour refuser l'accès du serveur ACSLS au port Portmapper du client (ce qui revient à refuser l'accès aux ports UDP et TCP 111), il faut modifier le composant logiciel du serveur ACSLS (reportez-vous à la section ci-dessus relative au côté serveur d'ACSLS).

Cette solution s'applique en deux temps :

• Oracle StorageTek a effectué les modifications nécessaires au niveau du code source de CSC Developer’s Toolkit 2.3 (ou version ultérieure).

• Les clients d'ACSLS qui souhaitent fournir cette sécurité à leur plate-forme client doivent intégrer ces modifications dans le code SSI côté client, reconstruire le produit et certifier à nouveau leur composant système client (CSC) avec ACSLS.

Avantages

Les parties côté client et côté serveur de la solution sont indépendantes. Par conséquent, si seul un des deux côtés se trouve derrière un pare-feu, c'est uniquement sur ce côté-là que les modifications logicielles doivent être implémentées. Par ailleurs, cette modification unilatérale conserve la compatibilité avec toutes les implémentations de client et de serveur actuelles et avec les autres composants logiciels qui utilisent l'interface CSI/SSI.

Remarque :

Cela inclut la compatibilité avec les produits Oracle StorageTek actuels.

Cette solution n'a pas d'effet sur les performances actuelles des communications client/server.

Activation des fonctionnalités Firewall Secure et définition des variables

Pour exécuter le serveur ACSLS (et aussi le client éventuellement) derrière un pare-feu, définissez les variables du serveur ACSLS et du système client lorsqu'ils se trouvent derrière un pare-feu. Ces variables vous permettent de restreindre les communications entrantes vers un port unique, et éventuellement de désactiver Portmapper.

Variables ACSLS

CSI_TCP_RPCSERVICE - Activer la prise en charge de la CSI pour RPC avec le protocole TCP.

• Fonction : permet au CSI de remplir les fonctions de serveur TCP RPC. Si des clients veulent communiquer avec ACSLS via TCP, définissez cette option sur TRUE.

• Options valides : TRUE ou FALSE (TRUE étant la valeur par défaut).

  • TRUE active l'accès au CSI via TCP pour les clients.

  • FALSE désactive l'accès au CSI via TCP pour les clients.

• Autres détails : le produit ACSLS doit redémarrer pour que cette option prenne effet.

CSI_UDP_RPCSERVICE : Enable CSI support for RPC using the UDP protocol.

• Fonction : permet au CSI de remplir les fonctions de serveur UDP RPC. Si des clients veulent communiquer avec ACSLS via UDP, définissez cette option sur TRUE.

• Options valides : TRUE ou FALSE (FALSE étant la valeur recommandée).

  • TRUE active l'accès au CSI via UDP pour les clients.

  • FALSE désactive l'accès au CSI via UDP pour les clients.

• Autres détails : le produit ACSLS doit redémarrer pour que cette option prenne effet. La CSI Firewall Secure est seulement prise en charge pour les communications TCP. Définissez CSI_UDP_RPCSERVICE sur FALSE, sauf si des applications client héritées se trouvent dans le pare-feu avec le serveur ACSLS.

CSI_USE_PORTMAPPER – Enable the portmapper.

• Fonction : oblige la CSI à interroger Portmapper lorsqu'elle ne parvient pas à envoyer une réponse à un client. Si vous ne voulez pas accorder l'accès à Portmapper sur le client, définissez cette option sur ALWAYS.

• Options valides : ALWAYS, NEVER ou IF_DUAL_LAN_NOT_ENABLED

  • ALWAYS signifie que Portmapper doit toujours être interrogé lorsque la CSI ne parvient pas à envoyer une réponse à un client.

  • NEVER signifie que Portmapper ne doit jamais être interrogé lorsque la CSI ne parvient pas à envoyer une réponse à un client. Cette option doit être sélectionnée si les clients ne prennent pas en charge Portmapper.

  • IF_DUAL_LAN_NOT_ENABLED spécifie que Portmapper doit être interrogé seulement si la double prise en charge LAN est activée. Si la double prise en charge LAN a été activée, il est considéré que les clients ne prennent pas en charge Portmapper. IF_DUAL_LAN_NOT_ENABLED est la valeur par défaut pour garantir la compatibilité ascendante.

• Autres détails : le produit ACSLS doit redémarrer pour que cette option prenne effet.

CSI_FIREWALL_SECURE - Enable the CSI to be used behind a firewall (with a user-defined inbound port).

• Fonction : permet au serveur ACSLS de fonctionner derrière un pare-feu sécurisé. Spécifiez le port entrant utilisé par ACSLS et limitez l'accès à un seul port. Configurez le pare-feu de manière à rejeter le trafic ACSLS entrant sur tous les autres ports. Cela permet de garantir que seul ce port est exposé pour être utilisé par les clients extérieurs qui veulent initier des communications avec ACSLS.

  Pour restreindre l'accès au port, suivez les étapes ci-après pour configurer le pare-feu sécurisé pour un port spécifié :

  • Définissez cette option sur TRUE.

  • Spécifiez le port que la CSI doit utiliser et sur lequel les demandes ACSLS entrantes sont autorisées. (Spécifié par CSI_INET_PORT.)

  • Pour certaines applications client héritées qui n'admettent pas RPC sur un port fixe, il peut être nécessaire d'ouvrir le port UDP/TCP 111 dans le pare-feu pour prendre en charge les demandes d'interrogation de Portmapper provenant du client.

  • La CSI Firewall Secure est seulement prise en charge pour les communications TCP.

    Définissez CSI_UDP_RPCSERVICE sur FALSE, sauf si des applications client héritées se trouvent dans le pare-feu avec le serveur ACSLS.

  • Configurez le pare-feu derrière lequel réside le serveur ACSLS pour permettre aux clients extérieurs d'initier et de recevoir des communications sur le port précédemment spécifié. N'oubliez pas de définir le même port fixe pour l'application client afin de minimiser le nombre de ports ouverts dans le pare-feu.

  • Redémarrez ACSLS.

• Options valides : TRUE ou FALSE (TRUE étant l'option par défaut)

  • TRUE – Restreindre l'accès du serveur ACSLS à un seul port pour les demandes entrantes des clients.

  • FALSE – Ne pas restreindre l'accès aux ports utilisés pour les demandes de client adressées au serveur ACSLS.

• Autres détails : le produit ACSLS doit redémarrer pour que cette option prenne effet.

CSI_INET_PORT - Port number used by the CSI to receive incoming ACSLS requests.

• Fonction : spécifie le port utilisé par la CSI pour les demandes par TCP entrantes provenant des clients.

• Options valides : un nombre situé entre 1024 et 65535, sauf 50003. (La valeur par défaut est 30031)

• Autres détails : le produit ACSLS doit redémarrer pour que cette option prenne effet. Cette variable est uniquement utilisée lorsque l'option CSI_FIREWALL_SECURE est définie sur TRUE.

Affichage et définition des variables ACSLS

Utilisez l'utilitaire acsss_config d'ACSLS ou l'utilitaire dv_config pour afficher et définir les variables ACSLS statiques et dynamiques :

• dv_config –d

  Affiche toutes les variables ACSLS statiques et dynamiques et leurs paramètres.

• dv_config -p <variable_name>  -u

  Vous invite à modifier une variable et, s'il s'agit d'une variable dynamique, à mettre à jour la mémoire partagée globale ACSLS. Saisissez ? à l'invite pour consulter une description complète de la variable. Une fois la description complète de la variable affichée, vous êtes de nouveau invité à la modifier.

Variables du système client ACSAPI

Le système client ACSLS doit être construit à l'aide d'ACSLS CSC Toolkit 2.3 (ou version ultérieure) pour qu'il soit possible d'y activer Firewall Secure.

Il existe quatre variables d'environnement qui permettent d'activer Firewall Secure sur le client ACSLS. Vous devez attribuer des valeurs spécifiques à ces variables. Chacune d'elles doit être définie et exportée dans l'environnement de la SSI avant le démarrage du processus SSI. Elles sont ensuite interprétées et utilisées par la SSI, tel qu'indiqué ci-après.

Si le CSC utilise un script pour démarrer la SSI, il est recommandé de définir et d'exporter ces variables à partir de ce script. Par ailleurs, il est possible que les développeurs du client fournissent une méthode permettant à l'utilisateur final de les configurer correctement, en fonction du CSC et de l'environnement dans lequel il est exécuté.

CSI_UDP_RPCSERVICE – Indique si UDP est utilisé pour les communications réseau.

• Fonction : active/désactive l'utilisation du protocole UDP en tant que couche de transport réseau sous-jacente pour les communications réseau SSI.

• Options valides : TRUE ou FALSE

• Autres détails : cette variable d'environnement doit être définie sur FALSE pour le CSC Firewall Secure. Les paquets des applications ACSLS Firewall Secure sont tous envoyés à l'aide du transport réseau TCP.

CSI_TCP_RPCSERVICE – Indique si TCP est utilisés pour les communications réseau.

• Fonction : active/désactive l'utilisation du protocole TCP en tant que couche de transport réseau sous-jacente pour les communications réseau SSI.

• Options valides : TRUE ou FALSE

• Autres détails : cette variable d'environnement doit être définie sur TRUE pour le CSC Firewall Secure. Les paquets des applications ACSLS Firewall Secure sont tous envoyés à l'aide du transport réseau TCP.

Nouvelles variables dans CSC Toolkit 2.3

SSI_INET_PORT – Numéro de port fixe pour les réponses entrantes.

• Fonction : spécifie le port que la SSI doit utiliser pour les réponses ACSLS entrantes.

• Options valides : 0 ou 1024 à 65535, sauf 50001 et 50004.

  • 0 indique que le comportement précédent permettant l'allocation dynamique du port reste en vigueur.

  • 1024 à 65535 indique le numéro de port TCP à utiliser sur lequel la SSI acceptera les réponses ACSLS.

  • NE PAS spécifier 50001 ou 50004, car ces numéros sont utilisés par mini_el et la SSI.

• Autres détails : lorsqu'une valeur différente de zéro est attribuée à cette variable d'environnement, la SSI utilise ce port pour les réponses ACSLS entrantes. Cela signifie que le pare-feu doit autoriser les demandes entrantes sur ce port pour que les réponses ACSLS soient reçues par la SSI. Il s'agit du seul port sur lequel le logiciel ACSLS initie des connexions avec la SSI des composants système client (CSC).

  Remarque :

  Cette valeur doit correspondre à celle configurée dans le pare-feu qui protège la plate-forme CSC, en permettant les demandes entrantes pour les connexions avec ce port.

CSI_HOSTPORT –Elimine les requêtes adressées à Portmapper sur le serveur ACSLS. A la place, envoie des demandes à ce port sur le serveur ACSLS.

• Fonction : spécifie le port auquel la SSI envoie ses demandes ACSLS sur le serveur ACSLS. La CSI ACSLS doit utiliser ce port (c'est-à-dire, avec le port fixe Firewall Secure défini sur la même valeur) pour accepter les demandes ACSLS entrantes provenant des CSC.

• Options valides : 1024 à 65535, sauf 50003, et 0 (cette valeur doit correspondre à celle définie sur le serveur ACSLS pour le port utilisé par la CSI pour les paquets entrants)

  • 0 indique que le comportement précédent consistant à interroger PortMapper sur le serveur ACSLS continue d'être utilisé.

  • 1024 à 65535 indique la valeur utilisée par la CSI pour les demandes entrantes.

  • NE PAS spécifier 50003, car il est utilisé par acslm.

• Autres détails : la définition de cette variable d'environnement élimine les interrogations de la CSI sur les ports Portmapper des serveurs ACSLSI. La valeur de cette variable spécifie le numéro de port sur le serveur ACSLS auquel la SSI doit envoyer ses demandes ACSLS sortantes. Cela permet à un serveur ACSLS protégé par un pare-feu de refuser l'accès à Portmapper. Auparavant, l'interrogation Portmapper permettait d'obtenir le numéro de port vers lequel la SSI doit diriger ses demandes ACSLS.

  Remarque :

  Cette valeur doit correspondre à celle utilisée par la CSI pour accepter et traiter les demandes entrantes. La fonctionnalité Firewall Secure doit être appliquée au logiciel ACSLS pour que ce port reste fixe de manière fiable en conservant la valeur spécifiée. En cas d'incohérence, aucune communication n'est possible entre le CSC et l'ACSLS.

Affichage et définition des variables d'environnement sur le client

Sur le client, les commandes permettant de définir des variables d'environnement dépendent du shell et du SE.

• Sous UNIX et Linux, affichez une variable d'environnement à l'aide de la commande suivante :

  echo $<variable-name>

• A l'aide des shells ksh et bash, vous pouvez définir une variable d'environnement en utilisant la commande suivante :

  <environment_variable> = <value>

  export <environment_variable>

Scénarios utilisant la solution Firewall Secure

Les diagrammes suivants présentent les scénarios possibles concernant le fonctionnement, l'utilisation des ports et les relations des composants ACSLS lorsqu'ils sont utilisés à travers un pare-feu. Ils sont précédés d'une légende présentant le contexte située juste au-dessus. La ”SSI” dans les diagrammes suivants désigne le composant d'interface réseau d'ACSLS exécuté sur le côté client des communications. La CSI désigne le composant d'interface réseau d'ACSLS exécuté sur la plate-forme ACSLS.

Remarque :

ACSLS CSC Developer’s Toolkit 2.3 (ou version ultérieure) et les nouvelles variables d'environnement sont requis pour que ces scénarios soient pris en charge.

Protection par pare-feu sur le côté serveur d'ACSLS uniquement

Dans cet exemple, la protection par pare-feu est implémentée sur le côté serveur d'ACSLS (CSI) uniquement. CSC Toolkit 2.3 (ou version ultérieure) et les nouvelles variables d'environnement ne sont pas nécessaires à la prise en charge de ce scénario.

Figure M-1 Protection par pare-feu sur le côté serveur d'ACSLS uniquement

Dans cet exemple, dynamique signifie que le port est sélectionné au démarrage par la SSI dans la plage 1024-65535. Le port n'est pas désigné par l'utilisateur et il n'est généralement pas fixe lors des nouvelles exécutions de la SSI (c'est-à-dire, il ne reste pas le même d'une instance d'exécution de la SSI à une autre).

Les ports Portmapper 111 du côté SSI sont rarement interrogés par la CSI. La CSI y accède seulement en cas de défaillance du numéro de port de retour fourni par la SSI dans son paquet de demande (c'est-à-dire, en cas de panne d'interface réseau) lors du renvoi des paquets de réponse à la SSI. Dans ce cas, pour effectuer une relance, la CSI interroge Portmapper du côté SSI pour identifier le port à utiliser (il est enregistré auprès de Portmapper sous le numéro de programme de la SSI).

Pour protéger ACSLS derrière un pare-feu, vous devez appliquer les paramètres suivants :

• ACSLS :  ACSLS must be restarted after any changes.

  • CSI_TCP_RPCSERVICE = TRUE

  • CSI_UDP_RPCSERVICE = FALSE

    (La valeur TRUE doit toutefois être attribuée à ce paramètre si des clients utilisent UDP pour communiquer avec ACSLS)

  • CSI_USE_PORTMAPPER = ALWAYS (ou bien IF_DUAL_LAN_NOT_ENABLED)

  • CSI_FIREWALL_SECURE = TRUE

  • CSI_INET_PORT = <1024-65535, not 50003> default 30031

• Paramètres SSI client - Variables d'environnement permettant à un client de s'exécuter derrière un pare-feu.

  • CSI_TCP_RPCSERVICE = TRUE

  • CSI_UDP_RPCSERVICE  = TRUE (could be FALSE)

  • SSI_INET_PORT = 0

    Il s'agit d'une nouvelle variable d'environnement d'ACSLS CSC Developer’s Toolkit 2.3 qui n'est pas requise pour ce scénario.

  • CSI_HOSTPORT  = 0 or <1024-65535, not 50003> default 30031

    Elle est inutile si vous utilisez Portmapper sur le serveur ACSLS. If defined and not zero, this must match CSI_INET_PORT on the ACSLS Server. Il s'agit d'une nouvelle variable d'environnement d'ACSLS CSC Developer’s Toolkit 2.3 (ou version ultérieure) qui n'est pas requise pour ce scénario.

Configurez le pare-feu pour permettre au client d'envoyer des demandes au serveur ACSLS via le port spécifié par CSI_INET_PORT (sur le serveur ACSLS) et par CSI_HOSTPORT (sur le client). Autorisez le client à accéder à Portmapper (port 111) sur le serveur ACSLS et autorisez le logiciel ACSLS à accéder à Portmapper (port 111) sur le client.

Protection par pare-feu sur le côté client uniquement

Dans cet exemple, la protection par pare-feu est implémentée sur le côté client (SSI) uniquement. CSC Toolkit 2.3 (ou version ultérieure) et les nouvelles variables d'environnement ne sont pas nécessaires à la prise en charge de ce scénario.

Figure M-2 Protection par pare-feu sur le côté client uniquement

Dans cet exemple, dynamique signifie que le port est sélectionné au démarrage par la CSI dans la plage 1024-65535. Le port n'est pas désigné par l'utilisateur et il n'est généralement pas fixe lors des nouvelles exécutions de la CSI (c'est-à-dire, il ne reste pas le même d'une instance d'exécution de la CSI à une autre).

Les ports Portmapper 111 du côté SSI sont rarement interrogés par la CSI. La CSI y accède seulement en cas de défaillance du numéro de port de retour fourni par la SSI dans son paquet de demande (c'est-à-dire, en cas de panne d'interface réseau) lors du renvoi des paquets de réponse à la SSI. Dans ce cas, pour effectuer une relance, la CSI interroge Portmapper du côté SSI pour identifier le port à utiliser (il est enregistré auprès de Portmapper sous le numéro de programme de la SSI).

Pour protéger le système client derrière un pare-feu, vous devez appliquer les paramètres suivants :

• ACSLS :  ACSLS must be restarted after any changes.

  • CSI_TCP_RPCSERVICE = TRUE

  • CSI_UDP_RPCSERVICE = FALSE

    If you have any clients using UDP to communicate with ACSLS, this must be TRUE. (La valeur TRUE doit être attribuée à ce paramètre si des clients utilisent UDP pour communiquer avec ACSLS)

  • CSI_USE_PORTMAPPER = ALWAYS (This could be IF_DUAL_LAN_NOT_ENABLED)

  • CSI_FIREWALL_SECURE = FALSE

  • CSI_INET_PORT = 0

• Paramètres SSI client - Variables d'environnement permettant à un client de s'exécuter derrière un pare-feu.

  • CSI_TCP_RPCSERVICE = TRUE

  • CSI_UDP_RPCSERVICE  = FALSE (could be TRUE)

  • SSI_INET_PORT = <1024 –65535, except 50001 and 50004>

    Il s'agit d'une nouvelle variable d'environnement d'ACSLS CSC Developer’s Toolkit 2.3 (ou version ultérieure) qui n'est pas requise pour ce scénario.

  • CSI_HOSTPORT  = 0 or <1024-65535, not 50003> default 30031

    Inutile si vous utilisez Portmapper sur le serveur ACSLS. If defined and not zero, this must match CSI_INET_PORT on the ACSLS Server. Il s'agit d'une nouvelle variable d'environnement d'ACSLS CSC Developer’s Toolkit 2.3 (ou version ultérieure) qui n'est pas requise pour ce scénario.

Pour configurer vos pare-feu, procédez comme suit :

• Autorisez le client à envoyer des demandes au serveur ACSLS via le port spécifié par CSI_INET_PORT (sur le serveur ACSLS) et par CSI_HOSTPORT (sur le client).

• Autorisez le client à accéder à Portmapper (port 111) sur le serveur ACSLS.

• Autorisez le serveur à envoyer des réponses au client via le port spécifié par SSI_INET_PORT sur le client.

• Autorisez le serveur ACSLS à interroger Portmapper sur le client via le port 111.

Protection par pare-feu des côtés serveur et client d'ACSLS avec Portmapper

Dans cet exemple, le client (SSI) et le serveur ACSLS (CSI) implémentent des API Firewall Secure. Le client et le serveur dépendent toujours de Portmapper pour l'identification des ports. CSC Toolkit 2.3 (ou version ultérieure) et les nouvelles variables d'environnement ne sont pas nécessaires à la prise en charge de ce scénario.

Figure M-3 Protection par pare-feu des côtés serveur et client d'ACSLS avec Portmapper

Les ports Portmapper 111 du côté SSI sont rarement interrogés par la CSI. La CSI y accède seulement en cas de défaillance du numéro de port de retour fourni par la SSI dans son paquet de demande (c'est-à-dire, en cas de panne d'interface réseau) lors du renvoi des paquets de réponse à la SSI. Dans ce cas, pour effectuer une relance, la CSI interroge Portmapper du côté SSI pour identifier le port à utiliser (il est enregistré auprès de Portmapper sous le numéro de programme de la SSI).

Pour les pare-feu protégeant le serveur ACSLS et le client, vous devez appliquer les paramètres suivants :

• ACSLS :  ACSLS must be restarted after any changes.

  • CSI_TCP_RPCSERVICE = TRUE

  • CSI_UDP_RPCSERVICE = FALSE

    La valeur TRUE doit toutefois être attribuée à ce paramètre si des clients utilisent UDP pour communiquer avec ACSLS.

  • CSI_USE_PORTMAPPER = ALWAYS (This could be IF_DUAL_LAN_NOT_ENABLED)

  • CSI_FIREWALL_SECURE = TRUE

  • CSI_INET_PORT = <1024-65535, not 50003> default 30031

• Paramètres SSI client - Variables d'environnement permettant à un client de s'exécuter derrière un pare-feu.

  • CSI_TCP_RPCSERVICE = TRUE

  • CSI_UDP_RPCSERVICE  = FALSE

  • SSI_INET_PORT = <1024 –65535, except 50001 and 50004>

  • CSI_HOSTPORT  = <1024-65535, not 50003> default 30031

    Doit correspondre à CSI_INET_PORT sur le serveur ACSLS.

Pour configurer vos pare-feu, procédez comme suit :

• Autorisez le client à envoyer des demandes au serveur ACSLS via le port spécifié par CSI_INET_PORT (sur le serveur ACSLS) et par CSI_HOSTPORT (sur le client).

• Autorisez le client à accéder à Portmapper (port 111) sur le serveur ACSLS.

• Autorisez le serveur à envoyer des réponses au client via le port spécifié par SSI_INET_PORT sur le client.

• Autorisez le serveur ACSLS à interroger Portmapper sur le client via le port 111.

Protection par pare-feu des côtés serveur et client d'ACSLS sans Portmapper

Dans cet exemple, le client (SSI) et le serveur ACSLS (CSI) implémentent les fonctionnalités Firewall Secure. Le client et le serveur ont activé la fonctionnalité ”No Portmapper”. CSC Toolkit 2.3 (ou version ultérieure) et les nouvelles variables d'environnement ne sont pas nécessaires à la prise en charge de ce scénario.

Figure M-4 Protection par pare-feu des côtés serveur et client d'ACSLS sans Portmapper

Les paramètres de configuration les plus sécurisés sont les suivants :

• ACSLS :  ACSLS must be restarted after any changes.

  • CSI_TCP_RPCSERVICE = TRUE

  • CSI_UDP_RPCSERVICE = FALSE

  • CSI_USE_PORTMAPPER = NEVER

  • CSI_FIREWALL_SECURE = TRUE

  • CSI_INET_PORT = <1024-65535, not 50003> default 30031

• Paramètres SSI client - Variables d'environnement permettant à un client de s'exécuter derrière un pare-feu.

  • CSI_TCP_RPCSERVICE = TRUE

  • CSI_UDP_RPCSERVICE  = FALSE

  • SSI_INET_PORT = <1024 –65535, except 50001 and 50004>

  • CSI_HOSTPORT  = <1024-65535, not 50003> default 30031

    Doit correspondre à CSI_INET_PORT sur le serveur ACSLS.

Pour configurer vos pare-feu, procédez comme suit :

• Autorisez le client à envoyer des demandes au serveur ACSLS via le port spécifié par CSI_INET_PORT (sur le serveur ACSLS) et par CSI_HOSTPORT (sur le client).

• Autorisez le serveur à envoyer des réponses au client via le port spécifié par SSI_INET_PORT sur le client.

Activation de la protection par pare-feu sur les serveurs ACSLS

Pour activer la fonctionnalité Firewall Secure, vous devez définir plusieurs variables à l'aide de l'utilitaire acsss_config.

1. Connectez-vous en tant qu'utilisateur acsss.

2. Arrêtez le serveur ACSLS.

   Remarque :

   Vous devez arrêter le serveur ACSLS pour que les nouvelles variables Firewall Secure prennent effet.

   acsss disable

3. Pour exécuter le script de configuration, entrez la commande suivante :

   acsss_config

   L'écran de configuration des fonctionnalités ACSLS s'affiche.

4. Sélectionnez l'option 1 : Set CSI tuning variables

   Acceptez la valeur par défaut de toutes les variables, à l'exception des suivantes.

   1. Définissez la valeur sur TRUE à l'invite suivante :

      Changes to alter use of the TCP protocol will not take effect until the product is restarted. (Les changements visant à modifier l'utilisation du protocole TCP ne seront pas appliqués avant le redémarrage du produit.) CSI support for RPC using the TCP protocol is enabled [TRUE].(La prise en charge du RPC par la CSI à l'aide du protocole TCP est activée [TRUE].)

      Variable : CSI_TCP_RPCSERVICE

      L'activation de TCP garantit la mise à disposition du protocole TCP pour les clients ACSLS pour les communications réseau. Comme la fonctionnalité Firewall Secure d'ACSLS prend uniquement en charge TCP, les clients doivent établir des communications réseau à l'aide de ce protocole.

   2. Définissez la valeur sur FALSE à l'invite suivante :

      Changes to alter use of the UDP protocol will not take effect until the product is restarted. (Les changements visant à modifier l'utilisation du protocole UDP ne seront pas appliqués avant le redémarrage du produit.) CSI support for RPC using the UDP protocol is enabled [TRUE].(La prise en charge du RPC par la CSI à l'aide du protocole UDP est activée [TRUE].)

      Variable : CSI_UDP_RPCSERVICE

      Mise en garde :

      Assurez-vous qu'aucun client ACSLS ne dépend du protocole UDP. La fonctionnalité Firewall Secure d'ACSLS s'exécute sur TCP uniquement.

      La désactivation d'UDP garantit qu'aucun client n'accède au serveur à l'aide de ce protocole. Cela vous permet de refuser tous le accès généraux à la plate-forme ACSLS via UDP et d'autoriser uniquement les accès spécifiquement requis dans votre environnement.

      Autorisez les clients à accéder à Portmapper via le port UDP et TCP 111, sauf s'ils implémentent la fonctionnalité Firewall Secure, et désactivez spécifiquement leurs requêtes adressées au service Portmapper ACSLS.

   3. Définissez la valeur sur NEVER à l'invite suivante :

      Changes to alter use of the port mapper will not take effect until the product is restarted. (Les changements visant à modifier le mappeur de ports ne seront pas appliqués avant le redémarrage du produit.) Enable port mapper (Activez Portmapper) : (ALWAYS / NEVER /IF_DUAL_LAN_NOT_ENABLED) [IF_DUAL_LAN_NOT_ENABLED].

      Variable : CSI_USE_PORTMAPPER

      NEVER permet aux clients ACSLS de refuser l'accès externe à Portmapper sur ces plates-formes client.

      Important : Cela ne vous autorise pas à désactiver l'accès externe à Portmapper sur la plate-forme ACSLS. Pour cela, les clients ACSLS doivent adopter les modifications apportées à Firewall Secure dans les composants logiciels clients et ce paramètre doit être activé dans le composant logiciel client.

      Ce paramètre permet de garantir que le serveur ACSLS n'interrogera pas Portmapper sur la plate-forme client. Il permet à un pare-feu qui protège le client de refuser l'accès à Portmapper.

   4. Définissez la valeur sur TRUE à l'invite suivante :

      Enable CSI to be used behind a firewall (user-defined inbound port) (TRUE/FALSE) [FALSE]: [Activer la CSI pour une utilisation derrière le pare-feu (port entrant défini par l'utilisateur)]

      Variable : CSI_FIREWALL_SECURE

      TRUE vous permet de spécifier le seul port que le logiciel ACSLS doit utiliser pour accepter les communications client entrantes (connexions TCP). Cette variable permet simplement d'activer cette fonctionnalité. C'est la variable suivante qui permet d'indiquer un port spécifique.

   5. Attribuez la valeur correspondant à un port fixe disponible sur le serveur ACSLS, à l'invite suivante :

      Port number used by the CSI to receive incoming ACSLS requests. (Numéro de port utilisé par la CSI pour recevoir des demandes ACSLS entrantes.)

      Variable : CSI_INET_PORT

      Il s'agit du port qui sera utilisé par le composant CSI ACSLS pour accepter des connexions réseau entrantes. Spécifiez un port compris entre 1024 et 65535, à l'exception du port 50003.

      IMPORTANT : Configurez le pare-feu pour autoriser les connexions entrantes sur ce port. Cela permet de garantir que seul ce port est exposé pour être utilisé par les clients extérieurs qui veulent initier des communications avec ACSLS. Vous pouvez refuser les connexions sur tous les autres ports entrants à l'exception de celui-ci et du port UDP/TCP 111 (sauf si les clients ont implémenté la fonctionnalité permettant d'éliminer leurs requêtes adressées au service Portmapper ACSLS ; dans ce cas, le port 111 peut aussi être refusé au niveau du pare-feu). La valeur par défaut recommandée pour ce port est 30031. Il est peu probable (mais pas impossible) que ce port soit utilisé par d'autres processus sur la plupart des systèmes. Reportez-vous à l'Dépannage pour connaître les étapes à suivre en cas de conflit de ports.

5. Sélectionnez E pour quitter acsss_config.

   Vos modifications sont sauvegardées.

6. Redémarrez ACSLS à l'aide de la commande suivante :

   acsss enable

Désactivation de la protection par pare-feu sur les serveurs ACSLS

Certaines variables indiquées ci-dessus qui permettent d'activer Firewall Secure sont aussi liés à la désactivation de cette fonctionnalité. Pour désactiver le comportement de Firewall Secure, il suffit d'effectuer les étapes ci-après, mais il est possible qu'un site spécifique veuille également modifier d'autres variables.

1. Connectez-vous en tant qu'utilisateur acsss.

2. Arrêtez le serveur ACSLS.

   Remarque :

   Arrêtez le serveur ACSLS pour que les nouvelles variables Firewall Secure prennent effet.

   acsss disable

3. Pour exécuter le script de configuration, entrez la commande suivante :

   acsss_config

4. Sélectionnez l'option 1 : Set CSI tuning variables

   Modifiez les valeurs suivantes qui ont été définies lors de la configuration de la fonctionnalité Firewall Secure. Modifiez les variables suivantes :

   1. Définissez la valeur sur ALWAYS à l'invite suivante :

      Changes to alter use of the port mapper will not take effect until the product is restarted. (Les changements visant à modifier le mappeur de ports ne seront pas appliqués avant le redémarrage du produit.) Enable port mapper (Activez Portmapper) : (ALWAYS / NEVER /IF_DUAL_LAN_NOT_ENABLED) [IF_DUAL_LAN_NOT_ENABLED].

      Variable : CSI_USE_PORTMAPPER

   2. Définissez la valeur sur FALSE à l'invite suivante :

      Enable CSI to be used behind a firewall (user-defined inbound port) (TRUE/FALSE) [FALSE]: [Activer la CSI pour une utilisation derrière le pare-feu (port entrant défini par l'utilisateur)]

      Variable : CSI_FIREWALL_SECURE

5. Sélectionnez E pour quitter acsss_config.

   Vos modifications sont sauvegardées.

6. Redémarrez ACSLS à l'aide de la commande suivante :

   acsss enable

Configuration de Firewall Secure

La procédure suivante exige que vous sachiez configurer le pare-feu réseau derrière lequel réside ACSLS. TOUS les pare-feu sont des logiciels tiers ayant chacun leurs spécificités quant à la configuration adaptée pour protéger votre environnement réseau. La section suivante n'a pas pour but de recommander une stratégie de protection par pare-feu, mais de fournir un ensemble d'instructions utiles sur ce qu'un pare-feu doit ou peut accomplir pour le produit ACSLS exclusivement. Pour plus d'informations sur la sécurité, contactez l'administrateur de votre système.

Voici une liste de recommandations pour configurer un pare-feu pour la plate-forme ACSLS :

• Mettez en place une règle générale pour refuser les connexions UDP entrantes et sortantes.

• Mettez en place une règle générale pour refuser les connexions TCP entrantes (les connexions TCP sortantes doivent rester ouvertes).

• Mettez en place une règle spécifique pour autoriser les connexions TCP entrantes sur le port spécifié pour ACSLS. IMPORTANT : ce port doit correspondre à celui configuré sous acsss_config, ou vous ne recevrez aucune communication client au niveau du serveur ACSLS.

Si tous vos clients ont implémenté la fonctionnalité Firewall Secure sans adresser de requêtes au service Portmapper de la plate-forme ACSLS, la procédure est terminée. Si les clients continuent de se servir de Portmapper sur la plate-forme ACSLS, vous devez effectuer l'opération suivante :

• Mettez en place une règle spécifique pour autoriser les connexions entrantes et sortantes sur le port Portmapper TCP et UDP 111 connu.

Exemple :

Voici un exemple de règles mises en place pour un pare-feu basé sur des tables IP afin d'appliquer toutes les recommandations qui précèdent.

Remarque :

les éléments ci-après s'ajoutent aux autres règles configurées pour un pare-feu spécifique.

echo " - FWD: Allow all connections OUT and only existing/related IN"
$IPTABLES -A FORWARD -i $EXTIF -o $INTIF -m state --state \
ESTABLISHED,RELATED -j ACCEPT
# These rules allow client access to the portmapper
$IPTABLES -A FORWARD -p tcp -i $EXTIF --dport 111 -j ACCEPT
$IPTABLES -A FORWARD -p udp -i $EXTIF --dport 111    -j ACCEPT
# These rules allow client access to the ACSLS CSI for network communication
# Note: This assumes that the CSI firewall-secure port was specified as 30031
$IPTABLES -A FORWARD -p tcp -i $EXTIF --dport 30031 -j ACCEPT
# Catch all rule, all other forwarding is denied and logged.
$IPTABLES -A FORWARD -j drop-and-log-it

Résolution des problèmes de communication liés à Firewall Secure

Le dépannage d'une interface de communication réseau comprenant la plate-forme et des clients ACSLS, et qui inclut désormais des pare-feu intermédiaires, peut nécessiter plusieurs étapes. L'introduction de pare-feu dans l'intervalle entre ACSLS et ses clients entraîne des risques de pannes de communication réseau plus importants. Par ailleurs, l'augmentation du nombre de composants pose un problème de configuration, car leurs paramètres doivent être compatibles entre eux pour ne pas affecter les communications réseau. Voici une liste de points à vérifier et de solutions à essayer si vous avez terminé toutes les tâches de configuration sur le logiciel ACSLS, ses clients et les pare-feu et que les communications réseau ne fonctionnent pas.

1. Vérification de la plate-forme ACSLS :

   • Le logiciel ACSLS est-il en cours d'exécution ? S'il ne l'est pas, recherchez des raisons possibles ou des conseils pour identifier un éventuel responsable dans le fichier acsss_event.log.

   • Le logiciel ACSLS parvient-il à exécuter correctement la CSI ? Si ce n'est pas le cas, le fichier acsss_event.log doit contenir des messages d'information indiquant la cause du problème. Il s'agit probablement d'une erreur au niveau des paramètres de configuration ou d'un conflit de ports.

   • Existe-t-il un conflit de ports consigné dans le fichier acsss_event.log qui provoque l'échec du CSI ? Dans ce cas, exécutez ”netstat” ou un utilitaire système similaire pour identifier les ports utilisés et configurer le logiciel ACSLS pour qu'il se serve d'un port disponible. N'oubliez pas de modifier la configuration du pare-feu en conséquence.

   • La CSI est-il inscrite au niveau du port prévu ? Utilisez la commande 'rpcinfo -p' pour consulter la table Portmap. La CSI est inscrite sous le numéro de programme 300031. Vérifiez que le port inscrit sous ce numéro de programme correspond à celui attendu (le port par défaut est 30031, et contient un zéro de moins que le numéro de programme).

2. Si le logiciel ACSLS et la CSI fonctionnent et sont correctement enregistrés, il convient ensuite de vérifier l'accès à la plate-forme ACSLS à travers le pare-feu :

   • Est-il possible d'accéder au logiciel ACSLS via un RPC de base ? Utilisez la commande ”rpcinfo -t <hostname> <program-number> <version-number>” pour envoyer une demande RPC simple au CSI. (Utilisez ”man rpcinfo” sur votre système pour obtenir des informations supplémentaires sur la commande rpcinfo et sa fonction.) Effectuez cette procédure sur une machine située à l'intérieur du pare-feu avec ACSLS (par exemple, depuis la plate-forme ACSLS elle-même), et à l'extérieur du pare-feu. Si l'accès est possible de l'intérieur mais pas de l'extérieur, le pare-feu intercepte les demandes ACSLS. Vérifiez de nouveau la configuration du pare-feu et du port ACSLS. Assurez-vous que Portmapper est accessible via le pare-feu (ce test ne fonctionne pas depuis l'extérieur du pare-feu si l'accès à Portmapper est défini sur disallowed).

   • Les ports configurés pour ACSLS et le pare-feu correspondent-ils ? Revérifiez ces paramètres. Il s'agit d'une cause probable des pannes de communication réseau. Après avoir vérifié les valeurs configurées, exécutez la commande 'rpcinfo -p' mentionnée ci-avant, pour vous assurer que la CSI s'enregistre sous le numéro de port prévu. Dans le cas contraire, recherchez dans le fichier acsss_event.log des informations sur l'origine de l'erreur.

   • Le logiciel ACSLS reçoit-il des demandes, sans pouvoir envoyer de réponses ? Si, en consultant le journal d'événements acsss_event.log, vous constatez que la CSI signale de nombreux abandons de paquet réseau ou d'échecs de communication avec les clients réseau, les demandes des clients rentrent, mais les réponses ne sortent pas. Encore une fois, cela indique que les demandes sont bloquées par un pare-feu.

3. Si le problème persiste.

   La section ci-avant traite de différents éléments à vérifier à plusieurs niveaux. Si aucune réponse précise ne s'en dégage, il est temps de procéder à une vérification de niveau inférieur pour découvrir à quel endroit les communications sont interrompues. La meilleure méthode consiste à recourir à un analyseur de réseau pour suivre les paquets, par exemple 'snoop' sous Solaris. Utilisez ”man snoop” sur votre système Solaris pour en savoir plus sur la commande snoop et sa fonction.

   Des dispositifs similaires de suivi de paquets sont disponibles sur d'autres systèmes connectés au réseau.

   • Pour utiliser cette méthode, vous devez procéder à l'analyse des paquets aux endroits où ils arrivent avant de se perdre. Cette analyse peut s'effectuer à l'intérieur ou à l'extérieur du pare-feu.

   • Par ailleurs, l'analyse des données des paquets doit permettre de fournir des informations. Si chaque côté du pare-feu est compatible avec Portmapper, des paquets PORTMAP sont probablement présents.

   • De plus, il est probable que des paquets RPC soient transmis entre ACSLS et ses clients.

   • Enfin, l'analyse des connexions TCP au niveau du transport fournir des renseignements sur les ports utilisés de chaque côté. Ces informations sont souvent cruciales pour identifier à quel endroit les communications sont coupées.

Les instructions détaillées pour effectuer ces opérations ne rentrent pas dans le cadre de ce manuel, toutefois votre administrateur système devrait être en mesure de vous y aider.

Questions fréquemment posées

• Pourquoi la solution Firewall-Secure est-elle nécessaire pour ACSLS ?

  La solution Firewall Secure permet d'exécuter efficacement le logiciel ACSLS derrière un pare-feu et de restreindre l'accès aux ports de ce pare-feu pour renforcer la sécurité de manière significative.

• Quelles versions d'ACSLS prennent en charge la fonctionnalité Firewall Secure ?

  Seule ACSLS 7.0.0 et les versions ultérieures prennent en charge cette fonctionnalité.

• Quel est le nombre maximal de ports à garder ouverts pour utiliser la fonctionnalité Firewall Secure ?

  Le nombre maximal de ports sur lesquels vous pourriez devoir autoriser les connexions réseau entrantes est égal à trois, un pour l'interface réseau ACSLS et deux pour Portmapper (UDP et TCP 111). Les ports sont sans restrictions, conformément aux pratiques acceptées par l'industrie en matière de sécurité.

• Quelle est le nombre minimal de ports pouvant rester ouverts ?

  Le nombre minimal est un. Un seul port peut rester ouvert si vos clients (logiciels ISV) ont également implémenté la fonctionnalité Firewall Secure sur leur système et qu'ils n'interrogent pas le service Portmapper résidant sur la plate-forme ACSLS. Dans ce cas, le seule port qui doit être ouvert pour les connexions entrantes est le port TCP spécifié par l'utilisateur dont se sert l'interface réseau ACSLS.

• Pourquoi la fonctionnalité utilise-t-elle une plage de ports ?

  Les plages de ports ne présentent aucun avantage en termes d'architecture mais engendrent un certain nombre d'inconvénients liés à la sécurité. Sans la fonctionnalité Firewall Secure, le logiciel ACSLS utilise une plage de ports constituée de l'intervalle complet des ports dynamiques d'une plate-forme donnée. Cette configuration est perçue à juste titre comme un risque potentiel vis-à-vis de la sécurité d'un site. L'objectif est de limiter autant que possible le nombre de ports ouverts, sans compromettre les performances d'ACSLS, afin d'éliminer ce risque. Comme l'interface réseau ACSLS utilise un seul port entrant à tout moment, il est inutile d'étendre la plage à plusieurs ports, à condition que l'unique port soit dédié à l'usage d'ACSLS pour la plate-forme.

• Qu'advient-il si le port choisi est en conflit avec un élément du système utilisant ce même port ?

  C'est l'une des raisons pour lesquelles le port est conçu de manière à pourvoir être spécifié par l'utilisateur. Les ports spécifiques disponibles varient d'un site de client à l'autre. L'utilisateur n'est pas autorisé à se servir de l'un des ports réservés connus dans la plage 0 à1023. Le port par défaut 30031 est compris dans la plage des ports inscrits, ce qui rend son utilisation par une autre application se servant de ports dynamiques moins probable (mais pas impossible). Bien qu'inclus dans la plage des ports inscrits, il n'est réservé par aucune application et peut donc logiquement faire office de sélection par défaut.

• Cette fonctionnalité me permet-elle de protéger le serveur ACSLS avec un pare-feu ?

  Oui, lorsque cette fonctionnalité est installée, le serveur ACSLS peut être placé du côté approuvé d'un pare-feu, avec les clients y accédant depuis le côté opposé (non approuvé) ou du même côté.

• Cette fonctionnalité me permet-elle de protéger mes clients ACSLS (composants ISV) avec un pare-feu ?

  En principe, oui, mais pas seule. Pour mettre en oeuvre ce scénario, les composants logiciels clients (les clients du ACSLS) doivent adopter la fonctionnalité Firewall Secure, disponible dans StorageTek ACSLS Client System Component Developer Toolkit. Contactez le fournisseur de votre logiciel client pour faire le point sur son statut actuel.

• Si je souhaite protéger mes clients avec un pare-feu, comment dois-je procéder ?

  Vous devez contacter le fournisseur de votre logiciel client. Il pourra vous dire si son composant logiciel client (CSC) a été mis à jour avec la fonctionnalité Firewall Secure.

• Qu'en est-il de Portmapper ? Est-il possible de refuser totalement l'accès à Portmapper ?

  Si vos clients ont adopté les modifications liées à Firewall Secure, vous pourrez peut-être arrêter les interrogations des clients adressées au service Portmapper de la plate-forme ACSLS. Dans ce cas, vous pouvez refuser l'accès à Portmapper sur le pare-feu qui protège la plate-forme ACSLS. Dans tous les autres cas, les clients dépendent de Portmapper du côté serveur ACSLS pour pouvoir établir une connexion avec l'interface réseau ADSLS et ils doivent y avoir accès.

• Pourquoi faut-il que le client implémente certaines modifications pour que le pare-feu du serveur ACSLS interrompe l'accès au service Portmapper de la plate-forme ACSLS ?

  Parce que c'est le client qui interroge la plate-forme ACSLS. Si le client continue d'effectuer ces requêtes, la plate-forme ACSLS ne doit pas cesser de fournir le service Portmapper afin qu'elles aboutissent.

• Je pense que le service Portmapper est nuisible. Pourquoi ne pas l'avoir supprimé complètement ?

  Le service Portmapper est très utile pour les clients hérités. Sa suppression complète invaliderait l'interface dont ces clients dépendent. En résumé, aucun client hérité ne fonctionnerait sans procéder à un recodage, de nouveaux essais et une certification avec la nouvelle interface sans Portmapper. Dans cette solution Firewall Secure, nous avons fourni la possibilité de supprimer les requêtes adressées à Portmapper, d'ACSLS au client et inversement, mais il n'est pas possible de forcer les logiciels clients à faire de même. Portmapper doit donc rester disponible au moins en tant que service facultatif jusqu'à ce que les clients des sites adoptent les fonctionnalités Firewall Secure et cessent d'utiliser le service Portmapper.

• Certains de mes clients ont adopté les fonctionnalités Firewall Secure mais pas tous. Comment en tirer parti ?

  Il se peut que les clients qui ont adopté ces fonctionnalités soient protégés derrière leurs propres pare-feu. Par ailleurs, l'accès aux ports connus de Portmapper peut être restreint au niveau du pare-feu, puis configuré pour que seuls les clients qui en ont besoin puissent accéder à Portmapper. Les configurations et les niveaux d'accès varient en fonction du pare-feu utilisé sur le site.

• Je pense que RPC est nuisible. Pourquoi ne pas l'avoir supprimé complètement ?

  L'interface réseau ACSLS est basée sur RPC depuis la première version d'ACSLS. RPC s'est révélé être un mécanisme efficace, stable et fiable, qui offre divers avantages au niveau de la couche des communications réseau. Néanmoins, il peut aussi être plus difficile de sécuriser une plate-forme qui utilise RPC en raison de l'allocation dynamique commune des ports et de l'utilisation de Portmapper. Dans la solution Firewall Secure, ces deux points sont résolus, ce qui permet à l'utilisateur de configurer efficacement un pare-feu de manière restrictive, en offrant les avantages liés à la sécurité pour lesquels le pare-feu a été mis en place.

  De plus, la suppression complète de RPC de l'interface réseau ACSLS invaliderait tous les clients ACSLS (hérités) actuels, en les empêchant de communiquer avec ACSLS sans un recodage, de nouveaux essais et une nouvelle certification de leurs composants logiciels client (CSC).

• Quelles sont les incidences de la fonctionnalité Firewall Secure sur les performances des communications réseau et sur les délais entre les clients et le serveur ACSLS ?

  Les nouvelles fonctionnalités Firewall Secure n'affectent pas les performances. L'emploi d'un pare-feu risque de nuire aux performances, mais les effets dépendent des caractéristiques opérationnelles de chaque implémentation par un client donné. Lorsque les effets d'un pare-feu sont négligeables au niveau des performances, le logiciel ACSLS et ses clients continuent de fonctionner comment avant l'installation de la fonctionnalité Firewall Secure. Par ailleurs, il est possible de configurer les tolérances de l'interface réseau ACSLS, de sorte que les délais imposés par le pare-feu puisse être gérés progressivement.

• Quelles sont les incidences de la fonctionnalité Firewall Secure sur les autres opérations ACSLS ?

  L'installation de la solution Firewall Secure n'a pas d'impact sur les autres parties des opérations ACSLS.

• Quels sont les effets de Firewall Secure sur les fonctionnalités ACSLS utilisées par mon client (via l'interface ACSAPI) ?

  L'ensemble des fonctionnalités disponibles via l'interface ACSAPI (et que nos clients ACSLS utilisent actuellement pour communiquer avec ACSLS) fonctionnent de la même façon avec ou sans Firewall Secure. Notamment, Firewall Secure prend en charge le contrôle d'accès, ainsi que les nouvelles fonctionnalités qui ont été ajoutées au produit ACSLS. Les fonctionnalités de l'interface ACSAPI continuent d'être prises en charge dans leur intégralité par Firewall Secure.

• La fonctionnalité Firewall Secure fonctionne-t-elle avec la solution ACSLS High Availability (HA) ?

  La fonctionnalité Firewall Secure ne nuit pas au fonctionnement de la haute disponibilité (HA). Néanmoins, la solution HA n'est pas conçue pour s'exécuter à travers un pare-feu (c'est-à-dire, lorsque les serveurs HA sont situés de part et d'autre d'un pare-feu). La solution HA requiert un accès distant à Portmapper, afin que le pare-feu ne puisse pas refuser l'accès à ce service en cas de tentative d'exécution des deux serveurs de chaque côté du pare-feu. Il existe d'autres facteurs liés à l'exécution de HA à travers un pare-feu qui risquent de nuire à ce type d'installation, cette configuration HA est vivement déconseillée.

  Si des serveurs HA sont installés du même côté sécurisé du pare-feu, il est possible de configurer cet ensemble de serveurs HA avec la fonctionnalité Firewall Secure. Les clients situés du côté opposé du pare-feu peuvent alors interagir à travers le pare-feu en présentant les mêmes performances et le même comportement que pour une solution HA sans Firewall Secure.

• La fonctionnalité Firewall Secure fonctionne-t-elle avec les autres produits logiciels StorageTek ?

  L'interopérabilité avec les autres produits StorageTek et les produits partenaires (c'est-à-dire, les composants logiciels client qui communiquent avec ACSLS) a été intégralement préservée. Ces produits peuvent continuer à fonctionner sans modification, en communiquant avec le serveur ACSLS, qu'il soit exécuté derrière un pare-feu sécurisé ou dans leur environnement (comme c'est actuellement le cas).

• Les autres produits logiciels StorageTek sont-ils aussi dotés des mêmes fonctionnalités Firewall Secure ?

  Les autres produits StorageTek ne bénéficient pas forcément des avantages de Firewall Secure simplement parce qu'ils sont utilisés dans le même environnement que la fonctionnalité Firewall Secure d'ACSLS. Chaque produit peut fonctionner avec un serveur ACSLS protégé par un pare-feu (voir la question précédente), mais la pertinence d'installer ces produits derrière leur pare-feu respectif est une question à soulever individuellement. Certains produits StorageTek intègrent déjà des stratégies permettant d'appliquer certaines restrictions au niveau des pare-feu destinés à protéger les plates-formes sur lesquelles ces produits sont exécutés. Par ailleurs, tout produit servant de client à ACSLS a la possibilité d'adopter les mises à jour Firewall Secure apportées à ACSLS, et qui sont fournies comme éléments d'ACSLS CSC Developer’s Toolkit 2.3 (ou version ultérieure).